|
1.虛擬IP是什么？
要是單講解虛擬 IP,理解起來很困難,所以干脆把 實體 IP：在網(wǎng)絡(luò)的世界里，為了要辨識每一部計算機的位置，因此有了計算機 IP 位址的定義。一個 IP 就好似一個門牌！例如，你要去微軟的網(wǎng)站的話，就要去『 207.46.197.101 』這個 IP 位置！這些可以直接在網(wǎng)際網(wǎng)絡(luò)上溝通的 IP 就被稱為『實體 IP 』了。 虛擬 IP：不過，眾所皆知的，IP 位址僅為 xxx.xxx.xxx.xxx 的資料型態(tài)，其中， xxx 為 1-255 間的整數(shù)，由于近來計算機的成長速度太快，實體的 IP 已經(jīng)有點不足了，好在早在規(guī)劃 IP 時就已經(jīng)預(yù)留了三個網(wǎng)段的 IP 做為內(nèi)部網(wǎng)域的虛擬 IP 之用。這三個預(yù)留的 IP 分別為： A級：10.0.0.0 - 10.255.255.255 上述中最常用的是192.168.0.0這一組。不過，由于是虛擬 IP ，所以當(dāng)您使用這些地址的時候﹐當(dāng)然是有所限制的，限制如下： 私有位址的路由信息不能對外散播 由于虛擬 IP 的計算機并不能直接連上 Internet ，因此需要特別的功能才能上網(wǎng)。不過，這給我們架設(shè)IP網(wǎng)絡(luò)做成很大的方便﹐比如﹕即使您目前的公司還沒有連上Internet﹐但不保證將來不會啊。如果使用公共IP的話﹐如果沒經(jīng)過注冊﹐等到以后真正要連上網(wǎng)絡(luò)的時候﹐就很可能和別人沖突了。也正如前面所分析的﹐到時候再重新規(guī)劃IP的話﹐將是件非常頭痛的問題。這時候﹐我們可以先利用私有位址來架設(shè)網(wǎng)絡(luò)﹐等到真要連上intetnet的時候﹐我們可以使用IP轉(zhuǎn)換協(xié)定﹐如 NAT (Network Addresss Translation)等技術(shù)﹐配合新注冊的IP就可以了。 固定 IP 與 動態(tài) IP：基本上，這兩個東西是由于近來網(wǎng)絡(luò)公司大量的成長下的產(chǎn)物，例如，你如果向中華電信申請一個商業(yè)型態(tài)的 ADSL 專線，那他會給你一個固定的實體 IP ，這個實體 IP 就被稱為『固定 IP 』了。而若你是申請計時制的 ADSL ，那由于你的 IP 可能是由數(shù)十人共同使用，因此你每次重新開機上網(wǎng)時，你這部計算機的 IP 都不會是固定的！于是就被稱為『動態(tài) IP』或者是『浮動式IP』。基本上，這兩個都是『實體IP』，只是網(wǎng)絡(luò)公司用來分配給用戶的方法不同而產(chǎn)生不同的名稱而已。
自己的理解 我們用路由器時，每個手機或電腦都有一個ip地址，這個IP就是虛擬IP。想象一下，如果世界上的每臺設(shè)備（電腦手機都算）都有一個實際IP地址，IP地址肯定不夠用。但如果每個實際的IP地址再對應(yīng)幾萬個虛擬的IP地址（比如 192.168.0.0 - 192.168.255.255），那不就夠了嗎？
資料來源：http://blog.csdn.net/u014290233/article/details/53635658
2.虛擬IP與arp協(xié)議
一、虛擬IP 虛擬IP（Vrtual IP Address），是一種不與特定計算機或者特定計算機網(wǎng)卡相對應(yīng)的IP地址。所有發(fā)往這個IP地址的數(shù)據(jù)包最后都會經(jīng)過真實的網(wǎng)卡到達目的主機的目的進程。
引用維基上面的定義：https://en./wiki/Virtual_IP_address
A virtual IP address (VIP or VIPA) is an IP address that doesn't correspond to an actual physical network interface (port). Uses for VIPs include network address translation (especially, one-to-many NAT), fault-tolerance, and mobility.
虛擬IP主要是用來網(wǎng)絡(luò)地址轉(zhuǎn)換，網(wǎng)絡(luò)容錯和可移動性。
虛擬IP比較常見的一個用例就是在系統(tǒng)高可用性（High Availability
HA）方面的應(yīng)用，通常一個系統(tǒng)會因為日常維護或者非計劃外的情況而發(fā)生宕機，為了提高系統(tǒng)對外服務(wù)的高可用性，就會采用主備模式進行高可用性的配置。當(dāng)提供服務(wù)的主機M宕機后，服務(wù)會切換到備用主機S繼續(xù)對外提供服務(wù)。而這一切用戶是感覺不到的，在這種情況下系統(tǒng)對客戶端提供服務(wù)的IP地址就會是一個虛擬IP，當(dāng)主機M宕機后，虛擬IP便會漂浮到備機上，繼續(xù)提供服務(wù)。
在這種情況下，虛擬IP就不是與特定計算主機或者特定某個物理網(wǎng)卡對應(yīng)的了，而是一種虛擬或者是說邏輯的概念，它是可以自由移動自由漂浮的，這樣一來既對外屏蔽了系統(tǒng)內(nèi)部的細節(jié)，又為系統(tǒng)內(nèi)部的可維護性和擴展性提供了方便。
二、arp協(xié)議
arp協(xié)議屬于TCP/IP協(xié)議族里面一種用戶將IP地址解析為MAC地址的協(xié)議。該協(xié)議是用戶局域網(wǎng)內(nèi)解析IP地址對應(yīng)的物理地址。通常一個主機A給另一個主機B通過網(wǎng)絡(luò)發(fā)送一個IP數(shù)據(jù)報的時候，首先會發(fā)送到主機A所在的路由器上面，然后路由器會判斷目的地址是否在本網(wǎng)絡(luò)內(nèi)，是則直接轉(zhuǎn)發(fā)到本網(wǎng)絡(luò)內(nèi)的目的主機，否則會繼續(xù)傳遞到下一個路由，直到到達指定的網(wǎng)絡(luò)的路由器。指定網(wǎng)絡(luò)的路由器會將此數(shù)據(jù)報發(fā)送到目的主機。整個過程最后都會涉及到由某一個網(wǎng)絡(luò)中的路由器發(fā)送到網(wǎng)內(nèi)某一主機的過程。這個過程通常是由路由器發(fā)送一個arp廣播請求，請求IP地址為數(shù)據(jù)包目的地址的主機將它自己的MAC地址發(fā)送過來，因為數(shù)據(jù)鏈路層的數(shù)據(jù)傳輸是通過物理地址傳輸?shù)?。arp請求會廣播到所有網(wǎng)內(nèi)的主機，網(wǎng)內(nèi)其他主機收到這個arp請求后，首先會檢查發(fā)送arp請求的主機的IP地址，然后將該IP地址和其對應(yīng)的MAC地址存放在緩存中，然后會檢查這個arp請求中請求的IP地址是否為自己的IP地址，是則發(fā)送一個arp應(yīng)答，應(yīng)答包含自己的IP地址和對應(yīng)的MAC地址。當(dāng)?shù)玫搅薓AC地址后，便可以將數(shù)據(jù)包正確傳輸?shù)侥康闹鳈C上了。
arp協(xié)議中比較重要的內(nèi)容之一就是arp緩存，主機操作系統(tǒng)會將IP地址與MAC地址的映射關(guān)系存放在主機的一片高速緩存中。
緩存失效：該緩存會在一定時間內(nèi)失效，失效后，請求該IP地址時需要廣播arp請求重新獲取IP地址對應(yīng)的MAC地址
緩存更新：當(dāng)收到ARP請求時，會將發(fā)送ARP請求的主機IP地址與MAC地址記錄下來，然后去更新本機arp緩存中對應(yīng)的記錄。
三、虛擬IP與arp協(xié)議 虛擬IP和arp協(xié)議 虛擬IP常用于系統(tǒng)高可用性的場景，那么虛擬IP實現(xiàn)的原理是什么?虛擬能夠自由漂浮的原理是什么？ 從前文介紹arp協(xié)議里面來看，主機與主機的通信過程都會涉及到一個ip地址轉(zhuǎn)換mac地址的過程，那么虛擬IP的通信也不會例外。因此，IP地址在主機通信的過程中其實就是一個邏輯地址。我們知道，每一個主機都存放著網(wǎng)絡(luò)內(nèi)一些主機的邏輯地址與物理地址（MAC地址）的映射，問題來了，當(dāng)虛擬IP VIP在主機A上時，主機A的MAC地址為MAC_A某主機M的arp緩存中存放著一個映射關(guān)系：VIP ---à MAC_A；當(dāng)主機A宕機后，虛擬IPVIP漂浮到了主機B，主機B的MAC地址為MAC_B，那么此時主機M想與虛擬IP通信時，是做不到，因為它的arp高速緩存中的虛擬IP VIP的映射還指向主機A的MAC地址。這個問題解決的思路就是當(dāng)虛擬IP漂浮后，刷新所有其他主機的arp緩存。
那么虛擬IP是如何實現(xiàn)漂浮后，是如何刷新所有其他主機的arp緩存的呢？ 這里就會引入另一個概念，garp()簡稱無端arp或者免費arp，主要是用來當(dāng)某一個主機C開機時，用來確認自己的IP地址沒有被人占用而做的一個檢測。廣播發(fā)送這個arp，請求得到本機IP地址的MAC地址，主機C并不希望此次arp請求會有arp應(yīng)答，因為應(yīng)答意味著IP地址沖突了。當(dāng)其他主機收到這個arp請求后，會刷新關(guān)于這個arp請求源的主機IP地址的映射。 Garp的作用主要有兩個: 1. 檢測IP地址是否有沖突 2. 刷新其他主機關(guān)于本次IP地址的映射關(guān)系
集群管理軟件Pacemaker里面的資源代理ocf:heartbeat:IPaddr2中，在虛擬IP漂浮后，會向網(wǎng)絡(luò)內(nèi)廣播發(fā)送garp請求，以此來刷新其他主機的arp緩存。 在配置OpenStack控制節(jié)點高可用性的時候，出現(xiàn)過虛擬IP切換時，某一個主機不能通信的問題，后來發(fā)現(xiàn)是arp緩存沒有刷新，有時候由于網(wǎng)絡(luò)的原因，某些主機沒有接收到此garp請求，因此ocf:heartbeat:IPaddr2資源代理中可以配置發(fā)送garp的次數(shù)，這里建議次數(shù)配置得多一點，這樣可以保證其他主機成功刷新arp緩存。
資料來源：http://blog.csdn.net/u014532901/article/details/52245138 3. 談?wù)刅IP漂移那點破事
一直以來都是用nginx的upstream模塊做網(wǎng)站最前端的負載均衡，為了防止nginx本身宕機導(dǎo)致網(wǎng)站不能訪問，通常都會做兩套nginx反向代理，然后用keepalive之類的軟件提供VIP。
常見的環(huán)境是nginx主節(jié)點和從節(jié)點各有一個公網(wǎng)IP，一個私有IP，VIP地址也使用公網(wǎng)IP來提供，正常情況下VIP只會在nginx主節(jié)點上工作，只有主節(jié)點宕機或者網(wǎng)絡(luò)不可達等情況下，VIP才會漂移到nginx從節(jié)點上。如果keepalive配置了非搶占模式，則主節(jié)點恢復(fù)后，VIP也不會漂移會主節(jié)點，而是繼續(xù)在從節(jié)工作。這種配置要求機房網(wǎng)絡(luò)不做mac地址綁定。
最近做的兩套培訓(xùn)系統(tǒng)測試情況如下: 系統(tǒng)一：主從節(jié)點做雙網(wǎng)卡綁定，都只有一個私有IP，VIP也為私有IP，通過防火墻的NAT轉(zhuǎn)發(fā)用戶的訪問請求。主節(jié)點宕機后，VIP可以漂移至從節(jié)點，但用戶無法訪問網(wǎng)站，telnet防火墻公網(wǎng)IP的80端口提示無法連接。
系統(tǒng)二：主從節(jié)點各有兩張網(wǎng)卡，分別配置一個公網(wǎng)IP和一個私有IP。VIP地址也使用公網(wǎng)IP來提供。 主節(jié)點宕機后，VIP可以漂移至從節(jié)點，但用戶無法ping通VIP，自然網(wǎng)站也就打不開。
于是分別對這兩種情況進行排查： 系統(tǒng)二：屬于比較常見的配置方案。VIP漂移后無法ping通，第一反應(yīng)詢問機房工作人員，是否相應(yīng)的設(shè)備做了mac地址綁定。得知無綁定策略后繼續(xù)排查。 發(fā)現(xiàn)配置net.ipv4.ip_nonlocal_bind = 1 參數(shù)并使其生效后重新測試正常。
系統(tǒng)一：情況有點特殊，按系統(tǒng)二的解決方法嘗試無果后，懷疑端口路由器映射上出現(xiàn)問題。于是繼續(xù)測試VIP漂移，發(fā)現(xiàn)VIP漂移到從節(jié)點后，防火墻上的arp表中vip對應(yīng)的mac地址依舊是主節(jié)點網(wǎng)卡的mac地址，原來防火墻才是罪魁禍首，坑爹的貨。機房使用的防火墻型號華為Quidway Eudemon1000E，據(jù)說默認配置下，這個arp地址表自動刷新需要20分鐘！
好吧！于是用下面的命名手工刷新后，萬事大吉，網(wǎng)站訪問也很順暢，比較郁悶的是當(dāng)主節(jié)點重新?lián)屨糣IP后，依然需要手工刷新下，否則防火墻還是把請求轉(zhuǎn)給從節(jié)點響應(yīng)。 # arping -I 網(wǎng)卡地址 -c 3 -s VIP地址 網(wǎng)關(guān)地址
后記： 要徹底解決系統(tǒng)一的問題，可以從兩方面去著手，首先是考慮去調(diào)整防火墻的arp表的自動刷新時間；其次是考慮在從節(jié)點上部署一個無限循環(huán)的腳本，時時去檢測是否搶占到了VIP，若搶占成功，則運行前面的刷新命令，命令成功運行后退出腳本，同時可以用nagios監(jiān)控該腳本，了解最新的主從切換情況。切記，循環(huán)運行一次接受后sleep 1秒，否則會死機的哦！ 如果在主節(jié)點上也部署類似的腳本，則會對網(wǎng)絡(luò)帶來負擔(dān)，因而主節(jié)點恢復(fù)后的刷新手工運行下就好了，如果忘記運行了，從節(jié)點依然可以工作，無傷大雅！
資料來源： http://ylw6006.blog.51cto.com/470441/1314004/ 4.HA集群中的虛擬IP原理
高可用性HA（High Availability）指的是通過盡量縮短因日常維護操作（計劃）和突發(fā)的系統(tǒng)崩潰（非計劃）所導(dǎo)致的停機時間，以提高系統(tǒng)和應(yīng)用的可用性。HA系統(tǒng)是目前企業(yè)防止核心計算機系統(tǒng)因故障停機的最有效手段。 實現(xiàn)HA的方式，一般采用兩臺機器同時完成一項功能，比如數(shù)據(jù)庫服務(wù)器，平常只有一臺機器對外提供服務(wù)，另一臺機器作為熱備，當(dāng)這臺機器出現(xiàn)故障時，自動動態(tài)切換到另一臺熱備的機器。 怎么實現(xiàn)故障檢測的那？ 心跳，采用定時發(fā)送一個數(shù)據(jù)包，如果機器多長時間沒響應(yīng)，就認為是發(fā)生故障，自動切換到熱備的機器上去。 怎么實現(xiàn)自動切換那？ 虛IP。何為虛IP那，就是一個未分配給真實主機的IP，也就是說對外提供數(shù)據(jù)庫服務(wù)器的主機除了有一個真實IP外還有一個虛IP，使用這兩個IP中的 任意一個都可以連接到這臺主機，所有項目中數(shù)據(jù)庫鏈接一項配置的都是這個虛IP，當(dāng)服務(wù)器發(fā)生故障無法對外提供服務(wù)時，動態(tài)將這個虛IP切換到備用主機。
開始我也不明白這是怎么實現(xiàn)的，以為是軟件動態(tài)改IP地址，其實不是這樣，其實現(xiàn)原理主要是靠TCP/IP的ARP協(xié)議。因為ip地址只是一個邏輯 地址，在以太網(wǎng)中MAC地址才是真正用來進行數(shù)據(jù)傳輸?shù)奈锢淼刂?，每臺主機中都有一個ARP高速緩存，存儲同一個網(wǎng)絡(luò)內(nèi)的IP地址與MAC地址的對應(yīng)關(guān) 系，以太網(wǎng)中的主機發(fā)送數(shù)據(jù)時會先從這個緩存中查詢目標IP對應(yīng)的MAC地址，會向這個MAC地址發(fā)送數(shù)據(jù)。操作系統(tǒng)會自動維護這個緩存。這就是整個實現(xiàn) 的關(guān)鍵。 下邊就是我電腦上的arp緩存的內(nèi)容。 (192.168.1.219) at 00:21:5A:DB:68:E8 [ether] on bond0
192.168.1.217、192.168.1.218是兩臺真實的電腦， 192.168.1.217為對外提供數(shù)據(jù)庫服務(wù)的主機。 192.168.1.218為熱備的機器。 192.168.1.219為虛IP。 大家注意紅字部分，219、217的MAC地址是相同的。 再看看那217宕機后的arp緩存 (192.168.1.219) at 00:21:5A:DB:7F:C2 [ether] on bond0 這就是奧妙所在。當(dāng)218 發(fā)現(xiàn)217宕機后會向網(wǎng)絡(luò)發(fā)送一個ARP數(shù)據(jù)包，告訴所有主機192.168.1.219這個IP對應(yīng)的MAC地址是00:21:5A:DB:7F:C2，這樣所有發(fā)送到219的數(shù)據(jù)包都會發(fā)送到mac地址為00:21:5A:DB:7F:C2的機器，也就是218的機器。
5. 基于keepalived 實現(xiàn)VIP轉(zhuǎn)移，lvs，nginx的高可用
一、Keepalived 高可用集群的解決方案 二、VRRP的有限狀態(tài)機 三、利用keepalived 實現(xiàn)主從VIP的切換 四、實現(xiàn)在狀態(tài)轉(zhuǎn)變的時候自定義進行通知， 五、實現(xiàn)負載均衡 六：實現(xiàn)nginx的高可用
一、Keepalived 高可用集群的解決方案
最初的誕生是為ipvs提供高可用的，在后端的realserver接收不到主節(jié)點的信息之后，keepalived能夠自己調(diào)用ipvsadm命令生成規(guī)則，能夠自動實現(xiàn)，將主節(jié)點的VIP以及ipvs規(guī)則“拿過來”，應(yīng)用在從節(jié)點上，繼續(xù)為用戶服務(wù)。還可以實現(xiàn)對后端realserver的健康狀況做檢測。 keepalived在一個節(jié)點上啟動之后，會生成一個Master主進程，這個主進程又會生成兩個子進程，分別是VRRP Stack（實現(xiàn)vrrp協(xié)議的） Checkers(檢測ipvs后端realserver的健康狀況檢測)
二、VRRP的有限狀態(tài)機
VRRP雙方節(jié)點都啟動以后，要實現(xiàn)狀態(tài)轉(zhuǎn)換的，剛開始啟動的時候，初始狀態(tài)都是BACKUP，而后向其它節(jié)點發(fā)送通告，以及自己的優(yōu)先級信息，誰的優(yōu)先級高，就轉(zhuǎn)換為MASTER，否則就還是BACKUP，這時候服務(wù)就在狀態(tài)為MASTER的節(jié)點上啟動，為用戶提供服務(wù)，如果，該節(jié)點掛掉了，則轉(zhuǎn)換為BACKUP，優(yōu)先級降低，另一個節(jié)點轉(zhuǎn)換為MASTER，優(yōu)先級上升，服務(wù)就在此節(jié)點啟動，VIP,VMAC都會被轉(zhuǎn)移到這個節(jié)點上，為用戶提供服務(wù)，
實驗環(huán)境： 虛擬主機版本： CentOS6.4-i686 兩個節(jié)點： node1.limian.com 172.16.6.1 node2.limian.com 172.16.6.10 準備 1、節(jié)點一： 同步時間： [root@node1 ~]# ntpdate 172.16.0.1 安裝keepalived [root@node1 ~]# yum -y install keepalived 2、節(jié)點二做同樣的工作
三、利用keepalived 實現(xiàn)主從VIP的切換 3.1我們修改下keepalived的配置文件：
3.2全局階段
3.3定義vrrp階段
這樣我們主節(jié)點的配置文件就修改好了，需要復(fù)制到從節(jié)點上，再做適當(dāng)?shù)男薷木涂梢允褂昧?/span>
3.4登錄到從節(jié)點;
3.5然后在主節(jié)點啟動服務(wù)
3.6在從節(jié)點啟動服務(wù) [root@node2 keepalived]# service keepalived start 把主節(jié)點上的服務(wù)停掉，看VIP會不會到從節(jié)點上 [root@node2 ~]# ip addr show
3.7在主節(jié)點上啟動服務(wù)
注： 默認情況下ARRP工作在“搶占模式”下，如果發(fā)現(xiàn)一個節(jié)點的服務(wù)停止了，另一個節(jié)點會立即把VIP和VMAC“搶過來”，如果在“非搶占模式”下，無論你的優(yōu)先級過高，一個節(jié)點服務(wù)停止，另一個節(jié)點也不會“搶”VIP和VMAC，除非這個節(jié)點掛了，兩一個節(jié)點才會“搶”。 四、實現(xiàn)在狀態(tài)轉(zhuǎn)變的時候自定義進行通知， 4.1這需要依賴于腳本來完成 主節(jié)點
轉(zhuǎn)換狀態(tài)查看是否會收到通知
說明腳本正常工作，那么去編輯配置文件
在全局階段添加
在vrrp階段添加如下幾行
4.2將該腳本復(fù)制到另一個節(jié)點，
并在配置文件中相應(yīng)的位置添加相同內(nèi)容 兩個節(jié)點都重啟服務(wù) 4.3讓主節(jié)點變成從節(jié)點
通過監(jiān)控，發(fā)現(xiàn)主節(jié)點立即變成從節(jié)點，并收到一封郵件
五、實現(xiàn)負載均衡 5.1編輯配置文件
5.2、在從節(jié)點上做同樣的修改 5.3重啟服務(wù)并用ipvsadm命令檢測是否會生成規(guī)則
但是為什么沒有我們定義的兩個realserver呢？那是因為沒啟動虛擬機呢，健康狀況檢測沒通過，就不會顯示了，我們?nèi)右粋€虛擬機，并啟動服務(wù)即可。 并執(zhí)行如下命令，做lvs負載均衡的DR模型
注： 1、后端的realserver的數(shù)量可以添加多臺，但是需要在主節(jié)點的配置文件中給出相應(yīng)的配置，并在添加的realserver上執(zhí)行相關(guān)命令即可 2、盡管keepalived可以自行添加ipvs規(guī)則，實現(xiàn)負載均衡，但是無法實現(xiàn)動靜分離，在生產(chǎn)環(huán)境中我們要根據(jù)場景選擇最佳的方案。 六：實現(xiàn)nginx的高可用 6.1前提 兩個節(jié)點上都裝上nginx服務(wù)，并確保httpd沒啟用 # netstat -tunlp //確保80端口沒占用 # service nginx start 6.2為每個節(jié)點的nginx編輯一個頁面，以便于效果更直觀一些
6.3確保nginx可以正常訪問
6.4然后停掉服務(wù)，
6.5同步腳本到節(jié)點2
6.6在主節(jié)點上
|
|
|
