次の方法で共有

高可用性とディザスター リカバリー

  • [アーティクル]

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

高可用性

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

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

RMS エミュレーターをホストしている管理サーバーが使用できなくなった場合でも、RMS エミュレーターを別の管理サーバーに移動できます。

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

Note

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

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

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

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

障害復旧

ディザスター リカバリーは、致命的な障害 (プライマリ インフラストラクチャをホストするデータ センター全体の損失など) の発生時にオペレーションを再開するための対策に関連しています。 これは、あらゆる展開で考慮する必要がある重要な要素であり、ディザスター リカバリーの計画での判断は、Operations Manager が、ユーザーが使用している重要な IT サービスのパフォーマンスと可用性に対するプロアクティブな監視およびレポート作成を引き続きサポートする方法に影響します。 このセクションでは、ディザスター リカバリーおよび回復性に関する推奨戦略に焦点を当てるとともに、円滑な復旧を確保する上で実行する必要のある手順にも焦点を当てて説明します。

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

ダウンタイムに対する影響と許容度を理解することは、Operations Manager のアーキテクチャと、ディザスター リカバリーをサポートするために必要な複雑さとコストのレベルを適切に設計するために理解する必要がある決定を促進するのに役立ちます。 さらに、IT 組織がビジネス上の結果を引き起こさずに許容できる監視データ損失の程度を考慮してください。 これは、目標復旧時間 (RTO) と目標復旧時点 (RPO) の 2 つの用語で最もよく説明されています。

Operations Manager で最も一般的なディザスター リカバリー デザイン構成には、次の 2 つがあります。

  • スケールと構成内で重複するセカンダリ データ センターに展開される同じ管理グループを作成します (プライマリ管理グループ)。
  • 運用とデータのウェアハウス データベースをサポートする際、セカンダリ データ センター内に追加サーバーを展開し、管理サーバーをコールド スタンバイ構成内に展開します。復旧アクションを実行する必要があるまでは、管理グループに参加しません。

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

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

重複する NSG の図。

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

単純な DR 構成の図。

この例では、同じハードウェア構成とコンピューター名を持つ 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 Data Access、System Center Configuration Management、および Microsoft Monitoring Agent サービスを停止し、手動または無効に設定し、ディザスター リカバリー シナリオでのみ開始する必要があります。

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

複雑な DR 構成の図。

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

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

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