改善OpenStack上DHCP的性能
你有沒有碰到過OpenStack中，VM失去IP地址的問題？如果有的話，你知道那可能是什么問題
——特別是如果你擁有大量的節點和VM。你的客戶會因為沒有明顯原因卻斷了與VM的連接而感到 挫敗。甚至云的支持團隊會為log文件里沒有提示卻出現問題感到挫敗。
聽起來很熟悉？
在這篇blog里，我將會分享我的一些關于Openstack網絡的經驗，特別是承擔為VM分配IP地址的責任的DHCP子組件。
為什么我們會把問題歸咎于DHCP組件？因為這些特定的問通常都是由這個小但明顯微不足道的OpenStack組件導致的。
DHCP agent和DNSmasq
在OpenStack中，neutron-dhcp-agent為實例提供ip地址。理論上，neutron-dhcp-agent可以支持多種
后端，但現在它只支持dnsmasq。當啟動一個實例時，分配和配置（ip）的程序包含一個在dnsmasq config中儲存ip地址的進程，接著啟動或重載dnsmasq。通常，OpenStack在每個網絡中只有一個neutron-dhcp-agent負責spawn一個dnsmasq，所以一個龐大的網絡（包含所有子網）中只會有一個dnsmasq提供服務。理論上，并且根據實用的實驗室測試，dnsmasq應該能每秒處理1000個DHCP請求，但這里有些事實要說明下：
1.租賃時間。默認情況下是120s，你大概會知道，在租賃時間內，dhcp客戶端會嘗試中途延長租賃時間。這意味著每個VM會一分鐘更新一次他們的ip地址。
2.去啟動一個包含65535個靜態租賃的DNSmasq實例幾乎需要4分鐘（3分43秒）。一般這會發生在neutron為新的VM分配新的ip地址，接著強行reload DNSmasq時。在此時，將沒有DHCP服務會為相應的私有Neutron網絡提供服務。
3.如果你沒有在dnsmasq的配置中使用no-ping選項——這是應歸于對安全擔憂的OpenStack的默認設置——你會因非常慢的服務速度感到痛苦，因為在dnsmasq中，一個分開的pinger進程會被用于檢查所提供的ip地址是否已經在使用中。包含no-ping選項，dnsmasq將能在10分鐘內為160個請求提供服務并且不會失去它們，盡管這依賴于核心（core）速度和CPU速度。
4.Ubuntu和CentOS有mac地址表（neighbour table）被限制到/128/512/1024(net.ipv4.neigh.default.gc_thresh1/2/3）個記錄。因為如此，不經常使用的 IP 記錄將會異常快速老化（IP records that are not frequently used will age abnormally fast）這會影響網絡性能并拖慢系統把流量發送至dhcp agent所在節點上的正確的mac地址的能力。
5.企圖通過顯著的增加ip的租賃時間去解決這些性能問題，這會導致neutron釋放ip地址這方面的大問題（如果你的云負載均衡地改變)。默認情況下，neutron會為一個VM分配一個ip地址達24小時（neutron will allocate an IP address to a VM for 24 hours），獨立于實際的租賃時間。當然，默認情況下，neutron不會為已經終止了的實例提供ip地址直至24小時。
你可以采取的措施
幸運的是，你可以做點事解決問題，如果你使用openstack并擁有一個地址空間大于255個地址（/24）的私有網絡，
接著你應該考慮調整dnsmasq和network節點自身的默認參數。
1.增加ip的租賃時間以減少每秒來自VM的嘗試更新ip地址的請求數量。根據一般的場景計算新的租賃時間，
記住虛擬機生命周期的平均時間。由于一個Bug，設置太大的租賃時間值會強迫OpenStack在數據庫中保留這個ip地址為“used”的狀態。即使VM已經被刪除，因為neutron的租賃時間在數據庫中，neutron將不會釋放這個ip地址。
2.增加MAC地址表的尺寸使其能服務至少一千個主機。要做到這樣，典型地，你可以設置dhcp-agent所在主機
的sysctl變量（通常在/etc/sysctl.conf）。視情況，你可以在所有與網絡有關的節點執行以下操作，這些變量
如此設置：
- net.ipv4.neigh.default.gc_thresh1 = 1024
- net.ipv4.neigh.default.gc_thresh2 = 4096
- net.ipv4.neigh.default.gc_thresh3 = 8192
3.為DNSmasq的默認參數加上no-ping選項。這個改變能夠使其每秒處理多10-20個請求，因為在被實際分配之前，dnsmasq無需再嘗試ping那些ip。如果你使用OpenStack作為你的基礎設施的一部分，記住，你必須謹慎地考慮這個選項。比如，如果你正使用提供者網絡（provider networks）并且你的VM與其他物理服務器、設備、等等是單一L2域的組成部分，IP沖突是可能發生的的,可以造成嚴重破壞。
Neutron社區必須思考的改變
不幸地，在neutron中沒有任何辦法能為用戶解決24小時ip分配的問題（the problem of 24 hour IP allocation），這個問題應該從neutron自身的改變去解決。一個簡單的解決方法是在neutron或dhcp-agent中增加一個可配置的參數以修改租賃時間，并把它用作neutron數據庫中的分配周期。這個方法表面看上去很***但是仔細檢查一下，你會意識到這會大大增加neutron-api/neutron-db的負載。所以這不是一個正確或不正確的方法去解決問題。
取而代之的是，neutron應該在實例被終止時簡單地從數據庫中移除ip地址。這會解決所有問題并在云上實現
動態負載和ip地址的***重用。【實際上，這恰好是Icehouse版本的情況，盡管目前問題有所減輕】
結論
正如我說的，我的所述只是覆蓋了一個很小的OpenStack網絡的子組件——DHCP服務。正如你所看到的， 如果配置不正確，特別是當你使用了DNSmasq的默認選項將會導致許多痛苦。上面我所推薦的希望能幫助你 了解如何選擇具體的DNSmasq選項和如何根據情況調整他們。
英文原文：Improving DHCP Performance In OpenStack
譯文鏈接：http://www.oschina.net/translate/improving-dhcp-performance-openstack
