ubuntu前書き高可用性はシステム設計の機能であり、障害が発生した場合にアプリケーションが自動的に再起動するか、作業を別の対応システムに再ルーティングできるようにします。サーバーに関しては、可用性の高いシステムをセットアップするために必要なテクノロジーがいくつかあります。作業をリダイレクトできるコンポーネントが必要です。障害を監視し、中断が検出された場合にシステムを移行するメカニズムが必要です。`デーモンを使用して、サービスまたはシステムを監視し、問題が発生した場合にスタンバイに自動的にフェールオーバーできます。+`を使用してロードバランサーの高可用性を設定する方法を示します。address]を構成します。これらはそれぞれ、2つのバックエンドWebサーバー間でトラフィックを分割するように構成されます。プライマリロードバランサーがダウンすると、フローティングIPは自動的に2番目のロードバランサーに移動し、サービスを再開できます。14.04サーバーを作成する必要があります。すべてのサーバーは同じデータセンター内に配置する必要があり、プライベートネットワークを有効にする必要があります。+`アクセスで設定された非rootユーザーが必要です。14.04初期サーバーセットアップガイド]を参照してください。サーバーネットワーク情報の検索インフラストラクチャコンポーネントの実際の構成を開始する前に、各サーバーに関する情報を収集することをお勧めします。このガイドを完了するには、サーバーに関する次の情報が必要です。+`を使用してDigitalOceanメタデータサービスからプライベートIPアドレスを取得することです。このコマンドは、ドロップレット内から実行する必要があります。各ドロップレットで、次を入力します。echoターミナルウィンドウに正しいIPアドレスを印刷する必要があります。「アンカーIP」は、DigitalOceanサーバーに接続されたときにフローティングIPがバインドするローカルプライベートIPアドレスです。+」アドレスの単なるエイリアスです。この値を取得する最も簡単でエラーの少ない方法は、DigitalOceanメタデータサービスから直接です。+」を使用すると、次のように入力して、各サーバー上のこのエンドポイントに到達できます。echoアンカーIPは独自の行に印刷されます。上記のデータを収集したら、サービスの構成に進むことができます。Note最初に、バックエンドWebサーバーをセットアップします。これらのサーバーは両方ともまったく同じコンテンツを提供します。プライベートIPアドレスを介したWeb接続のみを受け入れます。これにより、後で設定する2つのHAProxyサーバーのいずれかを経由してトラフィックが送信されるようになります。ロードバランサーの背後にWebサーバーをセットアップすると、いくつかの同一のWebサーバー間で要求の負荷を分散できます。トラフィックのニーズの変化に応じて、この層にWebサーバーを追加または削除することで、新しい需要に合わせて簡単に拡張できます。Nginxのインストールこの機能を提供するために、WebサービングマシンにNginxをインストールします。+」ユーザーでログインすることから始めます。各Webサーバーのローカルパッケージインデックスを更新し、次のように入力してNginxをインストールします。nginxロードバランサーからのリクエストのみを許可するようにNginxを構成する次に、Nginxインスタンスを構成します。Nginxに、サーバーのプライベートIPアドレスでのみリクエストをリッスンするように指示します。2つのロードバランサーのプライベートIPアドレスからのリクエストのみを処理します。これらの変更を行うには、各WebサーバーでデフォルトのNginxサーバーブロックファイルを開きます。`ディレクティブを変更します。`ディレクティブを変更して、現在の*ウェブサーバーのプライベートIPアドレス*をポート80でリッスンします。これは次のようになります。」ディレクティブを設定して、2つのロードバランサーのプライベートIPアドレスから発信されるトラフィックを許可します。+」ルールでこれをフォローアップします。.完了したら、ファイルを保存して閉じます。次のように入力して、行った変更が有効なNginx構文を表していることをテストします。-t問題が報告されていない場合は、次のように入力してNginxデーモンを再起動します。curl`を使用してリクエストを行うことができます。Webサーバー自体で、次のように入力して、ローカルコンテンツの簡単な要求を試すことができます。127.0.0.1Nginxサーバーブロックファイルに設定されている制限のため、このリクエストは実際に拒否されます。refusedこれは予想されることであり、実装しようとした動作を反映しています。これで、*ロードバランサー*のいずれかから、WebサーバーのパブリックIPアドレスのいずれかを要求できます。curl繰り返しますが、これは失敗するはずです。Webサーバーはパブリックインターフェイスをリッスンしておらず、さらにパブリックIPアドレスを使用している場合、Webサーバーはロードバランサーからのリクエストに許可されたプライベートIPアドレスを表示しません。refusedただし、ウェブサーバーの_プライベートIPアドレス_を使用してリクエストを行うように呼び出しを変更した場合、正しく動作するはずです。.これを両方のロードバランサーから両方のWebサーバーにテストします。プライベートIPアドレスに対する各リクエストは成功するはずであり、パブリックアドレスに対する各リクエストは失敗するはずです。上記の動作が実証されたら、次に進みます。バックエンドWebサーバーの設定が完了しました。次に、HAProxyロードバランサーを設定します。これらはそれぞれWebサーバーの前に配置され、2つのバックエンドサーバー間でリクエストを分割します。これらのロードバランサーは完全に冗長です。常に1つだけがトラフィックを受信します。HAProxy構成は、両方のWebサーバーに要求を渡します。ロードバランサーは、アンカーIPアドレスでリクエストをリッスンします。前述したように、これは、ドロップレットに添付されたときにフローティングIPアドレスがバインドするIPアドレスです。これにより、フローティングIPアドレスから発信されたトラフィックのみが転送されます。+`パッケージをインストールすることです。これはデフォルトのUbuntuリポジトリにあります。ロードバランサーのローカルパッケージインデックスを更新し、次のように入力してHAProxyをインストールします。エディターでそのファイルを開きます。/etc/default/haproxyこのファイルは、起動時にHAProxyを開始するかどうかを決定します。+`の値を「1」に変更する必要があります。16"上記の編集を行った後、ファイルを保存して閉じます。次に、メインのHAProxy構成ファイルを開くことができます。/etc/haproxy/haproxy.cfg調整する必要がある最初の項目は、HAProxyが動作するモードです。TCP、またはレイヤー4の負荷分散を構成します。+`行を変更する必要があります。ログを処理するオプションの直後にオプションを変更する必要があります。.ファイルの最後で、フロントエンドの構成を定義する必要があります。これにより、HAProxyが着信接続をリッスンする方法が決まります。HAProxyをロードバランサーのアンカーIPアドレスにバインドします。これにより、フローティングIPアドレスから発信されるトラフィックをリッスンできます。簡単にするために、フロントエンドを「www」と呼びます。トラフィックを渡すデフォルトのバックエンドも指定します(すぐに設定します)。nginx_pool次に、バックエンドセクションを構成できます。これにより、HAProxyが受信したトラフィックを渡すダウンストリームの場所が指定されます。WebサーバーのプライベートIPアドレスになります。従来のラウンドロビンバランシングを指定し、モードを再び「tcp」に設定します。check上記の変更が完了したら、ファイルを保存して閉じます。次のように入力して、行った構成変更が有効なHAProxy構文を表していることを確認します。-cエラーが報告されていない場合は、次を入力してサービスを再起動します。curl`でテストすることで、設定が有効であることを確認できます。127.0.0.1curlcurlこれらはすべて、次のようなメッセージで失敗します。index.html`ページが表示されます。.この動作がシステムの動作と一致する場合、ロードバランサーは正しく構成されています。Keepalivedのビルドとインストール現在、実際のサービスは稼働しています。アクティブなロードバランサーで問題が発生した場合、トラフィックをリダイレクトする方法がないため、インフラストラクチャの可用性はまだ高くありません。+`デーモンをインストールします。これは、アクティブなロードバランサーが利用できなくなった場合にフェールオーバー機能を提供するコンポーネントです。keepalived`のバージョンがありますが、それは時代遅れであり、構成が機能しなくなるいくつかのバグがあります。+`の最新バージョンをインストールします。開始する前に、ソフトウェアのビルドに必要な依存関係を取得する必要があります。+`がビルドする必要のあるSSL開発ライブラリが含まれます。`のtarballをダウンロードできます。[このページ]にアクセスしてください。最新バージョンを右クリックして、リンクアドレスをコピーします。+`を使用してコピーしたリンクを取得します。+`コマンドを使用して、アーカイブを展開します。結果のディレクトリに移動します。keepalived*次を入力して、デーモンをビルドおよびインストールします。installこれで、両方のロードバランサシステムにデーモンをインストールする必要があります。+`のインストールにより、すべてのバイナリとサポートファイルがシステム上の所定の場所に移動しました。14.04システムのUpstartスクリプトです。`サービスを処理できる非常にシンプルなUpstartスクリプトを作成できます。`が提供する機能の簡単な説明から始めることができます。+」ページの説明を使用します。次に、サービスを開始および停止するランレベルを指定します。このサービスは、すべての通常の状態(ランレベル2〜5)でアクティブになり、他のすべてのランレベル(たとえば、再起動、電源オフ、またはシングルユーザーモードが開始されたとき)で停止します。[!2345]このサービスはWebサービスを引き続き利用できるようにするために不可欠なので、障害が発生した場合にこのサービスを再起動する必要があります。+`オプションを追加する必要があります。--dont-fork完了したら、ファイルを保存して閉じます。+`の設定に進むことができます。+`ディレクトリで設定ファイルを探します。両方のロードバランサーでこのディレクトリを作成します。`設定ファイルを作成します。`ブロックを開いてHAProxyサービスのヘルスチェックを定義することから始めます。+」はロードバランサーの障害を監視できるため、プロセスがダウンしていることを通知し、対策を回復できます。チェックは非常に簡単です。+`を要求していることを確認します。`というブロックを開きます。+」が高可用性を実装する方法を定義するメインの設定セクションです。MASTER”に設定します。+」が使用する初期値です。+」オプションを使用して、選出されるメンバーを決定します。決定は、どのサーバーがこの設定の最大数を持っているかに基づいています。プライマリサーバーには「200」を使用します。200}次に、両方のノードで共有されるこのクラスターグループにIDを割り当てます。この例では「33」を使用します。*ロードバランサーのプライベートIPアドレスに設定する必要があります。+`を*セカンダリ*ロードバランサーのプライベートIPアドレスに設定します。`デーモンが互いに通信するための簡単な認証を設定できます。これは、連絡先のピアが正当であることを確認するための基本的な手段にすぎません。authentication`サブブロックを作成します。`を設定してパスワード認証を指定します。+`パラメーターには、両方のノードで使用される共有シークレットを設定します。残念ながら、重要なのは最初の8文字のみです。+`スクリプトを設定します。このスクリプトは、フローティングIPアドレスの再割り当てをトリガーします。このスクリプトを一時的に作成します。/etc/keepalived/master.sh}上記の情報を設定したら、ファイルを保存して閉じます。次に、セカンダリロードバランサーでコンパニオンスクリプトを作成します。+`でファイルを開きます。/etc/keepalived/keepalived.conf内部では、使用するスクリプトは主サーバーのスクリプトとほぼ同等です。変更する必要がある項目は次のとおりです。+:これは、選択が行われる前にノードがバックアップ状態に初期化されるように、セカンダリサーバーで「BACKUP」に変更する必要があります。+:これは、プライマリサーバーよりも低い値に設定する必要があります。このガイドでは、値「100」を使用します。*サーバーのプライベートIPアドレスでなければなりません。+:これには、*プライマリ*サーバーのプライベートIPアドレスが含まれている必要があります。これらの値を変更すると、セカンダリサーバーのスクリプトは次のようになります。/etc/keepalived/master.sh}スクリプトを入力して適切な値を変更したら、ファイルを保存して閉じます。+`インスタンスがマスターサーバーになるたびに、現在のドロップレットにフローティングIPアドレスを再割り当てするために使用できるスクリプトのペアを作成する必要があります。フローティングIP割り当てスクリプトをダウンロードするまず、汎用のPythonスクリプト(https://www.digitalocean.com/community/users/asb[DigitalOceanコミュニティマネージャー]が作成)をダウンロードします。これは、DigitalOceanを使用してフローティングIPアドレスをDropletに再割り当てするために使用できます。+`ディレクトリにダウンロードする必要があります。http://do.co/assign-ipこのスクリプトを使用すると、次を実行して既存のフローティングIPを再割り当てできます。+`という環境変数がある場合にのみ機能します。APIトークンを作成する必要があります。コントロールパネルで、上部の[API]リンクをクリックします。APIページの右側で、「新しいトークンを生成」をクリックします。token]次のページで、トークンの名前を選択し、「トークンの生成」ボタンをクリックします。セキュリティのため、後でこのトークンを再度表示する方法はありません。このトークンを紛失した場合、それを破棄して別のトークンを作成する必要があります。インフラストラクチャにフローティングIPを構成する次に、サーバーで使用するフローティングIPアドレスを作成して割り当てます。DigitalOceanコントロールパネルで、「ネットワーク」タブをクリックし、「フローティングIP」ナビゲーション項目を選択します。初期割り当てのメニューからプライマリロードバランサーを選択します。IP]アカウントに新しいフローティングIPアドレスが作成され、指定されたドロップレットに割り当てられます。[DigitalOceanフローティングIP割り当て]WebブラウザでフローティングIPにアクセスすると、バックエンドWebサーバーのいずれかから提供されるデフォルトのNginxページが表示されます。index.html]フローティングIPアドレスをコピーします。以下のスクリプトでこの値が必要になります。+`スクリプトを呼び出すラッパースクリプトを作成するために必要なアイテムができました。次のように入力して、ロードバランサーの両方にファイルを作成します。`という変数を割り当ててエクスポートすることから始めます。+」という変数を割り当てることができます。IDをメタデータサービスに要求します。」という変数に割り当てられます。このDropletに現在フローティングIPアドレスが割り当てられているかどうかを尋ねます。+`スクリプトを呼び出すことができます。フローティングIPがドロップレットに関連付けられていない場合にのみ、スクリプトを呼び出します。これにより、API呼び出しが最小限に抑えられ、マスターステータスがサーバー間で急速に切り替わる場合に、APIへの競合する要求を防ぐことができます。+`スクリプトを数回再試行します。以下では、各呼び出しの間に3秒間隔で、スクリプトを10回実行しようとします。フローティングIPの移動が成功すると、ループはすぐに終了します。donefi完了したら、ファイルを保存して閉じます。+`で呼び出せるようにするだけです。+`デーモンとそのすべてのコンパニオンスクリプトは完全に設定されているはずです。次のように入力して、両方のロードバランサーでサービスを開始できます。keepalivedサービスは各サーバーで起動し、ピアに接続して、構成した共有シークレットで認証する必要があります。+`プロセスからのシグナルをリッスンします。現在、フローティングIPアドレスが割り当てられているプラ​​イマリロードバランサーは、リクエストを各バックエンドNginxサーバーに順番に送信します。通常適用される単純なセッションスティッキがいくつかあり、Webブラウザーを介して要求を行うときに同じバックエンドを取得する可能性が高くなります。プライマリロードバランサーでHAProxyをオフにするだけで、簡単な方法でフェールオーバーをテストできます。stopブラウザでフローティングIPアドレスにアクセスすると、ページが見つからなかったことを示すエラーが一時的に表示される場合があります。index.html]HAProxyサービスはプライマリロードバランサーでまだ停止しているため、セカンダリロードバランサーが引き継いだことを示しています。+」を使用して、セカンダリサーバーはサービスの中断が発生したことを判別できました。APIを使用してフローティングIPを要求しました。これで、プライマリロードバランサーでHAProxyを再び起動できます。startプライマリロードバランサーは、すぐにフローティングIPアドレスの制御を取り戻しますが、これはユーザーに対してかなり透過的でなければなりません。遷移の視覚化ロードバランサー間の移行をよりよく視覚化するために、移行中にサーバーログの一部を監視できます。使用されているプロキシサーバーに関する情報はクライアントに返されないため、ログを表示するのに最適な場所は、実際のバックエンドWebサーバーからです。これらの各サーバーは、どのクライアントがアセットを要求するかに関するログを保持する必要があります。Nginxサービスの観点から見ると、クライアントは実際のクライアントに代わってリクエストを行うロードバランサーです。これにより、サーバーに対して行われた各リクエストが表示されます。ロードバランサーはラウンドロビンローテーションを使用してトラフィックを均等に分割するため、各バックエンドWebサーバーは約半分のリクエストを確認する必要があります。幸いなことに、クライアントアドレスはアクセスログの最初のフィールドです。+`コマンドを使用して値を抽出できます。Webサーバーの両方で次を実行します。$1;}'これらは、ほとんどの場合単一のアドレスを示します。.サーバーのIPアドレスを参照すると、これらのほとんどがプライマリロードバランサーからのものであることがわかります。実際の配布は、HAProxyが実装する単純なセッションスティッキ性により、少し異なる可能性が高いことに注意してください。+」コマンドを実行し続けます。フローティングIPへのリクエストを自動化する次に、ローカルマシンで、2秒ごとに1回、フローティングIPアドレスでWebコンテンツを要求します。これにより、ロードバランサーの変更が簡単に確認できます。ローカルターミナルで、次のように入力します(実際の応答は破棄されます。これは、どのロードバランサーが使用されているかに関係なく同じであるためです)。doneWebサーバーで、新しい要求が着信するのを確認する必要があります。+」リクエストは同じセッションスティッキ性を示しません。バックエンドWebサーバーへのリクエストがより均等に分割されるはずです。プライマリロードバランサーでHAProxyサービスを中断するこれで、プライマリロードバランサーのHAProxyサービスを再びシャットダウンできます。stop数秒後、ウェブサーバーで、プライマリロードバランサーのプライベートIPアドレスからセカンダリロードバランサーのプライベートIPアドレスに移行するIPのリストが表示されます。.新しいリクエストはすべて、セカンダリロードバランサーから行われます。次に、プライマリロードバランサーでHAProxyインスタンスを再度起動します。start数秒以内に、クライアントリクエストがプライマリロードバランサーのプライベートIPアドレスに戻ることがわかります。.プライマリサーバーは、フローティングIPアドレスの制御を取り戻し、インフラストラクチャのメインロードバランサーとしてのジョブを再開しました。ロードバランサーサーバーではなく、元のクライアントのIPアドレスをログに記録しておくと便利です。これは、すべてのバックエンドWebサーバーでNginx構成にいくつかの変更を加えることで簡単に実現できます。+`ファイルを開きます。+」ブロック内)を見つけて、次の行を追加します。'"$http_user_agent"';保存して終了。`の値(元のリクエストを行ったクライアントのIPアドレス)を追加します。アクティブなロードバランサーサーバー)。次に、この新しいログ形式を使用するには、デフォルトのサーバーブロックに行を追加する必要があります。+」サーバー設定を開きます。haproxy_log;保存して終了。+`ログ形式を使用してアクセスログを書き込むようにNginxに指示します。両方のWebサーバーで、Nginxを再起動して変更を有効にします。restartこれで、Nginxアクセスログには、リクエストを行っているクライアントの実際のIPアドレスが含まれているはずです。前のセクションで行ったように、アプリサーバーのログを追跡してこれを確認します。ログエントリは次のようになります。.ログに問題がなければ、準備は完了です!結論このガイドでは、可用性の高い、負荷分散されたインフラストラクチャをセットアップする完全なプロセスを説明しました。アクティブなHAProxyサーバーがバックエンドのWebサーバーのプールに負荷を分散できるため、この構成はうまく機能します。需要の増減に応じて、このプールを簡単に拡張できます。+」構成は、ロードバランシングレイヤーでの単一障害点を排除し、プライマリロードバランサーが完全に失敗した場合でもサービスが機能し続けることを可能にします。この構成はかなり柔軟であり、HAProxyサーバーの背後に好みのWebスタックをセットアップすることにより、独自のアプリケーション環境に適合させることができます。