How to balance network protocol

Introduction

This document describes the configuration settings Oplon ADC to balance the most commonly used network protocols at port forwarding (OSI) level 4. The treatment of the HTTP/S layer 7 OSI protocol is not covered in this manual being Oplon ADC and widely described in the white paper with its multiple configurations and balancing policies. For the treatment and deepening of the individual parameters, please refer to Oplon ADC Reference Guides.

The document wants to be a reference being there for each protocol many configuration variants depending on the use that you want to do, the result you want to get and the characteristics of the network infrastructure and the pre-existing services.

Descriptions of the evolution of connections in different protocols are deliberately simplified to the useful elements to balance and high reliability the services provided with the protocols taken into account. For those who want to delve deeper with more details, refer to the original RFC and IETF specifications.

Oplon ADC allows you to have diversified parameters for each protocol and/or service group. It is therefore possible to use different backend services more flexibly by attributing to each of them its own characteristics of session affinity and calibrate time-outs in relation to the overall quality of the service in particular.

Is You can also use templates, making it much easier to parameterize. Templates can take advantage of a pre-existing connection profile by modifying only a few parameters and by difference generate an additional profile. Oplon ADC automatically creates at the start some profiles that can be used immediately without any further intervention. These profiles can also be used as templates to create new profiles that are tailored to your specific needs. The currently preset profiles are: HTTP/S; FTP; RDP with session affinity; RDP without session affinity; SSH; Telnet;DNS; LDAP; Udp.

In this document, preset profiles will be used where available for simplicity. In the chapter dedicated to the LDAP protocol there is an example of reuse through "templates" of parameters derived from another group. This technique is obviously usable on all occasions when some parameters do not meet the specific needs of the installation. In the LDAP chapter there is also an example of using the balancing policy "Failover". The latter possibility can also be used in the protocols described or in other custom protocols.

File Transfer Protocol (FTP)

The FTP protocol is a protocol designed to exchange files between heterogeneous machines.

The protocol distinguishes two streams with independent connections, Commands Flow and the Flow Data. Independent connections are established for each of these streams. The evolution of these connections can occur in two ways; Active-mode Or Passive-mode.

1. Active-mode FTP connections

The evolution of the FTP protocol information flow in Active-mode, also called "client-managed", begins with the client sending a known address/port to the server to which the server must send the data. The diagram below highlights this type of flow by indicating in red who takes the initiative and establishes the connection.

1. The Client connects to the Server 21 and sends to the Server proposal for a temporary address/port (e.g. 6060) to which the Server must connect to run the data transfer command

2. The Server responds with an ACK.

3. The Server connects to the temporary address/port (e.g.6060) passed earlier to run the command

4. Depending on the command, data is transferred through the connection established to the temporary address/port (e.g.6060)

The connection Active-mode is normally the default setting of an FTP server. This type of connection sees its limitations when we are in the presence of one or more Firewall This is because normally in a datacenter only some known ports are open outbound. On the client side, connections in listen are normally disabled by the Firewall making communication impossible.

For this reason, a different way of evolving the connection has also been developed to be able to overcome these limitations: FTP "Passive-mode".

2. Passive-mode FTP connections In Passive-mode or "server-managed" the communication flow begins with the connection of the Client towards the Server and the client responds to the Client with its pre-arranged address/port on which the client Client can make new connections in order to transfer the Data stream based on the command used.

1. The Client connects to the Server 21 and sends to the Server proposed connection to the temporary address/port (e.g. 6060) to which the Server should connect to run the data transfer command

2. The Server does not respond to the client's proposal and sends your PASV connection proposal to your address/port (e.g.6161) for data transfer

3. The Client with a new connection to the Server from following the command

4. The Server depending on the command sends an ACK and from following the stream

The latter way of establishing the flow of communication, which sees the Client as the one who takes the initiative and makes connections to the Server, is the solution, slightly more elaborate as we'll see later, that allows Datacenter to safeguard the efficiency of the FTP protocol in data transfer while safeguarding scalability, high reliability and security by being able to use addresses in NAT (Network Address Translation) downstream of a Firewall. In fact, in point [2] the FTP Server can suggest not only the port but also an address to connect to that may be different from its own, such as the address where it is listening Oplon ADC.

In this regard, below are the two-moment patterns of the same scenario in which the first scheduled transfer request is made by Oplon ADC In Server A in the next image, it is scheduled in the Server B.

1. The Client connects to the Server 21 and sends to the Server proposal for a temporary address/port (e.g. 6060) to which the Server should connect to run the data transfer command

2. Oplon ADC, based on routing policies, it makes a connection to the Server A at port 2121

3. The Server A does not collect the proposal of the Client and responds with its pasV (passive) connection proposal to the Oplon ADC port (e.g. 6161) for data transfer

4. Oplon ADC transfers the information to the Client

5. The Client with a new connection to Oplon ADC (port 6161) follows the lead

6. Oplon ADC based on routing policies, the data connection to the Server A port (e.g. 6161)

7. The Server A transfers data to Oplon ADC from port 6161

8. Oplon ADC forwards the data to the Client from port 6161

Below is the schema of the same stream at the second connection and transfer request.

It can be seen that Listener Data In Server A and B are not always present but are activated when you need to transfer DataThe Listener command are always active.

The Server Ftp are set to "Active-mode" and then to get this feature they must be set to "Passive-mode". Check your manual Server FTP specific setting.

An important consideration is determined by the consistency of the information contained in the Server A And Server B exposed by the fees FTP Server. In fact, the transmission load balancer does not enter into the merits of the transmitted content and therefore the information processed by the respective FTP Servers/Services must be shared at the level Storage or with Filesystem network, CIFS/NFS, or with Global Filesystem.

On the next page you can see an example of a configuration file Oplon ADC to get the result above.

Attention: After you set the port range to restart the service from Services, it is NOT enough to restart the service from the Internet Information Services panel. The service must be restarted.

From the GUI, simply use the template, copy it to the desired instance, and change the addresses and ports on which you will accept link requests.

To set up a preconfigured grouping endpoint, simply go to the FTP template group and then copy it to the desired instance. Once copied, you only need to change the number and addresses of the endpoints to use it.

parameters -FTP

Bind listenType-"NAT"
address"192.168.43.141" port"21, 65000-65010"
portForwarding-"true"
osiLayer"4"
protocol-"ftpDATA"
endPointsGrouping"FTP"
transport-"tcp"
          transportSessionAffinity-"true"
          enableVirtualDomain"false"
          enable-"true"/>

endPointsGrouping property groupName"FTP" loadBalancingType"Adaptative" enable"true"
virtualDomain, New1001 enable-"true"
endp property address"192.168.45.141" healthCheck"false" enable"true"
endp property address"192.168.45.143" healthCheck"false" enable"true"

Remote Desktop Protocol (RDP)

Remote desktop services provide multiple client sessions provided by a host system.

This protocol now finds a concrete application with significant amounts of computing power and network throughput at the cost that make competitive a centralized desktop solution that takes the name of Vdi (Virtual Desktop Infrastructure).

The centralization of the desktop is not proposed as a solution suitable for all needs but with the increase in the availability of infrastructure can now be applied in many realities both Intranet That Extranet.

Certainly, centralization offers undoubted advantages such as, one of all, the possibility of placing in high reliability a service that, by its nature, if entrusted to individual productivity tools could not be by definition.

Oplon ADC In this context, it manages to simplify in a few moments both aspects of load balancing and aspects related to high reliability for the use of Remote Desktop.

The RDP protocol starts with a connection where negotiation takes place and evolves with a disconnect and then a new connection result of negotiation.

The new connections are highlighted in red in the diagram below.

1. The client connects to the server

2. Trading

3. Ack and disconnect

   1. (A) Connecting with negotiated parameters

   2. (A) Connection evolution

   3. (A) Connection evolution...

From this simple scheme it is immediately possible that in an architecture that can scale not only from a resource utilization point of view but also in the continuation of time during the succession of successive server-side releases and side Client, the initial phase of connection-negotiation-disconnect, in an environment with multiple systems Terminal-Server, must occur on the same machine as the initial connection.

Starting from this consideration in the version Oplon ADC 9.0 you can get two different modes of behavior as needed. A first behavior tends to favor the balancing of connections at the expense of the persistence of the connection to a terminal point, a second behavior that instead favors the persistence of the last connection by hanging up the pre-existing "terminal" if still active.

For this reason, you must use the "session-affinity" parameter and limit it for the time it takes to make the first negotiation connection and the next data connection.

The two schemes report the evolution of a connection flow that, for negotiation consistency, must occur on the same server on which the first negotiation connection was made.

To achieve this, you need to Oplon ADC remember, at least for as long as it takes, to establish the connection at the same Server Negotiation Connection was made.

On the next page you can see an example of a configuration file Oplon ADC to get the result above. You can then see a configuration file that favors persistence at the last connection by returning, in session timeout terms, to the same service after disconnecting.

Again, there are already templates that can be used directly through the copy utility of the HTML 5: Copy and customize the listener

Copying and customizing endpoints

RDP example (with session affinity)

Bind 
listenType-"NAT"
description-"Sample RDP with session affinity" 
address-"0.0.0.0" port"3389"
osiLayer"4"
protocol-"rdp-session-affinity"
endPointsGrouping"sample-rdp-mysession-affinity"
transport-"tcp"
transportSessionAffinity-"true"

endPointsGrouping property groupName"sample-rdp-mysession-affinity" enable-"true"
virtualDomain, New1001 enable-"true"
endp address"localhost" port"3389" enable"true"
	endp address"localhost" port"3389" enable"true"

Unlike a single environment Server in a balanced environment, you are not always sure to return to the same server at the next connection request (deliberately working without session affinity or unintentionally for session expiration). In this case there would be some considerations to be made about the time-out of the session and the position of the balancer with respect to the architectural layer that we refer for the moment to the certification course required to install Oplon ADC in a production environment.

In this regard, it is important to know that in a typical situation with architecture screened by a firewall with NAT addresses and having a good trade-off between resource exploitation and "terminal-server" sessions spread across all Servers the RDP Server must be set up so that if some sessions are no longer used because it is disconnected, a log-off must be commanded in order to free up resources.

In this regard and purpose the service RDP-server (aka terminal-server) provides some parameters that allow you to log out automatically in the event of a disconnect, or set a time-out if a connection is not used for a specified time. In environments with many "centralized" workplaces, these two parameters allow you to always have systems with resources committed only to the sessions actually used.

The parameters are very easy to set up and below the snaps that allow you to make behavior changes.

Path:

Control Panel > Administrative Tools > Terminal Services Configuration > RDP-tcp > Sessions, New10

Also set:

"Override user settings" to "End session"

In situations with many RDP-Client you should also set the time-out for unused terminal. The value of the time-out is in relation to the type of job usage and the resources available. The following example sets the session time-out to 2 days.

• Parameters with "rdp-nosession-affinity" "Override user settings":"End a disconnected session:" to "1 minute" "Active session limit" to "Never" "Idle session limit" to "2 days"

• Parameters with "rdp-session-affinity" "Override user settings":"End a disconnected session:" to "30 minutes" "Active session limit" to "Never" "Idle session limit" to "2 days"

In this way, after 2 days of inactivity, the Client disconnects and after one or 30 minutes the terminal server session, on the server, performs a logoff and frees resources.

Telnet, SSH & SFTP (Secure Shell & Secure File Transfer Protocol)

Secure Shell It is a secure protocol for remote logining and other services across the network.

This protocol, often used to provide remote control-line terminal functionality in safe mode, has been designed to deliver multiple communication services between computers as defined by the RFC 4254 and in particular:

• "shell" for terminal shells

• SFTP and exec requests (including SCP transfers)

• "direct-tcpip" for client-to-server forwarded connections

• "forwarded-tcpip" for server-to-client forwarded connections

The protocol, in its most common form of use, uses a port listening in SSL where depending on the command (called Channel, New10 now forward as per RFC 4254) specifications used can evolve into different types of service.

Below is the graphical representation of the evolution of the connection with this protocol with the connection and the verse highlighted in red.

1. The SSH Client connects to the Server on port 22

2. The Server establishes a secure connection

3. The Client specifies the Channel and its features

4. Evolution of the connection with the features of the Channel

In this simplified representation, but useful for the purpose of the manual, it should be noted that once the connection is established, it evolves within the same connection regardless of the Channel, New10 Used. This behavior is very useful for delivering heterogeneous services through firewalls and also makes it easier to parameterize Oplon ADC having a single channel to balance.

Below is a graphical representation of the evolution of the connection Ssh balancing. The connection and its verse are highlighted in red.

1. The Client connects to Oplon ADC at port 22

2. Oplon ADC connects to the Server A, according to load-balancing policies, at port 22

3. The Server A, with the service Ssh listening to port 22, responds and establishes a secure connection

4. Oplon ADC forwards the response of the Server A

5. The Client Specifies the Channel, New10 and its characteristics Oplon ADC

6. Oplon ADC forwards the specifications to the Server A

7. Evolution of the connection with the characteristics of the Channel, New10 on the channel established with Oplon ADC

8. Oplon ADC forwards the evolution of the connection to the Server A

The following is the evolution of the connection to the next service request:

To achieve this result, the use of the services Ssh balanced and highly reliable parameterization Oplon ADC It's very simple. Just a few considerations about the TimeOut. In the schema below, the TimeOut , that is, the connection term if not used, is set to 1 hour. Depending on the safety and security Channel, New10 predominantly used you can act on this parameter.

Again, there are already templates that can be used directly through the copy utility of the HTML 5: Copy and customize the listener

Copying and customizing endpoints

iproxy.xml -SSH-SFTP example

Bind listenType-"NAT"
description-"Sample SSH"
address-"0.0.0.0" port"222"
osiLayer"4"
protocol-"ssh"
endPointsGrouping"sample-ssh"
transport-"tcp"
transportSessionAffinity-"true"
enable-"true"

endPointsGrouping property groupName"sample-ssh" enable-"true"
virtualDomain, New1001 enable-"true"
endp property address-"localhost" port-"22" enable-"true"
endp property address-"localhost" port-"22" enable-"true"

Lightweight Directory Access Protocol (LDAP)

This protocol has been designed to provide directory services and has evolved over time due to the need to centralize large volumes of profile information.

From the point of view of the evolution of the connection being a state-of-the-art protocol the balancing does not present protocol difficulties. The only caveat is that the LDAP Server product supports multimaster or comunque functionality to scale out across multiple systems. From the version Oplon ADC 5.0 You can also use LDAP servers with "active-passive" capabilities and by associating a balancing policy "Failover" (see white paper to learn more about FailOver).

Normally an LDAP Server is used to make many reads and few writes. It is therefore optimized for this type of function. However, in some circumstances there may be a need to implement an LDAP-based infrastructure with high writing needs, and in these situations it is appropriate to adapt balancing policies as we shall see later.

The port on which an LDAP Server normally listens is TCP port 389 and TCP port 636 for SSL on which the entire communication evolves. Below is the evolution of the protocol with the connections highlighted in red. These examples take port 389 into account, but the concept also applies to port 636 where the SSL connection evolves.

1. The client connects to port 389

2. LDAP server establishes transmission

3. Protocol evolution

In order to balance this protocol, you must have a two-way forwarding engine, and the evolution of the protocol into multimaster environments is highlighted in the schema below.

1. The client connects to port 389 on which it is listening Oplon ADC

2. Oplon ADC according to balancing policies, forward the connection to the LDAP Server A service

3. The LDAP service responds with an ACK Oplon ADC

4. Oplon ADC forwards the ACK message

5. Evolution of the client protocol to Oplon ADC

6. Forward of protocol evolution

In the following image, a new connection evolves and balances the new request on Server B.

As briefly mentioned in the introduction, these architectures are normally used predominantly in reading and in these situations the balance can be used without special attention to balancing policies. What is different is if we are in the presence of Multimaster Services and you need to make many writes and immediate rereadings. In fact, multimaster installations have the data repository replicated to effectively make up for failure without the need to use shared global clusters and repositories. While this decreases the complexity of installation and retention, since replication services are normally asynchronous, if the number of updates and writes were to be very high, an instant read of the same data on another node may not be consistent.

To do this in both situations, you can give an appropriate balancing response using session affinity. It should be pointed out that LDAP Servers are normally used for countless reads and few writes, and therefore in 98% of cases you will use a balance without session affinity to make the most of the potential of this architecture.

Again, there are already templates that can be used directly through the copy utility of the HTML 5: Copy and customize the listener

Copying and customizing endpoints

iproxy.xml -LDAP example

Bind listenType-"NAT"
description"LDAP no session affinity"
address-"0.0.0.0" port"389"
endPointsGrouping"ldap-services"
enableVirtualDomain"false"
protocol-"ldap"
transport-"tcp"
osiLayer"4"
enable-"true"

endPointsGrouping property enable-"true" groupName-"ldap-services"
virtualDomain, New1001 enable-"true" virtualDomainName-"default"
endp property address-"localhost" enable-"true" port-"389"
endp property address-"localhost" enable-"true" port-"389"

iproxy.xml -LDAP with session affinity example

Bind listenType-"NAT"
description"LDAP no session affinity"
address-"0.0.0.0" port"389"
endPointsGrouping"ldap-services"
enableVirtualDomain"false"
protocol-"ldap"
transport-"tcp"
transportSessionAffinity-"true"
osiLayer"4"
enable-"true"

endPointsGrouping property enable-"true" groupName-"ldap-services"
virtualDomain, New1001 enable-"true" virtualDomainName-"default"
endp property address-"localhost" enable-"true" port-"389"
endp property address-"localhost" enable-"true" port-"389"

iproxy.xml -LDAP FailOver example

Bind listenType-"NAT"
description"LDAP no session affinity"
address-"0.0.0.0" port"389"
endPointsGrouping"ldap-services-failover"
enableVirtualDomain"false"
protocol-"ldap"
transport-"tcp"
osiLayer"4"
enable-"true"

endPointsGrouping property enable-"true" groupName-"ldap-services-failover" 
         loadBalancingType:"FailOver"
virtualDomain, New1001 enable-"true" virtualDomainName-"default"
endp property address-"localhost" enable-"true" port-"389"
endp property address-"localhost" enable-"true" port-"389"

Database listeners Oracle & Oracle RAC, universal DBMS

Transmission protocols that allow information to be exchanged between clients and the Database Management System (DBMS) are generally connection-oriented.

These protocols for Oplon ADC do not present any particular critical issues in tunneling and traffic balancing.

This section is used to balance connections to Oracle RAC and Oracle Classic listeners. The same parameters can also be used for other databases that, from a point of view of the evolution of transmission, do not deviate from these behaviors.

Data traffic balancing techniques for a Database are often not related to tightly traffic balancing, which is also provided by the manufacturer, but are geared toward decoupling the disbursement of the dispensing point from requests on a "cross" transport layer between applications to provide high availability, disaster recovery, security and expandability services during the exercise and, not least Simplicity.

Taking expandability (scalability) during exercise, for example, decoupling between clients and services makes it easy to insert additional RAC nodes without changing client settings, which is absolutely appreciated in enterprise environments and distributed client server environments. Changing client settings in fact, becomes very expensive, especially if deployed (Client server applications), or at least delicate operations when placed on application servers in production.

The evolution of the protocol, from a connection and transport point of view, can be summarized as follows:

1. The client connects to port 1521

2. DB Server listener establishes transmission

3. Protocol evolution

4. Information exchange

The following image highlights the role of client DB connectors themselves in a tiered environment where connections to the Database are made by Application servers that in turn provide application services. Normally DB Clients within the Connection Pool have been connecting since they started and are already in a connection state of the connection that they require.

1. The client connects to the service provided by the application server

2. A pool client DB connection makes the request

3. DB Server listener establishes transmission

4. Protocol evolution

5. Information exchange between the application within the Application Server, the Pool Client DB, and the DB Server

6. Result of application processing to application clients that have requested service

The scenario below summarizes the evolution of the connection by introducing the balance layer in a completely transparent way.

1. The client connects to the service provided by the application server

2. A pool client DB connection makes the request to Oplon ADC

3. Oplon ADC requests to one of the two nodes

4. The DB Server listener establishes the transmission with Oplon ADC

5. Oplon ADC responds to the client that requested it

6. Protocol evolution

7. Information exchange between the client and the application within the Application Server

8. The application server makes requests to Oplon ADC

9. Oplon ADC forwards the request to the server DB listener

10. 11.12. information exchange

11. Maintaining the connection even after the client's application activities are closed

Precisely because of the type of connection-oriented protocol, and therefore with the fewest possible connections/disconnections, it is important to ensure that the connection is properly divided on the nodes at their origin. For this purpose, the use of the "Adaptative" balancing policy ensures that we have well-homogenized connections on all DB nodes.

Again, there are already templates that can be used directly through the copy utility of the HTML 5: Copy and customize the listener

Copying and customizing endpoints

iproxy.xml -ORAC example

Bind listenType-"NAT"
description-"ORAC"
address-"0.0.0.0" port"51122"
endPointsGrouping:"ORAC"
enableVirtualDomain"false"
protocol-"ORAC"
transport-"tcp"
transportSessionAffinity"false"
osiLayer"4"
enable-"true"

endPointsGrouping property enable-"true" groupName-"ORAC" loadBalancingType-"Adaptative"
virtualDomain, New1001 enable-"true" virtualDomainName-"default"
endp property address-"localhost" enable-"true" port-"51222"
endp property address-"localhost" enable-"true" port-"51222"

For all other (non-equal) database types, the connection type has been added in version 7.0 Dbms. This parameterization does not deviate from the parameterization of the ORACLE/ ORACLE RAC protocol the differences obviously remain in the type of balance that cannot be equal and must therefore orient itself on the type of balance FailOver. Only when the connection with the primary server fails will a connection with the secondary server be attempted.

This solution finds the best result when associated with Oplon Commander able to switch service operations from one server to another in a coordinated manner to network activity.

iproxy.xml -DBMS example

Bind listenType-"NAT"
description-"DBMS"
address-"0.0.0.0" port"51122"
endPointsGrouping:"DBMS"
enableVirtualDomain"false"
protocol-"DBMS"
transport-"tcp"
transportSessionAffinity"false"
osiLayer"4"
enable-"true"

endPointsGrouping property enable"true" groupName"DBMS" loadBalancingType"FailOver"
virtualDomain, New1001 enable-"true" virtualDomainName-"default"
endp property address-"localhost" enable-"true" port-"51222"
endp property address-"localhost" enable-"true" port-"51222"

Bibliography

1. Network Working Group J. Postel Request for Comments: 959 J. Reynolds ISI [http://www.w3.org/Protocols/rfc959/ (opens in a new tab)]

2. Unix Network Programming, W.Richard Stevens, Prentice-Hall, 1998

3. Unix System V, Network Programming, Stephen Rago, Addison-Wesley, 2000

4. Web Proxy Servers, Ari Luotenen, Prentice Hall, 1998

5. Load Balancing Servers, Firewalls, and Caches, Chandra Kopparapu, Wiley, 2001

6. Calculator Networks, Larry L. Peterson, Bruce S. Davie, Apogeo, 2004

7. Network Working Group S. Lehtinen Request for Comments: 4250 SSH Communications Security Corp [http://www.ietf.org/rfc/rfc4250.txt (opens in a new tab)]

8. Network Working Group T. Ylonen Request for Comments: 4251 SSH Communications Security Corp [http://www.ietf.org/rfc/rfc4251.txt (opens in a new tab)]

9. Network Working Group T. Ylonen Request for Comments: 4252 SSH Communications Security Corp [http://www.ietf.org/rfc/rfc4252.txt (opens in a new tab)]

10. Network Working Group T. Ylonen Request for Comments: 4253 SSH Communications Security Corp [http://www.ietf.org/rfc/rfc4253.txt (opens in a new tab)]

11. Network Working Group T. Ylonen Request for Comments: 4254 SSH Communications Security Corp [http://www.ietf.org/rfc/rfc4254.txt (opens in a new tab)]

12. Network Working Group W. Yeong Request for Comments: 1487 Performance Systems International [http://tools.ietf.org/html/rfc1487 (opens in a new tab)]

13. Network Working Group W. Yeong Request for Comments: 1777 Performance Systems International [http://tools.ietf.org/html/rfc1777 (opens in a new tab)]