共计 4188 个字符，预计需要花费 11 分钟才能阅读完成。
这篇文章主要介绍 Linux 服务器集群系统中如何实现虚拟服务器，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！
实现虚拟服务的相关方法：
在网络服务中，一端是客户程序，另一端是服务程序，在中间可能有代理程序。由此看来，可以在不同的层次上实现多台服务器的负载均衡。用集群解决网络服务性能问题的现有方法主要分为以下四类。
1. 基于 RR-DNS 的解决方法
NCSA 的可伸缩的 WEB 服务器系统就是最早基于 RR-DNS(Round-Robin Domain Name System)的原型系统[1,2]。它的结构和工作流程如下图所示：
图 1：基于 RR-DNS 的可伸缩 WEB 服务器
有一组 WEB 服务器，他们通过分布式文件系统 AFS(Andrew File System)来共享所有的 HTML 文档。这组服务器拥有相同的域名(如 www.ncsa.uiuc.edu)，当用户按照这个域名访问时, RR-DNS 服务器会把域名轮流解析到这组服务器的不同 IP 地址，从而将访问负载分到各台服务器上。
这种方法带来几个问题。***，域名服务器是一个分布式系统，是按照一定的层次结构组织的。当用户就域名解析请求提交给本地的域名服务器，它会因不能直接解析而向上一级域名服务器提交，上一级域名服务器再依次向上提交，直到 RR-DNS 域名服器把这个域名解析到其中一台服务器的 IP 地址。可见，从用户到 RR-DNS 间存在多台域名服器，而它们都会缓冲已解析的名字到 IP 地址的映射, 这会导致该域名服器组下所有用户都会访问同一 WEB 服务器，出现不同 WEB 服务器间严重的负载不平衡。为了保证在域名服务器中域名到 IP 地址的映射不被长久缓冲，RR-DNS 在域名到 IP 地址的映射上设置一个 TTL(Time To Live)值，过了这一段时间，域名服务器将这个映射从缓冲中淘汰。当用户请求，它会再向上一级域名服器提交请求并进行重新影射。这就涉及到如何设置这个 TTL 值，若这个值太大，在这个 TTL 期间，很多请求会被映射到同一台 WEB 服务器上，同样会导致严重的负载不平衡。若这个值太小，例如是 0，会导致本地域名服务器频繁地向 RR-DNS 提交请求，增加了域名解析的网络流量，同样会使 RR-DNS 服务器成为系统中一个新的瓶颈。
第二，用户机器会缓冲从名字到 IP 地址的映射，而不受 TTL 值的影响，用户的访问请求会被送到同一台 WEB 服务器上。由于用户访问请求的突发性和访问方式不同，例如有的人访问一下就离开了，而有的人访问可长达几个小时，所以各台服务器间的负载仍存在倾斜 (Skew) 而不能控制。假设用户在每个会话中平均请求数为 20，负载 *** 的服务器获得的请求数额高于各服务器平均请求数的平均比率超过百分之三十。也就是说，当 TTL 值为 0 时，因为用户访问的突发性也会存在着较严重的负载不平衡。
第三，系统的可靠性和可维护性差。若一台服务器失效，会导致将域名解析到该服务器的用户看到服务中断，即使用户按“Reload”按钮，也无济于事。系统管理员也不能随时地将一台服务器切出服务进行系统维护，如进行操作系统和应用软件升级，这需要修改 RR-DNS 服务器中的 IP 地址列表，把该服务器的 IP 地址从中划掉，然后等上几天或者更长的时间，等所有域名服器将该域名到这台服务器的映射淘汰，和所有映射到这台服务器的客户机不再使用该站点为止。
2. 基于客户端的解决方法
基于客户端的解决方法需要每个客户程序都有一定的服务器集群的知识，进而把以负载均衡的方式将请求发到不同的服务器。例如，Netscape Navigator 浏览器访问 Netscape 的主页时，它会随机地从一百多台服务器中挑选第 N 台，*** 将请求送往 wwwN.netscape.com。然而，这不是很好的解决方法，Netscape 只是利用它的 Navigator 避免了 RR-DNS 解析的麻烦，当使用 IE 等其他浏览器不可避免的要进行 RR-DNS 解析。
Smart Client[3]是 Berkeley 做的另一种基于客户端的解决方法。服务提供一个 Java Applet 在客户方浏览器中运行，Applet 向各个服务器发请求来收集服务器的负载等信息，再根据这些信息将客户的请求发到相应的服务器。高可用性也在 Applet 中实现，当服务器没有响应时，Applet 向另一个服务器转发请求。这种方法的透明性不好，Applet 向各服务器查询来收集信息会增加额外的网络流量，不具有普遍的适用性。
3. 基于应用层负载均衡调度的解决方法
多台服务器通过高速的互联网络连接成一个集群系统，在前端有一个基于应用层的负载调度器。当用户访问请求到达调度器时，请求会提交给作负载均衡调度的应用程序，分析请求，根据各个服务器的负载情况，选出一台服务器，重写请求并向选出的服务器访问，取得结果后，再返回给用户。
应用层负载均衡调度的典型代表有 Zeus 负载调度器 [4]、pWeb[5]、Reverse-Proxy[6] 和 SWEB[7]等。Zeus 负载调度器是 Zeus 公司的商业产品，它是在 Zeus Web 服务器程序改写而成的，采用单进程事件驱动的服务器结构。pWeb 就是一个基于 Apache 1.1 服务器程序改写而成的并行 WEB 调度程序，当一个 HTTP 请求到达时，pWeb 会选出一个服务器，重写请求并向这个服务器发出改写后的请求，等结果返回后，再将结果转发给客户。Reverse-Proxy 利用 Apache 1.3.1 中的 Proxy 模块和 Rewrite 模块实现一个可伸缩 WEB 服务器，它与 pWeb 的不同之处在于它要先从 Proxy 的 cache 中查找后，若没有这个副本，再选一台服务器，向服务器发送请求，再将服务器返回的结果转发给客户。SWEB 是利用 HTTP 中的 redirect 错误代码，将客户请求到达一台 WEB 服务器后，这个 WEB 服务器根据自己的负载情况，自己处理请求，或者通过 redirect 错误代码将客户引到另一台 WEB 服务器，以实现一个可伸缩的 WEB 服务器。
基于应用层负载均衡调度的多服务器解决方法也存在一些问题。***，系统处理开销特别大，致使系统的伸缩性有限。当请求到达负载均衡调度器至处理结束时，调度器需要进行四次从核心到用户空间或从用户空间到核心空间的上下文切换和内存复制; 需要进行二次 TCP 连接，一次是从用户到调度器，另一次是从调度器到真实服务器; 需要对请求进行分析和重写。这些处理都需要不小的 CPU、内存和网络等资源开销，且处理时间长。所构成系统的性能不能接近线性增加的，一般服务器组增至 3 或 4 台时，调度器本身可能会成为新的瓶颈。所以，这种基于应用层负载均衡调度的方法的伸缩性极其有限。第二，基于应用层的负载均衡调度器对于不同的应用，需要写不同的调度器。以上几个系统都是基于 HTTP 协议，若对于 FTP、Mail、POP3 等应用，都需要重写调度器。
4. 基于 IP 层负载均衡调度的解决方法
用户通过虚拟 IP 地址 (Virtual IP Address) 访问服务时，访问请求的报文会到达负载调度器，由它进行负载均衡调度，从一组真实服务器选出一个，将报文的目标地址 Virtual IP Address 改写成选定服务器的地址，报文的目标端口改写成选定服务器的相应端口，*** 将报文发送给选定的服务器。真实服务器的回应报文经过负载调度器时，将报文的源地址和源端口改为 Virtual IP Address 和相应的端口，再把报文发给用户。Berkeley 的 MagicRouter[8]、Cisco 的 LocalDirector、Alteon 的 ACEDirector 和 F5 的 Big/IP 等都是使用网络地址转换方法。MagicRouter 是在 Linux 1.3 版本上应用快速报文插入技术，使得进行负载均衡调度的用户进程访问网络设备接近核心空间的速度，降低了上下文切换的处理开销，但并不彻底，它只是研究的原型系统，没有成为有用的系统存活下来。Cisco 的 LocalDirector、Alteon 的 ACEDirector 和 F5 的 Big/IP 是非常昂贵的商品化系统，它们支持部分 TCP/UDP 协议，有些在 ICMP 处理上存在问题。
IBM 的 TCP Router[9]使用修改过的网络地址转换方法在 SP/ 2 系统实现可伸缩的 WEB 服务器。TCP Router 修改请求报文的目标地址并把它转发给选出的服务器，服务器能把响应报文的源地址置为 TCP Router 地址而非自己的地址。这种方法的好处是响应报文可以直接返回给客户，坏处是每台服务器的操作系统内核都需要修改。IBM 的 NetDispatcher[10]是 TCP Router 的后继者，它将报文转发给服务器，而服务器在 non-ARP 的设备配置路由器的地址。这种方法与 LVS 集群中的 VS/DR 类似，它具有很高的可伸缩性，但一套在 IBM SP/ 2 和 NetDispatcher 需要上百万美金。总的来说，IBM 的技术还挺不错的。
在贝尔实验室的 ONE-IP[11]中，每台服务器都独立的 IP 地址，但都用 IP Alias 配置上同一 VIP 地址，采用路由和广播两种方法分发请求，服务器收到请求后按 VIP 地址处理请求，并以 VIP 为源地址返回结果。这种方法也是为了避免回应报文的重写，但是每台服务器用 IP Alias 配置上同一 VIP 地址，会导致地址冲突，有些操作系统会出现网络失效。通过广播分发请求，同样需要修改服务器操作系统的源码来过滤报文，使得只有一台服务器处理广播来的请求。
微软的 Windows NT 负载均衡服务 (Windows NT Load Balancing Service，WLBS)[12] 是 1998 年底收购 Valence Research 公司获得的，它与 ONE-IP 中的基于本地过滤方法一样。WLBS 作为过滤器运行在网卡驱动程序和 TCP/IP 协议栈之间，获得目标地址为 VIP 的报文，它的过滤算法检查报文的源 IP 地址和端口号，保证只有一台服务器将报文交给上一层处理。但是，当有新结点加入和有结点失效时，所有服务器需要协商一个新的过滤算法，这会导致所有有 Session 的连接中断。同时，WLBS 需要所有的服务器有相同的配置，如网卡速度和处理能力。
以上是“Linux 服务器集群系统中如何实现虚拟服务器”这篇文章的所有内容，感谢各位的阅读！希望分享的内容对大家有帮助，更多相关知识，欢迎关注丸趣 TV 行业资讯频道！
