标签: oracle-database-appliance

随着 Oracle 工程系统的引入，DBA 在某种程度上更接近于基础设施设计决策，并且期望至少对数据库的网络设计要求有一些意见。至少这是我发现自己的情况:)

部署 ODA 进行测试后，我发现自己采用了当前设置：

系统控制器 0 具有连接到典型边缘交换机 Catalyst 2960 系列的公共绑定接口 (bond0)。管理接口 (bond1) 连接到相同类型的第二个边缘交换机。

类似地，系统控制器 1 的公共接口连接到第二个交换机，而管理接口连接到第一个交换机。

这样，如果其中一个开关出现故障，操作员将能够通过公共界面或管理界面到达每个系统控制器以促进诊断。

在 Cisco 端，为 ODA 的 4 个绑定接口配置了 EtherChannel 组。这两个交换机单独连接到网络的其余部分，两者之间没有直接链接。

乍一看，这确实是一个合理的设计，但我对不同故障场景的思考越多，我似乎提出的问题就越多。

考虑到这些边缘型交换机本身并不是冗余的，集群能够处理由于电源故障导致的一台交换机不可用，或者一台交换机无法转发数据包似乎是相当重要的。

数据库客户端（在本例中为 Zend 服务器应用程序服务器）每个都类似地通过绑定接口连接到两个交换机中的一个。这就带来了一些关于负载均衡的问题：我对11gR2 RAC的理解，简单的连接到SCAN地址，很可能让客户端走很长一段路到主网，然后通过另一个交换机回来，这几乎不能考虑要非常有效率。

如果交换机出现故障或停止转发数据包，会发生什么情况？连接会通过 SCAN 找到可访问的 VIP 侦听器吗？RAC 是否会以某种方式检测网络故障并将 SCAN 和 VIP 移动到具有工作且可访问的公共接口的系统控制器？老实说，我看不出它会如何。

虽然客户端在故障转移场景中通过核心网络并返回很长一段路是可以接受的，但在正常生产中避免它肯定会很好。

我确信 Oracle 对这一切应该如何协同工作有一个非常清晰的认识，但恐怕我并没有那么清楚地看到这一切。

边缘级/非冗余交换机是否可以实现完全冗余？我们能否以某种方式对客户端连接在生产和故障转移情况下的路由位置添加一些控制？也许有一种很好的方法可以将两台交换机互连，以允许一台交换机上的客户端和另一台上的数据库侦听器之间直接进行通信？

在这一点上，我正在寻找应应用于典型高可用性 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: …

昨晚，我们其中一个 Oracle 数据库机上的恢复区已满。这是在其中一个数据库警报日志中报告的，我们能够在下一次日志切换之前清除一些空间，此时生产将停止。

多一点警告当然会很好，比如当磁盘组已满 70% 时。

我们有哪些选项可以监控 ASM 内的磁盘使用情况？

在Oracle Database Appliance，默认部署只给你一个control file.

我觉得这有点令人费解。单个控制文件会导致自动配置的企业管理器 DB 控制台中的策略违规，而 Oracle 的建议仍然是，据我所知，您应该始终在不同的驱动器和文件系统上至少拥有两个控制文件。就个人而言，为了保险起见，我一直都有三份副本。

ODA 使用 ASM 进行配置，并且使用三重镜像驱动器确实具有良好的存储冗余。在此配置中使用单个控制文件运行是否可以？

将第二个控制文件添加到同一个磁盘组可能没有多大意义，将控制文件多路复用到 SSD 磁盘组或每个节点的操作系统驱动器是否更有意义？