簡(jiǎn)介OpenStack與Ceph的分布式存儲(chǔ)集成是當(dāng)前云基礎(chǔ)架構(gòu)中的熱門實(shí)踐這份安裝測(cè)試報(bào)告正是一份面向云計(jì)算運(yùn)維工程師與OpenStack部署實(shí)施人員的完整參考文檔。文件包僅含1個(gè)docx文檔大小876KB但內(nèi)容組織完整既有云計(jì)算與OpenStack的基礎(chǔ)概念也梳理了Ceph的組件、CRUSH映射機(jī)制、強(qiáng)一致性與容錯(cuò)能力并與VMware方案做了對(duì)比可幫助讀者快速建立技術(shù)坐標(biāo)系。報(bào)告還針對(duì)在OpenStack中選擇Ceph作為后端存儲(chǔ)的考量、測(cè)試主機(jī)規(guī)劃以及本地YUM源配置進(jìn)行了說(shuō)明展現(xiàn)出從理論到落地的完整路徑。概念部分細(xì)致解釋了什么是云計(jì)算、OpenStack核心組件以及Ceph的RADOS對(duì)象存儲(chǔ)基礎(chǔ)對(duì)OSD、MON、MDS、RGW等角色也有明確說(shuō)明測(cè)試準(zhǔn)備環(huán)節(jié)可操作性強(qiáng)。目前已有254人學(xué)習(xí)下載適合需要系統(tǒng)了解Ceph集成原理、準(zhǔn)備實(shí)驗(yàn)環(huán)境或進(jìn)行方案選型的技術(shù)人員。1. OpenStack 集成 Ceph 分布式存儲(chǔ)一份能直接照著搭的安裝測(cè)試報(bào)告去年我?guī)鸵粋€(gè)客戶搭私有云計(jì)算節(jié)點(diǎn)本地盤吃緊打算上一套 Ceph 做統(tǒng)一存儲(chǔ)后端。當(dāng)時(shí)網(wǎng)上搜到的博客大多是「OpenStack 裝到一半」或者「Ceph 單節(jié)點(diǎn)演示」真正把控制節(jié)點(diǎn)、計(jì)算節(jié)點(diǎn)、Ceph 集群和 Over Ceph 配置整條鏈路走完的極少。最后是翻到一份 OpenStack Ceph 分布式存儲(chǔ)安裝測(cè)試報(bào)告才把環(huán)境跑通——從本地 YUM 源、keystone/glance/nova/cinder 逐組件安裝到 ceph-deploy 建集群再到讓虛機(jī)跑在 RBD 上每一步都有對(duì)應(yīng)操作和驗(yàn)證方法。這份資源適合三類人做 OpenStack 課程設(shè)計(jì)的學(xué)生、企業(yè)里做存儲(chǔ)選型驗(yàn)證的運(yùn)維、以及想搞明白「Ceph 到底怎么接進(jìn) OpenStack」的云計(jì)算從業(yè)者。它不解決架構(gòu)設(shè)計(jì)問(wèn)題但能讓你少走兩周彎路。2. 環(huán)境準(zhǔn)備主機(jī)規(guī)劃、本地 YUM 源與操作系統(tǒng)基線2.1 主機(jī)規(guī)劃三個(gè)角色的 IP、內(nèi)存與磁盤分配任何 OpenStack 部署翻車十有八九是規(guī)劃階段埋的雷。報(bào)告里的測(cè)試環(huán)境是典型的三類節(jié)點(diǎn)控制節(jié)點(diǎn)、計(jì)算節(jié)點(diǎn)、Ceph 存儲(chǔ)節(jié)點(diǎn)?？刂乒?jié)點(diǎn)要跑 MySQL、keystone、glance、nova、cinder、dashboard 這一整套服務(wù)內(nèi)存建議 8G 起步否則 MySQL 和 nova-api 同時(shí)啟動(dòng)時(shí) swap 會(huì)瘋狂抖動(dòng)。計(jì)算節(jié)點(diǎn)主要跑 nova-compute 和虛擬機(jī)的 vCPU/內(nèi)存CPU 核數(shù)和內(nèi)存按需分配但要注意網(wǎng)卡——nova-network 和虛擬機(jī)流量共用物理網(wǎng)卡時(shí)千兆口很容易成為瓶頸。Ceph 節(jié)點(diǎn)是這份報(bào)告重點(diǎn)關(guān)照的對(duì)象每個(gè)節(jié)點(diǎn)至少要有一塊獨(dú)立的系統(tǒng)盤和數(shù)據(jù)盤數(shù)據(jù)盤不分區(qū)直接給 OSD 用這是我反復(fù)強(qiáng)調(diào)的一點(diǎn)千萬(wàn)別把 OSD 放在和系統(tǒng)同一個(gè)分區(qū)上后面擴(kuò)容和故障替換都難受。IP 規(guī)劃我一般習(xí)慣把管理網(wǎng)、存儲(chǔ)網(wǎng)、業(yè)務(wù)網(wǎng)分開(kāi)就算測(cè)試環(huán)境只有兩三個(gè)網(wǎng)段也要預(yù)留出來(lái)。報(bào)告里的環(huán)境用了獨(dú)立的存儲(chǔ)網(wǎng)段承載 Ceph 的 public network 和 cluster network這個(gè)設(shè)計(jì)在測(cè)試階段也許看不出差別但等到 OSD 做數(shù)據(jù)同步的時(shí)候存儲(chǔ)流量和業(yè)務(wù)流量搶帶寬的場(chǎng)景會(huì)讓你很被動(dòng)。集群規(guī)模不大的情況下這三類節(jié)點(diǎn)可以合并部署但報(bào)告里是分開(kāi)的這更接近生產(chǎn)環(huán)境的形態(tài)復(fù)現(xiàn)價(jià)值也更高。節(jié)點(diǎn)角色建議配置關(guān)鍵服務(wù)備注控制節(jié)點(diǎn)4C8G100G 系統(tǒng)盤MySQL、keystone、glance、nova、cinder、dashboard數(shù)據(jù)庫(kù)和消息隊(duì)列都在這計(jì)算節(jié)點(diǎn)8C16G100G 系統(tǒng)盤nova-compute、nova-network虛機(jī)實(shí)例盤默認(rèn)落在本地接 Ceph 后改為 RBDCeph 節(jié)點(diǎn) ×34C8G100G 系統(tǒng)盤 1T 數(shù)據(jù)盤 ×Nceph-mon、ceph-osd數(shù)據(jù)盤不分區(qū)直接給 OSD2.2 本地 YUM 源createrepo 建倉(cāng)庫(kù)與客戶端指向沒(méi)有外網(wǎng)的環(huán)境里YUM 源是第一個(gè)卡點(diǎn)也是這份報(bào)告做得比較扎實(shí)的部分。它把 CentOS 基礎(chǔ)包、OpenStack 相關(guān) RPM 包和依賴包全部下載到一臺(tái)服務(wù)器上用 createrepo 工具生成倉(cāng)庫(kù)元數(shù)據(jù)再通過(guò) HTTP 發(fā)布。這個(gè)方法看起來(lái)樸素但非常實(shí)用——測(cè)試環(huán)境裝到一半因?yàn)槟硞€(gè)依賴包拉不下來(lái)而中斷是最浪費(fèi)時(shí)間的翻車方式。先裝 createrepo 并創(chuàng)建倉(cāng)庫(kù)。下載好的 RPM 包按目錄歸類比如base、openstack、ceph分別放然后在每個(gè)目錄下執(zhí)行 createrepo 生成元數(shù)據(jù)# 安裝 createrepo 工具 yum install -y createrepo httpd # 創(chuàng)建 RPM 包存放目錄按組件分類 mkdir -p /var/www/html/yum/base mkdir -p /var/www/html/yum/openstack mkdir -p /var/www/html/yum/ceph # 把提前下載好的 RPM 包拷貝進(jìn)對(duì)應(yīng)目錄后執(zhí)行倉(cāng)庫(kù)初始化 createrepo --update /var/www/html/yum/base createrepo --update /var/www/html/yum/openstack createrepo --update /var/www/html/yum/ceph # 啟動(dòng) httpd 并設(shè)置開(kāi)機(jī)自啟 systemctl start httpd systemctl enable httpd--update參數(shù)很關(guān)鍵它會(huì)在已有倉(cāng)庫(kù)基礎(chǔ)上增量更新元數(shù)據(jù)而不是重建。如果有新增的 RPM 包放進(jìn)目錄只需再跑一次帶--update的 createrepo 就行。做完這一步用瀏覽器訪問(wèn)http://YUM服務(wù)器IP/yum/能看到目錄列表就說(shuō)明發(fā)布成功?？蛻舳伺渲弥赶蜻@個(gè)本地源。在/etc/yum.repos.d/下新建一個(gè)local.repo把原有的網(wǎng)絡(luò)源臨時(shí)禁用避免裝到一半 source 漂移cat /etc/yum.repos.d/local.repo EOF [base] nameLocal Base Repository baseurlhttp://192.168.1.10/yum/base enabled1 gpgcheck0 [openstack] nameOpenStack Repository baseurlhttp://192.168.1.10/yum/openstack enabled1 gpgcheck0 [ceph] nameCeph Repository baseurlhttp://192.168.1.10/yum/ceph enabled1 gpgcheck0 EOF # 清理緩存并驗(yàn)證倉(cāng)庫(kù)可用性 yum clean all yum repolistgpgcheck0在離線環(huán)境是常規(guī)操作因?yàn)槟阋礇](méi)有對(duì)應(yīng)的 GPG 公鑰要么下載時(shí)已經(jīng)校驗(yàn)過(guò)完整性。最后一條yum repolist一定要執(zhí)行它能確認(rèn)三個(gè) repo 都識(shí)別到了而且能看到每個(gè)倉(cāng)庫(kù)的包數(shù)量包數(shù)量為 0 基本就是路徑問(wèn)題或 createrepo 沒(méi)跑成功。2.3 操作系統(tǒng)基線hosts、內(nèi)核、網(wǎng)橋與 NTP系統(tǒng)層面有幾項(xiàng)基礎(chǔ)工作順序不要亂。第一是/etc/hostsOpenStack 組件之間的通信大量依賴主機(jī)名hosts 解析配置錯(cuò)誤會(huì)引發(fā)各種詭異問(wèn)題最典型的就是 keystone 認(rèn)證超時(shí)日志里全是Connection refused但 IP 明明能 ping 通。添加集群內(nèi)所有節(jié)點(diǎn)的映射cat /etc/hosts EOF 192.168.1.10 controller 192.168.1.11 compute1 192.168.1.12 ceph1 192.168.1.13 ceph2 192.168.1.14 ceph3 EOF第二是網(wǎng)橋配置。OpenStack 實(shí)例要通過(guò)網(wǎng)橋接入網(wǎng)絡(luò)報(bào)告里手工配置 Linux 網(wǎng)橋的步驟比直接調(diào)用 neutron 或 nova-network 自動(dòng)創(chuàng)建要穩(wěn)得多。測(cè)試環(huán)境里最常見(jiàn)的做法是修改網(wǎng)絡(luò)腳本# 備份原有配置 cp /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eth0.bak cp /etc/sysconfig/network-scripts/ifcfg-br0 /etc/sysconfig/network-scripts/ifcfg-br0.bak # eth0 只負(fù)責(zé)物理鏈路不配置 IP cat /etc/sysconfig/network-scripts/ifcfg-eth0 EOF DEVICEeth0 TYPEEthernet BOOTPROTOnone ONBOOTyes BRIDGEbr0 EOF # br0 繼承原來(lái)的 IP 配置 cat /etc/sysconfig/network-scripts/ifcfg-br0 EOF DEVICEbr0 TYPEBridge BOOTPROTOstatic IPADDR192.168.1.11 NETMASK255.255.255.0 GATEWAY192.168.1.1 ONBOOTyes EOF systemctl restart network注意 eth0 的BRIDGEbr0這行它告訴內(nèi)核把 eth0 交給 br0 管理。配置完成后用brctl show查看留意到 br0 的 interfaces 列表里有 eth0 才算成功。這是個(gè)排查必查項(xiàng)很多時(shí)候 nova-network 起不來(lái)不是因?yàn)榉?wù)本身而是網(wǎng)橋沒(méi)建好。第三是 NTP 時(shí)間同步。Ceph 的 MON 節(jié)點(diǎn)對(duì)時(shí)鐘漂移極度敏感OSD 之間的心跳依賴時(shí)間戳?xí)r間不同步直接導(dǎo)致 MON 判定 OSD down。ntpdate一次性同步只能救急必須配置 cron 定期同步或啟用 ntpd 服務(wù)。這一點(diǎn)在避坑章節(jié)會(huì)細(xì)說(shuō)這里按下不表。3. 控制節(jié)點(diǎn)與計(jì)算節(jié)點(diǎn)組件安裝順序決定排錯(cuò)成本3.1 控制節(jié)點(diǎn)數(shù)據(jù)庫(kù)、消息中間件與認(rèn)證服務(wù)的啟動(dòng)順序控制節(jié)點(diǎn)的服務(wù)安裝順序是有講究的。MySQL 先裝因?yàn)?keystone、glance、nova、cinder 都要建數(shù)據(jù)庫(kù)接著是消息中間件報(bào)告里用的是 Qpid早期 OpenStack 版本Icehouse 前后的默認(rèn)選擇現(xiàn)在主流是 RabbitMQ但組件間解耦的思路完全一致然后才是 keystone——它一旦就緒后續(xù)所有組件都可以通過(guò) keystone 做認(rèn)證注冊(cè)。MySQL 初始化這里有個(gè)細(xì)節(jié)OpenStack 各組件創(chuàng)建的數(shù)據(jù)庫(kù)賬號(hào)建議密碼統(tǒng)一管理但權(quán)限按庫(kù)隔離# 安裝并啟動(dòng) MySQL yum install -y mysql mysql-server systemctl start mysqld # 初始化并設(shè)置 root 密碼 mysql_secure_installation # 創(chuàng)建各組件數(shù)據(jù)庫(kù)和賬號(hào) mysql -uroot -p EOF CREATE DATABASE keystone DEFAULT CHARACTER SET utf8; CREATE DATABASE glance DEFAULT CHARACTER SET utf8; CREATE DATABASE nova DEFAULT CHARACTER SET utf8; CREATE DATABASE cinder DEFAULT CHARACTER SET utf8; GRANT ALL PRIVILEGES ON keystone.* TO keystonelocalhost IDENTIFIED BY keystone_pass; GRANT ALL PRIVILEGES ON keystone.* TO keystone% IDENTIFIED BY keystone_pass; GRANT ALL PRIVILEGES ON glance.* TO glancelocalhost IDENTIFIED BY glance_pass; GRANT ALL PRIVILEGES ON glance.* TO glance% IDENTIFIED BY glance_pass; GRANT ALL PRIVILEGES ON nova.* TO novalocalhost IDENTIFIED BY nova_pass; GRANT ALL PRIVILEGES ON nova.* TO nova% IDENTIFIED BY nova_pass; GRANT ALL PRIVILEGES ON cinder.* TO cinderlocalhost IDENTIFIED BY cinder_pass; GRANT ALL PRIVILEGES ON cinder.* TO cinder% IDENTIFIED BY cinder_pass; FLUSH PRIVILEGES; EOF%這個(gè)主機(jī)通配符容易被忽略它解決的是控制節(jié)點(diǎn)和計(jì)算節(jié)點(diǎn)從遠(yuǎn)程連接數(shù)據(jù)庫(kù)時(shí)的授權(quán)問(wèn)題。只授權(quán)l(xiāng)ocalhost計(jì)算節(jié)點(diǎn)的 nova-compute 就沒(méi)法連數(shù)據(jù)庫(kù)這又是一個(gè)典型的「本地好好的、一跨節(jié)點(diǎn)就失敗」的坑。keystone 安裝配置的關(guān)鍵點(diǎn)在于連接 MySQL 和初始化數(shù)據(jù)庫(kù)表然后設(shè)置 token。早期版本用 UUID token每請(qǐng)求一次就要查數(shù)據(jù)庫(kù)校驗(yàn)后來(lái)引入 Fernet 才免掉了這個(gè)開(kāi)銷。報(bào)告里的keystone-manage db_sync執(zhí)行后要確認(rèn)沒(méi)有 ERROR 輸出然后配置令牌過(guò)期時(shí)間和簽發(fā)方式# 安裝 keystone yum install -y openstack-keystone python-keystoneclient # 修改 /etc/keystone/keystone.conf 中的數(shù)據(jù)庫(kù)連接 # 關(guān)鍵參數(shù)connection mysql://keystone:keystone_passcontroller/keystone # 以及 [token] 段下的 provider keystone.token.providers.uuid.Provider # 初始化數(shù)據(jù)庫(kù) keystone-manage db_sync # 配置令牌 keystone-manage pki_setup --keystone-user keystone --keystone-group keystonedb_sync是把 keystone 的模型同步到 MySQL它在 OpenStack 各組件里是通用操作glance、nova、cinder 都要執(zhí)行一遍。如果db_sync報(bào)錯(cuò)優(yōu)先檢查 MySQL 連接串里的密碼是否和授權(quán)時(shí)的密碼一致——這是最常見(jiàn)的低級(jí)錯(cuò)誤。3.2 glance 與 cinder鏡像服務(wù)和塊存儲(chǔ)服務(wù)為什么必須先于 novaglance 排在 nova 前面是因?yàn)?nova 創(chuàng)建虛機(jī)時(shí)需要從 glance 拉取鏡像nova-compute 會(huì)調(diào)用 glance API 獲取鏡像元數(shù)據(jù)和數(shù)據(jù)流。glance 本身也要先經(jīng)過(guò) keystone 認(rèn)證配置glance-api.conf里的認(rèn)證地址時(shí)要寫 keystone 的服務(wù)地址而不是 localhost——雖然測(cè)試環(huán)境可能都在同一臺(tái)機(jī)器上但規(guī)范起見(jiàn)還是顯式寫 controller 主機(jī)名。cinder 也一樣它依賴 keystone 認(rèn)證、glance 做鏡像服務(wù)最終還要對(duì)接后端的存儲(chǔ)。cinder 放在組件安裝的末尾并不是它不重要而是它前后依賴最多。配置 cinder 時(shí)有個(gè)參數(shù)容易踩坑——glance_api_version老版本默認(rèn)是 1但 glance 的 v2 API 才是現(xiàn)在的主流。如果 cinder 通過(guò) v1 API 連 glance 失敗創(chuàng)建云硬盤時(shí)從鏡像拷貝數(shù)據(jù)就會(huì)報(bào)錯(cuò)。安裝并驗(yàn)證 glance 服務(wù)# 安裝 glance yum install -y openstack-glance python-glanceclient # 初始化數(shù)據(jù)庫(kù) su -s /bin/sh -c glance-manage db_sync glance # 啟動(dòng)服務(wù) systemctl start openstack-glance-api openstack-glance-registry systemctl enable openstack-glance-api openstack-glance-registry # 驗(yàn)證上傳一張測(cè)試鏡像能顯示 active 狀態(tài)即為成功 glance image-create --name cirros --file cirros-0.3.4-x86_64-disk.img \ --disk-format qcow2 --container-format bare --visibility public注意db_sync要以 glance 用戶身份執(zhí)行直接用 root 會(huì)有文件屬主不一致的問(wèn)題到時(shí)候 glance 進(jìn)程寫不了/var/lib/glance下的文件表現(xiàn)就是鏡像上傳后狀態(tài)一直是 saving 而不是 active。這個(gè)問(wèn)題在避坑章節(jié)還會(huì)再提。3.3 計(jì)算節(jié)點(diǎn)nova-compute 與 nova-network 的聯(lián)動(dòng)計(jì)算節(jié)點(diǎn)的安裝重點(diǎn)是 nova-compute 和 nova-network。nova-compute 負(fù)責(zé)管理虛機(jī)的生命周期nova-network 則是早期 OpenStack 的默認(rèn)網(wǎng)絡(luò)方案通過(guò) Linux 網(wǎng)橋和 iptables 規(guī)則實(shí)現(xiàn) NAT 和安全組功能。報(bào)告里 Neutron 標(biāo)注了「待測(cè)試」說(shuō)明當(dāng)時(shí)網(wǎng)絡(luò)方案還停留在 nova-network 階段——新項(xiàng)目直接用 Neutron 沒(méi)問(wèn)題但從控制節(jié)點(diǎn)的注冊(cè)邏輯來(lái)看兩者對(duì) nova 來(lái)說(shuō)都是「網(wǎng)絡(luò)服務(wù)」nova 只關(guān)心如何調(diào)用網(wǎng)絡(luò)接口。計(jì)算節(jié)點(diǎn)上 nova.conf 的配置核心就是注冊(cè)信息和服務(wù)地址# 編輯 /etc/nova/nova.conf核心參數(shù)如下 # [database] connection mysql://nova:nova_passcontroller/nova # [keystone_authtoken] auth_uri http://controller:5000/v2.0 # [DEFAULT] my_ip 192.168.1.11 # [DEFAULT] vncserver_listen 0.0.0.0 # [DEFAULT] vncserver_proxyclient_address 192.168.1.11 # [DEFAULT] network_manager nova.network.manager.FlatDHCPManager # [DEFAULT] fixed_range 10.0.0.0/24 # [DEFAULT] flat_network_bridge br100 systemctl start openstack-nova-compute openstack-nova-network systemctl enable openstack-nova-compute openstack-nova-networkflat_network_bridge br100是 nova-network 的核心——虛機(jī)的 tap 設(shè)備都會(huì)橋接到 br100 上。如果這個(gè)網(wǎng)橋沒(méi)有提前創(chuàng)建好nova-network 會(huì)嘗試自己創(chuàng)建但有時(shí)會(huì)因?yàn)闄?quán)限問(wèn)題失敗所以建議在配置網(wǎng)絡(luò)時(shí)就手工建好。fixed_range定義虛機(jī)網(wǎng)段不要和物理網(wǎng)段沖突這是經(jīng)驗(yàn)之談沖突的話虛機(jī)網(wǎng)絡(luò)會(huì)變得非常混亂。4. 部署 Ceph 集群ceph-deploy 建集群與 CRUSH 數(shù)據(jù)分布原理4.1 ceph-deploy 初始化集群mon、osd 的創(chuàng)建順序Ceph 的安裝分兩條路線老版本用 ceph-deploy新版本推薦 cephadm。報(bào)告用的 ceph-deploy 雖然現(xiàn)在不再是首選但對(duì)理解 Ceph 的組件裝配過(guò)程非常有幫助——它一條命令做完的事情恰恰是要搞清楚的底層邏輯先建 MON再建 OSD最后才是 pool 和客戶端認(rèn)證。ceph-deploy 的操作流程非常固定照著走基本不會(huì)錯(cuò)# 安裝 ceph-deploy 工具在管理節(jié)點(diǎn)上執(zhí)行 yum install -y ceph-deploy # 創(chuàng)建集群配置目錄 mkdir /etc/ceph cd /etc/ceph # 初始化集群指定 MON 節(jié)點(diǎn) ceph-deploy new ceph1 ceph2 ceph3 # 安裝 ceph 軟件包到所有節(jié)點(diǎn) ceph-deploy install ceph1 ceph2 ceph3 # 初始化 MON 并收集密鑰 ceph-deploy mon create-initial # 創(chuàng)建 OSD指向數(shù)據(jù)盤 ceph-deploy osd create ceph1:/dev/sdb ceph2:/dev/sdb ceph3:/dev/sdb # 同步配置和密鑰到所有節(jié)點(diǎn) ceph-deploy admin ceph1 ceph2 ceph3 # 檢查集群狀態(tài) ceph -smon create-initial會(huì)生成一組密鑰文件包括ceph.client.admin.keyring和ceph.bootstrap-osd.keyring前者是管理員操作集群的鑰匙后者是 OSD 加入集群時(shí)用來(lái)自動(dòng)注冊(cè)的憑證。ceph-deploy admin的作用就是把 admin keyring 分發(fā)到各節(jié)點(diǎn)沒(méi)有這一步節(jié)點(diǎn)上執(zhí)行ceph命令會(huì)提示無(wú)法連接或認(rèn)證失敗。OSD 創(chuàng)建的兩個(gè)關(guān)鍵點(diǎn)是磁盤必須是沒(méi)有分區(qū)和文件系統(tǒng)的裸盤ceph-deploy osd create會(huì)自動(dòng)完成分區(qū)、格式化和數(shù)據(jù)目錄初始化如果磁盤之前用過(guò)要先用ceph-deploy disk zap清空直接復(fù)用帶數(shù)據(jù)的分區(qū)會(huì)導(dǎo)致文件系統(tǒng)識(shí)別失敗。4.2 CRUSH 映射與數(shù)據(jù)分布為什么副本數(shù)等于 2 也要注意 min sizeCeph 的數(shù)據(jù)分布靠 CRUSH 算法它和一致性哈希的區(qū)別在于CRUSH 不查表而是根據(jù)集群拓?fù)錂C(jī)架、主機(jī)、OSD 層級(jí)和規(guī)則直接計(jì)算出數(shù)據(jù)落在哪些 OSD 上。所以 CRUSH 沒(méi)有中心化的元數(shù)據(jù)服務(wù)也就沒(méi)有單點(diǎn)瓶頸。報(bào)告里對(duì) CRUSH 的描述比較簡(jiǎn)略但實(shí)操時(shí)有兩個(gè)參數(shù)繞不開(kāi)size和min_size。size是副本數(shù)默認(rèn) 3測(cè)試環(huán)境磁盤有限可以改成 2min_size是「降級(jí)但不停止服務(wù)」的最低副本數(shù)比如size2, min_size1意味著只有一個(gè)副本存活時(shí)集群還能繼續(xù)提供讀寫但數(shù)據(jù)安全性已經(jīng)降級(jí)了。# 創(chuàng)建存儲(chǔ)池用于 OpenStack 的鏡像、卷和虛機(jī) ceph osd pool create volumes 128 ceph osd pool create images 128 ceph osd pool create vms 128 # 設(shè)置副本數(shù)為 2測(cè)試環(huán)境生產(chǎn)環(huán)境建議保持 3 ceph osd pool set volumes size 2 ceph osd pool set images size 2 ceph osd pool set vms size 2 # 設(shè)置 min_size ceph osd pool set volumes min_size 1 ceph osd pool set images min_size 1 ceph osd pool set vms min_size 1Pool 的 PG 數(shù)量設(shè)置是門玄學(xué)但有大致的經(jīng)驗(yàn)公式PG 總數(shù) (OSD 總數(shù) × 100) / 副本數(shù)然后取最接近的 2 的冪次。3 個(gè) OSD、副本 2 的情況下128 個(gè) PG 是合理的選擇。PG 太少會(huì)導(dǎo)致單個(gè) PG 內(nèi)數(shù)據(jù)過(guò)多、均衡度差太多則會(huì)增加 OSD 的內(nèi)存開(kāi)銷和心跳負(fù)擔(dān)。很多人糾結(jié)為什么 OpenStack 里要分 volumes、images、vms 三個(gè) pool——這是職責(zé)隔離鏡像和虛機(jī)的數(shù)據(jù)特點(diǎn)不同分開(kāi)后可以獨(dú)立設(shè)置配額、快照策略和 QoS。cinder 后端存儲(chǔ)用 volumesglance 存鏡像用 imagesnova 的虛機(jī)磁盤用 vms各有各的活。4.3 性能優(yōu)化ssd journal、網(wǎng)絡(luò)與內(nèi)核參數(shù)Ceph 的性能瓶頸通常不在 CPU 和內(nèi)存而在磁盤 IO 和網(wǎng)絡(luò)。報(bào)告里的性能優(yōu)化涉及兩個(gè)方向一是北斗日志和數(shù)據(jù)的分離二是網(wǎng)絡(luò)參數(shù)的調(diào)整。在有 SSD 的環(huán)境里把 OSD 的 journal日志盤放在 SSD 上能大幅提升寫入性能。Ceph 的寫路徑是「先寫 journal再寫數(shù)據(jù)盤」journal 落盤后客戶端就能收到 ACK所以 journal 的速度直接決定寫延遲# 在 ceph.conf 中配置 OSD 參數(shù) cat /etc/ceph/ceph.conf EOF [global] osd journal size 10240 osd max open files 131072 osd op threads 8 [osd] osd heartbeat grace 30 osd heartbeat interval 10 EOF # 同步配置到所有節(jié)點(diǎn) ceph-deploy --overwrite-conf config push ceph1 ceph2 ceph3osd journal size單位是 MB設(shè) 10240MB 即 10G。journal 太小時(shí)高并發(fā)寫入會(huì)頻繁刷盤性能斷崖式下跌。osd max open files影響同時(shí)打開(kāi)的文件句柄數(shù)過(guò)低會(huì)導(dǎo)致 OSD 在壓力下報(bào)Too many open files。osd heartbeat grace是 OSD 被 MON 判定為 down 的寬限時(shí)間網(wǎng)絡(luò)抖動(dòng)頻繁的環(huán)境里適當(dāng)調(diào)大可以減少誤判。網(wǎng)絡(luò)層面的調(diào)優(yōu)集中在 TCP 緩沖區(qū)上Ceph 的數(shù)據(jù)傳輸走 TCP默認(rèn)的讀寫緩沖區(qū)不一定能跑滿萬(wàn)兆網(wǎng)卡# 修改 /etc/sysctl.conf提高網(wǎng)絡(luò)吞吐 net.core.rmem_max 134217728 net.core.wmem_max 134217728 net.ipv4.tcp_rmem 4096 87380 134217728 net.ipv4.tcp_wmem 4096 65536 134217728 net.ipv4.tcp_sack 1 sysctl -p調(diào)完后用ceph -s觀察osd perf的延遲數(shù)據(jù)以及ceph osd tree看數(shù)據(jù)分布是否均勻。如果某個(gè) OSD 的寫入延遲明顯高于其他節(jié)點(diǎn)大概率是它的 journal 落在了和數(shù)據(jù)盤同一塊 HDD 上——這就回到前面說(shuō)的規(guī)劃問(wèn)題每個(gè) OSD 節(jié)點(diǎn)最好單獨(dú)準(zhǔn)備一塊 SSD 做 journal。5. 避坑記錄OpenStack 和 Ceph 集成的四個(gè)高發(fā)問(wèn)題5.1 現(xiàn)象ceph -s 顯示 HEALTH_WARNOSD 狀態(tài)為 down現(xiàn)象集群跑著跑著ceph -s提示HEALTH_WARN查看ceph osd tree發(fā)現(xiàn)有 OSD 是 down 狀態(tài)但系統(tǒng)ps查看進(jìn)程還在。原因OSD 進(jìn)程正常但 MON 收不到它的心跳超過(guò)osd heartbeat grace時(shí)間后判定為 down。最常見(jiàn)的觸發(fā)因素是時(shí)鐘漂移其次是網(wǎng)絡(luò)抖動(dòng)導(dǎo)致心跳包丟失。Ceph 的 MON 之間和 OSD 之間對(duì)時(shí)間敏感節(jié)點(diǎn)間時(shí)間差超過(guò) 50ms 就會(huì)在ceph health里報(bào)CLOCK_SKEW。解決先同步時(shí)間再觀察。配置 ntpdate 定時(shí)任務(wù)或啟用 ntpd 服務(wù)Ceph 官方推薦所有節(jié)點(diǎn)使用同一臺(tái) NTP 服務(wù)器。如果時(shí)間正常檢查存儲(chǔ)網(wǎng)是否擁塞適當(dāng)調(diào)大osd heartbeat grace。我自己遇到過(guò)一次是 Ceph 節(jié)點(diǎn)上的防火墻攔截了半開(kāi)連接導(dǎo)致心跳包偶發(fā)丟失關(guān)掉 firewalld 后恢復(fù)。5.2 現(xiàn)象glance 上傳鏡像后狀態(tài)一直是 saving現(xiàn)象執(zhí)行g(shù)lance image-create后鏡像狀態(tài)長(zhǎng)時(shí)間停在saving最終報(bào)錯(cuò)或卡死。原因這個(gè)坑在純 OpenStack 環(huán)境里不常見(jiàn)但接上 Ceph 后概率大增。glance 把鏡像數(shù)據(jù)寫到 Ceph 的 images pool如果 pool 不存在或者 glance 進(jìn)程沒(méi)有該 pool 的讀寫權(quán)限數(shù)據(jù)寫入就會(huì)掛在半路。解決確認(rèn) images pool 存在用ceph osd pool ls檢查再確認(rèn) glance 的 ceph 認(rèn)證配置正確。檢查/etc/glance/glance-api.conf里的rbd_store_pool參數(shù)并確保 client.glance 的 keyring 在 glance 進(jìn)程可讀的路徑下# 檢查 pool ceph osd pool ls | grep images # 給 glance 用戶授權(quán) images pool ceph auth caps client.glance mon allow r osd allow class-read object_prefix rbd_children, allow rwx poolimages5.3 現(xiàn)象cinder 創(chuàng)建云硬盤失敗日志報(bào) rbd 權(quán)限錯(cuò)誤現(xiàn)象通過(guò) dashboard 或命令行創(chuàng)建云硬盤時(shí)狀態(tài)直接變?yōu)閑rrorcinder-volume 日志里出現(xiàn)error connecting to the cluster或Permission denied。原因cinder 后端配置的 RBD 用戶沒(méi)有 volumes pool 的訪問(wèn)權(quán)限。cinder 不同于 glance它通過(guò)配置的rbd_user來(lái)連接 Ceph如果這個(gè)用戶的 keyring 沒(méi)有被 cephx 認(rèn)證放行連接直接被拒。解決確認(rèn) cinder.conf 中rbd_user cinder且在 Ceph 中創(chuàng)建了 cinder 用戶并授權(quán)然后重啟 cinder-volume 服務(wù)# 創(chuàng)建 cinder 用戶并授權(quán) volumes pool ceph auth get-or-create client.cinder mon allow r osd allow class-read object_prefix rbd_children, allow rwx poolvolumes # 將 keyring 分發(fā)到控制節(jié)點(diǎn) ceph auth get client.cinder -o /etc/ceph/ceph.client.cinder.keyring # 重啟 cinder-volume systemctl restart openstack-cinder-volume5.4 現(xiàn)象nova live-migration 卡在 migrating 狀態(tài)現(xiàn)象執(zhí)行nova live-migration instance后虛機(jī)狀態(tài)一直停留在 migrating目標(biāo)節(jié)點(diǎn)上沒(méi)有任何變化。原因在線遷移要保證源和目標(biāo)節(jié)點(diǎn)的虛機(jī)磁盤內(nèi)容一致這要求虛機(jī)磁盤放在共享存儲(chǔ)上。接 Ceph 后虛機(jī)磁盤在 RBD 里理論上天然支持遷移但 nova-compute 需要知道「磁盤在 Ceph 上不需要本地拷貝」。如果 nova.conf 里沒(méi)配置正確的libvirt和rbd參數(shù)nova 會(huì)嘗試走本地文件拷貝的路徑當(dāng)然永久卡住。解決檢查 nova.conf 中計(jì)算節(jié)點(diǎn)的 rbd 配置是否完整尤其鏡像和虛機(jī)池的設(shè)置# /etc/nova/nova.conf 中 [libvirt] 段的核心參數(shù) # [libvirt] images_type rbd # [libvirt] images_rbd_pool vms # [libvirt] images_rbd_ceph_conf /etc/ceph/ceph.conf # [libvirt] images_rbd_glance_pool_name images # [libvirt] rbd_user nova # [libvirt] rbd_secret_uuid uuidimages_type rbd這行決定了 nova-compute 把虛機(jī)磁盤放在 RBD 而不是本地它是熱遷移能否進(jìn)行的前提條件。6. 端到端驗(yàn)證從鏡像上傳到在線遷移的一次完整閉環(huán)測(cè)試6.1 鏡像、云硬盤、虛機(jī)的貫通驗(yàn)證環(huán)境搭好之后報(bào)告里最后做了一次端到端驗(yàn)證這條鏈路完整走通才算真正交付上傳鏡像 → 創(chuàng)建云硬盤 → 從云硬盤引導(dǎo)虛機(jī) → 把另一塊云硬盤 attach 給虛機(jī)。首先是上傳測(cè)試鏡像然后基于鏡像創(chuàng)建云硬盤# 上傳鏡像 glance image-create --name cirros --file cirros-0.3.4-x86_64-disk.img \ --disk-format qcow2 --container-format bare --visibility public # 查看鏡像狀態(tài)確認(rèn) active glance image-list # 創(chuàng)建 5G 云硬盤source 指定鏡像 ID cinder create --image image-id --display-name boot-volume 5 # 查看卷狀態(tài)確認(rèn) available cinder list從云硬盤引導(dǎo)虛機(jī)是 OpenStack 接 Ceph 后最常見(jiàn)的場(chǎng)景用nova boot的--block-device-mapping參數(shù)nova boot --flavor m1.small \ --block-device-mapping vdavolume-id:::0 \ --nic net-idnet-id \ ceph-test-instancevdavolume-id:::0的最后一位數(shù)字 0 表示從該卷引導(dǎo)如果寫成 1 則會(huì)嘗試先查鏡像再掛卷。這一步正確后虛機(jī)起在 Ceph 的 vms pool 里數(shù)據(jù)落盤路徑完全走 RBD。6.2 在線遷移的驗(yàn)證方法與 libvirt 配置最后驗(yàn)證在線遷移先在控制節(jié)點(diǎn)檢查遷移功能所需配置然后執(zhí)行遷移# 檢查虛機(jī)當(dāng)前所在計(jì)算節(jié)點(diǎn) nova show ceph-test-instance | grep OS-EXT-SRV-ATTR:host # 執(zhí)行在線遷移 nova live-migration ceph-test-instance compute2 # 等待遷移完成后再次檢查宿主機(jī) nova show ceph-test-instance | grep OS-EXT-SRV-ATTR:host遷移期間可以在另一個(gè)終端用watch ceph -s觀察 RBD 層的 IOPS 變化。如果看到osd op rate明顯上升但虛機(jī)服務(wù)沒(méi)中斷說(shuō)明遷移流量確實(shí)走的是 Ceph 而不是本地磁盤拷貝。從那以后我每次驗(yàn)收 OpenStack 存儲(chǔ)后端都會(huì)強(qiáng)制走一遍「鏡像上傳 → 創(chuàng)建卷 → 從卷起虛機(jī) → 在線遷移」的完整閉環(huán)四步全通才算存儲(chǔ)接入成功。這個(gè)習(xí)慣幫我擋掉過(guò)不少「配置看著沒(méi)問(wèn)題、一跑就露餡」的部署交付希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取