通用方案：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机器

登录天基控制台。
在左侧集群页签下搜索oss，选择AdvanceOssCluster-A-2018XXXX-daXX集群，单击集群后的集群运维中心。
选择oss-chiji服务，单击服务器后面的Terminal，登录oss-chiji服务的主机。

切换到admin用户，执行以下命令，查看KV版本。
```
/apsara/deploy/kuadmin --buildinfo
```
系统显示类似如下。
执行以下命令，请确保这个IP是OSS集群内的。执行后有此IP字段输出，即确认属于OSS集群内的机器IP。
```
puadmin lscs | grep tcp | grep [$IP]
```
说明：[$IP]需要替换成待维修机器的IP。
执行以下命令，查看目标机器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的数量一致

登录oss-chiji服务的主机，使用admin用户，执行如下命令，获取所有KVServerRole数量。由于换行符问题需要将数量加一。
```
tj_show -r kvengine.KVServerRole# | wc -l
```
执行以下命令，获取所有盘古的ChunkServer数量。
```
puadmin lscs | grep ttl | wc  -l
```
对比步骤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黑名单

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

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

系统显示类似如下。

执行以下命令，查看缩容机器是否添加到KV黑名单。
```
/apsara/deploy/kuadmin --interactive=false --command=getblacklist
```
系统显示类似如下。

3.2.3. 验证Checkready是否通过

执行以下命令，获取应用程序列表。
```
/apsara/deploy/kuadmin  --interactive=false --command=listapp
```
系统显示类似如下。

以上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黑名单功能

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

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

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

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

登录oss-chiji服务的主机，执行以下下命令，开启fuxi手动加黑名单功能。
```
r sgf fuximaster "{\"fuxi_Enable_BadNodeManager\":false}"
```
系统显示类似如下。

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

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

执行以下命令，添加需要下线的机器到黑名单。
```
/apsara/deploy/rpc_wrapper/rpc.sh blacklist cluster add [$Hostname]
```
说明：[$Hostname]为需要下线机器的主机名。

系统显示类似如下。

执行以下命令，查看fuxi黑名单中是否有该机器。
```
/apsara/deploy/rpc_wrapper/rpc.sh blacklist cluster get
```
系统显示类似如下。

3.2.6. 机器关机维修步骤

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

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

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

3.2.7. RMA操作

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

执行以下命令，修改故障机器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]"
        }
    ]
}

执行以下命令，获取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
    }
}

执行以下命令，设置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值。

系统显示类似如下。

执行以下命令，查看机器action状态。
```
curl "http://127.0.0.1:7070/api/v5/GetMachineInfo?hostname=[$Hostname]"
```
系统显示类似如下。

执行以下命令，查看机器上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. 关机维修

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

维修完毕后，保证网线全部连接正常，启动服务器即可。
说明：
- 若不需要克隆机器，在执行机器上线操作后，进行机器启动后恢复流程操作。
- 若需要克隆机器，则从重新克隆装机开始进行操作。

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. 重新克隆装机

执行以下命令，设置故障机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分钟左右。
可通过以下两种方式，查看克隆进度。
1. 执行如下命令，查看机器状态。也可通过登录天基控制台查看。
```
curl "http://127.0.0.1:7070/api/v5/GetMachineInfo?hostname=[$Hostname]&attr=state,hostname"
```
2. 系统显示类似如下，状态为GOOD，表示机器维修完成，可恢复正常使用。
3. 登录天基控制台，选择报表>系统报表>机器clone报表，查看克隆进度。

3.2.11. 机器启动后恢复流程

登录oss-chiji服务的主机，切换到admin用户，执行以下操作，恢复ChunkServer状态。
恢复执行以下命令，查看下线机器的ChunkServer状态。如果是克隆机器则跳过此步骤。
```
/apsara/deploy/puadmin lscs | grep tcp
```
系统显示类似如下，状态为SHUTDOWN。
执行以下命令，恢复ChunkServer状态。
```
/apsara/deploy/puadmin cs -stat tcp://[$IP]:10260 --set=NORMAL
```
系统显示类似如下。

执行以下命令，将机器移除fuxi黑名单。

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

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

执行以下命令，验证checkready是否通过。

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

系统显示类似如下。

执行以下命令，查看kv_server进程。
```
ssh [$IP] 'ps -ef|grep kv_server'
```
系统显示类似如下。

执行以下命令，将机器移除KV黑名单。

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

系统显示类似如下。

执行以下命令，查看机器有没有移除黑名单。
```
/apsara/deploy/kuadmin --interactive=false --command=getblacklist
```
系统显示类似如下。
6个APP都执行以下命令，验证checkready是否通过。
```
/apsara/deploy/ku --interactive=false --command=checkready --appname=[$APP_Name]
```
系统显示类似如下。
6个APP都执行如下命令，确认是否有异常分区。如果有异常分区，请联系阿里云技术支持。
```
/apsara/deploy/ku --interactive=false --command=getserverparts --appname=[$APP_Name] --param1=tcp://[$IP]:10280
```
系统显示类似如下，表示正常。

3.3. 结果验证

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

4. 回滚方案

暂无回滚方法。

5. 补充说明

SSH登录到clone的机器，执行以下命令，查看是否有access_log日志文件产生。
```
ll -rt /apsara/apache/logs
```
系统显示类似如下。
执行以下命令，查看安装的Tengine的版本。
```
sudo rpm -qa|grep -i tengine
```
系统显示类似如下。

执行以下命令，修复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

系统显示类似如下。

执行以下命令，修复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
系统显示类似如下。

执行以下命令，确认有access_log日志文件生成。
```
ll -rt /apsara/apache/logs
```
系统显示类似如下。
执行以下命令，查看日志文件信息。
```
tail /apsara/apacha/logs/access_log.20180829
```
系统显示类似如下。

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