日本語フォーラム (Japanese)

Nutanixのハードウェアおよびソフトウェア製品に関するディスカッション。

198 Topics
187 Replies

パブリッククラウドの課題 – パート8 – ストレージの拡張と運用への影響

本記事はJosh Odgers氏が2020年8月21日に投稿した記事の翻訳版です。原文はコチラ。本シリーズの索引はコチラです。このシリーズのパート2とパート3では、Nutanix ClustersとVMware VMConAWSで同じAWSベアメタル（i3.metal）ハードウェアを基盤として使用した場合に、Nutanix Clustersのほうが使用可能な容量が多くなることを紹介しました。次に、データ効率テクノロジーと回復力に関する考慮事項を比較し、容量効率、柔軟性、回復力、パフォーマンスに関してNutanix ClustersがvSANよりも明らかに優れていることを紹介しました。パート5では、Nutanix Clustersがストレージデバイス（NVMe SSD）のデバイス障害をどのように処理するかについて、パート6ではベアメタルインスタンスの障害の場合について紹介しました。両方の場合とも、Nutanix ClustersはVMC/vSANよりも影響が小さく、Nutanixの基盤となる分散ストレージファブリック（AOS）のおかげでデータ整合性と回復力を短時間で回復できます。パート7では、コントローラーVM（CVM）にNutanix Clusters（AOS）が実装されるため、ストレージI/Oパスでハードウェアやソフトウェアの問題が発生しても、VMCよりも回復力が高く、影響が小さいことを紹介しました。VMCでは不要なHAイベントがノードに発生し、大きな影響が生じます。AWS EC2では、NutanixやVMwareなどのベンダーはハードウェア層を制御できないため、ストレージ容量を拡張するには、シンプルに、環境にベアメタルインスタンスを追加します。どちらの製品の場合でも、ストレージ容量要件に対応するには、新しいベアメタルインスタンスを追加するだけで済むとも言えます。本当にそれだけでしょうか。いいえ、そうではありません。実は、どちらの製品においても、新しい容量を実際に使用するためには時間と労力が大幅にかかります。VMC/vSANの問題1 – 新しいノードをVMCクラスターに追加しても、新しいノードのストレージリソースは既存の仮想マシンの使用可能な容量（またはパフォーマンス）に追加されません。どういうことだろうか、とお思いになりますよね。例えば、4ノードのVMC/

3 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

NutanixはAOS 5.18でHCIの歴史における新たなマイルストーンへ到達

本記事はSteve Carter氏が2020年10月12日に投稿した記事の翻訳版です。原文はこちら。 AOS 5.18のリリースはHCI顧客に革新的な分散アーキテクチャの上に実装された新しい機能でアプリケーションパフォーマンスの向上をもたらす一方で、IT運用のこれまで以上のシンプル化と自動化を提供することで、ハイパーコンバージドインフラストラクチャの歴史における大きな一歩を踏み出しました。ストレージ性能の向上AOSのバックボーンであるウェブスケールアーキテクチャはパフォーマンス、しなやかさ、そして拡張性に重きをおくのみならず、これらの領域に置ける継続的な革新を実現することにも重きをおいています。よく練り込まれたメタデータはスケールアウトアーキテクチャの基盤であり、妥協することのないしなやかさと柔軟性、そして想定通りの拡張性を実現しています。このメタデータは時々に応じたデータローカリティ、想定通りの高性能の提供をアクティブデータがアプリケーションのそばに維持することで提供しています。そして重要なことはAOSは適切なしやなやかさ、セキュリティ、性能をAOSの開発陣が速いペースでの堅牢な機能の確信を継続していくために、ユーザースペースで実装されているということです。 Blockstore(ブロックストア)Nutanixの完全に新しいブロックストアは低いCPUのオーバーヘッドと低遅延で、効率的にストレージメディアのIOを管理します。ブロックストアはユーザースペースのファイルシステムレイヤとブロック管理レイヤを司り、I/O操作を提供しながら、劇的にシステムコールとカーネルオーバーヘッドを削減します。ブロックストアによってAOSはあらゆる物理デバイス(NVMe、SSD、HDD)上にデータを迅速にかつ効率的に格納しながら、その一方でNANDベースのデバイスの摩耗を抑えることができます。まず最初はこの機能はNVMeデバイスを1つもしくは複数保持するオールフラッシュベースシステム向けに利用開始され、今後のリリースでより広範に利用されることになります。 SPDKブロックストアはAOSがIntel社のSPDK(Storage Performance Development Kit - ストレージパフォーマンス開発キット)を活用して、NVMeデバイスをユーザースペースから直接アクセスできる

3 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

AOS 5.19登場: パフォーマンスの向上、セキュリティの改善、自動化された運用

本記事は2020年12月18日にAOS Product Teamが投稿した記事の翻訳版です。原文はこちら。 Nutanix HCIでリモートワークをセキュアに、ワークロードを加速、インフラストラクチャの自動運転を実現AOS 5.19とそれに関連したPrism Centralのリリース PC 2020.11によってNutanixのハイパーコンバージドインフラストラクチャを利用しているお客様に新たな機能をお届けできることを大変喜ばしく感じています。AOS 5.19はAOS 5.18においてなし得たブレイクスルーの上でのさらなるパフォーマンスの改善とデータの暗号化およびセキュア化についてのビルトインの鍵管理能力を拡張を提供します。AOS 5.19ではビルトインのハイパーバイザーであるAHV上で動作する仮想マシンのポータビリティも向上しており、先進的な管理機能との一元化なども行なわれています。セキュリティROBO環境向けのネイティブ鍵管理システム(KMS - Key Management System)我々は新たな環境においてもいずれの場所であっても暗号化を保証することで継続的にセキュリティをシンプル化し続けています。NutanixはすでにFIPS 140-2認証を得たデータの最終暗号化と鍵管理を外部のKMSもしくはネイティブのKMSの選択肢とともに提供しています。更に詳しくは Data at Rest guideを参照してください。このリリースで我々はネイティブのKMSを拡張し、1もしくは2ノードのリモート&ブランチ(ROBO)サイトをサポートし、シンプルでコスト効率の高いセキュアなエッジソリューションを実現しました。ネイティブKMSはリモートのPrism Centralベースのroot-of-trustの新たなオプションも提供し、リモートオフィス拠点でのさらなる保護を実現します。AOS 5.19では複数のリモートのクラスタから中央のPrism Centralインスタンスへとローカルに展開されたKMSインスタンスのバックアップ機能も提供し、容易にデータと鍵の双方を保護しセキュアにすることができます。 AHVのMicrosoftのVBS と Credential GuardのサポートAOS 5.19では今年のはじめに開始したセキュアブートについての一連の動き

3 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

ネットワークトラフィックがビッグデータインジェストのパフォーマンスに与える影響の比較 – Nutanix vs VMware vSAN / DellEMC VxRAIL

本記事は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％増）多くかかりました。

3 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

異なるモデルでのクラスタサポート - Nutanix vs VMware vSAN

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

3 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

パブリッククラウドの課題– パート9 – キャパシティの改善と妥協なきパフォーマンス(更にその上でしなやかさは?)

本記事は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つの専用デバイス利用した

3 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

書き込みI/O パス (FTT1/RF2) の比較– Nutanix vs VMware 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台の別のノードに以下に示すとおり配置されることにな

3 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

高耐久フラッシュデバイス要件の比較 - NutanixとVMware vSAN / Dell EMC VxRAILの比較

本記事は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の大きなデメリットである」と主張することがあるようです。今日、私が見たそのような主張の例を１つ紹介します（この投稿に触発されたので、Dell EMCのNathan Bulmon氏に感謝します）。「Nutanixは、より多くの書き込み命令を行うため、高価なフラッシュドライブをより多く必要とします」とのことです。参考訳 : Josh Odgersさん、記事を読ませていただきました。HWとSWの統合されたアップデートについて、つまりインカー

3 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

Nutanix と VMware vSAN/DellEMC VxRAILを比較

本記事は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パスのしなやかさの比較更に追記予定!

3 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

使用可能な容量の比較 - Nutanix ADSFとVMware vSAN

本記事は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：ファイルシステム/オブジェクトストアのオーバーヘッド

3 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

読み取りI/Oパスの比較 - Nutanix vs VMware vSAN

本記事は2020年3月２日に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の最適な読

3 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

重複排除と圧縮の比較 - Nutanix ADSF vs VMware vSAN

本記事は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処理を回避する

3 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

ノード障害の比較 – Nutanix vs VMware vSAN

本記事は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は、クラスタ内の他の場所にある

3 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

I/Oパスのしなやかさの比較 – Nutanix AOS & VMware vSAN/DellEMC VxRAIL

本記事は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

2 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

HCIプラットフォームの可用性、回復力、そして整合性シリーズ

HCIプラットフォームの可用性、回復力、そして整合性シリーズの索引です。パート1 X-Rayおよび”Platform Availability, Resiiency & Integrity”シナリオの紹介パート2 Nutanix AOS vs vSAN/VxRAIL パート3 Nutanix AOS vs vSAN/VxRAIL I/Oタイムアウトを増やした場合パート4 Nutanix AOS vs vSAN/VxRAIL 完全なデータ退避モードの場合パート5 Nutanix AOS vs vSAN/VxRAIL オブジェクトの修復タイマーを0に減らした場合パート6 大規模クラスタ & vSAN 7U1のデータ整合性パート7 vSAN 7U1と対障害性 2 (FTT2) パート8 vSAN/VxRAILのストレッチクラスタはデータ整合性を維持できるか？パート9 X-RayのシナリオがGAしました!

2 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

ストレージのアップグレード比較 - NutanixとVMware vSAN/VxRAILの比較

本記事は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 のクラウド時代のハイ

3 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

イレイジャーコーディングの比較 - Nutanix ADSF vs VMware vSAN

本記事は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 ✅

3 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

HCIプラットフォームの可用性、回復力、そして整合性 – パート1

本記事は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)、インストール後の運用の確認の一部、そして構成変更後の期間での検証の一部として利用できるようにすることです。特に手を加える必要もなく、検証は自動的に利用可能なクラスタ/利

2 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

使用可能な容量の比較 – パート2 – Nutanix ADSF vs VMware vSAN

本記事は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ドライブ（フォーマット済

3 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

HCIプラットフォームの可用性、回復力、そして整合性 – パート2

本記事は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

2 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

ストレージ容量の拡張 - Nutanix vs VMware vSAN

本記事は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

3 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

HCIプラットフォームの可用性、復元力、そして整合性–パート3 – VMware vSAN / DellVxRAILの I/Oタイムアウト増加比較

本記事は2021年1月14日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの牽引はこちら。パート2では、Nutanix AOSがプラットフォームの可用性、復元力、そして整合性テストのすべてのフェーズでVMの可用性とI/Oの整合性を維持しているのに対し、vSAN 7 Update 1は再起動フェーズと電源オフフェーズでいずれも失敗し、何百ものI/Oエラーが検出されていたのを確認しました。パート3では、I/Oタイムアウトをデフォルトの30秒から60秒、90秒、120秒、150秒、そして最終的には180秒に増やすことでどのような結果になるかを確認していきます。 I/Oエラーが検出される前に、SCSIスタックは180秒のタイムアウトで6回の再試行を行います。つまり、エラーが検出された場合、1080秒後にI/Oが失敗したことになります（X-Rayのタイムアウトを最大の180秒に設定した場合）。それでは結果を見てみましょう。メンテナンスモードフェーズ： vSANは、すべてのタイムアウトレベルでVMの可用性を維持しています。 vSAN はメンテナンスモードフェーズで I/O エラーは発生しませんでした。興味深いことに、稀にメンテナンスモードフェーズで vSAN が I/O エラーを起こすことがありましたが、これには正直驚きでした（少なくとも vSAN 7 Update 1 では）VMware が vSAN 7 Update 1 で次のように発表していたからです。 vSAN 7 Update 1では、データの高可用性を実現するために、ホストがメンテナンスモードの間の耐久性を強化し、Ensured Accessibilityモードを採用しました。FTT=1の障害耐性を持つVMオブジェクトは、ホストをメンテナンスモードにすると、唯一のアクティブレプリカを含む 2 番目のホストが利用できなくなった場合のデータの可用性が強化されます。これにより、回復不能なノード障害が発生した場合、ホストがメンテナンスモードを終了すると、オブジェクトデータは保存された増分書き込みを使用して適宜更新されます。出典：https：//blogs.vmware.com/virtualblocks/2020/09/15/whats-new-in-vsan-7-upd

2 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

メモリ利用量の比較 – Nutanix ADSF vs VMware vSAN / DellEMC VxRAIL

本記事は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

3 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

CPU利用の比較 – Nutanix AOS vs VMware vSAN / DellEMC VxRAIL

本記事は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の結果は両プラットフォーム

3 years ago

TetsuoMiyoshiNutanix Employee

posted in 日本語フォーラム (Japanese)

ドライブ障害の比較 - Nutanix ADSF vs VMware vSAN

本記事は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にはディスクグループのような概念や煩わしさはなく

3 years ago

Page 5 / 8

日本語フォーラム (Japanese)

ドライブ障害の比較 - Nutanix ADSF vs VMware vSAN

ストレージ容量の拡張 - Nutanix vs VMware vSAN

日本語フォーラムの使い方

198 Topics

パブリッククラウドの課題 – パート8 – ストレージの拡張と運用への影響

NutanixはAOS 5.18でHCIの歴史における新たなマイルストーンへ到達

AOS 5.19登場: パフォーマンスの向上、セキュリティの改善、自動化された運用

ネットワークトラフィックがビッグデータインジェストのパフォーマンスに与える影響の比較 – Nutanix vs VMware vSAN / DellEMC VxRAIL

異なるモデルでのクラスタサポート - Nutanix vs VMware vSAN

パブリッククラウドの課題– パート9 – キャパシティの改善と妥協なきパフォーマンス(更にその上でしなやかさは?)

書き込みI/O パス (FTT1/RF2) の比較– Nutanix vs VMware vSAN

高耐久フラッシュデバイス要件の比較 - NutanixとVMware vSAN / Dell EMC VxRAILの比較

Nutanix と VMware vSAN/DellEMC VxRAILを比較

使用可能な容量の比較 - Nutanix ADSFとVMware vSAN

読み取りI/Oパスの比較 - Nutanix vs VMware vSAN

重複排除と圧縮の比較 - Nutanix ADSF vs VMware vSAN

ノード障害の比較 – Nutanix vs VMware vSAN

I/Oパスのしなやかさの比較 – Nutanix AOS & VMware vSAN/DellEMC VxRAIL

HCIプラットフォームの可用性、回復力、そして整合性シリーズ

ストレージのアップグレード比較 - NutanixとVMware vSAN/VxRAILの比較

イレイジャーコーディングの比較 - Nutanix ADSF vs VMware vSAN

HCIプラットフォームの可用性、回復力、そして整合性 – パート1

使用可能な容量の比較 – パート2 – Nutanix ADSF vs VMware vSAN

HCIプラットフォームの可用性、回復力、そして整合性 – パート2

ストレージ容量の拡張 - Nutanix vs VMware vSAN

HCIプラットフォームの可用性、復元力、そして整合性–パート3 – VMware vSAN / DellVxRAILの I/Oタイムアウト増加比較

メモリ利用量の比較 – Nutanix ADSF vs VMware vSAN / DellEMC VxRAIL

CPU利用の比較 – Nutanix AOS vs VMware vSAN / DellEMC VxRAIL

ドライブ障害の比較 - Nutanix ADSF vs VMware vSAN

Badges

日本語フォーラム (Japanese)

Badges

Sign up

Login to the community

Scanning file for viruses.

This file cannot be downloaded