2020年4月22日水曜日

vSphere 7の紹介【vSAN ライフサイクル&ファイルサービス編】

みなさん、こんにちは
本日はvSAN 7の強化ポイントに関する内容をご紹介したいと思いますが、内容が多いため、2回に分けてお話したいと思います。
今日はライフサイクルに関する話(vLCMからの追加)およびファイルサービスについてお話します。

vSANに関しては、ここ3年間はvSphereと同等バージョンで対応してきております。また、よりHCIを簡素化するために、ハードウェアベンダーとのファームウェアを含めてライフサイクル管理、ファイルサービスの提供、クラウドネイティブストレージへの対応も含めて、様々な強化ポイントが含まれております。

1. vSAN 7でHCIを最新化(モダナイゼーション) 

VMwareはvSAN 7をからHCIを刷新し、より多くのユースケースに対応できるようにして、さらに使いやすくなりました。vSANとHCIをワンストップのショップストレージプラットフォームに近づけるプラットフォーム全体に、さまざまなメリットを提供しています。そのために、統合されたファイルサービスを提供し、お客様が一部のユースケースでサードパーティソリューションの必要性を回避できるよう支援しています。また、ライフサイクル管理を大幅に簡素化するための措置を講じており、2日目の運用に必要なツールを1つのツールに削減しています。これも、既存のツールセットよりもはるかに信頼性が高くなっています。最後に、vSAN搭載HCIの主要な理由の1つは未来を見据えたインフラストラクチャの概念です。つまり、昨日のテクノロジーに縛られずに、ITの最新のイノベーションに対応するためにソフトウェアを常に進化させています。このリリースでは、Kubernetesによってオーケストレーションされたコンテナベースのワークロードのファイル共有を有効にし、永続的なボリュームレベルでより詳細なデータサービスを提供し、KubernetesでvSphereをサポートすることで、クラウドネイティブアプリケーションのサポートも強化しています。

2. 大規模なライフサイクル管理よりシンプルなアプローチ


vSphere Lifecycle Managerのパートでもお話したかと思いますが、vSANのプラットフォームにおいて、vLCMを提供します。

詳細は以下のブログを参照して頂ければと思います。
https://tkomiya.blogspot.com/2020/04/vsphere-7vsohere-lifecycle-manager.html

前回のブログからの補足事項をいくつか記載したいと思います。


  • vLCM互換ホストを決定するために、ReadyNodesが「vLCM対応」かどうかを示すVCGに追加された追加の属性を探します。
  • 特定のクラスターではvLCMとVUM(vSphere Update Manager)は共存しますが、お互いは排他的に動作します。 どちらか一方を利用するように選択しますが、両方を利用することはありません。
  • VUMを利用する既存のクラスターの場合、クラスターレベルのメッセージには、「単一のイメージでクラスターを管理すると、1つのイメージでクラスター内のすべてのホストを維持できるため、エラーを最低限に抑え、時間を節約するのに役立ちます」 この点から、「Learn More」をクリックするとクラスターをvLCMに変換できます。
  • クラスターがVUMからvLCMに移行すると、クラスターをVUMに戻すことはできません。
  • VUMは最終的には廃止される予定であるが、現時点では機能が制限されて共存します。 これはvSphere 7.0で非推奨となっている PercCLIやStorCLIなどの古いベンダーツールによるものです。
  • 新しいクラスターの場合、「新しいクラスター」のワークフローでは、DRS、HA、vSANなどの配下に「単一のイメージでクラスター内のすべてのホストを管理する」というチェックボックスが表示されます。これにより、クラスターでvLCMが有効になります。

当然、vSAN ReadyNodesのvLCMとVxRailとVCFのライフサイクル管理機能との比較が行われます。 これらの違いを区別する製品ポジショニングのスライドが提供されます。提供内容を正確に表現し、これらの他の製品を補完するように細心の注意を払う必要があります。 いづれの場合も、幅広い顧客ベースに対応するように構築されたvLCMによって提供されるこれらの機能(例:VxRailやVCF)を利用するためのより高度なLCMオファリングの機能を含む、多くのLCM機能の基盤として(vSphere 7.0以降)利用されます。vLCMはVxRail(およびその他のvSANアプライアンスも含めて)のライフサイクル管理機能の代わりとして位置づけるものではありません。

3. ネイティブ ファイルサービスによる管理の複雑さの削減
ファイルサービスに関しては、vSAN 6.7 U3でNFSをサポートしていましたが、多くのvSANのお客様はHCIアーキテクチャのみで標準化したいと考えています。 例えばファイルサービスをサードパーティの物理ソリューションを要求することは受け入れられません。 ファイルサービス用の認定された仮想アプライアンスの現状のエコシステムは、役立つものの、統合化されたHCIの運用モデルの約束を満たしていません。

一例として、VDIのソリューションでは、CIFSをなどを利用するシーンなどもありましたが、Windowsサーバーを仮想マシンとしてデプロイしても、要件になかなか満たすことができず、仮想アプライアンス(Nexenta Stor【現在DDNに買収されています】やNetAppのONTAP Selectなど)で実現することもできるが、ファイルサーバーを導入するにも、システム上はSSDなどが利用されることから、システムは一つに統合できたとしても、コストパフォーマンスは決して良くはありません。


vSAN 7ではVMwareはファイルサービスをvSANに統合し、ブロックストレージとファイルストレージの組み合わせ、テスト環境と開発環境およびクラウドネイティブアプリケーションを必要とする軽量アプリケーションの管理を容易にします。(ただし、今回もCIFSのサポートはありません)
管理者は単一のワークフローでファイルサービスVMをすばやくプロビジョニングおよび構成できます。

今回の特徴を以下に記載します。
  • ブロックおよびファイルプロトコル用の単一のコントロールプレーンでストレージを統合
  • 単一のファイルサービスワークフローによるプロビジョニングの簡素化
  • ユースケース:クラウドネイティブアプリ、テスト/開発環境、ファイルリポジトリ
  • NFS v4.1および v3 プロトコルのサポート

vSANファイル共有はvSANの他のストレージオブジェクトと同様に次のような重要なデータサービスを受け取ります: 高可用性、暗号化、きめ細かなポリシーベースの管理、柔軟なスケーラビリティなど

さらに、ファイルサービスをスケールアウトするメリットを享受できます。これには、大量の先行投資と大規模の投資が必要となります。 vSANはスケールアウトアーキテクチャによっても容量計画の複雑さを軽減します。

vSAN 7はNFS 4.1および NFS 3プロトコルをサポートします。 NFS 4.1は多くのクラウドネイティブアプリケーションで使用されており、NFS 3は使用されている最も一般的なNFSプロトコルです。

vSANファイルサービスは次のユースケースを対象:

  • クラウドネイティブアプリ
     vSANファイルサービスとクラウドネイティブの強力なストレージコントロール機能を組み合わせることで、お客様に魅力的なソリューションを提供できると確信しています
  • ブロックとNASのワークロードの組み合わせ
    vSANファイルサービスは複雑な専用のファイル共有ストレージを利用させない、小規模のファイルサービスアプリケーションのストレージ管理を簡素化します
  • スペア容量の使用
    追加のvSAN容量を利用して、軽量のファイル共有ワークロードを実現します。お客様にとってのメリットは、スケールアウトアーキテクチャによるシンプルな容量管理です

アーキテクチャ
------------------------------

ファイルサービスはクラスターレベルのサービスであり、iSCSIサービス、重複排除と圧縮、保存データの暗号化など、他のクラスターレベルのサービスと同じUIで有効にできます。
ファイルサービスはファイルサービスVMまたはFSVMと呼ばれる一連のエージェントVMを利用します。
エージェントVMは、PhotonOS、Dockerを含むサービスが有効(800MB)になると、非常に軽量なOVF(ダウンロード後にvCenterでキャッシュ)から構築されます。 クラスタでファイルサービスが無効になっている場合、これらのエージェントVMはパワーオフのままです。
vSAN 7のファイルサービスは、vSANクラスターごとに最大8台のファイルサービスVMをサポート
これらのエージェントVMはPhotonOSを使用して、POSIXを完全にサポートするためにGanesha経由でNFSサービスを提供するDockerコンテナーを実行し、統合してネームスペースを形成します。
ファイルサービスは9P(プロトコル)を使用します。

ファイルサービスのデータパススタックは次のとおり:
  • プロトコルレイヤー – Ganeshaを介してアドバタイズされたサービス(NFSなど)を提供します(エージェントVM内のコンテナーで提供)
  • Linuxファイルシステム– Linuxファイルシステムに、汎用仮想ファイルシステム(VFS)および9pのレイヤーを提供します。 POSIX要求を受け入れ、9pに変換してから、VDFSプロキシ(ローカルまたはリモート)を介してVDFSに変換します。
  • VDFS – 9pとのインターフェース、9pコマンドのリモートVDFSデーモンへの転送、またはvSANへのリクエストをブロックする変換
  • vSAN – ネットワークまたはローカルデバイスを介したブロックI/Oの処理
------------------------------

9Pプロトコルについては、Wikipediaをご参照下さい。

以上、よろしくお願いします。













0 件のコメント:

コメントを投稿

注: コメントを投稿できるのは、このブログのメンバーだけです。