シリーズの前回のブログでは、GaleraClusterを使用して地理分散クラスターを作成することの長所と短所について説明しました。この投稿では、Galeraベースの地理分散クラスターを設計し、ClusterControlを使用して必要なすべての要素を展開する方法を示します。
まず、構築する環境について説明します。ワイドエリアネットワーク（WAN）を介して接続された3つのリモートデータセンターを使用します。各データセンターは、ローカルアプリケーションサーバーから書き込みを受信します。読み取りもローカルのみになります。これは、WANを通過する不要なトラフィックを回避することを目的としています。
この設定では、接続が確立され、保護されていますが、これを実現する方法については詳しく説明しません。独自のハードウェアおよびソフトウェアソリューションからOpenVPNを介して始まり、SSHトンネルで終わる接続を保護する方法は多数あります。
別の可能な解決策は、ProxySQLをアプリケーションノードと併置し、ローカルホスト上のプロキシに接続するようにアプリケーションを構成することです。このアプローチは、ProxySQLが使用できない可能性は低いが、アプリケーションが同じノードで正常に動作するという前提の下で非常にうまく機能します。通常、私たちが目にするのはノード障害またはネットワーク障害のいずれかであり、ProxySQLとアプリケーションの両方に同時に影響を及ぼします。
上の図は、ProxySQLが併置されている環境のバージョンを示しています。アプリケーションと同じノード。 ProxySQLは、ローカルデータセンター内のすべてのGaleraノードにワークロードを分散するように構成されています。これらのノードの1つは、書き込みを送信するノードとして選択され、SELECTはすべてのノードに分散されます。データセンターに専用のライターノードを1つ持つことで、認証の競合の可能性を減らすことができ、通常、パフォーマンスが向上します。これをさらに減らすには、WAN接続を介してトラフィックを送信し始める必要がありますが、帯域幅の使用率が大幅に増加するため、これは理想的ではありません。現在、セグメントが配置されているため、データセンター間で送信されるライトセットのコピーは2つだけです（DCごとに1つ）。
Galera Clusterの地理分散型デプロイメントの主な懸念事項は、レイテンシーです。これは、環境を起動する前に常にテストする必要があるものです。コミット時間は大丈夫ですか？すべてのコミット認証を行う必要があるため、リモートノードを含むクラスター内のすべてのノードで書き込みセットを送信して認証する必要があります。待ち時間が長いと、セットアップがアプリケーションに不適切であると見なされる可能性があります。その場合、非同期レプリケーションを介して接続された複数のGaleraクラスターがより適切であることがわかります。ただし、これは別のブログ投稿のトピックになります。
ClusterControlを使用した地理分散型ガレラクラスターの展開
明確にするために、ここではデプロイメントがどのように見えるかを示します。実際のマルチDCセットアップは使用せず、すべてがローカルラボにデプロイされます。レイテンシーは許容範囲内であり、セットアップ全体が実行可能であると想定しています。 ClusterControlの優れている点は、インフラストラクチャに依存しないことです。ノードが互いに近接しているか、同じデータセンターにあるか、ノードが複数のクラウドプロバイダーに分散しているかは関係ありません。 ClusterControlインスタンスからすべてのノードへのSSH接続がある限り、展開プロセスはまったく同じように見えます。そのため、ローカルラボだけを使用して段階的に表示できます。
ClusterControlのインストール
まず、ClusterControlをインストールする必要があります。無料でダウンロードできます。登録後、ClusterControlをダウンロードしてインストールするためのガイド付きのページにアクセスする必要があります。シェルスクリプトを実行するのと同じくらい簡単です。 ClusterControlをインストールすると、管理ユーザーを作成するためのフォームが表示されます。
入力すると、ようこそ画面が表示され、アクセスできるようになります。展開ウィザードへ：
デプロイを行います。これにより、展開ウィザードが開きます：
MySQLGaleraを選択します。 SSH接続の詳細を渡す必要があります-rootユーザーまたはsudoユーザーのいずれかがサポートされています。次のステップでは、クラスター内のサーバーを定義します。
データセンターの1つに3つのノードをデプロイします。次に、クラスターを拡張して、さまざまなセグメントに新しいノードを構成できるようになります。今のところ、「デプロイ」をクリックして、ClusterControlがGaleraクラスターをデプロイするのを見るだけです。
最初の3つのノードが稼働しているので、追加に進むことができます他のデータセンターの追加ノード。
上のスクリーンショットに示すように、アクションメニューからこれを行うことができます。
ここで、ノードを1つずつ追加できます。重要なのは、Galeraセグメントをゼロ以外に変更する必要があることです（最初の3つのノードには0が使用されます）。
しばらくすると、3つのセグメントに分散された9つのノードすべてになります。
次に、プロキシレイヤーをデプロイする必要があります。そのためにProxySQLを使用します。 [管理]->[ロードバランサー]を使用してClusterControlにデプロイできます：
これにより、展開フィールドが開きます：
まず、ProxySQLを展開する場所を決定する必要があります。既存のGaleraノードを使用しますが、フィールドには何でも入力できるため、アプリケーションノードの上にProxySQLをデプロイすることは完全に可能です。さらに、管理および監視ユーザーのアクセス資格情報を渡す必要があります。
次に、MySQLの既存のユーザーの1人を選択するか、作成する必要がありますたった今。また、ProxySQLが同じデータセンターにのみ配置されているGaleraノードを使用するように構成されていることを確認する必要があります。
データセンターに1つのProxySQLが用意されている場合は、それを構成のソースとして使用できます。
これは、すべてのデータセンターにあるすべてのアプリケーションサーバーに対して繰り返す必要があります。 。次に、アプリケーションは、理想的にはUnixソケットを介してローカルProxySQLインスタンスに接続するように構成する必要があります。これにより、最高のパフォーマンスと最小のレイテンシが実現します。
最後のProxySQLがデプロイされたら、環境の準備が整います。アプリケーションノードはローカルProxySQLに接続します。各ProxySQLは、同じデータセンター内のGaleraノードと連携するように構成されています。
この2部構成のシリーズが、地理的に分散したガレラクラスターの長所と短所、およびClusterControlによってそのようなクラスターの展開と管理が非常に簡単になる方法を理解するのに役立つことを願っています。