Linux 负载均衡
随着计 算机 技术的 发展 和越来 越广 泛的应 用， 越来越 多的 依赖于 计算 机技 术 的 应用系 统走 进了我 们的 工作和 生活 。在给 我们 带来方 便和 效率的 同时 ，也使 得各 行 各业对 于计 算机技 术的 依赖程 度越 来越高 。尽 管随着 计算 机技术 以日 新月异 的速 度 发展， 单台 计算机 的性 能和可 靠性 越来越 好， 但还是 有许 多现实 的要 求是单 台计 算 机难以达到的。为了满足日益膨胀的需求，计算机应用中引入了集群技术。
本章目标：
学习完本章你将能够 了解集群的优点 理解 LVS 的工作原理 使用 LVS 搭建企业集群服务器
111
Version：1.0
1. 集群技术简介
1.1 为什么要集群
当今计算机技术已进入以网络为中心的计算时期。由于客户/服务器模型的简 单 性、易管理性和易维护性，客户/服务器计算模式在网上被大量采用。在九十年代 中 期，万维网（World Wide Web）的出现以其简单操作方式将图文并茂的网上信息 带 给普通大众，Web 也正在从一种内容发送机制成为一种服务平台，大量的服务和 应 用（如新闻服务、网上银行、电子商务等）都是围绕着 Web 进行。这促进 Internet 用户剧烈增长和 Internet 流量爆炸式地增长。 Internet 的飞速发展给网络带宽和服务器带来巨大的挑战。 从网络技术的发 展来 看，网络带宽的增长远高于处理器速度和内存访问速度的增长，如 100M Ethernet、 ATM、Gigabit Ethernet 等不断地涌现，10Gigabit Ethernet 即将就绪，在主干网上密 集波分复用（DWDM）将成为宽带 IP 的主流技术。所以，我们深信越来越多的瓶 颈 会出现在服务器端。很多研究显示 Gigabit Ethernet 在服务器上很难使得其吞吐率 达 到 1Gb/s 的原因是协议栈（TCP/IP）和操作系统的低效，以及处理器的低效，这 需 要对协议的处理方法、操作系统的调度和 IO 的处理作更深入的研究。 大部分网站都需要提供每天 24 小时、每星期 7 天的服务，对电子商务等网站尤 为突出，任何服务中断和关键性的数据丢失都会造成直接的商业损失。 现在 Web 服务中越来越多地使用 CGI、动态主页等 CPU 密集型应用，这对服 务器的 性能 有较高 要求 。未来 的网 络服务 会提 供更丰 富的 内容、 更好 的交互 性、 更 高的安全性等，需要服务器具有更强的 CPU 和 I/O 处理能力。例如，通过 HTTPS （Secure HTTP）取一个静态页面需要的处理性能比通过 HTTP 的高一个数量级， HTTPS 正在被电子商务站点广为使用。所以，网络流量并不能说明全部问题，要考 虑到应用本身的发展也需要越来越强的处理性能。 因此， 对用 硬件和 软件 方法实 现高 可伸缩 、高 可用网 络服 务的需 求不 断增 长 ， 这种需求可以归结以下几点： 可伸缩性（Scalability） ，当服务的负载增长时，系统能被扩展来满足需求，且不降 低服务质量。 高可用性（Availability） ，尽管部分硬件和软件会发生故障，整个系统的服务必须 是每天 24 小时每星期 7 天可用的。 可管理性（Manageability） ，整个系统可能在物理上很大，但应该容易管理。 价格有效性（Cost-effectiveness） ，整个系统实现是经济的、易支付的。 要解决 上述 几个需 求， 靠单个 的服 务器不 能满 足需求 ，因 此，只 能使 用多 台 服 务器联合工作以达到需求，这就是所谓的集群。
1.2 服务器集群优点
对称多处理（Symmetric Multi-Processor，简称 SMP）是由多个对称的处理器、 和通过总线共享的内存和 I/O 部件所组成的计算机系统。SMP 是一种低并行度的 结 构，是我们通常所说的“紧耦合多处理系统” ，它的可扩展能力有限，但 SMP 的优 点是单一系统映像（Single System Image） ，有共享的内存和 I/O，易编程。 由于 SMP 的可扩展能力有限，SMP 服务器显然不能满足高可伸缩、高可用网 络服务 中的 负载处 理能 力不断 增长 需求。 随着 负载不 断增 长，会 导致 服务器 不断 地 升级。 这种 服务器 升级 有下列 不足 ：一是 升级 过程繁 琐， 机器切 换会 使服务 暂时 中 断，并 造成 原有计 算资 源的浪 费； 二是越 往高 端的服 务器 ，所花 费的 代价越 大； 三 是 SMP 服务器是单一故障点（ Single Point of Failure） ，一旦该服务器或应用软件失 效，会导致整个服务的中断。 通过高 性能 网络或 局域 网互联 的服 务器集 群正 成为实 现高 可伸缩 的、 高可 用 网 络服务的有效结构。这种松耦合结构的服务器集群系统有下列优点： （1）性能 网络服 务的 工作负 载通 常是大 量相 互独立 的任 务，通 过一 组服务 器分 而治 之 ， 可以获得很高的整体性能。 （2）性能/价格比 组成集群系统的 PC 服务器或 RISC 服务器和标准网络设备因为大规模生产降低 成本，价格低，具有最高的性能/价格比。若整体性能随着结点数的增长而接近线 性 增加，该系统的性能/价格比接近于 PC 服务器。所以，这种松耦合结构比紧耦合 的 多处理器系统具有更好的性能/价格比。 （3）可伸缩性 集群系 统中 的结点 数目 可以增 长到 几千个 ，乃 至上万 个， 其伸缩 性远 超过 单 台 超级计算机。 （4）高可用性 在硬件 和软 件上都 有冗 余，通 过检 测软硬 件的 故障， 将故 障屏蔽 ，由 存活 结 点 提供服务，可实现高可用性。
1.3 集群类型
目前的集群类型主要概括为三大类型：高可扩展性集群技术（负载均衡） 、高可 靠性集 群和 高性能 计算 集群。 本章 将讲解 负载 均衡技 术， 高可用 性及 高性能 集群 将 在后面介绍。 高可扩 展性 集群技 术就 是带均 衡策 略（算 法） 的服务 器群 集。负 载均 衡群 集 在
多节点 之间 按照一 定的 策略（ 算法 ）分发 网络 或计算 处理 负载。 负载 均衡建 立在 现 有网络 结构 之上， 它提 供了一 种廉 价有效 的方 法来扩 展服 务器带 宽， 增加吞 吐量 ， 提高数据处理能力，同时又可以避免单点故障。 高可扩展性集群一般的框架结构如图 4-1 所示（以 Web 访问为例，其它应用 类 似） 。后台的多个 Web 服务器上面有相同的 Web 内容，Internet 客户端的访问请求首 先进入一台服务器，由它根据负载均衡策略（算法）合理地分配给某个 Web 服务 器。 每个 Web 服务器有相同的内容做起来不难，所以选择负载均衡策略（算法）是个 关 键问题。下面会专门介绍均衡算法。
图 4-1 负载均 衡的 作用就 像轮 流值日 制度 ，把任 务分 给大家 来完 成，以 免让 一个 人 过 度劳累 。但 是与轮 流值 日制度 不同 的是， 负载 均衡是 一种 动态均 衡， 它通过 一些 工 具实时 地分 析数据 包， 掌握网 络中 的数据 流量 状况， 把任 务理分 配出 去。对 于不 同 的应用环境（如电子商务网站，它的计 算负荷大；再如网络数据库应用，读写频繁， 服务器 的存 储子系 统系 统面临 很大 压力； 再如 视频服 务应 用，数 据传 输量大 ，网 络 接口负担重压。 ，使用的均衡策略(算法)是不同的。 所以均衡策略（算法）也就有 ） 了多种 多样 的形式 ，广 义上的 负载 均衡既 可以 设置专 门的 网关、 负载 均衡器 ，也 可 以通过一些专用软件与协议来实现。在 OSI 七层协议模型中的第二（数据链路层） 、 第三（ 网络 层） 第四 （传输 层） 、 、第七 层（ 应用层 ）都 有相应 的负 载均衡 策略 （算 法） ，在数据链路层上实现负载均衡的原理是根据数据包的目的 MAC 地址选择不同 的路径；在网络层上可利用基于 IP 地址的分配方式将数据流疏通到多个节点；而传 输层和应用层的交换（Switch） ，本身便是一种基于访问流量的控制方式，能够实 现 负载均衡。 不同的集群软件实现的方法都不太相同，下面我们将介绍 Linux 下的负载均衡 集群 LVS（Linux Virtual Server） 。
2. LVS 集群介绍
针对高可伸缩、高可用网络服务的需求，中国的章文嵩博士给出了基于 IP 层 和 基于内容请求分发的负载平衡调度解决方法，并在 Linux 内核中实现了这些方法 ， 将一组服务器构成一个实现可伸缩的、高可用网络服务的虚拟服务器。 虚拟服务器的体系结构如图 4-2 所示，一组服务器通过高速的局域网或者地 理 分布的广域网相互连接，在它们的前端有一个负载调度器（Load Balancer） 。负载 调 度器能 无缝 地将网 络请 求调度 到真 实服务 器上 ，从而 使得 服务器 集群 的结构 对客 户 是透明 的， 客户访 问集 群系统 提供 的网络 服务 就像访 问一 台高性 能、 高可用 的服 务 器一样 。客 户程序 不受 服务器 集群 的影响 不需 作任何 修改 。系统 的伸 缩性通 过在 服 务机群 中透 明地加 入和 删除一 个节 点来达 到， 通过检 测节 点或服 务进 程故障 和正 确 地重置系统达到高可用性。由于该负载调度技术是在 Linux 内核中实现的，因此 称 之为 Linux 虚拟服务器（Linux Virtual Server） 。
图 4-2 目前，LVS 项目已提供了一个实现可伸缩网络服务的 Linux Virtual Server 框架， 如图 4-3 所示。在 LVS 框架中，提供了含有三种 IP 负载均衡技术的 IP 虚拟服务器 软件 IPVS、基于内容请求分发的内核 Layer-7 交换机 KTCPVS 和集群管理软件。可 以利用 LVS 框架实现高可伸缩的、高可用的 Web、Cache、Mail 和 Media 等网络服 务；在 此基 础上， 可以 开发支 持庞 大用户 数的 、高可 伸缩 的、高 可用 的电子 商务 应 用。
图 4-3
2.1 IP 虚拟服务器软件 IPVS
在调度器的实现技术中，IP 负载均衡技术是效率最高的。在已有的 IP 负载均衡 技术中有通过网络地址转换（Network Address Translation）将一组服务器构成一 个 高 性 能 的 、 高 可 用 的 虚 拟 服 务 器 ， 我 们 称 之 为 VS/NAT 技 术 （ Virtual Server via Network Address Translation） ，大多数商品化的 IP 负载均衡调度器产品都是使用此 方法，如 Cisco 的 LocalDirector、F5 的 Big/IP 和 Alteon 的 ACEDirector。在分析 VS/NAT 的缺点和网络服务的非对称性的基础上，我们提出通过 IP 隧道实现虚 拟服 务器的方法 VS/TUN （Virtual Server via IP Tunneling） ，和通过直接路由实现虚拟服 务器的方法 VS/DR（Virtual Server via Direct Routing） ，它们可以极大地提高系统 的 伸缩性。所以，IPVS 软件实现了这三种 IP 负载均衡技术，它们的大致原理如下（稍 后会有配置实例） ： （1）Virtual Server via Network Address Translation（ VS/NAT） 通过网 络地 址转换 ，调 度器重 写请 求报文 的目 标地址 ，根 据预设 的调 度算 法 ， 将请求 分派 给后端 的真 实服务 器； 真实服 务器 的响应 报文 通过调 度器 时，报 文的 源 地址被重写，再返回给客户，完成整个负载调度过程。 （2）Virtual Server via IP Tunneling（VS/TUN） 采用 NAT 技术时，由于请求和响应报文都必须经过调度器地址重写，当客户 请 求越来 越多 时，调 度器 的处理 能力 将成为 瓶颈 。为了 解决 这个问 题， 调度器 把请 求 报文通过 IP 隧道转发至真实服务器，而真实服务器将响应直接返回给客户，所 以调 度器只处理请求报文。由于一般网络服务应答比请求报文大许多，采用 VS/TUN 技 术后，集群系统的最大吞吐量可以提高 10 倍。
（3）Virtual Server via Direct Routing（VS/DR） VS/DR 通过改写请求报文的 MAC 地址，将请求发送到真实服务器，而真实服 务器将响应直接返回给客户。同 VS/TUN 技术一样，VS/DR 技术可极大地提高集群 系统的伸缩性。这种方法没有 IP 隧道的开销，对集群中的真实服务器也没有必 须支 持 IP 隧道协议的要求，但是要求调度器与真实服务器都有一块网卡连在同一物理网 段上。 针对不同的网络服务需求和服务器配置，IPVS 调度器实现了如下八种负载调 度 算法： （1）轮叫 （Round Robin） 简写：RR。调度器通过“轮叫”调度算法将外部请求按顺序轮流分配到集群 中 的真实 服务 器上， 它均 等地对 待每 一台服 务器 ，而不 管服 务器上 实际 的连接 数和 系 统负载。 （2）加权 轮叫（ Weighted Round Robin） 简写：WRR。调度器通过“加权轮叫”调度算法根据真实服务器的不同处理能 力来调 度访 问请求 。这 样可以 保证 处理能 力强 的服务 器处 理更多 的访 问流量 。调 度 器可以自动问询真实服务器的负载情况，并动态地调整其权值。 （3）最少 链接（Least Connections） 简写：LC。调度器通过“最少连接”调度算法动态地将网络请求调度到已建立 的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用" 最小连接"调度算法可以较好地均衡负载。 （4）加权 最少链接 （ Weighted Least Connections） 简写：WLC。在集群系统中的服务器性能差异较大的情况下，调度器采用“ 加 权最少 链接 ”调度 算法 优化负 载均 衡性能 ，具 有较高 权值 的服务 器将 承受较 大比 例 的活动 连接 负载。 调度 器可以 自动 问询真 实服 务器的 负载 情况， 并动 态地调 整其 权 值。 （5）基于 局部性的 最 少链接（Locality-Based Least Connections） 简写：LBLC。 “基于局部性的最少链接”调度算法是针对目标 IP 地址的负 载均 衡，目前主要用于 Cache 集群系统。该算法根据请求的目标 IP 地址找出该目标 IP 地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器； 若服务 器不 存在， 或者 该服务 器超 载且有 服务 器处于 一半 的工作 负载 ，则用 “最 少 链接”的原则选出一个可用的服务器，将请求发送到该服务器。 （ 6） 带 复 制 的 基 于 局 部 性 最 少 链 接 （Locality-Based Least Connections with Replication） 简写：LBLCR。 “带复制的基于局部性最少链接”调度算法也是针对目标 IP 地
址的负载均衡，目前主要用于 Cache 集群系统。它与 LBLC 算法的不同之处是它要 维护从一个目标 IP 地址到一组服务器的映射，而 LBLC 算法维护从一个目标 IP 地 址到一台服务器的映射。该算法根据请求的目标 IP 地址找出该目标 IP 地址对应的 服 务 器 组 ， 按 "最 小 连 接 "原 则 从 服 务 器 组 中 选 出 一 台 服 务 器 ， 若 服 务 器 没 有 超 载 ， 将 请 求 发 送 到 该 服 务 器 ， 若 服 务 器 超 载 ； 则 按 "最 小 连 接 "原 则 从 这 个 集 群 中 选 出 一 台服务 器， 将该服 务器 加入到 服务 器组中 ，将 请求发 送到 该服务 器。 同时， 当该 服 务器组 有一 段时间 没有 被修改 ，将 最忙的 服务 器从服 务器 组中删 除， 以降低 复制 的 程度。 （7）目标 地址散列 （ Destination Hashing） 简写： “ 目标地址散列” DH。 调度算法根据请求的目标 IP 地址， 作为散列键 （Hash Key） 从 静 态 分 配 的 散 列 表 找 出 对 应 的 服 务 器 ， 若 该 服 务 器 是 可 用 的 且 未 超 载 ， 将 请求发送到该服务器，否则返回空。 （8）源地 址散列（ Source Hashing） 简写：SH。 “源地址散列”调度算法根据请求的源 IP 地址，作为散列键（Hash Key） 从 静 态 分 配 的 散 列 表 找 出 对 应 的 服 务 器 ， 若 该 服 务 器 是 可 用 的 且 未 超 载 ， 将 请求发送到该服务器，否则返回空。
2.2 内核 Layer-7 交换机 KTCPVS
在基于 IP 负载调度技术中，当一个 TCP 连接的初始 SYN 报文到达时，调度器 就选择一台服务器，将报文转发给它。此后通过查发报文的 IP 和 TCP 报文头地址， 保证此连接的后继报文被转发到该服务器。这样，IPVS 无法检查到请求的内容再 选 择服务 器， 这就要 求后 端服务 器组 提供相 同的 服务， 不管 请求被 发送 到哪一 台服 务 器， 返回结果都是一样的。 但是， 在有些应用中后端服务器功能不一， 有的提供 HTML 文 档 ， 有 的 提 供 图 片 ， 有 的 提 供 CGI， 这 就 需 要 基 于 内 容 的 调 度 (Content-Based Scheduling)。 由于用户空间 TCP Gateway 的开销太大，LVS 提出在操作系统的内核中实现 Layer-7 交换方法，来避免用户空间与核心空间的切换和内存复制的开销。在 Linux 操作系统的内核中，LVS 实现了 Layer-7 交换，称之为 KTCPVS（Kernel TCP Virtual Server） 。目前，KTCPVS 已经能对 HTTP 请求进行基于内容的调度，但它还不很成 熟，在其调度算法和各种协议的功能支持等方面，有大量的工作需要做。
3. LVS 集群的体系结构
前面介绍了 LVS 提供的功能，那么，在具体应用中，应该如何规划我们的服务
器呢？下面介绍几种常用的模型。
3.1 LVS 集群的通用体系结构
LVS 集群采用 IP 负载均衡技术和基于内容请求分发技术。 调度器具有很好 的吞 吐率， 将请 求均衡 地转 移到不 同的 服务器 上执 行，且 调度 器自动 屏蔽 掉服务 器的 故 障，从 而将 一组服 务器 构成一 个高 性能的 、高 可用的 虚拟 服务器 。整 个服务 器集 群 的结构对客户是透明的，而且无需修改客户端和服务器端的程序。 为此， 在设 计时需 要考 虑系统 的透 明性、 可伸 缩性、 高可 用性和 易管 理性 。 一 般来说，LVS 集群采用三层结构，其体系结构如图 4-4 所示，
用户
图形监控软件
互联网/企业网 负载均衡器 服务器1
心跳线连接
IP
服务器2
备份
服务器n
图 4-4 三层主要组成部分为： 负载调度 器（load balancer） ，它是整个集群对外面的前端机，负责将客户的请 求发送到一组服务器上执行，而客户认为服务是来自一个 IP 地址（我们可称之为 虚 拟 IP 地址）上的。
服 务 器 池 （ server pool） 是 一 组 真 正 执 行 客 户 请 求 的 服 务 器 ， 执 行 的 服 务 有 ， WEB、MAIL、FTP 和 DNS 等。 共 享 存 储 （shared storage） ，它为 服务器池提 供一个共享 的存储区， 这样很容 易使得服务器池拥有相同的内容，提供相同的服务。
3.2 可伸缩 Web 服务集群
基于 LVS 的 Web 集群的体系结构如图 4-5 所示：第一层是负载调度器，一般采 用 IP 负载均衡技术，可以使得整个系统有较高的吞吐率；第二层是 Web 服务器池 ， 在每个结点上可以分别运行 HTTP 服务或 HTTPS 服务、或者两者都运行；第三层是 共享存 储， 它可以 是数 据库， 可以 是网络 文件 系统或 分布 式文件 系统 ，或者 是三 者 的混合。集群中各结点是通过高速网络相连接的。
Responses Web服务运行在每个服务器上，动态数据 存储在数据库中，静态数据存储在网络文 件系统或分布式文件系统中
用户
管理员
互联网/企业网 负载均衡器 服务器1 Requests 心跳线连接
IP
服务器2
备份 可扩展的WEB集群
服务器n
图 4-5 对于动态页面（如 PHP、JSP 和 CGI 等） ，需要访问的动态数据一般存储在数 据 库服务器中。数据库服务运行在独立的服务器上，为所有 Web 服务器共享。无论 同 一 Web 服务器上多个动态页面访问同一数据， 还是不同 Web 服务器上多个动态页 面
访问同 一数 据，数 据库 服务器 有锁 机制使 得这 些访问 有序 地进行 ，从 而保证 数据 的 一致性。 对于静态的页面和文件（如 HTML 文档和图片等） ，可以存储在网络文件 系统 或者分 布式 文件系 统中 。至于 选择 哪一种 ，看 系统的 规模 和需求 而定 。通过 共享 的 网络 文 件系 统或 者 分布 式文 件 系统 ， Webmaster 可 以看 到 统一 的 文档 存储 空 间， 维 护和更新页面比较方便，对共享存储中页面的修改对所有的服务器都有效。 在这种 结构 下，当 所有 服务器 结点 超载时 ，管 理员可 以很 快地加 入新 的服 务 器 结点来处理请求，而无需将 Web 文档等复制到结点的本地硬盘上。 有些 Web 服务可能用到 HTTP Cookie，它是将数据存储在客户的浏览器来追踪 和标识客户的机制。使用 HTTP Cookie 后，来同一客户的不同连接存在相关性，这 些连接必须被发送到同一 Web 服务器。一些 Web 服务使用安全的 HTTPS 协议，它 是 HTTP 协议加 SSL（Secure Socket Layer）协议。另有些 Web 服务可能使用安全 的 HTTPS 协议，它是 HTTP 协议加 SSL 协议。当客户访问 HTTPS 服务（HTTPS 的 缺省端口为 443）时，会先建立一个 SSL 连接，来交换对称公钥加密的证书并协 商 一个 SSL Key，来加密以后的会话。在 SSL Key 的生命周期内，后续的所有 HTTPS 连接都使用这个 SSL Key，所以同一客户的不同 HTTPS 连接也存在相关性。针对这 些需要，IPVS 调度器提供了持久服务的功能，它可以使得在设定的时间内，来 自同 一 IP 地址的不同连接会被发送到集群中同一个服务器结点，可以很好地解决客户连 接的相关性问题。
3.3 媒体服务集群
基于 LVS 的媒体集群的体系结构与 WEB 服务集群相同如图 4-5 所示：第一层 是负载调度器，一般采用 IP 负载均衡技术，可以使得整个系统有较高的吞吐率；第 二层是 Web 服务器池， 在每个结点上可以运行相应的媒体服务； 第三层是共享存储， 通过网络文件系统/分布式文件系统存储媒体节目。集群中各结点是通过高速网络 相 连接。 在媒体服务集群中，IPVS 负载调度器一般使用直接路由方法（即 VS/DR 方法） 来架构 媒体 集群系 统。 调度器 将媒 体服务 请求 较均衡 地分 发到各 个服 务器上 ，而 媒 体服务 器将 响应数 据直 接返回 给客 户，这 样可 以使得 整个 媒体集 群系 统具有 很好 的 伸缩性。 媒 体 服 务 器 可 以 运 行 各 种 媒 体 服 务 软 件 。 目 前 ， LVS 集 群 对 于 Real Media、 Windows Media 和 Apple Quicktime 媒体服务都有很好的支持，都有真实的系统在运 行 。 一 般 来 说 ， 流 媒 体 服 务 都 会 使 用 一 个 TCP 连 接 （ 如 RTSP 协 议 ： Real-Time Streaming Protocol）进行带宽的协商和流速的控制，通过 UDP 将流数据返回客户 。 这里， IPVS 调度器提供功能将 TCP 和 UDP 集中考虑， 保证来自同一客户的媒体 TCP 和 UDP 连接会被转发到集群中同一台媒体服务器，使得媒体服务准确无误地进 行。
共享存 储是 媒体集 群系 统中最 关键 的问题 ，因 为媒体 文件 往往非 常大 （一 部 片 子需要几百兆到几千兆的存储空间） ，这对存储的容量和读的速度有较高的要求。对 于规模较小的媒体集群系统，例如有 3 至 6 个媒体服务器结点，存储系统可以考 虑 用带千兆网卡的 Linux 服务器，使用软件 RAID 和日志型文件系统，再运行内核 的 NFS 服务，会有不错的效果。对于规模较大的媒体集群系统，最好选择对文件分 段 （ File Stripping） 存 储 和 文 件 缓 存 有 较 好 支 持 的 分 布 式 文 件 系 统 ； 媒 体 文 件 分 段 存 储在分 布式 文件系 统的 多个存 储结 点上， 可以 提高文 件系 统的性 能和 存储结 点间 的 负载均衡；媒体文件在媒体服务器上自动地被缓存，可提高文件的访问速度。否 则， 可以考 虑自 己在媒 体服 务器上 开发 相应的 工具 ，如缓 存工 具能定 时地 统计出 最近 的 热点媒 体文 件，将 热点 文件复 制到 本地硬 盘上 ，并替 换缓 存中的 非热 点文件 ，最 后 通知其 他媒 体服务 器结 点它所 缓存 的媒体 文件 以及负 载情 况；在 媒体 服务器 上有 应 用层调 度工 具，它 收到 客户的 媒体 服务请 求， 若所请 求的 媒体文 件缓 存在本 地硬 盘 上，则 直接 转给本 地媒 体服务 进程 服务， 否则 先考虑 该文 件是否 被其 他媒体 服务 器 缓存； 如该 文件被 其他 服务器 缓存 并且该 服务 器不忙 ，则 将请求 转给 该服务 器上 的 媒体服 务进 程处理 ，否 则直接 转给 本地媒 体服 务进程 ，从 后端的 共享 存储中 读出 媒 体文件。 共享存 储的 好处是 媒体 文件的 管理 人员看 到统 一的存 储空 间，使 得媒 体文 件 维 护工作 比较 方便。 当客 户访问 不断 增加使 得整 个系统 超载 时，管 理员 可以很 快地 加 入新的媒体服务器结点来处理请求。
3.4 Cache 服务器集群
有效的网络 Cache 系统可以大大地减少网络流量、降低响应延时以及服务器的 负载。但是，若 Cache 服务器超载而不能及时地处理请求，反而会增加响应延时 。 所以，Cache 服务的 可 伸缩性 很重 要，当 系统 负载不 断增 长时， 整个 系统能 被扩 展 来提高 Cache 服务的处理能力。尤其，在主干网上的 Cache 服务可能需要几个 Gbps 的吞吐率，单台服务器远不能达到这个吞吐率。可见，通过 PC 服务器集群实现 可 伸缩 Cache 服务是很有效的方法，也是性能价格比最高的方法。 基于 LVS 的 Cache 集群的体系结构如图 4-6 所示：第一层是负载调度器， 一般 采用 IP 负载均衡技术，可以使得整个系统有较高的吞吐率；第二层是 Cache 服务器 池，一般 Cache 服务器放置在接近主干 Internet 连接处，它们可以分布在不同的 网 络中。调度器可以有多个，放在离客户接近的地方。 特别注意的是 Cache 服务器不 需要共享存储，所有数据存储在本地磁盘。 IPVS 负载调度器一般使用 IP 隧道方法（即 VS/TUN 方法，将在以后文章中详 细叙述） ，来架构 Cache 集群系统，因为 Cache 服务器可能被放置不同的地方（例如 在接近主干 Internet 连接处） ，而调度器与 Cache 服务器池可能不在同一个物理网络 中。采用 VS/TUN 方法，调度器只调度 Web Cache 请求，而 Cache 服务器将响应数 据直接 返回 给客户 。在 请求对 象不 能在本 地命 中的情 况下 ，Cache 服务器要 向 源 服 务器发请求，将结果取回，最后将结果返回给客户；若采用 NAT 技术的商品化 调度
器，需要四次进出调度器，完成这个请求。而用 VS/TUN 方法（或者 VS/DR 方法） ， 调度器只调度一次请求，其他三次都由 Cache 服务器直接访问 Internet 完成。所以， 这种方法对 Cache 集群系统特别有效。 Cache 服务 器采 用本 地 硬盘 来存 储 可缓 存的 对 象， 因为 存 储可 缓存 的 对象 是写 操作，且占有一定的比例，通过本地硬盘可以提高 I/O 的访问速度。Cache 服务器间 有专用的多播通道（Multicast Channel） ，通过 ICP 协议（Internet Cache Protocol） 来交互信息。 当一台 Cache 服务器在本地硬盘中未命中当前请求时， 它可以通过 ICP 查询其他 Cache 服务器是否有请求对象的副本，若存在，则从邻近的 Cache 服务器 取该对象的副本，这样可以进一步提高 Cache 服务的命中率。
Responses
用户
Cache服务器之间通过多播通讯， 并基于ICP协议互相协调工作 多播通道
互联网/企业网 负载均衡器 Requests
IP隧道 IP
服务器1
IP
服务器2
IP
备份 Cache服务集群
服务器n
图 4-6
3.5 邮件服务集群
随着 Internet 用户不断增长，很多 ISP 面临他们邮件服务器超载的问题。当邮件 服务器不能容纳更多的用户帐号时，有些 ISP 买更高档的服务器来代替原有的， 将 原有服 务器 的信息 （如 用户邮 件） 迁移到 新服 务器是 很繁 琐的工 作， 会造成 服务 的 中断；有些 ISP 设置新的服务器和新的邮件域名，新的邮件用户放置在新的服务器 上 ， 如 上 海 电 信 现 在 用 不 同 的 邮 件 服 务 器 https://www.doczj.com/doc/fe10193089.html,、 https://www.doczj.com/doc/fe10193089.html, 到
https://www.doczj.com/doc/fe10193089.html, 放置用户的邮件帐号，这样静态地将用户分割到不同的服务器上， 会造成 邮件 服务器 负载 不平衡 ，系 统的资 源利 用率低 ，对 用户来 说邮 件的地 址比 较 难记。 可以利用 LVS 框架实现高可伸缩、高可用的邮件服务系统。它的体系结构如图 4-7 所示：在前端是一个采用 IP 负载均衡技术的负载调度器；第二层是服务器 池， 有 LDAP（Light-weight Directory Access Protocol）服务器和一组邮件服务器。第三 层是数 据存 储，通 过分 布式文 件系 统来存 储用 户的邮 件。 集群中 各结 点是通 过高 速 网络相连接。
Responses
用户
互联网/企业网
LDAP 服务 负载均衡器 服务器1
Requests 心跳线连接
IP
服务器2
用户信息存储在LDAP服务 器，邮件存储在分布式文件 系统，SMTP、POP3、IMAP 通过负载均衡器转发服务 备份
服务器n
图 4-7 用户的信息如用户名、口令、主目录和邮件容量限额等存储在 LDAP 服务器 中， 可以通过 HTTPS 让管理员进行用户管理。在各个邮件服务器上运行 SMTP（Simple Mail Transfer Protocol） 、POP3（Post Office Protocol version 3） 、IMAP4（Internet Message Access Protocol version 4）和 HTTP/HTTPS 服务。SMTP 接受和转发用户的 邮件， SMTP 服务进程查询 LDAP 服务器获得用户信息， 再存储邮件。 POP3 和 IMAP4 通过 LDAP 服务器获得用户信息，口令验证后，处理用户的邮件访问请求。这里 ， 需要有机制避免不同服务器上的 SMTP、POP3 和 IMAP4 服务进程对用户邮件的读 写冲突。HTTP/HTTPS 服务是让用户通过浏览器可以访问邮件。
IPVS 调度器将 SMTP、POP3、IMAP4 和 HTTP/HTTPS 请求流负载较均衡地分 发到各 邮件 服务器 上， 从上面 各服 务的处 理流 程来看 ，不 管请求 被发 送到哪 一台 邮 件服务器处理，其结果是一样的。这里，将 SMTP、POP3、IMAP4 和 HTTP/HTTPS 运行在各个邮件服务器上进行集中调度，有利于提高整个系统的资源利用率。 系统中可能的瓶颈是 LDAP 服务器，对 LDAP 服务中 B+树的参数进行优化，再 结合高 端的 服务器 ，可 以获得 较高 的性能 。若 分布式 文件 系统没 有多 个存储 结点 间 的负载均衡机制，则需要相应的邮件迁移机制来避免邮件访问的倾斜。 这样， 这个 集群系 统对 用户来 说就 像一个 高性 能、高 可靠 的邮件 服务 器。 当 邮 件用户 不断 增长时 ，只 要在集 群中 增加服 务器 结点和 存储 结点。 用户 信息的 集中 存 储使得用户管理变得容易，且集群系统有利于提高资源利用率。
4. 基于 IP 负载均衡的配置实例
在网络服务中，一端是客户程序，另一端是服务程序，在中间可能有代理程 序。 由此看 来， 可以在 不同 的层次 上实 现多台 服务 器的负 载均 衡。用 集群 解决网 络服 务 性能问题的现有方法主要分为以下四类。
4.1 基于 RR-DNS 的解决方法
RR-DNS（Round-Robin Domain Name System）是利用 DNS 的解析机制来实现 负载均衡的一种集群策略。 有一组 WEB 服务器，他们通过分布式文件系统 AFS(Andrew File System)来共 享所有的 HTML 文档。这组服务器拥有相同的域名（如 https://www.doczj.com/doc/fe10193089.html,） ，当用户 按照这个域名访问时, RR-DNS 服务器会把域名轮流解析到这组服务器的不同 IP 地 址，从而将访问负载分到各台服务器上。
图 4-8
如图 4-8 所示，202.127.124.254 为 https://www.doczj.com/doc/fe10193089.html, 的 DNS 服务器，202.127.124.109 和 202.127.124.109 是 Web 服务器，配置 DNS 使客户端在访问 Web 服务器时自动进 行负载均衡。 配置步骤 ： （1） 配置 DNS 服务器， DNS 服务器的区域文件数据库中， https://www.doczj.com/doc/fe10193089.html, 在 对 的解析如下： www www 300 300 IN A IN A 202.127.124.110 202.127.124.109
其中的 300 是 TTL 值，即该解析结果在客户端最多只能缓存 5 分钟。 （2）测试 分别配置 202.127.124.110 和 202.127.124.110 的 Web 服务， 在两个服务器的 Web 主目录下存放不同内容的主页。 分别在两台客户机上访问 https://www.doczj.com/doc/fe10193089.html,/ ，如果两台客户机上的网页 内 容不同，说明 DNS 负载配置成功。 （3）分别配置两个 Web 服务器，使两个 Web 服务器的 ServerName 相同，并且 使它们的主目录指向相同的站点内容。 （可以使用 NFS 等共享存储方式）
这种方法（RR-DNS）带来几个问题。第一，域名服务器是一个分布式系统 ，是 按照一 定的 层次结 构组 织的。 当用 户就域 名解 析请求 提交 给本地 的域 名服务 器， 它 会因不能直接解析而向上一级域名服务器提交， 上一级域名服务器再依次向上提 交， 直到 RR-DNS 域名服器把这个域名解析到其中一台服务器的 IP 地址。可见，从用 户 到 RR-DNS 间存在多台域名服器，而它们都会缓冲已解析的名字到 IP 地址的映射, 这会导致该域名服器组下所有用户都会访问同一 WEB 服务器，出现不同 WEB 服务 器间严重的负载不平衡。为了保证在域名服务器中域名到 IP 地址的映射不被长久缓 冲，RR-DNS 在域名到 IP 地址的映射上设置一个 TTL(Time To Live)值，过了这一段 时间， 域名 服务器 将这 个映射 从缓 冲中淘 汰。 当用户 请求 ，它会 再向 上一级 域名 服 器提交请求并进行重新影射。这就涉及到如何设置这个 TTL 值，若这个值太大，在 这个 TTL 期间，很多请求会被映射到同一台 WEB 服务器上，同样会导致严重的负 载不平衡。若这个值太小，例如是０，会导致本地域名服务器频繁地向 RR-DNS 提 交请求，增加了域名解析的网络流量，同样会使 RR-DNS 服务器成为系统中一个 新 的瓶颈。 第二，用户机器会缓冲从名字到 IP 地址的映射，而不受 TTL 值的影响，用户 的访问请求会被送到同一台 WEB 服务器上。由于用户访问请求的突发性和访问 方 式不同 ，例 如有的 人访 问一下 就离 开了， 而有 的人访 问可 长达几 个小 时，所 以各 台 服务器间的负载仍存在倾斜（Skew）而不能控制。假设用户在每个会话中平均请 求 数为 20，负载最大的服务器获得的请求数额高于各服务器平均请求数的平均比率 超
过百分之三十。也就是说，当 TTL 值为 0 时，因为用户访问的突发性也会存在着较 严重的负载不平衡。 第三， 系统 的可靠 性和 可维护 性差 。若一 台服 务器失 效， 会导致 将域 名解 析 到 该服务器的用户看到服务中断，即使用户按 “Reload”按钮，也无济于事。系统管 理员也 不能 随时地 将一 台服务 器切 出服务 进行 系统维 护， 如进行 操作 系统和 应用 软 件升级，这需要修改 RR-DNS 服务器中的 IP 地址列表，把该服务器的 IP 地址从中 划掉， 然后 等上几 天或 者更长 的时 间，等 所有 域名服 器将 该域名 到这 台服务 器的 映 射淘汰，和所有映射到这台服务器的客户机不再使用该站点为止。 基于上述三个原因，现在这种方式已经很少用了。
4.2 通过 NAT 实现虚拟服务器（VS/NAT）
由于 IPv4 中 IP 地址空间的日益紧张和安全方面的原因，很多网络使用保留 IP 地址（10.0.0.0/255.0.0.0、 172.16.0.0/255.128.0.0 和 192.168.0.0/255.255.0.0） 。这些 地址不在 Internet 上使用，而是专门为内部网络预留的。当内部网络中的主机要 访 问 Internet 或 被 Internet 访 问 时 ， 就 需 要 采 用 网 络 地 址 转 换 （ Network Address Translation, 以下简称 NAT） ，将内部地址转化为 Internets 上可用的外部地址。NAT 的工作 原理 是报文 头（ 目标地 址、 源地址 和端 口等） 被正 确改写 后， 客户相 信它 们 连接一个 IP 地址，而不同 IP 地址的服务器组也认为它们是与客户直接相连的。由 此，可以用 NAT 方法将不同 IP 地址的并行网络服务变成在一个 IP 地址上的一个虚 拟服务。 下面以一个实例来说明基于 NAT 的集群配置。如图 4-9 所示是公司配置基 于 NAT 集群的网络拓扑。
图 4-9 具体配置 步 骤： 1.下载软件：
202.127.124.110
192.168.10.254
(1)、内核源代码：需要 2.4.24 以后版本的内核源代码。下载地址为： https://www.doczj.com/doc/fe10193089.html,。 本案例中下载的内核源代码为：linux-2.6.18.tar.bz2。 (2)、用户配置工具 ipvsadm，下载地址： https://www.doczj.com/doc/fe10193089.html,/software/ipvs.html。 在下载时注意您的内核版本，下载对应的配置工具。 本案例下载的是： https://www.doczj.com/doc/fe10193089.html,/software/kernel-2.6/ipvsadm-1.24.tar.gz
2.安装软件： 在 director( 控 制 器 ， 202.127.124.110) 上 安 装 支 持 LVS 的 内 核 和 配 置 工 具 ipvsadm。 (1)、在内核配置时以下选项必须选： Networking options <*> Packet socket [*] TCP/IP networking [*] IP: advanced router ---> ---> ---> [*] Network packet filtering (replaces ipchains) ---> Core Netfilter Configuration <*> Netfilter netlink interface IP: Netfilter Configuration <*> Connection tracking (required for masq/NAT) IP: Virtual Server Configuration (12)
(2)、编译和安装内核 分别执行: make bzImage;make modules;make modules_install；然后编辑启动配 置文件，重新启动系统，在启动时选择新的内核。 (3)、编译和安装 ipvsadm ln -s /usr/src/linux-2.6.18 /usr/src/linux tar -zxvf ipvsadm-1.24.tar.gz cd ipvsadm-1.24 make all make install 然后运行：ipvsadm --version 命令，应该有下面的内容输出： ipvsadm v1.24 2005/12/10 (compiled with popt and IPVS v1.2.0)
3. 配置 LVS (1)、在 202.127.124.110 上，启用路由转发功能： echo "1" >/proc/sys/net/ipv4/ip_forward 清除 ipvsadm 表： /sbin/ipvsadm -C 使用 ipvsadm 安装 LVS 服务 /sbin/ipvsadm -A -t 202.127.124.110:80 -s rr 增加第一台 realserver： /sbin/ipvsadm -a -t 202.127.124.110:80 -r 192.168.10.1:80 -m -w 1 增加第二台 realserver： /sbin/ipvsadm -a -t 202.127.124.110:80 -r 192.168.10.2:80 -m -w 1
(2)、realserver 配置 在 192.168.10.1(realserver1)和 192.168.10.2(realserver2)上 分别将 其网 关设置 为 192.168.10.254，并分别启动 apache 服务。 在客户端使用浏览器多次访问：http://202.127.124.110/，然后再 202.127.124.110 上运行 ipvsadm 命令，应该有类似下面的输出： IP Virtual Server version 1.2.0 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port TCP 202.127.124.110:http rr Masq 1 0 32 -> 192.168.10.1:http Forward Weight ActiveConn InActConn
-> 192.168.10.2:http
Masq
1
0
33
从上面的结果可以看出，我们的 LVS 服务器已经成功运行。
4.3 直接路由实现虚拟服务器（VS/DR）
在 VS/NAT 的集群系统中，请求和响应的数据报文都需要通过负载调度器，当 真实服务器的数目在 10 台和 20 台之间时，负载调度器将成为整个集群系统的新瓶 颈。大多数 Internet 服务都有这样的特点：请求报文较短而响应报文往往包含大 量 的数据 。如 果能将 请求 和响应 分开 处理， 即在 负载调 度器 中只负 责调 度请求 而响 应 直接返回给客户，将极大地提高整个集群系统的吞吐量。 VS/DR 利用大多数 Internet 服务的非对称特点，负载调度器中只负责调度请求， 而服务器直接将响应返回给客户，可以极大地提高整个集群系统的吞吐量。 VS/DR 的体系结构如图 4-10 所示： 调度器和服务器组都必须在物理上有一个 网 卡通过不分断的局域网相连，如通过高速的交换机或者 HUB 相连。VIP 地址为调 度 器和服务器组共享，调度器配置的 VIP 地址是对外可见的，用于接收虚拟服务的 请 求报文； 所有的服务器把 VIP 地址配置在各自的 Non-ARP 网络设备 （不会发送 ARP 请求的网络设备）上，它对外面是不可见的，只是用于处理目标地址为 VIP 的网 络 请求。
图 4-10 图 4-11 是公司的 Web 服务器集群的网络拓扑图， 其中 VIP 代表对外公布的 Web
云计算平台系统建设项目 设计方案
1.1设计方案 1.1.1平台架构设计 **高新区云计算平台将服务器等关键设备按照需要实现的功能划分为两个层面，分别对应业务层和计算平台层。 业务层中，功能区域的划分一般都是根据安全和管理需求进行划分，各个部门可能有所不同，云数据中心中一般有公共信息服务区(DMZ区)、运行管理区、等保二级业务区、等保三级业务区、开发测试区等功能区域，实际划分可以根据业务情况进行调整，总的原则是在满足安全的前提下尽量统一管理。 计算平台层中分为计算服务区和存储服务区，其中计算服务区为三层架构。计算服务区部署主要考虑三层架构，即表现层、应用层和数据层，同时考虑物理和虚拟部署。存储服务区主要分为IPSAN、FCSAN、NAS 和虚拟化存储。 云计算平台中计算和存储支持的功能分区如下图所示：
图云计算平台整体架构 图平台分层架构
基础架构即服务：包括硬件基础实施层、虚拟化&资源池化层、资源调度与管理自动化层。 硬件基础实施层：包括主机、存储、网络及其他硬件在内的硬件设备，他们是实现云服务的最基础资源。 虚拟化&资源池化层：通过虚拟化技术进行整合，形成一个对外提供资源的池化管理（包括内存池、服务器池、存储池等），同时通过云管理平台，对外提供运行环境等基础服务。 资源调度层：在对资源（物理资源和虚拟资源）进行有效监控管理的基础上，通过对服务模型的抽取，提供弹性计算、负载均衡、动态迁移、按需供给和自动化部署等功能，是提供云服务的关键所在。 平台即服务：主要在IaaS基础上提供统一的平台化系统软件支撑服务，包括统一身份认证服务、访问控制服务、工作量引擎服务、通用报表、决策支持等。这一层不同于传统方式的平台服务，这些平台服务也要满足云架构的部署方式，通过虚拟化、集群和负载均衡等技术提供云状态服务，可以根据需要随时定制功能及相应的扩展。 软件即服务：对外提供终端服务，可以分为基础服务和专业服务。基础服务提供统一门户、公共认证、统一通讯等，专业服务主要指各种业务应用。通过应用部署模式底层的稍微变化，都可以在云计算架构下实现灵活的扩展和管理。 按需服务是SaaS应用的核心理念，可以满足不同用户的个性化需求，如通过负载均衡满足大并发量用户服务访问等。 信息安全管理体系，针对云计算平台建设以高性能高可靠的网络安
A10负载均衡和会话保持 在大多数的企业级应用中，客户端与服务器经常需要通过多次的交互才能完成一次事务处理或一笔交易。由于这些交互与用户的身份是紧密相关的，因此，与这个客户端相关的应用请求，往往需要转发至一台服务器完成，而不能被负载均衡器转发至不同的服务器上进行处理。为了实现这一机制，我们需要在负载均衡上配置会话保持（Session Persistence）机制，以确保客户端与应用系统之间的交互不会因为部署了负载均衡而发生问题。 实际上，会话保持机制与负载均衡的基本功能是完全矛盾的。负载均衡希望将来自客户端的连接、请求均衡的转发至后端的多台服务器，以避免单台服务器负载过高；而会话保持机制却要求将某些请求转发至同一台服务器进行处理。因此，在实际的部署环境中，我们要根据应用环境的特点，选择适当的会话保持机制。 连接和会话的区别 在介绍会话保持技术之前，我们必须先花点时间弄清楚一些概念：什么是连接（Connection）、什么是会话（Session），以及这二者之间的区别。 需要特别强调的是，如果我们仅仅是谈论负载均衡，会话和连接往往具有相同的含义。但是，如果我们和开发人员沟通这些术语时，这两个术语却具有截然不同的含义。希望广大读者能够注意这其中的区别。在本文中，我想着重说明的是开发人员眼中的连接及会话的含义。
通常，在普通的客户端或服务器上，我们把具有相同[源地址：端口]，和相同[目的地址：端口]的数据包定义为一个连接。下表是Windows系统中用命令netstat–an输出的部分系统连接状态。 1.C:\>netstat-an 2. 3.活动连接 4. 5.协议本地地址外部地址状态 6. 7....<省略部分输出内容>... 8.TCP172.31.20.53:47669122.225.67.240:80ESTABLISHED 9.TCP172.31.20.53:47670122.225.67.240:80ESTABLISHED 10.TCP172.31.20.53:47671122.228.243.240:80ESTABLISHED 11.TCP172.31.20.53:47672110.75.34.138:80TIME_WAIT 12.TCP172.31.20.53:47673110.75.34.138:80TIME_WAIT 13.TCP172.31.20.53:47674110.75.34.138:80TIME_WAIT 14.TCP172.31.20.53:47675122.225.67.240:80ESTABLISHED 15.TCP172.31.20.53:47676122.225.67.240:80ESTABLISHED 16.TCP172.31.20.53:47677122.228.243.240:80ESTABLISHED 17.TCP172.31.20.53:47679110.75.24.105:80ESTABLISHED 18.TCP172.31.20.53:47681122.225.67.240:80ESTABLISHED 19.TCP172.31.20.53:47682122.225.67.240:80ESTABLISHED 20.TCP172.31.20.53:4768360.191.143.240:80ESTABLISHED 21.TCP172.31.20.53:4768460.191.143.240:80ESTABLISHED 22.TCP192.168.1.4:18231203.208.46.29:443CLOSE_WAIT 23....<省略部分输出内容>... 对于负载均衡来说，情况则稍微发生了一些变化。负载均衡会将来自相同[源IP：端口]，发送到相同[目的IP：端口]的数据包，通过NAT技术做一些转换后，转发至后端的某台固定的服务器。如下表所示，虽然两个TCP连接具有相同的源地址，但源端口不同，AX负载均衡仍然将其识别为两个不同的连接，并且转发至两台不同的服务器进行处理。 1.AX#show session 2....<省略部分输出内容>... 3.
在线考试系统负载均衡配置方案 目录 方案背景 (3)
运行环境要求 (3) 硬件要求 (3) 软件要求 (3) 配置方案 (4) 软硬件负载均衡比较 (7)
方案背景 在线考试系统的软件和需求分析已经结束。针对于此，给出此配置方案，硬件的要求和运行效果都将详细列明指出。 运行环境要求 数据库服务器内存要求：建议16GB以上 客户端内存要求：建议256M以上 应用服务器内存要求：建议8G以上 硬件要求 软件要求 应用服务器： ●OS：Microsoft Windows 2000 Server (Advance Server) ●Microsoft Windows 2003 Server 数据库服务器： DBMS：SQL SERVER2008
客户端： OS：Windows 2000、Windows XP、Windows Vista 浏览器：IE6以上 配置方案 一台服务器： 一台服务器的情况，硬件配置： 用户同时在线数：2000-5000。最优化最稳定的范围在3500人左右。 五台服务器软件负载均衡 用户同时在线数：6000-15000。最优化最稳定的范围在7000人左右。 如果五台服务器支撑在线测试系统的运行，那么会考虑到采用apache+tomcat的方式来做负载均衡，确保系统运行的稳定性和准确性。 负载均衡说明图：
五-十台服务器硬件负载均衡
用户同时在线数：6000-40000。最优化最稳定的范围在15000-30000人左右。 如果五台以上服务器支撑在线测试系统的运行（最多十台），那么会考虑到采用硬件的方式来做负载均衡，确保系统运行的稳定性和准确性。 负载均衡说明图：
一、用户需求 本案例公司中现有数量较多的服务器群： WEB网站服务器 4台 邮件服务器 2台 虚拟主机服务器 10台 应用服务器 2台 数据库 2台（双机+盘阵） 希望通过服务器负载均衡设备实现各服务器群的流量动态负载均衡，并互为冗余备份。并要求新系统应有一定的扩展性，如数据访问量继续增大，可再添加新的服务器加入负载均衡系统。 二、需求分析 我们对用户的需求可分如下几点分析和考虑： 1.新系统能动态分配各服务器之间的访问流量；同时能互为冗余，当其中 一台服务器发生故障时，其余服务器能即时替代工作，保证系统访问的 不中断； 2.新系统应能管理不同应用的带宽，如优先保证某些重要应用的带宽要 求，同时限定某些不必要应用的带宽，合理高效地利用现有资源；
3.新系统应能对高层应用提供安全保证，在路由器和防火墙基础上提供了 更进一步的防线； 4.新系统应具备较强的扩展性。 o容量上：如数据访问量继续增大，可再添加新的服务器加入系统； o应用上：如当数据访问量增大到防火墙成为瓶颈时，防火墙的动态负载均衡方案，又如针对链路提出新要求时关于Internet访问 链路的动态负载均衡方案等。 三、解决方案 梭子鱼安全负载均衡方案总体设计 采用服务器负载均衡设备提供本地的服务器群负载均衡和容错，适用于处在同一个局域网上的服务器群。服务器负载均衡设备带给我们的最主要功能是：
当一台服务器配置到不同的服务器群（Farm）上，就能同时提供多个不同的应用。可以对于每个服务器群设定一个IP地址，或者利用服务器负载均衡设备的多TCP端口配置特性，配置超级服务器群（SuperFarm），统一提供各种应用服务。
第1章分布式计算概述 一、选择题 1，CD 2，ABC 3，ABCD 4，ACD 二、简答题 1，参考1.1.1和节 2，参考1.1.2节 3，分布式计算的核心技术是进程间通信，参考1.3.2节 4，单播和组播 5，超时和多线程 三、实验题 1.进程A在进程B发送receive前发起send操作 进程A进程B 发出非阻塞send操 作，进程A继续运行 发出阻塞receive操 作，进程B被阻塞进程B在进程A发起send前发出receive操作
发出非阻塞send 操作，进程A 继续运行 发出阻塞receive 操作，进程B 被阻塞 收到进程A 发送的数据，进程B 被唤醒 2. 进程A 在进程B 发送receive 前发起send 操作 进程A 进程B 发出阻塞send 操作， 进程A 被阻塞 发出阻塞receive 操作，进程B 被阻塞 进程B 在进程A 发起send 前发出receive 操作
发出阻塞send操作，进程A被阻塞 发出阻塞receive操作，进程B 被阻塞 收到进程A发送的数据，进程B 被唤醒 收到进程B返回的数 据，进程A被唤醒 3.1).在提供阻塞send操作和阻塞receive操作的通信系统中在提供非阻塞send操作和阻塞receive操作的通信系统中2)．P1，P2，P3进程间通信的顺序状态图 m1 m1 m2 m2 第2章分布式计算范型概述 1.消息传递，客户-服务器，P2P，分布式对象，网络服务，移动代理等 2.分布式应用最广泛最流行的范型是客户-服务器范型，参考节
3.分布式应用最基本的范型是消息传递模型，参考节 4.参考节，P2P应用有很多，例如Napster，迅雷，PPS网络电视等 5.参考节 6.参考节 7.略 8.消息传递模式是最基本的分布式计算范型，适用于大多数应用；客户-服务器范型是最 流行的分布式计算范型，应用最为广泛；P2P范型又称为对等结构范型，使得网络以最有效率的方式运行，适用于各参与者地位平等的网络；分布式对象范型，是抽象化的远程调用，适用于复杂的分布式计算应用等。 9.略 10.中间件又称为代理，中间件为参与对象提供内容抽象，隐藏对象引用，起到中介作用。 11.略 第3章 Socket编程与客户服务器应用开发 一、填空题 1.数据包socket，流式socket 2.无连接方式，面向连接方式 3.数据层，业务层，应用层 4.迭代服务器和并发服务器 5.有状态服务器和无状态服务器 二、简答题 1.API：Application Programming Interface,应用程序编程接口，是一些预先定义 的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能 力，而又无需访问源码，或理解内部工作机制的细节 Socket API：套接字应用程序编程接口，适用于进程间通信的套接字应用程序编程 接口
铁路客票系统服务器负载均衡解决方案 项目概况： 某省铁路集团是国务院确定的512家重点国有企业和120家试点企业集团之一，也 是中国铁路运输业第一家企业集团，其前身是原XX铁路局。集团管辖铁路4274公 里。 铁路客票发售和预订系统（简称客票系统）建设自 1996 年启动，经历4个版本， 即适应全国统一车站售票软件的 1.0 版本，适应地区内联网售票的 2.0 版本，适 应全路联网异地售票的 3.0 版本，适应客运体制改革和收入清算需求的 4.0 版本。 客票系统 5.0 版是为适应铁路客运专线建设和第六次提速客运营销的需求，以实现客票销售渠道网络化、服务手段现代化、运营管理信息化为目标而研制的。系统的 升级将使我国铁路客票系统得到进一步的优化、完善与发展。 该项目同时希望在业务负载均衡等关键技术攻关中取得了较大突破和创新，成为我 国铁路客票系统的又一重大发展。 除中心点外,有多个节点需要提供高可靠性，高性能业务负载均衡。 客票系统 5.0 继续坚持集中与分布相结合的客户／服务器体系结构，席位全部集中到各地区中心，以加强席位的管理和调控力度。对于车站级系统， 5.0 在保障目前车站运行模式的基础上，支持车站取消服务器，更好地适应了生产力布局调整的需 要. 网络结构： 客户需求： 系统体系结构和功能框架具备可扩展性、兼容性和良好的适应性。 提供以列车作为客票管理线索为基础的数据中心非动态负载均衡。 客票应用服务器得到增强，应用结构更加合理；负载均衡高效合理。 由于该系统的不可间断性，高可用性和可靠性成为重点之一。
负载均衡设备内部连接应用服务器群，外部接入铁路内部大网，提供面对铁路系统的应用访问。 系统管理员能直接通过路由方式对内部应用服务器群进行管理，方便维护。 应用服务器群能通过路由方式直接访问位于负载均衡器外部的数据库服务器。 应用服务器与数据库服务器之间的数据连接为长连接，且要求负载均衡设备任何时候都不中断连接。 对外提供的服务要进行基于来源地址的会话保持。 F5的解决方案： 结构采用F5 BIGIP3400LTM 双机HA冗余做服务器负载均衡。 双机采用心跳及网络方式HA，保证系统服务不中断。 采用F5特有的负载均衡算法和健康检查方法保证业务负载实时高效均衡。保证业务处理高效，有效性。 F5 负载均衡器业界唯一专有的四层ASIC芯片处理保证数据处理快速高效。 通过高级VS设置提供路由方式实现网管对内部服务器群进行直接管理维护。 通过F5灵活的TCP优化及会话保持技术满足业务应用需求。 为什么选择F5： F5 负载均衡器双机心跳线方式提供毫秒级快速切换，是诸如客票系统这样的关键业务系统所必需的。 F5 负载均衡器高性能高稳定性在中国诸多用户业务环境中得到证实。 F5 是业界唯一采用专有四层加速芯片的负载均衡厂商。 F5 强大的技术储备和发展计划也是客户所关注的。 关键技术阐述： F5双机冗余：串口心跳线工作原理: 两台BIGIP之间通过Failover端口方式相连。切换触发信号通过串口线通知对端设备，同时，每台BIGIP通过串口心跳线监控对端设备的状态。 最新文件---------------- 仅供参考--------------------已改成-----------word文本 --------------------- 方便更改 赠人玫瑰，手留余香。
PS：Nginx/LVS/HAProxy是目前使用最广泛的三种负载均衡软件，本人都在多个项目中实施过，参考了一些资料，结合自己的一些使用经验，总结一下。 一般对负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术。具体的应用需求还得具体分析，如果是中小型的Web应用，比如日PV小于1000万，用Nginx就完全可以了；如果机器不少，可以用DNS轮询，LVS所耗费的机器还是比较多的；大型网站或重要的服务，且服务器比较多时，可以考虑用LVS。一种是通过硬件来进行进行，常见的硬件有比较昂贵的F5和Array等商用的负载均衡器，它的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大，所以对于规模较小的网络服务来说暂时还没有需要使用；另外一种就是类似于Nginx/LVS/HAProxy的基于Linux的开源免费的负载均衡软件，这些都是通过软件级别来实现，所以费用非常低廉。 目前关于网站架构一般比较合理流行的架构方案：Web前端采用 Nginx/HAProxy+Keepalived作负载均衡器；后端采用MySQL数据库一主多从和读写分离，采用LVS+Keepalived的架构。当然要根据项目具体需求制定方案。 下面说说各自的特点和适用场合。 一、Nginx Nginx的优点是： 1、工作在网络的7层之上，可以针对http应用做一些分流的策略，比如针对域名、目录结构，它的正则规则比HAProxy更为强大和灵活，这也是它目前广泛流行的主要原因之一，Nginx单凭这点可利用的场合就远多于LVS了。 2、Nginx对网络稳定性的依赖非常小，理论上能ping通就就能进行负载功能，这个也是它的优势之一；相反LVS对网络稳定性依赖比较大，这点本人深有体会； 3、Nginx安装和配置比较简单，测试起来比较方便，它基本能把错误用日志打印出来。LVS的配置、测试就要花比较长的时间了，LVS对网络依赖比较大。 3、可以承担高负载压力且稳定，在硬件不差的情况下一般能支撑几万次的并发量，负载度比LVS相对小些。 4、Nginx可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持url来检测。比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，Nginx会把上传切到另一台服务器重新处理，而LVS就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能会因此而不满。 5、Nginx不仅仅是一款优秀的负载均衡器/反向代理软件，它同时也是功能强大的Web应用服务器。LNMP也是近几年非常流行的web架构，在高流量的环境中稳定性也很好。 6、Nginx现在作为Web反向加速缓存越来越成熟了，速度比传统的Squid服务器更快，可以考虑用其作为反向代理加速器。 7、Nginx可作为中层反向代理使用，这一层面Nginx基本上无对手，唯一可以对比
目前，网络应用正全面向纵深发展，企业上网和政府上网初见成效。随着网络技术的发展，教育信息网络和远程教学网络等也得到普及，各地都相继建起了教育信息网络，带动了网络应用的发展。 一个面向社会的网站，尤其是金融、电信、教育和零售等方面的网站，每天上网的用户不计其数，并且可能都同时并发访问同一个服务器或同一个文件，这样就很容易产生信息传输阻塞现象；加上Internet线路的质量问题，也容易引起出 现数据堵塞的现象，使得人们不得不花很长时间去访问一个站点，还可能屡次看到某个站点“服务器太忙”，或频繁遭遇系统故障。因此，如何优化信息系统的性能，以提高整个信息系统的处理能力是人们普遍关心的问题。 一、负载均衡技术的引入 信息系统的各个核心部分随着业务量的提高、访问量和数据流量的快速增长，其处理能力和计算强度也相应增大，使得单一设备根本无法承担，必须采用多台服务器协同工作，提高计算机系统的处理能力和计算强度，以满足当前业务量的需求。而如何在完成同样功能的多个网络设备之间实现合理的业务量分配，使之不会出现一台设备过忙、而其他的设备却没有充分发挥处理能力的情况。要解决这一问题，可以采用负载均衡的方法。 负载均衡有两个方面的含义：首先，把大量的并发访问或数据流量分担到多台节点设备上分别处理，减少用户等待响应的时间；其次，单个重负载的运算分担到多台节点设备上做并行处理，每个节点设备处理结束后，将结果汇总，再返回给用户，使得信息系统处理能力可以得到大幅度提高。 对一个网络的负载均衡应用，可以从网络的不同层次入手，具体情况要看对网络瓶颈所在之处的具体情况进行分析。一般来说，企业信息系统的负载均衡大体上都从传输链路聚合、采用更高层网络交换技术和设置服务器集群策略三个角度实现。 二、链路聚合——低成本的解决方案 为了支持与日俱增的高带宽应用，越来越多的PC机使用更加快速的方法连入网络。而网络中的业务量分布是不平衡的，一般表现为网络核心的业务量高，而边缘比较低，关键部门的业务量高，而普通部门低。伴随计算机处理能力的大幅度提高，人们对工作组局域网的处理能力有了更高的要求。当企业内部对高带宽应用需求不断增大时（例如Web访问、文档传输及内部网连接），局域网核心部位的数据接口将产生瓶颈问题，因此延长了客户应用请求的响应时间。并且局域网具有分散特性，网络本身并没有针对服务器的保护措施，一个无意的动作，像不小心踢掉网线的插头，就会让服务器与网络断开。 通常，解决瓶颈问题采用的对策是提高服务器链路的容量，使其满足目前的需求。例如可以由快速以太网升级到千兆以太网。对于大型网络来说，采用网络系统升级技术是一种长远的、有前景的解决方案。然而对于许多企业，当需求还没有大到非得花费大量的金钱和时间进行升级时，使用升级的解决方案就显得有些浪费
Apache+Tomcat+mod_jk实现负载均衡方案 一、概述： 原理图： 提高系统可用性，对系统性能影响较小。对于一台服务器Down机后，可自动切换到另 最少需要两台机器，Tomcat1 和Tomcat2可在同一台服务器上。若条件允许最好是各用一台服务器。 二、详细配置步骤： 1、Apache http Server安装 32位的按照提示操作即可。 64位系统的不是安装包。 64位安装配置： 以管理员身份运行cmd 执行：httpd -k install 若无法运行并提示配置错误，请先安装vcredist_x64.exe后再执行。 安装后在Testing httpd.conf...时会报错，不影响。 httpd -k start 启动Apache、httpd -k shutdown 停止Apache 、httpd -k restart重启测试Apache：
在IE中输入：127.0.0.1 打开网页显示It work就OK 2、将Mod_jk的压缩包解压，找到mod_jk.so 复制到Apache目录下modules目录下 64位的下载mod_jk1.2.30_x64.zip 32位的下载tomcat-connectors-1.2.35-windows-i386-httpd-2.0.x.zip 3、修改Apache conf目录下的httpd.conf文件 在最后增加:Include conf/extra/mod_jk.conf 4、在conf/extra 下创建mod_jk.conf文件 增加如下： #load module mod_jk.so LoadModule jk_module modules/mod_jk.so #mod_jk config #load workers JkWorkersFile conf/workers.properties #set log file JkLogFile logs/mod_jk.log #set log level JkLogLevel info #map to the status server #mount the status server JkMount /private/admin/mystatus mystatus JkMount /* balance 5.在conf目录下创建workers.properties文件 增加：worker.tomcat1 中的tomcat1和tomcat2必须和Tomcat中的配置相同。Tomcat配置下面介召 worker.list=balance,mystatus #first worker config worker.tomcat1.type=ajp13 worker.tomcat1.host=192.168.8.204 worker.tomcat1.port=8009 #Tomcat的监听端口 worker.tomcat1.lbfactor=1 worker.tomcat1.socket_timeout=30 worker.tomcat1.socket_keepalive=1 #second worker config worker.tomcat2.type=ajp13 worker.tomcat2.host=192.168.8.204 worker.tomcat2.port=8010 #Tomcat的监听端口实验是在同一机器上做的，所以两个不同
L TE系统内异频负载均衡配置开启 1、打开异频切换开关 MOD ENODEBALGOSWITCH: HoAlgoSwitch=InterFreqCoverHoSwitch-1; 现网中基于覆盖的异频切换算法开关已经全部开启！ 参数含义：基于覆盖的异频切换算法开关：当基于覆盖的异频切换算法开关为ON时，启动基于覆盖的异频切换算法，通过异频切换保证用户业务连续性；当基于覆盖的异频切换算法开关为OFF时，关闭基于覆盖的异频切换算法。 2、打开MLB算法开关 MOD CELLALGOSWITCH: LocalCellId=XXX, MlbAlgoSwitch=InterFreqMlbSwitch-1; 一般没有大话务保障需求，现网异频负载平衡开关和异频空闲态负载平衡开关设为ON 负载平衡算法开关含义：该参数表示负载平衡算法控制开关，主要用来控制负载平衡算法的打开和关闭。包含同频、同频空闲态、异频、异频空闲态、异频盲负载、Utran系统、Utran系
统空闲态、Geran系统、Cdma系统、PRB评估值负载平衡算法开关、基于邻区负载状态的负载平衡算法开关，分别控制在负载平衡算法启动后在不同邻区间进行负载的调整。 对无线网络性能的影响：同频负载平衡开关设为OFF之后，同频MLB功能被关掉，如果出现同频负载不平衡的情况，无法得到处理，系统过载率会上升，接入成功率和总的吞吐量会下降；该参数设为ON之后，同频MLB功能启动，在负载较高且不平衡的情况下，系统的过载率会减小，接入成功率和总的吞吐量会上升。同频空闲态负载平衡开关需要在全网中统一配置，即全开或者全关。否则，可能会导致UE频繁重选。异频负载平衡开关设为OFF之后，异频MLB功能被关掉，如果出现本小区负载较高而异频邻区负载较低能够承担更多的业务时，无法得到处理，系统过载率会上升，接入成功率和总的吞吐量会下降；该参数设为ON之后，异频MLB功能启动，在负载较高且不平衡的情况下，系统的过载率会减小，接入成功率和总的吞吐量会上升。 3、设置MLB参数 3.1 选择负载均衡触发模式 MOD CELLMLB:LOCALCELLID=XXX,MLBTRIGGERMODE=UE_NUMBER_ONLY; 含义：该参数表示触发负载平衡的模式。PRB_ONLY表示PRB负载作为负载平衡的触发原因；UE_NUMBER_ONLY表示用户数作为负载平衡的触发原因；PRB_OR_UE_NUMBER表示PRB负载和用户数这两种因素中的任意一个都可以作为负载平衡的触发原因。 对无线网络性能的影响：当设置为PRB模式触发时，频点间数据信道资源会更加均衡，系统吞吐率有提升。当设置为用户数模式触发时，能够改善数据等待时延，提高用户体验。 触发模式主要有三种：1、PRB_ONLY(PRB模式触发) 2、UE_NUMBER_ONLY(用户数模式触发)3、PRB_OR_UE_NUMBER(PRB模式或用户数模式触发) 3.2 修改对应触发模式的触发参数 3.2.1 PRB模式触发参数
负载调度算法 负载均衡（Load Balance），又称为负载分担，就是将负载（工作任务）进行平衡、分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。负载均衡建立在现有网络结构之上，它提供了一种廉价又有效的方法来扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。 在调度器的实现技术中，IP负载均衡技术是效率最高的。在已有的IP负载均衡技术中有通过网络地址转换（Network Address Translation）将一组服务器构成一个高性能的、高可用的虚拟服务器，称之为VS/NAT技术。在分析VS/NAT 的缺点和网络服务的非对称性的基础上，提出通过IP隧道实现虚拟服务器的方法VS/TUN，和通过直接路由实现虚拟服务器的方法VS/DR，它们可以极大地提高系统的伸缩性。 在内核中的连接调度算法上，IPVS实现了以下几种调度算法： 1 轮叫调度 1.1 轮叫调度含义 轮叫调度（Round Robin Scheduling）算法就是以轮叫的方式依次将请求调度不同的服务器，即每次调度执行i = (i + 1) mod n，并选出第i台服务器。算法的优点是其简洁性，它无需记录当前所有连接的状态，所以它是一种无状态调度。 轮叫是基站为终端分配带宽的一种处理流程，这种分配可以是针对单个终端或是一组终端的。为单个终端和一组终端连接分配带宽，实际上是定义带宽请求竞争机制，这种分配不是使用一个单独的消息，而是上行链路映射消息中包含的一系列分配机制。 1.2 轮叫调度算法流程 轮询调度算法的原理是每一次把来自用户的请求轮流分配给内部中的服务器，从1开始，直到N（内部服务器个数），然后重新开始循环。在系统实现时，我们引入了一个额外条件，即当服务器的权值为零时，表示该服务器不可用而不被调度。这样做的目的是将服务器切出服务（如屏蔽服务器故障和系统维护），同时与其他加权算法保持一致。所以，算法要作相应的改动，它的算法流程如下：假设有一组服务器S = {S0, S1, …, Sn-1}，一个指示变量i表示上一次选择的服务器，W(Si)表示服务器Si的权值。变量i被初始化为n-1，其中n > 0。 j = i; do { j = (j + 1) mod n;
集群的负载均衡技术综述 摘要：当今世界，无论在机构内部的局域网还是在广域网如Internet上，信息处理量的增长都远远超出了过去最乐观的估计，即使按照当时最优配置建设的网络，也很快会感到吃不消。如何在完成同样功能的多个网络设备之间实现合理的业务量分配，使之不致于出现一台设备过忙、而别的设备却未充分发挥处理能力的情况，负载均衡机制因此应运而生。本组在课堂上讲解了《集群监控与调度》这一课题，本人在小组内负责负载均衡部分内容，以及PPT的制作。 关键词：负载均衡集群网络计算机 一、前言 负载均衡建立在现有网络结构之上，它提供了一种廉价有效的方法扩展服务器带宽和增加吞吐量，加强网络数据处理能力，提高网络的灵活性和可用性。它主要完成以下任务：解决网络拥塞问题，服务就近提供，实现地理位置无关性；为用户提供更好的访问质量；提高服务器响应速度；提高服务器及其他资源的利用效率；避免了网络关键部位出现单点失效。 其实，负载均衡并非传统意义上的“均衡”，一般来说，它只是把有可能拥塞于一个地方的负载交给多个地方分担。如果将其改称为“负载分担”，也许更好懂一些。说得通俗一点，负载均衡在网络中的作用就像轮流值日制度，把任务分给大家来完成，以免让一个人累死累活。不过，这种意义上的均衡一般是静态的，也就是事先确定的“轮值”策略。 与轮流值日制度不同的是，动态负载均衡通过一些工具实时地分析数据包，掌握网络中的数据流量状况，把任务合理分配出去。结构上分为本地负载均衡和地域负载均衡(全局负载均衡)，前一种是指对本地的服务器集群做负载均衡，后一种是指对分别放置在不同的地理位置、在不同的网络及服务器群集之间作负载均衡。 服务器群集中每个服务结点运行一个所需服务器程序的独立拷贝，诸如Web、FTP、Telnet或e-mail服务器程序。对于某些服务（如运行在Web服务器上的那些服务）而言，程序的一个拷贝运行在群集内所有的主机上，而网络负载均衡则将工作负载在这些主机间进行分配。对于其他服务（例如e-mail），只有一台主机处理工作负载，针对这些服务，网络负载均衡允许网络通讯量流到一个主机上，并在该主机发生故障时将通讯量移至其他主机。 二、负载均衡技术实现结构 在现有网络结构之上，负载均衡提供了一种廉价有效的方法扩展服务器带宽和增加吞吐量，加强网络数据处理能力，提高网络的灵活性和可用性。它主要完成以下任务： 1.解决网络拥塞问题，服务就近提供，实现地理位置无关性 2.为用户提供更好的访问质量 3.提高服务器响应速度
负载均衡软件实现方式之一- URL重定向方式 有一种用软件实现负载均衡的方式,是基于"URL重定向"的. 先看看什么是URL重定向: "简单的说，如果一个网站有正规的URL和别名URL，对别名URL进行重定向到正规URL，访问同一个网址，或者网站改换成了新的域名则把旧的域名重定向到新的域名，都叫URL 重定向" (https://www.doczj.com/doc/fe10193089.html,/service/host_faq.php) "很多网络协议都支持“重定向”功能，例如在HTTP协议中支持Location指令，接收到这个指令的浏览器将自动重定向到Location指明的另一个URL上。" (https://www.doczj.com/doc/fe10193089.html,/art/200604/25388.htm) 这种方式,对于简单的网站,如果网站是自己开发的,也在一定程度上可行.但是它存在着较多的问题: 1、“例如一台服务器如何能保证它重定向过的服务器是比较空闲的，并且不会再次发送Location指令，Location指令和浏览器都没有这方面的支持能力，这样很容易在浏览器上形成一种死循环。” 2、在哪里放LOCATION，也是一个问题。很有可能用户会访问系统的很多个不同URL，这个时候做起来会非常麻烦。并且，对URL的访问，有的时候是直接过来的，可以被重定向，有的时候是带着SESSION之类的，重定向就可能会出问题。并且，这种做法，将负载均衡这个系统级的问题放到了应用层，结果可能是麻烦多多。 3、这种方式一般只适用于HTTP方式，但是实际上有太多情况不仅仅是HTTP方式了，特别是用户如果在应用里面插一点流媒体之类的。 4、重定向的方式，效率远低于IP隧道。 5、这种方式，有的时候会伴以对服务器状态的检测，但往往也是在应用层面实现，从而实时性大打折扣。 实际上，这种方式是一种“对付”的解决方法，并不能真正用于企业级的负载均衡应用（这里企业级是指稍微复杂一点的应用系统） 可以看一下专业的负载均衡软件是如何来实现的： https://www.doczj.com/doc/fe10193089.html,/pcl/pcl_sis_theory.htm 对比一下可以发现，专业的负载均衡软件要更适用于正规应用，而重定向方式则比较适用于
LTE 系统的移动负载均衡技术 摘要—在本文中我们提出的仿真结果表明，一个基于自动调节切换门限的简单的分布式同频负载均衡算法能显著降低LTE(Long Term Evolution,长期演进)网络中的呼叫阻塞率，并提高蜂窝边缘的吞吐量。 【关键词】LTE 负载均衡 切换 SON 无线电资源管理(RRM) 简介 负载均衡的描述为，将过载小区的负载分配给轻载的相邻小区使整个网络的无线资源运用更有效率。在本文中，我们所关心的是同频负载平衡机制，它在几分钟或几小时内测量反应时间，并能在长期演进网（LTE ）中以最低的额外信令实现。 有很多方法可以重新分配小区之间的负载。一种方法是通过修改导频功率来调整小区的覆盖范围[1]。一个更强的导频功率实际上可以允许更多的远距离的用户进入小区，从而达到增加覆盖范围的目的。然而，自动调节小区覆盖范围冒着可能会造成覆盖漏洞的风险。另一种重新分配小区负载方法是修改两个相邻小区之间的切换区域。这种方法被称为移动负载均衡（MLB ）。移动负载均衡的规则是一偏置切换测量值来调整切换区域，致使超载小区的边缘用户切换到负载较轻的相邻小区，从而提高资源的利用效率[2]。其结果是在呼叫阻塞率的降低和蜂窝边缘的吞吐量的提高。由于小区间负载分配自动的被完成，这种技术是自组织网络（SON ）算法的一种。 本文的结构安排如下：在第二节中将介绍一个简单的分布式负载均衡算法；在第三节中，将介绍一个仿真模型并给出仿真结果；最后的结论将在第四节给出。 移动负载均衡 根据文献[3]，切换可以被许多事件所触发。在这篇文章中我们只涉及一个特定的事件，这个事件被称为事件A3，触发事件A3是当一个特定用户检测到一个相邻小区的信号质量比当前服务小区的好时进行切换触发。这个触发条件可以被描述为公式（1），其中i 和j 分别是当前小区和相邻小区，Mi 和Mj 分别是用户测量到小区i 和j 的信号强度，()O f i 和()O f j 分别是小区i 和j 的频率fi 与fj 的频率偏移，()cs i O 是服务小区的小区偏置，(),cn i j O 是小区i 对j 的小区偏置，ξ和η分别是一个滞后术语和一个固定的偏移量。Mi 的测量值可以是一个单位为dBm 的参考信号接收功率的形式，或者是单位为dB 的参考信号接收质
该文档是word2003—word2007兼容版 软件、硬件负载均衡部署方案 目录 1、硬件负载均衡之F5部署方案 (2) 1.1网络拓扑结构 (2) 1.2反向代理部署方式 (3) 2软件负载均衡方案 (4) 2.1负载均衡软件实现方式之一- URL重定向方式 (4) 2.2负载均衡软件实现方式之二- 基于DNS (5) 2.3负载均衡软件实现方式之三- LVS (8) 2.4负载均衡软件实现方式之四- 专业负载均衡软件 (16) 总结： (16)
1、硬件负载均衡之F5部署方案 对于所有的对外服务的服务器，均可以在BIG-IP上配置Virtual Server实现负载均衡，同时BIG-IP可持续检查服务器的健康状态，一旦发现故障服务器，则将其从负载均衡组中摘除。 BIG-IP利用虚拟IP地址（VIP由IP地址和TCP/UDP应用的端口组成，它是一个地址）来为用户的一个或多个目标服务器（称为节点：目标服务器的IP地址和TCP/UDP应用的端口组成，它可以是internet的私网地址）提供服务。因此，它能够为大量的基于TCP/IP的网络应用提供服务器负载均衡服务。根据服务类型不同分别定义服务器群组，可以根据不同服务端口将流量导向到相应的服务器。BIG-IP连续地对目标服务器进行L4到L7合理性检查，当用户通过VIP请求目标服务器服务时，BIG-IP根椐目标服务器之间性能和网络健康情况，选择性能最佳的服务器响应用户的请求。如果能够充分利用所有的服务器资源，将所有流量均衡的分配到各个服务器，我们就可以有效地避免“不平衡”现象的发生。 利用UIE+iRules可以将TCP/UDP数据包打开，并搜索其中的特征数据，之后根据搜索到的特征数据作相应的规则处理。因此可以根据用户访问内容的不同将流量导向到相应的服务器，例如：根据用户访问请求的URL将流量导向到相应的服务器。 1.1网络拓扑结构 网络拓扑结构如图所示：
云计算的资源分配现状 云计算的资源分配是指在一个共同的云环境中使用者根据一定是使用规则来调度资源的过程。目前云计算资源调度的研究主要集中在三个方面: (1)人工智能算法 人工智能算法是指以学习的方式对解空间进行人工搜索，以减少任务的平均时间，提高资源的利用率 (2)云计算的负载均衡 不同的用户对云计算有不同的需求，云计算必须满足服务器网络带宽、吞吐量、延迟和抖动等负载需求。因此，在进行云计算时，更应该注意云计算的负载均衡。 (3)云计算的能耗管理 数据中心作为云计算的中心，能耗过大，不仅浪费电能，还会降低系统的稳定性，影响环境。因此，加强云计算能耗管理也是云计算资源配置中需要解决的重要问题。 本章对于多目标优化、遗传算法、SPEA-II做出了详细的基础知识介绍，通过数学模型以及流程图对于该问题进行了解析分析。通过此小结可大致了解多目标问题的优劣端以及如何利用遗传算法和SPEA-II进行修饰，避免局部最优解，从而获得优秀的目标最优解集。
基于改进 SPEA-II动态资源配置 通过分组编码和多目标优化模型可知，根据遗传算法在交叉和突变阶段提出的TMR，便可以指出基因的类型及其在染色体上的分布。选择已经分层的Pareto前沿时，使用预筛选操作来维持种群分布的均匀性。当达到一定的进化代数时，上一代种群中平均功耗最低的个体被输出。 MOGAISP可以采用自适应概率突变和交叉概率突变进行遗传操作,以帮助我们防止遗传算法进化的过程陷入局部停滞的状态,保持遗传算法种群的多样性,提高了遗传算法进化和全局最优搜索的速度和能力。MOGAISP选择机制选择EFP种群的最优个体，使
（总结）Nginx/LVS/HAProxy负载均衡软件的优缺点详解 PS：Nginx/LVS/HAProxy是目前使用最广泛的三种负载均衡软件，本人都在多个项目中实施过，参考了一些资料，结合自己的一些使用经验，总结一下。 一般对负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术。具体的应用需求还得具体分析，如果是中小型的Web应用，比如日PV小于1000万，用Nginx就完全可以了；如果机器不少，可以用DNS轮询，LVS所耗费的机器还是比较多的；大型网站或重要的服务，且服务器比较多时，可以考虑用LVS。一种是通过硬件来进行进行，常见的硬件有比较昂贵的F5和Array等商用的负载均衡器，它的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大，所以对于规模较小的网络服务来说暂时还没有需要使用；另外一种就是类似于Nginx/LVS/HAProxy的基于Linux的开源免费的负载均衡软件，这些都是通过软件级别来实现，所以费用非常低廉。 目前关于网站架构一般比较合理流行的架构方案：Web前端采用 Nginx/HAProxy+Keepalived作负载均衡器；后端采用MySQL数据库一主多从和读写分离，采用LVS+Keepalived的架构。当然要根据项目具体需求制定方案。 下面说说各自的特点和适用场合。 Nginx的优点是： 1、工作在网络的7层之上，可以针对http应用做一些分流的策略，比如针对域名、目录结构，它的正则规则比HAProxy更为强大和灵活，这也是它目前广泛流行的主要原因之一，Nginx单凭这点可利用的场合就远多于LVS了。 2、Nginx对网络稳定性的依赖非常小，理论上能ping通就就能进行负载功能，这个也是它的优势之一；相反LVS对网络稳定性依赖比较大，这点本人深有体会； 3、Nginx安装和配置比较简单，测试起来比较方便，它基本能把错误用日志打印出来。LVS的配置、测试就要花比较长的时间了，LVS对网络依赖比较大。 3、可以承担高负载压力且稳定，在硬件不差的情况下一般能支撑几万次的并发量，负载度比LVS相对小些。 4、Nginx可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持url来检测。比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，Nginx会把上传切到另一台服务器重新处理，而LVS就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能会因此而不满。 5、Nginx不仅仅是一款优秀的负载均衡器/反向代理软件，它同时也是功能强大的Web应用服务器。LNMP也是近几年非常流行的web架构，在高流量的环境中稳定性也很好。 6、Nginx现在作为Web反向加速缓存越来越成熟了，速度比传统的Squid服务器