本文基於
openstack k
版**，在大規模環境中分析
openvswitch-agent
重啟過程中的時間消耗，並根據分析提出優化的方案。
資源
數目
openvswitch-agent
565network
1010
port
1010(dhcp), 18(nova)
測試環境如上表所示，
vxlan
埠總數
565，我們找一台計算節點，上面有
18個屬於不同網路的虛機。流表總數約為
600個，即
: 565
條vxlan port
對應的流表，
18*2共36
條本地vlan
和遠端tunnel
雙向對映的流表。
重啟計算節點
ovs-agent
，我們發現
vxlanport
和所有的
ovs flow
都被刪除，然後緩慢新增。待全部
port
和flow
全部新增完成，總共用了約
50分鐘。為了計算新增
port
和flow
的時間消耗，我們在新增
port
和flow
前後新增
log列印，得到部分列印日誌。
我們統計了下「
setup_tunnel_port
」的個數為
374條，「
add_flowstart
」的個數為
372條，「
mod_flow start
」的個數卻高達
7068
條，遠超
600條實際的流表數目
! 仔細檢視日誌，發現每次「
setup_tunnel_port
」都會有
18次「
mod_flow
」。檢視**發現，每新增乙個
tunnel
，都會遍歷所有的本地
vlan(
此處總共
18個），然後更新
vlan
到tunnel
的對映的流表，新增乙個
tunnel port
。這顯然是不合理的，
vlan
到tunnel
的對映的流表的太低。為此我們修改了**
[1]，在全部
tunnel
都完成以後，再新增
vlan
到tunnel
對映的流表。
此時重啟
ovs-agent
，發現埠、流表恢復時間縮短到
7分鐘左右。
計算節點的上承載的虛機有限，所以我們
重啟dhcp
節點的ovs-agent
，得到日誌分析如下：階段
資源型別
用時（秒）
資源數量
平均用時
ms讀取
ovsdb
網路數目
1921010
190.09901
分配vlan,
新增tunnel
到vlan
對映的流
網路數目
2701010
267.326733
tunnel_sync
，新增port
，新增flow
隧道數目
390565210
網路數目
1010
267配置
/刪除埠
vlan tag
網路數目
6001010
594.059406
傳送rpc
更新neutron db
中的埠狀態
網路數目
2401010
237.623762
總用時(
分鐘):
28.2
從這個**可以看出，如果節點上承載的網路數目較大，重啟恢復時間仍然很大。前面提到
ovs-agent
重啟時會刪除埠和流表，如果不刪除，恢復時間會大大減小。實際上，在
neutron l
版中已經支援了
ovs-agent
重啟時不刪除埠和流表
[2]，而且支援通過
ryu配置
ovs flow
，速度也會提高不少。
[1]
[2]
k8s Deployment重啟方案
本文介紹k8s depolyment重啟的三種方法。一般重啟deployment，常規操作是刪掉對應的pod,但如果有多個副本集的話，乙個個刪很麻煩。除了刪除pod，還可以 kubectl patch deploy p kubectl set image deploy nkubectl rollou...
K8s pods重啟策略
pod 的重啟策略有 3種，預設值為 always。always 容器失效時，kubelet 自動重啟該容器 onfailure 容器終止執行且退出碼不為0時重啟 never 不論狀態為何，kubelet 都不重啟該容器。失敗的容器由 kubelet 以五分鐘為上限的指數退避延遲 10秒，20秒，4...
Linux 關機重啟流程分析
下的關機和重啟流程對於一般的桌面應用和網路來說並不重要，但是在使用者自己定義的系統核心中就有一定的研究意義，通過了解linux 關機重啟的流程，我們對它可以修改和自定義，甚至以此為基礎開發出全新的功能來。1.概述 在linux 下的關機和重啟可能由兩種行為引發，一是通過使用者程式設計，一是系統自己產...