日本語フォーラム (Japanese) | Nutanix Community
Skip to main content
  • 213 Topics
  • 277 Replies
213 Topics

本記事は2021年1月12日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 Part1ではX-Rayのシナリオである「Platform Availability, Resiliency & Integrity (プラットフォームの可用性、回復力、そして整合性)」の成功結果のチャートと失敗結果のチャートを確認しました。(可用性が期待されたレベルで維持できたか、障害で I/Oエラーが検出されたかを確認できます) パート2では、ESXi7.0.1ビルド17325551で実行されているNutanixAOS5.19およびvSAN7 Update1のさまざまなテスト結果を確認します。 注:同じテストをESXi6.7とESXi7.0.1の以前のビルドで行い、AOSとvSANの両方で同様の結果が得られました。 最初の比較では、X-Ray向けの「Platform Availability, Resiliency & Integrity」のシナリオを使用し、シナリオのデフォルト設定を使用します。ディスク使用率は10%、I/Oタイムアウトは30秒、および「全てのプラットフォームでの復元力テスト」です。 パート1で学習したように、テストではノードごとに1つのVMをデプロイし(N+1ノード目は除く)、ノードでアクションが実行される前に、VMをノードからプロアクティブに移動します。これにより、VMはテスト全体を通じて起動し続け、I/Oアクティビティと整合性を正確に確認できます。 Nutanix AOS 5.19とvSANはどちらも、ESXi 7 Update 1(ビルド17325551)と同じDell PowerEdge R740xd-24 NVMe + SSDハードウェアで実行されています。 テスト前に、すべてのノードを最新のBIOS/ファームウェアに更新し、可能な限り公平で比較可能であることを確認しました。 VMの可用性(メンテナンスモード):NutanixAOSとvSAN7U1はどちらもVMの可用性を維持していました(合格) VM I / Oエラー(メンテナンスモード):NutanixAOSまたはvSAN7U1ではI / Oエラーは発生しませんでした(合格) VMの可用性(ローリングリブート):NutanixAOSとvSAN

本記事は2021年1月11日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 X-Ray 向けの「Platform Availability, Resiliency & Integrity (プラットフォームの可用性、回復力、そして整合性)」のシナリオをもうすぐ(※原文記載時ママ)リリースできることを喜ばしく思います。 X-Rayにあまり馴染みのない方のためにご紹介しますと、X-Rayは自動化された検証とベンチマーキングのフレームワークのソリューションで、主なハイパーコンバージドインフラソリューションの包括的な360°でのアセスメントを提供します。 「Platform Availability, Resiliency & Integrity」シナリオ(これは現在ではvSphere 7 Update 1 のサポートのためのNutanixの公式なQAプロセスの一部でもあります)はHCIプラットフォームのメンテナンスモードへ入れたり、システムの再起動のような制御下で行われるメンテナンスはもちろん、ノード障害のような状況における仮想マシンのI/Oアクティビティ(可用性/回復力)を維持し、I/Oの整合性(エラーがないこと)を再現することを念頭に設計されています。  この検証では1台を除いたそれぞれノード上に1台の仮想マシンを展開すると、クラスタ内のノードに応じて自動的にテストをスケールアップします。これはN+1で適切に実際の環境でのサイジングをシミュレーションするためで、それぞれのノード内のフラッシュドライブの数をベースとして適切に目標となるI/Oレベルに合わせるためでもあります。 I/Oレベルをフラッシュドライブ数をベースとして調整していくことは、検証において比較的小さなノードやクラスタに過負荷をかけるだけで、結果として現実的ではない、人為的に生み出される多くのエラーを避けることができます。 それでは検証の内容とそのオプションを見ていきましょう。  この検証の主な目標は検証自体を大変シンプルで使いやすくすることで、迅速/簡単に概念検証(PoC)、インストール後の運用の確認の一部、そして構成変更後の期間での検証の一部として利用できるようにすることです。 特に手を加える必要もなく、検証は自動的に利用可能なクラスタ/利

 本記事は2020年6月22日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 このシリーズの前半では、Nutanix AOSの読み取りパスおよび書き込みパスの利点と、Nutanix独自のデータローカリティの実装が、どのような恩恵をもたらすかについて説明しました。また、データローカリティに関する新たな比較シリーズを開始し、データローカリティが究極のストレージ性能だけではなく、基盤となるクラスタとすべての仮想マシンの性能と機能についてもハイライトしています。それでは、I/Oパスのしなやかさについて詳しく見ていきましょう。 先日、VMware社は「How to handle lost of stuck I/O on a host in vSAN Cluster(vSAN Clusterにおけるホスト上でのI/Oの喪失時の対応について)」というタイトルでKB71207を公開しました。この記事では、ストレージコントローラや物理ドライブなど、I/OパスのどこかでI/Oが「スタック」または「ロスト」した場合のvSANの対応について説明しています。この症状について、VMware社は次のように説明しています:ストレージコントローラやストレージディスクでI/Oがスタックしたり失われたりすると、ESXiストレージコンポーネントは、タスク管理要求を通じて、これらI/Oを中止しようとし、以下のコンソールメッセージを表示します。If I/O is stuck or lost on the storage controller or the storage disk, the ESXi storage stack will try to abort them using the task management request displaying these console messages:引用: HTTPS://KB.VMWARE.COM/S/ARTICLE/71207 記事はこう続けています:このようなロストI/Oがホスト上で見つかった場合、vSANはホストを強制的にPSODさせ、クラスタ上の他のホストに影響を与えないようにします。If such a lost I/O is found on a host, vSAN will force t

本記事は2020年5月15日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 これまで、Nutanix AOSとvSAN/VxRAILを比較して、書き込みI/Oの受け入れに関する基本的なアーキテクチャと、書き込みI/Oパスの数々の制限事項について解説してきました。以下はそれらに関するまとめです。vSANの書き込みパスは、VMがクラスタ内のどこにあるかに大きく依存します。 vSAN の静的なオブジェクトベースの書き込みパスでは、メンテンナンスの際には予めデータのバルク移動(別のホストへの退避)を行わなければ書き込みI/Oの冗長性を確保することができません。 Nutanix ADSFは、構成されたストレージポリシー(レジリエンシー ファクター)に基づいて、常に書き込みI/Oの完全性(冗長性)を維持します。 Nutanix ADSFは、VMがどこにあろうとも、あるいはクラスタ内で移動されようとも、一貫性のあるやりかたで書き込みパスを提供します。 多重化された書き込みデータがいずれも他のノードに(ネットワークを跨いで)送られるという状況は、Nutanixではメンテナンス時やCVMの障害時などのワーストシナリオで発生する動作ですが、vSANにおいてはこれは通常の動作です。 Nutanix ADSFは、偶然に頼らず、常にデータローカリティのメリットを享受できるように設計されています。 これらに加えて、「高コスト・高耐久なフラッシュデバイスに関するハードウェア要件」について比較してみると、どうなるでしょうか。耐久性は、1日あたりのドライブへの書き込み回数(DWPD)で評価できます。 Dell EMCやVMwareは「Nutanixは高耐久フラッシュデバイスへの依存度が高く、これはNutanix AOSの大きなデメリットである」と主張することがあるようです。 今日、私が見たそのような主張の例を1つ紹介します(この投稿に触発されたので、Dell EMCのNathan Bulmon氏に感謝します)。「Nutanixは、より多くの書き込み命令を行うため、高価なフラッシュドライブをより多く必要とします」とのことです。 参考訳 : Josh Odgersさん、記事を読ませていただきました。HWとSWの統合されたアップデートについて、つまりインカー

本記事は2020年3月9日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 このシリーズでは、Nutanix AOSソリューションがvSAN / VxRAILと比較して、多くのアーキテクチャ上の利点があることを学んできました。 この記事では、実世界のネットワークトラフィックがパフォーマンスに与える影響の例を紹介します。これまでに説明してきたコンセプトの多くが証明できます。この例では、ビッグデータのインジェスト処理のような書き込みの多いワークロードを見てみましょう。 ベースラインとなるテスト: 2つの同一構成の4ノード・クラスターを使用します。完全にアイドル状態になるのを待って 、X-Rayを使ってビッグデータ取り込みのシナリオを開始しました。2つのプラットフォームは同じくらいの時間でデータの取り込みを完了しました。 Nutanix AOSは13分、VMware vSANは14分でした。 ネットワークトラフィックがない状態でのビッグデータの取り込みテストの所要時間 テスト中のネットワーク使用率は、どちらのソリューションも約2GBpsで、vSANはテストが半分ほど経過したところで約1.5GBpsに低下しました。  次に、各ホスト上でiPerfを実行し、実世界のシナリオをシミュレートしました。ストレージトラフィックだけでなくVM間やクライアント・サーバ間のトラフィックを処理する環境です。 iPerfでネットワークトラフィックを生成した環境でのテスト 次のグラフは、テスト全体のネットワーク帯域幅を示しています。この中にはiPerf(~6GBps)で生成されるトラフィックとX-Rayのシナリオで生成されるビッグデータ取り込み(前のグラフのように~2GBps)の両方のトラフィックが含まれています。これらは両プラットフォームで同様の条件です。  当然のことながら、いくつかの影響が見られました。このテストは100%書き込みで、両方のプラットフォームが書き込みレプリカにネットワークを使用しなければならないためです。 iPerfのネットワークトラフィックを用いたビッグデータ取り込み処理の所要時間 Nutanixへの影響としては、シナリオ完了までに4分(~31%増)多くの時間がかかりました。vSANは14分(~100%増)多くかかりました。 

本記事は2020年3月2日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 このシリーズでは、NutanixプラットフォームがvSAN/VxRAILよりも多くの使用可能な容量を提供することで、物理ストレージをより効率的に利用できることをすでに学んできました。 また、Nutanixのアーキテクチャは、ドライブやノードの障害をより安全に処理し、復旧までの平均時間を大幅に短縮することができるなど、多くの利点があることを学びました。 Nutanixの容量拡張や性能向上を即座に改善する独自能力は、Day2 Operations(運用フェーズ)をはるかに単純化し、価値を生み出すまでの時間を短縮することにもつながります。 また、Nutanix Controller VM (CVM)は、基本的なストレージ層のみしか提供しないvSANカーネルモジュールよりも価値が高いことがわかりました。Nutanix CVMは、より高度な、回復力があり、スケーラブルで、パフォーマンスの高い分散型ストレージファブリックを提供するだけでなく、データ保護/レプリケーションなどの機能も提供し、利用性の高い管理スイート(PRISM Element)も提供します。 CVMは、より多くの価値を提供しているにもかかわらず、メモリ使用量の比較記事では、Nutanix CVMのメモリ使用量はvSAN/VxRAILと同等かそれ以下であることが多いということがわかりました。 さらに、vSAN/VxRAILが「インカーネル」で実行されていることがリソース使用量の面で大きな利点になるという神話を払拭するために、CPU使用量の例をいくつか見てみましょう。 注: VMwareのEULAでは、IOPS/スループットのパフォーマンス数値を共有することができませんが、すべての比較において、プラットフォームの差の割合を示しています。これにより、提供されるパフォーマンスが異なる場合でも、CPU使用率を正確に比較することができます。 次のチャートは、Nutanix X-Rayツールを使用して、「Four Corners」と「Throughput Scalability」のシナリオを使用して作成したものです。 例1 - ランダムリードのCPU使用率 このテストでは、IOPSの結果は両プラットフォーム

本記事は2020年4月1日にJosh Odgers氏が投稿した記事の翻訳版です。 原文はこちら。本シリーズの索引はこちら。  本シリーズのパート1、vSAN/VxRailとNutanixの利用可能な容量において、Nutanixがより多くの利用可能な容量とともに、重複排除と圧縮はもちろん、イレイジャーコーディングを利用した場合にもより優れた容量の効率、柔軟性、回復力、そしてパフォーマンスを提供することを学びました。また、DellEMCが「大規模なワークロード向けに最適化したハイパフォーマンスノード」と謳うDellEMC VxRAIL P-シリーズと同等のノードを利用したもう一つ別のvSAN/VxRAILとNutanixの利用可能な容量の比較についてもご披露いたしました。その結果は驚くべきものではなく、Nutanixでは18.38TB(〜16%)も多くの利用可能な容量を4ノードのソリューションで提供しており、それが8ノードに拡張された場合には77.925TB(〜31%)で圧勝してしまうというものでした。メモリの利用量についての話題は、比較的容易で(一方で、よく誤解や誤記を目にします)NutanixのCVMは静的な容量のメモリで構成された仮想マシンであるという比較になります。 標準では、Nutanix CVMは最小のノードでの24GBからノードでアグレッシブなリカバリ目標時点(RPO)を想定した場合で最大40GBの間となりますが、そうでない場合は32GBです。vSAN/VxRAILの場合、VMwareは「ESXi 6.0 U3,6.5.0d以降のvSANのメモリ消費を理解する」というタイトルのナレッジベースの記事を公開し、更新しています。この記事では様々な例をあげており、最初の例は小さな1つのディスクグループのハイブリッド構成であり、その環境ではvSANのために16.478GBが必要となっています。 例1: ホストあたり1つのディスクグループ、ハイブリッド構成::公式:HOST_FOOTPRINT + ( NumDiskGroups * ( DISKGROUP_FIXED_FOOTPRINT + DISKGROUP_SCALABLE_FOOTPRINT + ( CacheSize * CACHE_DISK_FOOTPRINT) + NumCapacityDisks * C

本記事は2020年4月1日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 vSAN/VxRAILとNutanixの使用可能な容量の比較のパート1では、Nutanixは重複排除と圧縮、およびイレイジャーコーディングを利用した場合に、容量の効率性、柔軟性、回復力、およびパフォーマンスの向上とともに、より多くの使用可能な容量を提供することを学びました。また、vSANの使用可能容量を改善する方法はありますかという問いに対して、(使用可能な容量の比較 – パート1の中で)4つの例を示しました(以下を参照)。 単一のディスクグループのみを使用することで、キャッシュによって「失われる」容量をSSD 1枚分だけをとどめます ディスクグループごとに、より多く本数のSSDを利用する/またはより大容量の SSD を使用します 圧縮/重複排除を使用します イレイジャーコーディング/RAID5または6を使用します この(Nutanix ADSF vs VMware vSANの)比較のためのハードウェア仕様は、4台のNVMeドライブと20台のSATA-SSDを搭載した4台のDell PowerEdge R740xdです。これは、各vSANディスクグループが前回の例(キャッシュドライブ1台、キャパシティドライブ2台)よりも多くのSSDを使用することを意味し、結果としてキャッシュドライブ1台、キャパシティドライブ5台となります。今回はより多くのSSDを搭載したノードや、ディスクグループごとに大容量のSSDを搭載したノードを使用して比較します。 この構成は、DellEMC社によって「データベースなどの重いワークロードに最適化された高性能ノード」と説明されているDellEMC VxRAIL P-Seriesの構成に相当し、24本の12G SASドライブスロット(2.5インチ)のディスク構成をサポートし、それぞれ最大5台のキャパシティドライブから構成される最大4つのディスクグループを持つことが可能です。 参考 : http://dellemcstorage.com/dell-emc-vxrail-p-series.html 以下は、vSphereクライアントに表示されるドライブを示しています。 4台のNVMe P4600 3.2TBドライブ(フォーマット済

本記事は2020年3月11日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 このシリーズでは、重複排除と圧縮、およびイレイジャーコーディングを使用する際に、Nutanixがより多くの使用可能容量を提供し、容量効率性、柔軟性、回復力、およびパフォーマンスを向上させることを学んできました。 また、Nutanixははるかに簡単かつ優れたストレージのスケーラビリティを提供し、ドライブやノードの障害による影響を大幅に軽減していることもわかりました。 このパートでは、NutanixのAOS(Acropolis Operating System)とVMwareのvSAN(Virtual SAN)における、ストレージ層のアップグレードなど、Day 2 オペレーションで重要となるトピックを取り上げます。 双方のプラットフォームでどのようにアップグレードが実行され、これらのアップグレードが環境にどのような影響を与えるかを議論していきます。 まずは単純な「チェックボックスの比較」から始めてみましょう。 アップグレード Nutanix VMware vSAN 停止を伴わないストレージのアップグレード ✅ ✅ 以前の記事でも強調しましたが、「チェックボックス」スタイルのスライドは、製品の能力に関するミスリーディング引き起こしがちです。この問題は、アップグレードなどのDay 2 オペレーションについても大いに当てはまります。 簡単な例を挙げてみましょう。 例1:AOSやvSANの新バージョンへのアップグレードチェックボックスの比較を見ると、両製品とも"停止を伴わないストレージのアップグレード"ができることがわかります。この議論のために、以下のシンプルな定義を使用します。 「停止を伴わないストレージのアップグレード」とは、仮想マシンが停止することなく、ソフトウェア定義ストレージ層のアップグレードを実行できることです。 NutanixとvSANの双方において、仮想マシンが停止することなくアップグレードを実行できるのは事実ですが、仮想マシンとクラスタの可用性/パフォーマンスとデータの整合性にはどのような影響があるのでしょうか? Nutanix のクラウド時代のハイ

本記事は2020年3月5日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 このシリーズでは、重複排除と圧縮、およびイレイジャーコーディングを使用する際に、Nutanixはより多くの使用可能な容量を提供し、より高い容量効率、柔軟性、回復力、およびパフォーマンスを提供することを学びました。 その後、ギアを切り替えて、異機種が混在したクラスタのサポートをカバーしました。これがHCIプラットフォームの拡張能力にいかに重要であるか、また、ツギハギやサイロを作らずに、強力なROIを実現できることを学びました。 次に、書き込み操作のためのI/Oパスを取り上げ、クラスタ内のVMの現在の位置とパフォーマンス/容量利用率に基づいてインテリジェントにデータを配置するNutanix独自のデータローカリティの多くの強みを解説しました。最適な書き込みレプリカの配置により、その後の読み込みI/O操作はNutanix ADSFでは主にローカルで提供されることが保証されます。これは(従来のSANのように)主にリモートで読み込みを提供するvSANとは対照的です。 また、Nutanixは、はるかに簡単で優れたストレージの拡張性を提供しているため、ドライブの故障による影響が大幅に軽減されることがわかりました。 今回は、回復力という重要なトピックをとりあげます。それぞれのプラットフォームがどのようにして様々な ノード障害シナリオに対処し、回復するかについて説明します。反論を避けるために、前回の記事でドライブの障害を取り上げたときと同様、DellEMCの圧倒的に人気の高いオールフラッシュのハードウェア構成であるVxRAIL Eシリーズを使用します。 注:使用されているコモディティなハードウェアは、この記事で提供されている例で、vSANやNutanix ADFS用のSWの動作という観点では、違いはもたらしません。しかし、フラッシュデバイスの量は、本記事で取り上げている、2つの製品間の違いについて、劇的な影響を与えます。 例1: ホストが応答しない/障害になった vSAN ホストが応答しない場合、VMware のドキュメントには以下のようにプロセスが記述されています:"ホストの障害または再起動によりホストが応答しなくなった場合、vSANは、クラスタ内の他の場所にある

本記事は2020年3月2日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 本シリーズではこれまでにNutanixでは重複排除や圧縮はもちろんのこと、イレイジャーコーディングを利用した場合であったとしても、より高い容量効率、柔軟性、回復力、そして性能をより多くの利用可能な容量とともに、ご提供できることを学んできました。 更に、Nutanixは遥かに簡単に優れたストレージの拡張性を提供でき、ドライブ障害の影響を劇的に低減できることも学んできました。 そこから我々はギアを変え、混在クラスタのサポートについて取り上げ、これがなぜHCIプラットフォームの拡張能力、そして完全な置き換えや新たなサイロを作ることなくより強力なROIを実現に重要であるかを学びました。 前回は、書き込みI/Oパスの比較について学習し、クラスタ内のVMの現在の場所とパフォーマンス/容量の使用率に基づいた、データをインテリジェントに配置するNutanix独自のデータローカリティの多くの長所を取り上げました。 今回は、vSANとNutanix ADSFの読み込みI/Oパスの比較について詳しく説明します。 vSAN読み取りI/O パス:書き込みI/Oパスの比較で学んだように、vSAN I/O パスの最良のシナリオは、VMが作成されたホストから移動していないか、偶然にもオブジェクトが存在するホストにVMが存在する場合です。その場合、ローカルのデータオブジェクトと、回復力のために別のホストにリモートなデータオブジェクトを持つことになり、IOパスは最適になります。 シナリオ1: vSANvSANの最適な読み取りI/Oパス ローカルにホストされたオブジェクトを利用ここでは、すべてのデータがローカルでホストされているため、100%の読み取りをローカルで提供できるように見えます。 しかし、vSANはこのような動作はしません。vSANの読み取りは、すべてのオブジェクトに対する「ラウンドロビン」方式で実行されます。つまり、オブジェクトがVMにローカルであるという最良のシナリオでも、FTT1の場合で読み取りの50%、FTT2の場合は読み取りの66%がリモートから提供されるのです。 シナリオ2: vSANシナリオ1でVMをノード2にvMotionしてみましょう。vSANの 最適な読

本記事は2020年2月27日にJosh Odgers氏によって投稿された記事の翻訳版です。原文は こちら。本シリーズの索引はこちら。 本シリーズではこれまでにNutanixでは重複排除や圧縮はもちろんのこと、イレイジャーコーディングを利用した場合であったとしても、より高い容量効率、柔軟性、回復力、そして性能をより多くの利用可能な容量ととともに、ご提供できることを学んできました。 更に、Nutanixは遥かに簡単に優れたストレージの拡張性を提供でき、ドライブ障害の影響を劇的に低減できることも学んできました。 そこから我々はギアを変え、混在クラスタのサポートについて取り上げ、これがなぜHCIプラットフォームの拡張能力、そして完全な置き換えや新たなサイロを作ることなくより強力なROIを実現に重要であるかを学びました。 ブログシリーズの今回のパートではそれぞれの製品の書き込み操作についてのI/Oパスについて、ミラーリング(vSANにとってはFTT1、そしてNutanixにとってはRF2)を例に上げて取り上げていきます。 それとは別にソフトウェア定義のストレージを「インカーネル」vs「コントローラーVM(CVM)」それぞれに展開する場合の比較の記事を公開する予定です。今回の記事ではトラフィックがどのようにノード間を飛び交うか、クラスタをどのように利用するかにフォーカスを当てたいと思います。 vSANとNutanix ADSFの両方で全くの新しい4ノードのクラスタがあり、600GBのvDiskの仮想マシンが1台あると考えましょう。600GBという値は2つの理由からこの値を選んでいます。 後ほど引用するVMwareの記事でもこの大きさを利用している 600GBということはvSANはディスクを複数のオブジェクトに分割する必要があります、これはvSANにとってプラス要素です。(<255GBであれば単一オブジェクトということになります>)vSANから見てきましょう: vSANは255GBというオブジェクトのサイズの上限からvDiskを3つのオブジェクトに分割します。つまり、3のオブジェクトと3つのレプリカ、そしてWitness(ウィットネス)が1つあるということになります。 オブジェクトはVMがホストされているノードともう1台の別のノードに以下に示すとおり配置されることにな

本記事は2020年2月26日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 このシリーズでは、重複排除と圧縮、およびイレージャーコーディングを使用する際に、Nutanixがより多くの使用可能な容量を提供するとともに、より大きな容量効率、柔軟性、回復力、およびパフォーマンスを提供することを学びました。また、Nutanixははるかに簡単で優れたストレージのスケーラビリティを提供し、ドライブの障害による影響を大幅に軽減していることも知りました。このパートでは、異なるモデルで構成するクラスタのサポートについて説明します。これは、HCIプラットフォームの拡張機能にとって非常に重要であり、絶えず変化するユーザーの要件を満たす/それ以上を提供するということを学んでいきます。ハードウェアのキャパシティ/パフォーマンスは非常に速いペースで進歩し続けており、ユーザーが一様な(同一スペックのノードによる)クラスタを使用することを余儀なくされた場合、TCOは上がり、投資の回収に多くの時間を必要とする可能性があります。これだけでも好ましくない事態ですが、それだけでなく、ユーザーが非効率的なサイロを作らなければ、新しいハードウェアの性能や集約のメリットを活かせなくなることを意味します。つまるところ、古いSAN時代のように、ハードウェアを「総入れ替え」する必要があるような状況にはなりたくありません。それでは、簡単な「チェックボックスの比較」から始めてみましょう。 サポートされているクラスタのノード構成 Nutanix VMware vSAN Heterogeneous(異なるモデルノード混在構成) Homogeneous(同一モデルノードのみの構成) 以前にも私が記事で強調したように "チェックボックス "スタイルの評価は、一般的に製品の機能についての誤った理解につながることを述べました。今回の記事は、この("チェックボックス "スタイルの)評価における問題のまさに典型的なモデルで、簡単な例を挙げてみます。 再びDellEMCが推奨するハードウェアプラットフォームであるVxRail E-Seriesの4ノー

本記事は2020年2月19日にJosh Odgers氏によって投稿された記事の翻訳版です。原文は こちら。本シリーズの索引はこちら。 このシリーズの最初の記事では、同じハードウェア上におけるNutanix ADSFとVMware vSANの、実際の使用可能な容量を比較しました。 Nutanixが約30~40%多くの使用可能な容量を提供することがわかりました。 次に重複排除と圧縮の技術を比較したところ、NutanixはvSANよりも容量効率、柔軟性、回復力、パフォーマンスの面で優れていることがわかりました。 次にイレイジャーコーディングについて調査し、Nutanixの実装(EC-Xと呼ばれる)は、リアルタイムにパフォーマンスとキャパシティ効率性のバランスを保つ、ダイナミックかつフレキシブルなものであることを学びました。 次に、私たちは両方のソリューションでどのように容量を拡張できるか、という議論を行いました。vSANには多くの制約があり、拡張の魅力を失わせていることがわかりました。 しかしながら、NutanxのvSANに対するこれらの優位性は、前提としてプラットフォームが障害に対する高い回復力を持っていなければ意味がありません。 このパートでは、オールフラッシュの一般的なハードウェア構成において、両プラットフォームがどのようにして様々なドライブ障害シナリオを処理し、復旧を行うかについて説明します。 最近、あるDell EMC の従業員の方から、これまでのサンプルでは最も広く利用されているハードウェアを使用していない、というご指摘を受けましたので、今回はアーロン氏がイチオシの VxRail E シリーズを使用してみます。Eシリーズは、10本の2.5インチドライブをサポートしています。よくオススメされる、10本の1.92TBのドライブを搭載したオールフラッシュ構成にしましょう。(アーロン、どういたしまして!) VxRail Eシリーズでは、vSANは2つのディスクグループを作成する構成をとります。興味深いことに、1つのディスクグループは最大7つのキャパシティドライブしかサポートできないため、2つのディスクグループを作成せざるを得ないというのがその内実です。 Nutanixに馴染みのない方のために補足しておくと、Nutanixにはディスクグループのような概念や煩わしさはなく

本記事は2020年2月10日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 このシリーズの最初の記事では、同じハードウェア上でのNutanix ADSFとVMware vSANの実際の使用可能な容量を比較しました。 その結果、Nutanixの方が、約30~40%多くの容量を提供できることがわかりました。 次に重複排除と圧縮の技術を比較したところ、NutanixはvSANよりも容量効率、柔軟性、回復力、パフォーマンスの面で優れていることがわかりました。 その後にはイレイジャーコーディングについて見てきました。(EC-Xと呼ばれる)Nutanixの実装では、パフォーマンスとキャパシティの効率性をリアルタイムにバランスさせることができ、動的でありながら柔軟性も提供できることを学びました。 一方、vSAN は「オール オア ナッシング」という原始的なアプローチを採用しているため、フロントエンドへの影響が大きくなります。また、最適なデータに対してイレイジャーコーディングを動的に適用できるわけでもありません。 この記事では、両プラットフォームがどのようにストレージ容量を拡張できるのかを学びましょう:  機能 Nutanix VMware vSAN 単独ドライブの追加 ✅ ✅ ノードの追加 ✅ ✅  この典型的な「チェックボックス」形式の比較からは、両方のプラットフォームが単独のドライブやノードを追加して容量を拡張できることがわかります。私の以前の投稿をいくつか読んでいただいた皆様にはご想像どおりかもしれませんが、以下では、上記のような比較が大きな誤解を招くものであることを説明していきます。 顧客が、プラットフォームを選択したり、既存の環境を拡張したりする際に、考慮すべき重要な要素は数多くあります。 vSANの問題  その1 - 重複排除と圧縮を有効にしたディスクグループにドライブを追加すると、新しく追加されたドライブでは自動的には重複排除と圧縮は実行されません。 参照:  https://blogs.vmware.com/virtualblocks/2017/11/29/vsan-operatio

本記事は2020年2月5日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 最近の記事で、同じハードウェア上のNutanix ADSFとVMware vSANの実際の使用可能容量を比較しました。Nutanixの方が約30~40%も多くの使用可能なキャパシティを実現していることがわかりました。 次に重複排除と圧縮の技術を比較したところ、NutanixはvSANに比べて容量効率、柔軟性、回復力、パフォーマンスの面で圧倒的な優位性を持っていることがわかりました。 ここでは、もう一つ、利用に値する価値があり、なおかつ実績も備えた技術であるイレイジャーコーディングについて見ていきます。イレイジャーコーディングは、重複排除と圧縮にさらに加えて、容量の拡大とパフォーマンスの効率化を可能にします。 以前の記事で強調したように、「チェックボックス」スタイルのスライドは、容量、回復力、パフォーマンスなどの重要なアーキテクチャー/サイジング上の考慮事項について、誤解を招きがちです。 この問題はイレイジャーコーディングにも当てはまります。簡単な例を挙げてみましょう:  機能 Nutanix VMware vSAN イレイジャーコーディング / RAID5と6 ✅ ✅  上記の表では、NutanixとVMware vSANでイレイジャーコーディング / RAID 5と6がサポートされていることを示しています。 この情報を見ると、顧客/パートナー/VARは、両製品のデータ削減機能は同等か、少なくとも購入やアーキテクチャの決定には重要ではないと結論づけてしまうのではないでしょうか? もしそうだとしたら、様々なとんでもない理由で途方も無い勘違いをしたという事になるでしょう。 以下の表は、両製品で現在サポートされているデータ削減の構成を示しています。  機能 Nutanix   VMware vSAN     オールフラッシュ ハイブリッド オールフラッシュ ハイブリッド イレイジャーコーディング / RAID5と6 ✅

本記事は2020年2月3日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 最近の記事で、同じハードウェア上のNutanix ADSFとVMware vSANの実際の使用可能容量を比較したところ、Nutanixの方が約30~40%も多くの使用可能容量を提供していることがわかりました。そうすると次の自然なステップは、使用可能容量にさらなるストレージ容量の効率性をもたらすデータ削減/効率化技術を比較することです。 前の記事では、使用可能容量の比較を単純化するために、2つの製品の機能差を「チャラ」にすると宣言しました。しかし、現実にはチャラにはなりません。Nutanixプラットフォームは、同じハードウェアであってもより多くの使用可能容量を提供する能力を保持しているからです。Acropolis Distributed Storage Fabric (ADSF)の優れたストレージ階層化に加え、データ削減技術を組み合わせたとしたら、vSANは銃撃戦にスプーンを持ってきたようなものです。 この記事では重複排除と圧縮について見ていきます。圧縮、重複排除などのデータ削減技術は、データセットに応じて顧客にさまざまなレベルの価値を提供する実績のある技術です。マーケティング資料などで、これらの機能が比較される際、多くの場合、ベンダーの営業担当者による"チェックボックス"スタイルのスライドが、利用されています。さらに悪いことに、こうしたスライドは殆どの場合、額面通りに(訳注:単に機能の有無しか表していないにも関わらず全く同等であるかの如く)受け取られてしまうため、容量、回復力、パフォーマンスなどの決定的なアーキテクチャ上/サイジング上の考慮事項について誤った想定をしてしまう可能性があります。これは、私が2014年に書いた記事のことを思い出させます:Not all VAAI-NAS storage solutions are created equal(すべてのVAAI-NASストレージソリューションは同じように作成されていない)と題して、私は複数のベンダーがvSphere用のVAAI-NASのサポートを表明しているにも関わらず、必ずしもすべてのベンダーがVAAI-NASの提供する、付加価値となる機能、容量の効率性、そして不必要なIO処理を回避する

本記事は2020年1月30日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 ハイパーコンバージド(HCI)製品を検討する際には、ベンダー、パートナー、VAR(Value Added Resellers: 再販業社)、顧客が複数のソリューションを比較することがよくあります。 このような比較の際には、マーケティング資料や、多くの場合は「チェックボックス」スタイルのスライドが比較され、さらに悪いことには額面通りの価値で比較され、容量、回復力、パフォーマンスなどの重要なアーキテクチャ/サイズの考慮事項について誤った仮定をしてしまうことがあります。 簡単な例を挙げてみましょう: 顧客は、要件を満たすために16台のノードを選択/必要としており、密度、電力効率、高性能のために2ラックユニットあたり4ノード(4N2U)という最も一般的なフォームファクタを選択しています。 フラッシュストレージのコストがユースケースに見合ったものであるため、ノードには6台の1.92TBドライブ(All Flash)が搭載されています。 つまり、16台のホスト* 6台のドライブ=合計96台のドライブを使用しています。 1.92TBドライブがフォーマットされた時の容量を1.78TBとすると96本では170.88TBとなります。 次に、顧客は vSAN と Nutanix を比較します。どちらもデータ保護の主要な形態としてレプリケーションを使用しており(従来の RAID とは対照的)、2 つのコピー(Nutanix では RF2、vSAN では FTT1)と 3 つのコピー(RF3 または FTT2)のどちらかを使用しています。 彼らは簡単な計算をして、次のような結論を出しています。 170.88TB / 2 (RF2 または FTT1) = 85.44TB 使用可能170.88TB / 3 (RF3 または FTT2) = 56.96TB 使用可能 顧客/パートナー/VARは、両製品の使用可能容量は同じであるか、少なくともその差は購入やアーキテクチャ上の決定には重要ではないと結論づけてしまっていないでしょうか? もしそうだとしたら、彼らは2つの重大な理由から大きな勘違いをしたことになるでしょう。 理由1:ファイルシステム/オブジェクトストアのオーバーヘッド 

本記事は2020年2月27日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。 以下はNutanixのAcropolis分散ストレージファブリック(ADFS)とDellEMC VxRAILプラットフォームの基盤をなすVMware Virtual SAN(vSAN)の機能と能力を比較した一連の記事です。このシリースは継続的に更新、拡張されて行きます。 もしも取り上げてほしいご質問やトピックスがあれば@josh_odgersからTwitterやLinkedInでご連絡ください。(※日本語でのお問い合わせは本記事のコメントにてお願いいたします。)また、 DellEMC/VMwareがNutanixに対して行っている数多くの誤った訴えについて取り上げているDellEMC/VMware anti-Nutanix FUD index(DellEMC/VMwareのNutanixに対するFUDへの反論の索引)も御覧ください。     利用可能なキャパシティ比較   重複排除&圧縮   イレイジャーコーディングの比較   ストレージキャパシティの拡張   ドライブ障害の比較   混在クラスタのサポート   Write I/Oパスの比較   Read I/Oパスの比較   ノード障害の比較   ストレージアップグレードの比較   利用可能なキャパシティの比較 ー パート2   メモリ利用の比較   CPU利用の比較   ビッグデータの取り込み性能におけるネットワーク帯域への影響についての比較   高耐久性のフラッシュデバイス要件についての比較   I/Oパスのしなやかさの比較 更に追記予定!        

本記事はJosh Odgers氏が2020年8月21日に投稿した記事の翻訳版です。原文はコチラ 。本シリーズの索引はコチラです。 パート2ではVMC/vSANが「ディスクグループ」アーキテクチャを採用していることからNutanix Clustersのほうが劇的に多くの利用可能なキャパシティを提供しながら、高いしなやかさを保証できることを学びました。パート3ではこの先進性が環境のサイズが拡張していくにつれてより良くなっていくだけであることを見てきました。パート9ではVMware社の直近のAWS i3en.metalインスタンスとNVMeネームスペースについてのアナウンスについて見ていきます。この記事において興味深いのは私がVMC/vSANがそれを支える物理フラッシュストレージデバイスにおいて非効率すぎると言い続けてきたことを確認できるということです。 この新しいホストで利用可能になるRawハードウェアを見ると、8本の7.5TB NVMeデバイスを見つけることができます ― ほぼ60TBのRawメディアで劇的なまでの量のリソースを保証してくれます。残念なことにvSANで7.5TBのNVMeデバイスを利用するには課題があります。もしもi3.metalでの実装をコピーしてメディアをディスクグループの一部へと分解していくと、キャッシュ層における利用されることのないリソースについてどうすることもできなくなってしまいます。リファレンス: HTTPS://BLOGS.VMWARE.COM/VIRTUALBLOCKS/2020/07/15/I3EN-METAL-ENHANCED-CAPACITY/ ですから、「ディスクグループ」のアーキテクチャ上の成約を回避するために、VMC on AWSはNVMeのネームスペースを利用し、フラッシュデバイスのキャパシティを論理的に分割し、別々のデバイスとして認識させています。これによって、VMC/vSANはWriteキャッシュレイヤーにおけるキャパシティの無駄を最小化することができるため、その意味ではこれは良い改善になるように思えます。VMCのソリューションでは7.5TBのNVMeフラッシュストレージデバイスを4つのネームスペースで分割し、32の独立した認識デバイスを作り上げます。そしてそれらはそれぞれのディスクグループが2つの専用デバイス利用した

Badges

Show all badges