Difference between revisions of "Designate/Blueprints/Server Pools"
(→Discussion) |
Graham Hayes (talk | contribs) (→Sub Blueprints) |
||
(12 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
− | == Overview == | + | == Archive == |
+ | [[Designate/Blueprints/Server_Pools/Archive|Previous Proposal]] | ||
+ | = Server Pools Overview = | ||
+ | == Why == | ||
− | + | Server Pools are required for a few different scenarios: | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | === | + | === Private Pools === |
− | This | + | 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 | + | 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 == | |
− | |||
− | |||
− | This | + | 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 === | ||
+ | [[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
Contents
Archive
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
Single Frames are here [1]