openstack
/
ha-guide
Code Issues Proposed changes
ha-guide/doc/ha-guide/source/locale/ha-guide.pot

4262 lines
134 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2015, OpenStack contributors
# This file is distributed under the same license as the High Availability Guide package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: High Availability Guide 0.0.1\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2016-03-07 06:00+0000\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../compute-node-ha-api.rst:4
msgid "Configure high availability on compute nodes"
msgstr ""
#: ../compute-node-ha-api.rst:6
msgid ""
"The `Installation Guide <http://docs.openstack.org/liberty/#install-"
"guides>`_ gives instructions for installing multiple compute nodes. To make "
"them highly available, you must configure the environment to include "
"multiple instances of the API and other services."
msgstr ""
#: ../compute-node-ha.rst:4
msgid "Configuring the compute node for high availability"
msgstr ""
#: ../controller-ha-galera-config.rst:2
msgid "Configuration"
msgstr ""
#: ../controller-ha-galera-config.rst:4
msgid ""
"Before you launch Galera Cluster, you need to configure the server and the "
"database to operate as part of the cluster."
msgstr ""
#: ../controller-ha-galera-config.rst:8
msgid "Configuring the server"
msgstr ""
#: ../controller-ha-galera-config.rst:10
msgid ""
"Certain services running on the underlying operating system of your "
"OpenStack database may block Galera Cluster from normal operation or prevent "
"``mysqld`` from achieving network connectivity with the cluster."
msgstr ""
#: ../controller-ha-galera-config.rst:16
msgid "Firewall"
msgstr ""
#: ../controller-ha-galera-config.rst:18
msgid "Galera Cluster requires that you open four ports to network traffic:"
msgstr ""
#: ../controller-ha-galera-config.rst:20
msgid ""
"On ``3306``, Galera Cluster uses TCP for database client connections and "
"State Snapshot Transfers methods that require the client, (that is, "
"``mysqldump``)."
msgstr ""
#: ../controller-ha-galera-config.rst:23
msgid ""
"On ``4567`` Galera Cluster uses TCP for replication traffic. Multicast "
"replication uses both TCP and UDP on this port."
msgstr ""
#: ../controller-ha-galera-config.rst:25
msgid "On ``4568`` Galera Cluster uses TCP for Incremental State Transfers."
msgstr ""
#: ../controller-ha-galera-config.rst:26
msgid ""
"On ``4444`` Galera Cluster uses TCP for all other State Snapshot Transfer "
"methods."
msgstr ""
#: ../controller-ha-galera-config.rst:29
msgid ""
"For more information on firewalls, see `Firewalls and default ports <http://"
"docs.openstack.org/liberty/config-reference/content/firewalls-default-ports."
"html>`_, in the Configuration Reference."
msgstr ""
#: ../controller-ha-galera-config.rst:35
msgid "``iptables``"
msgstr ""
#: ../controller-ha-galera-config.rst:37
msgid ""
"For many Linux distributions, you can configure the firewall using the "
"``iptables`` utility. To do so, complete the following steps:"
msgstr ""
#: ../controller-ha-galera-config.rst:40
msgid ""
"For each cluster node, run the following commands, replacing ``NODE-IP-"
"ADDRESS`` with the IP address of the cluster node you want to open the "
"firewall to:"
msgstr ""
#: ../controller-ha-galera-config.rst:59
msgid ""
"In the event that you also want to configure multicast replication, run this "
"command as well:"
msgstr ""
#: ../controller-ha-galera-config.rst:69
msgid ""
"Make the changes persistent. For servers that use ``init``, use the :command:"
"`save` command:"
msgstr ""
#: ../controller-ha-galera-config.rst:76
msgid ""
"For servers that use ``systemd``, you need to save the current packet "
"filtering to the path of the file that ``iptables`` reads when it starts. "
"This path can vary by distribution, but common locations are in the ``/etc`` "
"directory, such as:"
msgstr ""
#: ../controller-ha-galera-config.rst:81
msgid "``/etc/sysconfig/iptables``"
msgstr ""
#: ../controller-ha-galera-config.rst:82
msgid "``/etc/iptables/iptables.rules``"
msgstr ""
#: ../controller-ha-galera-config.rst:84
msgid ""
"When you find the correct path, run the :command:`iptables-save` command:"
msgstr ""
#: ../controller-ha-galera-config.rst:90
#: ../controller-ha-galera-config.rst:137
msgid ""
"With the firewall configuration saved, whenever your OpenStack database "
"starts."
msgstr ""
#: ../controller-ha-galera-config.rst:94
msgid "``firewall-cmd``"
msgstr ""
#: ../controller-ha-galera-config.rst:96
msgid ""
"For many Linux distributions, you can configure the firewall using the "
"``firewall-cmd`` utility for FirewallD. To do so, complete the following "
"steps on each cluster node:"
msgstr ""
#: ../controller-ha-galera-config.rst:100
msgid "Add the Galera Cluster service:"
msgstr ""
#: ../controller-ha-galera-config.rst:106
msgid ""
"For each instance of OpenStack database in your cluster, run the following "
"commands, replacing ``NODE-IP-ADDRESS`` with the IP address of the cluster "
"node you want to open the firewall to:"
msgstr ""
#: ../controller-ha-galera-config.rst:117
msgid ""
"In the event that you also want to configure mutlicast replication, run this "
"command as well:"
msgstr ""
#: ../controller-ha-galera-config.rst:124
msgid ""
"To make this configuration persistent, repeat the above commands with the :"
"option:`--permanent` option."
msgstr ""
#: ../controller-ha-galera-config.rst:141
msgid "SELinux"
msgstr ""
#: ../controller-ha-galera-config.rst:143
msgid ""
"Security-Enhanced Linux is a kernel module for improving security on Linux "
"operating systems. It is commonly enabled and configured by default on Red "
"Hat-based distributions. In the context of Galera Cluster, systems with "
"SELinux may block the database service, keep it from starting or prevent it "
"from establishing network connections with the cluster."
msgstr ""
#: ../controller-ha-galera-config.rst:149
msgid ""
"To configure SELinux to permit Galera Cluster to operate, complete the "
"following steps on each cluster node:"
msgstr ""
#: ../controller-ha-galera-config.rst:152
msgid "Using the ``semanage`` utility, open the relevant ports:"
msgstr ""
#: ../controller-ha-galera-config.rst:161
msgid ""
"In the event that you use multicast replication, you also need to open "
"``4567`` to UDP traffic:"
msgstr ""
#: ../controller-ha-galera-config.rst:168
msgid "Set SELinux to allow the database server to run:"
msgstr ""
#: ../controller-ha-galera-config.rst:174
msgid "With these options set, SELinux now permits Galera Cluster to operate."
msgstr ""
#: ../controller-ha-galera-config.rst:176
msgid ""
"Bear in mind, leaving SELinux in permissive mode is not a good security "
"practice. Over the longer term, you need to develop a security policy for "
"Galera Cluster and then switch SELinux back into enforcing mode."
msgstr ""
#: ../controller-ha-galera-config.rst:181
msgid ""
"For more information on configuring SELinux to work with Galera Cluster, see "
"the `Documentation <http://galeracluster.com/documentation-webpages/selinux."
"html>`_"
msgstr ""
#: ../controller-ha-galera-config.rst:187
msgid "AppArmor"
msgstr ""
#: ../controller-ha-galera-config.rst:189
msgid ""
"Application Armor is a kernel module for improving security on Linux "
"operating systems. It is developed by Canonical and commonly used on Ubuntu-"
"based distributions. In the context of Galera Cluster, systems with AppArmor "
"may block the database service from operating normally."
msgstr ""
#: ../controller-ha-galera-config.rst:194
msgid ""
"To configure AppArmor to work with Galera Cluster, complete the following "
"steps on each cluster node:"
msgstr ""
#: ../controller-ha-galera-config.rst:197
msgid ""
"Create a symbolic link for the database server in the ``disable`` directory:"
msgstr ""
#: ../controller-ha-galera-config.rst:203
msgid ""
"Restart AppArmor. For servers that use ``init``, run the following command:"
msgstr ""
# #-#-#-#-# controller-ha-galera-config.pot (High Availability Guide 0.0.1) #-#-#-#-#
# #-#-#-#-# controller-ha-galera-manage.pot (High Availability Guide 0.0.1) #-#-#-#-#
#: ../controller-ha-galera-config.rst:209
#: ../controller-ha-galera-manage.rst:43 ../controller-ha-galera-manage.rst:70
msgid "For servers that use ``systemd``, instead run this command:"
msgstr ""
#: ../controller-ha-galera-config.rst:215
msgid "AppArmor now permits Galera Cluster to operate."
msgstr ""
#: ../controller-ha-galera-config.rst:219
msgid "Database configuration"
msgstr ""
#: ../controller-ha-galera-config.rst:221
msgid ""
"MySQL databases, including MariaDB and Percona XtraDB, manage their "
"configurations using a ``my.cnf`` file, which is typically located in the ``/"
"etc`` directory. Configuration options available in these databases are also "
"available in Galera Cluster, with some restrictions and several additions."
msgstr ""
#: ../controller-ha-galera-config.rst:252
msgid "Configuring ``mysqld``"
msgstr ""
#: ../controller-ha-galera-config.rst:254
msgid ""
"While all of the configuration parameters available to the standard MySQL, "
"MariaDB or Percona XtraDB database server are available in Galera Cluster, "
"there are some that you must define an outset to avoid conflict or "
"unexpected behavior."
msgstr ""
#: ../controller-ha-galera-config.rst:259
msgid ""
"Ensure that the database server is not bound only to to the localhost, "
"``127.0.0.1``. Instead, bind it to ``0.0.0.0`` to ensure it listens on all "
"available interfaces."
msgstr ""
#: ../controller-ha-galera-config.rst:267
msgid ""
"Ensure that the binary log format is set to use row-level replication, as "
"opposed to statement-level replication:"
msgstr ""
#: ../controller-ha-galera-config.rst:276
msgid "Configuring InnoDB"
msgstr ""
#: ../controller-ha-galera-config.rst:278
msgid ""
"Galera Cluster does not support non-transactional storage engines and "
"requires that you use InnoDB by default. There are some additional "
"parameters that you must define to avoid conflicts."
msgstr ""
#: ../controller-ha-galera-config.rst:282
msgid "Ensure that the default storage engine is set to InnoDB:"
msgstr ""
#: ../controller-ha-galera-config.rst:288
msgid ""
"Ensure that the InnoDB locking mode for generating auto-increment values is "
"set to ``2``, which is the interleaved locking mode."
msgstr ""
#: ../controller-ha-galera-config.rst:295
msgid ""
"Do not change this value. Other modes may cause ``INSERT`` statements on "
"tables with auto-increment columns to fail as well as unresolved deadlocks "
"that leave the system unresponsive."
msgstr ""
#: ../controller-ha-galera-config.rst:299
msgid ""
"Ensure that the InnoDB log buffer is written to file once per second, rather "
"than on each commit, to improve performance:"
msgstr ""
#: ../controller-ha-galera-config.rst:306
msgid ""
"Bear in mind, while setting this parameter to ``1`` or ``2`` can improve "
"performance, it introduces certain dangers. Operating system failures can "
"erase the last second of transactions. While you can recover this data from "
"another node, if the cluster goes down at the same time (in the event of a "
"data center power outage), you lose this data permanently."
msgstr ""
#: ../controller-ha-galera-config.rst:312
msgid ""
"Define the InnoDB memory buffer pool size. The default value is 128 MB, but "
"to compensate for Galera Cluster's additional memory usage, scale your usual "
"value back by 5%:"
msgstr ""
#: ../controller-ha-galera-config.rst:322
msgid "Configuring wsrep replication"
msgstr ""
#: ../controller-ha-galera-config.rst:324
msgid ""
"Galera Cluster configuration parameters all have the ``wsrep_`` prefix. "
"There are five that you must define for each cluster node in your OpenStack "
"database."
msgstr ""
#: ../controller-ha-galera-config.rst:328
msgid ""
"**wsrep Provider** The Galera Replication Plugin serves as the wsrep "
"Provider for Galera Cluster. It is installed on your system as the "
"``libgalera_smm.so`` file. You must define the path to this file in your "
"``my.cnf``."
msgstr ""
#: ../controller-ha-galera-config.rst:337
msgid "**Cluster Name** Define an arbitrary name for your cluster."
msgstr ""
#: ../controller-ha-galera-config.rst:343
msgid ""
"You must use the same name on every cluster node. The connection fails when "
"this value does not match."
msgstr ""
#: ../controller-ha-galera-config.rst:346
msgid "**Cluster Address** List the IP addresses for each cluster node."
msgstr ""
#: ../controller-ha-galera-config.rst:352
msgid ""
"Replace the IP addresses given here with comma-separated list of each "
"OpenStack database in your cluster."
msgstr ""
#: ../controller-ha-galera-config.rst:355
msgid "**Node Name** Define the logical name of the cluster node."
msgstr ""
#: ../controller-ha-galera-config.rst:361
msgid "**Node Address** Define the IP address of the cluster node."
msgstr ""
#: ../controller-ha-galera-config.rst:371
msgid "Additional parameters"
msgstr ""
#: ../controller-ha-galera-config.rst:373
msgid ""
"For a complete list of the available parameters, run the ``SHOW VARIABLES`` "
"command from within the database client:"
msgstr ""
#: ../controller-ha-galera-config.rst:394
msgid ""
"For the documentation of these parameters, wsrep Provider option and status "
"variables available in Galera Cluster, see `Reference <http://galeracluster."
"com/documentation-webpages/reference.html>`_."
msgstr ""
#: ../controller-ha-galera-install.rst:2
msgid "Installation"
msgstr ""
#: ../controller-ha-galera-install.rst:4
msgid ""
"Using Galera Cluster requires that you install two packages. The first is "
"the database server, which must include the wsrep API patch. The second "
"package is the Galera Replication Plugin, which enables the write-set "
"replication service functionality with the database server."
msgstr ""
#: ../controller-ha-galera-install.rst:9
msgid ""
"There are three implementations of Galera Cluster: MySQL, MariaDB and "
"Percona XtraDB. For each implementation, there is a software repository that "
"provides binary packages for Debian, Red Hat, and SUSE-based Linux "
"distributions."
msgstr ""
#: ../controller-ha-galera-install.rst:16
msgid "Enabling the repository"
msgstr ""
#: ../controller-ha-galera-install.rst:18
msgid ""
"Galera Cluster is not available in the base repositories of Linux "
"distributions. In order to install it with your package manage, you must "
"first enable the repository on your system. The particular methods for doing "
"so vary depending on which distribution you use for OpenStack and which "
"database server you want to use."
msgstr ""
#: ../controller-ha-galera-install.rst:25
msgid "Debian"
msgstr ""
#: ../controller-ha-galera-install.rst:27
msgid ""
"For Debian and Debian-based distributions, such as Ubuntu, complete the "
"following steps:"
msgstr ""
#: ../controller-ha-galera-install.rst:30
msgid "Add the GnuPG key for the database repository that you want to use."
msgstr ""
#: ../controller-ha-galera-install.rst:37
msgid ""
"Note that the particular key value in this command varies depending on which "
"database software repository you want to use."
msgstr ""
#: ../controller-ha-galera-install.rst:41
msgid "Database"
msgstr ""
#: ../controller-ha-galera-install.rst:41
msgid "Key"
msgstr ""
#: ../controller-ha-galera-install.rst:43
msgid "Galera Cluster for MySQL"
msgstr ""
#: ../controller-ha-galera-install.rst:43
msgid "``BC19DDBA``"
msgstr ""
#: ../controller-ha-galera-install.rst:45
msgid "MariaDB Galera Cluster"
msgstr ""
#: ../controller-ha-galera-install.rst:45
msgid "``0xcbcb082a1bb943db``"
msgstr ""
#: ../controller-ha-galera-install.rst:47
msgid "Percona XtraDB Cluster"
msgstr ""
#: ../controller-ha-galera-install.rst:47
msgid "``1C4CBDCDCD2EFD2A``"
msgstr ""
#: ../controller-ha-galera-install.rst:50
msgid ""
"Add the repository to your sources list. Using your preferred text editor, "
"create a ``galera.list`` file in the ``/etc/apt/sources.list.d/`` directory. "
"For the contents of this file, use the lines that pertain to the software "
"repository you want to install:"
msgstr ""
#: ../controller-ha-galera-install.rst:66
msgid ""
"For each entry: Replace all instances of ``DISTRO`` with the distribution "
"that you use, such as ``debian`` or ``ubuntu``. Replace all instances of "
"``RELEASE`` with the release of that distribution, such as ``wheezy`` or "
"``trusty``. Replace all instances of ``VERSION`` with the version of the "
"database server that you want to install, such as ``5.6`` or ``10.0``."
msgstr ""
#: ../controller-ha-galera-install.rst:72
msgid ""
"In the event that you do not know the release code-name for your "
"distribution, you can use the following command to find it out:"
msgstr ""
#: ../controller-ha-galera-install.rst:81
msgid "Update the local cache."
msgstr ""
#: ../controller-ha-galera-install.rst:87
msgid ""
"Packages in the Galera Cluster Debian repository are now available for "
"installation on your system."
msgstr ""
#: ../controller-ha-galera-install.rst:91
msgid "Red Hat"
msgstr ""
#: ../controller-ha-galera-install.rst:93
msgid ""
"For Red Hat Enterprise Linux and Red Hat-based Linux distributions, the "
"process is more straightforward. In this file, only enter the text for the "
"repository you want to use."
msgstr ""
#: ../controller-ha-galera-install.rst:97
msgid ""
"For Galera Cluster for MySQL, using your preferred text editor, create a "
"``Galera.repo`` file in the ``/etc/yum.repos.d/`` directory."
msgstr ""
#: ../controller-ha-galera-install.rst:108
msgid ""
"Replace ``DISTRO`` with the name of the distribution you use, such as "
"``centos`` or ``fedora``. Replace ``RELEASE`` with the release number, such "
"as ``7`` for CentOS 7. Replace ``ARCH`` with your system architecture, such "
"as ``x86_64``"
msgstr ""
#: ../controller-ha-galera-install.rst:113
msgid ""
"For MariaDB Galera Cluster, using your preferred text editor, create a "
"``Galera.repo`` file in the ``/etc/yum.repos.d/`` directory."
msgstr ""
#: ../controller-ha-galera-install.rst:124
msgid ""
"Replace ``VERSION`` with the version of MariaDB you want to install, such as "
"``5.6`` or ``10.0``. Replace ``PACKAGE`` with the package type and "
"architecture, such as ``rhel6-amd64`` for Red Hat 6 on 64-bit architecture."
msgstr ""
#: ../controller-ha-galera-install.rst:129
msgid "For Percona XtraDB Cluster, run the following command:"
msgstr ""
#: ../controller-ha-galera-install.rst:135
msgid ""
"Bear in mind that the Percona repository only supports Red Hat Enterprise "
"Linux and CentOS distributions."
msgstr ""
#: ../controller-ha-galera-install.rst:138
msgid ""
"Packages in the Galera Cluster Red Hat repository are not available for "
"installation on your system."
msgstr ""
#: ../controller-ha-galera-install.rst:144
msgid "SUSE"
msgstr ""
#: ../controller-ha-galera-install.rst:146
msgid ""
"For SUSE Enterprise Linux and SUSE-based distributions, such as openSUSE "
"binary installations are only available for Galera Cluster for MySQL and "
"MariaDB Galera Cluster."
msgstr ""
#: ../controller-ha-galera-install.rst:150
msgid ""
"Create a ``Galera.repo`` file in the local directory. For Galera Cluster for "
"MySQL, use the following content:"
msgstr ""
#: ../controller-ha-galera-install.rst:161
msgid ""
"In the text: Replace ``DISTRO`` with the name of the distribution you use, "
"such as ``sles`` or ``opensuse``. Replace ``RELEASE`` with the version "
"number of that distribution."
msgstr ""
#: ../controller-ha-galera-install.rst:165
msgid "For MariaDB Galera Cluster, instead use this content:"
msgstr ""
#: ../controller-ha-galera-install.rst:175
msgid ""
"In the text: Replace ``VERSION`` with the version of MariaDB you want to "
"install, such as ``5.6`` or ``10.0``. Replace package with the package "
"architecture you want to use, such as ``opensuse13-amd64``."
msgstr ""
#: ../controller-ha-galera-install.rst:179
msgid "Add the repository to your system:"
msgstr ""
#: ../controller-ha-galera-install.rst:185
msgid "Refresh ``zypper``:"
msgstr ""
#: ../controller-ha-galera-install.rst:191
msgid ""
"Packages in the Galera Cluster SUSE repository are now available for "
"installation."
msgstr ""
#: ../controller-ha-galera-install.rst:196
msgid "Installing Galera Cluster"
msgstr ""
#: ../controller-ha-galera-install.rst:198
msgid ""
"When you finish enabling the software repository for Galera Cluster, you can "
"install it using your package manager. The particular command and packages "
"you need to install varies depending on which database server you want to "
"install and which Linux distribution you use:"
msgstr ""
#: ../controller-ha-galera-install.rst:203
msgid "Galera Cluster for MySQL:"
msgstr ""
#: ../controller-ha-galera-install.rst:206
#: ../controller-ha-galera-install.rst:230
#: ../controller-ha-galera-install.rst:255
msgid ""
"For Debian and Debian-based distributions, such as Ubuntu, run the following "
"command:"
msgstr ""
#: ../controller-ha-galera-install.rst:213
#: ../controller-ha-galera-install.rst:237
#: ../controller-ha-galera-install.rst:262
msgid ""
"For Red Hat Enterprise Linux and Red Hat-based distributions, such as Fedora "
"or CentOS, instead run this command:"
msgstr ""
#: ../controller-ha-galera-install.rst:220
#: ../controller-ha-galera-install.rst:244
msgid ""
"For SUSE Enterprise Linux Server and SUSE-based distributions, such as "
"openSUSE, instead run this command:"
msgstr ""
#: ../controller-ha-galera-install.rst:228
msgid "MariaDB Galera Cluster:"
msgstr ""
#: ../controller-ha-galera-install.rst:252
msgid "Percona XtraDB Cluster:"
msgstr ""
#: ../controller-ha-galera-install.rst:269
msgid ""
"Galera Cluster is now installed on your system. You must repeat this process "
"for each controller node in your cluster."
msgstr ""
#: ../controller-ha-galera-install.rst:272
msgid ""
"In the event that you already installed the standalone version of MySQL, "
"MariaDB or Percona XtraDB, this installation purges all privileges on your "
"OpenStack database server. You must reapply the privileges listed in the "
"installation guide."
msgstr ""
#: ../controller-ha-galera-manage.rst:2
msgid "Management"
msgstr ""
#: ../controller-ha-galera-manage.rst:4
msgid ""
"When you finish the installation and configuration process on each cluster "
"node in your OpenStack database, you can initialize Galera Cluster."
msgstr ""
#: ../controller-ha-galera-manage.rst:7
msgid "Before you attempt this, verify that you have the following ready:"
msgstr ""
#: ../controller-ha-galera-manage.rst:9
msgid ""
"Database hosts with Galera Cluster installed. You need a minimum of three "
"hosts;"
msgstr ""
#: ../controller-ha-galera-manage.rst:11
msgid "No firewalls between the hosts;"
msgstr ""
#: ../controller-ha-galera-manage.rst:12
msgid "SELinux and AppArmor set to permit access to ``mysqld``;"
msgstr ""
#: ../controller-ha-galera-manage.rst:13
msgid ""
"The correct path to ``libgalera_smm.so`` given to the ``wsrep_provider`` "
"parameter."
msgstr ""
#: ../controller-ha-galera-manage.rst:17
msgid "Initializing the cluster"
msgstr ""
#: ../controller-ha-galera-manage.rst:19
msgid ""
"In Galera Cluster, the Primary Component is the cluster of database servers "
"that replicate into each other. In the event that a cluster node loses "
"connectivity with the Primary Component, it defaults into a non-operational "
"state, to avoid creating or serving inconsistent data."
msgstr ""
#: ../controller-ha-galera-manage.rst:25
msgid ""
"By default, cluster nodes do not start as part of a Primary Component. "
"Instead they assume that one exists somewhere and attempts to establish a "
"connection with it. To create a Primary Component, you must start one "
"cluster node using the ``--wsrep-new-cluster`` option. You can do this using "
"any cluster node, it is not important which you choose. In the Primary "
"Component, replication and state transfers bring all databases to the same "
"state."
msgstr ""
#: ../controller-ha-galera-manage.rst:34
msgid "To start the cluster, complete the following steps:"
msgstr ""
#: ../controller-ha-galera-manage.rst:36
msgid ""
"Initialize the Primary Component on one cluster node. For servers that use "
"``init``, run the following command:"
msgstr ""
#: ../controller-ha-galera-manage.rst:49
msgid ""
"Once the database server starts, check the cluster status using the "
"``wsrep_cluster_size`` status variable. From the database client, run the "
"following command:"
msgstr ""
#: ../controller-ha-galera-manage.rst:63
msgid ""
"Start the database server on all other cluster nodes. For servers that use "
"``init``, run the following command:"
msgstr ""
#: ../controller-ha-galera-manage.rst:76
msgid ""
"When you have all cluster nodes started, log into the database client on one "
"of them and check the ``wsrep_cluster_size`` status variable again."
msgstr ""
#: ../controller-ha-galera-manage.rst:90
msgid ""
"When each cluster node starts, it checks the IP addresses given to the "
"``wsrep_cluster_address`` parameter and attempts to establish network "
"connectivity with a database server running there. Once it establishes a "
"connection, it attempts to join the Primary Component, requesting a state "
"transfer as needed to bring itself into sync with the cluster."
msgstr ""
#: ../controller-ha-galera-manage.rst:97
msgid ""
"In the event that you need to restart any cluster node, you can do so. When "
"the database server comes back it, it establishes connectivity with the "
"Primary Component and updates itself to any changes it may have missed while "
"down."
msgstr ""
#: ../controller-ha-galera-manage.rst:104
msgid "Restarting the cluster"
msgstr ""
#: ../controller-ha-galera-manage.rst:106
msgid ""
"Individual cluster nodes can stop and be restarted without issue. When a "
"database loses its connection or restarts, Galera Cluster brings it back "
"into sync once it reestablishes connection with the Primary Component. In "
"the event that you need to restart the entire cluster, identify the most "
"advanced cluster node and initialize the Primary Component on that node."
msgstr ""
#: ../controller-ha-galera-manage.rst:113
msgid ""
"To find the most advanced cluster node, you need to check the sequence "
"numbers, or seqnos, on the last committed transaction for each. You can find "
"this by viewing ``grastate.dat`` file in database directory,"
msgstr ""
#: ../controller-ha-galera-manage.rst:127
msgid ""
"Alternatively, if the database server is running, use the "
"``wsrep_last_committed`` status variable:"
msgstr ""
#: ../controller-ha-galera-manage.rst:140
msgid ""
"This value increments with each transaction, so the most advanced node has "
"the highest sequence number, and therefore is the most up to date."
msgstr ""
#: ../controller-ha-galera-manage.rst:145
msgid "Configuration tips"
msgstr ""
#: ../controller-ha-galera-manage.rst:149
msgid "Deployment strategies"
msgstr ""
#: ../controller-ha-galera-manage.rst:151
msgid "Galera can be configured using one of the following strategies:"
msgstr ""
#: ../controller-ha-galera-manage.rst:154
msgid "Each instance has its own IP address;"
msgstr ""
#: ../controller-ha-galera-manage.rst:156
msgid ""
"OpenStack services are configured with the list of these IP addresses so "
"they can select one of the addresses from those available."
msgstr ""
#: ../controller-ha-galera-manage.rst:160
msgid "Galera runs behind HAProxy."
msgstr ""
#: ../controller-ha-galera-manage.rst:162
msgid ""
"HAProxy load balances incoming requests and exposes just one IP address for "
"all the clients."
msgstr ""
#: ../controller-ha-galera-manage.rst:165
msgid ""
"Galera synchronous replication guarantees a zero slave lag. The failover "
"procedure completes once HAProxy detects that the active back end has gone "
"down and switches to the backup one, which is then marked as 'UP'. If no "
"back ends are up (in other words, the Galera cluster is not ready to accept "
"connections), the failover procedure finishes only when the Galera cluster "
"has been successfully reassembled. The SLA is normally no more than 5 "
"minutes."
msgstr ""
#: ../controller-ha-galera-manage.rst:174
msgid ""
"Use MySQL/Galera in active/passive mode to avoid deadlocks on ``SELECT ... "
"FOR UPDATE`` type queries (used, for example, by nova and neutron). This "
"issue is discussed more in the following:"
msgstr ""
#: ../controller-ha-galera-manage.rst:178
msgid "http://lists.openstack.org/pipermail/openstack-dev/2014-May/035264.html"
msgstr ""
#: ../controller-ha-galera-manage.rst:179
msgid "http://www.joinfu.com/"
msgstr ""
#: ../controller-ha-galera-manage.rst:181
msgid ""
"Of these options, the second one is highly recommended. Although Galera "
"supports active/active configurations, we recommend active/passive (enforced "
"by the load balancer) in order to avoid lock contention."
msgstr ""
#: ../controller-ha-galera-manage.rst:188
msgid "Configuring HAProxy"
msgstr ""
#: ../controller-ha-galera-manage.rst:190
msgid ""
"If you use HAProxy for load-balancing client access to Galera Cluster as "
"described in the :doc:`controller-ha-haproxy`, you can use the "
"``clustercheck`` utility to improve health checks."
msgstr ""
#: ../controller-ha-galera-manage.rst:194
msgid ""
"Create a configuration file for ``clustercheck`` at ``/etc/sysconfig/"
"clustercheck``:"
msgstr ""
#: ../controller-ha-galera-manage.rst:204
msgid ""
"Log in to the database client and grant the ``clustercheck`` user "
"``PROCESS`` privileges."
msgstr ""
#: ../controller-ha-galera-manage.rst:214
msgid ""
"You only need to do this on one cluster node. Galera Cluster replicates the "
"user to all the others."
msgstr ""
#: ../controller-ha-galera-manage.rst:217
msgid ""
"Create a configuration file for the HAProxy monitor service, at ``/etc/"
"xinetd.d/galera-monitor``:"
msgstr ""
#: ../controller-ha-galera-manage.rst:239
msgid ""
"Start the ``xinetd`` daemon for ``clustercheck``. For servers that use "
"``init``, run the following commands:"
msgstr ""
#: ../controller-ha-galera-manage.rst:247
msgid "For servers that use ``systemd``, instead run these commands:"
msgstr ""
#: ../controller-ha-galera.rst:2
msgid "Database (Galera Cluster)"
msgstr ""
#: ../controller-ha-galera.rst:4
msgid ""
"The first step is to install the database that sits at the heart of the "
"cluster. To implement high availability, run an instance of the database on "
"each controller node and use Galera Cluster to provide replication between "
"them. Galera Cluster is a synchronous multi-master database cluster, based "
"on MySQL and the InnoDB storage engine. It is a high-availability service "
"that provides high system uptime, no data loss, and scalability for growth."
msgstr ""
#: ../controller-ha-galera.rst:11
msgid ""
"You can achieve high availability for the OpenStack database in many "
"different ways, depending on the type of database that you want to use. "
"There are three implementations of Galera Cluster available to you:"
msgstr ""
#: ../controller-ha-galera.rst:15
msgid ""
"`Galera Cluster for MySQL <http://galeracluster.com/>`_ The MySQL reference "
"implementation from Codership, Oy;"
msgstr ""
#: ../controller-ha-galera.rst:17
msgid ""
"`MariaDB Galera Cluster <https://mariadb.org/>`_ The MariaDB implementation "
"of Galera Cluster, which is commonly supported in environments based on Red "
"Hat distributions;"
msgstr ""
#: ../controller-ha-galera.rst:20
msgid ""
"`Percona XtraDB Cluster <http://www.percona.com/>`_ The XtraDB "
"implementation of Galera Cluster from Percona."
msgstr ""
#: ../controller-ha-galera.rst:23
msgid ""
"In addition to Galera Cluster, you can also achieve high availability "
"through other database options, such as PostgreSQL, which has its own "
"replication system."
msgstr ""
#: ../controller-ha-haproxy.rst:3
msgid "HAProxy"
msgstr ""
#: ../controller-ha-haproxy.rst:5
msgid ""
"HAProxy provides a fast and reliable HTTP reverse proxy and load balancer "
"for TCP or HTTP applications. It is particularly suited for web crawling "
"under very high loads while needing persistence or Layer 7 processing. It "
"realistically supports tens of thousands of connections with recent hardware."
msgstr ""
#: ../controller-ha-haproxy.rst:11
msgid ""
"Each instance of HAProxy configures its front end to accept connections only "
"from the virtual IP (VIP) address and to terminate them as a list of all "
"instances of the corresponding service under load balancing, such as any "
"OpenStack API service."
msgstr ""
#: ../controller-ha-haproxy.rst:16
msgid ""
"This makes the instances of HAProxy act independently and fail over "
"transparently together with the network endpoints (VIP addresses) failover "
"and, therefore, shares the same SLA."
msgstr ""
#: ../controller-ha-haproxy.rst:20
msgid ""
"You can alternatively use a commercial load balancer, which is a hardware or "
"software. A hardware load balancer generally has good performance."
msgstr ""
#: ../controller-ha-haproxy.rst:23
msgid ""
"For detailed instructions about installing HAProxy on your nodes, see its "
"`official documentation <http://www.haproxy.org/#docs>`_."
msgstr ""
#: ../controller-ha-haproxy.rst:28
msgid ""
"HAProxy should not be a single point of failure. It is advisable to have "
"multiple HAProxy instances running, where the number of these instances is a "
"small odd number like 3 or 5. You need to ensure its availability by other "
"means, such as Keepalived or Pacemaker."
msgstr ""
#: ../controller-ha-haproxy.rst:34
msgid ""
"The common practice is to locate an HAProxy instance on each OpenStack "
"controller in the environment."
msgstr ""
#: ../controller-ha-haproxy.rst:37
msgid ""
"Once configured (see example file below), add HAProxy to the cluster and "
"ensure the VIPs can only run on machines where HAProxy is active:"
msgstr ""
# #-#-#-#-# controller-ha-haproxy.pot (High Availability Guide 0.0.1) #-#-#-#-#
# #-#-#-#-# controller-ha-pacemaker.pot (High Availability Guide 0.0.1) #-#-#-#-#
#: ../controller-ha-haproxy.rst:40 ../controller-ha-pacemaker.rst:574
msgid "``pcs``"
msgstr ""
# #-#-#-#-# controller-ha-haproxy.pot (High Availability Guide 0.0.1) #-#-#-#-#
# #-#-#-#-# controller-ha-pacemaker.pot (High Availability Guide 0.0.1) #-#-#-#-#
#: ../controller-ha-haproxy.rst:48 ../controller-ha-pacemaker.rst:565
msgid "``crmsh``"
msgstr ""
#: ../controller-ha-haproxy.rst:50
msgid "TBA"
msgstr ""
#: ../controller-ha-haproxy.rst:53
msgid "Example Config File"
msgstr ""
#: ../controller-ha-haproxy.rst:55
msgid ""
"Here is an example ``/etc/haproxy/haproxy.cfg`` configuration file. You need "
"a copy of it on each controller node."
msgstr ""
#: ../controller-ha-haproxy.rst:60
msgid ""
"To implement any changes made to this you must restart the HAProxy service"
msgstr ""
#: ../controller-ha-haproxy.rst:218
msgid ""
"The Galera cluster configuration directive ``backup`` indicates that two of "
"the three controllers are standby nodes. This ensures that only one node "
"services write requests because OpenStack support for multi-node writes is "
"not yet production-ready."
msgstr ""
#: ../controller-ha-haproxy.rst:225
msgid ""
"The Telemetry API service configuration does not have the ``option httpchk`` "
"directive as it cannot process this check properly. TODO: explain why the "
"Telemetry API is so special"
msgstr ""
#: ../controller-ha-haproxy.rst:229
msgid ""
"[TODO: we need more commentary about the contents and format of this file]"
msgstr ""
#: ../controller-ha-keystone.rst:4
msgid "Identity services (keystone)"
msgstr ""
#: ../controller-ha-keystone.rst:6
msgid ""
"OpenStack Identity (keystone) is the Identity service in OpenStack that is "
"used by many services. You should be familiar with `OpenStack identity "
"concepts <http://docs.openstack.org/liberty/install-guide-ubuntu/common/"
"get_started_identity.html>`_ before proceeding."
msgstr ""
#: ../controller-ha-keystone.rst:13
msgid ""
"Making the OpenStack Identity service highly available in active / passive "
"mode involves:"
msgstr ""
#: ../controller-ha-keystone.rst:16
msgid ":ref:`keystone-pacemaker`"
msgstr ""
#: ../controller-ha-keystone.rst:17
msgid ":ref:`keystone-config-identity`"
msgstr ""
#: ../controller-ha-keystone.rst:18
msgid ":ref:`keystone-services-config`"
msgstr ""
#: ../controller-ha-keystone.rst:23
msgid "Add OpenStack Identity resource to Pacemaker"
msgstr ""
#: ../controller-ha-keystone.rst:25
msgid ""
"You must first download the OpenStack Identity resource to Pacemaker by "
"running the following commands:"
msgstr ""
#: ../controller-ha-keystone.rst:36
msgid ""
"You can now add the Pacemaker configuration for the OpenStack Identity "
"resource by running the :command:`crm configure` command to connect to the "
"Pacemaker cluster. Add the following cluster resources:"
msgstr ""
#: ../controller-ha-keystone.rst:52
msgid ""
"This configuration creates ``p_keystone``, a resource for managing the "
"OpenStack Identity service."
msgstr ""
#: ../controller-ha-keystone.rst:55
msgid ""
":command:`crm configure` supports batch input so you may copy and paste the "
"above lines into your live Pacemaker configuration, and then make changes as "
"required. For example, you may enter edit ``p_ip_keystone`` from the :"
"command:`crm configure` menu and edit the resource to match your preferred "
"virtual IP address."
msgstr ""
#: ../controller-ha-keystone.rst:63
msgid ""
"After you add these resources, commit your configuration changes by "
"entering :command:`commit` from the :command:`crm configure` menu. Pacemaker "
"then starts the OpenStack Identity service and its dependent resources on "
"one of your nodes."
msgstr ""
#: ../controller-ha-keystone.rst:72
msgid "Configure OpenStack Identity service"
msgstr ""
#: ../controller-ha-keystone.rst:74
msgid ""
"Edit the :file:`keystone.conf` file to change the values of the :manpage:"
"`bind(2)` parameters:"
msgstr ""
#: ../controller-ha-keystone.rst:83
msgid ""
"The ``admin_bind_host`` parameter lets you use a private network for admin "
"access."
msgstr ""
#: ../controller-ha-keystone.rst:86
msgid ""
"To be sure that all data is highly available, ensure that everything is "
"stored in the MySQL database (which is also highly available):"
msgstr ""
#: ../controller-ha-keystone.rst:103
msgid ""
"Configure OpenStack services to use the highly available OpenStack Identity"
msgstr ""
#: ../controller-ha-keystone.rst:105
msgid ""
"Your OpenStack services must now point their OpenStack Identity "
"configuration to the highly available virtual cluster IP address rather than "
"point to the physical IP address of an OpenStack Identity server as you "
"would do in a non-HA environment."
msgstr ""
#: ../controller-ha-keystone.rst:112
msgid ""
"For OpenStack Compute, for example, if your OpenStack Identiy service IP "
"address is 10.0.0.11, use the following configuration in your :file:`api-"
"paste.ini` file:"
msgstr ""
#: ../controller-ha-keystone.rst:120
msgid ""
"You also need to create the OpenStack Identity Endpoint with this IP address."
msgstr ""
#: ../controller-ha-keystone.rst:125
msgid ""
"If you are using both private and public IP addresses, you should create two "
"virtual IP addresses and define your endpoint like this:"
msgstr ""
#: ../controller-ha-keystone.rst:139
msgid ""
"If you are using the horizon dashboard, edit the :file:`local_settings.py` "
"file to include the following:"
msgstr ""
# #-#-#-#-# controller-ha-memcached.pot (High Availability Guide 0.0.1) #-#-#-#-#
# #-#-#-#-# intro-ha-arch-pacemaker.pot (High Availability Guide 0.0.1) #-#-#-#-#
#: ../controller-ha-memcached.rst:3 ../intro-ha-arch-pacemaker.rst:179
msgid "Memcached"
msgstr ""
#: ../controller-ha-memcached.rst:5
msgid ""
"Memcached is a general-purpose distributed memory caching system. It is used "
"to speed up dynamic database-driven websites by caching data and objects in "
"RAM to reduce the number of times an external data source must be read."
msgstr ""
#: ../controller-ha-memcached.rst:10
msgid ""
"Memcached is a memory cache demon that can be used by most OpenStack "
"services to store ephemeral data, such as tokens."
msgstr ""
#: ../controller-ha-memcached.rst:13
msgid ""
"Access to memcached is not handled by HAproxy because replicated access is "
"currently only in an experimental state. Instead OpenStack services must be "
"supplied with the full list of hosts running memcached."
msgstr ""
#: ../controller-ha-memcached.rst:18
msgid ""
"The Memcached client implements hashing to balance objects among the "
"instances. Failure of an instance only impacts a percentage of the objects "
"and the client automatically removes it from the list of instances. The SLA "
"is several minutes."
msgstr ""
#: ../controller-ha-pacemaker.rst:3
msgid "Pacemaker cluster stack"
msgstr ""
#: ../controller-ha-pacemaker.rst:5
msgid ""
"`Pacemaker <http://clusterlabs.org/>`_ cluster stack is the state-of-the-art "
"high availability and load balancing stack for the Linux platform. Pacemaker "
"is useful to make OpenStack infrastructure highly available. Also, it is "
"storage and application-agnostic, and in no way specific to OpenStack."
msgstr ""
#: ../controller-ha-pacemaker.rst:11
msgid ""
"Pacemaker relies on the `Corosync <http://corosync.github.io/corosync/>`_ "
"messaging layer for reliable cluster communications. Corosync implements the "
"Totem single-ring ordering and membership protocol. It also provides UDP and "
"InfiniBand based messaging, quorum, and cluster membership to Pacemaker."
msgstr ""
#: ../controller-ha-pacemaker.rst:18
msgid ""
"Pacemaker does not inherently (need or want to) understand the applications "
"it manages. Instead, it relies on resource agents (RAs), scripts that "
"encapsulate the knowledge of how to start, stop, and check the health of "
"each application managed by the cluster."
msgstr ""
#: ../controller-ha-pacemaker.rst:23
msgid ""
"These agents must conform to one of the `OCF <https://github.com/"
"ClusterLabs/ OCF-spec/blob/master/ra/resource-agent-api.md>`_, `SysV Init "
"<http://refspecs.linux-foundation.org/LSB_3.0.0/LSB-Core-generic/ LSB-Core-"
"generic/iniscrptact.html>`_, Upstart, or Systemd standards."
msgstr ""
#: ../controller-ha-pacemaker.rst:28
msgid ""
"Pacemaker ships with a large set of OCF agents (such as those managing MySQL "
"databases, virtual IP addresses, and RabbitMQ), but can also use any agents "
"already installed on your system and can be extended with your own (see the "
"`developer guide <http://www.linux-ha.org/doc/dev-guides/ra-dev-guide."
"html>`_)."
msgstr ""
#: ../controller-ha-pacemaker.rst:34
msgid "The steps to implement the Pacemaker cluster stack are:"
msgstr ""
#: ../controller-ha-pacemaker.rst:36
msgid ":ref:`pacemaker-install`"
msgstr ""
#: ../controller-ha-pacemaker.rst:37
msgid ":ref:`pacemaker-corosync-setup`"
msgstr ""
#: ../controller-ha-pacemaker.rst:38
msgid ":ref:`pacemaker-corosync-start`"
msgstr ""
#: ../controller-ha-pacemaker.rst:39
msgid ":ref:`pacemaker-start`"
msgstr ""
#: ../controller-ha-pacemaker.rst:40
msgid ":ref:`pacemaker-cluster-properties`"
msgstr ""
#: ../controller-ha-pacemaker.rst:45
msgid "Install packages"
msgstr ""
#: ../controller-ha-pacemaker.rst:47
msgid ""
"On any host that is meant to be part of a Pacemaker cluster, you must first "
"establish cluster communications through the Corosync messaging layer. This "
"involves installing the following packages (and their dependencies, which "
"your package manager usually installs automatically):"
msgstr ""
#: ../controller-ha-pacemaker.rst:54
msgid "pacemaker"
msgstr ""
#: ../controller-ha-pacemaker.rst:56
msgid "pcs (CentOS or RHEL) or crmsh"
msgstr ""
#: ../controller-ha-pacemaker.rst:58
msgid "corosync"
msgstr ""
#: ../controller-ha-pacemaker.rst:60
msgid "fence-agents (CentOS or RHEL) or cluster-glue"
msgstr ""
#: ../controller-ha-pacemaker.rst:62
msgid "resource-agents"
msgstr ""
#: ../controller-ha-pacemaker.rst:64
msgid "libqb0"
msgstr ""
#: ../controller-ha-pacemaker.rst:69
msgid "Set up the cluster with `pcs`"
msgstr ""
#: ../controller-ha-pacemaker.rst:71
msgid "Make sure pcs is running and configured to start at boot time:"
msgstr ""
#: ../controller-ha-pacemaker.rst:78
msgid "Set a password for hacluster user **on each host**."
msgstr ""
#: ../controller-ha-pacemaker.rst:80
msgid ""
"Since the cluster is a single administrative domain, it is generally "
"accepted to use the same password on all nodes."
msgstr ""
#: ../controller-ha-pacemaker.rst:88
msgid ""
"Use that password to authenticate to the nodes which will make up the "
"cluster. The :option:`-p` option is used to give the password on command "
"line and makes it easier to script."
msgstr ""
#: ../controller-ha-pacemaker.rst:97
msgid "Create the cluster, giving it a name, and start it:"
msgstr ""
#: ../controller-ha-pacemaker.rst:107
msgid ""
"In Red Hat Enterprise Linux or CentOS environments, this is a recommended "
"path to perform configuration. For more information, see the `RHEL docs "
"<https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/"
"html/High_Availability_Add-On_Reference/ch-clusteradmin-HAAR.html#s1-"
"clustercreate-HAAR>`_."
msgstr ""
#: ../controller-ha-pacemaker.rst:112
msgid "Set up the cluster with `crmsh`"
msgstr ""
#: ../controller-ha-pacemaker.rst:114
msgid ""
"After installing the Corosync package, you must create the :file:`/etc/"
"corosync/corosync.conf` configuration file."
msgstr ""
#: ../controller-ha-pacemaker.rst:118
msgid ""
"For Ubuntu, you should also enable the Corosync service in the ``/etc/"
"default/corosync`` configuration file."
msgstr ""
#: ../controller-ha-pacemaker.rst:121
msgid ""
"Corosync can be configured to work with either multicast or unicast IP "
"addresses or to use the votequorum library."
msgstr ""
#: ../controller-ha-pacemaker.rst:125
msgid ":ref:`corosync-multicast`"
msgstr ""
#: ../controller-ha-pacemaker.rst:126
msgid ":ref:`corosync-unicast`"
msgstr ""
#: ../controller-ha-pacemaker.rst:127
msgid ":ref:`corosync-votequorum`"
msgstr ""
#: ../controller-ha-pacemaker.rst:132
msgid "Set up Corosync with multicast"
msgstr ""
#: ../controller-ha-pacemaker.rst:134
msgid ""
"Most distributions ship an example configuration file (:file:`corosync.conf."
"example`) as part of the documentation bundled with the Corosync package. An "
"example Corosync configuration file is shown below:"
msgstr ""
#: ../controller-ha-pacemaker.rst:139
msgid "**Example Corosync configuration file for multicast (corosync.conf)**"
msgstr ""
#: ../controller-ha-pacemaker.rst:210 ../controller-ha-pacemaker.rst:342
#: ../controller-ha-pacemaker.rst:426 ../controller-ha-pacemaker.rst:583
msgid "Note the following:"
msgstr ""
#: ../controller-ha-pacemaker.rst:212
msgid ""
"The ``token`` value specifies the time, in milliseconds, during which the "
"Corosync token is expected to be transmitted around the ring. When this "
"timeout expires, the token is declared lost, and after "
"``token_retransmits_before_loss_const lost`` tokens, the non-responding "
"processor (cluster node) is declared dead. In other words, ``token × "
"token_retransmits_before_loss_const`` is the maximum time a node is allowed "
"to not respond to cluster messages before being considered dead. The default "
"for token is 1000 milliseconds (1 second), with 4 allowed retransmits. These "
"defaults are intended to minimize failover times, but can cause frequent "
"\"false alarms\" and unintended failovers in case of short network "
"interruptions. The values used here are safer, albeit with slightly extended "
"failover times."
msgstr ""
#: ../controller-ha-pacemaker.rst:228
msgid ""
"With ``secauth`` enabled, Corosync nodes mutually authenticate using a 128-"
"byte shared secret stored in the :file:`/etc/corosync/authkey` file, which "
"may be generated with the :command:`corosync-keygen` utility. When using "
"``secauth``, cluster communications are also encrypted."
msgstr ""
#: ../controller-ha-pacemaker.rst:234
msgid ""
"In Corosync configurations using redundant networking (with more than one "
"interface), you must select a Redundant Ring Protocol (RRP) mode other than "
"none. ``active`` is the recommended RRP mode."
msgstr ""
#: ../controller-ha-pacemaker.rst:239
msgid "Note the following about the recommended interface configuration:"
msgstr ""
#: ../controller-ha-pacemaker.rst:241
msgid ""
"Each configured interface must have a unique ``ringnumber``, starting with 0."
msgstr ""
#: ../controller-ha-pacemaker.rst:244
msgid ""
"The ``bindnetaddr`` is the network address of the interfaces to bind to. The "
"example uses two network addresses of /24 IPv4 subnets."
msgstr ""
#: ../controller-ha-pacemaker.rst:247
msgid ""
"Multicast groups (``mcastaddr``) must not be reused across cluster "
"boundaries. In other words, no two distinct clusters should ever use the "
"same multicast group. Be sure to select multicast addresses compliant with "
"`RFC 2365, \"Administratively Scoped IP Multicast\" <http://www.ietf.org/rfc/"
"rfc2365.txt>`_."
msgstr ""
#: ../controller-ha-pacemaker.rst:255
msgid ""
"For firewall configurations, note that Corosync communicates over UDP only, "
"and uses ``mcastport`` (for receives) and ``mcastport - 1`` (for sends)."
msgstr ""
#: ../controller-ha-pacemaker.rst:260
msgid ""
"The service declaration for the pacemaker service may be placed in the :file:"
"`corosync.conf` file directly or in its own separate file, :file:`/etc/"
"corosync/service.d/pacemaker`."
msgstr ""
#: ../controller-ha-pacemaker.rst:266
msgid ""
"If you are using Corosync version 2 on Ubuntu 14.04, remove or comment out "
"lines under the service stanza, which enables Pacemaker to start up. Another "
"potential problem is the boot and shutdown order of Corosync and Pacemaker. "
"To force Pacemaker to start after Corosync and stop before Corosync, fix the "
"start and kill symlinks manually:"
msgstr ""
#: ../controller-ha-pacemaker.rst:277
msgid ""
"The Pacemaker service also requires an additional configuration file ``/etc/"
"corosync/uidgid.d/pacemaker`` to be created with the following content:"
msgstr ""
#: ../controller-ha-pacemaker.rst:288
msgid ""
"Once created, the :file:`corosync.conf` file (and the :file:`authkey` file "
"if the secauth option is enabled) must be synchronized across all cluster "
"nodes."
msgstr ""
#: ../controller-ha-pacemaker.rst:295
msgid "Set up Corosync with unicast"
msgstr ""
#: ../controller-ha-pacemaker.rst:297
msgid ""
"For environments that do not support multicast, Corosync should be "
"configured for unicast. An example fragment of the :file:`corosync.conf` "
"file for unicastis shown below:"
msgstr ""
#: ../controller-ha-pacemaker.rst:302
msgid "**Corosync configuration file fragment for unicast (corosync.conf)**"
msgstr ""
#: ../controller-ha-pacemaker.rst:344
msgid ""
"If the ``broadcast`` parameter is set to yes, the broadcast address is used "
"for communication. If this option is set, the ``mcastaddr`` parameter should "
"not be set."
msgstr ""
#: ../controller-ha-pacemaker.rst:348
msgid ""
"The ``transport`` directive controls the transport mechanism used. To avoid "
"the use of multicast entirely, specify the ``udpu`` unicast transport "
"parameter. This requires specifying the list of members in the ``nodelist`` "
"directive; this could potentially make up the membership before deployment. "
"The default is ``udp``. The transport type can also be set to ``udpu`` or "
"``iba``."
msgstr ""
#: ../controller-ha-pacemaker.rst:357
msgid ""
"Within the ``nodelist`` directive, it is possible to specify specific "
"information about the nodes in the cluster. The directive can contain only "
"the node sub-directive, which specifies every node that should be a member "
"of the membership, and where non-default options are needed. Every node must "
"have at least the ``ring0_addr`` field filled."
msgstr ""
#: ../controller-ha-pacemaker.rst:367
msgid ""
"For UDPU, every node that should be a member of the membership must be "
"specified."
msgstr ""
#: ../controller-ha-pacemaker.rst:370
msgid "Possible options are:"
msgstr ""
#: ../controller-ha-pacemaker.rst:372
msgid ""
"``ring{X}_addr`` specifies the IP address of one of the nodes. {X} is the "
"ring number."
msgstr ""
#: ../controller-ha-pacemaker.rst:375
msgid ""
"``nodeid`` is optional when using IPv4 and required when using IPv6. This is "
"a 32-bit value specifying the node identifier delivered to the cluster "
"membership service. If this is not specified with IPv4, the node id is "
"determined from the 32-bit IP address of the system to which the system is "
"bound with ring identifier of 0. The node identifier value of zero is "
"reserved and should not be used."
msgstr ""
#: ../controller-ha-pacemaker.rst:388
msgid "Set up Corosync with votequorum library"
msgstr ""
#: ../controller-ha-pacemaker.rst:390
msgid ""
"The votequorum library is part of the corosync project. It provides an "
"interface to the vote-based quorum service and it must be explicitly enabled "
"in the Corosync configuration file. The main role of votequorum library is "
"to avoid split-brain situations, but it also provides a mechanism to:"
msgstr ""
#: ../controller-ha-pacemaker.rst:396
msgid "Query the quorum status"
msgstr ""
#: ../controller-ha-pacemaker.rst:398
msgid "Get a list of nodes known to the quorum service"
msgstr ""
#: ../controller-ha-pacemaker.rst:400
msgid "Receive notifications of quorum state changes"
msgstr ""
#: ../controller-ha-pacemaker.rst:402
msgid "Change the number of votes assigned to a node"
msgstr ""
#: ../controller-ha-pacemaker.rst:404
msgid "Change the number of expected votes for a cluster to be quorate"
msgstr ""
#: ../controller-ha-pacemaker.rst:406
msgid ""
"Connect an additional quorum device to allow small clusters remain quorate "
"during node outages"
msgstr ""
#: ../controller-ha-pacemaker.rst:409
msgid ""
"The votequorum library has been created to replace and eliminate qdisk, the "
"disk-based quorum daemon for CMAN, from advanced cluster configurations."
msgstr ""
#: ../controller-ha-pacemaker.rst:413
msgid ""
"A sample votequorum service configuration in the :file:`corosync.com` file "
"is:"
msgstr ""
#: ../controller-ha-pacemaker.rst:428
msgid ""
"Specifying ``corosync_votequorum`` enables the votequorum library; this is "
"the only required option."
msgstr ""
#: ../controller-ha-pacemaker.rst:431
msgid ""
"The cluster is fully operational with ``expected_votes`` set to 7 nodes "
"(each node has 1 vote), quorum: 4. If a list of nodes is specified as "
"``nodelist``, the ``expected_votes`` value is ignored."
msgstr ""
#: ../controller-ha-pacemaker.rst:436
msgid ""
"Setting ``wait_for_all`` to 1 means that, When starting up a cluster (all "
"nodes down), the cluster quorum is held until all nodes are online and have "
"joined the cluster for the first time. This parameter is new in Corosync 2.0."
msgstr ""
#: ../controller-ha-pacemaker.rst:442
msgid ""
"Setting ``last_man_standing`` to 1 enables the Last Man Standing (LMS) "
"feature; by default, it is disabled (set to 0). If a cluster is on the "
"quorum edge (``expected_votes:`` set to 7; ``online nodes:`` set to 4) for "
"longer than the time specified for the ``last_man_standing_window`` "
"parameter, the cluster can recalculate quorum and continue operating even if "
"the next node will be lost. This logic is repeated until the number of "
"online nodes in the cluster reaches 2. In order to allow the cluster to step "
"down from 2 members to only 1, the ``auto_tie_breaker`` parameter needs to "
"be set; this is not recommended for production environments."
msgstr ""
#: ../controller-ha-pacemaker.rst:457
msgid ""
"``last_man_standing_window`` specifies the time, in milliseconds, required "
"to recalculate quorum after one or more hosts have been lost from the "
"cluster. To do the new quorum recalculation, the cluster must have quorum "
"for at least the interval specified for ``last_man_standing_window``; the "
"default is 10000ms."
msgstr ""
#: ../controller-ha-pacemaker.rst:469
msgid "Start Corosync"
msgstr ""
#: ../controller-ha-pacemaker.rst:471
msgid ""
"Corosync is started as a regular system service. Depending on your "
"distribution, it may ship with an LSB init script, an upstart job, or a "
"systemd unit file. Either way, the service is usually named corosync:"
msgstr ""
#: ../controller-ha-pacemaker.rst:476
msgid ":command:`# /etc/init.d/corosync start` (LSB)"
msgstr ""
#: ../controller-ha-pacemaker.rst:477
msgid ":command:`# service corosync start` (LSB, alternate)"
msgstr ""
#: ../controller-ha-pacemaker.rst:478
msgid ":command:`# start corosync` (upstart)"
msgstr ""
#: ../controller-ha-pacemaker.rst:479
msgid ":command:`# systemctl start corosync` (systemd)"
msgstr ""
#: ../controller-ha-pacemaker.rst:481
msgid "You can now check the Corosync connectivity with two tools."
msgstr ""
#: ../controller-ha-pacemaker.rst:483
msgid ""
"Use the :command:`corosync-cfgtool` utility with the :option:`-s` option to "
"get a summary of the health of the communication rings:"
msgstr ""
#: ../controller-ha-pacemaker.rst:498
msgid ""
"Use the :command:`corosync-objctl` utility to dump the Corosync cluster "
"member list:"
msgstr ""
#: ../controller-ha-pacemaker.rst:511
msgid ""
"You should see a ``status=joined`` entry for each of your constituent "
"cluster nodes."
msgstr ""
#: ../controller-ha-pacemaker.rst:514
msgid ""
"[TODO: Should the main example now use corosync-cmapctl and have the note "
"give the command for Corosync version 1?]"
msgstr ""
#: ../controller-ha-pacemaker.rst:519
msgid ""
"If you are using Corosync version 2, use the :command:`corosync-cmapctl` "
"utility instead of :command:`corosync-objctl`; it is a direct replacement."
msgstr ""
#: ../controller-ha-pacemaker.rst:525
msgid "Start Pacemaker"
msgstr ""
#: ../controller-ha-pacemaker.rst:527
msgid ""
"After the Corosync services have been started and you have verified that the "
"cluster is communicating properly, you can start :command:`pacemakerd`, the "
"Pacemaker master control process:"
msgstr ""
#: ../controller-ha-pacemaker.rst:531
msgid ":command:`# /etc/init.d/pacemaker start` (LSB)"
msgstr ""
#: ../controller-ha-pacemaker.rst:533
msgid ":command:`# service pacemaker start` (LSB, alternate)"
msgstr ""
#: ../controller-ha-pacemaker.rst:535
msgid ":command:`# start pacemaker` (upstart)"
msgstr ""
#: ../controller-ha-pacemaker.rst:537
msgid ":command:`# systemctl start pacemaker` (systemd)"
msgstr ""
#: ../controller-ha-pacemaker.rst:539
msgid ""
"After the Pacemaker services have started, Pacemaker creates a default empty "
"cluster configuration with no resources. Use the :command:`crm_mon` utility "
"to observe the status of Pacemaker:"
msgstr ""
#: ../controller-ha-pacemaker.rst:560
msgid "Set basic cluster properties"
msgstr ""
#: ../controller-ha-pacemaker.rst:562
msgid ""
"After you set up your Pacemaker cluster, you should set a few basic cluster "
"properties:"
msgstr ""
#: ../controller-ha-pacemaker.rst:585
msgid ""
"Setting the ``pe-warn-series-max``, ``pe-input-series-max`` and ``pe-error-"
"series-max`` parameters to 1000 instructs Pacemaker to keep a longer history "
"of the inputs processed and errors and warnings generated by its Policy "
"Engine. This history is useful if you need to troubleshoot the cluster."
msgstr ""
#: ../controller-ha-pacemaker.rst:591
msgid ""
"Pacemaker uses an event-driven approach to cluster state processing. The "
"``cluster-recheck-interval`` parameter (which defaults to 15 minutes) "
"defines the interval at which certain Pacemaker actions occur. It is usually "
"prudent to reduce this to a shorter interval, such as 5 or 3 minutes."
msgstr ""
#: ../controller-ha-pacemaker.rst:597
msgid "After you make these changes, you may commit the updated configuration."
msgstr ""
#: ../controller-ha-rabbitmq.rst:0 ../controller-ha-rabbitmq.rst:76
msgid "Install RabbitMQ"
msgstr ""
# #-#-#-#-# controller-ha-rabbitmq.pot (High Availability Guide 0.0.1) #-#-#-#-#
# #-#-#-#-# intro-ha-arch-pacemaker.pot (High Availability Guide 0.0.1) #-#-#-#-#
#: ../controller-ha-rabbitmq.rst:3 ../intro-ha-arch-pacemaker.rst:178
msgid "RabbitMQ"
msgstr ""
#: ../controller-ha-rabbitmq.rst:5
msgid ""
"An AMQP (Advanced Message Queuing Protocol) compliant message bus is "
"required for most OpenStack components in order to coordinate the execution "
"of jobs entered into the system."
msgstr ""
#: ../controller-ha-rabbitmq.rst:9
msgid ""
"The most popular AMQP implementation used in OpenStack installations is "
"RabbitMQ."
msgstr ""
#: ../controller-ha-rabbitmq.rst:12
msgid ""
"RabbitMQ nodes fail over both on the application and the infrastructure "
"layers."
msgstr ""
#: ../controller-ha-rabbitmq.rst:15
msgid ""
"The application layer is controlled by the ``oslo.messaging`` configuration "
"options for multiple AMQP hosts. If the AMQP node fails, the application "
"reconnects to the next one configured within the specified reconnect "
"interval. The specified reconnect interval constitutes its SLA."
msgstr ""
#: ../controller-ha-rabbitmq.rst:21
msgid ""
"On the infrastructure layer, the SLA is the time for which RabbitMQ cluster "
"reassembles. Several cases are possible. The Mnesia keeper node is the "
"master of the corresponding Pacemaker resource for RabbitMQ; when it fails, "
"the result is a full AMQP cluster downtime interval. Normally, its SLA is no "
"more than several minutes. Failure of another node that is a slave of the "
"corresponding Pacemaker resource for RabbitMQ results in no AMQP cluster "
"downtime at all."
msgstr ""
#: ../controller-ha-rabbitmq.rst:29
msgid ""
"Making the RabbitMQ service highly available involves the following steps:"
msgstr ""
#: ../controller-ha-rabbitmq.rst:31
msgid ":ref:`Install RabbitMQ<rabbitmq-install>`"
msgstr ""
#: ../controller-ha-rabbitmq.rst:33
msgid ":ref:`Configure RabbitMQ for HA queues<rabbitmq-configure>`"
msgstr ""
#: ../controller-ha-rabbitmq.rst:35
msgid ""
":ref:`Configure OpenStack services to use Rabbit HA queues <rabbitmq-"
"services>`"
msgstr ""
#: ../controller-ha-rabbitmq.rst:40
msgid ""
"Access to RabbitMQ is not normally handled by HAproxy. Instead, consumers "
"must be supplied with the full list of hosts running RabbitMQ with "
"``rabbit_hosts`` and turn on the ``rabbit_ha_queues`` option."
msgstr ""
#: ../controller-ha-rabbitmq.rst:45
msgid ""
"Jon Eck found the `core issue <http://people.redhat.com/jeckersb/private/vip-"
"failover-tcp-persist.html>`_ and went into some detail regarding the "
"`history and solution <http://john.eckersberg.com/improving-ha-failures-with-"
"tcp-timeouts.html>`_ on his blog."
msgstr ""
#: ../controller-ha-rabbitmq.rst:51
msgid "In summary though:"
msgstr ""
#: ../controller-ha-rabbitmq.rst:53
msgid ""
"The source address for the connection from HAProxy back to the client is the "
"VIP address. However the VIP address is no longer present on the host. This "
"means that the network (IP) layer deems the packet unroutable, and informs "
"the transport (TCP) layer. TCP, however, is a reliable transport. It knows "
"how to handle transient errors and will retry. And so it does."
msgstr ""
#: ../controller-ha-rabbitmq.rst:60
msgid "In this case that is a problem though, because:"
msgstr ""
#: ../controller-ha-rabbitmq.rst:62
msgid ""
"TCP generally holds on to hope for a long time. A ballpark estimate is "
"somewhere on the order of tens of minutes (30 minutes is commonly "
"referenced). During this time it will keep probing and trying to deliver the "
"data."
msgstr ""
#: ../controller-ha-rabbitmq.rst:67
msgid ""
"It is important to note that HAProxy has no idea that any of this is "
"happening. As far as its process is concerned, it called ``write()`` with "
"the data and the kernel returned success. The resolution is already "
"understood and just needs to make its way through a review."
msgstr ""
#: ../controller-ha-rabbitmq.rst:78
msgid ""
"The commands for installing RabbitMQ are specific to the Linux distribution "
"you are using:"
msgstr ""
#: ../controller-ha-rabbitmq.rst:85
msgid "Distribution"
msgstr ""
#: ../controller-ha-rabbitmq.rst:86
msgid "Command"
msgstr ""
#: ../controller-ha-rabbitmq.rst:87
msgid "Ubuntu, Debian"
msgstr ""
#: ../controller-ha-rabbitmq.rst:88
msgid ":command:`# apt-get install rabbitmq-server`"
msgstr ""
#: ../controller-ha-rabbitmq.rst:89
msgid "RHEL, Fedora, CentOS"
msgstr ""
#: ../controller-ha-rabbitmq.rst:90
msgid ":command:`# yum install rabbitmq-server`"
msgstr ""
#: ../controller-ha-rabbitmq.rst:91
msgid "openSUSE"
msgstr ""
#: ../controller-ha-rabbitmq.rst:92 ../controller-ha-rabbitmq.rst:98
msgid ":command:`# zypper install rabbitmq-server`"
msgstr ""
#: ../controller-ha-rabbitmq.rst:93
msgid "SLES 12"
msgstr ""
#: ../controller-ha-rabbitmq.rst:94
msgid ":command:`# zypper addrepo -f obs://Cloud:OpenStack:Kilo/SLE_12 Kilo`"
msgstr ""
#: ../controller-ha-rabbitmq.rst:96
msgid "[Verify fingerprint of imported GPG key; see below]"
msgstr ""
#: ../controller-ha-rabbitmq.rst:103
msgid ""
"For SLES 12, the packages are signed by GPG key 893A90DAD85F9316. You should "
"verify the fingerprint of the imported GPG key before using it."
msgstr ""
#: ../controller-ha-rabbitmq.rst:114
msgid ""
"For more information, see the official installation manual for the "
"distribution:"
msgstr ""
#: ../controller-ha-rabbitmq.rst:117
msgid "`Debian and Ubuntu <http://www.rabbitmq.com/install-debian.html>`_"
msgstr ""
#: ../controller-ha-rabbitmq.rst:118
msgid ""
"`RPM based <http://www.rabbitmq.com/install-rpm.html>`_ (RHEL, Fedora, "
"CentOS, openSUSE)"
msgstr ""
#: ../controller-ha-rabbitmq.rst:124
msgid "Configure RabbitMQ for HA queues"
msgstr ""
#: ../controller-ha-rabbitmq.rst:126
msgid ""
"[TODO: This section should begin with a brief mention about what HA queues "
"are and why they are valuable, etc]"
msgstr ""
#: ../controller-ha-rabbitmq.rst:129
msgid ""
"We are building a cluster of RabbitMQ nodes to construct a RabbitMQ broker, "
"which is a logical grouping of several Erlang nodes."
msgstr ""
#: ../controller-ha-rabbitmq.rst:132
msgid "The following components/services can work with HA queues:"
msgstr ""
#: ../controller-ha-rabbitmq.rst:134
msgid "[TODO: replace \"currently\" with specific release names]"
msgstr ""
#: ../controller-ha-rabbitmq.rst:136
msgid ""
"[TODO: Does this list need to be updated? Perhaps we need a table that shows "
"each component and the earliest release that allows it to work with HA "
"queues.]"
msgstr ""
#: ../controller-ha-rabbitmq.rst:140
msgid "OpenStack Compute"
msgstr ""
#: ../controller-ha-rabbitmq.rst:141
msgid "OpenStack Block Storage"
msgstr ""
#: ../controller-ha-rabbitmq.rst:142
msgid "OpenStack Networking"
msgstr ""
# #-#-#-#-# controller-ha-rabbitmq.pot (High Availability Guide 0.0.1) #-#-#-#-#
# #-#-#-#-# controller-ha-telemetry.pot (High Availability Guide 0.0.1) #-#-#-#-#
#: ../controller-ha-rabbitmq.rst:143 ../controller-ha-telemetry.rst:4
msgid "Telemetry"
msgstr ""
#: ../controller-ha-rabbitmq.rst:145
msgid ""
"We have to consider that, while exchanges and bindings survive the loss of "
"individual nodes, queues and their messages do not because a queue and its "
"contents are located on one node. If we lose this node, we also lose the "
"queue."
msgstr ""
#: ../controller-ha-rabbitmq.rst:151
msgid ""
"Mirrored queues in RabbitMQ improve the availability of service since it is "
"resilient to failures."
msgstr ""
#: ../controller-ha-rabbitmq.rst:154
msgid ""
"Production servers should run (at least) three RabbitMQ servers; for testing "
"and demonstration purposes, it is possible to run only two servers. In this "
"section, we configure two nodes, called ``rabbit1`` and ``rabbit2``. To "
"build a broker, we need to ensure that all nodes have the same Erlang cookie "
"file."
msgstr ""
#: ../controller-ha-rabbitmq.rst:162
msgid "[TODO: Should the example instead use a minimum of three nodes?]"
msgstr ""
#: ../controller-ha-rabbitmq.rst:164
msgid ""
"To do so, stop RabbitMQ everywhere and copy the cookie from the first node "
"to each of the other node(s):"
msgstr ""
#: ../controller-ha-rabbitmq.rst:171
msgid ""
"On each target node, verify the correct owner, group, and permissions of the "
"file :file:`erlang.cookie`."
msgstr ""
#: ../controller-ha-rabbitmq.rst:179
msgid ""
"Start the message queue service on all nodes and configure it to start when "
"the system boots."
msgstr ""
#: ../controller-ha-rabbitmq.rst:182
msgid "On Ubuntu, it is configured by default."
msgstr ""
#: ../controller-ha-rabbitmq.rst:184
msgid "On CentOS, RHEL, openSUSE, and SLES:"
msgstr ""
#: ../controller-ha-rabbitmq.rst:191
msgid "Verify that the nodes are running:"
msgstr ""
#: ../controller-ha-rabbitmq.rst:202
msgid "Run the following commands on each node except the first one:"
msgstr ""
#: ../controller-ha-rabbitmq.rst:216
msgid ""
"The default node type is a disc node. In this guide, nodes join the cluster "
"as RAM nodes."
msgstr ""
#: ../controller-ha-rabbitmq.rst:219
msgid "To verify the cluster status:"
msgstr ""
#: ../controller-ha-rabbitmq.rst:228
msgid ""
"If the cluster is working, you can create usernames and passwords for the "
"queues."
msgstr ""
#: ../controller-ha-rabbitmq.rst:231
msgid ""
"To ensure that all queues except those with auto-generated names are "
"mirrored across all running nodes, set the ``ha-mode`` policy key to all by "
"running the following command on one of the nodes:"
msgstr ""
#: ../controller-ha-rabbitmq.rst:240
msgid "More information is available in the RabbitMQ documentation:"
msgstr ""
#: ../controller-ha-rabbitmq.rst:242
msgid "`Highly Available Queues <http://www.rabbitmq.com/ha.html>`_"
msgstr ""
#: ../controller-ha-rabbitmq.rst:243
msgid "`Clustering Guide <https://www.rabbitmq.com/clustering.html>`_"
msgstr ""
#: ../controller-ha-rabbitmq.rst:247
msgid ""
"As another option to make RabbitMQ highly available, RabbitMQ contains the "
"OCF scripts for the Pacemaker cluster resource agents since version 3.5.7. "
"It provides the active/active RabbitMQ cluster with mirrored queues. For "
"more information, see `Auto-configuration of a cluster with a Pacemaker "
"<http://www.rabbitmq.com/pacemaker.html>`_."
msgstr ""
#: ../controller-ha-rabbitmq.rst:256
msgid "Configure OpenStack services to use Rabbit HA queues"
msgstr ""
#: ../controller-ha-rabbitmq.rst:258
msgid ""
"We have to configure the OpenStack components to use at least two RabbitMQ "
"nodes."
msgstr ""
#: ../controller-ha-rabbitmq.rst:261
msgid "Do this configuration on all services using RabbitMQ:"
msgstr ""
#: ../controller-ha-rabbitmq.rst:263
msgid "RabbitMQ HA cluster host:port pairs:"
msgstr ""
#: ../controller-ha-rabbitmq.rst:269
msgid ""
"How frequently to retry connecting with RabbitMQ: [TODO: document the unit "
"of measure here? Seconds?]"
msgstr ""
#: ../controller-ha-rabbitmq.rst:276
msgid ""
"How long to back-off for between retries when connecting to RabbitMQ: [TODO: "
"document the unit of measure here? Seconds?]"
msgstr ""
#: ../controller-ha-rabbitmq.rst:283
msgid ""
"Maximum retries with trying to connect to RabbitMQ (infinite by default):"
msgstr ""
#: ../controller-ha-rabbitmq.rst:289
msgid "Use durable queues in RabbitMQ:"
msgstr ""
#: ../controller-ha-rabbitmq.rst:295
msgid "Use HA queues in RabbitMQ (x-ha-policy: all):"
msgstr ""
#: ../controller-ha-rabbitmq.rst:303
msgid ""
"If you change the configuration from an old set-up that did not use HA "
"queues, you should restart the service:"
msgstr ""
#: ../controller-ha-telemetry.rst:6
msgid "[TODO (Add Telemetry overview)]"
msgstr ""
#: ../controller-ha-telemetry.rst:9
msgid "Telemetry central agent"
msgstr ""
#: ../controller-ha-telemetry.rst:11
msgid ""
"The Telemetry central agent can be configured to partition its polling "
"workload between multiple agents, enabling high availability."
msgstr ""
#: ../controller-ha-telemetry.rst:14
msgid ""
"Both the central and the compute agent can run in an HA deployment, which "
"means that multiple instances of these services can run in parallel with "
"workload partitioning among these running instances."
msgstr ""
#: ../controller-ha-telemetry.rst:18
msgid ""
"The `Tooz <https://pypi.python.org/pypi/tooz>`__ library provides the "
"coordination within the groups of service instances. It provides an API "
"above several back ends that can be used for building distributed "
"applications."
msgstr ""
#: ../controller-ha-telemetry.rst:23
msgid ""
"Tooz supports `various drivers <http://docs.openstack.org/developer/tooz/"
"drivers.html>`__ including the following back end solutions:"
msgstr ""
#: ../controller-ha-telemetry.rst:28 ../controller-ha-telemetry.rst:31
msgid "Recommended solution by the Tooz project."
msgstr ""
#: ../controller-ha-telemetry.rst:28
msgid "`Zookeeper <http://zookeeper.apache.org/>`__."
msgstr ""
#: ../controller-ha-telemetry.rst:31
msgid "`Redis <http://redis.io/>`__."
msgstr ""
#: ../controller-ha-telemetry.rst:34
msgid "Recommended for testing."
msgstr ""
#: ../controller-ha-telemetry.rst:34
msgid "`Memcached <http://memcached.org/>`__."
msgstr ""
#: ../controller-ha-telemetry.rst:36
msgid ""
"You must configure a supported Tooz driver for the HA deployment of the "
"Telemetry services."
msgstr ""
#: ../controller-ha-telemetry.rst:39
msgid ""
"For information about the required configuration options that have to be set "
"in the :file:`ceilometer.conf` configuration file for both the central and "
"compute agents, see the `coordination section <http://docs.openstack.org/"
"liberty/config-reference/content/ ch_configuring-openstack-telemetry."
"html>`__ in the OpenStack Configuration Reference."
msgstr ""
#: ../controller-ha-telemetry.rst:46
msgid ""
"Without the ``backend_url`` option being set only one instance of both the "
"central and compute agent service is able to run and function correctly."
msgstr ""
#: ../controller-ha-telemetry.rst:50
msgid ""
"The availability check of the instances is provided by heartbeat messages. "
"When the connection with an instance is lost, the workload will be "
"reassigned within the remained instances in the next polling cycle."
msgstr ""
#: ../controller-ha-telemetry.rst:54
msgid ""
"Memcached uses a timeout value, which should always be set to a value that "
"is higher than the heartbeat value set for Telemetry."
msgstr ""
#: ../controller-ha-telemetry.rst:57
msgid ""
"For backward compatibility and supporting existing deployments, the central "
"agent configuration also supports using different configuration files for "
"groups of service instances of this type that are running in parallel. For "
"enabling this configuration, set a value for the partitioning_group_prefix "
"option in the `central section <http://docs.openstack.org/liberty/ config-"
"reference/content/ch_configuring-openstack-telemetry.html>`__ in the "
"OpenStack Configuration Reference."
msgstr ""
#: ../controller-ha-telemetry.rst:65
msgid ""
"For each sub-group of the central agent pool with the same "
"``partitioning_group_prefix`` a disjoint subset of meters must be polled -- "
"otherwise samples may be missing or duplicated. The list of meters to poll "
"can be set in the :file:`/etc/ceilometer/pipeline.yaml` configuration file. "
"For more information about pipelines see the `Data collection and processing "
"<http://docs.openstack.org/admin-guide-cloud/telemetry-data-collection."
"html#data-collection-and-processing>`__ section."
msgstr ""
#: ../controller-ha-telemetry.rst:74
msgid ""
"To enable the compute agent to run multiple instances simultaneously with "
"workload partitioning, the workload_partitioning option has to be set to "
"``True`` under the `compute section <http://docs.openstack.org/liberty/ "
"config-reference/content/ch_configuring-openstack-telemetry.html>`__ in the :"
"file:`ceilometer.conf` configuration file."
msgstr ""
#: ../controller-ha-vip.rst:4
msgid "Configure the VIP"
msgstr ""
#: ../controller-ha-vip.rst:6
msgid ""
"You must select and assign a virtual IP address (VIP) that can freely float "
"between cluster nodes."
msgstr ""
#: ../controller-ha-vip.rst:9
msgid ""
"This configuration creates ``vip``, a virtual IP address for use by the API "
"node (``10.0.0.11``):"
msgstr ""
#: ../controller-ha-vip.rst:12
msgid "For ``crmsh``:"
msgstr ""
#: ../controller-ha-vip.rst:19
msgid "For ``pcs``:"
msgstr ""
#: ../controller-ha.rst:4
msgid "Configuring the controller for high availability"
msgstr ""
#: ../controller-ha.rst:6
msgid ""
"The cloud controller runs on the management network and must talk to all "
"other services."
msgstr ""
#: ../hardware-ha-basic.rst:4
msgid "Hardware setup"
msgstr ""
#: ../hardware-ha-basic.rst:6
msgid "The standard hardware requirements:"
msgstr ""
#: ../hardware-ha-basic.rst:8
msgid ""
"`Provider networks <http://docs.openstack.org/liberty/install-guide-ubuntu/"
"overview.html#networking-option-1-provider-networks>`_"
msgstr ""
#: ../hardware-ha-basic.rst:9
msgid ""
"`Self-service networks <http://docs.openstack.org/liberty/install-guide-"
"ubuntu/overview.html#networking-option-2-self-service-networks>`_"
msgstr ""
#: ../hardware-ha-basic.rst:11
msgid ""
"However, OpenStack does not require a significant amount of resources and "
"the following minimum requirements should support a proof-of-concept high "
"availability environment with core services and several instances:"
msgstr ""
#: ../hardware-ha-basic.rst:16
msgid "[TODO: Verify that these numbers are good]"
msgstr ""
#: ../hardware-ha-basic.rst:19
msgid "Memory"
msgstr ""
#: ../hardware-ha-basic.rst:19
msgid "NIC"
msgstr ""
#: ../hardware-ha-basic.rst:19
msgid "Node type"
msgstr ""
#: ../hardware-ha-basic.rst:19
msgid "Processor"
msgstr ""
#: ../hardware-ha-basic.rst:19
msgid "Storage"
msgstr ""
#: ../hardware-ha-basic.rst:21
msgid "1-2"
msgstr ""
#: ../hardware-ha-basic.rst:21
msgid "100 GB"
msgstr ""
#: ../hardware-ha-basic.rst:21 ../hardware-ha-basic.rst:23
msgid "2"
msgstr ""
#: ../hardware-ha-basic.rst:21
msgid "8 GB"
msgstr ""
#: ../hardware-ha-basic.rst:21
msgid "controller node"
msgstr ""
#: ../hardware-ha-basic.rst:23
msgid "100+ GB"
msgstr ""
#: ../hardware-ha-basic.rst:23
msgid "2-4+"
msgstr ""
#: ../hardware-ha-basic.rst:23
msgid "8+ GB"
msgstr ""
#: ../hardware-ha-basic.rst:23
msgid "compute node"
msgstr ""
#: ../hardware-ha-basic.rst:27
msgid ""
"For demonstrations and studying, you can set up a test environment on "
"virtual machines (VMs). This has the following benefits:"
msgstr ""
#: ../hardware-ha-basic.rst:31
msgid ""
"One physical server can support multiple nodes, each of which supports "
"almost any number of network interfaces."
msgstr ""
#: ../hardware-ha-basic.rst:34
msgid ""
"Ability to take periodic \"snap shots\" throughout the installation process "
"and \"roll back\" to a working configuration in the event of a problem."
msgstr ""
#: ../hardware-ha-basic.rst:37
msgid ""
"However, running an OpenStack environment on VMs degrades the performance of "
"your instances, particularly if your hypervisor and/or processor lacks "
"support for hardware acceleration of nested VMs."
msgstr ""
#: ../hardware-ha-basic.rst:44
msgid ""
"When installing highly-available OpenStack on VMs, be sure that your "
"hypervisor permits promiscuous mode and disables MAC address filtering on "
"the external network."
msgstr ""
#: ../hardware-ha.rst:4
msgid "Hardware considerations for high availability"
msgstr ""
#: ../hardware-ha.rst:6
msgid ""
"[TODO: Provide a minimal architecture example for HA, expanded on that given "
"in http://docs.openstack.org/liberty/install-guide-ubuntu/environment.html "
"for easy comparison]"
msgstr ""
#: ../index.rst:3
msgid "OpenStack High Availability Guide"
msgstr ""
#: ../index.rst:6
msgid "Abstract"
msgstr ""
#: ../index.rst:8
msgid ""
"This guide describes how to install and configure OpenStack for high "
"availability. It supplements the OpenStack Installation Guides and assumes "
"that you are familiar with the material in those guides."
msgstr ""
#: ../index.rst:13
msgid ""
"This guide documents OpenStack Liberty, OpenStack Kilo, and OpenStack Juno "
"releases."
msgstr ""
#: ../index.rst:16
msgid ""
"This guide is a work-in-progress and changing rapidly while we continue to "
"test and enhance the guidance. Please note where there are open \"to do\" "
"items and help where you are able."
msgstr ""
#: ../index.rst:21
msgid "Contents"
msgstr ""
#: ../index.rst:41
msgid "Search in this guide"
msgstr ""
#: ../index.rst:43
msgid ":ref:`search`"
msgstr ""
#: ../install-ha-memcached.rst:4
msgid "Install memcached"
msgstr ""
#: ../install-ha-memcached.rst:6
msgid ""
"[TODO: Verify that Oslo supports hash synchronization; if so, this should "
"not take more than load balancing.]"
msgstr ""
#: ../install-ha-memcached.rst:9
msgid ""
"[TODO: This hands off to two different docs for install information. We "
"should choose one or explain the specific purpose of each.]"
msgstr ""
#: ../install-ha-memcached.rst:12
msgid ""
"Most OpenStack services can use memcached to store ephemeral data such as "
"tokens. Although memcached does not support typical forms of redundancy such "
"as clustering, OpenStack services can use almost any number of instances by "
"configuring multiple hostnames or IP addresses. The memcached client "
"implements hashing to balance objects among the instances. Failure of an "
"instance only impacts a percentage of the objects and the client "
"automatically removes it from the list of instances."
msgstr ""
#: ../install-ha-memcached.rst:23
msgid ""
"To install and configure memcached, read the `official documentation "
"<https://code.google.com/p/memcached/wiki/NewStart>`_."
msgstr ""
#: ../install-ha-memcached.rst:26
msgid ""
"Memory caching is managed by `oslo.cache <http://specs.openstack.org/"
"openstack/oslo-specs/specs/kilo/oslo-cache-using-dogpile.html>`_ so the way "
"to use multiple memcached servers is the same for all projects."
msgstr ""
#: ../install-ha-memcached.rst:30
msgid "[TODO: Should this show three hosts?]"
msgstr ""
#: ../install-ha-memcached.rst:32
msgid "Example configuration with two hosts:"
msgstr ""
#: ../install-ha-memcached.rst:38
msgid ""
"By default, `controller1` handles the caching service but, if the host goes "
"down, `controller2` does the job. For more information about memcached "
"installation, see the `OpenStack Cloud Administrator Guide <http://docs."
"openstack.org/admin-guide-cloud/>`_."
msgstr ""
#: ../install-ha-ntp.rst:3
msgid "Configure NTP"
msgstr ""
#: ../install-ha-ntp.rst:5
msgid ""
"You must configure NTP to properly synchronize services among nodes. We "
"recommend that you configure the controller node to reference more accurate "
"(lower stratum) servers and other nodes to reference the controller node. "
"For more information, see the `Install Guides <http://docs.openstack.org/"
"#install-guides>`_."
msgstr ""
#: ../install-ha-os.rst:3
msgid "Install operating system on each node"
msgstr ""
#: ../install-ha-os.rst:5
msgid ""
"The first step in setting up your highly-available OpenStack cluster is to "
"install the operating system on each node. Follow the instructions in the "
"OpenStack Installation Guides:"
msgstr ""
#: ../install-ha-os.rst:9
msgid ""
"`CentOS and RHEL <http://docs.openstack.org/liberty/install-guide-rdo/"
"environment.html>`_"
msgstr ""
#: ../install-ha-os.rst:10
msgid ""
"`openSUSE and SUSE Linux Enterprise Server <http://docs.openstack.org/"
"liberty/install-guide-obs/environment.html>`_"
msgstr ""
#: ../install-ha-os.rst:11
msgid ""
"`Ubuntu <http://docs.openstack.org/liberty/install-guide-ubuntu/environment."
"html>`_"
msgstr ""
#: ../install-ha-os.rst:13
msgid ""
"The OpenStack Installation Guides also include a list of the services that "
"use passwords with important notes about using them."
msgstr ""
#: ../install-ha-os.rst:16
msgid "This guide uses the following example IP addresses:"
msgstr ""
#: ../install-ha.rst:3
msgid "Installing high availability packages"
msgstr ""
#: ../install-ha.rst:5
msgid "[TODO -- write intro to this section]"
msgstr ""
#: ../intro-ha-arch-keepalived.rst:3
msgid "The keepalived architecture"
msgstr ""
#: ../intro-ha-arch-keepalived.rst:6
msgid "High availability strategies"
msgstr ""
#: ../intro-ha-arch-keepalived.rst:8
msgid ""
"The following diagram shows a very simplified view of the different "
"strategies used to achieve high availability for the OpenStack services:"
msgstr ""
#: ../intro-ha-arch-keepalived.rst:15
msgid ""
"Depending on the method used to communicate with the service, the following "
"availability strategies will be followed:"
msgstr ""
#: ../intro-ha-arch-keepalived.rst:18
msgid "Keepalived, for the HAProxy instances."
msgstr ""
#: ../intro-ha-arch-keepalived.rst:19
msgid ""
"Access via an HAProxy virtual IP, for services such as HTTPd that are "
"accessed via a TCP socket that can be load balanced"
msgstr ""
#: ../intro-ha-arch-keepalived.rst:21
msgid ""
"Built-in application clustering, when available from the application. Galera "
"is one example of this."
msgstr ""
#: ../intro-ha-arch-keepalived.rst:23
msgid ""
"Starting up one instance of the service on several controller nodes, when "
"they can coexist and coordinate by other means. RPC in ``nova-conductor`` is "
"one example of this."
msgstr ""
#: ../intro-ha-arch-keepalived.rst:26
msgid ""
"No high availability, when the service can only work in active/passive mode."
msgstr ""
#: ../intro-ha-arch-keepalived.rst:29
msgid ""
"There are known issues with cinder-volume that recommend setting it as "
"active-passive for now, see: https://blueprints.launchpad.net/cinder/+spec/"
"cinder-volume-active-active-support"
msgstr ""
#: ../intro-ha-arch-keepalived.rst:33
msgid ""
"While there will be multiple neutron LBaaS agents running, each agent will "
"manage a set of load balancers, that cannot be failed over to another node."
msgstr ""
#: ../intro-ha-arch-keepalived.rst:38
msgid "Architecture limitations"
msgstr ""
#: ../intro-ha-arch-keepalived.rst:40
msgid ""
"This architecture has some inherent limitations that should be kept in mind "
"during deployment and daily operations. The following sections describe "
"these limitations."
msgstr ""
#: ../intro-ha-arch-keepalived.rst:44
msgid "Keepalived and network partitions"
msgstr ""
#: ../intro-ha-arch-keepalived.rst:46
msgid ""
"In case of a network partitioning, there is a chance that two or more nodes "
"running keepalived claim to hold the same VIP, which may lead to an "
"undesired behaviour. Since keepalived uses VRRP over multicast to elect a "
"master (VIP owner), a network partition in which keepalived nodes cannot "
"communicate will result in the VIPs existing on two nodes. When the network "
"partition is resolved, the duplicate VIPs should also be resolved. Note that "
"this network partition problem with VRRP is a known limitation for this "
"architecture."
msgstr ""
#: ../intro-ha-arch-keepalived.rst:56
msgid "Cinder-volume as a single point of failure"
msgstr ""
#: ../intro-ha-arch-keepalived.rst:58
msgid ""
"There are currently concerns over the cinder-volume service ability to run "
"as a fully active-active service. During the Mitaka timeframe, this is being "
"worked on, see: https://blueprints.launchpad.net/cinder/+spec/cinder-volume-"
"active-active-support Thus, cinder-volume will only be running on one of the "
"controller nodes, even if it will be configured on all nodes. In case of a "
"failure in the node running cinder-volume, it should be started in a "
"surviving controller node."
msgstr ""
#: ../intro-ha-arch-keepalived.rst:67
msgid "Neutron-lbaas-agent as a single point of failure"
msgstr ""
#: ../intro-ha-arch-keepalived.rst:69
msgid ""
"The current design of the neutron LBaaS agent using the HAProxy driver does "
"not allow high availability for the tenant load balancers. The neutron-lbaas-"
"agent service will be enabled and running on all controllers, allowing for "
"load balancers to be distributed across all nodes. However, a controller "
"node failure will stop all load balancers running on that node until the "
"service is recovered or the load balancer is manually removed and created "
"again."
msgstr ""
#: ../intro-ha-arch-keepalived.rst:78
msgid "Service monitoring and recovery required"
msgstr ""
#: ../intro-ha-arch-keepalived.rst:80
msgid ""
"An external service monitoring infrastructure is required to check the "
"OpenStack service health, and notify operators in case of any failure. This "
"architecture does not provide any facility for that, so it would be "
"necessary to integrate the OpenStack deployment with any existing monitoring "
"environment."
msgstr ""
#: ../intro-ha-arch-keepalived.rst:86
msgid "Manual recovery after a full cluster restart"
msgstr ""
#: ../intro-ha-arch-keepalived.rst:88
msgid ""
"Some support services used by RDO or RHEL OSP use their own form of "
"application clustering. Usually, these services maintain a cluster quorum, "
"that may be lost in case of a simultaneous restart of all cluster nodes, for "
"example during a power outage. Each service will require its own procedure "
"to regain quorum."
msgstr ""
#: ../intro-ha-arch-keepalived.rst:94
msgid ""
"If you find any or all of these limitations concerning, you are encouraged "
"to refer to the :doc:`Pacemaker HA architecture<intro-ha-arch-pacemaker>` "
"instead."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:3
msgid "The Pacemaker architecture"
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:6
msgid "What is a cluster manager"
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:8
msgid ""
"At its core, a cluster is a distributed finite state machine capable of co-"
"ordinating the startup and recovery of inter-related services across a set "
"of machines."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:12
msgid ""
"Even a distributed and/or replicated application that is able to survive "
"failures on one or more machines can benefit from a cluster manager:"
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:16
msgid "Awareness of other applications in the stack"
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:18
msgid ""
"While SYS-V init replacements like systemd can provide deterministic "
"recovery of a complex stack of services, the recovery is limited to one "
"machine and lacks the context of what is happening on other machines - "
"context that is crucial to determine the difference between a local failure, "
"clean startup and recovery after a total site failure."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:25
msgid "Awareness of instances on other machines"
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:27
msgid ""
"Services like RabbitMQ and Galera have complicated boot-up sequences that "
"require co-ordination, and often serialization, of startup operations across "
"all machines in the cluster. This is especially true after site-wide failure "
"or shutdown where we must first determine the last machine to be active."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:33
msgid ""
"A shared implementation and calculation of `quorum <http://en.wikipedia.org/"
"wiki/Quorum_(Distributed_Systems)>`_."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:36
msgid ""
"It is very important that all members of the system share the same view of "
"who their peers are and whether or not they are in the majority. Failure to "
"do this leads very quickly to an internal `split-brain <http://en.wikipedia."
"org/wiki/Split-brain_(computing)>`_ state - where different parts of the "
"system are pulling in different and incompatible directions."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:43
msgid ""
"Data integrity through fencing (a non-responsive process does not imply it "
"is not doing anything)"
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:46
msgid ""
"A single application does not have sufficient context to know the difference "
"between failure of a machine and failure of the applcation on a machine. The "
"usual practice is to assume the machine is dead and carry on, however this "
"is highly risky - a rogue process or machine could still be responding to "
"requests and generally causing havoc. The safer approach is to make use of "
"remotely accessible power switches and/or network switches and SAN "
"controllers to fence (isolate) the machine before continuing."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:55
msgid "Automated recovery of failed instances"
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:57
msgid ""
"While the application can still run after the failure of several instances, "
"it may not have sufficient capacity to serve the required volume of "
"requests. A cluster can automatically recover failed instances to prevent "
"additional load induced failures."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:62
msgid ""
"For this reason, the use of a cluster manager like `Pacemaker <http://"
"clusterlabs.org>`_ is highly recommended."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:66
msgid "Deployment flavors"
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:68
msgid ""
"It is possible to deploy three different flavors of the Pacemaker "
"architecture. The two extremes are **Collapsed** (where every component runs "
"on every node) and **Segregated** (where every component runs in its own 3+ "
"node cluster)."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:73
msgid ""
"Regardless of which flavor you choose, it is recommended that the clusters "
"contain at least three nodes so that we can take advantage of `quorum "
"<quorum_>`_."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:77
msgid ""
"Quorum becomes important when a failure causes the cluster to split in two "
"or more partitions. In this situation, you want the majority to ensure the "
"minority are truly dead (through fencing) and continue to host resources. "
"For a two-node cluster, no side has the majority and you can end up in a "
"situation where both sides fence each other, or both sides are running the "
"same services - leading to data corruption."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:84
msgid ""
"Clusters with an even number of hosts suffer from similar issues - a single "
"network failure could easily cause a N:N split where neither side retains a "
"majority. For this reason, we recommend an odd number of cluster members "
"when scaling up."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:89
msgid ""
"You can have up to 16 cluster members (this is currently limited by the "
"ability of corosync to scale higher). In extreme cases, 32 and even up to 64 "
"nodes could be possible, however, this is not well tested."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:94
msgid "Collapsed"
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:96
msgid ""
"In this configuration, there is a single cluster of 3 or more nodes on which "
"every component is running."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:99
msgid ""
"This scenario has the advantage of requiring far fewer, if more powerful, "
"machines. Additionally, being part of a single cluster allows us to "
"accurately model the ordering dependencies between components."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:104
msgid "This scenario can be visualized as below."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:109
msgid ""
"You would choose this option if you prefer to have fewer but more powerful "
"boxes."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:112
msgid "This is the most common option and the one we document here."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:115
msgid "Segregated"
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:117
msgid ""
"In this configuration, each service runs in a dedicated cluster of 3 or more "
"nodes."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:120
msgid ""
"The benefits of this approach are the physical isolation between components "
"and the ability to add capacity to specific components."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:123
msgid ""
"You would choose this option if you prefer to have more but less powerful "
"boxes."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:126
msgid ""
"This scenario can be visualized as below, where each box below represents a "
"cluster of three or more guests."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:133
msgid "Mixed"
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:135
msgid ""
"It is also possible to follow a segregated approach for one or more "
"components that are expected to be a bottleneck and use a collapsed approach "
"for the remainder."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:141
msgid "Proxy server"
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:143
msgid ""
"Almost all services in this stack benefit from being proxied. Using a proxy "
"server provides:"
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:146
msgid "Load distribution"
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:148
msgid ""
"Many services can act in an active/active capacity, however, they usually "
"require an external mechanism for distributing requests to one of the "
"available instances. The proxy server can serve this role."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:153
msgid "API isolation"
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:155
msgid ""
"By sending all API access through the proxy, we can clearly identify service "
"interdependencies. We can also move them to locations other than "
"``localhost`` to increase capacity if the need arises."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:160
msgid "Simplified process for adding/removing of nodes"
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:162
msgid ""
"Since all API access is directed to the proxy, adding or removing nodes has "
"no impact on the configuration of other services. This can be very useful in "
"upgrade scenarios where an entirely new set of machines can be configured "
"and tested in isolation before telling the proxy to direct traffic there "
"instead."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:168
msgid "Enhanced failure detection"
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:170
msgid ""
"The proxy can be configured as a secondary mechanism for detecting service "
"failures. It can even be configured to look for nodes in a degraded state "
"(such as being 'too far' behind in the replication) and take them out of "
"circulation."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:175
msgid ""
"The following components are currently unable to benefit from the use of a "
"proxy server:"
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:180
msgid "MongoDB"
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:182
msgid ""
"However, the reasons vary and are discussed under each component's heading."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:185
msgid ""
"We recommend HAProxy as the load balancer, however, there are many "
"alternatives in the marketplace."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:188
msgid ""
"We use a check interval of 1 second, however, the timeouts vary by service."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:190
msgid ""
"Generally, we use round-robin to distribute load amongst instances of active/"
"active services, however, Galera uses the ``stick-table`` options to ensure "
"that incoming connections to the virtual IP (VIP) should be directed to only "
"one of the available back ends."
msgstr ""
#: ../intro-ha-arch-pacemaker.rst:195
msgid ""
"In Galera's case, although it can run active/active, this helps avoid lock "
"contention and prevent deadlocks. It is used in combination with the "
"``httpchk`` option that ensures only nodes that are in sync with its peers "
"are allowed to handle requests."
msgstr ""
#: ../intro-ha-compute.rst:4
msgid "Overview of highly-available compute nodes"
msgstr ""
#: ../intro-ha-concepts.rst:3
msgid "High availability concepts"
msgstr ""
#: ../intro-ha-concepts.rst:5
msgid "High availability systems seek to minimize two things:"
msgstr ""
#: ../intro-ha-concepts.rst:8
msgid ""
"Occurs when a user-facing service is unavailable beyond a specified maximum "
"amount of time."
msgstr ""
#: ../intro-ha-concepts.rst:9
msgid "**System downtime**"
msgstr ""
#: ../intro-ha-concepts.rst:12
msgid "**Data loss**"
msgstr ""
#: ../intro-ha-concepts.rst:12
msgid "Accidental deletion or destruction of data."
msgstr ""
#: ../intro-ha-concepts.rst:14
msgid ""
"Most high availability systems guarantee protection against system downtime "
"and data loss only in the event of a single failure. However, they are also "
"expected to protect against cascading failures, where a single failure "
"deteriorates into a series of consequential failures. Many service providers "
"guarantee :term:`Service Level Agreement (SLA)` including uptime percentage "
"of computing service, which is calculated based on the available time and "
"system downtime excluding planned outage time."
msgstr ""
#: ../intro-ha-concepts.rst:23
msgid "Redundancy and failover"
msgstr ""
#: ../intro-ha-concepts.rst:25
msgid ""
"High availability is implemented with redundant hardware running redundant "
"instances of each service. If one piece of hardware running one instance of "
"a service fails, the system can then failover to use another instance of a "
"service that is running on hardware that did not fail."
msgstr ""
#: ../intro-ha-concepts.rst:31
msgid ""
"A crucial aspect of high availability is the elimination of single points of "
"failure (SPOFs). A SPOF is an individual piece of equipment or software that "
"causes system downtime or data loss if it fails. In order to eliminate "
"SPOFs, check that mechanisms exist for redundancy of:"
msgstr ""
#: ../intro-ha-concepts.rst:37
msgid "Network components, such as switches and routers"
msgstr ""
#: ../intro-ha-concepts.rst:39
msgid "Applications and automatic service migration"
msgstr ""
#: ../intro-ha-concepts.rst:41
msgid "Storage components"
msgstr ""
#: ../intro-ha-concepts.rst:43
msgid "Facility services such as power, air conditioning, and fire protection"
msgstr ""
#: ../intro-ha-concepts.rst:45
msgid ""
"In the event that a component fails and a back-up system must take on its "
"load, most high availability systems will replace the failed component as "
"quickly as possible to maintain necessary redundancy. This way time spent in "
"a degraded protection state is minimized."
msgstr ""
#: ../intro-ha-concepts.rst:50
msgid ""
"Most high availability systems fail in the event of multiple independent "
"(non-consequential) failures. In this case, most implementations favor "
"protecting data over maintaining availability."
msgstr ""
#: ../intro-ha-concepts.rst:54
msgid ""
"High availability systems typically achieve an uptime percentage of 99.99% "
"or more, which roughly equates to less than an hour of cumulative downtime "
"per year. In order to achieve this, high availability systems should keep "
"recovery times after a failure to about one to two minutes, sometimes "
"significantly less."
msgstr ""
#: ../intro-ha-concepts.rst:60
msgid ""
"OpenStack currently meets such availability requirements for its own "
"infrastructure services, meaning that an uptime of 99.99% is feasible for "
"the OpenStack infrastructure proper. However, OpenStack does not guarantee "
"99.99% availability for individual guest instances."
msgstr ""
#: ../intro-ha-concepts.rst:65
msgid ""
"This document discusses some common methods of implementing highly available "
"systems, with an emphasis on the core OpenStack services and other open "
"source services that are closely aligned with OpenStack. These methods are "
"by no means the only ways to do it; you may supplement these services with "
"commercial hardware and software that provides additional features and "
"functionality. You also need to address high availability concerns for any "
"applications software that you run on your OpenStack environment. The "
"important thing is to make sure that your services are redundant and "
"available; how you achieve that is up to you."
msgstr ""
#: ../intro-ha-concepts.rst:77
msgid "Stateless vs. stateful services"
msgstr ""
#: ../intro-ha-concepts.rst:79
msgid ""
"Preventing single points of failure can depend on whether or not a service "
"is stateless."
msgstr ""
#: ../intro-ha-concepts.rst:83
msgid ""
"A service that provides a response after your request and then requires no "
"further attention. To make a stateless service highly available, you need to "
"provide redundant instances and load balance them. OpenStack services that "
"are stateless include ``nova-api``, ``nova-conductor``, ``glance-api``, "
"``keystone-api``, ``neutron-api`` and ``nova-scheduler``."
msgstr ""
#: ../intro-ha-concepts.rst:89
msgid "Stateless service"
msgstr ""
#: ../intro-ha-concepts.rst:92
msgid ""
"A service where subsequent requests to the service depend on the results of "
"the first request. Stateful services are more difficult to manage because a "
"single action typically involves more than one request, so simply providing "
"additional instances and load balancing does not solve the problem. For "
"example, if the horizon user interface reset itself every time you went to a "
"new page, it would not be very useful. OpenStack services that are stateful "
"include the OpenStack database and message queue. Making stateful services "
"highly available can depend on whether you choose an active/passive or "
"active/active configuration."
msgstr ""
#: ../intro-ha-concepts.rst:102
msgid "Stateful service"
msgstr ""
#: ../intro-ha-concepts.rst:105
msgid "Active/Passive vs Active/Active"
msgstr ""
#: ../intro-ha-concepts.rst:107
msgid "Stateful services may be configured as active/passive or active/active:"
msgstr ""
#: ../intro-ha-concepts.rst:110
msgid ""
"Maintains a redundant instance that can be brought online when the active "
"service fails. For example, OpenStack writes to the main database while "
"maintaining a disaster recovery database that can be brought online if the "
"main database fails."
msgstr ""
#: ../intro-ha-concepts.rst:116
msgid ""
"A typical active/passive installation for a stateful service maintains a "
"replacement resource that can be brought online when required. Requests are "
"handled using a :term:`virtual IP` address (VIP) that facilitates returning "
"to service with minimal reconfiguration. A separate application (such as "
"Pacemaker or Corosync) monitors these services, bringing the backup online "
"as necessary."
msgstr ""
#: ../intro-ha-concepts.rst:121
msgid ":term:`active/passive configuration`"
msgstr ""
#: ../intro-ha-concepts.rst:124
msgid ""
"Each service also has a backup but manages both the main and redundant "
"systems concurrently. This way, if there is a failure, the user is unlikely "
"to notice. The backup system is already online and takes on increased load "
"while the main system is fixed and brought back online."
msgstr ""
#: ../intro-ha-concepts.rst:130
msgid ""
"Typically, an active/active installation for a stateless service maintains a "
"redundant instance, and requests are load balanced using a virtual IP "
"address and a load balancer such as HAProxy."
msgstr ""
#: ../intro-ha-concepts.rst:134
msgid ""
"A typical active/active installation for a stateful service includes "
"redundant services, with all instances having an identical state. In other "
"words, updates to one instance of a database update all other instances. "
"This way a request to one instance is the same as a request to any other. A "
"load balancer manages the traffic to these systems, ensuring that "
"operational systems always handle the request."
msgstr ""
#: ../intro-ha-concepts.rst:140
msgid ":term:`active/active configuration`"
msgstr ""
#: ../intro-ha-concepts.rst:143
msgid "Clusters and quorums"
msgstr ""
#: ../intro-ha-concepts.rst:145
msgid ""
"The quorum specifies the minimal number of nodes that must be functional in "
"a cluster of redundant nodes in order for the cluster to remain functional. "
"When one node fails and failover transfers control to other nodes, the "
"system must ensure that data and processes remain sane. To determine this, "
"the contents of the remaining nodes are compared and, if there are "
"discrepancies, a \"majority rules\" algorithm is implemented."
msgstr ""
#: ../intro-ha-concepts.rst:153
msgid ""
"For this reason, each cluster in a high availability environment should have "
"an odd number of nodes and the quorum is defined as more than a half of the "
"nodes. If multiple nodes fail so that the cluster size falls below the "
"quorum value, the cluster itself fails."
msgstr ""
#: ../intro-ha-concepts.rst:159
msgid ""
"For example, in a seven-node cluster, the quorum should be set to floor(7/2) "
"+ 1 == 4. If quorum is four and four nodes fail simultaneously, the cluster "
"itself would fail, whereas it would continue to function, if no more than "
"three nodes fail. If split to partitions of three and four nodes "
"respectively, the quorum of four nodes would continue to operate the "
"majority partition and stop or fence the minority one (depending on the no-"
"quorum-policy cluster configuration)."
msgstr ""
#: ../intro-ha-concepts.rst:167
msgid ""
"And the quorum could also have been set to three, just as a configuration "
"example."
msgstr ""
#: ../intro-ha-concepts.rst:172
msgid ""
"Note that setting the quorum to a value less than floor(n/2) + 1 is not "
"recommended and would likely cause a split-brain in a face of network "
"partitions."
msgstr ""
#: ../intro-ha-concepts.rst:176
msgid ""
"Then, for the given example when four nodes fail simultaneously, the cluster "
"would continue to function as well. But if split to partitions of three and "
"four nodes respectively, the quorum of three would have made both sides to "
"attempt to fence the other and host resources. And without fencing enabled, "
"it would go straight to running two copies of each resource."
msgstr ""
#: ../intro-ha-concepts.rst:182
msgid ""
"This is why setting the quorum to a value less than floor(n/2) + 1 is "
"dangerous. However it may be required for some specific cases, like a "
"temporary measure at a point it is known with 100% certainty that the other "
"nodes are down."
msgstr ""
#: ../intro-ha-concepts.rst:187
msgid ""
"When configuring an OpenStack environment for study or demonstration "
"purposes, it is possible to turn off the quorum checking; this is discussed "
"later in this guide. Production systems should always run with quorum "
"enabled."
msgstr ""
#: ../intro-ha-concepts.rst:194
msgid "Single-controller high availability mode"
msgstr ""
#: ../intro-ha-concepts.rst:196
msgid ""
"OpenStack supports a single-controller high availability mode that is "
"managed by the services that manage highly available environments but is not "
"actually highly available because no redundant controllers are configured to "
"use for failover. This environment can be used for study and demonstration "
"but is not appropriate for a production environment."
msgstr ""
#: ../intro-ha-concepts.rst:203
msgid ""
"It is possible to add controllers to such an environment to convert it into "
"a truly highly available environment."
msgstr ""
#: ../intro-ha-concepts.rst:207
msgid ""
"High availability is not for every user. It presents some challenges. High "
"availability may be too complex for databases or systems with large amounts "
"of data. Replication can slow large systems down. Different setups have "
"different prerequisites. Read the guidelines for each setup."
msgstr ""
#: ../intro-ha-concepts.rst:213
msgid "High availability is turned off as the default in OpenStack setups."
msgstr ""
#: ../intro-ha-controller.rst:3
msgid "Overview of highly-available controllers"
msgstr ""
#: ../intro-ha-controller.rst:5
msgid ""
"OpenStack is a set of multiple services exposed to the end users as HTTP(s) "
"APIs. Additionally, for own internal usage OpenStack requires SQL database "
"server and AMQP broker. The physical servers, where all the components are "
"running are often called controllers. This modular OpenStack architecture "
"allows to duplicate all the components and run them on different "
"controllers. By making all the components redundant it is possible to make "
"OpenStack highly-available."
msgstr ""
#: ../intro-ha-controller.rst:14
msgid ""
"In general we can divide all the OpenStack components into three categories:"
msgstr ""
#: ../intro-ha-controller.rst:16
msgid ""
"OpenStack APIs, these are HTTP(s) stateless services written in python, easy "
"to duplicate and mostly easy to load balance."
msgstr ""
#: ../intro-ha-controller.rst:19
msgid ""
"SQL relational database server provides stateful type consumed by other "
"components. Supported databases are MySQL, MariaDB, and PostgreSQL. Making "
"SQL database redundant is complex."
msgstr ""
#: ../intro-ha-controller.rst:23
msgid ""
":term:`Advanced Message Queuing Protocol (AMQP)` provides OpenStack internal "
"stateful communication service."
msgstr ""
#: ../intro-ha-controller.rst:27
msgid "Network components"
msgstr ""
#: ../intro-ha-controller.rst:29
msgid ""
"[TODO Need discussion of network hardware, bonding interfaces, intelligent "
"Layer 2 switches, routers and Layer 3 switches.]"
msgstr ""
#: ../intro-ha-controller.rst:32
msgid ""
"The configuration uses static routing without Virtual Router Redundancy "
"Protocol (VRRP) or similar techniques implemented."
msgstr ""
#: ../intro-ha-controller.rst:36
msgid ""
"[TODO Need description of VIP failover inside Linux namespaces and expected "
"SLA.]"
msgstr ""
#: ../intro-ha-controller.rst:39
msgid ""
"See [TODO link] for more information about configuring networking for high "
"availability."
msgstr ""
#: ../intro-ha-controller.rst:43
msgid "Common deployement architectures"
msgstr ""
#: ../intro-ha-controller.rst:45
msgid "There are primarily two HA architectures in use today."
msgstr ""
#: ../intro-ha-controller.rst:47
msgid ""
"One uses a cluster manager such as Pacemaker or Veritas to co-ordinate the "
"actions of the various services across a set of machines. Since we are "
"focused on FOSS, we will refer to this as the Pacemaker architecture."
msgstr ""
#: ../intro-ha-controller.rst:52
msgid ""
"The other is optimized for Active/Active services that do not require any "
"inter-machine coordination. In this setup, services are started by your init "
"system (systemd in most modern distributions) and a tool is used to move IP "
"addresses between the hosts. The most common package for doing this is "
"keepalived."
msgstr ""
#: ../intro-ha-other.rst:4
msgid "High availability for other components"
msgstr ""
#: ../intro-ha-storage.rst:3
msgid "Overview of high availability storage"
msgstr ""
#: ../intro-ha-storage.rst:5
msgid ""
"Making the Block Storage (cinder) API service highly available in active/"
"passive mode involves:"
msgstr ""
#: ../intro-ha-storage.rst:8
msgid "Configuring Block Storage to listen on the VIP address"
msgstr ""
#: ../intro-ha-storage.rst:10
msgid ""
"Managing the Block Storage API daemon with the Pacemaker cluster manager"
msgstr ""
#: ../intro-ha-storage.rst:12
msgid "Configuring OpenStack services to use this IP address"
msgstr ""
#: ../intro-ha.rst:4
msgid "Introduction to OpenStack high availability"
msgstr ""
#: ../networking-ha-dhcp.rst:6
msgid "Run neutron DHCP agent"
msgstr ""
#: ../networking-ha-dhcp.rst:8
msgid ""
"The OpenStack Networking service has a scheduler that lets you run multiple "
"agents across nodes; the DHCP agent can be natively highly available. To "
"configure the number of DHCP agents per network, modify the "
"``dhcp_agents_per_network`` parameter in the :file:`/etc/neutron/neutron."
"conf` file. By default this is set to 1. To achieve high availability, "
"assign more than one DHCP agent per network."
msgstr ""
#: ../networking-ha-l3.rst:0
msgid "/etc/neutron/neutron.conf parameters for high availability"
msgstr ""
#: ../networking-ha-l3.rst:6
msgid "Run neutron L3 agent"
msgstr ""
#: ../networking-ha-l3.rst:8
msgid ""
"The neutron L3 agent is scalable, due to the scheduler that supports Virtual "
"Router Redundancy Protocol (VRRP) to distribute virtual routers across "
"multiple nodes. To enable high availability for configured routers, edit "
"the :file:`/etc/neutron/neutron.conf` file to set the following values:"
msgstr ""
#: ../networking-ha-l3.rst:19
msgid "Parameter"
msgstr ""
#: ../networking-ha-l3.rst:20
msgid "Value"
msgstr ""
#: ../networking-ha-l3.rst:21
msgid "Description"
msgstr ""
#: ../networking-ha-l3.rst:22
msgid "l3_ha"
msgstr ""
#: ../networking-ha-l3.rst:23 ../networking-ha-l3.rst:26
msgid "True"
msgstr ""
#: ../networking-ha-l3.rst:24
msgid "All routers are highly available by default."
msgstr ""
#: ../networking-ha-l3.rst:25
msgid "allow_automatic_l3agent_failover"
msgstr ""
#: ../networking-ha-l3.rst:27
msgid "Set automatic L3 agent failover for routers"
msgstr ""
#: ../networking-ha-l3.rst:28
msgid "max_l3_agents_per_router"
msgstr ""
#: ../networking-ha-l3.rst:29 ../networking-ha-l3.rst:32
msgid "2 or more"
msgstr ""
#: ../networking-ha-l3.rst:30
msgid "Maximum number of network nodes to use for the HA router."
msgstr ""
#: ../networking-ha-l3.rst:31
msgid "min_l3_agents_per_router"
msgstr ""
#: ../networking-ha-l3.rst:33
msgid ""
"Minimum number of network nodes to use for the HA router. A new router can "
"be created only if this number of network nodes are available."
msgstr ""
#: ../networking-ha-lbaas.rst:6
msgid "Run neutron LBaaS agent"
msgstr ""
#: ../networking-ha-lbaas.rst:8
msgid ""
"Currently, no native feature is provided to make the LBaaS agent highly "
"available using the default plug-in HAProxy. A common way to make HAProxy "
"highly available is to use the VRRP (Virtual Router Redundancy Protocol). "
"Unfortunately, this is not yet implemented in the LBaaS HAProxy plug-in."
msgstr ""
#: ../networking-ha-lbaas.rst:16
msgid "[TODO: update this section.]"
msgstr ""
#: ../networking-ha-metadata.rst:6
msgid "Run neutron metadata agent"
msgstr ""
#: ../networking-ha-metadata.rst:8
msgid ""
"No native feature is available to make this service highly available. At "
"this time, the Active/Passive solution exists to run the neutron metadata "
"agent in failover mode with Pacemaker."
msgstr ""
#: ../networking-ha-metadata.rst:14
msgid ""
"[TODO: Update this information. Can this service now be made HA in active/"
"active mode or do we need to pull in the instructions to run this service in "
"active/passive mode?]"
msgstr ""
#: ../networking-ha.rst:4
msgid "OpenStack network nodes"
msgstr ""
#: ../networking-ha.rst:6
msgid ""
"Configure networking on each node. The `Networking <http://docs.openstack."
"org/liberty/install-guide-ubuntu/environment-networking.html>`_ section of "
"the *Install Guide* includes basic information about configuring networking."
msgstr ""
#: ../networking-ha.rst:12
msgid "Notes from planning outline:"
msgstr ""
#: ../networking-ha.rst:14
msgid ""
"Rather than configuring neutron here, we should simply mention physical "
"network HA methods such as bonding and additional node/network requirements "
"for L3HA and DVR for planning purposes."
msgstr ""
#: ../networking-ha.rst:18
msgid ""
"Neutron agents shuld be described for active/active; deprecate single "
"agent's instances case."
msgstr ""
#: ../networking-ha.rst:20
msgid "For Kilo and beyond, focus on L3HA and DVR."
msgstr ""
#: ../networking-ha.rst:21
msgid ""
"Link to `Networking Guide <http://docs.openstack.org/networking-guide/>`_ "
"for configuration details."
msgstr ""
#: ../networking-ha.rst:24
msgid ""
"[TODO: Verify that the active/passive network configuration information from "
"`<http://docs.openstack.org/high-availability-guide/content/s-neutron-server."
"html>`_ should not be included here."
msgstr ""
#: ../networking-ha.rst:29
msgid ""
"`LP1328922 <https://bugs.launchpad.net/openstack-manuals/+bug/1328922>` and "
"`LP1349398 <https://bugs.launchpad.net/openstack-manuals/+bug/1349398>` are "
"related.]"
msgstr ""
#: ../networking-ha.rst:34
msgid "OpenStack network nodes contain:"
msgstr ""
#: ../networking-ha.rst:36
msgid ":ref:`Neutron DHCP agent<dhcp-agent>`"
msgstr ""
#: ../networking-ha.rst:37
msgid ""
"Neutron L2 agent. Note that the L2 agent cannot be distributed and highly "
"available. Instead, it must be installed on each data forwarding node to "
"control the virtual network drivers such as Open vSwitch or Linux Bridge. "
"One L2 agent runs per node and controls its virtual interfaces."
msgstr ""
#: ../networking-ha.rst:43
msgid ":ref:`Neutron L3 agent<neutron-l3>`"
msgstr ""
#: ../networking-ha.rst:44
msgid ":ref:`Neutron metadata agent<neutron-metadata>`"
msgstr ""
#: ../networking-ha.rst:45
msgid ":ref:`Neutron LBaaS<neutron-lbaas>` (Load Balancing as a Service) agent"
msgstr ""
#: ../networking-ha.rst:49
msgid ""
"For Liberty, we do not have the standalone network nodes in general. We "
"usually run the Networking services on the controller nodes. In this guide, "
"we use the term \"network nodes\" for convenience."
msgstr ""
#: ../noncore-ha.rst:4
msgid "Configuring non-core components for high availability"
msgstr ""
#: ../storage-ha-backend.rst:6
msgid "Storage back end"
msgstr ""
#: ../storage-ha-backend.rst:8
msgid ""
"Most of this guide concerns the control plane of high availability: ensuring "
"that services continue to run even if a component fails. Ensuring that data "
"is not lost is the data plane component of high availability; this is "
"discussed here."
msgstr ""
#: ../storage-ha-backend.rst:14
msgid "An OpenStack environment includes multiple data pools for the VMs:"
msgstr ""
#: ../storage-ha-backend.rst:16
msgid ""
"Ephemeral storage is allocated for an instance and is deleted when the "
"instance is deleted. The Compute service manages ephemeral storage. By "
"default, Compute stores ephemeral drives as files on local disks on the "
"Compute node but Ceph RBD can instead be used as the storage back end for "
"ephemeral storage."
msgstr ""
#: ../storage-ha-backend.rst:24
msgid ""
"Persistent storage exists outside all instances. Two types of persistent "
"storage are provided:"
msgstr ""
#: ../storage-ha-backend.rst:27
msgid ""
"Block Storage service (cinder) can use LVM or Ceph RBD as the storage back "
"end."
msgstr ""
#: ../storage-ha-backend.rst:29
msgid ""
"Image service (glance) can use the Object Storage service (swift) or Ceph "
"RBD as the storage back end."
msgstr ""
#: ../storage-ha-backend.rst:33
msgid ""
"For more information about configuring storage back ends for the different "
"storage options, see the `Cloud Administrator Guide <http://docs.openstack."
"org/admin-guide-cloud/>`_."
msgstr ""
#: ../storage-ha-backend.rst:37
msgid ""
"This section discusses ways to protect against data loss in your OpenStack "
"environment."
msgstr ""
#: ../storage-ha-backend.rst:41
msgid "RAID drives"
msgstr ""
#: ../storage-ha-backend.rst:43
msgid ""
"Configuring RAID on the hard drives that implement storage protects your "
"data against a hard drive failure. If, however, the node itself fails, data "
"may be lost. In particular, all volumes stored on an LVM node can be lost."
msgstr ""
#: ../storage-ha-backend.rst:49
msgid "Ceph"
msgstr ""
#: ../storage-ha-backend.rst:51
msgid ""
"`Ceph RBD <http://ceph.com/>`_ is an innately high availability storage back "
"end. It creates a storage cluster with multiple nodes that communicate with "
"each other to replicate and redistribute data dynamically. A Ceph RBD "
"storage cluster provides a single shared set of storage nodes that can "
"handle all classes of persistent and ephemeral data -- glance, cinder, and "
"nova -- that are required for OpenStack instances."
msgstr ""
#: ../storage-ha-backend.rst:62
msgid ""
"Ceph RBD provides object replication capabilities by storing Block Storage "
"volumes as Ceph RBD objects; Ceph RBD ensures that each replica of an object "
"is stored on a different node. This means that your volumes are protected "
"against hard drive and node failures or even the failure of the data center "
"itself."
msgstr ""
#: ../storage-ha-backend.rst:70
msgid ""
"When Ceph RBD is used for ephemeral volumes as well as block and image "
"storage, it supports `live migration <http://docs.openstack.org/admin-guide-"
"cloud/compute-live-migration-usage.html>`_ of VMs with ephemeral drives; LVM "
"only supports live migration of volume-backed VMs."
msgstr ""
#: ../storage-ha-backend.rst:78
msgid "Remote backup facilities"
msgstr ""
#: ../storage-ha-backend.rst:80
msgid ""
"[TODO: Add discussion of remote backup facilities as an alternate way to "
"secure ones data. Include brief mention of key third-party technologies with "
"links to their documentation]"
msgstr ""
#: ../storage-ha-cinder.rst:6
msgid "Highly available Block Storage API"
msgstr ""
#: ../storage-ha-cinder.rst:8
msgid ""
"Cinder provides 'block storage as a service' suitable for performance "
"sensitive scenarios such as databases, expandable file systems, or providing "
"a server with access to raw block level storage."
msgstr ""
#: ../storage-ha-cinder.rst:12
msgid ""
"Persistent block storage can survive instance termination and can also be "
"moved across instances like any external storage device. Cinder also has "
"volume snapshots capability for backing up the volumes."
msgstr ""
#: ../storage-ha-cinder.rst:16
msgid ""
"Making this Block Storage API service highly available in active/passive "
"mode involves:"
msgstr ""
#: ../storage-ha-cinder.rst:19
msgid ":ref:`ha-cinder-pacemaker`"
msgstr ""
#: ../storage-ha-cinder.rst:20
msgid ":ref:`ha-cinder-configure`"
msgstr ""
#: ../storage-ha-cinder.rst:21
msgid ":ref:`ha-cinder-services`"
msgstr ""
#: ../storage-ha-cinder.rst:23
msgid ""
"In theory, you can run the Block Storage service as active/active. However, "
"because of sufficient concerns, it is recommended running the volume "
"component as active/passive only."
msgstr ""
#: ../storage-ha-cinder.rst:27
msgid "Jon Bernard writes:"
msgstr ""
#: ../storage-ha-cinder.rst:63
msgid ""
"You can read more about these concerns on the `Red Hat Bugzilla <https://"
"bugzilla.redhat.com/show_bug.cgi?id=1193229>`_ and there is a `psuedo "
"roadmap <https://etherpad.openstack.org/p/cinder-kilo-stabilisation-work>`_ "
"for addressing them upstream."
msgstr ""
#: ../storage-ha-cinder.rst:73
msgid "Add Block Storage API resource to Pacemaker"
msgstr ""
#: ../storage-ha-cinder.rst:75
msgid ""
"On RHEL-based systems, you should create resources for cinder's systemd "
"agents and create constraints to enforce startup/shutdown ordering:"
msgstr ""
#: ../storage-ha-cinder.rst:91
msgid ""
"If the Block Storage service runs on the same nodes as the other services, "
"then it is advisable to also include:"
msgstr ""
#: ../storage-ha-cinder.rst:98
msgid ""
"Alternatively, instead of using systemd agents, download and install the OCF "
"resource agent:"
msgstr ""
#: ../storage-ha-cinder.rst:107
msgid ""
"You can now add the Pacemaker configuration for Block Storage API resource. "
"Connect to the Pacemaker cluster with the :command:`crm configure` command "
"and add the following cluster resources:"
msgstr ""
#: ../storage-ha-cinder.rst:121
msgid ""
"This configuration creates ``p_cinder-api``, a resource for managing the "
"Block Storage API service."
msgstr ""
#: ../storage-ha-cinder.rst:124
msgid ""
"The command :command:`crm configure` supports batch input, so you may copy "
"and paste the lines above into your live pacemaker configuration and then "
"make changes as required. For example, you may enter ``edit p_ip_cinder-"
"api`` from the :command:`crm configure` menu and edit the resource to match "
"your preferred virtual IP address."
msgstr ""
#: ../storage-ha-cinder.rst:131
msgid ""
"Once completed, commit your configuration changes by entering :command:"
"`commit` from the :command:`crm configure` menu. Pacemaker then starts the "
"Block Storage API service and its dependent resources on one of your nodes."
msgstr ""
#: ../storage-ha-cinder.rst:139
msgid "Configure Block Storage API service"
msgstr ""
#: ../storage-ha-cinder.rst:141
msgid "Edit the ``/etc/cinder/cinder.conf`` file:"
msgstr ""
#: ../storage-ha-cinder.rst:143
msgid "On a RHEL-based system, it should look something like:"
msgstr ""
#: ../storage-ha-cinder.rst:184
msgid ""
"Replace ``CINDER_DBPASS`` with the password you chose for the Block Storage "
"database. Replace ``CINDER_PASS`` with the password you chose for the "
"``cinder`` user in the Identity service."
msgstr ""
#: ../storage-ha-cinder.rst:188
msgid ""
"This example assumes that you are using NFS for the physical storage, which "
"will almost never be true in a production installation."
msgstr ""
#: ../storage-ha-cinder.rst:191
msgid ""
"If you are using the Block Storage service OCF agent, some settings will be "
"filled in for you, resulting in a shorter configuration file:"
msgstr ""
#: ../storage-ha-cinder.rst:212
msgid ""
"Replace ``CINDER_DBPASS`` with the password you chose for the Block Storage "
"database."
msgstr ""
#: ../storage-ha-cinder.rst:218
msgid "Configure OpenStack services to use highly available Block Storage API"
msgstr ""
#: ../storage-ha-cinder.rst:220
msgid ""
"Your OpenStack services must now point their Block Storage API configuration "
"to the highly available, virtual cluster IP address rather than a Block "
"Storage API server’s physical IP address as you would for a non-HA "
"environment."
msgstr ""
#: ../storage-ha-cinder.rst:226
msgid "You must create the Block Storage API endpoint with this IP."
msgstr ""
#: ../storage-ha-cinder.rst:228
msgid ""
"If you are using both private and public IP addresses, you should create two "
"virtual IPs and define your endpoint like this:"
msgstr ""
#: ../storage-ha-glance.rst:3
msgid "Highly available OpenStack Image API"
msgstr ""
#: ../storage-ha-glance.rst:5
msgid ""
"The OpenStack Image service offers a service for discovering, registering, "
"and retrieving virtual machine images. To make the OpenStack Image API "
"service highly available in active / passive mode, you must:"
msgstr ""
#: ../storage-ha-glance.rst:10
msgid ":ref:`glance-api-pacemaker`"
msgstr ""
#: ../storage-ha-glance.rst:11
msgid ":ref:`glance-api-configure`"
msgstr ""
#: ../storage-ha-glance.rst:12
msgid ":ref:`glance-services`"
msgstr ""
#: ../storage-ha-glance.rst:14
msgid ""
"This section assumes that you are familiar with the `documentation <http://"
"docs.openstack.org/liberty/install-guide-ubuntu/glance.html>`_ for "
"installing the OpenStack Image API service."
msgstr ""
#: ../storage-ha-glance.rst:22
msgid "Add OpenStack Image API resource to Pacemaker"
msgstr ""
# #-#-#-#-# storage-ha-glance.pot (High Availability Guide 0.0.1) #-#-#-#-#
# #-#-#-#-# storage-ha-manila.pot (High Availability Guide 0.0.1) #-#-#-#-#
#: ../storage-ha-glance.rst:24 ../storage-ha-manila.rst:20
msgid "You must first download the resource agent to your system:"
msgstr ""
#: ../storage-ha-glance.rst:32
msgid ""
"You can now add the Pacemaker configuration for the OpenStack Image API "
"resource. Use the :command:`crm configure` command to connect to the "
"Pacemaker cluster and add the following cluster resources:"
msgstr ""
#: ../storage-ha-glance.rst:47
msgid ""
"This configuration creates ``p_glance-api``, a resource for managing the "
"OpenStack Image API service."
msgstr ""
#: ../storage-ha-glance.rst:50
msgid ""
"The :command:`crm configure` command supports batch input, so you may copy "
"and paste the above into your live Pacemaker configuration and then make "
"changes as required. For example, you may enter edit ``p_ip_glance-api`` "
"from the :command:`crm configure` menu and edit the resource to match your "
"preferred virtual IP address."
msgstr ""
#: ../storage-ha-glance.rst:57
msgid ""
"After completing these steps, commit your configuration changes by entering :"
"command:`commit` from the :command:`crm configure` menu. Pacemaker then "
"starts the OpenStack Image API service and its dependent resources on one of "
"your nodes."
msgstr ""
#: ../storage-ha-glance.rst:66
msgid "Configure OpenStack Image service API"
msgstr ""
#: ../storage-ha-glance.rst:68
msgid ""
"Edit the :file:`/etc/glance/glance-api.conf` file to configure the OpenStack "
"image service:"
msgstr ""
#: ../storage-ha-glance.rst:91
msgid "[TODO: need more discussion of these parameters]"
msgstr ""
#: ../storage-ha-glance.rst:96
msgid ""
"Configure OpenStack services to use highly available OpenStack Image API"
msgstr ""
#: ../storage-ha-glance.rst:98
msgid ""
"Your OpenStack services must now point their OpenStack Image API "
"configuration to the highly available, virtual cluster IP address instead of "
"pointint to the physical IP address of an OpenStack Image API server as you "
"would in a non-HA cluster."
msgstr ""
#: ../storage-ha-glance.rst:105
msgid ""
"For OpenStack Compute, for example, if your OpenStack Image API service IP "
"address is 10.0.0.11 (as in the configuration explained here), you would use "
"the following configuration in your :file:`nova.conf` file:"
msgstr ""
#: ../storage-ha-glance.rst:118
msgid ""
"You must also create the OpenStack Image API endpoint with this IP address. "
"If you are using both private and public IP addresses, you should create two "
"virtual IP addresses and define your endpoint like this:"
msgstr ""
#: ../storage-ha-manila.rst:6
msgid "Highly available Shared File Systems API"
msgstr ""
#: ../storage-ha-manila.rst:8
msgid ""
"Making the Shared File Systems (manila) API service highly available in "
"active/passive mode involves:"
msgstr ""
#: ../storage-ha-manila.rst:11
msgid ":ref:`ha-manila-pacemaker`"
msgstr ""
#: ../storage-ha-manila.rst:12
msgid ":ref:`ha-manila-configure`"
msgstr ""
#: ../storage-ha-manila.rst:13
msgid ":ref:`ha-manila-services`"
msgstr ""
#: ../storage-ha-manila.rst:18
msgid "Add Shared File Systems API resource to Pacemaker"
msgstr ""
#: ../storage-ha-manila.rst:28
msgid ""
"You can now add the Pacemaker configuration for the Shared File Systems API "
"resource. Connect to the Pacemaker cluster with the :command:`crm configure` "
"command and add the following cluster resources:"
msgstr ""
#: ../storage-ha-manila.rst:42
msgid ""
"This configuration creates ``p_manila-api``, a resource for managing the "
"Shared File Systems API service."
msgstr ""
#: ../storage-ha-manila.rst:45
msgid ""
"The :command:`crm configure` supports batch input, so you may copy and paste "
"the lines above into your live Pacemaker configuration and then make changes "
"as required. For example, you may enter ``edit p_ip_manila-api`` from the :"
"command:`crm configure` menu and edit the resource to match your preferred "
"virtual IP address."
msgstr ""
#: ../storage-ha-manila.rst:51
msgid ""
"Once completed, commit your configuration changes by entering :command:"
"`commit` from the :command:`crm configure` menu. Pacemaker then starts the "
"Shared File Systems API service and its dependent resources on one of your "
"nodes."
msgstr ""
#: ../storage-ha-manila.rst:59
msgid "Configure Shared File Systems API service"
msgstr ""
#: ../storage-ha-manila.rst:61
msgid "Edit the :file:`/etc/manila/manila.conf` file:"
msgstr ""
#: ../storage-ha-manila.rst:80
msgid "Configure OpenStack services to use HA Shared File Systems API"
msgstr ""
#: ../storage-ha-manila.rst:82
msgid ""
"Your OpenStack services must now point their Shared File Systems API "
"configuration to the highly available, virtual cluster IP address rather "
"than a Shared File Systems API server’s physical IP address as you would for "
"a non-HA environment."
msgstr ""
#: ../storage-ha-manila.rst:87
msgid "You must create the Shared File Systems API endpoint with this IP."
msgstr ""
#: ../storage-ha-manila.rst:89
msgid ""
"If you are using both private and public IP addresses, you should create two "
"virtual IPs and define your endpoints like this:"
msgstr ""
#: ../storage-ha.rst:3
msgid "Configuring Storage for high availability"
msgstr ""
View Git Blame Copy Permalink