假设我们有两个具有“真实”和外部IP的服务器A和B,我们可以将所谓的
‘failover ip’(W.X.Y.Z)切换为指向A或B的特定外部IP.这可以从“外部”开始,并且很容易完成.
作为背景：故障转移ip配置为/ etc / network / interfaces中的新条目：
作为背景：故障转移ip配置为/ etc / network / interfaces中的新条目：
auto eth0:0 iface eth0:0 inet static address W.X.Y.Z netmask 255.255.255.224
现在让我们假设WXYZ被动态配置为使用硬件A.现在我从B调用’curl domain.com’它使用正确的故障转移ip WXYZ然后以某种方式解析为错误的外部IP B(或localhost？)而不是使用配置的一个A：
Trying W.X.Y.Z ... * connect to W.X.Y.Z port 443 Failed: Connection refused * Failed to connect to domain.com port 443: Connection refused * Closing connection 0 curl: (7) Failed to connect to domain.com port 443: Connection refused
当我启动本地Nginx时,它可以成功地卷曲domain.com
我是否需要以某种方式在本地配置DNS？如何了解有关DNS链的更多信息？
如果从服务器B尝试此操作,则使用mtr只打印domain.com
这与this question有关吗？
The failover IP is W.X.Y.Z and is also the A record of domain.com
The /etc/hosts file for both nodes serverA and serverB looks like:
127.0.0.1 localhost
127.0.1.1 luminarhost
xxx serverA
xxx serverB
The /etc/network/interfaces of serverA
### Hetzner Online AG - installimage
# Loopback device:
auto lo
iface lo inet loopback
# device: eth0
auto eth0
iface eth0 inet static
address xxx
broadcast xxx
netmask xxx
gateway xxx
# default route to access subnet
up route add -net xxx netmask 255.255.255.224 gw xxx eth0
iface eth0 inet6 static
address xxx
netmask xxx
gateway xxx
# failover ip
auto eth0:0
iface eth0:0 inet static
address W.X.Y.Z
netmask 255.255.255.224
and of serverB it is:
### Hetzner Online AG - installimage
# Loopback device:
auto lo
iface lo inet loopback
# device: eth0
auto eth0
iface eth0 inet static
address xxx
broadcast xxx
netmask xxx
gateway xxx
# default route to access subnet
up route add -net xxx netmask 255.255.255.192 gw xxx eth0
iface eth0 inet6 static
address xxx
netmask xxx
gateway xxx
# failover ip
auto eth0:0
iface eth0:0 inet static
address W.X.Y.Z
netmask 255.255.255.224
>正如所承诺的,这是我的回答：
>完全披露：我不是为Hetzner工作,而是在过去和现在为不同的公司工作,他们过去常常在Hetzner公司安装硬件.
>如果您的个人资料中的位置正确,并且您需要支持：我位于同一个城市,可以提供一两手牌.
>对于所有从未与Hetzner打交道的人：他们过滤网络访问等,这意味着,特别是关于他们的 failover IPs(可在不同机器上使用以提供某种高可用性的IP),他们正在发送流量针对特定MAC的特定IP.
>如果想要更改流量指向的目标(机器),则必须向通过HTTPS提供的 API发送POST请求.然后,API验证身份验证(用户名和相应的密码)和请求,如果有效,则将此新配置传播到网络中的各种路由器.这种技术类似于OVH,一家位于法国的大型供应商.
>警告：尽管人们使用这些IP为他们的机器/服务提供某种高可用性(如编写),新路由配置的传播需要一些时间,有时长达约60秒.这意味着,例如,如果使用某种类型的自动故障转移,如果流量当前被路由到的机器,在一段时间内停机,人们会注意到,流量就会被丢弃,因为机器已关闭,直到新路由配置到位的时间点.
>到目前为止,我们来看看你的具体问题：
>正如评论/聊天中指出的那样,使用auto eth0：0,一旦网络启动,通常在启动时将在接口eth0：0设置故障转移IP.你有两台具有相同配置的机器,所以这导致了两台不同的机器上同一个IP处于活动状态(这不是禁止的,但导致你目前处理的情况) ).请注意：您正在使用的语法,多次别名相同的界面,是 deprecated(但仍然有效). Debian wiki(此链接)中也描述了“新方法”,它只为一个接口分配了多个IP.
>所以：你已经同时在两台机器上分配了IP.测试用例中的curl执行以下操作：它将给定的域名解析为IP,然后尝试在端口443连接到此IP.因为此IP在任何情况下都是在本地分配的,因此可以访问,所以数据包永远不会被发送出去到网络.如果Nginx(就像在你的测试用例中)在这个时候没有在本地运行,你只是得到连接拒绝,这是完全正常和有效的：“IP是本地的,所以让我们在那里发送流量”.它永远不会将数据包发送到某个路由器,这可能包含以下信息：“指向此IP的流量应该转到此计算机”.
>现在……实际上我并不完全确定你追求的是什么.你只想了解发生的事情吗？如果是这样,我试图描述这个.你想找到/实现一种“解决”这种情况的方法吗？如果是后者,这里有一些想法：
>解决方案1：从/ etc / network / interfaces中删除指令auto eth0：0(但保留eth0：0的其余配置).这样做,不会将IP分配给机器.执行此操作将是您的任务(脚本的任务),它执行ifup eth0：0(并且可能再次说明API以确保流量路由到正确的机器).
>解决方案2,又名“自动化所有事情”：不要进行手动故障转移,而是通过心跳(检查两者之间的健康状况)实现自动执行此操作的系统：存在多种解决方案,例如 Virtual Router Redundancy Protocol和(完全披露：我个人最喜欢的,我多年来一直在使用这个用于这样的任务)： corosync and pacemaker,这是设置在Linux下提供高可用性的集群的事实标准. (另外,请看一下 this.)如果你想尝试以后的方式,Kumina的优秀人员几年前开发(并发布)了 resource agent,以便在Hetzner处理这种情况.资源代理负责通过与API通信来更新路由信息. >结束(现在)：我不完全确定你追求的是什么.我试图描述你现在面临的问题的根本原因.此外,我试图提出一些可能的解决方案的想法.如果我没有得到你想要做的事情,有些事情不清楚或者你还有其他问题：请提供反馈,我很乐意提供帮助(或至少尝试). >(另外：请你把你的配置等移到你的帖子里,把所有的东西放在一个地方,所以这个问题对未来的其他人有帮助吗？)
原文链接：https://www.f2er.com/ubuntu/348455.html>完全披露：我不是为Hetzner工作,而是在过去和现在为不同的公司工作,他们过去常常在Hetzner公司安装硬件.
>如果您的个人资料中的位置正确,并且您需要支持：我位于同一个城市,可以提供一两手牌.
>对于所有从未与Hetzner打交道的人：他们过滤网络访问等,这意味着,特别是关于他们的 failover IPs(可在不同机器上使用以提供某种高可用性的IP),他们正在发送流量针对特定MAC的特定IP.
>如果想要更改流量指向的目标(机器),则必须向通过HTTPS提供的 API发送POST请求.然后,API验证身份验证(用户名和相应的密码)和请求,如果有效,则将此新配置传播到网络中的各种路由器.这种技术类似于OVH,一家位于法国的大型供应商.
>警告：尽管人们使用这些IP为他们的机器/服务提供某种高可用性(如编写),新路由配置的传播需要一些时间,有时长达约60秒.这意味着,例如,如果使用某种类型的自动故障转移,如果流量当前被路由到的机器,在一段时间内停机,人们会注意到,流量就会被丢弃,因为机器已关闭,直到新路由配置到位的时间点.
>到目前为止,我们来看看你的具体问题：
>正如评论/聊天中指出的那样,使用auto eth0：0,一旦网络启动,通常在启动时将在接口eth0：0设置故障转移IP.你有两台具有相同配置的机器,所以这导致了两台不同的机器上同一个IP处于活动状态(这不是禁止的,但导致你目前处理的情况) ).请注意：您正在使用的语法,多次别名相同的界面,是 deprecated(但仍然有效). Debian wiki(此链接)中也描述了“新方法”,它只为一个接口分配了多个IP.
>所以：你已经同时在两台机器上分配了IP.测试用例中的curl执行以下操作：它将给定的域名解析为IP,然后尝试在端口443连接到此IP.因为此IP在任何情况下都是在本地分配的,因此可以访问,所以数据包永远不会被发送出去到网络.如果Nginx(就像在你的测试用例中)在这个时候没有在本地运行,你只是得到连接拒绝,这是完全正常和有效的：“IP是本地的,所以让我们在那里发送流量”.它永远不会将数据包发送到某个路由器,这可能包含以下信息：“指向此IP的流量应该转到此计算机”.
>现在……实际上我并不完全确定你追求的是什么.你只想了解发生的事情吗？如果是这样,我试图描述这个.你想找到/实现一种“解决”这种情况的方法吗？如果是后者,这里有一些想法：
>解决方案1：从/ etc / network / interfaces中删除指令auto eth0：0(但保留eth0：0的其余配置).这样做,不会将IP分配给机器.执行此操作将是您的任务(脚本的任务),它执行ifup eth0：0(并且可能再次说明API以确保流量路由到正确的机器).
>解决方案2,又名“自动化所有事情”：不要进行手动故障转移,而是通过心跳(检查两者之间的健康状况)实现自动执行此操作的系统：存在多种解决方案,例如 Virtual Router Redundancy Protocol和(完全披露：我个人最喜欢的,我多年来一直在使用这个用于这样的任务)： corosync and pacemaker,这是设置在Linux下提供高可用性的集群的事实标准. (另外,请看一下 this.)如果你想尝试以后的方式,Kumina的优秀人员几年前开发(并发布)了 resource agent,以便在Hetzner处理这种情况.资源代理负责通过与API通信来更新路由信息. >结束(现在)：我不完全确定你追求的是什么.我试图描述你现在面临的问题的根本原因.此外,我试图提出一些可能的解决方案的想法.如果我没有得到你想要做的事情,有些事情不清楚或者你还有其他问题：请提供反馈,我很乐意提供帮助(或至少尝试). >(另外：请你把你的配置等移到你的帖子里,把所有的东西放在一个地方,所以这个问题对未来的其他人有帮助吗？)
