#, fuzzy msgid "" msgstr "" "Project-Id-Version: High Availability Guide 0.0.1\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2016-05-06 01:15+0000\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 `_ 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 `_, 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 `_" 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.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 `_." 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:240 msgid "" "Start the ``xinetd`` daemon for ``clustercheck``. For servers that use " "``init``, run the following commands:" msgstr "" #: ../controller-ha-galera-manage.rst:248 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 `_ The MySQL reference " "implementation from Codership, Oy;" msgstr "" #: ../controller-ha-galera.rst:17 msgid "" "`MariaDB Galera Cluster `_ 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 `_ 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 `_." 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.rst:40 ../controller-ha-pacemaker.rst:610 msgid "``pcs``" msgstr "" #: ../controller-ha-haproxy.rst:48 ../controller-ha-pacemaker.rst:601 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 `_ 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.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 `_ 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 `_ " "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 `_, `SysV Init `_, 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 `_)." 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 " "`_." 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:619 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\" `_." 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.conf` 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 "To start ``corosync`` with the LSB init script:" msgstr "" #: ../controller-ha-pacemaker.rst:482 ../controller-ha-pacemaker.rst:557 msgid "Alternatively:" msgstr "" #: ../controller-ha-pacemaker.rst:488 msgid "To start ``corosync`` with upstart:" msgstr "" #: ../controller-ha-pacemaker.rst:494 msgid "To start ``corosync`` with systemd unit file:" msgstr "" #: ../controller-ha-pacemaker.rst:500 msgid "" "You can now check the ``corosync`` connectivity with one of these tools." msgstr "" #: ../controller-ha-pacemaker.rst:502 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:517 msgid "" "Use the :command:`corosync-objctl` utility to dump the Corosync cluster " "member list:" msgstr "" #: ../controller-ha-pacemaker.rst:530 msgid "" "You should see a ``status=joined`` entry for each of your constituent " "cluster nodes." msgstr "" #: ../controller-ha-pacemaker.rst:533 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:538 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:544 msgid "Start Pacemaker" msgstr "" #: ../controller-ha-pacemaker.rst:546 msgid "" "After the ``corosync`` service have been started and you have verified that " "the cluster is communicating properly, you can start :command:`pacemakerd`, " "the Pacemaker master control process. Choose one from the following four " "ways to start it:" msgstr "" #: ../controller-ha-pacemaker.rst:551 msgid "To start ``pacemaker`` with the LSB init script:" msgstr "" #: ../controller-ha-pacemaker.rst:563 msgid "To start ``pacemaker`` with upstart:" msgstr "" #: ../controller-ha-pacemaker.rst:569 msgid "To start ``pacemaker`` with the systemd unit file:" msgstr "" #: ../controller-ha-pacemaker.rst:575 msgid "" "After the ``pacemaker`` service 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:596 msgid "Set basic cluster properties" msgstr "" #: ../controller-ha-pacemaker.rst:598 msgid "" "After you set up your Pacemaker cluster, you should set a few basic cluster " "properties:" msgstr "" #: ../controller-ha-pacemaker.rst:621 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:627 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:633 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.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`" msgstr "" #: ../controller-ha-rabbitmq.rst:33 msgid ":ref:`Configure RabbitMQ for HA queues`" msgstr "" #: ../controller-ha-rabbitmq.rst:35 msgid "" ":ref:`Configure OpenStack services to use Rabbit HA queues `" 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 `_ and went into some detail regarding the " "`history and solution `_ 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 `_" msgstr "" #: ../controller-ha-rabbitmq.rst:118 msgid "" "`RPM based `_ (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.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 `_" msgstr "" #: ../controller-ha-rabbitmq.rst:243 msgid "`Clustering Guide `_" 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 " "`_." 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 `__ 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 `__ 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 `__." msgstr "" #: ../controller-ha-telemetry.rst:31 msgid "`Redis `__." msgstr "" #: ../controller-ha-telemetry.rst:34 msgid "Recommended for testing." msgstr "" #: ../controller-ha-telemetry.rst:34 msgid "`Memcached `__." 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 `__ 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 `__ 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 " "`__ 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 `__ 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 `_" msgstr "" #: ../hardware-ha-basic.rst:9 msgid "" "`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 Mitaka, OpenStack Liberty, and OpenStack Kilo " "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 `_." msgstr "" #: ../install-ha-memcached.rst:26 msgid "" "Memory caching is managed by `oslo.cache `_ 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 Administrator Guide `_." 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 `_." 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 `_" msgstr "" #: ../install-ha-os.rst:10 msgid "" "`openSUSE and SUSE Linux Enterprise Server `_" msgstr "" #: ../install-ha-os.rst:11 msgid "" "`Ubuntu `_" 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` " "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 `_." 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 `_ 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 `_ 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 " "`_." 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/" "active 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 `_ 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 `_ " "for configuration details." msgstr "" #: ../networking-ha.rst:24 msgid "" "[TODO: Verify that the active/passive network configuration information from " "``_ should not be included here." msgstr "" #: ../networking-ha.rst:29 msgid "" "`LP1328922 `_ and " "`LP1349398 `_ are " "related.]" msgstr "" #: ../networking-ha.rst:34 msgid "OpenStack network nodes contain:" msgstr "" #: ../networking-ha.rst:36 msgid ":ref:`Neutron 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`" msgstr "" #: ../networking-ha.rst:44 msgid ":ref:`Neutron metadata agent`" msgstr "" #: ../networking-ha.rst:45 msgid "" ":ref:`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 `Administrator Guide `_." 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 `_ 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 `_ 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 `_ and there is a `psuedo " "roadmap `_ " "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 `_ 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.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 ""