openstack/deb-designate
Code Issues Proposed changes

Fix Production Arch docs

Browse Source 
Change-Id: I203da7b1bd3071cc88e935ef473d52fe6be8f8a8
This commit is contained in:
Graham Hayes 2015-02-13 17:52:29 +00:00
parent 86dddab7e3
commit f8d3ff4a61
1 changed files with 13 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
doc/source/production-architecture.rst
View File

@ -4,11 +4,6 @@
Production Architecture
=============================
Multi-Zone Architecture
-----------------------
.. image:: images/Designate-MultiZone.png
Outline
-------
This document outlines what a production environment hosting Designate could look like, it follows an in-cloud model, where Designate would be hosted on instances in an OpenStack cloud. It's supposed to complement the
@ -29,7 +24,10 @@ Roles
A Designate deploy breaks down into several key roles:
- `Designate API`_
- `Designate Sink`_
- `Designate Central`_
- `Designate MiniDNS`_
- `Designate Pool Manager`_
- `Message Queue`_
- `Database`_ (MySQL or derivative)
- `DNS Backend`_
@ -40,13 +38,21 @@ Typically, API nodes would be made available in multiple AZs, providing redundan
In a Multi-AZ deployment, the API nodes should be configured to talk to all members of the MQ Cluster - so that in the event of MQ node failing, requests continue to flow to the MQ.
Designate Sink
~~~~~~~~~~~~~~~~~~~~~~~
In a Multi-AZ deployment, the sink node should be configured to talk to all members of the MQ Cluster - so that in the event of MQ node failing, requests continue to flow to the MQ.
Designate Central
~~~~~~~~~~~~~~~~~~~~~~~
In a Multi-AZ deployment, the Central nodes should be configured to talk to all members of the MQ Cluster - so that in the event of MQ node failing, requests continue to be processed.
Designate Sink
Designate MiniDNS
~~~~~~~~~~~~~~~~~~~~~~~
In a Multi-AZ deployment, the sink node should be configured to talk to all members of the MQ Cluster - so that in the event of MQ node failing, requests continue to flow to the MQ.
In a Multi-AZ deployment, the MiniDNS nodes should be configured to talk to all members of the MQ Cluster - so that in the event of MQ node failing, requests continue to be processed. It should also be configured to talk to multiple DB servers, to allow for reliable access to the data store
Designate Pool Manager
~~~~~~~~~~~~~~~~~~~~~~~
In a Multi-AZ deployment, the Pool Manager nodes should be configured to talk to all members of the MQ Cluster - so that in the event of MQ node failing, requests continue to be processed.
Message Queue
~~~~~~~~~~~~~