機械翻訳について

第6章 サーバー・プールおよびOracle VM Serverの理解

目次

• 6.1 Oracle VM Serverがどのように追加されるか
• 6.2 サーバー・ロールとは
• 6.3 Oracle VM Serverでメンテナンスがどのように実行されるか
• 6.4 Oracle VM ServerのNTPの構成。
• 6.5 Oracle VM Serverの電源状態の変更と再起動
• 6.6 Oracle VM Serverの状態とは
• 6.7 Oracle VMに使用されるサーバー・プール
• 6.8 サーバー・プールがどのように作成されるか
• 6.9 サーバー・プール・クラスタの仕組み
  • 6.9.1 x86サーバー・プールのクラスタリング
  • 6.9.2 SPARCサーバー・プールのクラスタリング
• 6.10 クラスタ化されていないサーバー・プール
• 6.11 高可用性(HA)の仕組み
• 6.12 サーバー・プールのポリシーとは
  • 6.12.1 分散リソース・スケジューラ(DRS)
  • 6.12.2 分散電源管理(DPM)
  • 6.12.3 DRS/DPMネットワーク・ポリシー
• 6.13 アンチアフィニティ・グループとは
• 6.14 サーバー・プロセッサの互換性グループとは

Oracle VM Serverは、Oracle VM環境で馬車馬のように機能します。 重要なのは、デプロイメント内でのそれらの目的、実行中の環境にそれらがどのように追加されるか、およびそれらがどのように保持されるかを理解することです。 Oracle VM Serverの簡単な概要、そのコンポーネントおよび他のOracle VMエンティティとの一般的な関係は、2.2項「Oracle VM Serverとは」を参照してください。

サーバーがデプロイメントにどのように追加されるかは、6.1項「Oracle VM Serverがどのように追加されるか」を参照してください。 サーバーのメンテナンスの詳細は、6.3項「Oracle VM Serverでメンテナンスがどのように実行されるか」を参照してください。

Oracle VM Serverは、グループ化されてサーバー・プールを形成します。 これらのサーバー・プールでは、物理および仮想リソースを共有して、仮想マシンをホストし、仮想マシンの移行や高可用性(HA)などを実行するメカニズムが提供されます。 サーバー・プールの詳細は、6.7項「Oracle VMに使用されるサーバー・プール」を参照してください。

サーバー・プールでは、Oracle VMのクラスタリング機能を利用して、HAを達成できます。 クラスタ化されたサーバー・プールは、Oracle VM Managerを使用して非常に簡単に実装できますが、関連するテクノロジと、クラスタリングがどのように可能になるかについて深く理解することが重要です。 クラスタ化されたサーバー・プールの詳細は、6.9項「サーバー・プール・クラスタの仕組み」を参照してください。

最も一般的なデプロイメント戦略は、Oracle VMのクラスタリング機能を利用する傾向がありますが、クラスタ化されていない配置で実行されるように、サーバー・プールを構成することもできます。 このアプローチは、図6.2「NFS記憶域のみを使用したクラスタ化されていないサーバー・プール」を参照してください。

クラスタリングにより、サーバー・プール内のサーバーのHAを実現できますが、Oracle VMでは、個々の仮想マシンにHAを適用すべきかどうかを構成できます。 HAの詳細は、6.11項「高可用性(HA)の仕組み」を参照してください

Oracle VMでは、サーバーとサーバー・プールの構成方法に固有の追加の機能があります。 これらには、リソースの使用率と電力消費量を最適化する機能(6.12項「サーバー・プールのポリシーとは」を参照)、仮想マシンを実行できるようにする個々のサーバーを定義する機能(6.13項「アンチアフィニティ・グループとは」を参照)、互換性のあるプロセッサ・タイプを搭載したサーバーのグループを作成して、仮想マシンのライブ・マイグレーションを容易にする機能(6.14サーバー・プロセッサの互換性グループとは」を参照)などがあります。

6.1 Oracle VM Serverがどのように追加されるか

Oracle VM Serverがインストールされた後は、所有されていない状態であり、どのOracle VMデプロイメントとも関係がありません。 Oracle VM Serverを使用するには、サーバーの所有権を取得できるOracle VM Managerインスタンスに追加する必要があります。 これは、サーバー検出のプロセスです。

サーバー検出は、提供されるいずれかのインタフェースを使用して、Oracle VM Manager内から実行される簡単なプロセスです。 Oracle VM Managerでは、指定したIPアドレスまたはホスト名とパスワードを使用して、Oracle VM Serverで実行されるOracle VM Agentとの接続を試みます。 認証されると、サーバーはOracle VM Managerに追加され、ネットワークまたは記憶域の追加、サーバー・プール内へのグループ化、サーバーの更新などの様々な構成アクションを実行できます。 Oracle VM Manager Webインタフェース内でのサーバーの検出に必要なアクションは、『Oracle VM Managerユーザーズ・ガイド』のサーバーの検出に関する項を参照してください。

各Oracle VM Managerインスタンスには、検出されるOracle VM Serverを識別するUUIDが割り当てられます。 Oracle VM Serverで実行されるOracle VM Agentには、Oracle VM Agentを検出してその所有権を取得するOracle VM ManagerのUUIDが格納されます。 UUIDは、Oracle VM ManagerとOracle VM Serverの両方に格納されます。 Oracle VM Managerでは、UUIDは/u01/app/oracle/ovm-manager-3/.configで確認できます。 Oracle VM Serverでは、所有するOracle VM ManagerインスタンスのUUIDは、Oracle VM Serverシステムのrootユーザーとして次を実行することで、コンテンツのダンプが可能になるBerkeley DBデータベースに格納されます。

# cd /etc/ovs-agent/db
# ovs-agent-db dump_db server

所有されていない状態のOracle VM Serverの場合、Oracle VM Managerは、検出時にサーバーの所有権を自動的に取得します。 ただし、所有された状態としてレポートされるサーバーの場合、すでに所有権を持つOracle VM Managerが所有権を放棄するまで、Oracle VM Managerでサーバーの所有権を取得することはできません。 2つの別のOracle VM Managerインスタンスで実行される構成アクションがあると、競合が発生する場合があるため、これは重要です。 したがって、Oracle VM Managerインスタンスがサーバーの所有権を実際に持つまでは、サーバー構成を実行することはできません。 Oracle VM Manager Webインタフェースを使用した、サーバーの所有権の取得の詳細は、『Oracle VM Managerユーザーズ・ガイド』のサーバーの編集に関する項を参照してください。

サーバーを所有するOracle VM ManagerのUUIDに加えて、各Oracle VM Serverにも、大量の構成データがローカルに格納されます。 つまり、Oracle VM Managerインスタンスでダウンタイムが発生しても、環境を引き続き正常に機能させることができます。 これは、Oracle VM Managerインスタンスが完全に置き換えられた場合、新しく検出された各サーバーから構成のかなりの部分を直接ロードできます。 この一般的な例には、ネットワークおよびクラスタリング情報、Storage Connectionsなどがあります。 これにより、多少安心できる場合もありますが、様々な要素の別名などの情報は各サーバーに格納されないため、このようなOracle VM Managerインスタンスのリカバリはお薦めしません。 かわりに、適切なバックアップ戦略に従うようにしてください。 これが機能するには、新しいOracle VM Managerインスタンスと元のインスタンスのUUIDを同じにする必要があることを理解することも重要です。

これには、サーバー検出の意味も含まれます。 Oracle VM Serverの所有権が別のOracle VM Managerインスタンスにある場合、その既存のネットワーク、クラスタリングおよび記憶域の構成は、Oracle VM Managerに同時に自動ロードはされません。 サーバーに関する基本的な情報のみがOracle VM Managerにロードされます。 これは、部分検出と呼ばれます。 完全な検出は、サーバーの所有権がOracle VM Managerインスタンスの管理下にある場合にのみ実行できます。 Oracle VM Managerの代替インスタンスにサーバーの所有権がある場合は、所有権を最初に放棄する必要があります。 これは、サーバー・プールの一部でなく、リポジトリが提示されないサーバーに対してのみ実行できます。 Oracle VM Managerインスタンスによってサーバーが部分的に検出され、元のOracle VM Managerインスタンスが所有権をリリースしている場合、所有権を取得するOracle VM Managerインスタンスでサーバーの完全な再検出を実行する必要があります。 サーバーの所有権を取得しようとすると、Oracle VM Manager Webインタフェースがサーバーの再検出を自動的にトリガーします。

6.2 サーバー・ロールとは

サーバー・プール内のすべてのOracle VM Serverが、仮想マシンを実行する目的で必要になるとはかぎりません。 Oracle VM Serverは、Oracle VM Managerのかわりに、記憶域リポジトリでアクションを実行するなど、ユーティリティ機能を実行する場合にも必要になります。 両方の機能を実行できるように、すべてのOracle VM Serverを構成できますが、Oracle VMでは、サーバーの機能的役割に基づいて、サーバーを分離するオプションが用意されています。 これらの役割は次のように定義されます。

• VM Server role: VM Serverロールを使用すると、Oracle VM Serverで仮想マシンを実行できます。

• Utility Server role: ユーティリティ・サーバーは、仮想マシンをホストする以外の操作(たとえば、仮想マシン・テンプレートおよびアセンブリのインポート、仮想アプライアンスからの仮想マシン・テンプレートの作成、およびリポジトリの作成など)を実行するのに適しています。 ユーティリティ・サーバーが使用できない場合は、この操作にユーティリティ・サーバー以外のサーバーが選択されます。

サーバーがサーバー・プールの一部になると、サーバーのロールをOracle VM Manager内に構成できます。 サーバー・プール内のサーバーの少なくとも1つに「VM Server role」を割り当てないと、仮想マシンをサーバー・プールで実行できません。 サーバー・プールにOracle VM Serverを追加する際、デフォルトで「Utility Server role」および「VM Server role」の両方が自動的に選択されます。 「VM Server role」は、仮想マシンを実行するのに必要です。 「Utility Server role」は必要ではなく、あくまで参考です。

Oracle VM Serverは、いずれかまたは両方のロールに構成できるため、パフォーマンス目的でロール分離が使用されます。 たとえば、仮想マシン・テンプレートまたは仮想アプライアンスのインポートの場合は、このようなタスクがサーバー・プール内の仮想マシンに与える影響を抑えるために、このタスク専用のサーバーを用意することをお薦めします。

サーバー・プール内にサーバーがない場合、またはOracle VM Serverに(実行中または実行中でない)仮想マシンが存在する場合は、Oracle VM Serverの「VM Server role」を更新することはできません。 「VM Server role」を変更するには、Oracle VM Serverを所有している必要があります。 Oracle VM Serverを所有しているかぎり、いつでも「Utility Server role」を変更できます。

サーバー・ロールの構成の詳細は、『Oracle VM Managerユーザーズ・ガイド』のサーバーの編集に関する項を参照してください。

6.3 Oracle VM Serverでメンテナンスがどのように実行されるか

Oracle VM Serverがインストールされて検出されると、Oracle Supportによってシステムに直接アクセスするように指示されていないかぎり、管理者がその操作を実行する必要はありません。 すべてのメンテナンスおよび構成は、サーバーの所有権を持つOracle VM Managerインスタンスから直接処理されます。 これにより、サーバー更新の実行、ネットワークの構成、記憶域の接続、クラスタリングの構成、仮想マシンの管理などのシステム管理が、システム管理者にとって非常に簡単になり、デプロイメント内の複数のシステムへのアクセスのプロビジョニングのセキュリティ上の重要性が軽減されます。

Oracle VM Managerでは、サーバーにインストールして実行されているOracle VM Agentを介して、各Oracle VM Serverと直接通信できます。 通信はTLSを使用して保護され、Oracle VM Agentに対する認証が必要になります。 Oracle VM Agentに使用されるパスワードはインストール時に構成され、サーバー検出を実行する場合にOracle VM Managerで必要になります。 Oracle VM ManagerがOracle VM Serverの所有権を取得すると、証明書を使用して、Oracle VM Agentに対してOracle VM Managerの認証が実行され、Oracle VM Agentのセキュリティが向上します。 これにより、Oracle VM Serverの所有権を持つOracle VM Managerのみが、サーバーでのアクションの実行を認可されます。 Oracle VM Agentは、Oracle VM Managerから開始されるすべての構成変更とメンテナンスの実行を処理します。

Oracle VM Serverソフトウェアの更新とアップグレードは、Oracle VM Manager内からOracle VM Serverの1つ以上のサーバー更新リポジトリを構成することで処理されます。 1つ以上の更新リポジトリは、x86ベースのOracle VM Server (SPARCベースのサーバー)に対して構成できます。 これらのリポジトリは、そのハイパーバイザ・タイプを含むすべてのOracle VM Serverで使用できます。 これらのリポジトリをサーバー・プール・レベルでオーバーライドすることもできます。 リポジトリが構成されている場合、Oracle VM Managerは、環境内のOracle VM Serverごとに、更新を使用できるかどうかをレポートします。 サーバーの更新はOracle VM Managerによってトリガーできます。 Oracle VM Serverの更新の詳細は、『Oracle VM Managerユーザーズ・ガイド』のサーバーの更新に関する項を参照してください。

更新中、Oracle VM Serverは自動的にメンテナンス・モードになります。 メンテナンス・モードは、それ以上の仮想マシンが起動しないようにするためにサーバーをロックする場合に使用されます。 サーバーが、クラスタ化されたサーバーの一部になっている場合、メンテナンス・モードを設定すると、サーバーで実行される仮想マシンから、サーバー・プール内の代替サーバーへのライブ・マイグレーションを自動的に実行する最適な試行操作もトリガーされます。 なんらかの理由でライブ・マイグレーションが失敗すると、アップグレードは終了し、エラーが返され、そうでない場合は、仮想マシンがサーバーから移行され、アップグレードを続行できます。 これにより、既存のサービスに影響を与えることなく更新を実行できます。 アップグレード後にサーバーの再起動が必要な場合は、自動的に実行されます。 サーバーが再起動されると、サーバーはクラスタに再度参加し、通常の機能を再開します。 Oracle VM Serverのメンテナンス・モードは、サーバー・プロパティを編集することで設定できます。 メンテナンス・モードの詳細は、『Oracle VM Managerユーザーズ・ガイド』のサーバーの編集に関する項を参照してください。

Oracle VM Manager内からは、追加のネットワーク構成も処理されます。 サーバーをサーバー管理ネットワークに接続できるように、インストール中にプライマリ・ネットワークが定義されます。 この時点以降、追加のネットワーク構成がOracle VM Manager内から実行されます。 Oracle VMのネットワークの詳細は、第5章「ネットワークの理解」を参照してください。

Storage Connectionsの定義のプロセスおよびマウント・ポイントもOracle VM Manager内から処理されます。 これらの接続と作成方法の詳細は、第3章「記憶域の理解」を参照してください。

明らかにしておくべきことは、Oracle VM Serverに必要な初回のインストール以外では、サーバーのメンテナンスと構成に関連するすべての管理タスクは、Oracle VM Managerによって処理されることです。 このような一元管理により、サーバーの管理が容易になるだけでなく、セキュリティも向上し、サーバーのダウンタイムにつながる可能性のある構成エラーの可能性も軽減されます。

6.4 Oracle VM ServerのNTPの構成。

データがシステム間で常に共有される環境では、適切に同期することが重要になります。 これは、クラスタリングが頻繁に使用され、必要に応じて、仮想マシンをOracle VM Server間で移動できるOracle VM内で特に重要です。 この要件に対する最も一般的なアプローチは、Oracle VM Managerをインストールしたホストと同じホストで実行されるようにNTPサーバーを構成することです。 これにより、各Oracle VM ServerがOracle VM ManagerホストをNTPサーバーとして使用できます。 NTPのインストールおよび構成の詳細は、『Oracle VMインストレーションおよびアップグレード・ガイド』.のOracle VM ManagerホストでのNTPサービスの構成に関する項を参照してください。

任意Oracle VM Managerインスタンスの所有権下にないOracle VM Serversは、いずれかのNTPまたはサーバーごとに構成された1台のまたは複数のNTPサーバーにローカル・ホスト(127.127.1.0)をポイントするように構成されています。 Oracle VM Serverが検出され、Oracle VM Managerの内部で所有権が取得されると、そのOracle VM Serverに使用する必要のあるNTPサーバーを構成できるようになります。 Oracle VM Managerでは、Oracle VM Manager Webインタフェースのサーバー構成内で直接Oracle VM Serverに使用する必要のあるNTPサーバーを構成できます。 各サーバーのNTPの構成方法の詳細は、『Oracle VM Managerユーザーズ・ガイド』のサーバーの編集に関する項を参照してください。 大量のサーバーのNTPのバッチ編集が必要な場合に推奨される方法は、Oracle VM Managerコマンドライン・インタフェースまたはOracle VM WebサービスAPIを使用することです。 Oracle VM Managerコマンドライン・インタフェースを使用して、Oracle VM Serverを編集し、NTPを構成する方法は、サーバーの編集に関する項を参照してください。

Oracle VM Server構成からNTPサーバーをすべて削除すると、構成がデフォルトの状態に戻り、Oracle VM ServerがそのNTPサーバーとしてlocalhostを指すように構成されます。 これは、Oracle VM ServerがOracle VM Managerインスタンスの所有権からリリースされる場合に適用される動作と同じです。 したがって、Oracle VM Serverが新しく検出され、Oracle VM Managerインスタンスが所有権を取得すると、localhostを指すようにOracle VM ServerのNTP構成が常に構成されます。

6.5 Oracle VM Serverの電源状態の変更と再起動

Oracle VM Serverは、Webユーザー・インタフェースまたはコマンドライン・インタフェ―スを使用して、Oracle VM Managerから再起動できます。 『Oracle VM Managerユーザーズ・ガイド』のサーバーの再起動に関する項を参照してください。 Oracle VM Serverを実行しているハードウェア・アーキテクチャに応じて、再起動の結果が異なります。

x86ハードウェアの場合、システム全体が再起動されます。 つまり、サーバー・プールの構成、サーバーがメンテナンス・モードに最初に入っているかどうかに応じて、サーバーを再起動する前に、サーバーで実行されているすべての仮想マシンが代替のサーバー・プールに移行されるか、停止します。

SPARCハードウェアの場合は、再起動は制御ドメインにのみ適用されます。 これは、制御ドメインの再起動中に、SPARCベースのOracle VM Serverで実行されている仮想マシンが引き続き実行されることを意味します。 ただし、2番目のサービス・ドメインまたはシャドウ・ドメインをこのアクティビティに使用できないかぎり、制御ドメインの再起動中に、ネットワーク・アクセスとディスクI/Oはブロックされます。 「Oracle VM管理者ガイド」の「セカンダリ・サービス・ドメインの構成」を参照してください。 制御ドメインの再起動が終了すると、実行中の仮想マシンのネットワーク・アクセスおよびディスクI/Oが復元され、アクティビティが通常通りに再開します。 サーバー・プールのクラスタリングを使用している場合、制御ドメインの再起動に時間がかかりすぎる、またはなんらかの理由で完了しないと、仮想マシンが代替サーバーに移行される場合があります。

この場合は、x86とSPARCのどちらでも、電源を入れ直せば同じ結果になります。 システム全体が再起動されます。 サーバーが属するサーバー・プールでクラスタリングが有効になっているかどうかに応じて、すべての仮想マシンが停止または移行されます。 Oracle VM Manager内からOracle VM Serverを強制終了すれば、電源を入れ直すことと同じ結果になります。 この詳細は、『Oracle VM Managerユーザーズ・ガイド』のサーバーの強制終了に関する項を参照してください。

警告

スタンバイ・モードはOracle VM Serverではサポートされていません。 Oracle VM Serverをスタンバイ・モードにしないでください。 サーバーの電源状態をスタンバイに設定すると、サーバーがフリーズする場合があります。

6.6 Oracle VM Serverの状態とは

Oracle VM Managerでは、各Oracle VM Serverの様々な実行状態を定期的に追跡します。 Oracle VM Manager WebインタフェースまたはOracle VM Managerコマンドライン・インタフェース内では、任意の時点でOracle VM Serverの実行状態をチェックできます。 Oracle VM Serverに適用される実行状態は5種類あります。 次のリストでは、各実行状態と、それぞれに適用されるシナリオについて説明します。

• STARTING:

  • Oracle VM Managerを介して起動されたときにOracle VM Serverに設定される初期状態です。

  • これは、検出プロセスの初期にOracle VM Serverに設定される状態でもあります。 検出が終了すると、状態が更新され、RUNNINGに設定されます。

• RUNNING:

  • Oracle VM Serverが実行中で、Oracle VM Managerインスタンスでサーバー上のOracle VM Agentの認証と通信ができる場合に、Oracle VM Serverに設定される状態です。

  • この状態は、Oracle VM Serverの検出操作が正常に終了した時点で設定されます。

• STOPPING:

  • Oracle VM Serverの停止、再起動または強制終了を試行すると、即座にSTOPPING状態になります。

• STOPPED:

  • DISCONNECTイベントを最初に受信してから、Oracle VM Serverと長時間通信できず、最終的にOFFLINEイベントになると、状態がSTOPPEDに設定されます。

• UNKNOWN:

  • Oracle VM ServerがUNKNOWN状態に設定されるのは、Oracle VM ManagerインスタンスがOracle VM Serverを所有していない場合、またはOracle VM Serverに対する最後の認証に失敗した場合のみです。

6.7 Oracle VMに使用されるサーバー・プール

サーバー・プールは、1つ以上のOracle VM Serverで構成され、特定の仮想マシンのセットが実行可能なサーバーの論理グループを表します。 すべてのサーバー・プールの要件は、それらのサーバー・プール内のOracle VM Serverが同じCPUアーキテクチャを共有することです。 サーバー・プール内のすべてのサーバーは、同じ物理的場所にある必要があります。 サーバー・プールの地理的な分散はサポートされていません。

Oracle VMでデプロイメントは、設計が異なる場合があります。 同様に、そのすべての仮想化の要件から、1つのサーバー・プールしか使用できないデプロイメントもあれば、様々なハードウェア・プラットフォームまたは仮想マシンの完全な分離に対応する、複数のサーバー・プールから構成されるデプロイメントもあることは、十分考えられます。

サーバー・プールでは、水平拡張も可能です。 仮想マシンを実行するための十分なリソース(CPU、メモリーなど)がサーバー・プールにない場合は、Oracle VM Serverを追加することによってサーバー・プールを拡張できます。 このプロセスの詳細は、『Oracle VM Managerユーザーズ・ガイド』のサーバー・プールの編集に関する項を参照してください。 このように、サーバー・プールは、仮想マシンのグループで使用可能なリソースのセットとして説明することができます。

したがって、サーバー・プールを作成する前に、何台のOracle VM Serverをサーバー・プールに含めることができるか、各Oracle VM Serverで実行される機能またはロールについて考慮しておくと役に立ちます。 サーバーの機能およびロールの詳細は、6.2項「サーバー・ロールとは」を参照してください。 サーバー・プール内で実行される各仮想マシンでは、CPU、ネットワーク、メモリーなどのリソースを使用できるようにする必要があります。 それに応じて、サーバー・プールのサイズを設定してください。

Oracle VMの通常のデプロイメント・アーキテクチャでは、サーバー・プール内のOracle VM Server間で記憶域に共有アクセスできる、サーバー・プールを利用します。 仮想マシンは、サーバー・プールのワークロードを均等に分散するために共有記憶域に格納され、いずれかのOracle VM Serverにロードされます。

サーバー・プール内のすべてのOracle VM Serverにアクセス可能な共有記憶域を使用するデプロイメントでは、他の多くの機能を使用して、高可用性と優れたフェイルオーバーを実現できます。 サーバー・プールはクラスタとして構成できるため、サーバーのダウンタイムの発生時にサーバー間で仮想マシンが自動的にライブ・マイグレーションされます。

仮想マシンはサーバー・プール内の特定のOracle VM Serverにはバインドされていないため、個々のOracle VM Serverが偶然メンテナンスのために停止していたり、そのときに使用できない状態になっていることが原因で仮想マシンの起動が妨げられることはありません。 また、サーバー・プール内の仮想マシンに起動ポリシーを指定するためのオプションが提供されています。 起動ポリシーは、最大のリソースを使用できるOracle VM Serverでのみ仮想マシンが起動されるようにするロード・バランシング・アルゴリズムを実装できます。 ロード・バランシングは、動的電源管理(DPM)と分散リソース・スケジューラ(DRS)に使用される同じアルゴリズムを使用して実現されます。 また、ロード・バランシングは、サーバー・プールの集約パフォーマンスを最大限に引き出すのにも役立っています。

Oracle VMでのサーバー・プールの作成時に、次を指定します。

• サーバー・プールの名前および説明

• クラスタをアクティブにするかどうか

• グローバル・ハートビート用のサーバー・プール・ファイル・システムおよびその他のクラスタ情報

サーバー・プールの名前と説明は、様々なサーバー・プールを参照して、その目的を理解できるように、わかりやすい識別子としてOracle VM Manager内で使用されます。

クラスタリングを有効化するように選択すると、サーバー・プール内のサーバーはクラスタ化され、必要なすべての構成ステップがOracle VM Managerで自動的に実行されます。 この場合、クラスタ情報の格納に使用されるサーバー・プール・ファイル・システムを構成する必要があります。 詳細は、6.9項「サーバー・プール・クラスタ仕組み」を参照してください。 クラスタリングなしのサーバー・プールを選択する場合は、6.10項「サーバー・プールの理解」を参照してください。

6.8 サーバー・プールがどのように作成されるか

サーバー・プールは少なくとも1つ以上(通常は複数)のOracle VM Serverで構成されています。 サーバー・プール内のすべてのOracle VM ServerのCPUが同じCPUファミリのものである必要があります。 これらが同じCPUファミリとタイプのものでない場合、ライブ・マイグレーションなどの一部の操作が失敗する可能性があります。 CPUは同じCPUファミリのものであることが必要ですが、コアの数が異なるなど、構成が異なる場合があります。 RAMの量やディスク・ドライブの数とサイズなど、ホスト・コンピュータ上の他のハードウェア・コンポーネントが異なる場合もあります。

ホスト・コンピュータの構成が異なる場合でも、サーバー・プール内のすべてのOracle VM Serverは同一であることをお薦めします。 Oracle VM Managerには、プロセッサの互換性グループのルールが含まれています。 互換性のないプロセッサ間でライブ・マイグレーションが試行された場合、エラー・メッセージが表示されます。

サーバー・プールを作成する前に、次が必要です。

• Oracle VM ServerのIPアドレスまたはホスト名。

• Oracle VM ServerにインストールしたOracle VM Agentへアクセスするためのパスワード

  ノート

  Oracle VM Agentのパスワードは、サーバー・プール内の各Oracle VM Serverで同一である必要があります。 Oracle VM Serverの所有権がOracle VM Managerインスタンスにある場合、Oracle VM Agentのセキュリティを向上するために、パスワード認証が証明書ベースの認証に置き換えられます。

クラスタ化されたサーバー・プールは、サーバー・プールのファイル・システムとして使用する専用のファイル・システム(NASエクスポートまたはLUNのいずれか)を持つ必要があります。 この記憶域は10GB以上のサイズで作成することをお薦めします。 SPARCベースのサーバー・プールを作成している場合、サーバー・プールのファイル・システムではNFSファイル・システムのみがサポートされます。

「Create Server Pool」アイコンは、Oracle VM Manager Webインタフェース内の「Servers and VMs」タブに表示され、クリックすると、Create Server Poolウィザードが開き、指示に従ってサーバー・プールを作成できます。

サーバー・プールの作成の詳細は、『Oracle VM Managerユーザーズ・ガイド』のサーバー・プールの作成に関する項を参照してください。

6.9 サーバー・プール・クラスタの仕組み

• 6.9.1 x86サーバー・プールのクラスタリング
• 6.9.2 SPARCサーバー・プールのクラスタリング

Oracle VM内でのサーバー・プール・クラスタリングの実装は、サーバー・プールに使用されるOracle VM Serverがx86またはSPARCのどちらのアーキテクチャに基づくかによって異なりますが、サーバー・プール・クラスタの動作と、Oracle VM Manager内でどのように構成されるかは、使用するプラットフォームに関係なく、大部分がシームレスです。 これは、クラスタリングの実行に必要な要件が満たされてる場合、サーバー・プールに対して有効にするとすぐに、サーバー・プール・クラスタリングがOracle VM Managerで自動的に処理されることを意味します。

この項では、サーバー・プール・クラスタが各種のアーキテクチャでどのように機能するかについて考察し、クラスタリングを有効にするための要件について説明します。

6.9.1 x86サーバー・プールのクラスタリング

• 6.9.1.1 x86サーバー・プールのクラスタ関連の問題のトラブルシューティング

Oracle VMはOracle OCFS2とともに動作して、OCFS2ファイル・システムに存在するサーバー・プール・リソースへの共有アクセスを提供します。 クラスタ化が有効なサーバー・プールに属するx86 Oracle VM Serverで実行されている仮想マシンの高可用性(HA)を実現するには、この共有アクセス機能が重要です。

OCFS2は、オラクル社によって開発されたLinux用のクラスタ・ファイル・システムであり、複数のノード(Oracle VM Server)による同じディスクへの同時アクセスを可能にします。 パフォーマンスとHAの両方を提供するOCFS2は、多くのクラスタ対応アプリケーションまたは共有ファイル・システム機能が必要なアプリケーションで使用されます。 Oracle VMでは、OCFS2によって、同じサーバー・プールに属するOracle VM Serverが、制御された方法で共有リポジトリ内のリソースに対してアクセスまたは修正行うことが保証されます。

OCFS2ソフトウェアには、標準のファイル・システム・インタフェースおよび動作セマンティクスを提供するコア・ファイル・システムおよび共有ディスク・クラスタ機能をサポートするコンポーネントが含まれます。 共有ディスク・コンポーネントは、ほとんどの場合カーネルに存在し、O2CBクラスタ・スタックと呼ばれます。 これには、次のものが含まれます。

• 稼働しているサーバーを検出するためのディスク・ハートビート

• ノード間の通信のためのネットワーク・ハートビート

• クラスタ内のサーバーによる共有ディスク・リソースのロックおよび解放を可能にする分散ロック・マネージャ(DLM)

また、OCFS2では、OCFS2コンポーネントを調べてトラブルシューティングするためのサーバー・プールも提供されます。 OCFS2の詳細は、次の場所にあるOCFS2のマニュアルを参照してください。

http://oss.oracle.com/projects/ocfs2/documentation/

Oracle VMでは、記憶域リポジトリがオフラインの場合でもクラスタを使用できるように、記憶域リポジトリとクラスタが分離されます。 ハートビート・デバイスを1つ失っても、Oracle VM Serverによる自己フェンシングは強制されません。

サーバー・プールの作成時に、次の利点があるクラスタ機能をアクティブにすることを選択できます。

• クラスタ内のすべてのOracle VM Serverでアクセス可能なリポジトリ内のリソースへの共有アクセス。

• サーバー・プール内のOracle VM Serverで障害が発生した場合の仮想マシンの保護。

Oracle VM Manager内のサーバー・プールの作成または編集時に、サーバー・プール・クラスタを構成して、サーバー・プール内でHAを有効化するように選択できます。 サーバー・プールの作成および編集の詳細は、『Oracle VM Managerユーザーズ・ガイド』のサーバー・プールの作成およびサーバー・プールの編集に関する項を参照してください。

サーバー・プールの作成時、その新しいサーバー・プールに指定されたサーバー・プール・ファイル・システムは、OCFS2ファイル・システムとしてアクセスされ、フォーマットされます。 このフォーマットによって、グローバル・ディスク・ハートビートの領域を含め、ファイル・システムにいくつかの管理領域が作成されます。 サーバー・プール・ファイル・システムは、そのファイル・システムがNFS共有、FC LUNまたはiSCSI LUNとしてOracle VM Serverによってアクセスされるかどうかにかかわらず、OCFS2ファイル・システムとしてフォーマットされます。 記憶域がクラスタ・ファイル・システムにどのように使用されるか、および安定したクラスタ・ハートビート機能の要件の詳細は、3.8項「サーバー・プールのクラスタリングに記憶域がどのように使用されるか」を参照してください。

新しく作成されたサーバー・プールにOracle VM Serverが追加されると、Oracle VMでは次のことを実行します。

1. クラスタ構成ファイルおよびクラスタ・タイムアウト・ファイルを作成します。

2. 構成ファイルをサーバー・プール内のすべてのOracle VM Serverにプッシュします。

3. クラスタを起動します。

クラスタ・タイムアウトはサーバー・プールの作成時のみ構成できます。 クラスタ・タイムアウトでは、フェイルオーバーの発生前にクラスタ内ｓｗサーバーを使用不可にする時間を決定します。 この値を低すぎる値に設定すると、偽陽性が発生する可能性があり、短時間のネットワーク停止または突然の負荷の上昇によりフェイルオーバーが実行される場合があります。 クラスタ・タイムアウトを高い値に設定すると、フェイルオーバーが実行されるまで、サーバーが長期に使用不可になる場合もあります。 クラスタ・タイムアウトの最大値は300秒です(サーバーが使用不可になった場合でも、フェイルオーバーは5分後に実行されます)。 タイムアウト値の設定には、サーバー・プールの作成または編集時にOracle VM Manager内で提供される機能を使用することをお薦めします。 タイムアウト値の設定の詳細は、『Oracle VM Managerユーザーズ・ガイド』のサーバー・プールの作成およびサーバー・プールの編集に関する項を参照してください。

クラスタ内の各Oracle VM Serverでは、クラスタ構成ファイルは/etc/ocfs2/cluster.conf、クラスタ・タイムアウト・ファイルは/etc/sysconfig/o2cbにあります。 クラスタ内のすべてのノードでは、同じo2cbパラメータを設定する必要があります。 クラスタ内のサーバーごとに異なるパラメータを構成しないでください(そうすると、ハートビート・デバイスがマウントされなくなる場合があります)。 クラスタ・タイムアウト・ファイル内のクラスタ・ハートビート・パラメータは、サーバー・プールの作成中に、サーバー・プールに定義されたクラスタ・タイムアウト値から導出されます。 リストされているo2cbパラメータの設定には、次のアルゴリズムが使用されます。

• o2cb_heartbeat_threshold = (timeout/2) + 1

• o2cb_idle_timeout_ms = (timeout/2) * 1000

クラスタを起動すると、クラスタ内の各Oracle VM Serverでサーバー・サービスおよびサーバー・プロセスがアクティブになります。 最も重要なプロセスおよびサービスについて、表6.1「クラスタ・サービス」に示します。

表6.1 クラスタ・サービス

サービス	説明
o2net	o2netプロセスでは、TCP/IPイントラ・クラスタ・ノードの通信チャネルがポート7777に作成され、ノードが動作しているかどうかを検証するために通常のキープ・アライブ・パッケージがクラスタ内の各ノードに送信されます。 イントラ・クラスタ・ノードの通信では、クラスタ・ハートビート・ロールを持つネットワークが使用されます。 デフォルトでは、これがサーバー管理ネットワークです。 ただし、この機能用に別のネットワークを作成できます。 クラスタ・ハートビート・ロールの詳細は、5.6項「Oracle VMでネットワーク機能がどのように分離されるか」を参照してください。 クラスタ内の各Oracle VM Serverのファイアウォールでハートビート・ネットワーク上のネットワーク・トラフィックが許可されていることを確認してください。 デフォルトでは、インストール後にOracle VM Serverのファイアウォールは無効になっています。
o2hb-diskid	また、サーバー・プール・クラスタでは、ディスク・ハートビート・チェックも使用されます。 o2hbプロセスは、クラスタのグローバル・ディスク・ハートビート・コンポーネントを処理します。 ハートビート機能では、サーバー・プール・ファイル・システムの非表示領域内のファイルが使用されます。 各プール・メンバーによって、動作していることを示す書込みがこの領域の独自のブロックに2秒おきに行われます。 また、動作しているノードのマップをメンテナンスするために領域の読込みも行われます。 プール・メンバーがそのブロックへの書込みを停止すると、Oracle VM Serverは停止しているとみなされます。 これにより、Oracle VM Serverはフェンシングされます。 その結果、Oracle VM Serverはアクティブ・サーバー・プールから一時的に削除されます。 このフェンシング・プロセスにより、プール内のアクティブなOracle VM Serverから、フェンシングされたOracle VM Serverのリソースにアクセスできます。 フェンシングされたサーバーがオンラインに戻ると、サーバー・プールに再参加します。 ただし、このフェンシング・プロセスは内部動作であり、サーバー・プール構成は大きくは変更されません。 たとえば、Oracle VM Manager Webインタフェースでは、Oracle VM Serverがフィンシングされても、サーバー・プールのメンバーとして表示します。
o2cb	o2cbサービスはクラスタ操作の中心となります。 Oracle VM Serverを起動すると、o2cbサービスが自動的に起動されます。 共有リポジトリを正常にマウントするには、このサービスが稼働している必要があります。
ocfs2	OCFS2サービスは、ファイル・システムの操作を行います。 このサービスも自動的に起動されます。
ocfs2_dlmおよびocfs2_dlmfs	DLMモジュール(ocfs2_dlm、ocfs2_dlmfs)およびプロセス(user_dlm、dlm_thread、dlm_wq、dlm_reco_threadなど)は分散ロックマネージャの一部です。 OCFS2では、クラスタ全体でのリソースに対するロックの追跡および管理にDLMが使用されます。 これは、クラスタ内の各Oracle VM Serverが対象とするリソースのロック情報のみを保持するため、分散と呼ばれます。 Oracle VM Serverがクラスタ内のリソースに対するロック(仮想マシンに対するロックなど)を保持している間に停止した場合、サーバー・プール内の残りのOracle VM Serverによって、停止したOracle VM Serverが保持しているロック状態を再構築するための情報が収集されます。

警告

クラスタ構成ファイルの変更、または、クラスタ・サービスの開始および停止を手動で行わないでください。 Oracle VM Managerによって、サーバー・プールに属するOracle VM Serverのクラスタが自動的に起動されます。 クラスタを手動で構成したり、操作すると、クラスタで障害が発生する場合があります。

物理ディスクにリポジトリを作成すると、OCFS2ファイル・システムが物理ディスクに作成されます。 これは、ローカル・リポジトリの場合も同様です。 リポジトリ内のリソース(仮想マシン構成ファイル、仮想ディスク、ISOファイル、テンプレートおよび仮想アプライアンスなど)は、サーバー・プール全体で安全に共有できます。 サーバー・プールのメンバーが停止または終了すると、終了するサーバーが所有するリソースはリカバリされ、サーバー・プールのメンバーのステータスにおける変更がサーバー・プール内の残りのすべてのOracle VM Serverに伝播されます。

図6.1「OCFS2機能を使用したサーバー・プールのクラスタリング」に、サーバー・プールのクラスタリング、ディスクとネットワークのハートビートおよびクラスタ全体でリソースをロックするDLM機能の使用を示します。

図6.1 OCFS2機能を使用したサーバー・プールのクラスタリング

図6.1「OCFS2機能を使用したサーバー・プールのクラスタリング」は、3つのOracle VM Serverを含むサーバー・プールを表しています。 このサーバー・プールに関連付けられるサーバー・プールのファイル・システムは、NFS共有上に存在します。 サーバー・プールの作成時に、NFS共有へのアクセスが行われてNFS共有上にディスク・イメージが作成され、このディスク・イメージがOCFS2ファイル・システムとしてフォーマットされます。 この技術によって、基礎となる記憶域要素がNFS共有、iSCSI LUNまたはファイバ・チャネルLUNであるかどうかにかかわらず、OCFS2を使用し、同じ方法ですべてのOracle VM Serverのサーバー・プールのファイル・システムにアクセスできます。

Oracle VM環境で最初のサーバー・プールを作成する前に、Oracle VM Server間のプライベート・ネットワーク接続として示されるネットワーク・ハートビートが構成されます。 サーバー・プールの作成後、Oracle VM Serverがサーバー・プールに追加されます。 この時、クラスタ構成が作成され、クラスタの状態はオフライン からハートビートに変わります。 最後に、サーバー・プールのファイル・システムがクラスタ内のすべてのOracle VM Serverにマウントされ、クラスタの状態はハートビートからDLM準備完了に変わります。 図6.1「OCFS2機能を使用したサーバー・プールのクラスタリング」に示すとおり、ハートビートのリージョンは、クラスタ内のすべてのOracle VM Serverに対してグローバルであり、サーバー・プールのファイル・システムに存在します。 Oracle VM Serverは、ネットワーク・ハートビートを使用して、クラスタ内の他のOracle VM Serverとの通信チャネルを確立し、キープ・アライブ・パケットを送信してチャネルの中断を検出します。

物理記憶域要素上に新しく追加された各リポジトリでは、OCFS2ファイル・システムがリポジトリに作成され、このリポジトリは通常、プール内のすべてのOracle VM Serverに提示されます。 図6.1「OCFS2機能を使用したサーバー・プールのクラスタリング」に、リポジトリ1およびリポジトリ2がプール内のすべてのOracle VM Serverでアクセス可能であることが示されています。 これは通常の構成ですが、1つのリポジトリがプール内の1つのOracle VM Serverのみによってアクセス可能であることもあります。 図にリポジトリ3が示されていますが、このリポジトリにはOracle VM Server 1のみがアクセスできます。 このリポジトリにリソースが存在する仮想マシンは、サーバー・プールが提供する高可用性機能を利用できません。

NFS共有に構築されたリポジトリは、OCFS2ファイル・システムとしてフォーマットされないことに注意してください。 リポジトリの詳細は、3.9項「仮想マシン・リソースが配置される場所」を参照してください。

図6.1「OCFS2機能を使用したサーバー・プールのクラスタリング」に、共有リポジトリ1および2にリソースがあるいくつかの仮想マシンが示されています。 仮想マシンの作成、起動、停止または移行が実行されると、これらの仮想マシンのリソースは、このリソースを必要とするOracle VM Serverによってロックされます。 各Oracle VM Serverは、サーバー・プール内のロックされているすべてのリソースのサブセットを管理することになります。 リソースには、これに対して複数のロックがある場合があります。 同じリソースに同時に複数の読取り専用のロックが存在できますが、リソースへの書込みが予想される場合は排他ロックがリクエストされます。 図に示すように、ロックの状態は各Oracle VM Serverのメモリーに保持されます。 メモリーに保持されている分散ロック・マネージャ(DLM)の情報は、/dlmにマウントされた、dlmfsと呼ばれる統合ファイル・システムのユーザー領域に公開されます。 Oracle VM Serverで障害が発生した場合、そのロックは、クラスタ内の他のOracle VM Serverによってリカバリされ、障害が発生したOracle VM Serverで実行されている仮想マシンはクラスタ内の別のOracle VM Serverで再起動されます。 Oracle VM Serverがハートビートを介してクラスタと通信しなくなった場合は、このOracle VM Serverをクラスタから強制的に削除できます。 これはフェンシングと呼ばれます。 Oracle VM Serverは、クラスタの一部でなくなったと認識した場合、自身のフェンシングを行うこともできます。 Oracle VM Serverでは、マシンをリセットしてフェンシングが行われます。 これは、Oracle VM Serverがクラスタに再度参加する最も速い方法です。

6.9.1.1 x86サーバー・プールのクラスタ関連の問題のトラブルシューティング

サーバー・プールからOracle VM Serverを削除すると、エラーが発生する場合があります。 典型的な例は、OCFS2ベース・リポジトリがサーバー・プールから削除しようとした時点でもまだOracle VM Serverに提示されている場合、またはOracle VM Serverがサーバー・プール・ファイル・システムに対するアクセス権を失ったり、そのOracle VM Serverに対するハートビート機能が失敗したりしている場合です。 次のリストは、このような状況に対処するステップを説明します。

• サーバー・プールからリポジトリを削除する際に、サーバーに提示されているリポジトリが存在しないことを確認します。 これが問題の原因である場合には、通常、表示されるエラーにOCFS2ファイル・システムがまだ存在していることが示されます。 この情報の詳細は、『Oracle VM Managerユーザーズ・ガイド』のリポジトリの提示または非提示に関する項を参照してください。

• プール・ファイル・システムが原因で削除操作が失敗する場合は、アンマウント時にプール・ファイル・システムで他のプロセスが動作していた可能性があります。 後でOracle VM Serverの削除を試行してください。

• 新しくインストールされたOracle VM Managerのインスタンスにあるクラスタリングされたサーバー・プールからサーバーを削除しようとすると、ご使用の環境でサーバー・プールが検出されて以降ファイル・サーバーがリフレッシュされていない可能性があります。 Oracle VM Serverを削除する前に、記憶域上で、すべての記憶域とすべてのファイル・システムをリフレッシュしてみてください。

• サーバーが残りのサーバー・プールまたはサーバー・プール・ファイル・システムのある記憶域とのネットワーク接続を失ったためにOracle VM Serverをサーバー・プールから削除できない場合、通常、疑いのあるサーバーに対して重大なイベントが生成されます。 疑いのあるOracle VM Serverに対して生成された重大なイベントを確認してください。 詳細は、『Oracle VM Managerユーザーズ・ガイド』のイベント・パースペクティブに関する項を参照してください。 これらのイベントが確認されれば、再度サーバー・プールからサーバーを削除してみることができます。 ほとんどの場合、重大なイベントを確認した後にはサーバー・プールからのサーバーの削除は正常に行われますが、削除プロセス中にいくつかの警告が生成される場合があります。 サーバーがサーバー・プールから削除されたら、サーバーで発生している可能性のあるネットワークまたはストレージのアクセスの問題を解決する必要があります。

• サーバーにまだ記憶域へのアクセスの問題があり、すべての重大なイベントが確認されてもまだサーバー・プールから削除できない場合、サーバーを再起動してクラスタに正しく再結合できるようにしてから再度削除してみてください。

• サーバー・プールのファイル・システムがなんらかの理由で壊れた場合、または古くなったクラスタの残骸がサーバーに残っている場合、サーバー・プールを完全に消去して最初から再構築する必要があります。 これには、通常、クラスタ内の各Oracle VM Serverで一連の手動ステップを実行する必要があり、これはOracle Supportの支援のもとに実行する必要があります。

6.9.2 SPARCサーバー・プールのクラスタリング

Oracle OCFS2ファイル・システムは、SolarisではなくLinuxに対応しているため、SPARCサーバー・プールでこのファイル・システムを使用して、クラスタリング機能を実装することはできません。 したがって、SPARCサーバー・プールのクラスタリングは、NFS記憶域を使用してクラスタ・ファイル・システムをホストすることに制限され、物理ディスクには実装できません。 SPARCサーバー・プールのクラスタリングでは、追加のパッケージを利用しますが、このパッケージは、サーバー・プール内のOracle VM Serverごとに、制御ドメインにインストールする必要があります。 このパッケージには、クラスタを機能させるのに使用される分散ロック・マネージャ(DLM)が含まれます。 このパッケージのインストールの詳細は、『Oracle VMインストレーションおよびアップグレード・ガイド』の分散ロック・マネージャ(DLM)のインストールに関する項を参照してください。

SPARCサーバー・プールのクラスタリングの実行に使用されるDLMパッケージは、Linux上のOCFS2内で使用されるツールの一部ですが、実際のOCFS2ファイル・システム自体を実行します。 DLMパッケージは次のとおりです。

• 稼働しているサーバーを検出するためのディスク・ハートビート

• ノード間の通信のためのネットワーク・ハートビート

• クラスタ内のサーバーによる共有ディスク・リソースのロックおよび解放を可能にする分散ロック・マネージャ(DLM)

SPARCとx86でのクラスタリングの唯一の主な違いは、クラスタ・ファイル・システムをホストする場合にSPARCインフラストラクチャで使用可能な共有ディスクのタイプが制限されるかどうかです。 OCFS2を使用しない場合、クラスタリングは、共有アクセスを可能にするために、すでに構築したファイル・システムによって異なるため、この目的ではNFSのみがサポートされます。 x86環境と異なり、SPARCサーバー・プール・ファイル・システムをホストするのにNFSが使用されてる場合、OCFS2ディスク・イメージはNFS共有に作成されません。 かわりに、クラスタ・データがNFSファイル・システム自体に直接格納されるだけです。

この情報を考慮すると、6.9.1項「x86サーバー・プールのクラスタリング」の説明の大部分は、SPARCでのクラスタリングにも同様に適用されまが、実装ではOCFS2は使用されません。

注意しておくべき最後の点は、SPARCサーバー・プールのクラスタリングがサポートされるのは、サーバー・プール内のすべてのOracle VM Serverに単一の制御ドメインが構成されている場合のみです。 複数のサービス・ドメインの使用を決定している場合は、クラスタ化されていないサーバー・プールを構成する必要があります。 詳細は、6.10項「クラスタ化されていないサーバー・プール」を参照してください。

6.10 クラスタ化されていないサーバー・プール

サーバー・プールを作成するときに、プール内のサーバーがクラスタの一部であるかどうかを指定します。 ほとんどの場合は、クラスタ化されたサーバー・プールを作成します。 プール内のすべてのサーバーがリポジトリとしてNFS共有のみを使用する場合は、クラスタ化されていないプールを作成できます。 Oracle VM Serverが共有物理ディスク上のリポジトリにもアクセスする場合、これらのサーバーはクラスタ化されたサーバー・プールの一部である必要があります。 クラスタ化されていないサーバー・プールは、SPARC環境では一般的であり、この環境では、複数のサービス・ドメインの使用により、クラスタリングが妨げられますが、フォルト・トレランスと堅牢性に優れたプラットフォームを提供します。

図6.2「NFS記憶域のみを使用する、クラスタ化されていないサーバー・プール」は、クラスタ化されていない構成のサーバー・プール(NFS記憶域上のリソースへの共有アクセスがあり、サーバーのHA機能がない)を示しています。

図6.2 NFS記憶域のみを使用する、クラスタ化されていないサーバー・プール

クラスタ化されていないサーバー・プールでは、サーバー・プール・ファイル・システムは不要です。

クラスタ化されていないサーバー・プールでは、そのサーバーでデプロイされている仮想マシンに対してHAがサポートされません。 サーバーで障害が発生した場合、このサーバー上の仮想マシンは、このサーバー・プール内のサーバーで、または、場合によっては、障害が発生したサーバーの仮想マシンをデプロイするのに必要なリポジトリに別のサーバー・プールがアクセスできる場合は、そのサーバー・プール内のサーバーで、手動で再起動する必要があります。 クラスタ化されていないプール内のサーバー間のライブ・マイグレーションは、これらのサーバーのCPUアフィニティが同じ(同じファミリおよびタイプのCPU)である場合はサポートされます。

ノート

クラスタ化されていないサーバー・プールのクラスタ化されたサーバー・プールへの変換は、リリース3.4のOracle VMではサポートされません。

6.11 高可用性(HA)の仕組み

Oracle VMには、高可用性(HA)機能が組み込まれています。 環境に存在するOracle VM Managerは1つだけですが、重要な情報は管理対象の複数のサーバーに分散されるため、障害発生時にOracle VM Managerとそのインフラストラクチャ・データベースを再構築することができます。 仮想マシンのHAでは、Oracle VM Serverをクラスタ化できるので、1台のサーバーで障害が発生した場合、すべての仮想マシンのデータはOracle VM Serverに直接格納されているのではなく共有記憶域に格納されているため、仮想マシンを自動的に別のサーバーに移行できます。 予想可能な障害またはスケジュールされたメンテナンスが発生した場合、仮想マシンは、ライブ・マイグレーションを使用してサーバー・プールの他のメンバーに移動できます。

また、Oracle VMではHAネットワークおよび記憶域がサポートされますが、これらの構成はシステム管理者によってOracle VM Managerの外(RAID、マルチパスなど)に実装される必要があります。

HAを設定すると、仮想マシンの安定した可用性を実現できます。 HAが構成されている場合にOracle VM Serverが再起動または停止されると、そのOracle VM Serverで実行されている仮想マシンは、別のOracle VM Serverで再起動されるか、別のOracle VM Serverに移行されます。

また、HAはヒュージページ・ルールよりも優先されます。 たとえば、2台のサーバーを実行しているサーバー・プールがあるとします。 サーバーAで実行している仮想マシンでヒュージページを有効にします。 サーバーBで実行している仮想マシンでは、ヒュージページを有効にしません。 また、両方のサーバーのすべての仮想マシンでHAを有効にします。 サーバーAまたはサーバーBのいずれかが実行を停止すると、仮想マシンは、まだ実行中のサーバーに移行されます。 この移行は、ヒュージページの設定が異なる仮想マシンが同じサーバーで実行されないようにするルールに関係なく、行われます。

インバウンド・マイグレーション・ロック機能をOracle VM Serverに設定している場合、Oracle VM Managerでは、そのサーバーに新しい仮想マシンを作成したり、移行したりしませんが、サーバーですでに実行されている仮想マシンは、サーバー・プール内の他のOracle VM Serverに移行される場合があります。

ノート

サーバーにHAを構成している場合、フェイルオーバー発生すると、インバウンド・マイグレーション・ロック機能は、インバウンド・マイグレーションからサーバーを保護しません。

インバウンド・マイグレーション・ロック機能の使用の詳細は、7.12項「仮想マシンをどのように保護できるか」を参照してください。

HAの実装の前提条件は次のとおりです。

• サーバー・プールには、複数のOracle VM Serverを含める必要があります。 HAは、スタンドアロンのOracle VM Serverでは実装できません。

• サーバー・プールはクラスタ化される必要があります。

• すべてのOracle VM ServerがOracle VM Serverリリース3.0以上である必要があります。

• ライブ・マイグレーションを成功させるには、Oracle VM Serverの各インスタンスのリリース・バージョンを同じにする必要があります。 Oracle VM Serverのインスタンスのリリース・バージョンが、仮想マシンが実行されているOracle VM Serverのリリース・バージョンよりも前の場合、仮想マシンでは、そのインスタンスにライブ・マイグレーションできません。 この条件により、HAが正常に機能しなくなる場合があります。

HAを使用するには、図6.3「HAの有効化」に示すとおり、HAを最初にサーバー・プールで有効にし、次にすべての仮想マシンで有効にする必要があります。 HAをサーバー・プールで有効にしてから仮想マシンに対して有効にすると、Oracle VM Serverが停止したり、Oracle VM Serverで障害が発生した場合に、別の使用可能なOracle VM Serverで仮想マシンの移行または再起動が行われます。 HAは、サーバー・プールおよび仮想マシンの両方に対して有効にする必要があります。

図6.3 HAの有効化

サーバー・プール・クラスタを自動的に構成してサーバー・プールでHAを有効にするには、クラスタリングを有効にしてサーバー・プールを作成する必要があります。 サーバー・プールの作成の詳細は、『Oracle VM Managerユーザーズ・ガイド』のサーバー・プールの作成に関する項を参照してください。

仮想マシンでHAを有効にするには、仮想マシンの作成時に高可用性を有効にする必要があります。 仮想マシンの作成および編集の詳細は、『Oracle VM Managerユーザーズ・ガイド』の仮想マシンの作成および仮想マシンの編集に関する項を参照してください。

次の条件はHA環境に適用されます。

• HAが有効で、Oracle VM Serverを再起動、停止または削除する場合、最初に、HAが有効な実行中の仮想マシンを別の使用可能なOracle VM Serverに移行する必要があります。 仮想マシンの移行の詳細は、『Oracle VM Managerユーザーズ・ガイド』の仮想マシンの移行または移動に関する項を参照してください。

• 使用可能なOracle VM Serverがない場合、HA対応の仮想マシンは停止され(電源オフ)、Oracle VM Serverが使用可能になると再起動されます。

• Oracle VM Serverで障害が発生すると、実行中のすべての仮想マシンは、別の使用可能なOracle VM Serverで自動的に再起動されます。 これは、クラスタ内のOracle VM Serverでクラスタ・タイムアウトが発生した後に行われます。 詳細は、6.9項「サーバー・プール・クラスタ仕組み」を参照してください。

• Oracle VM Serverで障害が発生し、他のOracle VM Serverが使用可能ではない場合、実行中のすべての仮想マシンは、Oracle VM Serverが使用可能になったときに再起動されます。

• HA対応の仮想マシンをゲスト・オペレーティング・システム内から停止すると、仮想マシンが自動的に再起動します。 HA対応の仮想マシンを停止するには、Oracle VM Managerから仮想マシンを停止する必要があります。 『Oracle VM Managerユーザーズ・ガイド』の仮想マシンの停止に関する項を参照してください。

図6.4「Oracle VM Serverでの障害発生時に有効なHA」は、Oracle VM Serverでの障害発生と、サーバー・プールの他のOracle VM Serverでの仮想マシンの再起動を示しています。

図6.4 Oracle VM Serverでの障害発生時に有効なHA

ha-fails.pngの大きなイメージを表示するにはクリックしてください

Firefoxサーバー

HA構成をテストして、実際の障害時に適切に構成されていることを確認する必要があります。

図6.5「Oracle VM Serverでの再起動または停止時に有効なHA」は、Oracle VM Serverでの再起動と停止、およびサーバー・プールの他のOracle VM Serverへの仮想マシンの移行を示しています。 この例では、仮想マシンが稼動中のため、ライブ・マイグレーションは実行できますが、仮想マシンは動作を継続し中断されません。 ライブ・マイグレーションはHAの機能ではありませんが、HAとともにまたは独立して使用することができます。 ライブ・マイグレーションの詳細は、『Oracle VM Managerユーザーズ・ガイド』の仮想マシンの移行または移動に関する項を参照してください。

図6.5 Oracle VM Serverでの再起動または停止時に有効なHA

ha-reboot.pngの大きなイメージを表示するにはクリックしてください

HAを有効化しなかった場合、Oracle VM Serverを停止する前に、(標準の仮想マシンの移行またはライブ・マイグレーションのいずれかを使用して)すべての仮想マシンを別のOracle VM Serverに移行するか、サーバーをメンテナンス・モードに設定することによってそれらを自動的に移行させる必要があります。

6.12 サーバー・プールのポリシーとは

• 6.12.1 分散リソース・スケジューラ(DRS)
• 6.12.2 分散電源管理(DPM)
• 6.12.3 DRS/DPMネットワーク・ポリシー

負荷を管理して電力消費量を抑えることには、仮想化にとって2つの大きな利点があります。 サーバーの負荷がすでに大きくなっている場合は、サーバーで実行されている仮想マシンを、サーバー・プール内で使用率の低いサーバーに分散することをお薦めします。 同様に、使用率の低い時間は、未使用のサーバーの電源を切って、電力消費量を抑えられるように、仮想マシンをできるだけ少ない数のサーバーに統合することをお薦めします。

Oracle VMでは、このような種類の動作を自動的に処理する機能があります。 この機能は、サーバー・プール・ポリシーを作成することで処理されます。 サーバー・プール・ポリシーにより、サポートする様々なオプションを定義できます。 これらは次のように定義されます。

• 分散リソース・スケジューリング: ロード・バランシングの形式でリソース使用率を最適化する場合に使用します。 詳細は、6.12.1項「分散リソース・スケジューリング(DRS)」を参照してください。

• 分散電源管理: 仮想マシンを少ない数のサーバーに統合してエネルギー消費量を抑える場合に使用します。 詳細は、6.12.2項「分散電源管理(DPM)」を参照してください。

これらの動作をサーバー・プール内でトリガーするネットワーク使用率のしきい値を設定することで、サーバー・プール内で使用可能なネットワークに、これらのポリシーを適用することもできます。 この詳細は、6.12.3項「DRS/DPMネットワーク・ポリシー」を参照してください。

Oracle VM Serverで新しい仮想マシンを許可しないように、インバウンド・マイグレーション・ロック機能を設定している場合は、仮想マシンを移行したり、サーバーに新しい仮想マシンを作成しないように、サーバー・プール・ポリシーが制限されます。 インバウンド・マイグレーション・ロック機能の使用の詳細は、7.12項「仮想マシンをどのように保護できるか」を参照してください。

これらのサーバー・プール・ポリシーのいすれかを有効にするには、すべてのOracle VM Serverでリリース番号が一致している必要があります。 Oracle VM Serverのリリース番号が一致していない状態が長時間になると、Oracle VM Serverで実行されているリリース番号の大きい仮想マシンを、リリース番号の小さいOracle VM Serverにライブ・マイグレーションできなくなります。 これらのポリシーでは、移行の試行前にチェックが実行され、ターゲット・サーバーのリリース番号が一致していない場合は、移行できないようにします。 したがって、サーバーのバージョンが混在している環境では、サーバー・プール・ポリシーが実装されない場合があります。

6.12.1 分散リソース・スケジューラ(DRS)

分散リソース・スケジューラ(DRS)によって、サーバー・プールの仮想マシンのリソース使用率が最適化されます。 指定した期間、指定したCPUしきい値をいずれかのOracle VM Serverが超えた場合は、DRSによって、実行中の仮想マシンがサーバー・プール内の別のOracle VM Serverに自動的に移動されます。 DRSでは、すべてのOracle VM Serverおよびすべての仮想マシンのパフォーマンス・データが継続的にサンプリングされます。

仮想マシンの移動はポリシー駆動型です。 しきい値に達すると、実行中の仮想マシンは、Oracle VM ManagerによってOracle VM Server間でライブ・マイグレーションされ、停止時間は発生しません。 Oracle VM Managerでは、サーバー・プールごとにDRSしきい値を指定して、ポリシーに含めるOracle VM Serverを選択できます。

サーバー・プール内のDRSの有効化および構成の詳細は、『Oracle VM Managerユーザーズ・ガイド』のサーバー・プール・ポリシーの定義または編集に関する項を参照してください。

さらに、サーバー・プール・レベルですべての仮想マシンの既定の起動ポリシーを定義することができます。 デフォルトのVM開始ポリシーは、DRSおよびDPMアルゴリズムに基づいてVMの配置を決定する「ベスト・サーバー」です。 リリース3.4.5以降では、新しいVM開始ポリシー・オプション「バランス・サーバー」を使用できます。これにより、プール内のサーバー間でCPUとメモリーの使用率が最適化されます。 各仮想マシンの構成内でデフォルトのポリシーを上書きすることができます。

VM開始ポリシーの詳細については、「Oracle VM Managerユーザー・ガイド」の「サーバー・プールの作成」を参照してください。

6.12.2 分散電源管理(DPM)

分散電源管理(DPM)は、リソース使用率が比較的低い期間がある場合に、より少ない数のOracle VM Serverで統合の比率を増加させるために使用されます。 DPMによって、使用率の低いOracle VM Serverから仮想マシンが動的に移行されます。 仮想マシンが実行されていないOracle VM Serverがある場合は、再度必要になるまでそのOracle VM Serverを停止して電力を節約できます。

DPMの目的は、必要最小限の数のOracle VM Serverのみが実行されるようにすることです。 定期的なチェックでOracle VM ServerのCPU使用率がユーザーが設定したレベルを下回っていることが判明した場合、仮想マシンは同じサーバー・プール内の他のOracle VM Serverにライブ・マイグレーションされます。

すべての仮想マシンが移行されると、Oracle VM Serverは停止されます。

Oracle VM ServerがDPMポリシーのCPUしきい値を超える場合は、Oracle VM Managerによって、ビジー状態のOracle VM Serverからの仮想マシンの移行先となる他のOracle VM Serverが検索されます。 電源が入ったOracle VM Serverが使用可能でない場合は、Wake-On-LAN機能を使用して、Oracle VM Managerによって、Oracle VM Serverが検索されて起動されます。 そのOracle VM Serverが実行されていると、Oracle VM Managerによって、ビジー状態のOracle VM Serverから、新しく起動されたOracle VM Serverに仮想マシンがオフロードされ、全体がロード・バランスされます。 DPMに追加されたすべてのサーバーで、専用の管理ネットワークに接続する物理ネットワーク・インタフェースに対して、BIOSのWake-On-LANが有効になっている必要があります。

Oracle VM Managerでは、サーバー・プールごとにDPMしきい値を指定して、ポリシーに含めるOracle VM Serverを選択できます。

サーバー・プール内のDPMの有効化および構成の詳細は、『Oracle VM Managerユーザーズ・ガイド』のサーバー・プール・ポリシーの定義または編集に関する項を参照してください。

6.12.3 DRS/DPMネットワーク・ポリシー

DRSポリシーおよびDPMポリシーは、サーバー・プールのOracle VM Serverが使用するネットワークにも設定できます。 Oracle VM Serverが使用するネットワークがそのしきい値を超えると、使用されるリソースのバランスをとるために(DRS)、または使用される電力を削減するために(DPM)、仮想マシンが他のOracle VM Serverに移行されます。 Oracle VM Server上の各ネットワークにしきい値を設定できます。 しきい値は、受信データまたは送信データに適用されます。 しきい値が50%に設定されている場合、Oracle VM Serverのそのネットワーク上の受信または送信トラフィックがネットワークの理論上の容量の50%を超えると、Oracle VM Serverはしきい値を超えたとみなされます。 Oracle VM Server上のネットワークの理論上の容量は、Oracle VM Serverの物理イーサネット・アダプタのポート速度に等しくなります。 ネットワークがフェイルオーバー構成でボンディングされている場合、ポートの容量はいずれかのイーサネット・アダプタのポート速度に等しくなります。 ネットワークがリンクの集約を使用してOracle VM Serverでボンディングされている場合、ネットワークの容量はボンディングされたイーサネット・アダプタの速度の合計に等しくなります。

サーバー・プールのポリシーを設定する際、DRSおよびDPMのネットワーク・ポリシーを設定します。 サーバー・プール内のネットワークDRSおよびDPMのポリシーの有効化および構成の詳細は、『Oracle VM Managerユーザーズ・ガイド』のサーバー・プール・ポリシーの定義または編集に関する項を参照してください。

そのネットワークがサーバー・プール内のどのサーバーでも使用されていない場合でも、ネットワーク・ポリシーをサーバー・プールに定義できることを理解することが重要です。 この場合、ポリシーは無視されるだけですが、ネットワークに接続されたサーバーが後でサーバー・プールに追加されると、そのサーバーに接続されているネットワークで、このポリシーが自動的に有効になります。 サーバー・プールにネットワーク・ポリシーを定義し、ネットワークに接続されたすべてのサーバーを後で削除しても、ポリシーはサーバー・プール内でまだ適用されている状態です。 したがって、ネットワークの動作に影響する古いポリシーが残っている場合もあるため、サーバー・プールにサーバーを追加する場合は、サーバー・プール・ポリシーを常にチェックすることをお薦めします。

6.13 アンチアフィニティ・グループとは

アンチアフィニティ・グループでは、特定の仮想マシンが常に違うOracle VM Server.で実行される必要があることを指定します。 アンチアフィニティ・グループは、サーバー・プール内のすべてのOracle VM Serverに適用されます。 アンチアフィニティ・グループは、環境で冗長性や特定のアプリケーションのロード・バランシングを構築する場合に設定します。

仮想マシンをアンチアフィニティ・グループに追加する場合に、そのグループに同じOracle VM Server上で実行中の仮想マシンがすでに存在するときは、ジョブが中断され、その仮想マシンはグループに追加されません。 仮想マシンをそのアンチアフィニティ・グループに追加するには、別のOracle VM Serverに移行した後に、グループに追加します。

Oracle VM Serverで新しい仮想マシンを許可しないように、インバウンド・マイグレーション・ロック機能を設定している場合、設定したアンチアフィニティ・グループでは、仮想マシンを移行したり、サーバーに新しい仮想マシンを作成することが制限されます。 インバウンド・マイグレーション・ロック機能の使用の詳細は、7.12項「仮想マシンをどのように保護できるか」を参照してください。

アンチアフィニティ・グループの作成、編集および削除の詳細は、『Oracle VM Managerユーザーズ・ガイド』のアンチアフィニティ・グループ・パースペクティブに関する項を参照してください。

6.14 サーバー・プロセッサの互換性グループとは

仮想マシンのライブ・マイグレーションを成功させるには、Oracle VM Managerで、移行元コンピュータと移行先コンピュータのプロセッサ・ファミリおよび型番が同じである必要があります。 サーバー・プロセッサの互換性グループは、互換性のあるプロセッサを持つOracle VM Serverのグループで、あるOracle VM Serverで実行中の仮想マシンを別のOracle VM Serverに安全に移行して、継続して実行できます。 Oracle VM Managerにはサーバー・プロセッサの互換性のルールが含まれていますが、プロセッサのファミリおよびモデルが同じでない場合に、仮想マシン内で実行されるアプリケーションが移行後も存続できると確認できる場合、よりスムーズな移行を実現できるように、カスタムの互換性グループを作成することができます。 互換性のないプロセッサ間でライブ・マイグレーションが試行された場合、エラー・メッセージが表示され、移行が失敗します。 したがって、カスタムサーバー・プロセッサの互換性グループに属するすべてのサーバー間で移行を完全にサポートできることを必ず確認してください。

すべてのOracle VM Serverは検出時にデフォルトのサーバー・プロセッサの互換性グループに追加されます。 Oracle VM Managerに固有の新規のプロセッサがOracle VM Serverに含まれている場合、そのOracle VM Serverが検出されると、デフォルトのサーバー・プロセッサの互換性グループが作成されます。 これは、ライブ・マイグレーションと高可用性の機能をエラーを発生することなく安全に実行できるように、自動的行われます。 デフォルトのサーバー・プロセッサの互換性グループを直接削除または編集しないようにしてください。

各サーバー・プロセッサの互換性グループには、1つ以上のサーバー・プールのメンバーであるOracle VM Serverをそれぞれ含めることができます。 1つのOracle VM Serverは複数のサーバー・プロセッサの互換性グループに含めることができます。 サーバー・プロセッサの互換性グループを作成し、必要に応じて含めるOracle VM Serverを選択することができます。 作成できるサーバー・プロセッサの互換性グループの数に制限はありません。 サーバー・プロセッサの互換性グループを作成する場合は、ライブ・マイグレーションと他の高可用性機能に加えることができるサーバーを定義していることを理解することが重要です。 互換性のないプロセッサを持つサーバーが含まれるサーバー・プロセッサの互換性グループを作成すると、ライブ・マイグレーションと他の多くの機能が環境内で機能しなくなる場合があります。 したがって、ライブ・マイグレーションをグループ内のすべてのサーバーで実行できると確認している場合にのみ、サーバー・プロセッサの互換性グループを作成してください。

サーバー・プロセッサの互換性グループは、仮想マシンのライブ・マイグレーションの正常な実行に使用できるサーバーを定義する場合に使用されるため、ライブ・マイグレーションは、リリース番号が一致するサーバー間でのみサポートされることを再度確認してください。 サーバーのバージョンが混在している環境の場合、すべてのサーバーを同じリリースにアップグレードするプロセス中でない場合は、これらのサーバーを同じ互換性グループに含めないでください。

サーバー・プロセッサの互換性グループの構成の詳細は、『Oracle VM Managerユーザーズ・ガイド』のサーバー・プロセッサの互換性パースペクティブに関する項を参照してください。

Copyright © 2014, 2021 Oracle and/or its affiliates. 法律上の注意点