Openstack日常運(yùn)維

1、Openstack日常運(yùn)維目錄1. 運(yùn)維工作內(nèi)容2. 維護(hù)與診斷3. 標(biāo)準(zhǔn)化修復(fù)與例行檢查4. 日志與監(jiān)控5. 備份與恢復(fù)6. 故障解決思路運(yùn)維工作內(nèi)容 參與設(shè)計(jì)、審核、優(yōu)化公司IT系統(tǒng)基礎(chǔ)設(shè)施以及各應(yīng)用系統(tǒng)的體系架構(gòu)； 全面負(fù)責(zé)公司運(yùn)維項(xiàng)目的系統(tǒng)升級(jí)、擴(kuò)容需求與資源落實(shí)，配合開發(fā)需求，測試、調(diào)整運(yùn)維平臺(tái)； 負(fù)責(zé)網(wǎng)絡(luò)以及交換機(jī)、路由器、服務(wù)器的網(wǎng)絡(luò)設(shè)置、維護(hù)和優(yōu)化、網(wǎng)絡(luò)的安全監(jiān)控、系統(tǒng)性能管理和優(yōu)化、網(wǎng)絡(luò)性能管理和優(yōu)化； 建立面向開發(fā)部門，業(yè)務(wù)部門的服務(wù)流程和服務(wù)標(biāo)準(zhǔn)； 負(fù)責(zé)IT運(yùn)維相關(guān)流程的規(guī)劃、設(shè)計(jì)、推行、實(shí)施和持續(xù)改進(jìn)； 負(fù)責(zé)設(shè)計(jì)并部署相關(guān)應(yīng)用平臺(tái)（包括操作系統(tǒng)和基礎(chǔ)服務(wù)組件、自動(dòng)化部署

2、配置工具），并提出平臺(tái)的實(shí)施、運(yùn)行報(bào)告； 負(fù)責(zé)配合開發(fā)搭建測試平臺(tái)，協(xié)助開發(fā)設(shè)計(jì)、推行、實(shí)施和持續(xù)改進(jìn)； 負(fù)責(zé)相關(guān)故障、疑難問題排查處理，編制匯總故障、問題，定期提交匯總報(bào)告； 負(fù)責(zé)云服務(wù)產(chǎn)品監(jiān)控和應(yīng)急反應(yīng)，以確保云服務(wù)產(chǎn)品有7*24小時(shí)的持續(xù)運(yùn)行能力； 負(fù)責(zé)日常系統(tǒng)維護(hù)巡檢工作及監(jiān)控，提供IT軟硬件方面的服務(wù)和支持，保證系統(tǒng)的穩(wěn)定。維護(hù)與診斷1. 采用高可用部署2. 計(jì)劃內(nèi)停機(jī)盡量采用非高峰使用停機(jī)3. 計(jì)劃外停機(jī)，提供備用機(jī)替換或利用編寫好的安裝配置腳本腳本重新部署新機(jī)上線4. 實(shí)時(shí)監(jiān)測服務(wù)進(jìn)程，進(jìn)程當(dāng)機(jī)后利用自動(dòng)腳本重啟服務(wù)5. pstree -a控制節(jié)點(diǎn)控制節(jié)點(diǎn)計(jì)算節(jié)點(diǎn)計(jì)算節(jié)點(diǎn)1. 計(jì)

3、劃內(nèi)停機(jī)前，將宿主機(jī)內(nèi)的虛擬機(jī)進(jìn)行遷移，維護(hù)完成后恢復(fù)虛機(jī)2. 檢查服務(wù)進(jìn)程 ps aux|grep nova-compute3. 通過日志文件/var/log/nova/nova-compute檢查恢復(fù)問題虛擬機(jī)4. 利用qemu-nbd命令掛載虛擬機(jī)磁盤到本地設(shè)備，檢查修復(fù)失敗的虛擬機(jī)5. 利用nova volume-detach 和nova volume-attach重新掛載卷存儲(chǔ)6. 使用共享存儲(chǔ)的虛機(jī)實(shí)在無法啟動(dòng)，可以新建虛機(jī)掛在其他宿主節(jié)點(diǎn)7. 可以利用恢復(fù)/var/lib/nova/instances恢復(fù)虛機(jī)機(jī)8. pstree -a維護(hù)與診斷ip -a檢查網(wǎng)卡狀態(tài)檢查網(wǎng)卡狀態(tài)t

4、cpdump檢查連通性檢查連通性 ping檢查網(wǎng)絡(luò)檢查網(wǎng)絡(luò)檢查檢查DHCPNova console-log ps aux|grep dnsmasqtcpdump標(biāo)準(zhǔn)化修復(fù)與例行檢查標(biāo)準(zhǔn)化修復(fù)：標(biāo)準(zhǔn)化修復(fù)與例行檢查例行檢查：日志與監(jiān)控定位錯(cuò)誤產(chǎn)生操作錯(cuò)誤后，分析操作可能的API調(diào)用過程, 逐步檢查API日志定位可能的問題點(diǎn)日志與監(jiān)控日志與監(jiān)控如果查詢各個(gè)節(jié)點(diǎn)日志比較麻煩，最終可以建立一個(gè)專門的日志服務(wù)器集中管理日志日志與監(jiān)控如果查詢各個(gè)節(jié)點(diǎn)日志比較麻煩，最終可以建立一個(gè)專門的日志服務(wù)器集中管理日志日志與監(jiān)控預(yù)警：日志與監(jiān)控日志與監(jiān)控日志與監(jiān)控趨勢預(yù)測：日志與監(jiān)控備份與恢復(fù)數(shù)據(jù)庫備份：備份與恢復(fù)數(shù)

5、據(jù)庫備份：備份與恢復(fù)文件備份：備份與恢復(fù)文件備份：備份與恢復(fù)文件備份：備份與恢復(fù)數(shù)據(jù)恢復(fù)：1.數(shù)據(jù)庫恢復(fù)2.配置文件恢復(fù)3.其他文件恢復(fù)故障解決思路故障的表現(xiàn)是什么？無響應(yīng)？報(bào)錯(cuò)？故障是什么時(shí)候發(fā)現(xiàn)的？故障是否可重現(xiàn)？有沒有出現(xiàn)的規(guī)律（比如每小時(shí)出現(xiàn)一次）最后一次對(duì)整個(gè)平臺(tái)進(jìn)行更新的內(nèi)容是什么（代碼、服務(wù)器等）？故障影響的特定用戶群是什么樣的(已登錄的, 退出的, 某個(gè)地域的)?基礎(chǔ)架構(gòu)（物理的、邏輯的）的文檔是否能找到?是否有監(jiān)控平臺(tái)可用? （比如Munin、Zabbix、 Nagios、 New Relic 什么都可以）是否有日志可以查看?（比如Logstack系統(tǒng)筆記的云日志服務(wù)）一、盡

6、可能搞清楚問題的前因后果故障解決思路二、有誰在?$ w$ last 故障解決思路三、之前發(fā)生了什么?$ history 故障解決思路四、現(xiàn)在在運(yùn)行的進(jìn)程是啥?$ pstree -a $ ps aux故障解決思路五、監(jiān)聽的網(wǎng)絡(luò)服務(wù)$ netstat ntlp$ netstat -nulp $ netstat -nxlp故障解決思路六、CPU 和內(nèi)存$ free -m $ uptime $ top $ htop 注意以下問題:還有空余的內(nèi)存嗎? 服務(wù)器是否正在內(nèi)存和硬盤之間進(jìn)行swap?還有剩余的CPU嗎? 服務(wù)器是幾核的?是否有某些CPU核負(fù)載過多了?服務(wù)器最大的負(fù)載來自什么地方?平均負(fù)載是多少

7、?故障解決思路七、硬件$ lspci $ dmidecode $ ethtool故障解決思路八、IO 性能$ iostat -kx 2 $ vmstat 2 10 $ mpstat 2 10 $ dstat -top-io -top-bio 這些命令對(duì)于調(diào)試后端性能非常有用。 檢查磁盤使用量：服務(wù)器硬盤是否已滿? 是否開啟了swap交換模式 (si/so)? CPU被誰占用：系統(tǒng)進(jìn)程? 用戶進(jìn)程? 虛擬機(jī)? Dstat 用它可以看到誰在進(jìn)行 IO故障解決思路九、掛載點(diǎn) 和 文件系統(tǒng)$ mount $ cat /etc/fstab $ vgs $ pvs $ lvs $ df -h $ lsof

8、 +D / /* beware not to kill your box */ 一共掛載了多少文件系統(tǒng)?有沒有某個(gè)服務(wù)專用的文件系統(tǒng)? (比如MySQL?)文件系統(tǒng)的掛載選項(xiàng)是什么： noatime? default? 有沒有文件系統(tǒng)被重新掛載為只讀模式了？磁盤空間是否還有剩余?是否有大文件被刪除但沒有清空?如果磁盤空間有問題，你是否還有空間來擴(kuò)展一個(gè)分區(qū)故障解決思路十、內(nèi)核、中斷和網(wǎng)絡(luò)$ sysctl -a | grep . $ cat /proc/interrupts $ cat /proc/net/ip_conntrack /* may take some time on busy se

9、rvers */ $ netstat $ ss -s 你的中斷請(qǐng)求是否是均衡地分配給CPU處理，還是會(huì)有某個(gè)CPU的核因?yàn)榇罅康木W(wǎng)絡(luò)中斷請(qǐng)求或者RAID請(qǐng)求而過載了？ SWAP交換的設(shè)置是什么？對(duì)于工作站來說swappinness 設(shè)為 60 就很好, 不過對(duì)于服務(wù)器就太糟了：你最好永遠(yuǎn)不要讓服務(wù)器做SWAP交換，不然對(duì)磁盤的讀寫會(huì)鎖死SWAP進(jìn)程。 conntrack_max 是否設(shè)的足夠大，能應(yīng)付你服務(wù)器的流量? 在不同狀態(tài)下(TIME_WAIT, )TCP連接時(shí)間的設(shè)置是怎樣的？ 如果要顯示所有存在的連接，netstat 會(huì)比較慢， 你可以先用 ss 看一下總體情況。 你還可以看一下 L

10、inux TCP tuning 了解網(wǎng)絡(luò)性能調(diào)優(yōu)的一些要點(diǎn)。故障解決思路十一、系統(tǒng)日志和內(nèi)核消息$ dmesg $ less /var/log/messages $ less /var/log/secure $ less /var/log/auth 查看錯(cuò)誤和警告消息，比如看看是不是很多關(guān)于連接數(shù)過多導(dǎo)致？ 看看是否有硬件錯(cuò)誤或文件系統(tǒng)錯(cuò)誤? 分析是否能將這些錯(cuò)誤事件和前面發(fā)現(xiàn)的疑點(diǎn)進(jìn)行時(shí)間上的比對(duì)。如果你有多臺(tái)機(jī)器,看起來很不方便,可以事先把日志存儲(chǔ)在系統(tǒng)筆記的云日志服務(wù)器上,支持全文模糊查找故障解決思路十二、定時(shí)任務(wù)$ ls /etc/cron* + cat $ for user in $

11、(cat /etc/passwd | cut -f1 -d:); do crontab -l -u $user; done 是否有某個(gè)定時(shí)任務(wù)運(yùn)行過于頻繁? 是否有些用戶提交了隱藏的定時(shí)任務(wù)? 在出現(xiàn)故障的時(shí)候，是否正好有某個(gè)備份任務(wù)在執(zhí)行？故障解決思路十三、應(yīng)用系統(tǒng)日志這里邊可分析的東西就多了, 不過恐怕你作為運(yùn)維人員是沒功夫去仔細(xì)研究它的。關(guān)注那些明顯的問題，比如在一個(gè)典型的LAMP（Linux+Apache+Mysql+Perl）應(yīng)用環(huán)境里: Apache & Nginx; 查找訪問和錯(cuò)誤日志, 直接找 5xx 錯(cuò)誤, 再看看是否有 limit_zone 錯(cuò)誤。這里查看了下,并沒有503的,只有403的錯(cuò)誤.所以可以跳過 MySQL; 在mysql.log找錯(cuò)誤消息，看看有沒有結(jié)構(gòu)損壞的表， 是否有innodb修復(fù)進(jìn)程在運(yùn)行，是否有disk/index/query 問題. PHP-FPM; 如果設(shè)定了 php-slow 日志,