The following sample configuration shows how IP addresses could be assigned in a typical 2-node MOVEit DMZ deployment. There are three networks in use here: the Internet, an "Application" network and a "Cluster/Backbone" network.
The following information is provided to help experienced network technicians quickly set up configurations on their load balancer equipment to support MOVEit DMZ Resiliency. If you need additional help beyond this document or that provided by your load balancer vendor, Ipswitch may be available to help you set up your load balancing equipment as a consultant. (The standard onsite resiliency installation package already assumes some time will be spent configuring load balancing.)
Please remember that any load balancer must be set to allow established TCP connections to continue to exchange traffic with the same physical MOVEit DMZ node once a connection has been established. (This feature is often called "sticky connection".) If FTP/SSL will be used, the load balancer must also be configured to allow all subsequent connections from the same IP address (within a reasonable timeframe) to also connect to the same physical MOVEit DMZ node because FTP/SSL uses separate data channels which must be paired up their respective control channels. (This feature is often called "sticky IP".)
Windows 2003 and 2008 ship with a handy set of network load balancing services. These services can be used in place of a separate network hardware device to spread a distributed application load across multiple MOVEit DMZ Resilient nodes.
The following example describes two MOVEit DMZ nodes. The following assumptions are made about similar configurations:
Installation and Overview
Be sure to install the Microsoft Network Load Balancing Services BEFORE you install MOVEit DMZ. It may take some time for the Network Load Balancing (NLB) services to configure the adapters so a degree of patience is necessary when carrying out this task.
Instructions for configuring NLB on Windows Server 2003Once you have installed and configured NLB:
It is possible to configure NLBS to run a "failover only" mode using the proper combination of "Host Priority" and "Single Host".
As defined by Microsoft documentation...
"Host Priorities:
Each cluster host is assigned a unique host priority in the range of 1 to 32,
where lower numbers denote higher priorities.
The host with the highest host priority (lowest numeric value) is called the default host.
It handles all client traffic for the virtual IP addresses that is not specifically
intended to be load-balanced.
This ensures that server applications not configured for load balancing
only receive client traffic on a single host.
If the default host fails, the host with the next highest priority takes over as default host.
Also, as defined by Microsoft documentation...
"Multiple Hosts:
This parameter specifies that multiple hosts in the cluster handle network traffic for the associated port rule. This filtering mode provides scaled performance in addition to fault tolerance by distributing the network load among multiple hosts. You can specify that the load be equally distributed among the hosts or that each host handle a specified load weight.
Single Host:
This parameter specifies that network traffic for the associated port rule be handled by a single host in the cluster according to the specified handling priority. This filtering mode provides port specific fault tolerance for the handling of network traffic."
To convince NLBS to run in a pure failover mode, set the primary node with a priority of one, the secondary node with a priority of two and configure the service to function in "Single Host" mode.
In Multicast mode, Windows Load Balancing services use just one NIC per node to handle regular traffic and Windows Load Balancing messages. In Unicast mode, separate NICs are used to carry these two types of traffic. The most important configuration difference in terms of MOVEit DMZ is that sites that use Unicast Mode rather than MultiCast mode will need 3 NICs, not 2, to support a recommended network configuration.
Generally Unicast mode is not necessary unless a particular network switch is unable to handle Multicast mode load balancing. (The symptoms of this problem typically involve extremely poor network performance.)
The "IGMP multicast" checkbox available in this configuration should be set if you are working with a managed switch that has implemented "IGMP snooping" to prevent switch flooding. Obviously, it will only be available if "Multicast" mode load balancing (as opposed to "Unicast" mode) has been selected.
Ipswitch recommends using "Layer 3 Sticky" mode with Cisco CSS LBs.
Layer 3 rules will match any incoming connection for the virtual IP address as opposed to a layer 4 rule, which will only match on a particular port. The end result should be that if a particular client has established a ftps control connection with MOVEit DMZ on port 21 or 990, then any incoming ftps passive data connections will go to the same server as the control connection. This configuration is required to ensure that incoming FTP data connections get paired up with FTP control connections correctly.
Stickiness ensures that multiple TCP connections from the same remote IP address are always directed to one box or the other. Stickiness goes away if no new connections have been opened for several minutes. This configuration is required to ensure sessions are properly continued during normal operation.
For more information about the "sticky" feature and how to configure the sticky option on a Cisco CSS LB, try:
A sample content rule follows.
content rule MOVEitDMZ vip address <vip> add service dmzserver1 add service dmzserver2 advanced-balance sticky-srcip active
In addition, each MOVEit DMZ server will need to have the FTP NAT configured to send the <vip> in response to the PASV command. That way incoming data connections will go to the <vip>. This is configured on each MOVEit DMZ server by running Start --> Programs --> MOVEit DMZ --> MOVEit DMZ Config, clicking on the FTP IP's tab, and adding a rule like:
Server: *.*.*.* NAT: <vip> Client: *.*.*.*
A sample configuration from a live CSS used with MOVEit DMZ Resiliency is listed below.
!************************** SERVICE **************************
service Moveit1
ip address 10.252.0.35
redundant-index 2
keepalive type script ap-kal-tcp-ports "10.252.0.35 21 22 443"
active
service Moveit2
ip address 10.252.0.36
redundant-index 3
keepalive type script ap-kal-tcp-ports "10.252.0.36 21 22 443"
active
service upstream_downstream
keepalive frequency 2
keepalive maxfailure 2
keepalive retryperiod 2
keepalive type script ap-kal-pinglist "10.252.0.1"
ip address 10.252.0.1
active
!*************************** OWNER ***************************
owner Moveit
content MoveitVIP1-ftp
add service Moveit1
primarySorryServer Moveit2
redundant-index 1
balance leastconn
vip address 10.252.0.101
advanced-balance sticky-srcip
sticky-inact-timeout 30
active
!*************************** GROUP ***************************
group MoveitVIP1
vip address 10.252.0.101
add destination service Moveit1
add destination service Moveit2
redundant-index 1
active
The "ap-kal-tcp-ports" script referenced by this configuration is listed below.
!no echo
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! Filename: ap-kal-tcp-ports
! Parameters: Service Address, TCP Port(s)
!
!Description:
! This script will open and close a socket on the user specified
! ports.
! The close will be a FIN rather than a RST. If one of the ports fails
! the service will be declared down
!
! Failure Upon:
! Not establishing a connection with the host on one of the specified
! ports.
!
! Notes: Does not use output
! Will handle out of sockets scenario.
!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
set OUT-OF-SOCKETS "785"
set NO-CONNECT "774"
! Make sure the user has a qualified number of arguments
if ${ARGS}[#] "LT" "2"
echo "Usage: ap-kal-tcp-ports \'ipAddress tcpPort1 [tcpPort2 tcpPort3...]\'"
exit script 1
endbranch
set SERVICE "${ARGS}[1]"
!echo "SERVICE = ${ARGS}[1]"
var-shift ARGS
while ${ARGS}[#] "GT" "0"
set TCP-PORT "${ARGS}[1]"
var-shift ARGS
function SOCKET_CONNECT call
! If we're out of sockets, exit and look for sockets on the next KAL
interval
if RETURN "==" "${OUT-OF-SOCKETS}"
set EXIT_MSG "Exceeded number of available sockets, skipping until next interval."
exit script 0
endbranch
! Valid connection, look to see if it was good
if RETURN "==" "${NO-CONNECT}"
set EXIT_MSG "Connect: Failed to connect to
${SERVICE}:${TCP-PORT}"
exit script 1
endbranch
endbranch
no set EXIT_MSG
exit script 0
function SOCKET_CONNECT begin
set CONTINUE_ON_ERROR "1"
socket connect host ${SERVICE} port ${TCP-PORT} tcp 2000
set SOCKET-STAT "${STATUS}"
set CONTINUE_ON_ERROR "0"
socket disconnect ${SOCKET} graceful
function SOCKET_CONNECT return "${SOCKET-STAT}"
function SOCKET_CONNECT end
If there are two or more CSS devices you may want to include the section below for stateful failover.
owner Moveit
content MoveitVIP1
add service Moveit1
primarySorryServer Moveit2
redundant-index 1
balance leastconn
vip address 10.252.0.101
advanced-balance sticky-srcip
sticky-inact-timeout 30
active
content MoveitVIP1-ftp
add service Moveit1
primarySorryServer Moveit2
protocol tcp
port 21
application ftp-control
redundant-index 2
balance leastconn
vip address 10.252.0.101
advanced-balance sticky-srcip
sticky-inact-timeout 30
active