企業級自動化部署方案——ansible實現lvs+keepalived高可用架構

耗時8小時左右

總體設計

ansible-playbook目錄結構

入口文件
因為不同的主機配置不同，所以按主機分類設置了3個role

[root@ansible ~]# cat /etc/ansible/work_dir/lvs.yaml
- hosts: [nfs]
  roles:
    - nfs
- hosts: [rs]
  roles:
    - web
- hosts: [ds]
  roles:
    - keepalived

NFS服務playbook結構

[root@ansible ~]# tree /etc/ansible/roles/nfs
/etc/ansible/roles/nfs
├── files
├── handlers
│   └── main.yaml
├── tasks
│   └── main.yaml
├── templates
└── vars
    └── main.yaml

WEB服務playbook結構

[root@ansible ~]# tree /etc/ansible/roles/web
/etc/ansible/roles/web
├── files
├── handlers
│   └── main.yaml
├── tasks
│   └── main.yaml
├── templates
│   ├── ifcfg-lo.j2
│   └── rs_test.j2
└── vars
    └── main.yaml

Keepalived+LVS服務playbook結構

[root@ansible ~]# tree /etc/ansible/roles/keepalived
/etc/ansible/roles/keepalived
├── files
├── handlers
├── tasks
│   └── main.yaml
├── templates
│   ├── keepalived_conf.j2
│   └── keepalived_service.j2
└── vars
    └── main.yaml

執行過程

[root@ansible work_dir]# pwd
[root@ansible work_dir]# ansible-playbook lvs.yaml

結果測試

1.查看浮動ip
在ds1 (主) 上查看IP信息
在ds2(備) 上查看IP信息
浮動IP在負載均衡主節點上
在網頁上訪問測試
通過LVS訪問NFS（把NFS掛載到了/var/www/html/nfs）
實際頁面應該只有一個 Welcome to NFS！ ，這是多次測試ansible-playbook導致的
2.測試故障切換

[root@ftp ~]# while :; do curl 192.168.213.200;sleep 2;done

停止rs1的httpd服務，業務沒有中斷
當rsl systemctl start httpd 停止httpd服務後，所有的訪問請求都分配到rs2上；當rsl啟動httpd服務，所有的訪問請求都平均分配到兩個rs節點上（wrr演算法，weight都為1）

在sleep 2的時候會出現2次訪問不到的情況curl: (7) Failed connect to 192.168.213.200:80; Connection refused
在sleep 3/4/5的時候會出現1次訪問不到的情況
在sleep 6的時候訪問正常
可見，這個節點移除是需要時間的

停止ds1(主)的keepalived服務，服務不受影響，vip漂移到了ds2(備)上
當dsl重啟keepalived服務後，vip會漂移回來

實現過程問題記錄

1.在rs1，rs2上綁定VIP到迴環網卡
2.調整內核參數，關閉arp響應要 sysctl -p
3.keepalived首次啟動失敗
通過日誌文件/var/log/messages查看錯誤

(Line 12) WARNING - interface eth0 for vrrp_instance VI_1 doesn’t exist

問題： keepalived新版本會檢查/etc/keepalived/keepalived.conf配置文件，配置有誤會導致程式啟動失敗（如預設的配置文件中網卡為eth0，而實際網卡為ens33）

解決方法: 修改配置文件後再啟動進程（用以下方法可以方便的修改網卡名稱）

#/etc/ansible/roles/keepalived/templates/keepalived_conf.j2
interface {{ net_name }}

4.systemctl無法徹底停掉keepalived
現象描述： 無法正常stop掉keepalived進程，再次啟動時雖然可以啟動，但進程狀態裡面會提示：Can’t open PID file /var/run/keepalived.pid (yet?) after start

問題： systemd的啟動腳本有問題，無法創建PID文件

解決方法： 註釋掉啟動腳本中的如下行，重載 systemctl daemon-reload

#/lib/systemd/system/keepalived.service
KillMode=process #只殺掉程式的主進程，不管打開的子進程

這個問題可能和keepalived的版本有關，不一定都需要處理這個問題
5.keepalived開啟順序影響部分配置
當2台伺服器都設置為BACKUP模式時，先開啟keepalived進程的會先綁定VIP，後開啟的即使優先順序高也不會去搶占，除非先開啟的掛掉，即雙BACKUP模式下，要先開啟優先順序高的伺服器的keepalived進程（個人驗證的是這樣的）

6.keepalived中的兩種模式

（1）master->backup模式
一旦主庫宕機，虛擬ip會自動漂移到從庫，當主庫修複後，keepalived啟動後，還會把虛擬ip搶占過來，即使設置了非搶占模式（nopreempt）搶占ip的動作也會發生。
（2）backup->backup模式
當主庫宕機後虛擬ip會自動漂移到從庫上，當原主庫恢復和keepalived服務啟動後，並不會搶占新主的虛擬ip，即使是優先順序高於從庫的優先順序別，也不會發生搶占。為了減少ip漂移次數，通常是把修複好的主庫當做新的備庫。

在資料庫的應用場景中，不建議資料庫的頻繁切換，可配置為keepalived的VIP不搶占模式
7.在Linux中，掛載到目錄後，文件夾原來的數據會被隱藏，無法看到測試結果（只能看到NFS上的文件），所以新建了目錄 /var/www/html/nfs 進行掛載，既能看到測試結果，又能訪問到NFS伺服器

8.ds1和ds2的keepalived.conf文件除了一些參數不同，其餘都一樣，可以應用templates處理

vrrp_instance VI_1 {
    {% if ds_master == ansible_hostname%}
	state MASTER
    priority 150
    {% elif ds_slave == ansible_hostname%}
	state BACKUP
	priority 100
    {% endif %}
}

vars變數有部分重覆定義，但只寫一個role中對集群不同主機的配置會有影響，暫時未想到解決辦法

執行有些慢，可能是因為開了7台虛擬機的原因，也可能是網路原因