容器儲存的今生來世
寬為限 緊用功 功夫到 滯塞通
容器生態現狀
容器生態，對比2015年之前已經有重大變化，2015-2016年間，網際網路、新興企業都在將其Workload向容器環境遷。容器已不僅僅是兩年前的部署工具，更是一種成熟的技術和平臺，已經普遍的應用在公有云的運營和運維側、PaaS的虛擬化主流技術中。伴隨而來的容器持久化問題也必然會成為容器管理的核心之一。
近兩年，特別是2016年容器持久化生態有很快的發展，例如EMC、NetAPP、Huawei的企業儲存廠商積極擁抱容器生態，紛紛推出其Docker Volume-plugin實現，特別像EMC更是打造其開源社群EMC Code，並在今年5、6月陸續釋出其容器管控面生態Polly和Libstorage，意圖將其企業儲存更好地融入Docker生態。新興儲存廠商更是抓住容器可能顛覆雲基礎設施的機會推出針對容器定製的儲存，繼2015年的Portworx，2016年CoreOS、StorageOS也紛紛釋出其容器儲存產品.
面對容器持久化生態，應該如何分類，未來趨勢如何，我們不妨梳理並大膽預測下：
形態1: Data-volume + Volume-plugin
最原始的方式不一定是最有效的，Docker釋出之初便考慮到資料持久化問題，提供了Data-volume的支援，但最初的資料卷只是本地卷，不支援外接儲存，直到1.8版本才提供了資料卷外掛。原因可能是Docker最早的定位只是Stateless，但後來發現本地無法滿足有狀態服務的需求，又或者是Docker考慮過於超前，認為Cloud-native的應用應該向無狀態儲存API遷移，資料卷不應該作為主儲存吧。總之卷外掛來的很晚，但這並不妨礙儲存廠商趨之若鶩，大量的卷外掛雨後春筍，2016年上半年統計就有40餘個，如ClusterHQ的Flocker、Rancher的Convoy、EMC的REX-Ray，以及華為的Fuxi等等。
卷外掛最大的問題在於，它只是Docker公司解決持久化的簡單方案，卷外掛僅提供幾個簡單的卷管理介面（當然你可以擴充套件，但那不是標準），讓儲存管控面對接，但並未在資料面上做任何優化。當然這解決了有無問題，傳統儲存可以通過卷外掛給容器發放資料捲了，但問題還在後面，儲存發放的效率、如何適配Cloud-native的高彈性要求，如何在資料提供主機高密度的容器儲存發放，以及更高的併發效能，這些問題還是原地踏步。
— 典型卷外掛實現-Flocker:
形態2: Container-define
顯然有些容器生態的廠商意識到了卷外掛的侷限，便有了後面的第二階段，不能僅依靠Docker的Volume-plugin,還需要結合儲存資料面的能力，針對容器的特徵定製管控面和資料面特性，或者充分發揮企業儲存的高階特性，都是打破卷外掛束縛的思路。這裡面我們看到有CoreOS，基於ServerSAN和容器生態的kv-store etcd打造的容器定義儲存torus，相比單純的控制面，torus能夠更好的與k8s排程整合，並且具有更快的發放和伸縮能力。 容器定義儲存最大的特點在於融合了控制面和資料面能力，並且結合容器特點定製，相對單純控制面更具優勢，產品形態以ServerSAN為主。不足在於儲存本身不是cloud-native的，與容器本身還是在兩個層面，仍需要解決兩層間的排程聯動，適配cloud-native的能力。
— 典型容器定義儲存-torus:
形態3:STaaC
STaaC(Storage as a Container),儲存即容器。應該是目前最貼合容器的儲存了，集資料面、控制面與一身，更重要的是儲存自身也是容器化的，可以隨應用容器一起釋出，這也天然的解決了Cloud-native應用業務變化不可預期，彈性要求高的問題，相比容器定義儲存更具優勢。一些典型的STaaC如：Portworx、StorageOS、BlockBridge等。特點是控制面+資料面，並且自身是Cloud-native形態。缺點可以認為暫無，但下個形態中我們會看到還有優化的空間。
— 典型STaaC-Portworx:
形態4: Container-aware
之前的3個形態，雖然都有不同程度的演進，但沒有本質的改變，即仍是以傳統的儲存形態給容器使用：將卷、檔案掛載到容器宿主機，再通過Docker引擎將掛載目錄對映給容器資料卷，對於具有高密部署、微服務架構的Cloud-native應用來說，單主機會掛載非常多的容器，更重要的是宿主機的卷會變得越來越難於管理，資料卷的放速度也很難保證，要知道容器毫秒級的啟動速度可能因為儲存的發放而變成秒或數十秒，那麼應用如果是幾百或上千個容器的啟動那問題是不能容忍的，便會喪失容器相對虛擬化敏捷的優勢。
Container-aware應該是什麼？除了應該具備前3種形態的特點之外，應該還具備感知容器的能力，容器粒度的能力，而不是將這部分能力解除安裝到主機側，可以參考虛擬化儲存的例子：Tintri。Tintri定位於虛擬化感知，不同於傳統虛擬化儲存大LUN，小LUN的方式，Tintri直接將整個儲存叢集定義為一個VMstore，並且對映給vmware的一個Datastore，後面在這個Datastore建立的虛擬機器不需要在關注卷，Tintri摒棄了卷的概念，而是通過自身資料面去感知VM，並實現了VM-Level的管理、分析、保護和遷移能力，這才是真正面向一種虛擬化技術的儲存最佳方式。容器生態也是同理的，若能實現面向容器引擎甚至Pod叢集的ContainerStore，而不是在Container這一級，將大大減少容器儲存的粒度，並實現資料面的容器感知能力，基於感知容器資料卷實現Container-level的管理、分析、保護、遷移，才是容器儲存的最佳形態。 Container-aware兼具之前3種形態的特點，管控面+資料面，形態上兼具Cloud-native+ContainerStore。
— Tintri的VM-aware參考:
4個形態的演進總結:
盡頭？
IT雲技術瞬息萬變，伴隨著IoT、AI、VR\AR這些新興應用的未來我們不得而知，或許未來的應用儲存都像無狀態轉型，S3、MQ、NoSQL、EventHub，這些將成為主儲存也未嘗不可，儲存則只是一個數據匯流排或共享資料池，非結構化資料完全替代結構化資料，那時候可能不再需要不需要容器儲存了。
-