淘宝TFS的nameserver的hadoop设计

Nameserver HA 容灾方案

结构

Nameserver 的容灾采用ha结构，即两台机器互为热备，同时运行时，一台为主，一台为备，主绑定到对外vip，提供服务；当主机器宕机后，迅速将vip绑定当备机，备机切换为主，提供服务。

结构中有两个NameServer, 在同一时刻，只有一个为主，一个为备。主NameServer是对外提供服务的机器，并接管了对外服务的ip地址；备NameServer维护元数据状态，一旦主NameServer停止服务，会马上将自身切换为主，绑定对外ip地址，继续提供服务。

职责

NameServer(master) : 1. 提供对外服务

2. 管理所有DataServers, blocks的复制，迁移，紧缩以及nameserver的其他功能。 3. 增量同步元数据变更信息给NameServer备机。

NameServer(slave):

1. 维护DataServers心跳信息

2. 接受主NameServer同步的元数据

DataServer:

1. 接受外部请求

2. 同时给主备Nameserver汇报心跳

HeartAgent

监控NameServer的服务情况，发现主Ns挂掉以后，将备切换为主。

问题

为什么采用一主一备的结构

客户端只配置了一个vip地址，ha通过绑定这个地址到主ns提供服务。同一时间，只能有一个ns提供服务。

Ns需要保证一个block同时只能有一个client在更新，需要生成唯一的lease。

扩展

目前这种主备结构并不是最优方案，理想的nameserver容灾应该采用nameserver集群来解决，可以考虑实现一个chubby 集群，或是类似与cassandra的去中心化结构。

流程

启动过程

StartRead fsimageCan be Master?NoMaster exist?YesNotify MasterYesMaster exist?NoYesFatal ErrorAccept ds heartbeat NoMark self as MasterNotify MasterReady to SyncAccept ds heartbeat Handle Sync MetaData LoopHandle request Loop

作为主的启动流程：

1. Ns起来以后，首先检查自己是否能成为一个Master, 按上一节的说法，主要是检查vip

是否绑定在本机(.)

2. 如果发现可以做Master, 则要检查另外一台机器是否认为自己是Master, 3. 如果对方认为自己是，这个肯定是出问题了，必须马上告警并退出。

4. 如果对方是Slave, 那么将自己标记为Master， 并开始接受心跳和汇报blocks的信息。 5. Ok以后开始接受外部请求，并接受备NS过来的同步元数据请求

作为备的启动流程：

1. 如果发现自己不是Master，则要检查另外一台机器是否是Master, 2. 如果对方认为自己不是，这个肯定是出问题了，必须马上告警。

3. 如果对方不是，那么将自己标记为备机，向Master发送登记消息，告诉Master自己准

4. 5. 6. 7. 8.

备启动了。这个时候需要Master记录下当前的时间，作为同步开始的时间。 同时从Master拉回来当前的活动机器列表 开始接受ds heartbeat和blocks汇报信息

当一段时间以后，可以和从Master拉回来的机器列表做比较，如果发现心跳汇报的差不多了，告知Master启动完毕，准备好接收同步metaData了。 Master将slave启动期间新增的增量元数据信息同步给slave

Slave 进入等待循环，开始接收master过来的元数据同步信息和心跳。但是不接收其他任何消息。

切换过程

Ha agent发现主Ns不工作了，将vip漂移到备ns, 并通知备ns准备切换

备ns将自己标记为主，并接收外部请求

等待备机的同步请求。

切换的过程中，会发生一点数据损失，因为主忘备同步数据是有时差的，当主挂掉以后，还没来得及同步的那部分元数据，备机里面没有，那么这部分元数据就找不到，这部分元数据分为两种：

更改block 信息： 这种问题不大，写ds的时候会发现错误，导致一次或几次写错误，然后ds会更新ns的版本号。

新加的block: 这种在备ns里面找不到，而且是永远找不到，除非相关的ds重启重新汇报。 这会产生问题：

一是读不到这些block里面的文件，二是这些block可能被覆盖；

避免被覆盖的方法是，在备切换为主的过程中，新加blocks从当前最大的blocks序号中跳过一些，以免冲掉这些可能已经存在的blocks.等待原来的主起来以后，把那些没有同步过来的重新同步一遍。

问题

一台NameServer启动以后怎么决定自己是主？

对于目前的结构来讲，需要发现对外的ip地址是绑定在本机的，并且没有另外的主。

对于ha结构来讲，这个地址漂移的过程有多快？

从发现主不可用，把ip地址漂移到辅机，并且等待备NS发现以后，切换自身为主。 这个切换过程就是整个TFS失去响应的时间，应该控制在10s以内。

数据同步

Block元数据同步

Block元数据本身有几种变更信息，新加block, 更新block, 删除block； 这三种信息都需要从主ns同步到备ns， 同步的方式采用定时和定量同步，也就是一段时间内或者是更新记录达到一定条数以后同步一次。

异常1：

这种同步方式的问题是主ns一旦挂掉，会有一部分元数据没有同步，造成的后果切换过程中有描述。

Block&ds关系元数据同步

在主ns进行复制，迁移，整理(只有主ns会做这个工作)， 都会导致关系数据发生变化，主ns会将这部分数据实时同步到备ns，

复制，迁移，整理的过程是这样的：

1. 发送命令给ds

2. Ds进行相应的操作（复制，移动，或是整理） 3. Ds发送完成消息给主Ns

4. 主Ns更新关系元数据，并回复确认消息给Ds

在第4步主Ns更新关系元数据以后，需要实时发送同步消息给备Ns。

异常1：

备Ns没有起来，这个时候无需同步给备NS，因为备Ns起来以后有一个重新接收汇报的过程

异常2：

备Ns在启动过程当中，也就是备Ns在接收汇报消息的过程当中，这个时候不能接收同步消息。只有备Ns在接收汇报消息完毕以后，准备好接收同步信息，才能接收这个同步信息。 异常3：

在同步的过程中，主Ns挂了。在一个复制或是移动计划过程中，最多可能有Ds Count * taskNumPerDs（这个参数可配置，一般为3） 个操作进行，这个过程需要一段时间，如果这个过程中主Ns挂掉，那么第3步操作中，Ds就得不到响应，这个时候需要消息发给备Ns，重试一段时间（因为备Ns在切换为主了才能接收这个消息），如果重试一直不成功，需要将复制的数据删除掉，等待重新复制或是移动。

备Ns没有起来，这个时候无需同步给备NS，因为备Ns起来以后有一个重新接收汇报的过程

异常2：

备Ns在启动过程当中，也就是备Ns在接收汇报消息的过程当中，这个时候不能接收同步消息。只有备Ns在接收汇报消息完毕以后，准备好接收同步信息，才能接收这个同步信息。 异常3：

在同步的过程中，主Ns挂了。在一个复制或是移动计划过程中，最多可能有Ds Count * taskNumPerDs（这个参数可配置，一般为3） 个操作进行，这个过程需要一段时间，如果这个过程中主Ns挂掉，那么第3步操作中，Ds就得不到响应，这个时候需要消息发给备Ns，重试一段时间（因为备Ns在切换为主了才能接收这个消息），如果重试一直不成功，需要将复制的数据删除掉，等待重新复制或是移动。

本文来源：https://www.bwwdw.com/article/by53.html