ubuntu前書きこのチュートリアルでは、CorosyncとPacemakerをフローティングIPで使用して、DigitalOceanで高可用性(HA)サーバーインフラストラクチャを作成する方法を示します。*レイヤーと呼ばれるクラスターメンバーシップとメッセージング機能をクライアントサーバーに提供するオープンソースプログラムです。Pacemakerは、オープンソースのクラスターリソースマネージャー(CRM)です。CRMは、クラスターによって管理され、高可用性を実現するリソースとサービスを調整するシステムです。本質的に、Corosyncはサーバーがクラスターとして通信できるようにし、Pacemakerはクラスターの動作を制御する機能を提供します。14.04サーバーで構成されます。これは、障害が検出されない限り、ユーザーがWebサービスにアクセスする方法であるフローティングIPをポイントして、プライマリ(アクティブ)サーバーをポイントすることで実現されます。APIを介して自身にフローティングIPを再割り当てするスクリプトを自動的に実行します。IPへの後続のネットワークトラフィックはセカンダリサーバーに向けられ、セカンダリサーバーはアクティブサーバーとして機能し、着信トラフィックを処理します。この図は、説明されているセットアップの概念を示しています。[アクティブ/パッシブ図]この目標を達成するには、次の手順に従います。APIを使用する必要があります。Token(PAT)を生成する必要があります。PATは、https://www.digitalocean.com/communityに従って_read_および_write_アクセスを使用してDigitalOceanアカウントの認証に使用できるAPIトークンです。[個人アクセストークンの生成方法]セクション。PATはクラスター内の両方のサーバーに追加されるスクリプトで使用されるため、参照用にDigitalOceanアカウントへのフルアクセスを許可するため、安全な場所に保管してください。このチュートリアルでは、APIに加えて、次のDigitalOcean機能を利用します。[ユーザーデータ(Cloud-Configスクリプト)]詳細については、リンクされたチュートリアルをご覧ください。液滴を作成する最初のステップは、同じデータセンター内でプライベートネットワークが有効になっている2つのUbuntuドロップレットを作成することです。これは上記のプライマリサーバーとセカンダリサーバーとして機能します。このセットアップ例では、簡単に参照できるように「primary」および「secondary」という名前を付けます。Nginxを両方のDropletにインストールし、インデックスページをそれらを一意に識別する情報で置き換えます。これにより、HAセットアップが機能していることを示す簡単な方法が得られます。実際のセットアップでは、サーバーでNginxやHAProxyなど、選択したWebサーバーまたはロードバランサーを実行する必要があります。設定例に従う場合は、次のbashスクリプトをユーザーデータとして使用します。+」の内容をドロップレットのホスト名とIPアドレスに置き換えます(メタデータサービスを参照して)。パブリックIPアドレスを介していずれかのDropletにアクセスすると、Dropletのホスト名とIPアドレスを含む基本的なWebページが表示されます。IPがどのDropletを指すかをテストするのに役立ちます。*]をクリックします。*ボタンをクリックします。フローティングIPが割り当てられたら、そのIPアドレスをメモします。WebブラウザでフローティングIPアドレスにアクセスして、割り当てられたドロップレットに到達できることを確認します。http://プライマリドロップレットのインデックスページが表示されます。Aレコード*を作成して、ドメインがフローティングIPアドレスを指すようにします。伝播すると、ドメイン名を介してアクティブなサーバーにアクセスできます。現在使用するドメイン名がない場合は、代わりにフローティングIPアドレスを使用してセットアップにアクセスします。時刻同期を構成する複数のサーバーが相互に通信している場合、特にクラスタリングソフトウェアと通信している場合は常に、クロックが同期していることを確認することが重要です。Protocol)を使用してサーバーを同期します。*両方のサーバー*で、次のコマンドを使用してタイムゾーンセレクターを開きます。tzdata希望のタイムゾーンを選択します。次に、apt-getを更新します。+`パッケージをインストールします。ntpこれで、NTPを使用してサーバーのクロックを同期する必要があります。[タイムゾーンとネットワークタイムプロトコルの同期を構成する]。ファイアウォールを構成するCorosyncは、ポート「5404」と「5406」の間でUDPトランスポートを使用します。ファイアウォールを実行している場合、それらのポートでの通信がサーバー間で許可されていることを確認してください。+」(プライベートネットワークインターフェース)のトラフィックを許可できます。ACCEPT提供されている例よりも制限の厳しいファイアウォールルールを使用することをお勧めします。CorosyncとPacemakerをインストールする*両方のサーバー*で、apt-getを使用してCorosyncとPacemakerをインストールします。pacemakerCorosyncはPacemakerパッケージの依存関係としてインストールされることに注意してください。CorosyncとPacemakerがインストールされましたが、何か役に立つ前に設定する必要があります。Corosyncを構成するサーバーがクラスターとして通信できるように、Corosyncを構成する必要があります。クラスター認証キーを作成するノードがクラスターに参加できるようにするには、Corosyncで各ノードが同一のクラスター認証キーを所有している必要があります。havegedこのソフトウェアパッケージにより、サーバーのエントロピーの量を簡単に増やすことができます。+`スクリプトで必要です。+`スクリプトを実行します。+`に書き込まれます。*サーバーから削除しましょう。+`をセカンダリサーバーにコピーします。+`ファイルを適切な場所に移動し、その権限をルートに制限します。+`ファイルに同じ認証キーが必要になります。/etc/corosync/corosync.confサーバーがクラスターとして通信できるようにするCorosync構成ファイルを次に示します。強調表示された部分を適切な値に置き換えてください。`には、現在作業しているサーバーのプライベートIPアドレスを設定する必要があります。強調表示されている他の2つの項目は、指定されたサーバーのプライベートIPアドレスに設定する必要があります。+`を除き、ファイルは両方のサーバーで同一でなければなりません。*セクション(1〜11行目)は、Corosyncがクラスターメンバーシップに使用するTotemプロトコルを指し、クラスターメンバーが相互に通信する方法を指定します。+」(Corosyncがバインドするネットワークアドレスを指定)が含まれます。これは、クォーラムを達成するにはクラスター内に少なくとも3つのノードが必要であるという事実の回避策です。この設定により、2ノードクラスターがコーディネーター(DC)を選択できるようになります。DCは、特定の時点でクラスターを制御するノードです。*セクション(行18〜29)は、クラスター内の各ノードと、各ノードに到達する方法を指定します。ここでは、プライマリノードとセカンダリノードの両方を構成し、それぞれのプライベートIPアドレスを介して到達できるように指定します。+`に書き込むことを指定しています。このチュートリアルの残りの部分で問題が発生した場合は、トラブルシューティング中に必ずこちらをご覧ください。次に、Pacemakerサービスを許可するようにCorosyncを構成する必要があります。`ファイルを作成します。/etc/corosync/service.d/pcmk次に、Pacemakerサービスを追加します。これはCorosync構成に含まれ、PacemakerがCorosyncを使用してサーバーと通信できるようにします。デフォルトでは、Corosyncサービスは無効になっています。corosyncSTART=保存して終了。これで、Corosyncサービスを開始できます。*両方*サーバーで、次のコマンドでCorosyncを起動します。start両方のサーバーでCorosyncを実行したら、それらをクラスター化する必要があります。これを確認するには、次のコマンドを実行します。members出力は次のようになります。これは、プライマリ(ノード1)とセカンダリ(ノード2)がクラスターに参加したことを示しています。joinedCorosyncが適切に設定されたので、Pacemakerの構成に移りましょう。Pacemakerの起動と構成Corosyncのメッセージング機能に依存するPacemakerを起動して、基本的なプロパティを設定する準備ができました。Pacemakerを有効にして起動するPacemakerサービスではCorosyncが実行されている必要があるため、デフォルトでは無効になっています。*両方のサーバー*で、次のコマンドを使用してPacemakerがシステム起動時に起動できるようにします。01前のコマンドで、Pacemakerの開始優先度を「20」に設定します。PacemakerがCorosyncの後に起動するように、Corosyncの開始優先度(デフォルトでは「19」)を指定することが重要です。それでは、Pacemakerを起動しましょう。+`ユーティリティを使用します。]この出力について注意すべき点がいくつかあります。secondary(2)+`に設定する必要があります。0リソースが構成されている必要があります*。*としてマークする必要があります。それらが*オフライン*とマークされている場合は、30秒待ってからステータスを再度確認し、それが修正されるかどうかを確認します。この時点から、別のSSHウィンドウ(いずれかのクラスターノードに接続)で対話型CRMモニターを実行できます。これにより、各ノードのステータス、および各リソースが実行されている場所のリアルタイム更新が提供されます。`の出力と同じに見えます。クラスターのプロパティを構成するこれで、Pacemakerの基本的なプロパティを設定する準備が整いました。crm)コマンドはいずれかのノードサーバーから実行できます。目的のセットアップでは、2ノードクラスターをセットアップしているため、多くのクラスターが障害のあるノードを削除するために使用するSTONITHモードを無効にします。そのためには、いずれかのサーバーで次のコマンドを実行します。stonith-enabled=falseまた、ログ内のクォーラム関連のメッセージを無効にします。no-quorum-policy=ignore繰り返しますが、この設定は2ノードのクラスターにのみ適用されます。Pacemakerの構成を確認するには、次のコマンドを実行します。showこれにより、アクティブなPacemaker設定がすべて表示されます。現在、これには2つのノードと、設定したSTONITHおよびクォーラムプロパティのみが含まれます。フローティングIP再割り当てリソースエージェントの作成Pacemakerが実行および構成されたので、Pacemakerが管理するリソースを追加する必要があります。はじめに述べたように、リソースとは、クラスターが高可用性を実現するサービスです。Pacemakerでは、リソースを追加するには、管理されるサービスへのインターフェイスとして機能する*リソースエージェント*を使用する必要があります。Pacemakerには、共通サービス用のリソースエージェントがいくつか付属しており、カスタムリソースエージェントを追加できます。*によって提供されるサービスがアクティブ/パッシブセットアップで高可用性であることを確認する必要があります。IPを確実にする方法が必要です。常に利用可能なサーバーを指します。これを有効にするには、各ノードが実行できる*リソースエージェント*を設定して、ノードがフローティングIPを所有しているかどうかを判断し、必要に応じてスクリプトを実行してフローティングIPを指すようにする必要があります。OCFリソースエージェントをインストールしたら、リソース自体を定義できます。+`リソースを別のノードに移動する必要がある場合に備えて、フローティングIPが指すドロップレットを再割り当てできるスクリプトが必要です。APIを使用して、特定のドロップレットIDにフローティングIPを割り当てる基本的なPythonスクリプトをダウンロードします。Pythonスクリプトをダウンロードします。http://do.co/assign-ip*両方のサーバー*で実行可能にします。+`スクリプトを使用するには、次の詳細が必要です。PAT続行する前に、スクリプトの内容を自由に確認してください。OCFリソースエージェントから呼び出されます。Agentをインストールしましょう。OCFリソースエージェントをダウンロードPacemakerは、特定のディレクトリにOCFリソースエージェントを配置することで追加できます。+`リソースエージェントプロバイダーディレクトリを作成します。https://gist.githubusercontent.com/thisismitch/b4c91438e56bfe6b7bfb/raw/2dffe2ae52ba2df575baae46338c155adbaef678/floatip-ocf*両方のサーバー*で実行可能にします。/usr/lib/ocf/resource.d/digitalocean/floatip続行する前に、リソースエージェントの内容を自由に確認してください。`コマンドで呼び出された場合、それを呼び出すノードのドロップレットIDを(メタデータ経由で)検索し、フローティングIPをドロップレットIDに割り当てるbashスクリプトです。of」コマンドに応答します。次のOCFパラメーターが必要です。+`リソースを定義できます。+`リソースを設定できます。+`リソースを作成します(強調表示された2つのパラメーターを独自の情報で指定してください)。+)を使用して、「FloatIP」と呼ばれる一般的なタイプのクラスターリソースであるプリミティブリソースが作成されます。+」が必要であることに注意してください。これらは、フローティングIPを再割り当てする必要がある場合に使用されます。+`リソースが定義され、開始されていることがわかります。`モードになった場合、フローティングIPはオンラインサーバーに再割り当てされます。+」リソースを開始し、自身のフローティングIPアドレスを要求するように指示します。再割り当てが行われると、フローティングIPは新しくアクティブな*セカンダリ*サーバーにユーザーを誘導します。現在、フェールオーバー(フローティングIPの再割り当て)は、アクティブなホストがオフラインになるか、クラスターと通信できない場合にのみトリガーされます。このセットアップのより良いバージョンは、Pacemakerによって管理されるべき追加のリソースを指定します。これにより、クラスターはロードバランサーやWebサーバーソフトウェアなどの特定のサービスの障害を検出できます。設定する前に、基本的なフェールオーバーが機能することを確認する必要があります。高可用性のテスト高可用性の設定が機能することをテストすることが重要です。それでは、それを実行しましょう。IPアドレスまたはそれを指しているドメイン名を使用して、フローティングIPにアクセスすると、*プライマリ*サーバーのインデックスページが表示されます。サンプルのユーザーデータスクリプトを使用した場合、次のようになります。Address:これは、実際にはフローティングIPがプライマリドロップレットに割り当てられていることを示しています。+」を使用して1秒のループでフローティングIPにアクセスします。これを行うにはこのコマンドを使用しますが、必ずURLをドメインまたはフローティングIPアドレスに置き換えてください。done現在、これはプライマリサーバーの同じドロップレット名とIPアドレスを出力します。+」に変更してプライマリサーバーに障害が発生した場合、フローティングIPがセカンダリサーバーに再割り当てされるかどうかがわかります。ここで*プライマリ*サーバーを再起動しましょう。これを行うには、DigitalOceanコントロールパネルを使用するか、プライマリサーバーで次のコマンドを実行します。rebootしばらくすると、プライマリサーバーが使用できなくなります。+`ループの出力に注意してください。次のような出力が表示されるはずです。Address:...つまり、*セカンダリ*サーバーのIPアドレスを指すように、フローティングIPアドレスを再割り当てする必要があります。これは、正常な自動フェールオーバーが発生したため、HAセットアップが機能していることを意味します。プライマリサーバーの障害とフローティングIPの再割り当てが完了するまでの間にフローティングIPにアクセスしようとすると、「接続拒否」エラーが表示される場合と表示されない場合があります。+`リソースが開始されていることがわかります。Online`リストに参加します。フェイルオーバーのトラブルシューティング(オプション)HAセットアップが期待どおりに機能する場合は、このセクションをスキップしてください。フェイルオーバーが予想どおりに発生しなかった場合は、先に進む前にセットアップを確認する必要があります。ノードIPアドレス、フローティングIP、APIトークンなど、独自のセットアップへの参照を確認してください。トラブルシューティングに役立つコマンドセットアップのトラブルシューティングに役立つコマンドを次に示します。+`ツールはノードとリソースのリアルタイムステータスを表示するのに非常に役立ちます。crm_monまた、次のコマンドを使用してクラスター構成を確認できます。+`コマンドがまったく機能しない場合は、Corosyncログで手がかりを探す必要があります。/var/log/corosync/corosync.logその他のCRMコマンドこれらのコマンドは、クラスターを構成するときに役立ちます。+」モードに設定できます。これは、使用不可になるノードをシミュレートするために使用できます。online」に変更できます。online次のコマンドを使用して、リソースを編集できます。これにより、リソースを再構成できます。edit次のコマンドを使用して、削除する前に停止する必要があるリソースを削除できます。+`プロンプトにアクセスできます。+`設定の実行に使用できます。Nginxリソースの追加(オプション)フローティングIPフェイルオーバーが機能することが確認できたので、クラスターに新しいリソースを追加してみましょう。このセットアップ例では、Nginxが高可用性を実現するメインサービスであるため、クラスターが管理するリソースとしてNginxを追加する作業に取り掛かります。PacemakerにはNginxリソースエージェントが付属しているため、クラスターリソースとしてNginxを簡単に追加できます。このコマンドを使用して、「Nginx」という新しいプリミティブクラスターリソースを作成します。interval="0"指定されたリソースは、10秒ごとにNginxを監視し、Nginxが利用できなくなった場合に再起動するようにクラスターに指示します。status`を使用して、クラスターリソースのステータスを確認します。+`リソースを開始することにします。これは、フローティングIPが1つのドロップレットを指し、Nginxサービスが他のドロップレットでのみ実行されることを意味するためです。フローティングIPにアクセスすると、高可用性が必要なサービスを実行していないサーバーが示されます。*リソースを作成します。+」リソースの「Nginx-clone」というクローンリソースを作成します。Nginxクラスタのステータスは次のようになります。+`が両方のノードで開始されました。+`リソースを持つノードで実行されるように指定することです。「FloatIP-Nginx」というコロケーション抑制を作成するには、次のコマンドを使用します。+`の出力に違いは見られませんが、次のコマンドでコロケーションリソースが作成されたことがわかります。+`リソースが実行されているはずです。*サーバーを再起動または電源オフして、HAセットアップをテストする良い機会です。結論おめでとうございます。IPを使用した基本的なHAサーバーのセットアップが完了しました。次のステップは、例のNginxセットアップをリバースプロキシロードバランサーに置き換えることです。この目的でNginxまたはHAProxyを使用できます。ロードバランサーを*アンカーIPアドレス*にバインドすると、ユーザーが各サーバーのパブリックIPアドレスではなく、フローティングIPアドレスを介してのみサーバーにアクセスできることに注意してください。IPを使用して高可用性HAProxyセットアップを作成する方法]チュートリアル。