Global Forums | Nutanix Community
Skip to main content
224 Topics

本記事は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: vSAN vSANの最適な読み取り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 ノードクラスタを例にとります。 ここでは、 CPU とメモリを大量に消

本記事は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 に馴染みのない方のために補足しておくと、 Nutan

本記事は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-operations-adding-removing-drives-deduplication-compression-enabled/ 新しいドラ

本記事は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 ✅ ✅ ✅ ❌ 以前に学んだように、vSAN はハイブリッド構成(Flash + HDD)での重複排除や圧縮をサポートしておりません。イレイジャーコーディングも同様で、ハイブリッド構成はサポートされていません。 これにより、ハイブリッドプラットフ

本記事は 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の提供する、付加価値となる機能、容量の効率性

本記事は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の独立した認識デバイスを作り上げます。そしてそれらはそれぞ

本記事は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では今年のはじめに開始したセキュアブートについての一連の動きの

本記事は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デバイスをユーザースペースから直接アク

本記事は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 クラスターに追加しても、新しいノードのストレージ

本記事は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 を実行し、このホストがクラスター内の他

本記事は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の進化、ソフトウェアサブスクリプションモデルへの転換へ新たなるステージをもたらす年になり、我々のハイパーコンバージドインフラストラクチャに置けるリーダーシ

本記事は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 では使用可能な容量が少なくなるだけでなく、回復力とパフォーマンスの観点でハードウェアが効率よく使用されない

本記事は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ソリューションから最大の付加価値を迅速に、そして自身のニーズにあった幅広い購買モデルの選択肢とと

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

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

本記事は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 ノードクラスターでは

本記事は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 では、キャッシュドライブとキャパシティドライブという、アーキ

本記事は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 にデプロイした場合の、ネットワークの利用状況への影響について紹介します。 ストレージトラフィックと仮想マシントラフィック ストレージトラフィックがネットワークを独占的に使用する場合、仮想マシントラフィックが使用できる帯域幅はごくわずかである

Most awesome this week!

Badges

Show all badges