【精品资料】计算机类外文文献翻译-Linux企业集群.doc

摘自：linux企业集群(the linux enterprise cluster)英文原文: the linux enterprise clusteroverviewthis chapter will introduce the cluster load-balancing software called ip virtual server (ipvs). the ipvs software is a collection of kernel patches that were merged into the stock version of the linux kernel starting with version 2.4.23. when combined with the kernels routing and packet-filtering capabilities (discussed in chapter 2) the ipvs-enabled kernel lets you turn any computer running linux into a cluster load balancer. together, the ipvs-enabled cluster load balancer and the cluster nodes are called a linux virtual server (lvs).the lvs cluster load balancer accepts all incoming client computer requests for services and decides which cluster node should reply to each request. the load balancer is sometimes called an lvs director or simply a director. in this book the terms lvs director, director, and load balancer all refer to the same thing.the nodes inside an lvs cluster are called real servers, and the computers that connect to the cluster to request its services are called client computers. the client computers, the director, and the real servers communicate with each other using ip addresses the same way computers have always exchanged packets over a network; however, to make it easier to discuss this network communication, the lvs community has developed a naming convention to describe each type of ip address based on its role in the network conversation. so before we consider the different types of lvs clusters and the choices you have for distributing your workload across the cluster nodes (called scheduling methods), lets look at this naming convention and see how it helps describe the lvs cluster.lvs ip address name conventionsin an lvs cluster, we cannot refer to network addresses as simply ip addresses. instead, we must distinguish between different types of ip addresses based on the roles of the nodes inside the cluster. here are four basic types of ip addresses used in a cluster:virtual ip (vip) addressthe ip address the director uses to offer services to client computersreal ip (rip) addressthe ip address used on the cluster nodesdirectors ip (dip) addressthe ip address the director uses to connect to the d/rip networkclient computers ip (cip) addressthe ip address assigned to a client computer that it uses as a source ip address for requests sent to the clusterthe virtual ip (vip)the ip address that client computers use to connect to the services offered by the cluster are called virtual ip addresses (vips). vips are ip aliases or secondary ip addresses on the nic that connects the director to the normal, public network.1 the lvs vip is important because it is the address that client computers will use when they connect to the cluster. client computers send packets from their ip address to the vip address to access cluster services. you tell the client computers the vip address using a naming service (such as dns, ddns, wins, ldap, or nis), and this is the only name or address that client computers ever need to know in order to use the services inside the cluster. (the remaining ip addresses inside the cluster are not known to the client computer.)a single director can have multiple vips offering different services to client computers, and the vips can be public ip addresses that can be routed on the internet, though this is not required. what is required, however, is that the client computers be able to access the vip or vips of the cluster. (as well see later, an lvs-nat cluster can use a private intranet ip address for the nodes inside the cluster, even though the vip on the director is a public internet ip address.)the real ip (rip)in lvs terms, a node offering services to the outside world is called a real server. (we will use the terms cluster node and real server interchangeably throughout this book.) the ip address used on the real server is therefore called a real ip address (rip).the rip address is the ip address that is permanently assigned to the nic that connects the real server to the same network as the director. well call this network cluster network or the director/real-server network (d/rip network). the director uses the rip address for normal network communication with the real servers on the d/rip network, but only the director needs to know how to talk to this ip address.the directors ip (dip)the directors ip (dip) address is used on the nic that connects the director to the d/rip network. as requests for cluster services are received on the directors vip, they are forwarded out the dip to reach a cluster node. as is discussed in chapter 15, the dip and the vip can be on the same nic.the client computers ip (cip)the client computers ip (cip) address may be a local, private ip address on the same network as the vip, or it may be a public ip address on the internet.types of lvs clustersnow that weve looked at some of the ip address name conventions used to describe lvs clusters, lets examine the lvs packet-forwarding methods.lvs clusters are usually described by the type of forwarding method the lvs director uses to relay incoming requests to the nodes inside the cluster. three methods are currently available:network address translation (lvs-nat)direct routing (lvs-dr)ip tunneling (lvs-tun)although more than one forwarding method can be used on a single director (the forwarding method can be chosen on a per-node basis), ill simplify this discussion and describe lvs clusters as if the director is only capable of using one forwarding method at a time.the best forwarding method to use with a linux enterprise cluster is lvs-dr (and the reasons for this will be explained shortly), but an lvs-nat cluster is the easiest to build. if you have never built an lvs cluster and want to use one to run your enterprise, you may want to start by building a small lvs-nat cluster in a lab environment using the instructions in chapter 12, and then learn how to convert this cluster into an lvs-dr cluster as described in chapter 13. the lvs-tun cluster is not generally used for mission-critical applications and is mentioned in this chapter only for the sake of completeness. it will not be described in detail.network address translation (lvs-nat)in an lvs-nat configuration, the director uses the linux kernels ability (from the kernels netfilter code) to translate network ip addresses and ports as packets pass through the kernel. (this is called network address translation (nat), and it was introduced in chapter 2). note well examine the lvs-nat network communication in more detail in chapter 12.a request for a cluster service is received by the director on its vip, and the director forwards this requests to a cluster node on its rip. the cluster node then replies to the request by sending the packet back through the director so the director can perform the translation that is necessary to convert the cluster nodes rip address into the vip address that is owned by the director. this makes it appear to client computers outside the cluster as if all packets are sent and received from a single ip address (the vip).basic properties of lvs-natthe lvs-nat forwarding method has several basic properties:the cluster nodes need to be on the same network (vlan or subnet) as the director.the rip addresses of the cluster nodes normally conform to rfc 19182 (that is, they are private, non-routable ip addresses used only for intracluster communication).the director intercepts all communication (network packets going in either direction) between the client computers and the real servers.the cluster nodes use the directors dip as their default gateway for reply packets to the client computers.the director can remap network port numbers. that is, a request received on the directors vip on one port can be sent to a rip inside the cluster on a different port.any type of operating system can be used on the nodes inside the cluster.a single director can become the bottleneck for the cluster.at some point, the director will become a bottleneck for network traffic as the number of nodes in the cluster increases, because all of the reply packets from the cluster nodes must pass through the director. however, a 400 mhz processor can saturate a 100 mbps connection, so the network is more likely to become the bottleneck than the lvs director under normal circumstances.the lvs-nat cluster is more difficult to administer than an lvs-dr cluster because the cluster administrator sitting at a computer outside the cluster is blocked from direct access to the cluster nodes, just like all other clients. when attempting to administer the cluster from outside, the administrator must first log on to the director before being able to telnet or ssh to a specific cluster node. if the cluster is connected to the internet, and client computers use a web browser to connect to the cluster, having the administrator log on to the director may be a desirable security feature of the cluster, because an administrative network can be used to allow only internal ip addresses shell access to the cluster nodes. however, in a linux enterprise cluster that is protected behind a firewall, you can more easily administer cluster nodes when you can connect directly to them from outside the cluster. (as well see in part iv of this book, the cluster node manager in an lvs-dr cluster can sit outside the cluster and use the mon and ganglia packages to gain diagnostic information about the cluster remotely.)direct routing (lvs-dr)in an lvs-dr configuration, the director forwards all incoming requests to the nodes inside the cluster, but the nodes inside the cluster send their replies directly back to the client computers (the replies do not go back through the director).3 as shown in figure 11-3, the request from the client computer or cip is sent to the directors vip. the director then forwards the request to a cluster node or real server using the same vip destination ip address (well see how the director does this in chapter 13). the cluster node then sends a reply packet directly to the client computer, and this reply packet uses the vip as its source ip address. the client computer is thus fooled into thinking it is talking to a single computer, when in reality it is sending request packets to one computer and receiving reply packets from another. lvs-dr network communication basic properties of lvs-drthese are the basic properties of a cluster with a director that uses the lvs- dr forwarding method:the cluster nodes must be on the same network segment as the director.4 the rip addresses of the cluster nodes do not need to be private ip addresses (which means they do not need to conform to rfc 1918).the director intercepts inbound (but not outbound) communication between the client and the real servers.the cluster nodes (normally) do not use the director as their default gateway for reply packets to the client computers.the director cannot remap network port numbers.most operating systems can be used on the real servers inside the cluster.5 an lvs-dr director can handle more real servers than an lvs-nat director.although the lvs-dr director cant remap network port numbers the way an lvs-nat director can, and only certain operating systems can be used on the real servers when lvs-dr is used as the forwarding method,6 lvs-dr is the best forwarding method to use in a linux enterprise cluster because it allows you to build cluster nodes that can be directly accessed from outside the cluster. although this may represent a security concern in some environments (a concern that can be addressed with a proper vlan configuration), it provides additional benefits that can improve the reliability of the cluster and that may not be obvious at first:if the director fails, the cluster nodes become distributed servers, each with their own ip address. (client computers on the internal network, in other words, can connect directly to the lvs-dr cluster node using their rip addresses.) you would then tell users which cluster-node rip address to use, or you could employ a simple round-robin dns configuration to hand out the rip addresses for each cluster node until the director is operational again.7 you are protected, in other words, from a catastrophic failure of the director and even of the lvs technology itself.8 to test the health and measure the performance of each cluster node, monitoring tools can be used on a cluster node manager that sits outside the cluster (well discuss how to do this using the mon and ganglia packages in part iv of this book).to quickly diagnose the health of a node, irrespective of the health of the lvs technology or the director, you can telnet, ping, and ssh directly to any cluster node when a problem occurs.when troubleshooting what appear to be software application problems, you can tell end-users9 how to connect to two different cluster nodes directly by ip (rip) address. you can then have the end-user perform the same task on each node, and youll know very quickly whether the problem is with the application program or one of the cluster nodes. note in an lvs-dr cluster, packet filtering or firewall rules can be installed on each cluster node for added security. see the lvs-howto at for a discussion of security issues and lvs. in this book we assume that the linux enterprise cluster is protected by a firewall and that only client computers on the trusted network can access the director and the real servers.ip tunneling (lvs-tun)ip tunneling can be used to forward packets from one subnet or virtual lan (vlan) to another subnet or vlan even when the packets must pass through another network or the internet. building on the ip tunneling capability that is part of the linux kernel, the lvs-tun forwarding method allows you to place cluster nodes on a cluster network that is not on the same network segment as the director. note we will not use the lvs-tun forwarding method in any recipes in this book, and it is only included here for the sake of completeness.the lvs-tun configuration enhances the capability of the lvs-dr method of packet forwarding by encapsulating inbound requests for cluster services from client computers so that they can be forwarded to cluster nodes that are not on the same physical network segment as the director. for example, a packet is placed inside another packet so that it can be sent across the internet (the inner packet becomes the data payload of the outer packet). any server that knows how to separate these packets, no matter where it is on your intranet or the internet, can be a node in the cluster, as shown in figure 11-4.10 lvs-tun network communication the arrow connecting the director and the cluster node in figure 11-4 shows an encapsulated packet (one stored within another packet) as it passes from the director to the cluster node. this packet can pass through any network, including the internet, as it travels from the director to the cluster node.basic properties of lvs-tunan lvs-tun cluster has the following properties:the cluster nodes do not need to be on the same physical network segment as the director.the rip addresses must not be private ip addresses.the director can normally only intercept inbound communication between the client and the cluster nodes.the return packets from the real server to the client must not go through the director. (the default gateway cant be the dip; it must be a router or another machine separate from the director.)the director cannot remap network port numbers.only operating systems that support the ip tunneling protocol11 can be servers inside the cluster. (see the comments in the configure-lvs script included with the lvs distribution to find out which operating systems are known to support this protocol.)we wont use the lvs-tun forwarding method in this book because we want to build a cluster that is reliable enough to run mission-critical applications, and separating the director from the cluster nodes only increases the potential for a catastrophic failure of the cluster. although using geographically dispersed cluster nodes might seem like a shortcut to building a disaster recovery data center, such a configuration doesnt improve the reliability of the cluster, because anything that breaks the connection between the director and the cluster nodes will drop all client connections to the remote cluster nodes. a linux enterprise cluster must be able to share data with all applications running on all cluster nodes (this is the subject of chapter 16). geographically dispersed cluster nodes only decrease the speed and reliability of data sharing.2rfc 1918 reserves the following ip address blocks for private intranets: through 55 through 55 through 55 3without the special lvs martian modification kernel patch applied to the director, the normal lvs-dr director will simply drop reply packets if they try to go back out through the director.4the lvs-dr forwarding method requires this for normal operation. see chapter 13 for more info on lvs-dr clusters5the operating system must be capable of configuring the network interface to avoid replying to arp broadcasts. for more information, see arp broadcasts and the lvs-dr cluster in chapter 136the real servers inside an lvs-dr cluster must be able to accept packets destined for the vip without replying to arp broadcasts for the vip (see chapter 13)7see the load sharing with heartbeatround-robin dns section in chapter 8 for a discussion of round-robin dns8this is unlikely to be a problem in a properly built and properly t