第7章 仮想化と高可用性

さまざまな仮想化プラットフォームが、High Availability Add-On と Resilient Storage アドオンを使用する Red Hat Enterprise Linux 6 でサポートされています。Red Hat Enterprise Linux High Availability Add-On を使用する仮想化については、以下の 2 つのユースケースがサポートされています。
これには、仮想化プラットフォームとして使用できるベアメタルホスト上で実行される RHEL Cluster/HA が使用されます。このモードでは、クラスターリソースマネージャー (rgmanage) を設定し、仮想マシン (ゲスト) を高可用性リソースとして管理することができます。
  • 高可用性リソース/サービスとしての VM
  • ゲストクラスター

7.1. 高可用性リソース/サービスとしての VM

RHEL HA と RHEV はどちらも高可用性の仮想マシンを提供する仕組みを提供します。機能が重複していることを考慮すると、具体的なユースケースに適している製品を慎重に選択する必要があります。以下は、RHEL HA と RHEV のどちらを VM の高可用性を提供する製品として選択するかについての考慮すべきいくつかのガイドラインになります。
仮想マシンおよび物理ホスト数:
  • 多数の物理ホストで多数の VM が高可用化されている場合、RHEV ではホスト CPU、メモリーおよび負荷情報などを考慮して VM 配置を管理する高度なアルゴリズムを提供するため、RHEV がより適したソリューションになるでしょう。
  • 少数の物理ホストで少数の VM が高可用化されている場合、RHEL HA を使用すると追加される必要のあるインフラストラクチャーが少なくなるため、RHEL HA がより適したソリューションになるでしょう。RHEL HA の VM の最小ソリューションには、2 ノードクラスター用に 2 つの物理ホストが必要になります。一方、RHEV の最小ソリューションには RHEVM サーバーに高可用性を提供する 2 つのノードと、VM ホストとして機能する 2 つのノードの合計 4 ノードが必要です。
  • どの程度のホストまたは VM が「多数」と見なされるかについての厳密なガイドラインはありませんが、単一の RHEL HA クラスター内の最大ホスト数は 16 であり、8 つ以上のホストを持つすべてのクラスターには、サポート容易性を判断するための Red Hat によるアーキテクチャーレビューが必要になることに注意してください。
仮想マシンの使用:
  • お使いの高可用性 VM が共有インフラストラクチャーの提供用に使用されるサービスを提供している場合、RHEL HA または RHEV のいずれかを使用することができます。
  • VM 内で実行中の小規模な重要なサービスセット向けに高可用性を提供する必要がある場合は、RHEL HA または RHEV を使用することができます。
  • 仮想マシンの迅速なプロビジョニングを行うインフラストラクチャーを検討している場合には、RHEV を使用する必要があります。
    • RHEV の VM では、動的な高可用性が意図されています。新規の VM は RHEV の「クラスター」に簡単に追加でき、完全にサポートされます。
    • RHEL の VM の高可用性環境は高度に動的にならないものとされています。VM の固定されたセットを含むクラスターは、いったんセットアップされるとクラスターの有効期間中そのまま維持されるため、VM の追加または削除を行うことは推奨されません。
  • RHEL の高可用性は、そのクラスター設定における静的な性質と、物理ノードの最大カウント数 (16 ノード) が比較的に少ないことを考慮すると、クラウドのような環境を作成するためのインフラストラクチャーを提供する目的で使用することはできません。
RHEL 5 は、2 つの仮想化プラットフォームをサポートします。Xen は RHEL 5.0 リリース以降サポートされており、RHEL 5.4 では KVM が導入されました。
RHEL 6 は、仮想化プラットフォームとして KVM のみをサポートしています。
RHEL 5 AP クラスターは、ホストクラスターインフラストラクチャーで管理される仮想マシンの実行に、KVM と Xen の両方の使用をサポートします。
RHEL 6 HA は、ホストクラスターインフラストラクチャーで管理される仮想マシンの実行に使用される KVM をサポートしています。
以下は、Red Hat によって現在サポートされているデプロイメントシナリオのリストです。
  • RHEL 5.0+ は、RHEL AP クラスターとの併用で Xen をサポートしています。
  • RHEL 5.4 では、テクノロジープレビュー用の RHEL AP クラスター内の管理対象リソースとして、KVM 仮想マシンのサポートが導入されました。
  • RHEL 5.5+ では、KVM 仮想マシンの完全サポートに向けてサポートがレベルアップしました。
  • RHEL 6.0+ は、RHEL 6 High Availability Add-On の高可用性リソースとして KVM 仮想マシンをサポートしています。
  • RHEL 6.0+ では、RHEL 6 が Xen をサポートしなくなったため、RHEL 6 High Availability Add-On での Xen 仮想マシンのサポートを行っていません。

注記

サポートされているデプロイメントシナリオの更新情報および特記については、以下の Red Hat ナレッジベースのエントリーを参照してください。
管理対象リソースとして実行される仮想マシンがどの種類であるかは、問題にはなりません。RHEL で Xen または KVM のいずれかによってサポートされているすべてのゲストを高可用性ゲストとして使用できます。これには、各種の RHEL (RHEL3、RHEL4、 RHEL5) や Microsoft Windows のいくつかの種類が含まれます。RHEL のドキュメンテーションを参照し、各ハイパーバイザーでサポートされるゲストオペレーティングシステムの最新リストを確認してください。

7.1.1. 一般的な推奨事項

  • RHEL 5.3 以前には、rgmanager は Xen domU (ゲスト) を管理するためにネイティブの Xen インターフェースを使用しました。RHEL 5.4 では、Xen と KVM の 2 つのタイプのハイパーバイザー間に一貫したインターフェースを提供する目的で、これらのハイパーバイザーの両方に libvirt を使用できるような変更が加えられました。このアーキテクチャーの変更のほかにも RHEL 5.4 と 5.4.z では数多くのバグ修正がリリースされたため、Xen の管理対象のサービスを設定する際には、少なくとも最新の RHEL 5.5 パッケージにホストクラスターをアップグレードすることをお勧めします。
  • KVM の管理対象サービスについては、最初にこの機能の完全サポートを始めた RHEL のバージョン RHEL 5.5 にアップグレードする必要があります。
  • クラスターをデプロイする前には最新の RHEL エラータを常に確認し、既知の問題やバグについての最新の修正が適用されていることを確認してください。
  • 複数の異なるタイプのハイパーバイザーのホストを混在させることはサポートされていません。ホストクラスターはすべて Xen であるか、またはすべて KVM ベースであるかのいずれかである必要があります。
  • ホストハードウェアのプロビジョニングでは、ホストによるメモリーのオーバーコミットや仮想 CPU のオーバーコミットなしに、ホストハードウェアが複数の失敗したホストから再配置されたゲストを吸収できるようにする必要があります。メモリーまたは仮想 CPU のいずれかのオーバーコミットを引き起こす障害が発生した場合、重大なパフォーマンスの低下やクラスター障害が発生する可能性があります。
  • rgmanager の制御下にある (live migrate、stop.start) 仮想マシンの管理に xm または libvirt ツール (virsh、virt-manager) を直接使用することは、クラスター管理スタックのバイパスが生じる可能性があるためにサポートされておらず、推奨されていません。
  • それぞれの VM の名前は、ローカル専用/非クラスター VM を含め、クラスター全体で一意の名前です。Libvirtd はホストごとに一意の名前のみを使用します。VM を手動で複製する場合、クローンの設定ファイルで名前を変更する必要があります。