日本語フォーラム (Japanese)

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

198 Topics
187 Replies

198 Topics

書き込み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 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)

ドライブ障害の比較 - 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

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)

イレイジャーコーディングの比較 - 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)

重複排除と圧縮の比較 - 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

SyncraAdventurer

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

【質問】日本語版サポートドキュメントの所在について

日本語フォーラム初投稿＆質問になります。よろしくお願いします。 Nutanix関連でベストプラクティス的なものをググると、"doc-" で始まるファイル名のPDFが時折ヒットします。この内容が、単に英語版マニュアルやKBを翻訳しただけではなく、要点を簡潔に解りやすくまとめたうえで日本語化してあり、とてもありがたいものでした。最近気付いたのですが、過去に拾ったPDFでも似たファイル名のドキュメントがありました。いままでに見つけたのは、以下3点です。https://www.nutanix.com/content/dam/nutanix/ja/documents/support/doc-licensing.pdfhttps://www.nutanix.com/content/dam/nutanix/ja/documents/support/doc-node-restart.pdfhttps://www.nutanix.com/content/dam/nutanix/ja/documents/support/doc-aos-upgrade.pdfいずれも同じフォーマットで、URLも同じ場所なので、このシリーズが他にもあるのではないかと思いました。もしあるなら、全部見てみたいです。内容的に、おそらく日本のサポート担当にて作成されたのだと思うのですが、このドキュメントの一覧のようなものはあるのでしょうか？情報ありましたら、お知らせいただけると幸いです。

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)

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)

パブリッククラウドの課題– パート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

yujiaraVoyager

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

ノード復旧方法に関して

2016年頃に3ノードで導入したNutanix(vSphere)がノード障害を起こしてしまいました。調べてみると、ハードウェア障害でした。現在、障害の出ているノードはvSphere上では、該当のノードに”!”マークが表示されている状態です。iDRACでは、アクセスできており、メモリエラーが出ていました。(ソフトウェア・ハードウェア共にサポートが切れている状態です。Error：Correctable memory error rate exceeded for DIMM_B1.障害からの復旧方法をご教示いただけませんでしょうか。疑問点は以下の通りです。・障害の出ているノードをシャットダウンしても良いかどうか。・ハードウェアエラー復旧後のノード再登録方法。以上となります。よろしくお願いいたします。

3 years ago

smzkstsNutanix Employee

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

「ブログ書いたよ！」＆「こんな記事見つけたよ！」お知らせコーナー

Nutanixに関するブログを書いていただいた方は、より多くの方に読んでいただけるよう、ぜひこちらでお知らせください！また、Nutanixに関するメディア記事や海外ブログなどなど、ご自身が書いたもの以外でも「コレいいな」と思うものを見つけた際には、是非ご紹介ください！

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は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)

パブリッククラウドの課題 – パート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)

パブリッククラウドの課題 – パート7 – ストレージI/Oパスと回復力への影響

本記事はJosh Odgers氏が2020年8月20日に投稿した記事の翻訳版です。原文はコチラ。本シリーズの索引はコチラです。パート6では、ベアメタルインスタンスに障害が発生した後で、VMware VMCとNutanix Clustersの各アーキテクチャーではリビルドがどのように実行されるのかについて、および回復力とパフォーマンスにおいてNutanixで得られる主な利点について紹介しました。この投稿では、I/OパスにおいてI/Oが「スタック」または「ハング」するというシナリオに両方の製品がどのように対処するのかについて、および、これらの状況が及ぼす影響について紹介します。説明に入る前に、概念レベルで、インフラストラクチャーの目的は最大限の可用性とデータ整合性を確保することです。そのため、インフラストラクチャーと業務に対するリスクや影響を最小限に抑えるように、あらゆる障害に対処する必要があります。それを前提に、パブリッククラウドでVMware VMCとNutanix Clustersを使用する場合に、I/Oが「スタック」または「ハング」すると、どのようなことが発生するかを紹介します。VMwareはKB「How to handle lost or stuck I/O on a host in vSAN cluster (71207)」を公開しており、このKBの中で、I/Oパス内のいずれかの場所（ストレージコントローラーや物理ドライブ自体など）でI/Oの「スタック」または「損失」が発生した場合に、vSANがどのように対処するかを紹介しています。VMwareでは、この症状を以下のように説明しています。ストレージコントローラー上やストレージディスク上でI/Oのスタックまたは損失が発生した場合、ESXiストレージスタックはタスク管理リクエストを使用してI/Oを中止するように試み、以下のコンソールメッセージが表示されます。参照先：HTTPS://KB.VMWARE.COM/S/ARTICLE/71207続けて、以下のように説明しています。ホスト上でこのような損失I/Oが見つかった場合、vSANはこのホストで強制的にPSODを実行し、このホストがクラスター内の他のホストに影響を及ぼさないようにします。参照先：HTTPS://KB.VMWARE.COM/S/ARTICLE/712

3 years ago

TetsuoMiyoshiNutanix Employee

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

お客様とパートナー様への公開書簡

本記事はNutanixの新CEOであるRajiv Ramaswami氏が2020年12月9日に公開した記事の翻訳版です。原文はこちら。お客様の喜びへの絶え間のないフォーカスとともに、シンプルで柔軟性があり、コスト効率の良いソリューションを提供することがNutanixが行っていることの中心にあります。そのNutanixの新たなCEOとして、この機会で私自身をご紹介と、Nutanixに入社してどのように興奮しているか、そして皆様のビジネスの成功に導くお手伝いへの継続的なコミットについてお伝えしたいと考えています。本日、私はNutanixのCEO職にテクノロジー産業に置ける30年以上の経験とともに、つくこととなりました。直近ではVMware社でChief Operating Officer, Products and Cloud Servicesを務めていました。VMwareに入社する以前はIBMでキャリアをスタートさせたあと、Broadcom、Nortel、そしてCiscoを含む業界をリードする企業で様々なシニアリーダーシップを務めてきました。これらの時を経て、私は人材、テクノロジー、プロダクトを一体化させることで強力な企業を生み出す重要な役割について実感を得てきました。Nutanixは急速に成長し、データセンターに革命を起こし続けるハイパーコンバージドインフラストラクチャ市場を先駆け、作り出てきました。創業以来Dheerajは非常にうまくチームの舵を取り、18,000社以上のお客様とともに創業から$1B+企業へと導きました。実際私はDheerajが2010頃にシリコンバレーでNutanixについて述べていた場面に同席していたことを覚えています。その初期ステージからNutanixが公開企業として大規模に成長していることは素晴らしいことです。Nutanixの成長を勢いのある、そして手強い競合の立場から横目で見ながら、私はその企業がお客様そしてパートナー様と作り出すシンプルさと堅牢性そして深いレベルでのお客様の信頼と満足の代名詞とも呼べるイノベーティブな製品に長きに渡って称賛してきました。 2021はNutanixの進化、ソフトウェアサブスクリプションモデルへの転換へ新たなるステージをもたらす年になり、我々のハイパーコンバージドインフラストラクチャに置けるリーダーシップを

3 years ago

TetsuoMiyoshiNutanix Employee

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

パブリッククラウドの課題 – パート6：ベアメタルインスタンスの障害

本記事はJosh Odgers氏が2020年8月19日に投稿した記事の翻訳版です。原文はコチラ。本シリーズの索引はコチラです。パート1では、パブリッククラウドで環境の価値を高めるために、使用可能なネットワーク帯域幅を効率よく利用することがどれだけ重要なのかについて紹介しました。また、使用可能な帯域幅を最大限に確保すると、フラッシュデバイス（NVMe/SSD）の障害の場合にMean Time To Recover（MTTR：平均修復時間）が短くなり、回復力がどれほど向上するかについても紹介しました。ベアメタルインスタンス（サーバーとノード）の障害の場合にも同じ概念が当てはまります。ただしこの場合は、完全なデータ整合性を回復するためには、単一の1.9TB NVMeデバイス（i3.metalの場合）ではなく8つの1.9TB NVMeデバイスのデータを再保護する必要があります。そのため、リビルドをタイムリーに実行して影響を最小限に抑えるためには、効率的でスケーラブルなアーキテクチャーであることが重要です。まずVMware VMCについて、リビルドの基盤となるアーキテクチャーについて紹介します。VMC（vSANがベース）では、オブジェクト（最大255GB）がリストされるのは、オブジェクトがホストされているソースノード上のキャパシティドライブから、クラスター内の他のノード上のキャッシュドライブ（ディスクグループ当たり1つ）に対してだけです。AWSで、よく使用されているi3.metalインスタンス（8 x 1.9NVMeデバイス）を使用する場合、VMCのリビルド操作では主に2つのNVMeデバイス（2つの「キャッシュ」ドライブ）しか使用されず、キャッシュドライブが一杯になると、残りの3つのNVMeデバイス（ディスクグループ当たり）にリビルドデータが排出されます。つまり、VMwareのVMCを使用する場合、重要なリビルドトラフィックではリビルド用にNVMeドライブの20%しか使用されません。そのため、パート2とパート3で紹介したように、VMCでは使用可能な容量が少なくなるだけでなく、回復力とパフォーマンスの観点でハードウェアが効率よく使用されないため、明らかにVMCプラットフォームの価値が下がります。VMC/vSANでは、クラスター内の使用可能なハードウェアが最大限に利用されない

3 years ago

TetsuoMiyoshiNutanix Employee

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

NutanixがForresterのハイブリッドクラウド管理Waveでストロングパフォーマーとしてデビュー

本記事は2020年12月2日にAaditya Sood氏とVijay Raypati氏が投稿した記事の翻訳版です。原文はコチラ。比較的にこのマーケットセグメントへの参入は新しいメンバーであるNutanixはThe Forrester Wave™: Hybrid Cloud Management, Q4 2020への参加の招待を受けました。ForresterはHCM Waveにおいて34の指標を用いて様々なソリューションを評価しており、我々は今回はじめての参加でしたが、ストロングパフォーマーとしてこれに含まれたことを大変誇りに思います。Forresterはハイブリッドクラウド管理(HCM)をガバナンス、可視性、ライフサイクル管理、そして最適化のためのインサイトをパブリックとプライベート環境を含むマルチクラウドに渡って提供するソフトウェアスタックとして定義しています。 Nutanixでは我々は2つの製品を提供していますー Calm および Xi Beam ーこれらはハイブリッドクラウド環境を管理するために必要な機能をソリューション実装の簡単さと利用のしやすさとともに提供しています。我々のこのレポートの分析によるとこのレポートに含まれるいくつかのベンダーは広範な製品群によって彼らのHCMソリューションを構成していますが、NutanixのHCMはエンタープライズの顧客がハイブリッドクラウド内で自身のアプリケーションとデータを管理するために広く共通して利用される機能を深いレベルでサポートし提供している点を強調したいと考えています。なぜハイブリッドクラウド管理なのか? すべては自動化、コストの統制、セキュリティ自身のプライベートクラウドに加え、複数のパブリッククラウドでワークロードを稼働させている組織は単一ツールでのタスクの自動化、コストの管理、そしてセキュリティポリシーの徹底を求めています。こうしたツールがなければITおよびクラウドチームはそれぞれの環境向けの複数のプロプライエタリツールセットと運用モデルを管理しなければなりません。これはコスト増加、展開の遅さ、そしてエラーの増加に繋がります。簡単に展開できるパッケージによってNutanixは顧客が自身が利用するHCMソリューションから最大の付加価値を迅速に、そして自身のニーズにあった幅広い購買モデルの選択肢とともに提

3 years ago

TetsuoMiyoshiNutanix Employee

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

パブリッククラウドの課題 – パート5：ストレージデバイス障害と回復力への影響

本記事はJosh Odgers氏が2020年8月18日投稿した記事の翻訳版です。原文はコチラ、本シリーズの索引はコチラです。パート1では、AWSでVMwareのVMC製品を使用する場合、VMwareやその顧客はネットワーク帯域幅を制御できないという、VMCのコアアーキテクチャーが及ぼす重大な影響について紹介しました。パート1をお読みいただいていない場合は、この投稿を読み進める前に目を通していただくことをおすすめします。パート1で紹介している概念は、この投稿のテーマである「デバイス障害と回復力への影響」について理解を深めていただくために重要です。パート2、パート3、およびパート4では、AOSの機能のおかげで、Nutanix ClustersではVMCよりも高いフロントエンドパフォーマンスを発揮しながら、使用可能な容量も多くなるということについて紹介しました。また、パート4では、VMC（vSAN）で圧縮と重複解除を使用すると、ドライブ障害のリスクや影響が大きくなるのに対して、Nutanix Clustersでは、このようなデータ効率テクノロジーを使用するかどうかに関係なく、回復力への影響がないことを紹介しました。このようにNutanix ClustersはVMC/vSANに対して優位性がありますが、プラットフォームが障害に対して高い回復力を備えていなければ意味がありません。この投稿では、AWS i3.metalインスタンスを使用する場合に、Nutanix ClustersとVMware VMCがさまざまなドライブ障害シナリオをどのように対処し、どのように回復するのかについて紹介します。AWS EC2 i3.metalインスタンスなどのパブリッククラウドサービスを使用する際、NVMeフラッシュデバイスは耐久性が高くないと考えられるため、VMC/vSANなどの製品がディスクグループごとに単一キャッシュドライブに大きく依存する場合は、Drive Writes Per Day（DWPD：1日当たりのドライブ書き込み数）の指標が適切でない可能性がある、ということを考慮することが重要です。VMwareは記事「Understanding vSAN Architecture: Disk Groups」の中で、キャッシュドライブに関して以下のように述べています。高耐久性フラッシュデバイ

3 years ago

TetsuoMiyoshiNutanix Employee

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

パブリッククラウドの課題 – パート4：データ効率テクノロジーと回復力に関する考慮事項

本記事はJosh Odgers氏が2020年8月17日に投稿した記事の翻訳版です。原文はコチラ。本シリーズの索引はコチラです。パート1では、AWSでVMwareのVMC製品を使用する場合、VMwareやその顧客はネットワーク帯域幅を制御できないという、VMCのコアアーキテクチャーが及ぼす重大な影響について紹介しました。また、（オンプレミスの顧客が使用しているのと）同じAOSエンタープライズクラウドソフトウェアをベースとするNutanix Clusters製品で、Nutanix固有のデータローカリティ機能のメリットが得られることを紹介しました。この機能によって、ネットワークへの依存を最小限に抑えてネットワークリソースを解放できるため、ストレージや仮想マシンのパフォーマンスが向上し、クラスターの回復力や機能も強化されます。パート2とパート3では、AOSの機能によって、VMCよりも高いフロントエンドパフォーマンスを発揮しながら、使用可能な容量も多くなることを説明し、その結果としてNutanixで得られるTCO/ROIのメリットについて紹介しました。このようなメリットが得られる要因として、Nutanix AOSの卓越したイレージャーコーディングが挙げられます。また、Nutanixの高度な分散ストレージファブリックによって、レガシーな「キャッシュ+キャパシティ」アーキテクチャーを使用するVMC（vSANベース）のディスクグループよりも使用可能な物理容量が多くなることも挙げられます。このパート4では、VMwareのVMC製品とNutanix Clusters製品がそれぞれ備えているデータ効率機能について紹介し、AWSを使用した本番環境でのこれらのメリットと影響について明らかにします。Nutanix ADSFとVMware vSANの重複排除と圧縮の比較に関する投稿で、両方の製品が3つの主要なデータ効率テクノロジー（圧縮、重複排除、イレージャーコーディング）を備えていることを紹介しました。これらのテクノロジーは、表面上は同じように思えますが（以下の表を参照）、詳細は大きく異なります。また、これらのテクノロジーを有効にする場合、vSAN（VMCのベース）ではクラスターレベルの設定が「オールオアナッシング」であり、柔軟性が非常に低いことも紹介しました。VMCの顧客は、圧縮と重複排除

3 years ago

TetsuoMiyoshiNutanix Employee

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

パブリッククラウドの課題 – パート3：大規模環境でのTCO/ROIとストレージ容量

本記事はJosh Odgers氏が2020年8月14日に投稿した記事の翻訳版です。原文はコチラ。本シリーズの索引はコチラです。パート2では、効率的なAOSのおかげで、3ノードのi3.metal環境でのNutanix Clusters on AWSソリューションでは、使用可能な容量がVMwareのVMCよりも24.5%多くなることを説明しました。このことは小規模環境の顧客やコスト意識の高い顧客にとっては朗報ですが、Nutanixにおいて、環境が拡張されても容量やROIにおいて同様なメリットが得られるのか疑問に思う方もいらっしゃると思います。今回の投稿では、次の3つのシナリオについて紹介します。4ノードクラスターと5ノードクラスター 6ノードクラスター 16ノードクラスターこの3つのすべてのシナリオで、AWS i3.metalサービスを使用します。この3つの例を取り上げるのは、VMCでは、3ノード環境、4～5ノード環境、および6ノード以上の環境に対して、それぞれ異なるストレージポリシーがデフォルトで適用されるためです。16ノードの例では、VMCでサポートされている最大規模のクラスターを使用した場合について紹介します。 4ノードクラスターと5ノードクラスターの比較4ノード環境の場合、VMwareのVMCは、論理容量に対して物理容量のオーバーヘッドが2倍になるFTT1（ミラーリング）から、3+1ストライプサイズを使用するイレージャーコーディング（RAID5）に切り替わります。切り替え後は、1.33倍のオーバーヘッドで容量が提供されます。参照先：https://blogs.vmware.com/virtualblocks/2018/06/07/the-use-of-erasure-coding-in-vsan/イレージャーコーディング（RAID5）に切り替わると、使用可能な容量が増えるため、切り替えはその点で意味がありますが、以下のような重大な影響が生じます。オールオアナッシング的なアプローチのため、I/O用の重要なパスに影響が生じる。VMwareもパフォーマンスへの影響を認識している 4ノードクラスターでは単一ノード障害を許容できず、単一ノード障害の場合は自己修復が不可能（3+1のストライプでは4つのノードが必要）なため、回復力が低下する I/O処理が少なくとも4つのノード

3 years ago

TetsuoMiyoshiNutanix Employee

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

パブリッククラウドの課題 – パート2：TCO/ROIとストレージ容量

本記事は2020年8月13日にJosh Odgers氏が投稿した記事の翻訳版です。原文はコチラ。本シリーズの索引はコチラです。 Amazon EC2（AWS）などのパブリッククラウドサービスをNutanix ClustersやVMware Cloud（VMC）などの製品と併用することを検討する場合、ソリューションの仕組みや関連する総所有コスト（TCO）と投資対効果（ROI）を把握して、これらの要素を考慮することが重要です。簡単ながらも見落しがちなのは、どの程度のベアメタルリソースを実際に使用できるのかという点です。以前に製品比較したときに紹介したのですが、マーケティング資料（大概は「チェックボックス」形式のスライド）を比較して、記載されているままの価値を真に受けると、アーキテクチャーやサイジングに関して容量や回復力、パフォーマンスなどの重要な要素を検討する際に、誤った認識を前提としてしまう可能性があります。AWS i3.metalでVMCを使用する場合について、簡単な例を紹介します。AWSでi3.metalを使用した3ノードVMCクラスターVMCで31.1TBの物理容量が提供されているのが分かります。VMCは「ディスクグループ」を使用するvSANをベースとしており、「ディスクグループ」ごとに「キャッシュ」ドライブが必要です。VMCに対して、VMwareでは2つのディスクグループを使用することを選択しているため、キャッシュドライブとキャパシティドライブの比率は1対3になります。3ノードVMCクラスターのディスクグループ構成（i3.metal）次に、Nutanix Clusters on AWSを使用する場合の、使用可能な容量について紹介します。 Nutanix AOSのおかげで、3つのi3.metalノードで39.8TBが提供されており、VMCの場合よりも24.5%多くなっています。小規模な3ノード環境でも、AWSでi3.metalインスタンスを使用する場合は、Nutanix ClustersのほうがROIがはるかに高くなることが明らかです。その理由は、Nutanix AOSでは、キャッシュドライブとキャパシティドライブという、アーキテクチャー上の欠陥を持つ時代遅れの概念を適用していないためです。Nutanixノード内のすべてのフラッシュデバイスが書き込みと読み取りの

3 years ago

TetsuoMiyoshiNutanix Employee

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

パブリッククラウドの課題 – パート1：ネットワークパフォーマンス

本記事はJosh Odgers氏の記事の翻訳版です。原文はコチラ。本シリーズの索引はコチラです。 AWS EC2などのパブリッククラウド製品は「ベアメタル」サーバーをレンタルする機能を長年提供しており、顧客やパートナー企業はこの機能を利用することで、それぞれ選択したワークロードやソリューションをデプロイしています。追加のハードウェアはスタンバイ状態になっており、これまでと比べ短時間でのデプロイが可能なため、ハイパーコンバージド・インフラストラクチャー（HCI）ベンダーは、オンプレミス環境よりもさらに柔軟にオンデマンドで拡張できる形でベンダーのソリューションを提供できるようになりました。AWS EC2などのサービスは、ベアメタルインスタンス当たりの接続数や使用可能な帯域幅に関して、顧客がネットワークをほとんど制御できない点が課題となります。例えば、よく使用されているi3.metalインスタンスには、36個の物理CPUコア、512GBのメモリー、および25ギガビットネットワーク（公表値）が、8本の1.9TB NVMe SSDとともに含まれています。参照: https://aws.amazon.com/ec2/instance-types/i3/この構成は、Nutanixのような高度なHCIソリューションには最適ですが、ネットワークへの依存度が高いvSANのような製品にはそれほど適していません。「25ギガビットネットワーク（公表値）」とした理由実際に25Gbpsが使用可能なわけではないためです。使用できるのは、i3.metalインスタンスが同じ1台のラック内に配置されている場合は接続当たり最大10Gbps、複数のラックにまたがって配置されている場合は最大5Gbpsです。以下の例は、最新のアイドル状態のクラスターでテストした結果、AWS EC2で大きなばらつきが発生するということを示しています。次に、HCIソリューションをAWS EC2にデプロイした場合の、ネットワークの利用状況への影響について紹介します。ストレージトラフィックと仮想マシントラフィックストレージトラフィックがネットワークを独占的に使用する場合、仮想マシントラフィックが使用できる帯域幅はごくわずかであるため、ストレージ層のパフォーマンスが高くても、エンドユーザーアプリケーションやビジネスクリティカルなアプリケ

3 years ago

TetsuoMiyoshiNutanix Employee

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

パブリッククラウドの課題 – VMware VMConAWSとNutanix Clustersの比較 – 索引

本記事は2020年8月19日にJosh Odgers氏が投稿した記事の翻訳版です。原文はコチラ。パブリッククラウド内のベアメタルハードウェアにHCI（ハイパーコンバージドインフラストラクチャー：IT環境整備のための仮想化基盤インフラ）ソリューションをデプロイするメリットは、価値実現までの時間、スケーラビリティ、およびシンプルさという観点で大きな意味がありますが本ブログシリーズで紹介しているように、すべてのHCI製品が同じように開発されているわけではありません。もっともよく使用されている2つのHCIソリューションはVMware vSANとNutanix AOSであり、どちらのソリューションでも、ベアメタルインスタンスを使用したAWS EC2のサービスが用意されています。本ブログで連載するこのシリーズでは、パブリッククラウドベースのHCIソリューションを選択する際に考慮すべき主なトピックについて紹介します。尚、このブログシリーズは、新しいトピックを追加して改訂したり、テクノロジーの変化に応じて、必要に応じて改訂したりする場合があります。パート1 – ネットワークパフォーマンスパート2 – TCO/ROIとストレージ容量パート3 – 大規模環境でのTCO/ROIとストレージ容量パート4 – データ効率テクノロジーと回復力に関する考慮事項パート5 – ストレージデバイス障害と回復力への影響パート6 – ベアメタルインスタンスの障害パート7 – ストレージI/Oパスと回復力への影響パート8 – ストレージの拡張と運用への影響パート9 - キャパシティの改善と妥協なきパフォーマンス(更にその上でしなやかさは?) パート10 – 未定NutanixとVMware vSAN / VxRAILのプライベートクラウド/オンプレミスの比較については、以下を参照してください。NutanixとVMware vSAN / DellEMC VxRailを比較

3 years ago

Page 5 / 8

日本語フォーラム (Japanese)

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

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

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

198 Topics

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

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

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

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

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

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

【質問】日本語版サポートドキュメントの所在について

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

Nutanix と VMware vSAN/DellEMC VxRAILを比較

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

ノード復旧方法に関して

「ブログ書いたよ！」＆「こんな記事見つけたよ！」お知らせコーナー

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

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

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

パブリッククラウドの課題 – パート7 – ストレージI/Oパスと回復力への影響

お客様とパートナー様への公開書簡

パブリッククラウドの課題 – パート6：ベアメタルインスタンスの障害

NutanixがForresterのハイブリッドクラウド管理Waveでストロングパフォーマーとしてデビュー

パブリッククラウドの課題 – パート5：ストレージデバイス障害と回復力への影響

パブリッククラウドの課題 – パート4：データ効率テクノロジーと回復力に関する考慮事項

パブリッククラウドの課題 – パート3：大規模環境でのTCO/ROIとストレージ容量

パブリッククラウドの課題 – パート2：TCO/ROIとストレージ容量

パブリッククラウドの課題 – パート1：ネットワークパフォーマンス

パブリッククラウドの課題 – VMware VMConAWSとNutanix Clustersの比較 – 索引

Badges

日本語フォーラム (Japanese)

Badges

Sign up

Login to the community

Scanning file for viruses.

This file cannot be downloaded