⑴ 分布式存儲系統的應用方案
在一個視頻監控系統中，選擇什麼樣的存儲解決方案直接決定了整個系統的系統架構以及系統的性能和穩定程度。
一種是在攝像監控前端採用有一定存儲容量（如1.2T）的DVR設備，所有需要的數據均保存在前端DVR的存儲設備中，比較好的方案中，後台軟體可以管理和維護多台的DVR設備，包括這些DVR設備的存儲數據，如錄像的轉存、刪除和回放等功能。這種方案中所有數據主要保存在DVR中，後台主要負責維護和必要的存儲。
另一種是在攝像監控前端採用DVR或者網路視頻伺服器，而存儲主要在遠端通過後台的PC或者伺服器軟體來將數據保存在後台的存儲設備上。
上述兩種存儲方案均有很多弊端，尤其當監控點很多，需要的存儲量又很大的情況下，這些可能的弊端包括：由於存儲分散導致難以維護；由於存儲的專業程度不高導致存儲的可靠性不高，進而導致整個系統的可靠性不高；存儲的利用率不高；存儲的擴展性不好。
為了克服這些弊端，並推薦使用基於分布式存儲、集中管理思路的、以及基於iSCSI技術的IPSAN來作為視頻監控的存儲解決方案，這個方案的主要特點包括：
1、分布式存儲，集中管理；
2、基於iSCSI技術的IPSAN（STorageAreaNetwork）；
3、流媒體網關可以作為存儲解決方案的核心設備。 在這個方案中，共有三級：
1、上級監控中心：上級監控中心通常只有一個，主要由數字矩陣、認證伺服器和VSTARClerk軟體等。
2、本地監控中心：本地監控中心可以有多個，可依據地理位置設置，或者依據行政隸屬關系設立，主要由數字矩陣、流媒體網關、iSCSI存儲設備、VSTARRecorder軟體等組成；音視頻的數據均主要保存在本地監控中心，這就是分布式存儲的概念。
3、監控前端：主要由攝像頭、網路視頻伺服器組成，其中VE4000系列的網路視頻伺服器可以帶硬碟，該硬碟主要是用於網路不暢時，暫時對音視頻數據進行保存，或者需要在前端保存一些重要數據的情況。
本地監控中心的存儲設備也可以用一台伺服器，帶SCSI磁碟陣列的形式，但由於伺服器的網路收發性能有限，從而影響整個存儲系統的性能，因此有建議選用專業的iSCSI存儲設備。 1） iSCSI原理簡介
iSCSI 是由IETF 開發的一種基於存儲網路的新的Internet 協議，iSCSI 的原理是將SCSI 命令通過IP 網路傳輸，這樣就可以使在網路上傳送數據更加便利，而且可以實現遠程存儲管理。
iSCSI 使標準的SCSI 命令能夠在TCP/IP 網路上的主機系統（啟動器，Initiator）和存儲設備（目標器，target）之間傳送。而且iSCSI 協議支持在系統之間傳送標準的SCSI 命令。在系統之間的連接是通過標準的IP 網路基礎設施實現的，iSCSI 的協議模型如圖1 所示。
圖2 iSCSI 的協議模型
iSCSI 的工作原理是:當終端用戶或應用程序(啟動器)發送一個請求後，操作系統將生成一個適當的SCSI 命令和數據請求，SCSI 命令通過封裝，在需要加密的時候要執行加密處理。這些命令加上TCP/IP 協議的包頭，就可以在乙太網上傳輸。接收端(目標器)在收到這個數據包後按照相反的方向進行解包，解析出SCSI 命令和數據請求，SCSI命令再發送給SCSI 存儲設備驅動程序，因為iSCSI 是雙向的協議，所以它可以將數據返回給原來的請求。
2） 基於IP SAN的網路存儲方案
圖3 基於IP SAN 的網路存儲方案
在這個解決方案中，網路視頻伺服器需要支持iSCSI 協議，是啟動器，而位於監控中心的iSCSI 存儲設備則是目標器。本地監控中心的iSCSI 存儲設備可以充當多個網路視頻伺服器的存儲設備，而且iSCSI 存儲設備還可以再外掛磁帶設備，進一步擴大存儲容量。 在網路存儲方案中，每台網路視頻伺服器均佔有一個IP，如果希望通過Internet 來進行遠程監控，則網路視頻伺服器的IP 地址必須是公網IP，在通常情況，公網IP 地址都是稀有資源；另外遠程監控受到網路容量的限制以及網路擁塞的影響，帶寬通常不能保證，給遠程監控帶來了不便，而卓揚科技的流媒體網關可以解決這兩個問題。
卓揚科技的流媒體網關是一個嵌入式的硬體設備，所有的報文轉發均是基於硬體轉發(如果是軟體轉發，性能達不到要求)，報文的轉發能力可以達到1Gbps 以上，卓揚科技的流媒體網關的主要功能包括：
支持NAT 轉換功能
支持視頻分發功能，當多個遠程監控的用戶訪問同一台網路視頻伺服器的時候，均需要向流媒體網關發請求，然後流媒體網關再向網路視頻伺服器發出請求，當流媒體網關收到網路視頻伺服器的數據後(注意視頻伺服器與流媒體網關之間的數據流只有一份)再負責分發給遠端的多個監控用戶支持視頻點播服務，遠端用戶可以通過流媒體網關完成視頻點播的功能支持iSCSI 的Initiator
卓揚科技的流媒體網關可以對上述的功能進行分別進行配置。
下圖是一個流媒體網關與IP SAN 結合的網路視頻監控的解決方案，在方案中，流媒體網關沒有使能iSCSI 的Initiator，iSCSI 的Initiator 是由網路視頻伺服器完成，其中iSCSI 的存儲流是把監控流封裝了iSCSI 而成的。
圖4 與流媒體網關相配合的網路存儲方案1
下圖的網路存儲方案中，流媒體網關使能了iSCSI Initiator 功能，而網路視頻伺服器與流媒體網關傳送的均是原始的視頻數據流(與iSCSI 存儲流相比)。
圖5 中，需要對數據進行存儲的時候，流媒體網關首先從網路視頻伺服器活動數據(①)，然後再通過iSCSI 存儲流將視頻數據保存到iSCSI 的存儲設備上(②)。當A 用戶需要進行遠程監控的時候，首先A 用戶向流媒體網關發出請求(③)，流媒體網關再向視頻伺服器獲取數據(①)，然後流媒體網關把監控視頻數據發送給用戶A(③)。當B 用戶需要進行視頻點播的時候，B 用戶首先向流媒體網關發出請求(④)，流媒體網關再向iSCSI 存儲設備獲取數據(②)，然後然後流媒體網關把監控視頻數據發送給用戶B(④)。
圖5 與流媒體網關相配合的網路存儲方案2
另外，在圖4 和圖5 中，是否進行NAT 轉換視組網需求而定，可以靈活配置。
五、 後記
基於iSCSI 的IP SAN 存儲方案無疑是解決存儲問題的一個良方，尤其當iSCSI 的存儲設備的性能不斷提高、價格不斷降低的時候，採用這種方式就更是必然的選擇，我們深信，基於iSCSI 技術的存儲解決方案會逐漸成為大型網路視頻監控中存儲技術的主流。
⑵ 如何在VMware環境下部署存儲解決方案
在VMware環境下使用iSCSI存儲的最佳實踐 一旦iSCSI磁碟配置好了，虛擬機(VMs)就可以使用它們了。以下列出的最佳實踐可以幫助你在VMware環境中的iSCSI數據存儲獲得最大的性能和可靠性。 iSCSI存儲的性能高度依賴於網路的健康和使用。為了達到最佳...
⑶ ⑩ OpenStack高可用集群部署方案(train版)—OpenStack對接Ceph存儲
參考Ceph官方安裝文檔
Openstack環境中，數據存儲可分為臨時性存儲與永久性存儲。
臨時性存儲：主要由本地文件系統提供，並主要用於nova虛擬機的本地系統與臨時數據盤，以及存儲glance上傳的系統鏡像；
永久性存儲：主要由cinder提供的塊存儲與swift提供的對象存儲構成，以cinder提供的塊存儲應用最為廣泛，塊存儲通常以雲盤的形式掛載到虛擬機中使用。
Openstack中需要進行數據存儲的三大項目主要是nova項目（虛擬機鏡像文件），glance項目（共用模版鏡像）與cinder項目（塊存儲）。
下圖為cinder，glance與nova訪問ceph集群的邏輯圖：
ceph與openstack集成主要用到ceph的rbd服務，ceph底層為rados存儲集群，ceph通過librados庫實現對底層rados的訪問；
openstack各項目客戶端調用librbd，再由librbd調用librados訪問底層rados；
實際使用中，nova需要使用libvirtdriver驅動以通過libvirt與qemu調用librbd；cinder與glance可直接調用librbd；
寫入ceph集群的數據被條帶切分成多個object，object通過hash函數映射到pg（構成pg容器池pool），然後pg通過幾圈crush演算法近似均勻地映射到物理存儲設備osd（osd是基於文件系統的物理存儲設備，如xfs，ext4等）。
CEPH PG數量設置與詳細介紹
在創建池之前要設置一下每個OSD的最大PG 數量
PG PGP官方計算公式計算器
參數解釋：
依據參數使用公式計算新的 PG 的數目:
PG 總數= ((OSD總數*100)/最大副本數)/池數
3x100/3/3=33.33 ;舍入到2的N次幕為32
openstack集群作為ceph的客戶端；下面需要再openstack集群上進行ceph客戶端的環境配置
在openstack所有控制和計算節點安裝ceph Octopus源碼包，centos8有默認安裝，但是版本一定要跟連接的ceph版本一致
glance-api 服務運行在3個控制節點， 因此三台控制節點都必須安裝
cinder-volume 與 nova-compute 服務運行在3個計算（存儲）節點； 因此三台計算節點都必須安裝
將配置文件和密鑰復制到openstack集群各節點
配置文件就是生成的ceph.conf；而密鑰是 ceph.client.admin.keyring ，當使用ceph客戶端連接至ceph集群時需要使用的密默認密鑰，這里我們所有節點都要復制，命令如下
※Glance 作為openstack中鏡像服務，支持多種適配器，支持將鏡像存放到本地文件系統，http伺服器，ceph分布式文件系統，glusterfs和sleepdog等開源的分布式文件系統上。目前glance採用的是本地filesystem的方式存儲，存放在默認的路徑 /var/lib/glance/images 下，當把本地的文件系統修改為分布式的文件系統ceph之後，原本在系統中鏡像將無法使用，所以建議當前的鏡像刪除，部署好ceph之後，再統一上傳至ceph中存儲。
※Nova 負責虛擬機的生命周期管理，包括創建，刪除，重建，開機，關機，重啟，快照等，作為openstack的核心，nova負責IaaS中計算重要的職責，其中nova的存儲格外重要，默認情況下，nova將instance的數據存放在/var/lib/nova/instances/%UUID目錄下，使用本地的存儲空間。使用這種方式帶來的好處是:簡單，易實現，速度快，故障域在一個可控制的范圍內。然而，缺點也非常明顯：compute出故障，上面的虛擬機down機時間長，沒法快速恢復，此外，一些特性如熱遷移live-migration,虛擬機容災nova evacuate等高級特性，將無法使用，對於後期的雲平台建設，有明顯的缺陷。對接 Ceph 主要是希望將實例的系統磁碟文件儲存到 Ceph 集群中。與其說是對接 Nova，更准確來說是對接 QEMU-KVM/libvirt，因為 librbd 早已原生集成到其中。
※Cinder 為 OpenStack 提供卷服務，支持非常廣泛的後端存儲類型。對接 Ceph 後，Cinder 創建的 Volume 本質就是 Ceph RBD 的塊設備，當 Volume 被虛擬機掛載後，Libvirt 會以 rbd 協議的方式使用這些 Disk 設備。除了 cinder-volume 之後，Cinder 的 Backup 服務也可以對接 Ceph，將備份的 Image 以對象或塊設備的形式上傳到 Ceph 集群。
使用ceph的rbd介面，需要通過libvirt，所以需要在客戶端機器上安裝libvirt和qemu，關於ceph和openstack結合的結構如下，同時，在openstack中，需要用到存儲的地方有三個:
為 Glance、Nova、Cinder 創建專用的RBD Pools池
需要配置hosts解析文件，這里最開始已經配置完成，如未添加hosts解析需要進行配置
在cephnode01管理節點上操作 ；命名為：volumes，vms，images
記錄：刪除存儲池的操作
在cephnode01管理節點上操作 ；
針對pool設置許可權，pool名對應創建的pool
nova-compute與cinder-volume都部署在計算節點 ，不必重復操作,如果計算節點與存儲節點分離需要分別推送；
全部計算節點配置；以compute01節點為例；
Glance 為 OpenStack 提供鏡像及其元數據注冊服務，Glance 支持對接多種後端存儲。與 Ceph 完成對接後，Glance 上傳的 Image 會作為塊設備儲存在 Ceph 集群中。新版本的 Glance 也開始支持 enabled_backends 了，可以同時對接多個存儲提供商。
寫時復制技術(-on-write) ：內核只為新生成的子進程創建虛擬空間結構，它們復制於父進程的虛擬空間結構，但是不為這些段分配物理內存，它們共享父進程的物理空間，當父子進程中有更改相應的段的行為發生時，再為子進程相應的段分配物理空間。寫時復制技術大大降低了進程對資源的浪費。
全部控制節點進行配置；以controller01節點為例；
只修改涉及glance集成ceph的相關配置
變更配置文件，重啟服務
ceph官網介紹 QEMU和塊設備
對接 Ceph 之後，通常會以 RAW 格式創建 Glance Image，而不再使用 QCOW2 格式，否則創建虛擬機時需要進行鏡像復制，沒有利用 Ceph RBD COW 的優秀特性。
總結
將openstack集群中的glance鏡像的數據存儲到ceph中是一種非常好的解決方案，既能夠保障鏡像數據的安全性，同時glance和nova在同個存儲池中，能夠基於-on-write(寫時復制)的方式快速創建虛擬機，能夠在秒級為單位實現vm的創建。
全部計算節點進行配置； 以compute01節點為例；只修改glance集成ceph的相關配置
全部計算節點重啟cinder-volume服務；
任意openstack控制節點上查看;
在任意控制節點為cinder的ceph後端存儲創建對應的type，在配置多存儲後端時可區分類型；
為ceph type設置擴展規格，鍵值 volume_backend_name ，value值 ceph
任意控制節點上創建一個1GB的卷 ；最後的數字1代表容量為1G
查看創建好的卷
openstack創建一個空白 Volume，Ceph相當於執行了以下指令
從鏡像創建 Volume 的時候應用了 Ceph RBD COW Clone 功能，這是通過 glance-api.conf [DEFAULT] show_image_direct_url = True 來開啟。這個配置項的作用是持久化 Image 的 location，此時 Glance RBD Driver 才可以通過 Image location 執行 Clone 操作。並且還會根據指定的 Volume Size 來調整 RBD Image 的 Size。
一直存在的cirros_qcow2鏡像為對接ceph之前的鏡像，現在已無法使用，所以將之刪除
在openstack上從鏡像創建一個Volume，Ceph相當於執行了以下指令
任意控制節點操作；
查看快照詳細信息
在openstack上對鏡像的卷創建快照，Ceph相當於執行了以下指令
如果說快照時一個時間機器，那麼備份就是一個異地的時間機器，它具有容災的含義。所以一般來說 Ceph Pool backup 應該與 Pool images、volumes 以及 vms 處於不同的災備隔離域。
https://www.cnblogs.com/luohaixian/p/9344803.html
https://docs.openstack.org/zh_CN/user-guide/backup-db-incremental.html
一般的，備份具有以下類型：
在虛擬磁碟映像的計算節點上使用本地存儲有一些缺點：
Nova 為 OpenStack 提供計算服務，對接 Ceph 主要是希望將實例的系統磁碟文件儲存到 Ceph 集群中。與其說是對接 Nova，更准確來說是對接 QEMU-KVM/libvirt ，因為 librbd 早已原生集成到其中。
如果需要從ceph rbd中啟動虛擬機，必須將ceph配置為nova的臨時後端；
推薦在計算節點的配置文件中啟用rbd cache功能；
為了便於故障排查，配置admin socket參數，這樣每個使用ceph rbd的虛擬機都有1個socket將有利於虛擬機性能分析與故障解決；
相關配置只涉及全部計算節點ceph.conf文件的[client]與[client.cinder]欄位，以compute163節點為例
全部計算節點配置 ceph.conf文件相關的 [client] 與 [client.cinder] 欄位，以compute01節點為例；
在全部計算節點配置nova後端使用ceph集群的vms池，以compute01節點為例；
在全部計算節點操作;
在全部計算節點操作，以compute01節點為例；
以下給出libvirtd.conf文件的修改處所在的行num
⑷ 華為雲存儲的解決方案
為此，華為推出了基於雲存儲系統和雲存儲服務平台構建的端到端存儲服務解決方案，幫助運營商快速、經濟地提供雲存儲服務與發展用戶。 華為雲存儲系統具備彈性擴展、安全可靠、自動化管理等特點，以及豐富的業務支撐能力，滿足海量數據的存儲以及大規模業務承載的需求。
彈性擴展：高效的存儲基礎架構需支持在性能和容量兩個維度上進行擴展。華為雲存儲系統基於橫向擴展(Scale-out)架構設計，對上層業務平台提供透明的存儲資源服務，屏蔽底層的硬體差異，能夠幫助運營商實現存儲容量的擴展和業務性能的提升。
在容量擴展方面，雲存儲系統支持通過增加硬碟、存儲域和存儲節點三種方式擴展系統容量。此外，雲存儲系統通過統一的資源和I/O調度，使得新接入的存儲域和存儲節點能夠與已有的域和節點一起為上層業務提供存儲服務，實現整系統存儲空間從TB到EB的線性擴展，再通過跨域互聯、訪問重定向等技術，對多個資源池進行統一部署和調度管理。
在性能提升方面，雲存儲系統通過分布式存儲軟體協調大量的存儲硬體節點並行對外提供數據存儲服務，海量數據均勻下發到每個存儲節點的每個硬碟，充分發揮域內節點與硬碟的並行處理能力，使系統在擴展存儲容量的同時，也提升存儲系統的讀寫性能。
安全可靠：華為雲存儲系統從以下兩方面保證用戶數據在整個生命周期內的安全可靠。 通過Erasure Code技術，對文件進行條帶化後生成多個數據塊，並計算若干個校驗塊，同時將所有的數據塊和校驗塊分別存放在不同存儲節點上，若其中一個或多個存儲節點發生故障，系統可在提供正常的讀寫服務的同時，自動在後台進行數據重構，將故障節點上的數據重構到其他節點上。這種節點間的數據保護技術確保華為雲存儲系統具有較高的數據可靠性。
雲存儲系統通過許可權控制和加密來保證數據私密性。在許可權控制層面，擁有存儲業務的用戶或系統的各類管理員的操作必須被授權，不同許可權用戶執行不同的操作。在加密層面，系統選擇HTTP-SSL方式作為數據傳輸安全的技術實現方案，防止傳輸過程中的惡意監聽與篡改，保證數據傳輸的私密性、一致性和不可抵賴性。對於用戶的關鍵信息，如登錄密碼和系統訪問等鑒權信息，雲存儲系統也從客戶端到服務端都進行加密處理，能夠有效保障用戶關鍵信息的安全性。
自動化管理：雲存儲系統通過「一鍵部署」、「批量升級」、「智能告警」等功能實現系統的自動部署與管理。設備上電後管理軟體遠程對所有設備進行安裝、配置，降低系統部署難度，縮短部署時間。同時，存儲節點的批量升級，整個過程無需人工干預和控制，不中斷業務，實現業務透明化。雲存儲管理系統還能夠提供完整的圖形化管理界面，動態反映雲存儲系統的拓撲結構，實現存儲節點和網路設備的統一管理，提高系統運維效率，降低運營成本。
介面豐富：針對不同類型的應用對存儲的訪問需求，如IPTV、視頻監控、網盤等，雲存儲系統提供了文件存儲介面——NFS/CIFS、對象存儲介面——REST，以及針對第三方雲服務的API，滿足各種終端、各種應用的存儲接入。 基於雲存儲系統，雲存儲服務平台不僅可以提供空間租賃、在線存儲、集中備份等服務，還具備完善的業務管理功能。
空間租賃：無論是中小企業還是大型企業，數據增長的速度遠遠超過了對存儲設備投資的幅度。而且部署大型的存儲設備，不僅降低了業務靈活性，也增加了運維成本。通過運營商提供的空間租賃服務，企業可以按需購買存儲空間進行數據存儲，不僅可以更靈活地滿足存儲需求，也免去了繁雜的自運維過程。
在線存儲：在線存儲服務為個人用戶提供了遠端大容量的存儲空間。個人用戶可通過web方式、PC客戶端、手機客戶端三種形式訪問個人數據，web方式能夠使瀏覽器和本地桌面無縫結合;PC客戶端通過將網路資源本地化，不改變用戶的操作習慣;手機客戶端簡單易操作，方便用戶實時訪問，多種訪問方式實現用戶終端的多屏互動、文件同步。
集中備份：中小企業備份系統的建設面臨建設門檻高、周期長等問題，運營商提供的集中備份服務是對企業備份系統「效率」與「安全」的雙重升級，通過集中備份服務能夠實現本地數據共享，按需申請雲端備份空間，以及對重要數據進行本地與雲端的兩級備份。
「兩級備份」通過本地雲存儲網關與遠端雲存儲數據中心共同實現。首先，本地部署的雲存儲網關進行本地的一次備份，保證備份效率;其次，通過本地雲存儲網關的數據同步功能，實現網關上的數據到雲存儲數據中心的二次備份，進一步提高數據的安全性。
大數據時代的到來，將促使更多的企業與個人將數據遷移到雲端，這一過程為運營商向綜合信息服務提供商的轉型創造了良好的契機。華為雲存儲解決方案將致力於為運營商開展雲存儲服務提供良好支撐，華為已經與中國電信、中國移動就雲存儲服務進行了深入的合作。
⑸ 國內私有雲部署解決方案有哪些
在遷移到雲的過程中，很多企業選擇部署私有雲計算環境。這種模式的優點很多，整合了IT投資和資源、自動化任務並引入諸如虛擬化這樣的新技術。通常，雲模式為傳統老設備和新技術的引入之間打通了道路。
公有雲面臨安全問題挑戰，但是您應該在自己的數據中心內已經解決了大多數問題。為什麼不把這些解決方案通過整合和自動化進行擴展，以降低雲項目起步時的復雜性?
遷移到雲並不等於虛擬化
很多企業 IT 部門在考慮遷移到雲的時候總是想到虛擬化，實際上並非如此。在一些數據中心，虛擬平台都是服務提供的核心，但是雲並非僅僅指技術實現方式。實際上，它們還包括了人員、流程、 整合和控制。遷移到雲意味著對企業內重復服務內容的整合，以及對一些日常和傻瓜式工作 的自動化處理，可以解放員工去完成更復雜的工作。
雲可以是共享架構，可能是虛擬化的，也可能包含物理硬體。例如Google 的 Gmail 和微軟的SkyDrive ，這些服務並不需要虛擬化，他們都建立在大量的物理機上。企業的很多私有雲也可以這樣搭建，
事實上，有時候虛擬化甚至還會帶來一些麻煩，比如基於如Microsoft Cluster Service 這類技術的服務，使用虛擬化環境反而可能會發生沖突。此外還包括資源爭奪、安全問題、個別虛擬機管理的復雜性等等問題。
企業要實現的目標應該是整合而不是虛擬化。如果你能把50 台文件和列印伺服器整合到三台集群物理宿主機上，無論是否採用了虛擬化技術，這就是一種成功的雲，。
從虛擬化環境遷移到雲
首先，標准化基礎技術
虛擬化技術通過使用虛擬機模板和自動化部分安裝部署工作，實現了操作系統配置的標准化。同時也對數據復制、防火牆和其它安全工具、OS 以及存儲配置工作的標准化提供幫助。
這些標准化可能為虛擬化和雲計算提供幫助。 如果您無法創建一種萬能的方案，就選擇多種類型，目標是一次性解決配置問題。擁有 10 種不同類型的虛擬機要比3000 個各不相同的系統好得多。
其次，自動化
自動化可以有效消除許多重復性工作。例如：通過向虛擬機模板中添加常規應用軟體來避免之後安裝它，不再去每台伺服器上創建本地賬戶，而改用集中的Lightweight Directory Access Protocol 或Active Directory 實例代替，會更加高效，通過配置管理工具，如Puppet 或Chef 來自動更改和管理伺服器配置的工作。
就算是一組常規的運行命令腳本都能幫助極大。系統管理員可以通過使用命令腳本大幅減少重復性工作，能只輸入一次的命令，就絕不輸入兩次。
自動化並非提供自助服務所必需的。通常雲都被看做一種自助服務，但是 IT 行業花費 很多年時間包裝跟創建和管理伺服器相關的流程。這些流程通常服務於如何監控伺服器或服務，文件如何創建或授權如何管理等等內容。拋開這些事情去提供自助服務是一種錯誤。
調查調整企業內的IT服務
一旦通過標准化和自動化為雲打好了基礎，就可以開始進行進一步的較為復雜的工作了，調查企業中運行 的IT 服務，不要以為會很簡單，這絕對是一項不小的挑戰，你需要找到各項服務存在的原因。
人們總是有好的理由來復制服務。例如，企業的主Web 伺服器不能支持某種技術，所以部門創建了自己的 Web 伺服器。存檔這些需求並努力擴展中央系統功能以滿足它們。您還需要具備足夠的靈活性。遷移到雲需要對 IT 系統構架的長期整合過程，從中您會發現很多意想不到的驚喜。
我現在使用的是小鳥雲，6月新近活動認證可獲得0元伺服器，建議去看看！
⑹ 如何利用Mesos持久化存儲方案部署ArangoDB 集群
我們無法輕易的停止一個掛載了本地文件系統的 Docker 容器並在另一台機器上重啟它。然而，出於性能的考量，分布式資料庫和其他有狀態的服務通常又需要使用本地存儲，甚至是 SSD 盤。所以數據中心操作系統需要考慮為應用提供保留並訪問本地存儲的方式；確保某些任務重啟後被重新調度到同一個節點，進而重新使用它的本地存儲。
Mesos 0.23 的 persistence primitives 特性解決了上述這些挑戰。本文中，我們首先解釋下 Mesos 的 per
⑺ [轉]K8S 六種存儲解決方案的性能比較測試
原文地址： https://toutiao.io/posts/nmflsd/preview
大多數開發人員都認為在部署集群時選擇合適的存儲技術極為重要。但是，在 Kubernetes 這片市場上，人們對於存儲技術的選擇並沒有一個標準的答案。本文將 介紹 Kubernetes 中常用的 6 種存儲，分析它們的使用場景和優缺點，並對它們進行性能測試，找出哪種存儲解決方案才是最理想的選擇。
存儲技術的選擇在很大程度上取決於工程師們要運行的工作負載類型。如果你正在使用 Kubernetes，你可能偏向於通過動態配置使用 volume 來進行塊存儲。對於裸機集群，你就需要為你的用例選擇最為合適的技術，並將其集成到你的硬體上。
此外，例如 AKS、EKS 和 GKE 等公有雲可以開箱即用並帶有塊存儲，但這並不意味著它們是最好的選擇。在許多情況下，默認公有雲存儲類的故障轉移時間較長。例如，在 AWS EBS 中存在一個故障的 VM，附在此 VM Pod 上的 volume 需要 5 分鍾以上的時間才能在另一個節點上重新聯機。但是，像 Portworx 和 OpenEBS 此類雲原生存儲就可以很快解決這種問題。
本文的目的就是尋找在 Kubernetes 中最常用的存儲解決方案，並進行基本性能比較。本次測試使用以下存儲後端對 Azure AKS 執行所有測試：
測試結果
*註：請將結果作為存儲選擇期間的標准之一，但不要僅根據本文的數據做出最終判斷。
在描述過程之前，我們先總結一下最終結論。如果我們忽略本地 Azure pvc 或 hostPath，測試結果是：
那麼這究竟是為什麼呢？讓我們從每個後端存儲介紹安裝說明開始，詳述 AKS 測試的具體過程！
各存儲解決方案的安裝及優缺點
*註：本節不含 Azure hostpath 的安裝介紹。
本文將把 Azure 原生 Storage Class 作為所有測試的基線。Azure 會動態創建託管磁碟並將其映射到 VM 中，其中 Kubernetes 為 Pod 的 volume。
如果只是為了使用它，你沒有必要再做其他事情。當你配置新的 AKS 集群時，它會自動預定義為「default」和「managed-premium」兩種存儲類。Premium 類將使用基於 SSD 的高性能和低延遲磁碟。
優點：
弊端：
Ceph Rook 需要設計特定的硬體配置，根據數據類型生成 pg 組，配置日誌 SSD 分區（在 bluestore 之前）並定義 crush 映射。 它是一種處理整個存儲集群安裝的簡潔方法。
在 AKS 上安裝 Ceph Rook ：
優點：
弊端：
GlusterFS 是一個的開源存儲解決方案。 Heketi 是 GlusterFS RESTful volume 的管理界面。它提供了一種便捷的方式讓 GlusterFS 具有動態配置的能力。如果沒有這種訪問許可權，用戶就必須手動創建 GlusterFS volume 並將其映射到 Kubernetes pv 上。
*註：關於 GlusterFS 的更多信息，見： https://docs.gluster.org/en/latest/Install-Guide/Overview/
這里使用了 Heketi 快速入門指南[2]進行安裝：
以下是修復該問題的 PR：
同時，動態配置問題也會對測試造成一定影響。對於 Kubernetes 控制平面，Heketi restURL 是不可用的。測試人員嘗試利用 kube dns record、Pod IP 和 svc IP 來解決這個問題，但是都沒有奏效。為此，他們最後選擇通過 Heketi CLI 手動創建 volume。
以下是在 Kubernetes 上安裝 Heketi Gluster 的更多內容：
優點：
弊端：
OpenEBS 代表了一種新的 CAS（Container Attached Storage）概念，屬於雲原生存儲類別。 它是基於單個微服務的存儲控制器和基於多個微服務的存儲復製品。
作為開源項目，目前它提供 2 個後端：Jiva 和 cStor。cStor 作為控制器，它的副本部署在一個 namespace（安裝 openebs 的 namespace）中，也可以說它採用的是原始磁碟而不是格式化分區。每個 Kubernetes volume 都有自己的存儲控制器，它可以在節點可用存儲容量范圍內進行擴展。
在 AKS 上安裝它非常簡單：
優點：
弊端：
*註：OpenEBS 團隊幫忙修改的測試用例場景，見： https://github.com/kmova/openebs/tree/fio-perf-tests/k8s/demo/dbench
最後為大家介紹一種比較新穎的解決方案。
Portworx 是另一個專為 Kubernetes 設計的雲原生存儲，專注於高度分散的環境。它是一個主機可定址存儲，每個 volume 都直接映射到它所連接的主機上。它根據應用程序 I/O 的類型提供自動調整。 不幸的是，它不是開源的存儲方案。然而，它免費提供了 3 個節點可進行試用。
*註：關於 Portworx 更多信息，見： https://portworx.com/makes-portworx-unique/
在 AKS 上安裝 Portworx 很容易，可以使用 Kubernetes 規格生成器：
優點：
弊端：
AKS 測試環境
在本次測試中，測試人員配置了具有 3 個 VM 的基本 Azure AKS 集群。為了能夠連接託管的 Premium SSD，測試人員必須使用 E 類型大小的 VM。因此他們選擇了 Standard_E2s_v3，只有 2 個 vCPU 和 16GB RAM。
每個 AKS 集群都會自動配置第二個資源組（RG）MC_ <name>，你可以在其中找到所有 VM、NIC 。在 RG 內部，測試人員創建了 3 個 1TB 高級 SSD 託管磁碟並手動將它們連接到每個 VM 中。
它允許我在每個專用於測試的實例中獲得 1TB 的空磁碟。據 Azure 稱，它的性能可以在 5000 IOPS 和 200 MB/s 吞吐量之間，具體取決於 VM 和磁碟大小。
性能結果
重要說明：單個存儲性能測試的結果是無法單獨評估的，它們必須相互比較才能顯示出差距。測試的方法有很多種，下面是其中較為簡單的一種方法。
為了進行測試，測試人員決定使用名為 Dbench 的負載測試器。 它是 Pod 的 Kubernetes 部署清單 , 同時它也是運行 FIO 的地方，並且帶有 Flexible IO Tester 等 8 個測試用例。
測試在 Docker 鏡像的入口點指定:
註：所有測試的完整測試輸出，見：
https://gist.github.com/pupapaik/
隨機讀/寫帶寬
隨機讀取測試表明，GlusterFS、Ceph 和 Portworx 在讀取時的性能比 AWS 本地磁碟上的主機路徑快好幾倍，因為它們讀取的是緩存。GlusterFS 寫入速度最快，它與本地磁碟幾乎達到了相同的值。
隨機讀/寫 IOPS
隨機 IOPS 顯示 Portworx 和 Ceph 效果最佳。Portworx 在寫入時的 IOPS 與本機 Azure pvc 幾乎相同，這非常好。
讀/寫延遲
延遲測試返回了有趣的結果，因為本機 Azure pvc 比大多數其他測試存儲都慢。Portworx 和 Ceph 實現了最佳讀取速度。但是對於寫入，GlusterFS 比 Ceph 更好。與其他存儲相比，OpenEBS 延遲非常高。
順序讀/寫
順序讀/寫測試顯示與隨機測試類似的結果，但 Ceph 的讀取是 GlusterFS 的 2 倍多。除了表現非常差的 OpenEBS 之外，寫入結果幾乎都在同一級別上。
混合讀/寫 IOPS
最後一個測試用例驗證了混合讀/寫 IOPS，即使在 mixed write 上，Portworx 和 Ceph 也提供了比原生 Azure pvc 更好的 IOPS。
以上就是所有測試結果，希望這篇文章對你有所幫助。
--
參考文獻：
[1] https://github.com/rook/rook/blob/master/Documentation/ceph-quickstart.md#ceph-storage-quickstart
[2] https://github.com/gluster/gluster-kubernetes/blob/master/docs/setup-guide.md#deployment