最近遇到一个so
库符号冲突的问题, 可以总结为:
- 动态库
so1
中静态编译了某基础库 - 动态库
so2
中动态链接了该基础库的另一版本 - 可执行程序动态链接了这两个
so
- 程序执行到
so2
中函数时, 调用了so1
中的基础库的符号, 而恰好该基础库两个版本的同名函数不兼容, 因而出现了崩溃.
下面通过demo
代码来说明如何解决这个问题.
Keep learning, keep living...
最近遇到一个so
库符号冲突的问题, 可以总结为:
so1
中静态编译了某基础库so2
中动态链接了该基础库的另一版本so
so2
中函数时, 调用了so1
中的基础库的符号, 而恰好该基础库两个版本的同名函数不兼容, 因而出现了崩溃.下面通过demo
代码来说明如何解决这个问题.
VMware vSphere
的很多高级特性都依赖于共享存储, 如vMotion
, HA: High Availability
, DRS: Distributed Resource Schedule
等, 它们要生效都需要虚拟机的存储位于共享存储中. vSphere
支持的共享存储除了自家的vSAN
, 还包括: NFS
, iSCSI
, 光纤通道: Fibre Channel
等.
iSCSI
是一个标准协议, 全称为:Internet Small Computer System Interface
, 它在以太网
上基于TCP/IP
协议来传输SCSI
协议. SCSI
协议是计算机上的I/O
传输协议, SCSI
控制器通过SCSI
总线与硬盘等设备以块为单位传输数据. iSCSI
服务器称为target
, 客户端称为initiator
. iSCSI initiator
能够以纯软件实现运行在标准网络适配器上, 也可以以硬件形式实现为专用的HBA
卡:(Host Bus Adaptor
), 也有带有iSCSCI offload
硬件支持的网卡可以来加速iSCSI
协议处理.
iSCSI
协议层次如图(来自: https://www.snia.org/education/what-is-iscsi):
在VMware NSX-T
网络构建中,有两个地方需要配置VLAN
, 分别是:
逻辑交换机/分段
中的VLAN
, 如图:
Uplink Profile
中的传输VLAN(Transport VLAN
), 如图:
逻辑交换机
的VLAN
决定了逻辑交换机上的端口类型,表示access
或者trunk
类型的端口。逻辑交换机
又分为基于VLAN
类型和Overlay
类型两种。
对于VLAN
类型的逻辑交换机
, 如果配置的VLAN
为单一VLAN
时,表示端口为access
类型。这时逻辑交换机
与所连接的虚拟接口间的数据是不携带VLAN tag
的,但发送到ESXi主机外部的物理网络的报文会携带有所配置的VLAN tag
。VLAN 0
则比较特殊,在NSX-T
以及vSphere
体系里都表示不携带VLAN tag
。而如果配置多个VLAN
后,表示端口为trunk
类型。这种情况下,发送到逻辑交换机
的报文则必须携带有配置范围内的VLAN tag
。而该tag
也会透传到外部物理网络。因而使用VLAN
类型的逻辑交换机需要底层物理网络做相应的配置允许相应的VLAN
通行。
而对于Overlay
类型的逻辑交换机
, 可以不配置VLAN
, 这种情况下,逻辑交换机
的端口为access
类型。当设置VLAN
时,即使设置的是单一VLAN
,也会自动修改为trunk
类型。这种情况下,逻辑交换机
与虚拟接口间的报文则必须携带配置范围内的VLAN tag
。
整体逻辑可以梳理为:
首先介绍NSX-T
的基本概念。
参与构建NSX-T
网络的节点叫做传输节点(Transport Node)
, 包括ESXi
主机、KVM
主机和EDGE
节点。传输节点
上需要配置构建NSX-T
网络所需的NSX虚拟交换机
,可以新建N-VDS
类型的交换机,也可以复用vCenter
上所创建的VDS
, 如图:
逻辑交换机(logical switch)
也叫分段(segment)
为虚拟机提供网络接入点,它需要附着于NSX虚拟交换机
之上。有些场景下,逻辑交换机
并不需要在所有传输节点
上都存在,NSX-T
使用传输区域
来表示传输节点
的范围。NSX虚拟交换机
在创建时,需要配置所关联的传输区域
。
在程序中, 时间一般有两种表示方法:
UNIX
时间戳(UNIX timestamp
): 表示的是从UTC
时间1970年1月1日0时0分0秒起至现在的总秒数, 它也叫做epoch
,UNIX
时间,POSIX
时间等等。在同一时刻,全球所有地方的UNIX
时间戳都相同。
本地时间: 是以人类可读的格式表示的时间,比如2022-9-24 00:00:00
。由于时区
概念的存在,在同一UNIX
时间戳所表示的时间点,各时区的本地时间是不同的,如下图:
CST(China Standard Time)
时区中时间为2022-09-24 00:00:00
的时刻,UTC
时间为2022-09-23 16:00:00
。
以虚拟机镜像或者自带操作系统形式交付的产品往往需要对系统进行各种各样的配置,如IP设置、DNS设置等等。为了提升用户体验,提供更简化的使用方式,往往会在console
界面提供GUI/TUI
的交互方式, 如XenServer
的console
界面:
本文介绍在CentOS7
系统上增加GUI
界面的方法。
Linux系统的终端输入/输出设备一般称为TTY
,是TeleTypewriter
的缩写, 它的历史可以参考这两篇文章:
getty
是管理物理或者虚拟终端(ttys
)程序的通用名称,表示get tty
,用于防止非授权访问系统。当getty
检测到终端连接时,它获取用户输入用户名, 然后执行login
程序获取用户输入密码来进行登录校验。
从终端登录的一般过程是:
init
进程,它是一号进程。init
进程会在特定的tty
启动getty
进程获取用户名。exec
执行login
程序处理登录过程login
登录校验成功后,执行相应用户指定的shell
程序在C/S
架构中,Server
端需要依赖ID
来唯一标识Client
,而客户端相关数据都由这个唯一标识来索引。
这个标识可以由服务端分配,也可以由客户端自行生成再注册到服务端。
服务端分配是一种中心化生成方式,可以保证唯一性。客户端自行生成方式可以采用UUID
标准来生成,也可以保证唯一性。
尽管在生成方式可以保证唯一性,但是由于客户端某些特性的改变,服务端依然会出现ID
冲突的场景。
流量控制Traffic Control
简称TC
,表示网络设备接收和发送数据包的排队机制。比如,数据包的接收速率、发送速率、多个数据包的发送顺序等。
Linux实现了流量控制子系统,它包括两部分:
traffic control
框架iproute2
软件包中的tc
程序它们有些类似于内核态的netfilter
框架和用户态的iptables
程序。但相较于netfilter
, 关于tc
的资料非常少,并且也较为古老,彻底理解它的机制还是需要对照源码。
Traffic Control
的作用包括以下几种:
Shaping
): 通过推迟数据包发送来控制发送速率,只用于网络出方向(egress
)Scheduling
):调度不同类型数据包发送顺序,比如在交互流量和批量下载类型数据包之间进行发送顺序的调整。只用于网络出方向(egress
)Policing
): 根据到达速率决策接收还是丢弃数据包,用于网络入方向(ingress
)Dropping
): 根据带宽丢弃数据包,可以用于出入两个方向在一些业务环境的VMware Guest
虚拟机上安装我们的内核模块后,偶尔虚拟机会变成无响应的状态。重启后登录系统查看,处于无响应状态的那段时间在/var/log/messages
中却没有任何信息,完全没有分析问题原因的头绪。
经过调研,找到两种方法可以帮助排查定位这类系统失去响应的问题,分别是:
NMI: Non-Maskable Interupt
给虚拟机最近CentOS7
服务器上遇到一个系统崩溃:
1 | [92957.332974] BUG: unable to handle kernel NULL pointer dereference at 0000000000000a30 |