中性子シリーズ：中性子OVSオープンフローフローテーブル及びL2人口（8）

その他 2019-07-02 23:04:38 訪問数: null

トラブルシューティングガイド：


1.どのようarp_responderを使用するには？
2.どのようにl2pop環境を構築するには？



3. ARPレスポンダ

    原則arp_responder複雑ではありません。Neutorn DBは、すべてのポートのMACおよびIPアドレスデータに保存されています。しかし、ARPクエリは、別のIP仮想マシンに応じて仮想MACアドレス機密です。したがって、唯一の中性子サーバRPC ML2エージェントによってマシンは、マシンが存在するのに適しているとなるように、それは、ARPプロキシ上の仮想マシンにBR-TUNすることができ、MAC及びIPポートにそれぞれ計算をすべてのアクティブノードを教えARP要求に応じて、ローカルBR-TUNによって解決することができます。アサフメラーARPレスポンダを説明するエッセイ。

 

  ARP応答者は2つの条件を満たす必要があり使用します。

 

（1）=真OVSはARP処理能力を使用arp_responder設定。これは、（OVSのバージョンを確認するためにOVS-vswitchd --version実行されている）OVS 2.1を必要とし、駆動ML2のl2populationをサポートしています。トンネルモードを使用する場合、OVSではなく、放送メカニズムを使用してのARP要求を処理することができます。OVSのバージョンが十分でない場合、Neutornは、ARP応答エントリを設定することができない、あなたはopenvswitchエージェントが「標準エラーログが表示されます：「2015-07-11T04：57：32Z |宛先フィールドのarp_opが書き込み可能ではありません| WARN | 00001 | meta_flowを\ novs-ofctl： - ：2：アクションが指定された試合（OFPBAC_BAD_SET_ARGUMENT）と無効です\ n 'の中のBR-TUN」コマンドをダンプは、流れOVS-ofctl対応した出力を参照してください 『などの間違いは、あなたがしてなりません』 ARP応答者のエントリー。

 

（2）l2_population = trueを設定します。mechanism_driversを追加する際に= openvswitch、l2population。中性子OVSは、SDNコントローラARP表フローそれ入力として必要。


3.1 OVSのアップグレード

中性子openvswitch、ovs- *様々なプロセスを強制終了

 

＃コンパイラのインストール

 

コードの最新バージョンをダウンロードし、解凍、ディレクトリに解凍するhttp://openvswitch.org/download/後

 

gccなどの依存関係をインストールし、作ります

 

【バッシュシェル]  プレーンテキストビューは、  コードをコピー
?
1
2
3
uname -r
. /configure --with-linux= /lib/modules/3 .13.0-51-generic /build
make && make install

 

＃表示インストールされているバージョン

 

【バッシュシェル]  プレーンテキストビューは、  コードをコピー
?
1
2
3
4
root@compute2: /home/s1 # ovs-vsctl --version
ovs-vsctl (Open vSwitch) 2.3.2
Compiled Jul 12 2015 09:09:42
DB Schema 7.6.2

 

＃ハンドルデシベル

 

【バッシュシェル]  プレーンテキストビューは、  コードをコピー
?
1
2
rm /etc/openvswitch/conf .db （老的db要删除掉，否则会报错）
ovsdb-tool create /etc/openvswitch/conf .db vswitchd /vswitch .ovsschema

 

＃スタートOVS

 

【バッシュシェル]  プレーンテキストビューは、  コードをコピー
?
1
2
3
cp /usr/local/bin/ovs- * /usr/bin
ovsdb-server /etc/openvswitch/conf .db -vconsole:emer -vsyslog:err -vfile:info --remote=punix: /usr/local/var/run/openvswitch/db .sock --private-key=db:Open_vSwitch,SSL,private_key --certificate=db:Open_vSwitch,SSL,certificate --bootstrap-ca-cert=db:Open_vSwitch,SSL,ca_cert --no-chdir --log- file = /var/log/openvswitch/ovsdb-server .log --pidfile= /var/run/openvswitch/ovsdb-server .pid --detach --monitor
ovs-vswitchd unix: /usr/local/var/run/openvswitch/db .sock -vconsole:emer -vsyslog:err -vfile:info --mlockall --no-chdir --log- file = /var/log/openvswitch/ovs-vswitchd .log --pidfile= /var/run/openvswitch/ovs-vswitchd .pid --detach --monitor

 

＃は、OVS-vsctl確保、中性子openvswitchエージェントを起動して、OVS-ofctlコールログファイルにエラーが含まれていません。

 

＃変更は、/ usr / share / openvswitch /スクリプト/ OVS-libのファイル、OVS後に再起動マシンの正常な動作を確保するために

 

将RUNDIR = $ {OVS_RUNDIR - 'の/ var /実行/ openvswitch'}改为RUNDIR = $ {OVS_RUNDIR - 'は/ usr / local / VAR /実行/ openvswitch'}


3.2 ARPレスポンダ

arp_responderとした後、BR-TUNフローテーブルといくつかの処理を追加します。

 

（1）表2の増加の流れを、仮想マシンテーブル21にローカルARPブロードキャストフレームからなるように


放送-EDの要求がローカルARP_RESPONDERテーブルに行く＃ARPがローカルで解決するために

、テーブル= 2、n_packets = 0、n_bytes = 0、idle_age = 3、優先順位= 1、ARP、=のFF dl_dst：FF：FF：FF：FF： FFアクション=再送信し（21）

（2）毛髪に表22にフローテーブル21の上昇を


＃ザARPのいずれも、要求IPに対応するエントリない場合には、ブロードキャスト-EDパケットがフラッディング表に再送信され

= 21である表、n_packets = 0、n_bytes = 0、idle_age =は4、優先度= 0アクション=再送信（22）と

以下の（3）さらに高めるために、フロールールは、この要求を処理できない場合は、すべてのポートをあふれさせる表22に行きます。

（3）エントリテーブル21によって送信されたL2集団を更新します。

 

  新しいl2popアドレスが来たときに、テーブル21が更新されます。例えば、Cは、ノードAを計算し、新しい仮想マシンVM3を加算し、計算し、BはホストC、ネットワーク「Z」にVM3（IPは***、MACは***）をl2popというメッセージを受け取りますインチ 次いで、計算A及びBは、テーブル21内のそれぞれの流れを増加させるであろう。   


  br.add_flow（表= 21、優先順位= 1、プロト= 'ARP'、dl_vlan = local_vid、nw_dst = IP、アクション=アクション）

    アクションがどこにあるか（まああいまいな、これは...幸いなことに、詳細に説明されているが定義された素敵な文法があります）

 

[Pythonの]  プレーンテキストビューは、  コードをコピー
?
1
2
3
4
5
6
7
8
ARP_RESPONDER_ACTIONS = ( 'move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],'
                          'mod_dl_src:%(mac)s,'
                          'load:0x2->NXM_OF_ARP_OP[],'
                          'move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],'
                          'move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],'
                          'load:%(mac)#x->NXM_NX_ARP_SHA[],'
                          'load:%(ip)#x->NXM_OF_ARP_SPA[],'
                          'in_port' )



プロセスの（4）表21

     各フローのテーブル21、及び着信データフレームが一致（IP ARPプロトコル、ネットワーク、仮想マシン）を行います。一致が見つかった場合は、IPおよびMACを含むARP応答パケットの構成は、元のポートから仮想マシンに送り返されます。一致しない場合、その後、洪水を作るために、テーブル22に転送されます。

 

で増加したフローテーブル の赤色 部分：

 

<ignore_js_op>

 

   したがって、2.1は、Neutornは、ARPは、高価なARPブロードキャストを回避することにより、局部的にL2-ポップ機構ドライバとOVSを使用して仮想マシンを要求に答えることができます。この機能は、GREのためであるとVXLANはジュノのリリースで行われ得ます。青写真は、この機能ではVLANをサポートしているようだが、完全なようではありません。


4. L2人口

この文書によると、現在、OVSとLinuxのブリッジとGRE / VXLAN、ここではその青写真でVXLANをサポートしていl2pop。


4.1原理

    l2pop原理は複雑ではありません。中性子は、各ポートのステータスを保存し、ポートは、ネットワーク関連のデータを保持しています。仮想マシンの起動時には、下のポートからアクティブに状況を構築します。ポートの状態の変化が毎回発生した場合そのため、関数が呼び出されますupdate_port_postcommitは以下のとおりです。

 

[JavaScriptを]  プレーンテキストビューは、  コードをコピー 
{'status': 'DOWN/BUILD/ACTIVE', 'binding:host_id': u'compute1', 'allowed_address_pairs': [], 'extra_dhcp_opts': [], 'device_owner': u'compute:nova', 'binding:profile': {}, 'fixed_ips': [{'subnet_id': u'4ec65731-35a5-4637-a59b-a9f2932099f1', 'ip_address': u'81.1.180.15'}], 'id': u'1167e9ac-e10f-4cf5-bd09-6649eab38b32', 'security_groups': [u'f5377a66-803d-481b-b4c3-a6631e8ab456'], 'device_id': u'30580ea7-c456-416b-a01e-0fe645edf5dc', 'name': u'', 'admin_state_up': True, 'network_id': u'86c0d29b-4880-4739-bd68-eb3c392f5099', 'tenant_id': u'74c8ada23a3449f888d9e19b76d13aab', 'binding:vif_details': {u'port_filter': True, u'ovs_hybrid_plug': True}, 'binding:vnic_type': u'normal', 'binding:vif_type': u'ovs', 'mac_address': u'fa:16:3e:4f:59:9d'}

 

在某些状态变化下：

 

  • update_port_postcommit (down to active) -> _update_port_up -> add_fdb_entries -> fdb_add -> fdb_add_tun -> setup_tunnel_port  （如果 tunnel port 不存在，则创建 tunnel port）, add_fdb_flow -> add FLOOD_TO_TUN flow （如果是 Flood port，则将端口添加到 Flood output ports）; setup_entry_for_arp_reply('add'。如果不是 Flood port，那么 添加 ARP Responder entry （MAC -> IP）) 以及 add UCAST_TO_TUN flow Unicast Flow entry （MAC -> Tunnel port number）。

 

  • update_port_postcommit (active to down) -> _update_port_down -> remove_fdb_entries

 

  • delete_port_postcommit (active to down) -> _update_port_down -> remove_fdb_entries -> fdb_remove -> fdb_remove_tun -> cleanup_tunnel_port, del_fdb_flow -> mod/del FLOOD_TO_TUN flow; setup_entry_for_arp_reply ('remove'), delete UCAST_TO_TUN flow

 

  • update_port_postcommit (fixed ip changed) -> _fixed_ips_changed -> update_fdb_entries

 

    通过这种机制，每个节点上的如下数据得到了实时更新，从而避免了不必要的隧道连接和广播。

 

  • Tunnel port
  • FLOOD_TO_TUN （table 22）flow
  • ARP responder flow
  • UCAST_TO_TUN （table 20） flow

 

有和没有 l2pop 的效果：

 

<ignore_js_op>


4.2 过程实验

1. def tunnel_sync(self) 函数除了上报自己的 local_ip 外不再自己见 tunnels，一切等 l2pop 的通知。

 

2. 在 compute1 上添加第一个虚机 81.1.180.8

 

neutron-server：

 

  • 通知 compute1： {'segment_id': 6L, 'ports': {u'10.0.1.21': [['00:00:00:00:00:00', '0.0.0.0'], [u'fa:16:3e:87:40:f3', u'81.1.180.1']]}, 'network_type': u'gre'}}
  • 通知所有 agent： {'segment_id': 6L, 'ports': {u'10.0.1.31': [['00:00:00:00:00:00', '0.0.0.0'], [u'fa:16:3e:b3:e7:7a', u'81.1.180.8']]}, 'network_type': u'gre'}}

 

compute1：

 

  • 添加和网络节点的tunnel options: {df_default="true", in_key=flow, local_ip="10.0.1.31", out_key=flow, remote_ip="10.0.1.21"}
  • 添加到网段网关的 Unicast flow：table=20, n_packets=0, n_bytes=0, idle_age=130, priority=2,dl_vlan=2,dl_dst=fa:16:3e:87:40:f3 actions=strip_vlan,set_tunnel:0x6,output:4
  • 增加网段 81.1.180.1 网关的 ARP flows：table=21, n_packets=0, n_bytes=0, idle_age=130, priority=1,arp,dl_vlan=2,arp_tpa=81.1.180.1 actions=move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],mod_dl_src:fa:16:3e:87:40:f3,load:0x2->NXM_OF_ARP_OP[],move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],load:0xfa163e8740f3->NXM_NX_ARP_SHA[],load:0x5101b401->NXM_OF_ARP_SPA[],IN_PORT
  • 修改 Flood flow

 

compute 2 节点：因为它上面还没有运行虚机，所以不做操作。

 

3. 在 compute 2 上添加一个虚机 81.1.180.9

 

neutron server：

 

  • 通知 compute 2 ： {'segment_id': 6L, 'ports': {u'10.0.1.31': [['00:00:00:00:00:00', '0.0.0.0'], [u'fa:16:3e:b3:e7:7a', u'81.1.180.8']], u'10.0.1.21': [['00:00:00:00:00:00', '0.0.0.0'], [u'fa:16:3e:87:40:f3', u'81.1.180.1']]}, 'network_type': u'gre'}}
  • 通知所有 agent： {'segment_id': 6L, 'ports': {u'10.0.1.39': [['00:00:00:00:00:00', '0.0.0.0'], [u'fa:16:3e:73:49:41', u'81.1.180.9']]}, 'network_type': u'gre'}

 

compute1：

 

  • 建立 tunnel（ID 5）：  {df_default="true", in_key=flow, local_ip="10.0.1.31", out_key=flow, remote_ip="10.0.1.39"}
  • 增加 arp responder flow（compute2 上新的虚机 IP -> MAC）：table=21, n_packets=0, n_bytes=0, idle_age=79, priority=1,arp,dl_vlan=2,arp_tpa=81.1.180.9 actions=move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],mod_dl_src:fa:16:3e:73:49:41,load:0x2->NXM_OF_ARP_OP[],move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],load:0xfa163e734941->NXM_NX_ARP_SHA[],load:0x5101b409->NXM_OF_ARP_SPA[],IN_PORT
  • 增加 unicast flow （新虚机的 MAC -> Tunnel port）：table=20, n_packets=0, n_bytes=0, idle_age=79, priority=2,dl_vlan=2,dl_dst=fa:16:3e:73:49:41 actions=strip_vlan,set_tunnel:0x6,output:5
  • 添加新的 Tunnel port 到 Flood flow：table=22, n_packets=13, n_bytes=1717, idle_age=255, hard_age=78, dl_vlan=2 actions=strip_vlan,set_tunnel:0x6,output:5,output:4

 

compute2：

 

  • 建立和计算节点以及compute1的tunnel：options: {df_default="true", in_key=flow, local_ip="10.0.1.39", out_key=flow, remote_ip="10.0.1.21"}，options: {df_default="true", in_key=flow, local_ip="10.0.1.39", out_key=flow, remote_ip="10.0.1.31"}
  • 增加 ARP flow（compute 1 上的虚机的 MAC -> IP）：table=21, n_packets=0, n_bytes=0, idle_age=268, priority=1,arp,dl_vlan=2,arp_tpa=81.1.180.8 actions=move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],mod_dl_src:fa:16:3e:b3:e7:7a,load:0x2->NXM_OF_ARP_OP[],move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],load:0xfa163eb3e77a->NXM_NX_ARP_SHA[],load:0x5101b408->NXM_OF_ARP_SPA[],IN_PORT
  • 增加 Unicast flow （compute 1 上的虚机 MAC -> Tunnel port）：table=20, n_packets=0, n_bytes=0, idle_age=268, priority=2,dl_vlan=2,dl_dst=fa:16:3e:b3:e7:7a actions=strip_vlan,set_tunnel:0x6,output:4
  • 增加 ARP flow（新虚机的网关的 MAC -> IP） table=21, n_packets=0, n_bytes=0, idle_age=268, priority=1,arp,dl_vlan=2,arp_tpa=81.1.180.1 actions=move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],mod_dl_src:fa:16:3e:87:40:f3,load:0x2->NXM_OF_ARP_OP[],move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],load:0xfa163e8740f3->NXM_NX_ARP_SHA[],load:0x5101b401->NXM_OF_ARP_SPA[],IN_PORT
  • 修改 Flood flow（添加到 Compute 1 的 port）：table=22, n_packets=13, n_bytes=1717, idle_age=128, dl_vlan=2 actions=strip_vlan,set_tunnel:0x6,output:5,output:4

 

3. 删除 compute1 上的一个vm（也是唯一的一个）

 

neutron server：

 

  • 通知所有 agent： {'segment_id': 6L, 'ports': {u'10.0.1.31': [['00:00:00:00:00:00', '0.0.0.0'], [u'fa:16:3e:b3:e7:7a', u'81.1.180.8']]}, 'network_type': u'gre'}

 

compute 1：

 

  • 因为没有别的虚机了，删除所有 tunnel ports
  • 修改或者删除 ARP, Unicast 和 Flood flows

 

compute 2：

 

  • 删除了 compute1 的 tunnel
  • 删除该虚机对应的 ARP flow

 

4. 在 compute1 上创建第一个不同网络的虚机

 

neutron server：

 

  • 通知 compute 1： {u'e2022937-ec2a-467a-8cf1-f642a3f777b6': {'segment_id': 4L, 'ports': {u'10.0.1.21': [['00:00:00:00:00:00', '0.0.0.0'], [u'fa:16:3e:90:e5:50', u'91.1.180.1'], [u'fa:16:3e:17:c9:26', u'90.1.180.1'], [u'fa:16:3e:69:92:30', u'90.1.180.3'], [u'fa:16:3e:69:92:30', u'91.1.180.2']]}, 'network_type': u'gre'}}
  • 通知所有 agent：{u'e2022937-ec2a-467a-8cf1-f642a3f777b6': {'segment_id': 4L, 'ports': {u'10.0.1.31': [['00:00:00:00:00:00', '0.0.0.0'], [u'fa:16:3e:e9:ee:0c', u'91.1.180.9']]}, 'network_type': u'gre'}}

 

compute 1：建立和网络节点的 tunnel port；更新 Flood flows；添加 ARP flows

 

compute 2：没什么action，因为该节点上没有新建虚机的网络内的虚机

 

过程的大概说明：

 

  • 虚机在收到 fannout FDB entries 后，检查其中每个 port 的 network_id（即 “segment_id”）。如果本机上有该 network 内的 port，那么就处理 entries 中的 “ports”部分；否则，不处理该 entries。
  • 因此，当计算节点上没有运行任何虚机时，不会建立任何 tunnel。如果两个虚机上有相同网络内的虚机，那么建立会建立 tunnel。
  • 这种机制能实时建立 tunnel port，Flood entry （创建 Tunnel port 同时添加到 Flood output ports 列表）， Unicast flow （虚机和网关 MAC -> Tunnel port） 和 ARP Responder entry  （虚机和网关 MAC -> IP）。下图中的蓝色部分的流表都会被及时更新。
  • Neutron server 在端口创建/删除/修改时，如果是该节点上的第一个虚机，首先发送直接消息；然后发通知消息给所有的计算和网络节点。

 

<ignore_js_op>




4.3 性能

4.3.1 MQ 性能问题

    应该说 l2pop 的原理和实现都很直接，但是在大规模部署环境中，这种通知机制（通知所有的 ML2 Agent 节点）可能会给 MQ 造成很大的负担。一旦 MQ 不能及时处理消息，虚机之间的网络将受到影响。下面是 l2pop 中通知机制代码：

 

[Python]  纯文本查看 复制代码
?
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
def __init__( self , topic = topics.AGENT):
         super (L2populationAgentNotifyAPI, self ).__init__(
             topic = topic, default_version = self .BASE_RPC_API_VERSION)
         self .topic_l2pop_update = topics.get_topic_name(topic, topics.L2POPULATION, topics.UPDATE)
 
     def _notification_fanout( self , context, method, fdb_entries):
         self .fanout_cast(context, self .make_msg(method, fdb_entries = fdb_entries), topic = self .topic_l2pop_update)
 
     def _notification_host( self , context, method, fdb_entries, host):
         self .cast(context, self .make_msg(method, fdb_entries = fdb_entries), topic = '%s.%s' % ( self .topic_l2pop_update, host))
 
     def add_fdb_entries( self , context, fdb_entries, host = None ):
         if fdb_entries:
             if host:
                 self ._notification_host(context, 'add_fdb_entries' ,fdb_entries, host) #cast 给指定 host
             else :
                 self ._notification_fanout(context, 'add_fdb_entries' , fdb_entries) #fanout 给所有计算和网络节点

 

这段代码是说，l2pop 采用的 MQ topic 是 “L2POPULATION”，消息通知采用 fanout 或者 cast 机制。如果是 fanout 的话，消息将发到所有的 ML2 agent 节点。这样的话，其覆盖面就有些过于广泛了，就这个问题有人提了一个 ticket，官方答复是 work as design，要改的话只能是添加 new feature 了。


4.3.2 大规模网络环境中节点上的 OpenFlow flows 过多

    不知道这个数目有没有上限？数目很多的情况下会不会有性能问题？OVS 有没有处理能力上限？这些问题也许得在实际的生产环境中才能得到证实和答案。
 
 
 
 

おすすめ

転載: www.cnblogs.com/liuhongru/p/11121142.html
おすすめ
ランキング
Oracleのクエリ重複フィールド
An error occurred when ssm used count to query data
【Leyes de la Naturaleza】La sabiduría de las multitudes
JavaWebの研究では、（13）を締結 - セッションの使用は、重複送信フォームを防ぎます
Firebase増加サインアップクォータ
[MyBatisフレームワーク]mybatis入門
ハートレスの世界
Djangoのインストールと使用について
[转] UiPath展開アーキテクチャ
mybatis-plusは楽観的なロック変更を使用します
アーカイブ
もっと
2024-05-14(9)
2024-05-13(8)
2024-05-12(27)
2024-05-11(31)
2024-05-10(33)
2024-05-09(30)
2024-05-08(18)
2024-05-07(34)
2024-05-06(6)
2024-05-05(0)

コードワールド

© 2018 codetd.com