日本語フォーラム (Japanese)

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

228 Topics
344 Replies

Veeam Software at Nutanix Vol.4 クラウドやKubernetes環境のバックアップについて

3580

3 years ago

TetsuoMiyoshiNutanix Employee

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

Nutanixの回復力 – パート2 - RF2からRF3への変換

本記事は 2018 年 5 月 31 日に Josh Odgers 氏が投稿した記事の日本語版です。原文はこちら。本シリーズの索引はこちら。パート 1 では、 Nutanix AOS が Acropolis 分散ストレージファブリック (ADSF) のおかげで、ノード障害からのリビルドを高速かつ効率的に行う能力について説明しました。パート 2 では、ストレージコンテナがどのようにして RF2 から RF3 に変換されるのか、また、その操作が完了するまでのスピードについて、紹介したいと思います。今回のテストでは、クラスター内に 12 台のノードしか存在しません。まず、ストレージプール容量の使用状況から見てみましょう。現在、クラスター全体で50TB超のストレージ使用量であることが確認できます。 RF3 への変換、つまり簡単に言えば全データの 3 つ目のレプリカを追加する際には、十分な空き容量を確保する必要があり、さもないと RF3 のコンプライアンス上、問題があります。次に、クラスタ（およびメタデータ）の Redundancy Factor （冗長化係数）を RF3 に増やします。これにより、クラスタは RF3 コンテナをサポートし、メタデータの観点からは少なくとも 2 つのノード障害に耐えることができます。次に、対象のストレージコンテナを RF3 に増やします。コンテナが RF3 に設定されると、 Curator はクラスターが設定された Redundancy Factor に準拠していないことを検出し、追加のレプリカを作成するためのバックグラウンドタスクを開始します。今回のケースでは、ストレージプールに約 50TB のデータがある状態でスタートしたので、このタスクでは 50 ％のレプリカを作成する必要があり、最終的には約 75TB のデータを格納することになります。新しい Redundancy Factor に準拠するために、クラスターが 25TB のデータを作成するのにかかった時間を見てみましょう。今回は、 7GBps 以上のスループットで 3 時間未満の処理時間を示しており、 1 時間あたり約 8.3TB となりました。このプロセス全体を通して、クラスターは RF2 レベルの完全な回復力を維持しつつ、このフェーズで新しい書き込みが

16540

3 years ago

TetsuoMiyoshiNutanix Employee

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

Nutanixの回復力パート1 ノード障害時のリビルドのパフォーマンス

本記事は2018年5月30日にJosh Odgers氏が投稿した記事の日本語版です。原文はこちら。本シリーズの索引はこちら。 2013年半ばからNutanixに勤務し、ビジネスクリティカルなアプリケーション、スケーラビリティ、回復力、パフォーマンスに注力してきました。私はお客様やパートナーと、回復力について、また、Nutanixプラットフォームをどのように構成するのがベストなのかについて、たくさんの議論をしています。 Nutanixプラットフォームの多くの強みの1つであり、私が多くの時間とエネルギーを費やしている分野は、回復力とデータの整合性です。それには障害のシナリオとプラットフォームがどのように対処するかを理解することが重要です。 Nutanixは、独自の分散ストレージファブリック（ADSF）を使用して、仮想マシン、コンテナ、さらには物理サーバーにストレージを提供しています。このストレージは、レジリエンシーファクター（RF）2または3で構成することができます。つまり、回復力とパフォーマンスのために、データは2つもしくは3つのコピーが保存されます。単純化して考えれば、RF2とN+1（例：RAID5）、RF3とN+2（例：RAID3）を比較するのは簡単です。しかし、実際には、 RF2と3は分散ストレージファブリックのおかげで、従来のRAIDよりもはるかに高い耐障害性を持っています。これは、障害からのリビルドを極めて迅速に行うことができることと、障害が発生する前に問題を検出して解決するプロアクティブなディスクスクラビング機能を備えているためです。 Nutanixは、読み取りと書き込みのたびにチェックサムを実行し、データの整合性を最大限に確保するための継続的なバックグラウンドスクラビングを行います。これにより、LSE(Latent Sector Errors)やビットロット(Bit Rot)、通常のドライブの消耗などが事前に検出され、対処されるようになります。 ADSFの回復力を議論する際に重要なのは、ドライブやノードに障害が発生した場合に、RF2またはRF3に準拠した状態まで回復する速度です。リビルドは、すべてのノードとドライブにまたがる完全な分散処理（多対多の処理）です。ですから、非常に高速ですし、ボトルネックを回避するため、そして稼働中のワークロードへの影響

18700

3 years ago

TetsuoMiyoshiNutanix Employee

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

Nutanixの回復力シリーズ - 索引

Nutanixの回復力シリーズの索引です。パート1 ノード障害時のリビルドのパフォーマンスパート2 RF2からRF3への変換パート3 RF3でのノード障害時のリビルドのパフォーマンスパート4 RF3からイレイジャーコーディング(EC-X)への変換パート5 CVMのメンテナンスまたは障害時のRead I/O パート6 CVMのメンテナンスまたは障害時のWrite I/O パート7 ハイパーバイザーアップグレード中のReadおよびWrite I/O パート8 RF3およびイレイジャーコーディング(EC-X)でのノード障害時のリビルドのパフォーマンスパート9 自己治癒パート10 ディスクスクラビング / チェックサム

4950

3 years ago

ksaitoWayfarer

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

Veeam Software at Nutanix Vol.3 Nutanix Mine with Veeamについて

皆様こんにちは。ヴィームソフトウェアの斉藤と申します。 Veeamに関するフォーラム寄稿の第3弾となります。前回にも記載しましたが、まずは以下4回に分けてトピックをお伝え致します。・Vol.1 Veeam Software会社紹介とラインナップ+ライセンス・Vol.2 Veeamのバックアップについて・Vol.3 Nutanix Mine "with Veeam"について（今回のトピック）・Vol.4 クラウドやKubernetes環境のバックアップについて Nutanix Mine with Veeam のはじまり Nutanix Mineはご存知のとおりNutanixポートフォリオの一環として発表されたソリューションになります。“Mine”と言う英単語を聞くと私はまず「マインスイーパー」を思い出しますが、そのMineとは全く異なります。Mineにつけられたアイコンをご覧ください。ダイヤモンドが記載されています。つまり「鉱山」という定義が正しく、その心としてバックアップデータの中にあるダイヤモンドを掘り起こそう！というニュアンスが込められています。ゲームで言うと、「マインクラフト」が正解という事になります。ひょっとしたら「私のもの (mine)」といった副次的意味合いも含まれているかもしれません。参照先: https://www.nutanix.com/jp/products/mine そんな期待を込めてリリースされたNutanix Mineは、Nutanix プラットフォームの上でバックアップソフトウェアが稼働する統合型ソリューションとなります。稼働するバックアップソフトはNutanix プラットフォーム理念を継承し、マルチベンダ仕様となっており現在はHYCUとVeeam Softwareが選択可能となります。弊社がその一つとして選ばれたのが2年前の2019年5月になります。参照先: https://www.veeam.com/jp/news/nutanix-mine-with-veeam-simplifies-secondary-storage.html Nutanix Mine with Veeam の提供価値「NutanixのバックアップだったらやっぱりHYCUじゃないの？」と思う方もいらっしゃるかもしれません。確かにHYCUはNutani

1590

3 years ago

TetsuoMiyoshiNutanix Employee

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

データローカリティはストレージのパフォーマンスにのみ関係すると思いますか?もう一度考えてみてください!

本記事は2020年6月11日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちらです。 Nutanix の競合他社が、データローカリティは重要ではないと自分自身やお客様を納得させようと必死に努力しようとも、ネットワーキングを含むリソースを不必要に使うことは、非効率であり、ボトルネックとなって機能面やパフォーマンスに影響を与える可能性があるという事実は変わりません。 Nutanix は、当初よりこのような課題に対処するために AOS を設計し、データローカリティが特にプラットフォームの成功の鍵となり、私どものお客様環境を拡大し、長年にわたり最もミッションクリティカルなエンタープライズワークロードをサポートしてきました。ここでは、データローカリティのそれほど目立たないながらも重要な利点をいくつか紹介します。 1. より高速な vMotion/ ノードフェイルオーバー使用可能なネットワーク帯域幅が増えるほど vMotion の処理は早く完了し、 VM とアプリケーションへの影響が少なくなるため、明らかな効果が得られます。 VM のパフォーマンスが向上するだけでなく、ストレージ、ハイパーバイザ、ハードウェアのメンテナンス / アップグレードのためにメンテナンスモードに入るホストなどの運用保守業務を迅速に完了できます。ビジネスクリティカルアプリケーションが、 vMotion の影響を長時間受けたことはありませんか ? vMotion に十分な帯域幅を確保することは、 vBCA( ビジネスクリティカルアプリケーション ) を仮想環境で利用する上で重要です。 2. 同期 / 非同期レプリケーションの帯域幅の更なる確保実際の状況では、フロントエンド VM の IOPS/ スループットだけではなく、目標復旧時点 (RPO) と目標復旧時間 (RTO) に関する実際に必要な SLA を満たすことも必要です。レプリケーションをスケジュール通りに実行するために使用できる帯域幅が不足している場合、 SLA の達成に影響を与える可能性があります。 3. クラスターの再構築 / 再同期のパフォーマンスドライブ、ノード、ブロック、またはラックの障害が発生すると、 HCI 製品は再構築 / 再同期を実行して、設定されたレベルの回復力に復旧します。 ( 通常、 2 つか

8520

3 years ago

ksaitoWayfarer

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

Veeam Software at Nutanix Vol.2 Veeamのバックアップについて

皆様こんにちは。ヴィームソフトウェアの斉藤と申します。 Veeamに関するフォーラム寄稿の第2弾となります。前回にも記載しましたが、まずは以下4回に分けてトピックをお伝え致します。・Vol.1 Veeam Software会社紹介とラインナップ+ライセンス・Vol.2 Veeamのバックアップについて（今回のトピック）・Vol.3 Nutanix Mine "with Veeam"について・Vol.4 クラウドやKubernetes環境のバックアップについて Veeam Backup & Replication について Vol1.でもご紹介しましたが弊社のメインプロダクトになるのがVeeam Backup & Replication（通称 VBR）になります。ちなみに VBR の「R」は「レプリケーション」になりますのでお間違えの無きようお願い致します。 ※Commvault社が製品名称を「Simpana」から「Backup & Recovery」に改称したこともあり VBRは元々仮想化向け製品でしたが、現在は幅広いプラットフォームに対応しております。・仮想化基盤（ESXi/Hyper-V/AHV/RHV※1）のエージェントレスバックアップ・VMware ESXi/Microsoft Hyper-V 環境のレプリケーション・VMware ESXi/Nutanix AHVのストレージスナップショット作成・Windows/Linux/Oracle Solaris/IBM AIX/Mac環境のエージェントバックアップ・AWS/Microsoft Azure/Google Cloud上のエージェントレスバックアップ連携※2 ・Oracle RMAN/SAP HANAのPlug-inサポート ※1: 近日GA予定 ※2: Veeam Backup for AWS/Microsoft Azure/Google Cloud Platformを利用 Veeam の提唱する「3-2-1」ルールもはやバックアップ出来ないものは無い、といったくらい多種多様なデータ保護に対応しておりますが、Veeam Softwareではデータ保護に関しての基本コンセプトとして「3-2-1ルール」を提唱しております。聞いたことがないコンセプトだと思いますが、皆さんが思っている

3470

3 years ago

TetsuoMiyoshiNutanix Employee

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

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の可用性に影

1780

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 Availabili

2810

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のネ

3940

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%以上になりますし、もちろん

3050

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

2020

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 で変更されたメ

3420

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のフェーズではどうでしょ

2580

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-i

3100

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とvSAN7U1

2310

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

16126

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

3940

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

4000

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

6160

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 は、より多くの書き込み命令を行うため、高価なフラッシュドライブをより多く必要とします」とのことです。

7070

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％増

2310

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

8460

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_FOOTPRIN

10340

3 years ago

Page 5 / 10

日本語フォーラム (Japanese)

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

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

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

Most awesome this week!

Badges

日本語フォーラム (Japanese)

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

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

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

Most awesome this week!

Badges

Popular Subjects

Sign up

Login to the community

Scanning file for viruses.

This file cannot be downloaded