问题现象
接到客户反馈，说是创建不了新的服务了，查看相关的Event日志，发现此服务拉取不了images，后台查看harbor节点的状态，发现问题，harbor集群的VIP丢失，并且在主机上执行命令都比较卡，top查看平均负载发现非常高。
问题分析
首先我们需要排查什么原因导致harbor节点这个卡顿，负载一直升高。
平均负载是指单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数。所以，它不仅包括了正在使用CPU的进程，还包括等待CPU和等待I/O的进程。
系统平均负载升高的原因主要有三种：
- CPU密集型进程，使用大量CPU会导致平均负载升高，此时CPU使用率跟平均负载是一致的；
- I/O密集型进程，等待I/O也会导致平均负载升高，但CPU使用率不一定很高；
- 大量等待CPU的进程调度也会导致平均负载升高，此时CPU使用率也会比较高。
首先sar -u 观察CPU情况。
cpu使用率非常低，大部分为idle，说明没有进程在等待cpu资源。
sar -b 观察IO情况 IO设备的读写tps都几乎为0。
发现并不存在CPU/IO密集型的进程后，执行了下df操作，发现命令hang死，另外开一个终端，通过strace去分析df命令的系统调用及信号情况，可以明显发现df是在系统调用尝试获取目录/harborimages的stat信息时挂起。
通过ps aux抓取系统运行的df进程信息（状态为D+(无法中断的休眠状态)）：
通过ps aux查看内存和cpu占用最多的5个进程发现了问题，没有cpu占用特别大的进程，但是有一个状态为Dl的进程（无法中断的休眠状态/多线程，克隆线程）
我们再查看下此进程的线程状态：
发现有一堆不可中断的线程，而且越来越多，cpu使用率都为0，此时可以定位问题了，有大量进程读写请求一直获取不到资源，从而进程一直是不可中断状态。造成负载很高。平均负载升高导致机器性能降低，内部的keepalived服务心跳机制超时，最后使得VIP丢失。
registry是harbor中负责存储镜像文件的组件，同时负责处理镜像的pull/push命令。此服务会将宿主机的/harborimages作为挂载目录，为了保障可用性我们后端使用了客户现成的nas来挂载到了/harborimages目录，之前执行df hang住的地方正是这个目录。 又在本地创了个测试目录，使用之前的nas地址挂载发现异常。此时回想起来，前一天客户发通知说要进行xxx区机器网络进行调整，大概率是由于这个引起了。联系客户方运维协助排查，最后发现nas服务器因为重启过导致防火墙开启了。