您好,登錄后才能下訂單哦!
作者:田逸(formyz)
問題描述
某項目由兩套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點鐘再看,備份完成。
聯系其他運行人員,了解用戶訪問情況,反饋一切正常,未出現以前那種全部卡住的現象。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。