Merge "Arch Design: Edits on multi-site"
This commit is contained in:
Jenkins
Gerrit Code Review
commit
621490324a
@ -36,23 +36,23 @@
|
||||
<para>The majority of OpenStack components are designed to run within
|
||||
the context of a single region. The OpenStack Compute service is
|
||||
designed to manage compute resources within a region, with support
|
||||
for subdivisions of compute resources by using Availability Zones
|
||||
and Cells. The OpenStack Networking service can be used to manage
|
||||
for subdivisions of compute resources by using availability zones
|
||||
and cells. The OpenStack Networking service can be used to manage
|
||||
network resources in the same broadcast domain or collection of
|
||||
switches that are linked. The OpenStack Block Storage service
|
||||
controls storage resources within a region with all storage
|
||||
resources residing on the same storage network. Like the OpenStack
|
||||
Compute service, the OpenStack Block Storage Service also supports
|
||||
the Availability Zone construct,which can be used to subdivide
|
||||
Compute service, the OpenStack Block Storage service also supports
|
||||
the availability zone construct which can be used to subdivide
|
||||
storage resources.</para>
|
||||
<para>The OpenStack Dashboard, OpenStack Identity Service, and OpenStack
|
||||
<para>The OpenStack dashboard, OpenStack Identity, and OpenStack
|
||||
Object Storage services are components that can each be deployed
|
||||
centrally in order to serve multiple regions.</para>
|
||||
</section>
|
||||
<section xml:id="arch-multi-storage">
|
||||
<title>Storage</title>
|
||||
<para>With multiple OpenStack regions, having a single OpenStack Object
|
||||
Storage Service endpoint that delivers shared file storage for all
|
||||
Storage service endpoint that delivers shared file storage for all
|
||||
regions is desirable. The Object Storage service internally
|
||||
replicates files to multiple nodes. The advantages of this are that,
|
||||
if a file placed into the Object Storage service is visible to all
|
||||
|
||||
@ -19,8 +19,11 @@
|
||||
<para>Note that, as of the Icehouse release, documentation for
|
||||
implementing this feature is in progress. See this bug for
|
||||
more information:
|
||||
https://bugs.launchpad.net/openstack-manuals/+bug/1340509</para>
|
||||
<section xml:id="licensing"><title>Licensing</title>
|
||||
<link
|
||||
xlink:href="https://bugs.launchpad.net/openstack-manuals/+bug/1340509">https://bugs.launchpad.net/openstack-manuals/+bug/1340509</link>.
|
||||
</para>
|
||||
<section xml:id="licensing">
|
||||
<title>Licensing</title>
|
||||
<para>Multi-site OpenStack deployments present additional
|
||||
licensing considerations over and above regular OpenStack
|
||||
clouds, particularly where site licenses are in use to provide
|
||||
@ -56,11 +59,12 @@
|
||||
<title>Logging and monitoring</title>
|
||||
<para>Logging and monitoring does not significantly differ for a
|
||||
multi-site OpenStack cloud. The same well known tools
|
||||
described in the Operations Guide
|
||||
(http://docs.openstack.org/openstack-ops/content/logging_monitoring.html)
|
||||
remain applicable. Logging and monitoring can be provided both
|
||||
on a per-site basis and in a common centralized
|
||||
location.</para>
|
||||
described in the <link
|
||||
xlink:href="http://docs.openstack.org/openstack-ops/content/logging_monitoring.html">Logging
|
||||
and monitoring chapter</link> of the <citetitle>Operations
|
||||
Guide</citetitle> remain applicable. Logging and monitoring
|
||||
can be provided both on a per-site basis and in a common
|
||||
centralized location.</para>
|
||||
<para>When attempting to deploy logging and monitoring facilities
|
||||
to a centralized location, care must be taken with regards to
|
||||
the load placed on the inter-site networking links.</para></section>
|
||||
@ -71,49 +75,51 @@
|
||||
which is linked to the others by using centralized services
|
||||
such as Identity which are shared between sites. At a high
|
||||
level the recommended order of operations to upgrade an
|
||||
individual OpenStack environment is
|
||||
(http://docs.openstack.org/openstack-ops/content/ops_upgrades-general-steps.html):</para>
|
||||
individual OpenStack environment is (see the <link
|
||||
xlink:href="http://docs.openstack.org/openstack-ops/content/ops_upgrades-general-steps.html">Upgrades
|
||||
chapter</link> of the <citetitle>Operations Guide</citetitle>
|
||||
for details):</para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Upgrade the OpenStack Identity Service
|
||||
(Keystone).</para>
|
||||
<para>Upgrade the OpenStack Identity service
|
||||
(keystone).</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Upgrade the OpenStack Image Service (Glance).</para>
|
||||
<para>Upgrade the OpenStack Image Service (glance).</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Upgrade OpenStack Compute (Nova), including
|
||||
<para>Upgrade OpenStack Compute (nova), including
|
||||
networking components.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Upgrade OpenStack Block Storage (Cinder).</para>
|
||||
<para>Upgrade OpenStack Block Storage (cinder).</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Upgrade the OpenStack dashboard.(Horizon)</para>
|
||||
<para>Upgrade the OpenStack dashboard (horizon).</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
<para>The process for upgrading a multi-site environment is not
|
||||
significantly different:</para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Upgrade the shared OpenStack Identity Service
|
||||
(Keystone) deployment.</para>
|
||||
<para>Upgrade the shared OpenStack Identity service
|
||||
(keystone) deployment.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Upgrade the OpenStack Image Service (glance) at each
|
||||
site.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Upgrade OpenStack Compute (Nova), including
|
||||
<para>Upgrade OpenStack Compute (nova), including
|
||||
networking components, at each site.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Upgrade OpenStack Block Storage (Cinder) at each
|
||||
<para>Upgrade OpenStack Block Storage (cinder) at each
|
||||
site.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Upgrade the OpenStack dashboard (Horizon), at each
|
||||
site - or in the single central location if it is
|
||||
<para>Upgrade the OpenStack dashboard (horizon), at each
|
||||
site or in the single central location if it is
|
||||
shared.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
@ -143,10 +149,12 @@
|
||||
user may launch a total of 50 instances spread across both
|
||||
regions. They may not, however, launch more than 25 instances
|
||||
in any single region.</para>
|
||||
<para>For more information on managing quotas refer to Chapter 9.
|
||||
Managing Projects and Users
|
||||
(http://docs.openstack.org/openstack-ops/content/projects_users.html)
|
||||
of the OpenStack Operators Guide.</para></section>
|
||||
<para>For more information on managing quotas refer to the
|
||||
<link
|
||||
xlink:href="http://docs.openstack.org/openstack-ops/content/projects_users.html">Managing
|
||||
projects and users chapter</link> of the <citetitle>OpenStack
|
||||
Operators Guide</citetitle>.</para>
|
||||
</section>
|
||||
<section xml:id="policy-management-multi-site">
|
||||
<title>Policy management</title>
|
||||
<para>OpenStack provides a default set of Role Based Access
|
||||
@ -170,7 +178,7 @@
|
||||
OpenStack will schedule instances on a compute node
|
||||
automatically. However, when multiple regions are available,
|
||||
it is left to the end user to decide in which region to
|
||||
schedule the new instance. Horizon will present the user with
|
||||
schedule the new instance. The dashboard will present the user with
|
||||
the first region in your configuration. The API and CLI tools
|
||||
will not execute commands unless a valid region is specified.
|
||||
It is therefore important to provide documentation to your
|
||||
|
||||
@ -1,4 +1,8 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE section [
|
||||
<!ENTITY % openstack SYSTEM "../../common/entities/openstack.ent">
|
||||
%openstack;
|
||||
]>
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
@ -91,7 +95,7 @@
|
||||
customer requests and a NoSQL database back end storing the
|
||||
information.</para>
|
||||
<para>As of late there has been several outages in number of major
|
||||
public cloud providers - usually due to the fact these
|
||||
public cloud providers—usually due to the fact these
|
||||
applications were running out of a single geographical
|
||||
location. The design therefore should mitigate the chance of a
|
||||
single site causing an outage for their business.</para>
|
||||
@ -108,7 +112,7 @@
|
||||
each of the three regions. The other services,
|
||||
Identity, Orchestration, Telemetry, Image Service and
|
||||
Block Storage will be
|
||||
installed centrally - with nodes in each of the region
|
||||
installed centrally—with nodes in each of the region
|
||||
providing a redundant OpenStack Controller plane
|
||||
throughout the globe.</para>
|
||||
</listitem>
|
||||
@ -123,8 +127,8 @@
|
||||
replicated on a regular basis.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>A Distributed DNS service available to all regions -
|
||||
that allows for dynamic update of DNS records of
|
||||
<para>A Distributed DNS service available to all
|
||||
regions—that allows for dynamic update of DNS records of
|
||||
deployed instances.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -141,22 +145,22 @@
|
||||
<para>Web Servers, running Apache.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Appropriate user_data to populate the central DNS
|
||||
<para>Appropriate <literal>user_data</literal> to populate the central DNS
|
||||
servers upon instance launch.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Appropriate Ceilometer alarms that maintain state of
|
||||
<para>Appropriate Telemetry alarms that maintain state of
|
||||
the application and allow for handling of region or
|
||||
instance failure.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>Another autoscaling Heat template will be used to deploy a
|
||||
distributed MongoDB shard over the three locations - with the
|
||||
option of storing required data on a globally available Swift
|
||||
distributed MongoDB shard over the three locations—with the
|
||||
option of storing required data on a globally available swift
|
||||
container. according to the usage and load on the database
|
||||
server - additional shards will be provisioned according to
|
||||
the thresholds defined in Ceilometer.</para>
|
||||
<para>The reason that 3 regions were selected here was because of
|
||||
server—additional shards will be provisioned according to
|
||||
the thresholds defined in Telemetry.</para>
|
||||
<para>The reason that three regions were selected here was because of
|
||||
the fear of having abnormal load on a single region in the
|
||||
event of a failure. Two data center would have been sufficient
|
||||
had the requirements been met.</para>
|
||||
@ -165,20 +169,21 @@
|
||||
Additional configuration management tools, such as Puppet or
|
||||
Chef could also have been used in this scenario, but were not
|
||||
chosen due to the fact that Orchestration had the appropriate built-in
|
||||
hooks into the OpenStack cloud - whereas the other tools were
|
||||
external and not native to OpenStack. In addition - since this
|
||||
deployment scenario was relatively straight forward - the
|
||||
hooks into the OpenStack cloud—whereas the other tools were
|
||||
external and not native to OpenStack. In addition—since this
|
||||
deployment scenario was relatively straight forward—the
|
||||
external tools were not needed.</para>
|
||||
<para>Swift is used here to serve as a back end for Glance and
|
||||
Object storage since was the most suitable solution for a
|
||||
globally distributed storage solution - with its own
|
||||
<para>
|
||||
OpenStack Object Storage is used here to serve as a back end for
|
||||
the Image Service since was the most suitable solution for a
|
||||
globally distributed storage solution—with its own
|
||||
replication mechanism. Home grown solutions could also have
|
||||
been used including the handling of replication - but were not
|
||||
chosen, because Swift is already an intricate part of the
|
||||
infrastructure - and proven solution.</para>
|
||||
been used including the handling of replication—but were not
|
||||
chosen, because Object Storage is already an intricate part of the
|
||||
infrastructure—and proven solution.</para>
|
||||
<para>An external load balancing service was used and not the
|
||||
LBaaS in OpenStack because the solution in OpenStack is not
|
||||
redundant and does have any awareness of geo location.</para>
|
||||
redundant and does not have any awareness of geo location.</para>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata contentwidth="4in"
|
||||
|
||||
@ -29,8 +29,8 @@
|
||||
two sites to support a single Swift endpoint and a shared
|
||||
object storage capability between them. (An example of this
|
||||
technique, as well as a configuration walk-through, is
|
||||
available at
|
||||
http://docs.openstack.org/developer/swift/replication_network.html#dedicated-replication-network).
|
||||
available at <link
|
||||
xlink:href="http://docs.openstack.org/developer/swift/replication_network.html#dedicated-replication-network">http://docs.openstack.org/developer/swift/replication_network.html#dedicated-replication-network</link>).
|
||||
Another option in this scenario is to build a dedicated set of
|
||||
tenant private networks across the secondary link using
|
||||
overlay networks with a third party mapping the site overlays
|
||||
@ -41,9 +41,9 @@
|
||||
small packets, for example RPC calls, may encounter issues
|
||||
communicating with each other or operating properly.
|
||||
Additionally, OpenStack may encounter similar types of issues.
|
||||
To mitigate this, tuning of the Keystone call timeouts may be
|
||||
To mitigate this, tuning of the Identity service call timeouts may be
|
||||
necessary to prevent issues authenticating against a central
|
||||
Identity Service.</para>
|
||||
Identity service.</para>
|
||||
<para>Another capacity consideration when it comes to networking
|
||||
for a multi-site deployment is the available amount and
|
||||
performance of overlay networks for tenant networks. If using
|
||||
@ -81,19 +81,19 @@
|
||||
goal of this guide, the real test is whether an application
|
||||
can utilize it.</para>
|
||||
<para>Identity is normally the first interface for the majority of
|
||||
OpenStack users. Interacting with Keystone is required for
|
||||
OpenStack users. Interacting with the Identity service is required for
|
||||
almost all major operations within OpenStack. Therefore, it is
|
||||
important to ensure that you provide users with a single URL
|
||||
for Keystone authentication. Equally important is proper
|
||||
documentation and configuration of regions within Keystone.
|
||||
for Identity service authentication. Equally important is proper
|
||||
documentation and configuration of regions within the Identity service.
|
||||
Each of the sites defined in your installation is considered
|
||||
to be a region in Keystone nomenclature. This is important for
|
||||
the users of the system, when reading Keystone documentation,
|
||||
as it is required to define the Region name when providing
|
||||
actions to an API endpoint or in Horizon.</para>
|
||||
to be a region in Identity nomenclature. This is important for
|
||||
the users of the system, when reading Identity documentation,
|
||||
as it is required to define the region name when providing
|
||||
actions to an API endpoint or in the dashboard.</para>
|
||||
<para>Load balancing is another common issue with multi-site
|
||||
installations. While it is still possible to run HAproxy
|
||||
instances with load balancer as a service, these will be local
|
||||
instances with Load-Balancer-as-a-Service, these will be local
|
||||
to a specific region. Some applications may be able to cope
|
||||
with this via internal mechanisms. Others, however, may
|
||||
require the implementation of an external system including
|
||||
@ -107,7 +107,7 @@
|
||||
object available to more than one region will need to do the
|
||||
cross-site replication themselves. With a centralized swift
|
||||
proxy, however, the user may need to benchmark the replication
|
||||
timing of the Swift back end. Benchmarking allows the
|
||||
timing of the Object Storage back end. Benchmarking allows the
|
||||
operational staff to provide users with an understanding of
|
||||
the amount of time required for a stored or modified object to
|
||||
become available to the entire environment.</para></section>
|
||||
@ -122,16 +122,16 @@
|
||||
communicating across regions. This can especially impact
|
||||
systems like the OpenStack Identity service when making
|
||||
authentication attempts from regions that do not contain the
|
||||
centralized Keystone implementation. It can also affect
|
||||
centralized Identity implementation. It can also affect
|
||||
certain applications which rely on remote procedure call (RPC)
|
||||
for normal operation. An example of this can be seen in High
|
||||
Performance Computing workloads.</para>
|
||||
<para>Storage availability can also be impacted by the
|
||||
architecture of a multi-site deployment. A centralized Object
|
||||
Storage Service requires more time for an object to be
|
||||
Storage service requires more time for an object to be
|
||||
available to instances locally in regions where the object was
|
||||
not created. Some applications may need to be tuned to account
|
||||
for this effect. Block storage does not currently have a
|
||||
for this effect. Block Storage does not currently have a
|
||||
method for replicating data across multiple regions, so
|
||||
applications that depend on available block storage will need
|
||||
to manually cope with this limitation by creating duplicate
|
||||
@ -168,30 +168,34 @@
|
||||
<section xml:id="openstack-components-multi-site">
|
||||
<title>OpenStack components</title>
|
||||
<para>Most OpenStack installations require a bare minimum set of
|
||||
pieces to function. These include Keystone for authentication,
|
||||
Nova for compute, Glance for image storage, Neutron for
|
||||
networking, and potentially an object store in the form of
|
||||
Swift. Bringing multi-site into play also demands extra
|
||||
pieces to function. These include the OpenStack Identity
|
||||
(keystone) for authentication, OpenStack Compute
|
||||
(nova) for compute, OpenStack Image Service (glance) for image
|
||||
storage, OpenStack Networking (neutron) for networking, and
|
||||
potentially an object store in the form of OpenStack Object
|
||||
Storage (swift). Bringing multi-site into play also demands extra
|
||||
components in order to coordinate between regions. Centralized
|
||||
Keystone is necessary to provide the single authentication
|
||||
point. Centralized Horizon is also recommended to provide a
|
||||
Identity service is necessary to provide the single authentication
|
||||
point. Centralized dashboard is also recommended to provide a
|
||||
single login point and a mapped experience to the API and CLI
|
||||
options available. If necessary, a centralized Swift may be
|
||||
used and will require the installation of the Swift proxy
|
||||
service.</para>
|
||||
options available. If necessary, a centralized Object Storage
|
||||
service may be used and will require the installation of the
|
||||
swift proxy service.</para>
|
||||
<para>It may also be helpful to install a few extra options in
|
||||
order to facilitate certain use cases. For instance,
|
||||
installing Designate may assist in automatically generating
|
||||
installing designate may assist in automatically generating
|
||||
DNS domains for each region with an automatically-populated
|
||||
zone full of resource records for each instance. This
|
||||
facilitates using DNS as a mechanism for determining which
|
||||
region would be selected for certain applications.</para>
|
||||
<para>Another useful tool for managing a multi-site installation
|
||||
is Orchestration. Heat allows the use of templates to define a set of
|
||||
instances to be launched together or for scaling existing
|
||||
sets. It can also be used to setup matching or differentiated
|
||||
groupings based on regions. For instance, if an application
|
||||
requires an equally balanced number of nodes across sites, the
|
||||
same heat template can be used to cover each site with small
|
||||
alterations to only the region name.</para></section>
|
||||
is Orchestration (heat). The Orchestration module allows the
|
||||
use of templates to define a set of instances to be launched
|
||||
together or for scaling existing sets. It can also be used to
|
||||
setup matching or differentiated groupings based on
|
||||
regions. For instance, if an application requires an equally
|
||||
balanced number of nodes across sites, the same heat template
|
||||
can be used to cover each site with small alterations to only
|
||||
the region name.</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
@ -36,11 +36,12 @@
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>Examples of such legal frameworks include the data
|
||||
protection framework of the European Union
|
||||
(http://ec.europa.eu/justice/data-protection) and the
|
||||
requirements of the Financial Industry Regulatory Authority
|
||||
(http://www.finra.org/Industry/Regulation/FINRARules) in the
|
||||
United States. Consult a local regulatory body for more
|
||||
protection framework of the European Union (<link
|
||||
xlink:href="http://ec.europa.eu/justice/data-protection">http://ec.europa.eu/justice/data-protection</link>)
|
||||
and the requirements of the Financial Industry Regulatory
|
||||
Authority (<link
|
||||
xlink:href="http://www.finra.org/Industry/Regulation/FINRARules">http://ec.europa.eu/justice/data-protection</link>)
|
||||
in the United States. Consult a local regulatory body for more
|
||||
information.</para>
|
||||
<section xml:id="workload-characteristics">
|
||||
<title>Workload characteristics</title>
|
||||
@ -73,7 +74,7 @@
|
||||
<para>It is essential that the deployment of instances is
|
||||
consistent across the different sites. This needs to be built
|
||||
into the infrastructure. If OpenStack Object Store is used as
|
||||
a back end for Glance, it is possible to create repositories of
|
||||
a back end for the Image Service, it is possible to create repositories of
|
||||
consistent images across multiple sites. Having a central
|
||||
endpoint with multiple storage nodes will allow for a
|
||||
consistent centralized storage for each and every site.</para>
|
||||
@ -84,15 +85,16 @@
|
||||
the images across multiple sites.</para></section>
|
||||
<section xml:id="high-availability-multi-site"><title>High availability</title>
|
||||
<para>If high availability is a requirement to provide continuous
|
||||
infrastructure operations, a basic requirement of High
|
||||
Availability should be defined.</para>
|
||||
infrastructure operations, a basic requirement of high
|
||||
availability should be defined.</para>
|
||||
<para>The OpenStack management components need to have a basic and
|
||||
minimal level of redundancy. The simplest example is the loss
|
||||
of any single site has no significant impact on the
|
||||
availability of the OpenStack services of the entire
|
||||
infrastructure.</para>
|
||||
<para>The OpenStack High Availability Guide
|
||||
(http://docs.openstack.org/high-availability-guide/content/)
|
||||
<para>The <link
|
||||
xlink:href="http://docs.openstack.org/high-availability-guide/content/"><citetitle>OpenStack
|
||||
High Availability Guide</citetitle></link>
|
||||
contains more information on how to provide redundancy for the
|
||||
OpenStack components.</para>
|
||||
<para>Multiple network links should be deployed between sites to
|
||||
@ -138,10 +140,10 @@
|
||||
<para>The requirement of having more than one site has a cost
|
||||
attached to it. The greater the number of sites, the greater
|
||||
the cost and complexity. Costs can be broken down into the
|
||||
following categories</para>
|
||||
following categories:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Compute Resources</para>
|
||||
<para>Compute resources</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Networking resources</para>
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user