Load Balancing - Data Center Fundamentals

The concept of load balancing was introduced in Chapter 2. Chapter 6 describes the load-balancing concepts that are mentioned in this section.

Server load balancing is balancing trafﬁc load across a group of servers. The load balancer is in charge of distributing the load and ensuring the recipients of the load are available.

Load balancing can be performed by software running on the servers or by hardware devices that are in the path between the client and the server farm.

It is out of the scope of this book to describe in detail how software load balancing works, but it is important to understand that software load balancing is subject to scalability limitations.

TIP Software load balancing typically requires that all the servers see the clients’ requests even if each request is answered by only one server.

This mechanism causes flooding of each client request in the Data Center LAN. (Read Chapter 12, “Layer 2 Protocol Essentials,” for more information.) Flooding means that a single client request which arrives to the server farm is forwarded to all ports on the LAN.

The mechanism that forwards incoming requests to all the servers in the server farm uses multicast MAC addresses or dummy unicasts in the Data Center LAN.

A dummy unicast MAC address is a MAC that is never used by the servers as a source MAC address when forwarding traffic, so it is never learned by the Ethernet switches. The router device that forwards traffic on the server LAN uses either the multicast MAC address or the dummy unicast as the destination MAC address to reach the servers. Both MAC addresses cause flooding of this traffic on the server LAN.

This ﬂooding is undesirable because it consumes bandwidth. Additionally, all the servers see the client’s trafﬁc even if only one server is responding to the client’s request. For these reasons, software load balancing is subject to scalability limitations.

Hardware load balancing is a more efﬁcient mechanism for load distribution and high availability because it forwards each client request to only one server in the server farm, thus preserving the LAN bandwidth and optimizing the server-farm performance.

Load balancing is typically applied to these server categories: web servers, application servers, e-mail servers, DNS servers, RADIUS servers, streaming servers, and TN3270 servers.

You can conﬁgure load balancers to load-balance almost every protocol used by the applications, but they also have additional intelligence for certain protocols. HTTP is the protocol that load balancers understand better. In addition to HTTP, Cisco load balancers provide special support for SSL, DNS, FTP, POP2, POP3, SMTP, IMAP, streaming protocols, RADIUS, and the Wireless Session Protocol (WSP).

In addition to these protocols, a load balancer can operate on an unlimited number of protocols. You can conﬁgure load balancing for a given application if you know the following:

•

The Layer 4 protocols and ports used by the application—(Often referred to as the port mappings.) If the port mappings are well known, you can conﬁgure a load balancer to intercept only the protocol/port pairs of interest.

•

Whether or not the application negotiates dynamic ports—If the application negotiates Layer 4 ports dynamically, these ports cannot be speciﬁcally conﬁgured on the load balancer. The solution to this problem is to use a wildcard Layer 4 port.

Network Architecture Considerations 99

•

Whether or not the application uses embedded IP addresses—Load balancers perform NAT, which means that they hide the real address of the servers (which could be a private IP address) by translating it to a different IP address (which could be a public IP address). This mode of operation is referred to as directed mode. If the protocol used by the application carries IP addresses embedded in the payload of TCP or UDP, the load balancer might not be capable of translating these embedded IP addresses. The solution is to use the load balancer in dispatch mode. Protocols such as FTP or the streaming protocols often do not require dispatch mode because they are automatically translated by the load balancer.

All the protocol/port mappings (including mappings with wildcards) of a given application need to be grouped for the purpose of session persistence.

TIP The concepts described in this section apply to the virtual server conﬁguration of a load balancer. Read Chapter 6 to know what a virtual server is, the load-balancing modes of operation (directed mode and dispatch mode), and the basics of session persistence.

Read Chapter 19 for more information about session persistence.

Clustering

Clustering indicates the use of multiple servers that operate as a single device. Clustering provides high availability and load distribution. Business-critical applications are always deployed on clustered servers.

For some applications, such as database servers, e-mail servers, and ﬁle servers, clustering requires sharing the storage system so that when one element in the cluster fails, the remaining servers have access to the data that was previously processed by the failed device.

Figure 3-4 shows the topology of a cluster of two servers.

Figure 3-4 A Two-Node Cluster

Interconnect

Ethernet

Servers

SCSI Bus or Fibre Channel

RAID

The connectivity between the servers and the storage systems is provided by the I/O channel, which can be a Small Computer System Interface (SCSI) bus, Fibre Channel, Enterprise System Connection (ESCON), or Fibre Connectivity (FICON).

NOTE For more information about ESCON and FICON, see Chapter 14.

As shown in Figure 3-4, clustered topologies are characterized by the following:

•

A connection to the Ethernet network on a LAN where the servers receive client requests.

•

An interconnect cable (or network) that connects the servers directly. The servers use this connection to monitor each other and sometimes to transfer data as well. In most cases, the interconnect can be an Ethernet crossover cable or an Ethernet switch.

•

A storage system such as a Redundant Array of Independent Disks (RAID) connected to the servers in the cluster via a SCSI bus or a Fibre Channel network.

Cluster Models

If you want to conﬁgure servers to form a cluster, the server needs to run software that implements the clustering functions. Examples are Veritas Cluster Server, HP TruCluster Server, Microsoft Windows NT/2000 Cluster Service (MSCS), Solaris Sun Cluster, HP OpenVMS, and IBM Parallel Sysplex.

NOTE For more information about the IBM Parallel Sysplex, read Chapter 14.

The clustering software can support these clustering options:

•

Active/standby two-node cluster—This cluster consists of two servers attached to a RAID. One server is active and processes the clients’ requests. Data is continuously mirrored from the disks assigned to the primary server to the disks assigned to the backup server. When the primary server fails, the backup server takes over with the same IP address and provides access to the same data that was available on the primary server.

•

Active/active shared nothing—This architecture consists of a pair of servers, both attached to RAID systems of disks. Even if the disks are physically connected to both servers, each array is owned by one server. Figure 3-4 shows this type of topology.

Network Architecture Considerations 101

If a server fails, the other server takes over the operations of the failed server and uses the extra storage connection to mount the volumes previously controlled by the failed server.

•

Active/active shared everything—This architecture consists of servers connected to the same storage system where the servers can access the same ﬁles. A locking system provided by the cluster software prevents concurrent access to a given ﬁle. Active/

active shared everything clusters are typically used to build clusters with multiple servers. Figure 3-5 shows a cluster of servers connected with Fibre Channel to a shared storage system.

Figure 3-5 Fibre Channel Storage Cluster

Key network considerations for integrating clusters into the Data Center are the following:

•

The trafﬁc exchanged among the servers in the cluster for monitoring purposes can be multicast or unicast. Unicast is preferable because it preserves the LAN bandwidth.

•

Active/active shared everything topologies need to replace the interconnect cable with one or more switches in general with a LAN segment.

•

Active/active shared everything topologies call for the use of a SAN to connect servers to storage devices, as shown in Figure 3-5.

Geographical Clustering

Geographical clustering consists of clustering servers that are located at different geographical facilities.

Ethernet LAN

Fibre Channel SAN

Disk Subsystems

TIP By extending clusters geographically, it is possible to make the same application data available at multiple Data Centers, which is the prerequisite to deploying geographical load distribution such as DNS-based site selection. For more information on site selection, see Chapter 10.

The number-one requirement of geographical clustering is that the data available in one Data Center must be replicated at the remote Data Center. The second requirement is that the network must be capable of forwarding client requests to the servers in either Data Center location.

The data replication for cluster environments can take advantage of technologies such as disk replication or host-based replication:

•

Disk replication—This technique replicates data at the block level. When the servers of the cluster in the main Data Center write to the disk array, the disk-replication software generates the I/O write to a disk array in the remote Data Center. With this mechanism, the servers are unaware that the replication is taking place because the operation is performed by the disk-management software. Examples of this type of software are EMC Symmetrix Data Remote Facility (SRDF), IBM Peer-to-Peer Remote Copy (PPRC), HP Data Replication Manager (DRM), and Hitachi Truecopy.

•

Host-based replication—This technique replicates data at the ﬁle-system level.

Between the ﬁle system and the disk driver is the volume manager, which is software that manages the disks and creates a logical view of the physical devices for the use of the ﬁle system. With host replication, the volume manager on the server duplicates the writes to the storage system. Examples of this software are Microsoft Windows Local Disk Manager (LDM) and Veritas Volume Manager.

Designing a cluster solution requires validating which type of technology is supported by the clustering software and whether the replication technology is synchronous or

asynchronous.

Synchronous replication means that the server which is performing the write to disk waits for an acknowledgment of the success of the write. Asynchronous replication means that the server does not have to wait for an acknowledgment.

Synchronous technologies are suitable for low-latency networks such as a LAN or when Data Centers are no more than 100 kilometers (km) away. In all other cases, it is preferable to use asynchronous replication. The software typically provides the option to choose either mechanism.

The network design for data replication needs to consider the use of a SAN for the connectivity of the servers to the storage system and the need to connect Data Centers either via the WAN or with metro-optical technologies such as dense wave division multiplexing

Network Architecture Considerations 103

(DWDM) and coarse wave division multiplexing (CWDM). You can extend the SAN geographically with the following technologies:

•

iSCSI—Internet SCSI consists of sending SCSI commands on IP. If you install an iSCSI driver on the server, the volume manager can send SCSI commands to the Ethernet network interface card (NIC). You can use iSCSI for host-based replication to send write commands to a remote storage system through the WAN.

•

Fibre Channel over IP (FCIP)—This technique consists of tunneling Fibre Channel through the IP network by using routers with a Fibre Channel Port Adapter or a Fibre Channel switch/director with Gigabit Ethernet ports and FCIP capability (such as the Cisco MDS9000 family).

•

SAN extension via CWDM or DWDM—This technique consists in using CWDM or DWDM to provide Layer 1 connectivity for the SAN between two Data Centers.

With DWDM, it is possible to carry Fibre Channel, ESCON, FICON, and Gigabit Ethernet between Data Centers on the same ﬁber. Figure 3-6 depicts the use of DWDM equipment to multiplex the storage transport protocols into one ﬁber and demultiplex them at the remote Data Center.

Figure 3-6 Using DWDM to Connect Distributed Data Centers

You need to combine the data-replication technologies with a clustering technology that provides a single image of the system of servers. Depending on the clustering software, it might be a requirement that the servers of either Data Center location be on the same LAN.

Servers that belong to the same cluster should be able to exchange trafﬁc at Layer 2 between Data Centers. You can use metro-optical technologies such as CWDM or DWDM to extend the LAN by carrying Gigabit Ethernet to the remote Data Center, as depicted in Figure 3-6.

When you choose the transport technology that connects the Data Centers, you should consider the data-replication requirements as well as the possible need to extend the local subnet. Pay careful consideration to stretching a local subnet over the WAN because WANs

Data Center 1 Data Center 2

are built using a hierarchical approach to the IP addressing scheme and the interior gateway protocols (IGPs).

It is out of the scope of this book to describe each transport technology, but as a reference, this list describes the typical options:

•

WAN connectivity—A typical option for Data Center connectivity over the WAN is to use FCIP over a service provider or enterprise synchronous optical network/

synchronous digital hierarchy (SONET/SDH) transport. Replication using an FCIP transport can be synchronous over shorter metropolitan distances with low-latency links but is typically asynchronous over longer distances to avoid impacting application performance from the increased latency.

•

Dark Fiber—Enterprises can connect Data Centers via dark ﬁber-enabling transport of Gigabit Ethernet or Fibre Channel or further aggregation through deployment of CWDM, DWDM, Dynamic Packet Transport/Resilient Packet Ring (DPT/RPR), or SONET/SDH.

•

Wavelength services—In some areas, enterprises can connect Data Centers by leasing wavelength services from a service provider. From a technology standpoint, this choice equates to using a channel from a DWDM network. It enables Gigabit Ethernet, RPR, Fibre Channel, or SONET/SDH connectivity between Data Centers.

NOTE To optimize the use of the WAN bandwidth in high round-trip time (RTT), FCIP-capable devices—such as the Cisco MDS9000 family—you typically use the Window Scale Option (RFC 1323). (For more information about the Window Scale Option, see Chapter 7, “IP, TCP, and UDP”).

When designing the Data Center connectivity for high availability, one of the key consid-erations is the distance between the Data Centers. When you choose the distance, consider whether both Data Centers are within the threat radius of a potential disaster.

The achievable distance depends on the Layer 2 transport technology itself, and Chapter 12 provides the information that applies to Gigabit Ethernet. It also depends on the latency that can be tolerated by the applications that perform the data replication and the applications that perform the disk writes.

Security

Chapter 15 describes the security technologies that are typically used in a Data Center. The deployment of these technologies varies based on whether they are applied at the Internet Edge or in the intranet server farm.

Network Architecture Considerations 105

This list summarizes the aspects of the security design that relate to the architecture of the application environment of the Data Center:

•

Security zones—Server farms are assigned to different virtual LANs (VLANs), and ﬁrewalls separate these VLANs and server farms. Servers with similar security requirements are connected on the same LAN and are kept separated from servers that have different requirements. For example, in a multitier application architecture, web servers and database servers are on separate VLANs, and they communicate through a ﬁrewall.

•

Port mappings—Knowing which applications are used in the Data Center lets you decide which protocol/port pairs to open on a firewall. For those applications that open dynamic ports, the best option is to enable fixups on the firewall. A fixup is a feature tailored to a specific application, which can listen to the negotiation of dynamic ports between a client and a server and open these ports for the specific flow.

This arrangement limits the exposure of the servers to attacks that can take advantage of services which are not in use but have not been disabled on the servers.

•

Signatures—IDS sensors can detect attacks of many different types. IDS sensors deployed at the Internet Edge should be conﬁgured differently from IDS sensors deployed in front of the server farm. For the Internet Edge, it is appropriate to identify possible attacks to the client software carried with client-side programming

technologies. IDS sensors placed in front of the server farm should use signatures that capture attacks speciﬁc to the server and applications in use.

A common challenge when using firewalls in a multitier server farm is protocols that use dynamically negotiated ports and embedded IP addresses. It is easy to use firewalls with these protocols if they are supported as fixups.

Typical ﬁxups available on Cisco ﬁrewalls include HTTP, SMTP, Real Time Streaming Protocol (RTSP), FTP, LDAP, Sun RPC, SQL*NET, H.323, Trivial File Transfer Protocol (TFTP), UNIX rlogin, rexec, rsh, and Internet Control Message Protocol (ICMP).

NOTE For updated information about the supported protocols, refer to the Cisco documentation available on http://www.cisco.com.

Dynamically negotiated ports and embedded IP addresses are typical of the protocols that are used between web/application servers and distributed components and between web/

application servers and database servers. Some workarounds are necessary to pass these protocols through the ﬁrewalls if the ﬁrewall does not support them.

Using RMI and DCOM Through a Firewall

When using RMI for remote communication through firewalls, if you open only port 1099 for the connection to the registry, the communication will not work. After contacting the registry for the reference to the object, the actual call is executed on another port. Another possible problem is performing NAT on the firewall because the firewall does not translate the embedded IP address communicated by the registry to the client.

The trace in Example 3-6 shows a client machine 10.20.20.23 contacting a server machine on port 1099 (packet 1). Packet 10 shows the same client machine contacting the server on port 1067 with another TCP connection. 1099 is, of course, the registry port, and 1067 is the port assigned to the speciﬁc object being called. This port is dynamically negotiated, and there is no way for the ﬁrewall to know that it needs to open port 1067.

There are several workarounds to make RMI work through the ﬁrewalls, and they are described at http://java.sun.com/products/jdk/1.2/docs/guide/rmi/spec/rmi-arch.doc11.html and http://java.sun.com/j2se/1.4.1/docs/guide/rmi/faq.html.

Having a ﬁrewall in the path between a DCOM client and a DCOM server can be challenging. DCOM uses the well-known port 135, but the method calls are carried on the top of a dynamically negotiated port. Typically ﬁrewalls do not understand DCOM, which means that you need to open a range of ports for DCOM communication.

In document Data Center Fundamentals (Page 136-147)