Linux企業(yè)集群計(jì)算機(jī)類(lèi)外文翻譯@中英文翻譯@外文文獻(xiàn)翻譯

摘自 ： Linux 企業(yè)集群 (The Linux Enterprise Cluster) 英文原文 : The Linux Enterprise Cluster Overview This 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 comp uters 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 netwo rk； 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 Conventions In 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) address The IP address the Director uses to offer services to client computers Real IP (RIP) address The IP address used on the cluster nodes Directors IP (DIP) address The IP address the Director uses to connect to the D/RIP network Client computers IP (CIP) address The IP address assigned to a client computer that it uses as a source IP address for requests sent to the cluster The 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 Clusters Now 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-NAT The 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-DR These 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-TUN An 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 clusters 5The 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 13 6The 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 Heartbeat Round-Robin DNS section in Chapter 8 for a discussion of round-robin DNS 8This is unlikely to be a problem in a properly built and properly tested cluster configuration. Well discuss how to build a highly available Director in Chapter 15. 9Assuming the client computers IP address, the VIP and the RIP are all private (RFC 1918) IP addresses 10If your cluster needs to communicate over the Internet, you will likely need to encrypt packets before sending them. This can be accomplished with the IPSec protocol (see the FreeS/WAN project at for details). Building a cluster that uses IPSec is outside the scope of this book. 11Search the Internet for the Linux 2.4 Advanced Routing HOWTO for more information about the IP tunneling protocol. LVS Scheduling Methods Having discussed three ways to forward packets to the nodes inside the cluster, lets look at how to distribute the workload across the cluster nodes. When the Director receives an incoming request from a client computer to access a cluster service on its VIP, it has to decide which cluster node should get the request. The scheduling methods the Director can use to make this decision fall into two basic categories: fixed scheduling and dynamic scheduling. Note When a node needs to be taken out of the cluster for maintenance, you can set its weight to 0 using either a fixed or a dynamic scheduling method. When a cluster nodes weight is 0, no new connections will be assigned to it. Maintenance can be performed after all of the users log out normally at the end of the day. Well discuss cluster maintenance in detail in Chapter 19. Fixed (or Non-Dynamic) Scheduling Methods In the case of fixed, or non-dynamic, scheduling methods, the Director selects the cluster node to use for the inbound request without checking to see how many of the previously assigned connections are active. Here is the current list of fixed scheduling methods: Round-robin (RR) When a new request is received, the Director picks the next server on its list of servers, rotating through them in an endless loop. Weighted round-robin (WRR) You assign each cluster node a weight or ranking, based on how much processing load it can handle. This weight is then used, along with the round-robin technique, to select the next cluster node to be used when a new request is received, regardless of the number of connections that are still active. A server with a weight of 2 will receive twice the number of new connections as a server with a weight of 1. If you change the weight of a server to 0, no new connections will be allowed to the server (but currently active connections will not be dropped). Well look at how LVS uses this weight to balance the incoming workload in the Weighted Least-Connection (WLC) section of this chapter. Destination hashing This method always sends requests for the same IP address to the same server in the cluster. Like the locality-based least-connection (LBLC) scheduling method (which will be discussed shortly), this method is useful when the servers inside the cluster are really cache or proxy servers. Source hashing This method can be used when the Director needs to be sure the reply packets are sent back to the same router or firewall that the requests came from. This scheduling method is normally only used when the Director has more than one physical network connection, so that the Director knows which firewall or router to send the reply packet back through to reach the proper client computer. 中文 翻譯 : Linux 企業(yè)集群 綜述 本章將要介紹的是一款叫做 IP 虛擬服務(wù)器（ IPVS）的集群負(fù)載均衡軟件，它是被合并到 Linux2.4.23 內(nèi)核起的主干內(nèi)核版本的補(bǔ)丁集合，當(dāng)與內(nèi)核路由和數(shù)據(jù)包過(guò)濾功能（第 2 章中討論了）一起使用時(shí)啟用了 IPVS 的內(nèi)核讓你可以將任何運(yùn)行 Linux 的計(jì)算機(jī)變成一個(gè)集群負(fù)載調(diào)度器，啟用 IPVS 的集群負(fù)載調(diào)度器和集群節(jié)點(diǎn)一起叫做一個(gè) Linux 虛擬服務(wù)器（ LVS）。 LVS 集群負(fù)載調(diào)度器接受所 有訪問(wèn)服務(wù)的入站客戶端請(qǐng)求，并確定每個(gè)請(qǐng)求由哪個(gè)集群節(jié)點(diǎn)進(jìn)行應(yīng)答，在本書(shū)中的術(shù)語(yǔ)叫做 LVS Director， Director 以及負(fù)載調(diào)度器，它們指的都是同一個(gè)東西。 在 LVS 集群內(nèi)的節(jié)點(diǎn)叫做真實(shí)服務(wù)器（ real servers），連接到集群請(qǐng)求服務(wù)的計(jì)算機(jī)叫做客戶端計(jì)算機(jī)（ client computers），客戶端計(jì)算機(jī)、 Director和真實(shí)服務(wù)器使用 ip 地址相互通訊，然而，要更容易討論這個(gè)網(wǎng)絡(luò)通訊， LVS社區(qū)達(dá)成了一個(gè)命名規(guī)范描述網(wǎng)絡(luò)會(huì)話中每種基于角色的 ip 地址類(lèi)型，因此在我們考慮選擇哪種 LVS 集群分 擔(dān)工作負(fù)載之前（叫做調(diào)度方法），讓我們先來(lái)看看命名規(guī)范以及它是如何幫助描述 LVS 集群的。 LVS IP 地址命名規(guī)范 在 LVS 集群中，我們不能將網(wǎng)絡(luò)地址簡(jiǎn)單地說(shuō)為“ ip 地址”，相反，我們必須基于節(jié)點(diǎn)在集群內(nèi)的角色來(lái)區(qū)別不同種類(lèi)的 ip 地址，在一個(gè)集群內(nèi)有四種基本的 ip 地址類(lèi)型：虛擬 ip 地址（ VIP）即 Director 用于向客戶端計(jì)算機(jī)提供服務(wù)的 ip 地址；真實(shí) ip 地址（ RIP）即用在集群節(jié)點(diǎn)上的 ip 地址； Director 的ip 地址（ DIP）即 Director 用于連接 D/RIP 網(wǎng)絡(luò)的 ip 地址；客戶端計(jì)算機(jī)的 ip地址 （ CIP）即分配給客戶端計(jì)算機(jī)的 ip 地址，它用作向集群發(fā)送請(qǐng)求的源 ip地址。 虛擬 IP（ VIP）：用于客戶端計(jì)算機(jī)連接由集群提供的服務(wù)的 ip 地址叫做虛擬 ip 地址（ VIP）， VIP 是連接 Director 到常規(guī)公共網(wǎng)絡(luò)的網(wǎng)卡上的 ip 別名或從屬 ip 地址 1。 LVS VIP 很重要，因?yàn)樗强蛻舳擞?jì)算機(jī)連接集群時(shí)要用到的，客戶端計(jì)算機(jī)從它們的 ip 地址向 VIP 地址發(fā)送數(shù)據(jù)包訪問(wèn)集群服務(wù)，然后你告訴客戶端計(jì)算機(jī)使用這個(gè) VIP 地址的服務(wù)名（如 DNS、 DDNS、 WINS、 LDAP 或 NIS），這是客戶端計(jì)算機(jī)要使用集群服務(wù)常 需要知道的唯一名字或地址。（客戶端計(jì)算機(jī)不知道集群內(nèi)剩下的 ip 地址） 單個(gè) Director 可以配有多個(gè) VIP 向客戶端計(jì)算機(jī)提供不同的服務(wù)， VIP 可以是能在因特網(wǎng)上路由的公共 ip 地址，但這不是必須的。那么什么是必須的呢？是客戶端計(jì)算機(jī)能夠訪問(wèn)集群的 VIP。（我們將在后面看到， LVS-NAT 集群可以在集群內(nèi)為節(jié)點(diǎn)使用一個(gè)私有局域網(wǎng) ip 地址，即使 Director 上的 VIP 是一個(gè)公共因特網(wǎng) ip 地址） 真實(shí) IP（ RIP）：在 LVS 術(shù)語(yǔ)中，向外部世界提供服務(wù)的節(jié)點(diǎn)叫做真實(shí)服務(wù)器（本書(shū)中我們提到的術(shù)語(yǔ)集群節(jié)點(diǎn)和真實(shí)服務(wù)器 可相互替換），因此在真實(shí)服務(wù)器上使用的 ip 地址叫做真實(shí) ip 地址（ RIP）。 RIP 地址是分配給連接真實(shí)服務(wù)器到同一網(wǎng)絡(luò)上 Director 的網(wǎng)卡的永久性ip 地址，我叫這個(gè)網(wǎng)絡(luò)為集群網(wǎng)絡(luò)或 Director/真實(shí)服務(wù)器網(wǎng)絡(luò)（ D/RIP 網(wǎng)絡(luò)），Director使用 RIP地址在 D/RIP網(wǎng)絡(luò)上進(jìn)行正常的網(wǎng)絡(luò)通訊，但是只有 Director需要知道如何與這個(gè) ip 地址對(duì)話。 Director 的 IP（ DIP）： Director 的 ip 地址（ DIP）用在連接 Director 到D/RIP 網(wǎng)絡(luò)的網(wǎng)卡上的，在 Director 的 VIP 上 接收訪問(wèn)集群服務(wù)的請(qǐng)求，這些請(qǐng)求通過(guò) DIP 轉(zhuǎn)發(fā)出去抵達(dá)各個(gè)集群節(jié)點(diǎn)，如第 15 章中討論的那樣， DIP 和 VIP可以處于同一塊網(wǎng)卡上。 客戶端計(jì)算機(jī)的 IP（ CIP）：客戶端計(jì)算機(jī)的 ip 地址（ CIP）可能是一個(gè)本地的、與 VIP 在同一網(wǎng)絡(luò)的私有 ip 地址，或者是一個(gè)因特網(wǎng)上的公共 ip 地址。 LVS 集群的種類(lèi) 我們已經(jīng)看到部分用于描述 LVS 集群的 ip地址命名規(guī)范，現(xiàn)在讓我們開(kāi)始檢查 LVS 數(shù)據(jù)包轉(zhuǎn)發(fā)方法。 LVS 集群種類(lèi)通常是通過(guò) LVS Director 中繼到集群節(jié)點(diǎn)的請(qǐng)求的方法來(lái)形容的，目前有三種可用的方法：網(wǎng)絡(luò)地址轉(zhuǎn)換 （ LVS-NAT）、直接路由（ LVS-DR）、IP 隧道（ LVS-TUN）。 盡管在單個(gè) Director 上不止一種轉(zhuǎn)發(fā)方法（轉(zhuǎn)發(fā)方法在每個(gè)節(jié)點(diǎn)上可以選擇），但我將簡(jiǎn)化這個(gè)有關(guān) LVS 集群的討論和描述， Director 同一時(shí)間只會(huì)使用一種轉(zhuǎn)發(fā)方法。 和 Linux企業(yè)集群搭配使用的最佳轉(zhuǎn)發(fā)方法是 LVS-DR（原因稍后會(huì)做解釋?zhuān)?，但?LVS-NAT 集群是最容易建立的。如果你還沒(méi)有建立過(guò) LVS 集群，同時(shí)又想在企業(yè)中使用集群，你可能想使用第 12 章中的指令在一個(gè)實(shí)驗(yàn)環(huán)境中建立一個(gè)小型的 LVS-NAT 作為開(kāi)始，然后學(xué)習(xí)第 13 章中描述的如何將這個(gè)集群轉(zhuǎn)換為L(zhǎng)VS-DR 的方法。 LVS-TUN 集群通常不被用于關(guān)鍵應(yīng)用，本章提及主要是為了保持完整性，不會(huì)詳細(xì)描寫(xiě)它。 網(wǎng)絡(luò)地址轉(zhuǎn)換（ LVS-NAT）：在一個(gè) LVS-NAT 配置中，當(dāng)數(shù)據(jù)包通過(guò)內(nèi)核時(shí)，Director 使用內(nèi)核的功能（來(lái)自內(nèi)核的 Netfilter 代碼）轉(zhuǎn)換網(wǎng)絡(luò) ip 地址和端口。（這叫做網(wǎng)絡(luò)地址轉(zhuǎn)換（ NAT），它在第 2 章中已經(jīng)做過(guò)介紹了） 注意：在第 12 章中我們將會(huì)對(duì) LVS-NAT 的網(wǎng)絡(luò)通訊做更詳細(xì)的檢查。 訪問(wèn)集群服務(wù)的請(qǐng)求是由 Director 在其 VIP 上接收的，然后 Director 轉(zhuǎn)發(fā)這個(gè)請(qǐng)求到在其 RIP 上的集群節(jié)點(diǎn)，集群節(jié)點(diǎn)通過(guò)向 Director 發(fā)回?cái)?shù)據(jù)包進(jìn)行應(yīng)答，因此 Director 要將集群節(jié)點(diǎn)的 RIP 地址轉(zhuǎn)換成它自己的 VIP 地址，這使得對(duì)于在集群外的客戶端計(jì)算機(jī)看起來(lái)好像所有數(shù)據(jù)包都是通過(guò)一個(gè) ip 地址（ VIP）進(jìn)行發(fā)送和接收的。 LVS-NAT 的基本屬性 LVS-NAT 轉(zhuǎn)發(fā)方法有以下幾個(gè)基本屬性：集群節(jié)點(diǎn)需要與 Director 處于同一網(wǎng)絡(luò)（ VLAN 或子網(wǎng)）；集群節(jié)點(diǎn)的 RIP 地址一般要符合 RFC 19182規(guī)則（即它們是私有的、不可路由的 ip 地址，只用于集群內(nèi)部的通訊） ， Director 攔截客戶端計(jì)算機(jī)和真實(shí)服務(wù)器之間的所有通訊（兩個(gè)方向上的數(shù)據(jù)包）。 集群節(jié)點(diǎn)使用 Director 的 DIP 作為它們的默認(rèn)網(wǎng)關(guān)應(yīng)答客戶端計(jì)算機(jī)的請(qǐng)求。 Director 可以重新映射網(wǎng)絡(luò)端口號(hào)，即在 Director VIP 的一個(gè)端口上接收請(qǐng)求，在另一個(gè) RIP 端口上發(fā)送應(yīng)答，任何類(lèi)型的操作系統(tǒng)都可以用在集群內(nèi)的節(jié)點(diǎn)上 單個(gè) Director 可能會(huì)成為集群的瓶頸。在某些情況下，隨著集群節(jié)點(diǎn)數(shù)量的增長(zhǎng)， Director 將會(huì)成為網(wǎng)絡(luò)通訊的瓶頸，因?yàn)樗袘?yīng)答數(shù)據(jù)包都必須通過(guò)Director，一顆 400MHz 的 處理器能夠容納 100Mbps 的連接，因此，在一般情況下，網(wǎng)絡(luò)更可能比 LVS Director 更可能成為瓶頸。 LVS-NAT 集群比 LVS-DR 集群更難以管理，因?yàn)榧汗芾韱T處于集群之外的計(jì)算機(jī)前，受阻于直接對(duì)集群節(jié)點(diǎn)的訪問(wèn)，和其他客戶端非常類(lèi)似，在視圖從集群外部管理集群時(shí)，在 telnet 或 ssh 連接到一個(gè)指定的集群節(jié)點(diǎn)之前，管理員首先必須登陸到 Director，如果集群連接到因特網(wǎng)，客戶端計(jì)算機(jī)使用網(wǎng)頁(yè)瀏覽器連接到集群，管理員登陸到 Director 可能是一個(gè)令人滿意的集群安全特性，因?yàn)楣芾砭W(wǎng)絡(luò)通常只允許內(nèi)部 ip 地址通過(guò) shell 訪問(wèn)集群節(jié)點(diǎn)，但是，在 Linux企業(yè)集群中，集群通常是受防火墻保護(hù)的，你可以更容易從集群之外直接連接到要管理的集群節(jié)點(diǎn)。（我們將在本書(shū)的第四部分看到在 LVS-DR 集群中的集群節(jié)點(diǎn)管理器可以位于集群之外，使用 Mon 和 Ganglia 軟件包遠(yuǎn)程收集關(guān)于集群的診斷信息。） 直接路由（ LVS-DR）：在一個(gè) LVS-DR 配置中， Director 轉(zhuǎn)發(fā)所有的入站請(qǐng)求到集群內(nèi)的節(jié)點(diǎn)，集群節(jié)點(diǎn)直接向客戶端計(jì)算機(jī)發(fā)回應(yīng)答（應(yīng)答不再經(jīng)過(guò)Director） 3。來(lái)自客戶端計(jì)算機(jī)或 CIP 的請(qǐng)求發(fā)送到 Director 的 VIP，然后Director 將請(qǐng)求轉(zhuǎn)發(fā)到使用同一 VIP 目標(biāo) ip 地址的集群節(jié)點(diǎn)或真實(shí)服務(wù)器（我們將在第 13 章中看到 Director 是如何做這件事的），然后集群節(jié)點(diǎn)直接向客戶端計(jì)算機(jī)發(fā)送應(yīng)答數(shù)據(jù)包，這個(gè)應(yīng)答數(shù)據(jù)包使用 VIP 作為它的源 ip 地址，因而客戶端計(jì)算機(jī)被欺騙總是認(rèn)為在與一臺(tái)計(jì)算機(jī)對(duì)話，實(shí)際上它是將數(shù)據(jù)包發(fā)送到一臺(tái)計(jì)算機(jī)而從另一臺(tái)計(jì)算機(jī)接收數(shù)據(jù)包。 LVS-DR 的基本屬性： 下面是使用 LVS-DR 轉(zhuǎn)發(fā)方法的集群基本屬性：集群節(jié)點(diǎn)必須與 Director處于同一網(wǎng)段 4。集群節(jié)點(diǎn)的 RIP 地址不必是私有 ip 地址（即它們不需要符合RFC 1918 規(guī)范）。 Director 攔截客戶端與真實(shí)服務(wù)器之間的入站（不包括出站）通訊。 正常情況下，集群節(jié)點(diǎn)不使用 Director 作為它們的默認(rèn)網(wǎng)關(guān)傳遞發(fā)送到客戶端計(jì)算機(jī)的應(yīng)答數(shù)據(jù)包。 Director 不能重新映射網(wǎng)絡(luò)端口號(hào)大多數(shù)操作系統(tǒng)可以被用于集群內(nèi)部的真實(shí)服務(wù)器上 5。一個(gè) LVS-DR Director 比 LVS-NAT Director 能處理更多的真實(shí)服務(wù)器。 盡管 LVS-DR Director 不能象 LVS-NAT Director 那樣重新映射網(wǎng)絡(luò)端口號(hào)，當(dāng)使用 LVS-DR 作為轉(zhuǎn)發(fā)方法時(shí)只有確認(rèn)的操作系統(tǒng)可以用在真實(shí)服務(wù)器上 6，LVS-DR 是 Linux 企業(yè)集群最佳的轉(zhuǎn)發(fā)方法，因?yàn)樗试S你建立能直接從集群之外訪問(wèn)的集群節(jié)點(diǎn)，雖然在某些情況下這可能會(huì)有安全隱患（影響可以用恰當(dāng)?shù)腣LAN 配置標(biāo)記出來(lái)），它提供額外的優(yōu)點(diǎn)，改善集群的可靠性，可能在剛開(kāi)始時(shí)不是很明顯： 如果 Director 失效，集群節(jié)點(diǎn)變成分散的服務(wù)器，每一個(gè)都有它們自己的ip 地址（內(nèi)部網(wǎng)上的客戶端計(jì)算機(jī)可以使用 LVS-DR 集群節(jié)點(diǎn)的 RIP 直接連接），然后你可能要告訴用戶使用哪個(gè)集群節(jié)點(diǎn) RIP 地址，或使用循環(huán) DNS 分發(fā)各集群節(jié)點(diǎn)的 RIP 地址，直到 Director 恢復(fù)正常 7，換句話說(shuō)，在 Director 出現(xiàn)災(zāi)難故障甚至 LVS 本身出故障時(shí)你都是受到保護(hù)的 8。 要測(cè)試各集群節(jié)點(diǎn)的健康度和測(cè)量它們的性能，可以在處于集群外的集群管理器上使用監(jiān)視工具（本書(shū)第四部分將會(huì)討論如何使用 Mon 和 Ganglia 軟件包進(jìn)行監(jiān)視）。 要快速診斷節(jié)點(diǎn)的健康情況，而不考慮 LVS 或 Director 的健康狀況，當(dāng)出現(xiàn)問(wèn)題時(shí)，你可以直接 telnet、 ping 和 ssh 到任何集群節(jié)點(diǎn)。 在排除故障時(shí)，如果應(yīng)用程序顯示有問(wèn)題的話，你可