在前面文章中，講述了可伸縮網絡服務的幾種結構，它們都需要一個前端的負載調度器（或者多個進行主從備份）。我們先分析實現虛擬網絡服務的主要技術，指出IP負載均衡技術是在負載調度器的實現技術中效率最高的。在已有的IP負載均衡技術中，主要有通過網絡地址轉換（Network Address Translation）將一組服務器構成一個高性能的、高可用的虛擬服務器，我們稱之為VS/NAT技術（Virtual Server via Network Address Translation）。在分析VS/NAT的缺點和網絡服務的非對稱性的基礎上，我們提出了通過IP隧道實現虛擬服務器的方法VS/TUN（Virtual Server via IP Tunneling），和通過直接路由實現虛擬服務器的方法VS/DR（Virtual Server via Direct Routing），它們可以極大地提高系統的伸縮性。VS/NAT、VS/TUN和VS/DR技術是LVS集群中實現的三種IP負載均衡技術，我們將在文章中具體描述它們的工作原理和各自的優缺點。
這種方法帶來幾個問題。第一，域名服務器是一個分布式系統，是按照一定的層次結構組織的。當用戶就域名解析請求提交給本地的域名服務器，它會因不能直接解析而向上一級域名服務器提交，上一級域名服務器再依次向上提交，直到RR-DNS域名服器把這個域名解析到其中一臺服務器的IP地址。可見，從用戶到RR-DNS間存在多臺域名服器，而它們都會緩沖已解析的名字到IP地址的映射,這會導致該域名服器組下所有用戶都會訪問同一WEB服務器，出現不同WEB服務器間嚴重的負載不平衡。為了保證在域名服務器中域名到IP地址的映射不被長久緩沖，RR-DNS在域名到IP地址的映射上設置一個TTL(Time To Live)值，過了這一段時間，域名服務器將這個映射從緩沖中淘汰。當用戶請求，它會再向上一級域名服器提交請求并進行重新影射。這就涉及到如何設置這個TTL值，若這個值太大，在這個TTL期間，很多請求會被映射到同一臺WEB服務器上，同樣會導致嚴重的負載不平衡。若這個值太小，例如是０，會導致本地域名服務器頻繁地向RR-DNS提交請求，增加了域名解析的網絡流量，同樣會使RR-DNS服務器成為系統中一個新的瓶頸。
用戶通過虛擬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處理上存在問題。
