[arch-design-draft] Editorial changes
Minor edits only. Change-Id: I0f28330c3b3737930404aaf098e47cfa18e01fbc
This commit is contained in:
parent
7611246b41
commit
afa2c7d290
@ -32,9 +32,9 @@ General cloud example
|
|||||||
---------------------
|
---------------------
|
||||||
|
|
||||||
An online classified advertising company wants to run web applications
|
An online classified advertising company wants to run web applications
|
||||||
consisting of Tomcat, Nginx and MariaDB in a private cloud. To meet the
|
consisting of Tomcat, Nginx, and MariaDB in a private cloud. To meet the
|
||||||
policy requirements, the cloud infrastructure will run in their
|
policy requirements, the cloud infrastructure will run in their
|
||||||
own data center. The company has predictable load requirements, but
|
own data center. The company has predictable load requirements but
|
||||||
requires scaling to cope with nightly increases in demand. Their current
|
requires scaling to cope with nightly increases in demand. Their current
|
||||||
environment does not have the flexibility to align with their goal of
|
environment does not have the flexibility to align with their goal of
|
||||||
running an open source API environment. The current environment consists
|
running an open source API environment. The current environment consists
|
||||||
@ -44,10 +44,10 @@ of the following:
|
|||||||
vCPUs and 4 GB of RAM
|
vCPUs and 4 GB of RAM
|
||||||
|
|
||||||
* A three node MariaDB and Galera cluster, each with 4 vCPUs and 8 GB
|
* A three node MariaDB and Galera cluster, each with 4 vCPUs and 8 GB
|
||||||
RAM
|
of RAM
|
||||||
|
|
||||||
The company runs hardware load balancers and multiple web applications
|
The company runs hardware load balancers and multiple web applications
|
||||||
serving their websites, and orchestrates environments using combinations
|
serving their websites and orchestrates environments using combinations
|
||||||
of scripts and Puppet. The website generates large amounts of log data
|
of scripts and Puppet. The website generates large amounts of log data
|
||||||
daily that requires archiving.
|
daily that requires archiving.
|
||||||
|
|
||||||
@ -71,7 +71,7 @@ The solution would consist of the following OpenStack components:
|
|||||||
.. figure:: ../figures/General_Architecture3.png
|
.. figure:: ../figures/General_Architecture3.png
|
||||||
|
|
||||||
Running up to 140 web instances and the small number of MariaDB
|
Running up to 140 web instances and the small number of MariaDB
|
||||||
instances requires 292 vCPUs available, as well as 584 GB RAM. On a
|
instances requires 292 vCPUs available, as well as 584 GB of RAM. On a
|
||||||
typical 1U server using dual-socket hex-core Intel CPUs with
|
typical 1U server using dual-socket hex-core Intel CPUs with
|
||||||
Hyperthreading, and assuming 2:1 CPU overcommit ratio, this would
|
Hyperthreading, and assuming 2:1 CPU overcommit ratio, this would
|
||||||
require 8 OpenStack Compute nodes.
|
require 8 OpenStack Compute nodes.
|
||||||
@ -121,8 +121,8 @@ The Conseil Européen pour la Recherche Nucléaire (CERN), also known as
|
|||||||
the European Organization for Nuclear Research, provides particle
|
the European Organization for Nuclear Research, provides particle
|
||||||
accelerators and other infrastructure for high-energy physics research.
|
accelerators and other infrastructure for high-energy physics research.
|
||||||
|
|
||||||
As of 2011 CERN operated these two compute centers in Europe with plans
|
As of 2011, CERN operated these two compute centers in Europe with plans
|
||||||
to add a third.
|
to add a third one.
|
||||||
|
|
||||||
+-----------------------+------------------------+
|
+-----------------------+------------------------+
|
||||||
| Data center | Approximate capacity |
|
| Data center | Approximate capacity |
|
||||||
@ -144,7 +144,7 @@ to add a third.
|
|||||||
| | - 6 PB HDD |
|
| | - 6 PB HDD |
|
||||||
+-----------------------+------------------------+
|
+-----------------------+------------------------+
|
||||||
|
|
||||||
To support a growing number of compute-heavy users of experiments
|
To support the growing number of compute-heavy users of experiments
|
||||||
related to the Large Hadron Collider (LHC), CERN ultimately elected to
|
related to the Large Hadron Collider (LHC), CERN ultimately elected to
|
||||||
deploy an OpenStack cloud using Scientific Linux and RDO. This effort
|
deploy an OpenStack cloud using Scientific Linux and RDO. This effort
|
||||||
aimed to simplify the management of the center's compute resources with
|
aimed to simplify the management of the center's compute resources with
|
||||||
@ -164,7 +164,7 @@ contains three availability zones to further segregate compute resources
|
|||||||
and at least three RabbitMQ message brokers configured for clustering
|
and at least three RabbitMQ message brokers configured for clustering
|
||||||
with mirrored queues for high availability.
|
with mirrored queues for high availability.
|
||||||
|
|
||||||
The API cell, which resides behind a HAProxy load balancer, is in the
|
The API cell, which resides behind an HAProxy load balancer, is in the
|
||||||
data center in Switzerland and directs API calls to compute cells using
|
data center in Switzerland and directs API calls to compute cells using
|
||||||
a customized variation of the cell scheduler. The customizations allow
|
a customized variation of the cell scheduler. The customizations allow
|
||||||
certain workloads to route to a specific data center or all data
|
certain workloads to route to a specific data center or all data
|
||||||
@ -223,9 +223,9 @@ configuration and customization.
|
|||||||
Monitoring
|
Monitoring
|
||||||
^^^^^^^^^^
|
^^^^^^^^^^
|
||||||
|
|
||||||
CERN does not require direct billing, but uses the Telemetry service to
|
CERN does not require direct billing but uses the Telemetry service to
|
||||||
perform metering for the purposes of adjusting project quotas. CERN uses
|
perform metering for the purposes of adjusting project quotas. CERN uses
|
||||||
a sharded, replicated, MongoDB back-end. To spread API load, CERN
|
a sharded, replicated MongoDB back end. To spread API load, CERN
|
||||||
deploys instances of the nova-api service within the child cells for
|
deploys instances of the nova-api service within the child cells for
|
||||||
Telemetry to query against. This also requires the configuration of
|
Telemetry to query against. This also requires the configuration of
|
||||||
supporting services such as keystone, glance-api, and glance-registry in
|
supporting services such as keystone, glance-api, and glance-registry in
|
||||||
@ -265,7 +265,7 @@ This solution is depicted in the figure below:
|
|||||||
|
|
||||||
This example shows two clouds with a Cloud Management
|
This example shows two clouds with a Cloud Management
|
||||||
Platform (CMP) connecting them. This guide does not
|
Platform (CMP) connecting them. This guide does not
|
||||||
discuss a specific CMP, but describes how the Orchestration and
|
discuss a specific CMP but describes how the Orchestration and
|
||||||
Telemetry services handle, manage, and control workloads.
|
Telemetry services handle, manage, and control workloads.
|
||||||
|
|
||||||
The private OpenStack cloud has at least one controller and at least
|
The private OpenStack cloud has at least one controller and at least
|
||||||
@ -319,7 +319,7 @@ Hybrid cloud example: high availability and disaster recovery
|
|||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
Company C requires their local data center to be able to
|
Company C requires their local data center to be able to
|
||||||
recover from failure. Some of the workloads currently in
|
recover from failure. Some of the workloads currently in
|
||||||
use are running on their private OpenStack cloud.
|
use are running on their private OpenStack cloud.
|
||||||
Protecting the data involves Block Storage, Object Storage,
|
Protecting the data involves Block Storage, Object Storage,
|
||||||
and a database. The architecture supports the failure of
|
and a database. The architecture supports the failure of
|
||||||
@ -353,7 +353,7 @@ configures a single array spanning both clouds with OpenStack Identity.
|
|||||||
Using Federated Identity, the array talks to both clouds, communicating
|
Using Federated Identity, the array talks to both clouds, communicating
|
||||||
with OpenStack Object Storage through the Swift proxy.
|
with OpenStack Object Storage through the Swift proxy.
|
||||||
|
|
||||||
For Block Storage, the replication is a little more difficult,
|
For Block Storage, the replication is a little more difficult
|
||||||
and involves tools outside of OpenStack itself.
|
and involves tools outside of OpenStack itself.
|
||||||
The OpenStack Block Storage volume is not set as the drive itself
|
The OpenStack Block Storage volume is not set as the drive itself
|
||||||
but as a logical object that points to a physical back end.
|
but as a logical object that points to a physical back end.
|
||||||
@ -368,7 +368,7 @@ More information can be found here:
|
|||||||
https://blueprints.launchpad.net/cinder/+spec/cinder-backup-volume-metadata-support.
|
https://blueprints.launchpad.net/cinder/+spec/cinder-backup-volume-metadata-support.
|
||||||
|
|
||||||
The synchronous backups create an identical volume in both
|
The synchronous backups create an identical volume in both
|
||||||
clouds and chooses the appropriate flavor so that each cloud
|
clouds and choose the appropriate flavor so that each cloud
|
||||||
has an identical back end. This is done by creating volumes
|
has an identical back end. This is done by creating volumes
|
||||||
through the CMP. After this is configured, a solution
|
through the CMP. After this is configured, a solution
|
||||||
involving DRDB synchronizes the physical drives.
|
involving DRDB synchronizes the physical drives.
|
||||||
|
Loading…
Reference in New Issue
Block a user