openstack/operations-guide
Code Issues Proposed changes

Retire repository

Browse Source 
Retire repository following the process on retiring an OpenStack
repository:
http://docs.openstack.org/infra/manual/drivers.html#remove-project-content

This removes *all* content and just leaves a single README.rst that
explains how to get it.

Change-Id: I36ca5788dbc3e44b5421b88e64972585f8820947
Depends-On: I9f4e21b44c717d11511fea48db54a52103e294b1
This commit is contained in:
Andreas Jaeger 2016-05-05 20:40:53 +02:00
parent c628640944
commit c8ca0febaa
156 changed files with 10 additions and 98835 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
.gitignore vendored
View File

@ -1,25 +0,0 @@
.DS_Store
*.xpr
# Packages
.venv
*.egg
*.egg-info
# Testenvironment
.tox/
# Build directories
target/
publish-docs/
generated/
build/
/build-*.log.gz
# Transifex Client Setting
.tx
# Editors
*~
.*.swp
.bak

4
.gitreview
View File

@ -1,4 +0,0 @@
[gerrit]
host=review.openstack.org
port=29418
project=openstack/operations-guide.git

58
LICENSE
View File

@ -1,58 +0,0 @@
License
THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED.
BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE TO BE BOUND BY THE TERMS OF THIS LICENSE. TO THE EXTENT THIS LICENSE MAY BE CONSIDERED TO BE A CONTRACT, THE LICENSOR GRANTS YOU THE RIGHTS CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND CONDITIONS.
1. Definitions
"Adaptation" means a work based upon the Work, or upon the Work and other pre-existing works, such as a translation, adaptation, derivative work, arrangement of music or other alterations of a literary or artistic work, or phonogram or performance and includes cinematographic adaptations or any other form in which the Work may be recast, transformed, or adapted including in any form recognizably derived from the original, except that a work that constitutes a Collection will not be considered an Adaptation for the purpose of this License. For the avoidance of doubt, where the Work is a musical work, performance or phonogram, the synchronization of the Work in timed-relation with a moving image ("synching") will be considered an Adaptation for the purpose of this License.
"Collection" means a collection of literary or artistic works, such as encyclopedias and anthologies, or performances, phonograms or broadcasts, or other works or subject matter other than works listed in Section 1(g) below, which, by reason of the selection and arrangement of their contents, constitute intellectual creations, in which the Work is included in its entirety in unmodified form along with one or more other contributions, each constituting separate and independent works in themselves, which together are assembled into a collective whole. A work that constitutes a Collection will not be considered an Adaptation (as defined above) for the purposes of this License.
"Distribute" means to make available to the public the original and copies of the Work or Adaptation, as appropriate, through sale or other transfer of ownership.
"License Elements" means the following high-level license attributes as selected by Licensor and indicated in the title of this License: Attribution, Noncommercial, ShareAlike.
"Licensor" means the individual, individuals, entity or entities that offer(s) the Work under the terms of this License.
"Original Author" means, in the case of a literary or artistic work, the individual, individuals, entity or entities who created the Work or if no individual or entity can be identified, the publisher; and in addition (i) in the case of a performance the actors, singers, musicians, dancers, and other persons who act, sing, deliver, declaim, play in, interpret or otherwise perform literary or artistic works or expressions of folklore; (ii) in the case of a phonogram the producer being the person or legal entity who first fixes the sounds of a performance or other sounds; and, (iii) in the case of broadcasts, the organization that transmits the broadcast.
"Work" means the literary and/or artistic work offered under the terms of this License including without limitation any production in the literary, scientific and artistic domain, whatever may be the mode or form of its expression including digital form, such as a book, pamphlet and other writing; a lecture, address, sermon or other work of the same nature; a dramatic or dramatico-musical work; a choreographic work or entertainment in dumb show; a musical composition with or without words; a cinematographic work to which are assimilated works expressed by a process analogous to cinematography; a work of drawing, painting, architecture, sculpture, engraving or lithography; a photographic work to which are assimilated works expressed by a process analogous to photography; a work of applied art; an illustration, map, plan, sketch or three-dimensional work relative to geography, topography, architecture or science; a performance; a broadcast; a phonogram; a compilation of data to the extent it is protected as a copyrightable work; or a work performed by a variety or circus performer to the extent it is not otherwise considered a literary or artistic work.
"You" means an individual or entity exercising rights under this License who has not previously violated the terms of this License with respect to the Work, or who has received express permission from the Licensor to exercise rights under this License despite a previous violation.
"Publicly Perform" means to perform public recitations of the Work and to communicate to the public those public recitations, by any means or process, including by wire or wireless means or public digital performances; to make available to the public Works in such a way that members of the public may access these Works from a place and at a place individually chosen by them; to perform the Work to the public by any means or process and the communication to the public of the performances of the Work, including by public digital performance; to broadcast and rebroadcast the Work by any means including signs, sounds or images.
"Reproduce" means to make copies of the Work by any means including without limitation by sound or visual recordings and the right of fixation and reproducing fixations of the Work, including storage of a protected performance or phonogram in digital form or other electronic medium.
2. Fair Dealing Rights. Nothing in this License is intended to reduce, limit, or restrict any uses free from copyright or rights arising from limitations or exceptions that are provided for in connection with the copyright protection under copyright law or other applicable laws.
3. License Grant. Subject to the terms and conditions of this License, Licensor hereby grants You a worldwide, royalty-free, non-exclusive, perpetual (for the duration of the applicable copyright) license to exercise the rights in the Work as stated below:
to Reproduce the Work, to incorporate the Work into one or more Collections, and to Reproduce the Work as incorporated in the Collections;
to create and Reproduce Adaptations provided that any such Adaptation, including any translation in any medium, takes reasonable steps to clearly label, demarcate or otherwise identify that changes were made to the original Work. For example, a translation could be marked "The original work was translated from English to Spanish," or a modification could indicate "The original work has been modified.";
to Distribute and Publicly Perform the Work including as incorporated in Collections; and,
to Distribute and Publicly Perform Adaptations.
The above rights may be exercised in all media and formats whether now known or hereafter devised. The above rights include the right to make such modifications as are technically necessary to exercise the rights in other media and formats. Subject to Section 8(f), all rights not expressly granted by Licensor are hereby reserved, including but not limited to the rights described in Section 4(e).
4. Restrictions. The license granted in Section 3 above is expressly made subject to and limited by the following restrictions:
You may Distribute or Publicly Perform the Work only under the terms of this License. You must include a copy of, or the Uniform Resource Identifier (URI) for, this License with every copy of the Work You Distribute or Publicly Perform. You may not offer or impose any terms on the Work that restrict the terms of this License or the ability of the recipient of the Work to exercise the rights granted to that recipient under the terms of the License. You may not sublicense the Work. You must keep intact all notices that refer to this License and to the disclaimer of warranties with every copy of the Work You Distribute or Publicly Perform. When You Distribute or Publicly Perform the Work, You may not impose any effective technological measures on the Work that restrict the ability of a recipient of the Work from You to exercise the rights granted to that recipient under the terms of the License. This Section 4(a) applies to the Work as incorporated in a Collection, but this does not require the Collection apart from the Work itself to be made subject to the terms of this License. If You create a Collection, upon notice from any Licensor You must, to the extent practicable, remove from the Collection any credit as required by Section 4(d), as requested. If You create an Adaptation, upon notice from any Licensor You must, to the extent practicable, remove from the Adaptation any credit as required by Section 4(d), as requested.
You may Distribute or Publicly Perform an Adaptation only under: (i) the terms of this License; (ii) a later version of this License with the same License Elements as this License; (iii) a Creative Commons jurisdiction license (either this or a later license version) that contains the same License Elements as this License (e.g., Attribution-NonCommercial-ShareAlike 3.0 US) ("Applicable License"). You must include a copy of, or the URI, for Applicable License with every copy of each Adaptation You Distribute or Publicly Perform. You may not offer or impose any terms on the Adaptation that restrict the terms of the Applicable License or the ability of the recipient of the Adaptation to exercise the rights granted to that recipient under the terms of the Applicable License. You must keep intact all notices that refer to the Applicable License and to the disclaimer of warranties with every copy of the Work as included in the Adaptation You Distribute or Publicly Perform. When You Distribute or Publicly Perform the Adaptation, You may not impose any effective technological measures on the Adaptation that restrict the ability of a recipient of the Adaptation from You to exercise the rights granted to that recipient under the terms of the Applicable License. This Section 4(b) applies to the Adaptation as incorporated in a Collection, but this does not require the Collection apart from the Adaptation itself to be made subject to the terms of the Applicable License.
You may not exercise any of the rights granted to You in Section 3 above in any manner that is primarily intended for or directed toward commercial advantage or private monetary compensation. The exchange of the Work for other copyrighted works by means of digital file-sharing or otherwise shall not be considered to be intended for or directed toward commercial advantage or private monetary compensation, provided there is no payment of any monetary compensation in con-nection with the exchange of copyrighted works.
If You Distribute, or Publicly Perform the Work or any Adaptations or Collections, You must, unless a request has been made pursuant to Section 4(a), keep intact all copyright notices for the Work and provide, reasonable to the medium or means You are utilizing: (i) the name of the Original Author (or pseudonym, if applicable) if supplied, and/or if the Original Author and/or Licensor designate another party or parties (e.g., a sponsor institute, publishing entity, journal) for attribution ("Attribution Parties") in Licensor's copyright notice, terms of service or by other reasonable means, the name of such party or parties; (ii) the title of the Work if supplied; (iii) to the extent reasonably practicable, the URI, if any, that Licensor specifies to be associated with the Work, unless such URI does not refer to the copyright notice or licensing information for the Work; and, (iv) consistent with Section 3(b), in the case of an Adaptation, a credit identifying the use of the Work in the Adaptation (e.g., "French translation of the Work by Original Author," or "Screenplay based on original Work by Original Author"). The credit required by this Section 4(d) may be implemented in any reasonable manner; provided, however, that in the case of a Adaptation or Collection, at a minimum such credit will appear, if a credit for all contributing authors of the Adaptation or Collection appears, then as part of these credits and in a manner at least as prominent as the credits for the other contributing authors. For the avoidance of doubt, You may only use the credit required by this Section for the purpose of attribution in the manner set out above and, by exercising Your rights under this License, You may not implicitly or explicitly assert or imply any connection with, sponsorship or endorsement by the Original Author, Licensor and/or Attribution Parties, as appropriate, of You or Your use of the Work, without the separate, express prior written permission of the Original Author, Licensor and/or Attribution Parties.
For the avoidance of doubt:
Non-waivable Compulsory License Schemes. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme cannot be waived, the Licensor reserves the exclusive right to collect such royalties for any exercise by You of the rights granted under this License;
Waivable Compulsory License Schemes. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme can be waived, the Licensor reserves the exclusive right to collect such royalties for any exercise by You of the rights granted under this License if Your exercise of such rights is for a purpose or use which is otherwise than noncommercial as permitted under Section 4(c) and otherwise waives the right to collect royalties through any statutory or compulsory licensing scheme; and,
Voluntary License Schemes. The Licensor reserves the right to collect royalties, whether individually or, in the event that the Licensor is a member of a collecting society that administers voluntary licensing schemes, via that society, from any exercise by You of the rights granted under this License that is for a purpose or use which is otherwise than noncommercial as permitted under Section 4(c).
Except as otherwise agreed in writing by the Licensor or as may be otherwise permitted by applicable law, if You Reproduce, Distribute or Publicly Perform the Work either by itself or as part of any Adaptations or Collections, You must not distort, mutilate, modify or take other derogatory action in relation to the Work which would be prejudicial to the Original Author's honor or reputation. Licensor agrees that in those jurisdictions (e.g. Japan), in which any exercise of the right granted in Section 3(b) of this License (the right to make Adaptations) would be deemed to be a distortion, mutilation, modification or other derogatory action prejudicial to the Original Author's honor and reputation, the Licensor will waive or not assert, as appropriate, this Section, to the fullest extent permitted by the applicable national law, to enable You to reasonably exercise Your right under Section 3(b) of this License (right to make Adaptations) but not otherwise.
5. Representations, Warranties and Disclaimer
UNLESS OTHERWISE MUTUALLY AGREED TO BY THE PARTIES IN WRITING AND TO THE FULLEST EXTENT PERMITTED BY APPLICABLE LAW, LICENSOR OFFERS THE WORK AS-IS AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND CONCERNING THE WORK, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, INCLUDING, WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR THE ABSENCE OF LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OF ABSENCE OF ERRORS, WHETHER OR NOT DISCOVERABLE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO THIS EXCLUSION MAY NOT APPLY TO YOU.
6. Limitation on Liability. EXCEPT TO THE EXTENT REQUIRED BY APPLICABLE LAW, IN NO EVENT WILL LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY FOR ANY SPECIAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE OR EXEMPLARY DAMAGES ARISING OUT OF THIS LICENSE OR THE USE OF THE WORK, EVEN IF LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
7. Termination
This License and the rights granted hereunder will terminate automatically upon any breach by You of the terms of this License. Individuals or entities who have received Adaptations or Collections from You under this License, however, will not have their licenses terminated provided such individuals or entities remain in full compliance with those licenses. Sections 1, 2, 5, 6, 7, and 8 will survive any termination of this License.
Subject to the above terms and conditions, the license granted here is perpetual (for the duration of the applicable copyright in the Work). Notwithstanding the above, Licensor reserves the right to release the Work under different license terms or to stop distributing the Work at any time; provided, however that any such election will not serve to withdraw this License (or any other license that has been, or is required to be, granted under the terms of this License), and this License will continue in full force and effect unless terminated as stated above.
8. Miscellaneous
Each time You Distribute or Publicly Perform the Work or a Collection, the Licensor offers to the recipient a license to the Work on the same terms and conditions as the license granted to You under this License.
Each time You Distribute or Publicly Perform an Adaptation, Licensor offers to the recipient a license to the original Work on the same terms and conditions as the license granted to You under this License.
If any provision of this License is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this License, and without further action by the parties to this agreement, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable.
No term or provision of this License shall be deemed waived and no breach consented to unless such waiver or consent shall be in writing and signed by the party to be charged with such waiver or consent.
This License constitutes the entire agreement between the parties with respect to the Work licensed here. There are no understandings, agreements or representations with respect to the Work not specified here. Licensor shall not be bound by any additional provisions that may appear in any communication from You. This License may not be modified without the mutual written agreement of the Licensor and You.
The rights granted under, and the subject matter referenced, in this License were drafted utilizing the terminology of the Berne Convention for the Protection of Literary and Artistic Works (as amended on September 28, 1979), the Rome Convention of 1961, the WIPO Copyright Treaty of 1996, the WIPO Performances and Phonograms Treaty of 1996 and the Universal Copyright Convention (as revised on July 24, 1971). These rights and subject matter take effect in the relevant jurisdiction in which the License terms are sought to be enforced according to the corresponding provisions of the implementation of those treaty provisions in the applicable national law. If the standard suite of rights granted under applicable copyright law includes additional rights not granted under this License, such additional rights are deemed to be included in the License; this License is not intended to restrict the license of any rights under applicable law.

74
README.rst
View File

@ -1,67 +1,13 @@
OpenStack Operations Guide
++++++++++++++++++++++++++
This project is no longer maintained.
This content is read-only now, any changes to operations guide will be done
in the openstack-manuals repository where the guide lives in doc/ops-guide.
The contents of this repository are still available in the Git
source code management system. To see the contents of this
repository before it reached its end of life, please check out the
previous commit with "git checkout HEAD^1".
This repository contains the source files for the OpenStack Operations Guide.
The content has been merged into the openstack-manuals repository at
http://git.openstack.org/cgit/openstack/openstack-manuals/
You can read this guide at `docs.openstack.org/ops <http://docs.openstack.org/ops>`_.
It was originally authored during a book sprint in February 2013. Read more
about Book Sprints at http://www.booksprints.net.
Additionally, a tools directory contains tools for testing this guide.
Prerequisites
=============
`Apache Maven <http://maven.apache.org/>`_ must be installed to build the
documentation.
To install Maven 3 for Ubuntu 12.04 and later,and Debian wheezy and later::
apt-get install maven
On Fedora 20 and later::
yum install maven
Contributing
============
This book is undergoing a custom edit with O'Reilly publishing and we welcome
contributions to make it as accurate as possible. Our target is the Havana release.
The style guide to follow is at `chimera.labs.oreilly.com <http://chimera.labs.oreilly.com/books/1230000000969/index.html>`_.
Our community welcomes all people interested in open source cloud computing,
and encourages you to join the `OpenStack Foundation <http://www.openstack.org/join>`_.
The best way to get involved with the community is to talk with others online
or at a meetup and offer contributions through our processes, the `OpenStack
wiki <http://wiki.openstack.org>`_, blogs, or on IRC at ``#openstack``
on ``irc.freenode.net``.
Testing of changes and building of the manual
=============================================
Install the python tox package and run "tox" from the top-level
directory to use the same tests that are done as part of our Jenkins
gating jobs.
If you like to run individual tests, run:
* ``tox -e checkniceness`` - to run the niceness tests
* ``tox -e checksyntax`` - to run syntax checks
* ``tox -e checkdeletions`` - to check that no deleted files are referenced
* ``tox -e checkbuild`` - to actually build the manual
* ``tox -e buildlang -- $LANG`` - to build the manual for language $LANG
tox will use the openstack-doc-tools package for execution of these
tests.
Installing OpenStack
====================
Refer to http://docs.openstack.org to see where these documents are published
and to learn more about the OpenStack project.
For any further questions, please email
openstack-docs@lists.openstack.org or join #openstack-doc on
Freenode.

4
doc-test.conf
View File

@ -1,4 +0,0 @@
[DEFAULT]
repo_name = operations-guide
#file_exception = st-training-guides.xml

26
doc-tools-check-languages.conf
View File

@ -1,26 +0,0 @@
# Example configuration for the languages 'ja' and 'fr'.
# Directories to set up
declare -A DIRECTORIES=(
["ja"]="openstack-ops glossary"
)
# Books to build
declare -A BOOKS=(
["ja"]="openstack-ops"
)
# Where does the top-level pom live?
# Set to empty to not copy it.
POM_FILE=""
# Location of doc dir
DOC_DIR="doc/"
# Books with special handling
# Values need to match content in project-config/jenkins/scripts/common_translation_update.sh
declare -A SPECIAL_BOOKS=(
["ops-guide"]="skip"
# These are translated in openstack-manuals
["common"]="skip"
)

7
doc/common/README.txt
View File

@ -1,7 +0,0 @@
Important note about this directory
===================================
Because this directory is synced from openstack-manuals, make any changes in
openstack-manuals/doc/common. After changes to the synced files merge to
openstack-manuals/doc/common, a patch is automatically proposed for this
directory.

256
doc/common/app_support.rst
View File

@ -1,256 +0,0 @@
.. ## WARNING ##########################################################
.. This file is synced from openstack/openstack-manuals repository to
.. other related repositories. If you need to make changes to this file,
.. make the changes in openstack-manuals. After any change merged to,
.. openstack-manuals, automatically a patch for others will be proposed.
.. #####################################################################
=================
Community support
=================
The following resources are available to help you run and use OpenStack.
The OpenStack community constantly improves and adds to the main
features of OpenStack, but if you have any questions, do not hesitate to
ask. Use the following resources to get OpenStack support, and
troubleshoot your installations.
Documentation
~~~~~~~~~~~~~
For the available OpenStack documentation, see
`docs.openstack.org <http://docs.openstack.org>`__.
To provide feedback on documentation, join and use the
openstack-docs@lists.openstack.org mailing list at `OpenStack
Documentation Mailing
List <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs>`__,
or `report a
bug <https://bugs.launchpad.net/openstack-manuals/+filebug>`__.
The following books explain how to install an OpenStack cloud and its
associated components:
* `Installation Guide for openSUSE Leap 42.1 and SUSE Linux Enterprise
Server 12 SP1
<http://docs.openstack.org/mitaka/install-guide-obs/>`__
* `Installation Guide for Red Hat Enterprise Linux 7 and CentOS 7
<http://docs.openstack.org/mitaka/install-guide-rdo/>`__
* `Installation Guide for Ubuntu 14.04 (LTS)
<http://docs.openstack.org/mitaka/install-guide-ubuntu/>`__
The following books explain how to configure and run an OpenStack cloud:
* `Architecture Design Guide <http://docs.openstack.org/arch-design/>`__
* `Administrator Guide <http://docs.openstack.org/admin-guide/>`__
* `Configuration Reference <http://docs.openstack.org/mitaka/config-reference/>`__
* `Operations Guide <http://docs.openstack.org/ops/>`__
* `Networking Guide <http://docs.openstack.org/mitaka/networking-guide>`__
* `High Availability Guide <http://docs.openstack.org/ha-guide/>`__
* `Security Guide <http://docs.openstack.org/sec/>`__
* `Virtual Machine Image Guide <http://docs.openstack.org/image-guide/>`__
The following books explain how to use the OpenStack dashboard and
command-line clients:
* `API Guide <http://developer.openstack.org/api-guide/quick-start/>`__
* `End User Guide <http://docs.openstack.org/user-guide/>`__
* `Command-Line Interface Reference
<http://docs.openstack.org/cli-reference/>`__
The following documentation provides reference and guidance information
for the OpenStack APIs:
* `API Complete Reference
(HTML) <http://developer.openstack.org/api-ref.html>`__
* `API Complete Reference
(PDF) <http://developer.openstack.org/api-ref-guides/bk-api-ref.pdf>`__
The following guide provides how to contribute to OpenStack documentation:
* `Documentation Contributor Guide <http://docs.openstack.org/contributor-guide/>`__
ask.openstack.org
~~~~~~~~~~~~~~~~~
During the set up or testing of OpenStack, you might have questions
about how a specific task is completed or be in a situation where a
feature does not work correctly. Use the
`ask.openstack.org <https://ask.openstack.org>`__ site to ask questions
and get answers. When you visit the https://ask.openstack.org site, scan
the recently asked questions to see whether your question has already
been answered. If not, ask a new question. Be sure to give a clear,
concise summary in the title and provide as much detail as possible in
the description. Paste in your command output or stack traces, links to
screen shots, and any other information which might be useful.
OpenStack mailing lists
~~~~~~~~~~~~~~~~~~~~~~~
A great way to get answers and insights is to post your question or
problematic scenario to the OpenStack mailing list. You can learn from
and help others who might have similar issues. To subscribe or view the
archives, go to
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack. If you are
interested in the other mailing lists for specific projects or development,
refer to `Mailing Lists <https://wiki.openstack.org/wiki/Mailing_Lists>`__.
The OpenStack wiki
~~~~~~~~~~~~~~~~~~
The `OpenStack wiki <https://wiki.openstack.org/>`__ contains a broad
range of topics but some of the information can be difficult to find or
is a few pages deep. Fortunately, the wiki search feature enables you to
search by title or content. If you search for specific information, such
as about networking or OpenStack Compute, you can find a large amount
of relevant material. More is being added all the time, so be sure to
check back often. You can find the search box in the upper-right corner
of any OpenStack wiki page.
The Launchpad Bugs area
~~~~~~~~~~~~~~~~~~~~~~~
The OpenStack community values your set up and testing efforts and wants
your feedback. To log a bug, you must sign up for a Launchpad account at
https://launchpad.net/+login. You can view existing bugs and report bugs
in the Launchpad Bugs area. Use the search feature to determine whether
the bug has already been reported or already been fixed. If it still
seems like your bug is unreported, fill out a bug report.
Some tips:
* Give a clear, concise summary.
* Provide as much detail as possible in the description. Paste in your
command output or stack traces, links to screen shots, and any other
information which might be useful.
* Be sure to include the software and package versions that you are
using, especially if you are using a development branch, such as,
``"Kilo release" vs git commit bc79c3ecc55929bac585d04a03475b72e06a3208``.
* Any deployment-specific information is helpful, such as whether you
are using Ubuntu 14.04 or are performing a multi-node installation.
The following Launchpad Bugs areas are available:
* `Bugs: OpenStack Block Storage
(cinder) <https://bugs.launchpad.net/cinder>`__
* `Bugs: OpenStack Compute (nova) <https://bugs.launchpad.net/nova>`__
* `Bugs: OpenStack Dashboard
(horizon) <https://bugs.launchpad.net/horizon>`__
* `Bugs: OpenStack Identity
(keystone) <https://bugs.launchpad.net/keystone>`__
* `Bugs: OpenStack Image service
(glance) <https://bugs.launchpad.net/glance>`__
* `Bugs: OpenStack Networking
(neutron) <https://bugs.launchpad.net/neutron>`__
* `Bugs: OpenStack Object Storage
(swift) <https://bugs.launchpad.net/swift>`__
* `Bugs: Application catalog (murano) <https://bugs.launchpad.net/murano>`__
* `Bugs: Bare metal service (ironic) <https://bugs.launchpad.net/ironic>`__
* `Bugs: Clustering service (senlin) <https://bugs.launchpad.net/senlin>`__
* `Bugs: Containers service (magnum) <https://bugs.launchpad.net/magnum>`__
* `Bugs: Data processing service
(sahara) <https://bugs.launchpad.net/sahara>`__
* `Bugs: Database service (trove) <https://bugs.launchpad.net/trove>`__
* `Bugs: Deployment service (fuel) <https://bugs.launchpad.net/fuel>`__
* `Bugs: DNS service (designate) <https://bugs.launchpad.net/designate>`__
* `Bugs: Key Manager Service (barbican) <https://bugs.launchpad.net/barbican>`__
* `Bugs: Monitoring (monasca) <https://bugs.launchpad.net/monasca>`__
* `Bugs: Orchestration (heat) <https://bugs.launchpad.net/heat>`__
* `Bugs: Rating (cloudkitty) <https://bugs.launchpad.net/cloudkitty>`__
* `Bugs: Shared file systems (manila) <https://bugs.launchpad.net/manila>`__
* `Bugs: Telemetry
(ceilometer) <https://bugs.launchpad.net/ceilometer>`__
* `Bugs: Telemetry v3
(gnocchi) <https://bugs.launchpad.net/gnocchi>`__
* `Bugs: Workflow service
(mistral) <https://bugs.launchpad.net/mistral>`__
* `Bugs: Messaging service
(zaqar) <https://bugs.launchpad.net/zaqar>`__
* `Bugs: OpenStack API Documentation
(developer.openstack.org) <https://bugs.launchpad.net/openstack-api-site>`__
* `Bugs: OpenStack Documentation
(docs.openstack.org) <https://bugs.launchpad.net/openstack-manuals>`__
The OpenStack IRC channel
~~~~~~~~~~~~~~~~~~~~~~~~~
The OpenStack community lives in the #openstack IRC channel on the
Freenode network. You can hang out, ask questions, or get immediate
feedback for urgent and pressing issues. To install an IRC client or use
a browser-based client, go to
`https://webchat.freenode.net/ <https://webchat.freenode.net>`__. You can
also use Colloquy (Mac OS X, http://colloquy.info/), mIRC (Windows,
http://www.mirc.com/), or XChat (Linux). When you are in the IRC channel
and want to share code or command output, the generally accepted method
is to use a Paste Bin. The OpenStack project has one at
http://paste.openstack.org. Just paste your longer amounts of text or
logs in the web form and you get a URL that you can paste into the
channel. The OpenStack IRC channel is ``#openstack`` on
``irc.freenode.net``. You can find a list of all OpenStack IRC channels
at https://wiki.openstack.org/wiki/IRC.
Documentation feedback
~~~~~~~~~~~~~~~~~~~~~~
To provide feedback on documentation, join and use the
openstack-docs@lists.openstack.org mailing list at `OpenStack
Documentation Mailing
List <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs>`__,
or `report a
bug <https://bugs.launchpad.net/openstack-manuals/+filebug>`__.
OpenStack distribution packages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following Linux distributions provide community-supported packages
for OpenStack:
* **Debian:** https://wiki.debian.org/OpenStack
* **CentOS, Fedora, and Red Hat Enterprise Linux:**
https://www.rdoproject.org/
* **openSUSE and SUSE Linux Enterprise Server:**
https://en.opensuse.org/Portal:OpenStack
* **Ubuntu:** https://wiki.ubuntu.com/ServerTeam/CloudArchive

47
doc/common/conventions.rst
View File

@ -1,47 +0,0 @@
.. ## WARNING ##########################################################
.. This file is synced from openstack/openstack-manuals repository to
.. other related repositories. If you need to make changes to this file,
.. make the changes in openstack-manuals. After any change merged to,
.. openstack-manuals, automatically a patch for others will be proposed.
.. #####################################################################
===========
Conventions
===========
The OpenStack documentation uses several typesetting conventions.
Notices
~~~~~~~
Notices take these forms:
.. note:: A comment with additional information that explains a part of the
text.
.. important:: Something you must be aware of before proceeding.
.. tip:: An extra but helpful piece of practical advice.
.. caution:: Helpful information that prevents the user from making mistakes.
.. warning:: Critical information about the risk of data loss or security
issues.
Command prompts
~~~~~~~~~~~~~~~
.. code-block:: console
$ command
Any user, including the ``root`` user, can run commands that are
prefixed with the ``$`` prompt.
.. code-block:: console
# command
The ``root`` user must run commands that are prefixed with the ``#``
prompt. You can also prefix these commands with the :command:`sudo`
command, if available, to run them.

3950
doc/common/glossary.rst
View File

File diff suppressed because it is too large Load Diff

BIN
doc/figures/Check_mark_23x20_02.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 3.0 KiB

60
doc/figures/Check_mark_23x20_02.svg
View File

@ -1,60 +0,0 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://web.resource.org/cc/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
width="19.21315"
height="18.294994"
id="svg2"
sodipodi:version="0.32"
inkscape:version="0.45"
sodipodi:modified="true"
version="1.0">
<defs
id="defs4" />
<sodipodi:namedview
id="base"
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1.0"
gridtolerance="10000"
guidetolerance="10"
objecttolerance="10"
inkscape:pageopacity="0.0"
inkscape:pageshadow="2"
inkscape:zoom="7.9195959"
inkscape:cx="17.757032"
inkscape:cy="7.298821"
inkscape:document-units="px"
inkscape:current-layer="layer1"
inkscape:window-width="984"
inkscape:window-height="852"
inkscape:window-x="148"
inkscape:window-y="66" />
<metadata
id="metadata7">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
</cc:Work>
</rdf:RDF>
</metadata>
<g
inkscape:label="Layer 1"
inkscape:groupmode="layer"
id="layer1"
transform="translate(-192.905,-516.02064)">
<path
style="fill:#000000"
d="M 197.67968,534.31563 C 197.40468,534.31208 196.21788,532.53719 195.04234,530.37143 L 192.905,526.43368 L 193.45901,525.87968 C 193.76371,525.57497 194.58269,525.32567 195.27896,525.32567 L 196.5449,525.32567 L 197.18129,527.33076 L 197.81768,529.33584 L 202.88215,523.79451 C 205.66761,520.74678 208.88522,517.75085 210.03239,517.13691 L 212.11815,516.02064 L 207.90871,520.80282 C 205.59351,523.43302 202.45735,527.55085 200.93947,529.95355 C 199.42159,532.35625 197.95468,534.31919 197.67968,534.31563 z "
id="path2223" />
</g>
</svg>
Side by Side

Before

Width:  |  Height:  |  Size: 2.1 KiB

3
doc/figures/network_packet_ping.svg
View File

File diff suppressed because one or more lines are too long
Side by Side

Before

Width:  |  Height:  |  Size: 8.9 KiB

1734
doc/figures/neutron_packet_ping.svg
View File

File diff suppressed because it is too large Load Diff
Side by Side

Before

Width:  |  Height:  |  Size: 69 KiB

3
doc/figures/os-ref-arch.svg
View File

File diff suppressed because one or more lines are too long
Side by Side

Before

Width:  |  Height:  |  Size: 20 KiB

3
doc/figures/os_physical_network.svg
View File

File diff suppressed because one or more lines are too long
Side by Side

Before

Width:  |  Height:  |  Size: 11 KiB

BIN
doc/figures/osog_0001.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 765 KiB

BIN
doc/figures/osog_00in01.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 518 KiB

BIN
doc/figures/osog_0101.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 39 KiB

BIN
doc/figures/osog_0102.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 41 KiB

BIN
doc/figures/osog_0103.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 196 KiB

BIN
doc/figures/osog_0104.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 59 KiB

BIN
doc/figures/osog_0105.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 99 KiB

BIN
doc/figures/osog_0106.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 89 KiB

BIN
doc/figures/osog_01in01.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 95 KiB

BIN
doc/figures/osog_01in02.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 105 KiB

BIN
doc/figures/osog_0201.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 42 KiB

BIN
doc/figures/osog_0901.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 31 KiB

BIN
doc/figures/osog_0902.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 51 KiB

BIN
doc/figures/osog_1201.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 44 KiB

BIN
doc/figures/osog_1202.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 182 KiB

BIN
doc/figures/osog_ac01.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 72 KiB

BIN
doc/figures/releasecyclegrizzlydiagram.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 59 KiB

7
doc/glossary/README.rst
View File

@ -1,7 +0,0 @@
Important note about glossary
=============================
This directory is synced from openstack-manuals. If you need to make
changes, make the changes in openstack-manuals/doc/glossary. After any
change merged to openstack-manuals/doc/glossary, automatically a patch
for this directory will be proposed.

9698
doc/glossary/glossary-terms.xml
View File

File diff suppressed because it is too large Load Diff

6192
doc/glossary/locale/glossary.pot
View File

File diff suppressed because it is too large Load Diff

7607
doc/glossary/locale/ja.po
View File

File diff suppressed because it is too large Load Diff

1156
doc/glossary/locale/zh_CN.po
View File

File diff suppressed because it is too large Load Diff

79
doc/openstack-ops/acknowledgements.xml
View File

@ -1,79 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE acknowledgements [
<!-- Some useful entities borrowed from HTML -->
<!ENTITY ndash "&#x2013;">
<!ENTITY mdash "&#x2014;">
<!ENTITY hellip "&#x2026;">
<!ENTITY plusmn "&#xB1;">
<!-- Useful for describing APIs -->
<!ENTITY GET '<command xmlns="http://docbook.org/ns/docbook">GET</command>'>
<!ENTITY PUT '<command xmlns="http://docbook.org/ns/docbook">PUT</command>'>
<!ENTITY POST '<command xmlns="http://docbook.org/ns/docbook">POST</command>'>
<!ENTITY DELETE '<command xmlns="http://docbook.org/ns/docbook">DELETE</command>'>
]>
<acknowledgements xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="acknowledgments">
<title>Acknowledgments</title>
<para>The OpenStack Foundation supported the creation of this book with
plane tickets to Austin, lodging (including one adventurous evening
without power after a windstorm), and delicious food. For about USD
$10,000, we could collaborate intensively for a week in the same room at
the Rackspace Austin office. The authors are all members of the
OpenStack Foundation, which you can join. Go to the <link
xlink:href="https://www.openstack.org/join">Foundation web
site</link> at <uri>http://openstack.org/join</uri>.</para>
<para>We want to acknowledge our excellent host Rackers at Rackspace in
Austin:</para>
<itemizedlist>
<listitem>
<para>Emma Richards of Rackspace Guest Relations took excellent care
of our lunch orders and even set aside a pile of sticky notes
that had fallen off the walls.</para>
</listitem>
<listitem>
<para>Betsy Hagemeier, a Fanatical Executive Assistant, took care of
a room reshuffle and helped us settle in for the week.</para>
</listitem>
<listitem>
<para>The Real Estate team at Rackspace in Austin, also known as
"The Victors," were super responsive.</para>
</listitem>
<listitem>
<para>Adam Powell in Racker IT supplied us with bandwidth each day
and second monitors for those of us needing more screens.</para>
</listitem>
<listitem>
<para>On Wednesday night we had a fun happy hour with the Austin
OpenStack Meetup group and Racker Katie Schmidt took great care
of our group.</para>
</listitem>
</itemizedlist>
<para>We also had some excellent input from outside of the room:</para>
<itemizedlist>
<listitem>
<para>Tim Bell from CERN gave us feedback on the outline before we
started and reviewed it mid-week.</para>
</listitem>
<listitem>
<para>Sébastien Han has written excellent blogs and generously gave
his permission for re-use.</para>
</listitem>
<listitem>
<para>Oisin Feeley read it, made some edits, and provided emailed
feedback right when we asked.</para>
</listitem>
</itemizedlist>
<para>Inside the book sprint room with us each day was our book
sprint facilitator Adam Hyde. Without his tireless support and
encouragement, we would have thought a book of this scope was
impossible in five days. Adam has proven the book sprint
method effectively again and again. He creates both tools and
faith in collaborative authoring at <link
xlink:href="http://www.booksprints.net/"
>www.booksprints.net</link>.</para>
<para>We couldn't have pulled it off without so much supportive help and
encouragement.</para>
</acknowledgements>

572
doc/openstack-ops/app_crypt.xml
View File

@ -1,572 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE appendix [
<!ENTITY % openstack SYSTEM "openstack.ent">
%openstack;
]>
<appendix xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="app_crypt" label="B">
<title>Tales From the Cryp^H^H^H^H Cloud</title>
<para>Herein lies a selection of tales from OpenStack cloud operators. Read,
and learn from their wisdom.</para>
<section xml:id="double_vlan">
<title>Double VLAN</title>
<para>I was on-site in Kelowna, British Columbia, Canada
setting up a new OpenStack cloud. The deployment was fully
automated: Cobbler deployed the OS on the bare metal,
bootstrapped it, and Puppet took over from there. I had
run the deployment scenario so many times in practice and
took for granted that everything was working.</para>
<para>On my last day in Kelowna, I was in a conference call
from my hotel. In the background, I was fooling around on
the new cloud. I launched an instance and logged in.
Everything looked fine. Out of boredom, I ran
<command>ps aux</command> and
all of the sudden the instance locked up.</para>
<para>Thinking it was just a one-off issue, I terminated the
instance and launched a new one. By then, the conference
call ended and I was off to the data center.</para>
<para>At the data center, I was finishing up some tasks and remembered
the lock-up. I logged into the new instance and ran <command>ps
aux</command> again. It worked. Phew. I decided to run it one
more time. It locked up.</para>
<para>After reproducing the problem several times, I came to
the unfortunate conclusion that this cloud did indeed have
a problem. Even worse, my time was up in Kelowna and I had
to return back to Calgary.</para>
<para>Where do you even begin troubleshooting something like
this? An instance that just randomly locks up when a command is
issued. Is it the image? Nope&mdash;it happens on all images.
Is it the compute node? Nope&mdash;all nodes. Is the instance
locked up? No! New SSH connections work just fine!</para>
<para>We reached out for help. A networking engineer suggested
it was an MTU issue. Great! MTU! Something to go on!
What's MTU and why would it cause a problem?</para>
<para>MTU is maximum transmission unit. It specifies the
maximum number of bytes that the interface accepts for
each packet. If two interfaces have two different MTUs,
bytes might get chopped off and weird things happen&mdash;such
as random session lockups.</para>
<note>
<para>Not all packets have a size of 1500. Running the <command>ls</command>
command over SSH might only create a single packets
less than 1500 bytes. However, running a command with
heavy output, such as <command>ps aux</command>
requires several packets of 1500 bytes.</para>
</note>
<para>OK, so where is the MTU issue coming from? Why haven't
we seen this in any other deployment? What's new in this
situation? Well, new data center, new uplink, new
switches, new model of switches, new servers, first time
using this model of servers… so, basically everything was
new. Wonderful. We toyed around with raising the MTU at
various areas: the switches, the NICs on the compute
nodes, the virtual NICs in the instances, we even had the
data center raise the MTU for our uplink interface. Some
changes worked, some didn't. This line of troubleshooting
didn't feel right, though. We shouldn't have to be
changing the MTU in these areas.</para>
<para>As a last resort, our network admin (Alvaro) and myself
sat down with four terminal windows, a pencil, and a piece
of paper. In one window, we ran ping. In the second
window, we ran <command>tcpdump</command> on the cloud
controller. In the third, <command>tcpdump</command> on
the compute node. And the forth had <command>tcpdump</command>
on the instance. For background, this cloud was a
multi-node, non-multi-host setup.</para>
<para>One cloud controller acted as a gateway to all compute
nodes. VlanManager was used for the network config. This
means that the cloud controller and all compute nodes had
a different VLAN for each OpenStack project. We used the
-s option of <command>ping</command> to change the packet size.
We watched as sometimes packets would fully return,
sometimes they'd only make it out and never back in, and
sometimes the packets would stop at a random point. We
changed <command>tcpdump</command> to start displaying the
hex dump of the packet. We pinged between every
combination of outside, controller, compute, and
instance.</para>
<para>Finally, Alvaro noticed something. When a packet from
the outside hits the cloud controller, it should not be
configured with a VLAN. We verified this as true. When the
packet went from the cloud controller to the compute node,
it should only have a VLAN if it was destined for an
instance. This was still true. When the ping reply was
sent from the instance, it should be in a VLAN. True. When
it came back to the cloud controller and on its way out to
the Internet, it should no longer have a VLAN.
False. Uh oh. It looked as though the VLAN part of the
packet was not being removed.</para>
<para>That made no sense.</para>
<para>While bouncing this idea around in our heads, I was
randomly typing commands on the compute node:
<screen><userinput><prompt>$</prompt> ip a</userinput>
<computeroutput>&hellip;
10: vlan100@vlan20: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 1500 qdisc noqueue master br100 state UP
&hellip;</computeroutput></screen>
</para>
<para>"Hey Alvaro, can you run a VLAN on top of a
VLAN?"</para>
<para>"If you did, you'd add an extra 4 bytes to the
packet&hellip;"</para>
<para>Then it all made sense…
<screen><userinput><prompt>$</prompt> grep vlan_interface /etc/nova/nova.conf</userinput>
<computeroutput>vlan_interface=vlan20</computeroutput></screen>
</para>
<para>In <filename>nova.conf</filename>, <code>vlan_interface</code>
specifies what interface OpenStack should attach all VLANs
to. The correct setting should have been:
<programlisting>vlan_interface=bond0</programlisting></para>
<para>As this would be the server's bonded NIC.</para>
<para>vlan20 is the VLAN that the data center gave us for
outgoing Internet access. It's a correct VLAN and
is also attached to bond0.</para>
<para>By mistake, I configured OpenStack to attach all tenant
VLANs to vlan20 instead of bond0 thereby stacking one VLAN
on top of another. This added an extra 4 bytes to
each packet and caused a packet of 1504 bytes to be sent
out which would cause problems when it arrived at an
interface that only accepted 1500.</para>
<para>As soon as this setting was fixed, everything
worked.</para>
</section>
<section xml:id="issue">
<title>"The Issue"</title>
<para>At the end of August 2012, a post-secondary school in
Alberta, Canada migrated its infrastructure to an
OpenStack cloud. As luck would have it, within the first
day or two of it running, one of their servers just
disappeared from the network. Blip. Gone.</para>
<para>After restarting the instance, everything was back up
and running. We reviewed the logs and saw that at some
point, network communication stopped and then everything
went idle. We chalked this up to a random
occurrence.</para>
<para>A few nights later, it happened again.</para>
<para>We reviewed both sets of logs. The one thing that stood
out the most was DHCP. At the time, OpenStack, by default,
set DHCP leases for one minute (it's now two minutes).
This means that every instance
contacts the cloud controller (DHCP server) to renew its
fixed IP. For some reason, this instance could not renew
its IP. We correlated the instance's logs with the logs on
the cloud controller and put together a
conversation:</para>
<orderedlist>
<listitem>
<para>Instance tries to renew IP.</para>
</listitem>
<listitem>
<para>Cloud controller receives the renewal request
and sends a response.</para>
</listitem>
<listitem>
<para>Instance "ignores" the response and re-sends the
renewal request.</para>
</listitem>
<listitem>
<para>Cloud controller receives the second request and
sends a new response.</para>
</listitem>
<listitem>
<para>Instance begins sending a renewal request to
<code>255.255.255.255</code> since it hasn't
heard back from the cloud controller.</para>
</listitem>
<listitem>
<para>The cloud controller receives the
<code>255.255.255.255</code> request and sends
a third response.</para>
</listitem>
<listitem>
<para>The instance finally gives up.</para>
</listitem>
</orderedlist>
<para>With this information in hand, we were sure that the
problem had to do with DHCP. We thought that for some
reason, the instance wasn't getting a new IP address and
with no IP, it shut itself off from the network.</para>
<para>A quick Google search turned up this: <link
xlink:href="https://lists.launchpad.net/openstack/msg11696.html"
>DHCP lease errors in VLAN mode</link>
(https://lists.launchpad.net/openstack/msg11696.html)
which further supported our DHCP theory.</para>
<para>An initial idea was to just increase the lease time. If
the instance only renewed once every week, the chances of
this problem happening would be tremendously smaller than
every minute. This didn't solve the problem, though. It
was just covering the problem up.</para>
<para>We decided to have <command>tcpdump</command> run on this
instance and see if we could catch it in action again.
Sure enough, we did.</para>
<para>The <command>tcpdump</command> looked very, very weird. In
short, it looked as though network communication stopped
before the instance tried to renew its IP. Since there is
so much DHCP chatter from a one minute lease, it's very
hard to confirm it, but even with only milliseconds
difference between packets, if one packet arrives first,
it arrived first, and if that packet reported network
issues, then it had to have happened before DHCP.</para>
<para>Additionally, this instance in question was responsible
for a very, very large backup job each night. While "The
Issue" (as we were now calling it) didn't happen exactly
when the backup happened, it was close enough (a few
hours) that we couldn't ignore it.</para>
<para>Further days go by and we catch The Issue in action more
and more. We find that dhclient is not running after The
Issue happens. Now we're back to thinking it's a DHCP
issue. Running <filename>/etc/init.d/networking</filename> restart
brings everything back up and running.</para>
<para>Ever have one of those days where all of the sudden you
get the Google results you were looking for? Well, that's
what happened here. I was looking for information on
dhclient and why it dies when it can't renew its lease and
all of the sudden I found a bunch of OpenStack and dnsmasq
discussions that were identical to the problem we were
seeing!</para>
<para>
<link
xlink:href="http://www.gossamer-threads.com/lists/openstack/operators/18197"
>Problem with Heavy Network IO and Dnsmasq</link>
(http://www.gossamer-threads.com/lists/openstack/operators/18197)
</para>
<para>
<link
xlink:href="http://www.gossamer-threads.com/lists/openstack/dev/14696"
>instances losing IP address while running, due to No
DHCPOFFER</link>
(http://www.gossamer-threads.com/lists/openstack/dev/14696)</para>
<para>Seriously, Google.</para>
<para>This bug report was the key to everything:
<link
xlink:href="https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/997978"
> KVM images lose connectivity with bridged
network</link>
(https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/997978)</para>
<para>It was funny to read the report. It was full of people
who had some strange network problem but didn't quite
explain it in the same way.</para>
<para>So it was a qemu/kvm bug.</para>
<para>At the same time of finding the bug report, a co-worker
was able to successfully reproduce The Issue! How? He used
<command>iperf</command> to spew a ton of bandwidth at an instance. Within 30
minutes, the instance just disappeared from the
network.</para>
<para>Armed with a patched qemu and a way to reproduce, we set
out to see if we've finally solved The Issue. After 48
hours straight of hammering the instance with bandwidth,
we were confident. The rest is history. You can search the
bug report for "joe" to find my comments and actual
tests.</para>
</section>
<section xml:id="disappear_images">
<title>Disappearing Images</title>
<para>At the end of 2012, Cybera (a nonprofit with a mandate
to oversee the development of cyberinfrastructure in
Alberta, Canada) deployed an updated OpenStack cloud for
their <link xlink:title="DAIR project"
xlink:href="http://www.canarie.ca/cloud/"
>DAIR project</link>
(http://www.canarie.ca/en/dair-program/about). A few days
into production, a compute node locks up. Upon rebooting
the node, I checked to see what instances were hosted on
that node so I could boot them on behalf of the customer.
Luckily, only one instance.</para>
<para>The <command>nova reboot</command> command wasn't working, so
I used <command>virsh</command>, but it immediately came back
with an error saying it was unable to find the backing
disk. In this case, the backing disk is the Glance image
that is copied to
<filename>/var/lib/nova/instances/_base</filename> when the
image is used for the first time. Why couldn't it find it?
I checked the directory and sure enough it was
gone.</para>
<para>I reviewed the <code>nova</code> database and saw the
instance's entry in the <code>nova.instances</code> table.
The image that the instance was using matched what virsh
was reporting, so no inconsistency there.</para>
<para>I checked Glance and noticed that this image was a
snapshot that the user created. At least that was good
news&mdash;this user would have been the only user
affected.</para>
<para>Finally, I checked StackTach and reviewed the user's events. They
had created and deleted several snapshots&mdash;most likely
experimenting. Although the timestamps didn't match up, my
conclusion was that they launched their instance and then deleted
the snapshot and it was somehow removed from
<filename>/var/lib/nova/instances/_base</filename>. None of that
made sense, but it was the best I could come up with.</para>
<para>It turns out the reason that this compute node locked up
was a hardware issue. We removed it from the DAIR cloud
and called Dell to have it serviced. Dell arrived and
began working. Somehow or another (or a fat finger), a
different compute node was bumped and rebooted.
Great.</para>
<para>When this node fully booted, I ran through the same
scenario of seeing what instances were running so I could
turn them back on. There were a total of four. Three
booted and one gave an error. It was the same error as
before: unable to find the backing disk. Seriously,
what?</para>
<para>Again, it turns out that the image was a snapshot. The
three other instances that successfully started were
standard cloud images. Was it a problem with snapshots?
That didn't make sense.</para>
<para>A note about DAIR's architecture:
<filename>/var/lib/nova/instances</filename> is a shared NFS
mount. This means that all compute nodes have access to
it, which includes the <code>_base</code> directory.
Another centralized area is <filename>/var/log/rsyslog</filename>
on the cloud controller. This directory collects all
OpenStack logs from all compute nodes. I wondered if there
were any entries for the file that <command>virsh</command> is
reporting:
<screen><computeroutput>dair-ua-c03/nova.log:Dec 19 12:10:59 dair-ua-c03
2012-12-19 12:10:59 INFO nova.virt.libvirt.imagecache
[-] Removing base file:
/var/lib/nova/instances/_base/7b4783508212f5d242cbf9ff56fb8d33b4ce6166_10</computeroutput>
</screen>
</para>
<para>Ah-hah! So OpenStack was deleting it. But why?</para>
<para>A feature was introduced in Essex to periodically check
and see if there were any <code>_base</code> files not in use.
If there
were, OpenStack Compute would delete them. This idea sounds innocent
enough and has some good qualities to it. But how did this
feature end up turned on? It was disabled by default in
Essex. As it should be. It was <link
xlink:href="https://bugs.launchpad.net/nova/+bug/1029674"
>decided to be turned on in Folsom</link>
(https://bugs.launchpad.net/nova/+bug/1029674). I cannot
emphasize enough that:</para>
<para>
<emphasis>Actions which delete things should not be
enabled by default.</emphasis>
</para>
<para>Disk space is cheap these days. Data recovery is
not.</para>
<para>Secondly, DAIR's shared
<filename>/var/lib/nova/instances</filename> directory
contributed to the problem. Since all compute nodes have
access to this directory, all compute nodes periodically
review the _base directory. If there is only one instance
using an image, and the node that the instance is on is
down for a few minutes, it won't be able to mark the image
as still in use. Therefore, the image seems like it's not
in use and is deleted. When the compute node comes back
online, the instance hosted on that node is unable to
start.</para>
</section>
<section xml:id="valentines">
<title>The Valentine's Day Compute Node Massacre</title>
<para>Although the title of this story is much more dramatic
than the actual event, I don't think, or hope, that I'll
have the opportunity to use "Valentine's Day Massacre"
again in a title.</para>
<para>This past Valentine's Day, I received an alert that a
compute node was no longer available in the cloud&mdash;meaning,
<screen><prompt>$</prompt><userinput>nova service-list</userinput></screen>
showed this particular node in down state.</para>
<para>I logged into the cloud controller and was able to both
<command>ping</command> and SSH into the problematic compute node which
seemed very odd. Usually if I receive this type of alert,
the compute node has totally locked up and would be
inaccessible.</para>
<para>After a few minutes of troubleshooting, I saw the
following details:</para>
<itemizedlist>
<listitem>
<para>A user recently tried launching a CentOS
instance on that node</para>
</listitem>
<listitem>
<para>This user was the only user on the node (new
node)</para>
</listitem>
<listitem>
<para>The load shot up to 8 right before I received
the alert</para>
</listitem>
<listitem>
<para>The bonded 10gb network device (bond0) was in a
DOWN state</para>
</listitem>
<listitem>
<para>The 1gb NIC was still alive and active</para>
</listitem>
</itemizedlist>
<para>I looked at the status of both NICs in the bonded pair
and saw that neither was able to communicate with the
switch port. Seeing as how each NIC in the bond is
connected to a separate switch, I thought that the chance
of a switch port dying on each switch at the same time was
quite improbable. I concluded that the 10gb dual port NIC
had died and needed replaced. I created a ticket for the
hardware support department at the data center where the
node was hosted. I felt lucky that this was a new node and
no one else was hosted on it yet.</para>
<para>An hour later I received the same alert, but for another
compute node. Crap. OK, now there's definitely a problem
going on. Just like the original node, I was able to log
in by SSH. The bond0 NIC was DOWN but the 1gb NIC was
active.</para>
<para>And the best part: the same user had just tried creating
a CentOS instance. What?</para>
<para>I was totally confused at this point, so I texted our
network admin to see if he was available to help. He
logged in to both switches and immediately saw the
problem: the switches detected spanning tree packets
coming from the two compute nodes and immediately shut the
ports down to prevent spanning tree loops:
<screen><computeroutput>Feb 15 01:40:18 SW-1 Stp: %SPANTREE-4-BLOCK_BPDUGUARD: Received BPDU packet on Port-Channel35 with BPDU guard enabled. Disabling interface. (source mac fa:16:3e:24:e7:22)
Feb 15 01:40:18 SW-1 Ebra: %ETH-4-ERRDISABLE: bpduguard error detected on Port-Channel35.
Feb 15 01:40:18 SW-1 Mlag: %MLAG-4-INTF_INACTIVE_LOCAL: Local interface Port-Channel35 is link down. MLAG 35 is inactive.
Feb 15 01:40:18 SW-1 Ebra: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-Channel35 (Server35), changed state to down
Feb 15 01:40:19 SW-1 Stp: %SPANTREE-6-INTERFACE_DEL: Interface Port-Channel35 has been removed from instance MST0
Feb 15 01:40:19 SW-1 Ebra: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet35 (Server35), changed state to down</computeroutput></screen>
</para>
<para>He re-enabled the switch ports and the two compute nodes
immediately came back to life.</para>
<para>Unfortunately, this story has an open ending... we're
still looking into why the CentOS image was sending out
spanning tree packets. Further, we're researching a proper
way on how to mitigate this from happening. It's a bigger
issue than one might think. While it's extremely important
for switches to prevent spanning tree loops, it's very
problematic to have an entire compute node be cut from the
network when this happens. If a compute node is hosting
100 instances and one of them sends a spanning tree
packet, that instance has effectively DDOS'd the other 99
instances.</para>
<para>This is an ongoing and hot topic in networking circles
&mdash;especially with the raise of virtualization and virtual
switches.</para>
</section>
<section xml:id="rabbithole">
<title>Down the Rabbit Hole</title>
<para>Users being able to retrieve console logs from running
instances is a boon for support&mdash;many times they can
figure out what's going on inside their instance and fix
what's going on without bothering you. Unfortunately,
sometimes overzealous logging of failures can cause
problems of its own.</para>
<para>A report came in: VMs were launching slowly, or not at
all. Cue the standard checks&mdash;nothing on the Nagios, but
there was a spike in network towards the current master of
our RabbitMQ cluster. Investigation started, but soon the
other parts of the queue cluster were leaking memory like
a sieve. Then the alert came in&mdash;the master Rabbit server
went down and connections failed over to the slave.</para>
<para>At that time, our control services were hosted by
another team and we didn't have much debugging information
to determine what was going on with the master, and we
could not reboot it. That team noted that it failed without
alert, but managed to reboot it. After an hour, the
cluster had returned to its normal state and we went home
for the day.</para>
<para>Continuing the diagnosis the next morning was kick
started by another identical failure. We quickly got the
message queue running again, and tried to work out why
Rabbit was suffering from so much network traffic.
Enabling debug logging on
<systemitem class="service">nova-api</systemitem> quickly brought
understanding. A <command>tail -f
/var/log/nova/nova-api.log</command> was scrolling by
faster than we'd ever seen before. CTRL+C on that and we
could plainly see the contents of a system log spewing
failures over and over again - a system log from one of
our users' instances.</para>
<para>After finding the instance ID we headed over to
<filename>/var/lib/nova/instances</filename> to find the
<filename>console.log</filename>:
<screen><computeroutput>
adm@cc12:/var/lib/nova/instances/instance-00000e05# wc -l console.log
92890453 console.log
adm@cc12:/var/lib/nova/instances/instance-00000e05# ls -sh console.log
5.5G console.log</computeroutput></screen></para>
<para>Sure enough, the user had been periodically refreshing
the console log page on the dashboard and the 5G file was
traversing the Rabbit cluster to get to the
dashboard.</para>
<para>We called them and asked them to stop for a while, and
they were happy to abandon the horribly broken VM. After
that, we started monitoring the size of console
logs.</para>
<para>To this day, <link
xlink:href="https://bugs.launchpad.net/nova/+bug/832507"
>the issue</link>
(https://bugs.launchpad.net/nova/+bug/832507) doesn't have
a permanent resolution, but we look forward to the
discussion at the next summit.</para>
</section>
<section xml:id="haunted">
<title>Havana Haunted by the Dead</title>
<para>Felix Lee of Academia Sinica Grid Computing Centre in Taiwan
contributed this story.</para>
<para>I just upgraded OpenStack from Grizzly to Havana 2013.2-2 using
the RDO repository and everything was running pretty
well&mdash;except the EC2 API.</para>
<para>I noticed that the API would suffer from a heavy load and
respond slowly to particular EC2 requests such as
<literal>RunInstances</literal>.</para>
<para>Output from <filename>/var/log/nova/nova-api.log</filename> on
Havana:</para>
<screen><computeroutput>2014-01-10 09:11:45.072 129745 INFO nova.ec2.wsgi.server
[req-84d16d16-3808-426b-b7af-3b90a11b83b0
0c6e7dba03c24c6a9bce299747499e8a 7052bd6714e7460caeb16242e68124f9]
117.103.103.29 "GET
/services/Cloud?AWSAccessKeyId=[something]&amp;Action=RunInstances&amp;ClientToken=[something]&amp;ImageId=ami-00000001&amp;InstanceInitiatedShutdownBehavior=terminate...
HTTP/1.1" status: 200 len: 1109 time: 138.5970151
</computeroutput></screen>
<para>This request took over two minutes to process, but executed
quickly on another co-existing Grizzly deployment using the same
hardware and system configuration.</para>
<para>Output from <filename>/var/log/nova/nova-api.log</filename> on
Grizzly:</para>
<screen><computeroutput>2014-01-08 11:15:15.704 INFO nova.ec2.wsgi.server
[req-ccac9790-3357-4aa8-84bd-cdaab1aa394e
ebbd729575cb404081a45c9ada0849b7 8175953c209044358ab5e0ec19d52c37]
117.103.103.29 "GET
/services/Cloud?AWSAccessKeyId=[something]&amp;Action=RunInstances&amp;ClientToken=[something]&amp;ImageId=ami-00000007&amp;InstanceInitiatedShutdownBehavior=terminate...
HTTP/1.1" status: 200 len: 931 time: 3.9426181
</computeroutput></screen>
<para>While monitoring system resources, I noticed
a significant increase in memory consumption while the EC2 API
processed this request. I thought it wasn't handling memory
properly&mdash;possibly not releasing memory. If the API received
several of these requests, memory consumption quickly grew until
the system ran out of RAM and began using swap. Each node has
48 GB of RAM and the "nova-api" process would consume all of it
within minutes. Once this happened, the entire system would become
unusably slow until I restarted the
<systemitem class="service">nova-api</systemitem> service.</para>
<para>So, I found myself wondering what changed in the EC2 API on
Havana that might cause this to happen. Was it a bug or a normal
behavior that I now need to work around?</para>
<para>After digging into the nova (OpenStack Compute) code, I noticed two areas in
<filename>api/ec2/cloud.py</filename> potentially impacting my
system:</para>
<programlisting language="python">
instances = self.compute_api.get_all(context,
search_opts=search_opts,
sort_dir='asc')
sys_metas = self.compute_api.get_all_system_metadata(
context, search_filts=[{'key': ['EC2_client_token']},
{'value': [client_token]}])
</programlisting>
<para>Since my database contained many records&mdash;over 1 million
metadata records and over 300,000 instance records in "deleted"
or "errored" states&mdash;each search took a long time. I decided to clean
up the database by first archiving a copy for backup and then
performing some deletions using the MySQL client. For example, I
ran the following SQL command to remove rows of instances deleted
for over a year:</para>
<screen><prompt>mysql></prompt> <userinput>delete from nova.instances where deleted=1 and terminated_at &lt; (NOW() - INTERVAL 1 YEAR);</userinput></screen>
<para>Performance increased greatly after deleting the old records and
my new deployment continues to behave well.</para>
</section>
</appendix>

708
doc/openstack-ops/app_roadmaps.xml
View File

@ -1,708 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<appendix label="C" version="5.0" xml:id="working-with-roadmaps"
xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:ns5="http://www.w3.org/1999/xhtml"
xmlns:ns4="http://www.w3.org/2000/svg"
xmlns:ns3="http://www.w3.org/1998/Math/MathML"
xmlns:ns="http://docbook.org/ns/docbook">
<title>Working with Roadmaps</title>
<para>The good news: OpenStack has unprecedented transparency when it comes
to providing information about what's coming up. The bad news: each release
moves very quickly. The purpose of this appendix is to highlight some of the
useful pages to track, and take an educated guess at what is coming up in
the next release and perhaps further afield.<indexterm class="singular">
<primary>Kilo</primary>
<secondary>upcoming release of</secondary>
</indexterm><indexterm class="singular">
<primary>OpenStack community</primary>
<secondary>working with roadmaps</secondary>
<tertiary>release cycle</tertiary>
</indexterm></para>
<para>OpenStack follows a six month release cycle, typically releasing in
April/May and October/November each year. At the start of each cycle, the
community gathers in a single location for a design summit. At the summit,
the features for the coming releases are discussed, prioritized, and
planned. <xref linkend="release-cycle-diagram" /> shows an example release
cycle, with dates showing milestone releases, code freeze, and string freeze
dates, along with an example of when the summit occurs. Milestones are
interim releases within the cycle that are available as packages for
download and testing. Code freeze is putting a stop to adding new features
to the release. String freeze is putting a stop to changing any strings
within the source code.</para>
<figure xml:id="release-cycle-diagram">
<title>Release cycle diagram</title>
<mediaobject>
<imageobject>
<imagedata width="6in" fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/osog_ac01.png"></imagedata>
</imageobject>
</mediaobject>
</figure>
<section xml:id="roadmap-information-available">
<title>Information Available to You</title>
<para>There are several good sources of information available that you can
use to track your OpenStack development desires.<indexterm
class="singular">
<primary>OpenStack community</primary>
<secondary>working with roadmaps</secondary>
<tertiary>information available</tertiary>
</indexterm></para>
<para>Release notes are maintained on the OpenStack wiki, and also shown
here:</para>
<informaltable cellpadding="2" cellspacing="0" rules="all">
<thead>
<tr>
<th>Series</th>
<th>Status</th>
<th>Releases</th>
<th>Date</th>
</tr>
</thead>
<tbody>
<tr>
<td><para>Liberty</para></td>
<td><para><link
xlink:href="https://wiki.openstack.org/wiki/Liberty_Release_Schedule">Under Development</link> </para>
</td>
<td><para>2015.2</para></td>
<td><para>Oct, 2015</para></td>
</tr>
<tr>
<td><para>Kilo</para></td>
<td><para><link
xlink:href="https://wiki.openstack.org/wiki/Kilo_Release_Schedule">Current stable release, security-supported</link> </para>
</td>
<td><para><link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/Kilo">2015.1</link></para></td>
<td><para>Apr 30, 2015</para></td>
</tr>
<tr>
<td><para>Juno</para></td>
<td><para><link xlink:href="https://wiki.openstack.org/wiki/Juno_Release_Schedule">Security-supported</link> </para>
</td>
<td><para><link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/Juno">2014.2</link></para></td>
<td><para>Oct 16, 2014</para></td>
</tr>
<tr>
<td rowspan="4"><para>Icehouse</para></td>
<td rowspan="4"><para><link xlink:href="https://wiki.openstack.org/wiki/Icehouse_Release_Schedule">End-of-life</link> </para></td>
<td><para><link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse">2014.1</link></para></td>
<td><para>Apr 17, 2014</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2014.1.1">2014.1.1</link> </para></td>
<td><para>Jun 9, 2014</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2014.1.2">2014.1.2</link> </para></td>
<td><para>Aug 8, 2014</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2014.1.3">2014.1.3</link> </para></td>
<td><para>Oct 2, 2014</para></td>
</tr>
<tr>
<td rowspan="6"><para>Havana</para></td>
<td rowspan="6"><para>End-of-life</para></td>
<td><para> <link xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/Havana">2013.2</link>
</para></td>
<td><para>Apr 4, 2013</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2013.2.1">2013.2.1</link> </para></td>
<td><para>Dec 16, 2013</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2013.2.2">2013.2.2</link> </para></td>
<td><para>Feb 13, 2014</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2013.2.3">2013.2.3</link> </para></td>
<td><para>Apr 3, 2014</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2013.2.4">2013.2.4</link> </para></td>
<td><para>Sep 22, 2014</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2013.2.1">2013.2.1</link> </para></td>
<td><para>Dec 16, 2013</para></td>
</tr>
<tr>
<td rowspan="6"><para>Grizzly</para></td>
<td rowspan="6"><para>End-of-life</para></td>
<td><para> <link xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/Grizzly">2013.1</link>
</para></td>
<td><para>Apr 4, 2013</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2013.1.1">2013.1.1</link> </para></td>
<td><para>May 9, 2013</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2013.1.2">2013.1.2</link> </para></td>
<td><para>Jun 6, 2013</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2013.1.3">2013.1.3</link> </para></td>
<td><para>Aug 8, 2013</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2013.1.4">2013.1.4</link> </para></td>
<td><para>Oct 17, 2013</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2013.1.5">2013.1.5</link> </para></td>
<td><para>Mar 20, 2015</para></td>
</tr>
<tr>
<td rowspan="5"><para>Folsom</para></td>
<td rowspan="5"><para>End-of-life</para></td>
<td><para> <link xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/Folsom">2012.2</link>
</para></td>
<td><para>Sep 27, 2012</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2012.2.1">2012.2.1</link> </para></td>
<td><para>Nov 29, 2012</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2012.2.2">2012.2.2</link> </para></td>
<td><para>Dec 13, 2012</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2012.2.3">2012.2.3</link> </para></td>
<td><para>Jan 31, 2013</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2012.2.4">2012.2.4</link> </para></td>
<td><para>Apr 11, 2013</para></td>
</tr>
<tr>
<td rowspan="4"><para>Essex</para></td>
<td rowspan="4"><para>End-of-life</para></td>
<td><para> <link xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/Essex">2012.1</link>
</para></td>
<td><para>Apr 5, 2012</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2012.1.1">2012.1.1</link> </para></td>
<td><para>Jun 22, 2012</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2012.1.2">2012.1.2</link> </para></td>
<td><para>Aug 10, 2012</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2012.1.3">2012.1.3</link> </para></td>
<td><para>Oct 12, 2012</para></td>
</tr>
<tr>
<td rowspan="2"><para>Diablo</para></td>
<td rowspan="2"><para>Deprecated</para></td>
<td><para> <link xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/Diablo">2011.3</link>
</para></td>
<td><para>Sep 22, 2011</para></td>
</tr>
<tr>
<td><para> <link
xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/2011.3.1">2011.3.1</link> </para></td>
<td><para>Jan 19, 2012</para></td>
</tr>
<tr>
<td><para>Cactus</para></td>
<td><para>Deprecated</para></td>
<td><para> <link xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/Cactus">2011.2</link>
</para></td>
<td><para>Apr 15, 2011</para></td>
</tr>
<tr>
<td><para>Bexar</para></td>
<td><para>Deprecated</para></td>
<td><para> <link xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/Bexar">2011.1</link>
</para></td>
<td><para>Feb 3, 2011</para></td>
</tr>
<tr>
<td><para>Austin</para></td>
<td><para>Deprecated</para></td>
<td><para> <link xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/Austin">2010.1</link>
</para></td>
<td><para>Oct 21, 2010</para></td>
</tr>
</tbody>
</informaltable>
<para>Here are some other resources:</para>
<itemizedlist>
<listitem>
<para><link xlink:href="http://status.openstack.org/release/">A breakdown of
current features under development, with their target
milestone</link></para>
</listitem>
<listitem>
<para><link xlink:href="https://blueprints.launchpad.net/openstack">A list of all
features, including those not yet under development</link></para>
</listitem>
<listitem>
<para><link xlink:href="https://wiki.openstack.org/wiki/Summit/Kilo/Etherpads">Rough-draft design
discussions ("etherpads") from the last design summit</link></para>
</listitem>
<listitem>
<para><link xlink:href="https://review.openstack.org/">List of individual
code changes under review</link></para>
</listitem>
</itemizedlist>
</section>
<section xml:id="roadmap-influencing">
<title>Influencing the Roadmap</title>
<para>OpenStack truly welcomes your ideas (and contributions) and highly
values feedback from real-world users of the software. By learning a
little about the process that drives feature development, you can
participate and perhaps get the additions you desire.<indexterm
class="singular">
<primary>OpenStack community</primary>
<secondary>working with roadmaps</secondary>
<tertiary>influencing</tertiary>
</indexterm></para>
<para>Feature requests typically start their life in Etherpad, a
collaborative editing tool, which is used to take coordinating notes at a
design summit session specific to the feature. This then leads to the
creation of a blueprint on the Launchpad site for the particular project,
which is used to describe the feature more formally. Blueprints are then
approved by project team members, and development can begin.</para>
<para>Therefore, the fastest way to get your feature request up for
consideration is to create an Etherpad with your ideas and propose a
session to the design summit. If the design summit has already passed, you
may also create a blueprint directly. Read this <link
xlink:href="http://vmartinezdelacruz.com/how-to-work-with-blueprints-without-losing-your-mind/">blog post about how to work with
blueprints</link> the perspective of Victoria Martínez, a developer
intern.</para>
<para>The roadmap for the next release as it is developed can be seen at
<link xlink:href="http://status.openstack.org/release/">Releases</link>.</para>
<para>To determine the potential features going in to future releases, or
to look at features implemented previously, take a look at the existing
blueprints such as&#160;<link
xlink:href="https://blueprints.launchpad.net/nova">OpenStack Compute (nova)
Blueprints</link>, <link xlink:href="https://blueprints.launchpad.net/keystone">OpenStack
Identity (keystone) Blueprints</link>, and release notes.</para>
<para>Aside from the direct-to-blueprint pathway, there is another very
well-regarded mechanism to influence the development roadmap: the user
survey. Found at <link
xlink:href="http://openstack.org/user-survey"></link>, it allows you to
provide details of your deployments and needs, anonymously by default.
Each cycle, the user committee analyzes the results and produces a report,
including providing specific information to the technical committee and
project team leads.</para>
</section>
<section xml:id="aspects-to-watch">
<title>Aspects to Watch</title>
<para>You want to keep an eye on the areas improving within OpenStack. The
best way to "watch" roadmaps for each project is to look at the blueprints
that are being approved for work on milestone releases. You can also learn
from PTL webinars that follow the OpenStack summits twice a
year.<indexterm class="startofrange" xml:id="OSaspect">
<primary>OpenStack community</primary>
<secondary>working with roadmaps</secondary>
<tertiary>aspects to watch</tertiary>
</indexterm></para>
<section xml:id="roadmap-driver-improvements">
<title>Driver Quality Improvements</title>
<para>A major quality push has occurred across drivers and plug-ins in
Block Storage, Compute, and Networking. Particularly, developers of
Compute and Networking drivers that require proprietary or hardware
products are now required to provide an automated external testing
system for use during the development process.</para>
</section>
<section xml:id="roadmap-easier-upgrades">
<title>Easier Upgrades</title>
<para>One of the most requested features since OpenStack began (for
components other than Object Storage, which tends to "just work"):
easier upgrades. In all recent releases internal messaging communication
is versioned, meaning services can theoretically drop back to
backward-compatible behavior. This allows you to run later versions of
some components, while keeping older versions of others.</para>
<para>In addition, database migrations are now tested with the Turbo
Hipster tool. This tool tests database migration performance on copies of
real-world user databases.</para>
<para>These changes have facilitated the first proper OpenStack upgrade
guide, found in <xref linkend="ch_ops_upgrades" />, and will continue to
improve in the next release.<indexterm class="singular">
<primary>Kilo</primary>
<secondary>upgrades in</secondary>
</indexterm></para>
</section>
<section xml:id="nova-network-deprecation">
<title>Deprecation of Nova Network</title>
<para>With the introduction of the full software-defined networking
stack provided by OpenStack Networking (neutron) in the Folsom release,
development effort on the initial networking code that remains part of
the Compute component has gradually lessened. While many still use
<literal>nova-network</literal> in production, there has been a
long-term plan to remove the code in favor of the more flexible and
full-featured OpenStack Networking.<indexterm class="singular">
<primary>nova</primary>
<secondary>deprecation of</secondary>
</indexterm></para>
<para>An attempt was made to deprecate <literal>nova-network</literal>
during the Havana release, which was aborted due to the lack of
equivalent functionality (such as the FlatDHCP multi-host
high-availability mode mentioned in this guide), lack of a migration
path between versions, insufficient testing, and simplicity when used
for the more straightforward use cases <literal>nova-network</literal>
traditionally supported. Though significant effort has been made to
address these concerns, <literal>nova-network</literal> was not be
deprecated in the Juno release. In addition, to a limited degree,
patches to <literal>nova-network</literal> have again begin to be
accepted, such as adding a per-network settings feature and SR-IOV
support in Juno.<indexterm class="singular">
<primary>Juno</primary>
<secondary>nova network deprecation</secondary>
</indexterm></para>
<para>This leaves you with an important point of decision when designing
your cloud. OpenStack Networking is robust enough to use with a small
number of limitations (performance issues in some scenarios, only basic
high availability of layer 3 systems) and provides many more features than
<literal>nova-network</literal>. However, if you do not have the more
complex use cases that can benefit from fuller software-defined
networking capabilities, or are uncomfortable with the new concepts
introduced, <literal>nova-network</literal> may continue to be a viable
option for the next 12 months.</para>
<para>Similarly, if you have an existing cloud and are looking to
upgrade from <literal>nova-network</literal> to OpenStack Networking,
you should have the option to delay the upgrade for this period of time.
However, each release of OpenStack brings significant new innovation,
and regardless of your use of networking methodology, it is likely best
to begin planning for an upgrade within a reasonable timeframe of each
release.</para>
<para>As mentioned, there's currently no way to cleanly migrate from
<literal>nova-network</literal> to neutron. We recommend that you keep a
migration in mind and what that process might involve for when a proper
migration path is released.</para>
</section>
</section>
<section xml:id="roadmap-DVR">
<title>Distributed Virtual Router</title>
<para>One of the long-time complaints surrounding OpenStack Networking was
the lack of high availability for the layer 3 components. The Juno release
introduced Distributed Virtual Router (DVR), which aims to solve this
problem.</para>
<para>Early indications are that it does do this well for a base set of
scenarios, such as using the ML2 plug-in with Open vSwitch, one flat
external network and VXLAN tenant networks. However, it does appear that
there are problems with the use of VLANs, IPv6, Floating IPs, high
north-south traffic scenarios and large numbers of compute nodes. It is
expected these will improve significantly with the next release, but
bug reports on specific issues are highly desirable.</para>
</section>
<section xml:id="roadmap-ML2">
<title>Replacement of Open vSwitch Plug-in with <phrase
role="keep-together">Modular Layer 2</phrase></title>
<para>The Modular Layer 2 plug-in is a framework allowing OpenStack
Networking to simultaneously utilize the variety of layer-2 networking
technologies found in complex real-world data centers. It currently works
with the existing Open vSwitch, Linux Bridge, and Hyper-V L2 agents and is
intended to replace and deprecate the monolithic plug-ins associated with
those L2 agents.</para>
</section>
<section xml:id="roadmap-new-api">
<title>New API Versions</title>
<para>The third version of the Compute API was broadly discussed and
worked on during the Havana and Icehouse release cycles. Current
discussions indicate that the V2 API will remain for many releases, and
the next iteration of the API will be denoted v2.1 and have similar
properties to the existing v2.0, rather than an entirely new v3 API.
This is a great time to evaluate all API and provide comments
while the next generation APIs are being defined. A new working group was
formed specifically to
<link xlink:href="https://wiki.openstack.org/wiki/API_Working_Group">improve
OpenStack APIs</link> and create design guidelines, which you are welcome to join.
<indexterm class="singular"><primary>Kilo</primary>
<secondary>Compute V3 API</secondary>
</indexterm></para>
</section>
<section xml:id="roadmap-triple-o">
<title>OpenStack on OpenStack (TripleO)</title>
<para>This project continues to improve and you may consider using it for
greenfield <phrase role="keep-together">deployments</phrase>, though
according to the latest user survey results it remains to see widespread
uptake.</para>
</section>
<section xml:id="roadmap-savanna">
<title>Data processing service for OpenStack (sahara)</title>
<para>A much-requested answer to big data problems, a dedicated team has
been making solid progress on a Hadoop-as-a-Service project.</para>
</section>
<section xml:id="roadmap-baremetal">
<title>Bare metal Deployment (ironic)</title>
<para>The bare-metal deployment has been widely lauded, and development
continues. The Juno release brought the OpenStack Bare metal drive into the Compute
project, and it was aimed to deprecate the existing bare-metal driver in
Kilo.
If you are a current user of the bare metal driver, a particular blueprint to follow is <link
xlink:href="https://blueprints.launchpad.net/nova/+spec/deprecate-baremetal-driver">
Deprecate the bare metal driver</link>.<indexterm class="singular">
<primary>Kilo</primary>
<secondary>Compute bare-metal deployment</secondary>
</indexterm></para>
</section>
<section xml:id="roadmap-trove">
<title>Database as a Service (trove)</title>
<para>The OpenStack community has had a database-as-a-service tool in
development for some time, and we saw the first integrated
release of it in Icehouse. From its release it was able to deploy database
servers out of the box in a highly available way, initially supporting only
MySQL. Juno introduced support for Mongo (including clustering), PostgreSQL and
Couchbase, in addition to replication functionality for MySQL. In Kilo,
more advanced clustering capability was delivered, in addition to better
integration with other OpenStack components such as Networking.
<indexterm class="singular">
<primary>Juno</primary>
<secondary>database-as-a-service tool</secondary>
</indexterm></para>
</section>
<section xml:id="roadmap-zaqar">
<title>Message Service (zaqar)</title>
<para>A service to provide queues of messages and notifications was released.</para>
</section>
<section xml:id="roadmap-designate">
<title>DNS service (designate)</title>
<para>A long requested service, to provide the ability to manipulate DNS
entries associated with OpenStack resources has gathered a following. The
designate project was also released.</para>
</section>
<section xml:id="roadmap-scheduling">
<title>Scheduler Improvements</title>
<para>Both Compute and Block Storage rely on schedulers to determine where
to place virtual machines or volumes. In Havana, the Compute scheduler
underwent significant improvement, while in Icehouse it was the scheduler in
Block Storage that received a boost. Further down the track, an effort
started this cycle that aims to create a holistic scheduler covering both
will come to fruition. Some of the work that was done in Kilo can be found under the
<link xlink:href="https://wiki.openstack.org/wiki/Gantt/kilo">Gantt
project</link>.<indexterm class="singular">
<primary>Kilo</primary>
<secondary>scheduler improvements</secondary>
</indexterm></para>
<section xml:id="roadmap-volumes">
<title>Block Storage Improvements</title>
<para>Block Storage is considered a stable project, with wide uptake
and a long track record of quality drivers. The team
has discussed many areas of work at the summits,
including better error reporting, automated discovery, and thin
provisioning features.</para>
</section>
<section xml:id="roadmap-python-sdk">
<title>Toward a Python SDK</title>
<para>Though many successfully use the various python-*client code as an
effective SDK for interacting with OpenStack, consistency between the
projects and documentation availability waxes and wanes. To combat this,
an <link xlink:href="https://wiki.openstack.org/wiki/PythonOpenStackSDK">effort to improve the
experience</link> has started. Cross-project development efforts in
OpenStack have a checkered history, such as the <link
xlink:href="https://wiki.openstack.org/wiki/OpenStackClient"> unified client project</link>
having several false starts. However, the early signs for the SDK
project are promising, and we expect to see results during the Juno
cycle.<indexterm class="endofrange" startref="OSaspect" /></para>
</section>
</section>
</appendix>

300
doc/openstack-ops/app_usecases.xml
View File

@ -1,300 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<appendix label="A" version="5.0" xml:id="use-cases"
xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:ns5="http://www.w3.org/1999/xhtml"
xmlns:ns4="http://www.w3.org/1998/Math/MathML"
xmlns:ns3="http://www.w3.org/2000/svg"
xmlns:ns="http://docbook.org/ns/docbook">
<title>Use Cases</title>
<para>This appendix contains a small selection of use cases from the
community, with more technical detail than usual. Further examples can be
found on the <link xlink:href="https://www.openstack.org/user-stories/"
xlink:title="OpenStack User Stories Website">OpenStack
website</link>.</para>
<section xml:id="nectar">
<title>NeCTAR</title>
<para>Who uses it: researchers from the Australian publicly funded
research sector. Use is across a wide variety of disciplines, with the
purpose of instances ranging from running simple web servers to using
hundreds of cores for high-throughput computing.<indexterm
class="singular">
<primary>NeCTAR Research Cloud</primary>
</indexterm><indexterm class="singular">
<primary>use cases</primary>
<secondary>NeCTAR</secondary>
</indexterm><indexterm class="singular">
<primary>OpenStack community</primary>
<secondary>use cases</secondary>
<tertiary>NeCTAR</tertiary>
</indexterm></para>
<section xml:id="nectar_deploy">
<title>Deployment</title>
<para>Using OpenStack Compute cells, the NeCTAR Research Cloud spans
eight sites with approximately 4,000 cores per site.</para>
<para>Each site runs a different configuration, as a resource
<glossterm>cell</glossterm>s in an OpenStack Compute cells setup. Some
sites span multiple data centers, some use off compute node storage with
a shared file system, and some use on compute node storage with a
non-shared file system. Each site deploys the Image service with an
Object Storage back end. A central Identity, dashboard, and
Compute API service are used. A login to the dashboard triggers a SAML
login with Shibboleth, which creates an <glossterm>account</glossterm>
in the Identity service with an SQL back end. An Object Storage Global
Cluster is used across several sites.</para>
<para>Compute nodes have 24 to 48 cores, with at least 4 GB of RAM per
core and approximately 40 GB of ephemeral storage per core.</para>
<para>All sites are based on Ubuntu 14.04, with KVM as the hypervisor.
The OpenStack version in use is typically the current stable version,
with 5 to 10 percent back-ported code from trunk and modifications.
</para>
</section>
<section xml:id="nectar_resources">
<title>Resources</title>
<itemizedlist>
<listitem>
<para><link xlink:href="https://www.openstack.org/user-stories/nectar/">OpenStack.org case
study</link></para>
</listitem>
<listitem>
<para><link xlink:href="https://github.com/NeCTAR-RC/">NeCTAR-RC
GitHub</link></para>
</listitem>
<listitem>
<para><link xlink:href="https://www.nectar.org.au/">NeCTAR
website</link></para>
</listitem>
</itemizedlist>
</section>
</section>
<section xml:id="mit_csail">
<title>MIT CSAIL</title>
<para>Who uses it: researchers from the MIT Computer Science and
Artificial Intelligence Lab.<indexterm class="singular">
<primary>CSAIL (Computer Science and Artificial Intelligence
Lab)</primary>
</indexterm><indexterm class="singular">
<primary>MIT CSAIL (Computer Science and Artificial Intelligence
Lab)</primary>
</indexterm><indexterm class="singular">
<primary>use cases</primary>
<secondary>MIT CSAIL</secondary>
</indexterm><indexterm class="singular">
<primary>OpenStack community</primary>
<secondary>use cases</secondary>
<tertiary>MIT CSAIL</tertiary>
</indexterm></para>
<section xml:id="mit_csail_deploy">
<title>Deployment</title>
<para>The CSAIL cloud is currently 64 physical nodes with a total of 768
physical cores and 3,456 GB of RAM. Persistent data storage is largely
outside the cloud on NFS, with cloud resources focused on compute
resources. There are more than 130 users in more than 40 projects,
typically running 2,000–2,500 vCPUs in 300 to 400 instances.</para>
<para>We initially deployed on Ubuntu 12.04 with the Essex release of
OpenStack using FlatDHCP multi-host networking.</para>
<para>The software stack is still Ubuntu 12.04 LTS, but now with
OpenStack Havana from the Ubuntu Cloud Archive. KVM is the hypervisor,
deployed using <link xlink:href="http://fai-project.org/">FAI</link>
and Puppet for configuration management. The FAI and Puppet combination
is used lab-wide, not only for OpenStack. There is a single cloud
controller node, which also acts as network controller, with the
remainder of the server hardware dedicated to compute nodes.</para>
<para>Host aggregates and instance-type extra specs are used to provide
two different resource allocation ratios. The default resource
allocation ratios we use are 4:1 CPU and 1.5:1 RAM. Compute-intensive
workloads use instance types that require non-oversubscribed hosts where
<literal>cpu_ratio</literal> and <literal>ram_ratio</literal> are both
set to 1.0. Since we have hyper-threading enabled on our compute nodes,
this provides one vCPU per CPU thread, or two vCPUs per physical
core.</para>
<para>With our upgrade to Grizzly in August 2013, we moved to OpenStack
Networking, neutron (quantum at the time). Compute nodes have
two-gigabit network interfaces and a separate management card for IPMI
management. One network interface is used for node-to-node
communications. The other is used as a trunk port for OpenStack managed
VLANs. The controller node uses two bonded 10g network interfaces for
its public IP communications. Big pipes are used here because images are
served over this port, and it is also used to connect to iSCSI storage,
back-ending the image storage and database. The controller node also has
a gigabit interface that is used in trunk mode for OpenStack managed
VLAN traffic. This port handles traffic to the dhcp-agent and
metadata-proxy.</para>
<para>We approximate the older <literal>nova-network</literal>
multi-host HA setup by using "provider VLAN networks" that connect
instances directly to existing publicly addressable networks and use
existing physical routers as their default gateway. This means that if
our network controller goes down, running instances still have their
network available, and no single Linux host becomes a traffic
bottleneck. We are able to do this because we have a sufficient supply
of IPv4 addresses to cover all of our instances and thus don't need NAT
and don't use floating IP addresses. We provide a single generic public
network to all projects and additional existing VLANs on a
project-by-project basis as needed. Individual projects are also allowed
to create their own private GRE based networks.</para>
</section>
<section xml:id="CSAIL_resources">
<title>Resources</title>
<itemizedlist>
<listitem>
<para><link xlink:href="http://www.csail.mit.edu/">CSAIL
homepage</link></para>
</listitem>
</itemizedlist>
</section>
</section>
<section xml:id="dair">
<title>DAIR</title>
<para>Who uses it: DAIR is an integrated virtual environment that
leverages the CANARIE network to develop and test new information
communication technology (ICT) and other digital technologies. It combines
such digital infrastructure as advanced networking and cloud computing and
storage to create an environment for developing and testing innovative ICT
applications, protocols, and services; performing at-scale experimentation
for deployment; and facilitating a faster time to market.<indexterm
class="singular">
<primary>DAIR</primary>
</indexterm><indexterm class="singular">
<primary>use cases</primary>
<secondary>DAIR</secondary>
</indexterm><indexterm class="singular">
<primary>OpenStack community</primary>
<secondary>use cases</secondary>
<tertiary>DAIR</tertiary>
</indexterm></para>
<section xml:id="dair_deploy">
<title>Deployment</title>
<para>DAIR is hosted at two different data centers across Canada: one in
Alberta and the other in Quebec. It consists of a cloud controller at
each location, although, one is designated the "master" controller that
is in charge of central authentication and quotas. This is done through
custom scripts and light modifications to OpenStack. DAIR is currently
running Havana.</para>
<para>For Object Storage, each region has a swift environment.</para>
<para>A NetApp appliance is used in each region for both block storage
and instance storage. There are future plans to move the instances off
the NetApp appliance and onto a distributed file system such as
<glossterm>Ceph</glossterm> or GlusterFS.</para>
<para>VlanManager is used extensively for network management. All
servers have two bonded 10GbE NICs that are connected to two redundant
switches. DAIR is set up to use single-node networking where the cloud
controller is the gateway for all instances on all compute nodes.
Internal OpenStack traffic (for example, storage traffic) does not go
through the cloud controller.</para>
</section>
<section xml:id="dair_resources">
<title>Resources</title>
<itemizedlist>
<listitem>
<para><link xlink:href="http://www.canarie.ca/cloud/">DAIR
homepage</link></para>
</listitem>
</itemizedlist>
</section>
</section>
<section xml:id="cern">
<title>CERN</title>
<para>Who uses it: researchers at CERN (European Organization for Nuclear
Research) conducting high-energy physics research.<indexterm
class="singular">
<primary>CERN (European Organization for Nuclear Research)</primary>
</indexterm><indexterm class="singular">
<primary>use cases</primary>
<secondary>CERN</secondary>
</indexterm><indexterm class="singular">
<primary>OpenStack community</primary>
<secondary>use cases</secondary>
<tertiary>CERN</tertiary>
</indexterm></para>
<section xml:id="cern_deploy">
<title>Deployment</title>
<para>The environment is largely based on Scientific Linux 6, which is
Red Hat compatible. We use KVM as our primary hypervisor, although tests
are ongoing with Hyper-V on Windows Server 2008.</para>
<para>We use the Puppet Labs OpenStack modules to configure Compute,
Image service, Identity, and dashboard. Puppet is used widely for
instance configuration, and Foreman is used as a GUI for reporting and
instance provisioning.</para>
<para>Users and groups are managed through Active Directory and imported
into the Identity service using LDAP.&#160;CLIs are available for nova
and Euca2ools to do this.</para>
<para>There are three clouds currently running at CERN, totaling about
4,700 compute nodes, with approximately 120,000 cores. The CERN IT cloud
aims to expand to 300,000 cores by 2015.</para>
</section>
<section xml:id="cern_resources">
<title>Resources</title>
<itemizedlist>
<listitem>
<para><link xlink:href="http://openstack-in-production.blogspot.de/2013/09/a-tale-of-3-openstack-clouds-50000.html">“OpenStack in
Production: A tale of 3 OpenStack Clouds”</link></para>
</listitem>
<listitem>
<para><link xlink:href="http://cds.cern.ch/record/1457989/files/chep%202012%20CERN%20infrastructure%20final.pdf?version=1">“Review of CERN
Data Centre Infrastructure”</link></para>
</listitem>
<listitem>
<para><link xlink:href="http://information-technology.web.cern.ch/book/cern-private-cloud-user-guide">“CERN Cloud
Infrastructure User Guide”</link></para>
</listitem>
</itemizedlist>
</section>
</section>
</appendix>

63
doc/openstack-ops/bk_ops_guide.xml
View File

@ -1,63 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE book [
<!-- Some useful entities borrowed from HTML -->
<!ENTITY ndash "&#x2013;">
<!ENTITY mdash "&#x2014;">
<!ENTITY hellip "&#x2026;">
<!ENTITY plusmn "&#xB1;">
]>
<book xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns:html="http://www.w3.org/1999/xhtml" version="5.0"
xml:id="openstack-operations-guide">
<title>OpenStack Operations Guide</title>
<?rax pdf.url="../ops-guide.pdf"?>
<titleabbrev>OpenStack Ops Guide</titleabbrev>
<info>
<author>
<personname>
<firstname/>
<surname/>
</personname>
<affiliation>
<orgname>OpenStack
Foundation</orgname>
</affiliation>
</author>
<copyright>
<year>2014</year>
<holder>OpenStack Foundation</holder>
</copyright>
<productname>OpenStack</productname>
<pubdate/>
<legalnotice role="cc-by">
<annotation>
<remark>Copyright details are filled
in by the template.</remark>
</annotation>
</legalnotice>
<abstract>
<para>This book provides information about
designing and operating OpenStack
clouds.</para>
</abstract>
</info>
<!-- front matter -->
<xi:include href="acknowledgements.xml"/>
<xi:include href="preface_ops.xml"/>
<!-- parts: architecture and operations -->
<xi:include href="part_architecture.xml"/>
<xi:include href="part_operations.xml"/>
<!-- appendices -->
<xi:include href="app_usecases.xml"/>
<xi:include href="app_crypt.xml"/>
<xi:include href="app_roadmaps.xml"/>
<!-- doc history and resources -->
<xi:include href="ch_ops_resources.xml"/>
<!-- glossary -->
<xi:include href="../glossary/glossary-terms.xml"/>
<index/>
</book>

BIN
doc/openstack-ops/callouts/1.pdf
View File

Binary file not shown.

BIN
doc/openstack-ops/callouts/1.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 329 B

BIN
doc/openstack-ops/callouts/10.pdf
View File

Binary file not shown.

BIN
doc/openstack-ops/callouts/10.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 361 B

BIN
doc/openstack-ops/callouts/2.pdf
View File

Binary file not shown.

BIN
doc/openstack-ops/callouts/2.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 353 B

BIN
doc/openstack-ops/callouts/3.pdf
View File

Binary file not shown.

BIN
doc/openstack-ops/callouts/3.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 350 B

BIN
doc/openstack-ops/callouts/4.pdf
View File

Binary file not shown.

BIN
doc/openstack-ops/callouts/4.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 345 B

BIN
doc/openstack-ops/callouts/5.pdf
View File

Binary file not shown.

BIN
doc/openstack-ops/callouts/5.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 348 B

BIN
doc/openstack-ops/callouts/6.pdf
View File

Binary file not shown.

BIN
doc/openstack-ops/callouts/6.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 355 B

BIN
doc/openstack-ops/callouts/7.pdf
View File

Binary file not shown.

BIN
doc/openstack-ops/callouts/7.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 344 B

BIN
doc/openstack-ops/callouts/8.pdf
View File

Binary file not shown.

BIN
doc/openstack-ops/callouts/8.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 357 B

BIN
doc/openstack-ops/callouts/9.pdf
View File

Binary file not shown.

BIN
doc/openstack-ops/callouts/9.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 357 B

787
doc/openstack-ops/ch_arch_cloud_controller.xml
View File

@ -1,787 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter version="5.0" xml:id="cloud_controller_design"
xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:ns5="http://www.w3.org/1999/xhtml"
xmlns:ns4="http://www.w3.org/2000/svg"
xmlns:ns3="http://www.w3.org/1998/Math/MathML"
xmlns:db="http://docbook.org/ns/docbook">
<?dbhtml stop-chunking?>
<title>Designing for Cloud Controllers and <phrase
role="keep-together">Cloud Management</phrase></title>
<para>OpenStack is designed to be massively horizontally scalable, which
allows all services to be distributed widely. However, to simplify this
guide, we have decided to discuss services of a more central nature, using
the concept of a <emphasis>cloud controller</emphasis>. A cloud controller
is just a conceptual simplification. In the real world, you design an
architecture for your cloud controller that enables high availability so
that if any node fails, another can take over the required tasks. In
reality, cloud controller tasks are spread out across more than a single
node.<indexterm class="singular">
<primary>design considerations</primary>
<secondary>cloud controller services</secondary>
</indexterm><indexterm class="singular">
<primary>cloud controllers</primary>
<secondary>concept of</secondary>
</indexterm></para>
<para>The cloud controller provides the central management system for
OpenStack deployments. Typically, the cloud controller manages
authentication and sends messaging to all the systems through a message
queue.</para>
<para>For many deployments, the cloud controller is a single node. However,
to have high availability, you have to take a few considerations into
account, which we'll cover in this chapter.</para>
<para>The cloud controller manages the following services for the
cloud:<indexterm class="singular">
<primary>cloud controllers</primary>
<secondary>services managed by</secondary>
</indexterm></para>
<variablelist>
<varlistentry>
<term>Databases</term>
<listitem>
<para>Tracks current information about users and instances, for
example, in a database, typically one database instance managed per
service</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Message queue services</term>
<listitem>
<para>All AMQP—Advanced Message Queue Protocol—messages for services
are received and sent according to the queue broker<indexterm
class="singular">
<primary>Advanced Message Queuing Protocol (AMQP)</primary>
</indexterm></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Conductor services</term>
<listitem>
<para>Proxy requests to a database</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Authentication and authorization for identity management</term>
<listitem>
<para>Indicates which users can do what actions on certain cloud
resources; quota management is spread out among services,
however<indexterm class="singular">
<primary>authentication</primary>
</indexterm></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Image-management services</term>
<listitem>
<para>Stores and serves images with metadata on each, for launching in
the cloud</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Scheduling services</term>
<listitem>
<para>Indicates which resources to use first; for example, spreading
out where instances are launched based on an algorithm</para>
</listitem>
</varlistentry>
<varlistentry>
<term>User dashboard</term>
<listitem>
<para>Provides a web-based front end for users to consume OpenStack
cloud services</para>
</listitem>
</varlistentry>
<varlistentry>
<term>API endpoints</term>
<listitem>
<para>Offers each service's REST API access, where the API endpoint
catalog is managed by the Identity service</para>
</listitem>
</varlistentry>
</variablelist>
<para>For our example, the cloud controller has a collection of
<code>nova-*</code> components that represent the global state of the cloud;
talks to services such as authentication; maintains information about the
cloud in a database; communicates to all compute nodes and storage
<glossterm>worker</glossterm>s through a queue; and provides API access.
Each service running on a designated cloud controller may be broken out into
separate nodes for scalability or availability.<indexterm class="singular">
<primary>storage</primary>
<secondary>storage workers</secondary>
</indexterm><indexterm class="singular">
<primary>workers</primary>
</indexterm></para>
<para>As another example, you could use pairs of servers for a collective
cloud controller—one active, one standby—for redundant nodes providing a
given set of related services, such as:</para>
<itemizedlist>
<listitem>
<para>Front end web for API requests, the scheduler for choosing which
compute node to boot an instance on, Identity services, and the
dashboard</para>
</listitem>
<listitem>
<para>Database and message queue server (such as MySQL, RabbitMQ)</para>
</listitem>
<listitem>
<para>Image service for the image management</para>
</listitem>
</itemizedlist>
<para>Now that you see the myriad designs for controlling your cloud, read
more about the further considerations to help with your design
decisions.</para>
<section xml:id="hardware_consid">
<title>Hardware Considerations</title>
<para>A cloud controller's hardware can be the same as a compute node,
though you may want to further specify based on the size and type of cloud
that you run.<indexterm class="singular">
<primary>hardware</primary>
<secondary>design considerations</secondary>
</indexterm><indexterm class="singular">
<primary>design considerations</primary>
<secondary>hardware considerations</secondary>
</indexterm></para>
<para>It's also possible to use virtual machines for all or some of the
services that the cloud controller manages, such as the message queuing.
In this guide, we assume that all services are running directly on the
cloud controller.</para>
<para><xref linkend="controller-hardware-sizing" /> contains common
considerations to review when sizing hardware for the cloud controller
design.<indexterm class="singular">
<primary>cloud controllers</primary>
<secondary>hardware sizing considerations</secondary>
</indexterm><indexterm class="singular">
<primary>Active Directory</primary>
</indexterm><indexterm class="singular">
<primary>dashboard</primary>
</indexterm></para>
<table rules="all" xml:id="controller-hardware-sizing">
<caption>Cloud controller hardware sizing considerations</caption>
<col width="25%" />
<col width="75%" />
<thead>
<tr>
<th>Consideration</th>
<th>Ramification</th>
</tr>
</thead>
<tbody>
<tr>
<td><para>How many instances will run at once?</para></td>
<td><para>Size your database server accordingly, and scale out
beyond one cloud controller if many instances will report status at
the same time and scheduling where a new instance starts up needs
computing power.</para></td>
</tr>
<tr>
<td><para>How many compute nodes will run at once?</para></td>
<td><para>Ensure that your messaging queue handles requests
successfully and size accordingly.</para></td>
</tr>
<tr>
<td><para>How many users will access the API?</para></td>
<td><para>If many users will make multiple requests, make sure that
the CPU load for the cloud controller can handle it.</para></td>
</tr>
<tr>
<td><para>How many users will access the
<glossterm>dashboard</glossterm> versus the REST API
directly?</para></td>
<td><para>The dashboard makes many requests, even more than the API
access, so add even more CPU if your dashboard is the main interface
for your users.</para></td>
</tr>
<tr>
<td><para>How many <code>nova-api</code> services do you run at once
for your cloud?</para></td>
<td><para>You need to size the controller with a core per
service.</para></td>
</tr>
<tr>
<td><para>How long does a single instance run?</para></td>
<td><para>Starting instances and deleting instances is demanding on
the compute node but also demanding on the controller node because
of all the API queries and scheduling needs.</para></td>
</tr>
<tr>
<td><para>Does your authentication system also verify
externally?</para></td>
<td><para>External systems such as LDAP or <glossterm>Active
Directory</glossterm> require network connectivity between the cloud
controller and an external authentication system. Also ensure that
the cloud controller has the CPU power to keep up with
requests.</para></td>
</tr>
</tbody>
</table>
</section>
<section xml:id="separate_services">
<title>Separation of Services</title>
<para>While our example contains all central services in a single
location, it is possible and indeed often a good idea to separate services
onto different physical servers. <xref linkend="sep-services-table" /> is
a list of deployment scenarios we've seen and their
justifications.<indexterm class="singular">
<primary>provisioning/deployment</primary>
<secondary>deployment scenarios</secondary>
</indexterm><indexterm class="singular">
<primary>services</primary>
<secondary>separation of</secondary>
</indexterm><indexterm class="singular">
<primary>separation of services</primary>
</indexterm><indexterm class="singular">
<primary>design considerations</primary>
<secondary>separation of services</secondary>
</indexterm></para>
<table rules="all" xml:id="sep-services-table">
<caption>Deployment scenarios</caption>
<col width="25%" />
<col width="75%" />
<thead>
<tr>
<th>Scenario</th>
<th>Justification</th>
</tr>
</thead>
<tbody>
<tr>
<td><para>Run <code>glance-*</code> servers on the
<code>swift-proxy</code> server.</para></td>
<td><para>This deployment felt that the spare I/O on the Object
Storage proxy server was sufficient and that the Image Delivery
portion of glance benefited from being on physical hardware and
having good connectivity to the Object Storage back end it was
using.</para></td>
</tr>
<tr>
<td><para>Run a central dedicated database server.</para></td>
<td><para>This deployment used a central dedicated server to provide
the databases for all services. This approach simplified operations
by isolating database server updates and allowed for the simple
creation of slave database servers for failover.</para></td>
</tr>
<tr>
<td><para>Run one VM per service.</para></td>
<td><para>This deployment ran central services on a set of servers
running KVM. A dedicated VM was created for each service
(<literal>nova-scheduler</literal>, rabbitmq, database, etc). This
assisted the deployment with scaling because administrators could
tune the resources given to each virtual machine based on the load
it received (something that was not well understood during
installation).</para></td>
</tr>
<tr>
<td><para>Use an external load balancer.</para></td>
<td><para>This deployment had an expensive hardware load balancer in
its organization. It ran multiple <code>nova-api</code> and
<code>swift-proxy</code> servers on different physical servers and
used the load balancer to switch between them.</para></td>
</tr>
</tbody>
</table>
<para>One choice that always comes up is whether to virtualize. Some
services, such as <code>nova-compute</code>, <code>swift-proxy</code> and
<code>swift-object</code> servers, should not be virtualized. However,
control servers can often be happily virtualized—the performance penalty
can usually be offset by simply running more of the service.</para>
</section>
<section xml:id="database">
<title>Database</title>
<para>OpenStack Compute uses an SQL database to store and retrieve stateful
information. MySQL is the popular database choice in the OpenStack
community.<indexterm class="singular">
<primary>databases</primary>
<secondary>design considerations</secondary>
</indexterm><indexterm class="singular">
<primary>design considerations</primary>
<secondary>database choice</secondary>
</indexterm></para>
<para>Loss of the database leads to errors. As a result, we recommend that
you cluster your database to make it failure tolerant. Configuring and
maintaining a database cluster is done outside OpenStack and is determined
by the database software you choose to use in your cloud environment.
MySQL/Galera is a popular option for MySQL-based databases.</para>
</section>
<section xml:id="message_queue">
<title>Message Queue</title>
<para>Most OpenStack services communicate with each other using the
<emphasis>message queue</emphasis>.<indexterm class="singular">
<primary>messages</primary>
<secondary>design considerations</secondary>
</indexterm><indexterm class="singular">
<primary>design considerations</primary>
<secondary>message queues</secondary>
</indexterm> For example, Compute communicates to block storage services
and networking services through the message queue. Also, you can
optionally enable notifications for any service. RabbitMQ, Qpid, and 0mq
are all popular choices for a message-queue service. In general, if the
message queue fails or becomes inaccessible, the cluster grinds to a halt
and ends up in a read-only state, with information stuck at the point
where the last message was sent. Accordingly, we recommend that you
cluster the message queue. Be aware that clustered message queues can be a
pain point for many OpenStack deployments. While RabbitMQ has native
clustering support, there have been reports of issues when running it at a
large scale. While other queuing solutions are available, such as 0mq and
Qpid, 0mq does not offer stateful queues. Qpid is the <phrase
role="keep-together">messaging</phrase> system of choice for Red Hat and
its derivatives. Qpid does not have native clustering capabilities and
requires a supplemental service, such as Pacemaker or Corsync. For your
message queue, you need to determine what level of data loss you are
comfortable with and whether to use an OpenStack project's ability to
retry multiple MQ hosts in the event of a failure, such as using Compute's
ability to do so.<indexterm class="singular">
<primary>0mq</primary>
</indexterm><indexterm class="singular">
<primary>Qpid</primary>
</indexterm><indexterm class="singular">
<primary>RabbitMQ</primary>
</indexterm><indexterm class="singular">
<primary>message queue</primary>
</indexterm></para>
</section>
<section xml:id="conductor">
<title>Conductor Services</title>
<para>In the previous version of OpenStack, all
<literal>nova-compute</literal> services required direct access to the
database hosted on the cloud controller. This was problematic for two
reasons: security and performance. With regard to security, if a compute
node is compromised, the attacker inherently has access to the database.
With regard to performance, <literal>nova-compute</literal> calls to the
database are single-threaded and blocking. This creates a performance
bottleneck because database requests are fulfilled serially rather than in
parallel.<indexterm class="singular">
<primary>conductors</primary>
</indexterm><indexterm class="singular">
<primary>design considerations</primary>
<secondary>conductor services</secondary>
</indexterm></para>
<para>The conductor service resolves both of these issues by acting as a
proxy for the <literal>nova-compute</literal> service. Now, instead of
<literal>nova-compute</literal> directly accessing the database, it
contacts the <literal>nova-conductor</literal> service, and
<literal>nova-conductor</literal> accesses the database on
<literal>nova-compute</literal>'s behalf. Since
<literal>nova-compute</literal> no longer has direct access to the
database, the security issue is resolved. Additionally,
<literal>nova-conductor</literal> is a nonblocking service, so requests
from all compute nodes are fulfilled in parallel.</para>
<note>
<para>If you are using <literal>nova-network</literal> and multi-host
networking in your cloud environment, <literal>nova-compute</literal>
still requires direct access to the database.<indexterm class="singular">
<primary>multi-host networking</primary>
</indexterm></para>
</note>
<para>The <literal>nova-conductor</literal> service is horizontally
scalable. To make <literal>nova-conductor</literal> highly available and
fault tolerant, just launch more instances of the
<code>nova-conductor</code> process, either on the same server or across
multiple servers.</para>
</section>
<section xml:id="api">
<title>Application Programming Interface (API)</title>
<para>All public access, whether direct, through a command-line client, or
through the web-based dashboard, uses the API service. Find the API
reference at <link
xlink:href="http://api.openstack.org/"></link>.<indexterm class="singular">
<primary>API (application programming interface)</primary>
<secondary>design considerations</secondary>
</indexterm><indexterm class="singular">
<primary>design considerations</primary>
<secondary>API support</secondary>
</indexterm></para>
<para>You must choose whether you want to support the Amazon EC2
compatibility APIs, or just the OpenStack APIs. One issue you might
encounter when running both APIs is an inconsistent experience when
referring to images and instances.</para>
<para>For example, the EC2 API refers to instances using IDs that contain
hexadecimal, whereas the OpenStack API uses names and digits. Similarly,
the EC2 API tends to rely on DNS aliases for contacting virtual machines,
as opposed to OpenStack, which typically lists IP addresses.<indexterm
class="singular">
<primary>DNS (Domain Name Server, Service or System)</primary>
<secondary>DNS aliases</secondary>
</indexterm><indexterm class="singular">
<primary>troubleshooting</primary>
<secondary>DNS issues</secondary>
</indexterm></para>
<para>If OpenStack is not set up in the right way, it is simple to have
scenarios in which users are unable to contact their instances due to
having only an incorrect DNS alias. Despite this, EC2 compatibility can
assist users migrating to your cloud.</para>
<para>As with databases and message queues, having more than one
<glossterm>API server</glossterm> is a good thing. Traditional HTTP
load-balancing techniques can be used to achieve a highly available
<code>nova-api</code> service.<indexterm class="singular">
<primary>API (application programming interface)</primary>
<secondary>API server</secondary>
</indexterm></para>
</section>
<section xml:id="extensions">
<title>Extensions</title>
<para>The <link xlink:href="http://docs.openstack.org/api/api-specs.html"
xlink:title="API Specifications">API Specifications</link> define the core
actions, capabilities, and mediatypes of the OpenStack API. A client can
always depend on the availability of this core API, and implementers are
always required to support it in its <phrase
role="keep-together">entirety</phrase>. Requiring strict adherence to the
core API allows clients to rely upon a minimal level of functionality when
interacting with multiple implementations of the same API.<indexterm
class="singular">
<primary>extensions</primary>
<secondary>design considerations</secondary>
</indexterm><indexterm class="singular">
<primary>design considerations</primary>
<secondary>extensions</secondary>
</indexterm></para>
<para>The OpenStack Compute API is extensible. An extension adds
capabilities to an API beyond those defined in the core. The introduction
of new features, MIME types, actions, states, headers, parameters, and
resources can all be accomplished by means of extensions to the core API.
This allows the introduction of new features in the API without requiring
a version change and allows the introduction of vendor-specific niche
functionality.</para>
</section>
<section xml:id="scheduling">
<title>Scheduling</title>
<para>The scheduling services are responsible for determining the compute
or storage node where a virtual machine or block storage volume should be
created. The scheduling services receive creation requests for these
resources from the message queue and then begin the process of determining
the appropriate node where the resource should reside. This process is
done by applying a series of user-configurable filters against the
available collection of nodes.<indexterm class="singular">
<primary>schedulers</primary>
<secondary>design considerations</secondary>
</indexterm><indexterm class="singular">
<primary>design considerations</primary>
<secondary>scheduling</secondary>
</indexterm></para>
<para>There are currently two schedulers:
<literal>nova-scheduler</literal> for virtual machines and
<literal>cinder-scheduler</literal> for block storage volumes. Both
schedulers are able to scale horizontally, so for high-availability
purposes, or for very large or high-schedule-frequency installations, you
should consider running multiple instances of each scheduler. The
schedulers all listen to the shared message queue, so no special load
balancing is required.</para>
</section>
<section xml:id="images">
<title>Images</title>
<para>The OpenStack Image service consists of two parts:
<code>glance-api</code> and <code>glance-registry</code>. The former is
responsible for the delivery of images; the compute node uses it to
download images from the back end. The latter maintains the metadata
information associated with virtual machine images and requires a
database.<indexterm class="singular">
<primary>glance</primary>
<secondary>glance registry</secondary>
</indexterm><indexterm class="singular">
<primary>glance</primary>
<secondary>glance API server</secondary>
</indexterm><indexterm class="singular">
<primary>metadata</primary>
<secondary>OpenStack Image service and</secondary>
</indexterm><indexterm class="singular">
<primary>Image service</primary>
<secondary>design considerations</secondary>
</indexterm><indexterm class="singular">
<primary>design considerations</primary>
<secondary>images</secondary>
</indexterm></para>
<para>The <code>glance-api</code> part is an abstraction layer that allows
a choice of back end. Currently, it supports:</para>
<variablelist>
<varlistentry>
<term>OpenStack Object Storage</term>
<listitem>
<para>Allows you to store images as objects.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>File system</term>
<listitem>
<para>Uses any traditional file system to store the images as
files.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>S3</term>
<listitem>
<para>Allows you to fetch images from Amazon S3.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>HTTP</term>
<listitem>
<para>Allows you to fetch images from a web server. You cannot write
images by using this mode.</para>
</listitem>
</varlistentry>
</variablelist>
<para>If you have an OpenStack Object Storage service, we recommend using
this as a scalable place to store your images. You can also use a file
system with sufficient performance or Amazon S3—unless you do not need the
ability to upload new images through OpenStack.</para>
</section>
<section xml:id="dashboard">
<title>Dashboard</title>
<para>The OpenStack dashboard (horizon) provides a web-based user
interface to the various OpenStack components. The dashboard includes an
end-user area for users to manage their virtual infrastructure and an
admin area for cloud operators to manage the OpenStack environment as a
whole.<indexterm class="singular">
<primary>dashboard</primary>
</indexterm><indexterm class="singular">
<primary>design considerations</primary>
<secondary>dashboard</secondary>
</indexterm></para>
<para>The dashboard is implemented as a Python web application that
normally runs in <glossterm>Apache</glossterm> <code>httpd</code>.
Therefore, you may treat it the same as any other web application,
provided it can reach the API servers (including their admin endpoints)
over the <phrase role="keep-together">network</phrase>.<indexterm
class="singular">
<primary>Apache</primary>
</indexterm></para>
</section>
<section xml:id="authentication">
<title>Authentication and Authorization</title>
<para>The concepts supporting OpenStack's authentication and authorization
are derived from well-understood and widely used systems of a similar
nature. Users have credentials they can use to authenticate, and they can
be a member of one or more groups (known as projects or tenants,
interchangeably).<indexterm class="singular">
<primary>credentials</primary>
</indexterm><indexterm class="singular">
<primary>authorization</primary>
</indexterm><indexterm class="singular">
<primary>authentication</primary>
</indexterm><indexterm class="singular">
<primary>design considerations</primary>
<secondary>authentication/authorization</secondary>
</indexterm></para>
<para>For example, a cloud administrator might be able to list all
instances in the cloud, whereas a user can see only those in his current
group. Resources quotas, such as the number of cores that can be used,
disk space, and so on, are associated with a project.</para>
<para>OpenStack Identity provides
authentication decisions and user attribute information, which is then
used by the other OpenStack services to perform authorization. The policy is
set in the <filename>policy.json</filename> file. For <phrase
role="keep-together">information</phrase> on how to configure these, see
<xref linkend="projects_users" />.<indexterm class="singular">
<primary>Identity</primary>
<secondary>authentication decisions</secondary>
</indexterm><indexterm class="singular">
<primary>Identity</primary>
<secondary>plug-in support</secondary>
</indexterm></para>
<para>OpenStack Identity supports different plug-ins for authentication
decisions and identity storage. Examples of these plug-ins include:</para>
<itemizedlist role="compact">
<listitem>
<para>In-memory key-value Store (a simplified internal storage
structure)</para>
</listitem>
<listitem>
<para>SQL database (such as MySQL or PostgreSQL)</para>
</listitem>
<listitem>
<para>Memcached (a distributed memory object caching system)</para>
</listitem>
<listitem>
<para>LDAP (such as OpenLDAP or Microsoft's Active Directory)</para>
</listitem>
</itemizedlist>
<para>Many deployments use the SQL database; however, LDAP is also a
popular choice for those with existing authentication infrastructure that
needs to be integrated.</para>
</section>
<section xml:id="network_consid">
<title>Network Considerations</title>
<para>Because the cloud controller handles so many different services, it
must be able to handle the amount of traffic that hits it. For example, if
you choose to host the OpenStack Image service on the cloud controller,
the cloud controller should be able to support the transferring of the
images at an acceptable speed.<indexterm class="singular">
<primary>cloud controllers</primary>
<secondary>network traffic and</secondary>
</indexterm><indexterm class="singular">
<primary>networks</primary>
<secondary>design considerations</secondary>
</indexterm><indexterm class="singular">
<primary>design considerations</primary>
<secondary>networks</secondary>
</indexterm></para>
<para>As another example, if you choose to use single-host networking
where the cloud controller is the network gateway for all instances, then
the cloud controller must support the total amount of traffic that travels
between your cloud and the public Internet.</para>
<para>We recommend that you use a fast NIC, such as 10 GB. You can also
choose to use two 10 GB NICs and bond them together. While you might not
be able to get a full bonded 20 GB speed, different transmission streams
use different NICs. For example, if the cloud controller transfers two
images, each image uses a different NIC and gets a full 10 GB of
bandwidth.<indexterm class="singular">
<primary>bandwidth</primary>
<secondary>design considerations for</secondary>
</indexterm></para>
</section>
</chapter>

623
doc/openstack-ops/ch_arch_compute_nodes.xml
View File

@ -1,623 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter version="5.0" xml:id="compute_nodes"
xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:ns5="http://www.w3.org/1999/xhtml"
xmlns:ns4="http://www.w3.org/1998/Math/MathML"
xmlns:ns3="http://www.w3.org/2000/svg"
xmlns:ns="http://docbook.org/ns/docbook">
<?dbhtml stop-chunking?>
<title>Compute Nodes</title>
<para>In this chapter, we discuss some of the choices you need to consider
when building out your compute nodes. Compute nodes form the resource core
of the OpenStack Compute cloud, providing the processing, memory, network
and storage resources to run instances.</para>
<section xml:id="cpu_choice">
<title>Choosing a CPU</title>
<para>The type of CPU in your compute node is a very important choice.
First, ensure that the CPU supports virtualization by way of
<emphasis>VT-x</emphasis> for Intel chips and <emphasis>AMD-v</emphasis>
for AMD chips.<indexterm class="singular">
<primary>CPUs (central processing units)</primary>
<secondary>choosing</secondary>
</indexterm><indexterm class="singular">
<primary>compute nodes</primary>
<secondary>CPU choice</secondary>
</indexterm></para>
<tip>
<para>Consult the vendor documentation to check for virtualization
support. For Intel, read <link xlink:href="http://www.intel.com/support/processors/sb/cs-030729.htm"
xlink:title="Intel VT-x"> “Does my processor support Intel®
Virtualization Technology?”</link>. For AMD, read <link
xlink:href=" http://www.amd.com/en-us/innovations/software-technologies/server-solution/virtualization" xlink:title="AMD-v"> AMD
Virtualization</link>. Note that your CPU may support virtualization but
it may be disabled. Consult your BIOS documentation for how to enable
CPU features.<indexterm class="singular">
<primary>virtualization technology</primary>
</indexterm><indexterm class="singular">
<primary>AMD Virtualization</primary>
</indexterm><indexterm class="singular">
<primary>Intel Virtualization Technology</primary>
</indexterm></para>
</tip>
<para>The number of cores that the CPU has also affects the decision. It's
common for current CPUs to have up to 12 cores. Additionally, if an Intel
CPU supports hyperthreading, those 12 cores are doubled to 24 cores. If
you purchase a server that supports multiple CPUs, the number of cores is
further multiplied.<indexterm class="singular">
<primary>cores</primary>
</indexterm><indexterm class="singular">
<primary>hyperthreading</primary>
</indexterm><indexterm class="singular">
<primary>multithreading</primary>
</indexterm></para>
<?hard-pagebreak ?>
<sidebar>
<title>Multithread Considerations</title>
<para>Hyper-Threading is Intel's proprietary simultaneous multithreading
implementation used to improve parallelization on their CPUs. You might
consider enabling Hyper-Threading to improve the performance of
multithreaded applications.</para>
<para>Whether you should enable Hyper-Threading on your CPUs depends
upon your use case. For example, disabling Hyper-Threading can be
beneficial in intense computing environments. We recommend that you do
performance testing with your local workload with both Hyper-Threading
on and off to determine what is more appropriate in your case.<indexterm
class="singular">
<primary>CPUs (central processing units)</primary>
<secondary>enabling hyperthreading on</secondary>
</indexterm></para>
</sidebar>
</section>
<section xml:id="hypervisor_choice">
<title>Choosing a Hypervisor</title>
<para>A hypervisor provides software to manage virtual machine access to
the underlying hardware. The hypervisor creates, manages, and monitors
virtual machines.<indexterm class="singular">
<primary>Docker</primary>
</indexterm><indexterm class="singular">
<primary>Hyper-V</primary>
</indexterm><indexterm class="singular">
<primary>ESXi hypervisor</primary>
</indexterm><indexterm class="singular">
<primary>ESX hypervisor</primary>
</indexterm><indexterm class="singular">
<primary>VMware API</primary>
</indexterm><indexterm class="singular">
<primary>Quick EMUlator (QEMU)</primary>
</indexterm><indexterm class="singular">
<primary>Linux containers (LXC)</primary>
</indexterm><indexterm class="singular">
<primary>kernel-based VM (KVM) hypervisor</primary>
</indexterm><indexterm class="singular">
<primary>Xen API</primary>
<secondary>XenServer hypervisor</secondary>
</indexterm><indexterm class="singular">
<primary>hypervisors</primary>
<secondary>choosing</secondary>
</indexterm><indexterm class="singular">
<primary>compute nodes</primary>
<secondary>hypervisor choice</secondary>
</indexterm> OpenStack Compute supports many hypervisors to various
degrees, including: <itemizedlist role="compact">
<listitem>
<para><link xlink:href="http://www.linux-kvm.org/page/Main_Page"
xlink:title="reference manual">KVM</link></para>
</listitem>
<listitem>
<para><link xlink:href="https://linuxcontainers.org/"
xlink:title="reference manual">LXC</link></para>
</listitem>
<listitem>
<para><link xlink:href="http://wiki.qemu.org/Main_Page"
xlink:title="reference manual">QEMU</link></para>
</listitem>
<listitem>
<para><link xlink:href="https://www.vmware.com/support/vsphere-hypervisor"
xlink:title="reference manual">VMware ESX/ESXi</link></para>
</listitem>
<listitem>
<para><link xlink:href="http://www.xenproject.org/"
xlink:title="reference manual">Xen</link></para>
</listitem>
<listitem>
<para><link xlink:href="http://technet.microsoft.com/en-us/library/hh831531.aspx"
xlink:title="reference manual">Hyper-V</link></para>
</listitem>
<listitem>
<para><link xlink:href="https://www.docker.com/"
xlink:title="reference manual">Docker</link></para>
</listitem>
</itemizedlist></para>
<para>Probably the most important factor in your choice of hypervisor is
your current usage or experience. Aside from that, there are practical
concerns to do with feature parity, documentation, and the level of
community experience.</para>
<para>For example, KVM is the most widely adopted hypervisor in the
OpenStack community. Besides KVM, more deployments run Xen, LXC, VMware,
and Hyper-V than the others listed.&#160;However, each of these are
lacking some feature support or the documentation on how to use them with
OpenStack is out of date.</para>
<para>The best information available to support your choice is found on
the <link xlink:href="http://docs.openstack.org/developer/nova/support-matrix.html"
xlink:title="reference manual">Hypervisor Support Matrix</link> and in the
<link xlink:href="http://docs.openstack.org/liberty/config-reference/content/section_compute-hypervisors.html"
xlink:title="configuration reference">configuration
reference</link>.</para>
<note>
<para>It is also possible to run multiple hypervisors in a single
deployment using host aggregates or cells. However, an individual
compute node can run only a single hypervisor at a time.<indexterm
class="singular">
<primary>hypervisors</primary>
<secondary>running multiple</secondary>
</indexterm></para>
</note>
</section>
<section xml:id="instance_storage">
<title>Instance Storage Solutions</title>
<para>As part of the procurement for a compute cluster, you must specify
some storage for the disk on which the instantiated instance runs. There
are three main approaches to providing this temporary-style storage, and
it is important to understand the implications of the choice.<indexterm
class="singular">
<primary>storage</primary>
<secondary>instance storage solutions</secondary>
</indexterm><indexterm class="singular">
<primary>instances</primary>
<secondary>storage solutions</secondary>
</indexterm><indexterm class="singular">
<primary>compute nodes</primary>
<secondary>instance storage solutions</secondary>
</indexterm></para>
<para>They are:</para>
<itemizedlist role="compact">
<listitem>
<para>Off compute node storage—shared file system</para>
</listitem>
<listitem>
<para>On compute node storage—shared file system</para>
</listitem>
<listitem>
<para>On compute node storage—nonshared file system</para>
</listitem>
</itemizedlist>
<para>In general, the questions you should ask when selecting storage are
as follows:</para>
<itemizedlist role="compact">
<listitem>
<para>What is the platter count you can achieve?</para>
</listitem>
<listitem>
<para>Do more spindles result in better I/O despite network
access?</para>
</listitem>
<listitem>
<para>Which one results in the best cost-performance scenario you're
aiming for?</para>
</listitem>
<listitem>
<para>How do you manage the storage operationally?</para>
</listitem>
</itemizedlist>
<para>Many operators use separate compute and storage hosts. Compute
services and storage services have different requirements, and compute
hosts typically require more CPU and RAM than storage hosts. Therefore,
for a fixed budget, it makes sense to have different configurations for
your compute nodes and your storage nodes. Compute nodes will be invested
in CPU and RAM, and storage nodes will be invested in block
storage.</para>
<para>However, if you are more restricted in the number of physical hosts
you have available for creating your cloud and you want to be able to
dedicate as many of your hosts as possible to running instances, it makes
sense to run compute and storage on the same machines.</para>
<para>We'll discuss the three main approaches to instance storage in the
next few sections.</para>
<?hard-pagebreak ?>
<section xml:id="off_compute_node_storage">
<title>Off Compute Node Storage—Shared File System</title>
<para>In this option, the disks storing the running instances are hosted
in servers outside of the compute nodes.<indexterm class="singular">
<primary>shared storage</primary>
</indexterm><indexterm class="singular">
<primary>file systems</primary>
<secondary>shared</secondary>
</indexterm></para>
<para>If you use separate compute and storage hosts, you can treat your
compute hosts as "stateless." As long as you don't have any instances
currently running on a compute host, you can take it offline or wipe it
completely without having any effect on the rest of your cloud. This
simplifies maintenance for the compute hosts.</para>
<para>There are several advantages to this approach:</para>
<itemizedlist role="compact">
<listitem>
<para>If a compute node fails, instances are usually easily
recoverable.</para>
</listitem>
<listitem>
<para>Running a dedicated storage system can be operationally
simpler.</para>
</listitem>
<listitem>
<para>You can scale to any number of spindles.</para>
</listitem>
<listitem>
<para>It may be possible to share the external storage for other
purposes.</para>
</listitem>
</itemizedlist>
<para>The main downsides to this approach are:</para>
<itemizedlist role="compact">
<listitem>
<para>Depending on design, heavy I/O usage from some instances can
affect unrelated instances.</para>
</listitem>
<listitem>
<para>Use of the network can decrease performance.</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="on_compute_node_storage">
<title>On Compute Node Storage—Shared File System</title>
<para>In this option, each compute node is specified with a significant
amount of disk space, but a distributed file system ties the disks from
each compute node into a single mount.</para>
<para>The main advantage of this option is that it scales to external
storage when you require additional storage.</para>
<para>However, this option has several downsides:</para>
<itemizedlist role="compact">
<listitem>
<para>Running a distributed file system can make you lose your data
locality compared with nonshared storage.</para>
</listitem>
<listitem>
<para>Recovery of instances is complicated by depending on multiple
hosts.</para>
</listitem>
<listitem>
<para>The chassis size of the compute node can limit the number of
spindles able to be used in a compute node.</para>
</listitem>
<listitem>
<para>Use of the network can decrease performance.</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="on_compute_node_storage_nonshared">
<title>On Compute Node Storage—Nonshared File System</title>
<para>In this option, each compute node is specified with enough disks
to store the instances it hosts.<indexterm class="singular">
<primary>file systems</primary>
<secondary>nonshared</secondary>
</indexterm></para>
<para>There are two main reasons why this is a good idea:</para>
<itemizedlist role="compact">
<listitem>
<para>Heavy I/O usage on one compute node does not affect instances
on other compute nodes.</para>
</listitem>
<listitem>
<para>Direct I/O access can increase performance.</para>
</listitem>
</itemizedlist>
<para>This has several downsides:</para>
<itemizedlist role="compact">
<listitem>
<para>If a compute node fails, the instances running on that node
are lost.</para>
</listitem>
<listitem>
<para>The chassis size of the compute node can limit the number of
spindles able to be used in a compute node.</para>
</listitem>
<listitem>
<para>Migrations of instances from one node to another are more
complicated and rely on features that may not continue to be
developed.</para>
</listitem>
<listitem>
<para>If additional storage is required, this option does not
scale.</para>
</listitem>
</itemizedlist>
<para>Running a shared file system on a storage system apart from the
computes nodes is ideal for clouds where reliability and scalability are
the most important factors. Running a shared file system on the compute
nodes themselves may be best in a scenario where you have to deploy to
preexisting servers for which you have little to no control over their
specifications. Running a nonshared file system on the compute nodes
themselves is a good option for clouds with high I/O requirements and
low concern for reliability.<indexterm class="singular">
<primary>scaling</primary>
<secondary>file system choice</secondary>
</indexterm></para>
</section>
<section xml:id="live_migration">
<title>Issues with Live Migration</title>
<para>We consider live migration an integral part of the operations of
the cloud. This feature provides the ability to seamlessly move
instances from one physical host to another, a necessity for performing
upgrades that require reboots of the compute hosts, but only works well
with shared storage.<indexterm class="singular">
<primary>storage</primary>
<secondary>live migration</secondary>
</indexterm><indexterm class="singular">
<primary>migration</primary>
</indexterm><indexterm class="singular">
<primary>live migration</primary>
</indexterm><indexterm class="singular">
<primary>compute nodes</primary>
<secondary>live migration</secondary>
</indexterm></para>
<para>Live migration can also be done with nonshared storage, using a
feature known as <emphasis>KVM live block migration</emphasis>. While an
earlier implementation of block-based migration in KVM and QEMU was
considered unreliable, there is a newer, more reliable implementation of
block-based live migration as of QEMU 1.4 and libvirt 1.0.2 that is also
compatible with OpenStack. However, none of the authors of this guide
have first-hand experience using live block migration.<indexterm
class="singular">
<primary>block migration</primary>
</indexterm></para>
</section>
<section xml:id="file_systems">
<title>Choice of File System</title>
<para>If you want to support shared-storage live migration, you need to
configure a distributed file system.<indexterm class="singular">
<primary>compute nodes</primary>
<secondary>file system choice</secondary>
</indexterm><indexterm class="singular">
<primary>file systems</primary>
<secondary>choice of</secondary>
</indexterm><indexterm class="singular">
<primary>storage</primary>
<secondary>file system choice</secondary>
</indexterm></para>
<para>Possible options include:</para>
<itemizedlist role="compact">
<listitem>
<para>NFS (default for Linux)</para>
</listitem>
<listitem>
<para>GlusterFS</para>
</listitem>
<listitem>
<para>MooseFS</para>
</listitem>
<listitem>
<para>Lustre</para>
</listitem>
</itemizedlist>
<para>We've seen deployments with all, and recommend that you choose the
one you are most familiar with operating. If you are not familiar with
any of these, choose NFS, as it is the easiest to set up and there is
extensive community knowledge about it.</para>
</section>
</section>
<section xml:id="overcommit">
<title>Overcommitting</title>
<para>OpenStack allows you to overcommit CPU and RAM on compute nodes.
This allows you to increase the number of instances you can have running
on your cloud, at the cost of reducing the performance of the
instances.<indexterm class="singular">
<primary>RAM overcommit</primary>
</indexterm><indexterm class="singular">
<primary>CPUs (central processing units)</primary>
<secondary>overcommitting</secondary>
</indexterm><indexterm class="singular">
<primary>overcommitting</primary>
</indexterm><indexterm class="singular">
<primary>compute nodes</primary>
<secondary>overcommitting</secondary>
</indexterm> OpenStack Compute uses the following ratios by
default:</para>
<itemizedlist role="compact">
<listitem>
<para>CPU allocation ratio: 16:1</para>
</listitem>
<listitem>
<para>RAM allocation ratio: 1.5:1</para>
</listitem>
</itemizedlist>
<para>The default CPU allocation ratio of 16:1 means that the scheduler
allocates up to 16 virtual cores per physical core. For example, if a
physical node has 12 cores, the scheduler sees 192 available virtual
cores. With typical flavor definitions of 4 virtual cores per instance,
this ratio would provide 48 instances on a physical node.</para>
<para>The formula for the number of virtual instances on a compute node is
<emphasis>(OR*PC)/VC</emphasis>, where:</para>
<variablelist>
<varlistentry>
<term><emphasis>OR</emphasis></term>
<listitem>
<para>CPU overcommit ratio (virtual cores per physical core)</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis>PC</emphasis></term>
<listitem>
<para>Number of physical cores</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis>VC</emphasis></term>
<listitem>
<para>Number of virtual cores per instance</para>
</listitem>
</varlistentry>
</variablelist>
<para>Similarly, the default RAM allocation ratio of 1.5:1 means that the
scheduler allocates instances to a physical node as long as the total
amount of RAM associated with the instances is less than 1.5 times the
amount of RAM available on the physical node.</para>
<para>For example, if a physical node has 48 GB of RAM, the scheduler
allocates instances to that node until the sum of the RAM associated with
the instances reaches 72 GB (such as nine instances, in the case where
each instance has 8 GB of RAM).</para>
<note>
<para>Regardless of the overcommit ratio, an instance can not be placed
on any physical node with fewer raw (pre-overcommit) resources than
the instance flavor requires.</para>
</note>
<para>You must select the appropriate CPU and RAM allocation ratio for
your particular use case.</para>
</section>
<section xml:id="logging">
<title>Logging</title>
<para>Logging is detailed more fully in <xref
linkend="logging_monitoring" />. However, it is an important design
consideration to take into account before commencing operations of your
cloud.<indexterm class="singular">
<primary>logging/monitoring</primary>
<secondary>compute nodes and</secondary>
</indexterm><indexterm class="singular">
<primary>compute nodes</primary>
<secondary>logging</secondary>
</indexterm></para>
<para>OpenStack produces a great deal of useful logging information,
however; but for the information to be useful for operations purposes, you
should consider having a central logging server to send logs to, and a log
parsing/analysis system (such as <phrase
role="keep-together">logstash</phrase>).</para>
</section>
<section xml:id="networking">
<title>Networking</title>
<para>Networking in OpenStack is a complex, multifaceted challenge. See
<xref linkend="network_design" />.<indexterm class="singular">
<primary>compute nodes</primary>
<secondary>networking</secondary>
</indexterm></para>
</section>
<section xml:id="conclusion">
<title>Conclusion</title>
<para>Compute nodes are the workhorse of your cloud and the place where
your users' applications will run. They are likely to be affected by your
decisions on what to deploy and how you deploy it. Their requirements
should be reflected in the choices you make.</para>
</section>
</chapter>

49
doc/openstack-ops/ch_arch_examples.xml
View File

@ -1,49 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter version="5.0" xml:id="example_architecture"
xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:ns5="http://www.w3.org/1998/Math/MathML"
xmlns:ns4="http://www.w3.org/1999/xhtml"
xmlns:ns3="http://www.w3.org/2000/svg"
xmlns:ns="http://docbook.org/ns/docbook">
<?dbhtml stop-chunking?>
<title>Architecture Examples</title>
<para>To understand the possibilities that OpenStack offers, it's best to start
with basic architecture that has been tested in
production environments. We offer two examples with basic pivots on the
base operating system (Ubuntu and Red Hat Enterprise Linux) and the
networking architecture. There are other differences between these two
examples and this guide provides reasons for each choice made.</para>
<para>Because OpenStack is highly configurable, with many different back ends
and network configuration options, it is difficult to write documentation
that covers all possible OpenStack deployments. Therefore, this guide
defines examples of architecture to simplify the task of documenting, as well
as to provide the scope for this guide. Both of the offered architecture
examples are currently running in production and serving users.</para>
<tip>
<para>As always, refer to the <xref linkend="openstack_glossary" /> if you
are unclear about any of the terminology mentioned in architecture
examples.</para>
</tip>
<xi:include href="section_arch_example-nova.xml" />
<xi:include href="section_arch_example-neutron.xml" />
<section xml:id="example_archs_conclusion">
<title>Parting Thoughts on Architecture Examples</title>
<para>With so many considerations and options available, our hope is to
provide a few clearly-marked and tested paths for your OpenStack
exploration. If you're looking for additional ideas, check out <xref
linkend="use-cases" />, the <link
xlink:href="http://docs.openstack.org/">OpenStack Installation Guides</link>,
or the <link xlink:href="http://www.openstack.org/user-stories/">OpenStack User Stories
page</link>.</para>
</section>
</chapter>

536
doc/openstack-ops/ch_arch_network_design.xml
View File

@ -1,536 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter version="5.0" xml:id="network_design"
xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:ns5="http://www.w3.org/2000/svg"
xmlns:ns4="http://www.w3.org/1998/Math/MathML"
xmlns:ns3="http://www.w3.org/1999/xhtml"
xmlns:ns="http://docbook.org/ns/docbook">
<?dbhtml stop-chunking?>
<title>Network Design</title>
<para>OpenStack provides a rich networking environment, and this chapter
details the requirements and options to deliberate when designing your
cloud.<indexterm class="singular">
<primary>network design</primary>
<secondary>first steps</secondary>
</indexterm><indexterm class="singular">
<primary>design considerations</primary>
<secondary>network design</secondary>
</indexterm></para>
<warning>
<para>If this is the first time you are deploying a cloud infrastructure
in your organization, after reading this section, your first conversations
should be with your networking team. Network usage in a running cloud is
vastly different from traditional network deployments and has the
potential to be disruptive at both a connectivity and a policy
level.<indexterm class="singular">
<primary>cloud computing</primary>
<secondary>vs. traditional deployments</secondary>
</indexterm></para>
</warning>
<para>For example, you must plan the number of IP addresses that you need
for both your guest instances as well as management infrastructure.
Additionally, you must research and discuss cloud network connectivity
through proxy servers and firewalls.</para>
<para>In this chapter, we'll give some examples of network implementations
to consider and provide information about some of the network layouts that
OpenStack uses. Finally, we have some brief notes on the networking services
that are essential for stable operation.</para>
<section xml:id="mgmt_network">
<title>Management Network</title>
<para>A <glossterm>management network</glossterm> (a separate network for
use by your cloud operators) typically consists of a separate switch and
separate NICs (network interface cards), and is a recommended option. This
segregation prevents system administration and the monitoring of system
access from being disrupted by traffic generated by guests.<indexterm
class="singular">
<primary>NICs (network interface cards)</primary>
</indexterm><indexterm class="singular">
<primary>management network</primary>
</indexterm><indexterm class="singular">
<primary>network design</primary>
<secondary>management network</secondary>
</indexterm></para>
<para>Consider creating other private networks for communication between
internal components of OpenStack, such as the message queue and OpenStack
Compute. Using a virtual local area network (VLAN) works well for these
scenarios because it provides a method for creating multiple virtual
networks on a physical network.</para>
</section>
<section xml:id="public_addressing">
<title>Public Addressing Options</title>
<para>There are two main types of IP addresses for guest virtual machines:
fixed IPs and floating IPs. Fixed IPs are assigned to instances on boot,
whereas floating IP addresses can change their association between
instances by action of the user. Both types of IP addresses can be either
public or private, depending on your use case.<indexterm class="singular">
<primary>IP addresses</primary>
<secondary>public addressing options</secondary>
</indexterm><indexterm class="singular">
<primary>network design</primary>
<secondary>public addressing options</secondary>
</indexterm></para>
<para>Fixed IP addresses are required, whereas it is possible to run
OpenStack without floating IPs. One of the most common use cases for
floating IPs is to provide public IP addresses to a private cloud, where
there are a limited number of IP addresses available. Another is for a
public cloud user to have a "static" IP address that can be reassigned
when an instance is upgraded or moved.<indexterm class="singular">
<primary>IP addresses</primary>
<secondary>static</secondary>
</indexterm><indexterm class="singular">
<primary>static IP addresses</primary>
</indexterm></para>
<para>Fixed IP addresses can be private for private clouds, or public for
public clouds. When an instance terminates, its fixed IP is lost. It is
worth noting that newer users of cloud computing may find their ephemeral
nature frustrating.<indexterm class="singular">
<primary>IP addresses</primary>
<secondary>fixed</secondary>
</indexterm><indexterm class="singular">
<primary>fixed IP addresses</primary>
</indexterm></para>
</section>
<section xml:id="ip_address_planning">
<title>IP Address Planning</title>
<para>An OpenStack installation can potentially have many subnets (ranges
of IP addresses) and different types of services in each. An IP address
plan can assist with a shared understanding of network partition purposes
and scalability. Control services can have public and private IP
addresses, and as noted above, there are a couple of options for an
instance's public addresses.<indexterm class="singular">
<primary>IP addresses</primary>
<secondary>address planning</secondary>
</indexterm><indexterm class="singular">
<primary>network design</primary>
<secondary>IP address planning</secondary>
</indexterm></para>
<para>An IP address plan might be broken down into the following
sections:<indexterm class="singular">
<primary>IP addresses</primary>
<secondary>sections of</secondary>
</indexterm></para>
<variablelist>
<varlistentry>
<term>Subnet router</term>
<listitem>
<para>Packets leaving the subnet go via this address, which could be
a dedicated router or a <literal>nova-network</literal>
service.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Control services public interfaces</term>
<listitem>
<para>Public access to <code>swift-proxy</code>,
<code>nova-api</code>, <code>glance-api</code>, and horizon come to
these addresses, which could be on one side of a load balancer or
pointing at individual machines.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Object Storage cluster internal communications</term>
<listitem>
<para>Traffic among object/account/container servers and between
these and the proxy server's internal interface uses this private
network.<indexterm class="singular">
<primary>containers</primary>
<secondary>container servers</secondary>
</indexterm><indexterm class="singular">
<primary>objects</primary>
<secondary>object servers</secondary>
</indexterm><indexterm class="singular">
<primary>account server</primary>
</indexterm></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Compute and storage communications</term>
<listitem>
<para>If ephemeral or block storage is external to the compute node,
this network is used.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Out-of-band remote management</term>
<listitem>
<para>If a dedicated remote access controller chip is included in
servers, often these are on a separate network.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>In-band remote management</term>
<listitem>
<para>Often, an extra (such as 1 GB) interface on compute or storage
nodes is used for system administrators or monitoring tools to
access the host instead of going through the public
interface.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Spare space for future growth</term>
<listitem>
<para>Adding more public-facing control services or guest instance
IPs should always be part of your plan.</para>
</listitem>
</varlistentry>
</variablelist>
<para>For example, take a deployment that has both OpenStack Compute and
Object Storage, with private ranges 172.22.42.0/24 and 172.22.87.0/26
available. One way to segregate the space might be as follows:</para>
<programlisting><?db-font-size 55%?>172.22.42.0/24:
172.22.42.1 - 172.22.42.3 - subnet routers
172.22.42.4 - 172.22.42.20 - spare for networks
172.22.42.21 - 172.22.42.104 - Compute node remote access controllers
(inc spare)
172.22.42.105 - 172.22.42.188 - Compute node management interfaces (inc spare)
172.22.42.189 - 172.22.42.208 - Swift proxy remote access controllers
(inc spare)
172.22.42.209 - 172.22.42.228 - Swift proxy management interfaces (inc spare)
172.22.42.229 - 172.22.42.252 - Swift storage servers remote access controllers
(inc spare)
172.22.42.253 - 172.22.42.254 - spare
172.22.87.0/26:
172.22.87.1 - 172.22.87.3 - subnet routers
172.22.87.4 - 172.22.87.24 - Swift proxy server internal interfaces
(inc spare)
172.22.87.25 - 172.22.87.63 - Swift object server internal interfaces
(inc spare)</programlisting>
<para>A similar approach can be taken with public IP addresses, taking
note that large, flat ranges are preferred for use with guest instance
IPs. Take into account that for some OpenStack networking options, a
public IP address in the range of a guest instance public IP address is
assigned to the <literal>nova-compute</literal> host.</para>
</section>
<section xml:id="network_topology">
<title>Network Topology</title>
<para>OpenStack Compute with <literal>nova-network</literal> provides
predefined network deployment models, each with its own strengths and
weaknesses. The selection of a network manager changes your network
topology, so the choice should be made carefully. You also have a choice
between the tried-and-true legacy <literal>nova-network</literal> settings
or the <phrase role="keep-together">neutron</phrase> project for OpenStack
Networking. Both offer networking for launched instances with different
implementations and requirements.<indexterm class="singular">
<primary>networks</primary>
<secondary>deployment options</secondary>
</indexterm><indexterm class="singular">
<primary>networks</primary>
<secondary>network managers</secondary>
</indexterm><indexterm class="singular">
<primary>network design</primary>
<secondary>network topology</secondary>
<tertiary>deployment options</tertiary>
</indexterm></para>
<para>For OpenStack Networking with the neutron project, typical
configurations are documented with the idea that any setup you can
configure with real hardware you can re-create with a software-defined
equivalent. Each tenant can contain typical network elements such as
routers, and services such as DHCP.</para>
<para><xref linkend="network_deployment_options" /> describes the
networking deployment options for both legacy
<literal>nova-network</literal> options and an equivalent neutron
configuration.<indexterm class="singular">
<primary>provisioning/deployment</primary>
<secondary>network deployment options</secondary>
</indexterm></para>
<table rules="all" width="500" xml:id="network_deployment_options">
<caption>Networking deployment options</caption>
<col width="19%" />
<col width="23%" />
<col width="24%" />
<col width="34%" />
<thead>
<tr valign="top">
<th>Network deployment model</th>
<th>Strengths</th>
<th>Weaknesses</th>
<th>Neutron equivalent</th>
</tr>
</thead>
<tbody>
<tr valign="top">
<td><para>Flat</para></td>
<td><para>Extremely simple topology.</para> <para>No DHCP
overhead.</para></td>
<td><para>Requires file injection into the instance to configure
network interfaces.</para></td>
<td>Configure a single bridge as the integration bridge (br-int) and
connect it to a physical network interface with the Modular Layer 2
(ML2) plug-in, which uses Open vSwitch by default.</td>
</tr>
<tr valign="top">
<td><para>FlatDHCP</para></td>
<td><para>Relatively simple to deploy.</para> <para>Standard
networking.</para> <para>Works with all guest operating
systems.</para></td>
<td><para>Requires its own DHCP broadcast domain.</para></td>
<td>Configure DHCP agents and routing agents. Network Address
Translation (NAT) performed outside of compute nodes, typically on
one or more network nodes.</td>
</tr>
<tr valign="top">
<td><para>VlanManager</para></td>
<td><para>Each tenant is isolated to its own VLANs.</para></td>
<td><para>More complex to set up.</para> <para>Requires its own DHCP
broadcast domain.</para> <para>Requires many VLANs to be trunked
onto a single port.</para> <para>Standard VLAN number
limitation.</para> <para>Switches must support 802.1q VLAN
tagging.</para></td>
<td><para>Isolated tenant networks implement some form of isolation
of layer 2 traffic between distinct networks. VLAN tagging is key
concept, where traffic is “tagged” with an ordinal identifier for
the VLAN. Isolated network implementations may or may not include
additional services like DHCP, NAT, and routing.</para></td>
</tr>
<tr valign="top">
<td><para>FlatDHCP&#160;Multi-host with high availability
(HA)</para></td>
<td><para>Networking failure is isolated to the VMs running on the
affected hypervisor.</para> <para>DHCP traffic can be isolated
within an individual host.</para> <para>Network traffic is
distributed to the compute nodes.</para></td>
<td><para>More complex to set up.</para> <para>Compute nodes
typically need IP addresses accessible by external networks.</para>
<para>Options must be carefully configured for live migration to
work with networking services.</para></td>
<td><para>Configure neutron with multiple DHCP and layer-3 agents.
Network nodes are not able to failover to each other, so the
controller runs networking services, such as DHCP. Compute nodes run
the ML2 plug-in with support for agents such as Open vSwitch or
Linux Bridge.</para></td>
</tr>
</tbody>
</table>
<para>Both <literal>nova-network</literal> and neutron services provide
similar capabilities, such as VLAN between VMs. You also can provide
multiple NICs on VMs with either service. Further discussion
follows.</para>
<section xml:id="vlans">
<title>VLAN Configuration Within OpenStack VMs</title>
<para>VLAN configuration can be as simple or as complicated as desired.
The use of VLANs has the benefit of allowing each project its own subnet
and broadcast segregation from other projects. To allow OpenStack to
efficiently use VLANs, you must allocate a VLAN range (one for each
project) and turn each compute node switch port into a trunk
port.<indexterm class="singular">
<primary>networks</primary>
<secondary>VLAN</secondary>
</indexterm><indexterm class="singular">
<primary>VLAN network</primary>
</indexterm><indexterm class="singular">
<primary>network design</primary>
<secondary>network topology</secondary>
<tertiary>VLAN with OpenStack VMs</tertiary>
</indexterm></para>
<para>For example, if you estimate that your cloud must support a
maximum of 100 projects, pick a free VLAN range that your network
infrastructure is currently not using (such as VLAN 200–299). You must
configure OpenStack with this range and also configure your switch ports
to allow VLAN traffic from that range.</para>
</section>
<section xml:id="multi_nic">
<title>Multi-NIC Provisioning</title>
<para>OpenStack Networking with <literal>neutron</literal> and
OpenStack Compute with nova-network have the ability to assign
multiple NICs to instances. For nova-network this can be done
on a per-request basis, with each additional NIC using up an
entire subnet or VLAN, reducing the total number of supported
projects.<indexterm class="singular">
<primary>MultiNic</primary>
</indexterm><indexterm class="singular">
<primary>network design</primary>
<secondary>network topology</secondary>
<tertiary>multi-NIC provisioning</tertiary>
</indexterm></para>
</section>
<section xml:id="multi_host_single_host_networks">
<title>Multi-Host and Single-Host Networking</title>
<para>The <literal>nova-network</literal> service has the ability to
operate in a multi-host or single-host mode. Multi-host is when each
compute node runs a copy of <literal>nova-network</literal> and the
instances on that compute node use the compute node as a gateway to the
Internet. The compute nodes also host the floating IPs and security
groups for instances on that node. Single-host is when a central
server—for example, the cloud controller—runs the
<code>nova-network</code> service. All compute nodes forward traffic
from the instances to the cloud controller. The cloud controller then
forwards traffic to the Internet. The cloud controller hosts the
floating IPs and security groups for all instances on all compute nodes
in the cloud.<indexterm class="singular">
<primary>single-host networking</primary>
</indexterm><indexterm class="singular">
<primary>networks</primary>
<secondary>multi-host</secondary>
</indexterm><indexterm class="singular">
<primary>multi-host networking</primary>
</indexterm><indexterm class="singular">
<primary>network design</primary>
<secondary>network topology</secondary>
<tertiary>multi- vs. single-host networking</tertiary>
</indexterm></para>
<para>There are benefits to both modes. Single-node has the downside of
a single point of failure. If the cloud controller is not available,
instances cannot communicate on the network. This is not true with
multi-host, but multi-host requires that each compute node has a public
IP address to communicate on the Internet. If you are not able to obtain
a significant block of public IP addresses, multi-host might not be an
option.</para>
</section>
</section>
<section xml:id="services_for_networking">
<title>Services for Networking</title>
<para>OpenStack, like any network application, has a number of standard
considerations to apply, such as NTP and DNS.<indexterm class="singular">
<primary>network design</primary>
<secondary>services for networking</secondary>
</indexterm></para>
<section xml:id="ntp">
<title>NTP</title>
<para>Time synchronization is a critical element to ensure continued
operation of OpenStack components. Correct time is necessary to avoid
errors in instance scheduling, replication of objects in the object
store, and even matching log timestamps for debugging.<indexterm
class="singular">
<primary>networks</primary>
<secondary>Network Time Protocol (NTP)</secondary>
</indexterm></para>
<para>All servers running OpenStack components should be able to access
an appropriate NTP server. You may decide to set up one locally or use
the public pools available from the <link
xlink:href="http://www.pool.ntp.org/en/"> Network Time Protocol
project</link>.</para>
</section>
<section xml:id="dns">
<title>DNS</title>
<para>OpenStack does not currently provide DNS services, aside from the
dnsmasq daemon, which resides on <code>nova-network</code> hosts. You
could consider providing a dynamic DNS service to allow instances to
update a DNS entry with new IP addresses. You can also consider making a
generic forward and reverse DNS mapping for instances' IP addresses,
such as vm-203-0-113-123.example.com.<indexterm class="singular">
<primary>DNS (Domain Name Server, Service or System)</primary>
<secondary>DNS service choices</secondary>
</indexterm></para>
</section>
</section>
<section xml:id="ops-network-conclusion">
<title>Conclusion</title>
<para>Armed with your IP address layout and numbers and knowledge about
the topologies and services you can use, it's now time to prepare the
network for your installation. Be sure to also check out the <link
xlink:href="http://docs.openstack.org/sec/"
xlink:title="OpenStack Security Guide"><emphasis>OpenStack Security
Guide</emphasis></link> for tips on securing your network. We wish you a
good relationship with your networking team!</para>
</section>
</chapter>

375
doc/openstack-ops/ch_arch_provision.xml
View File

@ -1,375 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter version="5.0" xml:id="section_arch_provision"
xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:ns5="http://www.w3.org/1999/xhtml"
xmlns:ns4="http://www.w3.org/2000/svg"
xmlns:ns3="http://www.w3.org/1998/Math/MathML"
xmlns:ns="http://docbook.org/ns/docbook">
<?dbhtml stop-chunking?>
<title>Provisioning and Deployment</title>
<para>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 Puppet or
Chef. Combined, these systems greatly reduce manual effort and the chance
for operator error.<indexterm class="singular">
<primary>cloud computing</primary>
<secondary>minimizing costs of</secondary>
</indexterm></para>
<para>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).<indexterm class="singular">
<primary>Puppet</primary>
</indexterm><indexterm class="singular">
<primary>Chef</primary>
</indexterm></para>
<section xml:id="automated_deploy">
<title>Automated Deployment</title>
<para>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.<indexterm
class="singular">
<primary>deployment</primary>
<see>provisioning/deployment</see>
</indexterm><indexterm class="singular">
<primary>provisioning/deployment</primary>
<secondary>automated deployment</secondary>
</indexterm></para>
<para>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.</para>
<para>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:</para>
<para><itemizedlist>
<listitem>
<para>Disk partitioning and disk array setup for scalability</para>
</listitem>
<listitem>
<para>Networking configuration just for PXE booting</para>
</listitem>
</itemizedlist></para>
<section xml:id="disk_partition_raid">
<title>Disk Partitioning and RAID</title>
<para>At the very base of any operating system are the hard drives on
which the operating system (OS) is installed.<indexterm class="singular">
<primary>RAID (redundant array of independent disks)</primary>
</indexterm><indexterm class="singular">
<primary>partitions</primary>
<secondary>disk partitioning</secondary>
</indexterm><indexterm class="singular">
<primary>disk partitioning</primary>
</indexterm></para>
<para>You must complete the following configurations on the server's
hard drives:</para>
<itemizedlist role="compact">
<listitem>
<para>Partitioning, which provides greater flexibility for layout of
operating system and swap space, as described below.</para>
</listitem>
<listitem>
<para>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.</para>
</listitem>
</itemizedlist>
<para>The simplest option to get started is to use one hard drive with
two partitions:</para>
<itemizedlist role="compact">
<listitem>
<para>File system to store files and directories, where all the data
lives, including the root partition that starts and runs the
system</para>
</listitem>
<listitem>
<para>Swap space to free up memory for processes, as an independent
area of the physical disk used only for swapping and nothing
else</para>
</listitem>
</itemizedlist>
<para>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.</para>
<para>We recommend that you choose one of the following multiple disk
options:</para>
<variablelist>
<varlistentry>
<term>Option 1</term>
<listitem>
<para>Partition all drives in the same way in a horizontal
fashion, as shown in <xref
linkend="disk_partition_figure" />.</para>
<para>With this option, you can assign different partitions to
different RAID arrays. You can allocate partition 1 of disk one
and two to the <code>/boot</code> partition mirror. You can make
partition 2 of all disks the root partition mirror. You can use
partition 3 of all disks for a <code>cinder-volumes</code> LVM
partition running on a RAID 10 array.</para>
<figure xml:id="disk_partition_figure">
<title>Partition setup of drives</title>
<mediaobject>
<imageobject>
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/osog_0201.png"></imagedata>
</imageobject>
</mediaobject>
</figure>
<para>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.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Option 2</term>
<listitem>
<para>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.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Option 3</term>
<listitem>
<para>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.</para>
</listitem>
</varlistentry>
</variablelist>
<tip>
<para>You may find that you can automate the partitioning itself. For
example, MIT uses <link xlink:href="http://fai-project.org/">Fully
Automatic Installation (FAI)</link> to do the initial PXE-based
partition and then install using a combination of min/max and
percentage-based partitioning.<indexterm class="singular">
<primary>Fully Automatic Installation (FAI)</primary>
</indexterm></para>
</tip>
<para>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&amp;T. This example is from a specific deployment, so
your existing hardware or procurement opportunity may vary from this.
AT&amp;T uses three types of hardware in its deployment:</para>
<itemizedlist>
<listitem>
<para>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.</para>
</listitem>
<listitem>
<para>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.</para>
</listitem>
<listitem>
<para>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.</para>
</listitem>
</itemizedlist>
<para>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.</para>
</section>
<section xml:id="network_config">
<title>Network Configuration</title>
<para>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.<indexterm
class="singular">
<primary>networks</primary>
<secondary>configuration of</secondary>
</indexterm></para>
<para>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.</para>
</section>
</section>
<section xml:id="auto_config">
<title>Automated Configuration</title>
<para>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.<indexterm class="singular">
<primary>automated configuration</primary>
</indexterm><indexterm class="singular">
<primary>provisioning/deployment</primary>
<secondary>automated configuration</secondary>
</indexterm></para>
<para>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 <link
xlink:href="https://wiki.openstack.org/wiki/Puppet">Puppet OpenStack
</link>. Chef configuration management is provided within <link
role="orm:hideurl:ital"
xlink:href="https://git.openstack.org/cgit/openstack/openstack-chef-repo"></link>.
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.
</para>
<para>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.</para>
</section>
<section xml:id="remote_mgmt">
<title>Remote Management</title>
<para>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.<indexterm
class="singular">
<primary>provisioning/deployment</primary>
<secondary>remote management</secondary>
</indexterm></para>
<para>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.</para>
<para>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.</para>
</section>
<section xml:id="provision-deploy-summary">
<title>Parting Thoughts for Provisioning and Deploying OpenStack</title>
<para>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.<indexterm
class="singular">
<primary>provisioning/deployment</primary>
<secondary>tips for</secondary>
</indexterm></para>
<para>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.</para>
<tip>
<para>For further research about OpenStack deployment, investigate the
supported and documented preconfigured, prepackaged installers for
OpenStack from companies such as <link
xlink:href="http://www.ubuntu.com/cloud/ubuntu-openstack">Canonical</link>, <link
xlink:href="http://www.cisco.com/web/solutions/openstack/index.html">Cisco</link>, <link
xlink:href="http://www.cloudscaling.com/">Cloudscaling</link>, <link
xlink:href="http://www-03.ibm.com/software/products/en/smartcloud-orchestrator/">IBM</link>, <link
xlink:href="http://www.metacloud.com/">Metacloud</link>, <link
xlink:href="http://www.mirantis.com/">Mirantis</link>, <link
xlink:href="http://www.pistoncloud.com/">Piston</link>, <link
xlink:href="http://www.rackspace.com/cloud/private/">Rackspace</link>, <link
xlink:href="http://www.redhat.com/openstack/">Red Hat</link>, <link
xlink:href="https://www.suse.com/products/suse-cloud/">SUSE</link>, and <link
xlink:href="https://www.swiftstack.com/">SwiftStack</link>.</para>
</tip>
</section>
<section xml:id="provision_conclusion">
<title>Conclusion</title>
<para>The decisions you make with respect to provisioning and deployment
will affect your day-to-day, week-to-week, and month-to-month 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.</para>
</section>
</chapter>

716
doc/openstack-ops/ch_arch_scaling.xml
View File

@ -1,716 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE chapter [
<!ENTITY % openstack SYSTEM "openstack.ent">
%openstack;
]>
<chapter version="5.0" xml:id="scaling" xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:ns5="http://www.w3.org/2000/svg"
xmlns:ns4="http://www.w3.org/1998/Math/MathML"
xmlns:ns3="http://www.w3.org/1999/xhtml"
xmlns:ns="http://docbook.org/ns/docbook">
<?dbhtml stop-chunking?>
<title>Scaling</title>
<para>Whereas traditional applications required larger hardware to scale
("vertical scaling"), cloud-based applications typically request more,
discrete hardware ("horizontal scaling"). If your cloud is successful,
eventually you must add resources to meet the increasing demand.<indexterm
class="singular">
<primary>scaling</primary>
<secondary>vertical vs. horizontal</secondary>
</indexterm></para>
<para>To suit the cloud paradigm, OpenStack itself is designed to be
horizontally scalable. Rather than switching to larger servers, you procure
more servers and simply install identically configured services. Ideally,
you scale out and load balance among groups of functionally identical
services (for example, compute nodes or <literal>nova-api</literal> nodes),
that communicate on a message bus.</para>
<section xml:id="starting">
<title>The Starting Point</title>
<para>Determining the scalability of your cloud and how to improve it is
an exercise with many variables to balance. 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.<indexterm class="singular">
<primary>virtual machine (VM)</primary>
</indexterm><indexterm class="singular">
<primary>hardware</primary>
<secondary>virtual hardware</secondary>
</indexterm><indexterm class="singular">
<primary>flavor</primary>
</indexterm><indexterm class="singular">
<primary>scaling</primary>
<secondary>metrics for</secondary>
</indexterm></para>
<para>The default OpenStack flavors are shown in <xref
linkend="os-flavors-table" />.</para>
<?hard-pagebreak ?>
<table rules="all" xml:id="os-flavors-table">
<caption>OpenStack default flavors</caption>
<col width="20%" />
<col width="20%" />
<col width="20%" />
<col width="20%" />
<col width="20%" />
<thead>
<tr>
<th align="left">Name</th>
<th align="right">Virtual cores</th>
<th align="right">Memory</th>
<th align="right">Disk</th>
<th align="right">Ephemeral</th>
</tr>
</thead>
<tbody>
<tr>
<td><para>m1.tiny</para></td>
<td align="right"><para>1</para></td>
<td align="right"><para>512 MB</para></td>
<td align="right"><para>1 GB</para></td>
<td align="right"><para>0 GB</para></td>
</tr>
<tr>
<td><para>m1.small</para></td>
<td align="right"><para>1</para></td>
<td align="right"><para>2 GB</para></td>
<td align="right"><para>10 GB</para></td>
<td align="right"><para>20 GB</para></td>
</tr>
<tr>
<td><para>m1.medium</para></td>
<td align="right"><para>2</para></td>
<td align="right"><para>4 GB</para></td>
<td align="right"><para>10 GB</para></td>
<td align="right"><para>40 GB</para></td>
</tr>
<tr>
<td><para>m1.large</para></td>
<td align="right"><para>4</para></td>
<td align="right"><para>8 GB</para></td>
<td align="right"><para>10 GB</para></td>
<td align="right"><para>80 GB</para></td>
</tr>
<tr>
<td><para>m1.xlarge</para></td>
<td align="right"><para>8</para></td>
<td align="right"><para>16 GB</para></td>
<td align="right"><para>10 GB</para></td>
<td align="right"><para>160 GB</para></td>
</tr>
</tbody>
</table>
<para>The starting point for most is the core count of your cloud. By
applying some ratios, you can gather information about: <itemizedlist>
<listitem>
<para>The number of virtual machines (VMs) you expect to run,
<code>((overcommit fraction &times;&#160;cores) / virtual cores per
instance)</code></para>
</listitem>
<listitem>
<para>How much storage is required <code>(flavor disk size
&times;&#160;number of instances)</code></para>
</listitem>
</itemizedlist> You can use these ratios to determine how much
additional infrastructure you need to support your cloud.</para>
<para>Here is an example using the ratios for gathering scalability
information for the number of VMs expected as well as the storage needed.
The following numbers support (200 / 2) &times; 16 = 1600 VM instances and
require 80 TB of storage for <code>/var/lib/nova/instances</code>:</para>
<itemizedlist>
<listitem>
<para>200 physical cores.</para>
</listitem>
<listitem>
<para>Most instances are size m1.medium (two virtual cores, 50 GB of
storage).</para>
</listitem>
<listitem>
<para>Default CPU overcommit ratio (<code>cpu_allocation_ratio</code>
in nova.conf) of 16:1.</para>
</listitem>
</itemizedlist>
<note>
<para>Regardless of the overcommit ratio, an instance can not be placed
on any physical node with fewer raw (pre-overcommit) resources than
instance flavor requires.</para>
</note>
<para>However, you need more than the core count alone to estimate the
load that the API services, database servers, and queue servers are likely
to encounter. You must also consider the usage patterns of your
cloud.</para>
<para>As a specific example, compare a cloud that supports a managed
web-hosting platform with one running integration tests for a development
project that creates one VM per code commit. In the former, the heavy work
of creating a VM happens only every few months, whereas 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.<indexterm class="singular">
<primary>cloud controllers</primary>
<secondary>scalability and</secondary>
</indexterm></para>
<para>Aside from the creation and termination of VMs, you must consider
the impact of users accessing the service—particularly on
<literal>nova-api</literal> and its associated database. Listing instances
garners a great deal of information and, given the frequency with which
users run this operation, a cloud with a large number of users can
increase the load significantly. This can occur even without their
knowledge—leaving the OpenStack dashboard instances tab open in the
browser refreshes the list of VMs every 30 seconds.</para>
<para>After you consider these factors, you can determine how many cloud
controller cores you require. A typical eight core, 8 GB of RAM server is
sufficient for up to a rack of compute nodes —&#160;given the above
caveats.</para>
<para>You must also consider key hardware specifications for the
performance of user VMs, as well as budget and performance needs,
including storage performance (spindles/core), memory availability
(RAM/core), network bandwidth<indexterm class="singular">
<primary>bandwidth</primary>
<secondary>hardware specifications and</secondary>
</indexterm> (Gbps/core), and overall CPU performance (CPU/core).</para>
<tip>
<para>For a discussion of metric tracking, including how to extract
metrics from your cloud, see <xref
linkend="logging_monitoring" />.</para>
</tip>
</section>
<section xml:id="add_controller_nodes">
<title>Adding Cloud Controller Nodes</title>
<para>You can facilitate the horizontal expansion of your cloud by adding
nodes. Adding compute nodes is straightforward—they are easily picked up
by the existing installation. However, you must consider some important
points when you design your cluster to be highly available.<indexterm
class="singular">
<primary>compute nodes</primary>
<secondary>adding</secondary>
</indexterm><indexterm class="singular">
<primary>high availability</primary>
</indexterm><indexterm class="singular">
<primary>configuration options</primary>
<secondary>high availability</secondary>
</indexterm><indexterm class="singular">
<primary>cloud controller nodes</primary>
<secondary>adding</secondary>
</indexterm><indexterm class="singular">
<primary>scaling</primary>
<secondary>adding cloud controller nodes</secondary>
</indexterm></para>
<para>Recall that a cloud controller node runs several different services.
You can install services that communicate only using the message queue
internally—<code>nova-scheduler</code> and <code>nova-console</code>—on a
new server for expansion. However, other integral parts require more
care.</para>
<para>You should load balance user-facing services such as dashboard,
<code>nova-api</code>, or the Object Storage proxy. Use any standard HTTP
load-balancing method (DNS round robin, hardware load balancer, or
software such as Pound or HAProxy). One caveat with dashboard is the VNC
proxy, which uses the WebSocket protocol—something that an L7 load
balancer might struggle with. See also <link
xlink:href="http://docs.openstack.org/developer/horizon/topics/deployment.html#session-storage"
xlink:title="Horizon session storage">Horizon session
storage</link>.</para>
<para>You can configure some services, such as <code>nova-api</code> and
<code>glance-api</code>, to use multiple processes by changing a flag in
their configuration file—allowing them to share work between multiple
cores on the one machine.</para>
<tip>
<para>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
<xref linkend="operations" xrefstyle="part-num-title" />.<indexterm
class="singular">
<primary>Advanced Message Queuing Protocol (AMQP)</primary>
</indexterm></para>
</tip>
</section>
<section xml:id="segregate_cloud">
<title>Segregating Your Cloud</title>
<para>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:
<emphasis>cells</emphasis>, <emphasis>regions</emphasis>,
<emphasis>availability zones</emphasis>, or <emphasis>host
aggregates</emphasis>.<indexterm class="singular">
<primary>segregation methods</primary>
</indexterm><indexterm class="singular">
<primary>scaling</primary>
<secondary>cloud segregation</secondary>
</indexterm></para>
<para>Each method provides different functionality and can be best divided
into two groups:</para>
<itemizedlist>
<listitem>
<para>Cells and regions, which segregate an entire cloud and result in
running separate Compute deployments.</para>
</listitem>
<listitem>
<para><glossterm baseform="availability zone">Availability
zones</glossterm> and host aggregates, which merely divide a single
Compute deployment.</para>
</listitem>
</itemizedlist>
<para><xref linkend="segragation_methods" /> provides a comparison view of
each segregation method currently provided by OpenStack Compute.<indexterm
class="singular">
<primary>endpoints</primary>
<secondary>API endpoint</secondary>
</indexterm></para>
<table rules="all" xml:id="segragation_methods">
<caption>OpenStack segregation methods</caption>
<thead>
<tr>
<th></th>
<th>Cells</th>
<th>Regions</th>
<th>Availability zones</th>
<th>Host aggregates</th>
</tr>
</thead>
<tbody>
<tr>
<td><para><emphasis role="bold">Use when you need</emphasis>
</para></td>
<td><para>A single <glossterm>API endpoint</glossterm> for compute,
or you require a second level of scheduling.</para></td>
<td><para>Discrete regions with separate API endpoints and no
coordination between regions.</para></td>
<td><para>Logical separation within your nova deployment for
physical isolation or redundancy.</para></td>
<td><para>To schedule a group of hosts with common
features.</para></td>
</tr>
<tr>
<td><para><emphasis role="bold">Example</emphasis> </para></td>
<td><para>A cloud with multiple sites where you can schedule VMs
"anywhere" or on a particular site.</para></td>
<td><para>A cloud with multiple sites, where you schedule VMs to a
particular site and you want a shared infrastructure.</para></td>
<td><para>A single-site cloud with equipment fed by separate power
supplies.</para></td>
<td><para>Scheduling to hosts with trusted hardware
support.</para></td>
</tr>
<tr>
<td><para><emphasis role="bold">Overhead</emphasis> </para></td>
<td><para>Considered experimental.</para><para>A new service,
nova-cells.</para><para>Each cell has a full nova installation
except nova-api.</para></td>
<td><para>A different API endpoint for every
region.</para><para>Each region has a full nova installation.
</para></td>
<td><para>Configuration changes to <filename>nova.conf</filename>.</para></td>
<td><para>Configuration changes to <filename>nova.conf</filename>.</para></td>
</tr>
<tr>
<td><para><emphasis role="bold">Shared services</emphasis>
</para></td>
<td><para>Keystone</para><para><code>nova-api</code> </para></td>
<td><para>Keystone</para></td>
<td><para>Keystone</para><para>All nova services</para></td>
<td><para>Keystone</para><para>All nova services</para></td>
</tr>
</tbody>
</table>
<section xml:id="cells_regions">
<title>Cells and Regions</title>
<para>OpenStack Compute cells are designed to allow running the cloud in
a distributed fashion without having to use more complicated
technologies, or be invasive to existing nova installations. Hosts in a
cloud are partitioned into groups called <emphasis>cells</emphasis>.
Cells are configured in a tree. The top-level cell ("API cell") has a
host that runs the <code>nova-api</code> service, but no
<code>nova-compute</code> services. Each child cell runs all of the
other typical <code>nova-*</code> services found in a regular
installation, except for the <code>nova-api</code> service. Each cell
has its own message queue and database service and also runs
<code>nova-cells</code>, which manages the communication between the API
cell and child cells.<indexterm class="singular">
<primary>scaling</primary>
<secondary>cells and regions</secondary>
</indexterm><indexterm class="singular">
<primary>cells</primary>
<secondary>cloud segregation</secondary>
</indexterm><indexterm class="singular">
<primary>region</primary>
</indexterm></para>
<para>This allows for a single API server being used to control access
to multiple cloud installations. Introducing a second level of
scheduling (the cell selection), in addition to the regular
<code>nova-scheduler</code> selection of hosts, provides greater
flexibility to control where virtual machines are run.</para>
<para>Unlike having a single API endpoint, regions have a separate API endpoint
per installation, allowing for a more discrete separation. Users wanting
to run instances across sites have to explicitly select a region.
However, the additional complexity of a running a new service is not
required.</para>
<para>The OpenStack dashboard (horizon) can be configured to use multiple
regions. This can be configured through the <option>AVAILABLE_REGIONS</option> parameter.</para>
</section>
<section xml:id="availability_zones">
<title>Availability Zones and Host Aggregates</title>
<para>You can use availability zones, host aggregates, or both to
partition a nova deployment.<indexterm class="singular">
<primary>scaling</primary>
<secondary>availability zones</secondary>
</indexterm></para>
<para>Availability zones are implemented through and configured in a
similar way to host aggregates.</para>
<para>However, you use them for different reasons.</para>
<section xml:id="az_s3">
<title>Availability zone</title>
<para>This enables you to arrange OpenStack compute hosts into logical
groups and provides a form of physical isolation and redundancy from
other availability zones, such as by using a separate power supply or
network equipment.<indexterm class="singular">
<primary>availability zone</primary>
</indexterm></para>
<para>You define the availability zone in which a specified compute
host resides locally on each server. An availability zone is commonly
used to identify a set of servers that have a common attribute. For
instance, if some of the racks in your data center are on a separate
power source, you can put servers in those racks in their own
availability zone. Availability zones can also help separate different
classes of hardware.</para>
<para>When users provision resources, they can specify from which
availability zone they want their instance to be built. This allows
cloud consumers to ensure that their application resources are spread
across disparate machines to achieve high availability in the event of
hardware failure.</para>
</section>
<section xml:id="ha_s3">
<title>Host aggregates zone</title>
<para>This enables you to partition OpenStack Compute deployments into
logical groups for load balancing and instance distribution. You can
use host aggregates to further partition an availability zone. For
example, you might use host aggregates to partition an availability
zone into groups of hosts that either share common resources, such as
storage and network, or have a special property, such as trusted
computing hardware.<indexterm class="singular">
<primary>scaling</primary>
<secondary>host aggregate</secondary>
</indexterm><indexterm class="singular">
<primary>host aggregate</primary>
</indexterm></para>
<para>A common use of host aggregates is to provide information for
use with the <literal>nova-scheduler</literal>. For example, you might
use a host aggregate to group a set of hosts that share specific
flavors or images.</para>
<para>The general case for this is setting key-value pairs in the
aggregate metadata and matching key-value pairs in flavor's <parameter>extra_specs</parameter>
metadata. The <parameter>AggregateInstanceExtraSpecsFilter</parameter> in
the filter scheduler will enforce that instances be scheduled only on
hosts in aggregates that define the same key to the same value.</para>
<para>An advanced use of this general concept allows different
flavor types to run with different CPU and RAM allocation ratios so
that high-intensity computing loads and low-intensity development and
testing systems can share the same cloud without either starving the
high-use systems or wasting resources on low-utilization systems. This
works by setting <parameter>metadata</parameter> in your host
aggregates and matching <parameter>extra_specs</parameter> in your
flavor types.</para>
<para>The first step is setting the aggregate metadata keys
<parameter>cpu_allocation_ratio</parameter> and
<parameter>ram_allocation_ratio</parameter> to a floating-point
value. The filter schedulers
<parameter>AggregateCoreFilter</parameter> and
<parameter>AggregateRamFilter</parameter> will use those values rather
than the global defaults in <filename>nova.conf</filename> when
scheduling to hosts in the aggregate. It is important to be cautious
when using this feature, since each host can be in multiple aggregates
but should have only one allocation ratio for each resources. It is up
to you to avoid putting a host in multiple aggregates that define
different values for the same <phrase
role="keep-together">resource</phrase>.</para>
<para>This is the first half of the equation. To get flavor types
that are guaranteed a particular ratio, you must set the
<parameter>extra_specs</parameter> in the flavor type to the
key-value pair you want to match in the aggregate. For example, if you
define <parameter>extra_specs</parameter>
<parameter>cpu_allocation_ratio</parameter> to "1.0", then instances
of that type will run in aggregates only where the metadata key
<parameter>cpu_allocation_ratio</parameter> is also defined as "1.0."
In practice, it is better to define an additional key-value pair in
the aggregate metadata to match on rather than match directly on
<parameter>cpu_allocation_ratio</parameter> or
<parameter>core_allocation_ratio</parameter>. This allows better
abstraction. For example, by defining a key
<parameter>overcommit</parameter> and setting a value of "high,"
"medium," or "low," you could then tune the numeric allocation ratios
in the aggregates without also needing to change all flavor types
relating to them.</para>
<note>
<para>Previously, all services had an availability zone. Currently,
only the <literal>nova-compute</literal> service has its own
availability zone. Services such as
<literal>nova-scheduler</literal>, <literal>nova-network</literal>,
and <literal>nova-conductor</literal> have always spanned all
availability zones.</para>
<para>When you run any of the following operations, the services
appear in their own internal availability zone
(CONF.internal_service_availability_zone): <itemizedlist>
<listitem>
<para>nova host-list (os-hosts)</para>
</listitem>
<listitem>
<para>euca-describe-availability-zones verbose</para>
</listitem>
</itemizedlist>The internal availability zone is hidden in
euca-describe-availability_zones (nonverbose).</para>
<para>CONF.node_availability_zone has been renamed to
CONF.default_availability_zone and is used only by the
<literal>nova-api</literal> and <literal>nova-scheduler</literal>
services.</para>
<para>CONF.node_availability_zone still works but is
deprecated.</para>
</note>
</section>
</section>
</section>
<section xml:id="scalable_hardware">
<title>Scalable Hardware</title>
<para>While several resources already exist to help with deploying and
installing OpenStack, it's very important to make sure that you have your
deployment planned out ahead of time. This guide presumes that you have at
least set aside a rack for the OpenStack cloud but also offers suggestions
for when and what to scale.</para>
<section xml:id="hardware_procure">
<title>Hardware Procurement</title>
<para>“The Cloud” has been described as a volatile environment where
servers can be created and terminated at will. While this may be true,
it does not mean that your servers must be volatile. Ensuring that your
cloud's hardware is stable and configured correctly means that your
cloud environment remains up and running. Basically, put effort into
creating a stable hardware environment so that you can host a cloud that
users may treat as unstable and volatile.<indexterm class="singular">
<primary>servers</primary>
<secondary>avoiding volatility in</secondary>
</indexterm><indexterm class="singular">
<primary>hardware</primary>
<secondary>scalability planning</secondary>
</indexterm><indexterm class="singular">
<primary>scaling</primary>
<secondary>hardware procurement</secondary>
</indexterm></para>
<para>OpenStack can be deployed on any hardware supported by an
OpenStack-compatible Linux distribution.</para>
<para>Hardware does not have to be consistent, but it should at least
have the same type of CPU to support instance migration.</para>
<para>The typical hardware recommended for use with OpenStack is the
standard value-for-money offerings that most hardware vendors stock. It
should be straightforward to divide your procurement into building
blocks such as "compute," "object storage," and "cloud controller," and
request as many of these as you need. Alternatively, should you be
unable to spend more, if you have existing servers—provided they meet
your performance requirements and virtualization technology—they are
quite likely to be able to support OpenStack.</para>
</section>
<section xml:id="capacity_planning">
<title>Capacity Planning</title>
<para>OpenStack is designed to increase in size in a straightforward
manner. Taking into account the considerations that we've mentioned in
this chapter—particularly on the sizing of the cloud controller—it
should be possible to procure additional compute or object storage nodes
as needed. New nodes do not need to be the same specification, or even
vendor, as existing nodes.<indexterm class="singular">
<primary>capability</primary>
<secondary>scaling and</secondary>
</indexterm><indexterm class="singular">
<primary>weight</primary>
</indexterm><indexterm class="singular">
<primary>capacity planning</primary>
</indexterm><indexterm class="singular">
<primary>scaling</primary>
<secondary>capacity planning</secondary>
</indexterm></para>
<para>For compute nodes, <code>nova-scheduler</code> will take care of
differences in sizing having to do with core count and RAM amounts;
however, you should consider that the user experience changes with
differing CPU speeds. When adding object storage nodes, a
<glossterm>weight</glossterm> should be specified that reflects the
<glossterm>capability</glossterm> of the node.</para>
<para>Monitoring the resource usage and user growth will enable you to
know when to procure. <xref linkend="logging_monitoring" /> details some
useful metrics.</para>
</section>
<section xml:id="burin_testing">
<title>Burn-in Testing</title>
<para>The chances of failure for the server's hardware are high at the start and the
end of its life. As a result, dealing with hardware
failures 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.<indexterm class="singular">
<primary>testing</primary>
<secondary>burn-in testing</secondary>
</indexterm><indexterm class="singular">
<primary>troubleshooting</primary>
<secondary>burn-in testing</secondary>
</indexterm><indexterm class="singular">
<primary>burn-in testing</primary>
</indexterm><indexterm class="singular">
<primary>scaling</primary>
<secondary>burn-in testing</secondary>
</indexterm></para>
</section>
</section>
</chapter>

955
doc/openstack-ops/ch_arch_storage.xml
View File

@ -1,955 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter version="5.0" xml:id="storage_decision"
xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:ns5="http://www.w3.org/1999/xhtml"
xmlns:ns4="http://www.w3.org/2000/svg"
xmlns:ns3="http://www.w3.org/1998/Math/MathML"
xmlns:ns="http://docbook.org/ns/docbook">
<?dbhtml stop-chunking?>
<title>Storage Decisions</title>
<para>Storage is found in many parts of the OpenStack stack, and the
differing types can cause confusion to even experienced cloud engineers.
This section focuses on persistent storage options you can configure with
your cloud. It's important to understand the distinction between <glossterm
baseform="ephemeral volume"> ephemeral</glossterm> storage and <glossterm
baseform="persistent volume"> persistent</glossterm> storage.</para>
<section xml:id="ephemeral_storage">
<title>Ephemeral Storage</title>
<para>If you deploy only the OpenStack Compute Service (nova), your users
do not have access to any form of persistent storage by default. The disks
associated with VMs are "ephemeral," meaning that (from the user's point
of view) they effectively disappear when a virtual machine is
terminated.<indexterm class="singular">
<primary>storage</primary>
<secondary>ephemeral</secondary>
</indexterm></para>
</section>
<section xml:id="persistent_storage">
<title>Persistent Storage</title>
<para>Persistent storage means that the storage resource outlives any
other resource and is always available, regardless of the state of a
running instance.</para>
<para>Today, OpenStack clouds explicitly support three types of persistent
storage: <emphasis>object storage</emphasis>, <emphasis>block storage</emphasis>,
and <emphasis>file system storage</emphasis>.
<indexterm class="singular">
<primary>swift</primary>
<secondary>Object Storage API</secondary>
</indexterm>
<indexterm class="singular">
<primary>persistent storage</primary>
</indexterm>
<indexterm class="singular">
<primary>objects</primary>
<secondary>persistent storage of</secondary>
</indexterm>
<indexterm class="singular">
<primary>Object Storage</primary>
<secondary>Object Storage API</secondary>
</indexterm>
<indexterm class="singular">
<primary>storage</primary>
<secondary>object storage</secondary>
</indexterm>
<indexterm class="singular">
<primary>shared file system storage</primary>
<secondary>shared file systems service</secondary>
</indexterm>
</para>
<section xml:id="object_storage">
<title>Object Storage</title>
<para>With object storage, users access binary objects through a REST
API. You may be familiar with Amazon S3, which is a well-known example
of an object storage system. Object storage is implemented in OpenStack
by the OpenStack Object Storage (swift) project. If your intended users
need to archive or manage large datasets, you want to provide them with
object storage. In addition, OpenStack can store your virtual <phrase
role="keep-together">machine</phrase> (VM) images inside of an object
storage system, as an alternative to storing the images on a file
system.<indexterm class="singular">
<primary>binary</primary>
<secondary>binary objects</secondary>
</indexterm></para>
<para>OpenStack Object Storage provides a highly scalable, highly
available storage solution by relaxing some of the constraints of
traditional file systems. In designing and procuring for such a cluster,
it is important to understand some key concepts about its operation.
Essentially, this type of storage is built on the idea that all storage
hardware fails, at every level, at some point. Infrequently encountered
failures that would hamstring other storage systems, such as issues
taking down RAID cards or entire servers, are handled gracefully with
OpenStack Object Storage.<indexterm class="singular">
<primary>scaling</primary>
<secondary>Object Storage and</secondary>
</indexterm></para>
<para>A good document describing the Object Storage architecture is
found within <link xlink:href="http://docs.openstack.org/developer/swift/overview_architecture.html"
xlink:title="OpenStack wiki">the developer documentation</link>—read
this first. Once you understand the architecture, you should know what a
proxy server does and how zones work. However, some important points are
often missed at first glance.</para>
<para>When designing your cluster, you must consider durability and
availability. Understand that the predominant source of these is the
spread and placement of your data, rather than the reliability of the
hardware. Consider the default value of the number of replicas, which is
three. This means that before an object is marked as having been
written, at least two copies exist—in case a single server fails to
write, the third copy may or may not yet exist when the write operation
initially returns. Altering this number increases the robustness of your
data, but reduces the amount of storage you have available. Next, look
at the placement of your servers. Consider spreading them widely
throughout your data center's network and power-failure zones. Is a zone
a rack, a server, or a disk?</para>
<para>Object Storage's network patterns might seem unfamiliar at first.
Consider these main traffic flows:
<indexterm class="singular">
<primary>objects</primary>
<secondary>storage decisions and</secondary>
</indexterm>
<indexterm class="singular">
<primary>containers</primary>
<secondary>storage decisions and</secondary>
</indexterm><indexterm class="singular">
<primary>account server</primary>
</indexterm>
<itemizedlist>
<listitem>
<para>Among <glossterm>object</glossterm>,
<glossterm>container</glossterm>, and
<glossterm>account server</glossterm>s</para>
</listitem>
<listitem>
<para>Between those servers and the proxies</para>
</listitem>
<listitem>
<para>Between the proxies and your users</para>
</listitem>
</itemizedlist>
</para>
<para>Object Storage is very "chatty" among servers hosting data—even a
small cluster does megabytes/second of traffic, which is predominantly,
“Do you have the object?”/“Yes I have the object!” Of course, if the
answer to the aforementioned question is negative or the request times
out, replication of the object begins.</para>
<para>Consider the scenario where an entire server fails and 24 TB of
data needs to be transferred "immediately" to remain at three
copies—this can put significant load on the network.</para>
<?hard-pagebreak ?>
<para>Another fact that's often forgotten is that when a new file is
being uploaded, the proxy server must write out as many streams as there
are replicas—giving a multiple of network traffic. For a three-replica
cluster, 10 Gbps in means 30 Gbps out. Combining this with the previous
high bandwidth
<indexterm class="singular">
<primary>bandwidth</primary>
<secondary>private vs. public network recommendations</secondary>
</indexterm> demands of replication is what results in the
recommendation that your private network be of significantly higher
bandwidth than your public need be. Oh, and OpenStack Object Storage
communicates internally with unencrypted, unauthenticated rsync for
performance—you do want the private network to be private.
</para>
<para>The remaining point on bandwidth is the public-facing portion. The
<literal>swift-proxy</literal> service is stateless, which means that
you can easily add more and use HTTP load-balancing methods to share
bandwidth and availability between them.
</para>
<para>More proxies means more bandwidth, if your storage can keep
up.</para>
</section>
<section xml:id="block_storage">
<title>Block Storage</title>
<para>Block storage (sometimes referred to as volume storage) provides
users with access to block-storage devices. Users interact with block
storage by attaching volumes to their running VM instances.<indexterm
class="singular">
<primary>volume storage</primary>
</indexterm><indexterm class="singular">
<primary>block storage</primary>
</indexterm><indexterm class="singular">
<primary>storage</primary>
<secondary>block storage</secondary>
</indexterm></para>
<para>These volumes are persistent: they can be detached from one
instance and re-attached to another, and the data remains intact. Block
storage is implemented in OpenStack by the OpenStack Block Storage
(cinder) project, which supports multiple back ends in the form of
drivers. Your choice of a storage back end must be supported by a Block
Storage driver.</para>
<para>Most block storage drivers allow the instance to have direct
access to the underlying storage hardware's block device. This helps
increase the overall read/write IO. However, support for utilizing files
as volumes is also well established, with full support for NFS,
GlusterFS and others.</para>
<para>These drivers work a little differently than a traditional "block"
storage driver. On an NFS or GlusterFS file system, a single file is
created and then mapped as a "virtual" volume into the instance. This
mapping/translation is similar to how OpenStack utilizes QEMU's
file-based virtual machines stored in
<code>/var/lib/nova/instances</code>.</para>
</section>
<section xml:id="shared_file_system_service">
<title>Shared File Systems Service</title>
<para>
The Shared File Systems service provides a set of services for
management of Shared File Systems in a multi-tenant cloud environment.
Users interact with Shared File Systems service by mounting remote File
Systems on their instances with the following usage of those systems
for file storing and exchange. Shared File Systems service provides you
with shares. A share is a remote, mountable file system. You can mount
a share to and access a share from several hosts by several users at a
time. With shares, user can also:
<itemizedlist>
<listitem>
<para>Create a share specifying its size, shared file system
protocol, visibility level
</para>
</listitem>
<listitem>
<para>
Create a share on either a share server or standalone, depending
on the selected back-end mode, with or without using a share
network.
</para>
</listitem>
<listitem>
<para>Specify access rules and security services for existing
shares.</para>
</listitem>
<listitem>
<para>Combine several shares in groups to keep data consistency
inside the groups for the following safe group operations.</para>
</listitem>
<listitem>
<para>Create a snapshot of a selected share or a share group for
storing the existing shares consistently or creating new shares from
that snapshot in a consistent way</para>
</listitem>
<listitem>
<para>Create a share from a snapshot.</para>
</listitem>
<listitem>
<para>Set rate limits and quotas for specific shares and snapshots</para>
</listitem>
<listitem>
<para>View usage of share resources</para>
</listitem>
<listitem>
<para>Remove shares.</para>
</listitem>
</itemizedlist>
Like Block Storage, the Shared File Systems service is persistent. It
can be:
<itemizedlist>
<listitem>
<para>Mounted to any number of client machines.</para>
</listitem>
<listitem>
<para>Detached from one instance and attached to another without
data loss. During this process the data are safe unless the
Shared File Systems service itself is changed or removed.</para>
</listitem>
</itemizedlist>
Shares are provided by the Shared File Systems service. In OpenStack,
Shared File Systems service is implemented by Shared File System
(manila) project, which supports multiple back-ends in the form of
drivers. The Shared File Systems service can be configured to provision
shares from one or more back-ends. Share servers are, mostly, virtual
machines that export file shares via different protocols such as NFS,
CIFS, GlusterFS, or HDFS.
</para>
</section>
</section>
<section xml:id="storage_concepts">
<title>OpenStack Storage Concepts</title>
<para><xref linkend="openstack_storage" /> explains the different storage
concepts provided by OpenStack.<indexterm class="singular">
<primary>block device</primary>
</indexterm><indexterm class="singular">
<primary>storage</primary>
<secondary>overview of concepts</secondary>
</indexterm></para>
<table rules="all" xml:id="openstack_storage">
<caption>OpenStack storage</caption>
<col width="12%" />
<col width="22%" />
<col width="22%" />
<col width="22%" />
<col width="22%" />
<thead>
<tr>
<th></th>
<th>Ephemeral storage</th>
<th>Block storage</th>
<th>Object storage</th>
<th>Shared File System storage</th>
</tr>
</thead>
<tbody>
<tr>
<td><para>Used to…</para></td>
<td><para>Run operating system and scratch space</para></td>
<td><para>Add additional persistent storage to a virtual machine
(VM)</para></td>
<td><para>Store data, including VM images</para></td>
<td><para>Add additional persistent storage to a virtual machine</para></td>
</tr>
<tr>
<td><para>Accessed through…</para></td>
<td><para>A file system</para></td>
<td><para>A <glossterm>block device</glossterm> that can be
partitioned, formatted, and mounted (such as, /dev/vdc)</para></td>
<td><para>The REST API</para></td>
<td><para>A Shared File Systems service share (either manila
managed or an external one registered in manila) that can be partitioned,
formatted and mounted (such as /dev/vdc)</para></td>
</tr>
<tr>
<td><para>Accessible from…</para></td>
<td><para>Within a VM</para></td>
<td><para>Within a VM</para></td>
<td><para>Anywhere</para></td>
<td><para>Within a VM</para></td>
</tr>
<tr>
<td><para>Managed by…</para></td>
<td><para>OpenStack Compute (nova)</para></td>
<td><para>OpenStack Block Storage (cinder)</para></td>
<td><para>OpenStack Object Storage (swift)</para></td>
<td><para>OpenStack Shared File System Storage (manila)</para></td>
</tr>
<tr>
<td><para>Persists until…</para></td>
<td><para>VM is terminated</para></td>
<td><para>Deleted by user</para></td>
<td><para>Deleted by user</para></td>
<td><para>Deleted by user</para></td>
</tr>
<tr>
<td><para>Sizing determined by…</para></td>
<td><para>Administrator configuration of size settings, known as
<emphasis>flavors</emphasis> </para></td>
<td><para>User specification in initial request</para></td>
<td><para>Amount of available physical storage</para></td>
<td>
<para>
<itemizedlist>
<listitem>
<para>
User specification in initial request
</para>
</listitem>
<listitem>
<para>
Requests for extension
</para>
</listitem>
<listitem>
<para>
Available user-level quotes
</para>
</listitem>
<listitem>
<para>
Limitations applied by Administrator
</para>
</listitem>
</itemizedlist>
</para>
</td>
</tr>
<tr>
<td><para>Encryption set by…</para></td>
<td><para>Parameter in nova.conf</para></td>
<td><para>Admin establishing
<link xlink:href="http://docs.openstack.org/admin-guide/dashboard_manage_volumes.html">encrypted volume type</link>,
then user selecting encrypted volume</para></td>
<td><para>Not yet available</para></td>
<td><para>Shared File Systems service does not apply any additional
encryption above what the share’s back-end storage provides</para></td>
</tr>
<tr>
<td><para>Example of typical usage…</para></td>
<td><para>10 GB first disk, 30 GB second disk</para></td>
<td><para>1 TB disk</para></td>
<td><para>10s of TBs of dataset storage</para></td>
<td><para>Depends completely on the size of back-end storage specified when
a share was being created. In case of thin provisioning it can be partial
space reservation (for more details see <link xlink:href="http://docs.openstack.org/developer/manila/devref/capabilities_and_extra_specs.html?highlight=extra%20specs#common-capabilities">Capabilities and Extra-Specs</link> specification)</para></td>
</tr>
</tbody>
</table>
<sidebar>
<title>File-level Storage (for Live Migration)</title>
<para>With file-level storage, users access stored data using the
operating system's file system interface. Most users, if they have used
a network storage solution before, have encountered this form of
networked storage. In the Unix world, the most common form of this is
NFS. In the Windows world, the most common form is called CIFS
(previously, SMB).<indexterm class="singular">
<primary>migration</primary>
</indexterm><indexterm class="singular">
<primary>live migration</primary>
</indexterm><indexterm class="singular">
<primary>storage</primary>
<secondary>file-level</secondary>
</indexterm></para>
<para>OpenStack clouds do not present file-level storage to end users.
However, it is important to consider file-level storage for storing
instances under <code>/var/lib/nova/instances</code> when designing your
cloud, since you must have a shared file system if you want to support
live migration.</para>
</sidebar>
</section>
<section xml:id="storage_backends">
<title>Choosing Storage Back Ends</title>
<para>Users will indicate different needs for their cloud use cases. Some
may need fast access to many objects that do not change often, or want to
set a time-to-live (TTL) value on a file. Others may access only storage
that is mounted with the file system itself, but want it to be replicated
instantly when starting a new instance. For other systems, ephemeral
storage—storage that is released when a VM attached to it is shut down— is
the preferred way. When you select <glossterm>storage
back end</glossterm>s, <indexterm class="singular">
<primary>storage</primary>
<secondary>choosing back ends</secondary>
</indexterm><indexterm class="singular">
<primary>storage back end</primary>
</indexterm><indexterm class="singular">
<primary>back end interactions</primary>
<secondary>store</secondary>
</indexterm>ask the following questions on behalf of your users:</para>
<itemizedlist role="compact">
<listitem>
<para>Do my users need block storage?</para>
</listitem>
<listitem>
<para>Do my users need object storage?</para>
</listitem>
<listitem>
<para>Do I need to support live migration?</para>
</listitem>
<listitem>
<para>Should my persistent storage drives be contained in my compute
nodes, or should I use external storage?</para>
</listitem>
<listitem>
<para>What is the platter count I can achieve? Do more spindles result
in better I/O despite network access?</para>
</listitem>
<listitem>
<para>Which one results in the best cost-performance scenario I'm
aiming for?</para>
</listitem>
<listitem>
<para>How do I manage the storage operationally?</para>
</listitem>
<listitem>
<para>How redundant and distributed is the storage? What happens if a
storage node fails? To what extent can it mitigate my data-loss
disaster scenarios?</para>
</listitem>
</itemizedlist>
<para>To deploy your storage by using only commodity hardware, you can use
a number of open-source packages, as shown in <xref
linkend="storage_solutions" />.</para>
<table rules="all" xml:id="storage_solutions" role="resize">
<caption>Persistent file-based storage support</caption>
<thead>
<tr>
<th>&#160;</th>
<th>Object</th>
<th>Block</th>
<th>File-level<footnote>
<para>This list of open source file-level shared storage
solutions is not exhaustive; other open source solutions exist
(MooseFS). Your organization may already have deployed a
file-level shared storage solution that you can use.</para>
</footnote></th>
</tr>
</thead>
<tbody>
<tr>
<td><para>Swift</para></td>
<td><para><inlinemediaobject>
<imageobject>
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/Check_mark_23x20_02.png"
format="PNG"></imagedata>
</imageobject>
</inlinemediaobject></para></td>
<td><para></para></td>
<td><para>&#160;</para></td>
</tr>
<tr>
<td><para>LVM</para></td>
<td><para>&#160;</para></td>
<td><para><inlinemediaobject>
<imageobject>
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/Check_mark_23x20_02.png"
format="PNG"></imagedata>
</imageobject>
</inlinemediaobject></para></td>
<td><para>&#160;</para></td>
</tr>
<tr>
<td><para>Ceph</para></td>
<td><para><inlinemediaobject>
<imageobject>
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/Check_mark_23x20_02.png"
format="PNG"></imagedata>
</imageobject>
</inlinemediaobject></para></td>
<td><para><inlinemediaobject>
<imageobject>
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/Check_mark_23x20_02.png"
format="PNG"></imagedata>
</imageobject>
</inlinemediaobject></para></td>
<td><para>Experimental</para></td>
</tr>
<tr>
<td><para>Gluster</para></td>
<td><para><inlinemediaobject>
<imageobject>
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/Check_mark_23x20_02.png"
format="PNG"></imagedata>
</imageobject>
</inlinemediaobject></para></td>
<td><para><inlinemediaobject>
<imageobject>
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/Check_mark_23x20_02.png"
format="PNG"></imagedata>
</imageobject>
</inlinemediaobject></para></td>
<td><para><inlinemediaobject>
<imageobject>
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/Check_mark_23x20_02.png"
format="PNG"></imagedata>
</imageobject>
</inlinemediaobject></para></td>
</tr>
<tr>
<td><para>NFS</para></td>
<td><para></para></td>
<td><para><inlinemediaobject>
<imageobject>
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/Check_mark_23x20_02.png"
format="PNG"></imagedata>
</imageobject>
</inlinemediaobject></para></td>
<td><para><inlinemediaobject>
<imageobject>
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/Check_mark_23x20_02.png"
format="PNG"></imagedata>
</imageobject>
</inlinemediaobject></para></td>
</tr>
<tr>
<td><para>ZFS</para></td>
<td><para>&#160;</para></td>
<td><para><inlinemediaobject>
<imageobject>
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/Check_mark_23x20_02.png"
format="PNG"></imagedata>
</imageobject>
</inlinemediaobject></para></td>
<td><para>&#160;</para></td>
</tr>
<tr>
<td><para>Sheepdog</para></td>
<td><para><inlinemediaobject>
<imageobject>
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/Check_mark_23x20_02.png"
format="PNG"></imagedata>
</imageobject>
</inlinemediaobject></para></td>
<td><para><inlinemediaobject>
<imageobject>
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/Check_mark_23x20_02.png"
format="PNG"></imagedata>
</imageobject>
</inlinemediaobject></para></td>
<td><para> </para></td>
</tr>
</tbody>
</table>
<sidebar>
<title>Storage Driver Support</title>
<para>In addition to the open source technologies, there are a number of
proprietary solutions that are officially supported by OpenStack Block
Storage.<indexterm class="singular">
<primary>storage</primary>
<secondary>storage driver support</secondary>
</indexterm> They are offered by the following vendors:</para>
<itemizedlist role="compact">
<listitem>
<para>IBM (Storwize family/SVC, XIV)</para>
</listitem>
<listitem>
<para>NetApp</para>
</listitem>
<listitem>
<para>Nexenta</para>
</listitem>
<listitem>
<para>SolidFire</para>
</listitem>
</itemizedlist>
<para>You can find a matrix of the functionality provided by all of the
supported Block Storage drivers on the <link
xlink:href="https://wiki.openstack.org/wiki/CinderSupportMatrix"
xlink:title="OpenStack wiki">OpenStack wiki</link>.</para>
</sidebar>
<para>Also, you need to decide whether you want to support object storage
in your cloud. The two common use cases for providing object storage in a
compute cloud are:</para>
<itemizedlist role="compact">
<listitem>
<para>To provide users with a persistent storage mechanism</para>
</listitem>
<listitem>
<para>As a scalable, reliable data store for virtual machine
images</para>
</listitem>
</itemizedlist>
<section xml:id="commodity_storage_backends">
<title>Commodity Storage Back-end Technologies</title>
<para>This section provides a high-level overview of the differences
among the different commodity storage back end technologies. Depending on
your cloud user's needs, you can implement one or many of these
technologies in different combinations:<indexterm class="singular">
<primary>storage</primary>
<secondary>commodity storage</secondary>
</indexterm></para>
<variablelist>
<varlistentry>
<term>OpenStack Object Storage (swift)</term>
<listitem>
<para>The official OpenStack Object Store implementation. It is a
mature technology that has been used for several years in
production by Rackspace as the technology behind Rackspace Cloud
Files. As it is highly scalable, it is well-suited to managing
petabytes of storage. OpenStack Object Storage's advantages are
better <phrase role="keep-together">integration</phrase> with
OpenStack (integrates with OpenStack Identity, works with the
OpenStack dashboard interface) and better support for multiple
data center deployment through support of asynchronous eventual
consistency replication.</para>
<para>Therefore, if you eventually plan on distributing your
storage cluster across multiple data centers, if you need unified
accounts for your users for both compute and object storage, or if
you want to control your object storage with the OpenStack
dashboard, you should consider OpenStack Object Storage. More
detail can be found about OpenStack Object Storage in the section
below.<indexterm class="singular">
<primary>accounts</primary>
</indexterm></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Ceph<indexterm class="singular">
<primary>Ceph</primary>
</indexterm></term>
<listitem>
<para>A scalable storage solution that replicates data across
commodity storage nodes. Ceph was originally developed by one of
the founders of DreamHost and is currently used in production
there.</para>
<para>Ceph was designed to expose different types of storage
interfaces to the end user: it supports object storage, block
storage, and file-system interfaces, although the file-system
interface is not yet considered production-ready. Ceph supports
the same API as swift for object storage and can be used as a
back end for cinder block storage as well as back-end storage for
glance images. Ceph supports "thin provisioning," implemented
using copy-on-write.</para>
<para>This can be useful when booting from volume because a new
volume can be provisioned very quickly. Ceph also supports
keystone-based authentication (as of version 0.56), so it can be a
seamless swap in for the default OpenStack swift
implementation.</para>
<para>Ceph's advantages are that it gives the administrator more
fine-grained control over data distribution and replication
strategies, enables you to consolidate your object and block
storage, enables very fast provisioning of boot-from-volume
instances using thin provisioning, and supports a distributed
file-system interface, though this interface is <link
xlink:href="http://ceph.com/docs/master/cephfs/"
xlink:title="OpenStack wiki">not yet recommended</link> for use in
production deployment by the Ceph project.</para>
<para>If you want to manage your object and block storage within a
single system, or if you want to support fast boot-from-volume,
you should consider Ceph.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Gluster<indexterm class="singular">
<primary>GlusterFS</primary>
</indexterm></term>
<listitem>
<para>A distributed, shared file system. As of Gluster version
3.3, you can use Gluster to consolidate your object storage and
file storage into one unified file and object storage solution,
which is called Gluster For OpenStack (GFO). GFO uses a customized
version of swift that enables Gluster to be used as the back-end
storage.</para>
<para>The main reason to use GFO rather than regular swift is if
you also want to support a distributed file system, either to
support shared storage live migration or to provide it as a
separate service to your end users. If you want to manage your
object and file storage within a single system, you should
consider GFO.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>LVM<indexterm class="singular">
<primary>LVM (Logical Volume Manager)</primary>
</indexterm></term>
<listitem>
<para>The Logical Volume Manager is a Linux-based system that
provides an abstraction layer on top of physical disks to expose
logical volumes to the operating system. The LVM back-end
implements block storage as LVM logical partitions.</para>
<para>On each host that will house block storage, an administrator
must initially create a volume group dedicated to Block Storage
volumes. Blocks are created from LVM logical volumes.</para>
<note>
<para>LVM does <emphasis>not</emphasis> provide any replication.
Typically, administrators configure RAID on nodes that use LVM
as block storage to protect against failures of individual hard
drives. However, RAID does not protect against a failure of the
entire host.</para>
</note>
</listitem>
</varlistentry>
<varlistentry>
<term>ZFS<indexterm class="singular">
<primary>ZFS</primary>
</indexterm></term>
<listitem>
<para>The Solaris iSCSI driver for OpenStack Block Storage
implements blocks as ZFS entities. ZFS is a file system that also
has the functionality of a volume manager. This is unlike on a
Linux system, where there is a separation of volume manager (LVM)
and file system (such as, ext3, ext4, xfs, and btrfs). ZFS has a
number of advantages over ext4, including improved data-integrity
checking.</para>
<para>The ZFS back end for OpenStack Block Storage supports only
Solaris-based systems, such as Illumos. While there is a Linux
port of ZFS, it is not included in any of the standard Linux
distributions, and it has not been tested with OpenStack Block
Storage. As with LVM, ZFS does not provide replication across
hosts on its own; you need to add a replication solution on top of
ZFS if your cloud needs to be able to handle storage-node
failures.</para>
<para>We don't recommend ZFS unless you have previous experience
with deploying it, since the ZFS back end for Block Storage
requires a Solaris-based operating system, and we assume that your
experience is primarily with Linux-based systems.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Sheepdog<indexterm class="singular">
<primary>Sheepdog</primary>
</indexterm></term>
<listitem>
<para>Sheepdog is a userspace distributed storage system. Sheepdog scales
to several hundred nodes, and has powerful virtual disk management features
like snapshot, cloning, rollback, thin provisioning.</para>
<para>It is essentially an object storage system that manages disks and aggregates
the space and performance of disks linearly in hyper scale on commodity hardware in
a smart way. On top of its object store, Sheepdog provides elastic volume service
and http service. Sheepdog does not assume anything about kernel version and can
work nicely with xattr-supported file systems.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>
<section xml:id="storagedecisions_conclusion">
<title>Conclusion</title>
<para>We hope that you now have some considerations in mind and questions
to ask your future cloud users about their storage use cases. As you can
see, your storage decisions will also influence your network design for
performance and security needs. Continue with us to make more informed
decisions about your OpenStack cloud <phrase
role="keep-together">design</phrase>.</para>
</section>
</chapter>

266
doc/openstack-ops/ch_ops_advanced_configuration.xml
View File

@ -1,266 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter version="5.0" xml:id="advanced_configuration"
xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:ns5="http://www.w3.org/1999/xhtml"
xmlns:ns4="http://www.w3.org/2000/svg"
xmlns:ns3="http://www.w3.org/1998/Math/MathML"
xmlns:ns="http://docbook.org/ns/docbook">
<?dbhtml stop-chunking?>
<title>Advanced Configuration</title>
<para>OpenStack is intended to work well across a variety of installation
flavors, from very small private clouds to large public clouds. To achieve
this, the developers add configuration options to their code that allow the
behavior of the various components to be tweaked depending on your needs.
Unfortunately, it is not possible to cover all possible deployments with the
default configuration values.<indexterm class="singular">
<primary>advanced configuration</primary>
<see>configuration options</see>
</indexterm><indexterm class="singular">
<primary>configuration options</primary>
<secondary>wide availability of</secondary>
</indexterm></para>
<para>At the time of writing, OpenStack has more than 3,000 configuration
options. You can see them documented at <link
xlink:href="http://docs.openstack.org/liberty/config-reference/content/config_overview.html">the OpenStack configuration reference
guide</link>. This chapter cannot hope to document all of these, but we do
try to introduce the important concepts so that you know where to go digging
for more information.</para>
<section xml:id="driver_differences">
<title>Differences Between Various Drivers</title>
<para>Many OpenStack projects implement a driver layer, and each of these
drivers will implement its own configuration options. For example, in
OpenStack Compute (nova), there are various hypervisor drivers
implemented—libvirt, xenserver, hyper-v, and vmware, for example. Not all
of these hypervisor drivers have the same features, and each has different
tuning requirements.<indexterm class="singular">
<primary>hypervisors</primary>
<secondary>differences between</secondary>
</indexterm><indexterm class="singular">
<primary>drivers</primary>
<secondary>differences between</secondary>
</indexterm></para>
<note>
<para>The currently implemented hypervisors are listed on <link
xlink:href="http://docs.openstack.org/liberty/config-reference/content/section_compute-hypervisors.html">the OpenStack documentation
website</link>. You can see a matrix of the various features in
OpenStack Compute (nova) hypervisor drivers on the OpenStack wiki at
<link xlink:href="http://docs.openstack.org/developer/nova/support-matrix.html">the Hypervisor support matrix
page</link>.</para>
</note>
<para>The point we are trying to make here is that just because an option
exists doesn't mean that option is relevant to your driver choices.
Normally, the documentation notes which drivers the configuration applies
to.</para>
</section>
<section xml:id="periodic_tasks">
<title>Implementing Periodic Tasks</title>
<para>Another common concept across various OpenStack projects is that of
periodic tasks. Periodic tasks are much like cron jobs on traditional Unix
systems, but they are run inside an OpenStack process. For example, when
OpenStack Compute (nova) needs to work out what images it can remove from
its local cache, it runs a periodic task to do this.<indexterm
class="singular">
<primary>periodic tasks</primary>
</indexterm><indexterm class="singular">
<primary>configuration options</primary>
<secondary>periodic task implementation</secondary>
</indexterm></para>
<para>Periodic tasks are important to understand because of limitations in
the threading model that OpenStack uses. OpenStack uses cooperative
threading in Python, which means that if something long and complicated is
running, it will block other tasks inside that process from running unless
it voluntarily yields execution to another cooperative thread.<indexterm
class="singular">
<primary>cooperative threading</primary>
</indexterm></para>
<para>A tangible example of this is the <literal>nova-compute</literal>
process. In order to manage the image cache with libvirt,
<literal>nova-compute</literal> has a periodic process that scans the
contents of the image cache. Part of this scan is calculating a checksum
for each of the images and making sure that checksum matches what
<literal>nova-compute</literal> expects it to be. However, images can be
very large, and these checksums can take a long time to generate. At one
point, before it was reported as a bug and fixed,
<literal>nova-compute</literal> would block on this task and stop
responding to RPC requests. This was visible to users as failure of
operations such as spawning or deleting instances.</para>
<para>The take away from this is if you observe an OpenStack process that
appears to "stop" for a while and then continue to process normally, you
should check that periodic tasks aren't the problem. One way to do this is
to disable the periodic tasks by setting their interval to zero.
Additionally, you can configure how often these periodic tasks run—in some
cases, it might make sense to run them at a different frequency from the
default.</para>
<para>The frequency is defined separately for each periodic task.
Therefore, to disable every periodic task in OpenStack Compute (nova), you
would need to set a number of configuration options to zero. The current
list of configuration options you would need to set to zero are:</para>
<itemizedlist>
<listitem>
<para><literal>bandwidth_poll_interval</literal></para>
</listitem>
<listitem>
<para><literal>sync_power_state_interval</literal></para>
</listitem>
<listitem>
<para><literal>heal_instance_info_cache_interval</literal></para>
</listitem>
<listitem>
<para><literal>host_state_interval</literal></para>
</listitem>
<listitem>
<para><literal>image_cache_manager_interval</literal></para>
</listitem>
<listitem>
<para><literal>reclaim_instance_interval</literal></para>
</listitem>
<listitem>
<para><literal>volume_usage_poll_interval</literal></para>
</listitem>
<listitem>
<para><literal>shelved_poll_interval</literal></para>
</listitem>
<listitem>
<para><literal>shelved_offload_time</literal></para>
</listitem>
<listitem>
<para><literal>instance_delete_interval</literal></para>
</listitem>
</itemizedlist>
<para>To set a configuration option to zero, include a line such as
<literal>image_cache_manager_interval=0</literal> in your
<filename>nova.conf</filename> file.</para>
<para>This list will change between releases, so please refer to your
configuration guide for up-to-date information.</para>
</section>
<section xml:id="specific-advanced-config-topics">
<title>Specific Configuration Topics</title>
<para>This section covers specific examples of configuration options you
might consider tuning. It is by no means an exhaustive list.</para>
<section xml:id="adv-config-security">
<title>Security Configuration for Compute, Networking, and
Storage</title>
<para>The <emphasis><link xlink:href="http://docs.openstack.org/sec/">OpenStack
Security Guide</link></emphasis> provides a deep dive into securing an
OpenStack cloud, including SSL/TLS, key management, PKI and certificate
management, data transport and privacy concerns, and
compliance.<indexterm class="singular">
<primary>security issues</primary>
<secondary>configuration options</secondary>
</indexterm><indexterm class="singular">
<primary>configuration options</primary>
<secondary>security</secondary>
</indexterm></para>
</section>
<section xml:id="adv-config-ha">
<title>High Availability</title>
<para>The <emphasis><link
xlink:href="http://docs.openstack.org/ha-guide/index.html">OpenStack High Availability
Guide</link></emphasis> offers suggestions for elimination of a single
point of failure that could cause system downtime. While it is not a
completely prescriptive document, it offers methods and techniques for
avoiding downtime and data loss.<indexterm class="singular">
<primary>high availability</primary>
</indexterm><indexterm class="singular">
<primary>configuration options</primary>
<secondary>high availability</secondary>
</indexterm></para>
</section>
<section xml:id="adv-config-ipv6">
<title>Enabling IPv6 Support</title>
<para>You can follow the progress being made on IPV6 support by
watching the <link xlink:href="https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam">neutron IPv6
Subteam at work</link>.<indexterm class="singular">
<primary>Liberty</primary>
<secondary>IPv6 support</secondary>
</indexterm><indexterm class="singular">
<primary>IPv6, enabling support for</primary>
</indexterm><indexterm class="singular">
<primary>configuration options</primary>
<secondary>IPv6 support</secondary>
</indexterm></para>
<para>By modifying your configuration setup, you can set up IPv6 when
using <literal>nova-network</literal> for networking, and a tested setup
is documented for FlatDHCP and a multi-host configuration. The key is to
make <literal>nova-network</literal> think a <literal>radvd</literal>
command ran successfully. The entire configuration is detailed in a
Cybera blog post, <link xlink:href="http://www.cybera.ca/news-and-events/tech-radar/an-ipv6-enabled-cloud/">“An IPv6
enabled cloud”</link>.</para>
</section>
<section xml:id="adv-config-geography">
<title>Geographical Considerations for Object Storage</title>
<para>Support for global clustering of object storage servers
is available for all supported releases. You would implement these global
clusters to ensure replication across geographic areas in case of a
natural disaster and also to ensure that users can write or access their
objects more quickly based on the closest data center. You configure a
default region with one zone for each cluster, but be sure your network
(WAN) can handle the additional request and response load between
zones as you add more zones and build a ring that handles more zones.
Refer to <link
xlink:href="http://docs.openstack.org/developer/swift/admin_guide.html#geographically-distributed-clusters">Geographically Distributed
Clusters</link> in the documentation for additional
information.<indexterm class="singular">
<primary>Object Storage</primary>
<secondary>geographical considerations</secondary>
</indexterm><indexterm class="singular">
<primary>storage</primary>
<secondary>geographical considerations</secondary>
</indexterm><indexterm class="singular">
<primary>configuration options</primary>
<secondary>geographical storage considerations</secondary>
</indexterm></para>
</section>
</section>
</chapter>

289
doc/openstack-ops/ch_ops_backup_recovery.xml
View File

@ -1,289 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter version="5.0" xml:id="backup_and_recovery"
xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:ns5="http://www.w3.org/1999/xhtml"
xmlns:ns4="http://www.w3.org/1998/Math/MathML"
xmlns:ns3="http://www.w3.org/2000/svg"
xmlns:ns="http://docbook.org/ns/docbook">
<?dbhtml stop-chunking?>
<title>Backup and Recovery</title>
<para>Standard backup best practices apply when creating your OpenStack
backup policy. For example, how often to back up your data is closely
related to how quickly you need to recover from data loss.<indexterm
class="singular">
<primary>backup/recovery</primary>
<secondary>considerations</secondary>
</indexterm></para>
<note>
<para>If you cannot have any data loss at all, you should also focus on a
highly available deployment. The <emphasis><link
xlink:href="http://docs.openstack.org/ha-guide/index.html">OpenStack High Availability
Guide</link></emphasis> offers suggestions for elimination of a single
point of failure that could cause system downtime. While it is not a
completely prescriptive document, it offers methods and techniques for
avoiding downtime and data loss.<indexterm class="singular">
<primary>data</primary>
<secondary>preventing loss of</secondary>
</indexterm></para>
</note>
<para>Other backup considerations include:</para>
<itemizedlist>
<listitem>
<para>How many backups to keep?</para>
</listitem>
<listitem>
<para>Should backups be kept off-site?</para>
</listitem>
<listitem>
<para>How often should backups be tested?</para>
</listitem>
</itemizedlist>
<para>Just as important as a backup policy is a recovery policy (or at least
recovery testing).</para>
<section xml:id="what_to_backup">
<title>What to Back Up</title>
<para>While OpenStack is composed of many components and moving parts,
backing up the critical data is quite simple.<indexterm class="singular">
<primary>backup/recovery</primary>
<secondary>items included</secondary>
</indexterm></para>
<para>This chapter describes only how to back up configuration files and
databases that the various OpenStack components need to run. This chapter
does not describe how to back up objects inside Object Storage or data
contained inside Block Storage. Generally these areas are left for users
to back up on their own.</para>
</section>
<section xml:id="database_backups">
<title>Database Backups</title>
<para>The example OpenStack architecture designates the cloud controller
as the MySQL server. This MySQL server hosts the databases for nova,
glance, cinder, and keystone. With all of these databases in one place,
it's very easy to create a database backup:<indexterm class="singular">
<primary>databases</primary>
<secondary>backup/recovery of</secondary>
</indexterm><indexterm class="singular">
<primary>backup/recovery</primary>
<secondary>databases</secondary>
</indexterm></para>
<programlisting language="bash"><?db-font-size 75%?><prompt>#</prompt> mysqldump --opt --all-databases &gt; openstack.sql</programlisting>
<para>If you only want to backup a single database, you can instead
run:</para>
<programlisting language="bash"><?db-font-size 75%?><prompt>#</prompt> mysqldump --opt nova &gt; nova.sql</programlisting>
<para>where <code>nova</code> is the database you want to back up.</para>
<para>You can easily automate this process by creating a cron job that
runs the following script once per day:</para>
<programlisting language="bash"><?db-font-size 65%?><prompt>#</prompt>!/bin/bash
backup_dir="/var/lib/backups/mysql"
filename="${backup_dir}/mysql-`hostname`-`eval date +%Y%m%d`.sql.gz"
# Dump the entire MySQL database
/usr/bin/mysqldump --opt --all-databases | gzip &gt; $filename
# Delete backups older than 7 days
find $backup_dir -ctime +7 -type f -delete</programlisting>
<para>This script dumps the entire MySQL database and deletes any backups
older than seven days.</para>
</section>
<section xml:id="file_system_backups">
<title>File System Backups</title>
<para>This section discusses which files and directories should be backed
up regularly, organized by service.<indexterm class="singular">
<primary>file systems</primary>
<secondary>backup/recovery of</secondary>
</indexterm><indexterm class="singular">
<primary>backup/recovery</primary>
<secondary>file systems</secondary>
</indexterm></para>
<section xml:id="compute">
<title>Compute</title>
<para>The <filename>/etc/nova</filename> directory on both the cloud
controller and compute nodes should be regularly backed up.<indexterm
class="singular">
<primary>cloud controllers</primary>
<secondary>file system backups and</secondary>
</indexterm><indexterm class="singular">
<primary>compute nodes</primary>
<secondary>backup/recovery of</secondary>
</indexterm></para>
<para><code>/var/log/nova</code> does not need to be backed up if you
have all logs going to a central area. It is highly recommended to use a
central logging server or back up the log directory.</para>
<para><code>/var/lib/nova</code> is another important directory to back
up. The exception to this is the <code>/var/lib/nova/instances</code>
subdirectory on compute nodes. This subdirectory contains the KVM images
of running instances. You would want to back up this directory only if
you need to maintain backup copies of all instances. Under most
circumstances, you do not need to do this, but this can vary from cloud
to cloud and your service levels. Also be aware that making a backup of
a live KVM instance can cause that instance to not boot properly if it
is ever restored from a backup.</para>
</section>
<section xml:id="image_catalog_delivery">
<title>Image Catalog and Delivery</title>
<para><code>/etc/glance</code> and <code>/var/log/glance</code> follow
the same rules as their nova counterparts.<indexterm class="singular">
<primary>Image service</primary>
<secondary>backup/recovery of</secondary>
</indexterm></para>
<para><code>/var/lib/glance</code> should also be backed up. Take
special notice of <code>/var/lib/glance/images</code>. If you are using
a file-based back end of glance, <code>/var/lib/glance/images</code> is
where the images are stored and care should be taken.</para>
<para>There are two ways to ensure stability with this directory. The
first is to make sure this directory is run on a RAID array. If a disk
fails, the directory is available. The second way is to use a tool such
as rsync to replicate the images to another server:</para>
<programlisting># rsync -az --progress /var/lib/glance/images \
backup-server:/var/lib/glance/images/</programlisting>
</section>
<section xml:id="identity">
<title>Identity</title>
<para><code>/etc/keystone</code> and <code>/var/log/keystone</code>
follow the same rules as other components.<indexterm class="singular">
<primary>Identity</primary>
<secondary>backup/recovery</secondary>
</indexterm></para>
<para><code>/var/lib/keystone</code>, although it should not contain any
data being used, can also be backed up just in case.</para>
</section>
<section xml:id="ops_block_storage">
<title>Block Storage</title>
<para><code>/etc/cinder</code> and <code>/var/log/cinder</code> follow
the same rules as other components.<indexterm class="singular">
<primary>Block Storage</primary>
</indexterm><indexterm class="singular">
<primary>storage</primary>
<secondary>block storage</secondary>
</indexterm></para>
<para><code>/var/lib/cinder</code> should also be backed up.</para>
</section>
<section xml:id="ops_object_storage">
<title>Object Storage</title>
<para><code>/etc/swift</code> is very important to have backed up. This
directory contains the swift configuration files as well as the ring
files and ring <glossterm>builder file</glossterm>s, which if lost,
render the data on your cluster inaccessible. A best practice is to copy
the builder files to all storage nodes along with the ring files.
Multiple backup copies are spread throughout your storage
cluster.<indexterm class="singular">
<primary>builder files</primary>
</indexterm><indexterm class="singular">
<primary>rings</primary>
<secondary>ring builders</secondary>
</indexterm><indexterm class="singular">
<primary>Object Storage</primary>
<secondary>backup/recovery of</secondary>
</indexterm></para>
</section>
</section>
<section xml:id="recovering_backups">
<title>Recovering Backups</title>
<para>Recovering backups is a fairly simple process. To begin, first
ensure that the service you are recovering is not running. For example, to
do a full recovery of <literal>nova</literal> on the cloud controller,
first stop all <code>nova</code> services:<indexterm class="singular">
<primary>recovery</primary>
<seealso>backup/recovery</seealso>
</indexterm><indexterm class="singular">
<primary>backup/recovery</primary>
<secondary>recovering backups</secondary>
</indexterm></para>
<?hard-pagebreak ?>
<programlisting language="bash"><?db-font-size 65%?><prompt>#</prompt> stop nova-api
# stop nova-cert
# stop nova-consoleauth
# stop nova-novncproxy
# stop nova-objectstore
# stop nova-scheduler</programlisting>
<para>Now you can import a previously backed-up database:</para>
<programlisting language="bash"><?db-font-size 65%?><prompt>#</prompt> mysql nova &lt; nova.sql</programlisting>
<para>You can also restore backed-up nova directories:</para>
<programlisting language="bash"><?db-font-size 65%?><prompt>#</prompt> mv /etc/nova{,.orig}
# cp -a /path/to/backup/nova /etc/</programlisting>
<para>Once the files are restored, start everything back up:</para>
<programlisting language="bash"><?db-font-size 65%?><prompt>#</prompt> start mysql
# for i in nova-api nova-cert nova-consoleauth nova-novncproxy
nova-objectstore nova-scheduler
&gt; do
&gt; start $i
&gt; done</programlisting>
<para>Other services follow the same process, with their respective
directories and <phrase role="keep-together">databases</phrase>.</para>
</section>
<section xml:id="ops-backup-recovery-summary">
<title>Summary</title>
<para>Backup and subsequent recovery is one of the first tasks system
administrators learn. However, each system has different items that need
attention. By taking care of your database, image service, and appropriate
file system locations, you can be assured that you can handle any event
requiring recovery.</para>
</section>
</chapter>

1166
doc/openstack-ops/ch_ops_customize.xml
View File

File diff suppressed because it is too large Load Diff

797
doc/openstack-ops/ch_ops_lay_of_land.xml
View File

@ -1,797 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter version="5.0" xml:id="lay_of_the_land"
xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:ns5="http://www.w3.org/1999/xhtml"
xmlns:ns4="http://www.w3.org/2000/svg"
xmlns:ns3="http://www.w3.org/1998/Math/MathML"
xmlns:ns="http://docbook.org/ns/docbook">
<?dbhtml stop-chunking?>
<title>Lay of the Land</title>
<para>This chapter helps you set up your working environment and use it to
take a look around your cloud.</para>
<section xml:id="dashboard_admin">
<title>Using the OpenStack Dashboard for Administration</title>
<para>As a cloud administrative user, you can use the OpenStack dashboard
to create and manage projects, users, images, and flavors. Users are
allowed to create and manage images within specified projects and to share
images, depending on the Image service configuration. Typically, the
policy configuration allows admin users only to set quotas and create and
manage services. The dashboard provides an <guilabel>Admin</guilabel> tab
with a <guilabel>System Panel</guilabel> and an <guilabel>Identity
</guilabel> tab. These interfaces give you access to system information
and usage as well as to settings for configuring what end users can do.
Refer to the <link xlink:href="http://docs.openstack.org/admin-guide/dashboard.html">OpenStack
Administrator Guide</link> for detailed how-to information about using the
dashboard as an admin user.<indexterm class="singular">
<primary>working environment</primary>
<secondary>dashboard</secondary>
</indexterm><indexterm class="singular">
<primary>dashboard</primary>
</indexterm></para>
</section>
<section xml:id="cli_tools">
<title>Command-Line Tools</title>
<para>We recommend using a combination of the OpenStack command-line
interface (CLI) tools and the OpenStack dashboard for administration. Some
users with a background in other cloud technologies may be using the EC2
Compatibility API, which uses naming conventions somewhat different from
the native API. We highlight those differences.<indexterm class="singular">
<primary>working environment</primary>
<secondary>command-line tools</secondary>
</indexterm></para>
<para>We strongly suggest that you install the command-line clients from
the <link xlink:href="https://pypi.python.org/pypi">Python Package
Index</link> (PyPI) instead of from the distribution packages. The clients
are under heavy development, and it is very likely at any given time that
the version of the packages distributed by your operating-system vendor
are out of date.<indexterm class="singular">
<primary>command-line tools</primary>
<secondary>Python Package Index (PyPI)</secondary>
</indexterm><indexterm class="singular">
<primary>pip utility</primary>
</indexterm><indexterm class="singular">
<primary>Python Package Index (PyPI)</primary>
</indexterm></para>
<para>The pip utility is used to manage package installation from the PyPI
archive and is available in the python-pip package in most Linux
distributions. Each OpenStack project has its own client, so depending on
which services your site runs, install some or all of the
following<indexterm class="singular">
<primary>neutron</primary>
<secondary>python-neutronclient</secondary>
</indexterm><indexterm class="singular">
<primary>swift</primary>
<secondary>python-swiftclient</secondary>
</indexterm><indexterm class="singular">
<primary>cinder</primary>
</indexterm><indexterm class="singular">
<primary>keystone</primary>
</indexterm><indexterm class="singular">
<primary>glance</primary>
<secondary>python-glanceclient</secondary>
</indexterm><indexterm class="singular">
<primary>nova</primary>
<secondary>python-novaclient</secondary>
</indexterm> packages:</para>
<itemizedlist role="compact">
<listitem>
<para>python-novaclient (<glossterm>nova</glossterm> CLI)</para>
</listitem>
<listitem>
<para>python-glanceclient (<glossterm>glance</glossterm> CLI)</para>
</listitem>
<listitem>
<para>python-keystoneclient (<glossterm>keystone</glossterm>
CLI)</para>
</listitem>
<listitem>
<para>python-cinderclient (<glossterm>cinder</glossterm> CLI)</para>
</listitem>
<listitem>
<para>python-swiftclient (<glossterm>swift</glossterm> CLI)</para>
</listitem>
<listitem>
<para>python-neutronclient (<glossterm>neutron</glossterm> CLI)</para>
</listitem>
</itemizedlist>
<section xml:id="install_tools">
<title>Installing the Tools</title>
<para>To install (or upgrade) a package from the PyPI archive with pip,
<indexterm class="singular">
<primary>command-line tools</primary>
<secondary>installing</secondary>
</indexterm>as root:</para>
<programlisting><?db-font-size 60%?># pip install [--upgrade] &lt;package-name&gt;</programlisting>
<para>To remove the package:</para>
<programlisting><?db-font-size 60%?># pip uninstall &lt;package-name&gt;</programlisting>
<para>If you need even newer versions of the clients, pip can install
directly from the upstream git repository using the <code>-e</code>
flag. You must specify a name for the Python egg that is installed. For
example:</para>
<programlisting><?db-font-size 60%?># pip install -e \
git+https://git.openstack.org/openstack/python-novaclient#egg=python-novaclient</programlisting>
<para>If you support the EC2 API on your cloud, you should also install
the euca2ools package or some other EC2 API tool so that you can get the
same view your users have. Using EC2 API-based tools is mostly out of
the scope of this guide, though we discuss getting credentials for use
with it.</para>
</section>
<section xml:id="admin_cli">
<title>Administrative Command-Line Tools</title>
<para>There are also several <literal>*-manage</literal> command-line
tools. These are installed with the project's services on the cloud
controller and do not need to be installed<indexterm class="singular">
<primary>*-manage command-line tools</primary>
</indexterm><indexterm class="singular">
<primary>command-line tools</primary>
<secondary>administrative</secondary>
</indexterm> separately:</para>
<itemizedlist role="compact">
<listitem>
<para><literal>glance-manage</literal></para>
</listitem>
<listitem>
<para><literal>keystone-manage</literal></para>
</listitem>
<listitem>
<para><literal>cinder-manage</literal></para>
</listitem>
</itemizedlist>
<para>Unlike the CLI tools mentioned above, the <code>*-manage</code>
tools must be run from the cloud controller, as root, because they need
read access to the config files such as <code>/etc/nova/nova.conf</code>
and to make queries directly against the database rather than against
the OpenStack <glossterm baseform="API endpoint">API
endpoints</glossterm>.<indexterm class="singular">
<primary>API (application programming interface)</primary>
<secondary>API endpoint</secondary>
</indexterm><indexterm class="singular">
<primary>endpoints</primary>
<secondary>API endpoint</secondary>
</indexterm></para>
<warning>
<para>The existence of the <code>*-manage</code> tools is a legacy
issue. It is a goal of the OpenStack project to eventually migrate all
of the remaining functionality in the <code>*-manage</code> tools into
the API-based tools. Until that day, you need to SSH into the
<glossterm>cloud controller node</glossterm> to perform some
maintenance operations that require one of the <phrase
role="keep-together"><code role="keep-together">*-manage</code>
tools</phrase>.<indexterm class="singular">
<primary>cloud controller nodes</primary>
<secondary>command-line tools and</secondary>
</indexterm></para>
</warning>
</section>
<section xml:id="get_creds">
<title>Getting Credentials</title>
<para>You must have the appropriate credentials if you want to use the
command-line tools to make queries against your OpenStack cloud. By far,
the easiest way to obtain <glossterm>authentication</glossterm>
credentials to use with command-line clients is to use the OpenStack
dashboard. Select <guimenuitem>Project</guimenuitem>, click the
<guimenuitem>Project</guimenuitem> tab, and click <guimenuitem>Access
&amp; Security</guimenuitem> on the <guimenuitem>Compute</guimenuitem>
category. On the <guimenuitem>Access &amp; Security</guimenuitem> page,
click the <guimenuitem>API Access</guimenuitem> tab to display
two buttons, <guilabel>Download OpenStack RC File</guilabel> and
<guilabel>Download EC2 Credentials</guilabel>, which let you generate
files that you can source in your shell to populate the environment
variables the command-line tools require to know where your service
endpoints and your authentication information are. The user you logged
in to the dashboard dictates the filename for the openrc file, such as
<filename>demo-openrc.sh</filename>. When logged in as admin, the file
is named <filename>admin-openrc.sh</filename>.<indexterm
class="singular">
<primary>credentials</primary>
</indexterm><indexterm class="singular">
<primary>authentication</primary>
</indexterm><indexterm class="singular">
<primary>command-line tools</primary>
<secondary>getting credentials</secondary>
</indexterm></para>
<para>The generated file looks something like this:</para>
<programlisting><?db-font-size 60%?>#!/bin/bash
# With the addition of Keystone, to use an openstack cloud you should
# authenticate against keystone, which returns a **Token** and **Service
# Catalog**. The catalog contains the endpoint for all services the
# user/tenant has access to--including nova, glance, keystone, swift.
#
# *NOTE*: Using the 2.0 *auth api* does not mean that compute api is 2.0.
# We use the 1.1 *compute api*
export OS_AUTH_URL=http://203.0.113.10:5000/v2.0
# With the addition of Keystone we have standardized on the term **tenant**
# as the entity that owns the resources.
export OS_TENANT_ID=98333aba48e756fa8f629c83a818ad57
export OS_TENANT_NAME="test-project"
# In addition to the owning entity (tenant), openstack stores the entity
# performing the action as the **user**.
export OS_USERNAME=demo
# With Keystone you pass the keystone password.
echo "Please enter your OpenStack Password: "
read -s OS_PASSWORD_INPUT
export OS_PASSWORD=$OS_PASSWORD_INPUT</programlisting>
<warning>
<para>This does not save your password in plain text, which is a good
thing. But when you source or run the script, it prompts you for your
password and then stores your response in the environment variable
<code>OS_PASSWORD</code>. It is important to note that this does
require interactivity. It is possible to store a value directly in the
script if you require a noninteractive operation, but you then need to
be extremely cautious with the security and permissions of this
file.<indexterm class="singular">
<primary>passwords</primary>
</indexterm><indexterm class="singular">
<primary>security issues</primary>
<secondary>passwords</secondary>
</indexterm></para>
</warning>
<para>EC2 compatibility credentials can be downloaded by selecting
<guimenuitem>Project</guimenuitem>, then <guimenuitem>Compute
</guimenuitem>, then <guimenuitem>Access &amp; Security</guimenuitem>,
then <guimenuitem>API Access</guimenuitem> to display the
<guilabel>Download EC2 Credentials</guilabel> button. Click
the button to generate a ZIP file with server x509 certificates and a
shell script fragment. Create a new directory in a secure location
because these are live credentials containing all the authentication
information required to access your cloud identity, unlike the default
<code>user-openrc</code>. Extract the ZIP file here. You should have
<filename>cacert.pem</filename>, <filename>cert.pem</filename>,
<filename>ec2rc.sh</filename>, and <filename>pk.pem</filename>. The
<filename>ec2rc.sh</filename> is similar to this:<indexterm
class="singular">
<primary>access key</primary>
</indexterm></para>
<programlisting><?db-font-size 50%?>#!/bin/bash
NOVARC=$(readlink -f "${BASH_SOURCE:-${0}}" 2&gt;/dev/null) ||\
NOVARC=$(python -c 'import os,sys; \
print os.path.abspath(os.path.realpath(sys.argv[1]))' "${BASH_SOURCE:-${0}}")
NOVA_KEY_DIR=${NOVARC%/*}
export EC2_ACCESS_KEY=df7f93ec47e84ef8a347bbb3d598449a
export EC2_SECRET_KEY=ead2fff9f8a344e489956deacd47e818
export EC2_URL=http://203.0.113.10:8773/services/Cloud
export EC2_USER_ID=42 # nova does not use user id, but bundling requires it
export EC2_PRIVATE_KEY=${NOVA_KEY_DIR}/pk.pem
export EC2_CERT=${NOVA_KEY_DIR}/cert.pem
export NOVA_CERT=${NOVA_KEY_DIR}/cacert.pem
export EUCALYPTUS_CERT=${NOVA_CERT} # euca-bundle-image seems to require this
alias ec2-bundle-image="ec2-bundle-image --cert $EC2_CERT --privatekey \
$EC2_PRIVATE_KEY --user 42 --ec2cert $NOVA_CERT"
alias ec2-upload-bundle="ec2-upload-bundle -a $EC2_ACCESS_KEY -s \
$EC2_SECRET_KEY --url $S3_URL --ec2cert $NOVA_CERT"</programlisting>
<para>To put the EC2 credentials into your environment, source the
<code>ec2rc.sh</code> file.</para>
</section>
<section xml:id="cli_tricks">
<title>Inspecting API Calls</title>
<para>The command-line tools can be made to show the OpenStack&#160;API
calls they make by passing the <code>--debug</code> flag to
them.<indexterm class="singular">
<primary>API (application programming interface)</primary>
<secondary>API calls, inspecting</secondary>
</indexterm><indexterm class="singular">
<primary>command-line tools</primary>
<secondary>inspecting API calls</secondary>
</indexterm> For example:</para>
<programlisting><?db-font-size 60%?><prompt>#</prompt> nova --debug list</programlisting>
<para>This example shows the HTTP requests from the client and the
responses from the endpoints, which can be helpful in creating custom
tools written to the OpenStack API.</para>
<section xml:id="curl">
<title>Using cURL for further inspection</title>
<para>Underlying the use of the command-line tools is the OpenStack
API, which is a RESTful API that runs over HTTP. There may be cases
where you want to interact with the API directly or need to use it
because of a suspected bug in one of the CLI tools. The best way to do
this is to use a combination of&#160;<link
xlink:href="http://curl.haxx.se/">cURL</link> and another tool,
such as&#160;<link xlink:href="http://stedolan.github.io/jq/">jq</link>, to
parse the JSON from the responses.<indexterm class="singular">
<primary>authentication tokens</primary>
</indexterm><indexterm class="singular">
<primary>cURL</primary>
</indexterm></para>
<para>The first thing you must do is authenticate&#160;with the cloud
using your credentials to get an <glossterm>authentication
token</glossterm>.</para>
<para>Your credentials are a combination of username, password, and
tenant (project). You can extract these values from the
<code>openrc.sh</code> discussed above. The token allows you to
interact with your other service endpoints without needing to
reauthenticate for every request. Tokens are typically good for 24
hours, and when the token expires, you are alerted with a 401
(Unauthorized) response and you can request another <phrase
role="keep-together">token</phrase>.<indexterm class="singular">
<primary>catalog</primary>
</indexterm></para>
<para><orderedlist>
<listitem>
<para>Look at your OpenStack service
<glossterm>catalog</glossterm>:</para>
<programlisting language="bash"><?db-font-size 55%?>
<prompt>$</prompt> curl -s -X POST http://203.0.113.10:35357/v2.0/tokens \
-d '{"auth": {"passwordCredentials": {"username":"test-user", \
"password":"test-password"}, \
"tenantName":"test-project"}}' \
-H "Content-type: application/json" | jq .</programlisting>
</listitem>
<listitem>
<para>Read through the JSON response to get a feel for how the
catalog is laid out.</para>
<para>To make working with subsequent requests easier, store the
token in an environment variable:</para>
<programlisting language="bash"><?db-font-size 55%?>
<prompt>$</prompt> TOKEN=`curl -s -X POST http://203.0.113.10:35357/v2.0/tokens \
-d '{"auth": {"passwordCredentials": {"username":"test-user", \
"password":"test-password"}, \
"tenantName":"test-project"}}' \
-H "Content-type: application/json" | &#160;jq -r .access.token.id`</programlisting>
<para>Now you can refer to your token on the command line as
<literal>$TOKEN</literal>.</para>
</listitem>
<listitem>
<para>Pick a service endpoint from your service catalog, such as
compute. Try a request, for example, listing instances
(servers):</para>
<programlisting><?db-font-size 60%?>
<prompt>$</prompt> curl -s \
-H "X-Auth-Token: $TOKEN" \
http://203.0.113.10:8774/v2/98333aba48e756fa8f629c83a818ad57/servers | jq .</programlisting>
</listitem>
</orderedlist></para>
<para>To discover how API requests should be structured, read the
<link xlink:href="http://developer.openstack.org/api-ref.html">OpenStack API
Reference</link>. To chew through the responses using jq, see the
<link xlink:href="http://stedolan.github.io/jq/manual/">jq Manual</link>.</para>
<para>The <code>-s flag</code> used in the cURL commands above are
used to prevent the&#160;progress meter from being shown. If you are
having trouble running cURL commands, you'll want to remove it.
Likewise, to help you troubleshoot cURL commands, you can include the
<code>-v</code> flag to show you the verbose output. There are many
more extremely useful features in cURL; refer to the man page for all
the options.</para>
</section>
</section>
<section xml:id="servers_services">
<title>Servers and Services</title>
<para>As an administrator, you have a few ways to discover what your
OpenStack cloud looks like simply by using the OpenStack tools
available. This section gives you an idea of how to get an overview of
your cloud, its shape, size, and current state.<indexterm
class="singular">
<primary>services</primary>
<secondary>obtaining overview of</secondary>
</indexterm><indexterm class="singular">
<primary>servers</primary>
<secondary>obtaining overview of</secondary>
</indexterm><indexterm class="singular">
<primary>cloud computing</primary>
<secondary>cloud overview</secondary>
</indexterm><indexterm class="singular">
<primary>command-line tools</primary>
<secondary>servers and services</secondary>
</indexterm></para>
<para>First, you can discover what servers belong to your OpenStack
cloud by running:</para>
<programlisting><?db-font-size 60%?><prompt>#</prompt> nova service-list</programlisting>
<para>The output looks like the following:</para>
<programlisting><?db-font-size 60%?>
+----+------------------+-------------------+------+---------+-------+----------------------------+-----------------+
| Id | Binary | Host | Zone | Status | State | Updated_at | Disabled Reason |
+----+------------------+-------------------+------+---------+-------+----------------------------+-----------------+
| 1 | nova-cert | cloud.example.com | nova | enabled | up | 2016-01-05T17:20:38.000000 | - |
| 2 | nova-compute | c01.example.com | nova | enabled | up | 2016-01-05T17:20:38.000000 | - |
| 3 | nova-compute | c01.example.com. | nova | enabled | up | 2016-01-05T17:20:38.000000 | - |
| 4 | nova-compute | c01.example.com | nova | enabled | up | 2016-01-05T17:20:38.000000 | - |
| 5 | nova-compute | c01.example.com | nova | enabled | up | 2016-01-05T17:20:38.000000 | - |
| 6 | nova-compute | c01.example.com | nova | enabled | up | 2016-01-05T17:20:38.000000 | - |
| 7 | nova-conductor | cloud.example.com | nova | enabled | up | 2016-01-05T17:20:38.000000 | - |
| 8 | nova-cert | cloud.example.com | nova | enabled | up | 2016-01-05T17:20:42.000000 | - |
| 9 | nova-scheduler | cloud.example.com | nova | enabled | up | 2016-01-05T17:20:38.000000 | - |
| 10 | nova-consoleauth | cloud.example.com | nova | enabled | up | 2016-01-05T17:20:35.000000 | - |
+----+------------------+-------------------+------+---------+-------+----------------------------+-----------------+
</programlisting>
<para>The output shows that there are five compute nodes and one cloud
controller. You can see all the services are in up state, which
indicates that the services are up and running. If a service is no
longer available, then service state changes to down state. This is an indication
that you should troubleshoot why the service is down.</para>
<para>If you are using cinder, run the following command to see a
similar listing:</para>
<programlisting><?db-font-size 60%?><prompt>#</prompt> cinder-manage host list | sort</programlisting>
<programlisting><?db-font-size 60%?>host zone
c01.example.com nova
c02.example.com nova
c03.example.com nova
c04.example.com nova
c05.example.com nova
cloud.example.com nova</programlisting>
<para>With these two tables, you now have a good overview of what
servers and services make up your cloud.</para>
<para>You can also use the Identity service (keystone) to see what
services are available in your cloud as well as what endpoints have been
configured for the services.<indexterm class="singular">
<primary>Identity</primary>
<secondary>displaying services and endpoints with</secondary>
</indexterm></para>
<para>The following command requires you to have your shell environment
configured with the proper administrative variables:</para>
<programlisting><?db-font-size 60%?><prompt>$</prompt> openstack catalog list</programlisting>
<programlisting><?db-font-size 60%?>
+----------+------------+---------------------------------------------------------------------------------+
| Name | Type | Endpoints |
+----------+------------+---------------------------------------------------------------------------------+
| nova | compute | RegionOne |
| | | publicURL: http://192.168.122.10:8774/v2/9faa845768224258808fc17a1bb27e5e |
| | | internalURL: http://192.168.122.10:8774/v2/9faa845768224258808fc17a1bb27e5e |
| | | adminURL: http://192.168.122.10:8774/v2/9faa845768224258808fc17a1bb27e5e |
| | | |
| cinderv2 | volumev2 | RegionOne |
| | | publicURL: http://192.168.122.10:8776/v2/9faa845768224258808fc17a1bb27e5e |
| | | internalURL: http://192.168.122.10:8776/v2/9faa845768224258808fc17a1bb27e5e |
| | | adminURL: http://192.168.122.10:8776/v2/9faa845768224258808fc17a1bb27e5e |
| | | |
</programlisting>
<?hard-pagebreak ?>
<para>The preceding output has been truncated to show only two services.
You will see one service entry for each service that your cloud
provides. Note how the endpoint domain can be different depending on the
endpoint type. Different endpoint domains per type are not required, but
this can be done for different reasons, such as endpoint privacy or
network traffic segregation.</para>
<para>You can find the version of the Compute installation by using the
<literal>nova</literal> <phrase
role="keep-together">client command</phrase>: <screen><prompt>#</prompt> <userinput>nova version-list</userinput></screen></para>
</section>
<section xml:id="diagnose-compute">
<title>Diagnose Your Compute Nodes</title>
<para>You can obtain extra information about virtual machines that are
running—their CPU usage, the memory, the disk I/O or network I/O—per
instance, by running the <literal>nova diagnostics</literal> command
with<indexterm class="singular">
<primary>compute nodes</primary>
<secondary>diagnosing</secondary>
</indexterm><indexterm class="singular">
<primary>command-line tools</primary>
<secondary>compute node diagnostics</secondary>
</indexterm> a server ID:</para>
<screen><prompt>$</prompt> <userinput>nova diagnostics &lt;serverID&gt;</userinput></screen>
<para>The output of this command varies depending on the hypervisor
because hypervisors support different attributes.<indexterm
class="singular">
<primary>hypervisors</primary>
<secondary>compute node diagnosis and</secondary>
</indexterm> The following demonstrates the difference between the two
most popular hypervisors. Here is example output when the hypervisor is
Xen: <screen><computeroutput>+----------------+-----------------+
| Property | Value |
+----------------+-----------------+
| cpu0 | 4.3627 |
| memory | 1171088064.0000 |
| memory_target | 1171088064.0000 |
| vbd_xvda_read | 0.0 |
| vbd_xvda_write | 0.0 |
| vif_0_rx | 3223.6870 |
| vif_0_tx | 0.0 |
| vif_1_rx | 104.4955 |
| vif_1_tx | 0.0 |
+----------------+-----------------+</computeroutput></screen>While the
command should work with any hypervisor that is controlled through
libvirt (KVM, QEMU, or LXC), it has been tested only with KVM.
Here is the example output when the hypervisor is KVM:</para>
<?hard-pagebreak ?>
<screen><computeroutput>+------------------+------------+
| Property | Value |
+------------------+------------+
| cpu0_time | 2870000000 |
| memory | 524288 |
| vda_errors | -1 |
| vda_read | 262144 |
| vda_read_req | 112 |
| vda_write | 5606400 |
| vda_write_req | 376 |
| vnet0_rx | 63343 |
| vnet0_rx_drop | 0 |
| vnet0_rx_errors | 0 |
| vnet0_rx_packets | 431 |
| vnet0_tx | 4905 |
| vnet0_tx_drop | 0 |
| vnet0_tx_errors | 0 |
| vnet0_tx_packets | 45 |
+------------------+------------+</computeroutput></screen>
</section>
</section>
<section xml:id="network">
<title>Network Inspection</title>
<para>To see which fixed IP networks are configured in your cloud, you can
use the <literal>nova</literal> command-line client to get the IP
ranges:<indexterm class="singular">
<primary>networks</primary>
<secondary>inspection of</secondary>
</indexterm><indexterm class="singular">
<primary>working environment</primary>
<secondary>network inspection</secondary>
</indexterm><screen><prompt>$</prompt> <userinput>nova network-list</userinput>
<computeroutput>+--------------------------------------+--------+--------------+
| ID | Label | Cidr |
+--------------------------------------+--------+--------------+
| 3df67919-9600-4ea8-952e-2a7be6f70774 | test01 | 10.1.0.0/24 |
| 8283efb2-e53d-46e1-a6bd-bb2bdef9cb9a | test02 | 10.1.1.0/24 |
+--------------------------------------+--------+--------------+</computeroutput></screen></para>
<para>The <literal>nova</literal> command-line client can provide some additional
details:</para>
<screen><prompt>#</prompt> <userinput>nova network-list</userinput>
<computeroutput>id IPv4 IPv6 start address DNS1 DNS2 VlanID project uuid&#160;
1 10.1.0.0/24 None 10.1.0.3 None None 300 2725bbd beacb3f2
2 10.1.1.0/24 None 10.1.1.3 None None 301 none d0b1a796</computeroutput></screen>
<para>This output shows that two networks are configured, each network
containing 255 IPs (a /24 subnet). The first network has been assigned to
a certain project, while the second network is still open for assignment.
You can assign this network manually; otherwise, it is automatically
assigned when a project launches its first instance.</para>
<para>To find out whether any floating IPs are available in your cloud,
run:</para>
<programlisting><?db-font-size 60%?><prompt>#</prompt> nova floating-ip-list</programlisting>
<programlisting><?db-font-size 55%?>2725bb...59f43f 1.2.3.4 None nova vlan20
None 1.2.3.5 48a415...b010ff nova vlan20</programlisting>
<para>Here, two floating IPs are available. The first has been allocated
to a project, while the other is unallocated.</para>
</section>
<section xml:id="users_projects">
<title>Users and Projects</title>
<para>To see a list of projects that have been added to the
cloud,<indexterm class="singular">
<primary>projects</primary>
<secondary>obtaining list of current</secondary>
</indexterm><indexterm class="singular">
<primary>user management</primary>
<secondary>listing users</secondary>
</indexterm><indexterm class="singular">
<primary>working environment</primary>
<secondary>users and projects</secondary>
</indexterm> run:</para>
<programlisting><?db-font-size 60%?><prompt>$</prompt> openstack project list</programlisting>
<programlisting><?db-font-size 60%?>+----------------------------------+--------------------+
| ID | Name |
+----------------------------------+--------------------+
| 422c17c0b26f4fbe9449f37a5621a5e6 | alt_demo |
| 5dc65773519248f3a580cfe28ba7fa3f | demo |
| 9faa845768224258808fc17a1bb27e5e | admin |
| a733070a420c4b509784d7ea8f6884f7 | invisible_to_admin |
| aeb3e976e7794f3f89e4a7965db46c1e | service |
+----------------------------------+--------------------+ </programlisting>
<para>To see a list of users, run:</para>
<programlisting><?db-font-size 60%?><prompt>$</prompt> openstack user list</programlisting>
<programlisting><?db-font-size 60%?>+----------------------------------+----------+
| ID | Name |
+----------------------------------+----------+
| 5837063598694771aedd66aa4cddf0b8 | demo |
| 58efd9d852b74b87acc6efafaf31b30e | cinder |
| 6845d995a57a441f890abc8f55da8dfb | glance |
| ac2d15a1205f46d4837d5336cd4c5f5a | alt_demo |
| d8f593c3ae2b47289221f17a776a218b | admin |
| d959ec0a99e24df0b7cb106ff940df20 | nova |
+----------------------------------+----------+</programlisting>
<note>
<para>Sometimes a user and a group have a one-to-one mapping. This
happens for standard system accounts, such as cinder, glance, nova, and
swift, or when only one user is part of a group.</para>
</note>
</section>
<section xml:id="running_instances">
<title>Running Instances</title>
<para>To see a list of running instances,<indexterm class="singular">
<primary>instances</primary>
<secondary>list of running</secondary>
</indexterm><indexterm class="singular">
<primary>working environment</primary>
<secondary>running instances</secondary>
</indexterm> run:</para>
<programlisting><?db-font-size 60%?><prompt>$</prompt> nova list --all-tenants</programlisting>
<programlisting><?db-font-size 60%?>+-----+------------------+--------+-------------------------------------------+
| ID | Name | Status | Networks |
+-----+------------------+--------+-------------------------------------------+
| ... | Windows | ACTIVE | novanetwork_1=10.1.1.3, 199.116.232.39 |
| ... | cloud controller | ACTIVE | novanetwork_0=10.1.0.6; jtopjian=10.1.2.3 |
| ... | compute node 1 | ACTIVE | novanetwork_0=10.1.0.4; jtopjian=10.1.2.4 |
| ... | devbox | ACTIVE | novanetwork_0=10.1.0.3 |
| ... | devstack | ACTIVE | novanetwork_0=10.1.0.5 |
| ... | initial | ACTIVE | nova_network=10.1.7.4, 10.1.8.4 |
| ... | lorin-head | ACTIVE | nova_network=10.1.7.3, 10.1.8.3 |
+-----+------------------+--------+-------------------------------------------+</programlisting>
<para>Unfortunately, this command does not tell you various details about
the running <phrase role="keep-together">instances</phrase>, such as what
compute node the instance is running on, what flavor the instance is, and
so on. You can use the following command to view details about individual
instances:<indexterm class="singular">
<primary>config drive</primary>
</indexterm></para>
<programlisting><?db-font-size 60%?><prompt>$</prompt> nova show &lt;uuid&gt;</programlisting>
<para>For example: <programlisting><?db-font-size 60%?># nova show&#160;81db556b-8aa5-427d-a95c-2a9a6972f630</programlisting><programlisting><?db-font-size 60%?>+-------------------------------------+-----------------------------------+
| Property | Value |
+-------------------------------------+-----------------------------------+
| OS-DCF:diskConfig | MANUAL |
| OS-EXT-SRV-ATTR:host | c02.example.com |
| OS-EXT-SRV-ATTR:hypervisor_hostname | c02.example.com |
| OS-EXT-SRV-ATTR:instance_name | instance-00000029 |
| OS-EXT-STS:power_state | 1 |
| OS-EXT-STS:task_state | None |
| OS-EXT-STS:vm_state | active |
| accessIPv4 | |
| accessIPv6 | |
| config_drive | |
| created | 2013-02-13T20:08:36Z |
| flavor | m1.small (6) |
| hostId | ... |
| id | ... |
| image | Ubuntu 12.04 cloudimg amd64 (...) |
| key_name | jtopjian-sandbox |
| metadata | {} |
| name | devstack |
| novanetwork_0 network | 10.1.0.5 |
| progress | 0 |
| security_groups | [{u'name': u'default'}] |
| status | ACTIVE |
| tenant_id | ... |
| updated | 2013-02-13T20:08:59Z |
| user_id | ... |
+-------------------------------------+-----------------------------------+</programlisting></para>
<para>This output shows that an instance named
<userinput>devstack</userinput> was created from an Ubuntu 12.04 image
using a flavor of <literal>m1.small</literal> and is hosted on the compute
node <literal>c02.example.com</literal>.</para>
</section>
<section xml:id="ops-lay-of-land-summary">
<title>Summary</title>
<para>We hope you have enjoyed this quick tour of your working
environment, including how to interact with your cloud and extract useful
information. From here, you can use the <emphasis><link
xlink:href="http://docs.openstack.org/admin-guide/">OpenStack Administrator Guide</link></emphasis>
as your reference for all of the command-line functionality in your
cloud.</para>
</section>
</chapter>

1055
doc/openstack-ops/ch_ops_log_monitor.xml
View File

File diff suppressed because it is too large Load Diff

1492
doc/openstack-ops/ch_ops_maintenance.xml
View File

File diff suppressed because it is too large Load Diff

1297
doc/openstack-ops/ch_ops_network_troubleshooting.xml
View File

File diff suppressed because it is too large Load Diff

1106
doc/openstack-ops/ch_ops_projects_users.xml
View File

File diff suppressed because it is too large Load Diff

108
doc/openstack-ops/ch_ops_resources.xml
View File

@ -1,108 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<appendix label="D" version="5.0" xml:id="recommended-reading"
xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:ns5="http://www.w3.org/1998/Math/MathML"
xmlns:ns4="http://www.w3.org/2000/svg"
xmlns:ns3="http://www.w3.org/1999/xhtml"
xmlns:ns="http://docbook.org/ns/docbook">
<?dbhtml stop-chunking?>
<title>Resources</title>
<section xml:id="openstack-resources">
<title>OpenStack</title>
<itemizedlist>
<listitem>
<para><link xlink:href="http://docs.openstack.org/liberty/install-guide-obs/">Installation
Guide for openSUSE 13.2 and SUSE Linux Enterprise
Server 12</link></para>
</listitem>
<listitem>
<para><link xlink:href="http://docs.openstack.org/liberty/install-guide-rdo/">Installation
Guide for Red Hat Enterprise Linux 7, CentOS 7, and
Fedora 22</link></para>
</listitem>
<listitem>
<para><link
xlink:href="http://docs.openstack.org/liberty/install-guide-ubuntu/">Installation
Guide for Ubuntu 14.04 (LTS) Server</link></para>
</listitem>
<listitem>
<para><link xlink:href="http://docs.openstack.org/admin-guide/">OpenStack
Administrator Guide</link></para>
</listitem>
<listitem>
<para><link xlink:href="http://www.packtpub.com/openstack-cloud-computing-cookbook-second-edition/book"><emphasis>OpenStack
Cloud Computing Cookbook</emphasis> (Packt Publishing) </link></para>
</listitem>
</itemizedlist>
</section>
<section xml:id="cloud-general-resources">
<title>Cloud (General)</title>
<itemizedlist>
<listitem>
<para><link xlink:href="http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf">“The NIST Definition
of Cloud Computing”</link></para>
</listitem>
</itemizedlist>
</section>
<section xml:id="python-resources">
<title>Python</title>
<itemizedlist>
<listitem>
<para><link xlink:href="http://www.diveintopython.net/"><emphasis>Dive Into
Python</emphasis> (Apress)</link></para>
</listitem>
</itemizedlist>
</section>
<section xml:id="networking-resources">
<title>Networking</title>
<itemizedlist>
<listitem>
<para><link xlink:href="http://www.pearsonhighered.com/educator/product/TCPIP-Illustrated-Volume-1-The-Protocols/9780321336316.page"><emphasis>TCP/IP
Illustrated, Volume 1: The Protocols, 2/E</emphasis>
(Pearson)</link></para>
</listitem>
<listitem>
<para><link xlink:href="http://www.nostarch.com/tcpip.htm"><emphasis>The TCP/IP
Guide</emphasis> (No Starch Press)</link></para>
</listitem>
<listitem>
<para><link xlink:href="http://danielmiessler.com/study/tcpdump/">“A
<code>tcpdump</code> Tutorial and Primer”</link></para>
</listitem>
</itemizedlist>
</section>
<section xml:id="system-admin-resources">
<title>Systems Administration</title>
<itemizedlist>
<listitem>
<para><link xlink:href="http://www.admin.com/"><emphasis>UNIX and
Linux Systems Administration Handbook</emphasis> (Prentice
Hall)</link></para>
</listitem>
</itemizedlist>
</section>
<section xml:id="virtualization-resources">
<title>Virtualization</title>
<itemizedlist>
<listitem>
<para><link xlink:href="http://www.nostarch.com/xen.htm"><emphasis>The Book
of Xen</emphasis> (No Starch Press)</link></para>
</listitem>
</itemizedlist>
</section>
<section xml:id="config-management-resources">
<title>Configuration Management</title>
<itemizedlist>
<listitem>
<para><link xlink:href="http://docs.puppetlabs.com/">Puppet Labs
Documentation</link></para>
</listitem>
<listitem>
<para><link xlink:href="http://www.apress.com/9781430230571"><emphasis>Pro
Puppet</emphasis> (Apress)</link></para>
</listitem>
</itemizedlist>
</section>
</appendix>

678
doc/openstack-ops/ch_ops_upgrades.xml
View File

@ -1,678 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter version="5.0" xml:id="ch_ops_upgrades"
xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:ns5="http://www.w3.org/2000/svg"
xmlns:ns4="http://www.w3.org/1998/Math/MathML"
xmlns:ns3="http://www.w3.org/1999/xhtml"
xmlns:ns="http://docbook.org/ns/docbook">
<title>Upgrades</title>
<para>With the exception of Object Storage, upgrading from one
version of OpenStack to another can take a great deal of effort.
This chapter provides some guidance on the operational aspects
that you should consider for performing an upgrade for a basic
architecture.</para>
<section xml:id="ops_upgrades-pre-considerations">
<title>Pre-upgrade considerations</title>
<section xml:id="ops_upgrades-planning">
<title>Upgrade planning</title>
<itemizedlist>
<listitem>
<para>Thoroughly review the
<link xlink:href="http://wiki.openstack.org/wiki/ReleaseNotes/"
>release notes</link> to learn about new, updated, and deprecated features.
Find incompatibilities between versions.</para>
</listitem>
<listitem>
<para>Consider the impact of an upgrade to users. The upgrade process
interrupts management of your environment including the dashboard.
If you properly prepare for the upgrade, existing instances, networking,
and storage should continue to operate. However, instances might experience
intermittent network interruptions.</para>
</listitem>
<listitem>
<para>Consider the approach to upgrading your environment. You can perform
an upgrade with operational instances, but this is a dangerous approach.
You might consider using live migration to temporarily relocate instances
to other compute nodes while performing upgrades. However, you must
ensure database consistency throughout the process; otherwise your
environment might become unstable. Also, don't forget to provide
sufficient notice to your users, including giving them plenty of
time to perform their own backups.</para>
</listitem>
<listitem>
<para>Consider adopting structure and options from the service
configuration files and merging them with existing configuration
files. The
<link xlink:href="http://docs.openstack.org/kilo/config-reference/content/"
><citetitle>OpenStack Configuration Reference</citetitle></link>
contains new, updated, and deprecated options for most
services.</para>
</listitem>
<listitem>
<para>Like all major system upgrades, your upgrade could fail for
one or more reasons. You should prepare for this situation by
having the ability to roll back your environment to the previous
release, including databases, configuration files, and packages.
We provide an example process for rolling back your environment in
<xref linkend="ops_upgrades-roll-back"/>.<indexterm class="singular">
<primary>upgrading</primary>
<secondary>process overview</secondary>
</indexterm><indexterm class="singular">
<primary>rollbacks</primary>
<secondary>preparing for</secondary>
</indexterm><indexterm class="singular">
<primary>upgrading</primary>
<secondary>preparation for</secondary>
</indexterm></para>
</listitem>
<listitem>
<para>Develop an upgrade procedure and assess it thoroughly by
using a test environment similar to your production
environment.</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="ops_upgrades-pre-testing">
<title>Pre-upgrade testing environment</title>
<para>The most important step is the pre-upgrade testing. If you
are upgrading immediately after release of a new version,
undiscovered bugs might hinder your progress. Some deployers
prefer to wait until the first point release is announced.
However, if you have a significant deployment, you might follow
the development and testing of the release to ensure that bugs
for your use cases are fixed.<indexterm class="singular">
<primary>upgrading</primary>
<secondary>pre-upgrade testing</secondary>
</indexterm></para>
<para>Each OpenStack cloud is different even if you have a near-identical
architecture as described in this guide. As a result, you must still
test upgrades between versions in your environment using an
approximate clone of your environment.</para>
<para>However, that is not to say that it needs to be the same
size or use identical hardware as the production environment.
It is important to consider the hardware and scale of the cloud that
you are upgrading. The following tips can help you minimise the cost:<indexterm
class="singular">
<primary>upgrading</primary>
<secondary>controlling cost of</secondary>
</indexterm></para>
<variablelist>
<varlistentry>
<term>Use your own cloud</term>
<listitem>
<para>The simplest place to start testing the next version
of OpenStack is by setting up a new environment inside
your own cloud. This might seem odd, especially the double
virtualization used in running compute nodes. But it is a
sure way to very quickly test your configuration.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Use a public cloud</term>
<listitem>
<para>Consider using a public cloud to test the scalability
limits of your cloud controller configuration. Most public
clouds bill by the hour, which means it can be inexpensive
to perform even a test with many nodes.<indexterm class="singular">
<primary>cloud controllers</primary>
<secondary>scalability and</secondary>
</indexterm></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Make another storage endpoint on the same system</term>
<listitem>
<para>If you use an external storage plug-in or shared file
system with your cloud, you can test whether it works by
creating a second share or endpoint. This allows you to
test the system before entrusting the new version on to your
storage.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Watch the network</term>
<listitem>
<para>Even at smaller-scale testing, look for excess network
packets to determine whether something is going horribly
wrong in inter-component communication.</para>
</listitem>
</varlistentry>
</variablelist>
<para>To set up the test environment, you can use one of several
methods:</para>
<itemizedlist>
<!-- the following link suffers from a toolchain problem, where in the
rendered PDF version, the title butts up against the link, which comes
before the title FIXME -->
<listitem>
<para>Do a full manual install by using the <link
xlink:href="http://docs.openstack.org/index.html#install-guides"
><citetitle>OpenStack Installation
Guide</citetitle></link> for your platform. Review the
final configuration files and installed packages.</para>
</listitem>
<listitem>
<para>Create a clone of your automated configuration
infrastructure with changed package repository URLs.</para>
<para>Alter the configuration until it works.</para>
</listitem>
</itemizedlist>
<para>Either approach is valid. Use the approach that matches your
experience.</para>
<para>An upgrade pre-testing system is excellent for getting the
configuration to work. However, it is important to note that the
historical use of the system and differences in user interaction
can affect the success of upgrades.</para>
<para>If possible, we highly recommend that you dump your
production database tables and test the upgrade in your development
environment using this data. Several MySQL bugs have been uncovered
during database migrations because of slight table differences between
a fresh installation and tables that migrated from one version to another.
This will have impact on large real datasets, which you do not want to
encounter during a production outage.</para>
<para>Artificial scale testing can go only so far. After your
cloud is upgraded, you must pay careful attention to the
performance aspects of your cloud.</para>
</section>
<?hard-pagebreak?>
<section xml:id="ops_upgrades_upgrade_levels">
<title>Upgrade Levels</title>
<para>Upgrade levels are a feature added to OpenStack Compute since the
Grizzly release to provide version locking on the RPC
(Message Queue) communications between the various Compute services.
</para>
<para>This functionality is an important piece of the puzzle when
it comes to live upgrades and is conceptually similar to the
existing API versioning that allows OpenStack services of
different versions to communicate without issue.</para>
<para>Without upgrade levels, an X+1 version Compute service can
receive and understand X version RPC messages, but it can only
send out X+1 version RPC messages. For example, if a
<systemitem class="service">nova-conductor</systemitem>
process has been upgraded to X+1 version, then the conductor service
will be able to understand messages from X version
<systemitem class="service">nova-compute</systemitem>
processes, but those compute services will not be able to
understand messages sent by the conductor service.</para>
<para>During an upgrade, operators can add configuration options to
<filename>nova.conf</filename> which lock the version of RPC
messages and allow live upgrading of the services without
interruption caused by version mismatch. The configuration
options allow the specification of RPC version numbers if desired,
but release name alias are also supported. For example:</para>
<programlisting language="ini">[upgrade_levels]
compute=X+1
conductor=X+1
scheduler=X+1</programlisting>
<para>will keep the RPC version locked across the specified services
to the RPC version used in X+1. As all instances of a particular
service are upgraded to the newer version, the corresponding line
can be removed from <filename>nova.conf</filename>.</para>
<para>Using this functionality, ideally one would lock the RPC version
to the OpenStack version being upgraded from on
<systemitem class="service">nova-compute</systemitem> nodes, to
ensure that, for example X+1 version
<systemitem class="service">nova-compute</systemitem>
processes will continue to work with X version
<systemitem class="service">nova-conductor</systemitem>
processes while the upgrade completes. Once the upgrade of
<systemitem class="service">nova-compute</systemitem>
processes is complete, the operator can move onto upgrading
<systemitem class="service">nova-conductor</systemitem>
and remove the version locking for
<systemitem class="service">nova-compute</systemitem> in
<filename>nova.conf</filename>.
</para>
</section>
</section>
<section xml:id="ops_upgrade-process">
<title>Upgrade process</title>
<?dbhtml stop-chunking?>
<para>This section describes the process to upgrade a basic
OpenStack deployment based on the basic two-node architecture in the
<link xlink:href="http://docs.openstack.org/index.html#install-guides">
<citetitle>OpenStack Installation Guide</citetitle></link>.
All nodes must run a supported distribution of Linux with a recent kernel
and the current release packages.</para>
<section xml:id="upgrade-considerations">
<title>Prerequisites</title>
<itemizedlist>
<listitem>
<para>Perform some cleaning of the environment prior to
starting the upgrade process to ensure a consistent state.
For example, instances not fully purged from the system
after deletion might cause indeterminate behavior.</para>
</listitem>
<listitem>
<para>For environments using the OpenStack Networking
service (neutron), verify the release version of the database. For example:</para>
<screen><prompt>#</prompt> <userinput>su -s /bin/sh -c "neutron-db-manage --config-file /etc/neutron/neutron.conf \
--config-file /etc/neutron/plugins/ml2/ml2_conf.ini current" neutron</userinput></screen>
</listitem>
</itemizedlist>
</section>
<section xml:id="upgrades-backup">
<title>Perform a backup</title>
<procedure>
<step>
<para>Save the configuration files on all nodes. For example:</para>
<screen><prompt>#</prompt> <userinput>for i in keystone glance nova neutron openstack-dashboard cinder heat ceilometer; \
do mkdir $i-kilo; \
done</userinput>
<prompt>#</prompt> <userinput>for i in keystone glance nova neutron openstack-dashboard cinder heat ceilometer; \
do cp -r /etc/$i/* $i-kilo/; \
done</userinput></screen>
<note>
<para>You can modify this example script on each node to
handle different services.</para>
</note>
</step>
<step>
<para>Make a full database backup of your production data. As of
Kilo, database downgrades are not supported, and the only method
available to get back to a prior database version will be to restore
from backup.</para>
<screen><prompt>#</prompt> <userinput>mysqldump -u root -p --opt --add-drop-database --all-databases &gt; icehouse-db-backup.sql</userinput></screen>
<note>
<para>Consider updating your SQL server configuration as
described in the
<link xlink:href="http://docs.openstack.org/index.html#install-guides"
>OpenStack Installation Guide</link>.</para>
</note>
</step>
</procedure>
</section>
<section xml:id="upgrades-repos">
<title>Manage repositories</title>
<procedure>
<para>On all nodes:</para>
<step>
<para>Remove the repository for the previous release packages.</para>
</step>
<step>
<para>Add the repository for the new release packages.</para>
</step>
<step>
<para>Update the repository database.</para>
</step>
</procedure>
</section>
<section xml:id="upgrades-packages">
<title>Upgrade packages on each node</title>
<para>Depending on your specific configuration, upgrading all
packages might restart or break services supplemental to your
OpenStack environment. For example, if you use the TGT iSCSI
framework for Block Storage volumes and the upgrade includes
new packages for it, the package manager might restart the
TGT iSCSI services and impact connectivity to volumes.</para>
<para>If the package manager prompts you to update configuration
files, reject the changes. The package manager appends a
suffix to newer versions of configuration files. Consider
reviewing and adopting content from these files.</para>
<note>
<para>You may need to explicitly install the <literal>ipset</literal>
package if your distribution does not install it as a
dependency.</para></note>
</section>
<section xml:id="upgrades-services">
<title>Update services</title>
<para>To update a service on each node, you generally modify one or more
configuration files, stop the service, synchronize the
database schema, and start the service. Some services require
different steps. We recommend verifying operation of each
service before proceeding to the next service.</para>
<para>The order you should upgrade services, and any changes from the
general upgrade process is described below:</para>
<orderedlist>
<title>Controller node</title>
<listitem>
<para>OpenStack Identity - Clear any expired tokens before
synchronizing the database.</para>
</listitem>
<listitem>
<para>OpenStack Image service</para>
</listitem>
<listitem>
<para>OpenStack Compute, including networking
components.</para>
</listitem>
<listitem>
<para>OpenStack Networking</para>
</listitem>
<listitem>
<para>OpenStack Block Storage</para>
</listitem>
<listitem>
<para>OpenStack dashboard - In typical environments, updating the
dashboard only requires restarting the Apache HTTP service.</para>
<para></para>
</listitem>
<listitem>
<para>OpenStack Orchestration</para>
</listitem>
<listitem>
<para>OpenStack Telemetry - In typical environments, updating the
Telemetry service only requires restarting the service.</para>
<para></para>
</listitem>
<listitem>
<para>OpenStack Compute - Edit the configuration file and restart the
service.</para>
</listitem>
<listitem>
<para>OpenStack Networking - Edit the configuration file and restart
the service.</para>
</listitem>
</orderedlist>
<itemizedlist>
<title>Compute nodes</title>
<listitem>
<para>OpenStack Block Storage - Updating the Block Storage service
only requires restarting the service.</para>
</listitem>
</itemizedlist>
<itemizedlist>
<title>Storage nodes</title>
<listitem>
<para>OpenStack Networking - Edit the configuration file and restart
the service.</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="upgrades-final-steps">
<title>Final steps</title>
<para>On all distributions, you must perform some final tasks to
complete the upgrade process.<indexterm class="singular">
<primary>upgrading</primary>
<secondary>final steps</secondary>
</indexterm></para>
<procedure>
<step><para>Decrease DHCP timeouts by modifying
<filename>/etc/nova/nova.conf</filename> on the compute nodes
back to the original value for your environment.</para></step>
<step><para>Update all <filename>.ini</filename> files to match
passwords and pipelines as required for the OpenStack release in your
environment.</para></step>
<step><para>After migration, users see different results from
<command>nova image-list</command> and <command>glance
image-list</command>. To ensure users see the same images in
the list commands, edit the <filename>/etc/glance/policy.json</filename>
and <filename>/etc/nova/policy.json</filename> files to contain
<code>"context_is_admin": "role:admin"</code>, which limits
access to private images for projects.</para></step>
<step><para>Verify proper operation of your environment. Then, notify your users
that their cloud is operating normally again.</para></step>
</procedure>
</section>
</section>
<section xml:id="ops_upgrades-roll-back">
<title>Rolling back a failed upgrade</title>
<para>Upgrades involve complex operations and can fail. Before
attempting any upgrade, you should make a full database backup
of your production data. As of Kilo, database downgrades are
not supported, and the only method available to get back to a
prior database version will be to restore from backup.</para>
<para>This section provides guidance for rolling back to a previous
release of OpenStack. All distributions follow a similar <phrase role="keep-together"
>procedure</phrase>.<indexterm class="singular">
<primary>rollbacks</primary>
<secondary>process for</secondary>
</indexterm><indexterm class="singular">
<primary>upgrading</primary>
<secondary>rolling back failures</secondary>
</indexterm></para>
<para>A common scenario is to take down production management services
in preparation for an upgrade, completed part of the upgrade process,
and discovered one or more problems not encountered during testing.
As a consequence, you must roll back your environment to the original
"known good" state. You also made sure that you did not make any state
changes after attempting the upgrade process; no new instances, networks,
storage volumes, and so on. Any of these new resources will be in a frozen
state after the databases are restored from backup.</para>
<para>Within this scope, you must complete these steps to
successfully roll back your environment:</para>
<orderedlist>
<listitem>
<para>Roll back configuration files.</para>
</listitem>
<listitem>
<para>Restore databases from backup.</para>
</listitem>
<listitem>
<para>Roll back packages.</para>
</listitem>
</orderedlist>
<para>You should verify that you
have the requisite backups to restore. Rolling back upgrades is
a tricky process because distributions tend to put much more
effort into testing upgrades than downgrades. Broken downgrades
take significantly more effort to troubleshoot and, resolve than
broken upgrades. Only you can weigh the risks of trying to push
a failed upgrade forward versus rolling it back. Generally,
consider rolling back as the very last option.</para>
<para>The following steps described for Ubuntu have worked on at
least one production environment, but they might not work for
all environments.</para>
<procedure>
<title>To perform the rollback</title>
<step>
<para>Stop all OpenStack services.</para>
</step>
<step>
<para>Copy contents of configuration backup directories that you
created during the upgrade process back to
<filename>/etc/&lt;service&gt;</filename> directory.</para>
</step>
<step>
<para>Restore databases from the
<filename><replaceable>RELEASE_NAME</replaceable>-db-backup.sql</filename> backup file
that you created with the <command>mysqldump</command>
command during the upgrade process:</para>
<screen><prompt>#</prompt> <userinput>mysql -u root -p &lt; <replaceable>RELEASE_NAME</replaceable>-db-backup.sql</userinput></screen>
</step>
<step>
<para>Downgrade OpenStack packages.</para>
<warning>
<para>Downgrading packages is by far the most complicated
step; it is highly dependent on the distribution and the
overall administration of the system.</para>
</warning>
<substeps>
<step>
<para>Determine which OpenStack packages are installed on
your system. Use the <command>dpkg
--get-selections</command> command. Filter for
OpenStack packages, filter again to omit packages
explicitly marked in the <code>deinstall</code> state,
and save the final output to a file. For example, the
following command covers a controller node with
keystone, glance, nova, neutron, and cinder:</para>
<screen><prompt>#</prompt> <userinput>dpkg --get-selections | grep -e keystone -e glance -e nova -e neutron \
-e cinder | grep -v deinstall | tee openstack-selections</userinput>
<computeroutput>cinder-api install
cinder-common install
cinder-scheduler install
cinder-volume install
glance install
glance-api install
glance-common install
glance-registry install
neutron-common install
neutron-dhcp-agent install
neutron-l3-agent install
neutron-lbaas-agent install
neutron-metadata-agent install
neutron-plugin-openvswitch install
neutron-plugin-openvswitch-agent install
neutron-server install
nova-api install
nova-cert install
nova-common install
nova-conductor install
nova-consoleauth install
nova-novncproxy install
nova-objectstore install
nova-scheduler install
python-cinder install
python-cinderclient install
python-glance install
python-glanceclient install
python-keystone install
python-keystoneclient install
python-neutron install
python-neutronclient install
python-nova install
python-novaclient install
</computeroutput></screen>
<note>
<para>Depending on the type of server, the contents and
order of your package list might vary from this
example.</para>
</note>
</step>
<step>
<para>You can determine the package versions available for
reversion by using the <command>apt-cache
policy</command> command. If you removed the Grizzly
repositories, you must first reinstall them and run
<command>apt-get update</command>:</para>
<!-- FIXME - there was a query about whether this command and the output is
aligned correctly. In the PDF the # is directly above the n of nova common, and
everything is indented below the m of them in the previous sentence -->
<screen><prompt>#</prompt> <userinput>apt-cache policy nova-common</userinput>
<computeroutput>nova-common:
Installed: 1:2013.2-0ubuntu1~cloud0
Candidate: 1:2013.2-0ubuntu1~cloud0
Version table:
*** 1:2013.2-0ubuntu1~cloud0 0
500 http://ubuntu-cloud.archive.canonical.com/ubuntu/
precise-updates/havana/main amd64 Packages
100 /var/lib/dpkg/status
1:2013.1.4-0ubuntu1~cloud0 0
500 http://ubuntu-cloud.archive.canonical.com/ubuntu/
precise-updates/grizzly/main amd64 Packages
2012.1.3+stable-20130423-e52e6912-0ubuntu1.2 0
500 http://us.archive.ubuntu.com/ubuntu/
precise-updates/main amd64 Packages
500 http://security.ubuntu.com/ubuntu/
precise-security/main amd64 Packages
2012.1-0ubuntu2 0
500 http://us.archive.ubuntu.com/ubuntu/
precise/main amd64 Packages</computeroutput></screen>
<para>This tells us the currently installed version of the
package, newest candidate version, and all versions
along with the repository that contains each version.
Look for the appropriate Grizzly
version—<code>1:2013.1.4-0ubuntu1~cloud0</code> in
this case. The process of manually picking through this
list of packages is rather tedious and prone to errors.
You should consider using the following script to help
with this process:</para>
<!-- FIXME - there was a query about whether this command and the output is
aligned correctly. -->
<screen><prompt>#</prompt> <userinput>for i in `cut -f 1 openstack-selections | sed 's/neutron/quantum/;'`;
do echo -n $i ;apt-cache policy $i | grep -B 1 grizzly |
grep -v Packages | awk '{print "="$1}';done | tr '\n' ' ' |
tee openstack-grizzly-versions</userinput>
<computeroutput>cinder-api=1:2013.1.4-0ubuntu1~cloud0
cinder-common=1:2013.1.4-0ubuntu1~cloud0
cinder-scheduler=1:2013.1.4-0ubuntu1~cloud0
cinder-volume=1:2013.1.4-0ubuntu1~cloud0
glance=1:2013.1.4-0ubuntu1~cloud0
glance-api=1:2013.1.4-0ubuntu1~cloud0
glance-common=1:2013.1.4-0ubuntu1~cloud0
glance-registry=1:2013.1.4-0ubuntu1~cloud0
quantum-common=1:2013.1.4-0ubuntu1~cloud0
quantum-dhcp-agent=1:2013.1.4-0ubuntu1~cloud0
quantum-l3-agent=1:2013.1.4-0ubuntu1~cloud0
quantum-lbaas-agent=1:2013.1.4-0ubuntu1~cloud0
quantum-metadata-agent=1:2013.1.4-0ubuntu1~cloud0
quantum-plugin-openvswitch=1:2013.1.4-0ubuntu1~cloud0
quantum-plugin-openvswitch-agent=1:2013.1.4-0ubuntu1~cloud0
quantum-server=1:2013.1.4-0ubuntu1~cloud0
nova-api=1:2013.1.4-0ubuntu1~cloud0
nova-cert=1:2013.1.4-0ubuntu1~cloud0
nova-common=1:2013.1.4-0ubuntu1~cloud0
nova-conductor=1:2013.1.4-0ubuntu1~cloud0
nova-consoleauth=1:2013.1.4-0ubuntu1~cloud0
nova-novncproxy=1:2013.1.4-0ubuntu1~cloud0
nova-objectstore=1:2013.1.4-0ubuntu1~cloud0
nova-scheduler=1:2013.1.4-0ubuntu1~cloud0
python-cinder=1:2013.1.4-0ubuntu1~cloud0
python-cinderclient=1:1.0.3-0ubuntu1~cloud0
python-glance=1:2013.1.4-0ubuntu1~cloud0
python-glanceclient=1:0.9.0-0ubuntu1.2~cloud0
python-quantum=1:2013.1.4-0ubuntu1~cloud0
python-quantumclient=1:2.2.0-0ubuntu1~cloud0
python-nova=1:2013.1.4-0ubuntu1~cloud0
python-novaclient=1:2.13.0-0ubuntu1~cloud0
</computeroutput></screen>
<note>
<para>If you decide to continue this step manually,
don't forget to change <code>neutron</code> to
<code>quantum</code> where applicable.</para>
</note>
</step>
<step>
<para>Use the <command>apt-get install</command> command
to install specific versions of each package by
specifying
<code>&lt;package-name&gt;=&lt;version&gt;</code>. The
script in the previous step conveniently created a list
of <code>package=version</code> pairs for you:</para>
<screen><prompt>#</prompt> <userinput>apt-get install `cat openstack-grizzly-versions`</userinput></screen>
<para>This step completes the rollback procedure. You
should remove the upgrade release repository and run
<command>apt-get update</command> to prevent
accidental upgrades until you solve whatever issue
caused you to roll back your environment.</para>
</step>
</substeps>
</step>
</procedure>
</section>
</chapter>

543
doc/openstack-ops/ch_ops_upstream.xml
View File

@ -1,543 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter version="5.0" xml:id="upstream_openstack"
xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:ns5="http://www.w3.org/1999/xhtml"
xmlns:ns4="http://www.w3.org/2000/svg"
xmlns:ns3="http://www.w3.org/1998/Math/MathML"
xmlns:ns="http://docbook.org/ns/docbook">
<?dbhtml stop-chunking?>
<title>Upstream OpenStack</title>
<para>OpenStack is founded on a thriving community that is a source of help
and welcomes your contributions. This chapter details some of the ways you
can interact with the others involved.</para>
<section xml:id="get_help">
<title>Getting Help</title>
<para>There are several avenues available for seeking assistance. The
quickest way is to help the community help you. Search the Q&amp;A sites,
mailing list archives, and bug lists for issues similar to yours. If you
can't find anything, follow the directions for reporting bugs or use one
of the channels for support, which are listed below.<indexterm
class="singular">
<primary>mailing lists</primary>
</indexterm><indexterm class="singular">
<primary>OpenStack</primary>
<secondary>documentation</secondary>
</indexterm><indexterm class="singular">
<primary>help, resources for</primary>
</indexterm><indexterm class="singular">
<primary>troubleshooting</primary>
<secondary>getting help</secondary>
</indexterm><indexterm class="singular">
<primary>OpenStack community</primary>
<secondary>getting help from</secondary>
</indexterm></para>
<para>Your first port of call should be the official OpenStack
documentation, found on <link
xlink:href="http://docs.openstack.org"></link>. You can get questions
answered on <link xlink:href="http://ask.openstack.org"></link>.</para>
<para><link xlink:href="https://wiki.openstack.org/wiki/Mailing_Lists">Mailing lists</link> are
also a great place to get help. The wiki page has more information about
the various lists. As an operator, the main lists you should be aware of
are:</para>
<variablelist>
<varlistentry>
<term><link xlink:href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack">General
list</link></term>
<listitem>
<para><emphasis>openstack@lists.openstack.org</emphasis>. The scope
of this list is the current state of OpenStack. This is a very
high-traffic mailing list, with many, many emails per day.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><link xlink:href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators">Operators
list</link></term>
<listitem>
<para><emphasis>openstack-operators@lists.openstack.org.</emphasis>
This list is intended for discussion among existing OpenStack cloud
operators, such as yourself. Currently, this list is relatively low
traffic, on the order of one email a day.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><link xlink:href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">Development
list</link></term>
<listitem>
<para><emphasis>openstack-dev@lists.openstack.org</emphasis>. The
scope of this list is the future state of OpenStack. This is a
high-traffic mailing list, with multiple emails per day.</para>
</listitem>
</varlistentry>
</variablelist>
<para>We recommend that you subscribe to the general list and the operator
list, although you must set up filters to manage the volume for the
general list. You'll also find links to the mailing list archives on the
mailing list wiki page, where you can search through the
discussions.</para>
<para><link xlink:href="https://wiki.openstack.org/wiki/IRC">Multiple IRC
channels</link> are available for general questions and developer
discussions. The general discussion channel is #openstack on
<emphasis>irc.freenode.net</emphasis>.</para>
</section>
<section xml:id="report_bugs">
<title>Reporting Bugs</title>
<para>As an operator, you are in a very good position to report unexpected
behavior with your cloud. Since OpenStack is flexible, you may be the only
individual to report a particular issue. Every issue is important to fix,
so it is essential to learn how to easily submit a bug report.<indexterm
class="singular">
<primary>maintenance/debugging</primary>
<secondary>reporting bugs</secondary>
</indexterm><indexterm class="singular">
<primary>bugs, reporting</primary>
</indexterm><indexterm class="singular">
<primary>OpenStack community</primary>
<secondary>reporting bugs</secondary>
</indexterm></para>
<para>All OpenStack projects use <link
xlink:href="https://launchpad.net/">Launchpad</link>&#160;for bug
tracking. You'll need to create an account on Launchpad before you can
submit a bug report.</para>
<para>Once you have a Launchpad account, reporting a bug is as simple as
identifying the project or projects that are causing the issue. Sometimes
this is more difficult than expected, but those working on the bug triage
are happy to help relocate issues if they are not in the right place
initially:</para>
<itemizedlist>
<listitem>
<para>Report a bug in <link
xlink:href="https://bugs.launchpad.net/nova/+filebug/+login">nova</link>.</para>
</listitem>
<listitem>
<para>Report a bug in <link
xlink:href="https://bugs.launchpad.net/python-novaclient/+filebug/+login">python-novaclient</link>.</para>
</listitem>
<listitem>
<para>Report a bug in <link
xlink:href="https://bugs.launchpad.net/swift/+filebug/+login">swift</link>.</para>
</listitem>
<listitem>
<para>Report a bug in <link
xlink:href="https://bugs.launchpad.net/python-swiftclient/+filebug/+login">python-swiftclient</link>.</para>
</listitem>
<listitem>
<para>Report a bug in <link
xlink:href="https://bugs.launchpad.net/glance/+filebug/+login">glance</link>.</para>
</listitem>
<listitem>
<para>Report a bug in <link
xlink:href="https://bugs.launchpad.net/python-glanceclient/+filebug/+login">python-glanceclient</link>.</para>
</listitem>
<listitem>
<para>Report a bug in <link
xlink:href="https://bugs.launchpad.net/keystone/+filebug/+login">keystone</link>.</para>
</listitem>
<listitem>
<para>Report a bug in <link
xlink:href="https://bugs.launchpad.net/python-keystoneclient/+filebug/+login">python-keystoneclient</link>.</para>
</listitem>
<listitem>
<para>Report a bug in <link
xlink:href="https://bugs.launchpad.net/neutron/+filebug/+login">neutron</link>.</para>
</listitem>
<listitem>
<para>Report a bug in <link
xlink:href="https://bugs.launchpad.net/python-neutronclient/+filebug/+login">python-neutronclient</link>.</para>
</listitem>
<listitem>
<para>Report a bug in <link
xlink:href="https://bugs.launchpad.net/cinder/+filebug/+login">cinder</link>.</para>
</listitem>
<listitem>
<para>Report a bug in <link
xlink:href="https://bugs.launchpad.net/python-cinderclient/+filebug/+login">python-cinderclient</link>.</para>
</listitem>
<listitem>
<para>Report a bug in <link
xlink:href="https://bugs.launchpad.net/manila/+filebug/+login">manila</link>.</para>
</listitem>
<listitem>
<para>Report a bug in <link
xlink:href="https://bugs.launchpad.net/python-manilaclient/+filebug/+login">python-manilaclient</link>.</para>
</listitem>
<listitem>
<para>Report a bug in <link
xlink:href="https://bugs.launchpad.net/python-openstackclient/+filebug/+login">python-openstackclient</link>.</para>
</listitem>
<listitem>
<para>Report a bug in <link
xlink:href="https://bugs.launchpad.net/horizon/+filebug/+login">horizon</link>.</para>
</listitem>
<listitem>
<para>Report a bug with the <link
xlink:href="https://bugs.launchpad.net/openstack-manuals/+filebug/+login">documentation</link>.</para>
</listitem>
<listitem>
<para>Report a bug with the <link
xlink:href="https://bugs.launchpad.net/openstack-api-site/+filebug/+login">API documentation</link>.</para>
</listitem>
</itemizedlist>
<para>To write a good bug report, the following process is essential.
First, search for the bug to make sure there is no bug already filed for
the same issue. If you find one, be sure to click on "This bug affects X
people. Does this bug affect you?" If you can't find the issue, then enter
the details of your report. It should at least include:</para>
<itemizedlist>
<listitem>
<para>The release, or milestone, or commit ID corresponding to the
software that you are running</para>
</listitem>
<listitem>
<para>The operating system and version where you've identified the
bug</para>
</listitem>
<listitem>
<para>Steps to reproduce the bug, including what went wrong</para>
</listitem>
<listitem>
<para>Description of the expected results instead of what you
saw</para>
</listitem>
<listitem>
<para>Portions of your log files so that you include only relevant
excerpts</para>
</listitem>
</itemizedlist>
<para>When you do this, the bug is created with:</para>
<itemizedlist>
<listitem>
<para>Status: <emphasis>New</emphasis></para>
</listitem>
</itemizedlist>
<para>In the bug comments, you can contribute instructions on how to fix a
given bug, and set it to <emphasis>Triaged</emphasis>. Or you can directly
fix it: assign the bug to yourself, set it to <emphasis>In
progress</emphasis>, branch the code, implement the fix, and propose your
change for merging. But let's not get ahead of ourselves; there are bug
triaging tasks as well.</para>
<section xml:id="confirm_priority">
<title>Confirming and Prioritizing</title>
<para>This stage is about checking that a bug is real and assessing its
impact. Some of these steps require bug supervisor rights (usually
limited to core teams). If the bug lacks information to properly
reproduce or assess the importance of the bug, the bug is set to:</para>
<itemizedlist>
<listitem>
<para>Status: <emphasis>Incomplete</emphasis></para>
</listitem>
</itemizedlist>
<para>Once you have reproduced the issue (or are 100 percent confident
that this is indeed a valid bug) and have permissions to do so,
set:</para>
<itemizedlist>
<listitem>
<para>Status: <emphasis>Confirmed</emphasis></para>
</listitem>
</itemizedlist>
<para>Core developers also prioritize the bug, based on its
impact:</para>
<itemizedlist>
<listitem>
<para>Importance: &lt;Bug impact&gt;</para>
</listitem>
</itemizedlist>
<para>The bug impacts are categorized as follows:</para>
<?hard-pagebreak ?>
<orderedlist>
<listitem>
<para><emphasis>Critical</emphasis> if the bug prevents a key
feature from working properly (regression) for all users (or without
a simple workaround) or results in data loss</para>
</listitem>
<listitem>
<para><emphasis>High</emphasis> if the bug prevents a key feature
from working properly for some users (or with a workaround)</para>
</listitem>
<listitem>
<para><emphasis>Medium</emphasis> if the bug prevents a secondary
feature from working properly</para>
</listitem>
<listitem>
<para><emphasis>Low</emphasis> if the bug is mostly cosmetic</para>
</listitem>
<listitem>
<para><emphasis>Wishlist</emphasis> if the bug is not really a bug
but rather a welcome change in behavior</para>
</listitem>
</orderedlist>
<para>If the bug contains the solution, or a patch, set the bug status
to <emphasis>Triaged</emphasis>.</para>
</section>
<section xml:id="bug_fixing">
<title>Bug Fixing</title>
<para>At this stage, a developer works on a fix. During that time, to
avoid duplicating the work, the developer should set:</para>
<itemizedlist>
<listitem>
<para>Status: <emphasis>In Progress</emphasis></para>
</listitem>
<listitem>
<para>Assignee: &lt;yourself&gt;</para>
</listitem>
</itemizedlist>
<para>When the fix is ready, the developer proposes a change and gets
the change reviewed.</para>
</section>
<section xml:id="after_change_is_accepted">
<title>After the Change Is Accepted</title>
<para>After the change is reviewed, accepted, and lands in master, it
automatically moves to:</para>
<itemizedlist>
<listitem>
<para>Status: <emphasis>Fix Committed</emphasis></para>
</listitem>
</itemizedlist>
<para>When the fix makes it into a milestone or release branch, it
automatically moves to:</para>
<itemizedlist>
<listitem>
<para>Milestone: Milestone the bug was fixed in</para>
</listitem>
<listitem>
<para>Status:&#160;<emphasis>Fix Released</emphasis></para>
</listitem>
</itemizedlist>
</section>
</section>
<section xml:id="openstack_community">
<title>Join the OpenStack Community</title>
<para>Since you've made it this far in the book, you should consider
becoming an official individual member of the community and <link
xlink:href="https://www.openstack.org/join/">join the OpenStack
Foundation</link>.&#160;The OpenStack Foundation is an independent body
providing shared resources to help achieve the OpenStack mission by
protecting, empowering, and promoting OpenStack software and the community
around it, including users, developers, and the entire ecosystem. We all
share the responsibility to make this community the best it can possibly
be, and signing up to be a member is the first step to participating. Like
the software, individual membership within the OpenStack Foundation is
free and accessible to anyone.<indexterm class="singular">
<primary>OpenStack community</primary>
<secondary>joining</secondary>
</indexterm></para>
</section>
<section xml:id="contribute_to_docs">
<title>How to Contribute to the Documentation</title>
<para>OpenStack documentation efforts encompass operator and administrator
docs, API docs, and user docs.<indexterm class="singular">
<primary>OpenStack community</primary>
<secondary>contributing to</secondary>
</indexterm></para>
<para>The genesis of this book was an in-person event, but now that the
book is in your hands, we want you to contribute to it. OpenStack
documentation follows the coding principles of iterative work, with bug
logging, investigating, and fixing.</para>
<para>Just like the code, <link
xlink:href="http://docs.openstack.org"></link> is updated constantly using
the Gerrit review system, with source stored in git.openstack.org in the <link
xlink:href="https://git.openstack.org/cgit/openstack/openstack-manuals/">openstack-manuals repository</link>
and the <link xlink:href="https://git.openstack.org/cgit/openstack/api-site/">api-site
repository</link>.</para>
<para>To review the documentation before it's published, go to the
OpenStack Gerrit server at&#160;<link
xlink:href="http://review.openstack.org"></link> and search for <link
xlink:href="https://review.openstack.org/#/q/status:open+project:openstack/openstack-manuals,n,z">project:openstack/openstack-manuals</link>
or <link
xlink:href="https://review.openstack.org/#/q/status:open+project:openstack/api-site,n,z">project:openstack/api-site</link>.</para>
<para>See the <link xlink:href="https://wiki.openstack.org/wiki/How_To_Contribute">How To Contribute
page on the wiki</link> for more information on the steps you need to take
to submit your first documentation review or change.</para>
</section>
<section xml:id="security_info">
<title>Security Information</title>
<para>As a community, we take security very seriously and follow a
specific process for reporting potential issues. We vigilantly pursue
fixes and regularly eliminate exposures. You can report security issues
you discover through this specific process. The OpenStack Vulnerability
Management Team is a very small group of experts in vulnerability
management drawn from the OpenStack community. The team's job is
facilitating the reporting of vulnerabilities, coordinating security fixes
and handling progressive disclosure of the vulnerability information.
Specifically, the team is responsible for the following
functions:<indexterm class="singular">
<primary>vulnerability tracking/management</primary>
</indexterm><indexterm class="singular">
<primary>security issues</primary>
<secondary>reporting/fixing vulnerabilities</secondary>
</indexterm><indexterm class="singular">
<primary>OpenStack community</primary>
<secondary>security information</secondary>
</indexterm></para>
<variablelist>
<varlistentry>
<term>Vulnerability management</term>
<listitem>
<para>All vulnerabilities discovered by community members (or users)
can be reported to the team.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Vulnerability tracking</term>
<listitem>
<para>The team will curate a set of vulnerability related issues in
the issue tracker. Some of these issues are private to the team and
the affected product leads, but once remediation is in place, all
vulnerabilities are public.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Responsible disclosure</term>
<listitem>
<para>As part of our commitment to work with the security community,
the team ensures that proper credit is given to security researchers
who responsibly report issues in OpenStack.</para>
</listitem>
</varlistentry>
</variablelist>
<para>We provide two ways to report issues to the OpenStack Vulnerability
Management Team, depending on how sensitive the issue is:</para>
<itemizedlist>
<listitem>
<para>Open a bug in Launchpad and mark it as a "security bug." This
makes the bug private and accessible to only the Vulnerability
Management Team.</para>
</listitem>
<listitem>
<para>If the issue is extremely sensitive, send an encrypted email to
one of the team's members. Find their GPG keys at <link
xlink:href="http://www.openstack.org/projects/openstack-security/">OpenStack
Security</link>.</para>
</listitem>
</itemizedlist>
<para>You can find the full list of security-oriented teams you can join
at <link xlink:href="https://wiki.openstack.org/wiki/SecurityTeams">Security Teams</link>. The
vulnerability management process is fully documented at <link
xlink:href="https://wiki.openstack.org/wiki/VulnerabilityManagement">Vulnerability
Management</link>.</para>
</section>
<section xml:id="additional_info">
<title>Finding Additional Information</title>
<para>In addition to this book, there are many other sources of
information about OpenStack. The&#160;<link
xlink:href="http://www.openstack.org/">OpenStack website</link> is a good
starting point, with&#160;<link
xlink:href="http://docs.openstack.org/">OpenStack
Docs</link>&#160;and&#160;<link
xlink:href="http://developer.openstack.org/">OpenStack API Docs</link> providing
technical documentation about OpenStack. The <link
xlink:href="https://wiki.openstack.org/wiki/Main_Page">OpenStack wiki</link> contains a lot
of general information that cuts across the OpenStack projects, including
a list of <link xlink:href="https://wiki.openstack.org/wiki/OperationsTools">recommended
tools</link>. Finally, there are a number of blogs aggregated
at&#160;<link xlink:href="http://planet.openstack.org/">Planet
OpenStack</link>.<indexterm class="singular">
<primary>OpenStack community</primary>
<secondary>additional information</secondary>
</indexterm></para>
</section>
</chapter>

2739
doc/openstack-ops/ch_ops_user_facing.xml
View File

File diff suppressed because it is too large Load Diff

BIN
doc/openstack-ops/cover.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 2.3 MiB

BIN
doc/openstack-ops/figures/Check_mark_23x20_02.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 3.0 KiB

60
doc/openstack-ops/figures/Check_mark_23x20_02.svg
View File

@ -1,60 +0,0 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://web.resource.org/cc/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
width="19.21315"
height="18.294994"
id="svg2"
sodipodi:version="0.32"
inkscape:version="0.45"
sodipodi:modified="true"
version="1.0">
<defs
id="defs4" />
<sodipodi:namedview
id="base"
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1.0"
gridtolerance="10000"
guidetolerance="10"
objecttolerance="10"
inkscape:pageopacity="0.0"
inkscape:pageshadow="2"
inkscape:zoom="7.9195959"
inkscape:cx="17.757032"
inkscape:cy="7.298821"
inkscape:document-units="px"
inkscape:current-layer="layer1"
inkscape:window-width="984"
inkscape:window-height="852"
inkscape:window-x="148"
inkscape:window-y="66" />
<metadata
id="metadata7">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
</cc:Work>
</rdf:RDF>
</metadata>
<g
inkscape:label="Layer 1"
inkscape:groupmode="layer"
id="layer1"
transform="translate(-192.905,-516.02064)">
<path
style="fill:#000000"
d="M 197.67968,534.31563 C 197.40468,534.31208 196.21788,532.53719 195.04234,530.37143 L 192.905,526.43368 L 193.45901,525.87968 C 193.76371,525.57497 194.58269,525.32567 195.27896,525.32567 L 196.5449,525.32567 L 197.18129,527.33076 L 197.81768,529.33584 L 202.88215,523.79451 C 205.66761,520.74678 208.88522,517.75085 210.03239,517.13691 L 212.11815,516.02064 L 207.90871,520.80282 C 205.59351,523.43302 202.45735,527.55085 200.93947,529.95355 C 199.42159,532.35625 197.95468,534.31919 197.67968,534.31563 z "
id="path2223" />
</g>
</svg>
Side by Side

Before

Width:  |  Height:  |  Size: 2.1 KiB

3
doc/openstack-ops/figures/network_packet_ping.svg
View File

File diff suppressed because one or more lines are too long
Side by Side

Before

Width:  |  Height:  |  Size: 8.9 KiB

1734
doc/openstack-ops/figures/neutron_packet_ping.svg
View File

File diff suppressed because it is too large Load Diff
Side by Side

Before

Width:  |  Height:  |  Size: 69 KiB

3
doc/openstack-ops/figures/os-ref-arch.svg
View File

File diff suppressed because one or more lines are too long
Side by Side

Before

Width:  |  Height:  |  Size: 20 KiB

3
doc/openstack-ops/figures/os_physical_network.svg
View File

File diff suppressed because one or more lines are too long
Side by Side

Before

Width:  |  Height:  |  Size: 11 KiB

BIN
doc/openstack-ops/figures/osog_0001.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 765 KiB

BIN
doc/openstack-ops/figures/osog_00in01.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 518 KiB

BIN
doc/openstack-ops/figures/osog_0101.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 39 KiB

BIN
doc/openstack-ops/figures/osog_0102.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 41 KiB

BIN
doc/openstack-ops/figures/osog_0103.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 196 KiB

BIN
doc/openstack-ops/figures/osog_0104.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 59 KiB

BIN
doc/openstack-ops/figures/osog_0105.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 99 KiB

BIN
doc/openstack-ops/figures/osog_0106.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 89 KiB

BIN
doc/openstack-ops/figures/osog_01in01.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 95 KiB

BIN
doc/openstack-ops/figures/osog_01in02.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 105 KiB

BIN
doc/openstack-ops/figures/osog_0201.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 42 KiB

Some files were not shown because too many files have changed in this diff Show More