日本語フォーラム (Japanese)

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

221 Topics
311 Replies

HCI プラットフォームの可用性、回復力、整合性 X-Ray のシナリオがGAしました！

本記事は2021年3月5日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの牽引はこちら。私はしばらくの間、社内のエンジニアリング/QAだけでなく、お客様がNutanixのより詳細な機能を迅速/容易にかつ反復してテストできるように、新しいX-Rayシナリオの構築に取り組んできました。 HCIプラットフォームの可用性、回復力、そして整合性シリーズでは、Nutanix AOSとVMware vSANの両方でテストがどのように機能するかを詳細に説明しており、AOSがvSANに対して大きな優位性を持ち、最小3ノードの構成で障害が発生しても常にデータの整合性（可用性と回復力の両方）を維持できることを強調しています。一方、vSANは、より高いI/Oタイムアウト、より大きなクラスター、3つのデータコピー（FTT2）でもI/Oエラーが発生します。しかし、私の言葉を鵜呑みにせず、ご自身でもテストを行ってみてください。 Nutanix ポータルから X-Rayバージョン3.10.2の、vSphere用のOVAまたはAHV用のQCOWイメージをダウンロードし、テストを行う予定のクラスターとは別のクラスターにデプロイするだけです。その後、WebブラウザでX-Ray VMのIPアドレスに移動し、「ターゲット」クラスターを設定し、検証を実行して、すべての帯域外管理と認証情報が機能していることを確認すれば、準備完了です。デフォルトのオプションでは、メンテナンスモード、再起動、および10%の稼働率でのノード障害のシミュレーションを含む、プラットフォーム全体の回復力テストを実行します。このテストでは、クラスター内の1つのノードを除くすべてのノードに1つの仮想マシンをデプロイすることで、クラスター内のノード数に応じて自動的にスケールします。これにより、適切なサイズの実環境であるN+1をシミュレートするとともに、各ノードのフラッシュドライブ数に基づいて目標I/Oレベルを調整します。フラッシュデバイスの数に基づいてI/Oレベルを調整することで、現実的ではない、あるいは人為的に高いエラー数につながる、小規模ノードやクラスターへの単純な過負荷を避けることができます。このテストの目的は何でしょうか？簡単に言えば、もしもHCIプラットフォームが、VMの可用性に

1680

3 years ago

ksaitoWayfarer

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

Veeam Software at Nutanix Vol.1 Veeam Software会社紹介とラインナップ+ライセンス

皆様こんにちは。ヴィームソフトウェアの斉藤と申します。この度こちらの日本語フォーラムに寄稿させていただくことになりました。これから以下4回に分けてトピックをお伝えしようと思います。Vol.1 Veeam Software会社紹介とラインナップ+ライセンス（今回のトピック） Vol.2 Veeamのバックアップについて Vol.3 Nutanix Mine "with Veeam"について Vol.4 クラウドやKubernetes環境のバックアップについて Veeam SoftwareについてVeeam Softwareは2006年、スイス・バールにて創業した主にバックアップを生業とするデータマネジメントに関する企業になります。2020年に米国の投資会社「Insight Partner」による買収を経て現在はアメリカのオハイオ州に本社機構を移転しております。 2020年の売上高は10億ドルを超え、1,000億円の規模に到達しました。バックアップ業界におけるシェアはヨーロッパではNo.1、そしてグローバルでもこの度2020年後半にVeritas社を抜き、遂にNo.2 に浮上致しました。　お客様満足度も非常に高いのがポイントになりますが、中でもNPS (Net Promoter Score)の高さをベンチマークに挙げさせていただいており、使いやすさの方向性はNutanixに非常に近しいものだと考えております。　第三者機関の評価も非常に良好で、Gartner社のMagic Quadrantでは4年連続「Leaders」ポジションに選出されております。 2020年は縦軸の「実行力（Ability to Execute）」にてNo.1 のご評価をいただき、まさに有言実行でビジネスを行っている事が評価されていると考えております。近年のビジョンとなるメッセージは「クラウド・データ・マネジメント」を掲げており、データ視点におけるマルチクラウド環境のDXをめざしております。ビジョンにおける方向性もまた、Nutanix 社に近いものだと考えております。 Veeam SoftwareのポートフォリオそれではVeeam Softwareが提供しているポートフォリオをご紹介させていただきます。　Veeamのコア製品ともいえるソリューションが、「Veeam Availability S

2700

3 years ago

TetsuoMiyoshiNutanix Employee

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

vSAN/VxRAILのストレッチクラスタはデータ整合性を維持できるか？

本記事は2021年2月11日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。このシリーズでは、ではNutanix AOSが回復力ファクタ(RFつまり2つのデータコピー)を利用した場合に3ノードクラスタの場合も含め、メンテナンスモード、再起動、および障害シナリオにおいて完全な仮想マシンの可用性とデータの整合性を維持できるということを見てきました。そして、パート2では、Nutanix AOSとvSAN 7 Update 1とを比較し、vSANが再起動と電源サイクル(障害)シナリオの両方で、以下のようなあらゆるvSANにとって有利に働く状況を作ったとしてもI/O整合性のエラーに苦しんでいるという事実を確認しました: vSANが長い(SCSI)I/Oタイムアウト設定を利用している (180 秒 vs Nutanix 30 秒) vSANがデータの完全退避モードを利用している vSANのオブジェクトリビルドタイマーを60分の遅延から遅延なしに変更 (すなわち、これによってリビルドは即時開始される) より大きなクラスタ(8ノード)を利用し、その上で、テストはそのクラスタ内の最初の4ノードのみで実施するパート7では、7ノードのクラスターでvSANの耐障害性(FTT)を2に設定した場合の動作について見ていきましたが、驚くことに、デュアルパリティのvSANを使用してもデータ整合性の問題に対処できないことがわかりました。それでは、vSANをストレッチクラスター構成で使用する場合、仮想マシンの可用性とデータの整合性がどのように扱われるのかを確認していきます。このテストは、8台のDell PowerEdge R740xd-24を使用し、VMware ESXi, 7.0.1, Build 17551050を用いて実施しました。最初のテストでは、「4+4台構成のストレッチクラスタ｜FTT1｜I/Oタイムアウト180秒」を使用し、Active/Passiveスタイルのストレッチクラスタをシミュレートしました。ここでは、フォールトドメイン1では3つのVMを実行し、フォールトドメイン2ではVMを実行しませんでした。簡単に言えば、このテストにおけるフォールト・ドメインとは、サイトやデータセンターを意味しますが、ノードはすべて同じ25Gbのネ

3870

3 years ago

TetsuoMiyoshiNutanix Employee

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

HCIプラットフォームの可用性、回復力、整合性 – パート7 – vSAN 7U1 および対障害性2 (FTT2)

本記事は2021年2月8日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。このシリーズではNutanix AOSが回復力ファクタ(RFつまり2つのデータコピー)を利用した場合に3ノードクラスタの場合も含め、メンテナンスモード、再起動、および障害シナリオにおいて完全な仮想マシンの可用性とデータの整合性を維持できるということを見てきました。そして、パート2ではNutanix AOSとvSAN 7 Update 1とを比較し、vSANが再起動と電源サイクル(障害)シナリオの両方で、以下のようなあらゆるvSANにとって有利に働く状況を作ったとしてもI/O整合性のエラーに苦しんでいるという事実を確認しました:vSANが長い(SCSI)I/Oタイムアウト設定を利用している (180 秒 vs Nutanix 30 秒) vSANがデータの完全退避モードを利用している vSANのオブジェクトリビルドタイマーを60分の遅延から遅延なしに変更 (すなわち、これによってリビルドは即時開始される) より大きなクラスタ(8ノード)を利用し、その上で、テストはそのクラスタ内の最初の4ノードのみで実施するそれではvSAN 7 Update 1が対障害性(FTT)を2に設定した場合の動作について見ていきます、つまりvSANはデータのコピーを3つ書き込んでいくことになり、理論的には回復力を向上して、2つの同時ドライブもしくはノード障害に対応ができることになります。この一連のテストは回復力にフォーカスを当てており、FTT2(もしくはNutanix AOSではRF3)を利用するということは同時に実効で利用可能なキャパシティを50%からファイルシステム、キャッシュドライブ、そして回復用のキャパシティ(N-1/N-2)をマイナスしたものから33%から同じオーバーヘッドをマイナスしたものへと減少させるというコストを伴うということを理解しておくことが重要です。 FTT2(NutanixではRF3)を利用する場合には、同じ仮想マシンのフロントエンドのパフォーマンスに対してもより多くのシステムリソース(例:CPU/ストレージIO)を消費します。例えば、デュアルパリティへの移行によってサイジングには劇的な影響があり、大抵の場合33%以上になりますし、もちろんプラ

2900

3 years ago

TetsuoMiyoshiNutanix Employee

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

Nutanix AOS vs vSAN/VxRAIL 大規模クラスタ & vSAN 7U1のデータ整合性

本記事は2021年2月5日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。このシリーズでは、Nutanix AOSが、3ノードクラスタを含むResiliency Factor 2（RF2：データのコピーを2つ保持する設定）を使用している場合に、メンテナンスモード、リブート、障害シナリオにおいて、仮想マシンの完全な可用性とデータの整合性を維持することを学びました。また、Nutanix AOSとvSAN 7 Update 1を比較し、（vSANが）より高い（SCSI）I/Oタイムアウトの設定、データの完全退避モードを使用し、オブジェクト再構築タイマーを60分遅延からゼロ遅延（つまり、再構築を即時開始する設定）にしたにもかかわらず、vSANは再起動と電源オンオフ（障害）シナリオの両方でI/Oの整合性エラーが発生するという事実を見てきました。このパートでは、引き続きX-Ray のPlatform Availability, Resiliency and Integrity（プラットフォームの可用性、回復性、整合性）テストを実施しますが、今回はDell PowerEdge r740xd-24ノード（NVMe+SSD）を使用した8ノードのvSAN 7 Update 1クラスタで行います。このテストの目的は、大規模なクラスタが結果にどのような影響を与えるか、また、vSANが大規模な環境でI/Oの整合性を維持できるかどうかを確認することです。それでは早速、結果を見ていきましょう。メンテナンスモード: （このテストフェーズでは）I / Oエラーはレポートされません。再起動時: （このテストフェーズでは）206のI/Oエラーが確認できます。電源オフ時: （このテストフェーズでは）56 のI/Oエラーが確認できます。（テスト結果の）考察:4ノードのvSANクラスタでの以前の結果と比較すると、小さいクラスタよりも大きいクラスタの方がI/Oエラー数を減らすことができるようです。これは、仮想マシンオブジェクトがより多くのノードに配置された状況下で、テスト内容が（8ノード構成の）クラスタ内の最初の4つのノードでのみ操作（メンテナンスモード、再起動、電源オフ）を実行するため、理にかなっています。もし、このテストが（最初の4

2010

3 years ago

TetsuoMiyoshiNutanix Employee

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

HCIプラットフォームの可用性、耐障害性、整合性 – パート 5 – Nutanix AOS vs VMware vSAN/Dell VxRAIL - オブジェクト修復タイマーの値を0に減らした場合

本記事は2021年2月4日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの牽引はこちら。このシリーズでは、Nutanix AOSがメンテナンスモード、再起動、障害シナリオにおいて、仮想マシンの完全な可用性とデータの整合性を維持することを学びました。また、Nutanix AOSとvSAN 7 Update 1を比較したところ、vSANは、より高い(SCSI)I/Oタイムアウト設定と完全データ退避モードを使用しているにもかかわらず、再起動とパワーサイクルの両方の(障害)シナリオでI/O整合性エラーが発生するという事実に着目しました。この、第5回では"vSANオブジェクト修復タイマーを60分から0分に減らすと、I/O整合性の課題に対して何か良い影響がありますか？"という質問にお答えします。オブジェクト修復タイマーに馴染みのない方のために説明します。vSANオブジェクトは一部の障害シナリオに対して、(オブジェクト修復タイマーの)デフォルト設定である60分の間、修復が開始されません。その間、一部のデータは保護されず、設定されたポリシー（例：FTT1またはFTT2）に準拠した書き込みI/Oなどの機能を実行する能力を欠いた状態となります。これこそが、X-Ray のPlatform Availability, Resiliency and Integrity(プラットフォームの可用性、回復性、整合性)テストにおいて、vSANがI/O整合性の問題に見舞われた原因であると考えられます。では、この(オブジェクト修復タイマーの)値をより生産性の高い0分(の遅延)に変更する方法を見てみましょう。 vSAN 7 Update 1：オブジェクトの再同期(Resyncing Objects)のデフォルト表示 vSAN 7 Update 1：オブジェクト修復タイマーの値を0に変更するこの変更により、ノードがオフラインになった場合、vSANは回復力を維持するために必要なオブジェクトの復元プロセスを直ちに開始します。これによりvSANは、vSAN 7 Update 1で変更されたメンテナンスモード時にデータの整合性を維持することが理論的には可能となり、再起動や障害の後にもデータの整合性を維持できる状態に一歩近づいたはずです。その後、「カスタム」テスト

3300

3 years ago

TetsuoMiyoshiNutanix Employee

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

Nutanix AOS vs vSAN/VxRAIL 完全なデータ退避モードの場合

本記事は2021年2月2日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの牽引はこちら。本シリーズのパート1では、HCIプラットフォームをテストするためにX-Rayを使って実行できる、新しい「HCI Platform Availability, Resiliency & Integrity (プラットフォームの可用性、回復力、そして整合性)」」のシナリオについて学びました。パート2では、Nutanix AOSがメンテナンスモード、再起動、障害シナリオにおいて、仮想マシンの完全な可用性とデータの整合性を維持すること、そしてvSAN 7.0 Update 1が再起動と障害シナリオの両方でI/Oの整合性エラーが発生することを紹介しました。パート3では、PVSCSIドライバのI/Oタイムアウトを30秒から180秒まで増やすことで問題が解決するかどうかを調べました。その結果、I/Oタイムアウトを増加させることでエラー数は減少しましたが、最終的にはvSAN 7 Update 1で発生するI/Oエラーを防ぐことはできませんでした。今回のパート４での疑問は、「vSANの完全なデータ退避モードを使うことで、データの整合性の問題を回避できるか？」です。完全なデータ退避モードについては、以下のVMware社のドキュメントで説明されています。簡単に言うと、ホストがメンテナンスモードになると、すべてのデータ（vSANオブジェクト）がクラスタ内の他のホストに再作成されます。ですので、理論上はホストがオフラインの間もデータの整合性が損なわれることはありません。 https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vsan.doc/GUID-521EA4BC-E411-47D4-899A-5E0264469866.html パート2と3で、vSANでもメンテナンスモードのフェーズでは、可用性の欠如やI/Oエラーが発生しないことを確認しました。これは、これらのテストでも完全なデータ退避モードが使用されており、vSAN7U1とすべてのオブジェクトが、ホストがオフラインであっても常に利用可能であったためです。しかし、再起動や電源OFFのフェーズではどうでしょうか。再起動や

2570

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

3060

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

2290

3 years ago

tokumeiAdventurer

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

【質問】スナップショットについて

ハイパーバイザーに ESXi を使用した環境でバックアップ（スナップショット取得）を考えています。対象の仮想マシンはシステム領域とそれ以外の領域を複数の vmdk ファイルに分割し、マウントして一つの仮想マシンを構成しています。このような構成の仮想マシンで、各vmdkファイルを指定してスナップショットを取得することはできるのでしょうか？ VM単位のスナップショットを取得できることはわかっているのですが、vmdk単位のスナップショットを取得できるのかがよくわかりません。下記のような ncli コマンドを見ると、vmdk ファイルを指定してスナップショットを取得できるような気もするのですが… https://portal.nutanix.com/page/documents/details?targetId=Command-Ref-AOS-v5_19:acl-ncli-snapshot-auto-r.html ご教示のほど、よろしくお願い致します。

15816

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

3800

3 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しました!

3960

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

5910

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の統合されたアップデートについて、つまりインカー

6950

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

2110

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

7980

3 years ago

yhchoExplorer

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

Contact bare metal image (AOS) for new node extension

기존 클러스터에 새 노드를 추가할 계획입니다.확장 전에 새 노드 AOS(베어 메탈 설치)가 시작됩니다.기존 버전과 새 AOS 버전이 다른 경우 문제가 있을 수 있습니까?(AOS 나는 당신이 같은 일을하고 싶습니다,하지만 불가능한 경우)전) 기존 클러스터 AOS 5.10.9 / 새로운 노드AOS 5.15.x 감사합니다.

1091

3 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

9870

3 years ago

D.B.Voyager

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

SAS Diskを含む構成

こんにちは。 CEの2020 09版について相談させていただきたく。インストールは完了するのですが、CVMが起動しません。起動後virshで確認するとしばらくpausedの状態になり、shut offになります。構成はSATA DOM → hyper visor用NVMe M2 SSD → CVM用SAS ｘ4(RAID Card(EP400i)でRAID0 x4を構成) → Data用としてインストールしています。ドライブの種類があまり多いのは推奨されない、とどこかで見た覚えがあるのでそういうものかと、思ったりもするのですがSASが大分余っているので有効活用したくもあり、解決方法があれば教えて頂きたく。なお、前のバージョンではSATA DOM → ddでimgを書き込んで起動、インストール実行SATA SSDSAS ｘ4(RAID Card(EP400i)でRAID0 x4を構成)の構成で動作していました。また、2020 09でもSATA DOM → hyper visor用NVMe M2 SSD → CVM用SATA Disk (or SATA SSD) → Data用とした場合も問題はありませんでした。

8515

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

6350

3 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 のクラウド時代のハイ

10810

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

29580

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の最適な読

13060

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台の別のノードに以下に示すとおり配置されることにな

13990

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ノー

12080

3 years ago

Page 5 / 9

日本語フォーラム (Japanese)

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

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

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

Badges

日本語フォーラム (Japanese)

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

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

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

Badges

Sign up

Login to the community

Scanning file for viruses.

This file cannot be downloaded