今日のビジネスの現実では高可用性が最優先事項であるため、ユーザーが対処する最も一般的なシナリオの1つは、データベースをアプリケーションで常に利用できるようにする方法です。
すべてのサービスプロバイダーには、サービス中断のリスクが継承されているため、実行できる手順の1つは、リスクと追加の冗長性を軽減するために複数のプロバイダーに依存することです。
クラウドサービスプロバイダーも例外ではありません。失敗する可能性があるため、事前に計画する必要があります。 MariaDBクラスターにはどのようなオプションがありますか？このブログ投稿でそれを見てみましょう。
あるクラウドサービスプロバイダーによって提案されたSLAが十分でない場合は、そのプロバイダーの外部にディザスタリカバリサイトを作成するオプションが常にあります。このおかげで、クラウドプロバイダーのいずれかでサービスの低下が発生した場合は、いつでも別のプロバイダーに切り替えて、データベースを稼働状態に保つことができます。
マルチクラウドのセットアップで一般的な問題の1つは、より長い距離、または一般に地理的に離れた複数の場所について話している場合に避けられないネットワーク遅延です。光の速度は非常に高速ですが、それは有限であり、すべてのホップ、すべてのルーターもネットワークインフラストラクチャにある程度の遅延を追加します。
MariaDBクラスターは、低レイテンシーのネットワークでうまく機能します。これはクォーラムベースのクラスターであり、操作をスムーズに保つためにすべてのノード間の迅速な通信が必要です。ネットワーク遅延の増加は、クラスター操作、特に書き込みのパフォーマンスに影響を与えます。この問題に対処する方法はいくつかあります。
最初に、非同期レプリケーションリンクを使用して接続された個別のクラスターを使用するオプションがあります。これにより、非同期レプリケーションは待ち時間の長い環境での作業に非常に適しているため、待ち時間をほとんど忘れることができます。
別のオプションとして、データセンター間のレイテンシが低いネットワークを使用している場合でも、複数のデータセンターにまたがるMariaDBクラスターを実行しても問題はない可能性があります。結局のところ、複数のデータセンターは必ずしも地理的に長距離を意味するわけではありません。同じ大都市圏内にあり、高速で低遅延のネットワークに接続された複数のプロバイダーを使用することもできます。次に、レイテンシが最大で数十ミリ秒に増加することについて説明します。間違いなく数百ミリ秒ではありません。それはすべてアプリケーションによって異なりますが、そのような増加は許容できる場合があります。
これにはいくつかの制限があります。手始めに、マルチマスターを使用するか、すべてのトラフィックを1つのデータセンターのみに送信するかを決定する必要があります。両方のデータセンターへの書き込みとマスター-マスターレプリケーションの使用は避けておくことをお勧めします。注意を怠ると、深刻な問題が発生する可能性があります。
アクティブ-パッシブセットアップを使用する場合は、書き込み用に何らかのDNSベースのルーティングを実装して、アプリケーションサーバーが常に一連のアクティブなデータセンターにあるプロキシ。これは、フェイルオーバーが必要なときに変更される文字通りDNSエントリによって実現されるか、Consulなどのサービス検出ソリューションを介して実行できます。
非同期レプリケーションを使用して構築された環境の主な欠点は、データセンター間のネットワーク分割を処理する機能がないことです。これはレプリケーションから継承されます。レプリケーションとリンクする対象（単一ノード、MariaDBクラスター）に関係なく、レプリケーションがクォーラムに対応していないという事実を回避する方法はありません。ノードの状態を追跡し、トポロジ全体の概要を理解するメカニズムはありません。その結果、2つのデータセンター間のリンクがダウンすると、接続されておらず、両方ともトラフィックを受け入れる準備ができている2つの別個のMariaDBクラスターになります。そのような場合に何をするかを定義するのはユーザー次第です。外部から（つまり、3番目のデータセンターから）データベースの状態を監視し、その情報に基づいてアクションを実行する（またはアクションを実行しない）追加のツールを実装することができます。インフラストラクチャをデータベースと共有するが、クラスターを認識し、データセンターの接続状態を追跡し、環境を管理するスクリプトの信頼できる情報源として使用できるツールを併置することもできます。たとえば、ClusterControlは、RAFTプロトコルを使用してクォーラムを確保する3ノードクラスター（データセンターごとのノード）にデプロイできます。ノードがクラスターの他の部分との接続を失った場合、データセンターでネットワークのパーティション分割が発生したと見なされる可能性があります。
非同期レプリケーションの代わりに、複数のデータセンターにまたがるすべてのMariaDBクラスターソリューションを使用することもできます。
このブログの冒頭で述べたように、MariaDBクラスターはガレラベースのクラスターは、高いレイテンシーの影響を受けます。そうは言っても、「それほど高くない」レイテンシ環境で実行し、適切に動作して許容可能なパフォーマンスを提供することを期待することは完全に許容されます。それはすべて、ネットワークスループットと設計、データセンター間の距離、およびアプリケーション要件に依存します。このようなアプローチは、セグメントを使用して個別のデータセンターを区別する場合に特に効果的です。これにより、MariaDBクラスターはクラスター内接続を最適化し、DC間トラフィックを最小限に抑えることができます。
このセットアップの主な利点は、MariaDBクラスターに依存して障害を処理することです。 3つのデータセンターを使用する場合、スプリットブレインの状況からほぼカバーされます。過半数が存在する限り、データセンターは引き続き動作します。 3番目のデータセンターに本格的なノードがある必要はありません。クラスターの一部として機能するデーモンであるGaleraArbitratorを使用することもできますが、データベース操作を処理する必要はありません。ノードに接続し、クォーラム計算に参加し、2つのデータセンター間の直接接続が機能しない場合にトラフィックを中継するために使用できます。
この場合、フェイルオーバープロセス全体は次のように説明できます。ロードバランサー内のすべてのノードを定義します（データセンターが互いに近接している場合はすべて、それ以外の場合は、ロードバランサーの近くにあるノード）そしてそれはほとんどそれです。大多数を形成するMariaDBクラスターノードは、任意のプロキシを介して到達可能になります。
ClusterControlを使用したマルチクラウドMariaDBクラスターのデプロイ
ClusterControlを使用してマルチクラウドMariaDBクラスターをデプロイするために使用できる2つのオプションを見てみましょう。 ClusterControlは、管理するすべてのノードへのSSH接続を必要とするため、複数のデータセンターまたはクラウドプロバイダー間のネットワーク接続を確保するのはユーザーの責任であることに注意してください。接続が確立されている限り、2つの方法で進めることができます。
ClusterControlは、非同期レプリケーションを使用して接続された2つのクラスターをデプロイするのに役立ちます。単一のMariaDBクラスターをデプロイする場合、ノードの1つでバイナリログが有効になっていることを確認する必要があります。これにより、そのノードを、まもなく作成する2番目のクラスターのマスターとして使用できるようになります。
バイナリログが有効になったら、スレーブクラスターの作成ジョブを使用できます展開ウィザードを開始します。
マスターから直接データをストリーミングするか、使用することができますデータをプロビジョニングするためのバックアップの数。
次に、合格する必要のある標準のクラスター展開ウィザードが表示されます。 SSH接続の詳細。
データベースのベンダーとバージョンも選択するように求められますrootユーザーのパスワードの入力を求められます。
最後に、追加するノードを定義するように求められます。クラスターとあなたはすべて設定されています。
デプロイすると、クラスターのリストに表示されます。 ClusterControlUI。
前述したように、MariaDBクラスターをデプロイする別のオプションは、クラスターにノードを追加するときに個別のセグメントを使用することです。 ClusterControl UIには、「ノードの追加」オプションがあります。
使用すると、次の画面が表示されます。
デフォルトのセグメントは0なので、別の値に変更します。
ノードが追加されたら、[概要]タブを見て、ノードがどのセグメントにあるかを確認できます。
この短いブログで、マルチクラウドMariaDBクラスターのデプロイに使用できるオプションと、それらを使用してデータベースインフラストラクチャの高可用性を確保する方法について理解を深めていただければ幸いです。