Configuration > Name Servers

The Name Servers page allows you to manage machines acting as File System name servers. You may specify either a hostname or an IP addresses, but an IP address is preferable because it avoids problems associated with the lookup system (e.g., DNS or NIS).

Note: On Linux systems the NetworkManager service should be turned off because it can interfere with the StorNext nameserver and Linux network devices.

The hostnames or IP addresses are copied into the StorNext fsnameservers file. This specifies both the machines serving as File System Name Server coordinator(s) and defines the metadata network(s) used to reach them. The File System Name Server coordinator is a critical component of the StorNext File System Services (FSS).

Note: The fsnameservers file must be the same for all StorNext clients.

A principal function of the coordinator is to manage failover voting in a high-availability configuration. Therefore, it is critical to select highly reliable systems as coordinators. Redundancy is provided by listing the IP addresses of multiple machines in the fsnameservers file, one entry per line. The first IP address listed defines the path to the primary coordinator. A redundant path to this coordinator may then be specified. Any subsequent IP addresses listed serve as paths to backup coordinators. To create redundancy, Quantum recommends that you select two machines to act as coordinators. Typically, the selected systems are also configured for FSM services (), but this is not a requirement.

If the fsnameservers file does not exist, is empty or contains the localhost IP address (127.0.0.1), the file system operates as a local file system requiring both a client and a server. The file system will not communicate with any other StorNext File System product on the network, thus eliminating sharing the FSS over the SAN.

The addresses in the fsnameservers file define the metadata networks and therefore the addresses used to access file system services. When an sends a heartbeat to a nameserver, the nameserver records the source IP address from the UDP packet and uses that as the address to advertise for FSMs local to that.

If a nameserver receives multiple heartbeats on redundant metadata network interfaces, there will be a different source address for the same FSM and host. The name server will select only one of the metadata network addresses to use as the address of the FSM advertised to all hosts in the cluster. Thus all metadata traffic will use only one of the redundant metadata networks.

If the network being advertised for file system services fails, a backup network will be selected for FSM services. Clients will not necessarily reconnect using the new address. If a client maintains TCP connectivity using the old address, no reconnect will be necessary. If the client needs to connect or re-connect, it will use the currently advertised IP address of the file system services.

When you access this page by choosing Name Servers from the Configuration menu, a list of any previously entered IP addresses appears. A green check mark icon under the Enabled column heading indicates that the server is currently enabled as a name server. A red X icon indicates that the server is not currently enabled.

StorNext allows you to specify the order in which name servers are used.

  • Select a name server and then click Move Up or Move Down until the selected server is in the correct order.
  1. Enter the IP address in the field to the left of the Add button.
  2. Click Add.
  3. When the confirmation message appears, click Yes to proceed or No to abort.
  4. When the new name server appears in the list of available name servers, you can reposition the new name server by using the Move Up or Move Down buttons.

Caution: Changing the name server file affects all servers and clients on your SAN. All servers and clients MUST have the same name server file in order to ensure correct SAN operation. After the name server file has been updated on the server, the SAN administrator must copy the name server file to ALL connected clients and then restart StorNext File System services on those clients.

Note: Although not required, you might want to disable the name server before deleting it to prevent complications.

  • Select the name server you want to delete and then click Delete.

The StorNext name service supports the concept of a foreign server. StorNext client nodes can mount file systems that are not local to the client's home cluster. Additionally, a client may belong to no StorNext cluster by having an empty or non-existent fsnameservers file.

Clusters serving foreign clients address some scalability and topology issues present in the traditional client model. Depending on your needs, traditional clients, foreign clients or a mixture may result in the best performance and functionality.

Configuring foreign servers requires creating the fsforeignservers file on client nodes, which is created in the cvfs config directory. (Configuring foreign servers through the StorNext GUI is not currently supported.) The fsforeignservers file must be edited using a program appropriate for the platform, such as vi on Linux or Wordpad on Windows.

Configuring foreign servers allows customers to better scale large numbers of clients. Since foreign clients do not participate in FSM elections, a lot of complexity and message exchange in the voting process is eliminated. In a typical StorNext HA environment, clients have equal access to both candidates, making the choice of active FSM more of a load balancing decision rather than one of access.

Another benefit of foreign servers is that certain topology environments prevent all clients from having equal access to all file system s and associated primary storage. By selecting the set of file system services for each client through the foreign servers configuration, the client sees only the relevant set of file systems.

The format for the fsforeignservers file is similar to the fsnameservers file in that it contains a list of IP addresses or hostnames, preferably IP addresses. One difference is that the addresses in the fsforeignservers file are MDC addresses, addresses of hosts that are running the FSM services. This is in contrast to the fsnameservers file, where the name server coordinators specified may or may not also be acting as MDCs.

In the case that HA is present, you would specify both the active and the standby MDCs that are hosting FSMs for the file system in the fsforeignservers file.

No additional configuration is needed on the MDCs which act as foreign servers. Foreign clients send heartbeat messages to the addresses in the fsforeignservers file. The heartbeat rate is once every 5 seconds. The nodes reply to these heartbeat with a list of local, active FSMs and the address by which they may be reached.

After the fsforeignservers file has been created, services can be restarted and the file systems available through this service may be mounted. All the usual requirements of a file system client apply. The client must have access to the primary storage disks or use the LAN client mount option.

Note: For the HA setup, the ha_vip address can be entered in the fsforeignservers file.