问题描述
某项目由两套proxmox组成，一套运行所有的应用程序，一台运行mysql数据库。为了保险起见，proxmox外挂共享存储，夜间对所有的虚拟机进行自动备份。
备份是用的一台4U服务器，考虑到容量与成本，用了一台旧的4U服务器，插了好多慢速的sata盘，有效容量达超过35TB。项目上线后，前半年运行都还很正常，随着业务的增加，数据量跟着增长，特别是数据库的数量及大小。随之而来的是监控系统报警频繁，用户体验变差。而且这个影响面还挺大的。通过排查，发现是数据库虚拟机备份所致。
设定的备份是从凌晨0：30分开始的，基本不能在白天上班前完成，更糟糕的情况，会延迟到傍晚。数据库的性能IO，引起访问堵塞，造成一系列的连锁反应，运维工作的压力极大。
临时措施
为了保证业务的正常，同时也考虑数据安全，征用一台容量小一点的闲置服务器（本来是用于其它目的），其硬盘全部为600G的15000转的sas机械硬盘。将其配置成nfs服务以后，挂接到proxmox数据中心。
设定好以后，夜里安排人轮流跟踪，有报警立即相互通知，还好，未出现堵塞现象。这说明确实是sata性能太差，导致备份速度太慢所致。观察一個星期，如果问题不复现，就出正式的解决方案。这样拿数据说话，也能得到决策人的支持。
方案设计
因为不是不差钱那种机构，因此不可能单独买一套sas盘的存储，而弃用现有的低性能存储。只能在现有这个存储上做优化，提高其性能。在另外一個与之无关的项目中，曾经采购过数台阿里云的“高效云盘”来存放计算密集性的应用（java、php、数据库等），用户访问量大时（用户在线人数上万时），也是老出问题，因而对这个事情印象深刻。所谓的高效云盘，就是用ssd缓存后端的sata盘数据，性能比裸的sata好不少。数据备份没有应用对应磁盘性能那么高的要求，那么借鉴这个方式，是不是对备份的整体写入性能有帮助呢？
原系统有一块ssd，用于安装操作系统，其它sata用于共享，在底层做成了raid 5。再采购一块512G的ssd，拔掉一块sata盘。
咨询硬件供应商，并告知当前使用raid卡的类型及型号，得到的答复是方案可行，并且现有的raid卡可支持ssd缓存，仅仅需要采购一個硬件缓存加速模块并支付少许授权费。以前没有这方面的实践，心里没多少底，但就算达不到要求，造成的资金损失也不大（ssd可做它用）。
总结一下，就是在现有基础上，采购一块512G的ssd硬盘及一块raid卡缓存加速模块，做上配置，即可投入使用。
方案实施
月黑风高夜，派一小弟悄声潜入机房。关机，下架，插入ssd盘，为了方便插入raid 缓存加速模块，把raid卡抠下来，插好缓存加速模块后再插回主板。
硬件准备就绪以后，上架，通电。
进raid卡设置界面（在系统引导之前），给sata盘做好raid 5，然后使用菜单，把512G的ssd盘设置成raid 组的缓存设备。具体的操作，请参照各厂商的操作手册。
设置完毕以后，继续引导，进入系统，应该看不到做缓存的那个512G硬盘。
配置nfs共享目录并启动nfs服务，然后在proxmox数据中心挂接此nfs共享目录。
实施效果
是骡子是马，拉出来溜溜才清楚。
先用磁盘性能工具hdparm及dd等工具测试，速度确实比裸sata盘快好几倍。看看时间差不多了，把备份时间提前半小时，从0：00让系统自动开始备份。相关人等注意听着手机，一有报警相互通知。
早上七点，起来查看备份情况（proxmox管理界面可跟踪到具体备份到那个虚拟机，备份量是多少），完成了将近90%。送了一口气，等到9点钟再看，备份完成。
联系其他运行人员，了解用户访问情况，反馈一切正常，未出现以前那种全部卡住的现象。
