Global Forums

Discussions from around the globe

213 Topics

NutanixとMicrosoft Azureによるハイブリッドクラウドインフラストラクチャ

本記事は2021年9月21日にSahil M Bansal氏とVidhi Taneja氏が投稿した記事の翻訳版です。原文はこちら。.NEXT 2021に関する記事の索引はこちら。 NutanixはMicrosoftとコラボレーションし、より素早く、シンプルで、コスト効率性の高いクラウドへの道筋をご提供します。近年、そしてこの18ヶ月は特に顕著になってきましたが、ITチームは常に進化し続けるビジネスニーズの真ん中で、増加し続けるハイブリッドなワークプレースをサポートするために、より俊敏にならなければならないというプレッシャーに晒されてきました。多くのビジネス部門では数年分にも値するデジタルトランスフォーメーションの活動を削減された予算の中で運用を行い、短時間に詰め込んできました。プライベートとパブリッククラウドベンダーの両方がそれぞれのお客さまのニーズ、それは多くの場合でオンプレミスとクラウドをミックスさせたインフラストラクチャ上で、ワークロードを稼働させる、つまりはワークロードとビジネスのニーズにより良く答えるための取り組みを行っています。ハイブリッドクラウドアーキテクチャのアイディアは少し前から存在していましたが、そこにはいくつかのハイブリッドクラウドプラットフォームの急激な採用を阻む課題がありました。オンプレミスのデータセンターとパブリッククラウドの間の複雑なネットワークの管理は長きにわたる障害で有り続け、また、レガシーなアプリケーションをクラウド向けにリアーキテクトすることは時間のかかる作業でコストも高く付きます。もう一つの課題はそれぞれのクラウドのための複数の異なる管理ツールを使うことによって生じるサイロによる非効率性です。これらの課題を解決し、お客様のITニーズを次なるレベルへとパワーアップさせるため、Nutanixはマイクロソフトとハイブリッドクラウドソリューションにおいて協業し、クラウドとオンプレミスの間の境界を融合させ、完全なハイブリッドクラウドエクスペリエンスをご提供します。プレビュー開始: Nutanix Clusters on Microsoft Azure Nutanix Clusterson Microsoft Azure を限定的なプレビューとしてアナウンスできることを大変喜ばしく思います! NutanixはMicrosoftと従

2490

3 years ago

TetsuoMiyoshiNutanix Employee

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

.NEXT Digital Experience 2021 アナウンスメントについてのブログー索引ー

本記事は.NEXT Digital Experience 2021でのアナウンスメントについての記事の索引です。2021年内は.NEXT Digital Experience 2021 (グローバルイベント)のレコーディングにアクセスが可能ですので、ぜひ詳細が気になる方はイベントへの登録をお願いいたします。また、2021年10月7日には.NEXT Conference Japan 2021が実施されます。字幕入りのキーノートはもちろんですが、完全日本オリジナルコンテンツの22に及ぶブレイクアウトセッションは必見です。こちらも10月末まで視聴が可能ですので、ぜひイベントへの登録をお願いいたします。(グローバルイベントとは登録が独立していますのでご注意ください。) 本索引では、Nutanix社員はもちろん、コミュニティでの情報も集めて行きます。.NEXTに際して、こんな記事を書きましたというコミュニティの皆様、ぜひコメントにてお知らせください。記事タイトル概要原文リンク Nutanix AOS 6のご紹介 HCIソフトウェアのパイオニアであるNutanix AOSの大規模なマイルストーンであるNutanix AOS 6ソフトウェアをご紹介します。 Announcing Nutanix AOS 6 NutanixとMicrosoft Azureによるハイブリッドクラウドインフラストラクチャ NutanixはMicrosoftとコラボレーションし、より素早く、シンプルで、コスト効率性の高いクラウドへの道筋をご提供します。 Hybrid Cloud Infrastructure with Nutanix and Microsoft Azure Nutanix Eraによる思い通りのデータベース・アズ・ア・サービス Nutanix Eraの最新の機能をご紹介します。 Database-as-a-Service on your terms with Nutanix Era データ中心の世界のためのストレージを再考する Nutanixの統合ストレージー非構造化データ管理の新たなマイルストーン Rethinking Storage For A Data Centric World コミュニティの皆様のブログブログタイト

3490

3 years ago

TetsuoMiyoshiNutanix Employee

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

Nutanixの回復力 - パート 6 - CVMのメンテナンスや障害時のWrite I/Oについて

本記事は2018年6月8日に Josh Odgers 氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの牽引はこちら。パート5では、CVMのメンテナンスや障害時のI/Oの処理方法について説明しましたが、今度は同じメンテナンスや障害シナリオでWrite I/Oを処理するという、間違いなくより困難で重要なタスクを説明する必要があります。パート５をお読みになった方であれば、この次のセクションがよくわかると思います。パート５を読んでいない方は、ぜひ読んでいただきたいのですが、ここではNutanix ADSFがどのようにデータを書き込み、保護するのかという基本的なことを簡単に説明します。以下の図を見ると、3ノードのクラスターに1台の仮想マシンがあります。仮想マシンはa,b,c,dで表されるデータを書き込んでいます。通常の状況では、すべての書き込みは、1つのレプリカが仮想マシンを実行しているホスト(この場合はノード1)に書き込まれ、他のレプリカ(RF3の場合は1つまたは複数)はディスク適合性の値に基づいてクラスター全体に分配されます。ディスクの適合性の値（私は「インテリジェント・レプリカ・プレースメント」と呼んでいます）は、容量とパフォーマンスに基づいて、データが最初から最適な場所に配置されることを保証します。クラスターに1つ以上のノードが追加された場合、インテリジェント・レプリカ・プレースメントは、クラスターがバランスの取れた状態になるまで、それらのノード数に比例して多くのレプリカを（分散して）送信します。万が一、新たな書き込みが発生しなかった場合でも、ADSFにはバックグラウンドでディスクバランスをとるプロセスがあり、低い優先度でクラスター内のバランスをとります。 Nutanixが複数のレプリカを使用してデータを保護する方法（「レジリエンシーファクター（RF）」と呼ばれるもの）の基本がわかったところで、Nutanix ADSFストレージ層のアップグレード時に何が起こるかについて説明します。アップグレードはワンクリックで開始され、設定されたレジリエンシーファクター（RF）やイレイジャーコーディング (EC-X) の使用の有無に関わらず、一度に1つのコントローラVM (CVM)をローリング方式で実行します。ローリングアップグレードでは、一度に1つのCVMをオフ

9540

3 years ago

MohejiVoyager

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

CommunityEditionライセンスについて

CommunityEditionのライセンス期限が近づいてきたため警告が発生しています。CommunityEditionのライセンスを更新もしくは無期限にする方法をご存知に方はご教示いただきたくお願いいたします。

5982

3 years ago

TetsuoMiyoshiNutanix Employee

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

Nutanixの回復力 – パート 5 – CVMのメンテナンス中または障害時のRead I/O

2018年6月8日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。これまでのシリーズでは、ADSFがクラスタ全体にデータを分散することで、ノード障害から迅速に回復する方法について説明してきました（パート1）。また、耐障害性をRF2（Resiliency Factor 2）からRF3へ変換した場合や(パート2)、よりスペース効率の高いEC-X（Erasure Coding）構成へ変換する場合でも(パート4)、影響がないことを説明しました。ここでは、AOSのアップグレードなどのNutanix Controller VM (CVM)のメンテナンス時や、CVMのクラッシュや誤ってまたは悪意を持って電源を切ってしまった場合などの障害時に、VMがどのような影響を受けるかという非常に重要なトピックを取り上げます。早速ですが、Nutanix ADSFがどのようにデータを書き込み、保護するのか、その基本を説明します。下図は、3ノードでクラスタで、1台の仮想マシンが稼働している構成です。仮想マシンはa,b,c,dのデータを書き込んでいます。通常、すべての書き込みは、1つのレプリカが仮想マシンを実行しているホスト（ここではノード1）に書き込まれ、もう1つのレプリカ（RF3の場合は1つまたは複数）がディスク配置の選択優先順位に基づいてクラスタ全体に分散配置されます。ディスク配置の選択優先順位（私は「インテリジェント・レプリカ・プレースメント(Intelligent replica placement)」と呼んでいます）は、データが最初から最適な場所に置かれることを保証します。クラスタに1つ以上のノードが追加された場合、インテリジェント・レプリカ・プレースメントは、新たな書き込みが発生しなかった場合でも、クラスタがバランスのとれた状態になるまで、それらのノードに比例してより多くのレプリカを送信します。ADSFは低い優先度のバックグラウンド処理でディスクバランスを行います。 Nutanixがどのように複数のレプリカを使用してデータ保護を行っているか（「Resiliency Factor」と呼ばれる）の基本がわかったところで、Nutanix ADSFストレージ層のアップグレード時にどのようなことが起こるかを確認します。アップグレードは、

15130

3 years ago

km.itsnAdventurer

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

Nutanix CE ノード復旧時に仮想マシンが停止

Nutanix CEの3ノードクラスタで1ノードに障害が発生し、再セットアップを実施している最中に仮想マシンが停止する事象が発生しました。現在の状態から復旧可能か再構築が必要かお分かりになりましたら教えてください。バージョンは2020.09.16を使用しております。 ■経緯1.3ノードの内、1ノード(2号機)で稼働している仮想マシンが全てパワーオフになっていることを確認。 2.ログを確認したところ、HAでfail overがかかった記録があり、リソース不足で仮想マシンがパワーオンできなかったことを確認。 3.パワーオフされている仮想マシンを1台手動でパワーオンすると以下のエラーが発生し、仮想マシンがパワーオンできないことを確認。----------NetworkError: OVS Error running: { "args":[ "br0","be616bfb-4c01-4ed1-8232-49c10a69aeda","50:6b:8d:e7:f5:fb",1500,0,true,[],false,null,null ], "cmd": "create_local_port", "kwargs":{}} Output: Error: /bin/bash: Input/Output error---------- 4.2号機のコンソールを確認したところ、AHV用のUSBメモリのエラーが発生し、コンソールログインできない状態だったため、2号機の電源を強制再起動。 5.再起動してもブートメディアが見つからないメッセージが表示されAHVが起動しなかったので、AHV用のUSBメモリをWindows機に差し替え、USBメモリの正常性を確認したところ、アクセスができない状態になっていたことを確認。 6.昨日日本語フォーラム向けにブートデバイス障害時の復旧方法について質問させていただき、本日新しいAHV用USBメモリを用意して2号機を4号機(新規ノード)として再インストールを実施。昨日質問させていただいたフォーラムのURL----------https://next.nutanix.com/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%95%E3%82%A9%E3%83%BC%E3%83%A9%E3%83%A0-70/nutanix-ce-%E3%83%

5942

3 years ago

km.itsnAdventurer

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

Nutanix CE ブートメディア故障時の対応方法について

Nutanix CEで3ノードクラスタを構成しているのですが、1台のホストのブートデバイスが故障したらしく、復旧方法をご教示いただけないでしょうか？バージョンは2020.09.16を使用しております。以前2019.11.22の際は、新しいブートデバイスを接続し、インストールオプションで【Repair CVM(Existing data preserved)】を選択すればブートデバイスを復旧できたと思うのですが、2020.09.16も同様の手順でデータ(仮想マシン)は削除されずブートデバイスを復旧可能でしょうか？お手数をおかけいたしますがご教示いただけますと幸いです。

5384

3 years ago

TetsuoMiyoshiNutanix Employee

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

Nutanixの回復力 – パート 4 – RF3からイレイジャーコーディング(EC-X)への変換

本記事は2021年6月5日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。これまでの本シリーズの過程で、クラスタはRF2からRF3へと変換されている状態です。ここで、お客様は回復力に影響を与えることなく、容量効率の向上を図りたいと考えています。ここから我々はイレイジャーコーディング(EC-X)を有効化する際のプロセスとそのスピードについて見ていこうと思います。これまでに議論してきたように、NutanixのEC-Xはバックグラウンドタスクとして動作し、そしてWrite Cold(上書きの頻度が小さい)データのみを対象として実行されます。つまり、構成されているRF処理が通常通り完了し、そしてさらにポストプロセスとしてEC-Xの処理が行われます。これは初回の書き込みI/Oにクラスタ内の数多くのノードの参加が必要になることで、書き込みのプロセスが遅くなってしまわないことを保証するためです。 Nutanix EC-Xの実装についての更に詳しい情報については私の「Nutanix – Erasure Coding (EC-X) Deep Dive」という記事をご参照ください。「What I/O will Nutanix Erasure coding (EC-X) take effect on? (Nutanixのイレイジャーコーディング(EC-X)はどのようなI/Oに対して適用されますか?)」：良いご質問です、Write Coldデータのみです。ですから、EC-Xでの削減効果はデータが徐々にColdになってゆき、NutanixのADSFのCuratorスキャンが低優先度タスクとしてバックグラウンドで変換を行っていくに従って時とともに向上していきます。 ADSFのRF2/3からEC-Xストライプへの変換の速さは? ：極端な話をすれば、本シリーズの最初の部分で示したとおり、ハードウェアとして搭載されたドライブが可能な速さで行なえます、ですが、EC-Xは容量を削減するためのテクノロジーで、データをリスクに晒すものではないため、例えばノードやドライブの障害時の動作と同じ速さでやる意味はありません。ですから、内部的な「ErasureCode:Encode(イレイジャーコード:エンコード)」タスクの優先順位は以下に示すとおり3で、それに

5660

3 years ago

SBCTantousyaVoyager

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

Scanning Cluster(s) in your environment

シングルノードで構成されているクラスタの情報を、NutanixCollectorを使って取得しようとしています。しかし、「Scanning Cluster(s) in your environment ...」が表示されたまま一向に進みません。何か方法は無いでしょうか？

2774

3 years ago

TetsuoMiyoshiNutanix Employee

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

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

本記事は2021年6月5日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。パート1では、Nutanix AOSが分散ストレージファブリック（ADSF）により、ノード障害からレジリエンシーファクター2（RF2）の状態に高速かつ効率的にリビルドする機能について説明しましたが、パート2では、ストレージコンテナをRF2からRF3に変換して耐障害性をさらに向上させる方法と、そのプロセスがどれだけ高速に完了するかを紹介しました。（今回も）パート2と同様に、12ノードのクラスタを使用しており、ノードごとのディスク使用量の内訳は以下の通りです。今回障害をシミュレートするノードのディスク使用量は5TBで、パート1のノード障害テストでの容量とほぼ同じです。なお、クラスタが12ノードになったことで、パート1と比べて（パート1では16ノードを利用）読み書きするコントローラが少なくなっています。次に、ノードのIPMインターフェイス（IPMI）にアクセスし、「Power Off – Immediate（即時の電源オフ）」の操作を実行してノード障害をシミュレートしました。以下は、ノード障害時のリビルドが約30分で完了し、5TBのデータの再保護が完了した際のストレージプールのスループットを示しています。パッと見、5年以上前のハードウェアで5TBのデータの再保護が約30分で完了したことは、SANや他のHCI製品と比較しても非常に素晴らしいことですが、（Nutanixのリビルドは）もっと速くなるはずだと感じたので、少し調べてみました。その結果、ノード障害をシミュレートした時点でクラスタ（を構成する各ノード上のデータ量）のバランスが崩れており、（障害状態をシミュレートしたノードに比べて）他のノードにデータがほとんどないため、通常の状況のようにリビルドに貢献できなかったことがわかりました（リビルド時の読み取りの観点から）。クラスタがアンバランスな状態になっていたのは、（ここまでで）ノード障害のシミュレーションを頻繁に繰り返し行っており、ノード障害のシミュレーションを行う前に、クラスタにノードを追加した後にディスクバランシングが完了するのを待たなかったためです。通常、ベンダーは最適ではないパフォーマンス結果を掲載することはありませんが、私は透明性が重要

5160

3 years ago

ksaitoWayfarer

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

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

3500

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レベルの完全な回復力を維持しつつ、このフェーズで新しい書き込みが行われた際には、すべてRF3で保護されていたことに注目してください。下の図は、ストレージプールの使用量が運用中にリニアに増加してい

15390

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に準拠した状態まで回復する速度です。リビルドは、すべてのノードとドライブにまたがる完全な分散処理（多対多の処理）です。ですから、非常に高速ですし、ボトルネックを回避するため、そして稼働中のワークロードへの影響を軽

17200

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 ディスクスクラビング / チェックサム

4750

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はNutanixと

1550

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つか 3つのデータのコピー、または同等のパリティを持っています)。これらの操作は、データの整合性を復元し、

8250

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ルール」を提唱しております。聞いたことがないコンセプトだと思いま

3310

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

1660

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

2630

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

2810

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

2000

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

3240

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

3040

3 years ago

Page 4 / 9

Global Forums

Badges

Sign up

Login to the community

Scanning file for viruses.

This file cannot be downloaded