Jump to: navigation, search

Difference between revisions of "Designate/Blueprints/Server Pools"

(Phase One)
(Sub Blueprints)
 
(24 intermediate revisions by 5 users not shown)
Line 1: Line 1:
== Overview ==
+
== Archive ==
 +
[[Designate/Blueprints/Server_Pools/Archive|Previous Proposal]]
 +
= Server Pools Overview =
 +
== Why ==
  
== Current State ==
+
Server Pools are required for a few different scenarios:
=== Phase One ===
 
{| class="wikitable"
 
|-
 
! Gerrit Patch || [[https://review.openstack.org/#/c/47397/]]
 
|-
 
! Launchpad Blueprint || [[https://blueprints.launchpad.net/designate/+spec/initial-server-pools]]
 
|}
 
  
This is an initial change to the codebase to introduce the concept of a "server pool"
+
=== Private Pools ===
  
This has introduced a new service that sits where the agent would have traditionally sat for bind9
+
This allows users to have 'private' DNS servers. These servers would typically allow non standard TLDs (.dev , .local etc), and may not have the same level of blacklist restrictions.
 +
They would be aimed at people with Neutron Networking, and VPC style set ups, where access to the DNS server would come from trusted networks (eg, in-cloud - owned instances, and VPN'd onsite resources)
  
This has caused all servers and domains to assigned to a "pool", which we will use in the future to submit changes to the right pools.
+
This would allow customers to set DNS entries for internal servers, on domains that would not be available on the public pools, and have them accessible by internal users
  
''' Phase One State Diagram '''
+
=== Distribution ===
[[File:Pool-Manager-State.png|border|Phase One Server Pools State Diagram]]
 
<br />
 
<br/>
 
  
 +
Having multiple public pools with the same capabilities, would allow the scheduler to distribute zones across multiple infrastructures.
  
==== API v2 Changes ====
+
=== Features / Premium Systems ===  
  
Servers are now a full sub resource of pools, and are accessed using HTTP requests like:
+
By using scheduler hints, we can mark different pools as having different capabilites - such as GeoIP / Round Robin DNS / Anycast.
  
  GET http://designate-server:9001/v2/pools/<pool_id>/servers - get all servers in <pool_id>
+
This allows operators to run different DNS infrastructures as required. For example this allow users to have some zones on pools with GeoIP, and pay a premium for this feature, while having the rest of their zones on a cheaper 'standard' tier.
  GET http://designate-server:9001/v2/pools/<pool_id>/servers/<server_id> - get <server_id> details
 
 
 
  
This was to avoid massive amounts of changes to SOA records for domains, and allowing us to notify backends [[https://review.openstack.org/#/c/45078/]] of just the server that changed.
+
== What ==
  
==== Phase One limitations ====
+
Pools will be broken down into 'types'. This will be an extensible list - by using plugins to define types.
  
# Currently there is only support for one pool
+
=== Static ===
# This is currently a synchronous operation - async will be in a later phase
+
This would be similar to what we have today - a public pool that is maintained by adding servers, and then informing designate of the server name.
# When designate is set up / upgraded for the first time, you will need set up a default pool in the /etc/designate/designate.cfg file.
+
 
## There is a default pool created in the SQLAlchemy migrations, so this will just copying and pasting the pool_id into the right section in the config file.
+
=== Nova ===
 +
These would be dynamically created pools, generally used for private pools, that would have the server name / IP defined by nova / neutron.
 +
 
 +
We would need to extend the information in the server pools API to allow setting information like what neutron network / subnet to connect to, and any extra info required.
 +
 
 +
== How ==
 +
=== General Overview - Basic Info Flow ===
 +
[[File:Designate-MiniDNS-Pools.gif|framed|center|Information Flow]]
 +
 
 +
Single Frames are here [https://imgur.com/a/CawLd]
 +
 
 +
= Sub Blueprints =
 +
# [[Designate/Blueprints/Server_Pools/Central|Central Support]]
 +
# [[Designate/Blueprints/Server_Pools/API|API]]
 +
# [[Designate/Blueprints/Server_Pools/Storage|Storage]]
 +
# [[Designate/Blueprints/Server_Pools/Service|Pool Manager Service]]
 +
# [[Designate/Blueprints/Server_Pools/DNS_Notify|Pool Manager DNS Notify Support]]
 +
# [[Designate/Blueprints/Server_Pools/MiniDNS|MiniDNS Support]]
 +
# [[Designate/Blueprints/Server_Pools/Scheduler|Scheduler]]
 +
# [[Designate/Blueprints/Server_Pools/Dynamic_Pool_Interface|Dynamic Pools Creation Interface]]

Latest revision as of 17:40, 17 February 2014

Archive

Previous Proposal

Server Pools Overview

Why

Server Pools are required for a few different scenarios:

Private Pools

This allows users to have 'private' DNS servers. These servers would typically allow non standard TLDs (.dev , .local etc), and may not have the same level of blacklist restrictions. They would be aimed at people with Neutron Networking, and VPC style set ups, where access to the DNS server would come from trusted networks (eg, in-cloud - owned instances, and VPN'd onsite resources)

This would allow customers to set DNS entries for internal servers, on domains that would not be available on the public pools, and have them accessible by internal users

Distribution

Having multiple public pools with the same capabilities, would allow the scheduler to distribute zones across multiple infrastructures.

Features / Premium Systems

By using scheduler hints, we can mark different pools as having different capabilites - such as GeoIP / Round Robin DNS / Anycast.

This allows operators to run different DNS infrastructures as required. For example this allow users to have some zones on pools with GeoIP, and pay a premium for this feature, while having the rest of their zones on a cheaper 'standard' tier.

What

Pools will be broken down into 'types'. This will be an extensible list - by using plugins to define types.

Static

This would be similar to what we have today - a public pool that is maintained by adding servers, and then informing designate of the server name.

Nova

These would be dynamically created pools, generally used for private pools, that would have the server name / IP defined by nova / neutron.

We would need to extend the information in the server pools API to allow setting information like what neutron network / subnet to connect to, and any extra info required.

How

General Overview - Basic Info Flow

Information Flow

Single Frames are here [1]

Sub Blueprints

  1. Central Support
  2. API
  3. Storage
  4. Pool Manager Service
  5. Pool Manager DNS Notify Support
  6. MiniDNS Support
  7. Scheduler
  8. Dynamic Pools Creation Interface