随着互联网规模的不断扩大，服务器承载的压力也不断增加，对服务的质量要求也越来越高。最理想的情况是，使用低成本的服务器，承载更大的压力，并且7x24小时不中断服务。通常使用的方式就是部署集群，调度器+服务器+存储这样的架构。注意，集群不是单指的调度器，它是一个完整的系统，调度器只是集群的入口，起到负载均衡或内容调度的作用。还有一种方式是在服务器程序中加入集群的功能，使服务器节点之间可以通信，实现基于内容的调度，例如Traffic Server。不过即使在服务器中加入了集群的功能在部署时，仍然需要调度器。
我们首先来看一看没有调度器的情况。如果没有调度器的话，通常的架构是这样的：
这样的部署现在应该不常见到，它的缺点很明显。DNS服务器是一个分布式系统，是按照一定的层次结构组织的。当用户将域名解析请求提交给本地的域名服务器，它会因不能直接解析而向上一级域名服务器提交，上一级域名服务器再依次向上提交，直到我们这里的DNS服务器把这个域名解析到一台服务器的IP地址。解析完成后，从用户到我们这里的DNS服务器之间存在多台域名服务器，它们都会缓冲以解析的域名到IP地址的映射，这会导致该域名服务器组下所有用户都会访问同一台服务器，出现不同服务器间的负载不均衡。由于缓冲的存在，及请求的不确定性，即使设置了TTL值，负载仍然会不均衡。高可用性也很差。如果某台实际服务器宕机或服务器程序挂掉，所有的访问IP映射到这台机器的用户都会在一段时间内无法访问服务器，任何的服务中断都会立刻会用户感知到。即使在服务器中加入了集群的功能，最多只是在服务器间将根据内容来转发请求，如果没有调度器，宕机时也有同样的问题。
现在来看看加上调度器的情况，如下所示：
在这种情况下，域名对应的IP都会解析到调度器，用户是否能访问服务器依赖于调度器是否能正常工作，所以通常都会给主调度器在准备一台备份服务器，以便在主调度器不能服务器时来接管。在没有调度器时，则只能给每台实际服务器单独备份一个服务器，但是成本会很高，而且这种方式也很不好，也没有必要。主调度器现在做到了高可用性，现在来看实际服务器。调度器会定时探测实际服务器的运行情况，一旦出现宕机，服务器会很快探测到。即使在探测时间内出现宕机，服务器的定时探测还没有来得及知道这台服务器宕机，在转发请求的时候，会立即检测到，然后将请求转发到其他机器进行处理，保证用户的请求不受影响。只有在实际服务器全部宕机的情况下，才会无法响应用户的请求，相当于是多台实际服务器互备，高可用性不言而喻。
再来看看负载均衡的问题。请求由调度器转发，调度器肯定知道每台实际服务器处理了多少请求，所以在决定是否转发到某台实际服务器时会根据请求数来决定，避免某些机器转发了过多的请求。这种策略通常会工作地很好。但是由于请求的不确定性，处理的时间和消耗的资源也不相同，也有可能造成负载不均衡的问题，这就要求调度器能根据每台服务器的响应能力来分配请求，不过现在的调度器也都有这样的策略，也不是问题。
调度器将负载均分到不同的服务器上，充分提高了单台服务器的利用率，不过也造成了硬件和软件的冗余，这种冗余带来的好处也是巨大的，对保证服务质量非常有必要。