OpenStack運維面試(1)

 

   確實有好久都沒寫博客了,這篇題目筆記是本身經歷的,也有本身思考的,已經有很長時間纔算寫完這30道。說說本身的情況吧,首先說爲何是OpenStack運維面試呢,由於以前在一家OpenStack雲計算公司實習,時間不長,只有20天,我就離職了,是我本身主動要辭的。說實話,仍是不錯了,實習4K,週末雙休,不加班,不值夜班,坐辦公室學習,這簡直超乎了個人意料,確實跟我想象的運維工程師不太同樣。這種上班的感受仍是挺不錯的,我相信我過不了多久作下一份工做的時候,回憶起來確定以爲這簡直太幸福了。我面試準備了那麼久,好不容易找到一個工資不錯的公司,雖然只是實習,仍是一個朝氣蓬勃的行業和公司,說離開就離開估計是誰都想不通。唉,其實我本意也不想離開,可是我「闖禍了」,呵呵,倒不是技術上,而是說話上,還不是口頭,只是郵件。事情是這樣的,我也想吐槽,這真的很小氣。php

   原本讓我當天去偏僻的「DB」甲方公司看項目的,剛好那天讓我去搬防火牆(真尼瑪重!),那天回來後,通知我還讓我去,我什麼都沒準備啊,次日跑了好遠的路,天天的開銷不小,那一天啥事都沒有作,我連網都上不了。說是「看」,還算有點小見識,可是我真的感受還不會,也確實沒啥技術含量,就想下次回公司修煉一段時間再說,就是不來了。剛好那一週我給本身步驟的任務是一週內完成OpenStack平臺的搭建,各類事情的耽擱讓我有點慌,那天很早就下班,我跟個人上級說我不去甲方了,可是沒有跟項目經理說(其實我不想當面說的)。元旦回來,星期二我就發郵件說「我不去了,有見識但技術上沒啥收穫」,就這麼簡短的一句話,呵呵,那些所謂的領導就炸了,以爲我不服從管理,好高騖遠,狂妄自大吧,項目經理也回覆我了,感受是生氣的樣子。這幾天,剛好招我進來的HR休假了吧,部門老大以及直屬上級都找我談話,我也知道本身說話確實不過小心,這2我的仍是沒怎麼批評我,仍是對我挺好的,幫我洗黑,說實話,我感謝!html

   平靜的過了幾天,我覺得沒事了,沒想到,HR回來倒找我了,想讓我轉崗,以爲我不合適作運維,溝通能力很差,性格不合,怎麼可能呀,我花了那麼多時間,從網絡轉運維,費了多少力氣,現在再讓我轉軟件,簡直天方夜譚,貌似着是委婉趕我走的意思。整個下午我什麼事情都不想作,想一想本身,爲什麼命運多舛,以前面試的時候還有1家公司給我offer了,問的比較難,還好答得中規中矩,還跟我籤三方協議,可是工資過低,我就去了openstack公司,期間實習的時候還有2家公司面試都拒了。唉,沒想到,很快就又要面試了,我把公司電腦上全部東西都刪了,原來什麼樣就是什麼樣,跟帶個人人說了句我走了,就離開了,那天我哭了,有點小難過,只能說準備春招吧。linux

   回來了墮落了很久,徹底不想學習,接下來的簡歷我也不知道怎麼準備了,反正又是大變化。畢業設計也是特麼難搞,說句很差聽的,我尼瑪過年都有人問有女友了沒,真沒有啊,混得垃圾呀,身邊比我小的也結婚了,咱仍是...壓力大呀nginx

   技術、社交、生活,學的東西太多了,煩!下面好好準備春招吧,不投實習崗位了!web




一、如何刪除一個文本中的空白行,好比一行有字,而後一行空白,再有一行字?面試

[root@www]cat 1.txt算法

===========================數據庫

yhc apache


is swift


very 


good !

===========================

答:sed  '/^$/d' 1.txt   ##注意這裏不能加-n靜默選項。另外可使用cat 1.txt|tr "\n" " " 讓它變成一行英語語句


二、請解釋下怎麼進行location匹配的規則?(我以爲這個很是難以理解,多虧有視頻啊!看懂這個,對Nginx自信爆漲)

答:精確匹配>普通匹配>正則匹配

分析:首先是URI解析,找到第一個精確匹配的,若是命中精確匹配,那麼完全結束了,再也不進行下面的location匹配了,若是沒有精確命中,那麼就去尋找多個普通匹配的,普通匹配跟編輯location語句的順序沒有關係,若是普通匹配命中多個,那麼記憶匹配最長的(好比/aaa/bbb/)的結果,若是命中一個,那麼也記憶普通匹配的結果(注意,這裏並未完全結束),不管普通匹配有無命中,都要去尋找正則匹配,正則匹配跟編輯location的順序有關(必定是正則1不知足才找正則2),若是第一個正則匹配成功,則當即跳出,返回該正則匹配下的結果,也完全結束了,若是正則一個都沒有匹配成功,則返回前面普通匹配記憶的結果。

參考視頻:(燕十八location流程圖解) http://www.icoolxue.com/play/7027


三、Nginx如何拒絕某一我的來訪問?(對比上篇博客提到的apache只容許某個IP訪問)

答:在location上下文中添加If語句,若是$remote_addr是某個IP的話,直接返回403 forbidden

-----------------------------------------------------------------------------------------

location / {

root html;

index index.php index.html;

if ($remote_addr = 192.168.1.100) {         ##if 空格 (條件),不要忘了空格

return 403;

}

}

------------------------------------------------------------------------------------------


四、當瀏覽器訪問一個Nginx不存在的頁面時,如何返回404頁面?(感受這些問題很常見,可是沒怎麼想過具體怎麼作)

答:在location字段添加if語句,若是請求的文件名不存在,rewrite重寫到咱們人爲定義的404頁面,可是必需要加break,再也不進行下一輪UEI的匹配。rewrite到新的uri後進入另一個location,剛好這個location也有rewrite,再次重寫的uri又調回原來的location,這樣就是死循環了,最多執行10次,而後報500錯誤。本例中$document_root$fastcgi_script_name是客戶端傳過來的參數(好比test.html),而不是咱們服務端定義的網頁文檔!

-----------------------------------------------------------------------------------------------------------

location / {

root html;

index index.php index.html;

if (!-e $document_root$fastcgi_script_name){

rewrite ^.*$ /404.html break;  ##這條語句表示任意文件名到/usr/local/nginx/html/404.html

}

}

-----------------------------------------------------------------------------------------------------------


五、用什麼命令能夠看到整個目錄下的內容。

答:tree /usr/local/svn/svndata/


六、介紹下prefork和worker?(唉,這一點表述的很差,記不住了,event模式應該是nginx和apache都有的,都是一個進程處理多個請求)

答:(1)Prefork MPM實現了一個非線程的、預派生的web服務器。它在Apache啓動之初,root控制進程在最初創建「StartServers」個子進程後,

爲了知足MinSpareServers設置的須要建立一個進程,等待一秒鐘,繼續建立兩個,再等待一秒鐘,繼續建立四個……如此按指數級增長建立的進程數,最多達到每秒32個,直到知足MinSpareServers設置的值爲止。這種模式能夠沒必要在請求到來時再產生新的進程,從而減少了系統開銷以增長性能。而後等待鏈接;能夠減小頻繁建立和銷燬進程的開銷,每一個子進程只有一個線程,在一個時間點內,只能處理一個請求。這是一個成熟穩定,能夠兼容新老模塊,也不須要擔憂線程安全問題,可是一個進程相對佔用資源,消耗大量內存,不擅長處理高併發的場景。

(2)worker使用了多進程和多線程的混合模式,worker模式也一樣會先預派生一些子進程,而後每一個子進程建立一些線程,同時包括一個監聽線程,每一個請求過來會被分配到一個線程來服務。線程比起進程會更輕量,由於線程是經過共享父進程的內存空間,所以,內存的佔用會減小一些,在高併發的場景下會比prefork有更多可用的線程,表現會更優秀一些;另外,若是一個線程出現了問題也會致使同一進程下的線程出現問題,若是是多個線程出現問題,也只是影響Apache的一部分,而不是所有。因爲用到多進程多線程,須要考慮到線程的安全了。

參考文檔:http://www.mamicode.com/info-detail-1212491.html


七、Nginx的master進程和worker進程工做原理?

答:Nginx採用異步非阻塞的方式來處理網絡事件,相似於Libevent。Nginx服務一啓動後,master進程先建好須要listen的socket後,而後再fork出多個worker子進程,這樣每一個worker進程均可以去accept這個socket。當一個client鏈接到來時,全部accept的worker進程都會受到通知,但只有一個進程能夠accept成功,其它的則會accept失敗。Nginx提供了一把共享鎖accept_mutex來保證同一時刻只有一個worker進程在accept鏈接,從而解決驚羣問題。當一個worker進程accept這個鏈接後,就開始讀取請求,解析請求,處理請求,產生數據後,再返回給客戶端,最後才斷開鏈接,這樣一個完整的請求就結束了。

參考文檔:http://blog.chinaunix.net/uid-24517549-id-3977650.html


八、描述系統的啓動過程?當用戶登陸上系統後,linux系統爲用戶作了什麼任務?(拓麻的這個問題我吞吞吐吐的才說出好幾個,之前沒思考過這些問題,謝天謝地終於問了我那個背了好久的啓動過程,還好避免了悲劇)

答:(1)讀取/etc/passwd文件進行身份驗證。

(2)將用戶登陸信息寫入安全日誌裏面。

(3)啓動該用戶的環境變量 (而後引伸出環境變量的一系列問題,我不知道)

(4)


九、如何讓域名擁有多個IP地址?客戶端來解析的時候,返回的是哪條記錄?(後面這個問題我不清楚,當時猜想是第一條,如今想起來,真尼瑪×××,這特麼不就是DNS輪詢嗎?確定是一個客戶端返回第一個,另外一個客戶端返回第二個,而後這樣週期性的順序調度)

答:DNS給域名設置多條主機A記錄便可。不一樣客戶端可能返回不一樣記錄,根據輪詢指定哪一個IP地址返回給哪些客戶端。


十、說說TCP的擁塞控制。(果真是雲計算企業呀,畢竟互聯網,拓麻的這個問題勞資一時想不起來呀,我還寫的精通TCP/IP,其實這個問題

我整理過,表現不太完美)

答:(1)慢啓動算法做用在TCP數據傳輸的開始階段,當主機開始發送數據時,由於不知道網絡中的負荷狀況,若是當即發送大量的數據,有可能會引發網絡的擁塞。所以,TCP採用試探的方法,逐漸增大擁塞窗口。一般在剛開始發送數據報文段時,先將擁塞窗口cwnd設置爲一個TCP最大段長度MSS的值。而在每收到N個數據報文段的確認後,cwnd就增長一個MSS的數值(就是增大一倍,因此是指數型)。這樣就能夠逐漸增大發送端的擁塞窗口,使數據注入網絡的速率比較合理。

(2)爲了防止擁塞窗口增加過快而引發網絡擁塞,TCP還須要設置一個慢啓動閾值ssthresh,當擁塞窗口的值增長到ssthresh時,就要減緩擁塞窗口的增加速度,具體的作法是每通過一個RTT,擁塞窗口cwnd的值加1(單位爲MSS),這樣就可使cwnd按線性規律緩慢增加

(3)快速重傳算法的基本思想是:接收端每收到一個失序的數據報文段後就當即發出重複確認,以便更早地通知發送端有丟包的狀況發生。

(4)快速恢復是配合快速重傳使用的算法,其基本思想是:當發送端連續收到三個重複確認時,就將慢啓動閾值ssthresh減半,以預防網絡擁塞的發生,而且將擁塞窗口cwnd的值置爲減半後的ssthresh,而後開始執行擁塞避免算法,使得cwnd緩慢地加性增大。

參考文檔:https://www.nowcoder.com/discuss/6175


十一、用過啥抓包軟件?如何判斷網絡出現擁塞、***、延遲以及各類異常狀況?TCP的窗口在哪?(答得很差,根據序列號來判斷是我瞎說的,還好面試官原諒我沒經驗)

答:wireshark、tcpdump。

(1)分析是否有大量數據包的序列號混亂。

(2)分析是否有廣播地址存在。

(3)分析延遲多很少。(可是感受不容易,由於通常是看不出來延遲的,只是觀測一個源IP地址的數據包發出請求,而後看什麼位置目的端進行響應了該請求)


十二、若是我是小白,什麼叫作反向代理,Nginx的反向代理和負載均衡有什麼區別嗎?Nginx根據什麼來進行反向代理到後端服務器。(其實最後

一個問題當時除了URI根本答不出來其餘的)

答:反向代理:代理服務器監聽外網上的客戶端發出來的請求,並把該請求轉發給內網後臺的真實服務器進行處理,處理完畢後,先通過代理服務器緩存一份,然後,再經過代理服務器封裝http應答報文返回給客戶端。Nginx的經過location正則匹配URI代理到後端的服務器,而且在負載均衡upstream模塊,根據域名和端口代理到多臺後端服務器。(域名和端口這個怎麼能叫問題呢)

區別:(1)Nginx的反向代理和負載均衡沒有太大區別,基本的配置指令都同樣,可是反向代理提供緩存功能,因此能夠添加一些緩存命令行。

(2)代理到後端一臺服務器就能夠稱之爲反向代理,代理到後端多臺服務器就稱爲負載均衡,負載均衡是每臺機器都會分擔一些處理請求的壓力,負載均衡徹底能夠認爲是反向代理。

參考文檔:https://www.oschina.net/question/126236_119223


1三、爲何慢啓動算法中擁塞窗口要按指數級進行增加呢?擁塞窗口到底表明什麼意思?(之前真沒有好好想過擁塞控制,一旦本身面試遇到了,知道這玩意重要了)

答:擁塞窗口就是發送方在某次會話交互過程當中,在一個RTT(round trip time)週期內,可以發送的TCP報文段的數量多少。

緣由:(1)當TCP鏈接剛剛創建,準備要數據傳輸的時候,因爲不知道網絡的負載狀況,因此要去試探性檢測,只發出不多的數據包,擁塞窗口的值設的很小,我每發出N個數據幀,若是網絡不擁塞丟包,那麼就應該返回給我N個確認包,然後個人擁塞窗口就會在之前的基礎上增大一倍,說明我以前發出N個數據包是沒有問題的,不會堵塞,同時增大一倍提升發送效率。

(2)那麼每增大一倍,擁塞窗口的大小就是按着指數級別增加了。當增大到必定程度上,必須減緩發送速率,因而使用擁塞避免算法,讓擁塞窗口能夠線性增加,每收到一個確認,窗口就增大1個單位,當達到最大MSS(max segment size)時,擁塞窗口大小驟降,變爲原來慢啓動算法時候的窗口大小,一般爲1,而且門限值變爲MSS的一半,然後,如此往復。


1四、在OpenStack中,用戶PUT和GET都是同一個對象,說說存儲節點Swift存取的工做原理?

答:(1)上傳文件時,PUT請求通過負載均衡機器經過一致性哈希算法隨機選擇一臺代理服務器,再將請求轉發數據存儲節點,代理服務器經過查找本地的Ring(環)文件,包括account環、container環、object環選擇3個不一樣的區域(zone),zone保證了數據的副本不會都放在同一個存儲節點上,從而避免了單點故障的可能性,可使用3個磁盤來替代3個節點。然後,向3個數據節點都進行寫操做,只有當至少2個節點都確認寫成功後,再向用戶返回寫成功信息。

(2)然後,當用戶須要get請求該對象(對象=元數據+內容)下載文件時,也須要通過負載均衡隨機挑選一臺代理服務器,代理服務器上的環文件能

查詢到這個文件存儲在哪三個節點中,而後同時向後端查詢,當前僅當至少2個存儲節點表示能夠提供該文件,而後代理服務器才從中選擇一個節點下載文件。


1五、雲主機實例1和雲主機實例2彼此通訊,基於VXLAN的工做原理?(VTEP是Vxlan tunnel end point,VNI是vxlan的network identifier,虛擬機通訊還能夠

linux bridge)

答:(1)VM1要向VM2發送數據前,必需要知道VM2的MAC地址,其獲取過程以下:

         一、VM1發送ARP請求包,請求192.168.0.101[VM2_IP]的MAC地址;

         二、ARP請求包被VTEP1封裝成多播包,發給VNI=864的多播組;

         三、全部的VTEP接收此多播包,並添加(VNI–VTEP1–VM1_MAC Address)映射關係到本身的VXLAN表中;

         四、目的主機上的VTEP2接收到多播包後將其解開,並向本主機上VNI=864的全部虛擬機發送廣播包;

         五、VM2看到了ARP包後,迴應了本身的MAC地址;

         六、VTEP2再次封裝回應的單播包,經過路由發給VTEP1;

         七、VTEP1解包,並將包傳給VM1,則最終獲取了VM2的MAC地址;

         八、VTEP1將(VNI–VTEP2–VM2_MAC Address)映射關係添加到本身的VXLAN表中;

(2)VM1獲知VM2的MAC地址後,發送數據包,過程以下:

一、  VM1發送IP數據包到VM2,即192.168.0.100 到 192.168.0.101;

二、  VTEP1查找本身的VXLAN表知道要發給VTEP2,而後依次封裝如下數據包頭;

a)VXLAN包頭,VNI=864;

b)標準UDP包頭,校驗和checksum爲0x0000,目標端口號4789;

c)標準IP包頭,目標地址爲VTEP2的IP地址,協議號設爲0x11表面爲UDP包。

d)標準MAC數據包,目標地址爲下一跳設備(虛擬路由器)的MAC地址00:10:11:FE:D8:D2,可路由到目標隧道端VTEP2。

三、  VTEP2接收數據包,根據UDP的destination端口找到VXLAN數據包。接着查找全部所在VXLAN的VNI爲864的端口組,找到VM2的

四、  VM2接收並處理數據包,拿到Payload數據.(vxlan有2^24個邏輯網絡,因此稱爲擴展vlan)

參考文檔:http://www.aboutyun.com/thread-11189-1-1.html


1六、在OpenStack中,介紹什麼是浮動IP?什麼是元數據?

答:(1)OpenStack引入了一個叫浮動ip的概念,浮動ip是一些能夠從外部訪問的ip列表,一般從isp哪裏買來的。浮動ip缺省不會自動賦給實例,用戶須要手動從地址池裏抓取而後賦給實例。一旦用戶抓去後,他就變成這個ip的全部者,能夠隨意賦給本身擁有的其餘實例。若是實例死掉了的話,用戶也不會失去這個浮動ip,能夠隨時賦給其餘實例。暫時不支持爲了負載均衡多實例共享一個浮動ip。動IP地址可讓實例使用私有網絡鏈接到外部網絡,例如互聯網。而對於固定ip來講,實例啓動後得到的ip是自動的,不能指定某一個。因此當一個VM歇菜了,再啓動也許固定ip就換了一個。

(2)系統管理員能夠配置多個浮動ip池,這個ip池不能指定租戶,每一個用戶均可以去抓取。多浮動ip池是爲了考慮不一樣的isp服務提供商,省得某一個isp出故障帶來麻煩。若是運行的是企業雲,浮動ip池就是那些openstack外的數據中心都能訪問到的ip。浮動ip機制給雲用戶提供了不少靈活性,也給系統管理員減小了安全風險,儘可能只讓OpenStack軟件去改防火牆會安全些。

參考文檔:http://www.cnblogs.com/wcxy/p/3402006.html

元數據(Metadata):又稱中繼數據,描述爲數據的數據,主要是描述數據屬性(property)的信息,用來支持如指示存儲位置、歷史數據、資源查找、文件記錄等功能。


1七、講講Opnstack啓動虛擬機實例後,虛擬機的狀態是怎麼變化的?

答:(1)管理員發出建立虛擬機的命令,決定從鏡像文件或是快照文件進行啓動。

(2)當建立後,虛擬機實例進入Build狀態,任務狀態是Spawning孵化。

(3)期間,將會從控制節點上的Glance組件把相應的鏡像文件從中下載到Nova計算節點,並進行一些虛擬機的初始參數配置,如內存、CPU、磁盤空間。

(4)當一切正常後,虛擬機將會將會進入Active狀態,此後,用戶即可以使用雲主機了。建立實例的時間通常由鏡像文件的大小、網絡傳輸帶寬、以及建立的Hypervisor磁盤性能大小。

(5)虛擬機建立完畢,能夠通過Horzion的web界面進行管理,也能夠基於Python Nova client的命令行管理。


1八、說說OpenStakc各組件的做用?

答:(1)keystone負責爲每一個服務進行認證、受權、租戶管理、項目權限和配額以及服務目錄管理。

(2)Glance負責提供Nova建立實例所須要的鏡像文件,鏡像格式如raw、qcow2。

(3)Nova負責雲主機實例生命週期的管理,以及宿主機資源調度;Nova還決定了虛擬機實例在哪一臺Hypervisior物理機上運行。

(4)Horzion將用戶的http請求轉換爲RESTful請求,而後將RESTful請求分發給Nova API,進行實例的建立。

(5)cinder提供塊存儲,目的是用來作持久存儲的,典型軟件如ceph;swift提供對象存儲,用來文件共享的。

(6)neutron服務爲雲主機實例提供網絡服務,好比私有IP的地址分配問題,訪問外網的浮動IP、NAT路由、防火牆,以及雲主機實例彼此之間的vxlan通訊。


1九、談談你對OpentStack的認識?

答:OpenStack是一個分佈式系統,完成一件事,基本上都會涉及到一系列的組件,這些組件協同工做,在雲中扮演着各類角色。(而後就拿上面各組件的做用說,原理我看就算了,通常人說不清楚,對方也聽不懂,呵呵)


20、概述建立虛擬機的流程。(這個問題,很是值得思考,很容易被問到!)

答:(1)Horizon經過Keystone獲取nova-Compute組件的的訪問地址(即URL),並獲取令牌token。

(2)Horizion攜帶受權令牌,發送建立虛擬機指令。

(3)Nova-compute組件經過glance-api下載虛擬機鏡像,glance鏡像中有緩存機制,一般把緩存文件放入名爲_base的目錄,若是_base緩存沒有鏡像文件

,那麼就會從glance下載鏡像到base緩存,而後再從base緩存經過TCP/IP網絡複製到計算節點雲主機實例下的鏡像目錄裏。

(4)glance檢索後端鏡像,glance後端存儲不必定要使用swift,只要是存放鏡像文件的系統均可以。

(5)獲取網絡信息,決定虛擬機的網絡模式以及創建網絡鏈接。

(6)nova-compute發送啓動虛擬機指令,至此通過虛擬機服務任務狀態的變化,正常事後建立便可完成。


2一、若是我有多個計算節點,那麼我啓動一個雲主機實例,那麼我怎麼知道該實例在哪臺計算節點上運行呢?(嗯...因缺絲婷)

答:命令查看...



2二、PXE的工做原理?

答:實現自動獲取IP網絡安裝linux是這樣的:客啓端PXE網卡啓動-->經過Bootp協議廣播dhcp請求-->DHCP服務器-->獲取IP,TFTP服務器地址-->從TFTP上下載 pxelinux.0以及系統內核文件vmlinuz、initrd.img-->啓動系統-->(到指定url去下載ks.cfg文件-->根據ks.cfg文件去NFS/HTTP/FTP服務器自動下載軟件包)安裝系統-->完成安裝。

DHCP server爲客戶端分配ip並提供TFTP服務器地址及PXE啓動文件位置,TFTP server爲客戶端提供引導文件



2三、建立網絡時,Neutron作了什麼?

答:建立虛擬機時,Neutron會根據選擇的網絡,首先給虛擬機分配一個tap設備做爲虛擬的網卡,命名爲tapXXX , XXX是一串數字和字母的組合,用來標識的,譬如tap8eaf6158-80,

在系統中使用ifconfig命令能夠看到新增了這個網口。創建一個Linux網橋,命名爲

qbr8eaf6158-80。把上面那個新增的tap網口接在這個qbr的交換機上,使用命令「brctl

show」能夠列出存在的網橋設備和端口。如今,虛擬機上已經有了一個接在虛擬網橋上的網

口,接下來是如何把這個網口與OVS的br-tun鏈接起來。

    這時會有一對veth設備出現。veth是Linux中的虛擬網絡設備,老是成對出現,一對veth設備的數據老是從一個流人,

從另外一個流出。Neut1-on會創建一對分別命名爲qvbXXX

和qvoXXX的veth設備,而且把它們分別鏈接到前面提到的qbr8eaf6158和br-int這兩個交

換機上。可使用命令「brctl show」和「ovs-vsctl show」分別查詢qbrXXX和br-int這兩個

交換機是否已經串聯起來了。


2三、saltstack中,master和minion各自幹了什麼事?

答:master:存放全部minion的公鑰、監聽mininon、發送命令給minion、存放一些爲minion準備的配置文件,如state、存放一些爲minion準備的files和數據,如apache2.cnf,pillar

minion:鏈接master、監聽master發送的commands、從master下載state而且執行state、能夠執行在minion上執行state,用salt-call,固然這個通常多數用於調試


2四、SSH的工做原理?

答:(1)SSH能夠基於帳戶密碼進行認證;SSH能夠基於密鑰對進行認證

(2)基於密鑰的安全認證就是本機提供一對公鑰和私鑰,把公鑰複製一份放在遠程服務器上面,遠程服務器的sshd進程監聽22號端口。當向遠程服務器發起請求的時候,本機會把公鑰發送給遠程服務器,遠程服務器會在家目錄下檢查公鑰是否一致,若是一致,就會把應答數據包使用公鑰加密後返回給客戶端,客戶端再使用本身的私鑰進行解密,獲得解密後的數據包,其中解密後的數據包含有會話密鑰,然後使用會話密鑰進行通訊。


2五、Zabbix有何特性?

答:數據收集、靈活的閾值定義、高級告警設置、實時繪圖、擴展的圖形化展現、歷史數據存儲、監控主機使用模板、自動發現網絡設備、提供Zabbix API。


2六、Zabiix包含了哪幾個進程,各有什麼做用?

答:(1)Zabbix_agentd:客戶端守護進程,收集本機的數據

(2)Zabbix_get:Server端用於主動獲取被監控端數據

(3)Zabbix_sender:被監控端結合trapper進程,主動發送監控項收集的數據到Server或Proxy端

(4)Zabbix_server:服務端的守護進程,接受其餘進程發過來的數據

(5)Zabbix_proxy:代理守護進程,功能相似於Server,不過它只是一箇中轉站,把收集到的數據再提交給Server,跨機房和地區須要用到



2七、zabbix的server端如何去監控agent端?

答:原理:每個item都有其專用的key,zabbix服務器與被監控端進行通訊時就使用相應的協議或機制去質詢被監控端這個key的值,被監控端就調用此key所對應的腳本去獲取相應的數據並返回給服務端。


2八、監控中,歷史數據和歷史趨勢數據有何區別?

答:歷史數據:指的是採樣的數據。指定存儲在數據庫中的天數,若是超過該閾值,那麼會被housekeeper進程給清理掉

歷史趨勢數據:指的是每小時的最大值、最小值、平均值以及各類統計。


2九、說一下,在zabbix監控某個主機的時候,人爲應該部署哪些步驟?

答:建立主機、附加模板,修改item監控項,建立圖形(關聯Item),定義觸發器,建立用戶,建立事件、建立action


30、若是有100臺服務器,每臺服務器有30個監控項,每一個監控項60秒刷新一次,須要多大的硬盤呢?

答:隨着監控項的數量增多以及監控值的實時刷新,數據庫也會愈來愈龐大,那麼影響Zabbix硬盤大小的因素有:

(1)監控值每秒中存儲的數據量:100x30/60=50個  

(2)歷史記錄保存時間

(3)趨勢數據保存時間

(4)事件記錄保存時間 (報警、恢復)

(5)數據庫引擎以及數據類型(整型、浮點型、字符型)

綜上:數據庫硬盤空間=配置文件大小+歷史記錄+趨勢記錄+事件記錄

相關文章
相關標籤/搜索