Translated message

A translation of this page exists in English.

RHEL High Availability クラスターの設計ガイダンス - クラスターメンバーとしての VMware 仮想マシン

更新 -

目次

概要

該当する環境

  • Red Hat Enterprise Linux (RHEL) 7、8 (High Availability Add-On 使用)
  • 仮想マシンのホスティングに VMware プラットフォームを使用
  • 注記: このガイドでは、これらの製品の最新リリースに適用される機能に焦点を当てている場合があります。

役に立つリファレンスおよびガイド

はじめに

この記事では、VMware 仮想マシン上で実行される RHEL High Availability クラスターの設計に役立つと考えられる Red Hat の推奨事項、参考資料、および考慮事項を管理者に紹介します。

仮想化/ホスト管理

仮想化管理の推奨事項: vSphere + vCenter Server を使用

理由:

  • ホストクラスターと VM クラスターの信頼性を高めるためのいくつかの機能を提供します。詳細は、以下の追加機能の推奨事項を参照してください。
  • vSphere Hypervisor を使用したホストの手動管理と比較すると、新しいホストでの VM の迅速な回復や障害が発生したホストの検出など、障害状況への対応がより簡単かつ迅速になります。
  • Red Hat は、RHEL High Availability の開発とテストにおける vCenter Server の設定と機能に重点を置いています。

仮想化管理の代替戦略: vSphere Hypervisor (ESXi) の手動管理

考慮事項:

  • fence_vmware_soap STONITH メソッドの信頼性は各ホストと同じ程度です。ホストが使用できなくなったり応答しなくなったりすると、他の VM はこのメソッドを使用して欠落しているピアをフェンスすることができなくなり、クラスター操作がブロックします。
  • VM クラスターは、ホストの電源をセカンダリー STONITH メソッドとして使用するように設定できます。これは、ホストが応答しなくなった場合に、ホストを介して欠落しているピアをフェンスできるようにするためです。
  • vCenter Server を使用しないと、障害が発生した VM の手動リカバリーが遅くなり、VM クラスターのメンバーシップはより長い間、パフォーマンスが低下したままになる可能性があります。ホスト障害後に十分なメンバーで動作するのに十分な容量を持つ VM クラスターを設計します。

仮想化管理の代替戦略: vRealize Suite

考慮事項:

  • Red Hat は、vCenter Server または vSphere Hypervisor の手動管理の代替として、VM の RHEL High Availability クラスターを管理するための vRealize Suite の適合性を評価していません。
  • RHEL High Availability は、vRealize Suite を対象とした特別な機能や STONITH メソッドを提供しません。環境は、RHEL HA の一般的な VMware を対象とした機能 (STONITH 用の fence_vmware_soap や fence_scsi など) と互換性がある必要があります。

vCenter Server に関する推奨事項: 高可用性 vCenter Server

詳細:

  • vCenter Server に高可用性を提供します。kb.vmware.com - Supported vCenter Server High Availability Options を参照してください。
  • 信頼性を最大限に高めるには、マルチサイトの高可用性 vCenter Server と VM をマルチサイト RHEL High Availability クラスターに提供します。以下の RHEL High Availability 設定 セクションのマルチサイトに関する考慮事項を参照してください。

理由:

  • 高可用性の vCenter サーバーにより、fence_vmware_soap STONITH メソッドの信頼性が向上します。
  • 高可用性の vCenter は、障害発生後もホストおよび VM 管理への管理者アクセスを維持します。このような期間中、このアクセスは、その障害の影響を受けた RHEL High Availability マシンを回復または管理する上で重要となる可能性があります。

vCenter Server に関する推奨事項: vSphere HA

詳細:

  • Enable host monitoring

理由:

  • ホスト監視を備えた vSphere HA により、fence_vmware_soap STONITH メソッドの信頼性が向上します。
  • ホスト監視を備えた DRS および vSphere HA は、VM を迅速に回復させ、VM クラスターのパフォーマンスが障害後に低下したままになることを防ぎます。

vCenter Server に関する推奨事項: vSphere DRS クラスターの作成

詳細:

  • DRS Automation Level: Manual または Partially Automated を使用します。Fully Automated は使用しないでください。

理由:

  • + DRS VM-host アフィニティーで実行するように VM に複数のホストを提供すると、VM クラスターをパフォーマンスが低下したメンバーシップに残す代わりに、ホストの障害後に新しい場所へ VM を迅速に回復できます。

仮想化ホストに関する考慮事項: ホストの数

推奨事項: クラスター化された VM ごとに個別のホストを提供し、フェイルオーバー/メンテナンスアクティビティー用として、もう 1 つ利用できるようにします。

  • 単一ホストの障害が VM クラスターに及ぼす影響は、最小限に留めてください。
  • 追加のフェイルオーバーホストを使用すると、ホストの停止が長引いた場合でも、ホスト上の VM を二重化する必要がなく、ホストの障害後に VM は迅速に回復できます。

代替設定: クラスター化された VM の 50% 以上を持つホストが存在しないように、十分なホストを提供します。

  • VM の 50% がホストを共有している場合、単一ホストに障害が発生すると、クラスターの大部分を利用できなくなる可能性があります。

代替設定: 提供するホストを 2 つのみにするか、50% 以上の VM がホストを共有できるようにします。

  • クラスターの回復/再開のための手動介入が許容され、重要度が高くないワークロードの場合にのみ、この設定に依存してください。
  • アクティブなメンバーシップが 50% 以下でもクラスターが存続するようにするには、lms アルゴリズムを備えた RHEL HA クラスター設定で qdevice を使用します。詳細は、以下のクラスター設計セクションを参照してください。

非推奨: 単一ホスト設計は、テスト/開発の目的でのみ使用します。

仮想化ホストの推奨事項: ホストインフラストラクチャーの冗長性

詳細:

  • 電源、サーバーラックスイッチなどの個別のインフラストラクチャーによってサポートされるようにホストを設計します。
  • 信頼性をさらに高めるために、ホストをさまざまなファシリティーまたはサイトに分散させます。
    • ホストがサイト全体に分散している場合は、以下のセクションで RHEL HA クラスターのマルチサイト設計と考慮事項を確認してください。

理由:

  • ホストが電源またはネットワークハードウェアを共有すると、単一障害点が発生し、すべての RHEL HA メンバーが中断され、マネージドアプリケーションが停止する可能性があります。

ホスト環境設計の推奨事項: ネットワークの冗長性

詳細:

  • クラスターメンバーの相互接続ネットワーク、アプリケーションネットワーク、および vCenter Server/vSphere Hypervisor (fence_vmware_soap を使用) へのアクセスに使用されるネットワークのそれぞれに対して、vSwitch への冗長なアップリンクポートを提供します。
  • クラスターメンバーの相互接続ネットワークの場合は、代わりにセカンダリーネットワークを提供し、RHEL HA の RRP 機能である冗長なリングプロトコルと併用することもできます。

理由:

  • クラスターのメンバーシップ相互接続リンクの冗長性は、アプリケーションの停止や回復を引き起こす可能性があるメンバーシップの中断や分割を回避するために重要です。
  • fence_vmware_soap STONITH メソッドを使用する場合、メンバーが使用できなくなった場合に回復がブロックされないように、vCenter Server または vSphere Hypervisor へのアクセスを維持する必要があります。
  • アプリケーション/クライアントアクセスネットワークが失われると、ユーザーがクラスターのサービスにアクセスできなくなる可能性があります。

仮想化ホスト設定に関する考慮事項: クラスター転送プロトコル

考慮事項:

  • RHEL HA トランスポートプロトコルが異なれば、ネットワークのニーズも異なります。クラスターに最適なものを選択し、そのクラスターのホストネットワーク設定を検討してください。Exploring RHEL High Availability's Components, Concepts, and Features - Overview of Transport Protocols および Design Guidance for RHEL High Availability Clusters - Selecting the Transport Protocol を参照してください。
  • UDP トランスポートを使用しており、ネットワーク上でマルチキャスト機能が必要な場合は、VMware マルチキャストフィルタリングモードを検討してください。docs.vmware.com - Multicast Filtering Modes を参照してください。
    • 基本マルチキャスト: 物理ネットワークに適切なマルチキャスト転送機能がある場合、これは High Availability クラスターで機能するはずです。
    • マルチキャストスヌーピング: ESXi ホスト間の物理スイッチでは、IGMP スヌーピングを有効にする必要があります。vSphere のクエリー時間間隔が、物理スイッチ上のルーティングテーブルのタイムアウトよりも短く設定されていることを確認してください。

仮想マシンの設定

VM 分散の推奨事項: できるだけ多くの利用可能なホストに VM を分散する

詳細:

  • vCenter Server の場合: DRS VM-host アフィニティーを使用してホスト間で VM を分散し、フェイルオーバー後も引き続き VM を分離したままにしようとする 2 番目の優先ホストを提供します。
  • 他の管理戦略の場合: VM をホスト全体に分散し、ホストまたは VM に障害が発生した場合に通知を受ける計画と、VM をどこでどのように回復するかを計画します。

理由:

  • 同じホスト上で VM を実行すると、単一ホストの障害によってクラスターが複数のメンバーを失う危険にさらされます。
  • VM をホスト全体に分散すると、大規模な中断を引き起こす単一障害からクラスターが保護されます。

VM 管理要件: VM がクラスター内でアクティブな間は、ライブマイグレーションを実行しない

詳細:

  • Support policies - General conditions with virtualized cluster members を参照してください。
  • DRS VM-host アフィニティーを (上記の推奨事項のように) 使用する場合、ライブマイグレーションは阻止されます。
  • ホスト間での VM 分散を手動で管理する場合、または DRS VM-host アフィニティーを使用しない場合は、VM がアクティブな間に、ポリシーとプラクティスがライブマイグレーションを阻止することを確認してください。VM を移行する前に、必ず RHEL HA クラスターサービス (pcs cluster stop) を停止してください。

理由:

  • ライブマイグレーションにより VM の処理が一時停止され、High Availability メンバーシップが中断される可能性があります (実際の実稼働環境で確認されることが多いです)。この一時停止は予測不可能であり、これを確実に回避するように HA を設定することは困難です。
  • vMotion によるライブマイグレーションでは、新しいホストで VM のマルチキャストグループ登録を更新するために特別な手段が講じられます。Red Hat は、これらの手段と RHEL High Availability の udp (マルチキャスト) トランスポートプロトコルに互換性があるかを判断するための評価を行っていません。
  • ライブマイグレーションが原因で、クラスター内の静的 STONITH 設定のホスト <-> VM マッピングが正しくなくなる可能性があります。移行の前後に STONITH 設定を更新する計画がある場合でも、移行のフロントエンドまたはバックエンドで STONITH 設定が正しくない期間が発生し、VM が応答しなくなった場合に STONITH が失敗する可能性があり、クラスター操作がブロックされる可能性があります。

VM リソース設定に関する考慮事項: ストレージデバイス

考慮事項:

  • Support policies - VMware virtual machines as cluster members を参照し、VMware ストレージアクセスメソッドに関する Red Hat のポリシーと提案を検討してください。
  • fence_scsi または fence_mpath STONITH メソッドを使用する場合は、Support policies - fence_scsi and fence_mpath の特別条件を参照してください。
  • fence_scsi または fence_mpath を使用しない限り、Red Hat は RHEL High Availability 用の特定のストレージ設定を優先または推奨しません。サポートについては VMware にお問い合わせください。

VM システムのリソース設定に関する考慮事項

参照: Design guidance - Membership layout and member system specifications

RHEL HIGH AVAILABILITY クラスター設定

メンバーシップのレイアウトに関する一般的な考慮事項

参照: Design guidance - Membership layout and member system specifications

STONITH の推奨事項: プライマリーメソッドとしての fence_vmware_soap または fence_vmware_rest

詳細:

  • vCenter Server (使用している場合) をポイントするように設定し、それ以外の場合は vSphere Hypervisor ごとに 1 つの STONITH デバイスをポイントするように設定します。
  • VMware の VM 名が RHEL HA 設定のクラスターノード名と一致しない場合は、STONITH デバイス属性 pcmk_host_map="<nodename>:<VM name>;<nodename>:<VM name>[...]" を必ず設定してください。Red Hat knowledge solution - STONITH configuration when port values don't match node names を参照してください。

理由:

  • 電源フェンシングは、管理者の手動介入なしでクラスターを完全なメンバーシップに戻す点で、ストレージフェンシング (fence_scsi など) よりも信頼性が高くなります。
  • fence_vmware_soap を高可用性 vCenter Server と併用すると、プライマリー vCenter Server に障害が発生した場合でもフェンシングを成功させることができます。

STONITH 推奨事項: セカンダリーメソッドとしての fence_scsi

詳細:

理由:

STONITH に関する考慮事項: セカンダリーメソッドとしての仮想化ホストの電源

詳細:

  • ホストの電源を制御するフォールバック STONITH メソッド (fence_ipmilan、fence_apc_snmp、fence_cisco_ucs、fence_ilo4...など) を使用するように VM クラスターを設定します。
  • 重要: 永続的な VM-host アフィニティー、またはホストへの VM の一貫した手動での分散が必要です。これにより、特定の VM の適切なホストの電源を正しくオフにするように STONITH を設定できます。VM 分散を STONITH 設定に合わせない場合、データの破損やその他の競合が発生する可能性があります。
  • これにより、他の VM が実行されている可能性のあるホストの電源をオフにする機能が VM クラスターに与えられることに注意してください。
  • 通常は、vCenter Server を使用しないデプロイメントでのみ推奨されます。この場合、fence_vmware_soap の信頼性が低くなるため、バックアップメソッドがあると役に立ちます。

クォーラムの推奨事項: qdevice の使用

詳細:

理由:

  • メンバー障害やリンクの中断が発生したシナリオにおけるクラスターの信頼性が向上します。
  • qdevice により、典型的な "過半数" 設定よりも多くのメンバーで障害が発生した後でも、クラスターが存続できます。
  • メンバーシップの分割では、qdevice は、引き続き外部接続を持つメンバーに権限を与えるため、クライアントや外部ユーザーにより多くのサービスを提供できる可能性があります。

マルチサイト設計の考慮事項

考慮事項:

  • 複数のサイトにまたがる単一のメンバーシップ を対象とする場合、信頼性の高いクロスサイトクラスター STONITH は、VMware 環境では困難な課題となることに注意してください。

    • fence_vmware_soap および fence_vmware_rest は、vCenter Server または vSphere Hypervisor へのネットワーク接続に依存しているため、サイト間のリンクの中断により、サイト全体に広がる VM クラスターメンバーのフェンシングがブロックされる可能性があります。
    • fence_scsi / fence_mpath は、マルチサイトデプロイメントを対象とするストレージレプリケーション製品の SCSI-PR 機能の欠如によって制限される可能性があります。SCSI 永続予約が、ストレージベンダーの製品で正常に処理されるかどうかについては、ストレージベンダーのガイダンスを参照してください。
    • Red Hat では、booth チケットマネージャーを使用するコーディネートマルチサイトフェイルオーバークラスター を使用して、アクティブ/パッシブシステムで動作するようにユースケースの変更を試みることを推奨しています。
    • 複数のサイトにまたがる単一のメンバーシップ を使用している場合は、fence_vmware_soap がターゲットに到達できない場合に、クラスターを回復するために管理者による手動介入の可能性について計画してください。
    • 可用性の高い vCenter Server 設定は、STONITH の信頼性に関して役に立つ場合があります。
    • クラスターが分割メンバーシップをインテリジェントに解決できるようにするには、qdevice が強く推奨されます。

  • booth チケットマネージャーを使用するコーディネートマルチサイトフェイルオーバークラスター デザインを使用すると、クロスサイトフェンシングを必要とせずにマルチサイトフェイルオーバーを実現できます。これらは、VMware マルチサイトデプロイメントにより適している可能性があります。

    • booth 設定は、アクティブ/パッシブアプリケーションを対象としています。
    • 複数のサイトで同時にアクティブにする必要があるアクティブ/アクティブアプリケーションでは、複数のサイトにまたがる単一のメンバーシップが必要となり、サイトをまたいで機能する信頼性の高いフェンスメソッドが必要になります。
    • qdevice は、別のサイトにフェイルオーバーすることなく信頼性を高めるために、これらの調整クラスター内でも役立ちます。

Comments