精選

[主筆漫談] 專屬型微處理器的復興

電腦的世界自始至終都是圍繞在軟體與硬體的協作之上,單純的硬體或是單純的軟體,是無法完成任何事情的。如果從這個角度看,所謂的軟體定義抑或是硬體定義,只不過也就是「為賦新詞強說愁」罷了! 回到本文主題的微處理器身上。早年,也就是從所謂的「電腦」(計算機)剛被發明出來,一直到筆者唸...

2022/03/03

[企業儲存觀察室|技術] 容器與儲存

隨著更多的企業組織將應用程序遷移到雲端,容器 (Container) 已經開始成為某些應用開發人員的首選。當對容器的使用度越來越高時,做為 IT 基礎架構的一個部份,儲存自然也無法置身事外,這也意味著儲存也必須轉向為容器服務。在更深入的談容器的儲存生態系之前,我們先來為儲存管理者介紹一下容器。


圖一:容器與虛擬主機架構上的不同(圖片來源:NetApp)

應用容器化是一種將應用程序(服務)從底層伺服器硬體抽離出來的打包機制,容器將一個應用程序與其它的隔離開來,同時允許每個應用程序擁有權利存取必要的系統資源。從某個(更容易理解的)角度來說,容器很類似於建立一個虛擬的環境,但比傳統的虛擬環境輕量化許多。容器最大的優勢在於可以使雲原生的應用程序更快速的部署,更快地實現新功能的交付。

圖一展示了容器與傳統的虛擬主機在架構上的不同之處。主要的不同之處明顯的在於作業系統,主機虛擬層 (Hypvervisor) 建構在基礎架構的硬體之上,每一部虛擬伺服器都擁有自己的、完整的作業系統環境。而容器引擎則是架構在作業系統之上,容器包含了運行應用程序必要的程式庫與執行碼。因此,應用程序假如需要不一樣的作業系統環境,那麼就需要兩部(虛擬)主機,反之,如果對作業系統沒有特別的要求,不同的應用程序就可以運行在一部(虛擬)主機上的不同容器裡。

在應用程序的部署上,可以有不同的方式:
傳統的資料中心會將一組特定的應用程序,安裝在專用的伺服器與儲存等基礎架構硬體上(裸機安裝),系統環境設置認證後,就幾乎不會再進行更動,頂多就是做做硬體上的擴充,這種方式直覺而且運行多年,但很容易造成硬體資源的過度採購、閒置或配置不平衡,也就是資源的利用率不佳。

採用主機虛擬環境就可以克服裸機安裝資源不平衡和利用率不足的問題,透過在虛擬層上安裝完整的作業系統(虛擬伺服器),完全不同的作業系統/應用程序就可以共享一組實體資源。但虛擬主機上完整的作業系統,相對來說是屬於「重量級」的,對於應用程序的部署上彈性較差,在面對突然增加的需求反應也不夠即時(啟動太慢)。

而容器則是一種「打包」的解決方案,容器裡只包含運行應用程序所需要的內容,包括執行時的程式庫與所需要的支援軟體,它不需要安裝作業系統,容器運行時會管理與作業系統的傳輸與其它的資源需求。所有的應用程序都共用一個作業系統,相對前述的兩種方式,相對上是「輕量級」的,所以效能更好、反應也更快(啟動快)。
由於容器是輕量級的,因此建立一個新的容器並且將其運行起來非常地快速與直接,將新的服務或更多的工作負載分配到新的容器,可以很快速的進行,結果立即顯現。

與虛擬主機環境相同的,容器的建立、複製和刪除等工作,也需要一個管理的工具,像是 vSphere 裡的 vCenter 一樣;目前最流行的管理平台就是被 Google 開源的 Kubernetes (K8s),K8s 是一個框架,用來管理應用程序所需要的容器,或者一組應用程序需要協同工作的容器。現在,許多開發人員使用 K8s 做為部署在公有雲中的容器化應用程序背後的協作 (Orchestration) 軟體。

但這裡出現一個問題,容器原始上被設計成「無狀態 (Stateless)」的,也就是當容器被移除時,與該容器相關的資料就會全部消失。所有的關鍵性資訊,無論是在記憶體上的,或是在儲存系統上,都消失了,在未來都無法再被使用。這並不符合大部份企業的使用方式,有許多應用程序是需要把狀態保存下來的,即使應用程序停止執行,資料也必須要保留持續可用,像是許多實體資料庫、NoSQL 資料庫、記憶體內資料庫系統、資料處理和 AI/ML 等工作,都必須是「有狀態 (Stateful)」的。有些應用程序要求很高的效能,所以會使用本地的 SSD 來降低對關鍵性資料的存取延遲,但是如果採用容器的部署方式,一旦容器出現故障(宕機),那麼原來儲存在容器裡的資料也會丟失,這就會產生大問題。

大多數的企業都擁有傳統的基礎架構,她們為此付出巨大的投資,流程也已經很成熟了,這些傳統(老式)架構維持著我們這個世界正常的運作。
容器作為一種技術讓部署和建構應用環境變得容易,但它的快速發展以及 DevOps 與傳統的方式是在完全相反方向上。
除了原生無狀態的容器外,另一個問題在於儲存本身。儲統儲存架構複雜,缺乏支援現代化 API 的能力,無法隨著應用而擴展,效能也不可預期。更別提要在不同的站點或雲供應商間安全的移動資料,它需要需要加密、可攜性和整合性,目前這些仍然缺乏。

為了在容器環境裡解決這些問題,首先我們需要一種持久性的儲存機制,可以提供跨伺服器/容器的資料服務,即使容器被移動或移除,資料也始終可用。當資料必須對其它應用程序保持可用且不能被破壞時,持久性儲存是至關重要的。傳統儲存系統並不是容器原生儲存 (Container-Native Storage),因此必須透過容器儲存界面 (Container Storage Interface, CSI),CSI 使儲存供應商可以開發一個插件,使協作系統可以跨容器的建立或刪存儲存的資料卷。有了 CSI 儲存就可以提供檔案系統給在容器中運行的應用程序,儲存變得更具擴展性,也可以更廣泛的使用創新的儲存產品。經由 K8s 的 CSI 插件,應用程序就可以在不同的容器間共享資料。像是高速運算應用、人工智慧、機器學習或是資料庫,不同容器間的應用程序,無論是循序運行或是同時運行,都可以快速而且輕易的存取持久性儲存中的資料。
CSI 插件解決了許多問題:透過 CSI 儲存可以同時支援有狀態和無狀態的應用程序,資料集可以在多個容器間共享,也可以將一個命名空間擴展到 EB 級的規模。

隨著應用程序容器生態系的擴展,目前(幾乎)大部份傳統儲存供應商都已經支援 CSI,但,如同所有的技術支援一樣,各有細節巧妙不同。首先,從支援的廣度來看,有些只有單一系列產品支援,有些則是多系列產品都有支援,不同系列的產品可能要使用不同的 CSI 驅動程式。其次,也不是所有的供應商都同時在檔案儲存 (NFS) 與區塊儲存 (iSCSI) 上支援 CSI。另外,在資料實體複製、時點快照的支援上,也各有不同;其中筆者認為有一個很重要的資料卷輸入 (Volume Import)。
透過資料卷輸入功能才能把已經存在持久性資料卷載入其它的容器,在這個部份各家供應商支援的差距就比較大。
但長遠來看,CSI 的全面支援將會是必然。

最後我們來看一下容器原生儲存。容器原生儲存是一種軟體定義儲存,資料服務運行在 K8s 環境的容器中,沒有依存關係,為應用程序提供持久性資料卷。容器原生儲存為需要持久性資料卷的應用程序建立一個虛擬環境,在容器原生儲存環境中,底層的硬體如 HDD 或 NVMe SSD 在池中虛擬化,這個儲存池可供 K8s 應用程序使用,容器保存資料卷和物件,因此應用程序可以獨立運行而無需外部的依存關係。

容器原生儲存有一些優勢:
可攜性:容器在運行時儲存單元可以輕易地在資料中心的環境之間轉移。
隔離性:因為容器沒有任何的依存關係,運行的應用程序已經具有工作負載所需要的一切,包括資料卷。
附加功能:資料快照、複製和壓縮等功能,用於企業資料保護、備份或強化儲存。
容器原生儲存是一項還在早期發展階段的新技術,在虛擬主機的時代我們也經歷過類的階段,如今我們已經瞭解這類軟體的原生儲存並非全面適用於所有的工作負載,筆者認為容器原生儲存未來也會是相同的狀況。