nagios緩存

1. linux培訓內容有哪些

以下是比較經典的Linux編程學習路線：
第一階段：linux基礎入門
1. 開班課程介紹-規章制度介紹-破冰活動；
2. Linux硬體基礎/Linux發展歷史；
3. Linux系統安裝/xshell連接/xshell優化/SSH遠程連接故障問題排查
4. 第一關一大波命令及特殊字元知識考試題講解
5. L inux基礎優化
6. Linux目錄結構知識精講
7. 第二關一大波命令及特殊知識考試題講解（上）
8. 第二關一大波命令及特殊知識考試題講解（下）
9. Linux文件屬性一大堆知識精講
10. Linux通配符/正則表達式
11. 第三關一大波命令及重要知識考試題講解（上）
12. 第三關一大波命令及重要知識考試題講解（下）
13. Linux系統許可權(上)
14. Linux系統許可權(下)
15. 第一階段結束需要導師或講師對整體課程進行回顧
第二階段：linux系統管理進階
1. Linux定時任務
2. Linux用戶管理
3. Linux磁碟與文件系統(上)
4. Linux磁碟與文件系統(中下)
5. Linux三劍客之sed命令
第三階段：Linux Shell基礎
1. Shell編程基礎1
2. Shell編程基礎234
3. Linux三劍客之awk命令
第四階段：Linux網路基礎
1. 計算機網路基礎上
2. 計算機網路基礎下
3. 第二階段結束需要導師或講師對整體課程進行回顧。
第五階段：Linux網路服務
1. 集群實戰架構開始及環境准備
2. rsync數據同步服務
3. Linux全網備份項目案例精講
4. nfs網路存儲服務精講
5. inotify/sersync實時數據同步/nfs存儲實時備份項目案例精講
第六階段：Linux重要網路服務
1. http協議/www服務基礎
2. nginx web介紹及基礎實踐
3. nginx web精講結束
4. lnmp環境部署/資料庫異機遷移/共享數據異機遷移到NFS系統
5. nginx負載均衡深入透徹
6. keepalived高可用深入透徹
第七階段：Linux中小規模集群構建與優化（50台）
1. 期中架構開戰說明+期中架構部署回顧
2. 全體晝夜兼程部署期中架構並完成上台述職演講（加上兩個周末共9天）
3. kickstart cobbler 批量自動安裝系統
4. pptp vpn與ntp服務
5. memcached原理及部署/作為緩存及session會話共享
第八階段：Ansible自動化運維與Zabbix監控
1. SSH服務秘鑰認證
2. ansible批量自動化管理集群（入門及深入）
3. zabbix監控
第九階段：大規模集群高可用服務(Lvs、Keepalived)
1. Centos7系統自行安裝/centos6與7區別
2. lvs負載均衡集群/keepalived管理LVS集群
第十階段：java Tomcat服務及防火牆Iptables
1. iptables防火牆精講上
2. iptables防火牆精講下
3. tomcat java應用服務/nginx配合tomcat服務部署及優化
第十一階段：Mysql DBA高級應用實踐
1. MySQL資料庫入門基礎命令
2. MySQL資料庫進階備份恢復
3. MySQL資料庫深入事務引擎
4. MySQL資料庫優化SQL語句優化
5. MySQL資料庫集群主從復制/讀寫分離
6. MySQL資料庫高可用/mha/keepalved
第十二階段：高性能資料庫Redis和Memcached課程
第十三階段：Linux大規模集群架構構建（200台）
第十四階段：Linux Shell編程企業案例實戰
第十五階段：企業級代碼發布上線方案（SVN和Git）
1. GIT管理
2. 代碼上線項目案例
第十六階段企業級Kvm虛擬化與OpenStack雲計算
1. KVM虛擬化企業級實戰
2. OpenStack雲計算企業級實戰
第十七階段公有雲阿里雲8大組件構建集群實戰
第十八階段：Docker技術企業應用實踐
1. Docker容器與微服務深入實踐
2. 大數據Hadoop生態體系及實踐
第十九階段：python自動化入門及進階
第二十階段：職業規劃與高薪就業指導

2. Ubuntu怎樣用命令下載和安裝軟體

1. 使用apt-get install來安裝應用程序是最常見的一種安裝方法，比如要安裝buildessential這個軟體，使用以下，他會幫我把所有的依賴包都一起安裝了。
sudo apt-get install build-essential

執行上述命令以後，我們可以看到一下信息：
The following extra packages will be installed:表示所有需要再安裝的依賴包。

sudo apt-get install build-essential
[sudo] password for enadmin:
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
binutils cpp cpp-4.6 dpkg-dev fakeroot g++ g++-4.6 gcc gcc-4.6
libalgorithm-diff-perl libalgorithm-diff-xs-perl libalgorithm-merge-perl
libc-bin libc-dev-bin libc6 libc6-dev libdpkg-perl libgomp1 libmpc2 libmpfr4
libquadmath0 libstdc++6-4.6-dev linux-libc-dev manpages-dev
Suggested packages:
binutils-doc cpp-doc gcc-4.6-locales debian-keyring g++-multilib
g++-4.6-multilib gcc-4.6-doc libstdc++6-4.6-dbg gcc-multilib autoconf
automake1.9 libtool flex bison gdb gcc-doc gcc-4.6-multilib
libmudflap0-4.6-dev libgcc1-dbg libgomp1-dbg libquadmath0-dbg
libmudflap0-dbg binutils-gold glibc-doc libstdc++6-4.6-doc
The following NEW packages will be installed:
binutils build-essential cpp cpp-4.6 dpkg-dev fakeroot g++ g++-4.6 gcc
gcc-4.6 libalgorithm-diff-perl libalgorithm-diff-xs-perl
libalgorithm-merge-perl libc-dev-bin libc6-dev libdpkg-perl libgomp1 libmpc2
libmpfr4 libquadmath0 libstdc++6-4.6-dev linux-libc-dev manpages-dev
The following packages will be upgraded:
libc-bin libc6
2 upgraded, 23 newly installed, 0 to remove and 101 not upgraded.
Need to get 36.3 MB of archives.
After this operation, 83.6 MB of additional disk space will be used.
Do you want to continue [Y/n]? y

下面給出apt-get的的各種參數：
apt-get install xxx 安裝xxx 。如果帶有參數，那麼-d 表示僅下載 ，-f 表示強制安裝
apt-get remove xxx 卸載xxx
apt-get update 更新軟體信息資料庫
apt-get upgrade 進行系統升級
apt-cache search 搜索軟體包
Tips：建議您經常使用「apt-get update」命令來更新您的軟體信息資料庫 。
apt-get理論上是要求能夠聯網，但是如果製作了本地源，就不需要聯網，製作本地源可以參考：ubuntu製作本地源。

2. dpkg安裝deb包

Ubuntu軟體包格式為deb，安裝方法如下：
sudo dpkg -i package.deb
dpkg的詳細使用方法，網上有很多，下面簡單列了幾個：
dpkg -i package.deb 安裝包
dpkg -r package 刪除包
dpkg -P package 刪除包（包括配置文件）
dpkg -L package 列出與該包關聯的文件
dpkg -l package 顯示該包的版本
dpkg –unpack package.deb 解開 deb 包的內容
dpkg -S keyword 搜索所屬的包內容
dpkg -l 列出當前已安裝的包
dpkg -c package.deb 列出 deb 包的內容
dpkg –configure package 配置包
根據Ubuntu中文論壇上介紹，使用apt-get方法安裝的軟體，所有下載的deb包都緩存到了/var/cache/apt/archives目錄下了，所以可以把常用的deb包備份出來，甚至做成ISO工具包、刻盤，以後安裝Ubuntu時就可以在沒有網路環境的情況下進行了。下面的命令是拷貝archives這個目錄到/var/cache/apt/目錄下，替換原有的archives
enadmin@ubuntu-server:~/ftp$ sudo cp -r archives/ /var/cache/apt/

3. make install源代碼安裝。

如果要使用make安裝的話，那麼必須得安裝build-essential這個依賴包，安裝方法已經在前面說過了。在安裝完畢以後，我們就可以進行源碼安裝。源碼安裝大致可以分為三步驟：（./configure）–＞ 編譯（sudo make） –＞ 安裝（sudo make install）。
配置：這是編譯源代碼的第一步，通過 ./configure 命令完成。執行此步以便為編譯源代碼作準備。常用的選項有 --prefix=PREFIX，用以指定程序的安裝位置。更多的選項可通過 --help 查詢。也有某些程序無需執行此步。
編譯：一旦配置通過，可即刻使用 make 指令來執行源代碼的編譯過程。視軟體的具體情況而定，編譯所需的時間也各有差異，我們所要做的就是耐心等候和靜觀其變。此步雖然僅下簡單的指令，但有時候所遇到的問題卻十分復雜。較常碰到的情形是程序編譯到中途卻無法圓滿結束。此時，需要根據出錯提示分析以便找到應對之策。
安裝：如果編譯沒有問題，那麼執行 sudo make install 就可以將程序安裝到系統中了。
下面以安裝nagios為例進行說明。
//1.解壓縮
tar -zxf nagios-4.0.2.tar.gz
//2.進入目錄
cd nagios-4.0.2
//3.配置
./configure --prefix=/usr/local/nagios
//4.編譯
make all
//5.安裝
make install && make install-init && make install-commandmode && make install-config
以上就是源代碼安裝方式。

3. 技術面試會問很多技術問題嗎

筆者其實沒有想到去面試，只是在智聯上更新了一下簡歷，就陸陸續續接到很多獵頭的郵件和電話，實在是沒准備好要去面試，就推掉了幾家公司的面試了。正因為筆者也很久沒有面試了，筆者也想去面試學習一下，閑話少說，下面就分享給大家筆者在2018年1月4號上午10點30分的面試經歷：

首先，獵頭或者公司人資會把公司的介紹及崗位要求發到你郵箱（或者QQ、微信），下面這份是獵頭發給我的崗位說明，為了職業道德操守，公司的介紹和面試通知信息我就不貼出來了，我就把崗位要求貼出來：

職位描述：

1、 負責應用伺服器的安裝、配置、優化與維護；

2、 負責應用系統的日誌信息備份、管理、維護與分析；

3、 負責應用系統的日常監測於維護、故障處理、性能分析與優化；

4、 負責應用部署系統、環境配置系統、監控系統的開發、部署、升級與維護，建設高性能的運維平台。

崗位要求:

1、 熟悉Linux操作系統的基礎知識，熟練使用Linux常用操作命令；

2、 熟練配置Nginx、HAproxy 等應用相關軟體的部署、配置與優化維護；

3、 熟悉網路基礎知識、熟悉TCP/IP的工作原理，會配交換機或路由器，能熟練的對網路情況進行分析

4、 熟悉shell/perl/python中的一種或多種進行運維程序的開發；

5、 熟悉Nagios,Ganglia等監控軟體

看著上面的要求大家是不是覺得要求也不高啊，你要細看就會發現，這家公司要求的還挺多，不僅要會網路知識（熟悉TCP/IP好像是每家單位的都會寫這樣的要求），還要會開發技能。相信很多做運維的兄弟在網路這一塊是個頭疼的事情，都對交換機和路由器不怎麼會配置和管理。

然後，筆者詳細了解他們公司，了解崗位要求，在突擊復習一下可能會問到的知識點和技術點。到了面試的這天時間，早早的起床，把牙一定要刷干凈，特別是有口臭的兄弟，最好准備點口香糖，到達面試公司前嚼塊口香糖，以免因為口氣的原因熏到面試官，讓你在面試官心裡減分。早點要記得吃，如果你是下午面試的話也要吃午飯，吃早點了精氣神就有了。還要注意，帶上你的簡歷和一支筆，雖然他們那邊也會有你的簡歷，為了以防萬一還是准備好簡歷。

最後，關鍵點來了，就是和面試官溝通了，有筆試的公司會讓你做些面試題，沒有筆試就直接和面試官聊了，下面是我和面試官溝通完之後記住的一些問題，分享給大家看一下，筆者一共記住了7個問題，好像還有兩個問題實在想不起來了，如果大家有更恰當的回答一定要貼出來一起探討和進步：

1、介紹下自己？（幾乎每家公司首先都會讓你做個自我介紹，好像是必修課一樣）

筆者回答：此處省略筆者的自我介紹，筆者建議介紹自己的時間不宜過長，3-4分鍾為宜，說多了面試官會覺得你太啰嗦了。說太少了也不行，那樣會讓人感覺你的經歷太簡單了、太空了。正常情況下，一般你在做自我介紹的同時，面試官這個時候在看你的簡歷，他需要一邊看簡歷、一邊聽你介紹自己，如果你說個幾句話就把自己介紹完了，他肯定還沒緩過神來，對你的映像會減分的。在介紹的同時思維要清晰，邏輯要清楚，最好是根據你簡歷上寫的經歷來介紹，這樣可以把面試官的思路帶到你這里來，讓他思路跟著你走。不要東扯一句，西扯一句。竟量少介紹自己的性格、愛好（最好能不說就不說），你可以簡單羅列干過幾家公司（最多羅列3家公司/也包含目前所在的公司，注意順序不要亂），都在那幾家公司負責什麼工作，都用過什麼技術，在著重介紹一下你目前所在的公司是負責哪些工作的，可以稍微詳細一點介紹，不要讓面試官聽著暈頭轉向的感覺。

2、灰度發布如何實現？

筆者回答：其實對這個問題筆者也答的不好，就不寫出來誤導大家了。大家有好的方法可以共享出來。不過筆事後在知呼上看到了一位網友的建議覺得不錯，大家可以參考看一下 ：https://www.hu.com/question/20584476

3、Mongodb熟悉嗎，一般部署幾台？

筆者回答：部署過，沒有深入研究過，一般mongodb部署主從、或者mongodb分片集群；建議3台或5台伺服器來部署。MongoDB分片的基本思想就是將集合切分成小塊。這些塊分散到若乾片裡面，每個片只負責總數據的一部分。 對於客戶端來說，無需知道數據被拆分了，也無需知道服務端哪個分片對應哪些數據。數據在分片之前需要運行一個路由進程，進程名為mongos。這個路由器知道所有數據的存放位置，知道數據和片的對應關系。對客戶端來說，它僅知道連接了一個普通的mongod，在請求數據的過程中，通過路由器上的數據和片的對應關系，路由到目標數據所在的片上，如果請求有了回應，路由器將其收集起來回送給客戶端。

4、如何發布和回滾，用jenkins又是怎麼實現？

筆者回答：發布：jenkins配置好代碼路徑（SVN或GIT），然後拉代碼，打tag。需要編譯就編譯，編譯之後推送到發布伺服器（jenkins裡面可以調腳本），然後從分發伺服器往下分發到業務伺服器上。

回滾：按照版本號到發布伺服器找到對應的版本推送

5、Tomcat工作模式？

筆者回答：Tomcat是一個JSP/Servlet容器。其作為Servlet容器，有三種工作模式：獨立的Servlet容器、進程內的Servlet容器和進程外的Servlet容器。

進入Tomcat的請求可以根據Tomcat的工作模式分為如下兩類：

Tomcat作為應用程序伺服器：請求來自於前端的web伺服器，這可能是Apache, IIS, Nginx等；

Tomcat作為獨立伺服器：請求來自於web瀏覽器；

6、監控用什麼實現的？

筆者回答：現在公司的業務都跑在阿里雲上，我們首選的監控就是用阿里雲監控，阿里雲監控自帶了ECS、RDS等服務的監控模板，可結合自定義報警規則來觸發監控項。上家公司的業務是託管在IDC，用的是zabbix監控方案，zabbix圖形界面豐富，也自帶很多監控模板，特別是多個分區、多個網卡等自動發現並進行監控做得非常不錯，不過需要在每台客戶機（被監控端）安裝zabbix agent。

7、你是怎麼備份數據的，包括資料庫備份？

筆者回答：在生產環境下，不管是應用數據、還是資料庫數據首先在部署的時候就會有主從架構、或者集群，這本身就是屬於數據的熱備份；其實考慮冷備份，用專門一台伺服器做為備份伺服器，比如可以用rsync+inotify配合計劃任務來實現數據的冷備份，如果是發版的包備份，正常情況下有台發布伺服器，每次發版都會保存好發版的包。

總結

總結一下面試注意幾點事項，可能筆者也說得不太對，為了我們運維工作的兄弟們都能拿到高薪，大家一定要指證出來一起進步、一起探討：

第一，你要對自己的簡歷很熟悉，簡歷上的寫的技能自己一定要能說出個一二，因為面試官的很多問題都會挑你簡歷上寫的問。比如你簡歷上寫了這么一條技能「熟悉mysql資料庫的部署安裝及原理」。你即然寫了這么一條技能，你在怎麼不熟悉你也要了解mysql的原理，能說出個大概意思。萬一面試官問到了你寫的這一條，你都答不上來，那在他心裡你又減分了，基本上這次面試希望不大。

第二，如果面試官問到你不會的問題，你就說這個不太熟悉，沒有具體研究過，千萬別不懂裝懂，還扯一堆沒用的話題來掩飾，這樣只會讓面試官反感你。

第三，准備充分，竟可能多的記住原理性的知識，一般面試問的多的就是原理。很少問具體的配置文件是怎麼配置的。面試前也要了解清楚「職位描述」和「崗位要求」，雖然有時候大多數不會問到崗位要求的問題，但也要了解和熟悉。

第四，面試完後一定要總結，盡量記住面試官問的每一個問題，回去記錄下來，如果問到不會的問題，事後要立馬查網路或者找朋友搞清楚、弄明白，這樣你才能記勞，下次面試說不定又問到同樣的問題。

問完之後，面試官就跟我聊薪資待遇了，問我多少錢能達到自己的要求，我就不便透露了，可以私聊，哈哈，後續筆者會陸陸續續更新以前面試的經歷和問題，有需要的朋友可以轉載或者收藏起來一起討論。

基於大家熱情高昂的氣氛，筆者又花了一個下午的時間回憶並整理在2017年2月24號筆者在東三環邊上（快到東四環了，沒有地鐵過去，到了四惠還要轉公交車）的一家傳媒公司的面試經歷，還好筆者有做筆記的習慣，把之前面試的問題都記錄在案，這一次的面試筆者可是記憶猶新，因為這次這家公司都跟筆者發offer了，實在是真心不想去這家公司就找原因推掉了，大家可別學我這么不靠譜。下面是這家公司中的崗位要求說明：

崗位職責：
1、負責公司產品的版本控制、構建和發布管理；
2、負責公司統一配置庫管理工作，許可權管理與分配准確及時，定期完成配置備份；
3、負責公司內部開發/測試伺服器的運行管理工作；
4、負責Linux操作系統的安裝、配置、監控和維護、問題處理、軟體升級、 數據備份、應急響應、故障排除等、保證線上環境的穩定運行；
5、負責支撐平台24×7穩定運行，並進行前瞻性容量規劃；
6、負責公司機房伺服器日常維護及網路系統安裝、部署、維護工作。

崗位要求：
1、計算機相關專業本科及以上學歷，2年以上運維或配置管理工作經驗；
2、至少熟悉一種監控系統搭建，如Nagios/Zabbix/等；
3、至少熟悉一種集群管理工具，如Ansible/SaltStack等；
4、有使用集成發布工具發布構建經驗優先。比如：bamboo或者Jenkins；
5、熟悉Unix/Linux操作系統，熟悉Weblogic/tomcat等中間件，能夠編寫shell腳本，熟悉軟體開發過程及過程產品，有一定的網路基礎；
6、熟悉rsyslog, flume等日誌收集和處理系統；
7、具有強烈的安全意識及較強的溝通協調和學習能力，良好的團隊合作精神，工作積極主動。

過去之後，前台美眉把我帶到他們公司的地下室，我掃視了一下周圍的環境，貌似旁邊就是機房，因為我聽到伺服器的聲音。等了幾分鍾，面試官下來了，面試官目測比較瘦，看著跟我身材差不多（應該不到120），他說他是負責運維部的，然後開始就叫我先自我介紹，都是一個套路，免不了介紹的，所以兄弟們一定要把自我介紹練好。然後開始問我問題了，跟面試官聊得還行，問我應該有不下10個以上的問題，我記住了下面有10個問題：

1、LVS負載的原理，和Nginx負載有啥區別？

筆者回答：這個問題我覺得面試官司沒問好，正常都會這么問「LVS有哪些負載均衡技術和調度演算法?"。我回答就是按我說的這種問法回答的，反正他也頻繁點頭，當然，筆者回答的可能沒有下面我整理出來的那麼詳細，大概意思我都說明白了。

LVS是Liunx虛擬伺服器的簡稱，利用LVS提供的負載均衡技術和linux操作系統可實現高性能、高可用的伺服器集群，一般LVS都是位於整個集群系統的最前端，由一台或者多台負載調度器（Director Server）組成，分發給應用伺服器（Real Server）。它是工作在4層（也就是TCP/IP中的傳輸層），LVS是基於IP負載均衡技術的IPVS模塊來實現的，IPVS實現負載均衡機制有三種，分別是NAT、TUN和DR，詳述如下：

 VS/NAT： 即（Virtual Server via Network Address Translation）

也就是網路地址翻譯技術實現虛擬伺服器，當用戶請求到達調度器時，調度器將請求報文的目標地址（即虛擬IP地址）改寫成選定的Real Server地址，同時報文的目標埠也改成選定的Real Server的相應埠，最後將報文請求發送到選定的Real Server。在伺服器端得到數據後，Real Server返回數據給用戶時，需要再次經過負載調度器將報文的源地址和源埠改成虛擬IP地址和相應埠，然後把數據發送給用戶，完成整個負載調度過程。

可以看出，在NAT方式下，用戶請求和響應報文都必須經過Director Server地址重寫，當用戶請求越來越多時，調度器的處理能力將稱為瓶頸。

 VS/TUN ：即（Virtual Server via IP Tunneling）

也就是IP隧道技術實現虛擬伺服器。它的連接調度和管理與VS/NAT方式一樣，只是它的報文轉發方法不同，VS/TUN方式中，調度器採用IP隧道技術將用戶請求轉發到某個Real Server，而這個Real Server將直接響應用戶的請求，不再經過前端調度器，此外，對Real Server的地域位置沒有要求，可以和Director Server位於同一個網段，也可以是獨立的一個網路。因此，在TUN方式中，調度器將只處理用戶的報文請求，集群系統的吞吐量大大提高。

 VS/DR： 即（Virtual Server via Direct Routing）

也就是用直接路由技術實現虛擬伺服器。它的連接調度和管理與VS/NAT和VS/TUN中的一樣，但它的報文轉發方法又有不同，VS/DR通過改寫請求報文的MAC地址，將請求發送到Real Server，而Real Server將響應直接返回給客戶，免去了VS/TUN中的IP隧道開銷。這種方式是三種負載調度機制中性能最高最好的，但是必須要求Director Server與Real Server都有一塊網卡連在同一物理網段上。

回答負載調度演算法，IPVS實現在八種負載調度演算法，我們常用的有四種調度演算法（輪叫調度、加權輪叫調度、最少鏈接調度、加權最少鏈接調度）。一般說了這四種就夠了，也不會需要你詳細解釋這四種演算法的。你只要把上面3種負載均衡技術講明白面試官就對這道問題很滿意了。接下來你在簡單說下與nginx的區別：

LVS的優點：

抗負載能力強、工作在第4層僅作分發之用，沒有流量的產生，這個特點也決定了它在負載均衡軟體里的性能最強的；無流量，同時保證了均衡器IO的性能不會受到大流量的影響；

工作穩定，自身有完整的雙機熱備方案，如LVS+Keepalived和LVS+Heartbeat；

應用范圍比較廣，可以對所有應用做負載均衡；

配置性比較低，這是一個缺點也是一個優點，因為沒有可太多配置的東西，所以並不需要太多接觸，大大減少了人為出錯的幾率。

LVS的缺點：

軟體本身不支持正則處理，不能做動靜分離，這就凸顯了Nginx/HAProxy+Keepalived的優勢。

如果網站應用比較龐大，LVS/DR+Keepalived就比較復雜了，特別是後面有Windows Server應用的機器，實施及配置還有維護過程就比較麻煩，相對而言，Nginx/HAProxy+Keepalived就簡單一點

Nginx的優點：

工作在OSI第7層，可以針對http應用做一些分流的策略。比如針對域名、目錄結構。它的正則比HAProxy更為強大和靈活；

Nginx對網路的依賴非常小，理論上能ping通就就能進行負載功能，這個也是它的優勢所在；

Nginx安裝和配置比較簡單，測試起來比較方便；

可以承擔高的負載壓力且穩定，一般能支撐超過幾萬次的並發量；

Nginx可以通過埠檢測到伺服器內部的故障，比如根據伺服器處理網頁返回的狀態碼、超時等等，並且會把返回錯誤的請求重新提交到另一個節點；

Nginx不僅僅是一款優秀的負載均衡器/反向代理軟體，它同時也是功能強大的Web應用伺服器。LNMP現在也是非常流行的web環境，大有和LAMP環境分庭抗禮之勢，Nginx在處理靜態頁面、特別是抗高並發方面相對apache有優勢；

Nginx現在作為Web反向加速緩存越來越成熟了，速度比傳統的Squid伺服器更快，有需求的朋友可以考慮用其作為反向代理加速器；

Nginx的缺點：

Nginx不支持url來檢測。

Nginx僅能支持http和Email，這個它的弱勢。

Nginx的Session的保持，Cookie的引導能力相對欠缺。

2、redis集群的原理，redis分片是怎麼實現的，你們公司redis用在了哪些環境？

筆者回答：reids集群原理：

其實它的原理不是三兩句話能說明白的，redis 3.0版本之前是不支持集群的，官方推薦最大的節點數量為1000，至少需要3(Master)+3(Slave)才能建立集群，是無中心的分布式存儲架構，可以在多個節點之間進行數據共享，解決了Redis高可用、可擴展等問題。集群可以將數據自動切分(split)到多個節點，當集群中的某一個節點故障時，redis還可以繼續處理客戶端的請求。

redis分片：

分片(partitioning)就是將你的數據拆分到多個 Redis 實例的過程，這樣每個實例將只包含所有鍵的子集。當數據量大的時候,把數據分散存入多個資料庫中,減少單節點的連接壓力,實現海量數據存儲。分片部署方式一般分為以下三種：

（1）在客戶端做分片；這種方式在客戶端確定要連接的redis實例，然後直接訪問相應的redis實例；

（2）在代理中做分片；這種方式中，客戶端並不直接訪問redis實例，它也不知道自己要訪問的具體是哪個redis實例，而是由代理轉發請求和結果；其工作過程為：客戶端先將請求發送給代理，代理通過分片演算法確定要訪問的是哪個redis實例，然後將請求發送給相應的redis實例，redis實例將結果返回給代理，代理最後將結果返回給客戶端。

（3）在redis伺服器端做分片；這種方式被稱為「查詢路由」，在這種方式中客戶端隨機選擇一個redis實例發送請求，如果所請求的內容不再當前redis實例中它會負責將請求轉交給正確的redis實例，也有的實現中，redis實例不會轉發請求，而是將正確redis的信息發給客戶端，由客戶端再去向正確的redis實例發送請求。

redis用在了哪些環境：

java、php環境用到了redis，主要緩存有登錄用戶信息數據、設備詳情數據、會員簽到數據等

3、你會怎麼統計當前訪問的IP，並排序？

筆者回答：統計用戶的訪問IP，用awk結合uniq、sort過濾access.log日誌就能統計並排序好。一般這么回答就夠了，當然你還可以說出其它方式來統計，這都是你的加分項。

4、你會使用哪些虛擬化技術？

筆者回答：vmware vsphere及kvm，我用得比較多的是vmware vsphere虛擬化，幾本上生產環境都用的vmware vsphere，kvm我是用在測試環境中使用。vmware 是屬於原生架構虛擬化技術，也就是可直接在硬體上運行。kvm屬於寄居架構的虛擬化技術，它是依託在系統之上運行。vmware vcenter

管理上比較方便，圖形管理界面功能很強大，穩定性強，一般比較適合企業使用。KVM管理界面稍差點，需要管理人員花費點時間學習它的維護管理技術。

5、假如有人反應，調取後端介面時特別慢，你會如何排查？

筆者回答：其實這種問題都沒有具體答案，只是看你回答的內容與面試官契合度有多高，能不能說到他想要的點上，主要是看你排查問題的思路。我是這么說的：問清楚反應的人哪個服務應用或者頁面調取哪個介面慢，叫他把頁面或相關的URL發給你，首先，最直觀的分析就是用瀏覽器按F12，看下是哪一塊的內容過慢（DNS解析、網路載入、大圖片、還是某個文件內容等），如果有，就對症下葯去解決（圖片慢就優化圖片、網路慢就查看內網情況等）。其次，看後端服務的日誌，其實大多數的問題看相關日誌是最有效分析，最好用tail -f 跟蹤一下日誌，當然你也要點擊測試來訪問介面日誌才會打出來。最後，排除sql，，找到sql去mysql執行一下，看看時間是否很久，如果很久，就要優化SQL問題了，expain一下SQL看看索引情況啥的，針對性優化。數據量太大的能分表就分表，能分庫就分庫。如果SQL沒啥問題，那可能就是寫的邏輯代碼的問題了，一行行審代碼，找到耗時的地方改造，優化邏輯。

6、mysql資料庫用的是主從讀寫分離，主庫寫，從庫讀，假如從庫無法讀取了、或者從庫讀取特別慢，你會如何解決？

筆者回答：這個問題筆者覺得回答的不太好，對mysql比較在行的朋友希望能給點建議。以解決問題為前提條件，先添加從庫數量，臨時把問題給解決，然後抓取slow log ，分析sql語句，該優化就優化處理。慢要不就是硬體跟不上，需要升級；要不就是軟體需要調試優化，等問題解決在細化。

7、cpu單核和多核有啥區別？

筆者回答：很少有面試官會問這樣的問題，即然問到了，也要老實回答。還好筆者之前了解過CPU，我是這么說的：雙核CPU就是能處理多份任務，順序排成隊列來處理。單核CPU一次處理一份任務，輪流處理每個程序任務。雙核的優勢不是頻率，而是對付同時處理多件事情。單核同時只能幹一件事，比如你同時在後台BT下載，前台一邊看電影一邊拷貝文件一邊QQ。

8、機械磁碟和固態硬碟有啥區別？

筆者回答：我擦，啥年代了，還問磁碟的問題，這面試官有點逗啊。那也要回答啊：

HDD代表機械硬碟，SSD代表固態硬碟。首先，從性能方面來說，固態硬碟幾乎完勝機械硬碟，固態硬碟的讀寫速度肯定要快機械硬碟，因為固態硬碟和機械硬碟的構造是完全不同的（具體的構造就沒必要解釋了）。其次，固態盤幾乎沒有噪音、而機械盤噪音比較大。還有就是，以目前的市場情況來看，一般機械盤容量大，價格低；固態盤容量小，價格偏高。但是企業還是首選固態盤。

9、說一下用過哪些監控系統？

筆者回答：這個監控的問題又問到了，筆者在2018年1月4號也被問到類似這樣的問題，筆者曾經用過zabbix、nagios、 cacit等。但是在這次面試中只說用過zabbix和nagios。說完了之後，面試官就讓我說一下這兩個監控有啥區別：

從web功能及畫圖來講：

Nagios簡單直觀，報警與數據都在同一頁面， 紅色即為問題項。Nagios web端不要做任何配置。 Nagios需要額外安裝插件，且插件畫圖不夠美觀。

Zabbix監控數據與報警是分開的，查看問題項需要看觸發器，查看數據在最新數據查看。而且zabbix有很多其它配置項， zabbix攜帶畫圖功能，且能手動把多個監控項集在一個圖中展示。

從監控服務來講：

Nagios自帶的監控項很少。對一些變動的如多個分區、多個網卡進行監控時需要手動配置。

Zabbix自帶了很多監控內容，感覺zabbix一開始就為你做了很多事，特別是對多個分區、多個網卡等自動發現並進行監控時，那一瞬間很驚喜，很省心的感覺。

從批量配置和報警來講：

Nagios對於批量監控主機，需要用腳本在server端新增host，並拷貝service文件。 Nagios用腳本來修改所有主機的services文件，加入新增服務。

Zabbix在server端配置自動注冊規則，配置好規則後，後續新增client端不需要對server端進行操作。 Zabbix只需手動在模板中新增一監控項即可。

總體來講：

Nagios要花很多時間寫插件，Zabbix要花很多時間探索功能。

Nagios更易上手，Nagios兩天弄會，Zabbix兩周弄會。

Zabbix畫圖功能比Nagios更強大

Zabbix對於批量監控與服務更改，操作更簡潔；Nagios如果寫好自動化腳本後，也很簡單，問題在於寫自動化腳本很費神。

10、給你一套環境，你會如何設計高可用、高並發的架構？

筆者回答：如果這套環境是部署在雲端(比如阿里雲)，你就不用去考慮硬體設計的問題。可直接上阿里雲的SLB+ECS+RDS這套標準的高可用、高並發的架構。對外服務直接上SLB負載均衡技術，由阿里的SLB分發到後端的ECS主機；ECS主機部署多台，應用拆分在不同的ECS主機上，盡量細分服務。資料庫用RDS高可用版本（一主一備的經典高可用架構）、或者用RDS金融版（一主兩備的三節點架構）。在結合阿里其它的服務就完全OK，業務量上來了，主機不夠用了，直橫向擴容ECS主機搞定。

如果這套環境託管在IDC，那麼你就要從硬體、軟體（應用服務）雙面去考慮了。硬體要達到高可用、高並發公司必須買多套網路硬體設備（比如負載設備F5、防火牆、核心層交換、接入層交換）都必須要冗餘，由其是在網路設計上，設備之間都必須有雙線連接。設備如果都是跑的單機，其中一個設備掛了，你整個網路都癱瘓了，就談不上高可用、高並發了。其次在是考慮應用服務了，對外服務我會採用成熟的開源方案LVS+Keepalived或者Nginx+Keepalived，緩存層可以考慮redis集群及Mongodb集群，中間件等其它服務可以用kafka、zookeeper，圖片存儲可以用fastDFS或MFS，如果數據量大、又非常多，那麼可採用hadoop這一套方案。後端資料庫可採用 「主從+MHA」。這樣一套環境下來是絕對滿足高可用、高並發的架構

4. 如何使用 Cloud Foundry 建立 AppFog

[譯注]本文翻譯自Cloud Foundry英文博客站點，原文題為「How We Built AppFog Using Cloud Foundry」，文章發表時間是 2012 年 09 月 13 日。

使用雲的價值主張是「一切因此而簡單」。但構建和操作大規模的雲卻絕非易事。As正如 Mark Lucovsky 在他的最新訪談中所言：「誰說大規模分布式系統簡單？」盡管像 Cloud Foundry 這樣的解決方案使構建核心雲技術不再那麼令人生畏，但仍然不是件容易的事。

在這篇嘉賓博文中，AppFog 的創始人和 CEO Lucas Carlson講述了如何使用 Cloud Foundry 開源 PaaS 技術建立 AppFog 的歷程以及在這一過程中的收獲

核心雲技術高深莫測

運行基於 Cloud Foundry 的簡單服務並不是難事。查看 Micro Cloud FoundryTM。

構建一個適合生產和企業工作負荷的服務相當困難。

要構建含有一個 API 端點的基於 Cloud Foundry 的服務，該服務在 4 個以上的獨立基礎結構供應商的 6 個以上不同可用性區域中運行，適合於生產和企業工作負荷，具有一定規模和一般可用性？目前這真的很難。

快馬加鞭推行 Cloud Foundry

正如您可以設想到的那樣，自從 AppFog 宣布 GA 以來，人們一直在問我們怎樣去做。我們是如何解決怎樣將針對 Cloud Foundry 提供、為跨多個雲、多個可用區域以及多個供應商提供一個可共用界面的公共雲擴大規模的？

首先：Cloud Foundry 代碼庫確實很不錯。由於選擇使用 Cloud Foundry 進行構建，我們不必面對此類項目可能出現的很多潛在嚴峻挑戰和消耗大量時間的問題。

其次：我們能夠從 Cloud Foundry 生態系統內的更多工具、代碼和服務所獲得的益處顯著加快了我們的開發速度。

第三：擁有 GA 中已經存在並具有一定規模而且並非基於 Cloud Foundry 的公共 PaaS 是我們的一個重要促進因素。我們具有實現強大的 PaaS 所需要的內部操作經驗。

AppFog 的操作經驗對我們來說非常寶貴。盡管 PaaS 與 NoOps 趨勢緊密結合，但 NoOps 並不意味著無操作，而只是對開發人員而言無操作。正如每一個曾運行過 Cloud Foundry 的人員所知，很多操作對於運行 PaaS 都必不可少而且很重要。

最為重要的是，我們擁有一個有成千上萬的開發人員（PHP Fog 的用戶）參與的充滿活力的社區供我們咨詢，在從內部測試版到公共測試版直至 GA 的過程中幫助我們定義、測試及改進 AppFog。

悉心傾聽，交付所成

正是這個社區幫助我們了解了 AppFog 的 GA 的發展目標、需要的工作方式以及我們的目標定價。開發人員對我們的要求如下：

能夠跨數十個或數百個負載平衡的實例上輕松擴展應用程序，甚至免費版也是如此
必須在基礎結構中最快的伺服器上運行應用程序（例如 M2.4XL）
必須能夠跨多個基礎結構（Rackspace、HP、AWS、Azure，並且無價格差異）運行應用程序
必須簡化定價。沒有稀奇古怪的打包和組合以及名稱。簡單而且價格合理，最重要的是公正。
在雲中實現真正的互操作性，包括運供應商之間的一鍵式零代碼遷移，從而消除了所有供應商鎖定痕跡
目標是 30 秒部署到 AWS、Rackspace、HP、Azure 等等。
支持 Cloud Foundry 代碼庫中的任意及所有語言
支持任意及所有關系數據存儲和 NoSQL 數據存儲
這是一個令人生畏的列表。但這正是開發人員所需要的。

因此讓我們面對現實… 我們事實上是如何做到的呢？

如何圍繞 Cloud Foundry 構建 PaaS

這是個復雜的過程。幸運的是，幾個月前，Jeremy Voorhis 在倫敦 QCon 做了一個報告，敘述了 AppFog 如何將 Cloud Foundry OSS 位與我們自有的自定義擴展和增強功能集並用，來構建商用系統。這無疑是了解從 Cloud Foundry 到 AppFog 的發展歷程的最好開端。此報告的幻燈片位於此處，視頻位於此處。

在此，我們不逐一回顧 Jeremy 歷時近一小時的講話，但我們要討論一些要點。

首先，Jeremy 澄清了一些關於「Cloud Foundry」這一標志的混淆之處。一方面，CloudFoundry.com 是 VMware 提供的託管 PaaS，運行在 vSphere 虛擬平台上，該平台基於 CloudFoundry.org 中的開源項目。 VMware 還公開了其用來管理 CloudFoundry.com-Cloud Foundry BOSH-的工具的源代碼，並公開了其託管服務生產環境中的 BOSH 版本。

我們不在託管 VMware 服務上進行，而是從同一個開源 Cloud Foundry 項目構建。這種分布式開源系統使團隊能夠在其生命周期內在雲中管理及部署應用程序和服務，這是 AppFog 服務的核心。

由於我們構建了一個基礎結構不可知的 Cloud Foundry 服務，因此 AppFog 在當前的 Cloud Foundry 生態系統中是獨一無二的。

Cloud Foundry 的好處在於，基本上它可以與從基於 OpenStack 的 IaaS（如 Rackspace 或 HP）到 AWS、Joyent、Citrix 等等所提供的基礎結構相結合來實現。這種固有的多雲可移植性就是 Cloud Foundry 項目如此鼓舞人心的原因所在。

對於我們而言，在應用程序的生命周期內和多個基礎結構間部署和重新部署的能力是構建下一代 PaaS 的關鍵。我們認為，它還可以實現 PaaS 的以下基本使命： (a) 促進產品團隊對開發的關注；(b) 在應用程序生命周期內形成更短的反饋周期；(c) 提供接近即時水平擴展性的可能性。

Cloud Foundry 在雲計算革新中的作用

即使是對於通常而言精通雲計算領域的人，回顧歷史發展環境也非常重要。對我們 AppFog 人而言，Cloud Foundry 已提供了一些重要的構建基礎來構成首個下一代 PaaS。但是，這對我們有何意義？

首先，了解一些背景信息很重要。PaaS 最初是在一些歷史性突破的基礎上應運而生的，例如：

20 世紀 90 年代在 Rackspace 等公司出現數據中心。
21 世紀前十年的早期在 VMware 出現伺服器虛擬化
21 世紀前十年的中期 AWS 在虛擬化資源中引入 API
最近出現的 DevOps 範例及其關聯和派生的工具，例如 Puppet 和 Chef。
但只是在過去兩年，這條發展路線才開始真正走向成熟。像 Cloud Foundry 和 OpenStack 這樣的工具已產生，並能夠對整個應用程序生命周期進行管理。這意味著「平台即服務」中的「平台」現在可以包含開發之外的應用程序生命周期的所有方面。Jeremy 在報告中將此稱為「NoOps」。其含義絕非是再也無人去執行操作，而是操作工作的職責已傳遞到平台層，並且在應用程序生命周期的大部分時間（如果不是全部生命周期）會保留在該層。

如果沒有像 Cloud Foundry 這樣包羅萬象的工具，我們永遠也不能逾越第一代 PaaS 平台與下一代 PaaS（如 AppFog）之間的鴻溝，前者對於基礎結構管理而言實質上與用於（難以控制的）基礎結構管理的網關相比只是略有改進，而後者為用戶帶來的好處則要全面得多。

AppFog 對 Cloud Foundry 的修正

AppFog 從為託管 Cloud Foundry 生態系統提供強大的用戶界面和多雲體驗入手開始工作。我們在 Cloud Foundry 代碼庫和成型的 PaaS 產品之間遇到了許多障礙。盡管當前的 Cloudfoundry.org 項目集成了 CLI 和各種 IDE，但我們還著眼於全面的用戶體驗，包括快速注冊、Web 控制台以及我們稱為 Jumpstart、附加組件等等的構建前示例應用程序。

盡管一些 Cloud Foundry 用戶確實覺得從命令行、Eclipse 或 Spring Tool Suite 來操作系統（就像很多 AppFog 用戶的做法一樣）非常習慣，但我們還是希望為用戶提供直觀而又別具一格的控制台，用來管理他們的所有應用程序。下面是 AppFog 控制台的一個示例：

系統創建者希望 Cloud Foundry 對於事物的 UX 端處於一種不可知的狀態，而且不希望使其 UX 實現過於武斷。

我們知道，簡單和直觀並不是最終目的，而在基於低於標準的基礎系統生成簡潔的 UX 是很容易的事情。但還有很多方面需要進行探尋，以滿足盡可能多用戶的需求，我們相信我們已經做到了這一點。

以下是我們在 Cloud Foundry 的頂層和下層所引入的一些創新舉措：

基於 Varnish 的緩存層，用於顯著提高速度
從一個基於 CF 的基礎結構一鍵克隆到另一個基礎結構，實現真正的工作負載可移植性
Cloud Foundry API 兼容層，自動將請求路由到在空間的完全不同部分中運行的完全自治的 CF 實例
跨數據中心的深度 nagios 集成，使我們在問題產生影響前就發現問題的存在
此外，Cloud Foundry 使 AppFog 能夠創建非常完整的自通信體系結構。無論是在基礎結構級別還是其他級別，它還使我們能夠將 AppFog 設計為一個假定故障發生的系統，並提供一組處理故障的規程。

翻開 Cloud Foundry 新的一頁

構建能夠跨多個雲的完全成熟的商用級別 PaaS，並使其全部具有最高水準的最終用戶體驗，即使是從基本的 CloudFoundry.org 系統開始，也是一項宏大的事業。它需要一個極富開發人員敬業精神並全心投入的團隊，一個願意設身處地為客戶著想的團隊。

但我們認為值得為這樣的成果付出。我們非常幸運能夠擁有像 Cloud Foundry 這樣的核心系統。我們以多種方式進行回報，包括為項目添加初始 PHP 運行時支持，並在優化 Cloud Foundry 使其能夠在公共雲中良好運行的過程中不斷進行回饋。

對於 AppFog 轉向 GA，我們的激動之情難以言表。對於已經注冊並開發了千千萬萬個應用程序的千千萬萬個開發人員，我們更是無比興奮。

我們認為，AppFog 的成功不僅僅證明了 PaaS 的強大，還證明了 Cloud Foundry 代碼庫的力度及其開源生態系統和社區的強大。這不僅僅是 AppFog 的勝利，更是為 Cloud Foundry 的成功做出貢獻的每一個人的勝利。

關於作者：Lucas Carlson 是一位創業家和專業程序員，擅長開發具備一定規模的 Web 應用程序。Lucas 是主要跨雲 PaaS 公司 AppFog 的創始人和 CEO。他撰寫了十多個 Ruby 庫，並為包括 Rails 和 RedCloth 在內的多個重要 Rails 產品做出了貢獻。Lucas 創立、主辦了廣受歡迎的 Ruby on Rails 競賽 Rails Day 並擔任評委，一直是很多重要編程會議中廣受歡迎的發言人。Lucas 是 MOG 的第一位工程師，負責這一開創性音樂流服務的開發和技術指導。Lucas 居住在俄勒岡州波特蘭，喜愛統計學和 Go。

5. 學習Linux難嗎

Linux是學習曲線比較陡峭的學科，剛開始學習有些難度 ，入門後就相對比較輕鬆了。學習Linux大部分做的是運維工程師或者雲計算工程師。
運維不僅僅是懂Linux就行，因為還有一大部分的Windows運維，最近看一個報道說，windows的伺服器佔了47.71%。嗯，向windows運維人員致敬。當然我們這篇文章不是說運維除了懂Linux，還要懂Windows，而是涉及運維的其他方方面面。
環境部署
一開始這個世界是開發的，然後才是運維的。
開發實現產品邏輯，將產品開發完成後，然後提交運維進行部署。此時允許就需要准備好部署環境，如部署在Linux伺服器上，安裝相應的軟體，如Apache、Nginx、tomcat、JDK、PHP、MySQL等等。你不能只裝了軟體吧，還需要看看具體是哪個版本，java 7 和java 8 的差別還是有點的，php5和php7也有些語法不兼容。把軟體都安裝好了，就可以上線了？還是不行。還需要測試吧，那就還需要部署一套測試環境。有些時候，開發環境也是需要運維來部署的。
排錯和調優
事情從來都沒有一帆風順的。

上線沒多久，服務就502了，還不被老闆罵死。盡管你有一肚子的委屈，我只是個運維，代碼不是我寫的，為什麼要我來背這鍋？！委屈歸委屈，服務訪問不了了，就是運維的事。盡快定位問題，解決問題才是王道。怎麼來定位問題呢？最簡單直接的辦法就是看日誌，看系統日誌，看軟體相關的日誌，結合故障現象和經驗，快速的進行定位和恢復。然後就是總結經驗，吸取教訓，寫事故報告。OK，現在你知道，需要對系統環境需要進行一定的調優操作，不再做背鍋俠。
相關技術: top, vmstat, iftop, awk, sed, sar, iostat, strace, ...
備份
做最好的計劃，做最壞的打算。
前不久的gitlab刪庫事件的教訓猶在眼前，丟失了幾小時的數據，雖然大部分的備份策略都失效了，但還是挽救了幾小時前的一個備份，才沒有造成更大的數據丟失和公司損失。我們需要對設備進行備份冗餘，需要對資料庫進行備份及離線備份，需要對網站靜態進行備份冗餘，需要對機房進行備用，能做到雙活，那是更好的啦。
相關技術: rsync, crontab, lvm快照, mysqlmp, extrabackup, 完全備份, 差異備份, 增量備份, 離線異地備份, ...
高可用和集群
沒有永垂不朽，我們不能保證硬體24小時在線，但需要保障服務24小時在線。
出現故障後，如果做好高可用和冗餘，故障自動切換，移除故障節點，那樣也就保障了服務的實時在線。在老闆和用戶不知情的情況下，悄么的把故障處理好的，KPI算是保住了，獎金也許就會有的吧。
相關技術: F5, Nginx, LVS, HA-proxy, MHA, Zookeeper, 各種其他分布式集群方案, ...
監控告警
運維工程師的第一次解放運動。
時刻擔心網站掛掉，一年365天、每周7天、每天24小時，時刻保持精神高度緊張，就算你是神仙都會撐不住的。我們需要一個機器來監督其他的機器工作，我們需要解放我們自己。當有故障發生的時候，通過簡訊、微信、釘釘、郵件等等通知對應的運維工程師來處理，甚至是自動切換或摘除故障節點，然後我們離線對故障節點進行問題排查。
相關技術：Zabbix, Nagios, Cacti, Prometheus, open-falcon, Ganglia, sar, ...
安全和審計
狂奔在互聯網的康莊大道上，不過有些人是在裸奔。
不安全的網路環境和伺服器配置，無異於在網路世界裸奔，任何人都可以窺探你的隱私。你的應用是否做了SQL防注入？你的防火牆是否開啟？是否還在用root+密碼的方式登錄伺服器？網站開啟了https么？是否對系統操作進行審計？
相關技術: iptables, firewalld, waf, auditd, 各服務的正確配置, ...
自動化和DevOps
運維工程師的第二次解放運動。
偷懶是社會進步的第一動力。聰明的我們怎麼會讓自己一直在重復枯燥的事情上浪費時間，裝系統、部署環境、發版本、批量操作，把這一切交給程序去實現吧，我們需要的是享受生活。
相關技術: shell, python, go, rundeck, ansible, saltstack, puppet, chef, cobbler, fabric, ...
虛擬化和雲服務
正在發生的一場運維革命。
這場革命的發起人是買書的亞馬遜，這傢伙希望賣一切可以賣的東西，包括自己閑置的伺服器資源。現在國內的阿里雲和騰訊雲也發展得如日中天，他們幾乎提供了運維所需要的一切，甚至可以讓一個公司不再需要運維的崗位。你需要伺服器，只需要幾秒鍾，就可以創建一台。你需要資料庫集群，只需要滑鼠點擊幾下，就可以開通。
相關技術：docker, Moby, kubernetes, Xen, CoreOS, Hyper-V, KVM, ...

6. nginx lvs haproxy哪個用的多

一、lvs的優勢：

1、抗負載能力強，因為lvs工作方式的邏輯是非常之簡單，而且工作在網路4層僅做請求分發之用，沒有流量，所以在效率上基本不需要太過考慮。在我手裡的 lvs，僅僅出過一次問題：在並發最高的一小段時間內均衡器出現丟包現象，據分析為網路問題，即網卡或linux2.4內核的承載能力已到上限，內存和 cpu方面基本無消耗。

2、配置性低，這通常是一大劣勢，但同時也是一大優勢，因為沒有太多可配置的選項，所以除了增減伺服器，並不需要經常去觸碰它，大大減少了人為出錯的幾率。

3、工作穩定，因為其本身抗負載能力很強，所以穩定性高也是順理成章，另外各種lvs都有完整的雙機熱備方案，所以一點不用擔心均衡器本身會出什麼問題，節點出現故障的話，lvs會自動判別，所以系統整體是非常穩定的。

4、無流量，上面已經有所提及了。lvs僅僅分發請求，而流量並不從它本身出去，所以可以利用它這點來做一些線路分流之用。沒有流量同時也保住了均衡器的IO性能不會受到大流量的影響。

5、基本上能支持所有應用，因為lvs工作在4層，所以它可以對幾乎所有應用做負載均衡，包括http、資料庫、聊天室等等。

另：lvs也不是完全能判別節點故障的，譬如在wlc分配方式下，集群里有一個節點沒有配置VIP，會使整個集群不能使用，這時使用wrr分配方式則會丟掉一台機。目前這個問題還在進一步測試中。所以，用lvs也得多多當心為妙。

二、nginx和lvs作對比的結果

1、nginx工作在網路的7層，所以它可以針對http應用本身來做分流策略，比如針對域名、目錄結構等，相比之下lvs並不具備這樣的功能，所以 nginx單憑這點可利用的場合就遠多於lvs了；但nginx有用的這些功能使其可調整度要高於lvs，所以經常要去觸碰觸碰，由lvs的第2條優點 看，觸碰多了，人為出問題的幾率也就會大。

2、nginx對網路的依賴較小，理論上只要ping得通，網頁訪問正常，nginx就能連得通，nginx同時還能區分內外網，如果是同時擁有內外網的 節點，就相當於單機擁有了備份線路；lvs就比較依賴於網路環境，目前來看伺服器在同一網段內並且lvs使用direct方式分流，效果較能得到保證。另 外注意，lvs需要向託管商至少申請多一個ip來做Visual IP，貌似是不能用本身的IP來做VIP的。要做好LVS管理員，確實得跟進學習很多有關網路通信方面的知識，就不再是一個HTTP那麼簡單了。

3、nginx安裝和配置比較簡單，測試起來也很方便，因為它基本能把錯誤用日誌列印出來。lvs的安裝和配置、測試就要花比較長的時間了，因為同上所述，lvs對網路依賴比較大，很多時候不能配置成功都是因為網路問題而不是配置問題，出了問題要解決也相應的會麻煩得多。

4、nginx也同樣能承受很高負載且穩定，但負載度和穩定度差lvs還有幾個等級：nginx處理所有流量所以受限於機器IO和配置；本身的bug也還是難以避免的；nginx沒有現成的雙機熱備方案，所以跑在單機上還是風險較大，單機上的事情全都很難說。

5、nginx可以檢測到伺服器內部的故障，比如根據伺服器處理網頁返回的狀態碼、超時等等，並且會把返回錯誤的請求重新提交到另一個節點。目前lvs中 ldirectd也能支持針對伺服器內部的情況來監控，但lvs的原理使其不能重發請求。重發請求這點，譬如用戶正在上傳一個文件，而處理該上傳的節點剛 好在上傳過程中出現故障，nginx會把上傳切到另一台伺服器重新處理，而lvs就直接斷掉了，如果是上傳一個很大的文件或者很重要的文件的話，用戶可能 會因此而惱火。

6、nginx對請求的非同步處理可以幫助節點伺服器減輕負載，假如使用apache直接對外服務，那麼出現很多的窄帶鏈接時apache伺服器將會佔用大 量內存而不能釋放，使用多一個nginx做apache代理的話，這些窄帶鏈接會被nginx擋住，apache上就不會堆積過多的請求，這樣就減少了相 當多的內存佔用。這點使用squid也有相同的作用，即使squid本身配置為不緩存，對apache還是有很大幫助的。lvs沒有這些功能，也就無法能 比較。

7、nginx能支持http和email（email的功能估計比較少人用），lvs所支持的應用在這點上會比nginx更多。

在使用上，一般最前端所採取的策略應是lvs，也就是DNS的指向應為lvs均衡器，lvs的優點令它非常適合做這個任務。

重要的ip地址，最好交由lvs託管，比如資料庫的ip、webservice伺服器的ip等等，這些ip地址隨著時間推移，使用面會越來越大，如果更換ip則故障會接踵而至。所以將這些重要ip交給lvs託管是最為穩妥的，這樣做的唯一缺點是需要的VIP數量會比較多。

nginx可作為lvs節點機器使用，一是可以利用nginx的功能，二是可以利用nginx的性能。當然這一層面也可以直接使用squid，squid的功能方面就比nginx弱不少了，性能上也有所遜色於nginx。

nginx也可作為中層代理使用，這一層面nginx基本上無對手，唯一可以撼動nginx的就只有lighttpd了，不過lighttpd目前還沒有 能做到nginx完全的功能，配置也不那麼清晰易讀。另外，中層代理的IP也是重要的，所以中層代理也擁有一個VIP和lvs是最完美的方案了。

nginx也可作為網頁靜態伺服器，不過超出了本文討論的范疇，簡單提一下。

具體的應用還得具體分析，如果是比較小的網站（日PV<1000萬），用nginx就完全可以了，如果機器也不少，可以用DNS輪詢，lvs所耗費的機器還是比較多的；大型網站或者重要的服務，機器不發愁的時候，要多多考慮利用lvs。
****************************************************************************************************************
Nginx的優點:
性能好，可以負載超過1萬的並發。
功能多，除了負載均衡，還能作Web伺服器，而且可以通過Geo模塊來實現流量分配。
社區活躍，第三方補丁和模塊很多
支持gzip proxy
缺點:
不支持session保持。
對後端realserver的健康檢查功能效果不好。而且只支持通過埠來檢測，不支持通過url來檢測。
nginx對big request header的支持不是很好，如果client_header_buffer_size設置的比較小，就會返回400bad request頁面。
Haproxy的優點:
它的優點正好可以補充nginx的缺點。支持session保持，同時支持通過獲取指定的url來檢測後端伺服器的狀態。
支持tcp模式的負載均衡。比如可以給mysql的從伺服器集群和郵件伺服器做負載均衡。
缺點：
不支持虛擬主機(這個很傻啊)
目前沒有nagios和cacti的性能監控模板
LVS的優點:
性能好，接近硬體設備的網路吞吐和連接負載能力。
LVS的DR模式，支持通過廣域網進行負載均衡。這個其他任何負載均衡軟體目前都不具備。
缺點：
比較重型。另外社區不如nginx活躍。
*************************************************************************************

現在網路中常見的的負載均衡主要分為兩種：一種是通過硬體來進行進行，常見的硬體有比較昂貴的NetScaler、F5、Radware和Array等商用的負載均衡器，也有類似於LVS、Nginx、HAproxy的基於Linux的開源的負載均衡策略,
商用負載均衡裡面NetScaler從效果上比F5的效率上更高。對於負載均衡器來說，不過商用負載均衡由於可以建立在四~七層協議之上，因此適用 面更廣所以有其不可替代性，他的優點就是有專業的維護團隊來對這些服務進行維護、缺點就是花銷太大，所以對於規模較小的網路服務來說暫時還沒有需要使用。
另一種負載均衡的方式是通過軟體：比較常見的有LVS、Nginx、HAproxy等，其中LVS是建立在四層協議上面的，而另外Nginx和HAproxy是建立在七層協議之上的，下面分別介紹關於
LVS：使用集群技術和Linux操作系統實現一個高性能、高可用的伺服器，它具有很好的可伸縮性（Scalability）、可靠性（Reliability）和可管理性（Manageability）。
LVS的特點是：
1、抗負載能力強、是工作在網路4層之上僅作分發之用，沒有流量的產生；
2、配置性比較低，這是一個缺點也是一個優點，因為沒有可太多配置的東西，所以並不需要太多接觸，大大減少了人為出錯的幾率；
3、工作穩定，自身有完整的雙機熱備方案；
4、無流量，保證了均衡器IO的性能不會收到大流量的影響；
5、應用范圍比較廣，可以對所有應用做負載均衡；
6、LVS需要向IDC多申請一個IP來做Visual IP，因此需要一定的網路知識，所以對操作人的要求比較高。
Nginx的特點是：
1、工作在網路的7層之上，可以針對http應用做一些分流的策略，比如針對域名、目錄結構；
2、Nginx對網路的依賴比較小；
3、Nginx安裝和配置比較簡單，測試起來比較方便；
4、也可以承擔高的負載壓力且穩定，一般能支撐超過1萬次的並發；
5、Nginx可以通過埠檢測到伺服器內部的故障，比如根據伺服器處理網頁返回的狀態碼、超時等等，並且會把返回錯誤的請求重新提交到另一個節點，不過其中缺點就是不支持url來檢測；
6、Nginx對請求的非同步處理可以幫助節點伺服器減輕負載；
7、Nginx能支持http和Email，這樣就在適用范圍上面小很多；
8、不支持Session的保持、對Big request header的支持不是很好，另外默認的只有Round-robin和IP-hash兩種負載均衡演算法。
HAProxy的特點是：
1、HAProxy是工作在網路7層之上。
2、能夠補充Nginx的一些缺點比如Session的保持，Cookie的引導等工作
3、支持url檢測後端的伺服器出問題的檢測會有很好的幫助。
4、更多的負載均衡策略比如：動態加權輪循(Dynamic Round Robin)，加權源地址哈希(Weighted Source Hash)，加權URL哈希和加權參數哈希(Weighted Parameter Hash)已經實現
5、單純從效率上來講HAProxy更會比Nginx有更出色的負載均衡速度。
6、HAProxy可以對Mysql進行負載均衡，對後端的DB節點進行檢測和負載均衡。
***********************************************************************************************

現在網站發展的趨勢對網路負載均衡的使用是隨著網站規模的提升根據不同的階段來使用不同的技術：
第一階段：利用Nginx或者HAProxy進行單點的負載均衡，這一階段伺服器規模剛脫離開單伺服器、單資料庫的模式，需要一定的負載均衡，但是 仍然規模較小沒有專業的維護團隊來進行維護，也沒有需要進行大規模的網站部署。這樣利用Nginx或者HAproxy就是第一選擇，此時這些東西上手快， 配置容易，在七層之上利用HTTP協議就可以。這時是第一選擇
第二階段：隨著網路服務進一步擴大，這時單點的Nginx已經不能滿足，這時使用LVS或者商用F5就是首要選擇，Nginx此時就作為LVS或者 F5的節點來使用，具體LVS或者F5的是選擇是根據公司規模，人才以及資金能力來選擇的，這里也不做詳談，但是一般來說這階段相關人才跟不上業務的提 升，所以購買商業負載均衡已經成為了必經之路。
第三階段：這時網路服務已經成為主流產品，此時隨著公司知名度也進一步擴展，相關人才的能力以及數量也隨之提升，這時無論從開發適合自身產品的定製，以及降低成本來講開源的LVS，已經成為首選，這時LVS會成為主流。
最終形成比較理想的狀態為：F5/LVS<—>Haproxy<—>Squid/Varnish<—>AppServer。

7. 如何把dnsmasq 應用到區域網

DNSmasq是個非常小巧的dns伺服器，可以解決小范圍的dns查詢問題，譬如機房內網。
大致思路是這樣的：
配置dnsmasq為DNS緩存伺服器，同時在/etc/hosts文件中加入本地內網解析，這樣一來，每當內網機器查詢時就會優先查詢hosts文件，這就等於將/etc/hosts共享給全內網機器使用，從而解決內網機器互相識別的問題。相比逐台機器編輯hosts文件或者添加bind DNS記錄，僅編輯一個hosts文件，這簡直太容易了。
實施過程以CentOS 6為例
安裝配置
yum install dnsmasq -y
service dnsmasq start
將其他機器的DNS換成dnsmasq所在的IP即可，玩完了，就這么容易。
接下來你就可以編輯hosts文件了,你懂的，簡單列舉一下格式
127.0.0.1 localhost
192.168.1.10 web01.xxx.com web01
192.168.1.20 web02.xxx.com web02
hosts文件的強大之處還在於能夠劫持解析，譬如mirror.centos.org是CentOS倉庫所在，幾乎是機器正常必訪問一個域名，我將它解析成一個內網地址，搭建一個內網鏡像站，不僅內網機器也可以及時得到安全更新，每月還可以節省很多流量。
其他問題
默認配置文件為/etc/dnsmasq.conf,注釋掉的不是示例就是默認值。

默認直接緩存resolv.conf中的nameserver，通過下面的選項指定其他文件
resolv-file=/etc/resolv.dnsmasq.conf

默認監聽本地所有埠，指定監聽埠的辦法(別忘了本地回環)
listen-address=127.0.0.1,192.168.1.56

我要給dns記錄在另外一個文件，而不是/etc/hosts
addn-hosts=/etc/addion_hosts

設置dns緩存大小
cache-size=150

我擔心dnsmasq的穩定性怎麼辦
解決辦法一：寫腳本或用nagios監視dnsmasq進程，或者定時重啟
解決辦法二：在另一台機器也搭建一個dnsmasq，/etc/hosts文件拷一份過去，客戶端指定2個內網DNS
記得在iptables防火牆開放53埠哦！

8. 紅帽企業版Linux的目 錄

第1章 紅帽旋風 1
1.1 GNU/Linux是Linux的全稱 2
1.2 Linux傳奇 2
1.3 紅帽旋風 5
1.4 龐大的紅帽發行版家族 7
1.4.1 RHEL和Fedora Core項目 7
1.4.2 RHEL和CentOS 8
1.4.3 RHEL與Scientific Linux 8
1.4.4 RHEL與Oracle EnterpriseLinux 9
1.5 Linux學習方法 9
1.6 紅帽認證 10
第2章 安裝RHEL 14
2.1 安裝前的預備知識 15
2.1.1 Linux磁碟分區 15
2.1.2 邏輯卷管理器 16
2.1.3 磁碟陣列 17
2.2 安裝RHEL 5 17
2.2.1 安裝程序的獲取 17
2.2.2 本地安裝RHEL 5 18
2.2.3 首次啟動時的設置 22
2.3 RHEL 5的升級和刪除 24
2.3.1 升級RHEL 5 24
2.3.2 刪除RHEL 5 25
2.4 RHEL 6與RHEL 5的差異 27
2.4.1 安裝模式選擇界面的差異 27
2.4.2 安裝過程中的差異 28
2.4.3 軟體包管理工具的差異 28
2.4.4 救援模式的差異 28
2.5 RHEL配置精要 29
2.5.1 配置網路 29
2.5.2 配置本地DVD軟體源 32
2.5.3 RHEL 5和RHEL 6使用習慣差異 33
2.6 RHCE認證指南 34
第3章 Linux基礎 36
3.1 Linux啟動過程 37
3.1.1 GRUB引導程序 37
3.1.2 init程序 40
3.1.3 運行級別 42
3.2 Linux系統常用命令 43
3.2.1 Linux控制台 43
3.2.2 登錄和注銷 43
3.2.3 Linux基本命令 44
3.3 Linux的Shell 53
3.3.1 進入Shell 53
3.3.2 Shell變數 54
3.3.3 Shell語法 56
3.4 Linux的文件和目錄 59
3.4.1 Linux文件 59
3.4.2 Linux目錄 60
3.5 使用vi 61
3.5.1 啟動vi 61
3.5.2 使用vi編輯第一個文本 61
3.5.3 使用vi打開文件 62
3.5.4 保存文件 63
3.5.5 撤銷和恢復操作 63
3.5.6 搜索字元串 63
3.5.7 替換字元串 64
3.5.8 刪除 64
3.5.9 復制、粘貼和剪切 65
3.5.10 行定位 65
3.5.11 重復操作 65
3.5.12 vi環境設定 66
3.6 RHEL 6與RHEL 5的差異 66
3.6.1 init配置文件/etc/inittab的差異 66
3.6.2 控制台差異 67
3.6.3 gpm服務 67
3.7 RHCE認證指南 67
第4章 Linux高頻命令 68
4.1 系統和服務相關命令 69
4.1.1 uname列印系統信息 69
4.1.2 arch顯示系統硬體架構 69
4.1.3 halt關閉系統 69
4.1.4 reboot重新啟動系統 70
4.1.5 shutdown關閉/重啟系統 70
4.1.6 chkconfig設置服務的啟動和關閉 71
4.1.7 service管理系統服務 72
4.1.8 export設置並導出變數 72
4.2 用戶相關命令 73
4.2.1 su切換用戶身份 73
4.2.2 last查看用戶成功登錄信息 73
4.2.3 lastb查看用戶不成功的登錄信息 74
4.2.4 who查看已登錄的用戶 74
4.2.5 w查看登錄用戶的活動 75
4.3 磁碟管理命令 75
4.3.1 mkfs創建文件系統 75
4.3.2 mount掛載文件系統 76
4.3.3 umount卸載文件系統 77
4.3.4 df顯示磁碟使用情況 78
4.3.5 e2label查看或更改分區卷標 78
4.3.6 mpe2fs顯示文件系統信息 78
4.4 文件管理命令 80
4.4.1 chgrp改變文件所屬組 80
4.4.2 chown改變文件所有者和所屬組 80
4.4.3 chattr改變文件的文件系統屬性 81
4.4.4 lsattr查看文件的文件系統屬性 81
4.4.5 ln創建文件鏈接 82
4.4.6 查看文件佔用空間 82
4.4.7 file顯示文件類型 83
4.5 搜索命令 83
4.5.1 find查找目錄下的文件 83
4.5.2 locate定位文件位置 85
4.6 壓縮備份命令 85
4.6.1 tar歸檔工具 85
4.6.2 gzip壓縮工具 86
4.6.3 bzip2壓縮工具 87
4.7 文本處理相關命令 87
4.7.1 grep顯示文件中的匹配行 87
4.7.2 diff比較兩個文件之間的差異 88
4.7.3 sort排序文件內容 88
4.7.4 comm比較兩個已排序的文件 89
4.7.5 head顯示文件起始部分 89
4.7.6 tail顯示文件結尾部分 89
4.7.7 wc統計文件內容信息 90
4.8 RHEL 6與RHEL 5的差異 90
4.9 RHCE認證指南 90
第5章 系統管理 91
5.1 賬戶管理 93
5.1.1 Linux用戶和組 93
5.1.2 管理Linux組 94
5.1.3 管理Linux用戶 95
5.2 進程管理 96
5.2.1 什麼是進程 96
5.2.2 顯示當前進程 97
5.2.3 運行進程 98
5.2.4 調整進程優先順序 102
5.2.5 終止進程 103
5.3 磁碟管理 104
5.3.1 磁碟分區 104
5.3.2 邏輯卷管理器 106
5.3.3 磁碟陣列 114
5.3.4 磁碟限額 118
5.4 文件系統管理 121
5.4.1 創建文件系統 122
5.4.2 掛載文件系統 122
5.4.3 卸載文件系統 123
5.4.4 配置文件/etc/fstab 124
5.4.5 交換分區和交換文件 125
5.4.6 檢查文件系統 127
5.5 文件許可權管理 128
5.5.1 基本許可權 128
5.5.2 設定基本許可權 129
5.5.3 特殊許可權 131
5.5.4 設定特殊許可權 132
5.5.5 用戶掩碼設定 133
5.6 列印機管理 134
5.6.1 使用system-config-printer 134
5.6.2 使用網頁配置程序 136
5.7 日誌管理 136
5.7.1 系統日誌 136
5.7.2 應用程序日誌 138
5.7.3 查看日誌 139
5.7.4 日誌滾動 141
5.8 RHEL 6與RHEL 5的差異 143
5.8.1 /etc/fstab配置文件差異 143
5.8.2 列印機管理差異 144
5.8.3 系統日誌進程的差異 145
5.9 RHCE認證指南 146
第6章 RPM軟體包管理 147
6.1 Linux下的軟體安裝 148
6.2 認識RPM 148
6.3 使用rpm命令 148
6.3.1 安裝軟體包 148
6.3.2 升級軟體包 149
6.3.3 查詢軟體包 149
6.3.4 卸載軟體包 150
6.3.5 檢驗軟體包 150
6.4 解壓RPM軟體包 151
6.5 使用源代碼RPM包 152
6.5.1 源代碼RPM包文件構成 152
6.5.2 源代碼相關目錄 152
6.5.3 SPEC文件簡介 153
6.5.4 使用rpmbuild命令 153
6.6 使用YUM客戶端 156
6.6.1 認識YUM 156
6.6.2 YUM客戶端配置文件 156
6.6.3 使用yum命令 158
6.6.4 YUM圖形化管理工具 160
6.7 RHEL 6與RHEL 5的差異 161
6.8 RHCE認證指南 161
第7章 深入RHEL圖形伺服器 163
7.1 X-Window系統介紹 165
7.2 配置X-Window 165
7.2.1 使用system-config-display命令 165
7.2.2 配置文件
/etc/X11/xorg.conf 166
7.3 啟動X-Window 169
7.3.1 X-Window啟動流程 169
7.3.2 開機自啟動X-Window 170
7.3.3 使用startx命令 170
7.3.4 手動啟動X-Window 171
7.4 GNOME和KDE 173
7.4.1 GDM和KDM顯示管理器 173
7.4.2 GNOME窗口管理器 173
7.4.3 KDE窗口管理器 174
7.5 運行遠程X客戶端程序 174
7.6 RHEL 6與RHEL 5的差異 175
7.6.1 配置文件和工具差異 175
7.6.2 圖形登錄界面差異 176
7.6.3 窗口管理器差異 176
7.7 RHCE認證指南 178
第8章 TCP/IP網路管理 179
8.1 TCP/IP基礎 181
8.1.1 IP地址 181
8.1.2 子網掩碼和網路號 182
8.1.3 廣播地址 183
8.1.4 路由和網關 183
8.1.5 TCP/IP協議 183
8.1.6 埠 184
8.2 配置TCP/IP網路 185
8.2.1 重要的網路配置文件 185
8.2.2 網路配置程序 188
8.3 TCP/IP查錯工具 190
8.3.1 ping 190
8.3.2 traceroute 191
8.3.3 tcpmp 192
8.4 使用OpenSSH管理遠程主機 193
8.4.1 設定OpenSSH伺服器 194
8.4.2 使用SSH客戶端 196
8.5 使用RealVNC管理遠程主機 198
8.5.1 設定RealVNC伺服器 198
8.5.2 使用RealVNC客戶端 198
8.6 RHEL 6與RHEL 5的差異 200
8.6.1 網路配置差異 200
8.6.2 VNC軟體差異 201
8.7 RHCE認證指南 202
第9章 區域網應用組合 ——DHCP和NAT 203
9.1 DHCP和NAT介紹 204
9.2 DHCP服務設定 204
9.2.1 DHCP服務的安裝 204
9.2.2 DHCP配置文件dhcpd.conf 204
9.2.3 DHCP服務架設實例 206
9.2.4 DHCP客戶端設定 206
9.3 NAT服務設定 207
9.3.1 NAT服務的安裝 207
9.3.2 設定NAT服務 207
9.3.3 NAT客戶端設定 210
9.4 RHEL 6與RHEL 5的差異 210
9.4.1 DHCP服務的差異 210
9.4.2 NAT服務的差異 210
9.5 RHCE認證指南 212
第10章 Web服務與高效能 LAMP架構 213
10.1 HTTP協議和Web服務 214
10.2 Web伺服器 214
10.2.1 認識Web伺服器 214
10.2.2 Apache伺服器 215
10.3 安裝配置Apache伺服器 215
10.3.1 安裝Apache和相關軟體包 215
10.3.2 Apache配置文件httpd.conf 216
10.3.3 目錄的訪問控制 223
10.4 Apache安全管理 224
10.5 Apache故障排除 225
10.6 Apache圖形配置工具system-config-httpd 226
10.7 Apache應用實例 226
10.7.1 LAMP應用 226
10.7.2 架設YUM伺服器 229
10.7.3 架設Subversion伺服器 230
10.8 構建高效能LAMP架構 231
10.8.1 安裝注意事項 231
10.8.2 准備源碼包 232
10.8.3 編譯環境和編譯方法 233
10.8.4 LAMP環境編譯和安裝 234
10.9 RHEL 6與RHEL 5的差異 247
10.10 RHCE認證指南 248
第11章 FTP服務 249
11.1 FTP服務 250
11.2 FTP客戶端 250
11.3 VSFTPD伺服器 251
11.3.1 VSFTPD的安裝 251
11.3.2 VSFTPD的配置文件vsftpd.conf 252
11.3.3 匿名VSFTPD的搭建 255
11.3.4 僅允許系統用戶訪問的伺服器設定 255
11.3.5 VSFTPD虛擬用戶 256
11.3.6 配置具有SSL的VSFTPD 259
11.4 RHEL 6與RHEL 5的差異 262
11.5 RHCE認證指南 262
第12章 網路文件系統——NFS 263
12.1 認識NFS服務 264
12.2 NFS伺服器安裝配置 265
12.2.1 NFS伺服器安裝 265
12.2.2 配置NFS伺服器 265
12.2.3 啟動NFS服務 266
12.2.4 固定NFS服務相關埠 267
12.2.5 Iptables的NFS相關設定 268
12.2.6 NFS圖形配置工具system-config-nfs 268
12.3 NFS客戶機的使用 269
12.3.1 訪問NFS共享資源 269
12.3.2 自動掛載NFS共享目錄 270
12.4 RHEL 6與RHEL 5的差異 272
12.5 RHCE認證指南 272
第13章 分布式文件系統 ——Samba服務 274
13.1 Samba服務 275
13.1.1 Samba的作用 275
13.1.2 Samba相關協議 275
13.1.3 Samba的守護進程 275
13.2 Samba的安裝 276
13.3 Samba的配置 276
13.3.1 Samba相關文件介紹 276
13.3.2 Samba主配置文件smb.conf 277
13.3.3 Samba作為獨立伺服器 282
13.3.4 Samba作為域成員伺服器 283
13.3.5 Samba作為域控制器 285
13.3.6 創建Samba用戶賬號 286
13.4 Samba查錯 286
13.5 Samba圖形配置工具system-config-samba 287
13.6 Samba客戶端的使用 288
13.6.1 客戶端為Linux系統 288
13.6.2 客戶端為Windows系統 289
13.7 RHEL 6與RHEL 5的差異 289
13.8 RHCE認證指南 289
第14章 DNS域名服務 290
14.1 認識DNS服務 291
14.1.1 什麼是DNS 291
14.1.2 完全合格域名 291
14.1.3 DNS查詢流程 291
14.2 架設DNS伺服器的准備工作 293
14.3 安裝BIND套件 294
14.4 配置BIND服務 295
14.4.1 BIND配置文件 295
14.4.2 建立緩存伺服器 298
14.4.3 主/從架構DNS系統的架設 299
14.4.4 BIND圖形配置工具system-config-bind 301
14.5 DNS測試命令 302
14.6 DNS客戶端設定 303
14.7 RHEL 6與RHEL 5的差異 304
14.8 RHCE認證指南 305
第15章 郵件服務 306
15.1 郵件服務介紹 307
15.1.1 郵件服務的功能 307
15.1.2 郵件服務相關協議 307
15.1.3 郵件服務的組成單元 307
15.1.4 常用郵件服務程序介紹 308
15.2 Sendmail的安裝與設定 308
15.2.1 Sendmail的安裝 308
15.2.2 Sendmail的配置文件 308
15.3 Postfix的安裝與設定 314
15.3.1 Postfix的安裝 314
15.3.2 Postfix的配置文件 314
15.4 Dovecot的安裝與設定 319
15.4.1 Dovecot的安裝 319
15.4.2 Dovecot的配置文件 319
15.4.3 Dovecot的SSL認證 320
15.5 郵件伺服器架設實例 321
15.6 RHEL 6與RHEL 5的差異 325
15.7 RHCE認證指南 326
第16章 目錄服務 328
16.1 NIS服務 330
16.2 NIS伺服器 330
16.2.1 NIS服務端安裝 330
16.2.2 NIS服務端配置文件 331
16.2.3 NIS伺服器架設流程實例 333
16.3 NIS客戶端 335
16.3.1 NIS客戶端安裝 335
16.3.2 NIS客戶端配置文件 335
16.3.3 NIS客戶端架設流程實例 337
16.3.4 檢驗NIS客戶端 337
16.3.5 使用NIS客戶端修改賬戶 340
16.4 NIS應用實例 341
16.5 LDAP服務 342
16.6 OpenLDAP伺服器 343
16.6.1 OpenLDAP服務端安裝 343
16.6.2 OpenLDAP配置文件 343
16.6.3 OpenLDAP伺服器架設流程實例 345
16.7 OpenLDAP客戶端 346
16.7.1 OpenLDAP客戶端安裝 346
16.7.2 OpenLDAP客戶端配置文件 346
16.7.3 OpenLDAP客戶端架設流程實例 348
16.7.4 OpenLDAP常用命令 348
16.8 OpenLDAP應用實例 353
16.9 RHEL 6與RHEL 5的差異 355
16.9.1 NIS服務端設定差異 355
16.9.2 NIS客戶端設定差異 355
16.9.3 OpenLDAP服務端設定差異 355
16.9.4 OpenLDAP客戶端設定差異 356
16.10 RHCE認證指南 356
第17章 Squid代理伺服器 357
17.1 代理伺服器介紹 358
17.1.1 什麼是代理伺服器 358
17.1.2 代理伺服器運作方式 358
17.1.3 代理伺服器的種類 359
17.2 Squid代理伺服器 359
17.2.1 Squid的安裝 360
17.2.2 Squid配置文件squid.conf 360
17.2.3 匿名Squid伺服器設定 363
17.2.4 需要身份驗證的Squid伺服器設定 364
17.2.5 區域網中Squid作透明代理的設定 365
17.2.6 Squid作反向代理的設定 367
17.3 正向代理伺服器的客戶端設定 368
17.4 RHEL 6與RHEL 5的差異 369
17.5 RHCE認證指南 369
第18章 使用Webmin管理 RHEL 5 370
18.1 Webmin介紹 371
18.2 安裝和配置Webmin 371
18.2.1 安裝Webmin 371
18.2.2 配置Webmin 371
18.3 使用Webmin管理系統 376
18.4 使用Webmin管理網路服務 379
18.4.1 Apache 379
18.4.2 VSFTPD 380
18.4.3 NFS 380
18.4.4 Samba 381
18.4.5 BIND 382
18.4.6 Sendmail與Dovecot 383
18.4.7 NIS 384
18.4.8 Squid 385
18.5 使用Webmin加強系統安全 385
18.5.1 TCP_Wrapper 385
18.5.2 PAM 386
18.5.3 Iptables 386
第19章 全面加強RHEL安全 388
19.1 IP安全保障——TCP_Wrapper 390
19.2 系統和服務安全保障——PAM 391
19.2.1 PAM的語法及參數 391
19.2.2 PAM應用實例 394
19.3 使用防火牆Iptables 396
19.3.1 Linux內核防火牆——Netfilter/Iptalbes 396
19.3.2 配置Iptalbes防火牆 397
19.3.3 防火牆配置策略 401
19.3.4 簡單防火牆配置實例 404
19.4 SELinux實現全方位防護 406
19.4.1 SELinux簡介 406
19.4.2 啟用SELinux 406
19.4.3 查看SELinux狀態 407
19.4.4 查看和修改SELinux對網路服務的設定 408
19.5 RHEL 6與RHEL 5的差異 410
19.6 RHCE認證指南 410
第20章 RHEL的網路及無人值守安裝 412
20.1 使用網路方式安裝RHEL 5 413
20.1.1 Apache安裝伺服器 413
20.1.2 VSFTPD安裝伺服器 414
20.1.3 NFS安裝伺服器 414
20.2 KickStart自動應答腳本 415
20.2.1 創建KickStart腳本 415
20.2.2 保存KickStart文件 418
20.2.3 使用KickStart腳本進行客戶端安裝 418
20.3 PXE安裝伺服器 418
20.3.1 PXE安裝運作流程 418
20.3.2 PXE伺服器架設流程 419
20.3.3 PXE客戶端設定 422
20.4 RHEL 6與RHEL 5的差異 422
20.4.1 網路安裝方面的差異 422
20.4.2 KickStart安裝方面的差異 423
20.4.3 PXE安裝方面的差異 425
第21章 RHEL系統監測和優化策略 426
21.1 系統維護介紹 428
21.2 硬體系統的監測對象 428
21.3 系統監測工具 429
21.3.1 監測CPU 429
21.3.2 監測內存 432
21.3.3 監測磁碟 433
21.3.4 監測網路 435
21.4 使用Cacti監測系統 437
21.4.1 Cacti介紹 437
21.4.2 安裝Cacti 437
21.4.3 設定Cacti 439
21.4.4 使用Cacti 440
21.5 使用Nagios監控告警系統 442
21.5.1 Nagios介紹 442
21.5.2 安裝和設定Nagios服務端 443
21.5.3 安裝和設定NRPE客戶端 449
21.5.4 設定Nagios報警 450
21.5.5 編寫Nagios插件 453
21.6 系統優化策略 455
21.6.1 CPU優化策略 455
21.6.2 內存優化策略 455
21.6.3 磁碟優化策略 455
21.6.4 網路優化策略 455
21.7 RHEL 6與RHEL 5的差異 456
21.7.1 Cacti安裝方面的差異 456
21.7.2 Nagios安裝與設定方面的差異 456
第22章 Linux核心編譯與KVM虛擬化 460
22.1 Linux核心介紹 462
22.1.1 Linux核心是什麼 462
22.1.2 內核的版本號 462
22.1.3 為什麼需要編譯核心 462
22.1.4 獲取核心源代碼 463
22.2 Linux核心編譯 463
22.2.1 核心編譯步驟 463
22.2.2 Linux核心配置項 464
22.2.3 單獨編譯某個核心模塊 479
22.3 KVM虛擬化介紹 479
22.3.1 虛擬化技術 479
22.3.2 KVM虛擬化 480
22.4 使用KVM虛擬系統 480
22.4.1 安裝KVM虛擬系統 480
22.4.2 使用KVM虛擬機 481
22.4.3 設定橋接網路 484
22.5 RHEL 6與RHEL 5的差異 485
第23章 Linux伺服器集群與高可用系統LVS 487
23.1 認識LVS 489
23.1.1 LVS誕生背景 489
23.1.2 伺服器集群系統 489
23.1.3 LVS系統介紹 490
23.2 組建基本的LVS系統 492
23.2.1 Ipvsadm的安裝和使用 492
23.2.2 調度伺服器設定流程 493
23.2.3 應用伺服器設定流程 494
23.2.4 測試LVS系統 495
23.3 LVS系統進階 495
23.3.1 使用Ldirectord配置調度伺服器 495
23.3.2 使用Piranha配置調度伺服器 498
23.4 認識Heartbeat 501
23.4.1 Heartbeat背景知識 501
23.4.2 Heartbeat集群系統相關術語 501
23.4.3 Heartbeat系統結構 502
23.5 組建Heartbeat高可用系統 503
23.5.1 安裝Heartbeat 503
23.5.2 Heartbeat的配置文件 504
23.5.3 Heartbeat集群架設實例 506
23.5.4 使用圖形化工具設定Heartbeat集群 508
23.6 RHEL 6與RHEL 5的差異 511
23.6.1 LVS調度伺服器的安裝與設定差異 511
23.6.2 Heartbeat的安裝與設定差異 511
第24章 Linux集群文件系統 514
24.1 集群文件系統介紹 515
24.1.1 本地文件系統與集群文件系統 515
24.1.2 開源集群文件系統 515
24.1.3 集群文件系統的應用環境與優勢 516
24.2 OCFS2集群文件系統 516
24.2.1 安裝OCFS2文件系統 516
24.2.2 配置OCFS2文件系統 517
24.3 安裝Oracle 10g RAC 520
24.3.1 OCFS2文件系統安裝 520
24.3.2 安裝Oracle 10g RAC CRS 521
24.3.3 安裝Oracle 10g 529
24.3.4 創建Oracle資料庫 531
24.4 RHEL 6與RHEL 5的差異 535
附錄A RHEL企業級網路應用
方案對照表 537
附錄B RHEL程序員常用軟體
對照表 538

9. 阿里雲有什麼監控CPU和內存的日誌工具

1、可以使用阿里雲後台管理查看監控

10. 免費Windows伺服器監控工具有哪些

1.Performance Co-Pilot

Performance Co-Pilot，簡稱 PCP，是一個系統性能和分析框架。它從多個主機整理數據並實時的分析，幫你識別不正常的表現模式。它也提供 API 讓你設計自己的監控和報告解決方案。

5.Munin

Munin 是一個網路和系統監控工具，可以幫你分析伺服器資源趨勢。它是一個即插即用的解決方案。默認的安裝方式提供了很多的報告。