This section describes how to set up the network services for your a storage cluster.
Info |
---|
Platform ServerIf you useSkip this section if using Platform Server , skip this section: yournetwork services are set up. |
Table of Contents |
---|
Setting up NTP for time synchronization
The Network Time Protocol (NTP) server provides time synchronization between the cluster nodes, which is critical for many Swarm components. For best results, configure multiple NTP servers in close proximity to your a cluster. For example, you can use the NTP Pool Project's continental zones, which are pools of NTP servers.
One or more trusted NTP servers, such as dedicated hardware solutions on your the internal network or publicly available NTP servers, are required in your a storage cluster. This configuration is required, ensuring that the internal clocks in all nodes are synchronized with each other.
If Add trusted NTP servers are available, you can add these servers to your to the cluster by adding their the IP addresses or host names in the network.timeSource
parameter located in the node configuration files if available. The parameter value is a list of one or more NTP servers (either host names or IP addresses) separated by spaces. For example, to add a second NTP server IP address, use the following syntax:
...
Code Block | ||
---|---|---|
| ||
network.timeSource = ntp1.example.com ntp2.example.com |
See Configuring an External Time Server.
Info | |
---|---|
title | NTP 3.0NTP 3.0 included a design limitation that causescausing the time value to wrap in the year 2036. IfNTP cannot correct the time if the BIOS clock in a cluster node is set beyond this wrap point , NTP cannot correct the time. Before you bootbooting Swarm in youra cluster, ensure thatthe BIOS clocks in all nodes are set to a year prior to 2036. This issue was resolved in NTP 4.0. |
If The node does not boot if the configured NTP server(s) cannot be reached, the node will not boot. If . See Configuring a Node without NTP if the cluster nodes cannot access an external or internal NTP server, see Configuring a Node without NTP.
Setting up DHCP for IP address administration
The Dynamic Host Configuration Protocol (DHCP) server provides IP addresses to the cluster nodes and other devices that are enabled as DHCP clients. While Swarm nodes are not required to have static IP addresses to discover and communicate with each other, administrators might find it easier to manage and monitor a cluster where each node receives a predetermined IP address.
To configure this option using DHCP:
Map the Ethernet media access control (MAC) address of each node to a static IP address.
Configure
yourthe DHCP server to provide each node with an IP address for each of these:
network mask
default gateway
DNS server
Setting up DNS for name resolution
The Domain Name Service (DNS) is used to resolve host names into IP addresses. While DNS is not required for Swarm nodes to communicate with each other, DNS can be very useful for client applications to reach the cluster. If you use named objects, DNS is one method you can to use to enable access to objects over the Internet if using named objects.
Info | |
---|---|
title | Best practiceAlthough client applications can initiate first contact with any node in the storage cluster – even choosing to access the same node every time – best practice is for the node of first contact to be distributed evenly around the cluster. |
For example, you can:
Define multiple DNS entries ("A" or "CNAME" records) that specify the IP address for the same Swarm first contact node.
Use multiple IP addresses for a DNS entry to create a DNS round-robin that provides client request balancing.
See your the DNS software documentation for how to use "A" records and "CNAME" (alias) records.
Swarm requires a DNS server to resolve host names in the configuration file. For example, you can add a host name to the NTP list or the log host (such as ntp.pool.org) for name resolution. The DNS server needs to be set in the Swarm configuration file. In contrast, applications must resolve Swarm domain names to find the storage cluster. These unique requirements will are most likely be addressed using different DNS servers.
...
In this example, the Time To Live (TTL) value for each of the records in the round-robin group is very small (0-2 seconds). This configuration is necessary so that clients who cache the resolution results will quickly flush them. This process allows the first contact node to be distributed and allows a client to move quickly to another node if the first contact node is unavailable.
Info | |
---|---|
title | Best practiceApplications should implement robust mechanisms such as Zero Configuration Networking for distributing the node of first contact and skipping failed nodes, but an administrator can use DNS to assist with simpler applications. |
Preparing for domains
To allow clients to access named objects over the Internet, enable incoming HTTP requests to resolve to the correct domain. (A cluster can contain many domains, each of which can contain many buckets, each of which can contain many named objects.) Cluster and domain names should both be Internet Assigned Numbers Authority (IANA) compatible host names, such as cluster.example.com.
...
In this example, cluster.example.com
is the domain name, marketing is the name of a bucket, and photos/ads/object-naming.3gp
is the name of an object. Set up your the network so the host name in the HTTP request maps correctly to the object's domain name. The cluster name is not required.
To enable clients to access a named object:
Set up
your hosts filehost files to map domain names to IP address(es) of the first contact node.
For a Linux system, configure the /etc/hosts file.
For a Windows system, configure the %SystemRoot%\system32\drivers\etc\hosts file.
Example of a configured hosts file:Code Block language text 192.168.1.111 cluster.example.com 192.168.1.112 vault.example.com
Define multiple DNS entries ("A" or "CNAME" records) that identify the IP address(es) of the first contact node in the storage cluster. This process creates a DNS round-robin that provides client request load balancing.
For help setting up DNS for Swarm, see Setting up DNS for name resolution, above.
For information about setting up
youra DNS server, see
yourthe DNS software documentation.
Setting up a Syslog Server for Critical Alerts
You A syslog server must be set up a syslog server to capture critical operational alerts from the nodes in a storage cluster. The server captures messages sent by the Swarm nodes on UDP port 514.
...
Swarm provides monitoring information and administrative controls using the Simple Network Management Protocol (SNMP). Using an SNMP console, an administrator can monitor a storage cluster from a central location.
Info |
---|
Disabling SNMPIf you need to disable SNMP Disable the Swarm Storage setting |
Swarm uses an SNMP management information base (MIB) definition file to map SNMP object identifiers (OIDs) to logical names. The MIB can be located in one of two locations, depending on your the configuration:
- If your cluster nodes boot from a Platform Server, the
The aggregate MIB for the entire cluster is located at /usr/share/snmp/mibs
.If yourif cluster nodes
do notboot from a Platform Server
, the.
The MIB is located in the root directory of
yourthe Swarm software distribution if cluster nodes do not boot from a Platform Server.
Setting up network load balancing
...
During normal operations, a storage node routinely redirects a client to another node within the cluster. When this process occurs, the client must initiate another HTTP request to the redirected node. Any process that virtualizes the storage node IP addresses or attempts to control the nodes connected to the client will generate generates communication errors.
Setting up the network interfaces
Gigabit Ethernet or faster NICs provide the recommended 1000 Mbps data communications speed between your storage cluster nodes. Swarm automatically uses multiple NICs to provide a redundant network connection.
To implement this feature, connect the NICs to one or more interconnected switches in the same subnet.
See Switching Hardware.