Nginxは、低メモリWebアプリケーションのプロキシおよび/またはバランサーとしての高度な機能と効率性で、よく知られています。 原則として、nginxはWebアプリケーションの最初の「防衛線」で使用され、バックエンドサーバーに負荷を分散し、定期的にパフォーマンスをチェックします。 このテクノロジーは、フォールトトレランスを強化する必要があるアプリケーションに非常に人気があります。
最近、nginx 1.9は、HAProxyを使用する前とほぼ同じTCPバランシングのサポートを発表しました。 最大の欠点の1つは、nginxが高度なサーバーヘルスチェックをサポートしていないことです。 この関数は、MySQL Galera Clusterを使用している場合に必要です。 これについては、次の章で詳しく説明します。 有料版（NGINX Plusと呼ばれる）にはそのような制限がないことに注意してください。
この記事では、nginxをMySQL Galera Clusterのプロキシとして使用し、高いパフォーマンスを得ようとします。 CentOS 7.1でClusterControlを使用してGaleraクラスターを作成しました。 図に示すように、「新しい」ホストにnginxをインストールします。
ヘルスチェック
GaleraやNDBのような同期複製クラスターの出現により、TCPプロキシをロードバランサーとして使用することが非常に一般的になりました。 すべてのMySQLノードは同じ方法で処理されます。これは、すべてのノードから読み取りと書き込みができるためです。 従来のMySQLレプリケーションの場合のように、マスターとスレーブを分離する必要はなくなりました。 Nginxはデータベース用に設計されていないため、追加の構成を使用して、クラスターがヘルスチェックに対して「クリア」な応答を返すようにする必要があります。
HAProxyを使用する場合、各MySQLサーバーのヘルスチェックスクリプトはHTTPステータスを返すことができるはずです。 たとえば、MySQLサーバーが「気分が良い」場合、スクリプトは200 OKのHTTPステータスを返します。 それ以外の場合、スクリプトは503サービスを利用不可として返します。 これらの設定により、HAProxyはルーティングリストを更新し、「問題のある」サーバーを除外できます。 残念ながら、健全性をテストするために、HAProxyはxinetdをポート9200でリッスンするデーモンとして使用します。 これらの構成は、nginxにはまだ存在しません。
このフローチャートは、マルチマスターをセットアップしてGaleraクラスターの正常性を判断するプロセスを示しています。
執筆時点では、NGINX Plus（有料）もサーバーのヘルスチェックをサポートしていましたが、カスタムポート設定はありませんでした。
clustercheck-iptablesを使用する
制限を回避するために、 clustercheck-iptablesというヘルスチェックスクリプトを作成しました。 これは、Galeraノードの動作をチェックし、ノードが（HTTP応答を返す代わりに）期待どおりに機能する場合、iptablesを使用してリダイレクトポートを追加するバックグラウンドスクリプトです。 このスクリプトは、nginx（> 1.9）、IPVS、keepalived、piranha、ディストリビューター、バランス、ペンなどの機能チェック機能が制限されている他のTCPバランサーで使用できます。
彼はどのように働いていますか？ スクリプトは、1秒に1回、Galeraクラスターの各ノードの操作をチェックします。 ノードが正常に動作している場合（wsrep_cluster_state_comment = Synced and read_only = OFF）または（wsrep_cluster_state_comment = Donor and wsrep_sst_method = xtrabackup / xtrabackup-v2）、転送ポートはiptables（デフォルトでは3308、リダイレクト3308）を使用して発生します。
$ iptables -t nat -A PREROUTING -s $0.0.0.0/0 -p tcp --dport 3308 -j REDIRECT --to-ports 3306
それ以外の場合、このルールはiptablesルールリストから削除されます。 バランサーには、デフォルトのポート3306の代わりにポート3308をインストールする必要があります。ノードが正常でない場合、ポート3308は使用できません。この場合、バランサーはこのノードをバランシングリストから削除する必要があります。
スクリプトをインストールして、実際にどのように機能するかを見てみましょう。
1.データベースサーバー上で、次のコマンドを実行してスクリプトをインストールします。
$ git clone https://github.com/ashraf-s9s/clustercheck-iptables $ cp clustercheck-iptables/mysqlchk_iptables /usr/local/sbin
2.デフォルトでは、スクリプトはMySQLユーザー「mysqlchk_user」とパスワード「mysqlchk_password」を使用します。 ユーザーが存在し、正常性をチェックするために必要な権限を持っていることを確認する必要があります。 これらのコマンドをクラスターノードの1つで実行します（Galeraは残りのノードでコマンドを実行します）。
mysql> GRANT PROCESS ON *.* TO 'mysqlchk_user'@'localhost' IDENTIFIED BY 'mysqlchk_password'; mysql> FLUSH PRIVILEGES;
**別のユーザーまたはパスワードを使用する場合は、-uおよび-p引数でそれらを指定します。 以下に例を示します。
3.スクリプトが機能するにはiptablesが必要です。 この例では、CentOS 7を使用しており、デフォルトでfirewalldがインストールされています。 iptables-servicesをインストールする必要があります。
$ yum install -y iptables-services $ systemctl enable iptables $ systemctl start iptables
次に、iptablesがデータベースとの通信に影響を与えないように、MySQL Galeraクラスターの基本的なルールを確立します。
$ iptables -I INPUT -m tcp -p tcp --dport 3306 -j ACCEPT $ iptables -I INPUT -m tcp -p tcp --dport 3308 -j ACCEPT $ iptables -I INPUT -m tcp -p tcp --dport 4444 -j ACCEPT $ iptables -I INPUT -m tcp -p tcp --dport 4567:4568 -j ACCEPT $ service iptables save $ service iptables restart
4.ルールを設定したら、次のコマンドを使用してルールを確認します。
$ iptables -L -n
5. mysqlchk_iptablesのテスト：
$ mysqlchk_iptables -t Detected variables/status: wsrep_local_state: 4 wsrep_sst_method: xtrabackup-v2 read_only: OFF [11-11-15 08:33:49.257478192] [INFO] Galera Cluster Node is synced.
6.よさそうだ。 次に、スクリプトをデーモンとして実行します。
$ mysqlchk_iptables -d /usr/local/sbin/mysqlchk_iptables started with PID 66566.
7.ルーティングルールは次のようになります。
$ iptables -L -n -t nat Chain PREROUTING (policy ACCEPT) target prot opt source destination REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:3308 redir ports 3306 Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination
8.最後に、スクリプトの起動を/etc/rc.localに追加して、サーバーの起動時に起動するようにします。
$ echo '/usr/local/sbin/mysqlchk_iptables -d' >> /etc/rc.local
一部のディストリビューションでは、rc.localにスクリプトを実行するために必要な権限があることを確認する価値があります。
$ chmod +x /etc/rc.local
アプリケーション側で、ポート3308でデータベースに接続できることを確認します。クラスターのすべての（残りの）ノードで上記の手順を繰り返します（2を除く）。 これで、ヘルスチェックは完了しました。バランス調整を行います。
MySQLクラスタにロードバランサーとしてnginxをインストールする
1.バランサー（サーバー）で、必要なパッケージをインストールします。
$ yum -y install pcre-devel zlib-devel
2. TCPプロキシモジュールを使用して、nginx 1.9（コードから）をインストールします。
$ wget http://nginx.org/download/nginx-1.9.6.tar.gz $ tar -xzf nginx-1.9.6.tar.gz $ ./configure --with-stream
3.次の行をnginx構成ファイル（
/usr/local/nginx/conf/nginx.conf
）に追加します。
stream { upstream stream_backend { zone tcp_servers 64k; server 192.168.55.201:3308; server 192.168.55.202:3308; server 192.168.55.203:3308; } server { listen 3307; proxy_pass stream_backend; proxy_connect_timeout 1s; } }
4. nginxを実行します。
$ /usr/local/nginx/sbin/nginx
5.設定で示したように、nginxがポート3307で「リッスン」していることを確認します。 MySQL接続はこのポートを通過する必要があります。その後、ポート3308に転送されます。次に、iptables（ノード上）はポート3306に要求を転送し、そこでMySQLに「リッスン」します。
$ netstat -tulpn | grep 3307 tcp 0 0 0.0.0.0:3307 0.0.0.0:* LISTEN 5348/nginx: master
いいね！ MySQL Galera Clusterにロードバランサーとしてnginxをインストールしました。 テストに進みます。
テスト中
次のテストを実行して、Galeraクラスターのnginxバランスを検証しました。
1.読み取り専用= ONおよび読み取り専用= OFFをg1.localに設定します。
2. g1.localのmysqlプロセスを強制終了し、SSTを強制的に開始しました。
3.他の2つのデータベースノードを強制終了して、g1.localを非プライマリにします。
4.非プライマリステータスからg1.localを実行します。
5.他の2つのノードを接続します。
以下のスクリーンキャストは、いくつかの端末の出力を示しています。
- ターミナル1（左上隅）：iptables PREROUTING出力。
- ターミナル2（右上隅）：g1.localのMySQL error.log。
- ターミナル3（中央左）：nginxバランサーに接続したときのアプリケーション出力。 日付、ホスト名、wsrep_last_committedおよびwsrep_local_state_commentを表示します。
- ターミナル4（中央右）：output / var / log / mysqlchk_iptables。
- ターミナル5（左下）：read_onlyおよびwsrep_sst_methodのg1.localへの出力。
- ターミナル6（右下）：操作パネル。
おわりに
HAProxyのみがカスタムポートの使用を許可したため、GaleraクラスターノードのヘルスチェックはHAProxyによって制限されていました。 このスクリプトを使用すると、任意のTCPロードバランサーやプロキシを使用して、Galeraクラスターノードを正しく監視できます。