![关于 MAC 和高可用性故障转移的新手问题](https://linux22.com/image/797540/%E5%85%B3%E4%BA%8E%20MAC%20%E5%92%8C%E9%AB%98%E5%8F%AF%E7%94%A8%E6%80%A7%E6%95%85%E9%9A%9C%E8%BD%AC%E7%A7%BB%E7%9A%84%E6%96%B0%E6%89%8B%E9%97%AE%E9%A2%98.png)
我正在阅读有关高可用性的文章,但我无法理解以下内容:在故障转移时,主 IP 会迁移到备份服务器,但 MAC 地址也必须如此。
具体来说,我读到每台机器都有一个唯一的地址 MAC,该地址可供机器中的所有接口使用。我不明白这部分。MAC 不属于 NIC 吗?这句话中的接口是什么意思?
此外,在故障转移时,客户端必须更新其 IP/MAC 映射,并找到了 3 种方法,其中一种方法是使用自定义 MAC,并将其与公共 IP 一起从主 MAC 移至备份 MAC。这怎么可能呢?高可用性软件(例如 Pacemaker)可以做到这一点吗?如何做到?
答案1
这本书是正确的,但是它遗漏了一些部分。
- MAC 地址并不像您想象的那样固定,大多数高端 NIC 都能够将 MAC 地址更改为特定地址。无论是在 NIC 的 BIOS 中还是在驱动程序本身中。
- 为“虚拟”系统预留了特定范围的 MAC 地址(见我可以安全地为我的虚拟机使用哪些范围的 MAC 地址?)
- 集群软件可能会使用这些预留范围内的 MAC 地址来提供集群 IP 服务。
- Linux 网络堆栈能够创建具有特定 MAC 地址的虚拟 NIC。
集群软件基于虚拟 MAC 地址创建服务的过程非常简单。当服务启动时,它会提供一个 Gratuitous Arp 数据包,表示可以在虚拟 MAC 地址上找到特定 IP 地址。当发生故障转移时,“关闭”节点会删除其本地 IP/MAC 绑定,新节点会开始侦听该虚拟 MAC 地址和 IP 组合。没有麻烦,没有麻烦。
集群软件使用的另一种方法是根本不考虑虚拟 MAC,而是全程依赖 Gratuitous ARP。此类系统的启动/故障转移顺序如下:
- 集群软件将 IP 绑定到节点 A。
- 节点 A G-ARP“192.168.244.60 位于 02-00-ab-cd-ef-01”
- 子网上的所有设备都会更新其 ARP 表。
- 时间流逝。
- 节点 A 崩溃。
- 集群软件将 IP 绑定到节点 B。
- 节点 B G-ARP“192.168.244.60 位于 02-00-ab-cd-41-ba”
- 子网上的所有设备都会更新其 ARP 表。
根据我的经验,第二种方法,即纯 G-ARP,是目前大多数 Linux 集群使用的方法。但是,这两种方法都是有效的,并且已经被使用过。G-ARP 方法的好处是您不必为分配虚拟 MAC 地址而烦恼。纯虚拟 MAC 方法的好处是它不依赖于给定子网上的 G-ARP 工作。
答案2
听起来你找到了非常糟糕的阅读材料。介意发个参考吗?
一般来说:OSI 层模型解决了大多数问题,您几乎不需要同时在多个层上工作。
MAC 地址只能在以太网段中出现一次。在物理机上,MAC 地址是全局唯一的,绝不会重复出现(即使在同一台机器上的多个 NIC 上也不会重复出现)。使用虚拟机时,您可以通过软件设置 MAC,并且必须使用一些类似于私有 IP 范围的私有 MAC 范围。
为了实现 IP 的高可用性,只需在不同主机上配置 IP 即可。第 2 层的操作系统和网络基础设施将负责自动更新其 MAC/IP 映射。
然而,有些设备很顽固,需要“免费” ARP 请求来强制它们更新缓存。
在 Linux 上,我使用“ucarp”和附加脚本来自动配置具有这些“集群”IP 的机器。
答案3
答案4
在某些 HA 场景中,发生 HA 事件时,备用节点只会收回 IP 地址。在这种情况下,备用节点需要广播未经请求的 ARP 数据包,以更新同一以太网段上设备的 ARP 表。在收到未经请求的 ARP 数据包时,设备通常不会直接更新其 ARP 表(这将允许轻松入侵网络),而是使相应 IP 地址上的 ARP 条目无效。下次设备需要与 HA 服务通信时,它将发出 ARP 请求以获取与 IP 地址对应的 MAC。
在其他一些 HA 场景中(如某些路由器和防火墙),MAC 地址和 IP 地址都由备用节点收回。这允许同一以太网段上的客户端保持其 ARP 表完好无损,但这并不意味着备用节点可以保存其 ARP 广播(或其他形式的网络流量)。在这种情况下,需要 ARP 广播(或其他网络流量)来更新交换机 MAC 到端口表,以便流量不会在死设备端口上结束。
您可以阅读本文以了解更多(开关的详细内部工作原理)[网络嗅探软件如何在交换机上工作?。