隨着互聯網規模的不斷擴大，服務器承載的壓力也不斷增加，對服務的質量要求也越來越高。最理想的情況是，使用低成本的服務器，承載更大的壓力，並且7x24小時不中斷服務。通常使用的方式就是部署集羣，調度器+服務器+存儲這樣的架構。注意，集羣不是單指的調度器，它是一個完整的系統，調度器只是集羣的入口，起到負載均衡或內容調度的作用。還有一種方式是在服務器程序中加入集羣的功能，使服務器節點之間可以通信，實現基於內容的調度，例如Traffic Server。不過即使在服務器中加入了集羣的功能在部署時，仍然需要調度器。
我們首先來看一看沒有調度器的情況。如果沒有調度器的話，通常的架構是這樣的：
這樣的部署現在應該不常見到，它的缺點很明顯。DNS服務器是一個分佈式系統，是按照一定的層次結構組織的。當用戶將域名解析請求提交給本地的域名服務器，它會因不能直接解析而向上一級域名服務器提交，上一級域名服務器再依次向上提交，直到我們這裏的DNS服務器把這個域名解析到一臺服務器的IP地址。解析完成後，從用戶到我們這裏的DNS服務器之間存在多臺域名服務器，它們都會緩衝以解析的域名到IP地址的映射，這會導致該域名服務器組下所有用戶都會訪問同一臺服務器，出現不同服務器間的負載不均衡。由於緩衝的存在，及請求的不確定性，即使設置了TTL值，負載仍然會不均衡。高可用性也很差。如果某臺實際服務器宕機或服務器程序掛掉，所有的訪問IP映射到這臺機器的用戶都會在一段時間內無法訪問服務器，任何的服務中斷都會立刻會用戶感知到。即使在服務器中加入了集羣的功能，最多只是在服務器間將根據內容來轉發請求，如果沒有調度器，宕機時也有同樣的問題。
現在來看看加上調度器的情況，如下所示：
在這種情況下，域名對應的IP都會解析到調度器，用戶是否能訪問服務器依賴於調度器是否能正常工作，所以通常都會給主調度器在準備一臺備份服務器，以便在主調度器不能服務器時來接管。在沒有調度器時，則只能給每臺實際服務器單獨備份一個服務器，但是成本會很高，而且這種方式也很不好，也沒有必要。主調度器現在做到了高可用性，現在來看實際服務器。調度器會定時探測實際服務器的運行情況，一旦出現宕機，服務器會很快探測到。即使在探測時間內出現宕機，服務器的定時探測還沒有來得及知道這臺服務器宕機，在轉發請求的時候，會立即檢測到，然後將請求轉發到其他機器進行處理，保證用戶的請求不受影響。只有在實際服務器全部宕機的情況下，纔會無法響應用戶的請求，相當於是多臺實際服務器互備，高可用性不言而喻。
再來看看負載均衡的問題。請求由調度器轉發，調度器肯定知道每臺實際服務器處理了多少請求，所以在決定是否轉發到某臺實際服務器時會根據請求數來決定，避免某些機器轉發了過多的請求。這種策略通常會工作地很好。但是由於請求的不確定性，處理的時間和消耗的資源也不相同，也有可能造成負載不均衡的問題，這就要求調度器能根據每臺服務器的響應能力來分配請求，不過現在的調度器也都有這樣的策略，也不是問題。
調度器將負載均分到不同的服務器上，充分提高了單臺服務器的利用率，不過也造成了硬件和軟件的冗餘，這種冗餘帶來的好處也是巨大的，對保證服務質量非常有必要。