Jump to: navigation, search

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

m
(Sub Blueprints)
 
(15 intermediate revisions by 4 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]
 
|}
 
  
==== Overview ====
+
=== Private Pools ===  
  
This is an initial change to the codebase to introduce the concept of a "server pool"
+
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 introduced a new service that sits where the agent would have traditionally sat for bind9
+
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
  
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.
+
=== Distribution ===
  
==== Phase One State Diagram ====
+
Having multiple public pools with the same capabilities, would allow the scheduler to distribute zones across multiple infrastructures.
  
[[File:Pool-Manager-State.png|border|Phase One Server Pools State Diagram]]
+
=== Features / Premium Systems ===
  
==== API v2 Changes ====
+
By using scheduler hints, we can mark different pools as having different capabilites - such as GeoIP / Round Robin DNS / Anycast.
  
Servers are now a full sub resource of pools, and are accessed using HTTP requests like:
+
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 - get all servers in <pool_id>
+
== What ==
  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.
+
Pools will be broken down into 'types'. This will be an extensible list - by using plugins to define types.
  
==== Phase One Limitations ====
+
=== 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.
  
# Currently there is only support for one pool
+
=== Nova ===
# This is currently a synchronous operation - async will be in a later phase
+
These would be dynamically created pools, generally used for private pools, that would have the server name / IP defined by nova / neutron.
# 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.
 
  
== Next Steps ==
+
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.
  
=== Phase Two ===
+
== How ==
 +
=== General Overview - Basic Info Flow ===
 +
[[File:Designate-MiniDNS-Pools.gif|framed|center|Information Flow]]
  
{| class="wikitable"
+
Single Frames are here [https://imgur.com/a/CawLd]
|-
 
! Gerrit Patch || N/A Currently
 
|-
 
! Launchpad Blueprint || [https://blueprints.launchpad.net/designate/+spec/async-backends]
 
|}
 
  
==== Overview ====
+
= Sub Blueprints =
 
+
# [[Designate/Blueprints/Server_Pools/Central|Central Support]]
As part of phase two, we will introduce the concept of Async operations on backends, using the pool-manager interfaces.
+
# [[Designate/Blueprints/Server_Pools/API|API]]
 
+
# [[Designate/Blueprints/Server_Pools/Storage|Storage]]
There will be a couple of changes to the core of designate:
+
# [[Designate/Blueprints/Server_Pools/Service|Pool Manager Service]]
 
+
# [[Designate/Blueprints/Server_Pools/DNS_Notify|Pool Manager DNS Notify Support]]
# There will be a new table added for tracking of async operations.
+
# [[Designate/Blueprints/Server_Pools/MiniDNS|MiniDNS Support]]
# Zone serial numbers will move to a incrementing integer (from the current date/time stamp format)
+
# [[Designate/Blueprints/Server_Pools/Scheduler|Scheduler]]
# All responses from the API will move to a '''202 - Accepted''' for modifying operations on zones.
+
# [[Designate/Blueprints/Server_Pools/Dynamic_Pool_Interface|Dynamic Pools Creation Interface]]
## The response data for zone operations will include a status field, that will show '''PENDING'''.
 
## When the operation is complete, this will be changed to a '''ACTIVE''' status
 
 
 
==== Phase Two State Diagram ====
 
 
 
[[File:Designate-Pool-Manager-Async.png|border|Phase One Server Pools State Diagram]]
 
 
 
===== Notes =====
 
# This is 2 rpc calls, that no returns (oslo.messaging casts vs calls), meaning the central is not blocked on the pool-manager operation
 
# This is an example API call while the backend is still working on the change
 
# This is an example API call on the completion of the change
 
 
 
==== API v2 Changes ====
 
# Changing response code for async operations
 
 
 
==== Database Changes ====
 
''This will document the example changes to the SQLAlchemy implementation''
 
 
 
'''Additional Tables'''
 
# Pending Operations
 
## Resource ID - '''UUID'''
 
## Resource Type - '''UUID'''
 
## ChangeSetSerial - '''Integer''' ''(this name may need to be examined)''
 
 
 
=== Phase Three ===
 
 
 
{| class="wikitable"
 
|-
 
! Gerrit Patch || N/A Currently
 
|-
 
! Launchpad Blueprint || [https://blueprints.launchpad.net/designate/+spec/server-pool-scheduler]
 
|}
 
 
 
==== Overview ====
 
This will need fleshing out, but will be the creation of a pools scheduler to allow for multiple pools, and per tenant pools
 

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