手把手教你用Rancher建立產品質量資料庫設定
資料庫對於企業來說至關重要，因此資料庫體系結構遷移到容器平臺顯得尤為必要。本文將介紹如何用Rancher建立產品質量資料庫設定，並分析在Rancher高可用和Kubernetes中可供使用的各種選項，給大家設計產品質量資料庫提供參考。
------------
目標：在本文中，我們將介紹如何執行一個分散式產品質量資料庫設定，它由Rancher進行管理，並且保證永續性。為了部署有狀態的分散式Cassandra資料庫，我們將使用Stateful Sets （有狀態集）以及Rancher中的Kubernetes叢集。
先決條件：假設您已經有一個由雲服務商提供的Kubernetes叢集。如果您想在Amazon EC2中使用Rancher 2.0建立K8s叢集，可以檢視Rancher的資源：
ofollow,noindex" target="_blank">https://rancher.com/docs/ranch ... /ec2/ 。
------------
資料庫對業務至關重要，無論是資料丟失還是洩露，都會為企業帶來嚴重的風險。操作錯誤或體系結構故障都可能導致重大事件和資源的損失，這就需要故障轉移系統/過程來減少資料丟失的可能。在將資料庫體系結構遷移到Kubernetes之前，必須完成在容器體系結構以及裸機上執行資料庫叢集的成本效益分析對比，這包括評估恢復時間目標（Recovery Time Objective，RTO）以及恢復資料目標（Recovery Point Objective，RPO）的災難恢復要求。這些分析在面對資料敏感的應用程式是非常重要，尤其當程式需要真正高可用、針對大規模和冗餘需要地理分離、以及應用程式恢復要低延遲時。
在下文的步驟中，我們將分析在Rancher高可用和Kubernetes中可供使用的各種選項，給大家設計產品質量資料庫提供參考。
A．有狀態系統容器架構的缺點
部署在類似Kubernetes的叢集中的容器自然是無狀態而且短暫的，這意味著它們不會保持固定的身份，並且當發生錯誤或重新啟動時會發生資料丟失和遺忘。在設計分散式資料庫環境時，需要提供高可用性以及容錯，這對Kubernetes的無狀態體系結構提出了挑戰，因為無論是複製還是擴充套件都需要維護下面的狀態：
（1）儲存；（2）身份；（3）會話；（4）叢集角色。
考慮到我們的容器化應用程式，我們馬上就可以看出無狀態架構面臨的挑戰，我們的應用程式需要滿足一系列的要求：
我們的資料庫需要將資料（Data）和事務（Transactions）儲存在檔案中，這些檔案對每個資料庫容器來說都是持久且獨有的；
資料庫應用程式中的每個容器都需要維護一個固定的身份作為資料庫節點，以便我們可以通過名稱、地址或者索引將流量路由給它；
需要資料庫客戶端會話來維護狀態，為保證一致性，需確保在狀態更改之前，讀寫事務已經終止，而且出現永續性故障時狀態轉換不受影響。
個數據庫節點都需要在其資料庫叢集中有持久化的角色，比如主機、副本或者分片，除非它們被特定的應用程式的事件更改，或者由於模式更改了而必須更改。
針對這些挑戰，目前的解決方案可能是將PersistentVolume附加到我們Kubernetes pods上，它的生命週期獨立於使用它的任何一個pod。但是，PersistentVolume不會向叢集節點（即父節點、子節點或種子節點）提供一致的角色分配。叢集不能保證在整個應用程式的生命週期中維護資料庫狀態，說的具體一點就是，新的容器會由非確定的隨機名稱建立，並且pods可以設定在任何時間按照任何的順序啟動、終止或者縮放。所以我們的挑戰依然存在。
B．K8s部署分散式資料庫的優點
有這麼多在Kubernetes叢集中部署分散式資料庫的挑戰，我們是否還值得付出努力呢？Kubernetes開闢了許多優勢和可能性，包括管理大量的資料庫服務以及常見的自動化操作，從可恢復性、可靠性和可擴充套件性來支援其生命週期健康。即使在虛擬化環境中，部署資料庫叢集的所需的時間和成本也遠低於部署裸機叢集。
Stateful Sets提供了前一節中所述挑戰的前進方向。在1.5版本引入了Stateful Sets之後，Kubernetes現在為儲存和身份實現了有狀態質量，保證了下面的內容：
每個pod都附有一個持久卷，從pod連結到儲存，這解決了A中的儲存狀態問題；
每個pod都以相同的順序開始並以相反的順序終止，這解決了A的會話狀態問題；
每個pod都有一個唯一且可確定的名稱、地址和序號索引，用於解決A中的身份和叢集角色問題。
C．部署帶有Headless服務的有狀態集
注意：這部分我們會使用到kubectl服務。關於如何使用Rancher來部署kubectl服務可以參考這裡：
https://rancher.com/docs/ranch ... ectl/ 。
Stateful Set Pods需要headless服務來管理Pods的網路身份。實際上，headless服務具有未定義的叢集IP地址，這意味著在服務上沒有定義叢集IP。相反的，該服務定義具有選擇器，當服務被訪問的時候，DNS被配置成返回多個地址記錄或者地址。此時，服務fqdn將使用相同的選擇器對映到服務後面的所有pod IP的所有IP。
現在我們按照這個模板來為Cassandra建立一個Headless服務：
使用get svc命令列出cassandra服務的屬性：
用describe svc可以將cassandra服務的屬性按照verbose格式輸出：
D．為持久卷建立儲存類別
在Rancher中，通過本機的Kubernetes API資源、PersistentVolume和PersistentVolumeClaim，我們可以使用各種選項來管理持久儲存。Kubernetes中的儲存類別告訴了我們哪些儲存類別是我們的叢集所支援的。我們可以為持久儲存設定動態配置來自動建立卷，並將其附加到pod。例如，下面的儲存類將AWS作為它的儲存提供者，使用型別是gp2，可用區是us-west-2a。
如果需要，還可以建立一個新的儲存類，例如:
在建立有狀態集時，將根據它的儲存類為有狀態集pod啟動PersistentVolumeClaim。使用動態供應，可以根據PersistentVolumeClaim中請求的儲存類為pod動態供應PersistentVolume。
您可也以通過靜態供應手動建立持久卷。可以在這裡閱讀關於靜態供應的更多資訊：
https://rancher.com/docs/ranch ... rage/ 。
注意：對於靜態供應，要求它具有與Cassandra伺服器中的Cassandra節點數量相同的持久卷數量。
E．建立有狀態集
現在我們可以建立有狀態集，它將提供我們想要的屬性：有序的部署和終止、唯一的網路名稱和有狀態的處理。我們呼叫下面命令，啟動一個Cassandra伺服器：
F．驗證有狀態集
接著，我們呼叫下面命令驗證是否在Cassandra伺服器中部署了有狀態集：
在建立了有狀態集之後，DESIRED和CURRENT應該是相等的，呼叫get pods命令來檢視經有狀態集建立的pods的順序列表。
在節點建立期間，你可以執行nodetool state來檢視Cassandra節點是否啟動。
G．有狀態集的擴縮容
將F步驟中的設定複製x次，呼叫縮放命令就可以增加或者減少有狀態集的大小。在下面的示例中，我們按照x=3進行操作。
呼叫get statefulsets可以驗證是否有狀態集已經部署到了Cassandra伺服器上。
再次呼叫get pods來檢視有狀態集建立的pods順序。需要注意的是，在部署Cassandra pods時，它們是按照順序建立的。
我們可以在5分鐘後執行nodetool 狀態檢查，驗證Cassandra節點是否已經加入並且形成了一個Cassandra叢集。
一旦nodetool中節點的狀態變更為Up/Normal，我們就可以通過呼叫CQL來執行大量的資料庫操作。
H．呼叫CQL進行資料庫訪問和操作
當我們看到狀態是U/N，我們就可以呼叫cqlsh來訪問Cassandra容器。
I．使用Cassandra作為高可用無狀態資料庫服務的持久層
在前面的練習中，我們在K8s叢集中部署了一個Cassandra服務，並通過PersistentVolume提供持久儲存。然後，我們使用有狀態集為Cassandra叢集提供有狀態處理的屬性，並將叢集擴充套件到其他節點。我們現在可以在Cassandra叢集中使用CQL模式進行資料庫訪問和操作。CQL模式的優點是，我們可以輕鬆地使用自然型別和流暢的api實現無縫資料建模，特別是在設計擴充套件和時間序列資料模型（如欺詐檢測）的解決方案中。此外，CQL利用分割槽和叢集keys來提高資料建模場景中的操作速度。
總 結
在本系列文章的下一篇中，我們將探索如何在“資料庫即微服務”或無狀態資料庫中使用Cassandra作為持久層，利用Cassandra獨特的體系結構屬性並使用Rancher工具集作為起點。然後，我們將分析cassandra驅動的無狀態資料庫應用程式的操作效能和延遲，並評估其在設計中，邊緣和雲之間具有低延遲的高可用性服務的使用價值。
通過結合Cassandra和微服務架構，我們可以探索有狀態集資料庫的替代方案，改善記憶體SQL資料庫（如SAP HANA）容易出現/ifor read/write事務的延遲的問題，以及HTAP工作負載和NoSQL資料庫在執行需要多個表查詢或複雜過濾器的高階分析時速度較慢的問題。同時，無狀態體系結構可以改善資料庫因為記憶體異常而出現的問題。這些問題都可歸因於SQL資料庫中記憶體索引和多模型NoSQL資料庫中的高記憶體使用。有了這兩個方面的改進，將可以給大規模查詢和時間序列建模提供更好的操作效能。