一、背景

基于SMB提供文件系统的架构一般是VIP+分布式NAS+底层存储的架构；如果NAS机头故障需要进行连接的漂移，这个过程中怎么保证客户的IO是不中断的？

 

其中SMB2&3协议中有提供一些协议层的解决方案：

• Durable Handle -- 网络短暂中断后可恢复 -- Samba正式分支中已实现
• Resilient Handle -- Durable handle增强版 -- Samba正式分支中未实现
• Persistent Handle -- 机头宕机仍可恢复 --  Samba正式分支中未实现

二、Durable Handle

1、打开文件时申请

• Create Request中的一个Context
• 

2、网络超时或收到RST后Reconnect

前提：

• 持有Oplock/Lease
• 服务端Open状态存在且有效
• 重连成功IO不中断
• 
• 

3、Samba中实现

• Open状态未持久化
• 节点重启后状态不在
• 节点之间状态共享但是不备份

三、HA方案

• IP漂移：单VIP+多RS方案
• 状态保存：Samba中已经将文件有关状态保存到了以下表中，smbXsrv_open_global和locking
• 重建连接：Windows Client检测到网络超时或者收到RST包时会发送Durable Reconnect请求
• 状态重建：Server端基于之前保存的状态&校验处理Reconnect请求

四、状态保存

• Samba + CTDB

Samba处理SMB协议的过程中会将状态保证到TDB中，而CTDB – 分布式的TDB；CTDB的数据库分为三类：

1. Volatile Database，保存临时状态，数据在独一份但集群间共享，基于内存/tmpfs，重启删除
2. Replicated Database，与Volatile相比只多了数据在集群节点中复制
3. Persistent Database，保存持久状态，数据集群中复制，基于持久化存储

smbXsrv_open_global & locking 目前是Volatile Database，借助CTDB已有的数据持久化机制，更改表的创建标志为持久化数据库。

 

五、状态重建

1、文件元数据校验

Reconnect时会进行文件元数据校验，完全一致才能通过。因此Samba与底层存储交互只能走纯用户态的API方式保证dev_t、ino、blocksize等数据一致，若经内核则由内核管理，不同机头可能出现差异；例如ex_size（文件大小）保持一致，若经内核，绕不过pagecache，写入场景下可能出现丢数据等情况导致异常。纯用户态API主要有：samba + libcephfs & samba + glusterfsapi & samba + dfs

2、状态标志位校验

Smbd进程退出时会设置文件的状态未可重连，若进程core或者机器宕机则无人进行这一部分工作，暂时绕过状态是否可重建的标志位校验allow_reconnect、isdisconnected等

六、测试

• 官网LB 提供VIP
• 双机头，samba + ctdb
• 底层存储为glusterfs
• 客户端为windows server 2012/2016
• 客户端正在进行读写
• 异常操作

a) pkill smbd —— IO切换到另一个机头并且读写不中断

b) pkill smbd & pkill ctdb —— IO切换到另一个机头并且读写不中断

c) echo b > /proc/sysrq-triger —— IO切换到另一个机头并且读写不中断

七、待改进

• Durable Handle Reconnect时需要当前客户端保有文件的Oplock/Lease
• Oplock/Lease是smb协议中的delegation，若文件被别的客户端打开时，oplock/lease会失效；即若单个文件当前正在被多次打开，切换时会失败
• Durable Handle Reconnect时不会进行Lock/Unlock的Replay操作；若锁透传到底层的文件存储，目前samba中没有进行锁的主动重建；即若持有锁并且锁透传，切换时会失败
• smbXsrv_open_global & locking 持久化带来的性能损失衡量