<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h3 class="title">
      <a name="mysql-cluster-overview-requirements">
      </a>
      25.2.3 NDB Cluster Hardware, Software, and Networking Requirements
     </h3>
    </div>
   </div>
  </div>
  <a class="indexterm" name="idm46045124115008">
  </a>
  <a class="indexterm" name="idm46045124113520">
  </a>
  <p>
   One of the strengths of NDB Cluster is that it can be run on
      commodity hardware and has no unusual requirements in this regard,
      other than for large amounts of RAM, due to the fact that all live
      data storage is done in memory. (It is possible to reduce this
      requirement using Disk Data tables—see
   <a class="xref" href="mysql-cluster-disk-data.html" title="25.6.11 NDB Cluster Disk Data Tables">
    Section 25.6.11, “NDB Cluster Disk Data Tables”
   </a>
   , for more information
      about these.) You can obtain information about memory usage by
      data nodes by viewing the
   <a class="link" href="mysql-cluster-ndbinfo-memoryusage.html" title="25.6.17.46 The ndbinfo memoryusage Table">
    <code class="literal">
     ndbinfo.memoryusage
    </code>
   </a>
   table, or
      the output of the
   <a class="link" href="mysql-cluster-mgm-client-commands.html#ndbclient-report">
    <code class="literal">
     REPORT
      MemoryUsage
    </code>
   </a>
   command in the
   <a class="link" href="mysql-cluster-programs-ndb-mgm.html" title="25.5.5 ndb_mgm — The NDB Cluster Management Client">
    <span class="command">
     <strong>
      ndb_mgm
     </strong>
    </span>
   </a>
   client. For information about memory used by
   <code class="literal">
    NDB
   </code>
   tables, you can query the
   <a class="link" href="mysql-cluster-ndbinfo-memory-per-fragment.html" title="25.6.17.47 The ndbinfo memory_per_fragment Table">
    <code class="literal">
     ndbinfo.memory_per_fragment
    </code>
   </a>
   table.
  </p>
  <p>
   Increasing the number of CPUs, using faster CPUs, or both, on the
      computers hosting data nodes can generally be expected to enhance
      the performance of NDB Cluster. Memory requirements for cluster
      processes other than the data nodes are relatively small.
  </p>
  <p>
   The software requirements for NDB Cluster are also modest. Host
      operating systems do not require any unusual modules, services,
      applications, or configuration to support NDB Cluster. For
      supported operating systems, a standard installation should be
      sufficient. The MySQL software requirements are simple: all that
      is needed is a production release of NDB Cluster. It is not
      strictly necessary to compile MySQL yourself merely to be able to
      use NDB Cluster. We assume that you are using the binaries
      appropriate to your platform, available from the NDB Cluster
      software downloads page at
   <a class="ulink" href="https://dev.mysql.com/downloads/cluster/" target="_top">
    https://dev.mysql.com/downloads/cluster/
   </a>
   .
  </p>
  <p>
   For communication between nodes, NDB Cluster supports TCP/IP
      networking in any standard topology, and the minimum expected for
      each host is a standard 100 Mbps Ethernet card, plus a switch,
      hub, or router to provide network connectivity for the cluster as
      a whole. We strongly recommend that an NDB Cluster be run on its
      own subnet which is not shared with machines not forming part of
      the cluster for the following reasons:
  </p>
  <div class="itemizedlist">
   <ul class="itemizedlist" style="list-style-type: disc; ">
    <li class="listitem">
     <p>
      <b>
       Security.
      </b>
      Communications between NDB Cluster nodes are not encrypted
            or shielded in any way. The only means of protecting
            transmissions within an NDB Cluster is to run your NDB
            Cluster on a protected network. If you intend to use NDB
            Cluster for Web applications, the cluster should definitely
            reside behind your firewall and not in your network's
            De-Militarized Zone
            (
      <a class="ulink" href="http://compnetworking.about.com/cs/networksecurity/g/bldef_dmz.htm" target="_blank">
       DMZ
      </a>
      )
            or elsewhere.
     </p>
     <p>
      See
      <a class="xref" href="mysql-cluster-security-networking-issues.html" title="25.6.21.1 NDB Cluster Security and Networking Issues">
       Section 25.6.21.1, “NDB Cluster Security and Networking Issues”
      </a>
      ,
          for more information.
     </p>
    </li>
    <li class="listitem">
     <p>
      <b>
       Efficiency.
      </b>
      Setting up an NDB Cluster on a private or protected network
            enables the cluster to make exclusive use of bandwidth
            between cluster hosts. Using a separate switch for your NDB
            Cluster not only helps protect against unauthorized access
            to NDB Cluster data, it also ensures that NDB Cluster nodes
            are shielded from interference caused by transmissions
            between other computers on the network. For enhanced
            reliability, you can use dual switches and dual cards to
            remove the network as a single point of failure; many device
            drivers support failover for such communication links.
     </p>
    </li>
   </ul>
  </div>
  <p>
   <a name="mysql-cluster-network-latency-issues">
   </a>
   <b>
    Network communication and latency.
   </b>
   NDB Cluster requires communication between data nodes and API
        nodes (including SQL nodes), as well as between data nodes and
        other data nodes, to execute queries and updates. Communication
        latency between these processes can directly affect the observed
        performance and latency of user queries. In addition, to
        maintain consistency and service despite the silent failure of
        nodes, NDB Cluster uses heartbeating and timeout mechanisms
        which treat an extended loss of communication from a node as
        node failure. This can lead to reduced redundancy. Recall that,
        to maintain data consistency, an NDB Cluster shuts down when the
        last node in a node group fails. Thus, to avoid increasing the
        risk of a forced shutdown, breaks in communication between nodes
        should be avoided wherever possible.
  </p>
  <p>
   The failure of a data or API node results in the abort of all
      uncommitted transactions involving the failed node. Data node
      recovery requires synchronization of the failed node's data
      from a surviving data node, and re-establishment of disk-based
      redo and checkpoint logs, before the data node returns to service.
      This recovery can take some time, during which the Cluster
      operates with reduced redundancy.
  </p>
  <p>
   Heartbeating relies on timely generation of heartbeat signals by
      all nodes. This may not be possible if the node is overloaded, has
      insufficient machine CPU due to sharing with other programs, or is
      experiencing delays due to swapping. If heartbeat generation is
      sufficiently delayed, other nodes treat the node that is slow to
      respond as failed.
  </p>
  <p>
   This treatment of a slow node as a failed one may or may not be
      desirable in some circumstances, depending on the impact of the
      node's slowed operation on the rest of the cluster. When
      setting timeout values such as
   <a class="link" href="mysql-cluster-ndbd-definition.html#ndbparam-ndbd-heartbeatintervaldbdb">
    <code class="literal">
     HeartbeatIntervalDbDb
    </code>
   </a>
   and
   <a class="link" href="mysql-cluster-ndbd-definition.html#ndbparam-ndbd-heartbeatintervaldbapi">
    <code class="literal">
     HeartbeatIntervalDbApi
    </code>
   </a>
   for
      NDB Cluster, care must be taken care to achieve quick detection,
      failover, and return to service, while avoiding potentially
      expensive false positives.
  </p>
  <p>
   Where communication latencies between data nodes are expected to
      be higher than would be expected in a LAN environment (on the
      order of 100 µs), timeout parameters must be increased to
      ensure that any allowed periods of latency periods are well within
      configured timeouts. Increasing timeouts in this way has a
      corresponding effect on the worst-case time to detect failure and
      therefore time to service recovery.
  </p>
  <p>
   LAN environments can typically be configured with stable low
      latency, and such that they can provide redundancy with fast
      failover. Individual link failures can be recovered from with
      minimal and controlled latency visible at the TCP level (where NDB
      Cluster normally operates). WAN environments may offer a range of
      latencies, as well as redundancy with slower failover times.
      Individual link failures may require route changes to propagate
      before end-to-end connectivity is restored. At the TCP level this
      can appear as large latencies on individual channels. The
      worst-case observed TCP latency in these scenarios is related to
      the worst-case time for the IP layer to reroute around the
      failures.
  </p>
 </div>
 <br/>
</div>
