对于上述第一点，让客户端对不同数据的访问自动找到相应的NameNode，是通过前述的ViewFS来实现 的。而对上述的第二点，对数据的实际迁移过程，则是通过云梯开发团队全新开发的一个新的Master组件——CrossNode来实现的。图4是 CrossNode的架构图。
图4 云梯CrossNode架构图
CrossNode 是一个全新独立的Master节点，它所管理的是：读取一个配置文件，这个配置文件中记录了哪些文件和目录下的数据需要跨机房放置。例如，一个文件原本有 3个副本，都在A机房，把这个文件的路径写入到CrossNode的配置文件中，让CrossNode知道这个文件需要跨机房放置，并且在A机房是3个副 本，B机房需要2个副本，主角CrossNode只负责从A机房拷贝2个副本到B机房。同时由于在跨机房那个目录中会有新的文件被创建和写入，所以这些目 录下的文件在写入完成后，也需要后期对其进行跨机房副本放置的处理，这些也都是CrossNode来完成的。
因此，将NameNode2需 要管理的那部分数据从A机房迁移到B机房的方式为：将这些文件和目录配置到CrossNode的配置文件中，这样CrossNode就会发现有那么多的数 据需要在A机房和B机房同时放置，如3:3，于是会对这些数据的block进行跨机房拷贝，直到所有的block全部在B机房拥有3个副本，然后将 CrossNode中的配置进行修改，例如修改成0:3，这样表示A机房需要0个副本，B机房需要3个。于是CrossNode重新工作，将A机房原本的 3个副本进行删除，保留B机房的3个副本，支持完成NameNode2管理的所有数据从A机房到B机房的迁移。大家可以发现，这个CrossNode的方 案，正好解决了难点2，因为有了CrossNode以后，数据的迁移变成了一个计算的前序操作，每天云梯系统会根据前一天的计算分布和其他业务情况来决定 哪些文件需要跨机房分布，哪些需要进行迁移，哪些需要去除跨机房分布。这样在计算真正运行时，绝大部分计算job需要的数据都会存在于计算调度所在的本机 房内，并不需要跨机房读取和跨机房写入，这样机房间的带宽并不会成为影响计算作业效率的瓶颈。即使只有少量需要跨机房读写的访问存在的情况下，机房间的带 宽也完全能够处理得过来。
总结
至此，经过上述一系列步骤， 便实现了云梯hadoop集群的跨机房服务。目前，云梯集群规模已接近万台，跨越两个IDC机房，数据的分布和计算的调度每天都在根据实际情况进行实时调 整。跨机房云梯的更重要意义在于：在未来的时间里，阿里集团运行在Hadoop平台上的大数据业务不需要再为数据规模和性能而担惊受怕，在云梯现有的架构 下，已经基本看不到集群规模的上限，性能也可以根据实际情况和访问情况来进行动态的调整。
在过去五年中，阿里云梯一直都采取需求驱动的发展模式。直到2013年4月，这种模式再也无法继续下去：云梯集群所在的数据中心（IDC机房）的机位已满，无法继续扩充集群，不能满足阿里集团数据量增长的需求。此时，构建一个跨机房的Hadoop集群便刻不容缓。
作者罗李，花名鬼厉，阿里分布式团队创建之初的第一批员工，从事分布式计算、分布式存储和Hadoop系统的研发，目前负责分布式存储团队的所有技术和管理。
