通用方案：OSS物理机关机维修和系统重新克隆的方法

1. 概述

本文主要介绍在专有云V3环境中，OSS物理机关机维修和系统重新克隆的解决方案。

方案总览

类别	内容
国产化	否
风险等级（方案执行的影响）	中
操作方式	灰屏
操作复杂度	高
预估执行时长	N/A
客户业务的影响	有
可监控性	不支持
有效性（重启、重拉、补丁、升级、扩容等配置是否丢失）	固化
数据修订（变更是否涉及增删改操作）	有
执行灰度策略	请向产品侧咨询，明确灰度策略
首次发布时间	N/A
预计完成时间	N/A

1.1. 适用范围

• 专有云版本：V3.*
• 产品：OSS

说明：适用于专有云V3.1~V3.8.1版本，并且KV版本为kv_sprint8.4。

1.2. 用户告知

• 如果目标机器是KV_Master，需要先替换KV_Master机器。
• OSS物理机发生故障，每次只能下线一台，请合理安排窗口期。
• 在机器下线过程中，需要对盘古ChunkServer上的数据做备份，请预留出足够的时间做变更。
• 如果KV_Master不为3台或者5台，或者checkready检查异常，需要联系阿里云技术支持获取帮助。
• 如果出现不符合预期的情况，请联系阿里云技术支持获取帮助。

2. 问题描述

在专有云V3环境中，遇到OSS物理机发生故障时，需要将故障机器下线进行修复，重新克隆后，再进行上线。

3. 解决方案

3.1. 环境检查

3.1.1. 查看故障机器是否为KV_Master机器

1. 登录天基控制台。

2. 在左侧集群页签下搜索oss，选择AdvanceOssCluster-A-2018XXXX-daXX集群，单击集群后的集群运维中心。

   

3. 选择oss-chiji服务，单击服务器后面的Terminal，登录oss-chiji服务的主机。
   

4. 切换到admin用户，执行以下命令，查看KV版本。
   

   /apsara/deploy/kuadmin --buildinfo

   系统显示类似如下。
   
5. 执行以下命令，请确保这个IP是OSS集群内的。执行后有此IP字段输出，即确认属于OSS集群内的机器IP。

   puadmin lscs | grep tcp | grep [$IP]

   说明：[$IP]需要替换成待维修机器的IP。

6. 执行以下命令，查看目标机器IP是否在此命令的输出中。

   /apsara/deploy/mcu gas

   系统显示类似如下，如果目标机器的IP出现在图中ip这一行，暂停操作，请联系阿里云技术支持。

   

3.1.2. 检查集群机器和磁盘状态

执行如下命令，检查集群机器和磁盘状态。如果机器状态为disconnected，并且机器上的磁盘状态为OK或者宕机，则可以带外重启，其他情况不可直接带外重启机器。

puadmin lscs |grep [$IP] -A [$Number]

说明：

• [$IP]为集群机器IP地址。

• [$Number]为机器上磁盘个数。

系统显示类似如下。

3.1.3. 检查abnchunk是否存在

依次执行以下三条命令，确保三种类型的abnchunk都不存在，如果abnchunk存在，请联系阿里云技术支持处理。

puadmin fs -abnchunk -t none
puadmin fs -abnchunk -t onecopy
puadmin fs -abnchunk -t lessmin

系统显示类似如下。

3.1.4. 检查checkready

执行以下命令，检查checkready。如果有apperror错误请终止操作，请联系阿里云技术支持进行处理。

for i in ` /apsara/deploy/kuadmin --interactive=false --command=listapp | grep -v : ` ; do /apsara/deploy/ku --interactive=false --command=checkready --appname=$i ;done;

系统显示类似如下。

3.1.5. 检查KVServerRole角色机器数量跟盘古ChunkServer的数量一致

1. 登录oss-chiji服务的主机，使用admin用户，执行如下命令，获取所有KVServerRole数量。由于换行符问题需要将数量加一。

   tj_show -r kvengine.KVServerRole# | wc -l

2. 执行以下命令，获取所有盘古的ChunkServer数量。

   puadmin lscs | grep ttl | wc  -l

3. 对比步骤1和步骤2获取的数据是否一致，如果出现不一致的情况。先停止变更提交，排查不一致原因。

3.2. 实施步骤

3.2.1. 关闭健康检查

登录oss-chiji服务的机器，切换到admin用户，执行以下命令，关闭健康检查。

ssh [$IP] cat /cloud/app/oss-server/OssServer#/oss_server/current/oss_rpcbindport | xargs -i /apsara/deploy/rpc_caller --Server=tcp://[$IP]:{} --Method=/fuxi/SetGlobalFlag --Parameter={\"oss_DisableCheckOssStatus\":true}

说明：

• [$IP]为维修机器真实IP地址。

• 如果机器已经异常，则此步骤可能失败，跳过即可。

3.2.2. 加入KV黑名单

1. 执行以下命令，添加KV黑名单。

   /apsara/deploy/kuadmin --interactive=false --command=addblacklist --appname="" --param1=tcp://[$IP]:10280

   系统显示类似如下。

   

2. 执行以下命令，查看缩容机器是否添加到KV黑名单。

   /apsara/deploy/kuadmin --interactive=false --command=getblacklist

   系统显示类似如下。

   

3.2.3. 验证Checkready是否通过

1. 执行以下命令，获取应用程序列表。

   /apsara/deploy/kuadmin  --interactive=false --command=listapp

   系统显示类似如下。

   

2. 以上6个APP都执行以下命令，验证checkready是否通过。

   /apsara/deploy/ku --interactive=false --command=checkready --appname=[$APP_Name]

   说明：[$APP_Name]为以上得到的6个APP的名称。

   系统显示类似如下，说明正常。

   

3.2.4. 验证目标机器上已经没有分区

以上得到的6个APP都执行以下下命令，验证待重启机器上已经没有分区。

/apsara/deploy/ku --interactive=false --command=getserverparts --appname=[$APP_Name] --param1=tcp://[$IP]:10280

系统显示类似如下，说明正常。

3.2.5. 手动添加fuxi黑名单功能

1. 登录oss-chiji服务的主机，执行以下命令，获取所有KVServerRole机器列表。

   tj_show -r kvengine.KVServerRole#

2. 登录天基控制台，在左侧集群页签下搜索oss，选择AdvanceOssCluster-A-2018XXXX-daXX集群，单击集群后的集群配置文件。

   

3. 选择kvengine>resource_role.conf文件，查看KVServerRole#的参数Number数值，添加机器列表，将Number数值修改为与机器列表的总数，单击预览并提交。

   

   说明：列表中不包含待下线的机器。

4. 登录oss-chiji服务的主机，执行以下下命令，开启fuxi手动加黑名单功能。

   r sgf fuximaster "{\"fuxi_Enable_BadNodeManager\":false}"

   系统显示类似如下。

   

5. 执行以下命令，查看fuxi黑名单。

   /apsara/deploy/rpc_wrapper/rpc.sh blacklist cluster get

6. 执行以下命令，添加需要下线的机器到黑名单。

   /apsara/deploy/rpc_wrapper/rpc.sh blacklist cluster add [$Hostname]

   说明：[$Hostname]为需要下线机器的主机名。

   系统显示类似如下。

   

7. 执行以下命令，查看fuxi黑名单中是否有该机器。

   /apsara/deploy/rpc_wrapper/rpc.sh blacklist cluster get

   系统显示类似如下。

   

3.2.6. 机器关机维修步骤

• 如果只是机器宕机，没有更换设备或者更换磁盘操作，则忽略RMA操作和Clone流程，直接通过带外重启机器，重启成功直接跳至机器启动后恢复流程。

• 如果需要更换机器内存条、CPU、主板等硬件设备，则只执行RMA操作。

• 如果是更换操作系统盘，则需要先进行RMA操作，再进行克隆操作。

3.2.7. RMA操作

1. 登录OPS1服务器，如何登录服务器请参见专有云如何登录OPS服务器。

2. 执行以下命令，修改故障机器action状态为pending。

   curl "http://127.0.0.1:7070/api/v5/SetMachineAction?hostname=[$Hostname]" -d '{"action_name":"rma", "action_status":"pending"}'

   系统显示类似如下。

   {
       "err_code": 0,
       "err_msg": "",
       "data": [
           {
               "hostname": "[$Hostname]"
           }
       ]
   }

3. 执行以下命令，获取action_description@mtime的值。

   curl "http://127.0.0.1:7070/api/v5/GetMachineInfo?hostname=[$Hostname]&attr=action_name,action_status,action_description@mtime"

   系统显示类似如下。

   {
       "err_code": 0,
       "err_msg": "",
       "data": {
           "action_description": "",
           "action_description@mtime": 1516168642565661,
           "action_name": "rma",
           "action_name@mtime": 1516777552688111,
           "action_status": "pending",
           "action_status@mtime": 1516777552688111,
           "hostname": "[$Hostname]",
           "hostname@mtime": 1516120875605211
       }
   }

4. 执行以下命令，设置audit日志。

   curl "http://127.0.0.1:7070/api/v5/AddAuditLog?object=/m/[$Hostname]&category=action" -d '{"category":"action", "from":"tianji.HealingService#", "object":"/m/[$Hostname]", "content": "{\n   \"action\" : \"/action/rma\",\n  \"description\" : \"/monitor/rma=error, mtime: 1516168642565661\",\n   \"status\" : \"pending\"\n}\n" }'

   说明：mtime为上一步获取的action_description@mtime值。

   系统显示类似如下。

   

5. 执行以下命令，查看机器action状态。

   curl "http://127.0.0.1:7070/api/v5/GetMachineInfo?hostname=[$Hostname]"

   系统显示类似如下。

   

6. 执行以下命令，查看机器上SR的审批状态。若为宕机机器，机器可自行审批，若非宕机机器，需等待恢复正常后方可进行下面的操作，审批时间比较长。

   curl "http://127.0.0.1:7070/api/v5/GetMachineInfoPackage?hostname=[$Hostname]&attr=sr.id,sr.action_name,sr.action_status"

   说明：

   • pending表示正在审批的SR。

   • approved、doing和done表示已经审批完。

   • 没有action的表示还未审批。

3.2.8. 关机维修

1. 等机器的信息变为approved和doing状态后，即可将此服务器进行关机操作。

2. 维修完毕后，保证网线全部连接正常，启动服务器即可。

   说明：

   • 若不需要克隆机器，在执行机器上线操作后，进行机器启动后恢复流程操作。

   • 若需要克隆机器，则从重新克隆装机开始进行操作。

3.2.9. 机器上线

登录OPS1服务器，执行以下命令，将RMA状态设置为done。

curl "http://127.0.0.1:7070/api/v5/SetMachineAction?hostname=[$Hostname]&action_name=rma" -d '{"action_name":"rma","action_status":"done", "force":true}'

说明：随后天基开始启动应用，注意观察天基状态。

3.2.10. 重新克隆装机

1. 执行以下命令，设置故障机action状态，重新装机。

   curl "http://127.0.0.1:7070/api/v5/SetMachineAction?hostname=[$Hostname]&action_name=rma&action_status=doing" -d '{"action_name":"clone", "action_status":"approved", "action_description":"", "force":true}'

   注意：如果机器Action状态是RMA| approved下线状态，则执行以下命令。
   curl "http://127.0.0.1:7070/api/v5/SetMachineAction?hostname=[$Hostname]&action_name=rma&action_status=approved" -d '{"action_name":"clone", "action_status":"approved", "action_description":"", "force":true}'

   系统显示类似如下。

   { 
        "err_code": 0, 
        "err_msg": "", 
        "data": [
            {
                 "hostname": "[$Hostname]"
            }
       ]
   }

   说明：整个克隆过程大约40分钟左右。

2. 可通过以下两种方式，查看克隆进度。
   1. 执行如下命令，查看机器状态。也可通过登录天基控制台查看。

      curl "http://127.0.0.1:7070/api/v5/GetMachineInfo?hostname=[$Hostname]&attr=state,hostname"

   2. 系统显示类似如下，状态为GOOD，表示机器维修完成，可恢复正常使用。
      
   3. 登录天基控制台，选择报表>系统报表>机器clone报表，查看克隆进度。
      
      

3.2.11. 机器启动后恢复流程

1. 登录oss-chiji服务的主机，切换到admin用户，执行以下操作，恢复ChunkServer状态。
2. 恢复执行以下命令，查看下线机器的ChunkServer状态。如果是克隆机器则跳过此步骤。

   /apsara/deploy/puadmin lscs | grep tcp

   系统显示类似如下，状态为SHUTDOWN。
   
3. 执行以下命令，恢复ChunkServer状态。

   /apsara/deploy/puadmin cs -stat tcp://[$IP]:10260 --set=NORMAL

   系统显示类似如下。
   
4. 执行以下命令，将机器移除fuxi黑名单。

   /apsara/deploy/rpc_wrapper/rpc.sh blacklist cluster remove [$Hostname]

5. 执行如下命令，查看fuxi黑名单，确认机器是否移除黑名单。

   /apsara/deploy/rpc_wrapper/rpc.sh blacklist cluster get

   系统显示类似如下。
   
6. 移出伏羲黑名单之后，登录天基控制台，查看机器详情，需要等待机器上面的所有的服务状态都是OK，也就是全部都是绿色状态。
   
7. 待机器上的所有服务的状态如上图所示，则继续下面的配置变更操作。若出现三个或多个服务不正常，并出现以下错误，则参见本文中的补充说明修复Tengine的RPM包。
   
8. 登录天基控制台，在左侧集群页签下搜索oss，选择AdvanceOssCluster-A-2018XXXX-daXX集群，单击集群后的集群配置文件。
   
9. 选择kvengine>resource_role.conf文件，查看KVServerRole#的参数Number数值，将Number数值修改为原来的值，删除机器列表，单击预览并提交。
   
10. 若触发天基Rolling需要等到服务到达终态之后再进行操作，修改之后会有一小段时间是PROBATION状态，待天基检测状态变成GOOD后继续以下操作。
11. 执行以下命令，获取应用程序列表。

    /apsara/deploy/kuadmin  --interactive=false --command=listapp

    系统显示类似如下。
    
12. 执行以下命令，验证checkready是否通过。

    /apsara/deploy/ku --interactive=false --command=checkready --appname=[$APP_Name]

    系统显示类似如下。
    
13. 执行以下命令，查看kv_server进程。

    ssh [$IP] 'ps -ef|grep kv_server'

    系统显示类似如下。
    
14. 执行以下命令，将机器移除KV黑名单。

    /apsara/deploy/kuadmin --interactive=false --command=addblacklist --appname="" --param1=tcp://[$IP]:10280   --param2=0

    系统显示类似如下。
    
15. 执行以下命令，查看机器有没有移除黑名单。

    /apsara/deploy/kuadmin --interactive=false --command=getblacklist

    系统显示类似如下。
    
16. 6个APP都执行以下命令，验证checkready是否通过。

    /apsara/deploy/ku --interactive=false --command=checkready --appname=[$APP_Name]

    系统显示类似如下。
    
17. 6个APP都执行如下命令，确认是否有异常分区。如果有异常分区，请联系阿里云技术支持。

    /apsara/deploy/ku --interactive=false --command=getserverparts --appname=[$APP_Name] --param1=tcp://[$IP]:10280

    系统显示类似如下，表示正常。
    

3.3. 结果验证

登录天基控制台，查看OSS集群服务是否到终态。

4. 回滚方案

暂无回滚方法。

5. 补充说明

1. SSH登录到clone的机器，执行以下命令，查看是否有access_log日志文件产生。

   ll -rt /apsara/apache/logs

   系统显示类似如下。
   
2. 执行以下命令，查看安装的Tengine的版本。

   sudo rpm -qa|grep -i tengine

   系统显示类似如下。
   

3. 执行以下命令，修复Tengine的RPM包。

   sudo chmod -x /cloud/app/oss-server/TEngine#/oss_tengine/current/start && sudo rpm -e tengine-proxy-2.1.10-20170607114914.el7u2.x86_64

   系统显示类似如下。

   

4. 执行以下命令，修复Tengine的RPM包。
   sudo rm -rf /opt/taobao/tengine/ && sudo rm -rf /opt/taobao/install/tengine-2.1.10-\20170607114914.el7u2/ && sudo rpm -ivh /cloud/app/oss-server/TEngine#/oss_tengine/current/rpms/tengine-proxy-2.1.10-20170607114914.el7u2.x86_64.rpm && sudo chmod +x /cloud/app/oss-server/TEngine#/oss_tengine/current/start
   系统显示类似如下。
   

5. 执行以下命令，确认有access_log日志文件生成。

   ll -rt /apsara/apache/logs

   系统显示类似如下。
   

6. 执行以下命令，查看日志文件信息。

   tail /apsara/apacha/logs/access_log.20180829

   系统显示类似如下。

   

7. 等待Tengine服务正常启动，并输出访问日志，然后继续观察。