Home Affairs - Embedded Terminal Failover via Network Load Balancer

Solution Design Scope

Network-level failover is required for Terminal Embedded failover, failover will be at the network-level and will require a 3rd party network failover solution, which is not part of Dispatcher Paragon installation. Network level failover can be achieved via software like NetScaler, or hardware load balancers like F5 BIG-IP.

Change will remove the requirement for Direct Server Return in current design, Konica Minolta SafeQ 6 can now support a third party network load balancer without the need for DSR.


High Level Design

images/download/attachments/310177020/image2023-5-12_15-1-11-version-1-modificationdate-1683867672223-api-v2.png


Network-level failover is supported on the following terminal types:

  • Dispatcher Paragon Embedded Terminal for Fuji Xerox

  • Dispatcher Paragon Embedded Terminal for Fuji Xerox XCP


Requirements for the third-party load balancer

  • The solution must be based on software or hardware load balancer in the customer's network (black box Failover and Load balancing). The unit of failover and load balancing is one Spooler Controller Group. The Spooler Controller Group is represented from the perspective of MFDs by one and only one virtual IP address or FQDN (reverse lookups have to be configured) which is held by the load balancer. This virtual address will be used by MFDs and Dispatcher Paragon Terminals.

    Following requirements are expected to be delivered by the load balancer for Terminal Failover:

    • It shall make failover decision based on the state of appropriate Windows Services as reported by Service Control Manager of individual servers running SPOC/TS services AND/OR based on the availability of selected TCP ports. If TCP based monitor is in place, required ports for monitoring are 5555 (for SPOC service) and 5022 (for TS service). The TCP monitor must finish connection after SYN - ACK with RST, not with FIN. Our recommendation for monitoring period is 5 seconds with node considered down after 3 unsuccessful attempts. Node shall not be considered up immediately but after defined time which must be based on real time required for Management/Site Server to start.

    • The load balancer shall honor affinity between MFDs and particular SPOC/TS service instances in the Spooler Controller Group based on the prior decisions made by the load balancer and configurable timeout window. I.e., when the load balancer decides to connect an MFD with a particular SPOC/TS service, it must connect the MFD to the same SPOC/TS service if connection (incl. DNS lookup) attempts are made by the MFD before the configurable timeout elapses. Affinity needs to be set for a minimum of 30 minutes.

    • The load balancer shall distribute requests among SPOC/TS nodes in the Spooler Controller Group uniformly.

    • The load balancer shall handle monitoring and reporting of the service failures on its own.

Following requirements are expected to be delivered by the load balancer for Print Job failover and load balancing:

  • It shall make failover decision based on the state of appropriate Windows Services as reported by Service Control Manager of individual servers running FSP services AND/OR based on the availability of selected TCP ports. If TCP based monitor is in place, required port for monitoring is 515 (for FSP service). Our recommendation for monitoring period is 5 seconds with node considered down after 3 unsuccessful attempts. Node shall not be considered up immediately but after defined time which must be based on real time required for FSP to start.

  • The load balancer shall honor affinity between Workstations and particular FSP service instances in the Site Server Cluster based on the prior decisions made by the load balancer and configurable timeout window. I.e., when the load balancer decides to connect a Workstation with a particular FSP service, it must connect the Workstation to the same FSP service if connection (incl. DNS lookup) attempts are made by the Workstation before the configurable timeout elapses. Affinity needs to be set for a minimum of 30 minutes.

  • The load balancer shall distribute requests among FSP nodes in the Site Server Cluster uniformly.

  • The load balancer shall distribute requests from Workstations to FSP based on network communication configuration (port 515 for LPR)

  • The load balancer shall handle monitoring and reporting of the service failures on its own.

5.3.1. Health Check

Ports required to be monitored using TCP Half Open health check:

Port

Service

Method

5555

SPOC Service

TCP Half Open

5022

Terminal Server

TCP Half Open

5.3.2. Ports Pass Through

The following ports are required to be passed to a specific node of the load balancer:
Please note, all the ports should be passed to the same node per request window as defined by persistence, please do not split the ports to different nodes.

Ports

Service

Method

Affinity / Persistence / Stickiness

5011 through to 5025

Terminal Server

Least connection Method

30 Minutes

5610

Terminal Server (WebDav)

Least Connection Method

30 Minutes

21
FTP Implementation is PASSIVE FTP and will require port > 1024 to be passed, refer to FTP explanation below.

Terminal Server (FTP)

Least Connection Method

30 Minutes

5.3.3. FTP Note

The most popular FTP implementation is the Passive or PASV mode. PASV-mode FTP connections are the default on most popular browsers. One of the major advantages of PASV mode is that the server does not need to create a new inbound connection to the FTP client. As we’ll see later, this makes PASV-mode FTP a bit more firewall-friendly.

A PASV mode FTP sequence of events would go like this:

  1. FTP client: This opens random response ports in the high number range. (For the purposes of this example, we’ll assume ports TCP 6000 and TCP 6001.)

  2. FTP client: This sends a request to open a command channel from its TCP port 6000 to the FTP server’s TCP port 21.

  3. FTP server: This sends an “OK” from its TCP port 21 to the FTP client’s TCP port 6000. The command channel is now established.

  4. FTP client: This sends a PASV command requesting that the FTP server open a port number that the FTP client can connect to establish the data channel.

  5. FTP server: This sends over the command channel the TCP port number that the FTP client can initiate a connection to establish the data channel. In this example, the FTP server opens port 7000.

  6. FTP client: This opens a new connection from its own response port TCP 6001 to the FTP server’s data channel 7000. Data transfer takes place through this channel.



Note that the PASV-mode FTP client initiates all connections. The FTP server never needs to create a new connection back to the FTP client.

5.3.3.1. Firewalls and FTP

FTP modes pose distinct security challenges, depending on whether you’re the client-side or the server-side firewall administrator.

5.3.3.2. PORT-mode FTP client-side firewall

How do you handle PORT-mode requests made from your FTP clients?

You need to allow both inbound and outbound connections to support PORT-mode FTP client requests made from behind your firewall:

  • Outbound: TCP port 21

  • Inbound: TCP ports 1024 and above