アクセスランキング

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

« 2019年1月 | メイン | 2019年3月 »

2019年2月

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

2019/02/06

最大のパフォーマンスをAHVとOpen vSwitchから

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

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

原文を参照したい方はMaximum Performance from Acropolis Hypervisor and Open vSwitchご確認ください。

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

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

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

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


763i74215f1c55a62e72

Nutanixではデータネットワークをストレージのバックプレーンとして利用し、次の事がお客様がAHVを利用する上でAHVがデータセンターネットワークに接続するための良い方法なのかを決められる事を目的としています。

いくつかのバックグランドから始めましょう。AHVはOpen vSwitch(OVS)はCVM、HypervisorとゲストVM、物理ネットワークが接続されています。

OVS のサービスは各AHVノードで稼働し、OVSのサービスは自動的に起動します。

このブログはAHVの一部の内容であり、Open vSwitch BridgeとBondsの内容を包括しています。

来週のパートではロードバランス、VLANとAcropolisの管理ネットワークに触れていきますので、是非来週もご覧ください(できれば翻訳しようと考えてます)

OVS内の、bondのポートはAHVホストの物理インターフェイルにありデフォルトではbond0と名前がづけられbr0が作成されます。

(現在の最新のAOS 5.10ではボンド名はbr0-up , Bridge名はbr0となりますのでご注意ください)

ノードのイメージング(初期化)が完了したとは全てのインターフェスは一つのbondへ設定されます。これはFoundation Imagingプロセスの要件となります。

次のダイアグラムはイメージング直後の1ノードのネットワーク構成となります。

763i74215f1c55a62e72_2

次にnu.schoolのVideo(youtube動画)でデフォルトの構成についてもっと多くの事を学ぶとことが出来ます。デフォルトの設定を変更するためのコマンドやacli,cli toolについてのいくつか参考になるものも見つけることが出来るでしょう


YouTube: Tech TopX: AHV Host Networking [Part01]

大事なポイントはNutanixのCVMは10Gbアダプタに設定する事です(今では40Gbもあります)

これで最大のBandwidthと低いレイテンシーの実現をCVMへ提供するのです。それに加えてUser VMによって物理トラフィックを分けたいと思う事もあるかも知れません。

このネットワークを分離する事はセキュリティポリシー、仮想マシンのネットワーク(例えばルーティング、FireWall,ロードバランス)などによって必要になるかもしれません。

これはAHV OVS構成の推奨で1GbのNICを使った新しいブリッジの作成です。

764id82d1e145f720178

推奨の構成は10Gと1Gのインターフェイスを別々のBondへ構成し、CVMとUserVM通信は常に最速のLinkを使います。

ここでは10G(eth2, eth3)はbond0(br0-up)へグループし、CVMとUser VM1 へ

1GのインターフェイスはBond1へグループしUser VM2で利用します。

bond0とbond1はそれぞれブリッジ (br0 , br1)へ追加します。

この構成ではCVMとUser VMは10Gbのインターフェイスを利用し ブリッジ br1はCVMとbr0にいるVMから物理的にネットワークを分ける必要がある仮想マシンの為に利用できるようになります。

Eth0 , Eth1はさらに別のアップリンクのスイッチへ接続して分離する事も出来ます。

2つの上位スイッチはそれぞれのbondのインターフェイスのペアが接続し、bondの中では一つのインターフェイスがアクティブとして動作します。これはデフォルトのActive-Backup モードを利用した際の動作です。

ロードバランスについては次週に記載します。

Nutanix Clusterの各ノードで次を実施し、各Acropolis hostでブリッジbr1を追加、ローカルのAcropolis Hypervisor へはCVMから192.168.5.1 に対して接続できます。

CVMへログインしブリッジ br1を作成】

nutanix@CVM$ ssh root@192.168.5.1 "ovs-vsctl add-br br1"

CVMからeth0 , eth1 をすべてのCVMのデフォルトのbr0から削除します。

これらのインターフェイスはeth2 , eth3をBridgeに残して削除されます。「10g」は全ての10g インターフェイスを指定する事になります。(もちろんeth2,eth3のようなインターフェイス指定も可能です)

【br0へ10Gのみを追加する場合]

nutanix@CVM$ manage_ovs --bridge_name br0 --bond_name bond0 --interfaces 10g update_uplinks

ー>現在のデフォルトの--bond_nameはbr0-upとなります

【br0へeth2,eth3のみを追加する場合]

nutanix@CVM$ manage_ovs --bridge_name br0 --bond_name bond0 --interfaces eth2,eth3 update_uplinks

ー>現在のデフォルトの--bond_nameはbr0-upとなります

eth0とeth1をbr1へ追加する方法、「1g」のインターフェイス指定をすることも可能です

【br0へ1Gのを追加する場合]

nutanix@CVM$ manage_ovs --bridge_name br1 --bond_name bond1 --interfaces 1g update_uplinks

今や、1gbのインターフェイスが存在するbr1が存在しています。

aCLIコマンでUser VM2の為のネットワークを作ることができます。

PrismのGUIからネットワークを確認する際にブリッジ名とネットワーク名は役に立つのでここは名前を解りやすくしましょう

[cvmからbri1へvlan 99を作成、登録するコマンド]

nutanix@cvm$ acli net.create br1_vlan99 vswitch_name=br1 vlan=99

これで一つのAHVとCVMが10Gを通して接続する事が出来るようになり、User VMは10G か1Gかに接続する事が出来るようになりした。上にのせているyoutubeも参考になるので、ご参照ください。

 

ここでさらに便利なコマンドをご紹介!

ブリッジの作成などは全てのCVMに対して実施する必要がありますが、Nutanix Cluster全体のCVMはAHVへコマンドを投げることも出来ます。

全てのCVMへCLIを実施するには allssh、全てのAHVでCLIを実施するにはhostsshです。

この辺りをうまく利用しAHVの管理性を高めてみてはいかがでしょうか

Screenshot_14

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

2019/02/01

IBM Cloud Private 3.1.1 AD連携機能を試してみる

みなさん、こんにちは。

今回はユーザー連携部分のお話です。
当然、この手の製品の管理コンソールですとユーザーの作成はローカルとLDAPと連携する方法があり、ICPも同様です。

LDAP連携機能では、多くの皆さんが使われているであろう Microsoft Active Directory との連携も対応していますので、ちょっとセットアップしてみたいと思います。



環境

ICP環境は前回、前々回などと同じ環境です。
- ICP Master server 1台
- ICP Worker server 1台

今回はActive Directoryと連携するので、下記のActive Directoryを用意しています。


AD 環境

20190131_14h28_03_2


Active Directory ユーザーとコンピューター の画面はこのようになっています。

20190129_17h32_37



今回のゴール

下記のことができるように確認します。

  1. OU=icp のユーザーが ICPのユーザーとして登録できること
  2. ADのセキュリティグループ icpgroup に所属しているユーザーでログインができること
  3. 登録したユーザーには特定のリソースしか表示、利用できないこと


ADを登録

ICPでのLDAPの登録は管理コンソールからできます。

管理コンソールにログインして、

20190129_17h36_35


メニューの[管理]-[IDおよびアクセス]に移動します。

20190129_17h36_45


接続の作成をクリックします。

20190129_17h37_07a


下記の内容を参考に設定します。
LDAP認証の部分は Distinguished Name(DN) で書く必要があります。

20190131_14h28_15


20190129_18h00_45s


DNがわからないという方は、下記のようにコマンドプロンプトから確認したユーザーを入れてみてください。

20190129_18h24_06


入力後、接続の確認をして、保存します。


チームの登録

次にチームを登録します。
チームに対して、AD上のユーザーやセキュリティグループを割り当てたり、利用可能なリソースの割り当てを行います。

メニューの[管理]-[IDおよびアクセス]-[チーム]に移動します。
チームの作成をクリックします。

20190129_18h25_20


ポップアップウインドウで下記を参考に入力します。

20190131_14h28_25


20190130_10h49_32


作成をクリックします。
チームが登録されることが確認できます。


チームに登録されているセキュリティグループの確認

さきほどのチーム登録時に指定したセキュリティグループicpgroupが登録されていることと、グループに登録されているユーザーもICP上で確認可能か見てみます。

管理コンソールで作成したチーム名をクリックします。
今回であれば、icp-teamです。

20190129_18h49_14


チームに登録されているグループの一覧が表示されます。
まだ1グループしか登録していないので、icpgroupのみが登録されています。
icpgroupをクリックします。

20190129_18h50_51


icpgroupに所属しているユーザーの一覧が表示されます。

20190130_10h52_36



セキュリティグループに登録されているユーザーのログイン確認

セキュリティグループに登録されているユーザーもICP上で確認できましたので、そのユーザーでICP管理コンソールにログインできるか試してみます。

今開いている管理コンソールをログオフするか、別の種類のWebブラウザまたはシークレットモードで起動したWebブラウザを起動します。
※あとの工程上、ログオフせずに別のWebブラウザまたはシークレットモードのWebブラウザのほうが都合がよいです。

ログイン画面で先ほど確認したセキュリティグループに登録されているユーザーでログインします。
今回は user2 を利用します。

20190130_10h53_32


ログインでエラーがでることもなく、管理画面のようこそ画面が表示されることが確認できます。

20190130_10h57_13



チームにADユーザーを個別に登録

次に、作成済みのチームicp-teamにADユーザーを個別に登録してみます。

ICP管理コンソールを開き、adminでログインします。
メニューの[管理]-[IDおよびアクセス]-[チーム]に移動します。
その後、icp-teamに移動し、ユーザータブを表示します。
ユーザーの追加をクリックします。

20190130_10h57_45


下記を参考にユーザーを検索します。

20190131_14h30_18


検索結果が表示されていますので、今回はuser3を選択します。
このユーザーはセキュリティグループicp-teamには登録されていないユーザーです。
役割のカラムで役割をドロップダウンリストから選択できます。今回は管理者のまま、追加をクリックします。

20190130_10h58_27


ユーザーの一覧画面が表示され、ユーザー登録が完了していることが確認できます。


登録したユーザーでログインしてみる

登録したユーザーでICP管理コンソールにログインできるか確認してみます。

今開いている管理コンソールをログオフするか、別の種類のWebブラウザまたはシークレットモードで起動したWebブラウザを起動します。
※あとの工程上、ログオフせずに別のWebブラウザまたはシークレットモードのWebブラウザのほうが都合がよいです。

先ほど登録したuser3でログインします。

20190130_11h38_54


ログインでエラーがでることもなく、管理画面のようこそ画面が表示されることが確認できます。

20190130_11h39_08



リソースを見てみる

せっかくなので、user3で操作できるリソースを見てみます。

20190130_15h20_23


名前空間(name space)が割り当てられていないので操作ができません。
チームに対してリソースの割り当てを行います。


管理者アカウントでICP管理コンソールにログインし、メニューの[管理]-[IDおよびアクセス]-[チーム]に移動します。
その後、icp-teamに移動し、リソースタブを表示します。
リソースの管理をクリックします。

20190131_11h48_10


リソースの管理画面が表示されます。 今回は defaultibm-chartsにチェックを付け、保存します。

20190131_11h49_33

20190131_11h58_36


再度、user3でICP管理コンソールにログインします。
メニューの[ワークロード]-[デプロイメント]を開きます。

20190131_13h46_04


先ほどとは違い、エラーは表示されません。
実際にリソースが利用できるか確認してみます。
管理コンソール右上のカタログをクリックします。

20190131_13h46_04_2


検索画面に liberty と入力し、表示された結果から ibm-open-liberty を選択します。

20190131_13h46_36


構成をクリックし、下記のパラメーターを入力します。

20190131_14h28_58


記載のない設定は変更せず、インストール をクリックします。

20190131_13h55_14


Helmリリースの表示を開き、少し時間をあけてステータスを確認します。
デプロイメントのステータスの使用可能1になっており、ポッドのステータスもRunningになっていることが確認できました。

20190131_13h56_56


20190131_13h57_10


先ほどのHelmカタログからデプロイする際のターゲット名前空間のドロップリストはDefaultだけになっていましたので、user3ではdefault以外の名前空間のリソースに対しての権限を持っていないことも確認できました。




以上がAD連携の連携後の簡単な動作確認の方法でした。

NameSpace(名前空間)ごとに割り当てチームを決めることで、別のチームのNameSpaceへの影響も抑えられますし、そもそもユーザー管理をICP上でコツコツやるのは大変!という要望にもこたえられるかと思いますのでぜひ試してみてください。

現状の挙動として、ちゃんとAD上に存在していて、ICP上のチームに登録されているセキュリティグループにも所属しているADユーザーでもログインできない場合は、一度ICP上のADの登録画面で対象のADを編集で開き、再度保存してみてください。



今回も長々とありがとうございました。

すずきけ