随着 Oracle Engineered Systems 的引入，DBA 更接近于基础架构设计决策，并且期望至少对数据库的网络设计要求有一些意见。至少这是我发现自己的情况:)
在部署 ODA 进行测试后，我发现自己使用了当前设置：
系统控制器 0 具有连接到典型边缘交换机 Catalyst 2960 系列的公共绑定接口 (bond0)。管理接口 (bond1) 连接到相同类型的第二个边缘交换机。
系统控制器 1 的公共接口同样连接到第二个交换机，而管理接口连接到第一个交换机。
这样，如果其中一个开关发生故障，操作员将能够通过公共或管理界面访问每个系统控制器以方便诊断。
在 Cisco 端，为 ODA 的 4 个绑定接口配置了 EtherChannel 组。这两个交换机分别连接到网络的其余部分，两者之间没有直接链接。
乍一看，这确实是一个合理的设计，但我对不同故障场景的思考越多，我似乎提出的问题就越多。
考虑到这些边缘型交换机本身并不是冗余的，集群可以处理一台交换机由于电源故障而变得不可用或一台交换机无法转发数据包似乎是相当重要的。
数据库客户端（在这种情况下为 zend 服务器应用程序服务器）每个都类似地通过绑定接口连接到两个交换机之一。这就引出了一些关于负载均衡的问题：按照我对11gR2 RAC的理解，简单的连接到SCAN地址，很可能会让客户端走很长一段路到主网再通过另一台交换机返回，这很难考虑要非常高效。
如果交换机发生故障或停止转发数据包会怎样？连接会通过 SCAN 找到可访问的 VIP 侦听器吗？RAC 是否会以某种方式检测到网络故障并将 SCAN 和 VIP 移动到具有工作且可访问的公共接口的系统控制器？老实说，我看不出它会如何。
虽然在故障转移场景中客户端通过核心网络并返回很长一段路是可以接受的，但在正常生产中避免它肯定会很好。
我确信甲骨文对这一切应该如何协同工作有一个非常清晰的想法，但恐怕我只是看不清楚。
边缘级/非冗余交换机是否可以实现完全冗余？我们能否以某种方式在生产和故障转移情况下对客户端连接的路由位置添加一些控制？也许有一种很好的方法可以将两台交换机互连，以允许一台交换机上的客户端和另一台交换机上的数据库侦听器之间直接进行通信？
在这一点上，我正在寻找应该应用于典型高可用性 ODA 实施的任何最佳实践和基本网络设计注意事项。
希望这将对任何面临为其 ODA 做出网络设计决策的 DBA 有用:)
更新：
ODA 在主动备份配置中配置了绑定。我认为这可能允许设置绑定上的每个接口都连接到不同的交换机，而无需任何交换机端配置。
任何人都知道是否是这种情况？
[root@oma1 ~]# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)
Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth2
事实证明，ODA 出厂时配置了主动备份债券。我已经对此进行了测试，无需任何交换机端 LACP/EtherChannel 配置即可正常工作，并且每个绑定连接都可以跨两个交换机拆分。在我的测试中，没有模拟故障或网络重新配置导致超过几百毫秒的网络中断。
这意味着可以使用任何本质上不是冗余的第二层交换机为 Web 应用程序设置一个隔离的冗余前端网络。
为避免客户端连接进入公司网络并通过另一台交换机返回（从而使生产依赖于该设备），可以拥有一个仅存在于两个边缘交换机和它们之间的 EtherChannel 中继上的专用 VLAN .
因此，该虚拟网段上仅存在应用程序服务器和数据库设备。
我看不到一种方法来控制从应用程序服务器到数据库侦听器的连接采用哪条路径，因此两个交换机之间的链接必须是冗余的，否则该链接会成为单点故障。这排除了使用不支持 VLAN 和 LACP 或 STP 的非托管交换机。
使用 Cisco Catalyst 2960 系列交换机，我相信 EtherChannel 和 Port Fast 的组合将是两者之间可靠独立连接的更好选择。我还将在端口上使用 Port Fast 来连接到 ODA 和应用程序服务器的所有绑定连接。
由于生产网络是隔离的，因此需要单独的网络连接来进行管理、备份和连接到公司网络的其余部分。
自然，为了让这个前端生产网络完全自给自足，还必须解决对外部资源（例如 DNS 或身份验证服务）的任何依赖关系。理想情况下，生产将能够独立继续，而无需考虑数据中心或公司网络中其他任何地方的任何故障、持续维护或网络中断。