21.1.3 NDB 群集的硬件，软件和网络要求

NDB Cluster 的优点之一是它可以在商用硬件上运行，并且在这方面没有特殊要求(除了需要大量 RAM 之外)，原因是所有实时数据存储都在内存中完成。 (可以使用“磁盘数据”table 来减少此需求，有关这些的更多信息，请参见第 21.5.10 节“ NDB 群集磁盘数据 table”。)自然，多个更快的 CPU 可以提高性能。其他 NDB 群集进程的内存需求相对较小。

NDB Cluster 的软件要求也不高。主机 os 不需要任何异常的模块，服务，应用程序或配置即可支持 NDB 群集。对于受支持的 os，标准安装应该足够了。 MySQL 软件的要求很简单：所需的只是 NDB Cluster 的生产版本。并非仅仅为了能够使用 NDB Cluster 就必须自己编译 MySQL。我们假设您正在使用适合您平台的二进制文件，可从https://dev.mysql.com/downloads/cluster/的 NDB Cluster 软件下载页面获得。

对于节点之间的通信，NDB Cluster 在任何标准拓扑中都支持 TCP/IP 网络，并且每个主机的最低要求是标准 100 Mbps 以太网卡，以及为整个群集提供网络连接的交换机，集线器或 Router。 。出于以下原因，我们强烈建议 NDB 群集在其自己的子网中运行，该子网不与不属于该群集一部分的计算机共享。

• 安全性. NDB 群集节点之间的通信不以任何方式加密或屏蔽。保护 NDB 群集中的传输的唯一方法是在受保护的网络上运行 NDB 群集。如果打算将 NDB 群集用于 Web 应用程序，则该群集一定应该位于防火墙之后，而不是位于网络的非军事区(DMZ)或其他地方。

有关更多信息，请参见第 21.5.17.1 节“ NDB 群集安全性和网络问题”。

• 效率. 在专用或受保护的网络上设置 NDB 群集使群集可以独占使用群集主机之间的带宽。为 NDB 群集使用单独的交换机不仅可以防止未经授权访问 NDB 群集数据，还可以确保 NDB 群集节点免受网络上其他计算机之间的传输所造成的干扰。为了提高可靠性，您可以使用双交换机和双卡来将网络作为单点故障移除；许多设备驱动程序都支持此类通信链接的故障转移。

网络通信和延迟. NDB 群集需要数据节点和 API 节点(包括 SQL 节点)之间以及数据节点和其他数据节点之间的通信，以执行查询和更新。这些进程之间的通信延迟会直接影响观察到的性能和用户查询的延迟。另外，为了在节点无提示故障的情况下保持一致性和服务，NDB Cluster 使用心跳和超时机制，将从节点扩展的通信丢失视为节点故障。这可能导致冗余减少。回想一下，为了保持数据一致性，当节点组中的最后一个节点发生故障时，NDB 群集将关闭。因此，为避免增加强制关闭的风险，应尽可能避免节点之间的通信中断。

数据或 API 节点的故障会导致涉及该故障节点的所有未提交的事务中止。数据节点恢复需要在数据节点恢复服务之前，同步来自尚存数据节点的故障节点的数据，并重新构建基于磁盘的重做和检查点日志。此恢复可能需要一些时间，在此期间群集将以减少的冗余度运行。

心跳 signal 依赖于所有节点及时生成心跳 signal。如果节点过载，由于与其他程序共享而导致机器 CPU 不足或由于交换而导致延迟，则可能无法实现。如果心跳生成已充分延迟，则其他节点会将响应较慢的节点视为失败。

在某些情况下，将慢速节点视为故障节点可能不理想，这取决于节点的慢速操作对集群其余部分的影响。为 NDB 群集设置超时值(例如HeartbeatIntervalDbDb和HeartbeatIntervalDbApi)时，必须小心以实现快速检测，故障转移和恢复服务，同时避免潜在的昂贵误报。

在数据节点之间的通信 await 时间预计将比 LAN 环境中期望的通信 await 时间高(大约 100 µs)的情况下，必须增加超时参数以确保任何允许的 await 时间段都在配置的超时范围内。以这种方式增加超时将对最坏情况下检测故障的时间和服务恢复时间产生相应的影响。

LAN 环境通常可以配置为具有稳定的低延迟，从而可以通过快速故障转移提供冗余。可以在 TCP 级别(NDB 群集正常运行的地方)以最小且受控制的延迟从单个链路故障中恢复。 WAN 环境可能会提供一定范围的延迟，以及具有较慢故障转移时间的冗余。在恢复端到端连接之前，个别链路故障可能需要传播路由更改。在 TCP 级别，这可能会在各个通道上显示为较大的延迟。在这些情况下观察到的最坏情况下的 TCP 延迟与 IP 层在故障周围重新路由的最坏情况时间有关。