Network:2-Node KVM Cluster - 修訂歷史

Wells：/* Concept; 虛擬同步 */

2013-09-18T23:41:22Z

‎Concept; 虛擬同步

Wells：/* Concept; 虛擬同步 */

2013-09-18T23:33:19Z

‎Concept; 虛擬同步

Wells：/* Concept; Fencing */

2013-08-17T12:23:13Z

‎Concept; Fencing

Wells：/* Concept; Virtual Synchrony */

2013-08-17T12:03:58Z

‎Concept; Virtual Synchrony

Wells：/* Concept; Virtual Synchrony */

2013-08-15T18:36:13Z

‎Concept; Virtual Synchrony

Wells：/* Concept; quorum */

2013-08-15T18:27:52Z

‎Concept; quorum

Wells：/* Concept; quorum */

2013-08-15T18:18:27Z

‎Concept; quorum

Wells：/* Concept; quorum */

2013-08-15T18:17:08Z

‎Concept; quorum

Wells：/* Component; corosync */

2013-08-15T18:10:14Z

‎Component; corosync

Wells：/* Component; cman 叢集管理者 */

2013-08-15T17:56:56Z

‎Component; cman 叢集管理者

@@ 行 208： / 行 208： @@
 Many cluster operations, like distributed locking and so on, have to occur in the same order across all nodes. This concept is called "virtual synchrony". 許多的叢集運作，像是分散式鎖定等等，必須以相同的順序在所有的節點來發生。這個觀念被稱作是"虛擬同步"。
-This is provided by <source>corosync</source> using "closed process groups", <span class="code">[[CPG]]</span>. A closed process group is simply a private group of processes in a cluster. Within this closed group, all messages between members are ordered. Delivery, however, is not guaranteed. If a member misses messages, it is up to the member's application to decide what action to take.
+This is provided by corosync using "closed process groups", <span class="code">[[CPG]]</span>. A closed process group is simply a private group of processes in a cluster. Within this closed group, all messages between members are ordered. Delivery, however, is not guaranteed. If a member misses messages, it is up to the member's application to decide what action to take.
 這樣的機制透過corosync使用"封閉式行程群組(CFG)"來提供，一個封閉行程群組為叢集中行程的一個簡單私有群組。在一個封閉群組中，在成員中的所有訊息是有序的。只是，傳輸成功與否是不保證的。 如果一個成員錯失掉訊息，由成員的應用系統來決定所要採取的行動。
@@ 行 224： / 行 224： @@
 * The an-node01 member successfully starts service:foo and announces this to the CPG members. an-node01成員成功地啟始了foo服務，並且宣告此項事件給所有的CPG成員。
 * The an-node02 sees that <span class="code">service:foo</span> is now running on <span class="code">an-node01</span> and no longer tries to start the service. an-node02看見了fooo服務執行於an-node01上，並且不再嘗試啟始該服務。
 * The two members want to write to a common area of the <span class="code">/shared</span> GFS2 partition.

@@ 行 208： / 行 208： @@
 Many cluster operations, like distributed locking and so on, have to occur in the same order across all nodes. This concept is called "virtual synchrony". 許多的叢集運作，像是分散式鎖定等等，必須以相同的順序在所有的節點來發生。這個觀念被稱作是"虛擬同步"。
-This is provided by <span class="code">corosync</span> using "closed process groups", <span class="code">[[CPG]]</span>. A closed process group is simply a private group of processes in a cluster. Within this closed group, all messages between members are ordered. Delivery, however, is not guaranteed. If a member misses messages, it is up to the member's application to decide what action to take.
+This is provided by <source>corosync</source> using "closed process groups", <span class="code">[[CPG]]</span>. A closed process group is simply a private group of processes in a cluster. Within this closed group, all messages between members are ordered. Delivery, however, is not guaranteed. If a member misses messages, it is up to the member's application to decide what action to take.
 這樣的機制透過corosync使用"封閉式行程群組(CFG)"來提供，一個封閉行程群組為叢集中行程的一個簡單私有群組。在一個封閉群組中，在成員中的所有訊息是有序的。只是，傳輸成功與否是不保證的。 如果一個成員錯失掉訊息，由成員的應用系統來決定所要採取的行動。
 Let's look at two scenarios showing how locks are handled using CPG;
-* The cluster starts up cleanly with two members.
+* The cluster starts up cleanly with two members. 叢集以2個成員乾淨地啟動
-* Both members are able to start <span class="code">service:foo</span>.
+* Both members are able to start service:foo. 二個成員都能夠啟始foo服務
-* Both want to start it, but need a lock from [[DLM]] to do so.
+* Both want to start it, but need a lock from [[DLM]] to do so. 當二個都想啟始foo服務時，但只有一個從DLM來的一個鎖能夠讓他們達到目的。
-** The <span class="code">an-node01</span> member has its totem token, and sends its request for the lock.
+** The an-node01 member has its totem token, and sends its request for the lock. an-node01成員擁有他自己的totem權杖，送出對該鎖的取得要求。
-** DLM issues a lock for that service to <span class="code">an-node01</span>.
+** DLM issues a lock for that service to an-node01. DLM發出配置該鎖的服務給成員an-node01
-** The <span class="code">an-node02</span> member requests a lock for the same service.
+** The an-node02 member requests a lock for the same service. an-node02也發出了一個要求同樣服務的鎖請求。
-** DLM rejects the lock request.
+** DLM rejects the lock request. DLM 回絕該鎖要求。
-* The <span class="code">an-node01</span> member successfully starts <span class="code">service:foo</span> and announces this to the CPG members.
+* The an-node01 member successfully starts service:foo and announces this to the CPG members. an-node01成員成功地啟始了foo服務，並且宣告此項事件給所有的CPG成員。
-* The <span class="code">an-node02</span> sees that <span class="code">service:foo</span> is now running on <span class="code">an-node01</span> and no longer tries to start the service.
+* The an-node02 sees that <span class="code">service:foo</span> is now running on <span class="code">an-node01</span> and no longer tries to start the service. an-node02看見了fooo服務執行於an-node01上，並且不再嘗試啟始該服務。
 * The two members want to write to a common area of the <span class="code">/shared</span> GFS2 partition.

@@ 行 236： / 行 236： @@
 {{warning|1=DO NOT BUILD A CLUSTER WITHOUT PROPER, WORKING AND TESTED FENCING.}}
-[[Image:fence_meme.jpg|right|300px|thumb|Laugh, but this is a weekly conversation.]]
+Fencing is a '''absolutely critical''' part of clustering. Without '''fully''' working fence devices, '''''your cluster will fail'''''.
-Fencing is a '''absolutely critical''' part of clustering. Without '''fully''' working fence devices, '''''your cluster will fail'''''.
+Sorry, I promise that this will be the only time that I speak so strongly. Fencing really is critical, and explaining the need for fencing is nearly a weekly event. 抱歉，我保證這將是我唯一一次語氣如此地重！Fencing真的是關鍵，並且解釋fencing的需求幾乎是一週的事。
-Sorry, I promise that this will be the only time that I speak so strongly. Fencing really is critical, and explaining the need for fencing is nearly a weekly event.
+So then, let's discuss fencing.
-So then, let's discuss fencing.
+When a node stops responding, an internal timeout and counter start ticking away. During this time, no [[DLM]] locks are allowed to be issued. Anything using DLM, including <span class="code">rgmanager</span>, <span class="code">clvmd</span> and <span class="code">gfs2</span>, are effectively hung. The hung node is detected using a totem token timeout. That is, if a token is not received from a node within a period of time, it is considered lost and a new token is sent. After a certain number of lost tokens, the cluster declares the node dead. The remaining nodes reconfigure into a new cluster and, if they have quorum (or if quorum is ignored), a fence call against the silent node is made.
-When a node stops responding, an internal timeout and counter start ticking away. During this time, no [[DLM]] locks are allowed to be issued. Anything using DLM, including <span class="code">rgmanager</span>, <span class="code">clvmd</span> and <span class="code">gfs2</span>, are effectively hung. The hung node is detected using a totem token timeout. That is, if a token is not received from a node within a period of time, it is considered lost and a new token is sent. After a certain number of lost tokens, the cluster declares the node dead. The remaining nodes reconfigure into a new cluster and, if they have quorum (or if quorum is ignored), a fence call against the silent node is made.
+當一個節點停止回應，一個內部逾時和計時器開始運作，在這個期間，沒有DLM鎖被允許發出。任何使用DLM的事物，包括rgmanager、clvmd和gfs2，被有效率地懸置。透過使用一個totem權杖逾時來偵測出所有懸置的節點。也就是說，如果一個權杖(token)沒有在一個間隔時間內從一個節點被接收到，就被視為遺失，並且一個新的token被發出來。在累積一個相當數量的遺失token後，此叢集宣告該節點為死亡狀態。賸餘的節點重新組態以形成一個新的叢集，並且如果他們達到法定人數(或者，如果quorum是被忽略的)，一個在所有沈默節點的fence呼叫就被製造出來。
 The fence daemon will look at the cluster configuration and get the fence devices configured for the dead node. Then, one at a time and in the order that they appear in the configuration, the fence daemon will call those fence devices, via their fence agents, passing to the fence agent any configured arguments like username, password, port number and so on. If the first fence agent returns a failure, the next fence agent will be called. If the second fails, the third will be called, then the forth and so on. Once the last (or perhaps only) fence device fails, the fence daemon will retry again, starting back at the start of the list. It will do this indefinitely until one of the fence devices succeeds.

@@ 行 203： / 行 203： @@
 Even in a two-node cluster though, proper quorum can be maintained by using a quorum disk, called a [[qdisk]]. Unfortunately, <span class="code">qdisk</span> on a [[DRBD]] resource comes with its own problems, so we will not be able to use it here.
-== Concept; Virtual Synchrony ==
+== Concept; 虛擬同步 ==
 Many cluster operations, like distributed locking and so on, have to occur in the same order across all nodes. This concept is called "virtual synchrony". 許多的叢集運作，像是分散式鎖定等等，必須以相同的順序在所有的節點來發生。這個觀念被稱作是"虛擬同步"。

@@ 行 205： / 行 205： @@
 == Concept; Virtual Synchrony ==
-Many cluster operations, like distributed locking and so on, have to occur in the same order across all nodes. This concept is called "virtual synchrony".
+Many cluster operations, like distributed locking and so on, have to occur in the same order across all nodes. This concept is called "virtual synchrony". 許多的叢集運作，像是分散式鎖定等等，必須以相同的順序在所有的節點來發生。這個觀念被稱作是"虛擬同步"。
 This is provided by <span class="code">corosync</span> using "closed process groups", <span class="code">[[CPG]]</span>. A closed process group is simply a private group of processes in a cluster. Within this closed group, all messages between members are ordered. Delivery, however, is not guaranteed. If a member misses messages, it is up to the member's application to decide what action to take.
 Let's look at two scenarios showing how locks are handled using CPG;

@@ 行 156： / 行 156： @@
 == Concept; quorum ==
+法定人數
 [[Quorum]] is defined as the minimum set of hosts required in order to provide clustered services and is used to prevent [[split-brain]] situations. Quorum被定義為為了提供叢集服務的最少數量主機集合，並且被用來防止split-brain狀況。

@@ 行 160： / 行 160： @@
 [[註]]split-brain是 叢集運算（cluster）中，其中一種應用「高可靠度」（High Availability，簡稱 HA）中的一種錯誤情形。
-本註解資料來源：http://duo-anything.blogspot.tw/2008/06/split-brain.html
+<BR>本註解資料來源：http://duo-anything.blogspot.tw/2008/06/split-brain.html
 模擬情境：

@@ 行 136： / 行 136： @@
 == Component; corosync ==
-Corosync is the heart of the cluster. Almost all other cluster compnents operate though this.
+Corosync is the heart of the cluster. Almost all other cluster components operate though this. Corosync是叢集的心臟，幾乎所有的叢集元件透過此元件來運作。
-In Red Hat clusters, <span class="code">corosync</span> is configured via the central <span class="code">cluster.conf</span> file. It can be configured directly in <span class="code">corosync.conf</span>, but given that we will be building an RHCS cluster, we will only use <span class="code">cluster.conf</span>. That said, almost all <span class="code">corosync.conf</span> options are available in <span class="code">cluster.conf</span>. This is important to note as you will see references to both configuration files when searching the Internet.
+In Red Hat clusters, <span class="code">corosync</span> is configured via the central <span class="code">cluster.conf</span> file.It can be configured directly in <span class="code">corosync.conf</span>, but given that we will be building an RHCS cluster, we will only use <span class="code">cluster.conf</span>. That said, almost all <span class="code">corosync.conf</span> options are available in <span class="code">cluster.conf</span>. This is important to note as you will see references to both configuration files when searching the Internet.
 Corosync sends messages using [[multicast]] messaging by default. Recently, [[unicast]] support has been added, but due to network latency, it is only recommended for use with small clusters of two to four nodes. We will be using [[multicast]] in this tutorial.
 === A Little History ===
 There were significant changes between [[RHCS]] the old version 2 and version 3 available on [[EL6]], which we are using.

@@ 行 132： / 行 132： @@
 The <span class="code">cman</span> portion of the the cluster is the '''c'''luster '''man'''ager. In the 3.0 series used in [[EL6]], <span class="code">cman</span> acts mainly as a [[quorum]] provider. That is, is adds up the votes from the cluster members and decides if there is a simple majority. If there is, the cluster is "quorate" and is allowed to provide cluster services. Newer versions of the Red Hat Cluster Suite found in [[Fedora]] will use a new quorum provider and <span class="code">cman</span> will be removed entirely.
 在EL6所使用的3版系列中，cman主要作用是一個法定人數(quorum)的提供者，也就是說，加入了投票機制來決定當中的簡單多數。 如果這個多數存在的話，該叢集具備"法定人數"並且被允許提供叢集服務。在Fedora所提供的較新版的紅帽叢集化服務中，使用一個新的法定人數提供者，cman被完全地移除掉了。
-Until it is removed, the <span class="code">cman</span> service will be used to start and stop all of the daemons needed to make the cluster operate. 一直到他被移除掉，cman服務將被用來起始和結束所有的需要用來產生叢集運作的精靈(daemons)。
+Until it is removed, the <span class="code">cman</span> service will be used to start and stop all of the daemons needed to make the cluster operate. 除非直到cman被移除掉，否則cman服務將被用來起始和結束所有的需要用來產生叢集運作的精靈(daemons)。
 == Component; corosync ==