作者 | Gaurav Rishi
譯者 | 張鋒
審校 | Noe
隨著應用容器化的速度加快，Day2服務已經(jīng)成為一個迫在眉睫的問題。這些Day2服務包括數(shù)據(jù)管理功能，如備份和災難恢復以及應用程序遷移。在這個云原生應用容器化的新世界中，微服務通常部署在多個位置（區(qū)域、云、本地），同時使用多種數(shù)據(jù)服務（MongoDB、Redis、Kafka等）和存儲技術來存儲這些應用狀態(tài)。
在這種環(huán)境中，傳統(tǒng)基礎設施或基于虛擬機管理程序的解決方案將很難發(fā)揮作用，那么為云原生應用設計和實施這些數(shù)據(jù)管理功能的正確架構是什么呢？你應該如何分析存儲供應商、數(shù)據(jù)服務供應商和云供應商提供的各種數(shù)據(jù)管理選項來確定適合你環(huán)境和需求的正確方法呢？本文深入探討了各種數(shù)據(jù)管理方法在一致性、存儲要求和性能等多個屬性上的優(yōu)缺點。
定義一個詞匯
首先，我們將解構和簡化技術棧以顯示數(shù)據(jù)可能在云原生應用中的位置。
在考慮數(shù)據(jù)管理時，我們可以在上圖中顯示的一個（或多個）層上進行操作。讓我們列舉這些層：
1、物理存儲
該層包括各種存儲硬件選型，可以將狀態(tài)存儲在非易失性存儲器中，并可選擇從NVMe和SSD設備到旋轉型磁盤甚至磁帶的物理介質。它們有不同的外形尺寸，包括陣列和獨立機架服務器。
物理存儲可以位于：
- 在本地，你可能會遇到來自希捷、西部數(shù)據(jù)和美光等供應商的存儲硬件。
- 在托管云提供商的數(shù)據(jù)中心中。雖然你可能永遠不會接觸物理設備，但你知道它是云的基礎架構一部分。
2、文件和塊存儲
該軟件層提供文件或塊級結構，以實現(xiàn)從底層物理存儲進行高效的讀寫操作。在文件和塊這兩種情況下，底層存儲可以是獨立的（本地磁盤）或共享的網(wǎng)絡資源（NAS 或 SAN）。
- 塊存儲允許你從本地或遠程磁盤創(chuàng)建具有低延遲并可通過iSCSI和FiberChannel等協(xié)議訪問的原始存儲卷。云供應商上的塊存儲實現(xiàn)包括Amazon EBS和GCE 持久性磁盤。
- 文件存儲使用NFS和SMB等協(xié)議為文件語義和操作提供共享存儲。本地常見的文件存儲實現(xiàn)包括來自NetApp和Dell EMC的產(chǎn)品。云供應商上的文件存儲實現(xiàn)包括 Amazon EFS、Google Cloud Filestore和Azure Files。
這一層通常提供快照功能，按照時間點創(chuàng)建卷的副本來進行保護。此外，在 Kubernetes 環(huán)境中，該層提供容器存儲接口 (CSI) 驅動程序來規(guī)范化API，讓上層可以使用這些API來調用快照功能。請注意，就所支持的功能而言，并非所有CSI實現(xiàn)都是相同的。
3、數(shù)據(jù)服務
這一層位于文件/塊存儲實現(xiàn)之上。它提供了各種數(shù)據(jù)庫實現(xiàn)以及日益流行的存儲類型，即對象（又名 blob）存儲。該層通常與應用程序進行交互，底層數(shù)據(jù)庫實現(xiàn)基于工作負載和業(yè)務邏輯來選擇。對于基于微服務的應用程序，多語言持久性是一種規(guī)范，因為每個微服務都會為當前的工作選擇最合適的數(shù)據(jù)服務。
一些數(shù)據(jù)庫類型和示例實現(xiàn)的子集包括：
- SQL數(shù)據(jù)庫：MySQL、PostgreSQL、SQL Server
- NoSQL數(shù)據(jù)庫：
- 鍵值存儲：Redis、BerkeleyDB
- 時間序列數(shù)據(jù)庫：InfluxDB 、Prometheus
- 圖數(shù)據(jù)庫：Neo4j、 GraphDB
- 寬列存儲：Cassandra、Azure Cosmos
- 文檔存儲：MongoDB、CouchDB
- 消息隊列：Kafka、RabbitMQ、Amazon SQS
- 對象存儲1：Amazon S3、Google Cloud Storage、Minio
這些數(shù)據(jù)庫還有幾個托管實例，稱為數(shù)據(jù)庫即服務 (DBaaS) 系統(tǒng)。這些通常包括上面列出的數(shù)據(jù)庫類別之一，有時可以提供自動擴展，同時滿足即服務 ( -aaS ) 業(yè)務的消費經(jīng)濟。DBaaS系統(tǒng)的示例包括 Amazon RDS、MongoDB Atlas和Azure SQL。
從數(shù)據(jù)保護的角度來看，每個數(shù)據(jù)庫實現(xiàn)都提供了一組特定的實用程序（ PostgreSQL的pg_dump或WAL-E，MongoDB的mongodump等）來備份和恢復數(shù)據(jù)。值得注意的是，在一致性、恢復顆粒度和速度方面，許多實用程序具有不同的功能。無論它們是作為獨立實用程序提供還是作為即服務產(chǎn)品的一部分提供，通常僅限于特定的數(shù)據(jù)庫實現(xiàn)，或者至多是一種數(shù)據(jù)庫類型。
4、有狀態(tài)應用
應用程序層是業(yè)務邏輯所在的地方，在云原生世界中，應用程序通常基于現(xiàn)代敏捷開發(fā)并作為分布式微服務實現(xiàn)。幾乎所有應用程序都有一個需要持久化的狀態(tài)。雖然有多種存儲應用程序狀態(tài)的模式，但我們需要在有狀態(tài)的 Kubernetes 應用程序的上下文中將以下信息作為一個原子單元來持久化和保護：
- 應用程序數(shù)據(jù)：跨各種數(shù)據(jù)服務、塊和文件存儲實現(xiàn)分布在多個容器上。
- 應用程序定義和配置：應用程序鏡像和相關的環(huán)境配置分布在各種 Kubernetes 對象中，包括ConfigMaps、Secrets等。
- 其他配置狀態(tài)：包括CI/CD流水線狀態(tài)、發(fā)布信息和關聯(lián)的Helm部署元數(shù)據(jù)。
上圖為一個有狀態(tài)應用程序的示例，它突出顯示了一些需要保護的組件和相關狀態(tài)。需要注意的是，對于實際部署，應用程序由數(shù)百個這樣的底層組件組成。此外，在云原生架構中，保護的原子性單元需要是應用程序與底層數(shù)據(jù)服務或存儲基礎設施層。如前所述，這是因為應用程序的狀態(tài)包括分布在多個物理或虛擬節(jié)點和數(shù)據(jù)服務中的應用程序數(shù)據(jù)、定義和配置。
結論
從備份/恢復和應用程序可移植性的角度來看，一個好的數(shù)據(jù)管理解決方案需要將整個應用程序視為原子性單元，這使得傳統(tǒng)以管理程序為中心的解決方案不再適用。我們還展示了一個簡單的技術棧圖，從各種數(shù)據(jù)服務、塊和文件存儲以及跨本地和云實現(xiàn)物理存儲的角度顯示應用程序狀態(tài)實際所在的位置。這定義了一個基本范疇，使我們能夠深入了解云數(shù)據(jù)管理的操作層級。
附注
有些人可能爭辯認為對象存儲應該與文件/塊屬于同一層。在本文中，對象存儲將被視為另一種具有鍵值接口的數(shù)據(jù)服務，如果需要，可以在Kubernetes中運行。
原文鏈接：https://dzone.com/articles/demystifying-cloud-native-data-management-layers-of-operation
譯者介紹
張鋒，51CTO社區(qū)編輯，長期從事技術顧問工作，專注于運維/云原生領域，精通網(wǎng)絡疑難故障分析，有很豐富的大型銀行運維工具建設實踐經(jīng)驗。
