NDB Cluster 的优势之一是它可以在商品硬件上运行，并且在这方面没有特殊要求，除了大量 RAM，因为所有实时数据存储都是在内存中完成的。（可以使用磁盘数据表来减少此要求——有关这些的更多信息，请参阅 第 23.6.10 节，“NDB 集群磁盘数据表”。）自然地，多个更快的 CPU 可以提高性能。其他 NDB Cluster 进程的内存需求相对较小。
NDB Cluster 的软件要求也很适中。主机操作系统不需要任何不寻常的模块、服务、应用程序或配置来支持 NDB Cluster。对于受支持的操作系统，标准安装应该就足够了。MySQL 软件要求很简单：所需要的只是 NDB Cluster 的生产版本。仅仅为了能够使用 NDB Cluster 自己编译 MySQL 并不是绝对必要的。我们假设您正在使用适合您平台的二进制文件，可从 NDB Cluster 软件下载页面获得， 网址为https://mysql.net.cn/downloads/cluster/。
对于节点之间的通信，NDB Cluster 支持任何标准拓扑中的 TCP/IP 网络，每台主机的最低要求是标准的 100 Mbps 以太网卡，加上交换机、集线器或路由器，为整个集群提供网络连接. 我们强烈建议 NDB Cluster 在其自己的子网上运行，该子网不与不属于集群的机器共享，原因如下：
安全。 NDB Cluster 节点之间的通信没有以任何方式加密或屏蔽。保护 NDB Cluster 内传输的唯一方法是在受保护的网络上运行 NDB Cluster。如果您打算将 NDB Cluster 用于 Web 应用程序，则该集群绝对应该驻留在您的防火墙后面，而不是在您网络的非军事区（DMZ）或其他地方。
有关更多信息，请参阅 第 23.6.19.1 节，“NDB 集群安全和网络问题”。
效率。 在私有或受保护网络上设置 NDB Cluster 使集群能够独占使用集群主机之间的带宽。为 NDB Cluster 使用单独的交换机不仅有助于防止未经授权访问 NDB Cluster 数据，还可以确保 NDB Cluster 节点免受网络上其他计算机之间传输造成的干扰。为了增强可靠性，可以使用双交换机和双卡来消除网络的单点故障；许多设备驱动程序支持此类通信链路的故障转移。
网络通信和延迟。 NDB Cluster 需要数据节点和 API 节点（包括 SQL 节点）之间以及数据节点和其他数据节点之间的通信，以执行查询和更新。这些进程之间的通信延迟会直接影响观察到的性能和用户查询的延迟。此外，为了在节点无提示故障的情况下保持一致性和服务，NDB Cluster 使用心跳和超时机制，将来自节点的通信的扩展丢失视为节点故障。这可以导致减少冗余。回想一下，为了保持数据一致性，NDB Cluster 在节点组中的最后一个节点出现故障时关闭。因此，为避免增加强制关机的风险，
数据或 API 节点的故障会导致涉及故障节点的所有未提交事务的中止。数据节点恢复需要在数据节点恢复服务之前，从幸存的数据节点同步故障节点的数据，并重新建立基于磁盘的重做和检查点日志。此恢复可能需要一些时间，在此期间集群以减少的冗余运行。
心跳依赖于所有节点及时产生心跳信号。如果节点过载，由于与其他程序共享而机器 CPU 不足，或者由于交换而遇到延迟，这可能是不可能的。如果心跳生成被充分延迟，则其他节点将响应缓慢的节点视为失败。
在某些情况下，将慢速节点视为故障节点可能是可取的，也可能不是，这取决于节点运行缓慢对集群其余部分的影响。在为 NDB Cluster 设置超时值时
HeartbeatIntervalDbDb，
HeartbeatIntervalDbApi必须注意实现快速检测、故障转移和返回服务，同时避免潜在的代价高昂的误报。
如果数据节点之间的通信延迟预期高于 LAN 环境中的预期延迟（大约 100 µs），则必须增加超时参数以确保任何允许的延迟周期都在配置的超时范围内。以这种方式增加超时会对检测故障的最坏情况时间产生相应影响，从而影响服务恢复时间。
LAN 环境通常可以配置为具有稳定的低延迟，这样它们就可以提供具有快速故障转移的冗余。单个链路故障可以在 TCP 级别（NDB Cluster 通常运行的地方）可见的最小和受控延迟中恢复。WAN 环境可能会提供一系列延迟，以及具有较慢故障转移时间的冗余。个别链路故障可能需要在端到端连接恢复之前传播路由更改。在 TCP 级别，这可能表现为单个通道上的大延迟。在这些场景中观察到的最坏情况下的 TCP 延迟与 IP 层重新路由故障的最坏情况时间有关。