构建Red Hat Enterprise Linux 5.2的高可用性Linux虚拟服务器

需积分: 9 174 浏览量更新于2024-07-24 收藏 992KB PDF 举报

《Virtual_Server_Administration_5.2》是一本专为Red Hat Enterprise Linux（RHEL）5.2设计的实用指南，主要聚焦于Linux Virtual Server (LVS) 的高级管理员手册。LVS 是Linux内的一种负载均衡和集群技术，它通过专用路由和负载均衡技术如PIRANHA实现高度可用性和可扩展性，适用于生产环境中的服务配置。本书详细讲解了如何在RHEL 5.2环境中配置高性能系统和服务，特别关注使用LVS构建和管理集群，以确保服务的稳定性和性能优化。LVS的核心在于它的虚拟服务器（Virtual Server，VS）概念，它将单一的网络服务逻辑上分布在多个物理服务器上，从而提高服务的并发处理能力和可靠性。书中涵盖了以下关键知识点： 1. LVS体系结构：介绍了LVS的基本原理，包括NAT（Network Address Translation）、DR（Direct Routing）、TUN（Tap Interface Network）等不同工作模式，以及它们各自适用的场景和优势。 2. PIRANHA配置：PIRANHA是LVS中用于实现负载均衡和故障切换的工具，读者可以学习如何设置规则、策略和监控，以保证流量的合理分配和系统的高可用性。 3. 高级服务配置：针对具体的生产环境，作者会讲解如何配置数据库、Web服务器（如Apache、Nginx）、邮件服务器等服务，使其与LVS协同工作，并优化性能。 4. 网络安全与监控：书中还涉及了防火墙规则、安全策略、日志管理和性能监控等方面，帮助管理员确保LVS集群的安全运行。 5. 实战案例分析：通过具体的例子，读者可以掌握如何解决实际部署中可能遇到的问题，以及如何根据业务需求调整和优化LVS配置。 6. 版权和许可证：书中的内容受到Open Publication License (OPL) V1.0或更高版本的约束，强调未经版权持有人明确许可，不得擅自修改并分发实质性的文档内容。《Virtual_Server_Administration_5.2》是一本深入浅出的LVS技术指南，不仅适合Linux系统管理员，也对网络架构师和云计算工程师提供宝贵参考，帮助他们更好地理解和应用LVS来提升企业的IT基础设施效率和稳定性。

Figure 1.1. A Basic LVS Configuration

Service requests arriving at the LVS routers are addressed to a virtual IP address, or VIP. This

is a publicly-routable address the administrator of the site associates with a fully-qualified

domain name, such as www.example.com, and is assigned to one or more virtual servers. A

virtual server is a service configured to listen on a specific virtual IP. Refer to Section 6,

“VIRTUAL SERVERS” for more information on configuring a virtual server using the Piranha

Configuration Tool. A VIP address migrates from one LVS router to the other during a failover,

thus maintaining a presence at that IP address (also known as floating IP addresses).

VIP addresses may be aliased to the same device which connects the LVS router to the

Internet. For instance, if eth0 is connected to the Internet, than multiple virtual servers can be

aliased to eth0:1. Alternatively, each virtual server can be associated with a separate device

per service. For example, HTTP traffic can be handled on eth0:1, and FTP traffic can be

handled on eth0:2.

Only one LVS router is active at a time. The role of the active router is to redirect service

requests from virtual IP addresses to the real servers. The redirection is based on one of eight

supported load-balancing algorithms described further in Section 3, “LVS Scheduling Overview”.

Chapter 1. Linux Virtual Server Overview

The active router also dynamically monitors the overall health of the specific services on the real

servers through simple send/expect scripts. To aid in detecting the health of services that

require dynamic data, such as HTTPS or SSL, the administrator can also call external

executables. If a service on a real server malfunctions, the active router stops sending jobs to

that server until it returns to normal operation.

The backup router performs the role of a standby system. Periodically, the LVS routers

exchange heartbeat messages through the primary external public interface and, in a failover

situation, the private interface. Should the backup node fail to receive a heartbeat message

within an expected interval, it initiates a failover and assumes the role of the active router.

During failover, the backup router takes over the VIP addresses serviced by the failed router

using a technique known as ARP spoofing — where the backup LVS router announces itself as

the destination for IP packets addressed to the failed node. When the failed node returns to

active service, the backup node assumes its hot-backup role again.

The simple, two-layered configuration used in Figure 1.1, “A Basic LVS Configuration” is best for

serving data which does not change very frequently — such as static webpages — because the

individual real servers do not automatically sync data between each node.

1.1. Data Replication and Data Sharing Between Real Servers

Since there is no built-in component in LVS to share the same data between the real servers,

the administrator has two basic options:

• Synchronize the data across the real server pool

• Add a third layer to the topology for shared data access

The first option is preferred for servers that do not allow large numbers of users to upload or

change data on the real servers. If the configuration allows large numbers of users to modify

data, such as an e-commerce website, adding a third layer is preferable.

1.1.1. Configuring Real Servers to Synchronize Data

There are many ways an administrator can choose to synchronize data across the pool of real

servers. For instance, shell scripts can be employed so that if a Web engineer updates a page,

the page is posted to all of the servers simultaneously. Also, the system administrator can use

programs such as rsync to replicate changed data across all nodes at a set interval.

However, this type of data synchronization does not optimally function if the configuration is

overloaded with users constantly uploading files or issuing database transactions. For a

configuration with a high load, a three-tier topology is the ideal solution.

2. A Three-Tier LVS Configuration

Figure 1.2, “A Three-Tier LVS Configuration” shows a typical three-tier LVS topology. In this

example, the active LVS router routes the requests from the Internet to the pool of real servers.

Data Replication and Data Sharing Between

available database for transactions. Additionally, using an active-active configuration with Red

Hat Cluster Manager, administrators can configure one high-availability cluster to serve both of

these roles simultaneously.

The third tier in the above example does not have to use Red Hat Cluster Manager, but failing

to use a highly available solution would introduce a critical single point of failure.

3. LVS Scheduling Overview

One of the advantages of using LVS is its ability to perform flexible, IP-level load balancing on

the real server pool. This flexibility is due to the variety of scheduling algorithms an administrator

can choose from when configuring LVS. LVS load balancing is superior to less flexible methods,

such as Round-Robin DNS where the hierarchical nature of DNS and the caching by client

machines can lead to load imbalances. Additionally, the low-level filtering employed by the LVS

router has advantages over application-level request forwarding because balancing loads at the

network packet level causes minimal computational overhead and allows for greater scalability.

Using scheduling, the active router can take into account the real servers' activity and,

optionally, an administrator-assigned weight factor when routing service requests. Using

assigned weights gives arbitrary priorities to individual machines. Using this form of scheduling,

it is possible to create a group of real servers using a variety of hardware and software

combinations and the active router can evenly load each real server.

The scheduling mechanism for LVS is provided by a collection of kernel patches called IP

Virtual Server or IPVS modules. These modules enable layer 4 (L4) transport layer switching,

which is designed to work well with multiple servers on a single IP address.

To track and route packets to the real servers efficiently, IPVS builds an IPVS table in the

kernel. This table is used by the active LVS router to redirect requests from a virtual server

address to and returning from real servers in the pool. The IPVS table is constantly updated by

a utility called ipvsadm — adding and removing cluster members depending on their availability.

3.1. Scheduling Algorithms

The structure that the IPVS table takes depends on the scheduling algorithm that the

administrator chooses for any given virtual server. To allow for maximum flexibility in the types

of services you can cluster and how these services are scheduled, Red Hat Enterprise Linux

provides the following scheduling algorithms listed below. For instructions on how to assign

scheduling algorithms refer to Section 6.1, “The VIRTUAL SERVER Subsection”.

Round-Robin Scheduling

Distributes each request sequentially around the pool of real servers. Using this algorithm,

all the real servers are treated as equals without regard to capacity or load. This scheduling

model resembles round-robin DNS but is more granular due to the fact that it is

network-connection based and not host-based. LVS round-robin scheduling also does not

suffer the imbalances caused by cached DNS queries.

Real Servers

剩余71页未读，继续阅读

小叉子

粉丝: 3
资源: 9

构建Red Hat Enterprise Linux 5.2的高可用性Linux虚拟服务器

lvs Virtual_Server_Administration lvs pdf

rqt_virtual_joystick-melodic-devel.zip

XPEnoboot_DS3615xs_5.2-5565.2.zip

Red_Hat_Enterprise_Linux-5-Virtual_Server_Administration-zh-CN.rar

rhel_5.2_群集管理

sld_virtual_jtag.rar_sld_sld_virtual_jtag_virtual jtag

Virtual-COM-port.zip_STM32F107_Virtual_com_port_virtual Port_vir

virtual_base_class.rar_virtual base cla_virtual base class

SANGFOR_aDesk_V5.2_xubuntu系统虚拟机部署配置指导.pdf

Virtual_serial_driver_sample_virtualcomport_virtualcom_Virtual.S

最新资源