高可用性と障害復旧High Availability and Disaster Recovery

重要

このバージョンの Operations Manager はサポート終了に達したので、Operations Manager 2019 にアップグレードすることをお勧めします。This version of Operations Manager has reached the end of support, we recommend you to upgrade to Operations Manager 2019.

System Center - Operations Manager サーバーと機能は、Operations Manager 機能に影響を与え、障害が発生する可能性があります。System Center – Operations Manager servers and features can potentially fail, impacting Operations Manager functionality. エラーの際に失われるデータや機能の規模は、それぞれのエラー シナリオによって異なります。The amount of data and functionality lost during a failure is different in each failure scenario. エラーが生じた機能のロール、エラーが生じた機能の復元にかかる時間により状況は異なります。It depends on the role of the failing feature, the length of time it takes to recover the failing feature.

高可用性High availability

高可用性のニーズは、Operations Manager 操作とデータ ウェアハウス データベース、ゲートウェイと管理サーバー、および特定のワークロードの管理グループに冗長性を持たせることによって対処されます。High-availability needs are addressed by building redundancy into the management group for the Operations Manager operational and data warehouse databases, the gateway and management servers, and specific workloads. これらのワークロードには、ネットワーク デバイス監視、クロスプラットフォームの監視、および以前はルート管理サーバーによって管理されていた管理グループに固有のワークロードが含まれます。These workloads include network device monitoring, cross-platform monitoring, and management group-specific workloads that were previously managed by the Root Management Server.

複数のサーバーで、単一の管理グループの構成では、Operations Manager データベースの高可用性とサービスの継続性を提供するために、SQL Server AlwaysOn を利用できます。The multiple servers, single management group configuration can make use of SQL Server Always On for providing high availability and service continuity of the Operations Manager databases. 管理サーバーのフォールト トレランスは、少なくとも 2 つの管理サーバーを所有し、UNIX サーバー、Linux サーバー、およびネットワーク デバイスを監視するためにリソース プールを使用することによって提供されます。Management server fault-tolerance is provided by having at least two management servers and by using the resource pools for monitoring UNIX servers, Linux servers, and network devices. エージェント ベースの Windows サーバーは、管理サーバーがエラーになった場合にエージェントの通信をリダイレクトできるように、プライマリおよびセカンダリ管理サーバーで構成されることがあります。Agent-based Windows servers can be configured with a primary and secondary management server to redirect agent communications should a management server fail.

RMS エミュレーターは、別の管理サーバーに移動することができ、RMS エミュレーターをホストしている管理サーバーも無効になります。The RMS Emulator can be moved to another management server as well should the management server hosting the RMS Emulator become unavailable.

オペレーション コンソールの接続はデータ アクセス サービスに高可用性を構成することで可用性を高めることができます。Operations console connections can be made highly available by configuring high availability for the Data Access Services. Microsoft ネットワーク負荷分散 (NLB) をインストールするか、ハードウェア ベースのロード バランサー、または DNS エイリアスを使用して行われます。This can be done by installing Microsoft Network Load Balancing (NLB) or using a hardware-based load balancers, or DNS alias. 1 つ以上の管理サーバーは NLB プールのメンバーとして追加され、いずれかのコンソールを開くと、負荷分散された管理サーバーの DNS に登録されている仮想名を参照します。One or more management servers are added as members of the NLB pool and when opening either the console, you reference the virtual name registered in DNS, of the load-balanced management servers.

注意

ネットワーク ロード バランサーは、Operations Manager Web コンソール サーバーではサポートされていません。A Network Load Balancer is not supported for the Operations Manager web console server.

信頼境界に複数のゲートウェイ サーバーを展開することによって、信頼境界を越えて配置されているエージェントに冗長の通信路を提供できます。Multiple gateway servers can be deployed across a trust boundary to provide redundant pathways for agents that lie across that trust boundary. エージェントがプライマリ管理サーバーと 1 つまたは複数のセカンダリ管理サーバーの間でフェールオーバーできるように、複数のゲートウェイ サーバーもゲートウェイ サーバー間でフェールオーバーできます。Just as agents can fail over between a primary management server and one or more secondary management servers, they can also fail over between gateway servers. また、複数のゲートウェイ サーバーを使用することによって、エージェントレス型マネージド コンピューターおよび管理対象のネットワーク デバイスを管理する際の負荷を分散することもできます。In addition, multiple gateway servers can be used to distribute the workload of managing agentless-managed computers and managed network devices.

エージェントとゲートウェイのフェールオーバーによる冗長性の実現に加えて、複数の管理サーバーが使用可能な場合は、管理グループ内の管理サーバー間でゲートウェイ サーバーがフェールオーバーするように構成できます。In addition to providing redundancy through agent-gateway failover, gateway servers can be configured to fail over between management servers in a management group, if multiple management servers are available.

SQL Server Reporting Services は、1 つのレポート サーバー データベースを共有する複数のレポート サーバー インスタンスを実行できるようにする、スケール アウト展開モデルをサポートしますが、Operations Manager ではサポートされません。While SQL Server Reporting Services supports a scale-out deployment model that allows you to run multiple report server instances that share a single report server database, it is not supported with Operations Manager. Operations Manager レポートは、フロント エンド コンポーネントのセットアップの一部として、カスタム セキュリティ拡張機能をインストールします。このセットアップは、Web ファーム全体でレプリケートすることはできません。Operations Manager Reporting installs a custom security extension as part of the setup of the front-end components, which cannot be replicated across the web farm.

障害回復Disaster recovery

ディザスター リカバリーは、致命的なエラー (たとえば、プライマリ インフラストラクチャをホストするデータ センター全体の損失) の場合に操作を再開できるように、実行されるメジャーに関連しています。Disaster recovery relates to measures taken to ensure that operations can be resumed if a catastrophic failure (for example, loss of the entire data center that hosts the primary infrastructure). これは、すべての展開で検討する必要がある重要な要素であり、ディザスター リカバリーの計画における決定は、Operations Manager が重要な IT サービスのパフォーマンスと可用性おいて、予防措置としての監視やレポートをどのようにサポートし続けられるかに影響します。It is an important element that must be considered in any deployment and the decisions that are made in planning for disaster recovery affect how Operations Manager will be able to continue supporting proactive monitoring and reporting of the performance and availability of your critical IT services. このセクションでは、ディザスター リカバリーおよび回復性で推奨される戦略、および円滑に回復できるように実行する必要がある手順に注目します。This section will focus on the recommended strategy of disaster recovery and resiliency and what steps should be taken to ensure a smooth recovery.

高可用性と障害回復のソリューションは、システム障害やシステム損失からの保護を提供しますが、偶発的や悪質的なデータの損失または破損からの保護において、このソリューションに依存しないでください。While HA and DR solutions will provide protection from system failure or system loss, they should not be relied on for protection from accidental, unintended, or malicious data loss or corruption. このような場合、復元操作には、コピーされたバックアップまたは遅延しているレプリケーションのコピーを利用する必要がある可能性があります。In these cases, back up copied or lagged replication copies might have to be leveraged for restore operations. 多くの場合、復元操作が障害回復の中で最も適切です。In many cases, a restore operation is the most appropriate form of DR. この例の 1 つは、優先度の低いレポート データベースまたは分析データである可能性があります。One example of this could be a low-priority reporting database or analysis data. 多くの場合は、システムまたはアプリケーションのレベルでマルチサイトの障害回復を可能にするコストは、データの価値をはるかに上回ります。In many cases, the cost to enable multisite DR at the system or application level far outweighs the value of the data. データの短期的な価値が低い場合、および重大なビジネスへの影響がなく、データにアクセスする必要性を延ばせる場合、障害やサイトの障害回復が過剰な場合、コストの節約が正当であれば、障害回復のために単純なバックアップを使用して、プロセスを復元することを検討してください。In cases in which the near-term value of the data is low and the need to access the data can be delayed without severe business impact if a failure or site DR excessive, consider using simple backup and restore processes for DR if the cost savings warrant it.

ダウン時間の影響と許容範囲を理解することは、Operations Manager のアーキテクチャ、およびディザスター リカバリーのサポートに必要な複雑さのレベルとコストを適切に設計するために、理解する必要がある決定を促すために役立ちます。Understanding the impact and tolerance for downtime will help drive the decisions that need to be understood in order to properly design the architecture for Operations Manager and the level of complexity and cost required to support disaster recovery. また、ビジネスで損失を発生させずに、IT 組織が許容できるデータ損失の範囲も考慮してください。Additionally, consider the extent of monitoring data loss the IT organization can tolerate without causing business consequences. これは、回復時刻の目標 (RTO) と回復ポイントの目標 (RPO) の 2 つの用語で適切に示されます。This is best described in two terms: recovery time objective (RTO) and recovery point objective (RPO).

一般的な Operations Manager のディザスター リカバリーの設計構成は、次の 2 つです。The two most common disaster recovery design configurations for Operations Manager are:

  • スケールと構成内で重複するセカンダリ データ センターに展開される同じ管理グループを作成します (プライマリ管理グループ)。Creating a duplicate management group deployed to your secondary data center that duplicates in scale and configuration, the primary management group.
  • 回復操作を実行する必要があるまで管理グループに参加しない、コールド スタンバイ構成に展開された管理サーバーで、オペレーショナルおよびデータ ウェアハウス データベースをサポートするために、セカンダリ データ センターに追加のサーバーを展開します。Deploying additional servers in a secondary data center to support the Operational and Data Warehouse database, with management servers deployed in a cold-standby configuration, not participating in the management group until recovery actions need to be performed.

同じ管理グループを展開することは、ダウン時間の許容範囲がない場合のオプションですが、これは最も複雑なオプションです。Deploying a duplicate management group is an option when there is no tolerance for downtime; however, it is the most complex option. 稼働開始するときに、監視、アラートまたは報告、表示、および最後にエスカレートされた内容に違いがないように、両方の構成で一貫性を持たせる必要があります。Configuration between both needs to be consistent so that when you cut over, there is no difference in what is monitored, alerted or reported, presented, and finally escalated. その他の監視プラットフォーム、または System Center - Service Manager、Remedy、ServiceNow などの ITSM プラットフォームとの統合も存在する必要があり、インシデント、構成項目などの重複を避けるために、アクティブ/パッシブ状態で構成されている可能性があります。エージェントは両方の管理グループ間でマルチホームとなり、データの重複が起こります。Integration with other monitoring platforms or ITSM platforms such as System Center - Service Manager, Remedy or ServiceNow will need to exist as well, and possibly configured in an active/passive state to avoid duplication of incidents, configuration items, etc. Agents will be multihomed between both management groups, so there will be duplication of data.

次の図は、この設計シナリオの例です。The following diagram is an example of this design scenario.

重複する管理グループ

即時回復が Operations Manager の展開に必要なく、重複する管理グループの複雑さを回避する必要がある場合は、代わりに、管理グループの機能を保持するために、セカンダリ データ センターに追加の管理グループ コンポーネントを展開できます。If immediate recovery is not necessary for your Operations Manager deployment and you want to avoid the complexity of a duplicate management group, alternatively you can deploy additional management group components in your secondary data center in order to retain functionality of your management group. 少なくとも、2 ノード フェールオーバー クラスター インスタンス (FCI) がプライマリ データ センターに展開され、セカンダリ データセンターのスタンドアロンの SQL Server が単体の Windows Server フェールオーバー クラスターの一部として展開される場合、2 つ以上のデータ センター間のオペレーショナルおよびデータ ウェアハウス データベースの回復を提供する、SQL Server 2014 または 2016 AlwaysOn 可用性グループを実装することを検討してください。At a minimum, consider implementing a SQL Server 2014 or 2016 Always On Availability Group to provide recovery of the Operational and Data Warehouse databases between two or more datacenters, where a two-node failover cluster instance (FCI) is deployed in the primary data center, and a standalone SQL Server in the secondary datacenter as part of a single Windows Server Failover Cluster (WSFC). Always On 可用性グループのセカンダリ レプリカは、次の図に示すように FCI 以外のスタンドアロン インスタンスになります。The secondary replica for the Always On Availability Group would be on the non-FCI standalone instance as shown in the following diagram.

単純な障害回復の構成

この例では、同じハードウェア構成とコンピューター名で 1 つ以上の Windows Server を展開し、 /Recover パラメーターを使用して管理サーバーの役割を再インストールする必要があります。In this example, you would be required to deploy one or more Windows Servers with the same hardware configuration and computer name, and reinstall the management server role using the /Recover parameter. その間、エージェントは、管理グループ内の管理サーバーとの通信を再開するまで、収集されたデータ (アラート、イベント、パフォーマンスなど) をキューに入れます。During this time, agents will queue the data collected (alerts, events, performance, etc.) until they can resume communication with a management server in the management group. この手法では、SQL Server の新しいインスタンスのインストールや前回正常起動時のバックアップからデータベースを復元することを回避します。This approach avoids installing new instances of SQL Server and restoring databases from your last known good backup. ただし、この回復シナリオでは、操作可能な状態に戻るのに長い遅延が発生することが多く、最小の監視機能を再開するために必要な別の役割を展開する必要があります。However, in this recovery scenario there is likely going to be a longer delay in returning to an operable state given you will need to deploy the other roles necessary to resume minimum monitoring functionality. この手法が利用できない場合は、スタンバイ状態の回復で、セカンダリ データ センターに管理サーバーを展開することができます。If this approach isn't acceptable, you can deploy management servers in your secondary data center for on-standby recovery. これらを、3 つのプライマリ リソース プール (すべての管理サーバー リソース プール、通知、および AD 割り当て) のメンバーから削除します。Remove them as members of the three primary resources pools - All Management Servers Resource Pool, Notifications, and AD Assignment. これには、プライマリ データ センターでホストされている管理サーバーを含む場合があり、復旧計画の一部として機能し続ける必要がある、カスタム リソース プールも含まれます。This also includes any custom resource pool, which may include management servers hosted in the primary data center and need to continue to function as part of the recovery plan. System Center データ アクセス、System Center Configuration Management、および Microsoft Monitoring Agent サービスは、停止して手動に設定するか、無効にしてディザスター リカバリー シナリオでのみ開始されるようにする必要があります。The System Center Data Access, System Center Configuration Management, and Microsoft Monitoring Agent services should be stopped and set to manual or disable and only started in a disaster recovery scenario.
管理サーバーで統合をサポートしている場合 (管理サーバー上で直接、または VMM、Orchestrator または Service Manager などの別の System Center 製品からホストされているコネクタ)、統合の構成および一連の回復手順に応じて、手動または自動の回復手順を計画する必要があります。If a management server is supporting integration (via a connector hosted directly on the management server or from another System Center product such as VMM, Orchestrator or Service Manager), this will need to be planned for with manual or automatic recovery steps depending on the integration configuration and sequence of recovery steps. これにより、ディザスター リカバリーの計画が実装される必要があるときに、管理サーバーで他の依存関係がキャプチャされ計画されるようになります。This ensures any other dependency on the management server is captured and planned for when the disaster recovery plan needs to be implemented.

複雑な障害回復の構成Complex DR Config

1 つのサイトがオフラインになった場合、エージェントは別のサイトの管理サーバーにフェールオーバーされ、エージェントのフェールオーバーの構成がこれを許可すると仮定します。If one site goes offline, the agent will fail over to the management server in another site, assuming that the agent’s failover configuration allows this. 回復とレポートのみを遅延させる、セカンダリ データ センターの管理サーバーにフェールオーバーされないように管理する必要がある、プライマリ データ センターで管理サーバーのみをキャッシュするように、Windows エージェントを再構成します。Reconfigure the Windows agents to cache only management servers in your primary data center that should manage them to prevent them from attempting to failover to a management server in the secondary data center, which would only delay recovery and reporting. これは、インストール時に事前に構成するように、スクリプト (VBScript または PowerShell であればさらによい) で自動化された手法でエージェントを手動で展開する場合に実現されるか、または、エンタープライズ構成管理ソリューションで管理されたスクリプト化された手法を再度使用して、コンソールからエージェントをプッシュする場合に展開されます。This can be accomplished if you manually deploy the agent in an automated manner with a script (for example, VBScript or better yet, PowerShell) to pre-configure during installation, or post deployment if you push the agent from the console, again using a scripted method managed with your enterprise configuration management solution.

Operations Manager は、管理グループの継続性を維持するために、代わりのディザスター リカバリー オプションとして、Azure Virtual Machines に展開できます。Operations Manager can be deployed on Azure virtual machines as an alternative disaster recovery option to maintain continuity of the management group. 管理サーバーと Operations Manager データベースをホストしている SQL Server との間の遅延が、管理グループのパフォーマンスにネイティブに影響するように、ハイブリッドの構成ではなく、Azure の仮想マシンで SQL Server を展開することも必要です。It will be necessary to also deploy SQL Server on a virtual machine in Azure and not in a hybrid configuration, as the latency between a management server and the SQL Server hosting the Operations Manager databases will negatively impact performance of the management group.
Azure IaaS またはその他のパブリック クラウド プロバイダー内でこのシナリオを適切に構築するために、Microsoft Azure (サイト間 VPN または ExpressRoute) への監視範囲、ネットワーク トポロジおよびネットワーク接続、統合ポイント (ITSM ソリューション、その他の System Center 製品、サードパーティのアドインなど)、コンソールのアクセス権、規制や関連法、ポリシーなどを考慮します。Consider the monitoring scope, network topology, and network connectivity to Microsoft Azure (that is, site-to-site VPN or ExpressRoute), integration points (that is, ITSM solutions, other System Center products, third-part add-ons, etc.), console access, regulatory or relevant laws or policies, etc. in order to properly architect this scenario within Azure IaaS or other public cloud providers.