手把手教你用Rancher建立產品質量數據庫設置

數據庫對於企業來講相當重要，所以數據庫體系結構遷移到容器平臺顯得尤其必要。本文將介紹如何用Rancher建立產品質量數據庫設置，並分析在Rancher高可用和Kubernetes中可供使用的各類選項，給你們設計產品質量數據庫提供參考。

---

**目標：**在本文中，咱們將介紹如何運行一個分佈式產品質量數據庫設置，它由Rancher進行管理，而且保證持久性。爲了部署有狀態的分佈式Cassandra數據庫，咱們將使用Stateful Sets （有狀態集）以及Rancher中的Kubernetes集羣。

**先決條件：**假設您已經有一個由雲服務商提供的Kubernetes集羣。若是您想在Amazon EC2中使用Rancher 2.0建立K8s集羣，能夠查看Rancher的資源：

https://rancher.com/docs/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/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/rancher/v2.x/en/k8s-in-rancher/kubectl/。

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/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/。

注意：對於靜態供應，要求它具備與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數據庫中的高內存使用。有了這兩個方面的改進，將能夠給大規模查詢和時間序列建模提供更好的操做性能。