Proxmox虛擬機自動備份填坑記

做者:田逸(formyz)
php

問題描述java

某項目由兩套proxmox組成,一套運行全部的應用程序,一臺運行mysql數據庫。爲了保險起見,proxmox外掛共享存儲,夜間對全部的虛擬機進行自動備份。mysql

001.jpg

備份是用的一臺4U服務器,考慮到容量與成本,用了一臺舊的4U服務器,插了好多慢速的sata盤,有效容量達超過35TB。項目上線後,前半年運行都還很正常,隨着業務的增長,數據量跟着增加,特別是數據庫的數量及大小。隨之而來的是監控系統報警頻繁,用戶體驗變差。並且這個影響面還挺大的。經過排查,發現是數據庫虛擬機備份所致。sql

 

設定的備份是從凌晨0:30分開始的,基本不能在白天上班前完成,更糟糕的狀況,會延遲到傍晚。數據庫的性能IO,引發訪問堵塞,形成一系列的連鎖反應,運維工做的壓力極大。數據庫

 

臨時措施後端

爲了保證業務的正常,同時也考慮數據安全,徵用一臺容量小一點的閒置服務器(原本是用於其它目的),其硬盤所有爲600G的15000轉的sas機械硬盤。將其配置成nfs服務之後,掛接到proxmox數據中心。緩存

002.jpg

設定好之後,夜裏安排人輪流跟蹤,有報警當即相互通知,還好,未出現堵塞現象。這說明確實是sata性能太差,致使備份速度太慢所致。觀察一個星期,若是問題不復現,就出正式的解決方案。這樣拿數聽說話,也能獲得決策人的支持。安全

 

方案設計服務器

由於不是不差錢那種機構,所以不可能單獨買一套sas盤的存儲,而棄用現有的低性能存儲。只能在現有這個存儲上作優化,提升其性能。在另一個與之無關的項目中,曾經採購過數臺阿里雲的「高效雲盤」來存放計算密集性的應用(java、php、數據庫等),用戶訪問量大時(用戶在線人數上萬時),也是老出問題,於是對這個事情印象深入。所謂的高效雲盤,就是用ssd緩存後端的sata盤數據,性能比裸的sata好很多。數據備份沒有應用對應磁盤性能那麼高的要求,那麼借鑑這個方式,是否是對備份的總體寫入性能有幫助呢?運維

 

原系統有一塊ssd,用於安裝操做系統,其它sata用於共享,在底層作成了raid 5。再採購一塊512G的ssd,拔掉一塊sata盤。

 

諮詢硬件供應商,並告知當前使用raid卡的類型及型號,獲得的答覆是方案可行,而且現有的raid卡可支持ssd緩存,僅僅須要採購一個硬件緩存加速模塊並支付少量受權費。之前沒有這方面的實踐,內心沒多少底,但就算達不到要求,形成的資金損失也不大(ssd可作它用)。

003.jpg

總結一下,就是在現有基礎上,採購一塊512G的ssd硬盤及一塊raid卡緩存加速模塊,作上配置,便可投入使用。

 

方案實施

月黑風高夜,派一小弟悄聲潛入機房。關機,下架,插入ssd盤,爲了方便插入raid 緩存加速模塊,把raid卡摳下來,插好緩存加速模塊後再插回主板。

QQ圖片20190904164144.jpg

硬件準備就緒之後,上架,通電。

 

進raid卡設置界面(在系統引導以前),給sata盤作好raid 5,而後使用菜單,把512G的ssd盤設置成raid 組的緩存設備。具體的操做,請參照各廠商的操做手冊。

003.jpg

設置完畢之後,繼續引導,進入系統,應該看不到作緩存的那個512G硬盤。

004.jpg

配置nfs共享目錄並啓動nfs服務,而後在proxmox數據中心掛接此nfs共享目錄。

 

實施效果

是騾子是馬,拉出來溜溜才清楚。

先用磁盤性能工具hdparm及dd等工具測試,速度確實比裸sata盤快好幾倍。看看時間差很少了,把備份時間提早半小時,從0:00讓系統自動開始備份。相關人等注意聽着手機,一有報警相互通知。

 

早上七點,起來查看備份狀況(proxmox管理界面可跟蹤到具體備份到那個虛擬機,備分量是多少),完成了將近90%。送了一口氣,等到9點鐘再看,備份完成。

聯繫其餘運行人員,瞭解用戶訪問狀況,反饋一切正常,未出現之前那種所有卡住的現象。

006.jpg

相關文章
相關標籤/搜索