虽然该行业在每个市场都在鼓吹云计算，而用户，无论是急切地、不情愿地还是不知不觉地开始排队，但似乎很少有人谈论互联网的实际结构以及无可否认地介于客户和他们的使命之间的永远存在的复杂性关键的云服务。
因此，对于任何类型的连接问题，几乎没有人能接受；没关系，即使是欧洲北部郊区相当大的服务提供商，也可以影响骨干提供商之间的全球流量流动或缓解跨大西洋拥堵，其程度与附近的会议酒店大致相同，所述服务提供商在那里举办客户培训会议，可以阻止联合航空公司（当然，仅由于“紧迫的、不可预见的和其他未公开的乘客安全问题”。我相信你明白。）尽管酒店有明显且无可争议的义务，但取消客户团队的出境航班做好不可退款的房间预订。
简单来说，客户越来越希望服务提供商承担起他们的责任，以确保持续的服务可用性和性能，至少在客户自己的 Internet 上行链路之外。只需单击一下鼠标，竞争就不再遥远，我觉得多宿主正在迅速成为即使是最小的 SaaS 或其他互联网相关服务提供商的绝对要求——除了建立在第三方基础设施之上，在这种情况下同样的要求属于上述第三方。
不幸的是，BGP与以往一样复杂、繁琐和可怕，而且似乎不太适合没有专门的 wan 人员团队的相对较小的操作。因此，我一直在努力寻找一种相当强大、简单且廉价的解决方案，该解决方案将允许通过两个 Internet 服务提供商进行动态路由，而无需从您自己的 AS运行完整的 BGP。
现在，我想我终于有了一个可用设计的想法，该设计至少将动态路由协议保持在一定范围内，并且在大多数情况下，在两个 ISP 的各自域内。
设置利用一对夫妇的著名力学的BGP routing protocol和F5 Networks BigIP appliance。首先，BGP 会关注最具体的适用路由对象。这允许两个 ISP 宣布更大/22 route的和更具体的/23 route每个，从而在正常操作期间有效地将块切成两半。由于两者/23 routes合并占整个/22 block；只要两个 ISP 都可以访问，就/22 routes应该忽略 ，从而让流量根据/23 routes绿色标记流向每个站点。
如果，比方说，链路ISP 2断开，AS 200 应该撤回两条路由（或撤回小路由并降级另一个，因为他们仍然可以代表它的对等方宣布AS 1000）并且流量将开始流向/22 route已经宣布的AS 1000，运气好，跟随红色标记。
由于两者BigIP appliances都可从ISP gateways同一第 2 层网段中到达，因此重新路由的流量将跨Lan 2 Lan链路桥接，并以与BigIP appliance以前相同的方式结束，尽管它们将到达面向 的两个端口之一，Lan 2 Lan而不是面向 的端口ISP 2 gateway.
在这里，他提到的两个机制中的第二个开始发挥作用。通过该商品的特定要求的网络端口默认发送答复将起源，同样（或者我希望如此）直接流量始发端网关。诚然，我还没有测试有关转发到始发路由器的回复的部分；我想这可能是必要的某种规则的更新，也许用一个简单的本地路由协议或者甚至让上（或如果可能的话，在剩余的健康）接管不健康的IP地址。BigIPstatic gateway route entryVIP interfaceBigIPISP gatewayISP gateway
在此特定布局中，两个 ISP 已经具有直接对等互连的事实似乎增加了解决方案的稳健性。这些很可能已经代表彼此向各自的同行宣布了我们的路线。这既可以帮助减少中断的直接影响，也可以加速重新获得完全可达性所需的更改的传播。如果AS 200ofISP 2变得几乎不可用，尽管以某种方式保持与 toSite B以及BGP sessionto 的连接性ISP 1，则任何目的地ISP 2到达的流量都AS 1000将简单地转发到AS 200并从那里加入绿色标记的路径。
当然，如果这些场景中的任何一个被颠倒并且故障发生在ISP 1侧面，那么反映前面概述的那些效果应该会出现，并且流量应该同样开始沿着蓝色标记的路径流动。
至于设计的其余部分，将其与DNS round-robin在两个站点之间分发初始请求相结合应该是可能的，甚至是有益的。该设置还意味着tolerate任何内部组件的故障，包括整个站点停电。
所以。认为这应该可以正常工作吗？有什么理由不应该这样做？我错过了什么大问题吗？看到任何可能的改进吗？或者甚至有一个更好的选择？正如他们所说，我全神贯注:)