運(yùn)維培訓(xùn)_day4-01其余組件

1、其余通用組件EasyStack Inc.集群狀態(tài)檢查#確保集群中的節(jié)點(diǎn)都是運(yùn)行狀態(tài)rootnode-1 #-e showus |grepng_addresses、分別是集群中的3個(gè)Controller節(jié)點(diǎn)，任何一個(gè)沒有出現(xiàn)在上面截圖中的輸出都應(yīng)該是出了問題。需要登錄該節(jié)點(diǎn)，查看/var/log/d.log檢查該節(jié)點(diǎn)的狀態(tài)。#確保是同步的rootnode-1 #ws-e show sentus | grep集群狀態(tài)檢查#確保wsrep同步完成rootnode-1 #-e showus | grepwsrep_ready！注意：手動(dòng)重起集群，比如用命令resource restart clone_

2、p_集群要求必須至少有一個(gè)活的節(jié)點(diǎn)，所以不能將集群全部關(guān)閉，如果要關(guān)閉，要做相應(yīng)設(shè)置才能恢復(fù)。如果三個(gè)controller上的服務(wù)全部出問題，不會(huì)影響已如創(chuàng)建虛機(jī)，運(yùn)行關(guān)閉虛機(jī)等）。運(yùn)行的虛機(jī)， 但無法對(duì)云進(jìn)行操作（集群狀態(tài)檢查rabbitmq集群狀態(tài)#確保所有的節(jié)點(diǎn)都在running。以root用戶執(zhí)行如下命令rootnode-1 # rabbitmqctlclusterus需要關(guān)注running_nodes里面是否有3個(gè)節(jié)點(diǎn)在運(yùn)行，如果沒有，說明rabbitmq集群存在問題，需對(duì)有問題的節(jié)點(diǎn)進(jìn)行處理。#確保所有的節(jié)點(diǎn)能list queuesrootnode-1 # rabbitmqctl

3、list_queuesRabbitMQ狀態(tài)檢查如果RabbitMQ出問題， 不會(huì)影響已運(yùn)行的虛機(jī)， 但無法對(duì)云進(jìn)行操作（如創(chuàng)建虛機(jī)，運(yùn)行關(guān)閉虛機(jī)等）?？墒褂妹钪貑⑾㈥?duì)列resource restart p_rabbitmq-server此動(dòng)作不會(huì)對(duì)虛機(jī)造成影響。Pacemaker狀態(tài)檢查pacemaker管理的各服務(wù)集群狀態(tài)檢查rootnode-1 #us磁盤空間檢查檢查磁盤空間在每個(gè)節(jié)點(diǎn)運(yùn)行rootnode-1 # dfFilesystem/dev/mapper/os-root tmpfs/dev/sda3-hSize36G63GUsed Avail Use% Mounted on50G

4、12G25%37M/63G1%/dev/shm194M28M156M16%/boot/dev/mapper/mongo-mongodb1.1T74G919G8%/var/lib/mongo主要是log和的db log 占據(jù)的空間比較大以下在控制節(jié)點(diǎn)執(zhí)行，找到占用空間較大的logrootnode-1 # du -sh /var/log/* | sort-h如果log過大，空間不夠，不要?jiǎng)h除源文件使用下列命令清除logecho filename常見問題處理RabbitMQRabbitMQ問題檢查方法： rabbitmqctl cluster_|tail相關(guān)問題：消息隊(duì)列無法列出，或有大量消息卡死u

5、s;rabbitmqctl list_queues | sort-k2n兩個(gè)檢查命令，前者是檢查消息隊(duì)列集群狀態(tài)，后者是檢查是否有消息卡死。 如果無法正常列出，基本上是由于控制節(jié)點(diǎn)內(nèi)存,cpu占用太高導(dǎo)致。 請(qǐng)查看控制節(jié)點(diǎn)資源占用情況。如過在list_queues命令執(zhí)行后，發(fā)現(xiàn)輸出的第二列不為0， 說明有消息卡在消息隊(duì)列中， 需要重啟消息隊(duì)列來嘗試解決。resource restart p_rabbitmq_server.消息隊(duì)列出問題，只會(huì)影響openstack令執(zhí)行，不會(huì)影響現(xiàn)有虛機(jī)。也可通過修改ocf文件，將rabbitmq集群從pacemaker中取出， 通過rabbitmqctl

6、join命令，來重新組成集群。rabbitmqctl join_cluster rabbitnode-1MongoDB問題數(shù)據(jù)mongodb的ceilometer庫的用戶名和在 /etc/ceilometer/ceilometer.conf,的配置項(xiàng)connection=mongodb:/ceilometer:ZOJwyj7O,/ceilometer登錄方法mongo ceilometer -uceilometer -p ZOJwyj7O需要s的數(shù)據(jù)庫有meter, s istics900istics300, sistics60, sistics7200,istics86400, s如果直接一

7、個(gè)庫執(zhí)行如meterdb.meter.remove(）如果清除某一個(gè)時(shí)間之前的數(shù)據(jù)db.meter.remove(timest:$lt:ISODate(2014-15-01T19:30:07.805Z);MongoDB問題緩存使用admin用戶登錄后，在主節(jié)點(diǎn)上緩存命令：mand(closeAllDatabases:1)然后重啟secondary節(jié)點(diǎn)mongod進(jìn)程即可/etc/init.d/mongod restartMongoDB升級(jí)mongodb 3.0版本加入許多新特性，主要加入了新的擎，WiredTiger主要有如下特點(diǎn)：1、 文檔鎖引擎WiredTiger。相比較之前版本默認(rèn)的MM

8、AP引以前的版本是庫鎖，現(xiàn)在WiredTiger通過多版本控制（MVCC）實(shí)現(xiàn)了文檔鎖，很大的提高了并發(fā)性能2、 壓縮WiredTiger引擎支持三個(gè)壓縮模式，none（不壓縮），snappy（默認(rèn)），zlib（壓縮級(jí)別最高）3、 內(nèi)存限制以前版本的mongodb對(duì)內(nèi)存使用是不能控制的，有時(shí)候會(huì)出現(xiàn)內(nèi)存大量被cache，并使用交換分區(qū)?，F(xiàn)在可以通過參數(shù)控制內(nèi)存使用量。常見問題處理問題檢查var/lib空間，所有的數(shù)據(jù)都放在下面du -sh/var/lib/* | sort -h3.9M/var/lib/pacemaker12M/var/lib/yum45M/var/lib/rpm169M/va

9、r/lib/ganglia418M/var/lib/其中/var/lib/的操作日志在控制節(jié)點(diǎn)上使用然后查看日志會(huì)一直增長，主要是命令進(jìn)入控制臺(tái)， show binary logs;常見問題處理比如刪除-bin.000417 之前的log purge binary logs to-bin.000417;常見問題處理常見問題us檢查方法：常見問題處理某些服務(wù)down掉出現(xiàn)failed action的報(bào)錯(cuò)日志管理的服務(wù)主要分為Load Balance模式和Active Standby模式兩種。均為三個(gè)控制節(jié)點(diǎn)組成的集群。 整個(gè)服務(wù)集群完全down掉的如果之前某個(gè)服務(wù)有過掉線的經(jīng)歷， 那么就會(huì)出現(xiàn)相

10、關(guān)的failed action日志。 確認(rèn)所有服務(wù)均正常后，即可用下列命令來清楚resource cleanup 可能性極小，如果出現(xiàn)，請(qǐng)盡快們。如果是某個(gè)節(jié)點(diǎn)，如node-2上的所有服務(wù)全部stop，那問題一般都會(huì)出在node-2本身的系統(tǒng)宕機(jī)或者管理網(wǎng)絡(luò)不通，請(qǐng)做相應(yīng)檢查。網(wǎng)絡(luò)檢查方法見后面“其余常見問題”部分。執(zhí)行resource restart時(shí)，長時(shí)間卡死。出現(xiàn)此情況一般是由于某個(gè)控制節(jié)點(diǎn)內(nèi)存或cpu占用率較高，導(dǎo)致resource restart命令長時(shí)間如果是某個(gè)節(jié)點(diǎn)上的某個(gè)服務(wù)down掉無法完成。 可嘗試用名來手動(dòng)停止進(jìn)程，resourtop 服務(wù) us中相關(guān)服 tart 服務(wù)

11、resource restart，可用來通過等待resours重啟該服務(wù)。 但重啟前最好下。們確認(rèn)一務(wù)后， 再重新名來啟動(dòng)。 與resource restart命令相同，總體來說， 三個(gè)節(jié)點(diǎn)同時(shí)down掉的幾率很小，至少到目前還沒遇到過。 只要每項(xiàng)服執(zhí)行前最好。們，確認(rèn)不影響正常業(yè)務(wù)運(yùn)行務(wù)有一個(gè)是alive的， 那么云不會(huì)受到影響。和虛機(jī)運(yùn)行均其余常用操作修改admin1. 在頁面上修改admin用戶生效。，修改后立即2. 修改控制節(jié)點(diǎn)下的openrc文件，找到。三個(gè)password一項(xiàng)，把原控制節(jié)點(diǎn)均需修改。修改成新3. 修改控制節(jié)點(diǎn)/etc/easystack/hagent.conf文件，

12、 在Auth下找到password參數(shù)， 將參數(shù)也同樣改成更新后的需修改。 三個(gè)控制節(jié)點(diǎn)均resource restart4.重啟hagent：easystack-hagent其余常用操作更換Logo#修改登陸界面ESCloud#修改登陸后，瀏覽器左上角的ES小logovi /usr/share/openstack-vi /usr/share/openstack-dashboard/easystack_dashboard/templates/audashboard/easystack_dashboard/templates/_es_styleth/_login.htmlsheets.html#注釋掉中郵消費(fèi)!-link rel=shortcuticon href=IC_URLdashboard/img/favicon.ico/-#重啟httpd服務(wù)#重啟httpd服務(wù)service httpd restartservice httpd restart-#修改登陸后，左上角的ES LOGO，#修改登陸后，瀏覽器左上角的ESCloudrm /usr/share/openstack-vi /etc/openstack-dashboard/local_settingsdashboard/ic/bootstrap/img/logo.png#S