1. Ceph高可用部署和主要組件介紹
本教程用官網最近的cephadm來搭建ceph集群。
第一周作業: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
源修改成國內源 -- 具體步驟自行網路
https://mirrors.aliyun.com/ceph/#阿里雲鏡像倉庫
http://mirrors.163.com/ceph/#網易鏡像倉庫
https://mirrors.tuna.tsinghua.e.cn/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 https://github.com/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了 地址 : https://node1:8443/#/dashboard 訪問用戶密碼上一步生成
添加其他節點和其他組件
root@node1:~# ssh-keygen
## 配置免密通信
root@node1:~# ssh--id -f -i /etc/ceph/ceph.pub root@node2
root@node1:~# ssh--id -f -i /etc/ceph/ceph.pub root@node3
## 添加node
root@node1:~# ceph orch host add node2 192.168.106.102
root@node1:~# ceph orch host add node3 192.168.106.103
## 添加osd
root@node1:~# ceph orch daemon add osd node1:/dev/sdb
root@node1:~# ceph orch daemon add osd node1:/dev/sdb
root@node1:~# ceph orch daemon add osd node3:/dev/sdb
測試
root@node1:~# ceph fs volume create testfs ##添加測試fs
root@node1:~# ceph orch apply mds testfs --placement="3" ##設置備份數
root@node1:~# ceph orch daemon add mds testfs node1
root@node1:~# ceph mds stat
## 在集群之外的或者任意機器上操作
root@node4:~# apt install ceph-common -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觀察👀。
2. 塊儲存,對象存儲,文件存儲的區別和聯系
通常來講,磁碟陣列都是基於Block塊的存儲,而所有的NAS產品都是文件級存儲。
1. 塊存儲:DAS SAN
a) DAS(Direct Attach Storage): 是直接連接於主機伺服器的一種存儲方式,每台伺服器有獨立的存儲設備,每台主機伺服器的存儲設備無法互通,需要跨主機存取資料室,必須經過相對復雜的設定,若主機分屬不同的操作系統,則更復雜。
應用:單一網路環境下且數據交換量不大,性能要求不高的環境,技術實現較早。
b) SAN(Storage Area Network): 是一種高速(光纖)網路聯接專業主機伺服器的一種存儲方式,此系統會位於主機群的後端,它使用高速I/O聯接方式,如:SCSI,ESCON及Fibre-Channels.特點是,代價高、性能好。但是由於SAN系統的價格較高,且可擴展性較差,已不能滿足成千上萬個CPU規模的系統。
應用:對網速要求高、對數據可靠性和安全性要求高、對數據共享的性能要求高的應用環境中。
2. 文件存儲
通常NAS產品都是文件級存儲。
NAS(Network Attached Storage):是一套網路存儲設備,通常直接連在網路上並提供資料存取服務,一套NAS儲存設備就如同一個提供數據文件服務的系統,特點是性價比高。
它採用NFS或CIFS命令集訪問數據,以文件為傳輸協議,可擴展性好、價格便宜、用戶易管理。目前在集群計算中應用較多的NFS文件系統,但由於NAS的協議開銷高、帶寬低、延遲大,不利於在高性能集群中應用。
3. 對象存儲:
總體上講,對象存儲同時兼具SAN高級直接訪問磁碟特點及NAS的分布式共享特點。
核心是將數據通路(數據讀或寫)和控制通路(元數據)分離,並且基於對象存儲設備(OSD),構建存儲系統,每個對象存儲設備具備一定的職能,能夠自動管理其上的數據分布。
對象儲存結構組成部分(對象、對象存儲設備、元數據伺服器、對象存儲系統的客戶端)
3.1 對象
一個對象實際就是文件的數據和一組屬性信息的組合。
3.2 對象存儲設備(OSD)
OSD具有一定的智能,它有自己的CPU、內存、網路和磁碟系統。
OSD提供三個主要功能:包括數據存儲和安全訪問
(1)數據存儲 (2)智能分布 (3)每個對象元數據的管理
3.3 元數據伺服器(Metadata Server , MDS)
MDS控制Client與OSD對象的交互,主要提供以下幾個功能:
(1) 對象存儲訪問
允許Client直接訪問對象,OSD接收到請求時先驗證該能力,再訪問。
(2) 文件和目錄訪問管理
MDS在存儲系統上構建一個文件結構,限額控制、包括目錄、文件的創建、訪問控制等
(3) Client Cache 一致性
為提高性能,在對象存儲系統設計時通常支持Client的Cache。因此帶來了Cache一致性的問題,當Cache文件發生改變時,將通知Client刷新Cache,以防Cache不一致引發的問題。
對象存儲:
一個文件包含了屬性(術語叫matadata元數據,例如該文件的大小、修改時間、存儲路徑等)以及內容(簡稱數據)。
以往的文件系統,存儲過程將文件按文件系統的最小塊來打散,再寫進硬碟,過程中沒有區分元數據(metadata)和數據。而在每個塊最後才會告知下一個塊的地址,因此只能一個一個讀,速度慢。
而對象存儲則將元數據獨立出來,控制節點叫元數據伺服器(伺服器+對象存儲管理軟體),裡面主要存儲對象的屬性(主要是對象的數據被打散存放到了那幾台分布式伺服器中的信息),而其他負責存儲數據的分布式伺服器叫做OSD,主要負責存儲文件的數據部分。當用戶訪問對象時,會先訪問元數據伺服器,元數據伺服器只負責反饋對象存儲在那些OSD。假設反饋文件A存儲在B,C,D三台OSD,那麼用戶就會再次訪問三台OSD伺服器去讀取數據。
這時三台OSD同時對外傳輸數據,因此傳輸的速度就加快了。OSD伺服器數量越多,這種讀寫速度的提升就越大。
另一方面,對象存儲軟體有專門的文件系統,所以OSD對外又相當於文件伺服器,那麼就不存在文件共享方面的困難了,也解決了文件共享方面的問題。
因此對象存儲的出現,很好的結合了塊存儲與文件存儲的優點。
為什麼還要使用塊存儲和文件存儲:
1.有一類應用是需要存儲直接裸盤映射的,比如資料庫。因為資料庫需要存儲裸盤映射給自己後,再根據自己的資料庫文件系統來對了裸盤進行格式化,因此不能採用其他已經被格式化為某種文件系統的存儲。此類更適合塊存儲。
2.對象存儲的成本比普通的文件存儲還是較高,需要購買專門的對象存儲軟體以及大容量硬碟。如果對數據量要求不是海量,只是為了作文件共享的時候,直接用文件存儲的形式就好了,性價比高。
3. 信息以文件形式存儲,文件用什麼分類分層存放
文件、塊和對象是三種以不同的方式來保存、整理和呈現數據的存儲格式。這些格式各有各的功能和限制。文件存儲會以文件和文件夾的層次結構來整理和呈現數據;塊存儲會將數據拆分到任意劃分且大小相同的卷中; 對象存儲會管理數據並將其鏈接至關聯的元數據。
塊存儲
塊存儲會將數據拆分成塊,並單獨存儲各個塊。每個數據塊都有一個唯一標識符,所以存儲系統能將較小的數據存放在最方便的位置。這意味著有些數據可以存儲在 Linux 環境中,有些則可以存儲在 Windows 單元中。
塊存儲通常會被配置為將數據與用戶環境分離,並會將數據分布到可以更好地為其提供服務的多個環境中。然後,當用戶請求數據時,底層存儲軟體會重新組裝來自這些環境的數據塊,並將它們呈現給用戶。它通常會部署在存儲區域網路 (SAN) 環境中,而且必須綁定到正常運行的伺服器。
由於塊存儲不依賴於單條數據路徑(和文件存儲一樣),因此可以實現快速檢索。每個塊都獨立存在,且可進行分區,因此可以通過不同的操作系統進行訪問,這使得用戶可以完全自由地配置數據。它是一種高效可靠的數據存儲方式,且易於使用和管理。它適用於要執行大型事務的企業和部署了大型資料庫的企業。這意味著,需要存儲的數據越多,就越適合使用塊存儲。
塊存儲有一些缺點。塊存儲的成本高昂。它處理元數據的能力有限。
操作對象:磁碟
存儲協議:SCSI、iSCSI、FC
介面命令:以SCSI為例,主要有Read/Write/Read Capacity
存儲架構:DAS、SAN
文件存儲
文件存儲也稱為文件級存儲或基於文件的存儲,數據會以單條信息的形式存儲在文件夾中。當需要訪問該數據時,計算機需要知道相應的查找路徑。存儲在文件中的數據會根據元數據來進行整理和檢索,這些元數據會告訴計算機文件所在的確切位置。
請試想一下塞滿文件櫃的儲藏室。每個文檔都會按照某種類型的邏輯層次結構來排放 ——按文件櫃、抽屜、文件夾,然後再是紙張。「分層存儲」這個術語就是這么來的,而這就是文件存儲。它是適用於直接和網路附加存儲(NAS)系統的最古老且運用最為廣泛的一種數據存儲系統;當訪問保存在個人計算機上的文件中的文檔,就是在使用文件存儲。文件存儲具有豐富多樣的功能,幾乎可以存儲任何內容。它非常適合用來存儲一系列復雜文件,並且有助於用戶快速導航。
問題是基於文件的存儲系統必須通過添置更多系統來進行橫向擴展,而不是通過增添更多容量來進行縱向擴展。
操作對象:文件和文件夾
存儲協議:NFS、SAMBA(SMB)、POSIX
介面命令:以NFS為例,文件相關的介面命令包括:READ/WRITE/CREATE/REMOVE/RENAME/LOOKUP/ACCESS 等;文件夾相關的介面命令包括:MKDIR/RMDIR/READDIR 等
存儲架構:NAS (【Linux】NAS存儲_Jacky_Feng的博客-CSDN博客)
對象存儲
對象存儲,也稱為基於對象的存儲,是一種扁平結構,其中的文件被拆分成多個部分並散布在多個硬體間。在對象存儲中,數據會被分解為稱為「對象」的離散單元,並保存在單個存儲庫中,而不是作為文件夾中的文件或伺服器上的塊來保存。
對象存儲卷會作為模塊化單元來工作:每個卷都是一個自包含式存儲庫,均含有數據、允許在分布式系統上找到對象的唯一標識符以及描述數據的元數據。元數據包括年齡、隱私/安全信息和訪問突發事件等詳細信息。為了檢索數據,存儲操作系統會使用元數據和標識符,這樣可以更好地分配負載,並允許管理員應用策略來執行更強大的搜索。
對象存儲需要一個簡單的 HTTP 應用編程介面 (API),以供大多數客戶端(各種語言)使用。對象存儲經濟高效:您只需為已用的內容付費。它可以輕松擴展,因而是公共雲存儲的理想之選。它是一個非常適用於靜態數據的存儲系統,其靈活性和扁平性意味著它可以通過擴展來存儲極大量的數據。對象具有足夠的信息供應用快速查找數據,並且擅長存儲非結構化數據。
它的缺點是無法修改對象 ,即必須一次性完整地寫入對象。對象存儲也不能很好地與傳統資料庫搭配使用,因為編寫對象是一個緩慢的過程,編寫應用以使用對象存儲 API 並不像使用文件存儲那麼簡單。
操作對象:對象(Object)
存儲協議:S3、Swift
介面命令:主要有PUT/GET/DELETE等
存儲架構:去中心化框架
對象存儲概念
對象存儲的數據組成
存儲桶(Bucket):存放對象的「容器」,且該「容器」無容量上限。對象以扁平化結構存放在存儲桶中,無文件夾和目錄的概念,用戶可選擇將對象存放到單個或多個存儲桶中。存儲桶的容量大小需要通過累加各個對象的大小得到。
每個存儲桶可容納任意數量的對象,但同一個主賬號下存儲桶數量最多僅能夠創建200個。(???)
對於存儲桶,應當以用途為粒度進行劃分,確保每個存儲桶的用途盡可能單一。例如,針對存放個人文件、發布靜態網站、存儲備份等用途都應該創建不同的存儲桶。此外,不同項目的數據、不同的網站,或者完全私人的文件與工作性質、需要分享的文件,也應該劃分不同的存儲桶。
對象存儲中也沒有「文件夾」的概念。對象存儲的管理平台為了模仿本地存儲的使用習慣,並與本地存儲系統互相兼容而模擬了目錄結構,背後的原理也僅僅是根據 / 這個字元對 key 進行分隔。為了表示空目錄,部分雲平台也提供「文件夾」對象,實際上只是 key 以 / 結尾的空存儲對象。
存儲桶所在地域(Regin)
指對象存儲的數據中心所在地域。對象存儲允許用戶在不同地域創建存儲桶,可以選擇在離業務最近的地域上創建存儲桶,以滿足低延遲、低成本以及合規性要求。
Bucket讀寫許可權
Bucket讀寫許可權包括:私有讀寫、公有讀私有寫和公有讀寫。
私有讀寫
只有該存儲桶的創建者及有授權的賬號才對該存儲桶中的對象有讀寫許可權,其他任何人對該存儲桶中的對象都沒有讀寫許可權。存儲桶訪問許可權默認為私有讀寫,推薦使用。
公有讀私有寫
任何人(包括匿名訪問者)都對該存儲桶中的對象有讀許可權,但只有存儲桶創建者及有授權的賬號才對該存儲桶中的對象有寫許可權。
公有讀寫
任何人(包括匿名訪問者)都對該存儲桶中的對象有讀許可權和寫許可權,不推薦使用。
對象(Object):對象存儲的基本單元,可理解為任何格式類型的數據,例如圖片、文檔和音視頻文件等。
每個對象都由對象鍵(Key)、對象值(Data)、和對象元數據(Metadata)組成。
對象鍵(Key):對象鍵是對象在存儲桶中的全局唯一標識(UID),可以理解為文件(名)路徑。
key用於檢索對象,文件對象的 key 與實際存儲路徑無關,伺服器和用戶不需要知道數據的物理地址,通過key就能找到對象。
對象值(Data):即存儲對象內容數據,可以理解為文件內容(Object Content)。
對象元數據(Metadata):是一組鍵值對,可以通俗的理解為文件的屬性,例如文件的修改時間、存儲類型等。(傳統的文件存儲,元數據屬於文件本身,和文件一起封裝存儲。而對象存儲,元數據獨立出來,並不在數據內部封裝。)
對象訪問地址
對象的訪問地址由存儲桶訪問地址和對象鍵組成,其結構形式為<存儲桶域名>/<對象鍵> 。
例如:上傳對象exampleobject.txt到廣州(華南)的存儲桶examplebucket-1250000000中,那麼exampleobject.txt的訪問地址是:examplebucket-1250000000.cos.ap-guangzhou.myqcloud.com/exampleobject.txt。其中examplebucket-1250000000.cos.ap-guangzhou.myqcloud.com為存儲桶域名,exampleobject.txt為對象鍵。
目錄和文件夾
對象存儲中本身是沒有文件夾和目錄的概念的,對象存儲不會因為上傳對象project/a.txt而創建一個project文件夾。為了滿足用戶使用習慣,對象存儲在控制台、COS browser 等圖形化工具中模擬了「文件夾」或「目錄」的展示方式,具體實現是通過創建一個鍵值為project/,內容為空的對象,展示方式上模擬了傳統文件夾。
對象操作
用戶通過控制台、工具、API、SDK等多種方式管理對象。
對象存儲架構
對象存儲設備(OSD)
OSD由存儲介質、處理器、內存以及網路系統等組成,負責管理本地的對象,是對象存儲系統的核心。和塊設備相比,它們的差異在於提供的訪問介面。OSD的主要功能是數據存儲和安全訪問。
數據存儲:OSD管理對象數據,並將它們放置在標準的磁碟系統上,OSD不提供塊介面訪問方式,Client請求數據時用對象ID、偏移進行數據讀寫。
智能分布:OSD用其自身的CPU和內存優化數據分布,並支持數據的預取。由於OSD可以智能地支持對象的預取,從而可以優化磁碟的性能。
對象元數據管理:OSD管理存儲的對象元數據與傳統的inode元數據相似,通常包括對象的數據塊和對象的長度。而在傳統的NAS系統中,這些元數據是由文件伺服器維護的,對象存儲架構將系統中主要的元數據管理工作由OSD來完成,降低了Client的開銷。
元數據伺服器(MDS)
MDS控制Client與OSD對象的交互,為客戶端提供元數據,主要是文件的邏輯視圖(文件與目錄的組織關系、每個文件所對應的OSD等)。主要功能如下:
對象存儲訪問:MDS構造和管理描述每個文件分布的邏輯視圖,允許Client直接訪問對象。MDS為Client提供訪問該文件所含對象的能力,OSD在接收到每個請求時將先驗證該能力,然後才可以訪問。
文件和目錄訪問管理:MDS在存儲系統上構建一個文件結構,包括限額控制、目錄和文件的創建和刪除、訪問控制等。
Client Cache一致性:為了提高Client性能,在對象存儲系統設計時通常支持Client方的Cache。由於引入Client方的Cache,帶來了Cache一致性問題,MDS支持基於Client的文件Cache,當Cache的文件發生改變時,將通知Client刷新Cache,從而防止Cache不一致引發的問題。
客戶端(Client)
對象存儲系統提供給用戶的也是標準的POSIX文件訪問介面。介面具有和通用文件系統相同的訪問方式,同時為了提高性能,也具有對數據的Cache功能和文件的條帶功能。同時,文件系統必須維護不同客戶端上Cache的一致性,保證文件系統的數據一致。
文件系統讀訪問流程:
① 客戶端應用發出讀請求;
② 文件系統向元數據伺服器發送請求,獲取要讀取的數據所在的OSD;
③ 直接向每個OSD發送數據讀取請求;
④ OSD得到請求以後,判斷要讀取的Object,並根據此Object要求的認證方式,對客戶端進行認證,如果此客戶端得到授權,則將Object的數據返回給客戶端;
⑤ 文件系統收到OSD返回的數據以後,讀操作完成。
對象存儲的優缺點
(1)優點:
容量大,高擴展性
對象存儲的容量是EB級以上,對象存儲的所有業務、存儲節點採用分布式集群方式工作,各功能節點、集群都可以獨立擴容。從理論上來說,某個對象存儲系統或單個桶(bucket),並沒有總數據容量和對象數量的限制,即服務商就可以不停地往架構里增加資源,這個存儲空間就是無限的,也是支持彈性伸縮的。
高安全性,可靠性
對象存儲採用了分布式架構,對數據進行多設備冗餘存儲(至少三個以上節點),實現異地容災和資源隔離。數據訪問方面,所有的桶和對象都有訪問控制策略,所有連接都支持SSL加密,訪問用戶進行身份許可權鑒定。
高性能,支持海量用戶的並發訪問
(2)缺點:
不支持直接在存儲上修改
對象存儲系統保存的Object不支持修改(追加寫Object需要調用特定的介面,生成的Object也和正常上傳的Object類型上有差別)。用戶哪怕是僅僅需要修改一個位元組也需要重新上傳整個Object。因此,它不適合存儲需要頻繁擦寫的數據。
參考鏈接:
對象存儲,為什麼那麼火? - 知乎 (hu.com)
對象存儲 存儲桶概述 - 開發者指南 - 文檔中心 - 騰訊雲 (tencent.com)
基本概念 (aliyun.com)
文件存儲、塊存儲還是對象存儲? (redhat.com)
linux
駐馬店市民請關注領取補貼!
巨魔-抽手機公告
廣告
對比塊存儲、文件存儲、對象存儲
1242閱讀·0評論·3點贊
2019年2月27日
ShapeFile的文件格式設計
90閱讀·0評論·0點贊
2009年3月20日
應用ceph對象存儲(ceph-13.2.10)
72閱讀·0評論·0點贊
2022年11月26日
三種存儲類型比較-文件、塊、對象存儲
4.8W閱讀·0評論·13點贊
2016年7月26日
常見圖片存儲格式文件簡介
4534閱讀·0評論·0點贊
2020年5月4日
s3cmd常用命令
781閱讀·0評論·0點贊
2022年11月17日
駐馬店發布,你有一台5G手機待領取
00:23
巨摩互動
廣告
常見的存儲格式
1083閱讀·0評論·0點贊
2022年2月15日
文件、對象、塊區別
1399閱讀·0評論·0點贊
2020年7月13日
對象存儲、文件存儲、塊存儲的區別和聯系
7330閱讀·2評論·5點贊
2021年10月16日
數據分析中常見的存儲方式
1537閱讀·0評論·0點贊
2021年11月16日
三種存儲類型:塊存儲、文件存儲、對象存儲
1.5W閱讀·3評論·55點贊
2020年11月2日
如何設計二進制文件格式
1940閱讀·0評論·1點贊
2020年3月6日
BMP文件存儲格式
472閱讀·0評論·2點贊
2021年8月2日
hive 的存儲格式
1765閱讀·0評論·1點贊
2022年6月18日
數據存儲格式
446閱讀·0評論·0點贊
2022年12月21日
總結:對象存儲、塊存儲、文件存儲的區別
6606閱讀·0評論·3點贊
2022年4月9日
c語言中文件rw,什麼是「塊文件」?
386閱讀·0評論·0點贊
2021年5月23日
【存儲】塊存儲、文件存儲和對象存儲的區別?
350閱讀·0評論·0點贊
2022年7月22日
塊存儲、文件存儲與對象存儲的區別與應用場景
1846閱讀·1評論·0點贊
2022年6月5日
數據在內存中的存儲方式
272閱讀·0評論·0點贊
2022年8月21日
去首頁
看看更多熱門內容
4. mds文件用什麼打開 MDS是什麼文件
這是一種虛擬光碟機格式,推薦使用DAEMON Tools打開直接可以刻錄,也可以使用虛擬光碟機軟體Alcohol 120% Manual、DAEMOM,UltraISO、PowerISO、酒精Alcohol或其它虛擬光碟機軟體運行。
MDS:是鏡像文件的一種,mds和mdf文件一定是一起的,mds文件的容量較小,mdf文件的容量較大,數據都存放在這個文件內。平時應該把他們存放在一個文件夾內。但是,當把它們裝載入虛擬光碟機或把它們復制到Alcohol的文件列表以後,它們就合二為一了。只以mds文件的名稱出現。mds文件和mdf文件統稱mds文件。
(4)mds元數據伺服器是什麼擴展閱讀:
mds文件是鏡像文件的一種,mds和mdf文件一定是一起的,mds文件的容量較小,mdf文件的容量較大,數據都存放在這個文件內。平時應該把他們存放在一個文件夾內。
但是,當把它們裝載入虛擬光碟機或把它們復制到Alcohol的文件列表以後,它們就合二為一了。只以mds文件的名稱出現。mds文件和mdf文件統稱mds文件。
它最重要的特點是可以被特定的軟體識別並可直接刻錄到光碟上。其實通常意義上的鏡像文件可以再擴展一下,在鏡像文件中可以包含更多的信息。
5. Ceph 架構與原理
Ceph 是一個開源項目,它提供軟體定義的、統一的存儲解決方案 。Ceph 是一個具有高性能、高度可伸縮性、可大規模擴展並且無單點故障的分布式存儲系統 。
Ceph 是軟體定義存儲解決方案
Ceph 是統一存儲解決方案
Ceph 是雲存儲解決方案
高可用性
高擴展性
特性豐富
Ceph獨一無二地統一的系統提供了對象存儲、塊存儲和文件存儲功能。Ceph存儲集群由幾個不同的軟體守護進程組成(比較重要的兩個是MON和OSD),每個守護進程負責Ceph的一個獨特功能並將值添加到相應的組件中。
RADOS是CEPH存儲系統的核心,也稱為Ceph 存儲集群。Ceph的數據訪問方法(如RBD,CephFS,RADOSGW,librados)的所有操作都是在RADOS層之上構建的。當Ceph 集群接收到來自客戶端的請求時,CRUSH演算法首先計算出存儲位置,最後將這些對象存儲在OSD中,當配置的復制數大於1時,RADOS負責的形式將數據分發到集群內的所有節點,最後將這些對象存儲在OSD中。當配置的復制數大於1時,RADOS負責數據的可靠性,它復制對象,創建副本並將它們存儲在不同的故障區域中。
RADOS包含兩個核心組件: OSD和MON
OSD 是Ceph 存儲集群中最重要的一個基礎組件,他負責將實際的數據以對象的形式存儲在每一個集群節點的物理磁碟中。對於任何讀寫操作,客戶端首先向MON請求集群MAP,然後客戶端舊可以直接和OSD進行I/O操作。
一個Ceph 集群包含多個OSD。一個典型的Ceph集群方案會為集群節點上的每個物理磁碟創建一個ODS守護進程,這個是推薦的做法。OSD上的每個對象都有一個主副本和幾個輔副本,輔副本分散在其他OSD。一個OSD對於一些對象是主副本,同時對於其他對象可能是輔副本,存放輔副本的OSD主副本OSD控制,如果主副本OSD異常(或者對應的磁碟故障),輔副本OSD可以成為主副本OSD。
OSD是有一個已經存在的Linux文件系統的物理磁碟驅動器和OSD服務組成。Ceph 推薦OSD使用的文件系統是XFS。OSD的所有寫都是先存到日誌,再到存儲.
MON 負責監控整個集群的健康狀況。它以守護進程的形式存在,一個MON為每一個組件維護一個獨立的MAP,如OSD,MON,PG,CRUSH 和MDS map。這些map 統稱為集群的MAP。MON 不為客戶端存儲和提供數據,它為客戶端以及集群內其他節點提供更新集群MAP的服務。客戶端和集群內其他節點定期與MON確認自己持有的是否是集群最新的MAP.一個Ceph集群通常包含多個MON節點,但是同一時間只有一個MON。
librados是一個本地的C語言庫,通過它應用程序可以直接和RADOS通信,提高性能
Ceph 塊存儲,簡稱 RBD,是基於 librados 之上的塊存儲服務介面。RBD 的驅動程序已經被集成到 Linux 內核(2.6.39 或更高版本)中,也已經被 QEMU/KVM Hypervisor 支持,它們都能夠無縫地訪問 Ceph 塊設備。Linux 內核 RBD(KRBD)通過 librados 映射 Ceph 塊設備,然後 RADOS 將 Ceph 塊設備的數據對象以分布式的方式存儲在集群節點中
RGW,Ceph對象網關,也稱做RADOS網關,它是一個代理,可以將HTTP請求轉換為RADOS,也可以把RADOS轉換為HTTP請求,從而提供restful介面,兼容S3和Swift。Ceph對象網關使用Ceph對象網關守護進程(RGW)與librgw、librados交互。Ceph對象網關支持三類介面:S3、Swift、管理API(通過restful介面管理Ceph集群)。RGW有自己的用戶管理體系
Ceph 元數據伺服器服務進程,簡稱 MDS。只有在啟用了 Ceph 文件存儲(CephFS)的集群中才需要啟用 MDS,它負責跟蹤文件層次結構,存儲和管理 CephFS 的元數據。MDS 的元數據也是以 Obejct 的形式存儲在 OSD 上。除此之外,MDS 提供了一個帶智能緩存層的共享型連續文件系統,可以大大減少 OSD 讀寫操作頻率。
CephFS在RADOS層之上提供了一個兼容POSIX的文件系統。它使用MDS作為守護進程,負責管理其元數據並將它和其他數據分開。CephFS使用cephfuse模塊(FUSE)擴展其在用戶空間文件系統方面的支持(就是將CephFS掛載到客戶端機器上)。它還允許直接與應用程序交互,使用libcephfs庫直接訪問RADOS集群。
Ceph管理器軟體,可以收集整個集群的所有狀態。有儀錶板插件
一個對象通常包含綁定在一起的數據和元數據,並且用一個全局唯一的標識符標識。這個唯一的標識符確保在整個存儲集群中沒有其他對象使用相同的對象ID,保證對象唯一性。基於文件的存儲中,文件大小是有限制的,與此不同的是,對象的大小是可以隨著大小可變的元數據而變得很大。對象不使用一個目錄層次結構或樹結構來存儲,相反,它存儲在一個包含數十億對象且沒有任何復雜性的線性地址空間中。對象可以存儲在本地,也可以存放在地理上分開的線性地址空間中,也就是說,在一個連續的存儲空間中。任何應用程序都可以基於對象ID通過調用restful API從對象中獲取數據。這個URL可以以同樣的方式工作在網際網路上,一個對象ID作為一個唯一的指針指向對象。這些對象都以復制的方式存儲在OSD中,因為能提供高可用性。
對於Ceph集群的一次讀寫操作,客戶端首先聯系MON獲取一個集群map副本,然後使用對象和池名/ID將數據轉換為對象。接著將對象和PG數一起經過散列來生成其在Ceph池中最終存放的那一個PG。然後前面計算好的PG經過CRUSH查找來確定存儲或獲取數據所需的主OSD的位置。得到准確的OSD ID之後,客戶端直接聯系這個OSD來存取數據。所有這些計算操作都由客戶端來執行,因此它不會影響Ceph集群的性能。一旦數據被寫入主OSD,主OSD所在節點將執行CRUSH查找輔助PG和OSD的位置來實現數據復制,進而實現高可用。
簡單地說,首先基於池ID將對象名和集群PG數應用散列函數得到一個PG ID,然後,針對這個PG ID執行CRUSH查找得到主OSD和輔助OSD,最後寫入數據。
PG是一組對象地邏輯集合,通過復制它到不同的OSD上來提供存儲系統的可靠性。根據Ceph池的復制級別,每個PG的數據會被復制並分發到Ceph集群的多個OSD上。可以將PG看成一個邏輯容器,這個容器包含多個對象,同時這個邏輯容器被映射到多個OSD。
計算正確的PG數對一個Ceph存儲集群來說是至關重要的一步。PG數計算公式如下
Ceph池是一個用來存儲對象的邏輯分區,每個池都包含一定數量的PG,進而實現把一定數量的對象映射到集群內部不同OSD上的目的。每一個池都是交叉分布在集群所有節點上的,這樣就能提供足夠的彈性。池可以通過創建需要的副本數來保障數據的高可用性。
Ceph的池還支持快照功能,我們可以使用ceph osd pool mksnap命令來給特定的池製作快照。此外,Ceph池還允許我們為對象設置所有者和訪問許可權。
數據管理始於客戶端向Ceph池中寫數據。一旦客戶端准備寫數據到Ceph池中,數據首先寫入基於池副本數的主OSD中。主OSD再復制相同的數據到每個輔助OSD中,並等待它們確認寫入完成。只要輔助OSD完成數據寫入,就會發送一個應答信號給主OSD。最後主OSD再返回一個應答信號給客戶端,以確認完成整個寫入操作。
6. 對象存儲系統的對象存儲系統組成
對象(Object)
包含了文件數據以及相關的屬性信息,可以進行自我管理
OSD(Object-based Storage Device)
一個智能設備,是Object的集合
文件系統
文件系統運行在客戶端上,將應用程序的文件系統請求傳輸到MDS和OSD上
元數據伺服器(Metadata Server,MDS)
系統提供元數據、Cache一致性等服務
網路連接
1. 對象(Object)
對象存儲的基本單元。每個Object是數據和數據屬性集的綜合體。數據屬性可以根據應用的需求進行設置,包括數據分布、服務質量等。在傳統的存儲中,塊設備要記錄每個存儲數據塊在設備上的位置。Object維護自己的屬性,從而簡化了存儲系統的管理任務,增加了靈活性。Object的大小可以不同,可以包含整個數據結構,如文件、資料庫表項等。
2、OSD(Object-based Storage Device)
每個OSD都是一個智能設備,具有自己的存儲介質、處理器、內存以及網路系統等,負責管理本地的Object,是對象存儲系統的核心。OSD同塊設備的不同不在於存儲介質,而在於兩者提供的訪問介面。
OSD的主要功能
數據存儲和安全訪問
OSD使用Object對所保存的數據進行管理。它將數據存放到磁碟的磁軌和扇區,將若干磁軌和扇區組合起來構成Object,並且通過此Object向外界提供對數據的訪問。每個Object同傳統的文件相似,使用同文件類似的訪問介面,包括Open、Read、Write等。但是兩者並不相同,每個Object可能包括若干個文件,也可能是某個文件的一部分,且是獨立於操作系統的。除了具體的用戶數據外,OSD還記錄了每個Object的屬性信息,主要是物理視圖信息。將這些信息放到OSD上,大大減輕了元數據伺服器的負擔,增強了整個存儲系統的並行訪問性能和可擴展性。
3、文件系統
文件系統對用戶的文件操作進行解釋,並在元數據伺服器和OSD間通信,完成所請求的操作。
現有的應用對數據的訪問大部分都是通過POSIX文件方式進行的,對象存儲系統提供給用戶的也是標準的POSIX文件訪問介面。
介面具有和通用文件系統相同的訪問方式,同時為了提高性能,也具有對數據的Cache功能和文件的條帶功能。
同時,文件系統必須維護不同客戶端上Cache的一致性,保證文件系統的數據一致
文件系統讀訪問實例:
客戶端應用發出讀請求;
文件系統向元數據伺服器發送請求,獲取要讀取的數據所在的OSD;
然後直接向每個OSD發送數據讀取請求;
OSD得到請求以後,判斷要讀取的Object,並根據此Object要求的認證方式,對客戶端進行認證,如果此客戶端得到授權,則將Object的數據返回給客戶端;
文件系統收到OSD返回的數據以後,讀操作完成。
4.元數據伺服器 (Metadata Server)
為客戶端提供元數據,主要是文件的邏輯視圖,包括文件與目錄的組織關系、每個文件所對應的OSD等。
在傳統的文件系統中,元數據由本機或者文件伺服器負責維護,每次對數據塊的操作都要獲取元數據。
在對象存儲系統中,由於每次操作只有一次對元數據的訪問,具體的數據傳輸都由OSD和客戶端通過直接連接進行,大大減少了元數據的操作,降低了元數據伺服器的負擔,從而為系統的擴展提供了可能性。
特點
客戶端採用Cache來緩存數據
當多個客戶端同時訪問某些數據時,MDS提供分布的鎖機制來確保Cache的一致性。
5. 網路連接
為客戶端提供認證
為了增強系統的安全性,MDS為客戶端提供認證方式。OSD將依據MDS的認證來決定是否為客戶端提供服務。
網路連接是對象存儲系統的重要組成部分。它將客戶端、MDS和OSD連接起來,構成了一個完整的系統。