在测试k8s高可用过程中，出现了很多不稳定的问题，比如服务pod没有加载umc配置文件、redis主节点没有自动迁移等。这些问题通过脚本的方式解决的比较顺利，只有nfs高可用比较坎坷。
nfs高可用采用drbd方式实现，drbd分为主从模式，在停机切换时存在不稳定的情况。为了解决问题，达到稳定切换高可用的目的，经过2周的调整后问题已得到解决，在此记录调整过程，对自己的工作进行复盘。
1基础介绍
在文章开始之前，先介绍一些解决过程中用到的名词、部署架构和切换脚本。
1.1名词解释
1.nfs：网络文件系统，英文Network File System(NFS)，是由SUN公司研制的UNIX表示层协议(presentation layer protocol)，能使使用者访问网络上别处的文件就像在使用自己的计算机一样。
2.drbd：一个用软件实现的、无共享的、服务器之间镜像块设备内容的存储复制解决方案。
3.keepalived：作用是检测服务器的状态，如果有一台web服务器宕机或工作出现故障，Keepalived会检测到并将有故障的服务器从系统中剔除，同时使用其他服务器代替该服务器的工作，当服务器工作正常后Keepalived自动将服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉。
4.Shell脚本：Shell 脚本（shell script）是一种为shell编写的脚本程序，使用一种特定的描述性语言，依据一定的格式编写的可执行文件。
1.2部署架构
1.通过浮动IP指向主服务器上的存储磁盘，此时数据存取都是主节点，但会同步到从节点的存储磁盘中；
2.从节点是虚线，表示此时数据不走从节点，待机状态；
3.当主服务器出现问题时，浮动IP会转移到从服务器上，虚线变为实线，数据存储改为从服务器。切换过程中调用主副服务器的nfs_check.sh脚本，执行脚本内容，切换drbd。
1.3脚本介绍
切换nfs主从脚本nfs_check.sh，绿色部分为注解和打印日志说明，如下：
2测试方案
测试方案分为2种，一种是最基础的功能测试，主服务器宕机后检查副服务器的nfs是否启用。另一种是业务测试，即主服务器宕机后，esb、idm产品是否可以继续访问使用。
2.1基础测试
检查重点：主服务器宕机后，drbd是否切换挂载到从服务器，nfs依然正常挂载。
测试方法：
1.主服务器停止nfs服务，观察nfs服务是否自动启动，如果未启动，是否切换drbd；
2.主服务器停止keepalived服务，观察keepalived服务是否自动启动，如果未启动，是否切换drbd；
3.主服务器reboot重启，观察是否切换drbd，当主服务器恢复后，观察drbd是否回到主服务器。
2.2业务测试
检查重点：主服务器宕机后，idm、esb产品页面功能是否正常访问和使用，redis连接是否正常，后台日志输出。
测试方法：
1.主服务器reboot重启，观察是否切换drbd，idm、esb产品页面功能是否正常访问和使用，redis连接是否正常，后台日志输出；
2.当主服务器恢复后，观察drbd是否回到主服务器，idm、esb产品页面功能是否正常访问和使用，redis连接是否正常，后台日志输出。
3问题罗列
下文将介绍测试过程中每个阶段出现的问题和对应的解决方法，本次测试遇到的需要攻克的问题主要以下几种。
3.1切换挂载
nfs网络文件系统，本地连接远程服务器共享目录，能使使用者访问网络上别处的文件就像在使用自己的计算机一样。
3.1.1问题描述
drbd切换后，nfs挂载提示“mount.nfs: Stale NFS file handle”。
3.1.2解决思路
这种错误提示在当前的情况下是因为“过时的nfs句柄”造成的，原因是客户端已打开文件，但服务器不再识别文件句柄，在某些情况下，NFS会在超时后清理其数据结构。但在其他情况下，需要自己清理nfs数据结构后重新启动nfs。
3.1.3解决方法
重新启动nfs服务。
3.2drbd挂载
drbd是一个用软件实现的、无共享的、服务器之间镜像块设备内容的存储复制解决方案。
3.2.1问题描述
drbd切换后再切换回主服务器后，没有自动设置主节点，node1和node2互相认为对方 StandAlone，导致drbd连接失败，无法同步。
3.2.2解决思路
这个问题的解决思路就是想办法让2个drbd在系统自启后重新连接上。但有一点需要后续留意，就是本地搭建的虚拟机k8s集群，重启服务器，切换drbd，再恢复后是自动连接上的，而在项目的服务器上却不能自动连接。目前不清楚什么原因，暂不确定是虚拟机版本不同还是因为客户使用的华为服务器。
3.2.3解决方法
在主服务器重新设置主节点，在从服务器重新设置从节点。
主drbd服务器执行：
副drbd服务器执行：
3.3连接redis
产品运行存储使用了redis，在服务器宕机后，redis集群会自动转移，当服务器重新启动后，redis集群会自动恢复。
3.3.1问题描述
服务器重启后，自启的产品在启动过程中提示连接redis持久化异常。报错信息：Exiting on error writing to the append-only file: Bad file descriptor。
3.3.2解决思路
关掉aof持久化，因为我们主要使用redis的存储缓存、共享缓存，没有用到需要落地的场景。
3.3.3解决方法
在创建容器redis时，关掉aof持久化（使用默认值就行，默认没有开启），已经在umc中调整完成，后续不需再考虑。
3.4产品日志
产品日志是指服务运行的日志，由容器映射到服务器上进行存储和查看。
3.4.1问题描述
drbd切换后，nfs也好用，idm、esb功能也没问题，但查看产品服务日志时，发现自切换后，容器映射日志不再更新。
3.4.2解决思路
检查发现是因为脚本中有些命令有时会报错或者执行超时，而keepalived在定时调用脚本时，检查如果在监听时间内脚本没有执行完成，会被认为脚本执行失败，就会切换keepalived的vip，导致keepalived多次主从切换。在多次切换过程中，日志映射出现异常。因此解决思路是保障切换一次就可以成功。
3.4.3解决方法
调整脚本逻辑，减少非必要命令执行，在命令前加入timeout 1，表示此命令如果执行超过1秒，就跳过减少脚本执行一遍的时间。
4记录总结
经过2周时间终于解决了nfs高可用的问题，其实验证nfs大部分时间都用在了测试重启服务器上。其中也有一些小问题，但都很快的解决了，这里不再一一说明，下面说说自己的感想和总结。
4.1勇敢面对
遇到问题时不要害怕，也不要畏首畏尾。要相信没有解决不了的问题，只有解决不了问题的人。遇到不明白的技术点时，要冷静分析，从原理上考虑解决思路。同时多动手，多尝试，会发现其实问题没有想象中的困难。
4.2多种尝试
解决问题的最好办法是找各种方法进行尝试，原地发呆并非良方。在生活里，每个人做一件事都有自己的思考方式，看待一件事情也有自己的思维模式，但很多时候，我们经常会让自己的思维固化，局限自己的思维，形成思维惯性。解决这种思维的方式就要多思考、勤于思考，多反思、多学习、不断训练。
4.3解决方法
充分利用网络，其实百度很强大，基本可以解决大部分的问题，也可以使用bing和谷歌搜索，搜问题时也有一些讲究，关键字很重要。尽量多总结问题，然后在百度以各种形式发问，最终都可以找到问题的答案。
总而言之，解决问题的诀窍就是，不抛弃不放弃，多思考、多反思、多从原理入手。先在网上查资料，再不断思考尝试，如果还是无法解决，要向同事和领导虚心请教，大家一定会给你思路和解决方法。只要坚持，大多情况下都会胜利。
