ZKRush 運維如何賦能 Aleo挖礦

ZKRush作為一支有著豐富礦池運維開發經驗的團隊，對於集群設備的管理已經形成了一套有針對性的運作體系，來提升礦池效率，有效控製成本並減少事故率。對於即將到來的三測第二階段，可以預見到的是會有大量前以太坊礦工群體的湧入，競爭將會變得異常激烈。這時候，對於礦池背後的運維團隊而言，考驗也是巨大的。基於我們一直以來對於 Aleo 項目的參與和理解，本篇文章會站在運維的角度來闡述我們的團隊如何在Aleo挖礦中運用多種方案來解決一些實際問題。

容器化

相比傳統的服務部署方式，使用容器化技術，在部署，管理上有著非常明顯的優勢。並且試想一下，如果你手裡有上萬台不同型號配置的礦機，想要做統一管理，絕對是非常頭疼的事情。使用容器化部署，便能將這部分的差異，降到最低。與此同時，Kubernetes在功能上對於挖礦業務也是綽綽有餘。配合容器集群管理集成平台，並且在此基礎上，我們對平台進行了二次開發，新增了更多自動化，CMDB配置管理的功能以及更適合Aleo挖礦，Aleo配置的優化。

網絡

如果是一名合格的運維人員，也許管理一個Kubernetes集群，並不是一件難以勝任的工作。但是如果我們的礦機分佈在各個地域，不同機房的話。就不得不使用一些更高級的網絡模塊，來實現跨地域的礦機整合。把不同地域的服務器，組建成一個集群，並不是一件容易的事情。我們在集群上層，使用sdn網絡以及配套的SDN編排管理平台，將多機房的服務器之間網絡打通，根據業務組建虛擬網絡。這樣Kubernetes集群就能做到在不同機房的服務器間進行調度，部署程序。

CMDB

在我們對容器管理平台的二次開發中，最重要的內容之一，就是配置中心（CMDB）的功能。考慮到實際情況，我們集群中的礦機可能不全是同一配置，跑相同程序的。以太坊合併升級以來，很大可能一部分會轉向挖BTC，還有很大一部分亟需尋找替代幣種，類似ALEO，IronFish等。按照硬件的實際區別，團隊需要區分出適合Aleo的硬件，ETH的硬件或者其他項目的具體服務器。在這個基礎上，計算資源可能又要分配給不同的礦工，不同客戶，這樣運維的複雜度也會成倍的增加。恰好，這些規劃，都可以在CMDB中統一實現。運維人員只要錄入好礦機的基礎信息，用途等。再結合容器包管理平台，以及一些二次開發的自動化功能。便能輕鬆的拉起程序。

接下來，我們針對一些常見的問題，結合一些實際的例子，進行一些解答。

不同的服務器配置如何統一進行管理？

在礦機加入集群後，可以視作，我們有了一個大的資源池。接下來，我們會通過標籤的方式，給這些礦機打上配置相關，以及項目相關的兩種標籤。程序部署階段，可以選擇在擁有指定標籤的服務器上拉起對應服務。 Kubernetes便能自動在這些服務器中進行自動調度。用戶只要計算好最終需要的產量和對應的資源數量即可。在此基礎上，可以更細分到CPU核數，GPU卡的數量等等。都是可以實現的。如果有嚴格控制產量的需求，那麼在程序拉起前就能做好一切限制。

如何對服務器添加監控？

面對成千上萬台礦機，如何保障服務器是否在正常運行是影響最終收益的關鍵。容器管理平臺本身自帶的監控系統結合Prometheus和Grafana，便可以從各個系統及硬件層面有效的保障服務器的基礎運行情況。並且，利用好例如Kubernetes的DaemonSet/Job等此類控制器，也能在系統監控的基礎上添加更多自定義的業務監控指標。例如在Aleo測試網二的時候，我們針對每台Aleo挖礦設備提交 prove次數以及每輪任務的時間等進行了監控，或者說採集來自Aleo官網的一些鏈數據，並在第三方平台進行數據分析和告警，便能更快的感知到業務上的變化。

多地域多機房的場景下，我們有什麼優勢以及解決方案？

這部分涉及到剛才說的網絡SDN方案，基於此網絡架構並結合Kubernetes集群，我們將所有區域的設備納入一個集群統一管理，這極大的減輕了運維的壓力。並且，鑑於SDN網絡的配置過程極其複雜，我們引入了適配的網絡管理平台，只需一條命令，便可加入到自定義網絡中，這個過程也直接涵蓋在服務器初始化的階段，因此無需進行任何的人工操作即可完成。另外，為了不產生額外的網絡開銷，我們也建議在每個區域內網都部署一個容器鏡像倉庫，供每個機房的服務器下載鏡像。這個部分的設想，我們也在容器管理平台的二次開發中進行了實現，可配置多個鏡像倉庫地址自動選擇，並且在倉庫之間開啟複製功能，部署後基本無需介入管理便能找到最優的鏡像倉庫。

一個成熟且富有經驗的專業團隊可以在很大程度上保障挖礦的效率及礦池的穩定性，這其實也是礦工群體在礦池間做選擇時的重要參考依據。以上幾個部分是我們團隊對於ZKRush運維開發過程的一些精選提煉，我們也希望通過技術分享可以讓所有人對於 ZKRush 有更加全面的了解。