はじめに
こんにちは。ネットワークエンジニアの「だいまる」です。
今回はサーバ運用編として、「Nginx」のUpstreamモジュールを利用してみたので、構築方法や感想をまとめていきます。
Upstreamモジュールとは?
そもそも、Nginxの「Upstream」とは「Nginx上でHTTPによるロードバランシングを実施するために利用するモジュール」となります。
このモジュールを利用することで、「Active-Active」や「Active-Standby」の負荷分散(ロードバランシング)ができ、アクセスが大量にあるWebサーバ等の運用に役に立ちます。
一部機能は有料版での利用となるみたいですが、基本は無料版で利用できるので個人開発であれば、有効活用できると思います。
個人開発では極力お金はかけたくないですよね!
Upstreamモジュールの公式HP:https://nginx.org/en/docs/http/ngx_http_upstream_module.html
今回は「Active-Standby構成」で構築
Step1:構築したい構成・動作について
今回作ってみたいと思っていた構成は、以下の図の通りとなります。
この構成を作りたかった理由は「ブログの更なる安定運用につなげたい」ためです。
他記事で説明していますが、現在利用しているメインサーバはESXiの未サポートのマザーボードとNICとなっています。
そのため、度々、パープル画面やNICが不安定となり接続断が発生しています。
最近は両方とも安定しているのですが・・・・
NICの不安定状態も長いと「30分」程度の接続断が発生するし、外出時にパープル画面に遷移した場合、継続断となってしまいます。
そういった最悪の状況を防ぐために、バックアップ側のサーバに遷移するようにしたかったのです。
Step2:基本となるConfigの作成
構築したい構成を説明した後は、Upstreamの基本となるConfigについて説明したいと思います。
http{
upstream daimaru{
server x.x.x.x fail_timeout=1m max_fails=1;
server y.y.y.y backup;
}
server{
server_name daimaru-tech-blog.com;
location / {
proxy_next_upstream http_500 http_502 http_504 http_503;
proxy_next_upstream_timeout 15s;
proxy_next_upstream_tries 1;
proxy_pass http://daimaru/;
}
}
}
今回、追加したConfigは上記の通りとなります。
基本的にhttp配下に全て追加します。
「upstream」部分に負荷分散(ロードバランシング)を行うサーバ情報を記載するイメージです。
UpstreamのConfig作成
Upstream配下のConfigには、負荷分散(ロードバランシング)を行うサーバやルールを記載します。
具体的には、以下のConfig例を利用して説明したいと思います。
upstream <グループ名>{
server <サーバアドレス> fail_timeout=1m max_fails=1;
server <サーバアドレス> backup;
}
項目 | 詳細 |
upstream <グループ名> | 負荷分散を行うサーバの指定やルール記載のグローバルな設定 |
server <サーバアドレス> | 負荷分散を行うサーバの指定(アドレスやドメインの指定が可能) |
fail_timeout | サーバDown時、復旧確認までの時間 ※1mの場合:Downを検知し、1m経過するまでは復旧確認を行わない |
max_fails | サーバDownの判定基準となるアクセス失敗回数 ※アクセス失敗:別のConfigで定義 |
backup | 他サーバが全てDownした際に接続するサーバ |
down | 意図的にdownとするためのConfig |
location配下のConfig
location配下のConfigでは、upstream説明時に触れたアクセス失敗の基準を定義していきます。
location / {
proxy_next_upstream http_500 http_502 http_504 http_503;
proxy_next_upstream_timeout 15s;
proxy_next_upstream_tries 1;
proxy_pass http://daimaru/;
}
項目 | 詳細 |
proxy_next_upstream <指定オプション> | 指定オプションの回答があった場合、失敗もしくは他サーバへの再接続を実施 ※オプション:公式HP参照 |
proxy_next_upstream_timeout <時間> | アクセス試行時間(指定時間経過後、失敗と判定) |
proxy_next_upstream_tries <回数> | アクセス失敗時に再接続を実施するサーバ数 ※メインサーバが2台の場合は「2」とする |
proxy_pass <接続先> | プロキシ先のサーバ指定 ※upsream利用時はグループ名を記載 |
基本となる設定は上記2つで完了します。
次に実際の動作を確認していきましょう。
Step3:Config適用後は動作確認とその感想
Active側のサーバを落とし、期待通りにStandby側に切り替わるのかみてみました。
結果、想定通りとまではいきませんでした、切り替わることは確認できました。
ただ、切り替わるまで時間がかかっていたのと頻繁にエラーとなるため、あまり効果的には使えないなと思いました。
私の使い方が間違っている可能性もあるため、今後修正する可能性はありますが、今は非常時用のためだけに利用しています。
最後に
今回は、Nginxのモジュールの1つである「Upstream」についてまとめてみました。
みなさんのブログ運営等に役に立てたら幸いです。