Azure 上の Red Hat Enterprise Linux におけるビジネス継続性とディザスター リカバリーに関する考慮事項
この記事では、Azure 上の Red Hat Enterprise Linux (RHEL) ベースの環境におけるビジネス継続性およびディザスター リカバリー (BCDR) への対応性を向上させる方法について説明します。 また、RHEL ワークロードのサポートと RHEL プラットフォーム管理コンポーネントのデプロイに使用できる推奨事項を示します。 Red Hat Management サブスクリプションには、1 つ以上の RHEL ランディング ゾーンでワークロードを管理するのに役立つプラットフォーム コンポーネントが含まれています。 これらのコンポーネントには、それぞれ固有の BCDR 設定があります。
設計上の考慮事項
RHEL ワークロードの回復性を向上させるには、次の点を考慮してください。
目標復旧時間
目標復旧時間 (RTO) は、災害後にシステムが元の状態に回復するまでに要する時間です。 RTO には次の時間が含まれます。
- 仮想マシン (VM) とアプリケーションの最小限の機能を復元する時間
- アプリケーションが必要とするデータを復元する時間
ビジネス用語では、RTO は、ビジネス プロセスがサービスを提供できない時間を表します。 ミッションクリティカルなワークロードでは、ビジネス プロセスを迅速に再開できるように、RTO を短くすることが理想的です。 優先度の低いワークロードでは、RTO が長くても、会社のパフォーマンスに目立った影響はない可能性があります。
目標復旧時点
クラウド環境を正常に運用するには、障害からデータを保護するためにバックアップ、レプリケーション、またはその両方を実装する必要があります。 目標復旧時点 (RPO) とは、データが最後にキャプチャされた時点を指します。 システムに障害が発生した場合、最新の復旧ポイントまでしか復元できません。
RPO は、直近の復旧ポイントから障害発生時点までの時間で測定します。 RPO を時間単位で測定する場合、システムの障害により直近の復旧ポイントから障害発生時点までの数時間分のデータが失われます。 RPO を日単位で測定する場合、システムの障害により直近の復旧ポイントから障害発生時点までの数日分のデータが失われます。 1 日の RPO の場合、理論的には、当日の障害が発生する時点までのすべてのトランザクションが失われます。
ミッションクリティカルなシステムでは、収益や利益の損失を避けるために、RPO を分単位または秒単位で測定する必要があります。 短い RPO は一般的に管理コストの増加につながります。 これらのコストを削減するには、最長許容 RPO に焦点を当てた管理ベースラインを作成するとよいでしょう。 その後に、より多くの投資が必要な特定のプラットフォームまたはワークロードの RPO を短縮できます。
ワークロードの BCDR に関する考慮事項
RHEL ベースのワークロードに関する高可用性とディザスター リカバリーの設計上の考慮事項は、それらのワークロードをサポートする技術によって異なります。 多くの最新のワークロードには、可用性ゾーンやリージョン間で冗長性を確保するネイティブの Azure サービスを活用できます。 Azure サービスを使用して、データ レプリケーションの管理、可用性セットの自動スケール、更新ドメインと障害ドメインの制御を行います。 これらのプラクティスにより、RHEL デプロイの可用性を確保しやすくなります。
データベース ソリューションやその他のステートフル アプリケーションでは、高可用性とディザスター リカバリーを実現するためにオペレーティング システム中心のソリューションが必要になる場合があります。 アプリケーションがサポートするソリューションについては、アプリケーション開発者またはベンダーに相談してください。 詳細については、「IaaS アプリの高可用性とディザスター リカバリー」を参照してください。
| Azure の機能またはサービス | Definition | 考慮事項 |
|---|---|---|
| 地域 | ネットワーク遅延を少なくするために、互いに近接して配置されたデータセンターのグループ。 高速なデータ転送を実現するために、特定のリージョン ネットワークがデータセンターを結んでいます。 | Azure リージョンを選択する際は、データセンター、ユーザー、バックエンドデータの場所を考慮してください。 選択したリージョンで必要なサービスが利用可能かどうかを確認します。 RHEL デプロイでは、1 つのリージョンから始め、後で BCDR の目的でリージョンを追加できます。 |
| Azure ExpressRoute | Microsoft のデータセンターから自社のインフラストラクチャやコロケーション施設へのプライベート接続を確立するために使用できる Azure サービス。 | ExpressRoute はパブリック インターネットをバイパスし、専用のプライベート接続を提供します。 この構成は、大規模な RHEL デプロイでは一般的な要件です。 ExpressRoute は共有サービスであるため、企業全体の帯域幅のニーズを満たすように、帯域幅の容量を慎重に計画する必要があります。 帯域幅が不十分な場合、ユーザー エクスペリエンスやデータセンターの重要なサービスへのアクセスが損なわれる可能性があります。 リージョンやピアリング ロケーション間で ExpressRoute を回復力のある方法でデプロイするようにしてください。 |
| 可用性ゾーン | Azure リージョン内で独自の電源、冷却、ネットワーク システムを備えたデータセンターの独立したグループ。 可用性ゾーンはデータセンターの障害に対する高可用性と回復力をもたらします。 | 高レベルのサービス レベル契約 (SLA) を維持するために、可能な限り RHEL インフラストラクチャで可用性ゾーンを使用してください。 可用性ゾーンはリージョン内でデータセンターの冗長性を確保します。 ただし、すべてのリージョンに可用性ゾーンがあるわけではないので、慎重に計画する必要があります。 Azure Red Hat OpenShift やランディング ゾーン管理サービスなどの RHEL サービスは、可用性ゾーンをサポートしています。 |
| 可用性セット | VM の論理グループ。 計画的または計画外のメンテナンス イベント中に、少なくとも 1 つの VM が常に稼働しています。 障害ドメインは、電源やネットワークなどの共通の物理インフラストラクチャを共有する可用性セットのサブセットです。 異なる障害ドメインに VM を分散させる場合、可用性セットにより、ハードウェア障害が VM の可用性に与える影響が軽減されます。 | 可用性セットにより高い SLA が提供されます。 可用性セットは、リージョンに可用性ゾーンがない場合の RHEL インフラストラクチャに適しています。 可用性セットはハードウェアの冗長性のみを確保し、これはハイパーバイザーのアンチアフィニティ規則に似ています。 したがって、リージョンに可用性ゾーンがない場合は、データセンターと地理的冗長性のためにマルチリージョン戦略が必要です。 |
| Azure Load Balancer | ネットワーク負荷分散サービス。 Load Balancer を構成して、複数の Red Hat Enterprise サーバー間で大量のネットワーク トラフィックを効率的に処理できます。 このサービスは、低遅延と高スループットで動作するため、アプリケーションのパフォーマンスと可用性が向上します。 Load Balancer は需要に応じて自動的にスケールできます。 アプリケーションのハイブリッド デプロイを促進するために、Load Balancer は Azure 内の複数のリージョン間、およびオンプレミス環境と Azure 間でネットワーク トラフィックを分散できます。 |
Load Balancer は、複数のサーバー間でネットワーク トラフィックを分散することで、アプリケーションの可用性を中断することなく維持し、単一障害点を防止します。 障害が発生した場合、Load Balancer は稼働中のサーバーにトラフィックをリダイレクトして、迅速なフェールオーバーと復旧を実現します。 この操作により、ダウンタイムが最小限に抑えられ、ビジネスの運用が維持されます。 Load Balancer は、オンプレミス サーバーから Azure クラウドへ、または複数の Azure リージョン内のサーバー間でトラフィックのバランスをとることができます。 詳細については、「負荷分散のオプション」を参照してください。 |
| マネージド ディスク | Azure が管理する仮想化ディスク。 ディスクのサイズとタイプを選択できます。 Azure は、さまざまなストレージ ユニットにディスクを分散して、ハードウェア障害からデータを保護します。 | マネージド ディスクは、すべての RHEL インフラストラクチャに最適な選択肢です。 アンマネージド ディスクは使用しないでください。 詳細については、「VM の SLA」を参照してください。 ディスクのタイプによって、パフォーマンスとコストが異なります。 RHEL インフラストラクチャ マシンには Azure Premium SSD をお勧めします。 ディスクのタイプを選択する際は、コスト、パフォーマンス、可用性を考慮してください。 システムを割り当て解除すると、ローカル SSD とエフェメラル ディスクは削除されます。 必要に応じて、これらのディスク上のデータをバックアップしてください。 |
| Azure Backup | データをバックアップし、Azure クラウドから復旧するためのコスト効率の高いソリューションを提供するサービス。 | Backup は、VM の障害や破損から RHEL インフラストラクチャを保護する信頼性の高い費用対効果の高いソリューションです。 Backup を使用すると、VM を再作成したりデータを失ったりすることなく、クラウドから簡単に VM 全体または特定のファイルやフォルダーを復元できます。 サポートされている他のパートナー ソリューションも使用できます。 |
| Azure Arc | データセンター、エッジ デバイス、マルチクラウド アーキテクチャなど、多様な環境全体で Azure サービスを実行できるようにするプラットフォーム。 Azure Arc を使用して、アプリケーションとサービスの一貫した開発、運用、セキュリティ管理を行います。 | Azure Arc を使用して、自動バックアップと監視を一元化することで、BCDR の観点から回復性が向上します。 |
| Azure Site Recovery | ビジネス継続性を確保するためのディザスター リカバリー機能を提供するサービス。 Azure VM やオンプレミス VM を含むワークロードを異なるリージョン間でレプリケートおよび管理できます。 Site Recovery を使用すると、計画的および計画外の停止時にアプリケーションを保護するためのレプリケーション、フェールオーバー、復旧プロセスを設定できます。 | Site Recovery の使用により、復旧の問題を最小限に抑え、インフラストラクチャのコストを削減します。また、Azure リージョン間またはオンプレミスの場所から Azure への復旧が安全で信頼性の高いものになります。 |
| リソース ロック | 組織内のユーザーやロールを制限するために使用できる Azure の機能です。 重要なリソースを誤った変更や悪意のある変更から保護します。 サブスクリプション、リソース グループ、リソース単体のレベルなど、さまざまなスコープ レベルでリソースをロックできます。 ロックのタイプによっては、ユーザーによるリソースの削除または変更を禁止できますが、ユーザーはその構成を読み取ることはできます。 | すべての RHEL インフラストラクチャとゴールデン イメージ VM を保護するには、リソース ロックを使用してください。 重要なマシンには、誤った損失を防ぐために、少なくとも Delete ロックを適用してください。 RHEL インフラストラクチャ マシンには、ReadOnly ロックを適用してください。そのようなマシンは頻繁に変更されることがないためです。 変更は適切な変更管理ウィンドウ中にのみ行ってください。 |
RHEL プラットフォームの BCDR に関する考慮事項
RHEL プラットフォーム インフラストラクチャの BCDR 機能の詳細については、以下を参照してください。
設計の推奨事項
Linux コンテナー内のクラウドネイティブ アプリケーションには、スケーラビリティ、高可用性、冗長性を確保するために Kubernetes ベースのプラットフォームを使用してください。 Azure Red Hat OpenShift プラットフォーム、またはレプリケートされたストレージか geo レプリケートされたストレージを使用したセルフマネージド OpenShift デプロイの利用を考慮してください。
ネイティブ Web アプリケーション フロント エンドやステートレス アプリケーションには、アプリケーションの可用性を確保する多くの Azure ネイティブ サービスを使用できます。 そのようなサービスを使用するアーキテクチャについては、以下を参照してください。
これらのアーキテクチャでは、可用性ゾーンにさまざまな Azure サービスが使用されています。 マルチリージョン アーキテクチャでは、コンテンツに geo レプリケーション機能が使用され、負荷分散サービスとして Azure Front Door が使用されています。
高可用性を必要とする多くの従来のステートフル アプリケーションでは、RHEL から Pacemaker 高可用性アドオンが提供されています。 この機能を備えたシステムを Azure Marketplace から入手するか、必要なソフトウェア コンポーネントが組み込まれたカスタム イメージをデプロイすることもできます。 詳細については、「Microsoft Azure 上で Red Hat 高可用性クラスターを構成する」を参照してください。
可用性の問題はサービスの停止とサービスの応答時間に影響します。 サービスの品質が低下して、顧客のサービス エクスペリエンスが低下する可能性があります。 必要なリージョン内で適切なパフォーマンス レベルと十分な容量を確保するために、Azure のオンデマンド容量予約機能を使用してください。
信頼性
サービスとしてのインフラストラクチャ (IaaS) VM インフラストラクチャに適用される多くの概念は RHEL アーキテクチャにも適用されます。 詳細については、「信頼性の設計原則」を参照してください。
クラスター
Azure では、単一の RHEL Pacemaker クラスター内で Application Server Central Services とデータベースの高可用性を組み合わせることはサポートされていません。 この制限に対処するには、それらを個別のクラスターに分離してください。 最大 5 つの Central Services クラスターを 1 組の VM で組み合わせることができます。
SAP の BCDR には、SAP Central Services クラスターを実行するために次のサービスを考慮してください。
- RHEL Pacemaker クラスター: STONITH ブロック デバイスはサポートされていませんが、Azure フェンス エージェントを使用できます。
- SAP 認定の Microsoft 以外のクラスター ソフトウェア: ニーズに合致する場合は、このオプションを検討してください。
特定のニーズとオペレーティング システムに基づいて、適切なサービスを選択してください。
詳細については、以下を参照してください:
Azure Compute Gallery のレプリカ
Compute Gallery を使用して、デプロイ用のゴールデン イメージを保存できます。 これらのイメージを使用して、アプリケーションとツールのディザスター リカバリーを行うことができます。 Compute Gallery では、可用性ゾーンをサポートするリージョンで、ゾーン冗長ストレージ (ZRS) アカウントを使用して高可用性リソースを準備できます。 ZRS により、ゾーンの障害に対する回復性を得られます。 また、Gallery のイメージを他のリージョンや地理的位置にレプリケートすることもできます。
Note
少なくとも 2 つの Gallery をそれぞれ異なるリージョンに用意することをお勧めします。
Site Recovery
Site Recovery を使用すると、一部の RHEL コンポーネントの回復性を高めることができます。 サポートされている RHEL Site Recovery サーバーの一覧については、「Site Recovery による Azure VM ディザスター リカバリーのサポート マトリックス」を参照してください。 また、オンプレミス環境からクラウドへのフェールオーバーとして Site Recovery を設定することもできます。 Site Recovery のコストを見積もるには、Site Recovery Deployment Planner を使用してください。
復旧クラスター ノード
RTO を短縮し、回復性を高めるために、アクティブまたはスタンバイのリモート復旧クラスター ノードを使用できます。 ディザスター リカバリー クラスターの項目は手動で構成する必要があります。 たとえば、リソースを設定し、データをコピーするためには、そのための構成を適用する必要があります。