dhodovsk / source-git / pacemaker

Forked from source-git/pacemaker 3 years ago
Clone
Blob Blame History Raw
# 
# AUTHOR <EMAIL@ADDRESS>, YEAR.
#
msgid ""
msgstr ""
"Project-Id-Version: 0\n"
"POT-Creation-Date: 2018-05-14 18:03-0500\n"
"PO-Revision-Date: 2018-05-14 18:03-0500\n"
"Last-Translator: Automatically generated\n"
"Language-Team: None\n"
"MIME-Version: 1.0\n"
"Content-Type: application/x-publican; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Tag: title
#, no-c-format
msgid "Scaling a Pacemaker Cluster"
msgstr ""

#. Tag: title
#, no-c-format
msgid "Overview"
msgstr ""

#. Tag: para
#, no-c-format
msgid "In a basic Pacemaker high-availability cluster,<footnote><para>See the <ulink url=\"http://www.clusterlabs.org/doc/\">Pacemaker documentation</ulink>, especially <emphasis>Clusters From Scratch</emphasis> and <emphasis>Pacemaker Explained</emphasis>, for basic information about high-availability using Pacemaker</para></footnote> each node runs the full cluster stack of corosync and all Pacemaker components. This allows great flexibility but limits scalability to around 16 nodes."
msgstr ""

#. Tag: para
#, no-c-format
msgid "To allow for scalability to dozens or even hundreds of nodes, Pacemaker allows nodes not running the full cluster stack to integrate into the cluster and have the cluster manage their resources as if they were a cluster node."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Terms"
msgstr ""

#. Tag: term
#, no-c-format
msgid "cluster node"
msgstr ""

#. Tag: para
#, no-c-format
msgid "A node running the full high-availability stack of corosync and all Pacemaker components. Cluster nodes may run cluster resources, run all Pacemaker command-line tools (<literal>crm_mon</literal>, <literal>crm_resource</literal> and so on), execute fencing actions, count toward cluster quorum, and serve as the cluster’s Designated Controller (DC). <indexterm> <primary>cluster node</primary> </indexterm> <indexterm> <primary>node</primary><secondary>cluster node</secondary> </indexterm> <indexterm> <primary>cluster node</primary> </indexterm>"
msgstr ""

#. Tag: term
#, no-c-format
msgid "pacemaker_remote"
msgstr ""

#. Tag: para
#, no-c-format
msgid "A small service daemon that allows a host to be used as a Pacemaker node without running the full cluster stack. Nodes running pacemaker_remote may run cluster resources and most command-line tools, but cannot perform other functions of full cluster nodes such as fencing execution, quorum voting or DC eligibility. The pacemaker_remote daemon is an enhanced version of Pacemaker’s local resource management daemon (LRMD). <indexterm> <primary>pacemaker_remote</primary> </indexterm>"
msgstr ""

#. Tag: term
#, no-c-format
msgid "remote node"
msgstr ""

#. Tag: para
#, no-c-format
msgid "A physical host running pacemaker_remote. Remote nodes have a special resource that manages communication with the cluster. This is sometimes referred to as the <emphasis>baremetal</emphasis> case. <indexterm> <primary>remote node</primary> </indexterm> <indexterm> <primary>node</primary><secondary>remote node</secondary> </indexterm> <indexterm> <primary>remote node</primary> </indexterm>"
msgstr ""

#. Tag: term
#, no-c-format
msgid "guest node"
msgstr ""

#. Tag: para
#, no-c-format
msgid "A virtual host running pacemaker_remote. Guest nodes differ from remote nodes mainly in that the guest node is itself a resource that the cluster manages. <indexterm> <primary>guest node</primary> </indexterm> <indexterm> <primary>node</primary><secondary>guest node</secondary> </indexterm> <indexterm> <primary>guest node</primary> </indexterm>"
msgstr ""

#. Tag: para
#, no-c-format
msgid "<emphasis>Remote</emphasis> in this document refers to the node not being a part of the underlying corosync cluster. It has nothing to do with physical proximity. Remote nodes and guest nodes are subject to the same latency requirements as cluster nodes, which means they are typically in the same data center."
msgstr ""

#. Tag: para
#, no-c-format
msgid "It is important to distinguish the various roles a virtual machine can serve in Pacemaker clusters:"
msgstr ""

#. Tag: para
#, no-c-format
msgid "A virtual machine can run the full cluster stack, in which case it is a cluster node and is not itself managed by the cluster."
msgstr ""

#. Tag: para
#, no-c-format
msgid "A virtual machine can be managed by the cluster as a resource, without the cluster having any awareness of the services running inside the virtual machine. The virtual machine is <emphasis>opaque</emphasis> to the cluster."
msgstr ""

#. Tag: para
#, no-c-format
msgid "A virtual machine can be a cluster resource, and run pacemaker_remote to make it a guest node, allowing the cluster to manage services inside it. The virtual machine is <emphasis>transparent</emphasis> to the cluster."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Guest Nodes"
msgstr ""

#. Tag: para
#, no-c-format
msgid "<indexterm> <primary>guest node</primary> </indexterm> <indexterm> <primary>node</primary><secondary>guest node</secondary> </indexterm> <indexterm> <primary>guest node</primary> </indexterm>"
msgstr ""

#. Tag: para
#, no-c-format
msgid "<emphasis role=\"strong\">\"I want a Pacemaker cluster to manage virtual machine resources, but I also want Pacemaker to be able to manage the resources that live within those virtual machines.\"</emphasis>"
msgstr ""

#. Tag: para
#, no-c-format
msgid "Without pacemaker_remote, the possibilities for implementing the above use case have significant limitations:"
msgstr ""

#. Tag: para
#, no-c-format
msgid "The cluster stack could be run on the physical hosts only, which loses the ability to monitor resources within the guests."
msgstr ""

#. Tag: para
#, no-c-format
msgid "A separate cluster could be on the virtual guests, which quickly hits scalability issues."
msgstr ""

#. Tag: para
#, no-c-format
msgid "The cluster stack could be run on the guests using the same cluster as the physical hosts, which also hits scalability issues and complicates fencing."
msgstr ""

#. Tag: para
#, no-c-format
msgid "With pacemaker_remote:"
msgstr ""

#. Tag: para
#, no-c-format
msgid "The physical hosts are cluster nodes (running the full cluster stack)."
msgstr ""

#. Tag: para
#, no-c-format
msgid "The virtual machines are guest nodes (running the pacemaker_remote service). Nearly zero configuration is required on the virtual machine."
msgstr ""

#. Tag: para
#, no-c-format
msgid "The cluster stack on the cluster nodes launches the virtual machines and immediately connects to the pacemaker_remote service on them, allowing the virtual machines to integrate into the cluster."
msgstr ""

#. Tag: para
#, no-c-format
msgid "The key difference here between the guest nodes and the cluster nodes is that the guest nodes do not run the cluster stack. This means they will never become the DC, initiate fencing actions or participate in quorum voting."
msgstr ""

#. Tag: para
#, no-c-format
msgid "On the other hand, this also means that they are not bound to the scalability limits associated with the cluster stack (no 16-node corosync member limits to deal with). That isn’t to say that guest nodes can scale indefinitely, but it is known that guest nodes scale horizontally much further than cluster nodes."
msgstr ""

#. Tag: para
#, no-c-format
msgid "Other than the quorum limitation, these guest nodes behave just like cluster nodes with respect to resource management. The cluster is fully capable of managing and monitoring resources on each guest node. You can build constraints against guest nodes, put them in standby, or do whatever else you’d expect to be able to do with cluster nodes. They even show up in <literal>crm_mon</literal> output as nodes."
msgstr ""

#. Tag: para
#, no-c-format
msgid "To solidify the concept, below is an example that is very similar to an actual deployment we test in our developer environment to verify guest node scalability:"
msgstr ""

#. Tag: para
#, no-c-format
msgid "16 cluster nodes running the full corosync + pacemaker stack"
msgstr ""

#. Tag: para
#, no-c-format
msgid "64 Pacemaker-managed virtual machine resources running pacemaker_remote configured as guest nodes"
msgstr ""

#. Tag: para
#, no-c-format
msgid "64 Pacemaker-managed webserver and database resources configured to run on the 64 guest nodes"
msgstr ""

#. Tag: para
#, no-c-format
msgid "With this deployment, you would have 64 webservers and databases running on 64 virtual machines on 16 hardware nodes, all of which are managed and monitored by the same Pacemaker deployment. It is known that pacemaker_remote can scale to these lengths and possibly much further depending on the specific scenario."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Remote Nodes"
msgstr ""

#. Tag: para
#, no-c-format
msgid "<indexterm> <primary>remote node</primary> </indexterm> <indexterm> <primary>node</primary><secondary>remote node</secondary> </indexterm> <indexterm> <primary>remote node</primary> </indexterm>"
msgstr ""

#. Tag: para
#, no-c-format
msgid "<emphasis role=\"strong\">\"I want my traditional high-availability cluster to scale beyond the limits imposed by the corosync messaging layer.\"</emphasis>"
msgstr ""

#. Tag: para
#, no-c-format
msgid "Ultimately, the primary advantage of remote nodes over cluster nodes is scalability. There are likely some other use cases related to geographically distributed HA clusters that remote nodes may serve a purpose in, but those use cases are not well understood at this point."
msgstr ""

#. Tag: para
#, no-c-format
msgid "Like guest nodes, remote nodes will never become the DC, initiate fencing actions or participate in quorum voting."
msgstr ""

#. Tag: para
#, no-c-format
msgid "That is not to say, however, that fencing of a remote node works any differently than that of a cluster node. The Pacemaker scheduler understands how to fence remote nodes. As long as a fencing device exists, the cluster is capable of ensuring remote nodes are fenced in the exact same way as cluster nodes."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Expanding the Cluster Stack"
msgstr ""

#. Tag: para
#, no-c-format
msgid "With pacemaker_remote, the traditional view of the high-availability stack can be expanded to include a new layer:"
msgstr ""

#. Tag: title
#, no-c-format
msgid "Traditional HA Stack"
msgstr ""

#. Tag: title
#, no-c-format
msgid "HA Stack With Guest Nodes"
msgstr ""