淘宝TFS的nameserver的ha设计..docx

Nameserver HA 容灾方案结构Nameserver 的容灾采用ha结构，即两台机器互为热备，同时运行时，一台为主，一台为备，主绑定到对外vip，提供服务；当主机器宕机后，迅速将vip绑定当备机，备机切换为主，提供服务。结构中有两个NameServer, 在同一时刻，只有一个为主，一个为备。主NameServer是对外提供服务的机器，并接管了对外服务的ip地址；备NameServer维护元数据状态，一旦主NameServer停止服务，会马上将自身切换为主，绑定对外ip地址，继续提供服务。职责NameServer(master) : 提供对外服务管理所有DataServers, blocks的复制，迁移，紧缩以及nameserver的其他功能。增量同步元数据变更信息给NameServer备机。NameServer(slave):维护DataServers心跳信息接受主NameServer同步的元数据DataServer:接受外部请求同时给主备Nameserver汇报心跳HeartAgent监控NameServer的服务情况，发现主Ns挂掉以后，将备切换为主。问题为什么采用一主一备的结构客户端只配置了一个vip地址，ha通过绑定这个地址到主ns提供服务。同一时间，只能有一个ns提供服务。Ns需要保证一个block同时只能有一个client在更新，需要生成唯一的lease。扩展目前这种主备结构并不是最优方案，理想的nameserver容灾应该采用nameserver集群来解决，可以考虑实现一个chubby 集群，或是类似与cassandra的去中心化结构。流程启动过程作为主的启动流程：Ns起来以后，首先检查自己是否能成为一个Master, 按上一节的说法，主要是检查vip是否绑定在本机(.)如果发现可以做Master, 则要检查另外一台机器是否认为自己是Master,如果对方认为自己是，这个肯定是出问题了，必须马上告警并退出。如果对方是Slave, 那么将自己标记为Master，并开始接受心跳和汇报blocks的信息。Ok以后开始接受外部请求，并接受备NS过来的同步元数据请求作为备的启动流程：如果发现自己不是Master，则要检查另外一台机器是否是Master,如果对方认为自己不是，这个肯定是出问题了，必须马上告警。如果对方不是，那么将自己标记为备机，向Master发送登记消息，告诉Master自己准备启动了。这个时候需要Master记录下当前的时间，作为同步开始的时间。同时从Master拉回来当前的活动机器列表开始接受ds heartbeat和blocks汇报信息当一段时间以后，可以和从Master拉回来的机器列表做比较，如果发现心跳汇报的差不多了，告知Master启动完毕，准备好接收同步metaData了。Master将slave启动期间新增的增量元数据信息同步给slaveSlave 进入等待循环，开始接收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一旦挂掉，会有一部分元数据没有同步，造成的后果切换过程中有描述。Blockds关系元数据同步在主ns进行