[arch-design] Reorganize front page and overview chapter
1. Restructure index pages for the Ops Guide and Arch Guide 2. Rename and reorganize the overview chapter 3. Migrate security requirements, legal requirements, deployment, and capacity planning and scaling content to the Ops Guide Change-Id: Ic22d58f48ba11b59839d8fe39046281d26fa033c Implements: blueprint arch-design-pike
This commit is contained in:
daz
Darren Chan
parent
5774575e6b
commit
2e931e7db9
8
doc/arch-design/source/appendix.rst
Normal file
8
doc/arch-design/source/appendix.rst
Normal file
@ -0,0 +1,8 @@
|
||||
Appendix
|
||||
~~~~~~~~
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
common/app-support.rst
|
||||
common/glossary.rst
|
||||
13
doc/arch-design/source/arch-requirements.rst
Normal file
13
doc/arch-design/source/arch-requirements.rst
Normal file
@ -0,0 +1,13 @@
|
||||
=========================
|
||||
Architecture requirements
|
||||
=========================
|
||||
|
||||
This chapter describes the enterprise and operational factors that impacts the
|
||||
design of an OpenStack cloud.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
arch-requirements/arch-requirements-enterprise
|
||||
arch-requirements/arch-requirements-operations
|
||||
arch-requirements/arch-requirements-ha
|
||||
@ -1,9 +1,9 @@
|
||||
=====================
|
||||
Customer requirements
|
||||
=====================
|
||||
=======================
|
||||
Enterprise requirements
|
||||
=======================
|
||||
|
||||
The following sections describe business, usage, and performance
|
||||
considerations for customers which will impact cloud design.
|
||||
considerations for customers which will impact cloud architecture design.
|
||||
|
||||
Cost
|
||||
~~~~
|
||||
@ -24,6 +24,8 @@ architectures. However, overall operational costs might be lower by virtue of
|
||||
using a cloud brokerage tool to deploy the workloads to the most cost effective
|
||||
platform.
|
||||
|
||||
.. TODO Replace examples with the proposed example use cases in this guide.
|
||||
|
||||
Consider the following costs categories when designing a cloud:
|
||||
|
||||
* Compute resources
|
||||
@ -45,11 +47,8 @@ capital expenditure (CapEx) at all layers of the stack. Operators of massively
|
||||
scalable OpenStack clouds require the use of dependable commodity hardware and
|
||||
freely available open source software components to reduce deployment costs and
|
||||
operational expenses. Initiatives like Open Compute (more information available
|
||||
in the `Open Compute Project <http://www.opencompute.org>`_)
|
||||
provide additional information and pointers.
|
||||
Factors to consider include power, cooling, and the physical design of the
|
||||
chassis. Through customization, it is possible to optimize your hardware and
|
||||
systems for specific types of workloads when working at scale.
|
||||
in the `Open Compute Project <http://www.opencompute.org>`_) provide additional
|
||||
information.
|
||||
|
||||
Time-to-market
|
||||
~~~~~~~~~~~~~~
|
||||
@ -80,9 +79,7 @@ Capacity planning and scalability
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Capacity and the placement of workloads are key design considerations
|
||||
for clouds. One of the primary reasons many organizations use a hybrid cloud
|
||||
is to increase capacity without making large capital investments.
|
||||
The long-term capacity plan for these designs must
|
||||
for clouds. A long-term capacity plan for these designs must
|
||||
incorporate growth over time to prevent permanent consumption of more
|
||||
expensive external clouds. To avoid this scenario, account for future
|
||||
applications' capacity requirements and plan growth appropriately.
|
||||
@ -105,6 +102,10 @@ as a result, performance can be inconsistent.
|
||||
If at all possible, determine what the oversubscription rates
|
||||
of each host are and plan capacity accordingly.
|
||||
|
||||
.. TODO Considerations when building your cloud, racks, CPUs, compute node
|
||||
density. For ongoing capacity planning refer to the Ops Guide.
|
||||
|
||||
|
||||
Performance
|
||||
~~~~~~~~~~~
|
||||
|
||||
@ -289,7 +290,6 @@ data centers. Considerations include:
|
||||
- power usage and power usage efficiency (PUE)
|
||||
- physical security
|
||||
|
||||
|
||||
Auditing
|
||||
~~~~~~~~
|
||||
|
||||
@ -19,10 +19,10 @@ operations, metering, monitoring, and so on, are often referred to as the
|
||||
Control Plane. The SLA is likely to dictate a lower uptime requirement for
|
||||
these services.
|
||||
|
||||
The services comprising an OpenStack cloud have a number of requirements which
|
||||
the architect needs to understand in order to be able to meet SLA terms. For
|
||||
example, in order to provide the Compute service a minimum of storage, message
|
||||
queueing, and database services are necessary as well as the networking between
|
||||
The services comprising an OpenStack cloud have a number of requirements that
|
||||
you need to understand in order to be able to meet SLA terms. For example, in
|
||||
order to provide the Compute service a minimum of storage, message queueing and
|
||||
database services are necessary as well as the networking between
|
||||
them.
|
||||
|
||||
Ongoing maintenance operations are made much simpler if there is logical and
|
||||
@ -32,13 +32,8 @@ If one service failure affects the operation of an entire server (``noisy
|
||||
neighbor``), the separation between Control and Data Planes enables rapid
|
||||
maintenance with a limited effect on customer operations.
|
||||
|
||||
Eliminating single points of failure
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. TODO Add introduction
|
||||
|
||||
Within each site
|
||||
----------------
|
||||
Eliminating single points of failure within each site
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
OpenStack lends itself to deployment in a highly available manner where it is
|
||||
expected that at least 2 servers be utilized. These can run all the services
|
||||
@ -102,8 +97,8 @@ If using a storage design that includes shared access to centralized storage,
|
||||
ensure that this is also designed without single points of failure and the SLA
|
||||
for the solution matches or exceeds the expected SLA for the Data Plane.
|
||||
|
||||
Between sites in a multi-region design
|
||||
--------------------------------------
|
||||
Eliminating single points of failure in a multi-region design
|
||||
-------------------------------------------------------------
|
||||
|
||||
Some services are commonly shared between multiple regions, including the
|
||||
Identity service and the Dashboard. In this case, it is necessary to ensure
|
||||
@ -162,7 +157,7 @@ should be implemented to understand and plan for recovery scenarios.
|
||||
avoid race conditions.
|
||||
|
||||
|
||||
Inter-site replication data
|
||||
Replicating inter-site data
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Traditionally, replication has been the best method of protecting object store
|
||||
@ -1,6 +1,6 @@
|
||||
=====================
|
||||
Operator requirements
|
||||
=====================
|
||||
========================
|
||||
Operational requirements
|
||||
========================
|
||||
|
||||
This section describes operational factors affecting the design of an
|
||||
OpenStack cloud.
|
||||
@ -134,9 +134,9 @@ third parties involved.
|
||||
Support and maintenance
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
An operations staff supports, manages, and maintains an OpenStack
|
||||
environment. Their skills may be specialised or varied depending
|
||||
on the size and purpose of the installation.
|
||||
An operations staff supports, manages, and maintains an OpenStack environment.
|
||||
Their skills may be specialized or varied depending on the size and purpose of
|
||||
the installation.
|
||||
|
||||
The maintenance function of an operator should be taken into consideration:
|
||||
|
||||
@ -156,8 +156,7 @@ Reliability and availability
|
||||
|
||||
For more information on
|
||||
managing and maintaining your OpenStack environment, see the
|
||||
`Operations chapter <https://docs.openstack.org/ops-guide/operations.html>`_
|
||||
in the OpenStack Operations Guide.
|
||||
`OpenStack Operations Guide <https://docs.openstack.org/ops-guide/index.html>`_.
|
||||
|
||||
Logging and monitoring
|
||||
----------------------
|
||||
@ -177,8 +176,8 @@ Specific meters that are critically important to capture include:
|
||||
* Response time to the Compute API
|
||||
|
||||
Logging and monitoring does not significantly differ for a multi-site OpenStack
|
||||
cloud. The tools described in the `Logging and monitoring chapter
|
||||
<https://docs.openstack.org/ops-guide/ops-logging-monitoring.html>`__ of
|
||||
cloud. The tools described in the `Logging and monitoring
|
||||
<https://docs.openstack.org/ops-guide/ops-logging-monitoring.html>`__ in
|
||||
the Operations Guide remain applicable. Logging and monitoring can be provided
|
||||
on a per-site basis, and in a common centralized location.
|
||||
|
||||
@ -258,22 +257,3 @@ prepare for situations where it may not be possible to make changes.
|
||||
Additionally, cloud providers may differ on how infrastructure must be managed
|
||||
and exposed. This can lead to delays in root cause analysis where a provider
|
||||
insists the blame lies with the other provider.
|
||||
|
||||
Quota management
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Quotas are used to set operational limits to prevent system capacities
|
||||
from being exhausted without notification. For more
|
||||
information on managing quotas refer to the `Managing projects and users
|
||||
chapter <https://docs.openstack.org/ops-guide/ops-projects-users.html>`__
|
||||
of the OpenStack Operations Guide.
|
||||
|
||||
Policy management
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
OpenStack provides a default set of Role Based Access Control (RBAC)
|
||||
policies, defined in a ``policy.json`` file, for each service. If consistent
|
||||
RBAC policies across sites is a requirement, ensure proper synchronization of
|
||||
the ``policy.json`` files to all installations using system administration
|
||||
tools such as rsync.
|
||||
|
||||
@ -9,16 +9,26 @@ OpenStack Architecture Design Guide
|
||||
|
||||
.. note::
|
||||
|
||||
Parts of this guide is a work in progress. Contributions are welcome.
|
||||
This guide is a work in progress. Contributions are welcome.
|
||||
|
||||
Abstract
|
||||
~~~~~~~~
|
||||
|
||||
This guide provides information on planning and designing an OpenStack
|
||||
cloud. It describes common use cases, high availability, and considerations
|
||||
when changing capacity and scaling your cloud environment. A breakdown of the
|
||||
major OpenStack components is also described in relation to cloud architecture
|
||||
design.
|
||||
The Architecture Design Guide provides information on planning and designing
|
||||
an OpenStack cloud. It explains core concepts, cloud architecture design
|
||||
requirements, and the design criteria of key components and services in an
|
||||
OpenStack cloud. The guide also describes five common cloud use cases.
|
||||
|
||||
Before reading this book, we recommend:
|
||||
|
||||
* Prior knowledge of cloud architecture and principles.
|
||||
* Linux and virtualization experience.
|
||||
* A basic understanding of networking principles and protocols.
|
||||
|
||||
For information about deploying and operating OpenStack, see the
|
||||
`Installation Tutorials and Guides <https://docs.openstack.org/project-install-guide/ocata/>`_,
|
||||
`Deployment Guides <https://docs.openstack.org/project-deploy-guide/ocata/>`_,
|
||||
and the `OpenStack Operations Guide <https://docs.openstack.org/ops-guide/>`_.
|
||||
|
||||
Contents
|
||||
~~~~~~~~
|
||||
@ -27,31 +37,7 @@ Contents
|
||||
:maxdepth: 2
|
||||
|
||||
common/conventions.rst
|
||||
overview.rst
|
||||
use-cases.rst
|
||||
high-availability.rst
|
||||
capacity-planning-scaling.rst
|
||||
arch-requirements.rst
|
||||
design.rst
|
||||
|
||||
Appendix
|
||||
~~~~~~~~
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
common/app-support.rst
|
||||
|
||||
Glossary
|
||||
~~~~~~~~
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
common/glossary.rst
|
||||
|
||||
.. only:: html
|
||||
|
||||
Search
|
||||
~~~~~~
|
||||
|
||||
* :ref:`search`
|
||||
use-cases.rst
|
||||
appendix.rst
|
||||
|
||||
@ -1,93 +0,0 @@
|
||||
.. _legal-requirements:
|
||||
|
||||
==================
|
||||
Legal requirements
|
||||
==================
|
||||
|
||||
Using remote resources for collection, processing, storage,
|
||||
and retrieval provides potential benefits to businesses.
|
||||
With the rapid growth of data within organizations, businesses
|
||||
need to be proactive about their data storage strategies from
|
||||
a compliance point of view.
|
||||
|
||||
Most countries have legislative and regulatory requirements governing
|
||||
the storage and management of data in cloud environments. This is
|
||||
particularly relevant for public, community and hybrid cloud models,
|
||||
to ensure data privacy and protection for organizations using a
|
||||
third party cloud provider.
|
||||
|
||||
Common areas of regulation include:
|
||||
|
||||
* Data retention policies ensuring storage of persistent data
|
||||
and records management to meet data archival requirements.
|
||||
* Data ownership policies governing the possession and
|
||||
responsibility for data.
|
||||
* Data sovereignty policies governing the storage of data in
|
||||
foreign countries or otherwise separate jurisdictions.
|
||||
* Data compliance policies governing certain types of
|
||||
information needing to reside in certain locations due to
|
||||
regulatory issues - and more importantly, cannot reside in
|
||||
other locations for the same reason.
|
||||
* Data location policies ensuring that the services deployed
|
||||
to the cloud are used according to laws and regulations in place
|
||||
for the employees, foreign subsidiaries, or third parties.
|
||||
* Disaster recovery policies ensuring regular data backups and
|
||||
relocation of cloud applications to another supplier in scenarios
|
||||
where a provider may go out of business, or their data center could
|
||||
become inoperable.
|
||||
* Security breach policies governing the ways to notify individuals
|
||||
through cloud provider's systems or other means if their personal
|
||||
data gets compromised in any way.
|
||||
* Industry standards policy governing additional requirements on what
|
||||
type of cardholder data may or may not be stored and how it is to
|
||||
be protected.
|
||||
|
||||
This is an example of such legal frameworks:
|
||||
|
||||
Data storage regulations in Europe are currently driven by provisions of
|
||||
the `Data protection framework <http://ec.europa.eu/justice/data-protection/>`_.
|
||||
`Financial Industry Regulatory Authority
|
||||
<http://www.finra.org/Industry/Regulation/FINRARules/>`_ works on this in
|
||||
the United States.
|
||||
|
||||
Privacy and security are spread over different industry-specific laws and
|
||||
regulations:
|
||||
|
||||
* Health Insurance Portability and Accountability Act (HIPAA)
|
||||
* Gramm-Leach-Bliley Act (GLBA)
|
||||
* Payment Card Industry Data Security Standard (PCI DSS)
|
||||
* Family Educational Rights and Privacy Act (FERPA)
|
||||
|
||||
Cloud security architecture
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Cloud security architecture should recognize the issues
|
||||
that arise with security management, which addresses these issues
|
||||
with security controls. Cloud security controls are put in place to
|
||||
safeguard any weaknesses in the system, and reduce the effect of an attack.
|
||||
|
||||
The following security controls are described below.
|
||||
|
||||
Deterrent controls:
|
||||
Typically reduce the threat level by informing potential attackers
|
||||
that there will be adverse consequences for them if they proceed.
|
||||
|
||||
Preventive controls:
|
||||
Strengthen the system against incidents, generally by reducing
|
||||
if not actually eliminating vulnerabilities.
|
||||
|
||||
Detective controls:
|
||||
Intended to detect and react appropriately to any incidents
|
||||
that occur. System and network security monitoring, including
|
||||
intrusion detection and prevention arrangements, are typically
|
||||
employed to detect attacks on cloud systems and the supporting
|
||||
communications infrastructure.
|
||||
|
||||
Corrective controls:
|
||||
Reduce the consequences of an incident, normally by limiting
|
||||
the damage. They come into effect during or after an incident.
|
||||
Restoring system backups in order to rebuild a compromised
|
||||
system is an example of a corrective control.
|
||||
|
||||
For more information, see See also `NIST Special Publication 800-53
|
||||
<https://web.nvd.nist.gov/view/800-53/home>`_.
|
||||
@ -1,33 +0,0 @@
|
||||
==================
|
||||
Software licensing
|
||||
==================
|
||||
|
||||
The many different forms of license agreements for software are often written
|
||||
with the use of dedicated hardware in mind. This model is relevant for the
|
||||
cloud platform itself, including the hypervisor operating system, supporting
|
||||
software for items such as database, RPC, backup, and so on. Consideration
|
||||
must be made when offering Compute service instances and applications to end
|
||||
users of the cloud, since the license terms for that software may need some
|
||||
adjustment to be able to operate economically in the cloud.
|
||||
|
||||
Multi-site OpenStack deployments present additional licensing
|
||||
considerations over and above regular OpenStack clouds, particularly
|
||||
where site licenses are in use to provide cost efficient access to
|
||||
software licenses. The licensing for host operating systems, guest
|
||||
operating systems, OpenStack distributions (if applicable),
|
||||
software-defined infrastructure including network controllers and
|
||||
storage systems, and even individual applications need to be evaluated.
|
||||
|
||||
Topics to consider include:
|
||||
|
||||
* The definition of what constitutes a site in the relevant licenses,
|
||||
as the term does not necessarily denote a geographic or otherwise
|
||||
physically isolated location.
|
||||
|
||||
* Differentiations between "hot" (active) and "cold" (inactive) sites,
|
||||
where significant savings may be made in situations where one site is
|
||||
a cold standby for disaster recovery purposes only.
|
||||
|
||||
* Certain locations might require local vendors to provide support and
|
||||
services for each site which may vary with the licensing agreement in
|
||||
place.
|
||||
@ -1,60 +0,0 @@
|
||||
========
|
||||
Overview
|
||||
========
|
||||
|
||||
:term:`OpenStack` is a fully-featured, self-service cloud. This book takes you
|
||||
through some of the considerations you have to make when designing your
|
||||
cloud.
|
||||
|
||||
Intended audience
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
This book has been written for architects and designers of OpenStack
|
||||
clouds. For information about deploying and operating OpenStack, see the
|
||||
`OpenStack Operations Guide <https://docs.openstack.org/ops-guide/>`_.
|
||||
|
||||
Before reading this book, we recommend:
|
||||
|
||||
* Prior knowledge of cloud architecture and principles.
|
||||
* Experience in enterprise system design.
|
||||
* Linux and virtualization experience.
|
||||
* A basic understanding of networking principles and protocols.
|
||||
|
||||
How this book is organized
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This book examines some of the most common uses for OpenStack clouds, explains
|
||||
the considerations for each use case, and design criteria for each of the
|
||||
major OpenStack components. Cloud architects may use this book as a
|
||||
comprehensive guide by reading all of the use cases, but it is also possible
|
||||
to read only the chapters which pertain to a specific use case. The sections
|
||||
covered include:
|
||||
|
||||
* :doc:`Cloud Architecture Use Cases <use-cases>`: An examination of some
|
||||
of the most common OpenStack cloud use cases. It covers stakeholder
|
||||
requirements, user stories, an explanation of the design models, and
|
||||
component block diagrams.
|
||||
|
||||
* :doc:`High availability <high-availability>`: Separation of data plane and
|
||||
control plane, and how to eliminate single points of failure.
|
||||
|
||||
* :doc:`Capacity planning and scaling <capacity-planning-scaling>`:
|
||||
Information on how to design your cloud architecture for high network
|
||||
traffic and scalability.
|
||||
|
||||
* :doc:`Cloud architecture design <design>`: A detailed breakdown of the
|
||||
major cloud architecture components, and considerations when designing a
|
||||
cloud. This includes storage choices, networking design choices,
|
||||
implementing keystone, image creation and management, implementation of
|
||||
control plane components, and using Dashboard or cloud management platform
|
||||
tools.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
overview-planning
|
||||
overview-customer-requirements
|
||||
overview-legal-requirements
|
||||
overview-software-licensing
|
||||
overview-security-requirements
|
||||
overview-operator-requirements
|
||||
12
doc/ops-guide/source/appendix.rst
Normal file
12
doc/ops-guide/source/appendix.rst
Normal file
@ -0,0 +1,12 @@
|
||||
Appendix
|
||||
~~~~~~~~
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
app-usecases.rst
|
||||
app-crypt.rst
|
||||
app-roadmaps.rst
|
||||
app-resources.rst
|
||||
common/app-support.rst
|
||||
common/glossary.rst
|
||||
BIN
doc/ops-guide/source/figures/osog_0201.png
Normal file
BIN
doc/ops-guide/source/figures/osog_0201.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 42 KiB |
@ -39,6 +39,9 @@ Contents
|
||||
acknowledgements.rst
|
||||
preface.rst
|
||||
common/conventions.rst
|
||||
ops-deployment-factors.rst
|
||||
ops-planning.rst
|
||||
ops-capacity-planning-scaling.rst
|
||||
ops-lay-of-the-land.rst
|
||||
ops-projects-users.rst
|
||||
ops-user-facing-operations.rst
|
||||
@ -49,30 +52,4 @@ Contents
|
||||
ops-customize.rst
|
||||
ops-advanced-configuration.rst
|
||||
ops-upgrades.rst
|
||||
|
||||
Appendix
|
||||
~~~~~~~~
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
app-usecases.rst
|
||||
app-crypt.rst
|
||||
app-roadmaps.rst
|
||||
app-resources.rst
|
||||
common/app-support.rst
|
||||
|
||||
Glossary
|
||||
~~~~~~~~
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
common/glossary.rst
|
||||
|
||||
.. only:: html
|
||||
|
||||
Search
|
||||
~~~~~~
|
||||
|
||||
* :ref:`search`
|
||||
appendix.rst
|
||||
|
||||
@ -4,9 +4,9 @@
|
||||
Capacity planning and scaling
|
||||
=============================
|
||||
|
||||
Whereas traditional applications required larger hardware to scale
|
||||
(vertical scaling), cloud-based applications typically request more,
|
||||
discrete hardware (horizontal scaling).
|
||||
Cloud-based applications typically request more discrete hardware (horizontal
|
||||
scaling) as opposed to traditional applications, which require larger hardware
|
||||
to scale (vertical scaling).
|
||||
|
||||
OpenStack is designed to be horizontally scalable. Rather than switching
|
||||
to larger servers, you procure more servers and simply install identically
|
||||
@ -14,16 +14,16 @@ configured services. Ideally, you scale out and load balance among groups of
|
||||
functionally identical services (for example, compute nodes or ``nova-api``
|
||||
nodes), that communicate on a message bus.
|
||||
|
||||
The Starting Point
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
Determining cloud scalability
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Determining the scalability of your cloud and how to improve it requires
|
||||
balancing many variables. No one solution meets everyone's scalability goals.
|
||||
However, it is helpful to track a number of metrics. Since you can define
|
||||
virtual hardware templates, called "flavors" in OpenStack, you can start to
|
||||
make scaling decisions based on the flavors you'll provide. These templates
|
||||
define sizes for memory in RAM, root disk size, amount of ephemeral data disk
|
||||
space available, and number of cores for starters.
|
||||
However, it is helpful to track a number of metrics. You can define
|
||||
virtual hardware templates called "flavors" in OpenStack, which will impact
|
||||
your cloud scaling decisions. These templates define sizes for memory in RAM,
|
||||
root disk size, amount of ephemeral data disk space available, and the number
|
||||
of CPU cores.
|
||||
|
||||
The default OpenStack flavors are shown in :ref:`table_default_flavors`.
|
||||
|
||||
@ -85,8 +85,8 @@ and require 80 TB of storage for ``/var/lib/nova/instances``:
|
||||
- Most instances are size m1.medium (two virtual cores, 50 GB of
|
||||
storage).
|
||||
|
||||
- Default CPU overcommit ratio (``cpu_allocation_ratio`` in nova.conf)
|
||||
of 16:1.
|
||||
- Default CPU overcommit ratio (``cpu_allocation_ratio`` in the ``nova.conf``
|
||||
file) of 16:1.
|
||||
|
||||
.. note::
|
||||
Regardless of the overcommit ratio, an instance can not be placed
|
||||
@ -105,8 +105,6 @@ the latter puts constant heavy load on the cloud controller. You must
|
||||
consider your average VM lifetime, as a larger number generally means
|
||||
less load on the cloud controller.
|
||||
|
||||
.. TODO Perhaps relocate the above paragraph under the web scale use case?
|
||||
|
||||
Aside from the creation and termination of VMs, you must consider the
|
||||
impact of users accessing the service particularly on ``nova-api`` and
|
||||
its associated database. Listing instances garners a great deal of
|
||||
@ -133,7 +131,7 @@ CPU performance (CPU/core).
|
||||
metrics from your cloud, see the `OpenStack Operations Guide
|
||||
<https://docs.openstack.org/ops-guide/ops-logging-monitoring.html>`_.
|
||||
|
||||
Adding Cloud Controller Nodes
|
||||
Adding cloud controller nodes
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
You can facilitate the horizontal expansion of your cloud by adding
|
||||
@ -164,18 +162,16 @@ the one machine.
|
||||
Several options are available for MySQL load balancing, and the
|
||||
supported AMQP brokers have built-in clustering support. Information
|
||||
on how to configure these and many of the other services can be
|
||||
found in the `operations chapter
|
||||
<https://docs.openstack.org/ops-guide/operations.html>`_ in the Operations
|
||||
Guide.
|
||||
found in the `Operations Guide
|
||||
<https://docs.openstack.org/ops-guide/operations.html>`_.
|
||||
|
||||
Segregating Your Cloud
|
||||
Segregating your cloud
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
When you want to offer users different regions to provide legal
|
||||
considerations for data storage, redundancy across earthquake fault
|
||||
lines, or for low-latency API calls, you segregate your cloud. Use one
|
||||
of the following OpenStack methods to segregate your cloud: *cells*,
|
||||
*regions*, *availability zones*, or *host aggregates*.
|
||||
Segregating your cloud is needed when users require different regions for legal
|
||||
considerations for data storage, redundancy across earthquake fault lines, or
|
||||
for low-latency API calls. It can be segregated by *cells*, *regions*,
|
||||
*availability zones*, or *host aggregates*.
|
||||
|
||||
Each method provides different functionality and can be best divided
|
||||
into two groups:
|
||||
@ -228,7 +224,7 @@ segregation method currently provided by OpenStack Compute.
|
||||
- Keystone, All nova services
|
||||
- Keystone, All nova services
|
||||
|
||||
Cells and Regions
|
||||
Cells and regions
|
||||
-----------------
|
||||
|
||||
OpenStack Compute cells are designed to allow running the cloud in a
|
||||
@ -258,16 +254,12 @@ The OpenStack dashboard (horizon) can be configured to use multiple
|
||||
regions. This can be configured through the ``AVAILABLE_REGIONS``
|
||||
parameter.
|
||||
|
||||
Availability Zones and Host Aggregates
|
||||
Availability zones and host aggregates
|
||||
--------------------------------------
|
||||
|
||||
You can use availability zones, host aggregates, or both to partition a
|
||||
nova deployment.
|
||||
|
||||
Availability zones are implemented through and configured in a similar
|
||||
way to host aggregates.
|
||||
|
||||
However, you can use them for different reasons.
|
||||
nova deployment. Both methods are configured and implemented in a similar
|
||||
way.
|
||||
|
||||
Availability zone
|
||||
^^^^^^^^^^^^^^^^^
|
||||
@ -429,4 +421,3 @@ while in production can be avoided by appropriate burn-in testing to
|
||||
attempt to trigger the early-stage failures. The general principle is to
|
||||
stress the hardware to its limits. Examples of burn-in tests include
|
||||
running a CPU or disk benchmark for several days.
|
||||
|
||||
@ -1,8 +1,11 @@
|
||||
.. _security-requirements:
|
||||
.. _legal-requirements:
|
||||
|
||||
======================================
|
||||
Factors affecting OpenStack deployment
|
||||
======================================
|
||||
|
||||
=====================
|
||||
Security requirements
|
||||
=====================
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
When deploying OpenStack in an enterprise as a private cloud, it is
|
||||
usually behind the firewall and within the trusted network alongside
|
||||
@ -40,7 +43,7 @@ For more information OpenStack Security, see the `OpenStack Security
|
||||
Guide <https://docs.openstack.org/security-guide/>`_.
|
||||
|
||||
Security domains
|
||||
~~~~~~~~~~~~~~~~
|
||||
----------------
|
||||
|
||||
A security domain comprises of users, applications, servers or networks
|
||||
that share common trust requirements and expectations within a system.
|
||||
@ -89,7 +92,7 @@ OpenStack deployment topology. The domains and their trust requirements depend
|
||||
upon whether the cloud instance is public, private, or hybrid.
|
||||
|
||||
Hypervisor security
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
-------------------
|
||||
|
||||
The hypervisor also requires a security assessment. In a
|
||||
public cloud, organizations typically do not have control
|
||||
@ -106,7 +109,7 @@ important. However, enterprises can minimize vulnerability by avoiding
|
||||
hardware sharing with others in a public cloud.
|
||||
|
||||
Baremetal security
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
------------------
|
||||
|
||||
There are other services worth considering that provide a
|
||||
bare metal instance instead of a cloud. In other cases, it is
|
||||
@ -125,7 +128,7 @@ offers private Cloud-as-a-Service.
|
||||
workloads.
|
||||
|
||||
Networking security
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
-------------------
|
||||
|
||||
Consider security implications and requirements before designing the
|
||||
physical and logical network topologies. Make sure that the networks are
|
||||
@ -144,7 +147,7 @@ network onto dedicated Compute nodes. This prevents attackers
|
||||
from having access to the networks from a compromised instance.
|
||||
|
||||
Multi-site security
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
-------------------
|
||||
|
||||
Securing a multi-site OpenStack installation brings
|
||||
several challenges. Tenants may expect a tenant-created network
|
||||
@ -169,3 +172,128 @@ Networking (neutron). Therefore an external system may be required
|
||||
to manage mapping. Tenant networks may contain sensitive information requiring
|
||||
accurate and consistent mapping to ensure that a tenant in one site
|
||||
does not connect to a different tenant in another site.
|
||||
|
||||
Legal requirements
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Using remote resources for collection, processing, storage,
|
||||
and retrieval provides potential benefits to businesses.
|
||||
With the rapid growth of data within organizations, businesses
|
||||
need to be proactive about their data storage strategies from
|
||||
a compliance point of view.
|
||||
|
||||
Most countries have legislative and regulatory requirements governing
|
||||
the storage and management of data in cloud environments. This is
|
||||
particularly relevant for public, community and hybrid cloud models,
|
||||
to ensure data privacy and protection for organizations using a
|
||||
third party cloud provider.
|
||||
|
||||
Common areas of regulation include:
|
||||
|
||||
* Data retention policies ensuring storage of persistent data
|
||||
and records management to meet data archival requirements.
|
||||
* Data ownership policies governing the possession and
|
||||
responsibility for data.
|
||||
* Data sovereignty policies governing the storage of data in
|
||||
foreign countries or otherwise separate jurisdictions.
|
||||
* Data compliance policies governing certain types of
|
||||
information needing to reside in certain locations due to
|
||||
regulatory issues - and more importantly, cannot reside in
|
||||
other locations for the same reason.
|
||||
* Data location policies ensuring that the services deployed
|
||||
to the cloud are used according to laws and regulations in place
|
||||
for the employees, foreign subsidiaries, or third parties.
|
||||
* Disaster recovery policies ensuring regular data backups and
|
||||
relocation of cloud applications to another supplier in scenarios
|
||||
where a provider may go out of business, or their data center could
|
||||
become inoperable.
|
||||
* Security breach policies governing the ways to notify individuals
|
||||
through cloud provider's systems or other means if their personal
|
||||
data gets compromised in any way.
|
||||
* Industry standards policy governing additional requirements on what
|
||||
type of cardholder data may or may not be stored and how it is to
|
||||
be protected.
|
||||
|
||||
This is an example of such legal frameworks:
|
||||
|
||||
Data storage regulations in Europe are currently driven by provisions of
|
||||
the `Data protection framework <http://ec.europa.eu/justice/data-protection/>`_.
|
||||
`Financial Industry Regulatory Authority
|
||||
<http://www.finra.org/Industry/Regulation/FINRARules/>`_ works on this in
|
||||
the United States.
|
||||
|
||||
Privacy and security are spread over different industry-specific laws and
|
||||
regulations:
|
||||
|
||||
* Health Insurance Portability and Accountability Act (HIPAA)
|
||||
* Gramm-Leach-Bliley Act (GLBA)
|
||||
* Payment Card Industry Data Security Standard (PCI DSS)
|
||||
* Family Educational Rights and Privacy Act (FERPA)
|
||||
|
||||
Cloud security architecture
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Cloud security architecture should recognize the issues
|
||||
that arise with security management, which addresses these issues
|
||||
with security controls. Cloud security controls are put in place to
|
||||
safeguard any weaknesses in the system, and reduce the effect of an attack.
|
||||
|
||||
The following security controls are described below.
|
||||
|
||||
Deterrent controls:
|
||||
Typically reduce the threat level by informing potential attackers
|
||||
that there will be adverse consequences for them if they proceed.
|
||||
|
||||
Preventive controls:
|
||||
Strengthen the system against incidents, generally by reducing
|
||||
if not actually eliminating vulnerabilities.
|
||||
|
||||
Detective controls:
|
||||
Intended to detect and react appropriately to any incidents
|
||||
that occur. System and network security monitoring, including
|
||||
intrusion detection and prevention arrangements, are typically
|
||||
employed to detect attacks on cloud systems and the supporting
|
||||
communications infrastructure.
|
||||
|
||||
Corrective controls:
|
||||
Reduce the consequences of an incident, normally by limiting
|
||||
the damage. They come into effect during or after an incident.
|
||||
Restoring system backups in order to rebuild a compromised
|
||||
system is an example of a corrective control.
|
||||
|
||||
For more information, see See also `NIST Special Publication 800-53
|
||||
<https://web.nvd.nist.gov/view/800-53/home>`_.
|
||||
|
||||
|
||||
Software licensing
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The many different forms of license agreements for software are often written
|
||||
with the use of dedicated hardware in mind. This model is relevant for the
|
||||
cloud platform itself, including the hypervisor operating system, supporting
|
||||
software for items such as database, RPC, backup, and so on. Consideration
|
||||
must be made when offering Compute service instances and applications to end
|
||||
users of the cloud, since the license terms for that software may need some
|
||||
adjustment to be able to operate economically in the cloud.
|
||||
|
||||
Multi-site OpenStack deployments present additional licensing
|
||||
considerations over and above regular OpenStack clouds, particularly
|
||||
where site licenses are in use to provide cost efficient access to
|
||||
software licenses. The licensing for host operating systems, guest
|
||||
operating systems, OpenStack distributions (if applicable),
|
||||
software-defined infrastructure including network controllers and
|
||||
storage systems, and even individual applications need to be evaluated.
|
||||
|
||||
Topics to consider include:
|
||||
|
||||
* The definition of what constitutes a site in the relevant licenses,
|
||||
as the term does not necessarily denote a geographic or otherwise
|
||||
physically isolated location.
|
||||
|
||||
* Differentiations between "hot" (active) and "cold" (inactive) sites,
|
||||
where significant savings may be made in situations where one site is
|
||||
a cold standby for disaster recovery purposes only.
|
||||
|
||||
* Certain locations might require local vendors to provide support and
|
||||
services for each site which may vary with the licensing agreement in
|
||||
place.
|
||||
Loading…
Reference in New Issue
Block a user