OpenStack Designate系统架构分析

前言

OpenStack提供了云计算数据中心所必不可少的用户认证和授权、计算、存储、网络等功能，网上已经有不少的文章介绍这些功能的配置、架构分析以及代码详解。但是,针对OpenStack Designate所提供的DNSaaS服务，却只有Designate项目主页上一篇很简单的文档介绍其安装、架构和API列表。由于Designate项目还处于孵化阶段，文档的更新和维护并不是特别及时，本系列文章将试图解释Designate架构、安装、配置、以及探讨更深层次的设计细节，算是填补一下空白吧。这篇文章将是该系列的第1篇，着重介绍Designate的整体架构以及各个功能模块，了解各个功能模块之间如何协调工作。

Designate项目背景介绍

大型数据中心都提供了云域名系统，如Amazon的AWS Route53，Google的Cloud DNS, Rackspace也提供了Cloud DNS。这些域名系统都能够让用户将自己的域名托管到云服务商的数据中心域名系统中，用户无需自己租赁设备构建自己的DNS系统，降低了运维和管理成本。

OpenStack Designate提供了DNSaaS（DNS即服务）的功能，其目标就是要赋予OpenStack提供这种云域名系统的能力，云服务商可以使用Designate就能够很容易建造一个云域名管理系统来托管租户的公有域名。

Designate目前尚处于孵化阶段，曾经使用过Moniker这个名字，主要由HP贡献到OpenStack开源社区。到目前（2015年5月）为止，已经发布了stable/kilo版本，项目源代码托管在GitHub上（https://github.com/openstack/designate）。

Designate整体架构

Designate从kilo版本，软件架构发生了很大的变化，引入了pool manager机制，对DNS服务器进行池化管理。同时通过MiniDNS进行DNS区域和资源记录同步。下图给出了Designate的功能模块图，各模块之间通过消息队列进行通信。

• API：接收来自远端用户的HTTP/HTTPS请求，通过Keystone验证远端用户的合法性，将HTTP/HTTPS请求传递给Central模块。
• Central：业务逻辑处理核心。响应API请求以及处理Sink所监听到的来自Nova和Neutron的特定通知事件。同时会存取数据库，对业务逻辑处理所产生的数据进行持久化存储。
• Pool Manager：连接后端驱动，管理DNS服务器池，与MiniDNS配合同步DNS服务器的域名以及资源记录等数据。
• MiniDNS：实现了标准的DNS Notify和Zone Transfer的处理，后面将用一个例子介绍Pool Manager和MiniDNS如何配合实现域名配置与域名记录同步的工作原理。
• Backend：后端驱动，已经支持多种DNS后端服务器，包括BIND、PowerDNS、MySQL BIND等。
• Sink：监听来自Nova和Neutron的某些事件，用于自动生成域名资源记录，比如当监听到Nova的compute.instance.create.end事件通知后，自动创建一条对应于刚创建的实例的A记录；当监听到Nuetron的floatingip.update.end事件通知后，自动更新一条相应的A记录。

Desingate各个功能模块之间的通信使用AMQP消息队列机制。AMQP消息队列接收来自各个功能模块的RPC请求，并将RPC请求投递到目标功能模块，作为联络各个功能模块的神经中枢。

DNS服务器的池化管理

Designate kilo版本所引入的pool manager机制将DNS服务器群划分成多个服务器池（pool），如下图所示，每个服务器池可以配置包含1台或多台DNS服务器。而且，池中的DNS服务器选型还可以不同，也就是说在一个服务器池中，可以有1台BIND服务器，还可以有1台PowerDNS服务器，这是完全支持的。

服务器池的引入对于构建大规模的云级DNS系统是非常高效的，优点是显而易见的。

1. 细化域名托管的颗粒度。用户请求托管的域名可以委派到某一个服务器池，而不需要在所有服务器上管理用户的域名和资源记录，降低了管理和运维的复杂度。例如，abc.com委派给pool 1的DNS服务器来管理，xyz.com委派到pool N的DNS服务器来管理，……
2. 每个服务器池可以包含多台DNS服务器，实现了高可用性和冗余备份。
3. 服务器池的划分不受地域的限制，可以将分布在不同地域的DNS服务器划归到同一个池中，通过GLB和anycast路由技术可以实现就近DNS查询和负载均衡，加快DNS查询速度。

MiniDNS：Hidden Master设计

Hidden Master是DNS网络安全管理系统设计中所推荐的一种最佳实践。主DNS服务器“隐藏”在内网防火墙背后，负责DNS域名资源的管理并同步变更到从DNS服务器；从DNS服务器部署在DMZ区域，对外提供DNS查询服务。由于主DNS服务器不接受DNS查询，增强了安全性。

Designate MiniDNS功能模块就采用了Hidden Master的设计思想。所有托管到Designate中的DNS域都将MiniDNS视为主DNS服务器，而其被委托的DNS服务器都作为从DNS服务器。MiniDNS实现了标准的DNS Notify和Zone Transfer协议，负责同步DNS域名资源记录到从DNS服务器上。

下面，我们以创建一个DNS域名为例来详细介绍MiniDNS的工作过程。

序列图给出了简要的过程描述。详细的文字说明如下：
1. 首先，用户通过Desingate API创建一个example.com的DNS域；
2. Designate API将请求传递给Central，Central先将example.com域保存到数据库，接着发送RPC请求给Pool Manager；
3. Pool Manager收到来自Central的创建域名的请求之后，调用DNS后端驱动，在该域名被委托的服务器池中的所有服务器中创建example.com域。同时在这些服务器中，指定example.com的master服务器是MiniDNS；
4. Pool Manager完成所有从服务器上example.com域的创建之后，发送RPC请求给MiniDNS。
5. MiniDNS收到Pool Manager的RPC请求之后，向从服务器发送DNS Notify消息，告诉从服务器example.com有资源更新。
6. 从服务器收到DNS Notify消息后，要求主从数据库启动Zone Transfer，域迁移的方式可以是AXFR，也可以是IXFR。
7. 主服务器从数据库中读取为example.com域自动创建的SOA和NS记录，并将SOA和NS记录传送到从服务器。
后续任何对example.com域的变更操作都会遵循上述过程，由MiniDNS将变更同步到Designate所委派管理example.com域的DNS服务器上。

结束语

本文简单介绍了Designate所提供的DNSaaS的系统框架及其各个功能组件，在了解了Designate系统架构之后，该系列的第2篇文章将介绍Designate的安装、配置以及DNS服务器的部署。

欢迎转载，转载请说明原处！