OpenStack Designate简介

2019-03-04

本文主要简单介绍下Designate的部署过程,Designate与后端dns server的同步过程以及涉及到的DNS相关内容

1. Designate安装步骤

1.1 创建user，service，endpoint

1. create user:
openstack user create --domain local --password-prompt designate
2. create service:
openstack service create --name designate --description "DNS" dns
3. add role:
openstack role add --project service --user designate admin
4. create endpoint(internal,public,admin): openstack endpoint create --region RegionOne 
dns public http://controller:9001/

1.2 配置数据库:

mysql -u root -p
mysql> CREATE DATABASE designate CHARACTER SET utf8 COLLATE utf8_general_ci;
mysql> GRANT ALL PRIVILEGES ON designate.* TO 'designate'@'localhost' 
IDENTIFIED BY 'DESIGNATE_DBPASS';
mysql> GRANT ALL PRIVILEGES ON designate.* TO 'designate'@'%' 
IDENTIFIED BY 'DESIGNATE_DBPASS';

1.3 安装designate bind9

1 2	sudo apt-get install designate(包括designate-api/agent/central服务) sudo apt-get install bind9 bind9utils bind9-doc

1.4 配置Bind9

1	rndc-confgen -a -k designate -c /etc/designate/rndc.key

配置/etc/bind/named.conf.options
（可能需要修改/var/cache/bind的权限）

include "/etc/designate/rndc.key";
options {
directory "/var/cache/bind";
allow-new-zones yes;
request-ixfr no;
listen-on port 53 { 127.0.0.1; };
recursion no;
allow-query { 127.0.0.1; };
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "designate"; };
};

重启bind9
service bind9 restart

1.5 配置Designate

/etc/designate/designate.conf

[oslo_messaging_rabbit]
rabbit_userid = test
rabbit_password = eb53962sAusren418Dab
#rabbit_virtual_host = /
#rabbit_use_ssl = False
rabbit_hosts = 192.168.111.162
[service:api]
# Number of api worker processes to spawn
#workers = None
# Number of api greenthreads to spawn
#threads = 1000
# Enable host request headers
#enable_host_header = False
# The base uri used in responses
api_base_uri = http://192.168.111.162:9001/
# API bind host+port pairs, comma separated
listen = 192.168.111.162:9001
# Maximum line size of message headers to be accepted. max_header_line may
# need to be increased when using large tokens (typically those generated by
# the Keystone v3 API with big service catalogs).
#max_header_line = 16384
# Authentication strategy to use - can be either "noauth" or "keystone"
auth_strategy = keystone
# Enable Version 1 API (deprecated)
enable_api_v1 = True
# Enabled API Version 1 extensions
# Can be one or more of : diagnostics, quotas, reports, sync, touch
enabled_extensions_v1 = quotas, reports
# Enable Version 2 API
enable_api_v2 = True
# Enabled API Version 2 extensions
enabled_extensions_v2 = quotas, reports
[keystone_authtoken]
auth_url = http://192.168.111.162:35357/v3
project_name = service
username = designate
password = vmware
project_domain_id = 20dd11ec4ebb4d87b7c772c07c775824
user_domain_id = 20dd11ec4ebb4d87b7c772c07c775824
memcached_servers = 192.168.111.162:11211
auth_type = v3password
service_token_roles_required = True
[storage:sqlalchemy]
connection = mysql+pymysql://designate:DESIGNATE_DBPASS@controller/designate

1.6 DB sync

1	designate-manage database sync

1.7 重启Designate服务

1 2	service designate-central restart service designate-api restart

1.8 配置Designate pools.yaml

创建/etc/designate/pools.yaml

- name: default
    # The name is immutable. There will be no option to change the name after
    # creation and the only way will to change it will be to delete it
    # (and all zones associated with it) and recreate it.
    description: Default Pool
    attributes: {}
    # List out the NS records for zones hosted within this pool
    # This should be a record that is created outside of designate, that
    # points to the public IP of the controller node.
    ns_records:
        - hostname: ns1-1.example.org.
          priority: 1
    # List out the nameservers for this pool. These are the actual BIND servers.
    # We use these to verify changes have propagated to all nameservers.
    nameservers:
        - host: 127.0.0.1
          port: 53
    # List out the targets for this pool. For BIND there will be one
    # entry for each BIND server, as we have to run rndc command on each server
    targets:
        - type: bind9
            description: BIND9 Server 1
            # List out the designate-mdns servers from which BIND servers should
            # request zone transfers (AXFRs) from.
            # This should be the IP of the controller node.
            # If you have multiple controllers you can add multiple masters
            # by running designate-mdns on them, and adding them here.
            masters:
                - host: 127.0.0.1
                port: 5354
                # BIND Configuration options
            options:
                host: 127.0.0.1
                port: 53
                rndc_host: 127.0.0.1
                rndc_port: 953
                rndc_key_file: /etc/designate/rndc.key

1.9 更新pool并部署designate其他服务

1 2	su -s /bin/sh -c "designate-manage pool update" designate sudo apt-get install designate-pool-manager designate-zone-manager designate-sink designate-mdns

2. 结果验证

创建zone：
openstack zone create --email dnsmaster@example.com example.com.
创建recordset：
openstack recordset create --records '10.0.0.1' --type A example.com. www
更新recordset：
openstack recordset set 27b0d2ac-d856-4ef7-8a6d-3a9e153e4609 e5d26292-207e-43f2-8487-e14064523899 --no-ttl --records 10.0.0.2

3. Designate 架构分析

注: designate-worker取代了之前的designate-pool-manager, designate-producer取代了之前的designate-zone-manager

各服务简介：

designate-api: 提供标准的REST API服务。通过keystone对请求进行认证，对于认证通过的请求通过rabbitmq发送给designate-central服务。
designate-central:该服务用来处理RPC请求。将接收到的来自API服务的RPC请求写入数据库。
designate-producer:该服务取代了之前的“designate-zone-manager”服务。现在实现的task主要有：发送dns.zone.exists事件给ceilometer，从数据库purge已经删除的zone，轮训secondary zones在刷新间隔，生成延时NOTIFY transactions，定期recover处于ERROR状态的zone
designate-worker:该服务取代了之前的“designate-pool-mananger”服务。该服务通过读取数据库中pool的信息（通过pools.yaml加载到数据库中）。对接后台DNS服务器（bind9,powerdns,infoblox等），实现对zone/recordset的创建删除和更新。
designate-sink: 监听events Notification，handlers are available for Nova and Neutron. Notification events用来进行record的创建和删除
designate-mdns: 用于发送DNS NOTIFY消息以及answer zone transfer request（AXFR），mdns还支持发送SOA queries来check某一个change是否live。mdns可以通过标准的dns 协议与后端的dns server进行通信。
当zone内容发生变化时，designate-mdns给后端的dns server发送NOTIFY消息，告诉后端的DNS server我的zone发生变化了，后端dns server然后发送AXFR的消息来获取全量的zone信息，然后designate-mdns就会回答AXFR。
designate-agent: 利用DNS协议实现对zone的create/delete/update。pools.yaml里面配置type为agent。就会利用designate-agent实现对dns zone的管理。

4. DNS工作过程

这部分介绍DNS工作过程，首先看一下日常中经常接触的DNS server。DNS server大体上可以分为两类。

一类是管理DNS zone的DNS server，称为Authoritative DNS server。这些DNS Server只掌握了一个或者多个DNS zone的信息，不能为我们提供整个互联网的DNS信息。
另一类是Cache DNS server。这类DNS server不管理DNS zone，但是连接Authoritative DNS server，并且缓存从Authoritative DNS Server获取的信息。最典型的就是谷歌的8.8.8.8。

假设我的电脑配置的DNS server是8.8.8.8，我需要访问 www.zhihu.com 首先我的电脑要获取 www.zhihu.com 的IP地址，需要经过下面所示的步骤：

向8.8.8.8请求获取 www.zhihu.com 的IP地址。如果8.8.8.8包含了 www.zhihu.com 的IP地址记录，则直接跳到步骤8。
8.8.8.8所在的Cache DNS server并没有 www.zhihu.com 的记录，所以它向Authoritative DNS server请求数据。首先发往Root DNS server，这是全球共有的13个逻辑服务器，每一个是由一个集群构成。
Root DNS server实际上没有 www.zhihu.com 的记录，也不可能有，因为全球的DNS记录不可能集中在一起，这在性能上是不能接受的，并且这样就跟之前的hosts.txt文件也没有区别了。不过由于需要解析的是 www.zhihu.com Root DNS server知道如何到达“.com”的DNS Server，也就是TLD（Top-Level Domain）DNS server。因此将TLD DNS server的信息也就是“.com”的DNS server地址发送给8.8.8.8。
8.8.8.8收到了TLD DNS server的地址之后，继续向“.com” 的DNS server请求数据。
TLD DNS server 仍然没有 www.zhihu.com 的信息，但是TLD DNS Server知道zhihu.com的DNS server，于是TLD DNS Server将zhihu.com的DNS server地址发送给8.8.8.8。
8.8.8.8收到了DNS server地址之后，继续向 zhihu.com 的DNS server请求数据。
管理zhihu.com的Authoritative DNS server有 www.zhihu.com 的记录，于是将对应的IP地址发送给8.8.8.8。
8.8.8.8拿到了 www.zhihu.com 对应的IP地址，首先记录在本地缓存，这样下次不用再走一遍234567，接着将IP地址发送给请求主机。
主机拿到IP地址之后，向IP地址所在的Server发送实际的HTTP请求。

5. DNS主备同步过程

在Designate与后端bind9/powerdns对接时，designate充当了DNS master的属性，而后端的真实dns server bind9/powerdns充当了slave的角色。master和slave之间通过dns协议实现同步

dns协议简介：

AXFR：授权转移(Authoritative Transfer)，用于传输区域(zone)的信息。AXFR应答报文由一系列(包含1)DNS报文组成，其中第一条报文及最后一条报文需要包含区域的SOA资源记录，中间的报文为该区域(zone)的资源记录信息，如可以包含NS类、A类、CNAME类记录等。
IXFR：增量区域传输(Incremental Zone Transfer)，与AXFR一样用于传输区域(zone)的信息，但只传输增量数据。主要用于DNS NOTIFY。
NOTIFY：用于Master向Slave通知区域信息变更。默认使用udp传输，Master可以指定使用tcp传输。区别是，tcp方式只发送一次notify，超过响应等待时间后返回超时；而udp方式会定期发送notify，直到发送了过多的副本(即超时)或者收到了对应的回复。

例子：

Master与Slave之间使用DNS NOTIFY机制同步数据过程

当Master区域信息变更后，向Slave发起notify的请求
Slave响应notify请求
Slave向Master请求SOA信息
Master应答SOA请求
Slave根据自己的SOA序列号以及由Master处请求到的SOA序列号，判断自己是否需要变更(注：如果双发的SOA序列号一致，那么即使区域信息是有区别的，Slave也不会向Master发起更新请求)，如果需要变更，则向Master发起IXFR请求，期望同步区域信息到Master的那个版本。其中SOA表示了区域授权的起始，它包含了名字服务器域名(mname)、区域负责人邮箱域名(rname)、序列号(serial)、刷新时间(refresh)、重试间隔(retry)、过期时间(expire)、最小ttl时间(minimun，bind8.2之后已由第一行的TTL代替)。
Master应答了Slave的IXFR请求，返回了两个版本区域信息的增量记录

参考文献

https://www.sdnlab.com/19900.html