Global Forums

Discussions from around the globe

198 Topics

TetsuoMiyoshi
Nutanix Employee
TetsuoMiyoshiNutanix Employee
posted in 日本語フォーラム (Japanese)

AOS 5.19登場: パフォーマンスの向上、セキュリティの改善、自動化された運用

本記事は2020年12月18日にAOS Product Teamが投稿した記事の翻訳版です。原文はこちら。 Nutanix HCIでリモートワークをセキュアに、ワークロードを加速、インフラストラクチャの自動運転を実現AOS 5.19とそれに関連したPrism Centralのリリース PC 2020.11によってNutanixのハイパーコンバージドインフラストラクチャを利用しているお客様に新たな機能をお届けできることを大変喜ばしく感じています。AOS 5.19はAOS 5.18においてなし得たブレイクスルーの上でのさらなるパフォーマンスの改善とデータの暗号化およびセキュア化についてのビルトインの鍵管理能力を拡張を提供します。AOS 5.19ではビルトインのハイパーバイザーであるAHV上で動作する仮想マシンのポータビリティも向上しており、先進的な管理機能との一元化なども行なわれています。  セキュリティROBO環境向けのネイティブ鍵管理システム(KMS - Key Management System)我々は新たな環境においてもいずれの場所であっても暗号化を保証することで継続的にセキュリティをシンプル化し続けています。NutanixはすでにFIPS 140-2認証を得たデータの最終暗号化と鍵管理を外部のKMSもしくはネイティブのKMSの選択肢とともに提供しています。更に詳しくは Data at Rest guideを参照してください。 このリリースで我々はネイティブのKMSを拡張し、1もしくは2ノードのリモート&ブランチ(ROBO)サイトをサポートし、シンプルでコスト効率の高いセキュアなエッジソリューションを実現しました。ネイティブKMSはリモートのPrism Centralベースのroot-of-trustの新たなオプションも提供し、リモートオフィス拠点でのさらなる保護を実現します。AOS 5.19では複数のリモートのクラスタから中央のPrism Centralインスタンスへとローカルに展開されたKMSインスタンスのバックアップ機能も提供し、容易にデータと鍵の双方を保護しセキュアにすることができます。  AHVのMicrosoftのVBS と Credential GuardのサポートAOS 5.19では今年のはじめに開始したセキュアブートについての一連の動き

0
TetsuoMiyoshi
Nutanix Employee
3 years ago
K
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%

2
K
2 years ago
TetsuoMiyoshi
Nutanix Employee
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のリビルドは）もっと速くなるはずだと感じたので、少し調べてみました。その結果、ノード障害をシミュレートした時点でクラスタ（を構成する各ノード上のデータ量）のバランスが崩れており、（障害状態をシミュレートしたノードに比べて）他のノードにデータがほとんどないため、通常の状況のようにリビルドに貢献できなかったことがわかりました（リビルド時の読み取りの観点から）。クラスタがアンバランスな状態になっていたのは、（ここまでで）ノード障害のシミュレーションを頻繁に繰り返し行っており、ノード障害のシミュレーションを行う前に、クラスタにノードを追加した後にディスクバランシングが完了するのを待たなかったためです。通常、ベンダーは最適ではないパフォーマンス結果を掲載することはありませんが、私は透明性が重要

0
TetsuoMiyoshi
Nutanix Employee
2 years ago
TetsuoMiyoshi
Nutanix Employee
TetsuoMiyoshiNutanix Employee
posted in 日本語フォーラム (Japanese)

パブリッククラウドの課題 – パート5：ストレージデバイス障害と回復力への影響

本記事はJosh Odgers氏が2020年8月18日投稿した記事の翻訳版です。原文はコチラ、本シリーズの索引はコチラです。 パート1では、AWSでVMwareのVMC製品を使用する場合、VMwareやその顧客はネットワーク帯域幅を制御できないという、VMCのコアアーキテクチャーが及ぼす重大な影響について紹介しました。パート1をお読みいただいていない場合は、この投稿を読み進める前に目を通していただくことをおすすめします。パート1で紹介している概念は、この投稿のテーマである「デバイス障害と回復力への影響」について理解を深めていただくために重要です。パート2、パート3、およびパート4では、AOSの機能のおかげで、Nutanix ClustersではVMCよりも高いフロントエンドパフォーマンスを発揮しながら、使用可能な容量も多くなるということについて紹介しました。また、パート4では、VMC（vSAN）で圧縮と重複解除を使用すると、ドライブ障害のリスクや影響が大きくなるのに対して、Nutanix Clustersでは、このようなデータ効率テクノロジーを使用するかどうかに関係なく、回復力への影響がないことを紹介しました。このようにNutanix ClustersはVMC/vSANに対して優位性がありますが、プラットフォームが障害に対して高い回復力を備えていなければ意味がありません。この投稿では、AWS i3.metalインスタンスを使用する場合に、Nutanix ClustersとVMware VMCがさまざまなドライブ障害シナリオをどのように対処し、どのように回復するのかについて紹介します。AWS EC2 i3.metalインスタンスなどのパブリッククラウドサービスを使用する際、NVMeフラッシュデバイスは耐久性が高くないと考えられるため、VMC/vSANなどの製品がディスクグループごとに単一キャッシュドライブに大きく依存する場合は、Drive Writes Per Day（DWPD：1日当たりのドライブ書き込み数）の指標が適切でない可能性がある、ということを考慮することが重要です。VMwareは記事「Understanding vSAN Architecture: Disk Groups」の中で、キャッシュドライブに関して以下のように述べています。高耐久性フラッシュデバイ

0
TetsuoMiyoshi
Nutanix Employee
3 years ago
K
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も同様の手順でデータ(仮想マシン)は削除されずブートデバイスを復旧可能でしょうか？ お手数をおかけいたしますがご教示いただけますと幸いです。

4
K
2 years ago
TetsuoMiyoshi
Nutanix Employee
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しました!  

0
TetsuoMiyoshi
Nutanix Employee
2 years ago
TetsuoMiyoshi
Nutanix Employee
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のネ

0
TetsuoMiyoshi
Nutanix Employee
2 years ago
YukiYoshida
YukiYoshidaExplorer
posted in 日本語フォーラム (Japanese)

HYCUによるNutanix Cluster on AWSの統合データ保護

こんにちは、HYCU（ハイク）の吉田です。 当ブログは2020年8月12日にHYCUプロダクト部門のVPであるSubbiah Sundaramによるブログの翻訳版になります。原文はこちら オンプレミスとクラウドの両環境にNutanixを導入し、稼働している仮想マシンとアプリケーションに対し真のマルチクラウド・データ保護を必要とするNutanixのお客様には、HYCUが役立ちます。まず、Nutanix Cluster on AWSの一般提供開始に関する最近の発表について、Nutanixチームにおめでとうございますと言わせてください。これにより、Nutanixのエンタープライズ・クラウドインフラ・ソフトウェアとサービスは、AWSのベアメタルEC2インスタンスで実行できるようになりました。 Nutanixインフラストラクチャをクラウドで実行する理由について疑問がある場合は、ユースケースを注意深く検討する必要があります。Nutanixクラスタをクラウドで実行すべき最適な3つの使用例を次に示します。 クラウドバースト：多くの企業は、ピークシーズンにワークロードが急激に増加するため、それらを実行する上で投資対効果の高い方法が必要です。 オンデマンドの災害復旧：ご存じのとおり、災害復旧（DR）計画は必須ですが、いつ起こるか分からない災害対策にインフラストラクチャのコストを2倍にすることは、経済的にあまり意味がありません。その為、投資対効果の高いDR計画の重要性が不可欠です。 高度なテスト/開発環境：本番環境に移行する前に、実際のシナリオでアプリケーションとインフラストラクチャをテストすることが不可欠です。クラウドを活用することで、「追加の」必要な予備容量だけで実行できます。  HYCUは、Nutanix Clusters on AWSに対し、検証済み且つ正式にサポートする、最初のデータ保護ソリューションの戦略的テクノロジーパートナーになりました！これは、HYCUとNutanixの業界初及び独自の対応に基づいています。Nutanixとの戦略的テクノロジーパートナーシップにより、製品開発段階からNutanixチームと緊密に連携することで、Nutanix Clusters on AWS のリリース日にHYCUも利用可能であることを確認できました！ これまでと同様、HYCUは、Nutan

0
YukiYoshida
3 years ago
TetsuoMiyoshi
Nutanix Employee
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   コミュニティの皆様のブログブログタイト

0
TetsuoMiyoshi
Nutanix Employee
2 years ago
TetsuoMiyoshi
Nutanix Employee
TetsuoMiyoshiNutanix Employee
posted in 日本語フォーラム (Japanese)

パブリッククラウドの課題 – パート6：ベアメタルインスタンスの障害

本記事はJosh Odgers氏が2020年8月19日に投稿した記事の翻訳版です。原文は コチラ。本シリーズの索引はコチラです。 パート1では、パブリッククラウドで環境の価値を高めるために、使用可能なネットワーク帯域幅を効率よく利用することがどれだけ重要なのかについて紹介しました。また、使用可能な帯域幅を最大限に確保すると、フラッシュデバイス（NVMe/SSD）の障害の場合にMean Time To Recover（MTTR：平均修復時間）が短くなり、回復力がどれほど向上するかについても紹介しました。ベアメタルインスタンス（サーバーとノード）の障害の場合にも同じ概念が当てはまります。ただしこの場合は、完全なデータ整合性を回復するためには、単一の1.9TB NVMeデバイス（i3.metalの場合）ではなく8つの1.9TB NVMeデバイスのデータを再保護する必要があります。そのため、リビルドをタイムリーに実行して影響を最小限に抑えるためには、効率的でスケーラブルなアーキテクチャーであることが重要です。まずVMware VMCについて、リビルドの基盤となるアーキテクチャーについて紹介します。VMC（vSANがベース）では、オブジェクト（最大255GB）がリストされるのは、オブジェクトがホストされているソースノード上のキャパシティドライブから、クラスター内の他のノード上のキャッシュドライブ（ディスクグループ当たり1つ）に対してだけです。AWSで、よく使用されているi3.metalインスタンス（8 x 1.9NVMeデバイス）を使用する場合、VMCのリビルド操作では主に2つのNVMeデバイス（2つの「キャッシュ」ドライブ）しか使用されず、キャッシュドライブが一杯になると、残りの3つのNVMeデバイス（ディスクグループ当たり）にリビルドデータが排出されます。つまり、VMwareのVMCを使用する場合、重要なリビルドトラフィックではリビルド用にNVMeドライブの20%しか使用されません。そのため、パート2とパート3で紹介したように、VMCでは使用可能な容量が少なくなるだけでなく、回復力とパフォーマンスの観点でハードウェアが効率よく使用されないため、明らかにVMCプラットフォームの価値が下がります。VMC/vSANでは、クラスター内の使用可能なハードウェアが最大限に利用されない

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

0
TetsuoMiyoshi
Nutanix Employee
2 years ago
K
ksaitoWayfarer
posted in 日本語フォーラム (Japanese)

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

皆様こんにちは。ヴィームソフトウェアの斉藤と申します。Veeamに関するフォーラム寄稿の第4弾となります。 　　・Vol.1 Veeam Software会社紹介とラインナップ+ライセンス  ・Vol.2 Veeamのバックアップについて　・Vol.3 Nutanix Mine "with Veeam"について　・Vol.4 クラウドやKubernetes環境のバックアップについて（今回のトピック） Veeamのマルチクラウドアーキテクチャ はじめにVeeamは「クラウド・データ・マネジメント」の名のもと、マルチクラウド環境下でのインフラマネジメントを推進していることを改めて共有させていただきます。つまり、オンプレミスで稼働するワークロードのみならず「クラウドリフト」および「クラウドシフト」そして「モダナイゼーション」に対応するための支援をさせていただいております。今回はその3つを以下の観点でご紹介したいと思います。　・クラウドリフト：パブリッククラウド（AWS/Azure/GCP）への移行　・クラウドシフト：パブリッククラウド（AWS/Azure/GCP）上のバックアップ　・モダナイゼーション：Kubernetes 環境のバックアップ クラウドリフト：パブリッククラウド（AWS/Azure/GCP）への移行 　現在はクラウドの利活用が進み、開発環境や分析基盤をパブリッククラウドで運用するケースや、お客様によってはすべてのインフラをクラウドに移行するような場合もございます。いずれにせよ、現行のインフラ運用における最適解はオンプレ共存の「ハイブリッドクラウド」もしくは一歩進んでベンダロックインを避けるための「マルチクラウド」になります。しかしながら、オンプレにある環境をパブリッククラウドに移行する場合は適切なパブリッククラウドの選定だけでなく、パブリッククラウド上で既存インフラが稼働するかどうかの動作確認が事前に必要となります。その場合、一旦クラウドにシステムを移し替えるための準備や手間が必要となるため、運用者にとっての負荷増は否めません。その際、Veeamをお使いのお客様であれば「クラウドモビリティ」によりバックアップデータから直接パブリッククラウドにリストアすることが可能です。 　・Restore to Amazon EC2： バックアップをAmazon EC2に

0
K
2 years ago
TetsuoMiyoshi
Nutanix Employee
TetsuoMiyoshiNutanix Employee
posted in 日本語フォーラム (Japanese)

HCIプラットフォーム上のデータベースの拡張性と統合率を評価する方法

本記事は2020年3月27日にGary Little氏が投稿した記事の翻訳版です。原文はこちら。 データベースの統合率をどのように測定しますか？より多くのDBを統合することによってデータベース性能はどのように変化しますか? CVMの実行は利用可能なホストリソースにどのような影響を与えますか? クラスタの性能は理論的上の最大値の90%を達成できました。 CVMのオーバーヘッドはこのワークロードの5%でした。 テスト環境設定評価の目的は、クラスタにデータベースワークロードを徐々に追加していくことでDBのパフォーマンスがどのように影響を受けるかを確認することでした。2つ目の目的として、データベースサーバーと同じホストで仮想ストレージコントローラーを動かすことによる負荷を測定します。Postgresデータベースでpgbenchワークロードを用いて1秒当たりの合計トランザクションを測ります。 クラスタ構成4ノードのNutanixクラスタにて、各ホストはソケットあたり20コアで構成された2つのXeon CPUを備えています データベース構成各データベースは下記スペックやソフトウェアで構成しますPostgres 9.3 Ubuntu Linux 4 vCPU 8GBのメモリ pgbenchベンチマークは、”Simple”のクエリセットを実行しますデータベースのサイズはメモリ内に収まるように調整します。IOではなくCPU/メモリのテストです。 テスト手順1台のホスト上の1つのデータベースよりテストを行います。合せて40データベースになるまでクラスター上にデータベースを追加します。40のデータベースではそれぞれ4つのvCPUとCPUバウンドのワークロードで構成され、クラスター上で160個のCPUコアをすべて利用します。データベースはホストのDRAMメモリに収まるように構成しており、ベンチマークはCPUバウンドであり、可能な限り高速に実行されます。 結果下記より4ノードクラスタ上で1-40台のデータベースを実行した際の測定結果をご覧ください。40台のデータベースでCPUコアが飽和状態になるまで、パフォーマンスは4から160 CPUまでほぼ直線的に上昇し、明らかなボトルネックはありません。 4ノードクラスタでデータベースを1台から40台まで拡張する 完全なスケーリング 対 実際のスケーリ

0
TetsuoMiyoshi
Nutanix Employee
1 year ago
TetsuoMiyoshi
Nutanix Employee
TetsuoMiyoshiNutanix Employee
posted in 日本語フォーラム (Japanese)

Nutanixのメリット その10: ネイティブな仮想マシン単位でのデータ暗号化ではじめからセキュア

本記事はNutanixのTechnical Marketing Engineer – NCI & SecurityのEric Waltersが2022年10月13日に投稿した記事の翻訳版です。原文はこちら。  Nutanixのメリットシリーズを通して、Nutanixクラウドプラットフォームの多用途性、効率性、そしてレジリエンシーについてお伝えしてきました。このシリーズでは高いパフォーマンスとレジリエンシーを大規模環境においても実現するNutanixアーキテクチャのユニークな特性を取り上げてきました。エンタープライズグレードのレプリケーションと災害復旧(DR)と組み合わせ、Nutanixはお客様にハイパーバイザーの自由な選択肢とライセンスのポータビリティを提供できる優れたプラットフォームをご提供しています。加えて、Nutanixが単独のプラットフォームアプリケーションのニーズを満たす統合されたセルフサービスデータベース管理と完全に統合されたストレージをご提供することも確認してきました。これらのすべてのメリットは重要なものですが、昨今のようにエンタープライズにおいてセキュリティが最優先事項で語られるような状況においては、プラットフォームまたはデータがセキュアではない、ということになると、こうしたメリットは全て失われてしまいます。Nutanixはセキュリティを重要な要素として考え、レイヤー型アプローチでプラットフォーム、データ、そして最終的にはアプリケーションを網羅的に取り囲んで保護しています。 これから最もみなさまにとって重要なデータセキュリティについて掘り下げていきたいと思います。プラットフォームとアプリケーションのセキュリティの基本部分について取り上げていきますが、すべてを網羅するにはもう一つ別のシリーズが必要になってしまいます! プラットフォームセキュリティセキュリティは我々の Security development lifecycle (SecDL) プロセスを利用した開発のライフサイクルから始まります。  Nutanixはまた、セキュア構成管理および自動化(SCMA - Secure Configuration Management and Automation)でセキュリティベースラインを維持しており、自動的にセキュリティベースラインに合致しないあ

0
TetsuoMiyoshi
Nutanix Employee
1 year ago
TetsuoMiyoshi
Nutanix Employee
TetsuoMiyoshiNutanix Employee
posted in 日本語フォーラム (Japanese)

Nutanix と HPE が統合されたハイパーコンバージドインフラストラクチャアプライアンスを提供

本記事はMarc Trouard-Riolleが2019年8月1日に投稿した記事の翻訳版です。 原文は[url=https://www.nutanix.com/blog/nutanix-and-hpe-deliver-integrated-hyperconverged-infrastructure-appliance]こちら[/url]。 2019年の4月、NutanixとHPEは統合されたハイブリッドクラウド・アズ・ア・サービス(aaS)ソリューションを市場へ投入するこという[url=https://www.nutanix.com/press-releases/2019/hpe-nutanix-sign-global-agreement-deliver-hybrid-cloud-service]あらたなグローバル・パートナーシップをアナウンス[/url]しました。この合意によってNutanixのチャネルパートナーは直接HPEベースのアプライアンスとNutanix Enterprise Cloudソフトウェアと共に販売することができるようになります。 Nutanixはこの先のさらに次なるステップとして[url=https://www.nutanix.com/viewer?type=pdf&path=/content/dam/nutanix/resources/datasheets/ds-nutanix-hpe-dx.pdf]HPE ProLiant DX[/url]を発表できることを大変喜ばしく思います。これは業界標準の最もセキュアなサーバーとしてすでにProLiantとAppolloプラットフォームで培ってきた基盤となるHPEサーバテクノロジーをベースとした幅の広いNutanixの統合されたアプライアンスです。 [quote]「HPEはHPEとNutanixのパートナーシップによってお客様により幅の広い選択肢を提供できるようになったことについて大変喜ばしく思います。」とSenior Vice President & General Manager, Volume Global Business Unit, Hewlett-Packard EnterpriseのJustin Hotard氏は述べています。「新たなHPE ProLiant DXア

0
TetsuoMiyoshi
Nutanix Employee
4 years ago
TetsuoMiyoshi
Nutanix Employee
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

0
TetsuoMiyoshi
Nutanix Employee
2 years ago
TetsuoMiyoshi
Nutanix Employee
TetsuoMiyoshiNutanix Employee
posted in 日本語フォーラム (Japanese)

Nutanix AOS 6.1 – マルチノードの取り外しとパブリッククラウドバーストにおける優位性

 本記事は2021年12月14日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。 以前にNutanix AOSソリューションが提供するリビルドのパフォーマンスを含む拡張性、回復力、及び性能についての多くの優位性の詳細について述べてきました。これらはNutanix環境が障害発生後に自分自身で、完全な回復力を備えた状態にまでのリカバリを、可能な限り早く実行することを保証しています。 これはNutanix環境を支えるキャパシティとパフォーマンスに応じてデータをクラスタ全体で動的に分散させるAOSストレージファブリックによって可能になっています。 AOSストレージファブリックにはAOSがデータを1MB および 4MBのエクステントで保存するのとは反対に、未発達なHCI製品がデータの保存に巨大なオブジェクトを利用しているために潜在的に発生してしまう、個々のノードのキャパシティの問題に対して未然に対処する事ができる、という点以外にも多くの優位性があります。 AOS 6.1では、複数のノードを同時に取り外す事ができる新しい機能が搭載されますが、これを使うことによって同じAOSアーキテクチャ上で、合理的な時間内に効率的に複数のノードを取り外すことができるようになります。 ノードの取り外しは管理者が各々のノードの進捗状況を監視する必要なく行われ、1ノードが完了すると、それに続くノードの取り外しが前のノードと同様に行われます。 Nutanix Prism UI内でマルチノードの取り外しを実行するサンプル 一つずつ取り外すのと比べてどれぐらい効率的なのか?たとえば、8ノードのクラスタがあり、そこから２もしくはそれ以上のノードを取り外すときのことを考えてみましょう。 以前のAOSと、Nutanix以外のHCIプラットフォームではノード8からクラスタ内の他のノードへ移動されていました。 AOSはこれを、データを残されたすべてのノードに細やかなレベルでバランスしながら効率的に実施していましたが、それに続くノード７の取り外し時にはノード８に格納されていたデータのいくらかがノード7上に配置されており、再度データ移動の対象となってしまっていました。データを2回(もしくはもっと)移動させることは不必要ですし、クラスタへのオーバーヘッドと処理時間の長期化の両方が発生させます。 ノード

0
TetsuoMiyoshi
Nutanix Employee
2 years ago
TetsuoMiyoshi
Nutanix Employee
TetsuoMiyoshiNutanix Employee
posted in 日本語フォーラム (Japanese)

Nutanixの回復力 –パート10– ディスクスクラビング / チェックサム

本記事は2018年11月22日にJosh Odgers氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの索引はこちら。 このシリーズでは、Nutanixプラットフォームがいかに優れた回復力を有しているかを示す幅広いトピックを取り上げてきました。これには、障害時であっても新規書き込みのためのデータ整合性を維持できることや、障害後に問題を引き起こす次の障害のリスクを最小限にするために、タイムリーにリビルドする能力が含まれます。 このような情報があるにもかかわらず、競合ベンダーは、「2つのコピーが失われてしまえば、リビルド時間は問題の本質ではない」といった主張で、Nutanixが提供するデータインテグリティ（データ整合性・一貫性の担保の仕組み）の信用を貶めようとしています。現実的には、データの両方のコピーが同時に失われる可能性は低く、これは安易な主張です。しかし、もちろんNutanixは、最大限の回復力を求めるお客様のために、3つのデータのコピーを保存可能なRF3もサポートしています。 それでは、パート10に進みましょう。ここでは、ディスクスクラビングとチェックサムという2つの重要なトピックについて説明します。この2つの重要なトピックは、RF2とRF3の構成が非常に高い回復力を持ち、データが失われる可能性が極めて低いことを保証するものです。 まず、チェックサムについてですが、チェックサムとは何でしょうか？チェックサムは、書き込み操作中に作成された少量のデータであり、後で（チェックサムのデータを）読み込んで、実際のデータが完全なままであるかどうか（つまり、破損していないかどうか）を確認できます。次に、ディスクスクラビングですが、データの整合性を定期的にチェックするバックグラウンドタスクであり、エラーが検出された場合、ディスクスクラビングはエラー修正プロセスを開始して、修正可能な単独のエラーを修正します。 Nutanixは、すべての書き込み操作（RF2またはRF3）に対してチェックサムを実行し、すべての読み取り操作に対してチェックサムを検証します。これは、データの整合性検証がIO処理の一部であり、スキップしたりオフにしたりすることができないことを意味します。 データの整合性は、あらゆるストレージプラットフォームの最優先事項であり、これが故にNutanixはチェックサムを

0
TetsuoMiyoshi
Nutanix Employee
2 years ago
TetsuoMiyoshi
Nutanix Employee
TetsuoMiyoshiNutanix Employee
posted in 日本語フォーラム (Japanese)

Nutanixのメリット その2: 自動化されたアプリケーションを意識したデータ管理

本記事はNutanixのSenior Technical Marketing EngineerのBhavik Desaiが2022年8月10日に投稿した記事の翻訳版です。原文はこちら。  このブログシリーズはAOSのユニークな分散型ストレージアーキテクチャについて説明し、Nutanixのエンジニアがレジリエンシーと低遅延のパフォーマンスのために、スケールアウトクラスタ全体に動的に分散されるデータに対してどのように難しいアプローチを取ったのかということを取り上げていきます。さて、今回は2つ目の記事です。AOSが仮想マシンのvDiskデータをどのようにして、extent groupと呼ばれる4MBのちょうどよいサイズのチャンクに分割しているのかについて、掘り下げていきたいと思います。 このアプローチは保存の効率が悪く、保護を行うためにネットワーク帯域を多く消費し、リビルドに時間のかかる静的な巨大なブロックを用いるアプローチに比べ遥かに洗練されたアプローチです。AOS内のextentは分散されたメタデータストアによって実現されています。分散メタデータストアはクラウドアーキテクトにとっては最適な状態においても障害発生時においても一貫性を保ち、効率的に分散されたデータを取り扱う方法として知られています。特に障害発生時の動きはストレージアーキテクトにとって興味を引く内容でしょう。 分散された拡張性のあるメタデータ先の記事でご紹介したとおり、AOSのインテリジェンスはコントローラー仮想マシン(CVM)に格納されたサービスとしてクラスタ全体に分割され広がっています。AOS内のメタデータはグローバルとローカルのメタデータストアに分類できます。グローバルメタデータストアは論理的な、どのノードがデータを保持しているかと言うようなメタデータで、一方ローカルメタデータは物理的に実際にどのディスクのどの領域にデータが保存されているかというようなメタデータです。これによって柔軟かつ最適にメタデータを更新することができます。 図1: グローバルとローカルのメタデータ グローバルメタデータストアはかなり大規模に手を入れたApache Cassandraをベースとした分散ストアで、Paxosアルゴリズムを使って厳格に一貫性を担保しています。メタデータはリング状に分散して保存され、冗長性が提供されます。

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

0
TetsuoMiyoshi
Nutanix Employee
2 years ago
TetsuoMiyoshi
Nutanix Employee
TetsuoMiyoshiNutanix Employee
posted in 日本語フォーラム (Japanese)

Nutanixのメリットシリーズ 目次

 本シリーズはNutanix本社のマーケティングチームが2022年の秋に投稿した記事の翻訳版シリーズです。上の画像でIDCが予測するように、2022年から2026年の4年間で生まれるアプリケーションの数は過去40年間かけて生み出されてきたアプリケーションの数に匹敵します。つまり、アプリケーションが生まれるスピードが10倍になっているのです。1年や2年に1回アプリケーションがアップグレードされるのではなく、アプリケーションは1-2ヶ月という頻度で更新されるようになります。このスピードに対応するためには5年に一度更新されるようなインフラストラクチャーでは間に合わなくなってきています。また、数週間に一度というアプリケーションのアップグレードにアプリケーションの停止を伴うようなアーキテクチャーもビジネス上許されなくなり、マイクロサービス型のアーキテクチャへと急速に移行していきます。この流れに対応するため、NutanixもHCIから(ハイブリッド＆マルチ)クラウドプラットフォームへと進化を続けています。これまでのNutanix HCIのメリット(メリット1-5)をベースのテクノロジーとして、マルチクラウド(メリット6,7)、クラウドDBaaS(メリット 8)、マルチプロトコルデータサービス(メリット 9)、そして何よりも重要なマルチクラウドセキュリティ(メリット 10)の提供とクラウドプラットフォームとして進化を続けています。 ぜひ復習として1-5、さらにクラウドとしてのNutanixとして6-10をぜひご確認ください。 Nutanixのメリット その 1: 動的に分散されたストレージ Nutanixのメリット その2: 自動化されたアプリケーションを意識したデータ管理 Nutanixのメリット その3: パフォーマンスとキャパシティのためのシームレスなクラスタ管理 Nutanixのメリット その4: きめ細やかで効率性の高いスナップショット Nutanixのメリット その5: エンタープライズグレードのレプリケーションとディザスタリカバリ Nutanixのメリットその6: ハイパーバイザーの選択肢 Nutanixのメリットその7: 自由なライセンスポータビリティ Nutanixのメリットその8: 統合されたセルフサービスでのデータベース管理 Nutanixのメリット その9

0
TetsuoMiyoshi
Nutanix Employee
1 year ago
TetsuoMiyoshi
Nutanix Employee
TetsuoMiyoshiNutanix Employee
posted in 日本語フォーラム (Japanese)

パブリッククラウドの課題 – パート4：データ効率テクノロジーと回復力に関する考慮事項

本記事はJosh Odgers氏が2020年8月17日に投稿した記事の翻訳版です。原文はコチラ。本シリーズの索引はコチラです。 パート1では、AWSでVMwareのVMC製品を使用する場合、VMwareやその顧客はネットワーク帯域幅を制御できないという、VMCのコアアーキテクチャーが及ぼす重大な影響について紹介しました。また、（オンプレミスの顧客が使用しているのと）同じAOSエンタープライズクラウドソフトウェアをベースとするNutanix Clusters製品で、Nutanix固有のデータローカリティ機能のメリットが得られることを紹介しました。この機能によって、ネットワークへの依存を最小限に抑えてネットワークリソースを解放できるため、ストレージや仮想マシンのパフォーマンスが向上し、クラスターの回復力や機能も強化されます。パート2とパート3では、AOSの機能によって、VMCよりも高いフロントエンドパフォーマンスを発揮しながら、使用可能な容量も多くなることを説明し、その結果としてNutanixで得られるTCO/ROIのメリットについて紹介しました。このようなメリットが得られる要因として、Nutanix AOSの卓越したイレージャーコーディングが挙げられます。また、Nutanixの高度な分散ストレージファブリックによって、レガシーな「キャッシュ+キャパシティ」アーキテクチャーを使用するVMC（vSANベース）のディスクグループよりも使用可能な物理容量が多くなることも挙げられます。このパート4では、VMwareのVMC製品とNutanix Clusters製品がそれぞれ備えているデータ効率機能について紹介し、AWSを使用した本番環境でのこれらのメリットと影響について明らかにします。Nutanix ADSFとVMware vSANの重複排除と圧縮の比較に関する投稿で、両方の製品が3つの主要なデータ効率テクノロジー（圧縮、重複排除、イレージャーコーディング）を備えていることを紹介しました。これらのテクノロジーは、表面上は同じように思えますが（以下の表を参照）、詳細は大きく異なります。また、これらのテクノロジーを有効にする場合、vSAN（VMCのベース）ではクラスターレベルの設定が「オールオアナッシング」であり、柔軟性が非常に低いことも紹介しました。VMCの顧客は、圧縮と重複排除

0
TetsuoMiyoshi
Nutanix Employee
3 years ago
TetsuoMiyoshi
Nutanix Employee
TetsuoMiyoshiNutanix Employee
posted in 日本語フォーラム (Japanese)

Nutanixのメリット その5: エンタープライズグレードのレプリケーションとディザスタリカバリ

本記事はNutanixのTechnical Marketing EngineerのMike Umpherysが2022年9月8日に投稿した記事の翻訳版です。原文はこちら。  一つ前の記事では、Nutanixがネイティブに提供するきめ細やかで効率性の高いスナップショットのテクノロジーと、Nutanixのスナップショットの実装の違い、それがなぜ差別化要素になるのか、ということについて取り上げました。今回の記事では、Nutanixプラットフォームにビルトインされたネイティブのエンタープライズグレードのレプリケーションとディザスタリカバリ(DR/災害復旧)オーケストレーションのメリットについて取り上げたいと思います。 レプリケーションはじめから、Nutanixはプラットフォーム内にきめ細やかなレベルでのレプリケーションを含めていました。我々はこれをエクステントベースのレプリケーション(EBR – Extent-based Replication)と呼んでおり、ストレージのエクステントの範囲で動作しています。エクステントの1つは1 MBの論理的な連続したデータのブロックです。しかし、64 KBの変更データのみを転送したいという場合にはどうなるでしょうか? AOS 6.5 Long Term Support(LTS)以前ではプラットフォームは変更データを含む1 MBのエクステント全体をリモートへとレプリケーションし、リモートシステムは必要ではない部分を切り捨てていました。例えば、100の異なるエクステントでそれぞれ 16 KBの変更データが有った場合、ターゲットクラスタに対して 100 MBのデータを転送する必要がありました。AOS 6.5 LTSには、完全に新しいレンジベースレプリケーション(RBR – Range Based Replication) が含まれており、Nutanixプラットフォームはこれ以降、新規、もしくは更新されたデータの範囲のみをレプリケーションすることが可能になりました。上の例でRBRを利用したとすると、100MBではなく、スナップショットは1.6MBになります。我々の検証によると最大9のスナップショットを利用して、4つの異なるデータの変更率を利用した場合、レプリケーションされるデータを最大で63%削減できるという結果になりました。さらに、すでにターゲ

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

0
K
2 years ago
TetsuoMiyoshi
Nutanix Employee
TetsuoMiyoshiNutanix Employee
posted in 日本語フォーラム (Japanese)

Nutanixの回復力 – パート8 - RF3 & イレイジャーコーディング(EC-X)におけるノード障害時のリビルド性能

本記事は2018年6月19日に Josh Odgers 氏が投稿した記事の翻訳版です。原文はこちら。本シリーズの牽引はこちら。 RF2についてはパート1で、RF3についてはパート3で説明したように、ADSFの回復力を議論する際の重要な要素は、ドライブやノードに障害が発生した場合に、設定されたレジリエンシーファクターに準拠した状態に回復する速度です。 それでは、第1回と第3回の内容を簡単に振り返ってから、RF3とイレイジャーコーディング(EC-X)を使用した場合のノード障害に対するADSFのパフォーマンスの例を見てみましょう。 リビルド処理は、設定されているレジリエンシーファクターやEC-Xなどのデータ削減にかかわらず、すべてのノードとドライブに完全に分散された処理（多対多の処理）であるため、非常に高速であると同時に、ノードごとの作業負荷が最小限に抑えられるため、ボトルネックを回避し、稼働中のワークロードへの影響を軽減することができます。 リビルドの性能は、クラスターの規模、ドライブの数や種類（NVMe、SATA-SSD、DAS-SATAなど）、さらにはCPUの世代やネットワークの接続性など、さまざまな要因に左右されることを忘れてはいけませんが、それを踏まえた上で、以下のハードウェアを使った例を紹介します。 テスト環境は15ノードのクラスターで、Ivy Bridge 2560プロセッサ（2013年第3四半期発売）を搭載したNX-6050およびNX-3050ノードなど、約5年前のハードウェアが混在しており、各ノードにはサイズの異なる6つのSATA-SSDと2つの10GbEネットワークインターフェースが搭載されています。 イレイジャーコーディングはRF2やRF3よりも多くの計算オーバーヘッドを必要とするため、より高速なプロセッサを使用することでリビルド速度に大きな差が出ます。レジリエンシーファクターは単にレプリカをコピーするだけです（つまり、パリティの計算は必要ありません）。 今回のテストでは、クラスターをRF3とイレイジャーコーディングで構成しました。 これまでのテストと同様に、IPMIインターフェースを使用し、以下のように「Power off server - immediate」オプションを使用してノード障害をシミュレートします。これは、物理的なサーバーの背面から電

0
TetsuoMiyoshi
Nutanix Employee
2 years ago

Badges

Show all badges
Terms & Conditions