SANLock
介绍
sanlock守护程序管理具有共享存储的主机群集上运行的应用程序的租约。所有租赁管理和协调都是通过在共享存储上读写块来完成的。使用两种类型的租约,每种租约基于不同的算法:
- 增量租约的获取速度很慢,并且需要常规I / O才能共享存储。增量租赁存在于单个存储扇区中。获取增量租约涉及对该扇区的读取和写入,并通过特定的延迟将其分开。一旦获得租约,必须通过定期更新该部门的时间戳来续订租约。sanlock在内部使用增量租约在host_id上保留租约。host_id租约可防止两个主机使用相同的host_id,并根据续订提供基本的主机活动信息。
- paxos租约通常可以快速获取,并且sanlock使它们可以作为通用资源租约提供给应用程序。paxos租约存在于1MB的共享存储中(对于4k扇区为8MB)。获取Paxos租约涉及以磁盘Paxos算法指定的特定顺序读取和写入max_hosts(2000)扇区。paxos租约在内部使用host_id表示租约的所有者,如果不同的主机使用相同的host_id,则算法将失败。因此,增量租约提供了paxos租约中使用的唯一host_id。paxos租约还指代delta租约,以检查host_id是否有效。
在使用sanlock之前,用户必须为每个主机分配一个host_id,该值是1到2000之间的一个数字。不应为两个主机赋予相同的host_id(即使增量租约尝试检测到此错误)。sanlock将存储池视为“锁空间”。每个不同的存储池(例如来自不同来源的存储池)通常会定义为具有唯一锁空间名称的单独锁空间。
必须为Sanlock保留并初始化此存储空间的一部分,以存储增量租约。每个要使用锁空间的主机必须首先在其锁空间内的host_id号上获得增量租约。(请参见add_lockspace操作/ api)。锁空间中2000个增量租约所需的空间(对于2000个可能的host_id)为1MB(4k扇区为8MB)。(这是单个paxos租约所需的大小)。
有关更多信息,请参见
- sanlock(8)
- wdmd(8)
- https://pagure.io/sanlock/blob/master/f/README.mk
VDSM和SANLock
自存储域版本3起,VDSM正在利用SANLock 执行以下任务:
注意:在以前的所有存储域版本中,都不会激活SANLock。
VDSM中的锁空间和资源
VDSM使用UUID作为名称为每个存储域分配一个锁空间。例如:对于块存储域'1dfcd18e-b179-4b95-aef6-f0fba1a3db45',锁空间为
1dfcd18e-b179-4b95-aef6-f0fba1a3db45:0:/dev/1dfcd18e-b179-4b95-aef6-f0fba1a3db45/ids:0
对于存储域中存在的每个卷,将创建一个资源并分配其租约:
- 块域:在具有预定偏移量的租约LV中(取决于元数据偏移量)
- 文件域:在扩展名为“ .lease”的文件中,具有与卷文件相同的名称和位置
SPM资源位于偏移量为0的“租约”文件/ LV上(临时,它将移至其他偏移量以允许无缝域升级)。
包含SANLock资源的Libvirt XML
VDSM为libvirt准备在存储域版本3上运行VM的XML 包括获取卷资源所需的所有信息:
``vm1 ...`` ...`` ...`` `` ```c29ca345-4aab-42f1-97c5-bdf967073d22` ``7b1cff35-9482-4946-9654-adf1db5ecd10` `` `` ...``
有关libvirt如何处理租赁的更多信息,请参考其特定文档[1] [2]。
VDSM SANLock图
在connectStoragePool上,VDSM正在获取池中所有存储域上的锁空间。libvirt稍后将使用获取的锁空间来获取虚拟机的卷。
sanlock日志文件调试
/var/log/messages
包括来自sanlock或wdmd或/ dev / watchdog驱动程序的重要警告或错误。在此找到的任何sanlock或wdmd消息都应进行调查。
/var/log/sanlock.log
包括/ var / log / messages中的所有sanlock警告和错误,以及sanlock管理的每个锁空间和资源的记录。
/var/log/sanlock.log中的锁空间条目:
TIME sNUM lockspace LNAME:HOSTID:/dev/VG/LV:OFFSET
- sNUM – NUM是此锁空间uuid的短整数缩写。其他日志消息中使用sNUM来引用此锁定空间。每次启动sanlock守护程序时,NUM都会重置为1。
- LNAME –锁空间名称,vdsm将此名称设置为该锁空间的uuid
- / dev / VG / LV:OFFSET –此锁空间所在的磁盘区域
/var/log/sanlock.log中的资源条目:
TIME sNUM:rNUM resource LNAME:RNAME:/dev/VG/LV:OFFSET for X,Y,PID
- sNUM –短锁空间标识符(请参见上文)
- rNUM – NUM是此资源uuid的短整数缩写。在其他日志消息中使用rNUM引用此锁空间。每次启动sanlock守护程序时,NUM都会重置为1。
- LNAME-锁空间名称(来自vdsm的uuid)
- RNAME –资源名称,vdsm将此资源名称设置为uuid
- / dev / VG / LV:OFFSET –此资源所在的磁盘区域
- X,Y,PID – PID是请求此租约的进程,X是pid使用的内部连接ID,Y是用于连接的fd编号
更改日志记录级别
可以使用两个sanlock守护程序命令行选项控制写入/ var / log / messages或/var/log/sanlock.log的信息量:
-L pri 在优先级和日志文件中最多写入日志(-1无)
-S pri 优先级和最高syslog写入日志记录(-1无)
pri是与在中定义的日志优先级相对应的整数/usr/include/sys/syslog.h:
#define LOG_EMERG 0 /* system is unusable */
#define LOG_ALERT 1 /* action must be taken immediately */
#define LOG_CRIT 2 /* critical conditions */
#define LOG_ERR 3 /* error conditions */
#define LOG_WARNING 4 /* warning conditions */
#define LOG_NOTICE 5 /* normal but significant condition */
#define LOG_INFO 6 /* informational */
#define LOG_DEBUG 7 /* debug-level messages */
默认值为
- -L 4 因此,从警告到EMERG的日志消息将写入/var/log/sanlock.log
- -S 3 因此,从ERR到EMERG的日志消息将写入/ var / log / messages
因此,例如,要将所有调试消息都写入/var/log/sanlock.log,则应使用-L 7
sanlock对存储问题的响应
sanlock恢复的原因是存储连接丢失或来自存储的I / O响应时间变慢。“存储”是指写入Sanlock租约的设备或文件。
sanlock守护程序会以固定的间隔连续写入存储以更新其租约。如果Sanlock I / O到存储的时间未在固定时间内完成,则Sanlock守护程序将进入恢复状态。恢复从sanlock守护程序开始,尝试使用受影响存储上的租约杀死(pid)任何pid。如果10个SIGTERM超过10秒后没有任何pid退出,则sanlock将尝试kill(SIGKILL)。如果pid仍在固定时间内没有退出,则看门狗将触发,从而重置主机。如果所有pid都在必要的时间内退出,则看门狗将被更新并且不会触发。
在达到恢复超时之前,sanlock将记录与续订失败和租约过旧有关的错误。如果发现这些情况,明智的做法是减少存储或主机上的I / O负载,以避免超过阈值以进行实际恢复。
14:27:54 / 13256 (sanlock successfully renews lease)
14:27:58 / 13260 (storage connection blocked to begin test)
14:28:14 / 13276 (sanlock starts next scheduled lease renewal 20 sec after last)
- 以下消息(不是日志消息)的背景
14:28:15 sanlock [123]:13277 LNAME aio收集0x7f7f7c0008c0:0x7f7f7c0008d0:0x7f7f9dd72000结果-5:0匹配res 14:28:15 sanlock [123]:13277 s1 delta_renew读取rv -5偏移量0 / dev / VG / LV 14:28:15 sanlock [123]:13277 s1更新错误-5 delta_length 0 last_success 13256
- sanlock报告第一个I / O错误
- 如果I / O超时而不是快速失败,则第一个错误可能会迟到14:28:24 / 13286。
- 这些消息针对每个I / O错误重复一次,频率介于每秒两次和每10秒一次。
- 根据I / O问题的类型,可能会出现部分或全部这些行。
14:28:54 sanlock [123]:13316 s1 check_our_lease警告60 last_success 13256 14:28:55 sanlock [123]:13317 s1 check_our_lease警告61 last_success 13256…14:29:13 sanlock [123]:13335 s1 check_our_lease警告79 last_success 13256
- 在上次成功续订后的io_renewal_warn秒(60)内,每秒出现一次租赁期限警告。
- 尚无不良影响;这些警告在实际租赁到期之前。
14:29:14 sanlock [123]:13336 s1 check_our_lease失败80
- 上次成功续订后的id_renewal_fail秒(80),租约到期。
- 此时恢复开始;sanlock开始杀死pid。
14:29:14 wdmd [111]:测试pid 12437更新失败13256到期13336
- 来自wdmd的第一个警告出现,表明看门狗将触发并重置主机,除非所有pid在10秒内退出(或续约)。
wdmd对sanlock问题的响应
如果sanlock守护程序在使用时被杀死或以其他方式退出,则控制/ dev / watchdog的wdmd守护程序将记录错误,警告看门狗未处于活动状态,并将很快过期。此时,做任何事情都为时已晚,看门狗将重置主机。
sanlock超时
sanlock守护程序具有大量不同的但错综复杂的超时。所有这些都是从io_timeout派生的,它是10秒:一个i / o在sanlock认为失败之前可以花费的时间。
可以调整I / O超时,但是所有主机使用相同的I / O超时值至关重要。sanlock不会检测主机是否使用不同的I / O超时,并且这种错误配置可能导致数据损坏。当sanlock守护程序启动时,它将添加一个条目到/ var / log / messages中,其中包括基本超时值:
sanlock daemon started 2.0 aio 1 10 renew 20 80 ...
- aio 1 –启用异步I / O
- 10 – io_timeout
- renew 20 80 – id_renewal_seconds id_renewal_fail_seconds(续约和租约到期前的续约时间)
sanlock实时过程调试
调试sanlock守护进程。
# sanlock client status [-D]
这将显示当前正在管理的所有锁空间,租约和pid。-D包括其他内部调试信息。
# sanlock client host_status -s LOCKSPACE [-D]
这将显示所有正在监视的host_id租约的状态。LOCKSPACE可以只是锁空间名称/ uuid。-D包括其他内部调试信息。
# sanlock client log_dump
这将转储sanlock守护程序的内部近期调试消息的循环缓冲区。
参考文献
[1] http://libvirt.org/formatdomain.html#elementsLease
[2] http://libvirt.org/locking.html