Global Forums

Discussions from around the globe

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で変更されたメンテナンスモード時にデータの整合性を維持することが理論的には可能となり、再起動や障害の後にもデータの整合性を維持できる状態に一歩近づいたはずです。その後、「カスタム」テスト

3270

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のフェーズではどうでしょうか。再起動や

2560

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

2260

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 ご教示のほど、よろしくお願い致します。

15696

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

3950

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

5860

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

6920

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

2090

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

7920

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

9730

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用とした場合も問題はありませんでした。

8435

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

6300

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

10680

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

29480

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

12980

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

13780

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

12010

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

19180

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

39390

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 ✅

24040

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処理を回避する

36740

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も同じ場所なので、このシリーズが他にもあるのではないかと思いました。もしあるなら、全部見てみたいです。内容的に、おそらく日本のサポート担当にて作成されたのだと思うのですが、このドキュメントの一覧のようなものはあるのでしょうか？情報ありましたら、お知らせいただけると幸いです。

2782

3 years ago

Page 5 / 9

Global Forums

Badges

Sign up

Login to the community

Scanning file for viruses.

This file cannot be downloaded