GBase8a 调整gnode实例IP地址与节点逻辑名对应关系方法

1.背景说明：

本文档主要针对GBase 8a MPP Cluster在主从两套独立集群上实现基于Rsynctool工具的主从数据同步，同时在从集群上进行数据备份，备份文件可实现主或从集群的数据恢复的整体容灾方案实施部署中遇到的一个具体问题形成解决办法。
整体容灾方面分为两个层面容灾方案，并针对两种不同场景：
1)主从同步场景，主集群负责数据写入，写入数据可通过T+1时间间隔通过Rsynctool同步工具，将写入增量数据同步至从集群，从而形成主从双活的方案，主集群负责数据写入，从集群提供对外查询，适用于当出现主集群故障时，应用可马上切换到从集群恢复服务连续性场景；
2)备份恢复场景，因使用gcrcman.py备份工具进行数据备份需要设置集群readonly状态，需要有业务数据静止窗口，因此对于无足够数据静止窗口期的业务，可以考虑在从集群上进行数据备份，备份的数据通过网络传到NAS服务器上，可用于主集群或从集群进行数据恢复使用，适用于对出现误操作或因不可预期灾难造成数据全毁时进行全量数据恢复场景。
部署方案如下图：

由于主机集群和从集群在上述方案中需要拓扑结构相同，因此主集群的节点和从集群的节点希望形成一一映射的关系，在实际网络规划中，希望主备集群的节点相对有序并形成对应关系，比较符合网络规划和DBA管理员的习惯，并在后续管理中降低节点映射处理的管理工作量和维护映射的心智。例如：
主集群中的节点规划如下：
3台管理节点：gcluster、gcware混合部署
8台计算节点：每台部署2个gnode实例
主集群中每个节点分配2个IP地址，管理节点只使用第一个IP地址，数据节点的2个实例各使用1个IP地址

其中节点逻辑名对应安装好集群后执行gcadmin命令时NodeName列显示信息，类似如下：

且节点逻辑名将作为gcrcman.py工具进行数据备份时，本地挂载的备份目录中标识逻辑节点的目录名称，例如如下在备份目录中生成的子目录，代表备份数据是从集群的coordinator1_node1(该服务器的角色既是管理集群的第一个管理节点，也是计算集群的第一个gnode实例所在节点)

从集群中的节点规划对应主集群如下：
3台管理节点：gcluster、gcware混合部署
8台计算节点：每台部署2个gnode实例
从集群中每个节点分配2个IP地址，管理节点只使用第一个IP地址，数据节点的2个实例各使用1个IP地址
从集群IP地址规划如下：

两套集群间规划11.248和11.247网段，后两段IP地址相同的节点间形成映射关系，既满足Rsynctool工具同步增量数据的需求，同时也满足备份数据时IP地址后两段相同的节点间为相互映射的节点，用一套备份数据可同时恢复主备集群。同时，因为子网内IP地址后2段相同，只是前两段地址相区别，这样在进行备份恢复脚本编写时将极大的降低节点映射带来的管理心智负担。
但因为GBase 8a在安装脚本gcinstall.py中，采用了多线程的方式进行软件安装和节点加入集群，造成实际安装脚本配置文件demo.options中：
installPrefix= /mppdata
coordinateHost = 11.248.57.41，11.248.57.42，11.248.57.43
coordinateHostNodeID = 41,42,43
dataHost = 11.248.57.101,11.248.57.102,11.248.57.103,11.248.57.104,11.248.57.105,11.248.57.106,11.248.57.107,11.248.57.108,11.248.57.201,11.248.57.202,11.248.57.203,11.248.57.204,11.248.57.205,11.248.57.206,11.248.57.207,11.248.57.208
...
虽然在配置文件中按照节点IP顺序进行了组织，但集群安装完成并将上述节点自动加入集群时，其IP地址和期望对应的逻辑名称无法对上，可能出现实际安装完成时节点顺序（在gcadmin中显示的节点逻辑名称）与预期不符，从而会影响主从集群间的根据IP地址后两段相同进行的简单映射。
出现上述问题时，需要提供一种方法，避免安装后节点IP地址和节点逻辑名间的映射乱序问题。

2.问题解决办法：

出现上述问题时，可通过如下方案调整节点顺序，解决乱序问题，具体步骤如下：
1)正常安装集群：demo.options中填入预期的IP地址顺序，例如：
installPrefix= /mppdata
coordinateHost = 11.248.57.41，11.248.57.42，11.248.57.43
coordinateHostNodeID = 41,42,43
dataHost = 11.248.57.101,11.248.57.102,11.248.57.103,11.248.57.104,11.248.57.105,11.248.57.106,11.248.57.107,11.248.57.108,11.248.57.201,11.248.57.202,11.248.57.203,11.248.57.204,11.248.57.205,11.248.57.206,11.248.57.207,11.248.57.208
...
执行gcinstall.py安装集群

2)安装完成后检查乱序是否存在：执行gcadmin命令，检查节点逻辑名与IP地址间的映射关系，如果顺序出现乱序，此时集群软件安装步骤中gcinstall.py脚本在gcinstall目录下自动生成的gcChangeInfo.xml文件中的节点顺序信息应与当前执行gcadmin命令时节点逻辑名和IP地址的映射关系相同，也是乱序的。

3)执行gcadmin删除乱序加入集群的节点：
gcadmin rmnodes gcChangeInfo.xml
执行成功后，再次执行gcadmin时只能看到gcware节点和gcluster节点集群，gnode集群节点全部被删除了。

4)重新编辑gcChangeInfo.xml，使用正确的顺序：
对于上面例子中的主集群考虑节点IP顺序和节点逻辑名间的映射，及高可用分片摆放位置，可使用如下gcChangeInfo.xml文件中的内容：
<?xml version="1.0" encoding="utf-8"?>
<servers>
   <rack>
       <node ip="11.124.57.101"/>
       <node ip="11.124.57.102"/>
<node ip="11.124.57.103"/>
<node ip="11.124.57.104"/>
<node ip="11.124.57.105"/>
<node ip="11.124.57.106"/>
<node ip="11.124.57.107"/>
<node ip="11.124.57.108"/>
   </rack>
   <rack>
       <node ip="11.124.57.201"/>
       <node ip="11.124.57.202"/>
<node ip="11.124.57.203"/>
<node ip="11.124.57.204"/>
<node ip="11.124.57.205"/>
<node ip="11.124.57.206"/>
<node ip="11.124.57.207"/>
<node ip="11.124.57.208"/>
   </rack>
</servers>

5)执行gcadmin addnodes gcChangeInfo.xml，将节点加入集群中，将严格按照gcChangeInfo.xml中的nodeip顺序对应集群中节点的逻辑名。

后续操作与正常安装集群操作相同。
 

注意：如果是扩容时需调整加入集群的节点顺序，也需按照上述步骤进行调整，注意的是执行gcadmin rmnodes步骤时，只能删除新安装集群软件的扩容节点IP地址，如果是扩容前的已有数据的节点，执行gcadmin rmnodes删除老的节点时有报错提示，无法删除带有数据的node节点。