機械翻訳について

第3章 記憶域の理解

目次

記憶域は、Oracle VM内のこのような基本的なコンポーネントであり、それに関する多くのコンポーネントについては、Oracle VMのドキュメントでは説明されていないため、この章では、記憶域インフラストラクチャの概要と、Oracle VM内でどのように使用されるかについて的を絞って詳しく説明します。 ここで提示する概念の多くは、Webベースのユーザー・インタフェースやOracle VM Managerコマンドライン・インタフェースなど、Oracle VM Managerで提供されるインタフェースを使用して、記憶域の構成中に役立てることができるように構成されています。 記憶域コンポーネントの簡単な概要は、2.6.1項「記憶域」を参照してください。

Oracle VM内で記憶域がどのように使用されるか、およびサポートされる記憶域型の概要は、3.1項「Oracle VMに使用される記憶域」および3.2項「使用可能な記憶域のタイプ」を参照してください。

Oracle VMが記憶域にアクセスする特定の方法では、プラグインが使用されますが、オラクル社では、記憶域の異なるカテゴリおよびタイプごとにStorage Connectプラグインを作成することによって、記憶域の構成および統合をできるだけ柔軟性が高くモジュール化されたものとしています。 これらのプラグインの詳細は、3.4項「それぞれの記憶域型がどのように接続されるか」を参照してください。

記憶域リポジトリのコンテンツ(仮想マシン・テンプレート、ISOファイル、仮想アプライアンスなど)の管理および使用の詳細は、3.9項「仮想マシン・リソースが配置される場所」を参照してください。

Oracle VM記憶域の概念について十分に理解したら、記憶域インフラストラクチャの計画を開始する前に、3.10項「記憶域の構成のガイドラインの有無」を時間をかけて一読してください。 これにより、記憶域構成が十分に計画され、一般的な間違いを回避できます。

3.1 Oracle VMで使用される記憶域

Oracle VM内の記憶域は、様々な用途に使用されます。 これらは、次の2つの主要なカテゴリにグループ化できます。

  • Oracle VM Serverクラスタリング・リソース。

  • Oracle VM仮想マシン・リソース(仮想アプライアンス、テンプレート、ISO、ディスク・イメージ、構成データなど)。

最初のインスタンスでは、デプロイメント内で使用されるOracle VM Serverクラスタリング・リソースが共有記憶域に配置されることが絶対必要です。 共有記憶域は、サーバー・プール内のすべてのOracle VM Serverインスタンスで使用可能にすることができる記憶域メカニズムです。 プール内のコンポーネントの状態および可用性に関するデータをプール内のすべてのメンバーで共有する必要があるため、これが要件になります。 Oracle VMで提供されるクラスタリング機能を利用しないことで、共有記憶域の要件を回避できますが、これは一般的でない構成になり、各種の共有記憶域のテクノロジに対してOracle VMプロバイダから提供されるサポートの範囲から、少なくともこの目的には、なんらかの形の共有記憶域を使用することを強くお薦めします。

一般には、Oracle VM仮想マシン・リソースで共有記憶域も使用することを強くお薦めします。 これらのリソースの共有記憶域を使用することで、プール内の様々なサーバー間で仮想マシンを簡単に移行したり、再起動できます。 仮想マシン・リソースのプロビジョニングの目的で、特定のOracle VM Serverに接続される物理ディスクなど、デプロイメント内のローカル記憶域を使用できますが、ライブ・マイグレーションなどの機能が必要な場合は、制限が適用されます。 さらに、共有記憶域を使用するように選択すると、Oracle VMデプロイメントのデータ・センター内の記憶域の管理に必要なオーバーヘッドが大幅に軽減されます。

仮想マシンの実際のプロビジョニングは、通常は記憶域リポジトリを作成することで行われます。 Oracle VMの用語で、リポジトリとは、様々なリソースを簡単に配置し、仮想マシンの作成、クローニングまたは実行の用途に使用できるように、特定の方法で論理的に構造化されたファイル・システムになります。 リポジトリがNFS共有に配置されている場合、リポジトリに必要なディレクトリ構造は、共有を介して公開される既存のファイル・システムに作成されます。 ISCSIまたはファイバ・チャネルを介して、SANハードウェアで公開される共有物理ディスクでは、ディスクまたはLUNがOCFS2ファイル・システムでフォーマットされ、ディレクトリ構造がこの上部に作成されます。 この状況では、ファイル・システムが複数のOracle VM Serverによって同時にアクセスされるため、OCFS2が使用されます(ほとんどのファイル・システムでは同時アクセスを処理できませんが、OCFS2は処理するように明示的に設計されています)。 OCFS2はSPARCでは使用できないため、iSCSIおよびファイバ・チャネル・ディスクを使用して、SPARCベースのOracle VM Serverにアクセス可能なリポジトリをホストすることはできません。 SPARCベースのサーバーでは、NFSサーバー共有を常に使用して、リポジトリをホストするようにしてください。

リポジトリは、ローカル記憶域ディスクに作成することもできます。 これは一般に、このようなリポジトリ内のデータは、ディスクが接続されるOracle VM Serverで実行される仮想マシンにのみ使用できることを意味します。 ただし、サーバー・プール内のOracle VM Serverがx86ベースの環境では、ファイル・システムはOCFS2を使用してフォーマットされ、プール内のOracle VM Server間で、仮想マシン(ローカル記憶域外で実行)のライブ・マイグレーションを可能にする機能が提供されています。

SPARCベースのサーバーでは、ZFSおよびSASディスクは、ローカル記憶域ディスクとして扱われ、これらのディスクで実行される仮想マシンのライブ・マイグレーションは機能しません。

3.2 使用可能な記憶域のタイプ

Oracle VMは、様々な記憶域型を使用できるように設計されているため、構成をニーズに適応できます。 ハードウェア設定が限られるか、フルラックのサーバーがあるかに関係なく、またはテストと一時的な内部使用のためにインストールを実行するか、すべての領域で高可用性が必要な本番環境を設計するかに関係なく、Oracle VMでは適切な記憶域ソリューションのサポートが提供されます。

Oracle VMでは、汎用のStorage Connectプラグインとベンダー固有のStorage Connectプラグインの両方を利用し、次の型の記憶域を使用できます。

重要

Oracle VMでは、同じストレージ・デバイスにアクセスするための混在プロトコルをサポートしていません。 したがって、ストレージ・デバイスへのアクセスにファイバ・チャネルを使用している場合は、SCSIプロトコルを使用して同じデバイスにアクセスしないでください。

通常、Oracle VM Serverの記憶域として使用されるディスクのファイル・システムは、OCFS2 (Oracle Cluster File System)を使用してフォーマットされます。 この唯一の例外はNFSですが、この理由は、このファイル・システムは、基本的に複数のシステムで一度にアクセスできるように設計されているためです。 OCFS2を使用すると、複数のシステムによる同時アクセスをファイル・システムで適切に処理できるようになります。 OCFS2はOracleによって開発され、メインストリームLinuxカーネル内に統合されているため、優れたパフォーマンスを発揮し、Oracle VMデプロイメント内で完全に統合されます。 OCFS2は、サーバー・プールのクラスタリングの実装に使用される基本的なコンポーネントでもあります。 この詳細は、3.8項「サーバー・プールのクラスタリングに記憶域がどのように使用されるか」を参照してください。 OCFS2はSPARCでは使用できないため、SPARCベースのサーバー・プールのクラスタリングまたは共有リポジトリのホスティングのサポートに使用できるのはNFSのみです。

HAまたはライブ・マイグレーションを有効にするには、すべてのOracle VM Serverが同じ記憶域リソースにアクセスできることを確認する必要があります。 ライブ・マイグレーションおよび仮想マシンHAの再起動の場合は特に、Oracle VM Serverが同じサーバー・プールの一部である必要もあります。 クラスタ化されたサーバー・プールは、失敗や後続のサーバー・ロールの変更などの場合に、サーバー・プール情報が格納および取得される共有ファイル・システムへのアクセスが必要となることにも注意してください。 x86環境では、サーバー・プールのファイル・システムは、NFS共有上、またはSANサーバーのLUN上に配置できます。 SPARC環境では、サーバー・プールのファイル・システムはNFS共有のみに配置できます。

3.2.1 ローカル記憶域

ローカル記憶域は、Oracle VM Serverにローカルにインストールされているハード・ディスクで構成されます。 SPARCの場合、これにはSASディスクとZFSボリュームが含まれます。

デフォルトのインストールでは、Oracle VM Serverがインストール・ディスク上の未使用の領域を検出し、ディスクを再パーティション化して、この領域をローカル記憶域に使用できるようにします。 パーティションおよびデータが存在しないかぎり、デバイスはRAWディスクとして検出されます。 ローカル・ディスクを使用して、仮想マシンのディスクとして論理記憶域ボリュームをプロビジョニングしたり、記憶域リポジトリをインストールしたりできます。

Oracle VMリリース3.4.2では、NVM Express (NVMe)デバイスのサポートが追加されました。 Oracle VMデプロイメントでNVMeデバイスをローカル記憶域として使用すると、Oracle VM Serverがデバイスを検出して、Oracle VM Managerを介して提示します。

Oracle VM Server for x86

  • NVMeデバイス全体を記憶域リポジトリとして、または単一の仮想マシンの物理ディスクに使用するには、NVMeデバイスをパーティション化しないでください。

  • NVMeデバイスを複数の物理ディスクにプロビジョニングするには、デバイスがインストールされるOracle VM Serverでパーティション化してください。 NVMeデバイスがパーティション化されると、Oracle VM Managerによって、各パーティションがデバイス全体ではなく、物理ディスクとして表示されます。

    NVMeデバイスは、Oracle VM環境の外部でパーティション化する必要があります。 Oracle VM Managerでは、NVMeデバイスをパーティション化する機能は提供されていません。

  • NVMデバイスは、パーティションがデバイスに存在しない場合に検出できます。

  • Oracle VM ServerがNVMeデバイスにインストールされている場合、Oracle VM Serverは、そのNVMeデバイスの他のパーティションを検出しません。

Oracle VM Server for SPARC

  • Oracle VM Managerでは、NVMeデバイスの個々のパーティションを表示せず、1つのデバイスのみを表示します。

    Oracle VM Server for SPARCを使用している場合は、NVMeデバイスに記憶域リポジトリを作成することをお薦めします。 これにより、必要に応じた数の仮想ディスクを記憶域リポジトリに作成できます。 ただし、論理記憶域ボリュームを仮想マシン・ディスクに作成する場合は、ZFSボリュームをNVMeデバイスに手動で作成する必要があります。 「Oracle VM管理者ガイド」の「NVMe DeviceでのZFSボリュームの作成」を参照してください。

ローカル記憶域に関する重要な点は次のとおりです。

  • ローカル記憶域は、サーバー・プールのファイル・システムに使用できません。

  • ローカル記憶域は、ディスク・サブシステム用の特別なハードウェアが必要ないため、設定が非常に簡単です。 この設定の仮想化のオーバーヘッドは限られており、ディスク・アクセスは1つの物理サーバー内で内部的であるため、ローカル記憶域ではかなり高いパフォーマンスが得られます。

  • Oracle VM環境では、仮想マシン間でローカル物理ディスクを共有できますが、推奨していません。

  • x86環境でローカル・ディスクに記憶域リポジトリを配置すると、OCFS2ファイル・システムが作成されます。 ローカル・ディスクに記憶域リポジトリを作成する場合には、ディスクにデータやメタデータを含めないでください。 この場合、ディスクに記憶域リポジトリを作成する前に、手動でディスクをクリーンする必要があります。 これは、ddコマンドなどを使用して実行できます。 

    # dd if=/dev/zero of=/dev/disk bs=1M

    diskは、リポジトリを作成するディスクのデバイス名です。

    警告

    この動作は破壊的なため、この動作を行うデバイス上のデータは回復できなくなる場合があります。

  • SPARC環境では、記憶域リポジトリはZFSファイル・システムを使用して作成されます。 ローカル物理ディスクを記憶域リポジトリに使用すると、リポジトリの作成時に、ZFSプールおよびファイル・システムが自動的に作成されます。 ZFSボリュームを使用して、リポジトリをホストすると、ボリュームはZFSファイル・システムに置き換えられ、ファイル・システム内にリポジトリが作成されます。

  • Oracle VMリリース3.4では、x86プラットフォーム上のOCFS2ファイル・システムに組み込まれる機能を使用し、この機能により、ローカル記憶域に仮想ディスクのある、実行中の仮想マシンのライブ・マイグレーションを実行できます。 これらのライブ・マイグレーションにより、仮想マシンの稼働がほとんど中断されなくなります。

    ただし、仮想マシンが仮想ディスクを使用している場合、仮想マシンが停止すると、Oracle VM Managerで仮想マシンをローカル記憶域リポジトリ間で直接移動できなくなります。 この場合は、中間の共有リポジトリを使用して、仮想マシンと仮想ディスクをOracle VM Server間で移動する必要があります。

    ライブ・マイグレーションの詳細、およびローカル記憶域を備えたサーバー間で仮想マシンを移動する場合の制限事項の詳細は、7.7項「仮想マシンがどのように移動または移行されるか」を参照してください。

ローカル記憶域が最も有用な構成は、クラスタ化されていないサーバー・プールに含まれるOracle VM Serverの数が非常に限られている構成です。 ローカル記憶域で記憶域リポジトリを構成することによって(4.4項「リポジトリがどのように管理されるか」を参照)、1つまたは2つのOracle VM Serverで迅速かつ容易にOracle VMの仮想環境を設定でき、すべてのリソース、仮想マシンおよびそのディスクは、ローカルに格納されます。

その場合でも、本番環境でのローカル記憶域の使用には、次のような利点があります。

  • 多くの様々なシステムに配置されているディスク全体にデータを格納すると、バックアップ戦略が複雑になり、データ・センター管理に伴うオーバーヘッドがさらに必要になります。

  • ローカル記憶域は、サーバー・プール内の複数のOracle VM Serverでクラスタ化された設定において柔軟性に欠けています。 ローカル記憶域に配置される、テンプレートやISOなどの他のリソースは、同じサーバー・プール内にある場合でも、Oracle VM Server間で共有できません。

一般に、データ損失を確実に防止する高可用性を必要とする仮想マシンの実行、および重要なデータ用のローカル記憶域には、包括的な冗長性機能を備えた接続ストレージを使用することをお薦めします。

3.2.1.1 SASディスク

SAS (Serial Attached SCSI)ディスクは、Oracle VMデプロイメント内でローカル記憶域として使用できます。 SPARCシステムでは、SASディスクのサポートは、mpt_sas driverを使用するSASコントローラに制限されます。 これは、T3以降では内部SASディスク・サポートがありますが、T2およびT2+で内部SASディスクはサポートされないことを意味します。

Oracle VM Managerでは、ローカルSASストレージのみがサポートされています。 Oracle VMでは、共有SASストレージ(SAS SAN)はサポートされていません(つまり、エキスパンダを使用してSANと同様の動作を有効にするSASディスクは、ローカル・ストレージ・デバイスとしてのみアクセスできます)。 Oracle VM Managerは、検出プロセス時にローカルSASディスクを認識し、ローカル・ファイル・システムとして追加します。 SAS SANディスクは、検出プロセス時に無視され、Oracle VM Managerでの使用にはアクセスできません。

x86ハードウェアで実行しているOracle VM Serverで、SASデバイスが共有またはローカルのどちらかを確認するには、次のコマンドを実行します。 

# ls -l /sys/class/sas_end_device

ローカルSAS: 

lrwxrwxrwx 1 root root 0 Dec 18 22:07 end_device-0:2 ->\
 ../../devices/pci0000:00/0000:00:01.0/0000:0c:00.0/host0/port-0:2/end_device-0:2/sas_end_device/
   end_device-0:2
lrwxrwxrwx 1 root root 0 Dec 18 22:07 end_device-0:3 ->\
../../devices/pci0000:00/0000:00:01.0/0000:0c:00.0/host0/port-0:3/end_device-0:3/sas_end_device/
  end_device-0:3

SAS SAN: 

lrwxrwxrwx 1 root root 0 Dec 18 22:07 end_device-0:0:0 -> \
../../devices/pci0000:00/0000:00:01.0/0000:0c:00.0/host0/port-0:0/expander-0:0/port-0:0:0/
  end_device-0:0:0/sas_end_device/end_device-0:0:0
lrwxrwxrwx 1 root root 0 Dec 18 22:07 end_device-0:1:0 -> \
../../devices/pci0000:00/0000:00:01.0/0000:0c:00.0/host0/port-0:1/expander-0:1/port-0:1:0/
  end_device-0:1:0/sas_end_device/end_device-0:1:0

SAS SANストレージの場合は、デバイス・エントリ内にエキスパンダが含まれることに注意してください。

3.2.2 共有ネットワーク接続ストレージ(NFS)

ネットワーク接続ストレージ(通常、NFS)は、一般的に使用されているファイルベースのストレージ・システムであり、Oracle VM記憶域リポジトリのインストールに非常に適しています。 記憶域リポジトリは、テンプレート、仮想ディスク・イメージ、ISOファイルおよび仮想マシン構成ファイルなど、リソースの様々なカテゴリを含み、これらはすべて、リモートにある、接続されたファイル・システム上のディレクトリ構造にファイルとして格納されます。 これらのリソースのほとんどは、めったに書込みは行われませんが頻繁に読取りが行われるので、NFSはこれらの型のリソースを格納するのに最適です。

Oracle VMでは、サーバーIPまたはホスト名を介してNFS記憶域を検出し、通常はサーバー・プール内のすべてのサーバーに記憶域を提示して、それらが同じリソースを共有できるようにします。 これは、クラスタリングとともに、環境の高可用性を実現するのに役立ち、ロード・バランシングの目的で、またはハードウェア障害によりオフラインにならないように重要な仮想マシンを保護する目的で、仮想マシンをホスト・サーバー間で簡単に移行できます。

NFS記憶域は、Oracle VM Serverのファイル・システムにマウントされるNFSサーバー上の共有の形式でOracle VM Serverに公開されます。 NFS共有のマウントは、NFSが公開されているネットワーク・セグメント内の任意のサーバーで実行できるため、同じプールのサーバー間だけでなく、異なるサーバー・プールでもNFS記憶域を共有できます。

パフォーマンスに関しては、NFSは、論理ボリュームまたはRAWディスクと比較して、仮想ディスクのI/Oで低速になります。 これは、主にファイルベースの特性によります。 ディスク・パフォーマンスを向上させるには、Oracle VMでiSCSIまたはファイバ・チャネルSANの形式でサポートされる、ブロックベースの記憶域の使用を検討する必要があります。

NFSは、クラスタされたサーバー・プールのサーバー・プール・ファイル・システムを格納する場合にも使用されます。 これは、SPARCベースのサーバー・プールで、この目的でサポートされる唯一の共有記憶域機能です。 x86環境では、パフォーマンス上の理由から、iSCSIやファイバ・チャネルなどの代替の共有記憶域が、この目的に一般に推奨されます。

サポートされないNFSサーバー構成

次の構成は、記憶域リポジトリでエラーになるため、Oracle VMではサポートしていません。

1つのNFSサーバーに対する複数のIPアドレスまたはホスト名

複数のIPアドレスまたはホスト名を同じNFSサーバーに割り当てると、Oracle VM Managerは、各IPアドレスまたはホスト名を個別のNFSサーバーとして扱います。

DNSラインドロビン

単一のホスト名が複数のIPアドレス割り当てられるようにDNSを構成すると(ラウンドロビン構成)、記憶域リポジトリがOracle VM Serverファイル・システム上に繰り返しマウントされます。

ネストされたNFSのエクスポート

NFSファイル・システムに、ディレクトリ構造内部に存在する他のファイル・システムがある場合(ネストされたNFSのエクスポート)、最上位レベルのファイル・ディレクトリをNFSサーバーからエクスポートすると、エラーになり、Oracle VM Serverで記憶域リポジトリにアクセスできなくなります。 このシナリオでは、特定のジョブで「OVMRU_002063E No utility server」メッセージが返され、AdminServer.logに書き込まれます。

ネストされたNFSのエクスポートのエラーの解決方法の詳細は、Oracle Supportナレッジ・ベースのDoc ID 2109556.1を参照してください。

3.2.3 iSCSIストレージ接続ネットワーク

インターネットSCSI (iSCSI)を使用すると、記憶域エンティティをクライアント・マシンに接続でき、ディスクはローカル接続されたディスクであるかのように動作します。iSCSIは、イニシエータと呼ばれるもの(クライアント)とターゲット(記憶域プロバイダ)間の既存のIPネットワークを介してSCSIコマンドを転送することによって、この接続を可能にします。

すべてのOracle VM Serverは、iSCSI SANとのリンクを確立する場合に、構成済のネットワーク・インタフェースをiSCSIイニシエータとして使用できます。 次のことは、ユーザーが行います。

  • ストレージ・サーバーによって提供されるディスク・ボリューム(iSCSI LUN)の構成。

  • Oracle VM ManagerによるiSCSIストレージの検出。 検出されると、管理対象外のiSCSIおよびファイバ・チャネル・ストレージにOracle VM Managerの名前が割り当てられます。 ストレージに割り当てられるIDを使用して、管理対象外のストレージ・デバイスをOracle VM Manager WebインタフェースまたはOracle VM Managerコマンドライン・インタフェースで参照します。

  • Oracle VM Managerによる、iSCSIイニシエータのグループであるアクセス・グループの設定(どのLUNがどのOracle VM Serverで使用可能かを決定することを目的とする)。

iSCSI SANは、NFSなどのファイル・ベースの記憶域よりもパフォーマンスが高く、多くの場合、直接のローカル・ディスク・アクセスと同等です。 iSCSIストレージは、リモート・サーバーから接続されるため、記憶域の高可用性と仮想マシンのライブ・マイグレーションの可能性が重要な要素である、クラスタ化されたx86ベースのサーバー・プール構成に最適です。

SPARCベースの環境では、iSCSI LUNはローカル・ディスクとして扱われます。 OCFS2はSPARCではサポートされていないため、これらのディスクを使用して、サーバー・プール・クラスタ・ファイル・システムをホストしたり、リポジトリをホストすることはできません。 一般に、iSCSIがSPARC環境で使用される場合は、LUNを記憶域用の仮想マシンに直接使用できるようになります。

iSCSIストレージのプロビジョニングは、追加コストなしでオープン・ソースのターゲット作成ソフトウェアを使用して、またはハイエンドの専用ハードウェアを使用して(あるいはその中間の任意のものを使用して)実行できます。 iSCSIの汎用のOracle VM Storage Connectプラグインにより、Oracle VMは事実上、iSCSIのすべての記憶域プロバイダを使用できます。 また、特定のタイプの専用のOracle VM iSCSIストレージ・ハードウェアの場合はベンダー固有のStorage Connectプラグインが存在し、Oracle VM Managerは追加の対話型機能にアクセスできます(それ以外の場合、この機能は記憶域プロバイダの管理ソフトウェアを介してのみ使用可能)。 この例には、LUNの作成および削除、既存のLUNの拡張などがあります。 Oracle VM Storage Connectプラグインが使用可能かどうか、記憶域ハードウェアのサプライヤに確認してください。 インストールおよび使用手順については、サプライヤのプラグイン・ドキュメントを参照してください。

Oracle VMは、Oracle VM Storage Connectプラグインを利用して、LUN管理タスクを実行するように設計されています。 ストレージ・アレイでは、影響を受けるOracle VM Serverを再起動せずに、LUNをアンマップして別のLUN IDに再マップしないでください。 一般に、影響を受けるOracle VM Serverの外部にターゲットが切り替わってから、LUNを再マップすると、データが破損する場合があるため危険です。 LUNを別のIDに再マップしようとすると、影響を受けるOracle VM Serverは、再起動するまでディスクにアクセスできなくなり、次のエラーが/var/log/messagesに表示される場合があります。 

Warning! Received an indication that the LUN assignments on this target have changed. 
The Linux SCSI layer does not automatically remap LUN assignments.

3.2.4 ファイバ・チャネル・ストレージ接続ネットワーク

ファイバ・チャネルSANは、機能的にiSCSI SANとほとんど異なりません。 実際、ファイバ・チャネルの方が古いテクノロジであり、ファイバ・チャネルではかわりに専用ハードウェアが使用されます(SANハードウェア上では特殊なコントローラ、クライアント・マシン上ではホスト・バス・アダプタ(HBA)、およびコンポーネント間の相互接続用には特殊なファイバ・チャネル・ケーブルとスイッチ)。

iSCSIと同様に、ファイバ・チャネルSANはイニシエータとターゲット間でSCSIコマンドを転送し、直接ディスク・アクセスとほぼ同じ接続を確立します。 ただし、iSCSIはTCP/IPを使用するのに対し、ファイバ・チャネルSANはファイバ・チャネル・プロトコル(FCP)を使用します。 3.2.3項「iSCSIストレージ接続ネットワーク」で説明されているように、iSCSI SANの概念と同じ概念がファイバ・チャネルSANにも同様に適用されます。 この場合も、汎用およびベンダー固有のStorage Connectプラグインが存在します。 記憶域ハードウェアのサプライヤによってOracle VM Storage Connectプラグインの適切なドキュメントが提供されます。

3.3 Oracle VM内で記憶域がどのように作成されるか

記憶域をOracle VM環境に追加するには、最初に検出する必要があります。 検出プロセスでは、記憶域に接続して、使用可能な最初のシステムまたはディスクを検出し、Oracle VMで使用できるように構成します。

ファイル・サーバーの検出

Oracle VMでは、ローカル記憶域に対し、ファイル・サーバーという用語を使用して、別の物理サーバーから環境に対して使用可能にされているファイルベースの記憶域を示します。 ファイル・システム、NFS共有などの公開に使用されるテクノロジについては、このマニュアルで説明しません。 リンクされている次の手順では、公開されたファイル・ベースの記憶域をOracle VMに登録し、記憶域リポジトリのインストール用に準備し、ファイル・サーバーおよび検出されたファイル・システムを構成する方法について説明します。

ファイル・サーバーを検出する前に、ストレージ・サーバーが、書込み可能なファイル・システムをサーバー・プールの記憶域ネットワークに公開していることを確認します。

ファイル・サーバーを検出するには、「Storage」タブの「Discover File Servers」「Discover File Servers」アイコンを使用して、外部記憶域のマウント・ポイントの検出に使用される、「Discover a File Server」ダイアログ・ボックスを表示します。 ファイル・サーバーを検出するには、『Oracle VM Managerユーザーズ・ガイド』のファイル・サーバーの検出に関する項を参照してください。

SANサーバーの検出

ストレージ・アレイ・サーバーがRAWディスク(ファイバ・チャネルSANボリューム、iSCSIターゲットおよびLUN)をサーバー・プールの記憶域ネットワークに公開していることを確認します。

ストレージ・アレイ(SAN)サーバーを検出するには、「Storage」タブの「Discover SAN Server」「Discover SAN Server」アイコンを使用して、外部記憶域要素の検出に使用される、「Discover SAN Server」ダイアログ・ボックスを表示します。 ストレージ・アレイを検出するには、『Oracle VM Managerユーザーズ・ガイド』のSANサーバーの検出に関する項を参照してください。

ファイル・サーバーとそのファイル・システム、またはストレージ・アレイを検出したら、記憶域リポジトリに、またはサーバー・プールのファイル・システムとして使用する準備ができています。 サーバー・プールのファイル・システムは、サーバー・プールの作成時に選択され(6.8項「サーバー・プールがどのように作成されるか」を参照)、ファイル・システムに記憶域リポジトリを作成します(4.4項「リポジトリがどのように作成されるか」を参照)。

3.4 それぞれの記憶域型がどのように接続されるか

Oracle VM Managerは、Storage Connectフレームワークの一部である一連のプラグインを介してすべての記憶域と通信します。 これらのプラグインは、実際はOracle VM Managerから実行されるのではなく、一部またはすべてのOracle VM Server上に存在します。 これらのプラグイン・ファイルは、/opt/storage-connect/ディレクトリのOracle VM Serverのローカル・ファイル・システムにあります。 環境で使用する記憶域要素を作成および構成するときに、Oracle VM Manager Webインタフェースで、使用可能なプラグインを選択します。

Oracle VM Storage Connectフレームワークでは、記憶域検出と、Oracle VM Manager内から直接記憶域プラットフォームのプロビジョニングと管理を可能にするAPIのプロビジョニングが可能です。 Storage Connectフレームワークで提供される抽象化により、管理者は、Oracle VMインフラストラクチャ内で使用されている記憶域プラットフォームの具体的な動作を把握する必要なく、プロビジョニング操作を実行できます。 Storage Connect APIにより、サード・パーティの記憶域ベンダーは、自社のストレージ・アプライアンスをStorage Connectとのインタフェースにできる、独自のOracle VM Storage Connectプラグインを開発できます。

記憶域要素は、ファイル・サーバーとSANサーバーに論理的に分割されます。 この区別は、ファイルベースの記憶域とブロックベースの記憶域またはRAWディスクの違いを示します。 両方のタイプの記憶域は、Oracle VM Storage Connectプラグインを使用して処理されます。 Oracle VM Storage Connectフレームワークでは、これらの2つのタイプの記憶域機能を同じように提示できますが、それらのいずれも管理できるようにするには、記憶域の基本的な知識がユーザーに必要になります。

図3.1 Oracle VM Manager Webインタフェースの「Storage」タブ
この図では、Oracle VM Managerが、Oracle VM ServerにインストールされたOracle VM Storage Connectプラグインとのインタフェースとして機能し、アクションを実行したり、Oracle VM環境内で使用されるストレージ・デバイスを検出したりすることを示しています。

Oracle VM Storage Connectプラグインは、提供する機能に従って分けられ、汎用プラグインと非汎用プラグイン(ベンダー固有のプラグインとも呼ばれる)があります。 汎用プラグインは、既存の記憶域リソースの検出および操作など、すべての記憶域ハードウェアに対して限定された標準記憶域操作を提供します。 これらの操作は、ストレージ管理と相互作用せず、単に使用可能な記憶域アーキテクチャを検出してOracle VM環境で使用できるようにするという点でパッシブに分類されます。

ベンダー固有のプラグインには、より多くの一連の操作が含まれ、これには、クローニング、LUNの作成、サイズ変更など、記憶域ハードウェアでのアクティブな直接操作も含まれます。 汎用の記憶域プラグイン操作を実行するには、アクセス・ホストまたはファイバ・チャネル接続のみが必要です(iSCSIの場合、通常はホスト名またはIPアドレスとポート番号)。 非汎用プラグイン操作では、追加の管理ホストが必要であり(管理ユーザー名およびパスワードはオプション)、適切なプラグインがインストールされたOracle VM Serverに対して記憶域ハードウェアの構成への直接アクセス権が付与されます。

Oracle VM Serverに含まれる汎用プラグインは次のとおりで、Oracle VM Managerで動作します。

  • Oracle Generic NFSプラグイン。

  • Oracle Generic SCSIプラグイン。

ベンダー固有のプラグインをインストールするには、「Oracle VM管理者ガイド」の「Oracle VM Storage Connectプラグインのインストール」を参照してください。

3.5 マルチパスとは

マルチパスとは、サーバーとそのストレージ・デバイス間に複数の物理パスを作成する技術です。 これによってフォルト・トレランスが向上し、パフォーマンスが強化されます。 Oracle VMでは、マルチパスI/Oがデフォルトでサポートされます。 SANディスクがOracle VM Managerで検出される必要があるため、Oracle VM Serverは、マルチパスが有効な状態でインストールされます。

ノート

システム・ディスク( / または/boot)を含むディスク)は、Oracle VM Managerによってブロックされ、Oracle VM環境では使用できません。

マルチパスの構成情報は、各Oracle VM Server上の/etc/multipath.confに格納されており、よく使用されるSANハードウェアの様々な構成詳細とともに、Oracle VMの固有の設定を含みます。 ほとんどの場合、ユーザーはこのファイルを変更する必要がありません(変更しないことをお薦めします)。 ファイルの内容を調べることは、それがOracle VMでどのように機能するかと、SANでマルチパスが使用されず、LUNが表示されない場合に構成が必要となる可能性がある内容をより深く理解するのに役に立つ場合があります。

マルチパスの構成方法の詳細は、「Oracle VM管理者ガイド」で「マルチパスI/Oサポートの有効化」を参照してください。

3.6 均一エクスポートと不均一エクスポートとは

デプロイメント内のすべてのサーバーが、フィルタで公開されるファイル・システムへの同じアクセス権を持つ場合、Oracle VM Managerは、これらのエクスポートが均一であると判断します。 様々なアクセス制限のあるマウント・ポイントをエクスポートするように、NFSファイル・サーバーが構成される場合があります。 デプロイメント内の一部のOracle VM Serverが、他のOracle VM Serverでは使用できないエクスポートにアクセスできない場合、Oracle VM Managerは、これらのエクスポートを不均一と判断します。

Oracle VM Managerでは、記憶域に直接接続しませんが、Oracle VM Serverを利用して、NFSファイル・サーバーによってエクスポートされるファイル・システムの管理と検出を処理するため、Oracle VM Serverを管理サーバーとして指定する必要があります。 均一エクスポートの場合、管理サーバーとして指定されたOracle VM Serverがファイル・システムのリフレッシュを実行する目的で使用される場合があります。 ただし、エクスポートが不均一の場合は、ファイル・サーバーの一意のビューごとに、Oracle VM Serverを指定する必要があります。 これらのサーバーは、"リフレッシュ・サーバー"と呼ばれ、不均一エクスポートを使用するようにNFSファイル・サーバーが構成されるインスタンスでのみ構成するようにしてください。 均一エクスポートを使用したNFSファイル・サーバーにリフレッシュ・サーバーを構成しようとすると、操作が妨げられ、エラー・メッセージが返されます。 同様に、リフレッシュ・サーバーがファイル・サーバーに定義されている場合は、エクスポート・タイプを不均一から均一に変更することはできません。 かわりに、エクスポート・タイプの変更を試みる前に、すべてのリフレッシュ・サーバーをファイル・サーバーの構成から削除する必要があります。 この設計により、均一エクスポートで構成が最適に動作し、すべてのファイル・システムが不均一エクスポートのリフレッシュになります。

均一エクスポートでNFSファイル・サーバーのファイル・システムのリフレッシュ中、管理サーバーとして指定されたOracle VM Serverが選択され、ファイル・システムのリフレッシュを実行しますが、不均一エクスポートの場合、ファイル・システムのリフレッシュは、リフレッシュ・サーバーとして指定されたOracle VM Serverによって一つ一つ実行されます。 これにより、Oracle VM Managerでは、各サーバーからレポートされる情報を使用して、使用可能なすべてのファイル・システムのビューを構成します。 このため、不均一エクスポートで構成されるNFSファイル・サーバーでのファイル・システムのリフレッシュは完了に時間がかかる場合があります。

不均一エクスポートは同じサーバー・プール内のサーバーを対象としていません。 不均一エクスポートでNFSファイル・サーバー上のファイル・システムにアクセスする必要があるサーバー・プールに属するすべてのサーバーは、アクセスグループに追加する必要があります。 この情報の詳細は、『Oracle VM Managerユーザーズ・ガイド』のアクセス・グループ・パースペクティブに関する項を参照してください。

ノート

不均一エクスポートを使用しないNFSファイル・サーバーでファイル・システムをリフレッシュする必要がある場合、各サーバーはそれぞれ異なるエクスポートのセットにアクセスするため、操作を完了するには、各リフレッシュ・サーバーがそれぞれのシステム・リフレッシュを実行する必要があることを理解することが重要です。 リフレッシュ・サーバーのいずれかが使用不可の場合、一部のエクスポートがリフレッシュできないため、ジョブを完了できません。 このような状況に直面した場合は、NFSファイル・サーバーを編集して、使用不可のリフレッシュ・サーバーを削除し、ファイル・サーバー・エクスポートの同じセットにアクセスできる代替のリフレッシュ・サーバーを追加する必要が生じることがあります。

3.7 アクセス・グループとは

アクセス・グループでは、記憶域へのアクセスを整理して、限定されたサーバー・セットに制限できます。 Oracle VMでは、最終的には非常に似た機能を提供する2つのタイプのアクセス・グループがあります。

  • ファイル・システム・アクセス・グループでは、特定のファイル・サーバー・エクスポートまたはファイル・システムにアクセスできるOracle VM Serverを定義します。 これは、ファイル・システムをリフレッシュできるOracle VM Serverを判断できることが重要であるため、ファイル・サーバーに不均一エクスポートがある環境で一般に使用されます。 この詳細は、3.6項「均一エクスポートと不均一エクスポートとは」を参照してください。

  • SANアクセス・グループでは、iSCSIやファイバ・チャネルなど、SANストレージの形式を使用して公開される物理ディスクにアクセスする場合に使用できる、ストレージ・イニシエータを定義します。 SANアクセス・グループ機能は、使用しているOracle VM Storage Connectプラグインで定義されます。 汎用iSCSIプラグインでは、検出時に、使用可能なストレージ・イニシエータがすべて追加される単一のアクセス・グループを作成します。 他のプラグインでは、よりきめ細かな制御が可能なため、要件に従って、特定の物理ディスクへのアクセスを制限する複数のアクセス・グループを作成できます。

環境によっては、混在したSANストレージを配置している可能性があり、この場合は、iSCSIとファイバ・チャネルの両方のタイプが利用可能です。 アクセス・グループのストレージ・イニシエータは、アクセス・グループが構成されているストレーのタイプと一致する必要があるため、アクセス・グループの構成時に混乱が生じる場合があります。 アクセス・グループのコンテンツは、Oracle VM Storage Connectプラグインの製造業者によって定義されるため、Oracle VM Managerでは、タイプに従って、各Oracle VM Serverでストレージ・イニシエータをフィルタすることはできません。 したがって、複数のストレージ・タイプをサポートする環境では、アクセス・グループに追加するストレージ・イニシエータに注意を払うことが重要になります。 ストレージ・アレイ・タイプと異なるタイプのストレージ・イニシエータを含むアクセス・グループを作成すると、Oracle VM Storage Connectプラグインでエラーが生成されます。

3.8 サーバー・プールのクラスタリングに記憶域がどのように使用されるか

サーバー・プールのクラスタリングをサポートするには、共有記憶域が必要です。 On x86ハードウェアでは、これは、SANサーバー上でNFS共有またはLUNの形式で提供されます。 いずれの場合も、ディスク・イメージが作成され、OCFS2 (Oracle Cluster File System)を使用してフォーマットされます。 SPARCハードウェアでは、サーバー・プール・ファイル・システムをホストする場合にNFSのみがサポートされます。

x86環境では、クラスタ化されたサーバー・プールは、常にOCFS2ファイル・システムを使用して、クラスタ構成を格納し、OCFS2のハートビート機能を利用します。

SPARC環境では、クラスタ化されたサーバー・プールが常にNFS共有にホストされます。 SPARCのクラスタリングでは、OCFS2で利用できるのと同じメカニズムを使用しますが、実際のOCFS2ファイル・システムは使用しません。 かわりに、クラスタリング・データがNFS共有に直接格納されます。

高可用性を実現するために、クラスタ内では2種類のハートビートが使用されます。

  • ディスク・ハートビート: クラスタ内のすべてのOracle VM Serverがタイム・スタンプをサーバー・プールのファイル・システム・デバイスに書き込みます。

  • ネットワーク・ハートビート: Oracle VM Serverがネットワークを介して通信し、すべてのクラスタ・メンバーが動作していることを相互に確認します。

これらのハートビート機能は、カーネル内に直接存在し、Oracle VMがサーバー・プールに提供するクラスタリング機能の基盤になります。 同じ物理記憶域に対するI/O集中型の操作によって、ハートビート機能が妨害される場合があることを理解しておくことが重要です。 たとえば、サーバー・プールのファイル・システムが存在する同じNFSサーバー上の記憶域リポジトリでテンプレートのインポートまたは仮想マシンのクローニングを行うと、ハートビート通信でタイムアウトが発生する場合があり、サーバーのフェンシングおよび再起動の原因となります。 不要な再起動を回避するには、十分で安定したI/Oバンド幅があるサーバー・プールのファイル・システムの場所を選択することをお薦めします。 サーバー・プールのファイル・システムは、別のNFSサーバーに配置するか、可能な場合は小さいLUNを使用します。 サーバー・プール・ファイル・システムの記憶域の設定の詳細は、3.10項「記憶域の構成のガイドラインの有無」を参照してください。

3.9 仮想マシンリソースが配置される場所

記憶域リポジトリによって、Oracle VMリソースが存在する場所が定義されます。 リソースには、仮想マシン構成ファイル、仮想マシン作成のテンプレート、仮想アプライアンス、ISOファイル(CD/DVDイメージ・ファイル)、共有および共有されていない仮想ディスクなどがあります。 記憶域リポジトリ構成と管理、そのコンテンツの詳細は、第4章「リポジトリの理解」を参照してください。

3.10 記憶域の構成のガイドラインの有無

仮想インフラストラクチャをデプロイする前に記憶域構成を計画することが重要です。 次のいくつかのガイドラインに注意してください。

  • LUNの追加、削除およびサイズ変更を行うときは、物理サーバーの再起動が必要な場合があるため注意してください。 論理ディスクの一部として使用されているLUNのサイズは変更せず、かわりに、新しいLUNを作成してディスク・グループに追加します。 すでにリポジトリをホストしているLUNを縮小しないでください。リポジトリが読取り専用になり、OCFS2ファイル・システムが破損する可能性があります。

  • SANサーバーで物理ディスクのサイズを直接変更する場合は、Oracle VM Manager内で物理ディスクをリフレッシュし、リポジトリの作成などの他の操作の実行時に、物理ディスクが変更を認識して、使用可能なディスク領域を正しく判断できるようにする必要があります。

  • ターゲットがサーバーの外部で切り替えられていることで発生する可能性のあるLUNの再マップによるデータ破損を回避します。 Linux SCSIレイヤーは、ストレージ・アレイからの動的なLUNの再マップをサポートしません。

  • 本番に進む前に、テスト環境で構成(特にフェイルオーバー)をテストします。 Oracle VM Serverのマルチパス構成ファイルに変更を加える必要がある場合があります。

  • ワークロードごとに、使用する記憶域のサイズとタイプを計画します。 次に例を示します。

    • ほとんどのオペレーティング・システムでは、ブート・ディスク上のI/Oアクティビティは最小限ですが、そのI/Oの一部はレスポンス時間の影響を受けやすいメモリー・ページングであるため、ブート・ボリュームは通常、容量が大きいドライブに配置できます。

    • アプリケーションは、大量のI/Oを実行しないかぎり、より大きく低速なドライブ(RAID 5など)に配置できます。 書込み集中型のワークロードでは、中速から高速のドライブのRAID 10を使用する必要があります。 ログ・ファイルが、保護対象のデータとは異なる物理ドライブ上にあることを確認します。

    • DNSなどのインフラストラクチャ・サーバーのI/Oニーズは少ない傾向があります。 これらのサーバーのドライブはより大きく、低速にできます。

  • クローニングやスナップショットなどのストレージ・サーバー機能を使用する場合は、RAWディスクを使用します。

  • 論理ディスクを使用するときに、非常に大きなLUNを作成したいと考える場合がありますが、各仮想マシンが同じディスクに対するI/Oをキューに入れるため、パフォーマンスに悪影響を及ぼす可能性があります。 要件の徹底的な評価に基づいて、リポジトリのサイズを変更してから、正確な要件に近いサイズに維持するようにしてください。 リポジトリのサイズ変更は、次の値の合計を基準にしてください。

    • 実行中のすべての仮想マシンに必要なディスク領域の合計量。 たとえば、6つの仮想マシンでサイズが12 GBの場合、空きディスク領域がリポジトリに少なくとも72 GBあることを確認してください。

    • ローカル仮想ディスクで各仮想マシンをプロビジョニングするのに必要なディスク領域の合計量。 6つの仮想マシンがあり、それぞれ36 GBのローカル仮想ディスクがある場合は、空きディスク領域がリポジトリに少なくとも216 GB必要になります。

    • 新しいゲスト・イメージのデプロイに使用する可能性のあるテンプレートの格納に必要なディスク領域の合計量。

    • 新しいゲスト・イメージにインストールされる可能性のあるオペレーティング・システムのISOイメージの格納に必要なディスク領域の合計量。

    • 将来、ローカル仮想ディスクで追加の数の仮想マシンをデプロイするために、準備が必要になる可能性のあるディスク領域の合計量。 大まかには、実行中の仮想マシンごとに追加の仮想マシンのデプロイが必要になる場合があるため、6台の仮想マシンを最初に実行する場合は、12台の仮想マシンに対応できるように、リポジトリのサイズを変更することが適切になることがあります。

  • サーバー・プールのファイル・システムとして使用する小サイズの記憶域エンティティ(それぞれ12 GB以上)を作成するための空きディスク領域を必ず残してください。 サーバー・プールのファイル・システムはサーバー・プールおよびクラスタ・データの保持に使用され、クラスタのハートビートにも使用されます。 サーバー・プールのファイル・システム用の領域は、記憶域リポジトリの記憶域エンティティを作成する場合と同じ方法で作成します。 クラスタおよびサーバー・プールの使用と管理の詳細は、第6章「サーバー・プールおよびOracle VM Serverの管理」および『Oracle VM Managerユーザーズ・ガイド』の「Servers and VMs」タブに関する項を参照してください。

  • サーバー・プールのファイル・システムは、別のNFSサーバーに配置するか、可能な場合は小さいLUNを使用します。 同じ物理記憶域に対するI/O集中型の操作によって、クラスタ・ハートビート機能が妨害される場合があります。 たとえば、サーバー・プールのファイル・システムが存在する同じNFSサーバー上の記憶域リポジトリでテンプレートのインポートまたは仮想マシンのクローニングを行うと、ハートビート通信でタイムアウトが発生する場合があり、サーバーのフェンシングおよび再起動の原因となります。 不要な再起動を回避するには、十分で安定したI/Oバンド幅があるサーバー・プールのファイル・システムの場所を選択することをお薦めします。

  • 下層のディスク・システムで読取りおよび書込みキャッシュを無効化することでI/O同期が保証されます。 Oracle VM Serverまたは仮想マシンで突然障害が発生した場合に、キャッシュの使用によってデータの消失が発生する可能性があります。 書込みキャッシュを無効化するには、RAIDコントローラのBIOSの該当する設定を変更します。 または、sg_wr_modeコマンドを使用するか、次のようにSCSIディスク・クラスを直接使用します。echo "write through" > /sys/class/scsi_disk/scsi-device-id/cache_type

警告

ファイル・サーバーでエクスポートを作成する際に、ホストの特定のセットへのアクセスを制限する場合、ファイル・サーバー上のすべてのエクスポートには、エクスポート・リストで許可されているホストの同一のリストが必要です。 Oracle VM Managerでは、アクセスが許可されているホストのすべてを、ファイル・サーバーの管理サーバーのリストに追加する必要があります。 Oracle VM Managerでのファイル・サーバーへの管理サーバーの追加の詳細は、『Oracle VM Managerユーザーズ・ガイド』のファイル・サーバーの検出に関する項を参照してください。

3.11 リフレッシュ操作の実行内容

Oracle VM Managerでは、環境内の記憶域コンポーネントやリポジトリなど、様々なオブジェクトの情報を格納します。 一般に、すべての操作がOracle VM Managerを介して実行される場合、この情報に一貫性がなくなる可能性は低くなりますが、外部変更または手動更新により、Oracle VM Managerで使用可能な情報と実際のコンポーネントのステータスに一貫性がなくなる場合があります。 たとえば、リポジトリが配置されるファイル・システムを介して、ファイルがリポジトリに手動でコピーされると、Oracle VM Managerでは、リポジトリ内の変更を認識できず、リポジトリが配置されるファイル・システムの空き領域と使用済の領域の量が変更されても認識できません。

ノート

ファイルはリポジトリに手動でコピーできます。 これは定期的には行わないでください。 すべてのリポジトリ操作でOracle VM Managerを使用する必要があります。

これらの状況に対処するために、Oracle VM Managerでは、様々なコンポーネントの情報をリフレッシュするメカニズムが用意されています。 手動リフレッシュ操作は、次の各レベルで記憶域に対して実行できます。

  • Refresh File Server

  • Refresh SAN Server

  • Refresh Physical Disk

  • Refresh File System

  • Refresh Repository

各リフレッシュ操作では、割り当てられている1つ以上の管理またはリフレッシュ・サーバーでアクションをトリガーして、必要な情報を収集し、Oracle VM Managerにレポートします。 Oracle VM Manager WebインタフェースまたはOracle VM Managerコマンドライン・インタフェースを使用して、これらのリフレッシュ操作が実行されると、子操作がトリガーされて、関連する他のアイテムがリフレッシュされる場合があります。 たとえば、リポジトリをリフレッシュすると、リポジトリがホストされるファイル・システムでファイル・システムのリフレッシュもトリガーされますが、ファイル・サーバーをリフレッシュすると、ファイル・サーバーにホストされるすべてのファイル・システムのリフレッシュ操作もトリガーされます。

ファイル・システムがリフレッシュされると、構成済の管理サーバーに一時的にマウントされ、その使用率情報が収集されて、Oracle VM Managerに返されます。 これはリソースを消費する操作であり、完了するまで時間がかかる場合があります。 したがって、実行する必要のあるリフレッシュ操作のタイプを考慮するようにしてください。 たとえば、1つのファイル・システムの使用率情報のチェックのみが必要な場合は、ファイル・サーバー全体のリフレッシュを実行すると、多くの子操作がトリガーされるため、そのファイル・システムのみをリフレッシュしてください。

Oracle VM Manager内の一部の情報は、Oracle VM Managerに組み込まれている標準の状態モニタリング機能の一部として、ファイル・システムの統計を定期的に収集する機能で自動的に更新できます。 このサービスでは、リポジトリまたはサーバー・プール・クラスタをホストするために、Oracle VMで使用中のファイル・システムが、環境内のOracle VM Serverにすでにマウントされているという事実を利用します。 他の状態統計の機能がすでに備わっているOracle VM Serverでは、マウントされたファイル・システムの使用率情報を定期的にレポートすることもできます。 この機能が有効になっている場合、現在使用中のファイル・システムについて、Oracle VM Managerによって反映される情報の正確性と一貫性は高くなり、手動によるリフレッシュ操作の必要性は低くなります。 ファイル・システムの統計の自動収集の制御の設定は、『Oracle VM Managerユーザーズ・ガイド』.のプリファレンスに関する項を参照してください。

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