计算机类外文文献翻译-linux企业集群

计算机类外文文献翻译-linux企业集群内容摘要：

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 bee distributed servers, each with their own IP address. (Client puters on the internal work, in other words, can connect directly to the LVSDR cluster node using their RIP addresses.) You would then tell users which clusternode RIP address to use, or you could employ a simple roundrobin 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 (we39。 ll 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 tel, ping, and ssh directly to any cluster node when a problem occurs. When troubleshooting what appear to be software application problems, you can tell endusers[9] how to connect to two different cluster nodes directly by IP (RIP) address. You can then have the enduser perform the same task on each node, and you39。 ll know very quickly whether the problem is with the application program or one of the cluster nodes. Note In an LVSDR cluster, packet filtering or firewall rules can be installed on each cluster node for added security. See the LVSHOWTO 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 puters on the trusted work can access the Director and the real servers. IP Tunneling (LVSTUN) IP tunneling can be used to forward packets from one sub or virtual LAN (VLAN) to another sub or VLAN even when the packets must pass through another work or the Inter. Building on the IP tunneling capability that is part of the Linux kernel, the LVSTUN forwarding method allows you to place cluster nodes on a cluster work that is not on the same work segment as the Director. Note We will not use the LVSTUN forwarding method in any recipes in this book, and it is only included here for the sake of pleteness. The LVSTUN configuration enhances the capability of the LVSDR method of packet forwarding by encapsulating inbound requests for cluster services from client puters so that they can be forwarded to cluster nodes that are not on the same physical work segment as the Director. For example, a packet is placed inside another packet so that it can be sent across the Inter (the inner packet bees the data payload of the outer packet). Any server that knows how to separate these packets, no matter where it is on your intra or the Inter, can be a node in the cluster, as shown in Figure 114.[10] LVSTUN work munication The arrow connecting the Director and the cluster node in Figure 114 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 work, including the Inter, as it travels from the Director to the cluster node. Basic Properties of LVSTUN An LVSTUN cluster has the following properties: The cluster nodes do not need to be on the same physical work segment as the Director. The RIP addresses must not be private IP addresses. The Director can normally only intercept inbound munication 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 can39。 t be the DIP。 it must be a router or another machine separate from the Director.) The Director cannot remap work port numbers. Only operating systems that support the IP tunneling protocol[11] can be servers inside the cluster. (See the ments in the configurelvs script included with the LVS distribution to find out which operating systems are known to support this protocol.) We won39。 t use the LVSTUN forwarding method in this book because we want to build a cluster that is reliable enough to run missioncritical 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 doesn39。 t 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. [2]RFC 1918 reserves the following IP address blocks for private intras: through through through [3]Without the special LVS martian modification kernel patch applied to the Director, the normal LVSDR Director will simply drop reply packets if they try to go back out through the Director. [4]The LVSDR forwarding method requires this for normal operation. See Chapter 13 for more info on LVSDR clusters [5]The operating system must be capable of configuring the work interface to avoid replying to ARP broadcasts. For more information, see ARP Broadcasts and the L。