データベースクラスターの展開はロケット科学ではありません。その方法については多くのハウツーがあります。しかし、デプロイしたばかりのものが本番環境に対応していることをどのようにして知ることができますか？手動による展開も、面倒で反復的な場合があります。クラスタ内のノードの数によっては、展開手順に時間がかかり、エラーが発生しやすい場合があります。 Puppet、Chef、Ansibleなどの構成管理ツールはインフラストラクチャのデプロイで一般的ですが、ステートフルデータベースクラスターの場合、データベースHAスタック全体のデプロイを処理するために重要なスクリプトを実行する必要があります。さらに、選択したテンプレート/モジュール/クックブック/ロールは、インフラストラクチャの自動化の一部として信頼できるようになる前に、入念にテストする必要があります。バージョンを変更するには、スクリプトを更新して再度テストする必要があります。
良いニュースは、ClusterControlがスタック全体の展開を自動化することです-そして無料でも！何千もの本番クラスターをデプロイし、本番環境に対応できるようにさまざまな予防策を講じています。マスタースレーブレプリケーションからGalera、NDB、InnoDBクラスターまで、さまざまなデータベースプロキシを搭載したさまざまなトポロジがサポートされています。
>ClusterControlを介してデプロイされる高可用性スタックは、次の3つのレイヤーで構成されます。
- データベースレイヤー（Galera Clusterなど）
- リバースプロキシレイヤー（HAProxyやProxySQLなど）
- Keepalivedレイヤー。仮想IPを使用して、プロキシレイヤーの高可用性を保証します
このブログでは、高可用性セットアップのためのロードバランサーを備えた本番環境グレードのGaleraクラスターをデプロイする方法を紹介します。完全なセットアップは6つのホストで構成されています：
- 1ホスト-ClusterControl（デプロイメント、監視、管理サーバー）
- 3つのホスト-MySQLGaleraCluster
- 2つのホスト-リバースプロキシはクラスターの前でロードバランサーとして機能します。
次の図は、展開が完了した後の最終結果を示しています。
前提条件
ClusterControlは、クラスターの一部ではない独立したノードに存在する必要があります。 ClusterControlをダウンロードすると、ページに固有のライセンスが生成され、ClusterControlをインストールする手順が表示されます。
$ wget -O install-cc https://severalnines.com/scripts/install-cc
$ chmod +x install-cc
$ ./install-cc # as root or sudo userMySQLサーバー、ClusterControlノードのMySQLルートパスワード、ClusterControl使用法のcmonパスワードなどの設定について説明する手順に従ってください。インストールが完了すると、次の行が表示されます。
Determining network interfaces. This may take a couple of minutes. Do NOT press any key.
Public/external IP => http://{public_IP}/clustercontrol
Installation successful. If you want to uninstall ClusterControl then run install-cc --uninstall.次に、ClusterControlサーバーで、後でパスワードなしのSSHをセットアップするために使用するSSHキーを生成します。システム内の任意のユーザーを使用できますが、スーパーユーザー操作（sudoer）を実行する機能が必要です。この例では、rootユーザーを選択しました：
$ whoami
root
$ ssh-keygen -t rsaClusterControlを介して監視/管理するすべてのノードにパスワードなしのSSHを設定します。この場合、これをスタック内のすべてのノード（ClusterControlノード自体を含む）に設定します。 ClusterControlノードで、次のコマンドを実行し、プロンプトが表示されたらルートパスワードを指定します。
$ ssh-copy-id [email protected] # clustercontrol
$ ssh-copy-id [email protected] # galera1
$ ssh-copy-id [email protected] # galera2
$ ssh-copy-id [email protected] # galera3
$ ssh-copy-id [email protected] # proxy1
$ ssh-copy-id [email protected] # proxy2次に、ClusterControlノードで次のコマンドを実行して、機能しているかどうかを確認できます。
$ ssh [email protected] "ls /root"パスワードを入力しなくても、上記のコマンドの結果を確認できることを確認してください。
クラスターの展開
ClusterControlは、Galera Clusterのすべてのベンダー（Codership、Percona、MariaDB）をサポートしています。ベンダーを選択する際の決定に影響を与える可能性のあるいくつかの小さな違いがあります。それらの違いについて知りたい場合は、以前のブログ投稿-Galera Cluster Comparison-Codership vs PerconavsMariaDBをチェックしてください。
実稼働環境では、3ノードのGaleraクラスターが最低限必要です。クラスターがデプロイされたら、手動またはClusterControlを介して、いつでもスケールアウトできます。 ClusterControl UI（https://192.168.55.160/clustercontrol）を開き、最初の管理者ユーザーを作成します。次に、トップメニューに移動し、[展開->MySQLガレラ]をクリックします。 次のダイアログが表示されます：
2つのステップがあります。最初のステップは「一般およびSSH設定」です。ここでは、ClusterControlがデータベースノードに接続するために使用するSSHユーザーを、SSHキーへのパス（前提条件セクションで生成）およびデータベースノードのSSHポートとともに構成する必要があります。 ClusterControlは、すべてのデータベースノードが同じSSHユーザー、キー、およびポートで構成されていることを前提としています。次に、クラスターに名前を付けます。この場合は、「MySQLGaleraCluster5.7」を使用します。この値は後で変更できます。次に、必要なソフトウェアをインストールし、ファイアウォールを無効にし、特定のLinuxディストリビューションのセキュリティ拡張モジュールを無効にするようにClusterControlに指示するオプションを選択します。展開を成功させる可能性を最大化するために、これらすべてをオンに切り替えることをお勧めします。
[続行]をクリックすると、次のダイアログが表示されます：
次のステップでは、データベースサーバー（ベンダー、バージョン、datadir、ポートなど）を構成する必要があります。これらは非常にわかりやすいものです。 「構成テンプレート」は、ClusterControlノードの/ usr / share / cmon/templatesの下にあるテンプレートファイル名です。 「リポジトリ」は、ClusterControlがデータベースノードでリポジトリを構成する方法です。デフォルトでは、ベンダーリポジトリを使用し、リポジトリによって提供される最新バージョンをインストールします。ただし、セキュリティポリシーの制限により、ユーザーが元のリポジトリからミラーリングされた既存のリポジトリを持っている場合があります。それでも、ユーザーガイドの[リポジトリ]で説明されているように、ClusterControlはそれらのほとんどをサポートしています。
最後に、データベースノードのIPアドレスまたはホスト名（有効なFQDNである必要があります）を追加します。ノードの左側に緑色のチェックマークアイコンが表示されます。これは、ClusterControlがパスワードなしのSSHを介してノードに接続できたことを示します。これで準備完了です。 [デプロイ]をクリックしてデプロイを開始します。これが完了するまでに15〜20分かかる場合があります。 [アクティビティ]（トップメニュー）->[ジョブ]->[クラスターの作成]で、展開の進行状況を監視できます。 ：
展開が完了すると、この時点で、アーキテクチャを次のように示すことができます。
ロードバランサーの導入
Galera Clusterでは、すべてのノードが等しく、各ノードは同じ役割と同じデータセットを保持します。したがって、ノードに障害が発生した場合、クラスター内にフェイルオーバーはありません。クラスタが分割されている間、動作していないノードをスキップするために、アプリケーション側のみがフェイルオーバーを必要とします。したがって、ロードバランサーをGaleraクラスターの上に配置して次のことを行うことを強くお勧めします。
- 複数のデータベースエンドポイントを単一のエンドポイントに統合します（エンドポイントとしてロードバランサーホストまたは仮想IPアドレス）。
- バックエンドデータベースサーバー間のデータベース接続のバランスを取ります。
- ヘルスチェックを実行し、データベース接続のみを正常なノードに転送します。
- データベースサーバーに到達する前に、問題のある（不適切に記述された）クエリをリダイレクト/書き換え/ブロックします。
Galera Clusterのリバースプロキシには、HAProxy、MariaDB MaxScale、ProxySQLの3つの主な選択肢があります。これらはすべて、ClusterControlによって自動的にインストールおよび構成できます。この展開では、上記のすべてをチェックし、バックエンドサーバーのMySQLプロトコルを理解するため、ProxySQLを選択しました。
このアーキテクチャでは、2つのProxySQLサーバーを使用して、データベース層への単一障害点（SPOF）を排除します。これは、フローティング仮想IPアドレスを使用して結合されます。これについては次のセクションで説明します。 1つのノードはアクティブプロキシとして機能し、もう1つのノードはホットスタンバイとして機能します。特定の時間に仮想IPアドレスを保持しているノードがアクティブノードです。
最初のProxySQLサーバーをデプロイするには、クラスターアクションメニュー（概要バーの右側）に移動し、ロードバランサーの追加->ProxySQL->ProxySQLのデプロイをクリックします。 次のように表示されます：
繰り返しますが、ほとんどのフィールドは自明です。 「データベースユーザー」セクションでは、ProxySQLは、アプリケーションがデータベースに接続するためのゲートウェイとして機能します。アプリケーションはProxySQLに対して認証を行うため、すべてのバックエンドMySQLノードのすべてのユーザーをパスワードとともにProxySQLに追加する必要があります。 ClusterControlから、アプリケーションで使用する新しいユーザーを作成できます。名前、パスワード、付与するデータベースへのアクセス、およびそのユーザーが持つMySQL特権を決定できます。このようなユーザーは、MySQL側とProxySQL側の両方で作成されます。 2番目のオプションは、既存のインフラストラクチャにより適していますが、既存のデータベースユーザーを使用することです。ユーザー名とパスワードを渡す必要があります。そのようなユーザーはProxySQLでのみ作成されます。
最後のセクション「暗黙のトランザクション」では、SET autocommit =0でトランザクションを開始した場合、ClusterControlはすべてのトラフィックをマスターに送信するようにProxySQLを構成します。それ以外の場合、BEGINまたはSTART TRANSACTIONを使用してトランザクションを作成すると、ClusterControlはクエリルールで読み取り/書き込み分割を構成します。これは、ProxySQLがトランザクションを正しく処理することを保証するためです。アプリケーションがこれをどのように行うかわからない場合は、後者を選択できます。
「サーバーアドレス」の値が192.168.55.182であることを除いて、2番目のProxySQLノードに対して同じ構成を繰り返します。完了すると、両方のノードが[ノード]タブ-> ProxySQLの下に一覧表示され、UIから直接監視および管理できます。
この時点で、アーキテクチャは次のようになっています。
ProxySQLの詳細については、このチュートリアル-MySQLおよびMariaDBとProxySQLのデータベース負荷分散-チュートリアルをご覧ください。
仮想IPアドレスの導入
最後の部分は仮想IPアドレスです。これがないと、アプリケーションに障害のあるデータベース接続を別のロードバランサーに自動的にリダイレクトする機能がない限り、ロードバランサー（リバースプロキシ）は単一障害点になるため、弱いリンクになります。それでも、仮想IPアドレスを使用してそれらを統合し、データベース層への接続エンドポイントを簡素化することをお勧めします。
ClusterControl UI-> Add Load Balancer-> Keepalived-> Deploy Keepalivedから デプロイした2つのProxySQLホストを選択します。
また、仮想IPアドレスとIPアドレスをバインドするネットワークインターフェイスを指定します。ネットワークインターフェイスは、両方のProxySQLノードに存在する必要があります。デプロイすると、クラスターのサマリーバーに次の緑色のチェックが表示されます。
この時点で、私たちのアーキテクチャは次のように説明できます。
これで、データベースクラスターを本番環境で使用できるようになりました。既存のデータベースをインポートすることも、新しいデータベースを作成することもできます。試用ライセンスの有効期限が切れていない場合は、スキーマとユーザーの管理機能を使用できます。
ClusterControlがKeepalivedを構成する方法を理解するには、このブログ投稿「ClusterControlが仮想IPを構成する方法とフェイルオーバー中に何を期待するか」を確認してください。
データベースクラスターへの接続
アプリケーションとクライアントの観点から、ロードバランサーの上にフローティングされている仮想IPアドレスであるポート6033で192.168.55.180に接続する必要があります。たとえば、Wordpressデータベースの構成は次のようになります。
/** The name of the database for WordPress */
define( 'DB_NAME', 'wp_myblog' );
/** MySQL database username */
define( 'DB_USER', 'wp_myblog' );
/** MySQL database password */
define( 'DB_PASSWORD', 'mysecr3t' );
/** MySQL hostname - virtual IP address with ProxySQL load-balanced port*/
define( 'DB_HOST', '192.168.55.180:6033' );ロードバランサーをバイパスしてデータベースクラスターに直接アクセスする場合は、データベースホストのポート3306に接続するだけです。これは通常、管理、管理、およびトラブルシューティングのためにDBAスタッフが必要とします。 ClusterControlを使用すると、これらの操作のほとんどをユーザーインターフェイスから直接実行できます。
最終的な考え
上に示したように、データベースクラスターの展開はもはや難しい作業ではありません。展開されると、無料の監視機能の完全なスイートと、バックアップ管理、フェイルオーバー/リカバリなどの商用機能があります。さまざまなタイプのクラスター/レプリケーショントポロジの迅速な展開は、高可用性データベースソリューションを評価し、それらが特定の環境にどのように適合するかを評価するときに役立ちます。