A10应用交付aVCS踩坑经历

1、aVCS功能简介

 aVCS提供多台设备配置、OS统一管理及自动同步

2、aVCS集群配置

vrrp common #aVCS的集群号以及设备号继承vrrp内的配置(不要问我为什么，产品就是这么设计的)

set-id 1 #部署之前最好看下网络内还有没有其他已经部署好的集群，一般做aVCS了VRRP-A是肯定会做的，vip的虚拟mac会根据set-id生成，如果有其他集群在，set-id别冲突了。

device-id 1 #同一集群内不同设备分配好不同的编号

vcs enable #在全局配置模式下开启vcs功能

vcs device 1 #配置本机aVCS相关参数(此时集群尚未形成，需要去每台设备上分别配置)，如果是2号机就vcs device 2，以此类推

priority 200 #1-255，大的优先，选举成为vMaster

interface xx #可以用ve接口、mgt接口，一般使用心跳口

affinity-vrrp-a-vrid 0 #跟随vrid 0，当vrid 0的active切换至2号机时，vMaster也切换至2号机

enable #开启vcs

vcs reload #重启vcs，加载配置

3、aVCS选举机制

两台设备初始化协商时(也就是两台设备刚配置好，接好线缆，网络可达，然后再在两台设备上同时vcs reload)看优先级，优先级高的选举为vMaster。

当一台设备已经选举完成为vMaster时，新加入的设备不管优先级多高，一律为vBlade(一台设备已经选举成vMaster；新加入的设备先接好线缆，保证aVCS接口网络可达，然后再vcs reload)，此处可理解为aVCS已经选举出vMaster形成集群后，不会根据优先级抢占了。

踩坑的地方：2台设备各自选举成为vMaster，然后再接上心跳线，根据原厂工程师的解释，此时响应快的设备成为vMaster，而不是按优先级。

4、踩坑过程

客户当前有两台设备已经形成aVCS集群，需要拿第三台设备替换第二台。
备份02机的配置，恢复至03(03目前没有开启aVCS，拿02在vBlade状态备份的配置进行恢复会产生问题，待确认)。

03开启aVCS后再去连接心跳线，选举vMaster看谁响应快，这点已经不可控。

很不幸03选举成为vMaster，03将自身通过恢复的不完整的配置同步至01，导致01也不完整，01选举成vBlade之后自动重启。

事故发生后，尝试恢复之前备份的配置，无法恢复(这点待确认，是不是只能在vMaster上恢复，待确认)。

最后把01和03都下线，使用之前还没有关机的02，业务逐步恢复。

5、总结

在已有集群的情况下，新加入的设备配置好aVCS、接口ip、路由，vrrp-a等无法同步的非业务配置，但此时不要vcs reload，先接好心跳口线缆，确认对端能够ping通，确认vrrp-a状态正常，此时再vcs reload，当新设备加入集群成为vBlade之后会自动同步vMaster上的业务配置