51CTO第2本书样章曝光：DHCP服务器规划与应用案例-阿里云开发者社区

痛苦（手疼）并快乐的写书过程，51CTO博友们对第一本书的关注超出了我的预期，[url]http://blog.51cto.com/book/[/url]第2本书定位在Windows Server 2003 R2 和Windows Server 2008 俩个平台之上，之所以这样，是因为我们不能忽悠大家，2008的案例本来就不多，因为现在大家还都是用这2003，这是一个事实。

下面是第2本书的样章目录，以及DHCP规划的一些建议，与各位分析吧

第3章 DHCP服务器规划与应用案例

3.1 DHCP协议的前生今世

3.1.4 Windows Server DHCP图标状态解密

3.4.1 DHCP容错50/50故障转移

3.4.2 DHCP容错80/20故障转移

3.4.3 DHCP容错100/100故障转移

3.5 配置DHCP支持MAC地址与IP绑定案例

3.7 Windows Server 2008 IPv6组网案例

3.7.1 IPv6组网需求

3.7.2 DHCPv6与IPv6地址获取技术分析

6．Windows Vista与Windows Server 2008 中IPv6 的自动获取

Windows Vista 中的 IPv6 自动配置过程

3.7.3 Windows Server 2008 DHCPv6 的实现

1．设置DHCP Server IPv6地址属性

3.4 DHCP冗余规划建议汇总

有人说“DHCP不重要”？我再次反对这样的说法！DHCP停止工作将会让无法访问网络的用户火冒三丈。因此在DHCP环境中建立冗余并在其中一台牺牲的时候，另外一个服务器可以迅速的接过他手中的枪，这样的网络才有意义！
不幸的是，DHCP服务并没有一种办法来动态的与另外一个DHCP服务器协同工作以同步客户端租约情况。我花费了很长时间收集“51CTO专家博客”的建议，对于DHCP冗余，他们提供了多种可供选择的规划方案，而每种选项的优缺点可能要你与公司的情况相对应。
3.4.1 DHCP容错50/50故障转移
DHCP容错的50/50故障转移方法将使用2台DHCP服务器，每台服务器在子网上处理同等数量的客户端请求流量。每台服务器采用了非常相似的作用域配置，但作用域的范围不能重叠，以避免IP寻址冲突。
有一个偶然的机会，我的一位朋友参与了一个科研所的办公网络改造工程。该网络拥有200台以1921.68.100/24 定义的客户端，原本网络中只有一台DHCP服务器，一次意外的硬件故障发生时，这台服务器停止了服务。由于所有客户端都采用自动获取IP的方式，这次整个网络炸了锅，网络管理员迅速手工输入了几台重要客户端主机的IP地址，但200台的客户端主机数量让他非常恐惧。
他设计了个非常简单的方法，如图3-39所示，只要设定服务器排除掉重叠的IP地址段就可以了。

图 3-39 50/50故障转移方法
每台服务器包覆盖了整个网络中所有IP地址的范围，Server A 的作用域被配置成排除了192.168.100.1到192.168.100.125范围以外的所有IP；而Server B的作用域被设置成负责后一半IP地址的范围。
这种方法的优点为DHCP环境建立了某种程度的冗余，同时无需为客户端保留额外的IP地址作用域。但是要将这种方法付诸于实践之前，某些DHCP服务的限制还需要我们仔细斟酌。
从理论上讲有某一台服务器距离大多数客户端较近，因此多数的客户端被定向到这台服务器，千分之一秒的差距使得另外一台服务器无法得到负载均衡的功能。在理论上这将导致它的DHCP地址池很快就处于饱和状态，之后，另外一台DHCP服务器才开始接受客户端请求。如果Server A 不能提供服务了，Server B 所能提供的IP地址范围也不能够完全处理200台客户端的请求。
注意这是在同一子网网段上的范例，我想这个网络非常适用于100台左右的网络规模，这样的话每台服务器所能分配的地址空间是所需的1倍以上，而排除地址范围后，就能够实现Server A和Server B无缝配合了。
3.4.2 DHCP容错80/20故障转移
实现 DHCP 远程故障转移的另一种方式是在企业网络中使用两个 DHCP 服务器，使二者共享一个基于 80/20 规则的分隔作用域配置。
为了确保DHCP的可用性，往往在不同的网段均安装一台DHCP。各网段的DHCP遵循80/20原则，即：本地网段的80%地址由本地网段的DHCP负责，其余20%的地址由另一个网段的DHCP负责。具体实现的方法是将负责本地网段的DHCP上排除掉那20%的地址，另一个网段的DHCP上排除掉那80%的地址。
下面这个企业的网络就采用了80/20的容错机制，如图3-40所示。

图 3-40 80/20故障转移方法
不过这样的网络设计也存在局限性。以北京建国门办公网络的DHCP服务器为例，如果它停机时间过长，它也许会耗尽北京大兴工业园区DHCP服务器的客户端租约，导致两地的客户端都不能续约。因此，作为负责80%的服务器应制定灾难恢复计划，将停机时间缩至最短。
提示：80/20规则是微软所建议的分配比例，在实际应用时可以根据情况进行调整，比如70/30 的比例。另外，在一个子网中的两个DHCP服务器上所建的DHCP作用域不能有地址交叉的现象。
3.4.3 DHCP容错100/100故障转移
在讨论这个方法前，你必须要有足够多的IP地址可供客户端使用，通常需要超过实际客户端数量的2倍或者更多。有人会问，这可能吗？对于已经被总公司规划好的网络，仅仅有限的IP地址范围可供分公司使用，这是不可能实现100/100的DHCP设计，但对于那些拥有自主权，或者没有对整个网络中的IP地址进行配置的网络来说，使用专用的网络配置（10.x.x.x）是可以实现这种理想化的目标的。
下面是一所工商管理学院的DHCP规划案例。他们采用了最简单的100/100故障转移方法，包括了两台运行着DHCP的服务器，每台服务器都为公司的同一个子网分配IP地址，但是，每台服务器上的作用域包含有地址不同而容量相同的IP范围，如图3-41所示。

图 3-41 80/20故障转移方法
这两台服务器中的一台服务器（Server A）中断后，第二台服务器（Server B）将会接管它的工作，对客户端做出响应。这样的话，客户端的IP地址就将被分配到10.88.5.0-10.88.8.254的范围了。这里唯一的一个缺点是所有在企业中的网关设备的网络接口和路由条目，都需要拥有至少两套方案中的IP管理方法。
这对于Windows系统管理员可以轻松了许多，但对网络管理员来说这将是一件非常麻烦的事，只要他不骂你，就能够实现这样的完美结局。
3.4.4 DHCP中继服务器规划建议
在大型网络上安装中继代理之前，需要考虑一些重要的设计问题。
当你有多个 DHCP 服务器时，Microsoft 建议你将 DHCP 服务器置于不同的子网上而不是将所有的服务器置于一个子网上，以获得更强的容错能力。服务器在其作用域中不应有公用的 IP 地址（每个服务器应有唯一的地址池）。
如果本地子网上的 DHCP 服务器关闭，请求将被转发到远程子网。如果该位置的 DHCP 服务器维护着请求子网的 IP 地址作用域，它将可以响应 DHCP 请求。如果远程服务器没有为请求子网定义作用域，那么即使它有其他作用域的可用地址，也不能提供 IP 地址。如果每个 DHCP 服务器有用于每个子网的地址池，则它能为其自己 DHCP 服务器脱机的远程客户端提供 IP 地址。
1．推荐的设计思路
为获得最佳路由型 DHCP 网络性能，建议采用图3-42中继代理实现方法。使用连接于两个不同子网的两台 DHCP 服务器。在每个用于连接子网的路由器上运行的中继代理有不同的延迟间隔（一个设置为 4 秒，另一个不使用延迟）。它通过随机选择的网络路径排除了不希望出现的 DHCP 数据包溢出危险。

图3-42 最佳路由型 DHCP 网络
2．不推荐的实现方法
不推荐下列中继代理实现方法，如图3-43所示。它与上例有相同数量的 DHCP 服务器和子网，但使用时的警告更少。DHCP 客户端启动时广播的 DHCP 查找消息（DHCPDISCOVER）存在较大风险，它们在前往其他子网时可以随意被转发或复制。另外，中继代理不使用任何延迟间隔，这将会增加中继代理（路由器）复制任何客户端广播消息的可能性，并可能导致远程子网拥塞。

图 3-43 DHCPDISCOVER消息随意转发
3.4.5 待机作用域的方法
待机DHCP服务器就是安装了一台DHCP服务器，我们配置了作用域，但没有启用。这和前面的几个例子有些不同，我们可以设置相同的作用域范围，但备用的DHCP服务器通常都处于休眠状态，直到生产网络上的DHCP牺牲后才唤醒它。当出现问题的时候，只要激活睡眠状态的作用域。可以使用网络管理工具以及编成实现自动化的激活程序。
提示：有一定基础的系统管理员应学习一些命令行工具，这些工具的效率非常高，比如使用netsh dhcp server [\\ServerName] SubCommand 命令就可以管理DHCP服务器，例如“Dhcp Server 192.168.1.20 Scope 192.168.29.0 set state 1” 可以激活待机DHCP服务器上的192.168.29.0 作用域。
3.4.6 真正的冗余是群集服务
DHCP的最后一种冗余设计就是部署一个群集服务器组（Clusters）来运行DHCP，和上面所有的规划设计相比，这才是真正的冗余设备，不过也是最昂贵的（需要增加双机共享存储设备）的方法。
群集的优点之一就是运行在服务器群集上的应用程序和服务可以用虚拟服务器的形式出现在用户和工作站面前。用户和客户端在连接到以群集化的虚拟服务器形式运行的应用程序或服务时，就如同连接到一台物理性的服务器。
事实上，群集中的任何节点都可以接受这样的虚拟服务器连接。用户或客户端不会知道虚拟服务器真正驻留在哪个节点上。一旦DHCP应用程序或服务器发生故障，群集服务就会将整个虚拟服务器资源组转移到群集中的另一个节点上。在发生这样的故障时，客户端将会同该应用程序的会话中检测到故障，并且试图用与先前连接完全一致的方式进行重新连接。由于群集服务在恢复操作中可以简单地将虚拟服务器的公开 IP 地址映射到群集中幸存的节点，因此客户端的上述努力将可以获得成功。客户端会话不必知道相关的应用程序现在是否已实际驻留到了群集中的不同节点上就可以重建同该应用程序的连接。
动态主机配置协议（DHCP）服务算是群集服务中最基本的一个。DHCP 客户端的 IP 地址租约信息保存在 DHCP 数据库中。如果 DHCP 服务器资源发生故障，上述 DHCP 数据库将可以被转移到群集中可用的节点上，DHCP 数据库的内容不会变更。详细内容请看本书中关于Windows 群集服务配置的章节案例。

本文转自张琦51CTO博客，原文链接：http://blog.51cto.com/zhangqi/90372 ，如需转载请自行联系原作者