Zookeeperクラスタはなぜ高可用性ですか?
5847 ワード
私たちは通常zookeeperクラスタを導入して高可用性を実現しますが、zookeeperはどのように高可用性を実現しますか?
クラスタ構成
高可用性のZooKeeperクラスタを構築するには、まずクラスタの規模を決定する必要があります.ZooKeeperクラスタのサーバ構成については、ZooKeeperについてよく知っているが理解が足りない読者の多くが、ZooKeeperクラスタがLeaderをスムーズに選出できるように、ZooKeeperクラスタのサービス数を奇数に配置しなければならないという誤った認識を持っているか、かつて存在したことがある.ここで明らかにする必要があるのは、任意のZooKeeperサーバが導入され、正常に稼働していることです.
実はZooKeeperクラスタサーバ数について、ZooKeeper公式は確かに奇数に関する提案をしたが、ほとんどのZooKeeperユーザーはこの提案に対する認識にずれがある.本書で前述した「過剰生存即利用」特性では、ZooKeeperクラスタが外部に利用可能なサービスを提供する場合、クラスタ内に過剰なマシンが正常に動作し、互いに正常に通信できる必要があることを理解した.この特性に基づいて,N台のマシンのダウンを許容できるクラスタを構築するには,2*N+1台のサーバからなるZooKeeperクラスタを配備する.従って、3台の機器からなるZooKeeperクラスタは、1台の機器を切り離した後も正常に動作することができ、5台のサーバからなるZooKeeperクラスタに対しては、2台の機器を切り離した場合に災害対応を行うことができる.注意、6台のサーバからなるZooKeeperクラスタであれば、同じように2台のマシンを取り外すことができます.3台を切ると、残りのマシンは半分以上実現できないからです.
従って、上記の説明から、6台の機器からなるZooKeeperクラスタと、5台の機器からなるZooKeeperクラスタは、災害対応能力において顕著な優位性がなく、逆に1つのサーバリソースを多く占有していることが明らかになった.このため、ZooKeeperクラスタは通常、奇数台のサーバに配置されるように設計されている.
災害をしのぐ
災害対応とは、IT業界では、火災、地震、停電、その他のインフラストラクチャの障害などの壊滅的な災害に見舞われた場合でも、外部に利用可能なサービスを提供できる能力を有するコンピュータ情報システムを指すことが多い.
いくつかの一般的なアプリケーションでは、災害対応基準を達成するために、通常、クラスタを構成するために複数のマシンに配備することを選択します.これにより、クラスタの1台または複数のマシンに障害が発生しても、クラスタ全体が外部に利用可能なサービスを提供することができます.
いくつかのコアアプリケーションでは、複数のマシンを使用してクラスタを構築することによってサービスを提供するだけでなく、クラスタ内のマシンを2つのマシンルームに配置することで、そのうちの1つが災害に遭遇しても、外部に利用可能なサービスを提供することができます.
上述したのはすべて応用レベルの災害対応モデルであるが,ZooKeeperのような下位コンポーネントにとってどのように災害対応を行うのか.ここまで言うと、ZooKeeperが単一の問題を解決した以上、なぜ災害対応をしなければならないのかと疑問に思う読者は多いかもしれません.
たんてんもんだい
単一の問題は、分散環境で最も一般的で古典的な問題の一つであり、多くの分散システムでは、このような単一の問題が存在します.具体的には、単一点問題とは、あるコンポーネントに障害が発生すると、システム全体の可用性が大幅に低下し、麻痺状態になる分散システムにおいて、コンポーネントに単一点の問題があると考えられることを意味する.
ZooKeeperは確かに単点問題をうまく解決した.ZooKeeperが実行中にクラスタ内の少なくとも半分のマシンが最新のデータを保存していることを,「過半数」設計の原則に基づいて理解した.したがって,クラスタの半数以上のマシンが正常に動作すれば,クラスタ全体が対外的にサービスを提供できる.
災害をしのぐ
ちょっとした問題を解決したので、災害対策を考えるべきではないでしょうか.答えは肯定的であり,高利用可能なクラスタを構築する際には依然として災害対応問題を考慮する必要がある.前述したように,クラスタの半数以上のマシンが正常に動作している場合,クラスタは外部に正常なサービスを提供することができる.では、機械室全体に災害的な事故が発生した場合、この時は明らかに単点問題の範疇ではない.
ZooKeeperの災害対策の設計を行う過程で、私たちは「過剰原則」を十分に考慮しなければならない.つまり,どんなことがあってもZooKeeperクラスタの半数以上のマシンが正常に動作することを保証しなければならない.したがって、通常、次の2つの導入シナリオがあります.
デュアルルームの配置
災害対策の設計を行う際、私たちは通常、機械室単位で問題を考えています.現実的には、多くの会社の機械室の規模は大きくないため、ダブル機械室の配置は比較的一般的な案である.しかし、残念なことに、現在のバージョンのZooKeeperでは、どの機械室に異常が発生しても、ZooKeeperクラスタで利用可能な機器の半数を超えられない可能性があるため、デュアル機械室の条件下で比較的良い災害対応効果を実現することはできません.もちろん、2つの機械室を持っているシーンでは、通常、1つの機械室が主要機械室である(一般的には、会社は安定性が高く、設備がより信頼できる機械室を借りるのにもっとお金がかかります.この機械室は主要機械室であり、もう1つの機械室はもっと安いです).私たちが唯一できることは、できるだけ主要な機械室にもっと多くの機械を配置することです.例えば、7台の機器からなるZooKeeperクラスタについては、通常、主要機室に4台の機器を配置し、残りの3台の機器を別の機室に配置する.
三機械室の配置
ダブルルームの配置モデルでは良い災害対応効果が実現できない以上、条件のある会社では、3つのルームの配置を選ぶのは間違いなくより良い選択であり、どのルームが故障しても、残りの2つのルームの機械数は半数を超えている.3つのルームがサービスを導入でき、この3つのルームのネットワーク状況が良好であれば、3つのルームにいくつかのマシンを配置してZooKeeperクラスタを構成することができます.
ZooKeeperクラスタを構成するマシンの総数をNとし,3つのマシンルームに配置されたZooKeeperサーバ数をそれぞれN 1,N 2,N 3とし,このZooKeeperクラスタをより良好な災害対応能力を持たせるためには,以下のアルゴリズムに基づいてZooKeeperクラスタのマシン部署スキームを計算することができる.
1)N 1の計算
ZooKeeperクラスタのサーバ総数がNの場合:
N 1=(N-1)/2 Javaでは、"/"演算子が計算結果を自動的に下方向に整列します.例を挙げると、N=8であれば、N 1=3である.N=7の場合、N 1も3に等しい.
2.)N 2のオプション値の算出
N 2の計算規則はN 1と非常に類似しているが、N 2の値は1つの値範囲内である.
N 2の取値範囲が1~(N−N 1)/2である、すなわち、N=8であれば、N 1=3であれば、N 2の取値範囲は1~2であり、それぞれ1と2である.なお、1と2はN 2のオプション値のみであり、最終値ではない.N 2があるオプション値である場合、N 3の値を算出できない場合、そのオプション値も無効である.
3.)N 3を計算しながらN 2の値を決定する
明らかに、現在はN 3しか残っていないので、簡単にN 3の値が残りの機械数であると考えることができます.
N 3=N−N 1−N 2は、N 3の値のみがN 37台の機械を例に、3つの機械室の機械分布をどのように分配するかを見てみましょう.アルゴリズムのステップ1に従って,まずN 1の値を3とする.アルゴリズムのステップ2に従って,N 2のオプション値を1と2と決定した.最後に、ステップ3に従って、N 2のオプション値を巡回すると、(3,1,3)と(3,2,2)の2つの配置スキームが得られる.以下はJavaプログラムコードの上記のアルゴリズムに対する簡単な実装です.
すいへいかくさん
水平拡張性は、分散型システムが高可用性の面で提案した基本的なものであり、非常に重要な要求でもあり、水平拡張によって、システムが行わないか、またはわずかな改善作業を行うことを前提に、システムの対外的なサービスサポート能力を迅速に向上させることができる.簡単に言えば、水平拡張は、システムのサービス品質を向上させるためにクラスタにより多くのマシンを追加することである.
残念なことに,ZooKeeperは水平拡張拡張において十分に完璧ではなく,クラスタ全体の再起動が必要である.通常、クラスタ全体の再起動と、サーバの再起動を1台ずつ行う2つの再起動方式があります.
(1)全体再起動
クラスタ全体の再起動とは,まずクラスタ全体を停止し,その後ZooKeeperの構成を更新してから再起動することである.あなたのシステムでZooKeeperが非常にコアなコンポーネントではなく、短いサービス停止(通常は数秒の間隔)を許可できる場合は、この方法を選択してください.全体的な再起動中に、クラスタのクライアントはすべてクラスタに接続できません.クラスタが再起動されると、これらのクライアントは自動的に接続できます.全体的に起動する前に確立されたクライアントセッションは、今回の全体的な再起動で失効することはありません.つまり、全体的な再起動期間にかかる時間は、セッションタイムアウト時間の計算には計上されません.
(2)1台ずつ再起動
この方法はほとんどの実際のシーンに適しています.この方式では、クラスタ内の1台のマシンのみを再起動し、クラスタ内のマシン全体を1台ずつ再起動操作する.この方法は、再起動中にクラスタの対外的な正常なサービスを保証することができる.
クラスタ構成
高可用性のZooKeeperクラスタを構築するには、まずクラスタの規模を決定する必要があります.ZooKeeperクラスタのサーバ構成については、ZooKeeperについてよく知っているが理解が足りない読者の多くが、ZooKeeperクラスタがLeaderをスムーズに選出できるように、ZooKeeperクラスタのサービス数を奇数に配置しなければならないという誤った認識を持っているか、かつて存在したことがある.ここで明らかにする必要があるのは、任意のZooKeeperサーバが導入され、正常に稼働していることです.
実はZooKeeperクラスタサーバ数について、ZooKeeper公式は確かに奇数に関する提案をしたが、ほとんどのZooKeeperユーザーはこの提案に対する認識にずれがある.本書で前述した「過剰生存即利用」特性では、ZooKeeperクラスタが外部に利用可能なサービスを提供する場合、クラスタ内に過剰なマシンが正常に動作し、互いに正常に通信できる必要があることを理解した.この特性に基づいて,N台のマシンのダウンを許容できるクラスタを構築するには,2*N+1台のサーバからなるZooKeeperクラスタを配備する.従って、3台の機器からなるZooKeeperクラスタは、1台の機器を切り離した後も正常に動作することができ、5台のサーバからなるZooKeeperクラスタに対しては、2台の機器を切り離した場合に災害対応を行うことができる.注意、6台のサーバからなるZooKeeperクラスタであれば、同じように2台のマシンを取り外すことができます.3台を切ると、残りのマシンは半分以上実現できないからです.
従って、上記の説明から、6台の機器からなるZooKeeperクラスタと、5台の機器からなるZooKeeperクラスタは、災害対応能力において顕著な優位性がなく、逆に1つのサーバリソースを多く占有していることが明らかになった.このため、ZooKeeperクラスタは通常、奇数台のサーバに配置されるように設計されている.
災害をしのぐ
災害対応とは、IT業界では、火災、地震、停電、その他のインフラストラクチャの障害などの壊滅的な災害に見舞われた場合でも、外部に利用可能なサービスを提供できる能力を有するコンピュータ情報システムを指すことが多い.
いくつかの一般的なアプリケーションでは、災害対応基準を達成するために、通常、クラスタを構成するために複数のマシンに配備することを選択します.これにより、クラスタの1台または複数のマシンに障害が発生しても、クラスタ全体が外部に利用可能なサービスを提供することができます.
いくつかのコアアプリケーションでは、複数のマシンを使用してクラスタを構築することによってサービスを提供するだけでなく、クラスタ内のマシンを2つのマシンルームに配置することで、そのうちの1つが災害に遭遇しても、外部に利用可能なサービスを提供することができます.
上述したのはすべて応用レベルの災害対応モデルであるが,ZooKeeperのような下位コンポーネントにとってどのように災害対応を行うのか.ここまで言うと、ZooKeeperが単一の問題を解決した以上、なぜ災害対応をしなければならないのかと疑問に思う読者は多いかもしれません.
たんてんもんだい
単一の問題は、分散環境で最も一般的で古典的な問題の一つであり、多くの分散システムでは、このような単一の問題が存在します.具体的には、単一点問題とは、あるコンポーネントに障害が発生すると、システム全体の可用性が大幅に低下し、麻痺状態になる分散システムにおいて、コンポーネントに単一点の問題があると考えられることを意味する.
ZooKeeperは確かに単点問題をうまく解決した.ZooKeeperが実行中にクラスタ内の少なくとも半分のマシンが最新のデータを保存していることを,「過半数」設計の原則に基づいて理解した.したがって,クラスタの半数以上のマシンが正常に動作すれば,クラスタ全体が対外的にサービスを提供できる.
災害をしのぐ
ちょっとした問題を解決したので、災害対策を考えるべきではないでしょうか.答えは肯定的であり,高利用可能なクラスタを構築する際には依然として災害対応問題を考慮する必要がある.前述したように,クラスタの半数以上のマシンが正常に動作している場合,クラスタは外部に正常なサービスを提供することができる.では、機械室全体に災害的な事故が発生した場合、この時は明らかに単点問題の範疇ではない.
ZooKeeperの災害対策の設計を行う過程で、私たちは「過剰原則」を十分に考慮しなければならない.つまり,どんなことがあってもZooKeeperクラスタの半数以上のマシンが正常に動作することを保証しなければならない.したがって、通常、次の2つの導入シナリオがあります.
デュアルルームの配置
災害対策の設計を行う際、私たちは通常、機械室単位で問題を考えています.現実的には、多くの会社の機械室の規模は大きくないため、ダブル機械室の配置は比較的一般的な案である.しかし、残念なことに、現在のバージョンのZooKeeperでは、どの機械室に異常が発生しても、ZooKeeperクラスタで利用可能な機器の半数を超えられない可能性があるため、デュアル機械室の条件下で比較的良い災害対応効果を実現することはできません.もちろん、2つの機械室を持っているシーンでは、通常、1つの機械室が主要機械室である(一般的には、会社は安定性が高く、設備がより信頼できる機械室を借りるのにもっとお金がかかります.この機械室は主要機械室であり、もう1つの機械室はもっと安いです).私たちが唯一できることは、できるだけ主要な機械室にもっと多くの機械を配置することです.例えば、7台の機器からなるZooKeeperクラスタについては、通常、主要機室に4台の機器を配置し、残りの3台の機器を別の機室に配置する.
三機械室の配置
ダブルルームの配置モデルでは良い災害対応効果が実現できない以上、条件のある会社では、3つのルームの配置を選ぶのは間違いなくより良い選択であり、どのルームが故障しても、残りの2つのルームの機械数は半数を超えている.3つのルームがサービスを導入でき、この3つのルームのネットワーク状況が良好であれば、3つのルームにいくつかのマシンを配置してZooKeeperクラスタを構成することができます.
ZooKeeperクラスタを構成するマシンの総数をNとし,3つのマシンルームに配置されたZooKeeperサーバ数をそれぞれN 1,N 2,N 3とし,このZooKeeperクラスタをより良好な災害対応能力を持たせるためには,以下のアルゴリズムに基づいてZooKeeperクラスタのマシン部署スキームを計算することができる.
1)N 1の計算
ZooKeeperクラスタのサーバ総数がNの場合:
N 1=(N-1)/2 Javaでは、"/"演算子が計算結果を自動的に下方向に整列します.例を挙げると、N=8であれば、N 1=3である.N=7の場合、N 1も3に等しい.
2.)N 2のオプション値の算出
N 2の計算規則はN 1と非常に類似しているが、N 2の値は1つの値範囲内である.
N 2の取値範囲が1~(N−N 1)/2である、すなわち、N=8であれば、N 1=3であれば、N 2の取値範囲は1~2であり、それぞれ1と2である.なお、1と2はN 2のオプション値のみであり、最終値ではない.N 2があるオプション値である場合、N 3の値を算出できない場合、そのオプション値も無効である.
3.)N 3を計算しながらN 2の値を決定する
明らかに、現在はN 3しか残っていないので、簡単にN 3の値が残りの機械数であると考えることができます.
N 3=N−N 1−N 2は、N 3の値のみがN 3
public class Allocation {
static final int n = 7;
public static void main(String[] args){
int n1,n2,n3;
n1 = (n-1) / 2;
int n2_max = (n-n1) / 2;
for(int i=1; i<=n2_max; i++){
n2 = i;
n3 = n - n1 -n2;
if(n3 >= (n1+n2)){
continue;
}
System.out.println("("+n1+","+n2+","+n3+")");
}
}
}すいへいかくさん
水平拡張性は、分散型システムが高可用性の面で提案した基本的なものであり、非常に重要な要求でもあり、水平拡張によって、システムが行わないか、またはわずかな改善作業を行うことを前提に、システムの対外的なサービスサポート能力を迅速に向上させることができる.簡単に言えば、水平拡張は、システムのサービス品質を向上させるためにクラスタにより多くのマシンを追加することである.
残念なことに,ZooKeeperは水平拡張拡張において十分に完璧ではなく,クラスタ全体の再起動が必要である.通常、クラスタ全体の再起動と、サーバの再起動を1台ずつ行う2つの再起動方式があります.
(1)全体再起動
クラスタ全体の再起動とは,まずクラスタ全体を停止し,その後ZooKeeperの構成を更新してから再起動することである.あなたのシステムでZooKeeperが非常にコアなコンポーネントではなく、短いサービス停止(通常は数秒の間隔)を許可できる場合は、この方法を選択してください.全体的な再起動中に、クラスタのクライアントはすべてクラスタに接続できません.クラスタが再起動されると、これらのクライアントは自動的に接続できます.全体的に起動する前に確立されたクライアントセッションは、今回の全体的な再起動で失効することはありません.つまり、全体的な再起動期間にかかる時間は、セッションタイムアウト時間の計算には計上されません.
(2)1台ずつ再起動
この方法はほとんどの実際のシーンに適しています.この方式では、クラスタ内の1台のマシンのみを再起動し、クラスタ内のマシン全体を1台ずつ再起動操作する.この方法は、再起動中にクラスタの対外的な正常なサービスを保証することができる.