文章目錄
在上次的《運維面試，你應該知道這些（1）》中，記錄了一些網絡面試需要知道的知識，今天繼續給大家分享我認爲比較有實踐意義的面試知識，也許下次我面試應聘者的時候會用上。
運維分工
運維分爲：DBA運維、網站運維、虛擬化運維、監控運維、遊戲運維
遊戲運維又分爲：
- 開發運維：是給應用運維開發運維工具和運維平臺的
- 應用運維：是給業務上線、維護和做故障排除的，用開發運維開發出來的工具給業務上線、維護、做故障排查
- 系統運維：是給應用運維提供業務上的基礎設施，比如：系統、網絡、監控、硬件等等
如何管理300臺服務器
- 設定跳板機，使用統一賬號登錄，便於安全與登錄的考量。
- 使用salt、ansiable、puppet進行系統的統一調度與配置的統一管理。
- 建立簡單的服務器的系統、配置、應用的cmdb信息管理。便於查閱每臺服務器上的各種信息記錄。
raid0 raid1 raid5
RAID，可以把硬盤整合成一個大磁盤，還可以在大磁盤上再分區，放數據
還有一個大功能，多塊盤放在一起可以有冗餘（備份）
RAID整合方式有很多，常用的：0 1 5 10
- RAID 0，可以是一塊盤和N個盤組合
優點：讀寫快，是RAID中最好的
缺點：沒有冗餘，一塊壞了數據就全沒有了 - RAID 1，只能2塊盤，盤的大小可以不一樣，以小的爲準
優點：100%的冗餘，另一個做備份
缺點：10G+10G只有10G，浪費資源，成本高 - RAID 5 ，3塊盤，容量計算10*（n-1）,損失一塊盤
優點：成本在RAID 0和RAID 1之間
缺點：讀寫性能一般，讀還好一點，寫不好 - RAID 10，又叫1+0，4塊盤，先按raid 0分成兩組，再分別對兩組按raid 1方式鏡像
優點：兼顧冗餘(提供鏡像存儲)和性能(數據條帶形分佈)
缺點：成本高
單項對比
| 對比 | RAID0 | RAID1 | RAID5 | RAID10 |
|---|---|---|---|---|
| 冗餘 | $ | $$$$ | $$ | $$$ |
| 性能 | $$$$ | $ | $$ | $$$ |
| 成本 | $ | $$$ | $$ | $$$$ |
使用場景
| RAID0 | RAID1 | RAID5 | RAID10 | |
|---|---|---|---|---|
| 用途 | 數據庫服務器，從庫；WEB服務器 | 單臺服務器，系統盤 | 數據庫服務器，從庫；WEB服務器 | 數據庫服務器，主庫 |
LVS、Nginx、HAproxy
| LVS | HAproxy | Nginx | |
|---|---|---|---|
| 定義 | 基於四層的轉發 | 基於四層和七層的轉發 | 可以做七層的轉發 |
| 用途 | 只能做端口的轉發 | 專業的代理服務器 | 是WEB服務器，緩存服務器，又是反向代理服務器 |
| 優點 | 性能最強，大併發量的 | 配置簡單，支持Session的保持，Cookie的引導，負載均衡策略非常多 | 對網絡穩定性的依賴非常小，理論上能ping通就能進行負載功能 |
| 缺點 | 對網絡穩定性依賴比較大，不支持正則表達式處理，不能做動靜分離 | 配置簡單 | 僅能支持http、https和Email協議 |
| 適合企業 | 大型 | 中小型 | 中小型 |
Squid、Varinsh和Nginx
Squid、Varinsh和Nginx都是代理服務器
| Squid | Varinsh | Nginx | |
|---|---|---|---|
| 代理服務 | 專業的cache服務 | 專業的cache服務，採用了可視化頁面緩存技術 | 反向代理/web服務器，用了插件可以做，只能緩存靜態文件 |
| 內存利用 | 比Squid具有優勢，性能要比Squid高 | ||
| 環境 | 完整的龐大的cache技術資料，和很多的應用生產環境 | ||
| cache服務 | 優先選擇 | 優先選擇 |
Tomcat8005、8009、8080三個端口的含義？
8005關閉時使用
8009爲AJP端口，即容器使用，如Apache能通過AJP協議訪問Tomcat的8009端口
8080一般應用使用
LVS三種模式
LVS 有三種負載均衡的模式，分別是VS/NAT（nat 模式） VS/DR(路由模式) VS/TUN（隧道模式）
| VS/NAT（nat 模式） | VS/DR(路由模式) | VS/TUN（隧道模式） | |
|---|---|---|---|
| 原理 | 就是把客戶端發來的數據包的IP頭的目的地址，在負載均衡器上換成其中一臺RS的IP地址併發至此RS來處理,RS處理完後把數據交給負載均衡器,負載均衡器再把數據包原IP地址改爲自己的IP將目的地址改爲客戶端IP地址即可期間,無論是進來的流量,還是出去的流量,都必須經過負載均衡器 | 首先要知道，互聯網上的大多Internet服務的請求包很短小，而應答包通常很大那麼隧道模式就是，把客戶端發來的數據包，封裝一個新的IP頭標記(僅目的IP)發給RS，RS收到後,先把數據包的頭解開,還原數據包,處理後,直接返回給客戶端,不需要再經過負載均衡器。注意,由於RS需要對負載均衡器發過來的數據包進行還原,所以說必須支持IPTUNNEL協議，所以,在RS的內核中,必須編譯支持IPTUNNEL這個選項 | 負載均衡器和RS都使用同一個IP對外服務但只有DR對ARP請求進行響應,所有RS對本身這個IP的ARP請求保持靜默也就是說,網關會把對這個服務IP的請求全部定向給DR,而DR收到數據包後根據調度算法,找出對應的RS,把目的MAC地址改爲RS的MAC（因爲IP一致）,並將請求分發給這臺RS這時RS收到這個數據包,處理完成之後，由於IP一致，可以直接將數據返給客戶,則等於直接從客戶端收到這個數據包無異,處理後直接返回給客戶端,由於負載均衡器要對二層包頭進行改換,所以負載均衡器和RS之間必須在一個廣播域,也可以簡單的理解爲在同一臺交換機上 |
| 優點 | 集羣中的物理服務器可以使用任何支持TCP/IP操作系統，只有負載均衡器需要一個合法的IP地址 | 負載均衡器只負責將請求包分發給後端節點服務器，而RS將應答包直接發給用戶，所以，減少了負載均衡器的大量數據流動，能處理很巨大的請求量，這種方式，一臺負載均衡器能夠爲很多RS進行分發。而且跑在公網上就能進行不同地域的分發。 | 和TUN（隧道模式）一樣，負載均衡器也只是分發請求，應答包通過單獨的路由方法返回給客戶端,與VS-TUN相比，VS-DR這種實現方式不需要隧道結構，因此可以使用大多數操作系統做爲物理服務器。 |
| 缺點 | 擴展性有限。當服務器節點（普通PC服務器）增長過多時,負載均衡器將成爲整個系統的瓶頸。當服務器節點過多時大量的數據包都交匯在負載均衡器那，速度就會變慢 | 隧道模式的RS節點需要合法IP，這種方式需要所有的服務器支持”IP Tunneling”(IP Encapsulation)協議，服務器可能只侷限在部分Linux系統上 | 要求負載均衡器的網卡必須與物理網卡在一個物理段上 |
發現病毒文件刪了又自動創建怎麼解決
公司的內網某臺linux服務器流量莫名其妙的劇增：
- 用iftop查看有連接外網的情況
- netstat連接的外網ip和端口
- lsof -p pid可以查看到具體是那些進程，哪些文件
經查勘發現/root下有相關的配置conf.n hhe兩個可疑文件，rm -rf後不到一分鐘就自動生成了，由此推斷是某個母進程產生的這些文件。所以找到母進程就是找到罪魁禍首 - 斷掉外網訪問，病毒就失去外聯的能力，殺掉它就容易的多
- ps aux一個個排查，查看用戶和和系統相似而又不是的冒牌貨，果然，看到了如下進程可疑，/usr/bin/.sshd，殺掉所有.sshd相關的進程，然後直接刪掉.sshd這個可執行文件，然後才刪掉了文章開頭提到的自動復活的文件
總結，遇到這種問題，如果不是太嚴重，儘量不要重裝系統
一般就是先斷外網，然後利用iftop,ps,netstat,chattr,lsof,pstree這些工具順藤摸瓜。但是如果遇到諸如此類的問題
/boot/efi/EFI/redhat/grub.efi: Heuristics.Broken.Executable FOUND，個人覺得就要重裝系統了
寫腳本，實現判斷192.168.1.0/24網絡裏，當前在線的IP有哪些，能ping通則認爲在線
!/bin/bash
for ip in seq 1 255
do
{
ping -c 1 192.168.1.$ip > /dev/null 2>&1
if [ $? -eq 0 ]; then
echo 192.168.1.$ip UP
else
echo 192.168.1.$ip DOWN
fi
}&done
wait
每晚12 點，打包站點目錄/var/www/html 備份到/data 目錄下（最好每次備份按時間生成不同的備份包）
cat a.sh
/bin/bash
cd /var/www/ && /bin/tar zcf /data/html-
date +%m-%d%H
.tar.gz html/
crontab –e
00 00 * * * /bin/sh /root/a.sh