怎么用Rancher創建產品質量數據庫設置

小編給大家分享一下怎么用Rancher創建產品質量數據庫設置，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

數據庫對業務至關重要，無論是數據丟失還是泄露，都會為企業帶來嚴重的風險。操作錯誤或體系結構故障都可能導致重大事件和資源的損失，這就需要故障轉移系統/過程來減少數據丟失的可能。在將數據庫體系結構遷移到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來提高數據建模場景中的操作速度。

以上是“怎么用Rancher創建產品質量數據庫設置”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！