你有沒有碰到過OpenStack中，VM失去IP地址的問題？如果有的話，你知道那可能是什么問題 

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

聽起來很熟悉？ 

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

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

DHCP agent和DNSmasq 

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

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

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

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

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

4.Ubuntu和CentOS有mac地址表（neighbour table）被限制到/128/512/1024(net.ipv4.neigh.default.gc_thresh1/2/3）個記錄。因為如此，不經(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的租賃時間去解決這些性能問題，這會導(dǎo)致neutron釋放ip地址這方面的大問題（如果你的云負(fù)載均衡地改變)。默認(rèn)情況下，neutron會為一個VM分配一個ip地址達(dá)24小時（neutron will allocate an IP address to a VM for 24 hours），獨(dú)立于實際的租賃時間。當(dāng)然，默認(rèn)情況下，neutron不會為已經(jīng)終止了的實例提供ip地址直至24小時。 

你可以采取的措施 

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

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

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

記住虛擬機(jī)生命周期的平均時間。由于一個Bug，設(shè)置太大的租賃時間值會強(qiáng)迫OpenStack在數(shù)據(jù)庫中保留這個ip地址為“used”的狀態(tài)。即使VM已經(jīng)被刪除，因為neutron的租賃時間在數(shù)據(jù)庫中，neutron將不會釋放這個ip地址。 

2.增加MAC地址表的尺寸使其能服務(wù)至少一千個主機(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選項。這個改變能夠使其每秒處理多10-20個請求，因為在被實際分配之前，dnsmasq無需再嘗試ping那些ip。如果你使用OpenStack作為你的基礎(chǔ)設(shè)施的一部分，記住，你必須謹(jǐn)慎地考慮這個選項。比如，如果你正使用提供者網(wǎng)絡(luò)（provider networks）并且你的VM與其他物理服務(wù)器、設(shè)備、等等是單一L2域的組成部分，IP沖突是可能發(fā)生的的,可以造成嚴(yán)重破壞。 

Neutron社區(qū)必須思考的改變 

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

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

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

結(jié)論 

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

英文原文：Improving DHCP Performance In OpenStack

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