2019/03/29

VDPとは違うのだよ、VDPとは!(Veeam B&R)

2017年4月にVMware社からvSphere Data Protection(以下、VDP)の提供終了が発表されましたが、VDPを使用して仮想マシンをバックアップしているお客様から、移行先となるバックアップソフトを検討していると弊社にご相談いただく機会が増えてきました。

End of Availability (EOA) of VMware vSphere Data Protection (2149614)

https://kb.vmware.com/kb/2149614

そこで、今回はVDPからの移行先のバックアップソフトの候補の1つとして、Veeam Backup & Replication(以下、VBR)とVDPの違いやVDPから移行するメリットをご紹介したいと思います。


VDPを使い続ける課題

まず、VDPを使い続けた場合の問題点を見てましょう。

(1)サポート期限

VDPのサポート期限は下記で公開されておりますが、VDPの最終バージョンの6.1はジェネラルサポートの終了が2020年3月12日、テクニカルガイダンスの終了が2022年3月12日となっています。

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/support/product-lifecycle-matrix.pdf

01

03_2

ジェネラルサポートとテクニカルガイダンスの違いは下の表の通りですが、ジェネラルサポートが終了すると新規のセキュリティパッチの提供や新規の不具合の修正が行われなくなりますので、セキュリティリスクが高くなり、障害が発生した場合に問題が解決しない可能性も出てきます。

https://www.vmware.com/jp/support/policies/lifecycle.html

04_2

(2)対応vSphereバージョン

次にVDPが対応するvSphereのバージョンを確認してみましょう。VMare製品の互換性は下記から確認できますが、VDPのバージョン6.1.8以降で6.5 Update2に対応しておりますが、6.7には対応していないため、vSphereを6.7にバージョンアップする際にはVDPから別のバックアップソフトへの移行が必須になります。

<VMware Product Interoperability> https://www.vmware.com/resources/compatibility/sim/interop_matrix.php

05_2

(3)対応Data Dmainバージョン

VDPのバックアップ先としてはVDPの仮想アプライアンスの仮想ディスクだけでなく、Dell EMCの重複排除バックアップストレージであるData Domainも利用できますが、Data Domainにバックアップしている環境ではData DomainのOS(以下、DDOS)のバージョンも考慮する必要があります。
 

Dell EMC社の互換性リストを確認すると、VDPの最終バージョンの6.1はDDOS 6.0までの対応になっており、DDOS 6.1以降には対応していないため、DDOSのバージョンを6.1以降にバージョンアップすることができません。

http://compatibilityguide.emc.com:8080/CompGuideApp/getDataDomainBoostCompGuidePage.do

06

Dell EMC社のKB(要:Dell EMCアカウント)で公開されておりますが、VDPにDDOS 6.1.xのData Domain を追加しようとするとエラーになります。

VDP: Adding a Data Domain with DDOS version 6.1.x to the VDP fails with error "Invalid hostname or credentials"

https://support.emc.com/kb/507577

 

下の表はDDOSのサポート終了日を纏めたものです。DDOS 6.0のサポート終了日は現時点では決まっておりませんが、6.0.1.xは既にサポートが終了しておりますので、DDOS 6.0のサポート終了日にも注意しましょう。

07

尚、DDOS 6.0のサポート終了日の最新情報は下記から確認してください。(要:Dell EMCアカウント)

https://support.emc.com/products/41097_DD-OS-6.0

VBRに移行する理由(メリット)

次に、VDPとVBRの違いを見てみましょう。

(1)vSphereとData Domainへの対応

VBR 9.5 Update4ではvSphere 5.0から最新の6.7 Update1までの幅広いバージョンに対応しております。

https://www.veeam.com/veeam_backup_9_5_u4_release_notes_rn.pdf

08_2

 

Data Domainに関しても既にVBR 9.5 Update3でDDOS 6.1に対応しており、最新のVBR 9.5 Udpate4aでDDOS 6.2にも対応しました。

KB2926: Release Notes for Veeam Backup & Replication 9.5 Update 4a

https://www.veeam.com/kb2926

09

(2)対応バックアップデバイス         

下の表はVDPとVBRの対応しているバックアップデバイスを比較したものです。VDPは仮想アプライアンス、VBRはWindowsにインストールするアプリケーションという違いはありますが、VBRはVDPと比べて多くのデバイスに対応しています。

10

(3)アプリケーション対応

下の表はVDPとVBRの対応している仮想マシンのアプリケーションを比較したものですが、VDPはSQL Server/Exchange/SharePointだけになり、新しいバージョンにも対応できていませんが、VBRは最新バージョンにも対応しており、更にActive DirectoryとOracleにも対応しています。

11

※アプリケーションによっては、Service Packの要件もありますので、ご注意ください。
 

アプリケーションの対応内容にも違いがあります。VDPの場合には、仮想マシンに各アプリケーション用のソフトウェアをインストトールし、仮想マシン全体のエージェントレスのバックアップとは別にアプリケーション単位でもバックアップする必要があります。

12

重複排除によりバックアップデータは大きく変わらないとしても、仮想マシンにソフトウェアをインストールしなければならない点やバックアップジョブの数が増えること、バックアップ実行タイミングが重ならないようにするなど考慮すべき点は増えます。

それに対して、VBRの場合は、仮想マシンにソフトウェアのインストールは不要で、仮想マシン全体のエージェントレスのバックアップをするだけでアプリケーションを含めてバックアップすることができ、そのバックアップデータから仮想マシン単位・アプリケーション単位どちらのリストアもできてしまうのです。

13

(4)ファイルレベルリストア

VDPとVBRはどちらも仮想マシン全体のバックアップからファイル単位でのリストアができますが、そのファイル単位でのリストアにも違いがあります。下の表は対応しているファイルシステムを比較したものですが、VDPは対応しているファイルシステムが少なく、制限が多いのに対してVBRは多くのファイルシステムに対応しています。

14

実際のリストア操作においても、違いがあります。VDPはバックアップ対象の仮想マシンからブラウザでVDPのファイルレベルリストア用のサイトにログインしてリストアしなければなりません。

<VDPのファイルレベルリストア画面>

15_2

それに対して、VBRは管理サーバもしくは、リモート管理コンソールをインストールしたマシンからリストア操作ができ、バックアップ対象の仮想マシンからリストアしなければならないという制限はありません。

<VBRのファイルレベルリストア画面>

16_2

VDPのようにバックアップ対象の仮想マシンからブラウザを使用してユーザーにリストアをさせたい場合には、セルフサービスリストアの機能を利用すれば、VDPに近い運用も可能です。

<VBRのセルフサービスリストア画面>

17_2

(5)通知機能

VDPもVBRもメール通知機能がありますが、その内容には違いがあります。VDPの場合は、1日1回サマリーのメールを1通送信するだけになります。

18_2

複数のバックアップジョブを設定した場合でも1通のみになり、特定のバックアップジョブが失敗していた場合に対象のジョブを確認しづらいという問題があります。

19

それに対して、VBRはバックアップジョブ毎にメ―ル送信を設定でき、更に失敗した場合のみ通知する設定もできるため、どのバックアップジョブが失敗したのかが分かりやすくなっています。

20

21

(6)構成情報のバックアップ

VDPは仮想アプラインスとして提供されております。仮想アプラインス自体が壊れてしまった場合には、仮想アプラインスのデプロイ自体は簡単ですが、バックアップジョブなどの設定は全て再設定になります。それに対して、VBRは設定情報をバックアップする機能があるため、VBRのサーバが壊れてしまった場合でもOSとVBRのアプリケーションをインストールし、バックアップしておいた構成情報をリストアすれば、バックアップジョブやカタログ、認証情報などの設定を戻すことができるため、再設定が不要になります。

22_3

 23_4

(7)スケールアウト対応

仮想マシンが多数あるような大規模環境では1台のVDPだけでは、バックアップを処理しきれない場合があります。そのような時、VDPの場合は追加のVDPアプライアンスを展開することになりますが、それぞれのVDPがバックアップ管理サーバ兼バックアップ処理サーバとなるため、各VDPにログインしてバックアップ設定をすることになり、運用も煩雑になります。

24

それに対して、VBRはバックアップ処理サーバ(Proxy Server)だけを追加することができるため、バックアップ設定は1台のバックアップ管理サーバにログインして行えば良いため、運用が楽であり、簡単にスケールアウトすることが可能な仕組みになっています。

27_2


以上のように、VBRにはVDPの問題を解決でき、更に多くのメリットがあります。ここでは書き切れませんが、VBRには他にも魅力的な機能が沢山ありますので、VDPから別製品への移行を検討している方は、VBRを検討頂ければ幸いです。

VBR以外にも弊社では多数のバックアップソフトを扱っておりますので、VBRに限らず、仮想環境のバックアップは弊社にお気軽にご相談ください。それでは、また。

 担当:臼井

2019/03/27

Nutanix VirtIO ハードウェア取り出しの無効化

こんにちは、ネットワールドの海野です。

今日はNutanix VirtIOについて記事を書きました。

Nutanix環境において Windows OSの利用時、右下のタスクトレイから仮想ハードウェアの「取り出し」ができてしまいます。

仮想ハードウェアの「取り出し」を行うと仮想マシンの正常動作に影響が発生しますので、

対策方法をまとめました。

01


前提条件

対象となるWindows仮想マシンが Active Directory へ参加していること。

対応の概要

Active Directory の GPO にてスタートアップスクリプトの作成および適用を実施します。

対象となるWindows仮想マシンで「ハードウェアの取り出し」が無効となったことを確認します。

用意するスクリプト (テキストファイルにコピーして拡張子を.batにします。)

reg.exe add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\PCI\VEN_1AF4&DEV_1000&SUBSYS_00011AF4&REV_00\3&13c0b0c5&0&18" /v Capabilities /t REG_DWORD /d 2 /f
reg.exe add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\PCI\VEN_1AF4&DEV_1002&SUBSYS_00051AF4&REV_00\3&13c0b0c5&0&28" /v Capabilities /t REG_DWORD /d 2 /f
reg.exe add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\PCI\VEN_1AF4&DEV_1004&SUBSYS_00081AF4&REV_00\3&13c0b0c5&0&20" /v Capabilities /t REG_DWORD /d 2 /f

手順 (画像でお楽しみください。)

8

9

10

11

12

これで完了です。


以下、参考情報です。

14

15※この記事の元ネタを書いてくださった William Fulmer 氏に感謝申し上げます。
 元ネタ : WHERE DID I READ THAT ( Removing Nutanix AHV Acropolis HotPlug Devices )

16

17

18

今日はこんなところで。

記事担当者 : SI技術本部 海野 航 (うんの わたる)

2019/03/20

Nutanix Move 3.0(旧Xtract for VM)がGA

本記事の原文は記事の原文はDerek Seaman氏の個人ブログの記事の翻訳ヴァージョンです。原文を参照したい方は、Nutanix Move 3.0 (formerly Xtract for VMs) now GA をご確認ください。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら

ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。

(初回はID、パスワードの取得が必要です)

 


最新の Nutanix Move 3.0 です。Nutanix Move 3.0とは何でしょうか?Move 3.0は、以前はXtract for VMと呼ばれていた製品の次のメジャーリリースです。 Xtract for VMは、Nutanix AHVハイパーバイザーへのVMの簡単な移行を可能にする無償のNutanix製品です。 VMをAHVに移動するにはさまざまな方法がありますが、Moveは最も優れたツールの1つです。私は無償と言いましたか?はい、言いました。私の顧客の何人かはそれを使用し大きな成功を手に入れました。

 

Move 3.0の新機能:

 ・Move のサービスはDockerisedになり、すべての Moveサービスと MoveエージェントサービスはDockerコンテナとして実行されるようになりました。 アーキテクチャ的には、これは移動を「サービス化」し、サービスをほとんど中断することなく機能を追加/更新する機能を提供するとともに、どこでも移動を実行できる柔軟性を提供するための重要なマイルストーンです。

・移行元としてのHyper-VのGAリリース、ESXiとAWSのソースリストへの追加

・Move のワンクリックアップグレード。 (ダークサイトのサポートが登場)

・UI のステータスアップデートの強化を伴う大規模な VM 移行向けユーザーエクスペリエンスの更なる機能強化

・単一のマイグレーションプラン(* 移行ジョブ)の中に、自動で準備されたソースVM と手動で準備されたソースVMの混在を許可するソースVM の混在モードをサポート

・移行元のESXi上で実行されているLinuxソースVMに対するPEMベースの認証のサポート

・最後に、「Xtract for VM」から「Nutanix Move」へのブランド変更

 

Move 3.0は、移行元がESXi 向けにCentos / RHEL 6.3、Suse Linux Enterprise Server 12、Ubuntu 12.0.4サーバーエディション、Ubuntu 18.0.4サーバーエディションのゲストOSもサポートしています。さらに、移行元が Hyper-V 向けにWindows Server 2019ゲストOSのサポートが追加されました。

 

便利なリンク:

Release Notes
User Guide
Downloadable Bits


記事担当者 : SI技術本部 キタガワ @Networld_NTNX

2019/03/14

Xi Leap - 実証済み、高速かつ効率的

本記事の原文はNuatnix Community に投稿されている Nutanix Leap(旧Xi DR サービス)に関する記事の翻訳です。原文を参照したい方は、Xi Leap - Proven, Fast and Efficient をご確認ください。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら

ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。

(初回はID、パスワードの取得が必要です)


この記事はNutanix のPrincipal Technical Marketing Engineer であるDwayne Lessner氏によって書かれました。

 

「悪魔は細部に宿る」という古いことわざがあります。 あなたが何かを考えてから、より多くの支払いが必要になったり、何かを修正したり、または購入したものがうまく動作しないままだったのなら、痛みを感じていたでしょう。 昨年末、私は目標復旧時点(RPO)の重要性に加え、目標復旧時間(RTO)の提供に関する記事を書きました。 私は、Xi East Regionへ接続し使用しているオンプレミスラボクラスタの技術的な詳細をいくつか共有したいと思いました。フェイルオーバーを行ってもアプリケーションのパフォーマンスを維持し続ける、Xi Leaps SLAのRTOを証明したいです。

 

実証済みの結果

テスト中に達成できたこと:

・1VMあたりのリストア時間が8秒未満

・オンプレミスまたはXiの同じ仮想マシンで同等のパフォーマンス(1分あたり+ 60万トランザクション)を達成

・同じイメージから仮想マシンを作成するとき、NutanixスナップショットはXiへの通信よりも効率的である

 

詳細については、ブログの残りの部分を読み、以下に含まれる3つのビデオをご覧ください。

 

現在の私のラボクラスタでは、フェニックスにある環境で動作しており、パワーオンの流れをテストするのに、さまざまなサービス、Active Directory、Citrix for VDIのフェールオーバーテスト、SQLパフォーマンス、およびさまざまな多層アプリケーションがあります。

1

  

私の Xi Region は、Xi Eastでバージニア州アッシュバーンにあります。アリゾナ州フェニックスからアッシュバーンへの平均的なレイテンシは、Palo Altoが提供するソフトウェアVPNを介したレプリケーションで約58ミリ秒です。 オンプレミスの自動設定で5つの異なるネットワークベンダーをサポートしていますが、これらのデバイスに限定されません。

 

2  

効率的なハードウェアベースのスナップショット

私は、6 vCPU、32 GBのRAM、ストレージとして450GB の使用可能な容量がある8つのvDiskを備えた中規模のSQLサーバーを展開しました。 サーバー上の最初のコピーが複製されたらすぐに、追加の10個のコピーをオンプレミスで複製し、Xi Leapで保護することで、Nutanixスナップショットの効率性を示したかったのです。 以下のビデオは、メタデータがどのように追跡されているのかを示していますが、全体の450 GB×10回を複製している訳ではありません。 Xiテナントにログインするまでに、レプリケーションが完了したことがわかります。 したがって、同じイメージから多数のVMを構築しているのであれば、Xiでネットワークとストレージのコストを全容量分支払う必要はありません。 また、これらはハードウェアベースのスナップショットなので、長いスナップショットチェーンについて心配する必要はなく、手動でそれらをつぶすために時間を費やす必要はありません。

Nutanix hardware based snapshots allow for efficient data transfer for Xi Leap
YouTube: Nutanix hardware based snapshots allow for efficient data transfer for Xi Leap

 

低 RTO

10個のSQL VMが完全にXiに複製されたので、復元にかかる時間を見てみましょう。 200台以上の仮想マシンに障害が発生した場合、完全な復元には約20分かかります。 簡単なフェイルオーバープロセスを見るために以下を見てください。

 

Xi Leap for Fast RTOs (Recovery Time Objective)
YouTube: Xi Leap for Fast RTOs (Recovery Time Objective)

 

上記のビデオは、仮想マシンあたり10秒以内にVMを復元できることを実証できました(ビデオでは仮想マシンあたり7.7秒でした)。復旧のスピードは、オンプレミスとクラウドソリューションで同じイメージフォーマットを使用していることに起因します。同じイメージフォーマットを使用すると、仮想マシンの変換プロセスを経ずに、準備が整ったらオンプレミスに戻ることもでき、オンプレミスに戻る RTO を低減することができます。ビジネスクリティカルなサービスをバックアップし稼働させるという重圧があるとき、同じ管理フレームワークとVMイメージフォーマットを持つことでユーザーエラーを回避するべきです。

 

安定したハイパフォーマンス

XiにはいくつかのちょうどいいサイズのSQL VMがあったので、新しいクラウドストレージ構造を考え出すことを心配することなく、オンプレミスで実行するのと同じようなパフォーマンスを達成する方法を示すことで、復元プロセスを集約したかった。以下のビデオでは、オンプレミスとクラウドで同じデータセンターオペレーティングシステムを使用しているため、パフォーマンスを犠牲にすることなく柔軟性が得られます。

 

3


図1オンプレミスとクラウドでの同様のパフォーマンス

Xi SQL Server Performance
YouTube: Xi SQL Server Performance


 

Xi Leapを使用すると、パフォーマンスを心配することなく、ITスタッフを再トレーニングすることなく、また2つ目のDRデータセンターを維持することなく、ビジネスを迅速に再開および運用することができます。 オンプレミスの利点をすべて維持しながら、ワンクリックでフェイルオーバーを実現します。

 

Disclaimer: This blog may contain links to external websites that are not part of Nutanix.com. Nutanix does not control these sites and disclaims all responsibility for the content or accuracy of any external site. Our decision to link to an external site should not be considered an endorsement of any content on such site.

Photo2019 Nutanix, Inc. All rights reserved. Nutanix, the Nutanix logo and the other Nutanix products and features mentioned herein are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s).


記事担当者 : SI技術本部 キタガワ @Networld_NTNX

2019/03/06

Nutanix Files と Nutanix Files Pro ライセンスのクラウドライクな柔軟性

本記事の原文はNutanix Community に投稿されているNutanix Files(旧 Acropolis File Services)の新しいライセンス体系に関する記事の翻訳です。原文を参照したい方は、Cloud Like Flexibility for Nutanix Files and Nutanix Files Pro Licensing をご確認ください。

 

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら

ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。

(初回はID、パスワードの取得が必要です)


この記事は、ストレージサービス担当シニアプロダクトマーケティングマネージャ、Devon Helmsによって執筆されました。

2年足らず前にAcropolis File Services(AFS)を立ち上げて以来、エンドユーザーの採用が急速に進んできました。 私たちは現在、ペタバイト規模のデータを管理している1000近くのお客様を抱えています。 これらのお客様の多くは、レガシーNASソリューションに代わる、スタンドアロンのNASクラスタとしてAFSを展開しています。 これらのお客様は、私たちが過去4年間に渡り行なったエンジニアリング投資より、NAS市場で効果的に競争できるソリューションをもたらしたことに気づかせてくれました。

その結果、昨年11月15日に、Nutanix Files と Files Proを立ち上げました。 Files は、既存のAOSクラスタにNAS機能を追加したいお客様のためのものです。 Files Proは、当社のソリューションを専用のNASクラスタとして展開したいお客様のためのものです。

 

容量ベースのライセンス

Nutanix FilesとNutanix Files Proの両方が、新しい“Used capacity”ベースのライセンス(capacity based licensing)を導入しています。

 

 “Used capacity” とは、管理する容量を指し、ライセンス基準の指標です。一例として、お客様が専用NAS クラスタに 250TB のファイルデータを持っている場合、250TB の Nutanix Files Pro ライセンスを購入します。クラスタの物理容量がより大きい場合でも、お客様は、必要な容量のソフトウェアライセンスを購入するだけで済みます。

 

容量ベースのライセンス構造の利点

 このライセンス方式には、多くの利点があります。主な利点は、数か月あるいは数年使用されないかもしれない容量を事前購入する費用を控除するために、お客様が必要に応じて支払うモデル(pay-as-you-grow)を使用できるようになることです。もう一つの関連する利点は、長期計画の簡素化です。私たちのお客様の多くは、非構造化データが爆発的に増加し、その増加をあらゆるレベルの正確に予測することは困難です。

 

容量ベースライセンスと、Nutanix Filesおよび、Nutanix Files Pro の独自のスケールアップ-スケールアウトアーキテクチャを組み合わせることで、お客様はニーズに合わせて時間の経過とともに簡単かつ柔軟に環境を拡張することができます。

 

AOS を利用するお客様のための Nuatnix Files 無料容量

この新しいライセンスモデルは、まだNutanix Files やNutanix Files Pro を自身の環境に採用していない多くのNutanix のお客様には間違いなく興味を持ってもらえるでしょう。 現在、Nutanix AOS クラスタごとに1 TBのNutanix Files 容量を無償提供しています。 この容量により、既存のAOS のお客様は、自分の環境でNutanix Files をテストし、このシンプルで柔軟でインテリジェントなファイルストレージソリューションの利点を直接体験することができます。

 

Nutanix Files と Nutanix Files Pro の利点

容量ベースのライセンスは、Nutanix Files および、Nutanix Files Pro が提供する多くの新機能の一つに過ぎません。3月のリリースでは、エンドユーザがどのようにデータにアクセスしているのか見通したり、潜在的な脅威を可視化したりする新しいFile Analytics 機能を提供するでしょう。また、新しいNFSv3 とマルチプロトコル機能をリリースし、お客様の様々なアーキテクチャが混在した環境に柔軟性を提供するでしょう。

あなたは http://nutanix.com/files でファイルストレージにおけるこれらの大きな進歩のすべてについて学ぶことができます。



C_3 2019 Nutanix, Inc. All rights reserved. Nutanix, the Nutanix logo and the other Nutanix products and features mentioned herein are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s).


記事担当者 : SI技術本部 キタガワ @Networld_NTNX

2019/02/27

最小限のダウンタイムでVMをAHVへ移行

本記事の原文はNutanix Communityに投稿されているNutanix Move(旧称 Xtract )に関する記事の翻訳です。原文を参照したい方は、 Migrate your VMs to AHV with Minimum Downtime をご確認ください。

 

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら

ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。

(初回はID、パスワードの取得が必要です)


 

この投稿は、Nutanix Technology Champion(NTC)のMattias Sundling氏(データセンターおよびクラウドサービス部門長、A3)によって執筆されました。

 

サービスプロバイダーになることで、オンプレミスの仮想環境を実行しているお客様に常にサービスを提供できます。 それらの大部分は、VMware ESXiおよびMicrosoft Hyper-V上で実行されています。VMの可用性と私たちが費やす時間への影響を最小限に抑えながら、これらのワークロードをパブリッククラウドサービスに移動するプロセスを合理化するために、最初のベータ版以来Nutanix Move(以前はXtractと呼ばれていました)を使用しています。 リリースされたのは1年以上前のことで、VMware ESXiをサポートしていました。 だから、私たちはHyper-VをサポートするMoveのベータプログラムがあることにとても興奮していました。

 

ターゲット(移行先)のAHVクラスターに仮想アプライアンスとして実行される新しいバージョン(のMove)をインストールし、それをお客様のHyper-Vホストに接続しました。 その後、Nutanix Moveはすべてのホストからインベントリを取得し、選択したVMの Migration Plan(*1)を作成することを可能にします。 管理者/ルート資格情報を入力することで、すべてのゲストOSの準備が自動的に行われ(Nutanix VirtIOドライバのインストールとIP設定のエクスポート)、ネットワークマッピングの入力も求められます。

*1 移行ジョブのようなもの

 

Move001

 

Migration Planを構成したら、ユーザーに影響を与えずに、選択したVMのseeding the data(データの初期同期)を開始できます。 最初の同期が完了すると、VMのサイズによっては時間がかかることがありますが、進行中の同期は10分ごとに行われます。 最後のステップは、cutover を行うことで、これは移行元のVMをシャットダウンしてから移行したVMの電源を入れる前に最後のオフライン同期を1回実行することです。

 

このアプローチで気に入っていることの1つは、移行したVMで問題が解決しない場合、非常に良い切り戻すプランがあることです。 仮想NICを有効にしてソースVMの電源を入れるだけで、シャットダウン前の状態に戻ります。

  

VirtIO ドライバを使用して作成されたため、移行されたVM は初めてAHV で起動し、正常に実行されます。まずはDHCP、その後エクスポートされたIP設定が自動的に適用されるため、必要に応じてIPアドレスがMACアドレスを含めて保持されます。

 


YouTube: Nutanix Move Overview in 90 Seconds

私たちは、Nutanixに報告したベータ版のマイナーなバグに気付いただけで、すべての移行は成功したので、結果には満足しました。Nutanix Moveは、Hyper-Vのお客様に多く使用されるだろうし、お客様をレガシー環境から、Nutanix AHV をベースとするパブリッククラウドに移行することを可能にします。

 


この度 Xtract と呼ばれていた、VM の移行ツールの名称が Nutanix Move と呼ばれるようになりました。

これを機に、Nutanix Move に関して、あらためて知りたいという方がいらっしゃいましたら、手前味噌ではありますが、ネットワールドらぼの過去の Xtract 関連記事もあわせてご参照いただければと思います。

 

記事担当者 : SI技術本部 キタガワ @Networld_NTNX

2019/02/20

AHVへのVLAN設定

本記事の原文はであるNutanix Communityに投稿されているAHVのOpen vSwitchの基本に関する記事の翻訳です。

投稿されてから時間はたっていますが、AHVを構成する際にベースとなる構成の為、改めて紹介していきます。

原文を参照したい方はVirtual LANs for your Acropolis Hypervisor Virtual Machinesご確認ください。

情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら

ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。

(初回はID、パスワードの取得が必要です)


784ia358bc964aa457ed

最初の記事ではLoad Balancingを紹介し本日はAHVとController VMのVLAN についてお話をします。

ストレージと管理トラフィックは実際にユーザー仮想マシンのトラフィックを別にしていますが、AHVに関してもこれは例外ではありません。VLANはユーザーVMのタイプ管でのトラフィックの分離を提供するのに便利です。

仮想化において多くのVLANはしばしばトランクされ、仮想マシンによって異なるワークの利用を行います。

Nutanixでは下の図のようにVLANコンフィグレーションでCVMとAHVをデフォルトVLAN(untagged , or Native)VLANに設定する事を推奨しています。

784ia358bc964aa457ed_2

Note:このデフォルト構成のVLANはユーザーVMの為にAHVが101, 102がトランクとして構成されています。

AHVとCVMへのトラフィックはVLAN Tagを構成していませんが、デフォルトの構成のuntagged 通信がAHVとCVM通信に好ましくないケースやセキュリティポシリー上、許可されない場合はVLANTagをホスト、CVMへ次の用に追加する事が出来ます。

785icb9c4d95fb243e72

クラスタ内の全てのAHVホストのbr0へVLANタグを構成する方法です。

全てのホストで以下を実施してTagを追加します。

nutanix@CVM$ ssh root@192.168.5.1 "ovs-vsctl set port br0 tag=10"
nutanix@CVM$ ssh root@192.168.5.1 "ovs-vsctl list port br0"

クラスタ内の全てのCVMへVLAN タグを追加する方法です。

全てのホストへ同じように追加します。

nutanix@CVM$ change_cvm_vlan 10

本Tagの構成を実施する場合は一台づつ実施してping等が疎通出来る事を確認して次のホストへ実施という方法を推奨します。

(そのためには一旦クラスタの停止->VLAN追加 ー>ホスト起動)という形が理想です

このデザインではAHVホストとCVMトラフィックはVLAN ID 10のTagが追加されている状態となります。ユーザーVMはaCLIまたはPrismでネットワークの構成を実施します。

CVMのストレージデータと管理トラフィックはサンプルで表示しているVLAN10で通信されます。

ストレージデータと管理トラフィックで分離する必要がある場合は

ネットワークセグメンテーション等を活用して分離する事も可能です。

CVMとAHVホストはUserVMとは別のネットワークで通信が出来るようになっています。

AHVをご利用する際に考慮する項目としてこれまでに、物理スイッチとホストのネットワーク構成

OpenvSwitchの設定、ブリッジの作成に関する説明を記載しておりますので、設定の際に参考頂ければ幸いです。

記事担当者 : SI技術本部 カッシー @Networld_NTNX

2019/02/18

本当のMulti Cloud Manager (ver 3.1.2)

みなさん、こんばんは。こんにちは。鈴木です。

ひたすらIBM Cloud Private関連の内容を投稿していますが、変わらずその内容です。

今現在、IBM Think 2019が行われており、これまでいろいろを投稿させていただいているMultiCloud Managerについて新バージョン(ver 3.1.2)がリリースされました。 今回は速報でサクッとご説明したいと思います。

  • Azure,AWS,GoogleのKubernetes環境に対応

20190213_234743958_ios


画像のように、IBM MultiCloud Managerで他社製のクラウドの管理もできるようになります。 設定としては、各クラウドのKubernetes上に Klusterlet という管理エージェントとなるコンテナーをデプロイする必要があります。

実際に管理している画面はこちら。

20190213_234748306_ios


実は、AWSやGKSなどは自動で判別はしてくれませんが、タグをつけることができるので、ユーザーごとに管理単位ごとにタグ付けしていただくことで、管理に柔軟性を持つことができます。


  • 検索の実行 これまでのMultiCloud Managerでは複数クラスター(これまではICPとIKSでしたが)の管理をしている場合に、どこにどのPodがあるかなどの検索の手段がありませんでした。 しかし、今回のバージョンでは Search の機能が追加されており、Podなどの検索がサクッとできるようになっています。

20190213_235540541_ios



  • Dash boardからのドリルダウン 地味ですが、管理者には素敵な機能です。
    これまでは、Dash boardの一覧で問題があったホストなどがあっても、Dash board上からはドリルダウンできない場所もありました。 今回のバージョンでは、Dashboardの一覧から問題のあるHostなどに対して、すぐにドリルダウンできるようにインターフェースが改良されています。


  • インストールに関して IBM MultiCloud Manager 3.1.2が最新になりますが、これを使う場合にはICP3.1.2が必要になります。
    ICP3.1.2のインストールもMultiCloud Managerのインストールも試していませんが、MultiCloud ManagerのKulusterletについては 提供時のファイル名が大きく変わっていましたので、手順の再確認をする予定です。
    (現地でSEに確認する限り、方法は変わっていないようですが・・・)


インストールについては改めて弊社で検証後、記事として投稿させていただきますのでお待ちください。


IBM Knowledge Centerではすでにドキュメントが公開されています。

ICP 3.1.2の新機能
https://www.ibm.com/support/knowledgecenter/SSBS6K_3.1.2/getting_started/whats_new.html

MCM3.1.2の新機能
https://www.ibm.com/support/knowledgecenter/SSBS6K_3.1.2/mcm/getting_started/whats_new_mcm.html



以上となります。 さらっとですが、これまで どこまで対応するの?MultiCloud Manager という部分がやっと見えてきました。

トライアル等、デモ等ご要望がございましたら是非ご連絡ください。

すずきけ

2019/02/15

Lenovoのx86サーバー ThinkSystemを選択する メリットについて学んでみよう!

この記事はレノボ・エンタープライズ・ソリューションズの小宮様に寄稿いただきました。

Lenovo 社が提供する x86サーバーである、ThinkSystemの価値、選択するメリットについてのご紹介となります。


レノボ・エンタープライズ・ソリューションズ小宮です。本日はLenovoのx86サーバ―であるThinkSystemをサーバープラットフォームとして選択する理由とそのメリットについてお話したいと思います。最近LenovoではNutanixおよびVMware/Microsoftなどのソリューションに対応した認定ハードウェアをリリースしています。そのため、コモディティ化されているハードウェアの中で、ThinkSystemがいかに価値があるものなのかを理解し、お客様に選定して頂くことための内容をご説明したいと思います。

 

  1. Lenovoのサーバーとは?

LenovoというとPCのメーカーというイメージがありますが、実は2014年10月にIBM社からx86サーバー事業をLenovoに売却されて、そのDNAを引き継いで事業を続けています。そのため、LenovoがIBMから事業譲渡する前にThinkServerというブランドを持っていましたが、IBMから事業譲渡された旧System xが統合されて、現在はThinkSystemという統一ブランドに一つにラインナップ化されています。

IBM社からの事業譲渡前は、IBM社のホストコンピュータで培った技術をいかにして、x86サーバーに取り込むことにより稼働率・品質向上につなげることをイノベーションとして取り込んできました。その内容について触れていきたいと思います。(ThinkSystemはLenovoの技術というより、旧IBM社の技術が詰まっているサーバーです)

Les01

構成製品のメインであるThinkSystemのサーバー、SR, ST, SD, SNシリーズのメリットについてご説明します

ThinkSystemは、タワー型、ラック型、高密度型、ブレード型からハイエンドサーバーといわれるミッションクリティカルな用途に対応できる幅広い製品を、ラインナップしています。

ThinkSystemサーバーのメリットは大きくわけて3点あります

1.管理負担の軽減

  長年の設計ノウハウによる高い信頼性と、管理プロセッサー(XCC XClarity Controller)により管理負担を軽減します

2.投資対効果の追及

  ラックの1U,2Uサーバーのポートフォリオを3倍に拡大、合わせて保守アップグレードサービスの選択肢を増やすことで必要なだけ投資することができ、投資対効果の向上を訴求することができます

3.俊敏性と時間短縮

  Light PathやPPA(Proactive Platform Alert)により、不具合による計画外停止などを少なくし、部品の共通化により保守時間短縮や保守容易性を実現します

  1. ThinkSystemの信頼性について

Les02

信頼性についてもう少し深く掘り下げてご説明したいと思います。

こちらの資料はITICにて発表されている2017年から2018年の一年間に世界中の企業の750名を超えるCIOおよびIT管理者の信頼性における調査をお客様にした結果になっています。この調査において計画外ダウンタイム(IT管理者が想定していない停止時間)が4時間以上経験しているかどうかの調査結果で、LenovoのSystem x(ThinkSystemも含む)で約1%の数値をたたき出しています。これはほぼメイン・フレームに近い稼働率の数値になっており、コモディティ化されているサーバーおいて、なぜこれだけの差がついてしまうのか?

それは、旧IBMからのテクノロジーがこの数値を支えており、これらが実現しているからこそ、ファイブナイン(99.999%)の稼働率を実現しています。同じようなスペックで他社製品と比べた時に、製品として信頼性あるものを選ぶことも重要なファクターであると思います。

  1. ThinkSystemのパフォーマンスについて

Les03

こちらは世界記録叩き出しているベンチマークの数になります。コモディティ化されているサーバーならば本来どのメーカーを選んでもパフォーマンスは変わらないはずですが、サーバーの開発段階からIntel社などの主要メーカーと緊密な協力体制のもとで製品化に取り組んでいることから、主要サーバー・ベンダーに中でもパフォーマンスが良いものを提供しています。この中には仮想化のベンチマーク、SAPなどのSAP値などの主要なアプリケーション環境でも最適パフォーマンスが出せるものになっています。現在は30もの世界記録のベンチマークがあります。

信頼性の時と同様に、パフォーマンスが良いものを購入時に選択することも一つの差別化につながります。

  1. ThinkSystemの高信頼性をもたらしているもの

Les04

高信頼性をもたらしているもの、それはこの2つのテクノロジーです。

・プロアクティブ・プラットフォーム・アラート

  • CPU・HDD・SSD・ファン・メモリー・電源ユニットなどの障害を可能な範囲で事前に検出し、通知する機能がプロアクティブ・プラットフォーム・アラートです。
    この障害検知の仕組みについてはメイン・フレームの運用から培った技術の結晶であり、稼働率向上に向けた仕組みとなっています。
  • XClarity Integratorと連携することでシステムの停止なく、仮想OSを安全に退避することができます。

・Light Path診断テクノロジー

  • サーバーの停止時間を最小化するために、ThinkSystemではLight path診断テクノロジーを使用しています。
  • LEDが点灯することでメモリーやファンなどの障害部位を容易に特定できます。障害発生時の保守作業の時間を大幅に削減することができます。

 

例えばデーターセンターでメモリ不良でサーバーが立ち上がらなくなった際に、(他のベンダーのサーバーでは)メモリモジュールが多く故障モジュールが判断つかないケースがあります。不良のメモリーモジュールを探し当てる際にメモリの差し替えを行うなどして、故障モジュールを特定するのに数時間要することがあります。

その時に、Light Path診断テクノロジーがあれば、瞬時に故障モジュールの特定も可能でサポート対応も迅速に行うことができ、顧客満足度向上につながります。

  1. 強固なセキュリティを実現するThinkSystem

Les05

2014年にIBM社からLenovoにサーバー事業の譲渡を行う際に、IBM社からLenovoに対して引き継がれた内容として、事業譲渡後も同様のセキュリティ体制(およびセキュリティレベル)を維持することになっています。そのため、製品化する際に最高のセキュリティ基準を意識して開発を行っています。

ThinkSystem サーバーのセキュリティ対応は、①ハードウェアとしての対応と、②ファームウェア開発プロセスの2つの面で対応しています

①ハードウェアとしての対応

ThinkSystemサーバーは全モデルにおいてセキュリティ対応としてTPMチップを搭載しています。

このTPMチップを使うことで、署名付きファームウェアの適用しかしないとか、ブート対象のファームウェアに改ざんがあったかを判断することができ、万一改ざんが発見された場合は、別に保存してある正しいファームウェア―で上書き(ロールバック)して、ブートすることができます。

②ファームウェア開発プロセス

また、サーバーのファームウェアの開発、リリース、適用の全体に渡り、セキュリティ管理プロセスを導入しています。

ファームウェアのリリース前のコードの厳格なテストや、デジタル署名付きでファームウェアをリリースし、ThinkSystemに搭載されたセキュリティチップにより、信頼されるファームウェアのみしかサーバーに適用できない仕組みを構築しています。

また、開発に関連する社員のセキュリティ教育にも力を入れています。

  1. 顧客満足度向上させるサポート(コールホーム機能)

Les06

サーバーのハードウェアに障害が発生した際に、IT管理者が障害に気が付いてからサポートセンター連絡するようなケースでは、障害対応を遅れてしまいます。

万が一、障害が起きた場合にユーザー様のご負担を減らすことができるのが、障害自動通報(コールホーム機能)です。

コールホームを使わないケースでは、不具合が起きたことをエンドのユーザー様が検知した後、Lenovoのサポートセンターにご連絡いただいてから修理作業に入ります。

コールホームを利用いただいている場合は、障害起きた時点で、Lenovoのサポートセンターに自動的に通報され、Lenovoサポートセンターよりよりお客様にご連絡をいたします。

さらに、自動通報時に障害が起きたサーバーのログ(構成情報、障害ログ)も自動で送付されますので、お客様側でログ取得等の手間を省くこともできます。

こちらのサポート内容はすでに一部のサーバー・ベンダーでは同様レベルの内容を提供できておりますが、コールホーム機能については旧IBM社からの機能をそのままLenovoに事業譲渡した後も引き続きご利用可能になっております。

  1. XClarityによるシステム導入後のファームウェア管理と統合管理

Les07

XClarityはレノボエンタープライズ製品を管理するための統合管理ソフトウェアです。ライフサイクルをカバーする先進機能を搭載しながら、業界標準のRedfishの採用により上位管理層との連携とオープンな管理性を提供します。

XClarityにはライフマネージメント機能の他、統合管理ツールとしての多くのメリットがあります。

画面左側は一般的に「システム管理体系」で要求される内容、画面右側はそれに対応したレノボのシステム管理製品XClarityの機能名です。

特に赤字の部分は、今回新しく名称変更、機能アップされた名称です。

例えば、従来のUEFIはXClarity Provisioning Mangaer、IMMはXClarity Controller、ToolsCenterはXClarity Essentialとなっています。

 

XClarityについては、今後のブログにて詳細のご説明致します。

 

今後ともよろしくお願い致します。

 


今回は小宮様に Lenovo ThinkSystemを採用する理由、メリットについて、ご紹介いただきました。

当社ネットワールドでも Lenovo ThinkSystem を取り扱っておりますので、ご興味のある方はぜひお問い合わせいただければと思います。

今後も、小宮様の Blog にどうぞご期待ください!

2019/02/13

Acropolis Hypervisorのネットワークロードバランス

本記事の原文はであるNutanix Communityに投稿されているAHVのOpen vSwitchの基本に関する記事の翻訳です。

投稿されてから時間はたっていますが、AHVを構成する際にベースとなる構成の為、改めて紹介していきます。

原文を参照したい方はNetwork Load Balancing with Acropolis Hypervisorご確認ください。

情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら

ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。

(初回はID、パスワードの取得が必要です)


763i74215f1c55a62e72_2

Acropolis Networkingの最初の記事でブリッジとbondについてお話ししました。

今回は物理ノードにおける複数のネットワークの利用方法について説明します。

771i19a614e729de5917_2


ブリッジを分けることでCVM通信は10Gbインターフェイスでルートされ、ユーザVMは10Gbか1GbのAdapterを利用してトラフィックが流れます。

OVS bond内におけるロードバランスに対する準備が出来ました。

主に考慮しないといけないのはフォールトトレランスとスループットです。

フォールトトレランスの為には上記の図のように最低でも2つのNICを利用する必要があります。

一度ボンドが2つ以上のネットワークで構成されると、一つのbondで提供されるスループットを管理できるようになります。次の全てのbondモードはフォルトトレランスを実現しています。

このビデオではAcropolis HypervisorとOpenvSwitchにおけるロードバランスの違いを説明しています。是非、nu.schoolを確認してみてくださ。

このビデオには"allssh"などbondの構成に便利なショートカットも紹介しています。


BondモードではBond内のトラフィックは複数の物理インターフェイスで分散されます。

デフォルトのモードはActive-Backupでbond内の1つのActiveリンクのみを利用し他のインターフェイスはActive Linkが落ちるまで利用されません。

BondモードとActive なインターフェイスを確認するには次のコマンドで確認できます。

nutanix@CVM$ ssh root@192.168.5.1 "ovs-appctl bond/show"

デフォルトのコンフィグのActive-Backupです、結果は次のものと近いもにになるでしょう。

---- bond0 ----
bond_mode: active-backup
bond-hash-basis: 0
updelay: 0 ms
downdelay: 0 ms
lacp_status: off

slave eth2: enabled
active slave
may_enable: true

slave eth3: enabled
may_enable: true

Active-Backup

Active-Backup bond モードはシンプルで簡単に上位スイッチに追加の設定なしに接続できる方法です。

サーバ側の全てのVMのトラフィックはBond内の一つActiveなリンクだけを使います。。

全てのBackup linkは利用されないままです。

10Gbの2つのインターフェイスがある場合、最大のスループットは全ての仮想マシンで10Gbpsとなります。

772i377649a697233636_2


Active-backupモードはデフォルトで有効ですが、AHVで次のコマンドを実行し構成する事も出来ます。

nutanix@CVM$ ssh root@192.168.5.1 "ovs-vsctl set port bond0 bond_mode=active-backup"


Balance-slb

複数の上位スイッチのリンクの利用により帯域幅を有効活用できます。

私たちはこのbalance-slbのモードの利用を推奨します。

このOVSのbalance-slb モードはBond内の全てのリンクを利用し、トラフィックを測定して仮想マシンをトラフィックの多いインターフェイスから少ないインターフェイスに移動させ、bondのリバランス期間が過ぎると、OVSはトラフィックを測定しソースMACハッシュに基づいてトラフィックを分散します。

ソースMACからのトラフィックはBondの利用率を均等にする為、トラフィックの低いインターフェイスへ移動するかもしれません。完全にバランスが取れた状態が常に可能という事ではありません。

ここの仮想マシンのNICはbondの中の一つのインターフェイスを利用します。複数の仮想マシンNICを持つトラフィックはハッシュアルゴリズムに基づきインターフェイス間で分散されます。

結果的にはAHVが10Gbpsのインターフェイスを2つ持っている場合は、AHVは20Gbpsのスループットを利用できるが、VMは10Gbpsのスループットの利用となります。


デフォルトのリバランス間隔は10秒ですが、ソースMACアドレスハッシュの過度は移動を避けるために60秒にする事を推奨しています。

(現在のKBでは60->30となっています。)

私たちはこの構成を2つの上位スイッチとAcropolis Hypervisorで確認しています。

追加のスイッチの構成無しに、スイッチとの相互接続さえ出来ていれば利用可能です。


balance-slbは全てのCluser内の全てのAHVノードで次の通り実行する事で設定可能です。


nutanix@CVM$ ssh root@192.168.5.1 "ovs-vsctl set port bond0 bond_mode=balance-slb"

nutanix@CVM$ ssh root@192.168.5.1 "ovs-vsctl set port bond0 other_config:bond-rebalance-interval=60000"

ー>現在はbond-revalance-interval=30000

設定の確認は次のコマンドで可能です。
nutanix@CVM$ ssh root@192.168.5.1 "ovs-appctl bond/show bond0"
---- bond0 ----
bond_mode: balance-slb
bond-hash-basis: 0
updelay: 0 ms
downdelay: 0 ms
next rebalance: 59108 ms
lacp_status: off

slave eth2: enabled
may_enable: true
hash 120: 138065 kB load
hash 182: 20 kB load

slave eth3: enabled
active slave
may_enable: true
hash 27: 0 kB load
hash 31: 20 kB load
hash 104: 1802 kB load
hash 206: 20 kB load


LACP and Link Aggregation

この構成をする場合は十分に検証を行ってください。

それはLACP,balance-tcpは上位のスイッチの構成が必要であり、AHVのノードがスイッチの設定がされていないポートに接続されるとネットワーク接続が無効になるかもしれないからです。

しかし、一つのVMから複数のリンクで構成される上位スイッチに対して最大の帯域幅を利用できることになります。OVSのlink aggregationはLACPとbalance-tcpが必要です。

LACPにより複数リンクの別々の物理スイッチは一つのL2リンクとして表示されます。

トラフィックはトラフィックハッシュアルゴリズムを基にactive-activeに分散んされ、スイッチのマックアドレステーブルに関係なくlinkのメンバーで分散します。

これはuplinkが一つのL2リンクとして表示されるからです。

Link Aggregation , LACP , balance-tcpによりAHVのノードが2つの10Gbpsアダプタを搭載している場合は、一つのVMで20Gbpsの帯域を利用できます。

774iaa103d96e3c9d67d_2

LACP,balance-tcpには次のコマンドを実行します。

また上位スイッチではLACPが必要です。



nutanix@CVM$ ssh root@192.168.5.1 "ovs-vsctl set port bond0 lacp=active"

nutanix@CVM$ ssh root@192.168.5.1 "ovs-vsctl set port bond0 bond_mode=balance-tcp"

上位とのLACPネゴシエーションに失敗した場合、デフォルトではbondを無効にしすべてのトラフィックをブロックします。

次のコマンドでLACPのネゴシエーション失敗時、Active-backupへの切り戻しを実施できるようになります。
(こちらの設定を実施時はスイッチ側の設定をこちらのKBに従って設定、確認をしましょう)

nutanix@CVM$ ssh root@192.168.5.1 "ovs-vsctl set port bond0 other_config:lacp-fallback-ab=true"

Finding the right balance

お客様の仮想化環境要件に合わせて最適なbondモードを選択しましょう。

本記事では簡単な方法から難しい方法までを載せています。

10Gbpsを2つでbondを構成すると以下の通りです。

Active-backup - AHV , VM共に一つのActive-NIC (Switch 設定不要)

balance-slb    -  AHV 20Gbps , VM 10Gbps ( Switch 設定不要)

balance-tcp    -  AHV , VM 20Gbps  ( Switch 設定必要)

記事担当者 : SI技術本部 カッシー @Networld_NTNX

アクセスランキング

お問い合わせ先
ネットワールド ブログ運営事務局
blog.doc-info@networld.co.jp
フォトアルバム