2013年4月，阿里云梯集群所在的数据中心（IDC机房）的机位已满，无法继续扩充集群。根据当时阿里集团数据量的增长趋势，在可以预见的很短时 间内，集群规模将因为机房机位不足而无法继续扩充。由于当时云梯的hadoop版本还不支持单集群跨机房分布的功能，所以阿里集团的大数据业务 将因为集群规模的限制而停止发展。云梯的跨机房项目就在这种背景下开始的。目标非常明确：构建一个支持跨机房的Hadoop集群。
技术挑战
要构建一个跨机房的Hadoop集群，有非常多的技术难点。
难点1：NameNode的扩展性
众所周知，Hadoop HDFS中的NameNode单点是阻碍Hadoop集群能够无限扩充的一个最大问题点。云梯在跨机房之前一直是单NameNode的结构，不管如何优 化，其服务能力有其上限。虽然经过云梯开发团队的多轮优化，已能超过5000台规模（日平均RPC访问量达到25亿次），但考虑将规模扩大一倍的话，显然 无法实现。所以云梯的Hadoop版本要能支持多NameNode就非常必要。
难点2：机房间网络限制
有些问题并不是将其中一个机房的所有Slave直接汇报给另外一个机房的Master就可以解决的，因为机房间的带宽是一个巨大的障碍。
难点3：数据应该如何跨机房分布
切分成多NameNode以后，势必需要对数据进行划机房甚至是跨机房的分布，分布的策略需要从业务层面进行整体的规划。这个问题的解决方案并不在本文讨论范围之内，所以只简单提出一下。实际上，云梯团队是根据上层应用对数据的访问分布和需求情况聚类生成的数据分布。
难点4：计算应该如何跨机房调度
数据跨机房分布后，计算调度该如何进行最优的调度策略，以避免数据在机房间的来回拷贝以及作业跨机房读取数据呢？
难点5：几十PB数据的迁移，以及带数据升级
带着上百PB数据进行集群整体升级，数据不能有任何丢失，是一个非常大的挑战。
难点6：怎样做到对用户透明？
实现了多Master以后，如何对用户透明，不需要云梯上几十万个job做任何修改就能无缝兼容，是对开发团队的另一个巨大挑战。
难点7：方案是否能扩展到多机房（>=3）？
为了以后进一步跨越更多的机房，云梯版本需要考虑的不仅是双机房分布，而是多机房分布。
解决方案的详细步骤
明确了需求和难点，接下来就需要有明确的实施步骤，经过开发团队、测试团队、运维团队和业务团队的多方沟通和头脑风暴，云梯跨机房项目确定了如下的 技术实施步骤（这里的设计方案，是按照整个项目实际的实施步骤顺序来介绍的，以方便大家理解每一步的初衷和解决的问题，会对每一步解决了什么问题进行相应 介绍）。
第一步，将云梯集群升级为支持Federation版本（基于云梯自身的版本进行开发），将现有NameNode作为一个NameSpace，为“NameNode1”，该“NameNode1”的NameSpace下拥有云梯的全量数据，规模为5000台。
第二步，在同机房中搭建另一个NameNode，为“NameNode2”。该NameNode下的NameSpace为空，刚开始不管理任何数据。同时在所有的DataNode上创建针对NameNode2的BlockPool，用来向NameNode2汇报。
第三步，将NameNode1中的部分数据（如50%）迁移到NameNode2（这里的迁移包括NameSpace中的元数据迁移和底下DataNode磁盘中的block）。这一步完成之后，云梯结构如图1所示。这一步是一个非常大的难点。
图1 云梯多NameNode架构图
