问题描述
某项目由两套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点钟再看,备份完成。
联系其他运行人员,了解用户访问情况,反馈一切正常,未出现以前那种全部卡住的现象。
推荐本站淘宝优惠价购买喜欢的宝贝:
本文链接:https://hqyman.cn/post/6463.html 非本站原创文章欢迎转载,原创文章需保留本站地址!
打赏微信支付宝扫一扫,打赏作者吧~
休息一下~~