TCP/IP Networking

The Controller Node

Where a Server Group has two or more DataCore Servers in it, one of them will be designated as the controller node for the whole group.

The controller node is responsible for managing what is displayed in the SANsymphony Console for all DataCore Servers in the Server Group – for example, receiving status updates for the different objects in the configuration for those other DataCore Servers (e.g. Disk Pools, Virtual Disks, and Ports, etc.), including the posting of any Event messages for those same objects within the SANsymphony console.

The controller node is also responsible for the management and propagation of any configuration changes made in the SANsymphony Console regardless of which DataCore Server’s configuration is being modified and makes sure that all other DataCore Servers in the Server Group always have the most recent and up-to-date changes.

The ‘election’ of which DataCore Server is to become the controller node is decided by the SANsymphony software automatically and whenever

• A DataCore Server is removed from or added to the existing Server Group
• The existing controller node is shutdown
• The existing controller node becomes ‘unreachable’ via the TCP/IP network to the rest of the Server Group (e.g., an IP Network outage, or a clock change sufficient to require a reconnection of the WCF connection between nodes).

The decision on which DataCore Server becomes the controller node is decided automatically between all the Servers in the Group and cannot be manually configured.

It is also important to understand that the controller node does not manage any Host, Mirror, or Back-end I/O (i.e., in-band connections) for otherDataCore Servers in the Server Group. In- band I/O is handled by each DataCore Server independently of the other Servers in the Server Group, whether it is the elected controller or not. Nor does it send or receive Replication data configured for another DataCore Server in the same Server Group, although it will manage all Replication configuration changes and Replication status updates whether it is the Source Replication Server or not.

The Connection Interface Setting

Except for iSCSI I/O, all other TCP/IP traffic sent and received by a DataCore Server is managed by the SANsymphonyConnection Interface setting.

This includes:

• When applying SANsymphony configuration updates to all servers in the same Server Group.
• Any UI updates while viewing the SANsymphony Console, including state changes and updates for all the different objects within the configuration (e.g., Disk Pools, Virtual Disks, Snapshots and Ports, etc.).
• Configuration updates and state information to and from remote Replication Groups.
• Configuration updates when using SANsymphony’s VMware vCenter Integration component.
• SQL updates when using a remote SQL server for Performance Recording.

The Connection Interface’s default setting (‘All’) means that SANsymphony will use any available network interface on the DataCore Server for its host name resolution, this is determined by the Windows operating system and how it has been configured and connected to the existing network.

It is possible to change this setting and choose an explicit network interface (i.e., IP Address) to use for hostname resolution instead, but this requires that the appropriate network connections and routing tables have been set up correctly and are in place. SANsymphony will not automatically retry other network connections if it cannot resolve to a hostname using an explicit interface.

We recommend leaving the setting to ‘All’ and using the appropriate ‘Hosts’ file or DNS settings to control hostname resolution.

In case this is set to a specific IP Address and this address disappears from the system, then no configuration changes are possible (including a change to the address setting) unless this address re-appears!

On the DataCore Server

Even if the SANsymphony Management Console is used to log into one of the other DataCore Servers in the group (i.e. an ‘unelected node’) that other server will still connect directly to the controller node to make configuration changes or to display the information in its own SANsymphony Console.

This means that all DataCore Servers in the same Server Group must have a routable TCP/IP connection to each other and a working mutual name resolution so that if the controller node ‘moves’ to a different server, then the new controller node must also be able connect to all the remaining DataCore Servers in the group 1 ‘Re-election’ of the controller node takes place if the node is shutdown or if it becomes unavailable on the network to the rest of the Server Group for any reason..

On a Workstation

Workstations that only have the SANsymphony Console component installed cannot become ‘controller nodes’ and never directly send or receive configuration information for any Server Group they connect to. Just like an ‘unelected’ node, the workstation will connect to the controller node to make configuration changes or to display the information in its own SANsymphony Console (See Understanding the Controller Node Concept).

This means that even if the workstation is on a separate network segment from the DataCore Servers (e.g., in a different vLAN) it must still be able to send and receive TCP/IP traffic to and from all the DataCore Servers in that vLAN and mutual name resolution must be in place.

While it is technically possible to share ISCSI I/O, Replication data, and the SANsymphony Console’s inter-node traffic over the same TCP/IP connection, for performance as well as losing more than one of these functions at once, we recommend using dedicated and separate network interfaces for each iSCSI port.

The DataCore Server 'Management' Connection

For all TCP/IP traffic where Multipath I/O protocols are not being used (i.e., non-iSCSI traffic), we recommend using NIC teaming to provide redundant network paths to other DataCore Servers.

We also recommend that each NIC that is teamed is in its separate network and that ‘failover’ mode is used rather than ‘load balancing’ as there is no specific performance requirement for Inter-node communication as the TCP/IP and using ‘fail over’ mode means that configuring and managing the network connections and switches is simpler. It also makes troubleshooting any future connection problems easier as well.

iSCSI Connections

See Fibre Channel and iSCSI Connections.

Replication

See Replication.

There is no preference for managing DataCore Server hostname resolution between using the local ‘Hosts’ file or DNS. Either method can be used, however, any unavailability of DNS will affect the ability of the SANsymphony nodes to communicate as well as connect remote management consoles.

DataCore does recommend however using Host Name resolution over just using IP addresses as it is easier to manage any IP address changes that might occur, planned or unexpected, by being able to simply update any ‘Hosts’ file or DNS entries instead of ‘reconfiguring’ a Replication group or remote SQL server connection for Performance Recording (i.e. manually disconnecting and reconnecting), which is disruptive.

When using a ‘Hosts’ file, do not add any entries for the local DataCore Server but only for the ‘remote’ DataCore Servers, and do not add multiple, different entries for the same server (e.g. each entry has a different IP address and/or server name for the same server) as this will cause problems when trying to (re)establish network connections. "The server name entered into the 'Hosts' file should match the "Computer name" for the node in the DataCore Management Console.

Firewalls and Network Security

The SANsymphony software installer will automatically reconfigure the DataCore Server’s Windows firewall settings to allow it to be able to communicate with other DataCore Servers in the same Server or Replication groups. No additional action should be required.

If using an ‘external’ firewall solution or another method to secure the IP networks between servers then refer to the ‘Windows Security Settings Disclosure’ for the full list of TCP Ports required by the DataCore Server and ensure that connections are allowed through.

Also see:

Windows Security Settings Disclosure

iSCSI Connections

See iSCSI connections for more information on iSCSI.

Other Required TCP/IP Connections

• Leave the DataCore Server’s Connection Interface setting as default (‘All’).
• Use either ‘Hosts’ or DNS settings to control all hostname resolutions for the DataCore Server.
• Use a managed ‘Hosts’ file (or DNS) instead of just using IP addresses.
• Any Windows updates and security fixes that are currently available from Microsoft’s Windows Update Service should be applied whenever possible.
• For Firewalls and other network security requirements please refer to ‘Windows Security Settings Disclosure’.

TCP/IP Network Topology

• Ensure DataCore Servers in the same Server Group always have routable TCP/IP connections to each other.
• Ensure Workstations that are only using the SANsymphony Console always has a routable TCP/IP connection to all DataCore Servers in the Server Group.
• Ensure mutual name resolution works for DataCore Servers and management Workstations.
• If using SANsymphony’s VMware vCenter Integration component, ensure the server running the vCenter always has a routable TCP/IP connection to all DataCore Servers in the Server Group.
• Do not route ‘non-iSCSI’ TCP/IP traffic over iSCSI connections.

• Use dedicated and separate TCP/IP connections for each of the following:

  • The SANsymphony Console
  • Replication transfer
  • Performance Recording when connecting to a remote SQL server
• Use NIC teaming, in ‘failover’ mode, for inter-node connection redundancy for ‘non-ISCSI’ TCP/IP traffic with separate networks for each NIC.
• Use independent network switches for redundant TCP/IP networks used for inter-node communication between DataCore Servers.