軟件定義的“可靠性”到底可不可靠

李進才

服務器宕機可能是很多運維工程師最可怕的噩夢。谷歌的一項研究表明大多數死機故障是由內存問題引起的，而且每年有1/3的谷歌服務器都會出現可糾正的內存故障，而有1 %的谷歌服務器會出現不可糾正的內存故障，后者是造成系統宕機的典型情況之一。

如果有人說，用軟件的方式，可以解決硬件的內存問題，還能減少30 %的服務器宕機故障，你覺得可靠嗎？

當前的數據中心已經走向軟件定義的時代，從最初的軟件定義網絡SDN到軟件定義數據中心SDDC。為了防止服務器宕機的意外發生，越來越多的企業開始考慮軟件定義的解決方案，并通過軟件定義的可靠性屏蔽服務器、內存等硬件故障帶來的影響。那么軟件是如何實現對內存以及服務器可用性的提升呢？

內存故障非常多，就看系統能不能識別出來，有些故障是內存單個或多個bit故障，有些是內存顆粒故障，有些是內存顆粒上的單行或單列的存儲單元出現故障，還有firmware故障、內存控制器故障。另外還有一些是內存金手指焊接點老化、主板上的內存插槽松動或有灰塵等引起的故障。

器件質量類的故障只能通過工藝的改進來解決，而信服云要解決的是軟件層面可以控制的bit級故障。往往大故障來自于bit級小故障的持續積累，這時要做的就是“防微杜漸”，在小故障發生的時候就抓住它、隔離它，避免影響擴大。

Intel有一種機制叫做MCA（MachineCheck Architecture），可以監測這種類型錯誤。這個機制的運行方式是：首先需定義出這些錯誤模型，把可以自動糾正的錯誤叫做CE（Correctable Error），這些往往是任意單比特錯誤、部分是單顆粒比特的錯誤。但是一些錯誤無法自動糾正恢復，會導致系統宕機，這些錯誤被定義為UCE（Uncorrectable Error）。根據統計，CE/UCE類的問題類型占內存所有類型問題的59 %，所以，如果能夠設計一種故障檢查和糾正的機制，其價值會非常大。

這個全套的錯誤檢查和糾正的機制就是ECC（Error Checking and Correcting）。ECC在遇到故障時首先會進行問題識別，通過設計內存主動掃描機制，可以設置一天24 h不休（也可以調整）掃描和發現故障。識別后判斷故障位置（這里其實用到了一些特殊的bit計算和校驗算法），認定故障位置后，就嘗試隔離有問題的內存空間，避免后續業務再次使用該內存空間。

業界主流的IT服務商都會利用Intel的MCA機制進行內存錯誤處理，但是其軟件實現的精細化程度不一，比如有些服務商只是把CE錯誤屏蔽掉，或者只是簡單的告警，沒有做進一步處理；還有一些服務商即使有告警但是無法準確定位到發生問題的插槽。而信服云則提出了一個風險區機制，一旦發生內存錯誤，就將問題單元置于一個“緩沖區”進行觀察，當CE錯誤達到一定閾值則立刻自動隔離有風險的內存區域，避免錯誤繼續擴大引起嚴重的宕機。

近年來，信服云在內存隔離恢復機制上不斷優化，2022年1月推出的超融合HCI6.7.0中還對ECC機制進行了增強。該增強機制的運行方式是：首先通過CPU的BIOS設置CE Record選項，使得硬件識別出內存錯誤，一旦發現CE/UCE錯誤，硬件就會把這個錯誤上報給信服云的軟件。然后輪到軟件機制上場，OS系統先是判斷這個內存是否被軟件（包括應用軟件和操作系統）使用，如果沒有使用就直接隔離，不允許再分配給軟件使用。

如果被軟件使用了，就獲取軟件的上下文，判斷區分其是被操作系統內核（in_kernel）還是被用戶應用軟件（in_user）使用。

如果是被應用軟件（in_user）使用，對于CE可糾正錯誤，信服云的內存ECC增強機制就用一塊好的內存區域替換掉有錯誤的內存區域，這個過程中業務完全不受影響。如果是UCE不可糾正的錯誤，該機制就重新啟動該進程，把錯誤的內存區域釋放出來并隔離出去不再使用，進程重啟后就可以使用完全正常的內存了。

如果是被操作系統內核（in_kernel）使用，其內存ECC增強機制就把有錯誤的內存區域的信息記錄下來，在系統再次啟動的時候，該機制會隔離這些有錯誤的內存，以保證不會被再次使用。

推出上述機制后，信服云在1 000臺主機環境中進行了驗證。結果證明，通過軟件控制的ECC機制，能夠提前發現內存異常，并且100 %自動隔離成功，提前處置以規避更大的故障影響，總體上相對原有方式能夠減少30 %的服務器宕機故障。

回到開頭的問題，用軟件可以解決硬件層面帶來的問題嗎？毫無疑問，當然可以。信服云的ECC機制就通過創新性的軟件技術，更加準確、智能地控制了服務器的內存故障，有效地提高了IT系統的可靠性。