你有沒有碰到過OpenStack中，VM失去IP地址的問題？如果有的話，你知道那可能是什么問題
——特別是如果你擁有大量的節(jié)點(diǎn)和VM。你的客戶會因?yàn)闆]有明顯原因卻斷了與VM的連接而感到 挫敗。甚至云的支持團(tuán)隊(duì)會為log文件里沒有提示卻出現(xiàn)問題感到挫敗。

聽起來很熟悉？

在這篇blog里，我將會分享我的一些關(guān)于Openstack網(wǎng)絡(luò)的經(jīng)驗(yàn)，特別是承擔(dān)為VM分配IP地址的責(zé)任的DHCP子組件。

為什么我們會把問題歸咎于DHCP組件？因?yàn)檫@些特定的問通常都是由這個(gè)小但明顯微不足道的OpenStack組件導(dǎo)致的。
**
DHCP agent和DNSmasq **

在OpenStack中，neutron-dhcp-agent為實(shí)例提供ip地址。理論上，neutron-dhcp-agent可以支持多種

后端，但現(xiàn)在它只支持dnsmasq。當(dāng)啟動一個(gè)實(shí)例時(shí)，分配和配置（ip）的程序包含一個(gè)在dnsmasq config中儲存ip地址的進(jìn)程，接著啟動或重載dnsmasq。通常，OpenStack在每個(gè)網(wǎng)絡(luò)中只有一個(gè)neutron-dhcp-agent負(fù)責(zé)spawn一個(gè)dnsmasq，所以一個(gè)龐大的網(wǎng)絡(luò)（包含所有子網(wǎng)）中只會有一個(gè)dnsmasq提供服務(wù)。理論上，并且根據(jù)實(shí)用的實(shí)驗(yàn)室測試，dnsmasq應(yīng)該能每秒處理1000個(gè)DHCP請求，但這里有些事實(shí)要說明下：

1.租賃時(shí)間。默認(rèn)情況下是120s，你大概會知道，在租賃時(shí)間內(nèi)，dhcp客戶端會嘗試中途延長租賃時(shí)間。這意味著每個(gè)VM會一分鐘更新一次他們的ip地址。

2.去啟動一個(gè)包含65535個(gè)靜態(tài)租賃的DNSmasq實(shí)例幾乎需要4分鐘（3分43秒）。一般這會發(fā)生在neutron為新的VM分配新的ip地址，接著強(qiáng)行reload DNSmasq時(shí)。在此時(shí)，將沒有DHCP服務(wù)會為相應(yīng)的私有Neutron網(wǎng)絡(luò)提供服務(wù)。

3.如果你沒有在dnsmasq的配置中使用no-ping選項(xiàng)——這是應(yīng)歸于對安全擔(dān)憂的OpenStack的默認(rèn)設(shè)置——你會因非常慢的服務(wù)速度感到痛苦，因?yàn)樵赿nsmasq中，一個(gè)分開的pinger進(jìn)程會被用于檢查所提供的ip地址是否已經(jīng)在使用中。包含no-ping選項(xiàng)，dnsmasq將能在10分鐘內(nèi)為160個(gè)請求提供服務(wù)并且不會失去它們，盡管這依賴于核心（core）速度和CPU速度。

4.Ubuntu和CentOS有mac地址表（neighbour table）被限制到/128/512/1024(net.ipv4.neigh.default.gc_thresh1/2/3）個(gè)記錄。因?yàn)槿绱?#xff0c;不經(jīng)常使用的 IP 記錄將會異常快速老化（IP records that are not frequently used will age abnormally fast）這會影響網(wǎng)絡(luò)性能并拖慢系統(tǒng)把流量發(fā)送至dhcp agent所在節(jié)點(diǎn)上的正確的mac地址的能力。

5.企圖通過顯著的增加ip的租賃時(shí)間去解決這些性能問題，這會導(dǎo)致neutron釋放ip地址這方面的大問題（如果你的云負(fù)載均衡地改變)。默認(rèn)情況下，neutron會為一個(gè)VM分配一個(gè)ip地址達(dá)24小時(shí)（neutron will allocate an IP address to a VM for 24 hours），獨(dú)立于實(shí)際的租賃時(shí)間。當(dāng)然，默認(rèn)情況下，neutron不會為已經(jīng)終止了的實(shí)例提供ip地址直至24小時(shí)。

你可以采取的措施
幸運(yùn)的是，你可以做點(diǎn)事解決問題，如果你使用openstack并擁有一個(gè)地址空間大于255個(gè)地址（/24）的私有網(wǎng)絡(luò)，
接著你應(yīng)該考慮調(diào)整dnsmasq和network節(jié)點(diǎn)自身的默認(rèn)參數(shù)。

1.增加ip的租賃時(shí)間以減少每秒來自VM的嘗試更新ip地址的請求數(shù)量。根據(jù)一般的場景計(jì)算新的租賃時(shí)間，
記住虛擬機(jī)生命周期的平均時(shí)間。由于一個(gè)Bug，設(shè)置太大的租賃時(shí)間值會強(qiáng)迫OpenStack在數(shù)據(jù)庫中保留這個(gè)ip地址為“used”的狀態(tài)。即使VM已經(jīng)被刪除，因?yàn)閚eutron的租賃時(shí)間在數(shù)據(jù)庫中，neutron將不會釋放這個(gè)ip地址。

2.增加MAC地址表的尺寸使其能服務(wù)至少一千個(gè)主機(jī)。要做到這樣，典型地，你可以設(shè)置dhcp-agent所在主機(jī)
的sysctl變量（通常在/etc/sysctl.conf）。視情況，你可以在所有與網(wǎng)絡(luò)有關(guān)的節(jié)點(diǎn)執(zhí)行以下操作，這些變量
如此設(shè)置：

net.ipv4.neigh.default.gc_thresh1 = 1024 net.ipv4.neigh.default.gc_thresh2 = 4096 net.ipv4.neigh.default.gc_thresh3 = 8192

3.為DNSmasq的默認(rèn)參數(shù)加上no-ping選項(xiàng)。這個(gè)改變能夠使其每秒處理多10-20個(gè)請求，因?yàn)樵诒粚?shí)際分配之前，dnsmasq無需再嘗試ping那些ip。如果你使用OpenStack作為你的基礎(chǔ)設(shè)施的一部分，記住，你必須謹(jǐn)慎地考慮這個(gè)選項(xiàng)。比如，如果你正使用提供者網(wǎng)絡(luò)（provider networks）并且你的VM與其他物理服務(wù)器、設(shè)備、等等是單一L2域的組成部分，IP沖突是可能發(fā)生的的,可以造成嚴(yán)重破壞。
Neutron社區(qū)必須思考的改變

不幸地，在neutron中沒有任何辦法能為用戶解決24小時(shí)ip分配的問題（the problem of 24 hour IP allocation），這個(gè)問題應(yīng)該從neutron自身的改變?nèi)ソ鉀Q。一個(gè)簡單的解決方法是在neutron或dhcp-agent中增加一個(gè)可配置的參數(shù)以修改租賃時(shí)間，并把它用作neutron數(shù)據(jù)庫中的分配周期。這個(gè)方法表面看上去很完美但是仔細(xì)檢查一下，你會意識到這會大大增加neutron-api/neutron-db的負(fù)載。所以這不是一個(gè)正確或不正確的方法去解決問題。

取而代之的是，neutron應(yīng)該在實(shí)例被終止時(shí)簡單地從數(shù)據(jù)庫中移除ip地址。這會解決所有問題并在云上實(shí)現(xiàn)
動態(tài)負(fù)載和ip地址的完美重用。【實(shí)際上，這恰好是Icehouse版本的情況，盡管目前問題有所減輕】

結(jié)論

正如我說的，我的所述只是覆蓋了一個(gè)很小的OpenStack網(wǎng)絡(luò)的子組件——DHCP服務(wù)。正如你所看到的， 如果配置不正確，特別是當(dāng)你使用了DNSmasq的默認(rèn)選項(xiàng)將會導(dǎo)致許多痛苦。上面我所推薦的希望能幫助你 了解如何選擇具體的DNSmasq選項(xiàng)和如何根據(jù)情況調(diào)整他們

總結(jié)

以上是生活随笔為你收集整理的改善OpenStack上DHCP的性能 【已翻译100%】的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。