高可用性と障害復旧

重要

このバージョンの Operations Manager はサポート終了に達しました。 Operations Manager 2022 にアップグレードすることをお勧めします。

System Center – Operations Manager のサーバーと機能が失敗し、Operations Manager の機能に影響を与える可能性があります。 エラーの際に失われるデータや機能の規模は、それぞれのエラー シナリオによって異なります。 失敗した機能の役割と、障害が発生した機能の回復にかかる時間によって異なります。

高可用性

高可用性のニーズは、Operations Manager 操作とデータ ウェアハウス データベース、ゲートウェイと管理サーバー、および特定のワークロードの管理グループに冗長性を持たせることによって対処されます。 これらのワークロードには、ネットワーク デバイス監視、クロスプラットフォームの監視、および以前はルート管理サーバーによって管理されていた管理グループに固有のワークロードが含まれます。

複数のサーバーで、単一の管理グループの構成では、Operations Manager データベースの高可用性とサービスの継続性を提供するために、SQL Server AlwaysOn を利用できます。 管理サーバーのフォールト トレランスは、少なくとも 2 つの管理サーバーを所有し、UNIX サーバー、Linux サーバー、およびネットワーク デバイスを監視するためにリソース プールを使用することによって提供されます。 エージェント ベースの Windows サーバーは、管理サーバーがエラーになった場合にエージェントの通信をリダイレクトできるように、プライマリおよびセカンダリ管理サーバーで構成されることがあります。

RMS エミュレーターは、別の管理サーバーに移動することができ、RMS エミュレーターをホストしている管理サーバーも無効になります。

オペレーション コンソールの接続はデータ アクセス サービスに高可用性を構成することで可用性を高めることができます。 これを行うには、Microsoft ネットワーク負荷分散 (NLB) をインストールするか、ハードウェア ベースのロード バランサーまたは DNS エイリアスを使用します。 1 つ以上の管理サーバーは NLB プールのメンバーとして追加され、いずれかのコンソールを開くと、負荷分散された管理サーバーの DNS に登録されている仮想名を参照します。

Note

ネットワーク Load Balancerは、Operations Manager Web コンソール サーバーではサポートされていません。

信頼境界に複数のゲートウェイ サーバーを展開することによって、信頼境界を越えて配置されているエージェントに冗長の通信路を提供できます。 エージェントがプライマリ管理サーバーと 1 つまたは複数のセカンダリ管理サーバーの間でフェールオーバーできるように、複数のゲートウェイ サーバーもゲートウェイ サーバー間でフェールオーバーできます。 また、複数のゲートウェイ サーバーを使用することによって、エージェントレス型マネージド コンピューターおよび管理対象のネットワーク デバイスを管理する際の負荷を分散することもできます。

エージェントとゲートウェイのフェールオーバーによる冗長性の実現に加えて、複数の管理サーバーが使用可能な場合は、管理グループ内の管理サーバー間でゲートウェイ サーバーがフェールオーバーするように構成できます。

SQL Server Reporting Servicesでは、1 つのレポート サーバー データベースを共有する複数のレポート サーバー インスタンスを実行できるスケールアウト 配置モデルがサポートされていますが、Operations Manager ではサポートされていません。 Operations Manager Reporting では、フロントエンド コンポーネントのセットアップの一環としてカスタム セキュリティ拡張機能がインストールされます。これは、Web ファーム間でレプリケートすることはできません。

障害復旧

ディザスター リカバリーは、致命的なエラー (たとえば、プライマリ インフラストラクチャをホストするデータ センター全体の損失) の場合に操作を再開できるように、実行されるメジャーに関連しています。 これは、展開で考慮する必要がある重要な要素であり、ディザスター リカバリーの計画で行われる決定は、重要な IT サービスのパフォーマンスと可用性に関する積極的な監視とレポートを Operations Manager が引き続きサポートする方法に影響します。 このセクションでは、ディザスター リカバリーおよび回復性で推奨される戦略、および円滑に回復できるように実行する必要がある手順に注目します。

HA および DR ソリューションは、システム障害やシステム損失からの保護を提供しますが、偶発的、意図しない、または悪意のあるデータの損失や破損からの保護に依存しないようにする必要があります。 このような場合は、バックアップ コピーまたは遅延レプリケーション コピーを復元操作に使用する必要があります。 多くの場合、復元操作が障害回復の中で最も適切です。 この例の 1 つは、優先度の低いレポート データベースまたは分析データである可能性があります。 多くの場合は、システムまたはアプリケーションのレベルでマルチサイトの障害回復を可能にするコストは、データの価値をはるかに上回ります。 データの短期的な価値が低い場合、および重大なビジネスへの影響がなく、データにアクセスする必要性を延ばせる場合、障害やサイトの障害回復が過剰な場合、コストの節約が正当であれば、障害回復のために単純なバックアップを使用して、プロセスを復元することを検討してください。

ダウン時間の影響と許容範囲を理解することは、Operations Manager のアーキテクチャ、およびディザスター リカバリーのサポートに必要な複雑さのレベルとコストを適切に設計するために、理解する必要がある決定を促すために役立ちます。 また、ビジネスで損失を発生させずに、IT 組織が許容できるデータ損失の範囲も考慮してください。 これは、回復時刻の目標 (RTO) と回復ポイントの目標 (RPO) の 2 つの用語で適切に示されます。

一般的な Operations Manager のディザスター リカバリーの設計構成は、次の 2 つです。

• プライマリ管理グループをスケールおよび構成で複製する、セカンダリ データ センターにデプロイされた重複する管理グループの作成。
• 回復操作を実行する必要があるまで管理グループに参加しない、コールド スタンバイ構成に展開された管理サーバーで、オペレーショナルおよびデータ ウェアハウス データベースをサポートするために、セカンダリ データ センターに追加のサーバーを展開します。

重複する管理グループの展開は、ダウンタイムに対する許容度がない場合のオプションです。ただし、これは最も複雑なオプションです。 両方の構成は一貫している必要があります。そのため、切り替えるときに、監視、アラート、報告、表示、および最終的にエスカレートされる内容に違いはありません。 System Center - Service Manager、Remedy、ServiceNow などの他の監視プラットフォームまたは ITSM プラットフォームとの統合も必要であり、インシデントや構成項目の重複を避けるために、アクティブ/パッシブ状態で構成される可能性があります。 エージェントは両方の管理グループ間でマルチホームとなり、データの重複が起こります。

次の図は、この設計シナリオの例です。

Operations Manager の展開に即時復旧が必要ない場合に、重複する管理グループの複雑さを回避したい場合は、管理グループの機能を保持するために、セカンダリ データ センターに追加の管理グループ コンポーネントを展開することもできます。 少なくとも、2 ノード フェールオーバー クラスター インスタンス (FCI) がプライマリ データ センターに展開され、セカンダリ データセンターのスタンドアロンの SQL Server が単体の Windows Server フェールオーバー クラスターの一部として展開される場合、2 つ以上のデータ センター間のオペレーショナルおよびデータ ウェアハウス データベースの回復を提供する、SQL Server 2014 または 2016 AlwaysOn 可用性グループを実装することを検討してください。 Always On 可用性グループのセカンダリ レプリカは、次の図に示すように FCI 以外のスタンドアロン インスタンスになります。

この例では、同じハードウェア構成とコンピューター名で 1 つ以上の Windows Server を展開し、/Recover パラメーターを使用して管理サーバーの役割を再インストールする必要があります。 サンプルを次に示します。

Setup.exe /silent /AcceptEndUserLicenseAgreement:1 /recover /InstallPath:<Install Directory> /ManagementGroupName:MGNAME /SqlServerInstance:SQLServerName.domain.com /DatabaseName:OperationsManager /DWSqlServerInstance:SQLServerName.domain.com /DWDatabaseName:OperationsManagerDW /ActionAccountUser:DOMAIN\omaa /ActionAccountPassword:password /DASAccountUser:DOMAIN\omdas /DASAccountPassword:password /DatareaderUser:DOMAIN\omdr /DatareaderPassword:password /DataWriterUser:DOMAIN\omdw /DataWriterPassword:password /EnableErrorReporting:Always /SendCEIPReports:1 /UseMicrosoftUpdate:0

詳細については、「コマンド プロンプトから Operations Manager をインストールする」を参照してください。

この間、エージェントは、管理グループ内の管理サーバーとの通信を再開できるようになるまで、収集されたデータ (アラート、イベント、パフォーマンスなど) をキューに入れます。 この手法では、SQL Server の新しいインスタンスのインストールや前回正常起動時のバックアップからデータベースを復元することを回避します。 ただし、この復旧シナリオでは、最小限の監視機能を再開するために必要な他のロールをデプロイする必要があるため、操作可能な状態に戻るのにより長い遅延が発生する可能性があります。 この手法が利用できない場合は、スタンバイ状態の回復で、セカンダリ データ センターに管理サーバーを展開することができます。 これらを、3 つのプライマリ リソース プール (すべての管理サーバー リソース プール、通知、および AD 割り当て) のメンバーから削除します。 これには、プライマリ データ センターでホストされている管理サーバーを含む場合があり、復旧計画の一部として機能し続ける必要がある、カスタム リソース プールも含まれます。 System Center データ アクセス、System Center Configuration Management、および Microsoft Monitoring Agent サービスは、停止して手動に設定するか、無効にしてディザスター リカバリー シナリオでのみ開始されるようにする必要があります。

管理サーバーが統合をサポートしている場合 (管理サーバー上で直接ホストされているコネクタ、または VMM、Orchestrator、またはService Managerなどの別の System Center 製品を介して)、統合の構成と復旧手順のシーケンスに応じて、手動または自動の復旧手順を使用してこれを計画する必要があります。 これにより、ディザスター リカバリーの計画が実装される必要があるときに、管理サーバーで他の依存関係がキャプチャされ計画されるようになります。

1 つのサイトがオフラインになった場合、エージェントは別のサイトの管理サーバーにフェールオーバーされ、エージェントのフェールオーバーの構成がこれを許可すると仮定します。 回復とレポートのみを遅延させる、セカンダリ データ センターの管理サーバーにフェールオーバーされないように管理する必要がある、プライマリ データ センターで管理サーバーのみをキャッシュするように、Windows エージェントを再構成します。 これは、インストール時に事前に構成するスクリプト (VBScript など)、または展開後にコンソールからエージェントをプッシュする場合に、エンタープライズ構成管理ソリューションで管理されているスクリプト化された方法を再度使用して、自動化された方法でエージェントを手動でデプロイする場合に実現できます。

Operations Manager は、管理グループの継続性を維持するために、代わりのディザスター リカバリー オプションとして、Azure Virtual Machines に展開できます。 また、管理サーバーと Operations Manager データベースをホストするSQL Serverの間の待機時間が管理グループのパフォーマンスに悪影響を及ぼすため、ハイブリッド構成ではなく、Azure の仮想マシンにSQL Serverをデプロイする必要もあります。

Azure IaaS またはその他のパブリック クラウド プロバイダー内でこのシナリオを適切に設計するために、Microsoft Azure への監視スコープ、ネットワーク トポロジ、およびネットワーク接続 (つまり、サイト間 VPN または ExpressRoute)、統合ポイント (ITSM ソリューション、その他の System Center 製品、第 3 部のアドオンなど)、コンソール アクセス、規制または関連する法律またはポリシーなどを検討します。