ZooKeeperクラスタ管理
3571 ワード
ZooKeeperサービス側は単一ノードとクラスタをサポートすることができ、単一ノードモードでは、すべてのクライアントが同じサービス側ノードに接続されて動作する.クラスタモードの場合、ZooKeeperサービス側はリーダーノードを選択し、他のサービス側ノードはリーダーに接続され、同じデータを保存します.各サービス・エンド・ノードは、読み取り操作を処理できますが、書き込み操作については、leaderノードを介して開始する必要があります.
サービス側ノード管理
クラスタ・モードでは、ZooKeeperサービス・エンドには、次の3つのタイプのサービス・エンド・ノードが含まれます.-leader:クラスタ内のすべてのサービス・エンド・ノードが共同で選択して生成され、create、setData、deleteを含む修正操作の順序を保証します.-follower:leader以外のノードは、leaderの選挙過程に参加し、修正操作の投票に参加します.-observer:leaderの選挙プロセスと変更操作の投票に参加せず、データのみを保存し、データの変更に応答し、クライアントにクエリー操作を提供します.リーダー、follower、observerはすべて完全なデータを保存します.observerノードはleaderの選挙と修正操作の投票に参加しないため、observerノードを増やすことでシステムのスループットを向上させることができますが、クラスタメンテナンスの効率にあまり影響を与えません.
データ照会
ZooKeeperのクエリー操作には、exists、getData、getChildrenが含まれます.クエリー操作の場合、ZooKeeperサービス側は直接ローカルからデータを読み出し、クライアントに返します.この特性のため、ZooKeeperは読み取り操作が非常に迅速であり、サーバ数を拡張することでスループットを容易に増加させることができる.
データの変更
ZooKeeperの変更操作にはcreate、delete、setDataが含まれ、すべての変更操作はleaderによって完了します.具体的な過程は以下の通りである.ZooKeeperクライアントは、変更されたznodeの新しいデータと新しいバージョン番号を含む変更要求を開始します.新しいバージョン番号は、既存のバージョン番号に1を追加します.ZooKeeperサービス側は、変更要求を受信すると、要求をleaderノードに転送します.leaderノードは、変更要求をトランザクションにカプセル化し、変更プロセスを開始します(詳細プロセスは、後続の「データ整合性」セクションを参照).変更操作は原子的であり、ZooKeeperのサービス側がデータを変更する場合は、すべての変更(データとバージョン番号)がトランザクションとして変更されるか、成功するか、失敗するかを確認する必要があります.ZooKeeperは、リレーショナル・データベースのようなロールバック・メカニズムを提供していませんが、複数のトランザクション間で相互影響がないことを保証しています.トランザクションには、同じトランザクションが複数回実行されると、同じ結果が得られるなどのべき乗が必要です.さらに、同じトランザクションが複数回実行され、同じ順序で実行される限り、同じ結果が得られます.ZooKeeperは、各トランザクションに対して一意の識別zxid(ZooKeeper transaction ID)を生成し、zxidは、ZooKeeperのサービス側がシーケンス的にトランザクションを実行することを保証するために使用される.zxidはepochとcounterの2つの部分に分けられ、それぞれ32ビットを占めています.epochは現在どのleaderであるかを識別し、counterは現在のleaderが処理しているトランザクションのフロー番号を識別します.新しいリーダーが生成されると、epochに1を追加して、サーバ間でステータスを同期させることができます.新しいトランザクションを処理するたびにcounterが1ずつ加算されるため、2つのトランザクションのzxidがzxid 1、zxid 2の場合、zxid 1がzxid 2より大きい場合、zxid 1はzxid 2の後に生成されます.
リーダー選挙
Zookeeperのleaderの役割は、クライアントのcreate、setData、delete操作をソートすることです.リーダーはクラスタ内のノードとともに選択されます.
サービス側ノード状態管理
ZooKeeperのサービス・エンド・ノードには、次の状態があります.
Split-Brain
Split-Brainの問題は,ネットワークに障害が発生した場合,クラスタが2つの部分に分けられ,2つの部分が正常に動作しているかどうか分からないため,この2つの部分はいずれも1つのleaderを選択し,2つの部分がleaderを選択するとネットワークが回復し,セット全体に2つのleaderが出現し,クラスタの状態が一致しないことである.ZooKeeperはSplit-Brainの問題を解決するために、クラスタの少なくとも半分以上のノード(oberverを含まない)がクラスタ全体を正常に動作することを要求している.これもクラスタノード数が奇数許容度が高い理由である.クラスタノードの数が3であるため、1つのノードの失効を許容する.クラスタノード数は4であり、1ノードの失効を許容し、ノード数は4であり、許容失効のノード数を増加させることなく、逆にデータ同期の負担を増加させる(スループットを増加させることはobserverノードを増加させることによって実現できる).
リーダー選挙過程
ZooKeeperサービス側ノードが起動するとLOOKING状態に入り、クラスタにすでにリーダーが存在する場合、他のノードはそのノードリーダーが誰であるかを通知し、そのノードがリーダーに接続されると、リーダーとデータ同期を開始し、自分の状態とリーダーの状態が一致することを確保します.クラスタにリーダーが存在しない場合、そのノードはクラスタ内の他のすべてのノードとともに1つのリーダーを選択し、選択されたリーダーはLEADING状態に入り、リーダーにならない選択ノードはFOLLOWING状態に入る必要がある.選挙プロセスは、ノードがLOOKING状態に入ると、クラスタ内の他のすべてのノードに通知メッセージを送信し、現在の投票オブジェクトのサーバID(sid)と投票オブジェクトが最後に実行したトランザクションのzxidを含む.ノードが投票通知を受信すると、次のルールに従って処理されます. voteIdおよびvoteZxidは、通知メッセージを受信したsidおよびzxidである. (voteZxid>myZxid)または(voteZxid=myZxid and voteId>mySid)の場合、現在の投票は保持されます. それ以外の場合は、自身sidおよびzxidをvoteIdおよびvoteZxidとする.
1つのノードがほとんどのノード(半分以上)の同じ投票を受け取ると、ノードはleader選挙の完了を宣言します.リーダーが彼自身であれば、リーダーロールを実行し始めます.そうしないとfollowerになり、リーダーに接続しようとします.リーダーに接続すると、ステータスとの同期が開始され、ステータスの同期が完了するとfollowerが新しいリクエストの処理を開始します.接続に失敗した場合、serverは使用できません.ZooKeeperの選挙過程は,クラスタの半分以上のノードが利用可能であればクラスタが正常に動作することを決定した.クラスタのリーダーがオフになった後、クラスタの残りの半分以上のノードが使用可能であれば、クラスタは新しいリーダーを選択して正常に動作し続けることができます.
サービス側ノード管理
クラスタ・モードでは、ZooKeeperサービス・エンドには、次の3つのタイプのサービス・エンド・ノードが含まれます.-leader:クラスタ内のすべてのサービス・エンド・ノードが共同で選択して生成され、create、setData、deleteを含む修正操作の順序を保証します.-follower:leader以外のノードは、leaderの選挙過程に参加し、修正操作の投票に参加します.-observer:leaderの選挙プロセスと変更操作の投票に参加せず、データのみを保存し、データの変更に応答し、クライアントにクエリー操作を提供します.リーダー、follower、observerはすべて完全なデータを保存します.observerノードはleaderの選挙と修正操作の投票に参加しないため、observerノードを増やすことでシステムのスループットを向上させることができますが、クラスタメンテナンスの効率にあまり影響を与えません.
データ照会
ZooKeeperのクエリー操作には、exists、getData、getChildrenが含まれます.クエリー操作の場合、ZooKeeperサービス側は直接ローカルからデータを読み出し、クライアントに返します.この特性のため、ZooKeeperは読み取り操作が非常に迅速であり、サーバ数を拡張することでスループットを容易に増加させることができる.
データの変更
ZooKeeperの変更操作にはcreate、delete、setDataが含まれ、すべての変更操作はleaderによって完了します.具体的な過程は以下の通りである.ZooKeeperクライアントは、変更されたznodeの新しいデータと新しいバージョン番号を含む変更要求を開始します.新しいバージョン番号は、既存のバージョン番号に1を追加します.ZooKeeperサービス側は、変更要求を受信すると、要求をleaderノードに転送します.leaderノードは、変更要求をトランザクションにカプセル化し、変更プロセスを開始します(詳細プロセスは、後続の「データ整合性」セクションを参照).変更操作は原子的であり、ZooKeeperのサービス側がデータを変更する場合は、すべての変更(データとバージョン番号)がトランザクションとして変更されるか、成功するか、失敗するかを確認する必要があります.ZooKeeperは、リレーショナル・データベースのようなロールバック・メカニズムを提供していませんが、複数のトランザクション間で相互影響がないことを保証しています.トランザクションには、同じトランザクションが複数回実行されると、同じ結果が得られるなどのべき乗が必要です.さらに、同じトランザクションが複数回実行され、同じ順序で実行される限り、同じ結果が得られます.ZooKeeperは、各トランザクションに対して一意の識別zxid(ZooKeeper transaction ID)を生成し、zxidは、ZooKeeperのサービス側がシーケンス的にトランザクションを実行することを保証するために使用される.zxidはepochとcounterの2つの部分に分けられ、それぞれ32ビットを占めています.epochは現在どのleaderであるかを識別し、counterは現在のleaderが処理しているトランザクションのフロー番号を識別します.新しいリーダーが生成されると、epochに1を追加して、サーバ間でステータスを同期させることができます.新しいトランザクションを処理するたびにcounterが1ずつ加算されるため、2つのトランザクションのzxidがzxid 1、zxid 2の場合、zxid 1がzxid 2より大きい場合、zxid 1はzxid 2の後に生成されます.
リーダー選挙
Zookeeperのleaderの役割は、クライアントのcreate、setData、delete操作をソートすることです.リーダーはクラスタ内のノードとともに選択されます.
サービス側ノード状態管理
ZooKeeperのサービス・エンド・ノードには、次の状態があります.
- LOOKING： leader， leader ；
- LEADING： leader ， leader；
- FOLLOWING： leader ， follower。
Split-Brain
Split-Brainの問題は,ネットワークに障害が発生した場合,クラスタが2つの部分に分けられ,2つの部分が正常に動作しているかどうか分からないため,この2つの部分はいずれも1つのleaderを選択し,2つの部分がleaderを選択するとネットワークが回復し,セット全体に2つのleaderが出現し,クラスタの状態が一致しないことである.ZooKeeperはSplit-Brainの問題を解決するために、クラスタの少なくとも半分以上のノード(oberverを含まない)がクラスタ全体を正常に動作することを要求している.これもクラスタノード数が奇数許容度が高い理由である.クラスタノードの数が3であるため、1つのノードの失効を許容する.クラスタノード数は4であり、1ノードの失効を許容し、ノード数は4であり、許容失効のノード数を増加させることなく、逆にデータ同期の負担を増加させる(スループットを増加させることはobserverノードを増加させることによって実現できる).
リーダー選挙過程
ZooKeeperサービス側ノードが起動するとLOOKING状態に入り、クラスタにすでにリーダーが存在する場合、他のノードはそのノードリーダーが誰であるかを通知し、そのノードがリーダーに接続されると、リーダーとデータ同期を開始し、自分の状態とリーダーの状態が一致することを確保します.クラスタにリーダーが存在しない場合、そのノードはクラスタ内の他のすべてのノードとともに1つのリーダーを選択し、選択されたリーダーはLEADING状態に入り、リーダーにならない選択ノードはFOLLOWING状態に入る必要がある.選挙プロセスは、ノードがLOOKING状態に入ると、クラスタ内の他のすべてのノードに通知メッセージを送信し、現在の投票オブジェクトのサーバID(sid)と投票オブジェクトが最後に実行したトランザクションのzxidを含む.ノードが投票通知を受信すると、次のルールに従って処理されます.
1つのノードがほとんどのノード(半分以上)の同じ投票を受け取ると、ノードはleader選挙の完了を宣言します.リーダーが彼自身であれば、リーダーロールを実行し始めます.そうしないとfollowerになり、リーダーに接続しようとします.リーダーに接続すると、ステータスとの同期が開始され、ステータスの同期が完了するとfollowerが新しいリクエストの処理を開始します.接続に失敗した場合、serverは使用できません.ZooKeeperの選挙過程は,クラスタの半分以上のノードが利用可能であればクラスタが正常に動作することを決定した.クラスタのリーダーがオフになった後、クラスタの残りの半分以上のノードが使用可能であれば、クラスタは新しいリーダーを選択して正常に動作し続けることができます.