你有沒(méi)有碰到過(guò)OpenStack中，VM失去IP地址的問(wèn)題？如果有的話，你知道那可能是什么問(wèn)題 

——特別是如果你擁有大量的節(jié)點(diǎn)和VM。你的客戶會(huì)因?yàn)闆](méi)有明顯原因卻斷了與VM的連接而感到 挫敗。甚至云的支持團(tuán)隊(duì)會(huì)為log文件里沒(méi)有提示卻出現(xiàn)問(wèn)題感到挫敗。 

聽(tīng)起來(lái)很熟悉？ 

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

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

DHCP agent和DNSmasq 

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

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

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

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

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

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

5.企圖通過(guò)顯著的增加ip的租賃時(shí)間去解決這些性能問(wèn)題，這會(huì)導(dǎo)致neutron釋放ip地址這方面的大問(wèn)題（如果你的云負(fù)載均衡地改變)。默認(rèn)情況下，neutron會(huì)為一個(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不會(huì)為已經(jīng)終止了的實(shí)例提供ip地址直至24小時(shí)。 

你可以采取的措施 

幸運(yùn)的是，你可以做點(diǎn)事解決問(wèn)題，如果你使用openstack并擁有一個(gè)地址空間大于255個(gè)地址（/24）的私有網(wǎng)絡(luò)， 
 

接著你應(yīng)該考慮調(diào)整dnsmasq和network節(jié)點(diǎn)自身的默認(rèn)參數(shù)。 

1.增加ip的租賃時(shí)間以減少每秒來(lái)自VM的嘗試更新ip地址的請(qǐng)求數(shù)量。根據(jù)一般的場(chǎng)景計(jì)算新的租賃時(shí)間， 

記住虛擬機(jī)生命周期的平均時(shí)間。由于一個(gè)Bug，設(shè)置太大的租賃時(shí)間值會(huì)強(qiáng)迫OpenStack在數(shù)據(jù)庫(kù)中保留這個(gè)ip地址為“used”的狀態(tài)。即使VM已經(jīng)被刪除，因?yàn)閚eutron的租賃時(shí)間在數(shù)據(jù)庫(kù)中，neutron將不會(huì)釋放這個(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è)請(qǐng)求，因?yàn)樵诒粚?shí)際分配之前，dnsmasq無(wú)需再嘗試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中沒(méi)有任何辦法能為用戶解決24小時(shí)ip分配的問(wèn)題（the problem of 24 hour IP allocation），這個(gè)問(wèn)題應(yīng)該從neutron自身的改變?nèi)ソ鉀Q。一個(gè)簡(jiǎn)單的解決方法是在neutron或dhcp-agent中增加一個(gè)可配置的參數(shù)以修改租賃時(shí)間，并把它用作neutron數(shù)據(jù)庫(kù)中的分配周期。這個(gè)方法表面看上去很***但是仔細(xì)檢查一下，你會(huì)意識(shí)到這會(huì)大大增加neutron-api/neutron-db的負(fù)載。所以這不是一個(gè)正確或不正確的方法去解決問(wèn)題。 

取而代之的是，neutron應(yīng)該在實(shí)例被終止時(shí)簡(jiǎn)單地從數(shù)據(jù)庫(kù)中移除ip地址。這會(huì)解決所有問(wèn)題并在云上實(shí)現(xiàn) 
 

動(dòng)態(tài)負(fù)載和ip地址的***重用?！緦?shí)際上，這恰好是Icehouse版本的情況，盡管目前問(wèn)題有所減輕】 

結(jié)論 

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

英文原文：Improving DHCP Performance In OpenStack

譯文鏈接：http://www.oschina.net/translate/improving-dhcp-performance-openstack