NDB Cluster 的優勢之一是它可以在一般硬體上執行，並且在這方面沒有不尋常的需求，除了需要大量的 RAM，因為所有即時資料儲存都在記憶體中完成。（可以使用磁碟資料表來減少此需求—請參閱第 25.6.11 節「NDB Cluster 磁碟資料表」，以取得更多資訊。）您可以檢視ndbinfo.memoryusage 表格，或在 ndb_mgm 用戶端中使用 REPORT MemoryUsage 指令的輸出，來取得有關資料節點記憶體用量的資訊。有關 NDB 表格所使用的記憶體資訊，您可以查詢 ndbinfo.memory_per_fragment 表格。

增加託管資料節點的電腦上的 CPU 數量、使用更快的 CPU 或兩者都使用，通常可以預期會提高 NDB Cluster 的效能。除了資料節點之外，叢集程序對記憶體的需求相對較小。

NDB Cluster 的軟體需求也很適中。主機作業系統不需要任何不尋常的模組、服務、應用程式或組態來支援 NDB Cluster。對於支援的作業系統，標準安裝應該就足夠了。MySQL 軟體需求很簡單：只需要 NDB Cluster 的正式發行版本。嚴格來說，您不需要自己編譯 MySQL 才能夠使用 NDB Cluster。我們假設您使用的是適合您平台的二進位檔案，可以從 NDB Cluster 軟體下載頁面取得：https://mysqldev.dev.org.tw/downloads/cluster/。

對於節點之間的通訊，NDB Cluster 支援任何標準拓撲中的 TCP/IP 網路，並且每個主機的最低預期是標準的 100 Mbps 乙太網路卡，加上交換器、集線器或路由器，以提供整個叢集的網路連線能力。我們強烈建議 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 層繞過故障重新路由的最差情況時間相關。