NetApp ONTAPおよびVMware vVOL

この記事では、ONTAPファームウェアを備えたNetAppストレージシステムに実装されているvVolテクノロジーの内部デバイスとアーキテクチャについて検討します。



なぜこのテクノロジーが登場したのか、なぜ必要なのか、なぜ現代のデータセンターで需要があるのか​​？ この記事では、これらの質問やその他の質問に答えようとします。



VVolテクノロジーは、VMを作成するときに、指定された特性を持つ仮想ディスクを作成するプロファイルを提供しています。 このような環境では、仮想環境の管理者は、一方で、vCenterインターフェイスで、どの仮想マシンがどのメディアに存在するかを簡単かつ迅速に確認し、ストレージシステム上の特性を見つけることができます。 DRのレプリケーション、圧縮、重複排除、暗号化などがそこに設定されているかどうか vVolテクノロジーにより、ストレージはvCenterの単なるリソースのコレクションになり、以前よりも相互に深く統合されています。

スナップショット

スナップショットを統合し、VMwareスナップショットからディスクサブシステムの負荷を増やすという問題は、小規模な仮想インフラストラクチャでは目立たない場合がありますが、仮想マシンロボットの速度が低下したり、統合できない（スナップショットを削除できない）という形で悪影響を被ることもあります。 vVolは、VMware COWスナップショットとは異なり、アーキテクチャに設計され、パフォーマンスに影響を与えることなく根本的に異なる動作をするため、VM仮想ディスクのハードウェアQoS、およびHardware-Assistant レプリケーションとNetAppスナップショットをサポートします。 誰がこれらのスナップショットを使用しているように見えますが、なぜこれが重要なのですか 実際、一貫性のあるデータを取得したい場合、仮想化環境のすべてのバックアップスキームは、何らかの形でVMware COWスナップショットの使用をアーキテクチャ的に強制されます。

vVol

一般的なvVolとは何ですか？ vVolはデータストアのレイヤー、つまり データストア仮想化テクノロジーです。 以前は、LUN（SAN）またはファイル共有（NAS）にデータストアがありました。 原則として、各データストアは複数の仮想マシンをホストしていました。 vVolは、仮想マシンのディスクごとに個別のデータストアを作成することにより、データストアをより細かくしました。 vVolは、仮想化環境のNASおよびSANプロトコルとの統合作業も行います。一方で、管理者は月やファイルを気にしません。一方で、各仮想VMディスクは、異なるボリューム、月、ディスクプール（集合体）キャッシングとQoS設定、異なるコントローラー、 このVMディスクに従う異なるポリシーを持つことができます 。 従来のSANの場合、ストレージシステムが「見た」ものと管理できるものすべて-データストア全体であり、各VM仮想ディスクは個別ではありません。 vVolを使用すると、1つの仮想マシンを作成するときに、個別のポリシーに従って個別のディスクをそれぞれ作成できます。 各vVolポリシーでは、vVolポリシーで事前定義された条件に対応する使用可能なストレージリソースプールから空きスペースを選択できます。



これにより、ストレージシステムのリソースと機能をより効率的かつ便利に使用できます。 したがって、仮想マシンの各ディスクは、LUN RDMと同様の専用仮想データストアに配置されます。 一方、vVolテクノロジーでは、ハードウェアスナップショットとクローンはデータストア全体のレベルではなく、個々の仮想ディスクのレベルで実行され、VMware COWスナップショットは使用されないため、1つの共通スペースの使用はもはや問題ではありません。 同時に、ストレージシステムは各仮想ディスクを個別に「表示」できるようになり、ストレージ機能をvSphereに委任できるようになり（スナップショットなど）、仮想化のためのディスクリソースのより深い統合と透過性が提供されます。



VMwareは2012年にvVolの開発を開始し、2年後にプレビューでこのテクノロジーを実証しました。同時に、NetAppは、VMWareがサポートするすべてのプロトコルを備えたONTAPファームウェアを備えたデータストレージシステムでのサポートを発表しました：NAS（NFS）、SAN（iSCSI、 FCP）。

プロトコルエンドポイント

次に、抽象的な説明から離れて、詳細に進みましょう。 vVol'yはFlexVol上にあり、NASおよびSANの場合はそれぞれ、ファイルまたは衛星です。 各VMDKディスクは、専用のvVolディスク上に存在します。 vVolディスクが別のストレージノードに移動すると、この新しいノード上の別のPEに透過的に再マップされます。 ハイパーバイザーは、仮想マシンのディスクごとに個別にスナップショットの作成を開始できます。 1つの仮想ディスクのスナップショットは、そのフルコピー、つまり 別のvVol。 スナップショットのない新しい仮想マシンはそれぞれ、複数のvVolで構成されています。 vVolの目的に応じて、次のタイプがあります。







さて、実際には、PEについて。 PEは、一種のプロキシであるvVol'amへのエントリポイントです。 PEとvVol'yはストレージシステムにあります。 NASの場合、ストレージポート上のIPアドレスを持つ各データLIFはそのようなエントリポイントです。 SANの場合、これは4MBの特別な月です。



PEは、VASAプロバイダー（VP）の要求で作成されます。 PEは、VPからストレージへのBinging要求を介してすべてのvVolを適応させます。最も頻繁な要求の例はVMの起動です。



ESXiは、vVolに直接ではなく、常にPEに接続します。 SANの場合、これにより、ESXiホストごとの255ムーンの制限と、ムーンへのパスの最大数が回避されます。 各仮想マシンは、NFS、iSCSI、またはFCPの1つのプロトコルvVolのみで構成できます。 すべてのPEのLUN IDは300以上です。



わずかな違いにもかかわらず、NASとSANは、仮想化環境でのvVolに関して非常に類似しています。

cDOT::*> lun bind show -instance Vserver: netapp-vVol-test-svm PE MSID: 2147484885 PE Vdisk ID: 800004d5000000000000000000000063036ed591 vVol MSID: 2147484951 vVol Vdisk ID: 800005170000000000000000000000601849f224 Protocol Endpoint: /vol/ds01/vVolPE-1410312812730 PE UUID: d75eb255-2d20-4026-81e8-39e4ace3cbdb PE Node: esxi-01 vVol: /vol/vVol31/naa.600a098044314f6c332443726e6e4534.vmdk vVol Node: esxi-01 vVol UUID: 22a5d22a-a2bd-4239-a447-cb506936ccd0 Secondary LUN: d2378d000000 Optimal binding: true Reference Count: 2
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

iGroupおよびエクスポートポリシー

iGroupとエクスポートポリシーは、ホストからストレージシステムで利用可能な情報を非表示にできるメカニズムです。 つまり 各ホストに必要な情報を提供します。 NASとSANの場合のように、衛星のマッピングとファイルボールのエクスポートは、VPから自動的に行われます。 ESXiはPEをプロキシとして使用するため、iGroupはすべてのvVolにマッピングされるのではなく、PEにのみマッピングされます。 NFSプロトコルの場合、エクスポートポリシーはファイル共有に自動的に適用されます。 iGroupおよびエクスポートポリシーは、vCenterからの要求を使用して自動的に作成および入力されます。

SANおよびIP SAN

iSCSIプロトコルの場合、ESXiホスト上の対応するVMkernelと同じネットワークに接続されている各ストレージノードに少なくとも1つのデータLIFが必要です。 iSCSIとNFS LIFは分離する必要がありますが、同じIPネットワークと1つのVLANで共存できます。 FCPの場合、各工場の各ストレージノードに少なくとも1つのデータLIFが必要です。つまり、原則として、これらは独自の個別のターゲットポートに存在する各ストレージノードからの2つのデータLIFです。 FCPのスイッチでソフトゾーニングを使用します。

NAS（NFS）

NFSプロトコルの場合、ESXiホスト上の対応するVMkernelと同じネットワークサブネットに接続されている各ストレージノードに設定されたIPアドレスを持つ少なくとも1つのデータLIFが必要です。 iSCSIとNFSに同じIPアドレスを同時に使用することはできませんが、同じVLAN、同じサブネット、同じ物理イーサネットポートの両方で共存できます。

VASAプロバイダー

VPは、vCenterとストレージの間の仲介者であり、vCenterが必要とするストレージを説明し、逆もまた重要なアラートと物理的に実際にある利用可能なストレージリソースについてvCenterに伝えます。 つまり vCenterは、実際に空きスペースの量を知ることができます。ストレージシステムがハイパーバイザーに薄い衛星を提示する場合、特に便利です。



VPは、障害が発生しても仮想マシンが正常に動作し続けるという意味で単一障害点ではありませんが、vVolでポリシーと仮想マシンを作成または編集したり、vVolでVMを起動または停止したりすることはできません。 つまり インフラストラクチャ全体の完全なリブートが発生した場合、VPはPEをvVolにマッピングするためのストレージへのバインド要求を満たさないため、仮想マシンは起動できません。 したがって、VPは予約することが明らかに望ましいです。 また、同じ理由で、VPからvVolに制御する仮想マシンをホストすることは許可されていません。 なぜ予約するのが「望ましい」のですか？ NetApp VP 6.2以降では、後者はストレージ自体からメタ情報を読み取るだけでvVolコンテンツを回復できるためです。 構成および統合の詳細については、 VASA ProviderおよびVSCのドキュメントを参照してください 。

災害復旧

VPはディザスタリカバリ機能をサポートします：VPが削除または破損した場合、vVol環境データベースを復元できます：vVol環境に関するメタ情報は、VPデータベースに、およびONTAP上のvVolオブジェクト自体とともに、複製された形式で保存されます。 VPを復元するには、古いVPを登録し、新しいVPを上げ、そこにONTAPを登録し、 そこでvp dr_recoverdbコマンドを実行してvCenterに接続し、後者で「Rescan Storage Provider」を実行します。 詳細はKBにあります。



VPのDR機能を使用すると、SnapMirrorハードウェアレプリケーションを使用してvVolを複製し、vVolがストレージレプリケーションのサポートを開始したときにサイトをDRサイトに復元できます（VASA 3.0）。

仮想ストレージコンソール

VSCは、VPポリシーの操作を含む、vCenter GUIのストレージ用のプラグインです。 VSCは、vVolが機能するために必要なコンポーネントです。

スナップショットとフレックスクローン

ハイパーバイザーに関するスナップショットとストレージに関するスナップショットの間に線を引きましょう。 これは、NetAppのvVolがスナップショットでどのように機能するかの内部構造を理解するために非常に重要です。 多くの人が既に知っているように、ONTAPのスナップショットは常にボリュームレベル（およびアグリゲートレベル）で実行され、ファイル/ムーンレベルでは実行されません。 一方、vVolはファイルまたは衛星です。 ストレージシステムを使用して、VMDKファイルごとにスナップショットを個別に削除することはできません。 ここでは、 FlexCloneテクノロジーが役立ちます。これは、ボリューム全体だけでなく、ファイル/月のクローンを作成する方法を知っているだけです。 つまり ハイパーバイザーがvVolに存在する仮想マシンのスナップショットを取得すると、内部で次のことが発生します：vCenterはVSCおよびVPにアクセスし、必要なVMDKファイルが存在する場所を見つけて、それらからクローンを削除するONATPコマンドを提供します。 はい、ハイパーバイザーの側面からのスナップショットのように見えるのは、ストレージシステム上のクローンです。 つまり、vVolでハードウェアアシスタントスナップショットを実行するにはFlexCloneライセンスが必要です。 この目的または同様の目的のために、ONTAPには、古いクローンを削除するためのポリシーを設定できる新しいFlexClone Autodelete機能があります。



スナップショットはストレージレベルで実行されるため、スナップショットの統合（ESXi）の問題と、スナップショットがディスクサブシステムのパフォーマンスに与える悪影響は、ONTAPの内部クローニング/スナップショットメカニズムにより完全に排除されます。

一貫性

ハイパーバイザー自体がストレージシステムを使用してスナップショットを削除するため、スナップショットは即座に自動的に整合されます。 これは、 NetApp ONTAPバックアップパラダイムに非常によく適合します 。 vSphereは、専用vVolへのVMメモリのスナップショットをサポートしています。

クローニングとVDI

クローン作成機能は、多くの場合、同じタイプの仮想マシンの多くを迅速に展開する必要があるVDI環境で非常に人気があります。 ハードウェアアシスタントのクローン作成を使用するには、FlexCloneライセンスが必要です。 FlexCloneテクノロジーは、多数の仮想マシンのコピーの展開を劇的に高速化するだけでなく、ディスク容量の消費を劇的に削減するだけでなく、間接的に作業を高速化することに注意することが重要です。 クローニングは、本質的に重複排除と同様の機能を実行します。 占有スペースの量を減らします。 事実は、NetApp FASは常にシステムキャッシュにデータを配置し、システムキャッシュとSSDキャッシュはDedup対応であるということです。 すでに存在する他の仮想マシンから重複ブロックを引き抜くことはなく、システムおよびSSDキャッシュが物理的にできる以上に論理的に対応します。 これにより、ストレージの操作中、特にキャッシュとの間のデータのヒット/読み取りが増加するため、ブートストームの瞬間のパフォーマンスが劇的に向上します（a）。

マップ解除

VMware 6.0以降のVVolテクノロジー、VMハードウェアバージョン11、およびNTFSファイルシステムを備えたWindows 2012は、この仮想マシンが自動的に配置されるシンムーン内のスペースのリリースをサポートします。 これにより、Thing Provisioningとハードウェアアシスタントスナップショットを使用して、SANインフラストラクチャで使用可能なスペースの使用率が大幅に向上します。 また、VMware 6.5およびSPC-4をサポートするLinuxゲストOSから、仮想マシンの内部のスペースを解放してストレージシステムに戻すことができるため、高価なストレージスペースを大幅に節約できます。 UNMAPの詳細 。

最小システム要件

• NetApp VASA Provider 5.0以降
• VSC 5.0以降。
• clustered Data ONTAP 8.2.1以降
• VMware vSphere 6.0以降
• VSCとVPには同じバージョンが必要です（たとえば、両方とも5.xまたは両方とも6.x）。

詳細については、認定NetAppパートナーまたは互換性マトリックスにお問い合わせください。

SRMおよびハードウェアレプリケーション

残念ながら、VMwareによるVASAプロトコルの現在の実装ではレプリケーションとSRMがサポートされていないため 、Site Recovery Manager はまだvVolをサポートしていません 。 NetApp FASシステムはSRMと統合され、vVolなしで動作します。 VMSテクノロジー（MetroCluster）では、VVolテクノロジーもサポートされており、地理的に分散されたアクセスしやすいストレージを構築できます。

バックアップ

VVolテクノロジーは、バックアップへのアプローチを劇的に変え、バックアップ時間を短縮し、ストレージスペースをより効率的に使用します。 この理由の1つは、vVolがハードウェアスナップショットを使用するため、スナップショットとバックアップに対する根本的に異なるアプローチです。これが、VMwareスナップショットの統合と削除の問題が不要になった理由です。 VMwareスナップショットの統合に関する問題が解消されたため、アプリケーション対応（ハードウェア）スナップショットとバックアップを削除することは、管理者にとって頭痛の種ではなくなりました。 これにより、より頻繁なバックアップとスナップショットが可能になります。 パフォーマンスに影響を与えないハードウェアスナップショットを使用すると、生産性の高い環境に多くのスナップショットを直接保存できます。また、ハードウェアレプリケーションにより、アーカイブまたはDRサイトへのデータのレプリケーションがより効率的になります。 フルバックアップと比較してスナップショットを使用すると、ストレージスペースをより経済的に使用できます。

VASA API 3.0

ストレージベンダーのプラグイン（NetApp VASA Provider 6.0など）とVMware VASA API（VASA API 3.0など）を混同しないでください。 近い将来、VASA APIで最も重要で期待される革新は、ハードウェアレプリケーションのサポートです。 vVolテクノロジーが広く使用されるためには、ハードウェアレプリケーションサポートが非常に不足しています。 新しいバージョンは、DR機能を提供するストレージを使用したvVolディスクのハードウェアレプリケーションをサポートします。 レプリケーションはストレージシステムを使用して以前に実行できましたが、vSphereのVASA API 2.X（およびそれ以降）でこのような機能がサポートされていないため、ハイパーバイザーは以前はレプリケートされたデータを操作できませんでした vVolでDRを管理するためのPowerShellコマンドレットも表示されます。さらに重要なのは、複製されたマシンをテストするために実行できる機能です。 DRサイトからの計画的な移行の場合、仮想マシンの複製が要求される場合があります。 これにより、vVolでSRMを使用できます。



Oracle RACはvVolで動作することが検証されます。これは朗報です。

免許

vVolが機能するには、VP、VSA、およびvVolをサポートする必要なファームウェアを備えたストレージが必要です。 これらのコンポーネントだけでは、vVolを操作するためのライセンスは必要ありません。 NetApp ONTAP側では、vVolが機能するためにFlexCloneライセンスが必要です。このライセンスは、ハードウェアスナップショットまたはクローン（削除とリカバリ）をサポートするためにも必要です。 データレプリケーション（必要な場合）には、NetApp SnapMirror / SnapVaultライセンスが必要です（両方のストレージシステム：メインサイトとバックアップサイト）。 vSphereには、StandardまたはEnterprise Plusライセンスが必要です。

結論

VVolテクノロジーは、ESXiハイパーバイザーをストレージとさらに統合し、管理を簡素化するために設計されました。 これにより、 UNMAPのおかげで、 細い衛星のスペースを解放できる Thing Provisioningなどのストレージ機能とリソースをより合理的に使用できるようになりました 。 同時に、ハイパーバイザーにはストレージスペースとリソースの実際の状態が通知されます。これにより、Thing ProvisioningをNASだけでなく、SANとの「戦闘」状態で使用し、アクセスプロトコルから抽象化し、インフラストラクチャの透過性を確保することができます。 また、パフォーマンスに影響を与えないストレージリソース、シンクローン、スナップショットを使用するためのポリシーにより、仮想化されたインフラストラクチャに仮想マシンをより迅速かつ便利に展開できます。