你好，哈布爾的讀者。 在本文中，我們開啟了一個系列，將討論我們開發的超融合系統 AERODISK vAIR。 最初，我們想在第一篇文章中講述所有內容，但係統相當複雜，所以我們將把大象分成幾部分。
讓我們從系統創建的歷史開始講故事，深入研究作為 vAIR 基礎的 ARDFS 檔案系統，同時也談談這個解決方案在俄羅斯市場的定位。
在以後的文章中，我們將更詳細地討論不同的架構元件（叢集、管理程式、負載平衡器、監控系統等）、設定流程、提出授權問題、單獨展示崩潰測試，當然，也會撰寫有關負載測試和漿紗。 我們也將專門撰寫一篇文章來介紹 vAIR 的社群版本。
Aerodisk 是一個關於儲存系統的故事嗎？ 或者說我們一開始為什麼要開始做超融合？
最初，我們在 2010 年左右萌生了創造自己的超融合的想法。 當時，市場上既沒有 Aerodisk，也沒有類似的解決方案（商業盒裝超融合系統）。 我們的任務如下：從一組具有本機磁碟的伺服器，透過乙太網路協定透過互連聯合起來，有必要創建一個擴展儲存並在那裡啟動虛擬機器和軟體網路。 所有這一切都必須在沒有儲存系統的情況下實現（因為根本沒有錢購買儲存系統及其硬件，而且我們還沒有發明自己的儲存系統）。
我們嘗試了很多開源解決方案，最終解決了這個問題，但解決方案非常複雜，難以重複。 此外，該解決方案屬於「它有效嗎？」的類別。 別碰！ 因此，在解決了這個問題之後，我們並沒有進一步發展將我們的工作成果轉化為成熟產品的想法。
那次事件之後，我們放棄了這個想法，但我們仍然感覺這個問題是完全可以解決的，而這個解決方案的好處是顯而易見的。 隨後國外公司發表的HCI產品也更加印證了這種感覺。
因此，在 2016 年中期，我們重新開始執行此任務，作為創建成熟產品的一部分。 當時我們還沒有和投資人建立任何關係，所以只能用自己不多的錢去買開發台。 收集完 Avito 上使用過的伺服器和交換器後，我們開始做正事。
最初的主要任務是創建我們自己的檔案系統，雖然很簡單，但是我們自己的檔案系統，它可以以虛擬區塊的形式自動均勻地將資料分佈在第n 個叢集節點上，這些節點透過乙太網路互連進行連接。 同時，FS應該能夠良好且輕鬆地擴展，並且獨立於相鄰系統，即以「只是一個儲存設施」的形式與 vAIR 疏遠。
第一個 vAIR 概念
我們故意放棄使用現成的開源解決方案來組織擴展儲存（ceph、gluster、lustre 等），轉而支持我們自己的開發，因為我們已經擁有了許多使用它們的專案經驗。 當然，這些解決方案本身非常出色，在開發 Aerodisk 之前，我們與它們實施了多個整合專案。 但是，為一個客戶實施特定任務、培訓員工，或許還需要購買大型供應商的支援是一回事，而創建一種易於複製的產品，用於各種任務，則是另一回事，我們作為一個供應商，甚至可能了解我們自己，但我們不會。 對於第二個目的，現有的開源產品不適合我們，所以我們決定自己建立一個分散式檔案系統。
兩年後，幾位開發人員（將 vAIR 的工作與經典 Engine 儲存系統的工作結合）取得了一定的成果。
到 2018 年，我們已經編寫了一個簡單的檔案系統，並補充了必要的硬體。 系統透過內部互連將來自不同伺服器的實體（本地）磁碟組合成一個扁平池，並將它們「切割」成虛擬區塊，然後從虛擬區塊創建具有不同容錯程度的區塊設備，並在虛擬區塊上創建虛擬塊設備。並使用 KVM 管理程式汽車執行。
我們沒有過多考慮檔案系統的名稱，簡單地將其稱為 ARDFS（猜猜它代表什麼））
這個原型看起來不錯（當然不是視覺上的，當時還沒有視覺設計），並且在性能和擴展方面表現出了良好的效果。 在獲得第一個實際結果後，我們啟動了該項目，組織了一個成熟的開發環境和一個僅處理 vAIR 的獨立團隊。
那時解決方案的整體架構已經成熟，尚未發生重大變化。
深入探討 ARDFS 檔案系統
ARDFS 是 vAIR 的基礎，它在整個叢集中提供分散式、容錯的資料儲存。 ARDFS 的顯著特徵之一（但不是唯一）是它不使用任何額外的專用伺服器進行元資料和管理。 最初的設想是為了簡化解決方案的配置並提高其可靠性。
儲存結構
在叢集的所有節點中，ARDFS 從所有可用磁碟空間組織一個邏輯池。 重要的是要理解池還不是資料或格式化空間，而只是標記，即任何安裝了 vAIR 的節點在新增到叢集時，都會自動新增到共用 ARDFS 池中，磁碟資源會自動在整個叢集中共用（並可用於將來的資料儲存）。 這種方法可讓您動態新增和刪除節點，而不會對已經運行的系統產生任何嚴重影響。 那些。 該系統非常容易「以磚塊形式」擴展，如有必要，可以新增或刪除叢集中的節點。
虛擬磁碟（虛擬機器的儲存物件）會新增到 ARDFS 池的頂部，該池由 4 MB 大小的虛擬區塊建構。 虛擬磁碟直接儲存資料。 容錯方案也是在虛擬磁碟層級設定的。
你可能已經猜到了，為了磁碟子系統的容錯，我們沒有使用RAID（獨立磁碟冗餘陣列）的概念，而是使用RAIN（獨立節點冗餘陣列）。 那些。 容錯是基於節點而不是磁碟來測量、自動化和管理的。 當然，磁碟也是一個儲存對象，它們像其他所有東西一樣受到監控，您可以使用它們執行所有標準操作，包括組裝本機硬體 RAID，但叢集專門在節點上運行。
在您確實需要 RAID 的情況下（例如，支援小型叢集上的多個故障的場景），沒有什麼可以阻止您使用本機 RAID 控制器，並在頂部建立延伸儲存和 RAIN 架構。 這種場景非常活躍並且得到了我們的支持，因此我們將在一篇有關使用 vAIR 的典型場景的文章中討論它。
儲存容錯方案
vAIR 中的虛擬磁碟可以有兩種容錯方案：
1）複製因子或簡單的複製－這種容錯方法就像一根棍子和一條繩子一樣簡單。 同步複製在節點之間執行，因子為 2（每個集群 2 個副本）或 3（分別為 3 個副本）。 RF-2 允許虛擬磁碟承受叢集中 3 個節點的故障，但「吃掉」一半的有用卷，而 RF-2 將承受叢集中 2 個節點的故障，但保留 3/1 的可用卷。滿足其所需的有用體積。 此方案與RAID-2非常相似，即RF-XNUMX中配置的虛擬磁碟可以抵抗叢集中任何一個節點的故障。 在這種情況下，資料一切正常，甚至 I/O 也不會停止。 當故障節點恢復服務時，將開始自動資料恢復/同步。
以下是正常模式和故障情況下 RF-2 和 RF-3 資料分佈的範例。
我們有一個虛擬機，其獨特（有用）資料容量為 8MB，該虛擬機在 4 個 vAIR 節點上運行。 顯然，現實中不太可能有這麼小的體積，但對於反映ARDFS運行邏輯的方案來說，這個例子是最容易理解的。 AB 是包含唯一虛擬機器資料的 4MB 虛擬區塊。 RF-2 分別建立這些區塊 A1+A2 和 B1+B2 的兩個副本。 這些區塊是跨節點「佈局」的，避免了同一節點上相同資料的交集，即副本A1不會與副本A2位於同一節點。 與B1和B2相同。
如果其中一個節點發生故障（例如，3 號節點，其中包含 B1 的副本），則該副本會在沒有其副本（即 B2 的副本）的節點上自動啟動。
因此，虛擬磁碟（以及對應的 VM）可以輕鬆地在 RF-2 方案中的一個節點發生故障時倖存下來。
複製方案雖然簡單可靠，但也存在與 RAID1 相同的問題 - 可用空間不足。
2)糾刪碼或糾刪碼(也稱為「冗餘編碼」、「擦除編碼」或「冗餘碼」)就是為了解決上述問題而存在的。 EC 是一種冗餘方案，與複製相比，它提供了高資料可用性和更低的磁碟空間開銷。 此機制的工作原理與RAID 5、6、6P類似。
編碼時，EC 程序根據 EC 方案將虛擬區塊（預設為 4MB）劃分為幾個較小的「資料區塊」（例如，2+1 方案將每個 4MB 區塊劃分為 2 個 2MB 區塊）。 接下來，該過程為不大於先前劃分的部分之一的「資料區塊」產生「奇偶校驗區塊」。 解碼時，EC 透過讀取整個叢集中「倖存」的資料來產生遺失的區塊。
例如，採用2+1 EC方案的虛擬磁碟，在4個叢集節點上實現，將像RF-2一樣輕鬆承受叢集中一個節點的故障。 在這種情況下，管理費用會更低，特別是，RF-2 的有用容量係數為2，EC 2+1 的有用容量係數為1,5。
簡單描述一下，本質就是將虛擬區塊劃分為2-8個（為什麼是2到8個，見下文）“區塊”，並為這些區塊計算相似體積的奇偶校驗“區塊”。
因此，資料和奇偶校驗均勻分佈在群集的所有節點上。 同時，與複製一樣，ARDFS會自動在節點之間分配數據，以防止相同的數據（數據副本及其奇偶校驗）存儲在同一節點上，以消除由於數據丟失而丟失數據的機會。事實上，數據及其奇偶校驗將突然出現在一個故障的儲存節點上。
以下是一個範例，具有相同的 8 MB 虛擬機器和 4 個節點，但採用 EC 2+1 方案。
塊A和B被分成兩塊，各2MB（因為2+1是兩塊），即A1+A2和B1+B2。 與副本不同，A1 不是 A2 的副本，它是虛擬區塊 A，分成兩部分，與 B 區塊相同。總共，我們得到兩組 4MB，每組包含兩個 2MB 的區塊。 接下來，對於每個集合，以不超過 2 塊（即 4 MB）的體積計算奇偶校驗，我們獲得額外的 + 2 塊奇偶校驗（AP 和 BP）。 總共我們有 2×2 資料 + XNUMX×XNUMX 奇偶校驗。
接下來，這些片段被「佈局」在節點之間，以便資料不會與其奇偶校驗相交。 那些。 A1和A2不會與AP在同一節點上。
當其中一個節點（例如第三個）發生故障時，掉落的區塊 B1 會自動從儲存在 2 號節點上的 BP 奇偶校驗中恢復，並在有故障的節點上啟動。沒有B 奇偶校驗，即BP 的一部分。 在本例中，這是節點 1
相信讀者一定有個疑問：
“你所描述的一切早已被競爭對手和開源解決方案所實現，那麼你在 ARDFS 中實施 EC 有何區別？”
然後 ARDFS 將會有一些有趣的功能。
注重靈活性的糾刪碼
最初，我們提供了一個相當靈活的 EC X+Y 方案，其中 X 等於 2 到 8 之間的數字，Y 等於 1 到 8 之間的數字，但總是小於或等於 X。該方案提供為了靈活性。 增加虛擬區塊被劃分成的資料片(X)的數量允許減少開銷成本，即增加可用空間。
增加奇偶校驗區塊 (Y) 的數量可提高虛擬磁碟的可靠性。 Y 值越大，叢集中可能發生故障的節點就越多。 當然，增加奇偶校驗容量會減少可用容量，但這是可靠性付出的代價。
性能對EC電路的依賴性幾乎是直接的：「塊」越多，性能就越低；當然，這裡需要一個平衡的觀點。
這種方法允許管理員以最大的靈活性配置延伸儲存。 在 ARDFS 池中，您可以使用任何容錯方案及其組合，我們認為這也非常有用。
下表比較了幾種（並非所有可能的）RF 和 EC 方案。
表格顯示，即使是最「特里」的組合EC 8+7（允許同時丟失集群中最多7 個節點），也比標準複製「吃掉」更少的可用空間（1,875 比2），並且保護效果好7 倍，這使得這種保護機制雖然更複雜，但在需要在有限的磁碟空間條件下確保最大可靠性的情況下更具吸引力。 同時，您需要了解 X 或 Y 的每一個「加」都會帶來額外的性能開銷，因此在可靠性、節省和性能之間的三角關係中，您需要非常謹慎地選擇。 因此，我們將專門撰寫一篇文章來討論糾刪碼大小調整。
文件系統的可靠性和自治性
ARDFS 在叢集的所有節點上本地運行，並透過專用乙太網路介面使用自己的方式同步它們。 重要的一點是ARDFS不僅獨立同步數據，還獨立同步與儲存相關的元數據。 在開發ARDFS 時，我們同時研究了許多現有的解決方案，我們發現許多解決方案使用外部分散式DBMS 來同步檔案系統元數據，我們也使用它來進行同步，但只是配置，而不是FS 元數據（關於此子系統和其他相關子系統）在下一篇文章中）。
使用外部 DBMS 同步 FS 元資料當然是一個可行的解決方案，但是 ARDFS 上儲存的資料的一致性將取決於外部 DBMS 及其行為（坦白說，這是一個任性的女士），這在我們的意見很糟糕。 為什麼？ 如果FS元資料被損壞，FS資料本身也可以說“再見”，所以我們決定採取更複雜但更可靠的路徑。
我們自己為 ARDFS 製作了元資料同步子系統，它完全獨立於相鄰子系統。 那些。 沒有其他子系統可以損壞 ARDFS 資料。 我們認為，這是最可靠、最正確的方式，但時間會證明事實是否如此。 此外，這種方法還有一個額外的優點。 ARDFS 可以獨立於 vAIR 使用，就像延伸儲存一樣，我們肯定會在未來的產品中使用它。
因此，透過開發 ARDFS，我們獲得了一個靈活可靠的文件系統，您可以選擇節省容量或放棄一切性能，或以合理的成本實現超可靠的存儲，但降低性能要求。
再加上簡單的許可策略和靈活的交付模式（展望未來，vAIR 按節點許可，並作為軟體或軟體包交付），這使您能夠非常精確地根據各種客戶需求自訂解決方案，並然後輕鬆維持這種平衡。
誰需要這個奇蹟？
一方面，我們可以說，市場上已經有一些參與者在超融合領域擁有認真的解決方案，而這正是我們實際前進的方向。 看來這個說法是正確的，但是…
另一方面，當我們深入現場與客戶溝通時，我們和我們的合作夥伴發現事實並非如此。 超融合有很多任務，在某些地方，人們根本不知道這種解決方案的存在，在其他地方，它似乎很昂貴，在其他地方，替代解決方案的測試不成功，在其他地方，由於制裁，他們根本禁止購買。 總的來說，這塊田地沒有耕過，所以我們去種植處女地）））。
儲存系統什麼時候比GCS更好？
當我們與市場合作時，經常被問到什麼時候使用經典儲存系統方案更好，什麼時候使用超融合？ 許多生產 GCS 的公司（尤其是那些在其產品組合中沒有儲存系統的公司）表示：“儲存系統正在變得過時，只有超融合！” 這是一個大膽的說法，但並不完全反映現實。
事實上，儲存市場確實正在朝著超融合和類似的解決方案發展，但總有一個「但是」。
首先，按照儲存系統的經典方案建構的資料中心和IT基礎設施無法輕易重建，因此此類基礎設施的現代化和完成仍然需要5-7年的時間。
其次，目前正在建造的基礎設施大部分（指俄羅斯聯邦）是根據使用儲存系統的經典方案建構的，並不是因為人們不了解超融合，而是因為超融合市場是新的，解決方案和標準尚未建立，IT人員尚未接受培訓，他們經驗很少，但他們需要在此時此地建立資料中心。 而且這種趨勢還將持續 3-5 年（然後是另一個遺產，請參閱第 1 點）。
第三，純粹的技術限制是每次寫入 2 毫秒的額外小延遲（當然不包括本地快取），這是分散式儲存的成本。
好吧，我們不要忘記使用喜歡垂直擴展磁碟子系統的大型實體伺服器。
在許多必要且流行的任務中，儲存系統的表現比 GCS 更好。 當然，那些產品組合中沒有儲存系統的製造商不會同意我們的觀點，但我們準備合理地爭論。 當然，作為這兩種產品的開發者，我們肯定會在未來的出版物中對儲存系統和GCS進行比較，我們將清楚地展示在什麼條件下哪個更好。
超融合解決方案在哪些方面比儲存系統效果更好？
綜合以上幾點，可以得到三個明顯的結論：
- 如果任何產品中都會出現額外的 2 毫秒的記錄延遲（現在我們不是在談論合成產品，合成產品上可以顯示奈秒），但超融合是合適的。
- 當大型實體伺服器的負載可以轉換為許多小型虛擬伺服器並分佈在節點之間時，超融合也將在那裡發揮作用。
- 當水平縮放比垂直縮放優先權更高時，GCS 也能做得很好。
這些解決方案是什麼？
- 所有標準基礎設施服務（目錄服務、郵件、EDMS、檔案伺服器、中小型 ERP 和 BI 系統等）。 我們稱之為「通用計算」。
- 雲端供應商的基礎設施，需要快速、標準化地水平擴展，並輕鬆地為客戶「切割」大量虛擬機器。
- 虛擬桌面基礎架構 (VDI)，許多小型使用者虛擬機器在統一的叢集中運作並安靜地「浮動」。
- 分支機構網絡，其中每個分支機構都需要一個由 15-20 個虛擬機組成的標準、容錯且廉價的基礎設施。
- 任何分散式計算（例如大數據服務）。 負載不是“深度”，而是“廣度”。
- 可接受額外小延遲的測試環境，但存在預算限制，因為這些是測試。
目前，我們正是為了這些任務而製作了 AERODISK vAIR，並且我們正在專注於這些任務（到目前為止是成功的）。 也許這種情況很快就會改變，因為… 世界並非靜止不動。
所以…
一系列文章的第一部分到此結束；在下一篇文章中，我們將討論該解決方案的體系結構和所使用的組件。
我們歡迎提出問題、建議和建設性爭議。
來源： www.habr.com