高可用性（HA）コントローラのデプロイにより、サーバーまたはネットワークの障害、管理のダウンタイム、またその他の中断によって引き起こる中断を最小限に抑えることができます。HA デプロイは 2 つのコントローラで構成され、1 つはプライマリ、もう 1 つはセカンダリの役割を果たします。
Enterprise Console により、Linux システムでの高可用性デプロイに関連する構成および管理タスクが自動化されます。コントローラ HA ペアは、Windows Enterprise Console マシンでは利用できません。
基本的には、コントローラの高可用性を設定するため、プライマリコントローラとセカンダリコントローラのMySQLインスタンス間でマスターレプリケーションを構成することになります。
注意すべき重要な運用上のポイントは、両方のコントローラのデータベースを実行する必要がある一方で、両方のコントローラ アプリケーション サーバーが同時にアクティブ（ネットワークにより実行されアクセス可能である）であってはならないことです。同様に、コントローラペアのロードバランサで構成するトラフィック分散ポリシーは、一度に1つのコントローラにのみトラフィックを送信する必要があります（ロードバランサでラウンドロビンまたは類似のルーティング配信ポリシーを使用しない）。
コントローラは暗号化されたデータベース レプリケーションをサポートしています。
高可用性の概要
HAの配置にコントローラをデプロイすると大きなメリットがあります。サーバーに障害が発生した際のダウンタイムを最小限に抑え、最低限の中断でプライマリコントローラをメンテナンスすることができます。セカンダリはコントローラデータの更新コピーを保持するため、コントローラデータのバックアップ要件を満たします。セカンダリはデータのコールドバックアップ実行や長期的なクエリを実行するためのデータベースへのアクセス、たとえばトラブルシューティングやカスタマイズした報告など、ライブコントローラでは実行が推奨されない特定のリソース集約型操作を実行することもできます。
HA モードには、各コントローラにコントローラが生成した完全なデータを持つ独自の MySQL データベースが存在します。プライマリコントローラにはマスター MySQL データベースがあり、セカンダリコントローラのレプリカ MySQL データベースにデータを複製します。HA モードでは、MySQL マスター/マスター レプリケーション タイプの設定を使用します。コントローラの HA ペアの各マシンには、同等のディスク容量が必要です。
下図は、高レベルのHAペアのデプロイを示しています。このシナリオでは、エージェントはプロキシロードバランサを介してプライマリコントローラに接続します。HA ペアのコントローラは同等のバージョンで、同じデータセンター内にある必要があります。
この図では、MySQLインスタンスはデータ複製のため専用のリンクを介して接続されています。これはオプションですが、大容量の環境においてはこの方法を推奨します。リバースプロキシやファイアウォールを介さず、大容量のリンクで、可能であれば直接接続する必要があります。デプロイ環境の詳細については、「高可用性デプロイの設定」の「ロードバランサの要件と考慮事項」を参照してください。
運用上の注意事項
高可用性のデプロイでは、一度に1つのコントローラのみがアクティブであることが重要です。プライマリデータベースの複製コピーを維持できるよう、セカンダリではデータベースプロセスのみを実行する必要があります。
HA セカンダリ上のコントローラ アプリケーション サーバー プロセスは、必要になるまでオフのままです。2 つのアクティブなプライマリコントローラが存在する場合、HA ペア間でデータの不一致が発生する恐れがあります。
フェールオーバーが発生すると、セカンダリアプリサーバーを起動または再起動する必要があります（すでに実行中の場合は、キャッシュをクリアします）。
複製のセットアップ速度を向上させるために、サーバーは数百の MB/秒のネットワークリソースにアクセスする必要があります。複製のセットアップのパラレリズムを指定することにより、セットアップ時間を大幅に短縮できます。
たとえば、1 つの rsync が使用可能なネットワークキャパシティの 1/5 だけを使用している場合、replicate.sh コマンドの末尾に -P r5 を追加することで、セットアップの最大スループットを実現できます。このレベルのネットワークトラフィックが、進行中のコントローラ動作に干渉する場合は、この設定をモニターして調整する必要があります。
- HA ツールキットバージョン 3.54 以降を使用している場合は、
replicate.sh コマンドの末尾に -P r5 を追加します。 - Enterprise Console（バージョン 4.5.17 以降）で HA モジュールを使用している場合は、
--args numberThreadForRsync=5 を CLI に追加する必要があります。 - Enterprise Console UI から、増分または確定の [Number of parallel rsync threads] を選択します（実行しているステージによって異なります）。
HAシナリオにおけるコントローラへのエージェント接続
通常、アプリエージェントとマシンエージェントはプライマリコントローラと通信します。プライマリコントローラが使用できなくなった場合、エージェントはセカンダリコントローラと通信する必要があります。
AppDynamicsでは、上図に示すとおりエージェントとコントローラ間のリバースプロキシによってトラフィックルーティングを処理することを推奨します。これにより、フェールオーバーの発生時にエージェント構成を変更する必要性がなくなります。また、DNS メカニズムを使用してエージェントでトラフィックを切り替えることにより発生する遅延もなくなります。
プロキシを使用している場合は、以下の controller-info.xml ファイルの Java エージェント設定例のように、エージェント構成のコントローラホスト接続の値をプロキシコントローラの仮想 IP または仮想ホスト名に設定します。
.NET エージェントの場合は、コントローラ高可用性属性を config.xml で true に設定します。詳細については、.NETエージェントの構成プロパティを参照してください。
プロキシでルーティングルールの自動化を設定すると、プロキシは次のアドレスでコントローラを監視できます。
アクティブなノードは、この URL への GET リクエストに対し、HTTP 200 の応答を返します。応答本文には、<available>true</available> が含まれます。パッシブなノードは、503 Service Unavailable を返します。本文は <available>false</available> です。
詳細については、「リバースプロキシの使用」を参照してください。
