NDB 集群的一个优点是，它可以在通用硬件上运行，并且没有特殊的硬件需求，只需要大量的RAM，因为所有存活数据都存储在内存中。 (使用 Disk Data 表可以减少这个要求—见第25.6.11节，“NDB 集群 Disk Data 表”，了解这些表的更多信息。) 可以通过查看ndbinfo.memoryusage 表或REPORT MemoryUsage 命令在ndb_mgm 客户端中获取数据节点的内存使用信息。要了解NDB 表的内存使用，可以查询ndbinfo.memory_per_fragment 表。

增加数据节点所在计算机的 CPU 数量、使用更快的 CPU 或两者都可以预期提高 NDB 集群的性能。除了数据节点之外的集群进程的内存需求相对较小。

NDB 集群的软件要求也相对简单。主机操作系统不需要任何特殊模块、服务、应用程序或配置来支持 NDB 集群。对于支持的操作系统，标准安装应该足够。MySQL 软件要求也很简单：只需要生产版本的 NDB 集群即可。编译 MySQL 自己并不是必要的，只要使用适合平台的-binaries，从https://dev.mysql.com/downloads/cluster/下载页面获取。

为了实现节点之间的通信，NDB 集群支持标准 TCP/IP 网络拓扑结构，并且每个主机至少需要一个标准 100 Mbps Ethernet 卡，以及一个交换器、集线器或路由器来为整个集群提供网络连接。我们强烈建议将 NDB 集群运行在自己的子网中，而不是与非集群机器共享的 subnet，因为以下原因：

网络通信和延迟。 NDB 集群需要数据节点和 API 节点（包括 SQL 节点）之间，以及数据节点之间的通信，以执行查询和更新。这些进程之间的通信延迟可以直接影响用户查询的性能和延迟。此外，为了保持一致性和服务，即使某个节点Silent failure，NDB 集群使用心跳机制和超时机制将长时间的节点失去通信视为节点故障。这可能会导致减少冗余。请记住，在维护数据一致性时，NDB 集群在最后一个节点组中的所有节点失败时将关闭。因此，以避免增加强制关闭的风险，应该尽量避免节点之间的通信中断。

数据或 API 节点的故障将导致未提交事务的abort。数据节点恢复需要从存活的数据节点同步失败节点的数据，并重新建立磁盘基于redo和checkpoint日志，然后才能返回服务。这项恢复可能需要一些时间，在这个期间，集群将以减少冗余的方式运行。

心跳检测依赖于所有节点 timely 生成心跳信号。如果节点过载、机器 CPU 不足或出现交换延迟，可能无法生成心跳信号。 如果心跳生成被推迟，其他节点将视为响应缓慢的节点失败。

对一个响应缓慢的节点视为失败可能在某些情况下是可取的，但也可能不是。在设置超时值，如HeartbeatIntervalDbDb和HeartbeatIntervalDbApi时，需要小心地平衡快速检测、故障转移和恢复服务的需求，而避免可能昂贵的假阳性。

在数据节点之间通信延迟期望高于 LAN 环境（约 100 µs）时，超时参数必须增加，以确保允许的延迟期限都在配置的超时范围内。这样增加超时将对最坏情况下的故障检测时间和服务恢复时间产生相应影响。

局域网(LAN)环境通常可以配置为稳定的低延迟环境，并且能够提供快速故障转移。单个链路故障可以在 TCP 层面（NDB 集群通常操作的层面）中恢复，从而最小化和控制延迟。WAN 环境可能具有各种延迟，以及较慢的故障转移时间。单个链路故障可能需要路由更改以便将端到端连接恢复。在 TCP 层面，这可能会出现在单个通道上的大延迟。这些场景中最坏情况下的 TCP 延迟与 IP 层面的最坏情况重新路由时间相关。