解决了

VM网络故障排除

  • 2020年5月12日
  • 5回复
  • 2110意见
j

你好，

如果使用余额SLB，则如何弄清楚一个VM正在使用哪个物理？

例如，使用ESXi，我会运行Esxtop，我可以看到哪个物理NIC被“映射”到我的虚拟NIC。AHV有可能吗？如果是的话怎么样？

我认为在排除故障时很重要。

图标

最好的答案Diegodco.2020年5月13日，00:29

查看原版
Hello,\u00a0<\/p>

If you use balance-slb, how does one figure out which physical is being used by one VM ?<\/p>

For instance, with ESXi I\u2019d run esxtop, and I can see which physical nic is being \u201cmapped\u201d to my virtual nic. Is it possible with AHV? If yes how ?\u00a0<\/p>

I think it is important when you troubleshoot.<\/p>","quoteUsername":"jgautierit","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">

此主题已关闭征询意见

5回复

D.

你好

您可以使用网络可视化：

https://portal.nutanix.com/page/documents/kbs/details/?targetid=ka032000000tvficag.

https://next.nutanix.com/how-it-works-22/network-visualization-and-network-switch-information-37473.

j

这是唯一的方法吗？没有CLI命令？

Is it the only way ? No cli commands ?\u00a0<\/p>","quoteUsername":"jgautierit","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">
D.

我不知道任何匹配命令在ahv上的esxtop。

I don\u2019t know any matching command to esxtop on AHV.<\/p>","quoteUsername":"diegodco","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">
j

谢谢你的回答！

Thank you for answering !<\/p>","quoteUsername":"jgautierit","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">
Bbburs.
秩
UserLevel 2.
徽章 +14

如果使用余额SLB，则VM源MAC地址将由OV转换为哈希（1-255）。然后，该散列值在Bond_Rebalance_Interval的键合的主动物理适配器之间（默认为10秒，Nutanix建议30秒）之间平衡。

您可以通过使用CVM的以下命令查看每个适配器上的活动哈希值：

SSH.root@192.168.5.1OVS-APPCTL BOND / SHOW

您将看到输出，如：

$ ssh root@192.168.5.1 OVS-APPTL键/显示

---- br0p ----

BOND_MODE：余额SLB

下一次重新平衡：4762毫秒

主动奴隶MAC：00：E0：ED：73：F3：5F（eth3）

Slave eth2：启用

may_enable：真实

哈希10：5 KB负荷

哈希22：1 KB负荷

哈希34：1 KB负载

哈希58：1 KB负荷

哈希60：6 KB负荷

哈希68：6 KB负荷

哈希78：21 KB负荷

哈希81：1 KB负载

哈希83：1574 KB负荷

......

Slave eth3：启用

活跃奴隶

may_enable：真实

哈希2：2 KB负载

哈希3：11 KB负荷

哈希4：23 KB负荷

哈希8：3 KB负载

哈希13：48 KB负载

哈希17：25 KB负荷

哈希19：1 KB负载

据我所知，没有简单的方法来确定哪些MAC地址属于哈希值。由于最多255个哈希值，并且不避免哈希碰撞，因此多个VM可能会溅到相同的值。

余额-SLB的目标是尝试均匀地分布来自一组债券接口之间的许多源MAC地址的流量，并将其随着时间的推移而保持平衡，以上策略改变，上述策略完成。

缺点如下：

  1. 您无法轻易将单个VM映射到当前活动的链接。
  2. 您无法保证任何两个VM都映射到相对的绑定成员接口。

在多播处理周围有其他缺点是平衡 - SLB，突出显示AHV网络最佳实践指南- 这是值得一看的。

杰森烧伤|ccie协作＃20707 |技术营销工程师|jason.burns@nutanix.com |@bbbburns.
If you use balance-slb, your VM\u00a0source MAC addresses are converted to a hash (1-255) by OVS. This hash value is then balanced between the active physical adapters in the bond at the bond_rebalance_interval (10 second by default, Nutanix recommends 30 seconds).<\/p>

You can view the active hashes on each adapter by using the following\u00a0command from the CVM:<\/p>

ssh root@192.168.5.1<\/a>\u00a0ovs-appctl bond\/show<\/code><\/p>

\u00a0<\/p>

You\u2019ll see output like:<\/p>

$ ssh root@192.168.5.1 ovs-appctl bond\/show<\/code><\/p>

---- br0-up ----<\/code><\/p>

bond_mode: balance-slb<\/code><\/p>

next rebalance: 4762 ms<\/code><\/p>

active slave mac: 00:e0:ed:73:f3:5f(eth3)<\/code><\/p>

\u00a0<\/p>

slave eth2: enabled<\/code><\/p>

may_enable: true<\/code><\/p>

hash 10: 5 kB load<\/code><\/p>

hash 22: 1 kB load<\/code><\/p>

hash 34: 1 kB load<\/code><\/p>

hash 58: 1 kB load<\/code><\/p>

hash 60: 6 kB load<\/code><\/p>

hash 68: 6 kB load<\/code><\/p>

hash 78: 21 kB load<\/code><\/p>

hash 81: 1 kB load<\/code><\/p>

hash 83: 1574 kB load<\/code><\/p>

...<\/p>

\u00a0<\/p>

slave eth3: enabled<\/code><\/p>

active slave<\/code><\/p>

may_enable: true<\/code><\/p>

hash 2: 2 kB load<\/code><\/p>

hash 3: 11 kB load<\/code><\/p>

hash 4: 23 kB load<\/code><\/p>

hash 8: 3 kB load<\/code><\/p>

hash 13: 48 kB load<\/code><\/p>

hash 17: 25 kB load<\/code><\/p>

hash 19: 1 kB load<\/code><\/p>

\u00a0<\/p>

As far as I know, there is no easy way to determine which MAC addresses belong to which hash value. Since there are a maximum of 255 hash values, and hash collision is not avoided, it\u2019s possible that more than one VM gets hashed to the same value.<\/p>

\u00a0<\/p>

The goal of balance-slb is to attempt to evenly distribute traffic from a number of source MAC addresses among a set of bond interfaces, and maintain that balance over time as traffic patterns change, which the above strategy accomplishes.<\/p>

\u00a0<\/p>

The drawbacks are as follows:<\/p>

  1. You cannot easily map a single VM to the currently active link.<\/li>
  2. You cannot guarantee that any two VMs are mapped to opposing bond member interfaces.<\/li> <\/ol>

    \u00a0<\/p>

    There are other drawbacks to balance-slb around multicast handling, highlighted in the AHV Networking Best Practices Guide<\/a> - which is worth a look.<\/p>","quoteUsername":"bbbburns","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">

Baidu