Convert compute sections to rst
Converted the following files to RST: - section_compute-images-instances.xml - section_compute-networking-nova.xml - section_trusted-compute-pools.xml Consolidated several files into compute-system-admin.rst to resolve structure issues. Implements: blueprint reorganise-user-guides Change-Id: I1df41b34a2a9d1d31c28504960905462feee85bc
This commit is contained in:
Brian Moss
parent
8b903b3b2e
commit
30a1675a05
@ -1,382 +0,0 @@
|
|||||||
.. _section_configuring-compute-migrations:
|
|
||||||
|
|
||||||
====================
|
|
||||||
Configure migrations
|
|
||||||
====================
|
|
||||||
|
|
||||||
.. :ref:`_configuring-migrations-kvm-libvirt`
|
|
||||||
.. :ref:`_configuring-migrations-xenserver`
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
Only cloud administrators can perform live migrations. If your cloud
|
|
||||||
is configured to use cells, you can perform live migration within
|
|
||||||
but not between cells.
|
|
||||||
|
|
||||||
Migration enables an administrator to move a virtual-machine instance
|
|
||||||
from one compute host to another. This feature is useful when a compute
|
|
||||||
host requires maintenance. Migration can also be useful to redistribute
|
|
||||||
the load when many VM instances are running on a specific physical
|
|
||||||
machine.
|
|
||||||
|
|
||||||
The migration types are:
|
|
||||||
|
|
||||||
- **Non-live migration** (sometimes referred to simply as 'migration').
|
|
||||||
The instance is shut down for a period of time to be moved to another
|
|
||||||
hypervisor. In this case, the instance recognizes that it was
|
|
||||||
rebooted.
|
|
||||||
|
|
||||||
- **Live migration** (or 'true live migration'). Almost no instance
|
|
||||||
downtime. Useful when the instances must be kept running during the
|
|
||||||
migration. The different types of live migration are:
|
|
||||||
|
|
||||||
- **Shared storage-based live migration**. Both hypervisors have
|
|
||||||
access to shared storage.
|
|
||||||
|
|
||||||
- **Block live migration**. No shared storage is required.
|
|
||||||
Incompatible with read-only devices such as CD-ROMs and
|
|
||||||
`Configuration Drive (config\_drive) <http://docs.openstack.org/user-guide/cli_config_drive.html>`_.
|
|
||||||
|
|
||||||
- **Volume-backed live migration**. Instances are backed by volumes
|
|
||||||
rather than ephemeral disk, no shared storage is required, and
|
|
||||||
migration is supported (currently only available for libvirt-based
|
|
||||||
hypervisors).
|
|
||||||
|
|
||||||
The following sections describe how to configure your hosts and compute
|
|
||||||
nodes for migrations by using the KVM and XenServer hypervisors.
|
|
||||||
|
|
||||||
.. _configuring-migrations-kvm-libvirt:
|
|
||||||
|
|
||||||
KVM-Libvirt
|
|
||||||
~~~~~~~~~~~
|
|
||||||
|
|
||||||
.. :ref:`_configuring-migrations-kvm-shared-storage`
|
|
||||||
.. :ref:`_configuring-migrations-kvm-block-migration`
|
|
||||||
|
|
||||||
.. _configuring-migrations-kvm-shared-storage:
|
|
||||||
|
|
||||||
Shared storage
|
|
||||||
--------------
|
|
||||||
|
|
||||||
.. :ref:`_section_example-compute-install`
|
|
||||||
.. :ref:`_true-live-migration-kvm-libvirt`
|
|
||||||
|
|
||||||
**Prerequisites**
|
|
||||||
|
|
||||||
- **Hypervisor:** KVM with libvirt
|
|
||||||
|
|
||||||
- **Shared storage:** :file:`NOVA-INST-DIR/instances/` (for example,
|
|
||||||
:file:`/var/lib/nova/instances`) has to be mounted by shared storage.
|
|
||||||
This guide uses NFS but other options, including the
|
|
||||||
`OpenStack Gluster Connector <http://gluster.org/community/documentation//index.php/OSConnect>`_
|
|
||||||
are available.
|
|
||||||
|
|
||||||
- **Instances:** Instance can be migrated with iSCSI-based volumes.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
- Because the Compute service does not use the libvirt live
|
|
||||||
migration functionality by default, guests are suspended before
|
|
||||||
migration and might experience several minutes of downtime. For
|
|
||||||
details, see :ref:Enabling True Live Migration.
|
|
||||||
|
|
||||||
- This guide assumes the default value for ``instances_path`` in
|
|
||||||
your :file:`nova.conf` file (:file:`NOVA-INST-DIR/instances`). If you
|
|
||||||
have changed the ``state_path`` or ``instances_path`` variables,
|
|
||||||
modify the commands accordingly.
|
|
||||||
|
|
||||||
- You must specify ``vncserver_listen=0.0.0.0`` or live migration
|
|
||||||
will not work correctly.
|
|
||||||
|
|
||||||
- You must specify the ``instances_path`` in each node that runs
|
|
||||||
nova-compute. The mount point for ``instances_path`` must be the
|
|
||||||
same value for each node, or live migration will not work
|
|
||||||
correctly.
|
|
||||||
|
|
||||||
.. _section_example-compute-install:
|
|
||||||
|
|
||||||
Example Compute installation environment
|
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
||||||
|
|
||||||
- Prepare at least three servers. In this example, we refer to the
|
|
||||||
servers as ``HostA``, ``HostB``, and ``HostC``:
|
|
||||||
|
|
||||||
- ``HostA`` is the Cloud Controller, and should run these services:
|
|
||||||
nova-api, nova-scheduler, ``nova-network``, cinder-volume, and
|
|
||||||
``nova-objectstore``.
|
|
||||||
|
|
||||||
- ``HostB`` and ``HostC`` are the compute nodes that run
|
|
||||||
nova-compute.
|
|
||||||
|
|
||||||
Ensure that ``NOVA-INST-DIR`` (set with ``state_path`` in the
|
|
||||||
:file:`nova.conf` file) is the same on all hosts.
|
|
||||||
|
|
||||||
- In this example, ``HostA`` is the NFSv4 server that exports
|
|
||||||
``NOVA-INST-DIR/instances`` directory. ``HostB`` and ``HostC`` are
|
|
||||||
NFSv4 clients that mount ``HostA``.
|
|
||||||
|
|
||||||
**Configuring your system**
|
|
||||||
|
|
||||||
#. Configure your DNS or ``/etc/hosts`` and ensure it is consistent across
|
|
||||||
all hosts. Make sure that the three hosts can perform name resolution
|
|
||||||
with each other. As a test, use the :command:`ping` command to ping each host
|
|
||||||
from one another:
|
|
||||||
|
|
||||||
.. code:: console
|
|
||||||
|
|
||||||
$ ping HostA
|
|
||||||
$ ping HostB
|
|
||||||
$ ping HostC
|
|
||||||
|
|
||||||
#. Ensure that the UID and GID of your Compute and libvirt users are
|
|
||||||
identical between each of your servers. This ensures that the
|
|
||||||
permissions on the NFS mount works correctly.
|
|
||||||
|
|
||||||
#. Export ``NOVA-INST-DIR/instances`` from ``HostA``, and ensure it is
|
|
||||||
readable and writable by the Compute user on ``HostB`` and ``HostC``.
|
|
||||||
|
|
||||||
For more information, see: `SettingUpNFSHowTo <https://help.ubuntu.com/community/SettingUpNFSHowTo>`_
|
|
||||||
or `CentOS/Red Hat: Setup NFS v4.0 File Server <http://www.cyberciti.biz/faq/centos-fedora-rhel-nfs-v4-configuration/>`_
|
|
||||||
|
|
||||||
#. Configure the NFS server at ``HostA`` by adding the following line to
|
|
||||||
the :file:`/etc/exports` file:
|
|
||||||
|
|
||||||
.. code:: ini
|
|
||||||
|
|
||||||
NOVA-INST-DIR/instances HostA/255.255.0.0(rw,sync,fsid=0,no_root_squash)
|
|
||||||
|
|
||||||
Change the subnet mask (``255.255.0.0``) to the appropriate value to
|
|
||||||
include the IP addresses of ``HostB`` and ``HostC``. Then restart the
|
|
||||||
NFS server:
|
|
||||||
|
|
||||||
.. code:: console
|
|
||||||
|
|
||||||
# /etc/init.d/nfs-kernel-server restart
|
|
||||||
# /etc/init.d/idmapd restart
|
|
||||||
|
|
||||||
#. On both compute nodes, enable the 'execute/search' bit on your shared
|
|
||||||
directory to allow qemu to be able to use the images within the
|
|
||||||
directories. On all hosts, run the following command:
|
|
||||||
|
|
||||||
.. code:: console
|
|
||||||
|
|
||||||
$ chmod o+x NOVA-INST-DIR/instances
|
|
||||||
|
|
||||||
#. Configure NFS on ``HostB`` and ``HostC`` by adding the following line to
|
|
||||||
the :file:`/etc/fstab` file
|
|
||||||
|
|
||||||
.. code:: console
|
|
||||||
|
|
||||||
HostA:/ /NOVA-INST-DIR/instances nfs4 defaults 0 0
|
|
||||||
|
|
||||||
Ensure that you can mount the exported directory
|
|
||||||
|
|
||||||
.. code:: console
|
|
||||||
|
|
||||||
$ mount -a -v
|
|
||||||
|
|
||||||
Check that ``HostA`` can see the :file:`NOVA-INST-DIR/instances/`
|
|
||||||
directory
|
|
||||||
|
|
||||||
.. code:: console
|
|
||||||
|
|
||||||
$ ls -ld NOVA-INST-DIR/instances/
|
|
||||||
drwxr-xr-x 2 nova nova 4096 2012-05-19 14:34 nova-install-dir/instances/
|
|
||||||
|
|
||||||
Perform the same check on ``HostB`` and ``HostC``, paying special
|
|
||||||
attention to the permissions (Compute should be able to write)
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
:linenos:
|
|
||||||
|
|
||||||
$ ls -ld NOVA-INST-DIR/instances/
|
|
||||||
drwxr-xr-x 2 nova nova 4096 2012-05-07 14:34 nova-install-dir/instances/
|
|
||||||
|
|
||||||
$ df -k
|
|
||||||
Filesystem 1K-blocks Used Available Use% Mounted on
|
|
||||||
/dev/sda1 921514972 4180880 870523828 1% /
|
|
||||||
none 16498340 1228 16497112 1% /dev
|
|
||||||
none 16502856 0 16502856 0% /dev/shm
|
|
||||||
none 16502856 368 16502488 1% /var/run
|
|
||||||
none 16502856 0 16502856 0% /var/lock
|
|
||||||
none 16502856 0 16502856 0% /lib/init/rw
|
|
||||||
HostA: 921515008 101921792 772783104 12% /var/lib/nova/instances ( <--- this line is important.)
|
|
||||||
|
|
||||||
#. Update the libvirt configurations so that the calls can be made
|
|
||||||
securely. These methods enable remote access over TCP and are not
|
|
||||||
documented here.
|
|
||||||
|
|
||||||
- SSH tunnel to libvirtd's UNIX socket
|
|
||||||
|
|
||||||
- libvirtd TCP socket, with GSSAPI/Kerberos for auth+data encryption
|
|
||||||
|
|
||||||
- libvirtd TCP socket, with TLS for encryption and x509 client certs
|
|
||||||
for authentication
|
|
||||||
|
|
||||||
- libvirtd TCP socket, with TLS for encryption and Kerberos for
|
|
||||||
authentication
|
|
||||||
|
|
||||||
Restart libvirt. After you run the command, ensure that libvirt is
|
|
||||||
successfully restarted
|
|
||||||
|
|
||||||
.. code:: console
|
|
||||||
|
|
||||||
# stop libvirt-bin && start libvirt-bin
|
|
||||||
$ ps -ef | grep libvirt
|
|
||||||
root 1145 1 0 Nov27 ? 00:00:03 /usr/sbin/libvirtd -d -l\
|
|
||||||
|
|
||||||
#. Configure your firewall to allow libvirt to communicate between nodes.
|
|
||||||
By default, libvirt listens on TCP port 16509, and an ephemeral TCP
|
|
||||||
range from 49152 to 49261 is used for the KVM communications. Based on
|
|
||||||
the secure remote access TCP configuration you chose, be careful which
|
|
||||||
ports you open, and always understand who has access. For information
|
|
||||||
about ports that are used with libvirt,
|
|
||||||
see `the libvirt documentation <http://libvirt.org/remote.html#Remote_libvirtd_configuration>`_.
|
|
||||||
|
|
||||||
#. You can now configure options for live migration. In most cases, you
|
|
||||||
will not need to configure any options. The following chart is for
|
|
||||||
advanced users only.
|
|
||||||
|
|
||||||
.. TODO :include :: /../../common/tables/nova-livemigration.xml/
|
|
||||||
|
|
||||||
.. _true-live-migration-kvm-libvirt:
|
|
||||||
|
|
||||||
Enabling true live migration
|
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
||||||
|
|
||||||
Prior to the Kilo release, the Compute service did not use the libvirt
|
|
||||||
live migration function by default. To enable this function, add the
|
|
||||||
following line to the ``[libvirt]`` section of the :file:`nova.conf` file:
|
|
||||||
|
|
||||||
.. code:: ini
|
|
||||||
|
|
||||||
live_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE,VIR_MIGRATE_TUNNELLED
|
|
||||||
|
|
||||||
On versions older than Kilo, the Compute service does not use libvirt's
|
|
||||||
live migration by default because there is a risk that the migration
|
|
||||||
process will never end. This can happen if the guest operating system
|
|
||||||
uses blocks on the disk faster than they can be migrated.
|
|
||||||
|
|
||||||
.. _configuring-migrations-kvm-block-migration:
|
|
||||||
|
|
||||||
Block Migration
|
|
||||||
^^^^^^^^^^^^^^^
|
|
||||||
|
|
||||||
Configuring KVM for block migration is exactly the same as the above
|
|
||||||
configuration in :ref:`configuring-migrations-kvm-shared-storage`
|
|
||||||
the section called shared storage, except that ``NOVA-INST-DIR/instances``
|
|
||||||
is local to each host rather than shared. No NFS client or server
|
|
||||||
configuration is required.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
- To use block migration, you must use the :option:`--block-migrate`
|
|
||||||
parameter with the live migration command.
|
|
||||||
|
|
||||||
- Block migration is incompatible with read-only devices such as
|
|
||||||
CD-ROMs and `Configuration Drive (config_drive) <http://docs.openstack.org/user-guide/cli_config_drive.html>`_.
|
|
||||||
|
|
||||||
- Since the ephemeral drives are copied over the network in block
|
|
||||||
migration, migrations of instances with heavy I/O loads may never
|
|
||||||
complete if the drives are writing faster than the data can be
|
|
||||||
copied over the network.
|
|
||||||
|
|
||||||
.. _configuring-migrations-xenserver:
|
|
||||||
|
|
||||||
XenServer
|
|
||||||
~~~~~~~~~
|
|
||||||
|
|
||||||
.. :ref:Shared Storage
|
|
||||||
.. :ref:Block migration
|
|
||||||
|
|
||||||
.. _configuring-migrations-xenserver-shared-storage:
|
|
||||||
|
|
||||||
Shared storage
|
|
||||||
--------------
|
|
||||||
|
|
||||||
Prerequisites
|
|
||||||
^^^^^^^^^^^^^
|
|
||||||
|
|
||||||
- **Compatible XenServer hypervisors**. For more information, see the
|
|
||||||
`Requirements for Creating Resource Pools <http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#pooling_homogeneity_requirements>`_ section of the XenServer
|
|
||||||
Administrator's Guide.
|
|
||||||
|
|
||||||
- **Shared storage**. An NFS export, visible to all XenServer hosts.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
For the supported NFS versions, see the
|
|
||||||
`NFS VHD <http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#id1002701>`_
|
|
||||||
section of the XenServer Administrator's Guide.
|
|
||||||
|
|
||||||
To use shared storage live migration with XenServer hypervisors, the
|
|
||||||
hosts must be joined to a XenServer pool. To create that pool, a host
|
|
||||||
aggregate must be created with specific metadata. This metadata is used
|
|
||||||
by the XAPI plug-ins to establish the pool.
|
|
||||||
|
|
||||||
**Using shared storage live migrations with XenServer Hypervisors**
|
|
||||||
|
|
||||||
#. Add an NFS VHD storage to your master XenServer, and set it as the
|
|
||||||
default storage repository. For more information, see NFS VHD in the
|
|
||||||
XenServer Administrator's Guide.
|
|
||||||
|
|
||||||
#. Configure all compute nodes to use the default storage repository
|
|
||||||
(``sr``) for pool operations. Add this line to your :file:`nova.conf`
|
|
||||||
configuration files on all compute nodes:
|
|
||||||
|
|
||||||
.. code:: ini
|
|
||||||
|
|
||||||
sr_matching_filter=default-sr:true
|
|
||||||
|
|
||||||
#. Create a host aggregate. This command creates the aggregate, and then
|
|
||||||
displays a table that contains the ID of the new aggregate
|
|
||||||
|
|
||||||
.. code:: console
|
|
||||||
|
|
||||||
$ nova aggregate-create POOL_NAME AVAILABILITY_ZONE
|
|
||||||
|
|
||||||
Add metadata to the aggregate, to mark it as a hypervisor pool
|
|
||||||
|
|
||||||
.. code:: console
|
|
||||||
|
|
||||||
$ nova aggregate-set-metadata AGGREGATE_ID hypervisor_pool=true
|
|
||||||
|
|
||||||
$ nova aggregate-set-metadata AGGREGATE_ID operational_state=created
|
|
||||||
|
|
||||||
Make the first compute node part of that aggregate
|
|
||||||
|
|
||||||
.. code:: console
|
|
||||||
|
|
||||||
$ nova aggregate-add-host AGGREGATE_ID MASTER_COMPUTE_NAME
|
|
||||||
|
|
||||||
The host is now part of a XenServer pool.
|
|
||||||
|
|
||||||
#. Add hosts to the pool
|
|
||||||
|
|
||||||
.. code:: console
|
|
||||||
|
|
||||||
$ nova aggregate-add-host AGGREGATE_ID COMPUTE_HOST_NAME
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
The added compute node and the host will shut down to join the host
|
|
||||||
to the XenServer pool. The operation will fail if any server other
|
|
||||||
than the compute node is running or suspended on the host.
|
|
||||||
|
|
||||||
.. _configuring-migrations-xenserver-block-migration:
|
|
||||||
|
|
||||||
Block migration
|
|
||||||
^^^^^^^^^^^^^^^
|
|
||||||
|
|
||||||
- **Compatible XenServer hypervisors**.
|
|
||||||
The hypervisors must support the Storage XenMotion feature.
|
|
||||||
See your XenServer manual to make sure your edition
|
|
||||||
has this feature.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
- To use block migration, you must use the :option:`--block-migrate`
|
|
||||||
parameter with the live migration command.
|
|
||||||
|
|
||||||
- Block migration works only with EXT local storage storage
|
|
||||||
repositories, and the server must not have any volumes attached.
|
|
||||||
@ -1,120 +0,0 @@
|
|||||||
.. highlight:: ini
|
|
||||||
:linenothreshold: 5
|
|
||||||
|
|
||||||
.. _configuring-compute-service-groups:
|
|
||||||
|
|
||||||
================================
|
|
||||||
Configure Compute service groups
|
|
||||||
================================
|
|
||||||
|
|
||||||
The Compute service must know the status of each compute node to
|
|
||||||
effectively manage and use them. This can include events like a user
|
|
||||||
launching a new VM, the scheduler sending a request to a live node, or a
|
|
||||||
query to the ServiceGroup API to determine if a node is live.
|
|
||||||
|
|
||||||
When a compute worker running the nova-compute daemon starts, it calls
|
|
||||||
the join API to join the compute group. Any service (such as the
|
|
||||||
scheduler) can query the group's membership and the status of its nodes.
|
|
||||||
Internally, the ServiceGroup client driver automatically updates the
|
|
||||||
compute worker status.
|
|
||||||
|
|
||||||
.. _database-servicegroup-driver:
|
|
||||||
|
|
||||||
Database ServiceGroup driver
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
By default, Compute uses the database driver to track if a node is live.
|
|
||||||
In a compute worker, this driver periodically sends a ``db update``
|
|
||||||
command to the database, saying “I'm OK” with a timestamp. Compute uses
|
|
||||||
a pre-defined timeout (``service_down_time``) to determine if a node is
|
|
||||||
dead.
|
|
||||||
|
|
||||||
The driver has limitations, which can be problematic depending on your
|
|
||||||
environment. If a lot of compute worker nodes need to be checked, the
|
|
||||||
database can be put under heavy load, which can cause the timeout to
|
|
||||||
trigger, and a live node could incorrectly be considered dead. By
|
|
||||||
default, the timeout is 60 seconds. Reducing the timeout value can help
|
|
||||||
in this situation, but you must also make the database update more
|
|
||||||
frequently, which again increases the database workload.
|
|
||||||
|
|
||||||
The database contains data that is both transient (such as whether the
|
|
||||||
node is alive) and persistent (such as entries for VM owners). With the
|
|
||||||
ServiceGroup abstraction, Compute can treat each type separately.
|
|
||||||
|
|
||||||
.. _zookeeper-servicegroup-driver:
|
|
||||||
|
|
||||||
ZooKeeper ServiceGroup driver
|
|
||||||
-----------------------------
|
|
||||||
|
|
||||||
The ZooKeeper ServiceGroup driver works by using ZooKeeper ephemeral
|
|
||||||
nodes. ZooKeeper, unlike databases, is a distributed system, with its
|
|
||||||
load divided among several servers. On a compute worker node, the driver
|
|
||||||
can establish a ZooKeeper session, then create an ephemeral znode in the
|
|
||||||
group directory. Ephemeral znodes have the same lifespan as the session.
|
|
||||||
If the worker node or the nova-compute daemon crashes, or a network
|
|
||||||
partition is in place between the worker and the ZooKeeper server
|
|
||||||
quorums, the ephemeral znodes are removed automatically. The driver
|
|
||||||
can be given group membership by running the :command:`ls` command in the
|
|
||||||
group directory.
|
|
||||||
|
|
||||||
The ZooKeeper driver requires the ZooKeeper servers and client
|
|
||||||
libraries. Setting up ZooKeeper servers is outside the scope of this
|
|
||||||
guide (for more information, see `Apache Zookeeper <http://zookeeper.apache.org/>`_). These client-side
|
|
||||||
Python libraries must be installed on every compute node:
|
|
||||||
|
|
||||||
**python-zookeeper**
|
|
||||||
The official Zookeeper Python binding
|
|
||||||
|
|
||||||
**evzookeeper**
|
|
||||||
This library makes the binding work with the eventlet threading model.
|
|
||||||
|
|
||||||
This example assumes the ZooKeeper server addresses and ports are
|
|
||||||
``192.168.2.1:2181``, ``192.168.2.2:2181``, and ``192.168.2.3:2181``.
|
|
||||||
|
|
||||||
These values in the :file:`/etc/nova/nova.conf` file are required on every
|
|
||||||
node for the ZooKeeper driver:
|
|
||||||
|
|
||||||
.. code:: ini
|
|
||||||
|
|
||||||
# Driver for the ServiceGroup service
|
|
||||||
servicegroup_driver="zk"
|
|
||||||
|
|
||||||
[zookeeper]
|
|
||||||
address="192.168.2.1:2181,192.168.2.2:2181,192.168.2.3:2181"
|
|
||||||
|
|
||||||
To customize the Compute Service groups, use these configuration option
|
|
||||||
settings:
|
|
||||||
|
|
||||||
.. TODO ../../common/tables/nova-zookeeper.xml
|
|
||||||
|
|
||||||
.. _memcache-servicegroup-driver:
|
|
||||||
|
|
||||||
Memcache ServiceGroup driver
|
|
||||||
----------------------------
|
|
||||||
|
|
||||||
The memcache ServiceGroup driver uses memcached, a distributed memory
|
|
||||||
object caching system that is used to increase site performance. For
|
|
||||||
more details, see `memcached.org <http://memcached.org/>`_.
|
|
||||||
|
|
||||||
To use the memcache driver, you must install memcached. You might
|
|
||||||
already have it installed, as the same driver is also used for the
|
|
||||||
OpenStack Object Storage and OpenStack dashboard. If you need to install
|
|
||||||
memcached, see the instructions in the `OpenStack Installation Guide <http://docs.openstack.org/>`_.
|
|
||||||
|
|
||||||
These values in the :file:`/etc/nova/nova.conf` file are required on every
|
|
||||||
node for the memcache driver:
|
|
||||||
|
|
||||||
.. code:: ini
|
|
||||||
|
|
||||||
# Driver for the ServiceGroup service
|
|
||||||
servicegroup_driver="mc"
|
|
||||||
|
|
||||||
# Memcached servers. Use either a list of memcached servers to use for
|
|
||||||
caching (list value),
|
|
||||||
# or "<None>" for in-process caching (default).
|
|
||||||
memcached_servers=<None>
|
|
||||||
|
|
||||||
# Timeout; maximum time since last check-in for up service
|
|
||||||
(integer value).
|
|
||||||
# Helps to define whether a node is dead
|
|
||||||
service_down_time=60
|
|
||||||
@ -4,9 +4,6 @@ Images and instances
|
|||||||
|
|
||||||
.. TODO (bmoss)
|
.. TODO (bmoss)
|
||||||
|
|
||||||
compute-image-mgt.rst
|
|
||||||
compute-instance-building-blocks.rst
|
|
||||||
compute-instance-mgt-tools.rst
|
|
||||||
instance-scheduling-constraints.rst
|
instance-scheduling-constraints.rst
|
||||||
|
|
||||||
|
|
||||||
@ -39,14 +36,14 @@ flavors that you can edit or add to.
|
|||||||
services <http://docs.openstack.org/kilo/config-reference/content/ch_configuring-openstack-image-service.html>`__
|
services <http://docs.openstack.org/kilo/config-reference/content/ch_configuring-openstack-image-service.html>`__
|
||||||
section of the OpenStack Configuration Reference.
|
section of the OpenStack Configuration Reference.
|
||||||
|
|
||||||
- For more information about flavors, see ? or
|
- For more information about flavors, see :ref:`compute-flavors` or
|
||||||
`Flavors <http://docs.openstack.org/openstack-ops/content/flavors.html>`__
|
`Flavors <http://docs.openstack.org/openstack-ops/content/flavors.html>`__
|
||||||
in the OpenStack Operations Guide.
|
in the OpenStack Operations Guide.
|
||||||
|
|
||||||
You can add and remove additional resources from running instances, such
|
You can add and remove additional resources from running instances, such
|
||||||
as persistent volume storage, or public IP addresses. The example used
|
as persistent volume storage, or public IP addresses. The example used
|
||||||
in this chapter is of a typical virtual system within an OpenStack
|
in this chapter is of a typical virtual system within an OpenStack
|
||||||
cloud. It uses the cinder-volume service, which provides persistent
|
cloud. It uses the ``cinder-volume`` service, which provides persistent
|
||||||
block storage, instead of the ephemeral storage provided by the selected
|
block storage, instead of the ephemeral storage provided by the selected
|
||||||
instance flavor.
|
instance flavor.
|
||||||
|
|
||||||
@ -54,14 +51,14 @@ This diagram shows the system state prior to launching an instance. The
|
|||||||
image store, fronted by the Image service (glance) has a number of
|
image store, fronted by the Image service (glance) has a number of
|
||||||
predefined images. Inside the cloud, a compute node contains the
|
predefined images. Inside the cloud, a compute node contains the
|
||||||
available vCPU, memory, and local disk resources. Additionally, the
|
available vCPU, memory, and local disk resources. Additionally, the
|
||||||
cinder-volume service provides a number of predefined volumes.
|
``cinder-volume`` service provides a number of predefined volumes.
|
||||||
|
|
||||||
|Base image state with no running instances|
|
|Base image state with no running instances|
|
||||||
|
|
||||||
To launch an instance select an image, flavor, and any optional
|
To launch an instance select an image, flavor, and any optional
|
||||||
attributes. The selected flavor provides a root volume, labeled ``vda``
|
attributes. The selected flavor provides a root volume, labeled ``vda``
|
||||||
in this diagram, and additional ephemeral storage, labeled ``vdb``. In
|
in this diagram, and additional ephemeral storage, labeled ``vdb``. In
|
||||||
this example, the cinder-volume store is mapped to the third virtual
|
this example, the ``cinder-volume`` store is mapped to the third virtual
|
||||||
disk on this instance, ``vdc``.
|
disk on this instance, ``vdc``.
|
||||||
|
|
||||||
|Instance creation from image and runtime state|
|
|Instance creation from image and runtime state|
|
||||||
@ -74,8 +71,8 @@ images, as less data needs to be copied across the network.
|
|||||||
A new empty ephemeral disk is also created, labeled ``vdb`` in this
|
A new empty ephemeral disk is also created, labeled ``vdb`` in this
|
||||||
diagram. This disk is destroyed when you delete the instance.
|
diagram. This disk is destroyed when you delete the instance.
|
||||||
|
|
||||||
The compute node connects to the attached cinder-volume using ISCSI. The
|
The compute node connects to the attached ``cinder-volume`` using ISCSI. The
|
||||||
cinder-volume is mapped to the third disk, labeled ``vdc`` in this
|
``cinder-volume`` is mapped to the third disk, labeled ``vdc`` in this
|
||||||
diagram. After the compute node provisions the vCPU and memory
|
diagram. After the compute node provisions the vCPU and memory
|
||||||
resources, the instance boots up from root volume ``vda``. The instance
|
resources, the instance boots up from root volume ``vda``. The instance
|
||||||
runs, and changes data on the disks (highlighted in red on the diagram).
|
runs, and changes data on the disks (highlighted in red on the diagram).
|
||||||
@ -98,6 +95,65 @@ process.
|
|||||||
|
|
||||||
|End state of image and volume after instance exits|
|
|End state of image and volume after instance exits|
|
||||||
|
|
||||||
|
|
||||||
|
Image management
|
||||||
|
~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
The OpenStack Image service discovers, registers, and retrieves virtual
|
||||||
|
machine images. The service also includes a RESTful API that allows you
|
||||||
|
to query VM image metadata and retrieve the actual image with HTTP
|
||||||
|
requests. For more information about the API, see the `OpenStack API
|
||||||
|
Complete Reference <http://developer.openstack.org/api-ref.html>`__ and
|
||||||
|
the `Python
|
||||||
|
API <http://docs.openstack.org/developer/python-glanceclient/>`__.
|
||||||
|
|
||||||
|
The OpenStack Image service can be controlled using a command-line tool.
|
||||||
|
For more information about using the OpenStack Image command-line tool,
|
||||||
|
see the `Manage
|
||||||
|
Images <http://docs.openstack.org/user-guide/common/cli_manage_images.html>`__
|
||||||
|
section in the OpenStack End User Guide.
|
||||||
|
|
||||||
|
Virtual images that have been made available through the Image service
|
||||||
|
can be stored in a variety of ways. In order to use these services, you
|
||||||
|
must have a working installation of the Image service, with a working
|
||||||
|
endpoint, and users that have been created in OpenStack Identity.
|
||||||
|
Additionally, you must meet the environment variables required by the
|
||||||
|
Compute and Image service clients.
|
||||||
|
|
||||||
|
The Image service supports these back-end stores:
|
||||||
|
|
||||||
|
File system
|
||||||
|
The OpenStack Image service stores virtual machine images in the
|
||||||
|
file system back end by default. This simple back end writes image
|
||||||
|
files to the local file system.
|
||||||
|
|
||||||
|
Object Storage
|
||||||
|
The OpenStack highly available service for storing objects.
|
||||||
|
|
||||||
|
Block Storage
|
||||||
|
The OpenStack highly available service for storing blocks.
|
||||||
|
|
||||||
|
VMware
|
||||||
|
ESX/ESXi or vCenter Server target system.
|
||||||
|
|
||||||
|
S3
|
||||||
|
The Amazon S3 service.
|
||||||
|
|
||||||
|
HTTP
|
||||||
|
OpenStack Image service can read virtual machine images that are
|
||||||
|
available on the Internet using HTTP. This store is read only.
|
||||||
|
|
||||||
|
RADOS block device (RBD)
|
||||||
|
Stores images inside of a Ceph storage cluster using Ceph's RBD
|
||||||
|
interface.
|
||||||
|
|
||||||
|
Sheepdog
|
||||||
|
A distributed storage system for QEMU/KVM.
|
||||||
|
|
||||||
|
GridFS
|
||||||
|
Stores images using MongoDB.
|
||||||
|
|
||||||
|
|
||||||
Image properties and property protection
|
Image properties and property protection
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
An image property is a key and value pair that the cloud administrator
|
An image property is a key and value pair that the cloud administrator
|
||||||
@ -280,6 +336,97 @@ Information on the configuration options for caching on compute nodes
|
|||||||
can be found in the `Configuration
|
can be found in the `Configuration
|
||||||
Reference <http://docs.openstack.org/kilo/config-reference/content/>`__.
|
Reference <http://docs.openstack.org/kilo/config-reference/content/>`__.
|
||||||
|
|
||||||
|
Instance building blocks
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
In OpenStack, the base operating system is usually copied from an image
|
||||||
|
stored in the OpenStack Image service. This results in an ephemeral
|
||||||
|
instance that starts from a known template state and loses all
|
||||||
|
accumulated states on shutdown.
|
||||||
|
|
||||||
|
You can also put an operating system on a persistent volume in Compute
|
||||||
|
or the Block Storage volume system. This gives a more traditional,
|
||||||
|
persistent system that accumulates states that are preserved across
|
||||||
|
restarts. To get a list of available images on your system, run:
|
||||||
|
|
||||||
|
.. code:: console
|
||||||
|
|
||||||
|
$ nova image-list
|
||||||
|
+---------------------------+------------------+--------+----------------+
|
||||||
|
| ID | Name | Status | Server |
|
||||||
|
+---------------------------+------------------+--------+----------------+
|
||||||
|
| aee1d242-730f-431f-88c1- | | | |
|
||||||
|
| 87630c0f07ba | Ubuntu 14.04 | | |
|
||||||
|
| | cloudimg amd64 | ACTIVE | |
|
||||||
|
| 0b27baa1-0ca6-49a7-b3f4- | | | |
|
||||||
|
| 48388e440245 | Ubuntu 14.10 | | |
|
||||||
|
| | cloudimg amd64 | ACTIVE | |
|
||||||
|
| df8d56fc-9cea-4dfd-a8d3- | | | |
|
||||||
|
| 28764de3cb08 | jenkins | ACTIVE | |
|
||||||
|
+---------------------------+------------------+--------+----------------+
|
||||||
|
|
||||||
|
The displayed image attributes are:
|
||||||
|
|
||||||
|
``ID``
|
||||||
|
Automatically generated UUID of the image.
|
||||||
|
|
||||||
|
``Name``
|
||||||
|
Free form, human-readable name for the image.
|
||||||
|
|
||||||
|
``Status``
|
||||||
|
The status of the image. Images marked ``ACTIVE`` are available for
|
||||||
|
use.
|
||||||
|
|
||||||
|
``Server``
|
||||||
|
For images that are created as snapshots of running instances, this
|
||||||
|
is the UUID of the instance the snapshot derives from. For uploaded
|
||||||
|
images, this field is blank.
|
||||||
|
|
||||||
|
Virtual hardware templates are called ``flavors``. The default
|
||||||
|
installation provides five predefined flavors.
|
||||||
|
|
||||||
|
For a list of flavors that are available on your system, run:
|
||||||
|
|
||||||
|
.. code:: console
|
||||||
|
|
||||||
|
$ nova flavor-list
|
||||||
|
+----+----------+----------+-----+----------+-----+------+------------+----------+
|
||||||
|
| ID | Name | Memory_MB| Disk| Ephemeral| Swap| VCPUs| RXTX_Factor| Is_Public|
|
||||||
|
+----+----------+----------+-----+----------+-----+------+------------+----------+
|
||||||
|
| 1 | m1.tiny | 512 | 1 | 0 | | 1 | 1.0 | True |
|
||||||
|
| 2 | m1.small | 2048 | 20 | 0 | | 1 | 1.0 | True |
|
||||||
|
| 3 | m1.medium| 4096 | 40 | 0 | | 2 | 1.0 | True |
|
||||||
|
| 4 | m1.large | 8192 | 80 | 0 | | 4 | 1.0 | True |
|
||||||
|
| 5 | m1.xlarge| 16384 | 160 | 0 | | 8 | 1.0 | True |
|
||||||
|
+----+----------+----------+-----+----------+-----+------+------------+----------+
|
||||||
|
|
||||||
|
By default, administrative users can configure the flavors. You can
|
||||||
|
change this behavior by redefining the access controls for
|
||||||
|
``compute_extension:flavormanage`` in :file:`/etc/nova/policy.json` on the
|
||||||
|
``compute-api`` server.
|
||||||
|
|
||||||
|
|
||||||
|
Instance management tools
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
OpenStack provides command-line, web interface, and API-based instance
|
||||||
|
management tools. Third-party management tools are also available, using
|
||||||
|
either the native API or the provided EC2-compatible API.
|
||||||
|
|
||||||
|
The OpenStack python-novaclient package provides a basic command-line
|
||||||
|
utility, which uses the :command:`nova` command. This is available as a native
|
||||||
|
package for most Linux distributions, or you can install the latest
|
||||||
|
version using the pip python package installer:
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
|
# pip install python-novaclient
|
||||||
|
|
||||||
|
For more information about python-novaclient and other command-line
|
||||||
|
tools, see the `OpenStack End User
|
||||||
|
Guide <http://docs.openstack.org/user-guide/index.html>`__.
|
||||||
|
|
||||||
|
|
||||||
Control where instances run
|
Control where instances run
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
The `OpenStack Configuration
|
The `OpenStack Configuration
|
||||||
|
|||||||
1011
doc/admin-guide-cloud-rst/source/compute-networking-nova.rst
Normal file
1011
doc/admin-guide-cloud-rst/source/compute-networking-nova.rst
Normal file
File diff suppressed because it is too large
Load Diff
@ -1,333 +0,0 @@
|
|||||||
.. _section_nova-compute-node-down:
|
|
||||||
|
|
||||||
==================================
|
|
||||||
Recover from a failed compute node
|
|
||||||
==================================
|
|
||||||
|
|
||||||
If Compute is deployed with a shared file system, and a node fails,
|
|
||||||
there are several methods to quickly recover from the failure. This
|
|
||||||
section discusses manual recovery.
|
|
||||||
|
|
||||||
.. TODO ../../common/section_cli_nova_evacuate.xml
|
|
||||||
|
|
||||||
.. _nova-compute-node-down-manual-recovery:
|
|
||||||
|
|
||||||
Manual Recovery
|
|
||||||
~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
To recover a KVM or libvirt compute node, see
|
|
||||||
the section called :ref:`nova-compute-node-down-manual-recovery`. For
|
|
||||||
all other hypervisors, use this procedure:
|
|
||||||
|
|
||||||
**Recovering from a failed compute node manually**
|
|
||||||
|
|
||||||
#. Identify the VMs on the affected hosts. To do this, you can use a
|
|
||||||
combination of ``nova list`` and ``nova show`` or
|
|
||||||
``euca-describe-instances``. For example, this command displays
|
|
||||||
information about instance i-000015b9 that is running on node np-rcc54:
|
|
||||||
|
|
||||||
.. code:: console
|
|
||||||
|
|
||||||
$ euca-describe-instances
|
|
||||||
i-000015b9 at3-ui02 running nectarkey (376, np-rcc54) 0 m1.xxlarge 2012-06-19T00:48:11.000Z 115.146.93.60
|
|
||||||
|
|
||||||
#. Query the Compute database to check the status of the host. This example
|
|
||||||
converts an EC2 API instance ID into an OpenStack ID. If you use the
|
|
||||||
:command:`nova` commands, you can substitute the ID directly (the output in
|
|
||||||
this example has been truncated):
|
|
||||||
|
|
||||||
.. code:: ini
|
|
||||||
|
|
||||||
mysql> SELECT * FROM instances WHERE id = CONV('15b9', 16, 10) \G;
|
|
||||||
*************************** 1. row ***************************
|
|
||||||
created_at: 2012-06-19 00:48:11
|
|
||||||
updated_at: 2012-07-03 00:35:11
|
|
||||||
deleted_at: NULL
|
|
||||||
...
|
|
||||||
id: 5561
|
|
||||||
...
|
|
||||||
power_state: 5
|
|
||||||
vm_state: shutoff
|
|
||||||
...
|
|
||||||
hostname: at3-ui02
|
|
||||||
host: np-rcc54
|
|
||||||
...
|
|
||||||
uuid: 3f57699a-e773-4650-a443-b4b37eed5a06
|
|
||||||
...
|
|
||||||
task_state: NULL
|
|
||||||
...
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
The credentials for your database can be found in :file:`/etc/nova.conf`.
|
|
||||||
|
|
||||||
#. Decide which compute host the affected VM should be moved to, and run
|
|
||||||
this database command to move the VM to the new host:
|
|
||||||
|
|
||||||
.. code:: console
|
|
||||||
|
|
||||||
mysql> UPDATE instances SET host = 'np-rcc46' WHERE uuid = '3f57699a-e773-4650-a443-b4b37eed5a06';
|
|
||||||
|
|
||||||
#. If you are using a hypervisor that relies on libvirt (such as KVM),
|
|
||||||
update the :file:`libvirt.xml` file (found in
|
|
||||||
:file:`/var/lib/nova/instances/[instance ID]`) with these changes:
|
|
||||||
|
|
||||||
- Change the ``DHCPSERVER`` value to the host IP address of the new
|
|
||||||
compute host.
|
|
||||||
|
|
||||||
- Update the VNC IP to `0.0.0.0`
|
|
||||||
|
|
||||||
#. Reboot the VM:
|
|
||||||
|
|
||||||
.. code:: console
|
|
||||||
|
|
||||||
$ nova reboot 3f57699a-e773-4650-a443-b4b37eed5a06
|
|
||||||
|
|
||||||
The database update and :command:`nova reboot` command should be all that is
|
|
||||||
required to recover a VM from a failed host. However, if you continue to
|
|
||||||
have problems try recreating the network filter configuration using
|
|
||||||
``virsh``, restarting the Compute services, or updating the ``vm_state``
|
|
||||||
and ``power_state`` in the Compute database.
|
|
||||||
|
|
||||||
.. _section_nova-uid-mismatch:
|
|
||||||
|
|
||||||
**Recover from a UID/GID mismatch**
|
|
||||||
|
|
||||||
In some cases, files on your compute node can end up using the wrong UID
|
|
||||||
or GID. This can happen when running OpenStack Compute, using a shared
|
|
||||||
file system, or with an automated configuration tool. This can cause a
|
|
||||||
number of problems, such as inability to perform live migrations, or
|
|
||||||
start virtual machines.
|
|
||||||
|
|
||||||
This procedure runs on nova-compute hosts, based on the KVM hypervisor:
|
|
||||||
|
|
||||||
#. Set the nova UID in :file:`/etc/passwd` to the same number on all hosts (for
|
|
||||||
example, 112).
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
Make sure you choose UIDs or GIDs that are not in use for other
|
|
||||||
users or groups.
|
|
||||||
|
|
||||||
#. Set the ``libvirt-qemu`` UID in :file:`/etc/passwd` to the same number on
|
|
||||||
all hosts (for example, 119).
|
|
||||||
|
|
||||||
#. Set the ``nova`` group in :file:`/etc/group` file to the same number on all
|
|
||||||
hosts (for example, 120).
|
|
||||||
|
|
||||||
#. Set the ``libvirtd`` group in :file:`/etc/group` file to the same number on
|
|
||||||
all hosts (for example, 119).
|
|
||||||
|
|
||||||
#. Stop the services on the compute node.
|
|
||||||
|
|
||||||
#. Change all the files owned by user or group nova. For example:
|
|
||||||
|
|
||||||
.. code:: console
|
|
||||||
|
|
||||||
# find / -uid 108 -exec chown nova {} \;
|
|
||||||
# note the 108 here is the old nova UID before the change
|
|
||||||
# find / -gid 120 -exec chgrp nova {} \;
|
|
||||||
|
|
||||||
#. Repeat all steps for the :file:`libvirt-qemu` files, if required.
|
|
||||||
|
|
||||||
#. Restart the services.
|
|
||||||
|
|
||||||
#. Run the :command:`find` command to verify that all files use the correct
|
|
||||||
identifiers.
|
|
||||||
|
|
||||||
.. _section_nova-disaster-recovery-process:
|
|
||||||
|
|
||||||
Recover cloud after disaster
|
|
||||||
----------------------------
|
|
||||||
|
|
||||||
This section covers procedures for managing your cloud after a disaster,
|
|
||||||
and backing up persistent storage volumes. Backups are mandatory, even
|
|
||||||
outside of disaster scenarios.
|
|
||||||
|
|
||||||
For a definition of a disaster recovery plan (DRP), see
|
|
||||||
`http://en.wikipedia.org/wiki/Disaster\_Recovery\_Plan <http://en.wikipedia.org/wiki/Disaster_Recovery_Plan>`_.
|
|
||||||
|
|
||||||
A disaster could happen to several components of your architecture (for
|
|
||||||
example, a disk crash, network loss, or a power failure). In this
|
|
||||||
example, the following components are configured:
|
|
||||||
|
|
||||||
- A cloud controller (nova-api, nova-objectstore, nova-network)
|
|
||||||
|
|
||||||
- A compute node (nova-compute)
|
|
||||||
|
|
||||||
- A storage area network (SAN) used by OpenStack Block Storage
|
|
||||||
(cinder-volumes)
|
|
||||||
|
|
||||||
The worst disaster for a cloud is power loss, which applies to all three
|
|
||||||
components. Before a power loss:
|
|
||||||
|
|
||||||
- Create an active iSCSI session from the SAN to the cloud controller
|
|
||||||
(used for the ``cinder-volumes`` LVM's VG).
|
|
||||||
|
|
||||||
- Create an active iSCSI session from the cloud controller to the compute
|
|
||||||
node (managed by cinder-volume).
|
|
||||||
|
|
||||||
- Create an iSCSI session for every volume (so 14 EBS volumes requires 14
|
|
||||||
iSCSI sessions).
|
|
||||||
|
|
||||||
- Create iptables or ebtables rules from the cloud controller to the
|
|
||||||
compute node. This allows access from the cloud controller to the
|
|
||||||
running instance.
|
|
||||||
|
|
||||||
- Save the current state of the database, the current state of the running
|
|
||||||
instances, and the attached volumes (mount point, volume ID, volume
|
|
||||||
status, etc), at least from the cloud controller to the compute node.
|
|
||||||
|
|
||||||
After power is recovered and all hardware components have restarted:
|
|
||||||
|
|
||||||
- The iSCSI session from the SAN to the cloud no longer exists.
|
|
||||||
|
|
||||||
- The iSCSI session from the cloud controller to the compute node no
|
|
||||||
longer exists.
|
|
||||||
|
|
||||||
- The iptables and ebtables from the cloud controller to the compute
|
|
||||||
node are recreated. This is because nova-network reapplies
|
|
||||||
configurations on boot.
|
|
||||||
|
|
||||||
- Instances are no longer running.
|
|
||||||
|
|
||||||
Note that instances will not be lost, because neither ``destroy`` nor
|
|
||||||
``terminate`` was invoked. The files for the instances will remain on
|
|
||||||
the compute node.
|
|
||||||
|
|
||||||
- The database has not been updated.
|
|
||||||
|
|
||||||
**Begin recovery**
|
|
||||||
|
|
||||||
.. warning::
|
|
||||||
|
|
||||||
Do not add any extra steps to this procedure, or perform the steps
|
|
||||||
out of order.
|
|
||||||
|
|
||||||
#. Check the current relationship between the volume and its instance, so
|
|
||||||
that you can recreate the attachment.
|
|
||||||
|
|
||||||
This information can be found using the :command:`nova volume-list` command.
|
|
||||||
Note that the ``nova`` client also includes the ability to get volume
|
|
||||||
information from OpenStack Block Storage.
|
|
||||||
|
|
||||||
#. Update the database to clean the stalled state. Do this for every
|
|
||||||
volume, using these queries:
|
|
||||||
|
|
||||||
.. code:: console
|
|
||||||
|
|
||||||
mysql> use cinder;
|
|
||||||
mysql> update volumes set mountpoint=NULL;
|
|
||||||
mysql> update volumes set status="available" where status <>"error_deleting";
|
|
||||||
mysql> update volumes set attach_status="detached";
|
|
||||||
mysql> update volumes set instance_id=0;
|
|
||||||
|
|
||||||
Use ``nova volume-list`` commands to list all volumes.
|
|
||||||
|
|
||||||
#. Restart the instances using the :command:`nova reboot INSTANCE` command.
|
|
||||||
|
|
||||||
.. important::
|
|
||||||
|
|
||||||
Some instances will completely reboot and become reachable, while
|
|
||||||
some might stop at the plymouth stage. This is expected behavior, DO
|
|
||||||
NOT reboot a second time.
|
|
||||||
|
|
||||||
Instance state at this stage depends on whether you added an
|
|
||||||
`/etc/fstab` entry for that volume. Images built with the
|
|
||||||
cloud-init package remain in a ``pending`` state, while others skip
|
|
||||||
the missing volume and start. This step is performed in order to ask
|
|
||||||
Compute to reboot every instance, so that the stored state is
|
|
||||||
preserved. It does not matter if not all instances come up
|
|
||||||
successfully. For more information about cloud-init, see
|
|
||||||
`help.ubuntu.com/community/CloudInit/ <https://help.ubuntu.com/community/CloudInit/>`__.
|
|
||||||
|
|
||||||
#. Reattach the volumes to their respective instances, if required, using
|
|
||||||
the :command:`nova volume-attach` command. This example uses a file of
|
|
||||||
listed volumes to reattach them:
|
|
||||||
|
|
||||||
.. code:: bash
|
|
||||||
|
|
||||||
#!/bin/bash
|
|
||||||
|
|
||||||
while read line; do
|
|
||||||
volume=`echo $line | $CUT -f 1 -d " "`
|
|
||||||
instance=`echo $line | $CUT -f 2 -d " "`
|
|
||||||
mount_point=`echo $line | $CUT -f 3 -d " "`
|
|
||||||
echo "ATTACHING VOLUME FOR INSTANCE - $instance"
|
|
||||||
nova volume-attach $instance $volume $mount_point
|
|
||||||
sleep 2
|
|
||||||
done < $volumes_tmp_file
|
|
||||||
|
|
||||||
Instances that were stopped at the plymouth stage will now automatically
|
|
||||||
continue booting and start normally. Instances that previously started
|
|
||||||
successfully will now be able to see the volume.
|
|
||||||
|
|
||||||
#. Log in to the instances with SSH and reboot them.
|
|
||||||
|
|
||||||
If some services depend on the volume, or if a volume has an entry in
|
|
||||||
fstab, you should now be able to restart the instance. Restart directly
|
|
||||||
from the instance itself, not through ``nova``:
|
|
||||||
|
|
||||||
.. code:: console
|
|
||||||
|
|
||||||
# shutdown -r now
|
|
||||||
|
|
||||||
When you are planning for and performing a disaster recovery, follow
|
|
||||||
these tips:
|
|
||||||
|
|
||||||
- Use the ``errors=remount`` parameter in the :file:`fstab` file to prevent
|
|
||||||
data corruption.
|
|
||||||
|
|
||||||
This parameter will cause the system to disable the ability to write
|
|
||||||
to the disk if it detects an I/O error. This configuration option
|
|
||||||
should be added into the cinder-volume server (the one which performs
|
|
||||||
the iSCSI connection to the SAN), and into the instances' :file:`fstab`
|
|
||||||
files.
|
|
||||||
|
|
||||||
- Do not add the entry for the SAN's disks to the cinder-volume's
|
|
||||||
:file:`fstab` file.
|
|
||||||
|
|
||||||
Some systems hang on that step, which means you could lose access to
|
|
||||||
your cloud-controller. To re-run the session manually, run this
|
|
||||||
command before performing the mount:
|
|
||||||
|
|
||||||
.. code:: console
|
|
||||||
|
|
||||||
# iscsiadm -m discovery -t st -p $SAN_IP $ iscsiadm -m node --target-name $IQN -p $SAN_IP -l
|
|
||||||
|
|
||||||
- On your instances, if you have the whole ``/home/`` directory on the
|
|
||||||
disk, leave a user's directory with the user's bash files and the
|
|
||||||
:file:`authorized_keys` file (instead of emptying the ``/home`` directory
|
|
||||||
and mapping the disk on it).
|
|
||||||
|
|
||||||
This allows you to connect to the instance even without the volume
|
|
||||||
attached, if you allow only connections through public keys.
|
|
||||||
|
|
||||||
If you want to script the disaster recovery plan (DRP), a bash script is
|
|
||||||
available from `https://github.com/Razique <https://github.com/Razique/BashStuff/blob/master/SYSTEMS/OpenStack/SCR_5006_V00_NUAC-OPENSTACK-DRP-OpenStack.sh>`_
|
|
||||||
which performs the following steps:
|
|
||||||
|
|
||||||
#. An array is created for instances and their attached volumes.
|
|
||||||
|
|
||||||
#. The MySQL database is updated.
|
|
||||||
|
|
||||||
#. All instances are restarted with euca2ools.
|
|
||||||
|
|
||||||
#. The volumes are reattached.
|
|
||||||
|
|
||||||
#. An SSH connection is performed into every instance using Compute
|
|
||||||
credentials.
|
|
||||||
|
|
||||||
The script includes a ``test mode``, which allows you to perform that
|
|
||||||
whole sequence for only one instance.
|
|
||||||
|
|
||||||
To reproduce the power loss, connect to the compute node which runs that
|
|
||||||
instance and close the iSCSI session. Do not detach the volume using the
|
|
||||||
:command:`nova volume-detach` command, manually close the iSCSI session.
|
|
||||||
This example closes an iSCSI session with the number 15:
|
|
||||||
|
|
||||||
.. code:: console
|
|
||||||
|
|
||||||
# iscsiadm -m session -u -r 15
|
|
||||||
|
|
||||||
Do not forget the ``-r`` flag. Otherwise, you will close all sessions.
|
|
||||||
@ -1,102 +0,0 @@
|
|||||||
.. _root-wrap-reference:
|
|
||||||
|
|
||||||
====================
|
|
||||||
Secure with rootwrap
|
|
||||||
====================
|
|
||||||
|
|
||||||
Rootwrap allows unprivileged users to safely run Compute actions as the
|
|
||||||
root user. Compute previously used :command:`sudo` for this purpose, but this
|
|
||||||
was difficult to maintain, and did not allow advanced filters. The
|
|
||||||
:command:`rootwrap` command replaces :command:`sudo` for Compute.
|
|
||||||
|
|
||||||
To use rootwrap, prefix the Compute command with :command:`nova-rootwrap`. For
|
|
||||||
example:
|
|
||||||
|
|
||||||
.. code:: console
|
|
||||||
|
|
||||||
$ sudo nova-rootwrap /etc/nova/rootwrap.conf command
|
|
||||||
|
|
||||||
A generic ``sudoers`` entry lets the Compute user run :command:`nova-rootwrap`
|
|
||||||
as root. The :command:`nova-rootwrap` code looks for filter definition
|
|
||||||
directories in its configuration file, and loads command filters from
|
|
||||||
them. It then checks if the command requested by Compute matches one of
|
|
||||||
those filters and, if so, executes the command (as root). If no filter
|
|
||||||
matches, it denies the request.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
Be aware of issues with using NFS and root-owned files. The NFS
|
|
||||||
share must be configured with the ``no_root_squash`` option enabled,
|
|
||||||
in order for rootwrap to work correctly.
|
|
||||||
|
|
||||||
Rootwrap is fully controlled by the root user. The root user
|
|
||||||
owns the sudoers entry which allows Compute to run a specific
|
|
||||||
rootwrap executable as root, and only with a specific
|
|
||||||
configuration file (which should also be owned by root).
|
|
||||||
The :command:`nova-rootwrap` command imports the Python
|
|
||||||
modules it needs from a cleaned, system-default PYTHONPATH.
|
|
||||||
The root-owned configuration file points to root-owned
|
|
||||||
filter definition directories, which contain root-owned
|
|
||||||
filters definition files. This chain ensures that the Compute
|
|
||||||
user itself is not in control of the configuration or modules
|
|
||||||
used by the :command:`nova-rootwrap` executable.
|
|
||||||
|
|
||||||
Rootwrap is configured using the :file:`rootwrap.conf` file. Because
|
|
||||||
it's in the trusted security path, it must be owned and writable
|
|
||||||
by only the root user. The file's location is specified in both
|
|
||||||
the sudoers entry and in the :file:`nova.conf` configuration file
|
|
||||||
with the ``rootwrap_config=entry`` parameter.
|
|
||||||
|
|
||||||
The :file:`rootwrap.conf` file uses an INI file format with these
|
|
||||||
sections and parameters:
|
|
||||||
|
|
||||||
.. list-table:: rootwrap.conf configuration options
|
|
||||||
:widths: 64 31
|
|
||||||
|
|
||||||
|
|
||||||
* - Configuration option=Default value
|
|
||||||
- (Type) Description
|
|
||||||
* - [DEFAULT]
|
|
||||||
filters\_path=/etc/nova/rootwrap.d,/usr/share/nova/rootwrap
|
|
||||||
- (ListOpt) Comma-separated list of directories
|
|
||||||
containing filter definition files.
|
|
||||||
Defines where rootwrap filters are stored.
|
|
||||||
Directories defined on this line should all
|
|
||||||
exist, and be owned and writable only by the
|
|
||||||
root user.
|
|
||||||
|
|
||||||
If the root wrapper is not performing correctly, you can add a
|
|
||||||
workaround option into the :file:`nova.conf` configuration file. This
|
|
||||||
workaround re-configures the root wrapper configuration to fall back to
|
|
||||||
running commands as sudo, and is a Kilo release feature.
|
|
||||||
|
|
||||||
Including this workaround in your configuration file safeguards your
|
|
||||||
environment from issues that can impair root wrapper performance. Tool
|
|
||||||
changes that have impacted
|
|
||||||
`Python Build Reasonableness (PBR) <https://git.openstack.org/cgit/openstack-dev/pbr/>`__
|
|
||||||
for example, are a known issue that affects root wrapper performance.
|
|
||||||
|
|
||||||
To set up this workaround, configure the ``disable_rootwrap`` option in
|
|
||||||
the ``[workaround]`` section of the :file:`nova.conf` configuration file.
|
|
||||||
|
|
||||||
The filters definition files contain lists of filters that rootwrap will
|
|
||||||
use to allow or deny a specific command. They are generally suffixed by
|
|
||||||
``.filters`` . Since they are in the trusted security path, they need to
|
|
||||||
be owned and writable only by the root user. Their location is specified
|
|
||||||
in the :file:`rootwrap.conf` file.
|
|
||||||
|
|
||||||
Filter definition files use an INI file format with a ``[Filters]``
|
|
||||||
section and several lines, each with a unique parameter name, which
|
|
||||||
should be different for each filter you define:
|
|
||||||
|
|
||||||
.. list-table:: filters configuration options
|
|
||||||
:widths: 72 39
|
|
||||||
|
|
||||||
|
|
||||||
* - Configuration option=Default value
|
|
||||||
- (Type) Description
|
|
||||||
* - [Filters]
|
|
||||||
filter\_name=kpartx: CommandFilter, /sbin/kpartx, root
|
|
||||||
- (ListOpt) Comma-separated list containing the filter class to
|
|
||||||
use, followed by the Filter arguments (which vary depending
|
|
||||||
on the Filter class selected).
|
|
||||||
@ -1,36 +0,0 @@
|
|||||||
.. _section-compute-security:
|
|
||||||
|
|
||||||
==================
|
|
||||||
Security hardening
|
|
||||||
==================
|
|
||||||
|
|
||||||
OpenStack Compute can be integrated with various third-party
|
|
||||||
technologies to increase security. For more information, see the
|
|
||||||
`OpenStack Security Guide <http://docs.openstack.org/sec/>`_.
|
|
||||||
|
|
||||||
.. :ref:section_trusted-compute-pools.rst
|
|
||||||
|
|
||||||
Encrypt Compute metadata traffic
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
**Enabling SSL encryption**
|
|
||||||
|
|
||||||
OpenStack supports encrypting Compute metadata traffic with HTTPS.
|
|
||||||
Enable SSL encryption in the :file:`metadata_agent.ini` file.
|
|
||||||
|
|
||||||
#. Enable the HTTPS protocol::
|
|
||||||
|
|
||||||
nova_metadata_protocol = https
|
|
||||||
|
|
||||||
#. Determine whether insecure SSL connections are accepted for Compute
|
|
||||||
metadata server requests. The default value is ``False``::
|
|
||||||
|
|
||||||
nova_metadata_insecure = False
|
|
||||||
|
|
||||||
#. Specify the path to the client certificate::
|
|
||||||
|
|
||||||
nova_client_cert = PATH_TO_CERT
|
|
||||||
|
|
||||||
#. Specify the path to the private key::
|
|
||||||
|
|
||||||
nova_client_priv_key = PATH_TO_KEY
|
|
||||||
File diff suppressed because it is too large
Load Diff
@ -17,21 +17,11 @@ web-based API.
|
|||||||
|
|
||||||
compute_arch.rst
|
compute_arch.rst
|
||||||
compute-images-instances.rst
|
compute-images-instances.rst
|
||||||
common/support-compute.rst
|
compute-networking-nova.rst
|
||||||
compute-system-admin.rst
|
compute-system-admin.rst
|
||||||
compute_config-firewalls.rst
|
common/support-compute.rst
|
||||||
compute-rootwrap.rst
|
|
||||||
compute-configure-migrations.rst
|
|
||||||
compute-configure-service-groups.rst
|
|
||||||
compute-security.rst
|
|
||||||
compute-recover-nodes.rst
|
|
||||||
|
|
||||||
.. TODO (bmoss)
|
.. TODO (bmoss)
|
||||||
compute/section_compute-networking-nova.xml
|
|
||||||
compute/section_compute-system-admin.xml
|
|
||||||
../common/section_support-compute.xml
|
|
||||||
../common/section_cli_nova_usage_statistics.xml
|
../common/section_cli_nova_usage_statistics.xml
|
||||||
../common/section_cli_nova_volumes.xml
|
|
||||||
../common/section_cli_nova_customize_flavors.xml
|
|
||||||
../common/section_compute-configure-console.xml
|
../common/section_compute-configure-console.xml
|
||||||
|
|
||||||
|
|||||||
@ -1,33 +0,0 @@
|
|||||||
.. _default_ports:
|
|
||||||
|
|
||||||
==========================================
|
|
||||||
Compute service node firewall requirements
|
|
||||||
==========================================
|
|
||||||
|
|
||||||
Console connections for virtual machines, whether direct or through a
|
|
||||||
proxy, are received on ports ``5900`` to ``5999``. The firewall on each
|
|
||||||
Compute service node must allow network traffic on these ports.
|
|
||||||
|
|
||||||
This procedure modifies the iptables firewall to allow incoming
|
|
||||||
connections to the Compute services.
|
|
||||||
|
|
||||||
**Configuring the service-node firewall**
|
|
||||||
|
|
||||||
#. Log in to the server that hosts the Compute service, as root.
|
|
||||||
|
|
||||||
#. Edit the :file:`/etc/sysconfig/iptables` file, to add an INPUT rule that
|
|
||||||
allows TCP traffic on ports from ``5900`` to ``5999``. Make sure the new
|
|
||||||
rule appears before any INPUT rules that REJECT traffic:
|
|
||||||
|
|
||||||
.. code:: ini
|
|
||||||
|
|
||||||
-A INPUT -p tcp -m multiport --dports 5900:5999 -j ACCEPT
|
|
||||||
|
|
||||||
#. Save the changes to :file:`/etc/sysconfig/iptables` file, and restart the
|
|
||||||
iptables service to pick up the changes:
|
|
||||||
|
|
||||||
.. code:: console
|
|
||||||
|
|
||||||
$ service iptables restart
|
|
||||||
|
|
||||||
#. Repeat this process for each Compute service node.
|
|
||||||
@ -1,3 +1,5 @@
|
|||||||
|
.. _networking:
|
||||||
|
|
||||||
==========
|
==========
|
||||||
Networking
|
Networking
|
||||||
==========
|
==========
|
||||||
|
|||||||
@ -165,6 +165,8 @@ administrative user can view and set the provider extended attributes
|
|||||||
through Networking API calls. See the section called
|
through Networking API calls. See the section called
|
||||||
:ref:`Authentication and authorization` for details on policy configuration.
|
:ref:`Authentication and authorization` for details on policy configuration.
|
||||||
|
|
||||||
|
.. _L3-routing-and-NAT:
|
||||||
|
|
||||||
L3 routing and NAT
|
L3 routing and NAT
|
||||||
~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user