如何在实验室进行MRS大集群规模测试

      随着时代发展，数据变得更加开放、共享，客户的业务也面临着多元化处理，原有的集群亟待扩容，另外，推到原有小规模集群的烟囱建设，打造一体化数据湖的诉求也越来越迫切。在这一背景下，原本上千规模的集群已经远远无法满足客户的业务诉求，于是，迫切需要建设上万规模的数据湖。

      而上万规模的数据湖如何在进行实验室进行功能、性能、可靠性等方面的测试，也成为我们研发团队需要考虑的问题。

      通常情况下，我们的软件是直接部署在物理设备上进行测试的，3万节点规模大集群就需要3万台物理设备，这显然无法在实验室条件下得到满足，需要借助虚拟化的技术。

     结合我们大数据产品的特点，其节点类型分为管理节点、控制节点、数据节点；在实际的部署使用过程中，管理节点和控制节点，往往会成为大集群规模下的瓶颈问题，应作为首先测试观察项。那如何有效的利用有限的实验室资源，进行有效的测试呢？ 我们在Docker容器与虚拟机中进行对比发现，Docker容器采用共享OS的方式，占用资源比虚拟机少，而且隔离性也能满足我们的诉求，因此，我们采用如下方式进行实验环境搭建。

       我们使用Docker Swarm进行Docker容器管理。因为相比Kubernetes，Docker Swarm更轻量，方便快速安装卸载，另外，可以通过级联的方式搭建超大规模集群。

下面看看其组网：

在这种测试方案下，一台64U256G的物理机，就可以虚拟出60个1U4G的数据节点，两百台机器就可以进行上万规模节点的测试。

在实施过程中，我们也踩了不少坑，比如：

• 如何解决小资源的Docker数据节点，快速部署安装问题。

解决措施：直接跳过安装过程，在Docker镜像中内置启动脚本，拉起镜像过程中，直接启动数据节点。这样就避免了管理节点下发软件包，软件包在小资源环境中的安装部署缓慢的问题。

• 在上述场景中，如何确保大规模集群下的扩容、缩容功能正常？

解决措施：实际测试扩容、缩容时，采用物理节点进行测试，避免小资源环境中扩容、缩容缓慢的问题。

• 如何解决Docker数据节点的IP地址冲突的问题？

解决措施：利用Docker Swarm进行组网设计，给每一台物理节点划分网络范围，使得不同节点上启动的Docker数据节点绝对不会重复。

• 避免在大二层组网下的广播风暴问题。

为了方便组网和测试，我们使用了Mac-VLan的组网方式，在这种方式下，存在广播风暴的问题，我们采用ARP静态缓存规避了此问题。

• 如何解决Docker数据节点的共享目录问题。

解决措施：Docker数据节点各自规划不同目录，在镜像启动过程中，在磁盘上划分以Docker名称为变量的目录，有效解决目录冲突问题。

以上是我们在环境搭建部署过程中遇到的一些问题，下期我们再看看产品软件层面有哪些改进项吧。