[arch-design-draft] Migrate content
1. Migrate customer requirements content from arch-guide-draft-mitaka to the Overview chapter and Design chapter 2. Migrate Provisioning and Deployment section from the Ops Guide to the Overview chapter Change-Id: I6962986d17bfa1584a3fc5d5695d5297b35fb9b8 Implements: blueprint arch-guide-restructure
This commit is contained in:
daz
KATO Tomoyuki
parent
f28d3684d7
commit
5b1188077b
|
|
@ -1,194 +0,0 @@
|
|||
====================
|
||||
Usage considerations
|
||||
====================
|
||||
|
||||
Application readiness
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Some applications are tolerant of a lack of synchronized object
|
||||
storage, while others may need those objects to be replicated and
|
||||
available across regions. Understanding how the cloud implementation
|
||||
impacts new and existing applications is important for risk mitigation,
|
||||
and the overall success of a cloud project. Applications may have to be
|
||||
written or rewritten for an infrastructure with little to no redundancy,
|
||||
or with the cloud in mind.
|
||||
|
||||
Application momentum
|
||||
Businesses with existing applications may find that it is
|
||||
more cost effective to integrate applications on multiple
|
||||
cloud platforms than migrating them to a single platform.
|
||||
|
||||
No predefined usage model
|
||||
The lack of a pre-defined usage model enables the user to run a wide
|
||||
variety of applications without having to know the application
|
||||
requirements in advance. This provides a degree of independence and
|
||||
flexibility that no other cloud scenarios are able to provide.
|
||||
|
||||
On-demand and self-service application
|
||||
By definition, a cloud provides end users with the ability to
|
||||
self-provision computing power, storage, networks, and software in a
|
||||
simple and flexible way. The user must be able to scale their
|
||||
resources up to a substantial level without disrupting the
|
||||
underlying host operations. One of the benefits of using a general
|
||||
purpose cloud architecture is the ability to start with limited
|
||||
resources and increase them over time as the user demand grows.
|
||||
|
||||
|
||||
Cloud type
|
||||
~~~~~~~~~~
|
||||
|
||||
Public cloud
|
||||
For a company interested in building a commercial public cloud
|
||||
offering based on OpenStack, the general purpose architecture model
|
||||
might be the best choice. Designers are not always going to know the
|
||||
purposes or workloads for which the end users will use the cloud.
|
||||
|
||||
Internal consumption (private) cloud
|
||||
Organizations need to determine if it is logical to create their own
|
||||
clouds internally. Using a private cloud, organizations are able to
|
||||
maintain complete control over architectural and cloud components.
|
||||
|
||||
Hybrid cloud
|
||||
Users may want to combine using the internal cloud with access
|
||||
to an external cloud. If that case is likely, it might be worth
|
||||
exploring the possibility of taking a multi-cloud approach with
|
||||
regard to at least some of the architectural elements.
|
||||
|
||||
|
||||
Tools
|
||||
~~~~~
|
||||
|
||||
Complex clouds, in particular hybrid clouds, may require tools to
|
||||
facilitate working across multiple clouds.
|
||||
|
||||
Broker between clouds
|
||||
Brokering software evaluates relative costs between different
|
||||
cloud platforms. Cloud Management Platforms (CMP)
|
||||
allow the designer to determine the right location for the
|
||||
workload based on predetermined criteria.
|
||||
|
||||
Facilitate orchestration across the clouds
|
||||
CMPs simplify the migration of application workloads between
|
||||
public, private, and hybrid cloud platforms.
|
||||
|
||||
We recommend using cloud orchestration tools for managing a diverse
|
||||
portfolio of systems and applications across multiple cloud platforms.
|
||||
|
||||
|
||||
Workload considerations
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
A workload can be a single application or a suite of applications
|
||||
that work together. It can also be a duplicate set of applications that
|
||||
need to run on multiple cloud environments.
|
||||
|
||||
In a hybrid cloud deployment, the same workload often needs to function
|
||||
equally well on radically different public and private cloud environments.
|
||||
The architecture needs to address these potential conflicts,
|
||||
complexity, and platform incompatibilities.
|
||||
|
||||
Federated hypervisor and instance management
|
||||
Adding self-service, charge back, and transparent delivery of
|
||||
the resources from a federated pool can be cost effective.
|
||||
|
||||
In a hybrid cloud environment, this is a particularly important
|
||||
consideration. Look for a cloud that provides cross-platform
|
||||
hypervisor support and robust instance management tools.
|
||||
|
||||
Application portfolio integration
|
||||
An enterprise cloud delivers efficient application portfolio
|
||||
management and deployments by leveraging self-service features
|
||||
and rules according to use.
|
||||
|
||||
Integrating existing cloud environments is a common driver
|
||||
when building hybrid cloud architectures.
|
||||
|
||||
|
||||
Capacity planning
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
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
|
||||
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.
|
||||
|
||||
It is difficult to predict the amount of load a particular
|
||||
application might incur if the number of users fluctuates, or the
|
||||
application experiences an unexpected increase in use.
|
||||
It is possible to define application requirements in terms of
|
||||
vCPU, RAM, bandwidth, or other resources and plan appropriately.
|
||||
However, other clouds might not use the same meter or even the same
|
||||
oversubscription rates.
|
||||
|
||||
Oversubscription is a method to emulate more capacity than
|
||||
may physically be present. For example, a physical hypervisor node with 32 GB
|
||||
RAM may host 24 instances, each provisioned with 2 GB RAM.
|
||||
As long as all 24 instances do not concurrently use 2 full
|
||||
gigabytes, this arrangement works well.
|
||||
However, some hosts take oversubscription to extremes and,
|
||||
as a result, performance can be inconsistent.
|
||||
If at all possible, determine what the oversubscription rates
|
||||
of each host are and plan capacity accordingly.
|
||||
|
||||
|
||||
Utilization
|
||||
~~~~~~~~~~~
|
||||
|
||||
A CMP must be aware of what workloads are running, where they are
|
||||
running, and their preferred utilizations.
|
||||
For example, in most cases it is desirable to run as many workloads
|
||||
internally as possible, utilizing other resources only when necessary.
|
||||
On the other hand, situations exist in which the opposite is true,
|
||||
such as when an internal cloud is only for development and stressing
|
||||
it is undesirable. A cost model of various scenarios and
|
||||
consideration of internal priorities helps with this decision.
|
||||
To improve efficiency, automate these decisions when possible.
|
||||
|
||||
The Telemetry service (ceilometer) provides information on the usage
|
||||
of various OpenStack components. Note the following:
|
||||
|
||||
* If Telemetry must retain a large amount of data, for
|
||||
example when monitoring a large or active cloud, we recommend
|
||||
using a NoSQL back end such as MongoDB.
|
||||
* You must monitor connections to non-OpenStack clouds
|
||||
and report this information to the CMP.
|
||||
|
||||
|
||||
Authentication
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
It is recommended to have a single authentication domain rather than a
|
||||
separate implementation for each and every site. This requires an
|
||||
authentication mechanism that is highly available and distributed to
|
||||
ensure continuous operation. Authentication server locality might be
|
||||
required and should be planned for.
|
||||
|
||||
|
||||
Storage
|
||||
~~~~~~~
|
||||
|
||||
OpenStack compatibility
|
||||
Interoperability and integration with OpenStack can be paramount in
|
||||
deciding on a storage hardware and storage management platform.
|
||||
Interoperability and integration includes factors such as OpenStack
|
||||
Block Storage interoperability, OpenStack Object Storage
|
||||
compatibility, and hypervisor compatibility (which affects the
|
||||
ability to use storage for ephemeral instance storage).
|
||||
|
||||
Storage management
|
||||
You must address a range of storage management-related
|
||||
considerations in the design of a storage-focused OpenStack cloud.
|
||||
These considerations include, but are not limited to, backup
|
||||
strategy (and restore strategy, since a backup that cannot be
|
||||
restored is useless), data valuation-hierarchical storage
|
||||
management, retention strategy, data placement, and workflow
|
||||
automation.
|
||||
|
||||
Data grids
|
||||
Data grids are helpful when answering questions around data
|
||||
valuation. Data grids improve decision making through correlation of
|
||||
access patterns, ownership, and business-unit revenue with other
|
||||
metadata values to deliver actionable information about data.
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
=====================
|
||||
Customer requirements
|
||||
=====================
|
||||
|
||||
A customer's business requirements impact cloud design. These requirements
|
||||
can be broken down into three general areas: business considerations,
|
||||
usage considerations, and performance considerations.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
customer-requirements-business-considerations.rst
|
||||
customer-requirements-usage-considerations.rst
|
||||
customer-requirements-performance-considerations.rst
|
||||
|
|
@ -0,0 +1,49 @@
|
|||
===============================
|
||||
Cloud management platform tools
|
||||
===============================
|
||||
|
||||
Complex clouds, in particular hybrid clouds, may require tools to
|
||||
facilitate working across multiple clouds.
|
||||
|
||||
Broker between clouds
|
||||
Brokering software evaluates relative costs between different
|
||||
cloud platforms. Cloud Management Platforms (CMP)
|
||||
allow the designer to determine the right location for the
|
||||
workload based on predetermined criteria.
|
||||
|
||||
Facilitate orchestration across the clouds
|
||||
CMPs simplify the migration of application workloads between
|
||||
public, private, and hybrid cloud platforms.
|
||||
|
||||
We recommend using cloud orchestration tools for managing a diverse
|
||||
portfolio of systems and applications across multiple cloud platforms.
|
||||
|
||||
Technical details
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. TODO
|
||||
|
||||
Capacity and scale
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. TODO
|
||||
|
||||
High availability
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. TODO
|
||||
|
||||
Operator requirements
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. TODO
|
||||
|
||||
Deployment considerations
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. TODO
|
||||
|
||||
Maintenance considerations
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. TODO
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
==================
|
||||
Dashboard and APIs
|
||||
==================
|
||||
|
|
@ -47,4 +47,4 @@ where privileged administrator commands are necessary.
|
|||
design-identity.rst
|
||||
design-images.rst
|
||||
design-control-plane.rst
|
||||
design-dashboard-api.rst
|
||||
design-cmp-tools.rst
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 42 KiB |
|
|
@ -1,8 +1,113 @@
|
|||
==========================
|
||||
Performance considerations
|
||||
==========================
|
||||
=====================
|
||||
Customer requirements
|
||||
=====================
|
||||
|
||||
Performance is a critical considertion when designing any cloud, and becomes
|
||||
The following sections describe business, usage, and performance
|
||||
considerations for customers which will impact cloud design.
|
||||
|
||||
Cost
|
||||
~~~~
|
||||
|
||||
Financial factors are a primary concern for any organization. Cost
|
||||
considerations may influence the type of cloud that you build.
|
||||
For example, a general purpose cloud is unlikely to be the most
|
||||
cost-effective environment for specialized applications.
|
||||
Unless business needs dictate that cost is a critical factor,
|
||||
cost should not be the sole consideration when choosing or designing a cloud.
|
||||
|
||||
As a general guideline, increasing the complexity of a cloud architecture
|
||||
increases the cost of building and maintaining it. For example, a hybrid or
|
||||
multi-site cloud architecture involving multiple vendors and technical
|
||||
architectures may require higher setup and operational costs because of the
|
||||
need for more sophisticated orchestration and brokerage tools than in other
|
||||
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.
|
||||
|
||||
Consider the following costs categories when designing a cloud:
|
||||
|
||||
* Compute resources
|
||||
|
||||
* Networking resources
|
||||
|
||||
* Replication
|
||||
|
||||
* Storage
|
||||
|
||||
* Management
|
||||
|
||||
* Operational costs
|
||||
|
||||
It is also important to consider how costs will increase as your cloud scales.
|
||||
Choices that have a negligible impact in small systems may considerably
|
||||
increase costs in large systems. In these cases, it is important to minimize
|
||||
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 OpenCompute (more information available
|
||||
at 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.
|
||||
|
||||
Time-to-market
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
The ability to deliver services or products within a flexible time
|
||||
frame is a common business factor when building a cloud. Allowing users to
|
||||
self-provision and gain access to compute, network, and
|
||||
storage resources on-demand may decrease time-to-market for new products
|
||||
and applications.
|
||||
|
||||
You must balance the time required to build a new cloud platform against the
|
||||
time saved by migrating users away from legacy platforms. In some cases,
|
||||
existing infrastructure may influence your architecture choices. For example,
|
||||
using multiple cloud platforms may be a good option when there is an existing
|
||||
investment in several applications, as it could be faster to tie the
|
||||
investments together rather than migrating the components and refactoring them
|
||||
to a single platform.
|
||||
|
||||
Revenue opportunity
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Revenue opportunities vary based on the intent and use case of the cloud.
|
||||
The requirements of a commercial, customer-facing product are often very
|
||||
different from an internal, private cloud. You must consider what features
|
||||
make your design most attractive to your users.
|
||||
|
||||
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
|
||||
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.
|
||||
|
||||
It is difficult to predict the amount of load a particular
|
||||
application might incur if the number of users fluctuates, or the
|
||||
application experiences an unexpected increase in use.
|
||||
It is possible to define application requirements in terms of
|
||||
vCPU, RAM, bandwidth, or other resources and plan appropriately.
|
||||
However, other clouds might not use the same meter or even the same
|
||||
oversubscription rates.
|
||||
|
||||
Oversubscription is a method to emulate more capacity than
|
||||
may physically be present. For example, a physical hypervisor node with 32 GB
|
||||
RAM may host 24 instances, each provisioned with 2 GB RAM.
|
||||
As long as all 24 instances do not concurrently use 2 full
|
||||
gigabytes, this arrangement works well.
|
||||
However, some hosts take oversubscription to extremes and,
|
||||
as a result, performance can be inconsistent.
|
||||
If at all possible, determine what the oversubscription rates
|
||||
of each host are and plan capacity accordingly.
|
||||
|
||||
Performance
|
||||
~~~~~~~~~~~
|
||||
|
||||
Performance is a critical consideration when designing any cloud, and becomes
|
||||
increasingly important as size and complexity grow. While single-site, private
|
||||
clouds can be closely controlled, multi-site and hybrid deployments require
|
||||
more careful planning to reduce problems such as network latency between sites.
|
||||
|
|
@ -83,9 +188,8 @@ Scale
|
|||
capacity, while also allowing flexibility to implement new
|
||||
technologies and methods as they become available.
|
||||
|
||||
|
||||
Network considerations
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
Network
|
||||
~~~~~~~
|
||||
|
||||
It is important to consider the functionality, security, scalability,
|
||||
availability, and testability of the network when choosing a CMP and cloud
|
||||
|
|
@ -157,22 +261,117 @@ Dynamic resource expansion or bursting
|
|||
a public cloud for these peak load periods. These bursts could be
|
||||
for long or short cycles ranging from hourly to yearly.
|
||||
|
||||
Compliance and geo-location
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Consistency of images and templates across different sites
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
An organization may have certain legal obligations and regulatory
|
||||
compliance measures which could require certain workloads or data to not
|
||||
be located in certain regions.
|
||||
|
||||
It is essential that the deployment of instances is consistent across
|
||||
different sites and built into the infrastructure. If OpenStack
|
||||
Object Storage is used as a back end for the Image service, it is
|
||||
possible to create repositories of consistent images across multiple
|
||||
sites. Having central endpoints with multiple storage nodes allows
|
||||
consistent centralized storage for every site.
|
||||
Compliance considerations are particularly important for multi-site clouds.
|
||||
Considerations include:
|
||||
|
||||
Not using a centralized object store increases the operational overhead
|
||||
of maintaining a consistent image library. This could include
|
||||
development of a replication mechanism to handle the transport of images
|
||||
and the changes to the images across multiple sites.
|
||||
- federal legal requirements
|
||||
- local jurisdictional legal and compliance requirements
|
||||
- image consistency and availability
|
||||
- storage replication and availability (both block and file/object storage)
|
||||
- authentication, authorization, and auditing (AAA)
|
||||
|
||||
Geographical considerations may also impact the cost of building or leasing
|
||||
data centers. Considerations include:
|
||||
|
||||
- floor space
|
||||
- floor weight
|
||||
- rack height and type
|
||||
- environmental considerations
|
||||
- power usage and power usage efficiency (PUE)
|
||||
- physical security
|
||||
|
||||
|
||||
Auditing
|
||||
~~~~~~~~
|
||||
|
||||
A well-considered auditing plan is essential for quickly finding issues.
|
||||
Keeping track of changes made to security groups and tenant changes can be
|
||||
useful in rolling back the changes if they affect production. For example,
|
||||
if all security group rules for a tenant disappeared, the ability to quickly
|
||||
track down the issue would be important for operational and legal reasons.
|
||||
For more details on auditing, see the `Compliance chapter
|
||||
<http://docs.openstack.org/security-guide/compliance.html>`_ in the OpenStack
|
||||
Security Guide.
|
||||
|
||||
Security
|
||||
~~~~~~~~
|
||||
|
||||
The importance of security varies based on the type of organization using
|
||||
a cloud. For example, government and financial institutions often have
|
||||
very high security requirements. Security should be implemented according to
|
||||
asset, threat, and vulnerability risk assessment matrices.
|
||||
See `security-requirements`.
|
||||
|
||||
Service level agreements
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Service level agreements (SLA) must be developed in conjunction with business,
|
||||
technical, and legal input. Small, private clouds may operate under an informal
|
||||
SLA, but hybrid or public clouds generally require more formal agreements with
|
||||
their users.
|
||||
|
||||
For a user of a massively scalable OpenStack public cloud, there are no
|
||||
expectations for control over security, performance, or availability. Users
|
||||
expect only SLAs related to uptime of API services, and very basic SLAs for
|
||||
services offered. It is the user's responsibility to address these issues on
|
||||
their own. The exception to this expectation is the rare case of a massively
|
||||
scalable cloud infrastructure built for a private or government organization
|
||||
that has specific requirements.
|
||||
|
||||
High performance systems have SLA requirements for a minimum quality of service
|
||||
with regard to guaranteed uptime, latency, and bandwidth. The level of the
|
||||
SLA can have a significant impact on the network architecture and
|
||||
requirements for redundancy in the systems.
|
||||
|
||||
Hybrid cloud designs must accommodate differences in SLAs between providers,
|
||||
and consider their enforceability.
|
||||
|
||||
Application readiness
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Some applications are tolerant of a lack of synchronized object
|
||||
storage, while others may need those objects to be replicated and
|
||||
available across regions. Understanding how the cloud implementation
|
||||
impacts new and existing applications is important for risk mitigation,
|
||||
and the overall success of a cloud project. Applications may have to be
|
||||
written or rewritten for an infrastructure with little to no redundancy,
|
||||
or with the cloud in mind.
|
||||
|
||||
Application momentum
|
||||
Businesses with existing applications may find that it is
|
||||
more cost effective to integrate applications on multiple
|
||||
cloud platforms than migrating them to a single platform.
|
||||
|
||||
No predefined usage model
|
||||
The lack of a pre-defined usage model enables the user to run a wide
|
||||
variety of applications without having to know the application
|
||||
requirements in advance. This provides a degree of independence and
|
||||
flexibility that no other cloud scenarios are able to provide.
|
||||
|
||||
On-demand and self-service application
|
||||
By definition, a cloud provides end users with the ability to
|
||||
self-provision computing power, storage, networks, and software in a
|
||||
simple and flexible way. The user must be able to scale their
|
||||
resources up to a substantial level without disrupting the
|
||||
underlying host operations. One of the benefits of using a general
|
||||
purpose cloud architecture is the ability to start with limited
|
||||
resources and increase them over time as the user demand grows.
|
||||
|
||||
Authentication
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
It is recommended to have a single authentication domain rather than a
|
||||
separate implementation for each and every site. This requires an
|
||||
authentication mechanism that is highly available and distributed to
|
||||
ensure continuous operation. Authentication server locality might be
|
||||
required and should be planned for.
|
||||
|
||||
Migration, availability, site loss and recovery
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -0,0 +1,252 @@
|
|||
=================================================
|
||||
Planning for deploying and provisioning OpenStack
|
||||
=================================================
|
||||
|
||||
The decisions you make with respect to provisioning and deployment will
|
||||
affect your maintenance of the cloud. Your configuration management will be
|
||||
able to evolve over time. However, more thought and design need to be done
|
||||
for upfront choices about deployment, disk partitioning, and network
|
||||
configuration.
|
||||
|
||||
A critical part of a cloud's scalability is the amount of effort that it
|
||||
takes to run your cloud. To minimize the operational cost of running
|
||||
your cloud, set up and use an automated deployment and configuration
|
||||
infrastructure with a configuration management system, such as :term:`Puppet`
|
||||
or :term:`Chef`. Combined, these systems greatly reduce manual effort and the
|
||||
chance for operator error.
|
||||
|
||||
This infrastructure includes systems to automatically install the
|
||||
operating system's initial configuration and later coordinate the
|
||||
configuration of all services automatically and centrally, which reduces
|
||||
both manual effort and the chance for error. Examples include Ansible,
|
||||
CFEngine, Chef, Puppet, and Salt. You can even use OpenStack to deploy
|
||||
OpenStack, named TripleO (OpenStack On OpenStack).
|
||||
|
||||
Automated deployment
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
An automated deployment system installs and configures operating systems
|
||||
on new servers, without intervention, after the absolute minimum amount
|
||||
of manual work, including physical racking, MAC-to-IP assignment, and
|
||||
power configuration. Typically, solutions rely on wrappers around PXE
|
||||
boot and TFTP servers for the basic operating system install and then
|
||||
hand off to an automated configuration management system.
|
||||
|
||||
Both Ubuntu and Red Hat Enterprise Linux include mechanisms for
|
||||
configuring the operating system, including preseed and kickstart, that
|
||||
you can use after a network boot. Typically, these are used to bootstrap
|
||||
an automated configuration system. Alternatively, you can use an
|
||||
image-based approach for deploying the operating system, such as
|
||||
systemimager. You can use both approaches with a virtualized
|
||||
infrastructure, such as when you run VMs to separate your control
|
||||
services and physical infrastructure.
|
||||
|
||||
When you create a deployment plan, focus on a few vital areas because
|
||||
they are very hard to modify post deployment. The next two sections talk
|
||||
about configurations for:
|
||||
|
||||
- Disk partitioning and disk array setup for scalability
|
||||
|
||||
- Networking configuration just for PXE booting
|
||||
|
||||
Disk partitioning and RAID
|
||||
--------------------------
|
||||
|
||||
At the very base of any operating system are the hard drives on which
|
||||
the operating system (OS) is installed.
|
||||
|
||||
You must complete the following configurations on the server's hard
|
||||
drives:
|
||||
|
||||
- Partitioning, which provides greater flexibility for layout of
|
||||
operating system and swap space, as described below.
|
||||
|
||||
- Adding to a RAID array (RAID stands for redundant array of
|
||||
independent disks), based on the number of disks you have available,
|
||||
so that you can add capacity as your cloud grows. Some options are
|
||||
described in more detail below.
|
||||
|
||||
The simplest option to get started is to use one hard drive with two
|
||||
partitions:
|
||||
|
||||
- File system to store files and directories, where all the data lives,
|
||||
including the root partition that starts and runs the system.
|
||||
|
||||
- Swap space to free up memory for processes, as an independent area of
|
||||
the physical disk used only for swapping and nothing else.
|
||||
|
||||
RAID is not used in this simplistic one-drive setup because generally
|
||||
for production clouds, you want to ensure that if one disk fails,
|
||||
another can take its place. Instead, for production, use more than one
|
||||
disk. The number of disks determine what types of RAID arrays to build.
|
||||
|
||||
We recommend that you choose one of the following multiple disk options:
|
||||
|
||||
Option 1
|
||||
Partition all drives in the same way in a horizontal fashion, as
|
||||
shown in :ref:`partition_setup`.
|
||||
|
||||
With this option, you can assign different partitions to different
|
||||
RAID arrays. You can allocate partition 1 of disk one and two to the
|
||||
``/boot`` partition mirror. You can make partition 2 of all disks
|
||||
the root partition mirror. You can use partition 3 of all disks for
|
||||
a ``cinder-volumes`` LVM partition running on a RAID 10 array.
|
||||
|
||||
.. _partition_setup:
|
||||
|
||||
.. figure:: figures/osog_0201.png
|
||||
|
||||
Partition setup of drives
|
||||
|
||||
While you might end up with unused partitions, such as partition 1
|
||||
in disk three and four of this example, this option allows for
|
||||
maximum utilization of disk space. I/O performance might be an issue
|
||||
as a result of all disks being used for all tasks.
|
||||
|
||||
Option 2
|
||||
Add all raw disks to one large RAID array, either hardware or
|
||||
software based. You can partition this large array with the boot,
|
||||
root, swap, and LVM areas. This option is simple to implement and
|
||||
uses all partitions. However, disk I/O might suffer.
|
||||
|
||||
Option 3
|
||||
Dedicate entire disks to certain partitions. For example, you could
|
||||
allocate disk one and two entirely to the boot, root, and swap
|
||||
partitions under a RAID 1 mirror. Then, allocate disk three and four
|
||||
entirely to the LVM partition, also under a RAID 1 mirror. Disk I/O
|
||||
should be better because I/O is focused on dedicated tasks. However,
|
||||
the LVM partition is much smaller.
|
||||
|
||||
.. tip::
|
||||
|
||||
You may find that you can automate the partitioning itself. For
|
||||
example, MIT uses `Fully Automatic Installation
|
||||
(FAI) <http://fai-project.org/>`_ to do the initial PXE-based
|
||||
partition and then install using a combination of min/max and
|
||||
percentage-based partitioning.
|
||||
|
||||
As with most architecture choices, the right answer depends on your
|
||||
environment. If you are using existing hardware, you know the disk
|
||||
density of your servers and can determine some decisions based on the
|
||||
options above. If you are going through a procurement process, your
|
||||
user's requirements also help you determine hardware purchases. Here are
|
||||
some examples from a private cloud providing web developers custom
|
||||
environments at AT&T. This example is from a specific deployment, so
|
||||
your existing hardware or procurement opportunity may vary from this.
|
||||
AT&T uses three types of hardware in its deployment:
|
||||
|
||||
- Hardware for controller nodes, used for all stateless OpenStack API
|
||||
services. About 32–64 GB memory, small attached disk, one processor,
|
||||
varied number of cores, such as 6–12.
|
||||
|
||||
- Hardware for compute nodes. Typically 256 or 144 GB memory, two
|
||||
processors, 24 cores. 4–6 TB direct attached storage, typically in a
|
||||
RAID 5 configuration.
|
||||
|
||||
- Hardware for storage nodes. Typically for these, the disk space is
|
||||
optimized for the lowest cost per GB of storage while maintaining
|
||||
rack-space efficiency.
|
||||
|
||||
Again, the right answer depends on your environment. You have to make
|
||||
your decision based on the trade-offs between space utilization,
|
||||
simplicity, and I/O performance.
|
||||
|
||||
Network configuration
|
||||
---------------------
|
||||
|
||||
.. TODO Reference to networking sections in the following paragraph.
|
||||
|
||||
Network configuration is a very large topic that spans multiple areas of
|
||||
this book. For now, make sure that your servers can PXE boot and
|
||||
successfully communicate with the deployment server.
|
||||
|
||||
For example, you usually cannot configure NICs for VLANs when PXE
|
||||
booting. Additionally, you usually cannot PXE boot with bonded NICs. If
|
||||
you run into this scenario, consider using a simple 1 GB switch in a
|
||||
private network on which only your cloud communicates.
|
||||
|
||||
Automated configuration
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The purpose of automatic configuration management is to establish and
|
||||
maintain the consistency of a system without using human intervention.
|
||||
You want to maintain consistency in your deployments so that you can
|
||||
have the same cloud every time, repeatably. Proper use of automatic
|
||||
configuration-management tools ensures that components of the cloud
|
||||
systems are in particular states, in addition to simplifying deployment,
|
||||
and configuration change propagation.
|
||||
|
||||
These tools also make it possible to test and roll back changes, as they
|
||||
are fully repeatable. Conveniently, a large body of work has been done
|
||||
by the OpenStack community in this space. Puppet, a configuration
|
||||
management tool, even provides official modules for OpenStack projects
|
||||
in an OpenStack infrastructure system known as `Puppet
|
||||
OpenStack <https://wiki.openstack.org/wiki/Puppet>`_. Chef
|
||||
configuration management is provided within
|
||||
https://git.openstack.org/cgit/openstack/openstack-chef-repo. Additional
|
||||
configuration management systems include Juju, Ansible, and Salt. Also,
|
||||
PackStack is a command-line utility for Red Hat Enterprise Linux and
|
||||
derivatives that uses Puppet modules to support rapid deployment of
|
||||
OpenStack on existing servers over an SSH connection.
|
||||
|
||||
An integral part of a configuration-management system is the item that
|
||||
it controls. You should carefully consider all of the items that you
|
||||
want, or do not want, to be automatically managed. For example, you may
|
||||
not want to automatically format hard drives with user data.
|
||||
|
||||
Remote management
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
In our experience, most operators don't sit right next to the servers
|
||||
running the cloud, and many don't necessarily enjoy visiting the data
|
||||
center. OpenStack should be entirely remotely configurable, but
|
||||
sometimes not everything goes according to plan.
|
||||
|
||||
In this instance, having an out-of-band access into nodes running
|
||||
OpenStack components is a boon. The IPMI protocol is the de facto
|
||||
standard here, and acquiring hardware that supports it is highly
|
||||
recommended to achieve that lights-out data center aim.
|
||||
|
||||
In addition, consider remote power control as well. While IPMI usually
|
||||
controls the server's power state, having remote access to the PDU that
|
||||
the server is plugged into can really be useful for situations when
|
||||
everything seems wedged.
|
||||
|
||||
Other considerations
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. TODO In the first paragraph, reference to use case sections.
|
||||
|
||||
You can save time by understanding the use cases for the cloud you want
|
||||
to create. Use cases for OpenStack are varied. Some include object
|
||||
storage only; others require preconfigured compute resources to speed
|
||||
development-environment set up; and others need fast provisioning of
|
||||
compute resources that are already secured per tenant with private
|
||||
networks. Your users may have need for highly redundant servers to make
|
||||
sure their legacy applications continue to run. Perhaps a goal would be
|
||||
to architect these legacy applications so that they run on multiple
|
||||
instances in a cloudy, fault-tolerant way, but not make it a goal to add
|
||||
to those clusters over time. Your users may indicate that they need
|
||||
scaling considerations because of heavy Windows server use.
|
||||
|
||||
You can save resources by looking at the best fit for the hardware you
|
||||
have in place already. You might have some high-density storage hardware
|
||||
available. You could format and repurpose those servers for OpenStack
|
||||
Object Storage. All of these considerations and input from users help
|
||||
you build your use case and your deployment plan.
|
||||
|
||||
.. tip::
|
||||
|
||||
For further research about OpenStack deployment, investigate the
|
||||
supported and documented preconfigured, prepackaged installers for
|
||||
OpenStack from companies such as
|
||||
`Canonical <http://www.ubuntu.com/cloud/openstack>`_,
|
||||
`Cisco <http://www.cisco.com/web/solutions/openstack/index.html>`_,
|
||||
`Cloudscaling <http://www.cloudscaling.com/>`_,
|
||||
`IBM <http://www-03.ibm.com/software/products/en/ibm-cloud-orchestrator>`_,
|
||||
`Metacloud <http://www.metacloud.com/>`_,
|
||||
`Mirantis <https://www.mirantis.com/>`_,
|
||||
`Rackspace <http://www.rackspace.com/cloud/private>`_,
|
||||
`Red Hat <http://www.redhat.com/openstack/>`_,
|
||||
`SUSE <https://www.suse.com/products/suse-openstack-cloud/>`_,
|
||||
and `SwiftStack <https://www.swiftstack.com/>`_.
|
||||
|
|
@ -52,6 +52,8 @@ covered include:
|
|||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
overview-planning
|
||||
overview-customer-requirements
|
||||
overview-legal-requirements
|
||||
overview-security-requirements
|
||||
overview-operator-requirements
|
||||
|
|
|
|||
|
|
@ -1,17 +1,6 @@
|
|||
.. _use-cases:
|
||||
|
||||
=========
|
||||
Use Cases
|
||||
Use cases
|
||||
=========
|
||||
|
||||
Development Cloud
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
General Compute Cloud
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Web Scale Cloud
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Public Cloud
|
||||
~~~~~~~~~~~~
|
||||
|
|
|
|||
Loading…
Reference in New Issue