作者将本文同时发布到：EMC中文支持论坛 https://community.emc.com/community/support/chinese/storagehw/blog/2013/10/21/celerravnx-file-data-mover-%E4%B8%BB%E5%A4%87%E5%88%87%E6%8D%A2%E7%9A%84%E8%BF%87%E7%A8%8B%E4%BB%A5%E5%8F%8A%E5%88%87%E6%8D%A2%E7%9A%84%E6%97%B6%E9%97%B4%E5%BC%80%E9%94%80

在大多数的Celerra，VNX的Data Mover配置中，出于高可用性的需求，最常见的配置都会配置至少一个备用Data Mover，当主DM发生了问题或者因为管理维护需要而重启的时候，主备切换就可能发生以保证用户的数据访问。然而Data Mover的主备切换到底是做了什么？对用户又有什么样的影响？需要花多长时间才能完成呢？下文就这3个问题做了一定程度的解析。

DM发生failover的过程：

  1. Data mover上发生failure

  2. CS检测到这个failure

  3. CS重新配置系统以使备用的DM接管发生问题的DM的业务和身份（包括名字，ip，MAC地址等各种配置）；并且CS还将发生问题的DM重启，然后载入一个基本的配置（没有load任何配置或挂载任何文件系统），这么做是为了避免两个DM都load配置尝试去接管生产从而发生“精神分裂”的情况。

  4. 寂寞地等待了许久的备份DM，终于等到主DM发生问题，可以大展拳脚，于是它顶掉了原配，开始首先初始化一些自身的配置（例如转载各种driver，打开自己的网卡，给它们分配好IP地址，根据parameter配置文件设置各种参数等），紧接着初始化一些外部部署的配置（包括挂载文件系统，设置CIFS server等）。

  5. 此时DM的failover算是完成了。理论上用户即应该可以访问数据。取决于用户的客户端（以及使用的协议），failover所花的时间可能会对用户体验造成不同的影响。例如windows用户势必需要重新login一次share（当然如果用户是使用应用程序在访问或者映射了网络盘，这个重新登录的过程会由应用程序或操作系统自动完成，而用户只感到顿卡），重新login的原因是备份的DM只会继承配置文件中的配置，而不会继承用户之前login到share时记录在DM内存里的缓存，这些缓存会随着DM重启而消失；而对于Linux的用户，默认的mount方式会不断的尝试通过NFS将文件系统mount起来，因而经历过几次timeout之后，Linux用户就又恢复使用了。

 

总的来说，failover得快，Windows用户可能遭遇顿卡而后恢复，Linux用户比较可能毫无知觉（除非一直持续读写，或failover的瞬间正在读写）。

而failover得慢，windows用户可能遭遇的就是OS或应用程序的timeout/最终网盘挂掉等待手工mount，而Linux用户可能就要被卡死，等待操作系统不断的mount这个NFS share直到用户决定终止。

 

Failover所花的时间似乎颇为神秘，使得其对用户体验的影响难以估计，有的存储管理员也不敢轻易使用，生怕failover花的时间长了，给用户带来长时间的DU而接到抱怨。

 

由于触发failover的原因不同（DM panic，手动触发，DM被物理移除等），计算failover所需时间的方法也不同。并且由于各种变量（文件系统数量，配置量）还有各种常量（NBS服务由备用DM提供的切换过程使用的时间），甚至变化的常量（随着各个OE版本变化而改变的一些值譬如初始化ip等DM独立配置的时间），我们无法给出一个具体的时间，但是可以提供的是一个大概的计算方法以估计failover的时间。

 

总的来说，failover的完成需要3部分的时间：

  1. 检测到问题所需要的时间。

    • (a) 对于手动failover，这段时间主要相当于正常关闭一台DM所需的时间。因为是用户手动触发，系统需要首先正常关机当前的主DM，然后重启它，才能开始真正的failover的过程。而正常关机所花的时间又因为各种变量而不同，取决于当前DM有多少客户端连接，当前打开的文件数量，lock的情况，文件系统数量，需要flush到客户端或后端阵列的缓存的数据量等等。那就是另外一个话题了。

    • (b) 而对于最大可能的failover，则是由于DM panic造成的自动failover，基本会在1到2秒内检测到panic，然后约10秒之内生成dump文件以便事后分析RCA。如果是panic的话，这段时间大约就是2+10=12秒左右。

    • (c) 如果DM到CS的两条内部网络128.221.252.0/24和128.221.253.0/24都断开（无法ping通），那么也会发生failover，而这个情况需要12秒的时间检测到。由于两条内部网络4秒检测一次，当3次检测都失败，则触发failover。

    • (d) 还有其他情况也会触发failover，不过相比前者都不容易遇到，就不一一赘述，可以查看high availability的白皮书。

     

  2. 一段固定的时间开销，根据OE版本的不同而不同。在比较老的5.0和6.0版本需要花费至少15秒，而在新版的7.0和7.1只需6秒

  3. 一段变量的时间，究竟需要多久取决于DM需要mount的文件系统的数据加上快照的数据以及DM mount它们的速度。文件系统和快照越多，所需时间越长；DM mount的速度越快，所需时间越短。

DM上文件系统的数量和快照的数量对于每个用户来说是固定的，而DM mount文件系统和快照的速度则随着OE版本的变化而有所改进，就笔者所知7.0.45的File OE速度约为每秒20+个文件系统。Mount 1700个文件系统大约要65秒左右。

 


 

 

因此failover所需的时间=检测故障的时间（1）+ 根据OE版本固定的时间开销（2）+ mount文件系统和快照所需的时间（3）（文件系统+快照的数据量/DM mount的速度）

 

注意：failover完成后表示DM已经available了，但是并不代表用户就一定立即可用，在不同的用户环境，有可能还会有各种各样外部的延迟导致用户并不是立刻访问到数据，例如备份的DM起来之后和DNS服务器和DC，或者CAVA还有其他种种相关服务的交互，还有客户端主机重新登录share的各种时间开销都有可能延长服务恢复的等待时间。

 

以上就是Data Mover在failover中的所作所为以及每一部分操作大约的时间消耗，也许对于估算一个确切的值没有什么用（还无法做到），但是相信对于技术支持回答客户问题，以及存储管理员预估failover对生产的影响的判断，还是能起到一定的支持作用。