第壹周作業：1.ceph的組件和功能2.ceph的數據讀寫流程3.使用ceph-deploy安裝壹個最少三個節點的ceph集群 推薦3個或以上的磁盤作為專用osd 4.測試ceph的rbd使用
1·Ceph組件和功能
組件
Ceph OSDs : ( Ceph OSD ）object storage daemon的功能是存儲數據，處理數據的復制、恢復、回填、再均衡，並通過檢查其他OSD 守護進程的心跳來向 Ceph Monitors 提供壹些監控信息。當 Ceph 存儲集群設定為有2個副本時，至少需要2個 OSD 守護進程，集群才能達到 active+clean 狀態（ Ceph 默認有3個副本，但妳可以調整副本數）。
Monitors : 維護著展示集群狀態的各種圖表，包括監視器圖、 OSD 圖、歸置組（ PG ）圖、和 CRUSH 圖。 Ceph 保存著發生在Monitors 、 OSD 和 PG上的每壹次狀態變更的歷史信息（稱為 epoch ）。
MDSs : Ceph 元數據服務器為 Ceph 文件系統存儲元數據（也就是說，Ceph 塊設備和 Ceph 對象存儲不使用MDS ）。元數據服務器使得 POSIX 文件系統的用戶們，可以在不對 Ceph 存儲集群造成負擔的前提下，執行諸如 ls、find 等基本命令。
CephMgr ：在壹個主機上的守護進程，負責運行指標，運行狀態，性能負載，
其他術語：
RADOS：多個主機組成的存儲集群，即可靠，自動化，分布式的對象存儲系統。
File:? 就是普通文件，ObjectRADOS看到的對象，Object與File的區別是， Object的最大尺寸由RADOS限定(通常為2MB或4MB) ，以便實現底層存儲的組織管理。因此，當上層應用向RADOS存入尺寸很大的File時，需要將File切分成統壹大小的壹系列Objet (最後壹個的大小可以不同)進行存儲。
librados：RADOS集群的API，支持大部分主流語言。
Pool：存儲池，大小取決於底層的存儲空間。
PG：placeholder group，壹個pool（存儲池）內可以有多個PG，pool個pg都是抽象的邏輯概念，可以通過公示計算。PG的用途是對Object的存儲進行組織和位置映射的。具體而言，壹個PG負責組織若幹個Object，但壹個Obiect只能被映射到壹個PG中，即PG和Object之間是“壹對多”的映射關系。同時，壹個PG會被映射到n個OSD上，而每個OSD上都會承載大量的PG，即PG和OSD之間是“多對多”的映射關系。在實踐當中，n至少為2，如果用於生產環境，則至少為3。壹個OSD上的PG可達到數百個。事實上， PG數量的設置關系到數據分布的均勻性問題。
OSD daemon：默認每2秒發送狀態數據給monitor，（同時監控組內其他OSD的狀態）（up 可以提供IO，down不能提供，in有數據，out沒有數據）
PG和OSD之間的關系通過CRUSH算法得出的。常規這三個 OSD daemon 可以在壹臺機器上，也可以在不同機器上；那麽根據 CRUSH 算法會盡可能的保證壹個平衡，就是不在同壹個機器上；畢竟Ceph中的數據是壹個為平衡的狀態，壹切都是通過CRUSH 算法來實現的數據平衡，而 PG 本身是個有序列表，位於第壹的位置是 master；這個列表的產生是由 monitor 來產生的；
尋址流程
File->Object映射 這次映射的目的是，將用戶要操作的File映射為RADOS能夠處理的Object，其十分簡單，本質上就是按照Object的最大尺寸（默認4M）對File進行切分，相當於磁盤陣列中的條帶化過程。這種切分的好處有兩個:壹是讓大小不限的File變成具有壹致的最大尺寸、可以被RADOS高效管理的Object;二是讓對單壹File實施的串行處理變為對多個Object實施的並行化處理。每壹個切分後產生的Object將獲得唯壹的oid,即Object ID,其產生方式也是線性映射,極其簡單。 Object →PG映射 在File被映射為1個或多個Object之後,就需要將每個Object獨立地映射到1個PG中去。這個映射過程也很簡單,如圖所示,其計算公式如下:Hash(oid) & mask -> pgid由此可見,其計算由兩步組成。首先,使用Ceph系統指定的壹個靜態哈希算法計算oid的哈希值,將oid映射為壹個近似均勻分布的偽隨機值。然後,將這個偽隨機值和mask按位相與,得到最終的PG序號(pgid) 。根據RADOS的設計,給定PG的總數為m(m應該為2的整數冪),則mask的值為m-1。因此,哈希值計算和按位與操作的整體結果事實上是從所有m個PG中近似均勻地隨機選擇1個。基於這壹機制,當有大量Object和大量PG時, RADOS能夠保證Object和PG之間的近似均勻映射。又因為Object是由File切分而來的,大部分Object的尺寸相同,因此,這壹映射最終保證了各個PG中存儲的Object的總數據量近似均勻。這裏反復強調了“大量” ,意思是只有當Object和PG的數量較多時,這種偽隨機關系的近似均勻性才能成立, Ceph的數據存儲均勻性才有保證。為保證“大量”的成立,壹方面, Object的最大尺寸應該被合理配置,以使得同樣數量的File能夠被切分成更多的Object;另壹方面, Ceph也推薦PG總數應該為OSD總數的數百倍,以保證有足夠數量的PG可供映射。 PG→ OSD映射 第3次映射就是將作為Object的邏輯組織單元的PG映射到數據的實際存儲單元OSD上。RADOS采用壹個名為CRUSH的算法,將pgid代入其中,然後得到壹組***n個OSD。這n個OSD***同負責存儲和維護壹個PG中的所有Objecto前面提到過, n的數值可以根據實際應用中對於可靠性的需求而配置,在生產環境下通常為3。具體到每個OSD,則由其上運行的OSD Daemon負責執行映射到本地的Object在本地文件系統中的存儲、訪問、元數據維護等操作。和“Object →PG"映射中采用的哈希算法不同, CRUSH算法的結果不是絕對不變的,而會受到其他因素的影響。其影響因素主要有兩個。壹是當前系統狀態,也就是在前面有所提及的集群運行圖。當系統中的OSD狀態、數量發生變化時,集群運行圖也可能發生變化,而這種變化將會影響到PG與OSD之間的映射關系。二是存儲策略配置。這裏的策略主要與安全相關。利用策略配置,系統管理員可以指定承載同壹個PG的3個OSD分別位於數據中心的不同服務器或機架上,從而進壹步改善存儲的可靠性。因此,只有在系統狀態和存儲策略都不發生變化的時候, PG和OSD之間的映射關系才是固定不變的。在實際使用中,策略壹經配置通常不會改變。而系統狀態的改變或是因為設備損壞,或是因為存儲集群規模擴大。好在Ceph本身提供了對這種變化的自動化支持,因而,即便PG與OSD之間的映射關系發生了變化,也並不會對應用產生影響。事實上, Ceph正是利用了CRUSH算法的動態特性,可以將壹個PG根據需要動態遷移到不同的OSD組合上,從而自動化地實現高可靠性、數據分布再平衡等特性。之所以在此次映射中使用CRUSH算法,而不使用其他哈希算法,壹方面原因是CRUSH算法具有上述可配置特性,可以根據管理員的配置參數決定OSD的物理位置映射策略;另壹方面原因是CRUSH算法具有特殊的“穩定性" ,也即,當系統中加入新的OSD,導致系統規模增大時,大部分PG與OSD之間的映射關系不會發生改變,只有少部分PG的映射關系會發生變化並引發數據遷移。這種可配置性和穩定性都不是普通哈希算法所能提供的。因此, CRUSH算法的設計也是Ceph的核心內容之壹。 至此為止, Ceph通過3次映射,完成了從File到Object. Object到PG,PG再到OSD的整個映射過程。從整個過程可以看到,這裏沒有任何的全局性查表操作需求。至於唯壹的全局性數據結構:集群運行圖。它的維護和操作都是輕量級的,不會對系統的可擴展性、性能等因素造成影響 。
存儲過程總結：
1.計算文件到對象的映射
2.通過哈希算法計算計算出文件對應的pool的PG
3.通過CRUSH把對象映射到PG中的OSD
4.PG種的OSD將對象寫入到磁盤
5.主OSD將數據同步到備份OSD，待備份OSD返回確認
6.主OSD的到備份OSD寫完操作以後給客戶的返回寫入成功
2. ceph的讀寫流程
當某個客戶端需要向Ceph集群寫入壹個File時，首先需要在本地完成尋址流程，將File變為壹個Object，然後找出存儲該Object的壹組***3個OSD，這3個OSD具有各自不同的序號，序號最靠前的那個OSD就是這壹組中的Primary OSD，而後兩個則依次Secondary OSD和Tertiary OSD。找出3個OSD後，客戶端將直接和Primary OSD進行通信，發起寫入操作(步驟1)。 Primary OSD收到請求後，分別向Secondary OSD和Tertiary OSD發起寫人操作(步驟2和步驟3)。當Secondary OSD和Tertiary OSD各自完成寫入操作後，將分別向Primary OSD發送確認信息(步驟4和步驟5)。當Primary OSD確認其他兩個OSD的寫入完成後，則自己也完成數據寫入，並向客戶端確認Object寫入操作完成(步驟6)。之所以采用這樣的寫入流程，本質上是為了保證寫入過程中的可靠性，盡可能避免出現數據丟失的情況。同時，由於客戶端只需要向Primary OSD發送數據，因此在互聯網使用場景下的外網帶寬和整體訪問延遲又得到了壹定程度的優化。當然，這種可靠性機制必然導致較長的延遲，特別是，如果等到所有的OSD都將數據寫入磁盤後再向客戶端發送確認信號，則整體延遲可能難以忍受。因此， Ceph可以分兩次向客戶端進行確認。當各個OSD都將數據寫入內存緩沖區後，就先向客戶端發送壹次確認，此時客戶端即可以向下執行。待各個OSD都將數據寫入磁盤後，會向客戶端發送壹個最終確認信號，此時客戶端可以根據需要刪除本地數據。分析上述流程可以看出，在正常情況下，客戶端可以獨立完成OSD尋址操作，而不必依賴於其他系統模塊。因此，大量的客戶端可以同時和大量的OSD進行並行操作。同時，如果壹個File被切分成多個Object，這多個Object也可被並行發送至多個OSD上。從OSD的角度來看，由於同壹個OSD在不同的PG中的角色不同，因此，其工作壓力也可以被盡可能均勻地分擔，從而避免單個OSD變成性能瓶頸。
問：為什麽要設計三層映射而不是壹層？
答：如果將object直接映射到壹組OSD上，如果這種算法是固定的哈希算法，則意味著壹個object被固定映射在壹組OSD上，當其中壹個OSD損壞時，object也無法部署到新的OSD上(因為映射函數不允許)。
如果設計壹個動態算法(例如CRUSH算法)來完成這壹映射，結果將是各個OSD所處理的本地元數據暴增，由此帶來的計算復雜度和維護工作量也是難以承受的。
綜上所訴，引入PG的好處至少有二：壹方面試下呢object和OSD之間的動態映射，從而為Ceph的可靠性、自動化等特性的實現留下了空間；另壹方面也有效簡化了數據的存儲組織，大大降低了系統的維護管理開銷。
1.準備工作
時間同步`
安裝ntpdate（時間同步工具）
# apt install ntpate
0* * * * ntpdate time1.aliyun.com
echo'0 * * * * ntpdate time1.aliyun.com'>> /var/spool/cron/crontabs/root
或者 可以通過
ansible all-mshell-a"echo? '0 * * * * ntpdate time1.aliyun.com' >> /var/spool/cron/crontabs/root"
關閉 selinux 和防火墻
root@node1:~# sudo ufw status? ##查看狀態
Status: inactive
root@node1:~# sudo ufw disable
Firewall stopped and disabled on system startup##禁用
root@node1:~#
配置域名解析或通過 DNS 解析
root@node1:~# cat /etc/hosts
127.0.0.1 localhost
root@node1:~# hostnamectl set-hostname 對應的名稱
## 以下是新增的 可以按照自己的習慣配置
192.168.106.101? node1
192.168.106.102? node2
192.168.106.103? node3
安裝python
root@node1:~# apt install python? ##python2
源修改成國內源? -- 具體步驟自行百度
/ceph/#清華大學鏡像源
ceph用到的端口 (防火墻和安全中記得放開)
Ceph Monitor：啟用 Ceph MON 服務或端口 6789 (TCP)。
Ceph OSD 或元數據服務器：啟用 Ceph OSD/MDS 服務或端口 6800-7300 (TCP)。
iSCSI 網關：打開端口 3260 (TCP)。
對象網關：打開對象網關通訊所用的端口。此端口在 /etc/ceph.conf 內以 rgw frontends = 開頭的行中設置。HTTP 的默認端口為 80，HTTPS (TCP) 的默認端口為 443。
NFS Ganesha：默認情況下，NFS Ganesha 使用端口 2049（NFS 服務、TCP）和 875 （rquota 支持、TCP）。
SSH：打開端口 22 (TCP)。
NTP：打開端口 123 (UDP)。
2.搭建ceph集群
安裝cephadm
root@node1:~#? wget /ceph/ceph/raw/pacific/src/cephadm/cephadm ## node1 管理節點上執行
root@node1:~#? chmod +x cephadm
root@node1:~# ./cephadm add-repo --release pacific? ##設置要安裝的版本
root@node1:~#? which cephadm ? ##確認是否安裝成功
初始化集群
root@node1:~# cephadm bootstrap --mon-ip 192.168.106.101 ? ##ceph集群第壹個節點的ip
初始化完了以後就可以訪問dashboard了 地址 ： mon -y
node1初始化集群的節點操作
root@node1:~#? scp /etc/ceph/ceph.client.admin.keyring user@node4:/etc/ceph
##? 集群之外的clinet或者測試節點執行
root@node4:~#? mount -t ceph node1:/ /mnt/testfs -o name=admin,secret=AQAoJjBh7OPVNhAAQZyzLhDfgSj+KPmeU5RVlA==,fs=testfs ?
root@node4:~#? mount -t ceph node2:/ /mnt/cephfs -o name=admin,secret=AQAoJjBh7OPVNhAAQZyzLhDfgSj+KPmeU5RVlA==,fs=testfs
root@node4:~#? df -h
Filesystem Size? Used Avail Use% Mounted on
udev1.4G01.4G0% /dev
tmpfs ? 293M1.2M? 292M1% /run
....
192.168.106.101:/ ? 18G 1000M ? 17G6% /mnt/testfs
192.168.106.102:/ ? 18G 1000M ? 17G6% /mnt/cephfs
root@node4:~#? cd /mnt/cephfs
root@node4:/mnt/cephfs#? dd if=/dev/zero of=test bs=1M count=100 ##生成文件
這時候文件是直接寫在ceph集群上看了， 可以通過dashboard觀察?。