|
随着网络在生活中适用面越来越广，使得大部分的网络服务器在固定时间内所需处理的客户请求在不断的增多。目前广泛实施的DHCP逻辑框架--即基于failover草案的双机服务模型，已不可能再进一步的优化，只能通过硬件设备的改良来提升服务效率。所以引入新逻辑框架来解决目前DHCP服务面临的瓶颈是有其必要性的。 现有的DHCP的多处理机服务设计主要是两种，其一是将所有的数据保存在数据库，数据存取以及数据查询都交由数据库来完成；另一种是将服务器的IP池划分为若干个IP段，每一段由一个服务器来负责IP地址的分配，同时每台服务器采用多线程来并行处理客户请求以及1∶N的冗余方案来应对服务器崩溃的情况。目前所有集群化服务的设计中，共享存储的应用较为广泛，实现方式主要分为基于高速缓存行的硬件实现和基于虚存页的软件实现，以及目前应用较多的存储结构主要是两大类：NUMA（non-uniform MemoryAccess，非一致访存结构）和COMA（CacheOnly Memory Architecture，唯高速缓存结构）。前者的做法是：每一个共享页都有固定的主节点，每一个处理机需要资源时都是从主节点处获取该共享页的备份，除此之外所有的处理机都必须根据一致性协议将相对于主节点的页差（diff）传回到主节点进行数据更新。诸如JIAJIA、Cashmere等系统都是基于该存储结构来实现的；后者则不是基于主节点的对称存储结构。其思想是：每一个拥有该共享页的处理机都将保存这个共享页和相应的diff，如果一旦其他的处理机需要该共享页时，就会向当前所有持有该共享页的处理机发出请求，持有该页的处理机就会将共享页和diff一起发送到请求源。ThreadMarks、CVM等系统都是基于这种方法来实现的。 本文的方案的设计场景是在一个局域网内--实现基于局域网内的DHCP服务集群化，如图1所示。将所有的DHCP服务器放置在同一个网段。采用共享存储的方法来实现多处理机的数据的一致性。虽然是基于局域网的DHCP集群化服务，但是对于今后的DHCP云服务的思想有一定程度上的吻合，所以姑且可以将本文看成是DHCP云服务的小范围尝试。
系统设计 用共享存储的方法来实现集群化服务，设计主要分为三个部分：资源组织模型、资源存储方式以及一致性方案的设计。资源的组织模型主要是以什么样的形式调度以及分配共享资源。由于本文的设计是基于软件实现，所以采用虚存页的组织模型。资源存储方式主要是资源如何存取，涉及到I/O速率以及系统消耗等问题。一致性方案的设计是方案的核心和实现共享存储的必要条件。 资源存储结构 由于在DHCP服务中IP池的信息是不可以被修改的，服务过程中需记录的是IP地址与其被分配对象的信息（客户的MAC地址）的配对信息。所以借鉴NUMA存储方式，初始时将IP资源按照合适的页单元进行划分，将所有的资源存储在一个固定的区域--主节点。之后主节点分配初始资源给服务器。根据通信协议，在运行一定时间后要将页差（diff）写回到主节点上进行数据更新。处理器产生缺页事件时，就会向主节点发出请求，这时主节点会根据空闲资源的情况，进行资源的再次分配。 数据一致性设计 基于上文资源存储方式的设计，要实现数据一致性，必须规定每一个共享页内的IP资源的分配权在同一时间有且只能被一台服务器所拥有，相当于给共享资源加了修改权限。共享页的修改权限只有主节点才能进行分配。所以实现DHCP服务的共享存储必须满足以下两个条件： 1.在主节点获得最新的diff并且更新完共享页的信息之后，主节点才能将共享页的修改权限进行分配； 2.服务器在分配共享页内的资源之前必须从主节点获得该页最新的内容的映射以及该页的修改权限。 系统运行流程 系统初始时，主节点先将所有的IP段资源按照页单元划分。然后按照一定的规则给每一个服务器分配共享页的映射并且也分配该共享页的修改权限。在系统运行一段时间之后，根据通信协议（如时间片轮转）处理器将每一个共享页的diff写回，同时要交还该共享页的修改权限。主节点在更新完共享页内容之后，需返回一个确认信息给服务器，同时将该页的修改权限再次分配给原服务器。该系统中服务器的缺页请求一般是资源不足需要新的共享页。如果主节点的空白页仍有空余，则直接分配给请求服务器。若没有空白页的话，则需要从其他的服务器回收资源未完全利用的共享页（具体回收算法根据具体的使用场景而定），回收完之后再将其分配给请求服务器；详细的流程见图2。
服务器与主节点通信机制 1.服务器注册：新服务器加入系统时，必须向主节点发送注册请求。然后主节点更新服务器表后，分配给服务器Server ID以及初始的共享页资源。服务器在收到之后返回确认信息。 2.服务器写回：服务器在使用共享页一段时间后（时间片耗尽），需将共享页的diff以及共享页的权限写回到主节点。主节点在更新共享页的信息以及重置服务器的写回时间片之后，发送确认信号。如果写回的共享页有资源被分配出去，则将共享页的权限返回给原服务器，服务器接收到之后重置写回时间（服务器的写回时间小于主节点的写回时间）。在该时段，服务器将不会接收新的客户请求（即REQUEST），直到服务器更新完内存资源。 3.确认服务：借助服务器写回机制，如果服务器超过主节点的写回时间都没有写回，则主节点发出确认服务信号。确认服务信号发出三次之后服务器还是没有响应，主节点确认该服务器停止服务，主节点将该服务器所所有的共享页修改权限重置，并且再次分配。 4.服务器缺页：服务器资源不足的时候向主节点发出资源请求。主节点在资源整理之后，将共享页的映射以及修改权限分配给缺页服务器。 5.主节点强制写回：主节点在空余资源不足却仍需要分配资源给缺页请求服务器时，根据回收算法选择一个已分配的未完全利用的共享页来回收。主节点发出信号之后，服务器将diff以及修改权限写回主节点，主节点更新完之后返回确认信号。 6.服务器注销：服务器停止工作时，发送注销信号给主节点。主机接收到之后发出响应信号，服务器停止接收客户请求，并将所有的共享页的diff以及修改权限写回主节点。主节点接收到之后返回确认信号。服务器注销成功。 功能拓展 前文的设计都是基于局域网内的设计，但是方案的前提是局域网内服务器处理的客户请求都是来自同一类型的客户，即所需的服务内容是一样的，仅仅是所获得的IP地址有所区别。而通常来说客户的需求往往是不同的，诸如VIP和普通用户是不一样的。要实现这些可以根据划分不同IP地址段来实现。具体的可以将VIP用户的可以被分配到的IP划分到一起，交由一个局域网内的服务器进行分配，其余类型的IP地址交由另一个局域网内的服务器来分配。之后将每一个局域网通过一个消息总线将其串接起来，而具体如何去区分请求用户的类别，则交由总线控制器来完成。这也就实现了服务的分类。整体架构如图3所示。
设计的主要问题 由于服务器是周期性的将共享页写回到主节点，主节点内共享页的信息实时性不强，服务器故障将会出现重复分配IP的情况。但是过于频繁的写回主节点，这就对DHCP服务的效率产生不利的影响。所以写回周期的选取对于系统性能是十分重要的。目前主流的DHCP服务设计是在单台服务内用多线程的方法来实现并发，而该方案则是在多个服务器间实现并发处理。后者对硬件依赖更小，费用较为便宜，资源利用率更高。由于周期性写回机制的存在，而线程间的信息交互的时间损耗几乎可以忽略不计，所以在客户数目变化不大的情况下，前者的服务效率更佳。 本文主要介绍了一种基于局域网内的DHCP服务集群化方案。涉及到共享存储的各方面知识同时详细介绍了方案的整体设计。虽然该方案仍然存在不完善的地方，但是希望能对今后的DHCP服务的拓展有所帮助。 （作者单位为北京邮电大学网络技术研究院） |
