搭建OpenStack云平臺這事聽著像是只有大廠運維才碰的東西實際上我身邊不少做虛擬化、做K8s底層支撐的同行都在自己折騰這套。原因也很簡單公有云雖然省事但數(shù)據(jù)面、網(wǎng)絡(luò)面、計費面都捏在別人手里想要完全可控的私有云OpenStack幾乎是目前唯一一個既有社區(qū)活躍度、又有生產(chǎn)驗證的開源選擇。這篇文章把我從規(guī)劃、部署到排錯全流程的經(jīng)驗拆開寫出來。不繞彎子先從最關(guān)鍵的架構(gòu)決策講起再一步步給你能直接抄作業(yè)的命令和配置最后把我踩過的坑、排查過的故障一并交代清楚。無論你是剛接觸OpenStack的新手還是被分配了搭建任務(wù)的運維開發(fā)這套流程應(yīng)該都能幫你少走很多彎路。1. 為什么要自己搭一套OpenStack而不是直接用現(xiàn)成云1.1 私有云的真實需求先說一個很多人沒想明白的問題你到底是需要“一朵云”還是只需要“幾臺虛擬機”如果是后者裝個KVM、裝個Proxmox VE就夠了完全沒必要上OpenStack。OpenStack的價值在于它把計算、存儲、網(wǎng)絡(luò)這三塊資源做成了統(tǒng)一的、可調(diào)度的、有租戶隔離的云平臺。我做過的模擬項目X就是這樣業(yè)務(wù)方要求為內(nèi)部多個團隊提供按需申請的計算資源每個團隊要有獨立的網(wǎng)絡(luò)隔離、獨立的賬號權(quán)限、獨立的鏡像管理還要能通過自助界面申請資源。這種需求用單機虛擬化根本撐不起來必須有一個帶認證、帶配額、帶網(wǎng)絡(luò)的云管平臺。OpenStack恰好就是解決這一類問題的。當然選擇OpenStack也意味著接受它的復(fù)雜度。組件多、服務(wù)多、概念多任何一個環(huán)節(jié)配錯都可能導(dǎo)致整個系統(tǒng)不可用。這也是為什么我建議第一次搭建時不要追求生產(chǎn)級的高可用先把核心組件跑通理解了服務(wù)之間的依賴關(guān)系再考慮擴展。1.2 裸機虛擬化、K8s和OpenStack的區(qū)別很多剛接觸云計算的人會把OpenStack和Kubernetes混為一談其實兩者的定位完全不同。K8s管的是容器OpenStack管的是虛擬機也可以管裸機但那是Ironic組件的事。K8s的調(diào)度對象是PodOpenStack的調(diào)度對象是實例。K8s本身不關(guān)心底層的計算資源是怎么來的而OpenStack正好負責把計算資源池化、虛擬化、網(wǎng)絡(luò)化。實際生產(chǎn)環(huán)境里完全可以用OpenStack作為IaaS層在它上面再部署K8s集群這樣K8s的節(jié)點可以按需擴容底層資源由OpenStack統(tǒng)一調(diào)度。我見過一個挺典型的場景某公司原本直接用物理機部署K8s擴容一次要采購硬件、人工裝機、配置網(wǎng)絡(luò)周期動輒兩周。后來改成OpenStack提供虛擬機作為K8s節(jié)點擴容時間縮短到分鐘級而且節(jié)點規(guī)格可以通過flavor靈活調(diào)整資源利用率明顯提升。1.3 先想清楚這幾件事再動手動手之前有幾個問題必須先有答案否則搭建過程中很容易反復(fù)返工。第一網(wǎng)絡(luò)方案。Neutron支持Flat、VLAN、VXLAN等多種模式選擇哪種直接影響物理交換機的配置、IP地址規(guī)劃、租戶網(wǎng)絡(luò)的隔離方式。我建議第一次搭建用VLAN模式兼容性好排查問題也比VXLAN簡單。第二存儲方案。如果只是測試環(huán)境用本地磁盤加LVM就夠了不需要單獨部署Cinder。如果涉及塊存儲服務(wù)就要考慮后端存儲怎么接是Ceph還是NFS還是其他商業(yè)存儲這會顯著影響架構(gòu)復(fù)雜度。第三版本和部署工具。OpenStack每半年左右發(fā)一個版本社區(qū)推薦的部署工具也在變化選型時需要確認是手動部署還是自動化部署這決定了后續(xù)的工程量和維護成本。2. 環(huán)境規(guī)劃與版本選型決定后續(xù)是否踩坑2.1 節(jié)點規(guī)劃與硬件建議一套最精簡的OpenStack環(huán)境至少需要兩個節(jié)點一個控制節(jié)點一個計算節(jié)點?？刂乒?jié)點承載認證、鏡像、調(diào)度、網(wǎng)絡(luò)管理等服務(wù)計算節(jié)點負責運行虛擬機實例。實際搭建時我給模擬項目X分配的節(jié)點方案如下節(jié)點角色服務(wù)組件最低配置建議備注控制節(jié)點Keystone、Glance、Placement、Nova API、Neutron Server、Horizon4核CPU / 8GB內(nèi)存 / 100GB硬盤建議系統(tǒng)盤與數(shù)據(jù)盤分開計算節(jié)點Nova Compute、Neutron Agent、KVM/QEMU8核CPU / 16GB內(nèi)存 / 200GB硬盤根據(jù)業(yè)務(wù)量彈性調(diào)整可選存儲節(jié)點Cinder、Ceph按容量規(guī)劃測試環(huán)境可省略如果你只有一臺物理服務(wù)器也可以把控制節(jié)點和計算節(jié)點放在同一臺機器上但這種單節(jié)點模式只適合學(xué)習(xí)驗證不適合運行真實業(yè)務(wù)。2.2 網(wǎng)絡(luò)方案怎么選網(wǎng)絡(luò)是OpenStack里最復(fù)雜也最容易出問題的部分。我把常見三種模式的特點整理成了一張表網(wǎng)絡(luò)模式隔離方式優(yōu)點缺點Flat不隔離配置最簡單只能用于測試VLAN802.1Q虛擬局域網(wǎng)兼容性好、性能穩(wěn)定依賴物理交換機配置VXLANOverlay隧道大規(guī)模擴展性好故障排查難度較大我個人的建議是第一次搭建用VLAN模式將物理網(wǎng)卡劃分出管理網(wǎng)、數(shù)據(jù)網(wǎng)和外部網(wǎng)。管理網(wǎng)用于服務(wù)之間的通信數(shù)據(jù)網(wǎng)承載虛擬機流量外部網(wǎng)用于訪問云主機。三個網(wǎng)絡(luò)盡量用不同網(wǎng)段和不同物理網(wǎng)卡避免流量互相干擾。2.3 版本和部署工具的選型邏輯OpenStack的版本代號從字母A到Z按字母表命名每個字母對應(yīng)一個版本。我搭建時用的是Yoga版本算是比較穩(wěn)定可靠的一個版本不同發(fā)行版自帶的OpenStack包版本不同需要先確認發(fā)行版軟件源里提供的版本。部署工具方面有幾種選擇一是純手動部署按照官方文檔逐個安裝配置服務(wù)。這種方式最能幫助你理解各個組件的原理但工作量大容易出錯適合學(xué)習(xí)場景。二是使用RDO或PackStack這是基于某個Linux發(fā)行版的OpenStack部署工具可以用一條命令搭建基礎(chǔ)環(huán)境適合快速驗證。三是以Kolla-Ansible為代表的容器化部署方案把OpenStack服務(wù)打包成容器配合Ansible自動化編排。這種方式是目前生產(chǎn)環(huán)境的主流選擇升級回滾方便部署一致性好。我在正式交付給某公司做內(nèi)部培訓(xùn)時用的就是Kolla-Ansible方案。但如果你希望把OpenStack的內(nèi)部機制徹底搞懂我建議至少手動部署一次核心組件這個認知價值無法替代。提示無論選擇哪種部署方式都建議先在虛擬機里做一遍完整的演練。不要在物理機上一上來就跑全程OpenStack部署過程中的各種網(wǎng)絡(luò)配置、依賴沖突、服務(wù)啟動失敗在小規(guī)模實驗環(huán)境里更容易定位問題。3. 基礎(chǔ)環(huán)境配置系統(tǒng)、網(wǎng)絡(luò)與依賴3.1 操作系統(tǒng)與基礎(chǔ)服務(wù)OpenStack對操作系統(tǒng)要求不低但核心原則就是使用長期支持版本避免新版本軟件源不穩(wěn)定。我搭建時用的是基于Linux內(nèi)核的主流服務(wù)器發(fā)行版LTS版本這類系統(tǒng)社區(qū)支持時間長、軟件包齊全、遇到問題容易搜到答案。系統(tǒng)裝好之后第一件事就是配置主機名和hosts文件。三個節(jié)點的主機名我規(guī)劃為controller、compute1在/etc/hosts中把節(jié)點IP和主機名的對應(yīng)關(guān)系寫清楚。這一步看似簡單但很多服務(wù)之間是通過主機名通信的如果hosts配置錯誤后面會出現(xiàn)各種詭異的認證失敗和服務(wù)連接超時。然后創(chuàng)建一個專用的系統(tǒng)用戶用于執(zhí)行OpenStack相關(guān)操作。生產(chǎn)實踐中不建議直接用root操作因為OpenStack的配置文件、日志文件、虛擬化操作都有獨立的權(quán)限體系單獨的用戶便于管理和審計。3.2 網(wǎng)卡和橋接配置實操以控制節(jié)點為例通常需要至少兩塊網(wǎng)卡一塊用于管理網(wǎng)絡(luò)一塊用于外部網(wǎng)絡(luò)。在配置網(wǎng)絡(luò)之前先確認物理網(wǎng)卡的名稱然后編輯網(wǎng)絡(luò)配置文件。管理網(wǎng)卡的配置比較簡單設(shè)置靜態(tài)IP即可。外部網(wǎng)卡需要配置為橋接模式因為在OpenStack里外部網(wǎng)絡(luò)是通過網(wǎng)橋與物理網(wǎng)絡(luò)連接的。我用一個例子來說明cat /etc/network/interfaces.d/br-ex.cfgauto br-ex iface br-ex inet static address 192.168.68.20 netmask 255.255.255.0 gateway 192.168.68.1 dns-nameservers 192.168.68.1這段配置的含義是創(chuàng)建一個名為br-ex的Linux網(wǎng)橋給它配置靜態(tài)IP地址。物理網(wǎng)卡上不配置IP而是把它加入網(wǎng)橋。這樣虛擬機通過網(wǎng)橋就能訪問外部網(wǎng)絡(luò)配置思路跟家用路由器里的“橋接模式”是一個道理。配置完成后一定要重啟網(wǎng)絡(luò)服務(wù)并驗證連通性我在早期搭建時經(jīng)常遇到網(wǎng)卡配置沖突導(dǎo)致SSH斷開的問題所以強烈建議在本地控制臺或帶外管理界面操作網(wǎng)絡(luò)配置避免把自己鎖在外面。3.3 時鐘同步與軟件源OpenStack的認證服務(wù)高度依賴精確時間時間偏差超過幾分鐘就可能導(dǎo)致令牌校驗失敗。NTP是必須配置的控制節(jié)點同步外部時間源計算節(jié)點同步控制節(jié)點。chronyc sources -v配置完成后用這條命令檢查時間同步狀態(tài)。如果輸出顯示時間源處于活躍狀態(tài)說明同步正常如果顯示^*或*符號說明已鎖定到時間源。軟件源也建議提前配置因為OpenStack組件依賴大量其他軟件包默認軟件源下載速度慢或者缺少必要包會導(dǎo)致安裝中斷。我記得有一次安裝網(wǎng)絡(luò)服務(wù)時因為依賴包版本沖突整整花了一個下午排查最后發(fā)現(xiàn)是軟件源里的包版本和OpenStack版本不匹配。4. 核心組件部署從認證到計算4.1 先搭認證服務(wù)KeystoneKeystone是OpenStack所有服務(wù)的“門衛(wèi)”其他所有組件在調(diào)用API之前都要先經(jīng)過認證和權(quán)限校驗。所以搭建順序必須是先創(chuàng)建Keystone再創(chuàng)建后續(xù)服務(wù)否則后續(xù)組件創(chuàng)建用戶和端點時會失敗。創(chuàng)建Keystone的數(shù)據(jù)庫、服務(wù)憑證和API端點都需要設(shè)置統(tǒng)一的認證信息。我習(xí)慣用一個環(huán)境變量文件統(tǒng)一管理這些信息每次操作前先加載export OS_PROJECT_DOMAIN_NAMEDefault export OS_USER_DOMAIN_NAMEDefault export OS_PROJECT_NAMEadmin export OS_USERNAMEadmin export OS_PASSWORD你的強密碼 export OS_AUTH_URLhttp://controller:5000 export OS_IDENTITY_API_VERSION3這個環(huán)境變量文件在實際操作中非常重要。日志排查時如果API請求返回401八成就是環(huán)境變量里的密碼或項目名寫錯了。我建議把這套環(huán)境變量放在/root/openrc這樣的獨立文件里每次需要執(zhí)行OpenStack命令就先source一下。4.2 鏡像服務(wù)Glance與鏡像上傳Glance負責管理虛擬機鏡像可以理解成云主機模板的倉庫。安裝好Glance之后必須上傳一個至少可用的系統(tǒng)鏡像后續(xù)創(chuàng)建云主機才有模板可用。挑選鏡像時我建議用官方提供的云鏡像這類鏡像預(yù)裝了cloud-init工具能夠自動完成主機名配置、SSH密鑰注入、分區(qū)擴容等初始化操作。上傳命令openstack image create --disk-format qcow2 --container-format bare \ --public --file ubuntu-server.qcow2 ubuntu-serverqcow2是鏡像格式bare表示容器格式為裸鏡像這兩個參數(shù)是鏡像服務(wù)要求的必填項。--public參數(shù)表示所有項目都能使用這個鏡像如果不想讓租戶看到可以改成--private。上傳完成后用openstack image list確認鏡像狀態(tài)是active。我遇到過一次鏡像狀態(tài)一直卡在queued的情況后來發(fā)現(xiàn)是控制節(jié)點磁盤空間不足Glance無法把鏡像文件完整寫入存儲目錄。4.3 計算服務(wù)Nova的控制與計算節(jié)點Nova是OpenStack的計算核心分為控制節(jié)點的Nova API、調(diào)度器和計算節(jié)點上的Nova Compute?？刂乒?jié)點負責接收創(chuàng)建虛擬機的請求計算節(jié)點負責真正通過KVM或QEMU啟動虛擬機。配置Nova之前必須先注冊Placement服務(wù)這是負責資源跟蹤的組件。Placement的作用相當于一個資源臺賬記錄每個計算節(jié)點剩余多少CPU、多少內(nèi)存Nova調(diào)度器在收到創(chuàng)建請求后會根據(jù)Placement提供的數(shù)據(jù)決定把VM調(diào)度到哪臺物理機上。我第一次部署時漏掉了Placement導(dǎo)致虛擬機創(chuàng)建一直報“No valid host was found”日志里全是調(diào)度失敗的報錯。后來把Placement的數(shù)據(jù)庫和服務(wù)注冊補齊問題馬上解決了。4.4 網(wǎng)絡(luò)服務(wù)Neutron的配置要點Neutron配置是整個部署過程中最講究的部分因為它涉及很多網(wǎng)絡(luò)概念網(wǎng)絡(luò)、子網(wǎng)、路由、端口、安全組、DHCP代理、Open vSwitch網(wǎng)橋等。配置時有兩個點最容易被忽略。第一Neutron的認證配置必須和Keystone保持一致。很多人在配置Neutron時只改了數(shù)據(jù)庫連接、改了口令卻漏了認證類型和API版本結(jié)果Neutron服務(wù)啟動后無法和Keystone正常通信所有網(wǎng)絡(luò)創(chuàng)建請求都返回認證失敗。第二DHCP代理和L3代理要確保在正確節(jié)點上啟動。控制節(jié)點上需要啟動neutron-dhcp-agent為租戶網(wǎng)絡(luò)分配IP地址啟動neutron-l3-agent管理虛擬路由器的NAT和南北向流量。這兩個代理服務(wù)如果沒起來創(chuàng)建網(wǎng)絡(luò)不會報錯但創(chuàng)建出來的虛擬機獲取不到IP地址這是非常常見的問題。我習(xí)慣在配置完成后用如下命令檢查代理狀態(tài)openstack network agent list輸出中每個代理的狀態(tài)都應(yīng)為Alive。如果出現(xiàn)xxx not running的字段就需要回到對應(yīng)節(jié)點查看服務(wù)日志。5. 驗證與第一臺云主機的誕生5.1 命令行驗證所有服務(wù)核心組件全部裝完之后先不要急著在界面上操作用命令行把所有服務(wù)狀態(tài)過一遍。我總結(jié)了一套快速驗證流程openstack service list openstack endpoint list openstack image list openstack compute service list openstack network agent list這幾條命令分別驗證服務(wù)目錄、API端點、鏡像狀態(tài)、計算節(jié)點的服務(wù)狀態(tài)、網(wǎng)絡(luò)代理狀態(tài)。如果有任何一項輸出異常都應(yīng)該先排查清楚再繼續(xù)否則后續(xù)創(chuàng)建云主機時會把問題復(fù)雜化。5.2 創(chuàng)建網(wǎng)絡(luò)、路由與云主機現(xiàn)在到了最激動人心的環(huán)節(jié)——創(chuàng)建第一臺云主機。先創(chuàng)建租戶網(wǎng)絡(luò)。假如規(guī)劃用一個192.168.100.0/24網(wǎng)段給云主機分配地址openstack network create demo-net openstack subnet create demo-subnet \ --network demo-net \ --subnet-range 192.168.100.0/24 \ --dhcp為了訪問外部網(wǎng)絡(luò)還需要創(chuàng)建路由連接外部網(wǎng)絡(luò)。這一步相當于給云主機加了一個默認網(wǎng)關(guān)沒有路由的話云主機只能在租戶網(wǎng)絡(luò)內(nèi)部互通無法訪問外部。創(chuàng)建云主機的命令openstack server create --flavor m1.small --image ubuntu-server \ --network demo-net --key-name mykey my-first-instance其中m1.small是定義好的規(guī)格模板包含虛擬機的CPU、內(nèi)存、磁盤大小需要提前用openstack flavor create創(chuàng)建。--key-name指定SSH密鑰如果沒有配置密鑰創(chuàng)建后只能通過VNC控制臺或密碼登錄這在自動化和后續(xù)運維中不太方便。創(chuàng)建完成后用openstack server list查看狀態(tài)當狀態(tài)變?yōu)锳CTIVE說明云主機已經(jīng)成功啟動。5.3 通過Horizon可視化操作命令行之外OpenStack還提供了Horizon儀表盤。雖然不是核心組件但裝上它對日常使用和排錯都很有幫助。Horizon裝好之后用瀏覽器訪問控制節(jié)點的IP地址輸入之前創(chuàng)建的賬號密碼就能在圖形界面里創(chuàng)建實例、管理網(wǎng)絡(luò)、查看控制臺日志、調(diào)整安全組規(guī)則。我個人認為Horizon更適合給業(yè)務(wù)方當自助門戶而運維排障時還是命令行更快更直接。業(yè)務(wù)方不需要懂OpenStack概念只需要在界面上點擊申請資源運維人員則應(yīng)當熟練命令行因為很多底層錯誤信息只會在API日志里出現(xiàn)界面上根本看不到。6. 常見問題與排查實錄6.1 實例無法獲取IP這是我遇到過最多的故障幾乎每次都會有人來問。云主機創(chuàng)建成功狀態(tài)是ACTIVE但進到系統(tǒng)里發(fā)現(xiàn)網(wǎng)卡沒有IP地址。排查路徑按順序來先看Neutron代理是否存活再看DHCP命名空間是否創(chuàng)建成功然后查看DHCP租約數(shù)據(jù)庫中是否有IP分配記錄。這三個環(huán)節(jié)任何一個中斷都會導(dǎo)致IP獲取失敗。我做過一次印象很深的排障所有代理都正常DHCP租約也有記錄但虛擬機就是拿不到IP。后來查了半天發(fā)現(xiàn)是物理節(jié)點iptables規(guī)則把DHCP請求的UDP 67端口攔掉了。解決方式是確認OpenStack所需的防火墻端口全部放行同時檢查宿主機自身的iptables規(guī)則是否干擾了虛擬機的DHCP流量。6.2 云主機創(chuàng)建失敗與日志定位云主機創(chuàng)建失敗的表現(xiàn)通常有兩種同步等待的時候狀態(tài)卡住或直接報錯說沒有可用主機。遇到這類問題我的第一反應(yīng)是看Nova調(diào)度器和計算節(jié)點的日志因為創(chuàng)建VM的主要工作都在這兩個節(jié)點上。日志路徑是/var/log/nova/重點看nova-compute.log和nova-scheduler.log。我整理過一份常見問題速查表故障現(xiàn)象可能原因排查命令/日志實例狀態(tài)一直BUILD鏡像格式錯誤或磁盤空間不足查看nova-compute.log報No valid hostPlacement資源數(shù)據(jù)不準確檢查Placement服務(wù)狀態(tài)連不上VNC控制臺控制臺代理地址配置錯誤查看nova.conf中vnc配置實例訪問外部超時路由或安全組規(guī)則問題openstack路由列表、安全組規(guī)則定位問題時不要只看表面報錯要順著日志里的時間戳和請求ID一層層往上翻。Nova組件之間的調(diào)用都有請求ID根據(jù)這個ID可以在各個服務(wù)日志中串聯(lián)出一條完整的調(diào)用鏈。6.3 服務(wù)狀態(tài)異常的排查路徑當某個服務(wù)啟動失敗或狀態(tài)異常時我有一套固定的排查順序第一步確認服務(wù)進程是否存在systemctl status查看。第二步查看對應(yīng)的日志文件通常位于/var/log/對應(yīng)服務(wù)目錄下。第三步檢查配置文件的語法和權(quán)限很多服務(wù)配置錯誤只是啟動時報錯但日志寫的比較模糊需要手動核對配置文件。還有一個經(jīng)常被忽略的細節(jié)OpenStack各服務(wù)運行的用戶和用戶組不同如果日志目錄權(quán)限不對服務(wù)啟動時寫日志就會失敗導(dǎo)致服務(wù)重啟后一直處于異常狀態(tài)。我在某次部署中遇到過Neutron服務(wù)反復(fù)重啟查了一圈最后發(fā)現(xiàn)是日志目錄屬主不對調(diào)整權(quán)限后服務(wù)立刻恢復(fù)了。注意生產(chǎn)環(huán)境中重啟某個服務(wù)前務(wù)必確認是否影響正在運行的業(yè)務(wù)。例如重啟計算節(jié)點上的nova-compute服務(wù)會中斷該節(jié)點上所有運行中的虛擬機。在測試環(huán)境隨便重啟沒什么關(guān)系但生產(chǎn)環(huán)境一定要先規(guī)劃好維護窗口。7. 寫在最后的運維心得OpenStack這套東西部署只是萬里長征第一步。真正拉開差距的是后續(xù)的監(jiān)控、告警、備份、升級、故障恢復(fù)這些運維能力。我后來在給某公司做內(nèi)部支持時最深的體會是部署文檔到處都是但“如何優(yōu)雅地運維”才是真正有門檻的部分。我現(xiàn)在只要搭完一套環(huán)境會立刻把所有的配置分區(qū)、服務(wù)節(jié)點、賬號信息、網(wǎng)絡(luò)規(guī)劃整理成一份清單放在團隊統(tǒng)一的知識庫里。這份清單在故障排查和人員交接時的價值比任何部署文檔都大。另外強烈建議把OpenStack各服務(wù)的配置目錄納入版本管理哪怕只有兩個人協(xié)作也能避免“我改了配置文件但忘了改了什么”這種尷尬局面。如果你正準備開始搭建自己的OpenStack云平臺就從最精簡的兩節(jié)點架構(gòu)開始先跑通再談優(yōu)化。等你的環(huán)境里有了監(jiān)控、有了備份、有了灰度升級的流程再回頭看第一天的搭建過程會發(fā)現(xiàn)很多當初覺得莫名的坑其實都是架構(gòu)規(guī)劃時埋下的雷。