Home > Blogs > Japan Cloud Infrastructure Blog > 作成者別アーカイブ: Eri Teshima

作成者別アーカイブ: Eri Teshima

VMware Cloud Foundation でハイブリッドクラウドへ踏み出そう

Part3: 理想のSDDC環境をツールで一気にセットアップ!

ー Back Number ー

#1 「VMware Cloud Foundation (VCF) 」 をご存知ですか

#2    VCFはどんなお客様向けの製品?

#3   自動セットアップの方法とは?

#4   VCFはHPE Synergy との連携に優れている

 

日本ヒューレット・パッカード(HPE)で仮想化やハイブリッドクラウドソリューションなどのプリセールスをしている片山倫哉(かたやまともや)です。

 

連載第3回は、VCF(VMware Cloud Foundation)のセットアップ方法についてご紹介いたします。

 

前回の連載では、VCFは VMware社の理想形で構築され、さらに構築が早い!”ことをお伝えしました。では、 VCFのセットアップは実際に「どのような流れで進めていくのか」「本当に構築が早いのか??」、またSDDC(Software-Defined Datacenter)インフラを構築するにあたり、“VCFアリ”と “VCFナシ”では、どれくらい作業内容に差があるか見ていきましょう。

 

◆スクラッチでのセットアップと、専用ツールでのセットアップ◆

◇スクラッチで1個1個セットアップ◇

ホストごとに設定画面を開き、細かい部分まで手作業で設定していくという大事ではあるけれど、時間がかかって辛い仕事―――。

これらの作業を手動で実施すると1週間以上かかっていたなんてこともありますよね?

また、集中力が切れてしまい「途中1台だけミスをしまう」ことや、そのミスに気づかずに1台だけ設定が異なってしまうことで、隠れた癌のように後々カットオーバー後に性能や安定性に影響を及ぼしてしまうリスクもあります。

◇専用ツール◇

では、VCFだとどうでしょう?

VCFには専用のセットアップツールが付属しています。用意されたパラメーターシートにホスト名、IPアドレス、ライセンスキーなどを入力し、セットアップVM(Cloud Builder VMといいます)にブラウザからアップロードするだけで、各種SDDCコンポーネント(ESXivCenterNSXvSANvRealize:オプション)がVMware社の理想とする“完璧な状態”で出来上がります!

作業時間はもとより、「設計ミス」「構築ミス」から解放されます!

◇パラメーターシートの入手◇

VCFのセットアップはパラメーターシートの入手から始まります。私は前職SIerで勤務していたのでよくわかりますが、パラメーターシートというと会社ごとに書式が決まっていたり、パッと見て分かりづらいものも多かったりするのが実情ですよね。

しかし、VMware社が専用のパラメーターシートを用意してくれています!!

こういったところもVMware社は利用者(構築者)目線だと思いませんか。

 

入手方法ですが、MyVMwareにログインをして「Cloud Builder Deployment Guide」(Excel形式)をダウンロードすることができます(※)。

ファイル名:vcf-ems-deployment-parameter_VCF3.X.X.xlsx

※本稿執筆時の最新バージョンである「バージョン3.7.1」の場合、次のURLからアクセス可能です。

https://my.vmware.com/jp/group/vmware/details?downloadGroup=VCF371&productId=865

 

◇パラメーターシートの記入◇

Excelでパラメーターシートを開くと、視覚的にわかりやすいレイアウトになっていることが分かります。タブがいくつか用意されていますが、サンプルとして既にIPアドレスが入力されていますので、お客様環境に合わせた内容に調整するだけです。

 

 

◇パラメーターシートをセットアップVMにアップロード◇

 

ブラウザ(Chormeなど)から https://<CloudBuilderVM IP >:8008/  へアクセスします(注)。

「UPLOAD」ボタンをクリックし、作成したパラメーターシートをアップロードしてください。

 

(注)アクセスするアドレスはバージョンにより変わります。該当するバージョンのドキュメントをご確認ください。

◇セットアップ前の不安も払拭!自動構成チェック◇

 

実機でセットアップする際は、私自身もここで不安になりました。

それは「自分が記入したパラメーターシートに内容に誤りがないか」です。入念にチェックをしても、どうしても心配になるかと思います。

しかし、安心してください!

パラメーターシートをアップロードすると、内容に矛盾がないか、誤りがないかを確認してくれます。作業者の不安まで払拭してくれるため心強いですね。

 

 

Configuration File Validation

      ※ESXi、vCenter、NSX、vSAN、vRealize 1つ1つのパラメーターチェック

 

もちろん、問題があればきちんとエラーを表示してくれます。

また、パラメーターシートに記入した「値」のチェックだけではありません。ネットワークの疎通チェックや、ESXiハイパーバイザーが正しくセットアップしているかもチェックしてくれます。

 

※次の例では意図的にESXi側でSSH接続を無効にし、SSH接続できない状態にしてエラーを表示させました。

 

◇自動セットアップの開始(Bringing Up)◇

各SDDCコンポ―ネントのセットアップ作業は「Bringing Up」と呼ばれます。視覚的に現在進行中の作業がわかる画面デザインになっています。

◇自動セットアップの完了!◇

 

約2時間待つだけ で全てのセットアップが完了します。

無事セットアップに成功すると、緑色の枠内に待ちに待った “VMware SDDC Manager”のアクセスURLが表示されます。

 

さっそくアクセスしてみましょう!

次のスクリーンショットはVMware SDDC Managerのログイン直後の画面です。

 

◇これがVMware社理想の状態!!◇

 

「VMware社の理想」と繰り返しお伝えしましたので、それがどのような状態か気になっている方も多いかと思います。みなさまお馴染みのvCenter Server(vSphere Client)の画面も用意してみました。さすがにフルスタックというだけあって、たくさんの管理系の仮想マシンが並んでいます。リソースプールも使われていますね。

vSAN の構成ももちろんバッチリです!

ここまでで、基本的なVCFのセットアップ作業は完了です。VMware理想の設計でインフラが組まれました。

 

ESXi、vCenter、NSX、vSAN、vRealizeと、それぞれ技術書籍一冊ずつ書けてしまうものが、そのセットアップをたった1回のブログ記事で書けてしまいました。。。

この点においても、VCFのスゴさを私自身が再認識してしまったところです。

 

次回は、ここまでオンプレミス環境を中心に書いてきたVCF、クラウド適用についてご紹介します。是非ご期待ください!

 

 

片山 倫哉(かたやま ともや)

日本ヒューレット・パッカードのプリセールス部門に所属するプリセールスコンサルタント。

前職ではプログラマー、HPEでは仮想化のサポートエンジニアを経験後、プリセールス部門に転身。

技術が好きでVMware製品やMicrosoft製品の提案や、ProLiantサーバーを中心としたハイブリッドクラウドの提案などに従事。

 

タイムマシンをお持ちでない方向け仮想化基盤移行の話

皆様、はじめまして。  日本ヒューレット・パッカード(HPE)でサーバーの仕事をしています齋藤豪(さいとうごう)と申します。

突然ですが、皆様の環境には仮想化基盤はありますでしょうか。そのシステムは何年前に入れたものですか?と言うのも、古いものだとそろそろバージョンアップを考えないと不要なリスクを負うことになってしまうんですよ。

 

環境を塩漬けにしていませんか? vSphere 5.5のEOGS(End Of General Support)

例えばお使いの環境がVMware vSphere 5.5の場合、General Supportが終了し、既にセキュリティリスクが発生していると言うことができます(General Supportが終了しているため、既にセキュリティを含むパッチは提供されません)。

でも、自分は大丈夫だと思っていませんか?近年、感染すると恐ろしい被害をもたらすマルウェアの1つが流行していますが、JPCERT/CCの調査 (2018/7/30発表)によると、調査した組織のうち、35%がLockyやWannCryなどのランサムウエアの被害を経験したと発表されています。

タイムマシンをお持ちでない限り時間は遡れません。既に今日現在はGeneral Supportが終了した“黄信号”の状況ですので、お早目の更改をご検討ください。(もしお持ちの方がいたら詳しくお話聞かせください)また、vSphere 6.0 についても2020年3月にGeneral Supportが終了し、“黄信号”に入ります。なので、寿命の長い最新のvSphere 6.7へのアップデートが激しくオススメなのですが、古いサーバーだと最新のvSphereバージョンがサポートされていない場合もあります。

 

環境を塩漬けにしていませんか?(Gen8サーバの保守期限が近付いています)

今ご利用のサーバはどの世代でしょうか?

ご購入時期が2012年9月~2015年頃の場合、HPEで言うとGen8世代のサーバー(Intel Xeon E5-2600v1、v2を搭載のもの)に該当するかと思います。販売終了から5年を迎え、一般的に機器の老朽化による故障も心配ですし、保守契約が終了してしまった機器の場合はパーツ交換ができないことも考えられます。

また保守が受けられないということは、サーバに同梱されているファームウエアの改良版の提供も受けられないということになります。2018年最初には、大規模セキュリティインシデントとなった「Meltdown」 と 「Spectre」という、近年発売されたほとんどのプロセッサにおいて深刻なセキュリティホールが存在するというニュースが流れましたが覚えておられるでしょうか?ほぼすべてのデスクトップOSとモバイルOSの搭載端末に影響を与える大問題で、対策にはファームウエアのアップデートが必要になります。このような場合でも、保守切れのサーバには対策されたファームウエアがリリースされません。

安心して日々の業務を行って頂くために、またご自身のお客様のために、vSphere 6.7へのアップグレードと共に、新しいサーバーへの移行もご検討ください。

 

HPEのサーバーなら結構安心

リプレース先としては、HPEのサーバーがすごくオススメです。

リプレース先としては、HPEのサーバーがすごくオススメです。(2回目)

x86サーバーはご多分に漏れず、最新モデルの性能は結構あがっていますので、そもそもの集約効率や費用対効果の向上が見込めます。

それだけではなく、HPEサーバーならではの充実したセキュリティ機能があります。

サイバーセキュリティに関する怖いニュースが後を絶ちません。攻撃者の狙い目がネットワークからサーバーにも及び始めていることから、HPEの最新サーバーは全てファームウェアレベルでの改ざん検知・復旧機能を持っています。しかも標準搭載。無償です。

 

vSphere 6.7への移行と、どうせならもう少し楽でイケてるインフラを

肝心な移行方法につきましては、お客様環境にもよるので一概には言えませんが、HPEでも移行のお手伝いをさせて頂くことが可能です。こちらについては、後述のウェビナーでもご紹介予定です。

ここで、仮想化基盤の更改と合わせてご検討頂きたいインフラ技術についても少しご紹介します。

ストレージ専用装置はもちろん優秀ですが、コストや求められるスキルの専門性から負担になっているケースも多く見受けられます。そこで普及が進んでいるのがSDS(ソフトウェアデファインドストレージ)を用いたHCI(ハイパーコンバージドインフラ)です。めっちゃ横文字。。要はサーバーの内蔵ディスクを共有ストレージとして使う技術がかなり充実してきたというお話で、VMware vSANであればいつも仮想化環境でお使いの管理画面からストレージの管理も行えます。

そしてもちろん、HPEサーバーはお客様のシステム規模やご要件に応じて最適なものをご提案させて頂きます。コスト重視環境ならばAMD EPYC プロセッサ搭載のProLiant DL325、小~中規模環境ならProLiant DL380、サーバー数が4台以上になるような基盤や外部ストレージとの併用、仮想化しきれない環境も混在する場合はHPE Synergyがおすすめです。

単に従来型のサーバー・ネットワーク・ストレージ構成(3-Tier)をHCI 化するだけでなく、ネットワーク仮想化であるVMware NSX Data Centerや、運用監視のためのVMware vRealize製品群も取り入れたSDDC (Software-Defined Datacenter)をご希望であれば「VMware Cloud Foundation (VCF)」を検討することをお勧めします。VCFであれば、VMware Cloud on AWS に代表されるようなVMwareベースのクラウドとのハイブリッドクラウドも実現可能です。詳しくは弊社の片山の投稿を是非ご覧ください。

VMware Cloud Foundation でハイブリッドクラウドへ踏み出そう

 

ウェビナーのご案内

少々長くなりましたが、VMwareさんとHPEで共同開催するウェビナーでより詳しく解説します。

vSphere 5.5のジェネラルサポート終

今だから知りたいVMware最新情報と移行の勘

日時: 2019年06月 04日 (火)11:00 -11:45

以下のリンクよりお申込みください!

https://event.on24.com/wcc/r/1991399/6CB64B78C708EF56A0C80F5AB5C14847?partnerref=VMBlog

齋藤豪(さいとう ごう)

日本ヒューレット・パッカードのプリセールス部門に所属。HPE入社以来金融業界のお客様を担当し、現在はコンポーザブルインフラ、ハイパーコンバージドインフラの提案、ビジネス開発活動に従事。好きな音楽はMYTH&ROID。

VMware Cloud Foundation でハイブリッドクラウドへ踏み出そう

Part2: VCFのメリット

ー Back Number ー

#1 「VMware Cloud Foundation (VCF) 」 をご存知ですか

#2    VCFはどんなお客様向けの製品?

#3   自動セットアップの方法とは?

#4   VCFはHPE Synergy との連携に優れている

 

こんにちは。日本ヒューレット・パッカード(HPE)で仮想化やハイブリッドクラウドソリューションなどのプリセールスをしている片山倫哉(かたやまともや)です。

 

連載第2回は、VCF(VMware Cloud Foundation)はどのようなお客様向けの製品なのかをご説明します。

 

今回お伝えしたことは、大きく3つです!

 

  1. VMware開発者の理想形が手に入る
  2. SIerさんも嬉しい
  3. 運用中も理想形のまま維持される

 

◆ 1. VMware開発者の理想形が手に入る ◆

 

連載第1回では、VCFはハイブリッドクラウドを実現するための製品であることやVMware CloudTM on AWS も実はVCFをベースとした共通技術(アーキテクチャー)で動いていることをお伝えしました。

共通技術で稼動するシステムがプライベートクラウド上とパブリッククラウド上にあれば、もうおわかりですよね。

――――そうです。

それぞれがシームレスに連携可能になります。わかりやすい例を1つ挙げると、VCF環境にインターネット接続が整っていれば、プライベートクラウドとパブリッククラウドの仮想マシンが相互vMotionすることが可能になります。

では、もしVCFを導入していないVMware仮想化環境でプライベートクラウドとパブリッククラウドをシームレスに連携させるとどうなるでしょうか??

 

下記のようなコンポーネントを一から ”1つ1つ” 構築をしていくことになります。

これらを構築するとなると、様々なソフトウェアを設計し、セットアップし、設定項目も判断しなければなりません。各々は連動もするでしょうから、相互の動作テストも必要です。何十時間、場合によっては何百時間も必要な設計と構築作業―――。うんざりしてしまいますよね。

 

第1回でもお伝えしたとおり、VCFには専用のセットアップツールが付属します。

これで構築を行うとどうなるのでしょう??

 

なんと、 開発元が想定した“理想形”が復元される んです!!

 

先ほどのソフトウェア(コンポーネント)は担当者の設計・判断は必要なく、開発元であるVMware社の最も理想とする形にセットアップされます。せっかく予算化して調達したのですから、良いもの・理想的なもの・高品質なものを手に入れたいのは担当者にとって当たり前のこと。開発元の想定した“理想形”であれば不安もないですし、安心です。

◆ 2. SIer さんも嬉しい ◆

日本のIT現場では“SIerさん”も無くてはならない存在です。

ツールを用いたセットアップはお客様だけはなく、SIer様にもメリットがあります。

 

1つは誰でも構築できること。担当者は実行ボタンをクリックはしますが、実際にセットアップするのはツールの中にいる“ロボット”です。ヒトに判断を委ねることもほとんどありませんので、引っ張りだこの“スーパーエンジニア”でなくとも品質を一律に保ってセットアップできます。そして早い

VCFのセットアップツールは高品質なうえに驚異的な早さでセットアップしてくれます。私が検証したときはナント セットアップ時間 1時間54分 で完了しました。

自動セットアップ完了時の画面 「Bringing Up the SDDC」

vSANやNSX・vRealizeといったVMware SDDCインフラを構築したことがある方であればこれが驚異的な早さであることはお分かりいただけるはず。忙しい設計担当者(アーキテクト)の工数も大きく削減可能です。

◆ 3. 運用中も理想形のまま維持される ◆

では、設計・構築の話はここまでにして、ここからはお客様が最も気になる「運用フェーズ」の話をしたいと思います。

いきなりですが、従来のVMware環境と、理想的な形でセットアップされたVCF環境は運用にどれくらいの違いがあるか説明していきます。

 

◇従来のVMware環境◇

運用を開始し、半年、1年、2年と経過していくと、メインコンポーネントであるVMware vSphere(ESXi)やNSX、管理コンポーネントであるvCenter Server・vRealizeといった各ソフトウェアに新しいバージョンが次々とリリースされていきます。機能強化だけではなく、脆弱性に関するパッチも含まれるため、セキュリティ対策のためにも定期的なアップデートが求められます。

 

これとは逆に“バージョン塩漬け”を好まれるお客様もいらっしゃいますが、VMware製品には製品ごとにサポート期間が設けられており、「サポート切れ」予告が次々に襲ってきます。このようなシステムでは計画停止もタイミングもなかなかありませんし、後手後手でバージョンアップしていくと、各コンポーネント間の互換性チェックが疎かになったり、知らぬ間に相互連携機能が正しく動かなくなってしまう―――。

 

その結果どうなるでしょうか??

 

導入当初どれだけ完璧な状態に構築されても、実際に運用が始まり、日が経つにつれてメーカーの理想形からどんどんかけ離れていきます。

気がついたら、サポートされない組み合わせになっていた・・・なんてことも良く聞く話です。

 

参考:「VMware Product Interoperability Matrices」
https://www.vmware.com/resources/compatibility/sim/interop_matrix.php

 

 

◇VCF環境◇

では、VCFを導入している環境ではどうでしょうか。

もちろん、従来環境と同様に、VCF環境でも半年、1年、2年が経過していくと、コンポーネントごとに次々と新しいバージョンがリリースされていきます。

 

しかし!

VCF環境にはバージョン管理の“救世主”として「VMware SDDC Manager」がいます。

 

覚えていますか?? Part1 でご紹介した「導入」「構成」「プロビジョニング」「パッチの適用」といった一連のライフサイクル管理を自動化して運用を大幅にラクにするツールです。

 

VCF環境はメーカーの理想形で完璧に構築されるだけでなく、お客様の運用が始まっても、SDDC Managerが理想の状態を維持してくれます。各コンポーネントにパッチがリリースされたりバージョンアップしても、「互換性を考えながら」「最適な手順で」「管理者の手を煩わせずに」最新の状態にアップデートしてくれます。従来と一線を画すこの管理手法は「自動ライフサイクル管理」と呼ばれています。

 

 

 

自動ライフサイクル管理により、理想の状態が保たれますので、運用管理者は不安なく、いつも安心して日々の運用を続けていくことができるというわけです。

 

これまでのようにバージョンアップを検討するたびに「これとこれの組み合わせは大丈夫だったかな・・・」と毎回考えないでよいと思うと、大きな重荷から解放されますよね!!

 

 

今回は、VCFを導入することにより、お客様のメリットをご紹介しました。

 

VCFはVMware開発者の理想形で構築され、それを維持し続けることができる。みんな幸せ!

 

この一言を是非、記憶に留めていただければと思います。

次回は今回取り上げたセットアップツールを解説していきます、是非ご期待ください!

 

片山 倫哉(かたやま ともや)

日本ヒューレット・パッカードのプリセールス部門に所属するプリセールスコンサルタント。

前職ではプログラマー、HPEでは仮想化のサポートエンジニアを経験後、プリセールス部門に転身。技術が好きでVMware製品やMicrosoft製品の提案や、ProLiantサーバーを中心としたハイブリッドクラウドの提案などに従事。

 

VMware Cloud Foundation でハイブリッドクラウドへ踏み出そう

Part1:「VMware Cloud Foundation (VCF) 」 をご存知ですか?

 

ー Back Number ー

#1 「VMware Cloud Foundation (VCF) 」 をご存知ですか

#2 VCFはどんなお客様向けの製品?

#3 自動セットアップの方法とは?

#4 VCFはHPE Synergy との連携に優れている

 

はじめまして。日本ヒューレット・パッカード(HPE)で仮想化やハイブリッドクラウドソリューションなどのプリセールスをしている片山倫哉(かたやまともや)と申します。

昨今、パブリッククラウドやプライベートクラウドの登場を背景に、「従来型のシステムを将来に向けてどのように変化させていけばよいのか」といった相談が増えてきました。こういった性質の異なるサービスのメリットをうまく組み合わせた「ハイブリッドクラウド」というワードもメディアで取り扱われるようになり、都市部では有志によるハイブリッドクラウド勉強会なども開催されるようになってきています。

 

そんなハイブリッドクラウドを実現する1つの手段として、「VMware Cloud Foundation ™」製品があります。“VCF”(ヴイ・シー・エフ)と略されるこの製品はvExpertでもある私のイチオシであり、今後もVMwareのオンプレミス製品をお使いの方はもちろん、「VMware CloudTM on AWS」といった話題のクラウドサービスをご検討の方も理解しておかなければならない“必須科目”です。

 

HPEはVCFにおいて日本のみならずグローバルにて協業を進めており、以下のような記事も発表しております。

今回は、HPE Synergy上でVCFを検証した結果も含め、4回に分けてVCFのご紹介を行っていきます。

ご参考記事:

HPE、VMware Cloud Foundation認定のハイブリッドIT基盤を発表(ASCII.jp)

https://ascii.jp/elem/000/001/666/1666586/

 

対談 システムの自律化がクラウドの未来を切り開く(日経XTECH)

https://special.nikkeibp.co.jp/atclh/NXT/18/hpe1005/

 

◆ VMware Cloud Foundation (VCF)とは?◆

 

早速ですが、VCFを一言でいうと「ハイブリッドクラウドを実現するための製品」です。

 

VMware Cloud Foundationの“ファンデーション”は化粧品のそれと同じで「土台」や「基盤」といった意味があります。つまり、VCFはVMware Cloudのベースとなっていることがわかります。意外に知られていませんが、実は先ほど挙げたVMware Cloud on AWS もVCFをベースに動いています。

 

“クラウド”という言葉が付いていますが、VCFはなんとオンプレミス環境でも利用することができます。つまり、VCFはオンプレミスでもパブリッククラウドでも利用することができる、共通技術(アーキテクチャー)なのです!!

 

―――オンプレミスでもパブリックでも?あれ、このフレーズ最近よく耳にしますよね?

はい。「ハイブリッドクラウド」です。

 

 

◆ VCFの構成要素 ◆

 

冒頭ではVCFのことを「製品」と書きました。ただ「共通技術(アーキテクチャー)」とも表現しています。しかもVMware Cloud on AWSもVCFで動いている!?

――― 一体どういうことでしょう。

 

まず、VMware Cloud on AWSについてですが、これはAWSのべアメタルサーバーにVCFソフトウェア(製品)をインストールしてユーザーに提供するフルマネージド型のクラウドサービスです。

 

理解を深めるために、より身近な製品(コンポーネント)まで掘り下げてみましょう。VCFにはよく耳にする次の製品が組み込まれています。

 

 

◆ キーとなるのは 「VMware SDDC Manager」 ◆

あれ、1個聞き慣れない製品が混じっていますね・・・「VMware SDDC Manager」。これは何者でしょう?

 

「VMware SDDC」も呼ばれる、vSANやNSX・vRealizeまで導入したソフトウェアデファインドなVMwareインフラ。これを実際に構築・運用することを考えてみてください。HCI(Hyper Converged Infrastructure)であるvSANを使っていますし、一見外部ストレージ要らずでシンプルなアーキテクチャーに感じますが、実際のところはどうでしょう?

よくよく考えてみると、面倒を見なければいけないものがものとても多い。大まかに図にしただけでもこれだけのものがあります。

 

 

これら1個1個の四角アイコンは、ハードウェアもソフトウェアもそれぞれ“バージョン”を持っています。バージョンがあるということは「バージョン管理」をしていかなければならない―――。

 

このバージョン管理を手動で行っていくのは、日常的にかなりの手間と時間が掛かります。芋づる式のバージョン互換性を紐解きながらバージョンアップしなければいけませんし、トラブルなく進めるには事前検証・調査も必要です。それなりの規模になればトラブル無しは当たり前。いかにダウンタイムを最小限に留められるかを求められる運用管理者も多いのではないでしょうか。もし、事前の調査不足や検証不足などでバージョンアップが途中で失敗したらそこでトラブルシューティングをしなければならず、更に時間を要してしまいます。損ばかりの悩ましい問題です。

※バージョンは一例です

 

vSphereはもちろん、vSAN, NSX, vRealizeをきちんと導入してソフトウェアデファインドなSDDCインフラを目指したいけど、運用が大変―――。

 

これを解決するのが「VMware SDDC Manager」です。

 

VMware SDDC Manager はVCFアーキテクチャー環境専用の運用管理ツール。VCFを構成するvSphere, vSAN, NSX, vRealizeといった各コンポーネント(ソフトウェア)の「導入」「構成」「プロビジョニング」「パッチの適用」といった一連のライフサイクル管理を自動化して運用を大幅にラクにするツールです。

 

「ライフサイクル管理??」

 

このメリットは今後本連載を通じて一つずつご紹介していきたいと思いますが、少しだけスクリーンショットをお見せします。

 

まずは導入(セットアップ)フェーズ。

既にここから自動化です。vCenter Serverのインストールはもちろん、仮想スイッチやクラスタ構成・vSANのセットアップ・設定もすべて自動。しかも、VMware社の開発エンジニアの考える「うちの製品をこう設計・構築して欲しい」という姿―――。つまり“メーカーの理想形”(*) の環境にセットアップされます。

 

*「VMware Validated Design」と呼ばれています

 

自動セットアップ画面 「Bringing Up the SDDC」

自動セットアップが終わると、VCF専用の管理画面「VMware SDDC Manager」にアクセス可能になり、ここで一連のライフサイクル管理を行っていきます。

 

VMware SDDC Manager:Dashboard

 

今回はVCFの概要についてご紹介しました。

次回は、VCFがどのようなお客様にとってメリットがあるのかをご紹介いたします。

 

片山 倫哉(かたやま ともや)

日本ヒューレット・パッカードのプリセールス部門に所属するプリセールスコンサルタント。

前職ではプログラマー、HPEでは仮想化のサポートエンジニアを経験後、プリセールス部門に転身。

技術が好きでVMware製品やMicrosoft製品の提案や、ProLiantサーバーを中心としたハイブリッドクラウドの提案などに従事。

 

仮想基盤のパフォーマンスは使用率だけでは図れない

1回目:仮想基盤のパフォーマンスは使用率だけでは図れない

– Back Number –

#1:仮想基盤のパフォーマンスは使用率だけでは図れない
#2:アラートからブレイクダウン
#3:仮想マシンのリストはカスタムビューで
#4:6.7バージョンはメトリックの活用がポイント
#5:vSAN運用管理者にはvROpsは欠かせないツール

日本ヒューレット・パッカード株式会社の中川明美です。

VMware vRealize Operations Manager 6.7が2018年4月にリリースされましたね。

6.7を操作した感想は、「仮想基盤の運用管理に必要なメトリック (カウンタ) にフォーカスしている!」です。フォーカスされていると、覚えるべき項目が少なくなり、初めて仮想基盤の運用に携わる方は助かりますね。

6.7バージョンの一番の変更点は、「分析」タブがなくなったことです。分析タブがなくなったのは残念ですが、初心者に優しいダッシュボードが準備されています。

#1:仮想基盤のパフォーマンスは使用率だけでは図れない

#2:アラートからブレイクダウン

#3:仮想マシンのリストはカスタムビューで

#4:6.7バージョンはメトリックの活用がポイント

ここ数年vROpsに関わるお仕事で、現在も物理マシンと同様の手法で仮想マシンを監視されていらっしゃる方をお見受けします。よくあるのは「使用率」のみを監視する方法です。

仮想基盤は、「キャパシティ」と「パフォーマンス」の2つの視点で監視する必要があります。「使用率」に加え、仮想基盤特有のメトリックと合わせて監視するのがポイントです。

数バージョン前からVMware vRealize Operations Manager (以降はvROps) のワークロードには、CPUは「デマンド」、メモリは「消費 (実際に使用された物理メモリ量) 」を分析結果に表示しています。これらのメトリックを調査するのは仮想マシンのパフォーマンスを最適化する前提となります。標準で提供されるVMのトラブルシューティングダッシュボードでは、使用率と仮想基盤に特化するメトリックが並べて表示されています。

 

仮想基盤において、なぜ使用率のみでは正しい判断ができないのでしょうか。コンピュータリソースのCPUとメモリを例に検証します。

 

◆ワークロード◆

下図は、vROps 6.6まで提供されていた、「分析」タブの「ワークロード」画面です。

この画面はデータセンターを選択しています。ESXiホスト2台分で、CPUのキャパシティは16.76GHz、メモリは32GBです。

<CPU>

ESXiホストの使用率は23.2%です。物理マシンの使用率を監視するならば、問題なしと判断されます。しかしこの画面から2台の仮想マシンのワークロードが高い状態であることがわかります。この画面だけでは根本原因はわかりませんが、ホストの「デマンド」が「使用量」より高い状態であることが1つのヒントになります。

参考までに、この画面でオーバーヘッドが高いのは、CPUの省電力機能が原因です。

KB: Virtual machine application runs slower than expected in ESXi (1018206)

 

<メモリ>

ESXiホストの使用率は82.48%です。物理マシンの使用率を監視するならば、高い使用率から問題ありと判断されるのではないでしょうか。しかし仮想マシンのワークロードは高くありません。この結果から、仮想マシンからのデマンド(要求)により、物理マシンの多くの物理メモリが消費されていることがわかります。

ESXiホストの使用率は90%を超えないように監視するのがポイントです。

仮想マシンからの要求により割り当てられた物理メモリの回収の発生タイミングは、次のBlogにまとめられています。

https://blogs.vmware.com/vsphere/2012/05/memminfreepct-sliding-scale-function.html

ESXiホストに96GBの物理メモリが搭載されていた場合、バルーニングが発生するタイミングは残りメモリが10244.26MBになった時です。このスライディングスケールというアーキテクチャを知ると、90%を超えないように監視するというのも納得できますね。

そして物理マシンの高いメモリ使用率が単純に仮想マシンのパフォーマンスに影響を与えるわけではないこともわかると思います。

 

CPUの高いワークロードの原因を特定しましょう。

◆仮想マシンのCPU診断リスト◆

下図は、vROps 6.6まで提供されていた、「仮想マシンのCPU診断リスト」ビューの画面です。

高いワークロードの原因は、高い競合値です。仮想CPUに物理CPUが割り当てられず、待ちが発生すると、高い競合値となります。

さらにこのBlogのテーマである使用率を確認します。VM-2を例にします。

VM-2のCPUキャパシティは約2.8MHzです。使用量を確認すると、約1.4MHzですから、使用率は50%です。低い使用量は物理CPUが割り当てられないためと考えられます。

 

上記から、物理マシンや仮想マシンの使用率のみでは、仮想基盤のパフォーマンスを分析するための判断材料が不足していることはおわかりになるかと思います。

次にデマンドの値も確認しましょう。競合値が特に高い、2つの仮想マシンでは、「キャパシティ」よりも「デマンド」の方が高い値が表示されています。これも物理CPUが割り当てられないために、リソース要求 (デマンド) が高くなっているためです。

 

 

◆「VMのトラブルシューティング」ダッシュボード◆

vROps 6.7では、「VMのトラブルシューティング」ダッシュボードが標準で提供されています。

このダッシュボードの内容から、「慣れるまではこのダッシュボートを活用すれば問題ないよ」というメッセージを感じます。私が個人的にお勧めする初心者に優しいダッシュボートです。

左側のリストから仮想マシンを選択すると、仮想マシンの構成情報、アラート、ワークロード、稼働ホスト、格納先データストア、VMware Toolsのバージョンを一覧表示できます。

ダッシュボードをスクロールすると、左側に各リソースの使用量 (CPUはデマンド/メモリはワークロード/ディスクはIOPS総数/ネットワークは使用率)、右側にパフォーマンスに影響を与えるメトリックが表示されています。そのメトリックには、CPUとメモリは競合、ディスクは遅延、ネットワークはドロップパケット数が選択されています。

 

複数の画面を遷移せずとも、このダッシュボードから、パフォーマンスに影響を与える原因と対応方法のおおよその検討をつけることができます。

CPUを例にします。CPUのデマンドが高くかつ競合が高いのであれば、パフォーマンスに問題があると判断し、他のESXiホストへの移行を検討します。CPUのデマンドが高くかつ競合が低いのであれば、キャパシティに問題があると判断し、その仮想マシンの仮想CPUの追加を検討します。

 

◆「運用概要」ダッシュボード◆

「運用概要」ダッシュボードで表示される上位15でも、「使用率」ではなく、「CPU競合」「メモリ競合」「ディスク遅延」が選択されています。このダッシュボードも標準で提供されています。

なぜ使用率 (使用量) が選択されていないのかはもうおわかりですよね!

競合の詳細な原因や、ディスク遅延およびネットワークのドロップの発生原因は、「ビュー」または「メトリック」を使用して分析します。こちらについては、以降の回でご紹介します。

 

 

◆まとめ◆

仮想基盤のパフォーマンスに影響を与えるメトリックには仮想基盤特有のメトリックがあるにも関わらず、物理基盤と同様の方法で監視されている方がいらっしゃるのが気になっていました。それをご存じないために、物理基盤と同様の方法で監視されるのではないかと推測します。vROpsで仮想基盤に特化したメトリックが表示されていても、活用するには少々ハードルが高いというお話も私の耳には入っていました。

「VMのトラブルシューティング」ダッシュボードを見た時に、「そうそう、このメトリックが必要なの!」とうれしく思いました。仮想基盤の運用に慣れていない方も、VMのトラブルシューティングダッシュボードを活用すれば、一時切り分けが可能です。

vROps 6.7から、初心者が活用することを意識した構成になっていると個人的に感じています。知識習熟度レベルによって、使い分けられたら費用対効果もあります。

次回は、アラート対象のオブジェクトの原因を探る方法をご紹介します。

仮想スイッチのお作法~Network I/O Control#6~

6回目:仮想スイッチのお作法#6    (Network I/O Control#6)

– Back Number –
#1…仮想スイッチのお作法#1
#2…仮想スイッチのお作法#2
#3…vSphere 6. 5の分散スイッチの機能とアーキテクチャ#3
#4…分散スイッチの管理①#4
#5…分散スイッチの管理②#5
#6…Network I/O Control#6

日本ヒューレット・パッカード株式会社の中川明美です。

6回目は、分散スイッチが提供する「vSphere Network I/O Control バージョン3」についてご紹介します。「Network I/O Control」は、複数の種類のトラフィックが共通のリソースを使用する場合に、競合する問題を解決します。

サーバーの最新モデルによっては、10Gbpsの物理NICを16個まで搭載することができるようになりました。16個もあれば、10Gbpsの物理NICを必要なトラフィックで占有できそうですね。参考までに、vSphere 6.5の10Gbps物理NICの最大構成数は、Intel製は16個、QLogic製またはEmulex製は8個です。

数年前までは10Gbps物理NICは2個が大半で、物理NICを共有する複数の種類のトラフィックをどのようにコントロールするかは設計者の腕の見せ所だったのではないかと思います。

また、Network I/O Controlバージョン2をお使いの方で、物理NICのコントロールはNetwork I/O Controlを、仮想NICのコントロール (制限) はトラフィックシェーピングを使用されていた方もいらっしゃったのではないかと思います。

バージョン3では物理NICおよび仮想NICのリソースコントロール機能を提供しています。ぜひこの機会に、Network I/O Control バージョン3の使いどころを知っていただけたら幸いです。

 

 

◆vSphere Network I/O Control バージョン2とバージョン3

vSphere 6.0から提供されたNetwork I/O Control バージョン3では、vSphere 5.5までのバージョン2にいくつかの機能を追加しています。バージョン2と3の違いを確認します。

 

<バージョン2>

バージョン2では、たとえば仮想マシンのネットワークトラフィックで、物理NICを対象に異なるコントロールを行いたい場合、ユーザー定義のネットワークリソースプールを使用します。

新規ネットワークリソースプールで、「制限」「シェア値」「CoS優先順位タグ」を指定します。作成したネットワークリソースプールを分散ポートグループに割り当てます。

 

 

 

 

 

 

 

 

 

 

 

 

<バージョン3>

バージョン3では、仮想マシンのネットワークトラフィックで、物理NICを対象にコントロールを行いたい場合は「仮想マシンシステムトラフィック」を、仮想NICを対象にする場合は「ネットワークリソースプール」または「仮想マシンの設定」を使用します。

ネットワークリソースプールを作成する前に、仮想マシンシステムトラフィックでバンド幅の予約設定が必要です。

 

◆システムトラフィックのバンド幅割り当て

システムトラフィックには、事前に定義された9つのトラフィックタイプがあります。

物理NICを対象に、「シェア」「予約」「制限」の設定値を使用して、各システムトラフィックにバンド幅を割り当てます。バージョン3から、設定値に「予約」が追加されました。

設定値 説明
シェア 同じ物理NICを使用するシステムトラフィックタイプの優先順位の相対的な比率です。低/標準/高/カスタム (1から100) を指定します。

たとえば、FTとiSCSIに100、それ以外には50のシェア値が設定され、対象の物理NICはFT/iSCSI/vMotion用に使用されているとします。

ある時点でFTとiSCSIの2つのトラフィックが物理NICの帯域を超えたら、各トラフィックは物理アダプタのバンド幅の50%を使用します。

ある時点で3つのトラフィックが物理NICの帯域を超えたら、FTとiSCSIに物理アダプタのバンド幅の40%、vMotionに物理アダプタのバンド幅の20%が使用されます。

予約 1個の物理NIC上で確保が必要な最小バンド幅 (Mbps) です。

すべてのシステムトラフィックタイプで予約される合計バンド幅は、物理NICのバンド幅の75%を超えることはできません。

制限 1個の物理アダプタでシステムトラフィックタイプが使用できる最大バンド幅 (MbpsまたはGbit/s) です。

 

下図は、vMotionトラフィックの設定の編集画面です。この分散スイッチには1Gbpsの物理NICが割り当てられています。

 

 

 

 

 

 

 

 

 

 

<10Gbps物理NIC上のシステムトラフィックのバンド幅予約例>

たとえば、次の予約設定によって、1つの物理NICを対象に、仮想マシン用の0.5Gbpsのバンド幅を確保できたことになります。

 

◆仮想マシントラフィックのバンド幅割り当て

仮想マシンを対象に異なるコントロールを行いたい場合には、「ネットワークリソースプール」を使用する方法と、仮想マシンの設定の編集で設定する方法の2つがあります。

設定値 説明
シェア 仮想マシントラフィックをネットワークに転送する物理NICのキャパシティに応じ、この仮想マシンの仮想NICを通過するトラフィックの優先順位の相対的な比率です。低/標準/高/カスタム (1から100) を指定します。
予約 仮想マシンの仮想NICが物理NIC上で受け取る必要がある、最小バンド幅(MbpsまたはGbit/s) です。

ネットワークリソースプールは予約 (Mbps) のみの設定です。

制限 同じESXiホストまたは別のESXiホストに配置されている他の仮想マシンへのトラフィックに使用できる、仮想マシンの仮想NIC上の最大バンド幅(MbpsまたはGbit/s) です。

 

 

<ネットワークリソースプール>

ネットワークリソースプールのバンド幅割り当ては、そのプールに関連付けられている分散ポートグループ間で共有されます。仮想マシンには、その仮想マシンが接続されている分散ポートグループを介して、ネットワークリソースプールからバンド幅が割り当てられます。

デフォルトでは、分散スイッチ上の分散ポートグループは、割り当てが構成されていない「デフォルト」と呼ばれるネットワークリソースプールに割り当てられています。

 

下図を例にすると、分散ポートグループAに接続される仮想マシンに割り当てられるバンド幅の合計が最小2Gbps確保 (保証) されます。

先に述べたように、ネットワークリソースプールを使用するには、仮想マシンシステムトラフィックで予約の設定をします。

下図は、仮想マシンシステムトラフィックの設定の編集画面です。物理NICのバンド幅の75%を超えない値を設定します。

 

下図は、新規ネットワークリソースプールの画面です。ここで予約値 (最小バンド幅) を設定します。最大割り当て値は、仮想マシントラフィックで設定した予約値×アップリンク (物理NIC) の数です。このアップリンク数は分散スイッチで設定した値です。

 

 

下図は、分散ポートグループの設定の編集画面です。ここで作成したネットワークリソースプールを割り当てます。

<仮想マシン>

各仮想マシンのバンド幅割り当ては、仮想マシンの設定の編集で行います。

「制限」と「予約」は、仮想NICが接続されている分散ポートグループのトラフィックシェーピングポリシーにも依存します。たとえば、トラフィックシェーピングポリシーで平均バンド幅を100Mbpsに設定したなら、仮想マシンの仮想NICの予約値によって仮想マシンが200Mbpsを要求したとしても、実際のバンド幅は100Mbpsになります。

下図は、仮想マシンの設定の編集画面です。ネットワークアダプタを分散ポートグループへ変更し、「シェア」「予約」「制限」を設定します。

 

◆仮想マシンバンド幅のアドミッションコントロール

仮想マシンに十分なバンド幅を確実に割り当てられるようにするため、バンド幅予約とチーミングポリシーにしたがい、ESXiホストおよびクラスタレベルでアドミッションコントロールを実装します。

仮想マシンをパワーオンすると、分散スイッチのNetwork I/O Control機能が、ESXiホストで次の条件が満たされることを確認します。

  • ESXiホスト上の物理NICが、チーミングポリシーと予約に従って、仮想NICに最小限のバンド幅を提供できる
  • 仮想NIC用の予約が、ネットワークリソースプール内の空き割り当て量より小さい

 

<vSphere DRSのバンド幅のアドミッションコントロール>

DRSクラスタ内の仮想マシンをパワーオンすると、vSphere DRSはアクティブなチーミングポリシーに従って、その仮想マシン用に予約されたバンド幅が確保されるキャパシティを持つESXiホストに、その仮想マシンを配置します。下図は極端な例です。

<vSphere HAのバンド幅のアドミッションコントロール>

HAクラスタ内のESXiホストでエラーが発生するかホストが隔離されると、vSphere HAはバンド幅予約とチーミングポリシーに基づき、HAクラスタ内の別のESXiホスト上で仮想マシンをパワーオンします。

 

 

◆まとめ

仮想マシン上のアプリケーションによっては、ネットワークリソースが競合した場合により多くのリソースを割り当てたい、最小限のバンド幅を割り当てたい等のご要望はあると思います。

Network I/O Control バージョン3であれば、これらの要望を仮想NICレベルで満たすことができます。CPUやメモリと同様のコントロール方法ですから、取り組みやすいと思います。予約は仮想マシンがパワーオンできない要因になりますから、その点は注意が必要です。

今回で分散スイッチの投稿は終了です。今後はNSXのご紹介を予定しています。ネットワークは詳しくないと思われているサーバー管理者の方がNSXを検討するなら、を前提に進めたいと考えています。引き続きよろしくお願いします。

仮想スイッチのお作法~分散スイッチの管理②#5~

5回目:仮想スイッチのお作法#5  (分散スイッチの管理②#5)

– Back Number –
#1…仮想スイッチのお作法#1
#2…仮想スイッチのお作法#2
#3…vSphere 6. 5の分散スイッチの機能とアーキテクチャ#3
#4…分散スイッチの管理①#4
#5…分散スイッチの管理②#5
#6…Network I/O Control#6

日本ヒューレット・パッカード株式会社の中川明美です。

5回目は、分散スイッチの障害からのリカバリ方法、vCenter ServerとESXiホスト間のネットワーク接続に問題が生じた場合の対処方法をおもにご紹介します。

◆分散スイッチのネットワーク構成のバックアップとリストア

分散スイッチのネットワーク構成のバックアップとリストアは、次の目的で使用します。

  • vCenter Serverデータベースの破損または誤った設定からの復旧
  • アップグレードでエラーが発生した場合に以前の設定へロールバック
  • 分散スイッチのコピーを作成するためのテンプレート

次の操作により、上記目的を達成します。

  • 非同期でディスク上へ分散スイッチ/分散ポートグループ/アップリンクポートグループ設定のバックアップ (エクスポート)
  • バックアップから分散スイッチ/分散ポートグループ/アップリンクポートグループを復旧 (リストア)
  • 変更後に以前の分散ポートグループ/アップリンクポートグループ設定にロールバック (リストア)
  • バックアップから新しい分散スイッチの作成 (インポート)

◆ネットワーク構成のバックアップ

<分散スイッチのバックアップ>

「設定のエクスポート」メニューで、分散スイッチ/分散ポートグループ/アップリンクポートグループの設定をバックアップします。

ここでは、分散スイッチのバックアップを行います。

「分散スイッチを右クリック → 設定 → 設定のエクスポート」を選択します。

次にエクスポート対象を選択します。

バックアップデータを保存して、終了です。

以前、vCenter Serverデータベースの障害により、複数のVLANを構成した分散スイッチにエラーが発生しました。再作成を前に、導入エンジニアが嘆いていたのを思い出します。

新規作成や構成変更のタイミングで、バックアップを取得しておくことは心の安定を得られますね。様々な設定を構成した分散スイッチのエラーを解消できず、最初から作成するのは心が折れます!

◆ネットワーク構成のリストア

設定ミスを想定し、次の内容に変更しています。

リストアは、分散スイッチ単位/分散ポートグループ単位/アップリンクポートグループ単位で行うことができます。

 

<分散スイッチのリストア>

分散スイッチ単位でリストアする場合は、「分散スイッチを右クリック → 設定 → 設定のリストア」を選択します。次にバックアップファイルとリストア対象を選択します。

<分散ポートグループのリストア>

分散スイッチのバックアップデータから、分散ポートグループのみをリストアすることもできます。リストアしたい分散ポートグループを右クリックし、「設定のリストア」を選択します。

次に、バックアップデータから戻すのか(「設定を次のファイルからリストア」)、正常に動作していた以前の設定にロールバックするのか(「以前の設定にリストア」)を選択します。

バックアップ時の設定に戻されているかは、「設定」 → 「ポリシー」で確認します。下の画面では、先のリストア操作で変更前の状態に戻っています。

 

◆分散スイッチのインポート

バックアップした構成ファイルのインポートから、「新しい分散スイッチの作成」「削除された分散スイッチの再作成」「アップグレードに失敗した分散スイッチの復元」を行うことができます。

また既存の分散スイッチに、エクスポートした分散ポートグループのインポートすることもできます。

ここでは分散スイッチのインポートを行います。データセンターを右クリック、「Distributed Switch」 → 「Distributed Switchのインポート」を選択します。

次に、バックアップファイルを選択します。再作成や復元をする場合は、「元のDistributed Switchとポートグループ識別子を保存します」オプションを選択します。

◆管理ネットワークのロールバックとリカバリ

管理ネットワークの構成ミスのためにvCenter Serverへの接続を失った場合、分散スイッチでは管理ネットワークのロールバックとリカバリを行うことができます。

<ロールバック>

ロールバックはデフォルトで有効の設定になっています。接続を失ったことを検知後、30秒 (デフォルトのタイムアウト値) でロールバックします。タイムアウト値の変更方法はKB2096691を参照ください。

分散スイッチのロールバックは、分散スイッチ/分散ポートグループ/分散ポートに不適切な変更が行われると自動で起動します。

ロールバックを無効にするには、vCenter Serverの詳細設定で「config.vpxd.network.rollback」を「false」にします。

<リストア>

ロールバックを無効にした場合や物理ネットワークの変更によって管理ネットワークに問題を生じた場合、ダイレクトコンソール ユーザーインターフェイス (DCUI) を使用して、管理ネットワークの復旧を行います。

DCUIには次の3つのリストア設定があります。

  • Restore Network Settings
  • Restore Standard Switch
  • Restore vDS

「Restore Standard Switch」「Restore vDS」は、分散スイッチで管理ネットワークが構成されている場合に選択可能になります。管理ネットワークが構成されていない場合はグレーアウト表示になります。

「Restore Network Settings」を選択し、次の画面で<F11>を選択すると、工場出荷時の状態に戻ります。

管理ネットワークの構成エラーから復旧する場合は「Restore vDS」を選択します。次の画面で、ポートバインドの方法を選択します。

分散スイッチを標準スイッチに復元する場合は「Restore Standard Switch」を選択します。

「Restore Standard Switch」を選択すると、IPアドレスを割り当てることができる新しいVMkernelポートと標準仮想スイッチがESXiホスト上に作成されます。分散スイッチのアップリンクは、新しい標準仮想スイッチに移動されます。

<KBのご紹介>

◆分散スイッチのアップグレード

アップグレード対象の分散スイッチを右クリックし、「アップグレード」 → 「Distributed Switchのアップグレード」を選択します。

アップグレードメニューには、他に「Network I/O Controlのアップグレード」「LACPサポートの強化」があります。

< Network I/O Controlのアップグレード>

Network I/O Controlをバージョン3へアップグレードすると、システムトラフィックおよび個々の仮想マシン (仮想NIC) へバンド幅割り当てることができます。#6で紹介します。

<LACPサポートの強化>

バージョン5.1の分散スイッチからバージョン5.5/6.0にアップグレードした分散スイッチで、拡張LACPサポートに変換すると、複数のLAGを作成することができます。

アップグレード前に分散スイッチで基本LACPサポートが有効になっていた場合、拡張LACPサポートへは手動で拡張します。

次の画面で、アップグレードするバージョンを指定します。

 

アップグレード前には、分散スイッチの設定のエクスポートをおすすめします!

 

◆まとめ

今回ご紹介した、「ネットワーク構成のバックアップとリストア」や「管理ネットワークのロールバックとリカバリ」は、バージョン5.1から提供されている機能です。分散スイッチはvSphere 4.0から提供されていますから、こなれた仮想スイッチではありますね。

10Gbpsの物理NICの使用が一般的となり、管理するESXiホストが増設され、分散スイッチを活用する機会が増えてきたのではないかと個人的には思います。

管理ネットワークを分散スイッチで構成するなら、設計も変わってきますよね。分散スイッチで管理ネットワークを構成し、接続が失われた時に慌てた方もいらっしゃると思います。実際に正常に復元するの?と問われたこともあります。事前の復元検証は必須かと思いますが、分散スイッチが提供する復旧機能をぜひ活用いただけたらと思います。

次回は、Network I/O Control バージョン3をご紹介します。

 

仮想スイッチのお作法~標準スイッチから分散スイッチへの道~

4回目:仮想スイッチのお作法#4    (分散スイッチの管理①#4)

– Back Number –
#1…仮想スイッチのお作法#1
#2…仮想スイッチのお作法#2
#3…vSphere 6. 5の分散スイッチの機能とアーキテクチャ#3
#4…分散スイッチの管理①#4
#5…分散スイッチの管理②#5
#6…Network I/O Control#6

日本ヒューレット・パッカード株式会社の中川明美です。

4回目は、分散スイッチの特長であるポートの管理機能および分散スイッチで提供されるアラームや権限付与についてご紹介します。

◆ポートバインド

「ポートバインド」設定によって、仮想マシンの仮想NICを分散スイッチのポートに割り当てるタイミングと方法を指定します。ポートバインドは分散ポートグループで設定します。

下図は、仮想マシンの分散ポートグループの編集画面です。

ポートバインドには、次の3つのオプションがあります。

  • 静的バインド (デフォルト設定)
  • 動的バインド (ESXi 5.0から廃止)
  • 短期-バインドなし

「静的バインド」と「短期-バインドなし」の違いをまとめます。

<KBのご紹介>Choosing a port binding type in ESX/ESXi (1022312)

https://kb.vmware.com/s/article/1022312

<参考>標準スイッチのポート数

ESXi 5.5以降の標準スイッチのポート数は、分散スイッチのポート割り当ての弾性と同様に8個ずつポートが追加されます。標準スイッチではポートバインドはされません。

標準スイッチは、ESXiホストでサポートされているポートの最大数まで拡張できます。vSphere 6.5の標準スイッチ1台あたりの最大作成ポート数は4,088です。

◆ポート単位の管理

分散スイッチでは、ポート単位でポリシーを設定することができます。

下図は分散ポートグループの編集画面です。「詳細」ページで、各ポリシーのオーバーライドを「許可」に設定します。この設定により、分散ポートグループのポリシーをポートのポリシーで上書きすることができます。

下図はアップリンクチーミングでオーバーライドの許可をした後のポート0の編集画面です。

許可していない項目はオーバーライドを選択することができません。

◆アップリンクポートの管理

分散スイッチでは、アップリンクポートグループやアップリンクポート単位でポリシーを設定することもできます。

下図はアップリンクポートグループのオーバーライドを設定する画面です。この画面でベンダー設定を「許可」にすると、「VLAN」「NetFlow」「トラフィックのフィルタリングとマーキング」に対して、一度にオーバーライドの許可を行うことができます。

◆監視機能

監視機能には、「NetFlow」「ポート状態の監視」「アラーム」があります。

<NetFlow>

NetFlowを有効にすると、分散ポートグループのポートまたは分散ポートを通過するIPパケットを監視することができます。

分散スイッチでNetFlowの構成をする場合は、分散スイッチの設定で、「NetFlow」を選択し、「編集」をクリックします。

編集画面で、コレクタのIPとポート番号を指定します。コレクタから分散スイッチを識別できるように、スイッチIPアドレスに分散スイッチ用のIPアドレスを指定します。

<ポート状態の監視>

「ポート状態の監視を開始」アイコンをクリックすると、ランタイム統計情報を表示することができます。

<アラーム>

分散スイッチでは、「分散スイッチ」「アップリンクポートグループ」「分散スイッチポートグループ」で、新しいアラームを定義することができます。標準スイッチでは定義することはできません。

下図は分散スイッチの新しいアラームの定義を設定する画面です。

<参考>

パケットのキャプチャ用のコマンド「pktcap-uw」をご紹介します。

下図はVMkernelアダプタの「vmk0」をキャプチャした画面です。他に物理アダプタ、vmxnet3仮想マシンアダプタ、ドロップされたパケットのキャプチャを行うこともできます。

3パケットの内容を保存し、Wiresharkなどのツールで表示することもできます。

◆まとめ

4回目は、分散スイッチの分散ポートにフォーカスし、どのような機能があるのかをご紹介しました。物理スイッチの運用管理をされている方には、ポートを番号で管理するのは当然と思われるかもしれませんが、仮想スイッチも分散スイッチなら可能です。

今回ご紹介した機能は、私がインストラクターをしていた時に、「仮想スイッチで〇〇の機能はありますか」とご質問いただいた機能でもあります。

標準スイッチをお使いの方は、運用の効率性もふまえ、分散スイッチの使用をぜひご検討いただけたらと思います。

仮想スイッチのお作法~標準スイッチから分散スイッチへの道~

3回目:仮想スイッチのお作法#3 (vSphere 6. 5の分散スイッチの機能とアーキテクチャ)

– Back Number –
#1…仮想スイッチのお作法#1
#2…仮想スイッチのお作法#2
#3…vSphere 6. 5の分散スイッチの機能とアーキテクチャ#3
#4…分散スイッチの管理①#4
#5…分散スイッチの管理②#5
#6…Network I/O Control#6

日本ヒューレット・パッカード株式会社の中川明美です。

「仮想スイッチのお作法」は、以前所属する会社名で執筆していたものです。

最近こちらのブログのフィードバックをいただくことがあり、サブタイトルにあります「分散スイッチへの道」を継続投稿することにいたしました。

マーケット的には、「VMware NSX」が注目されていますね。NSXは分散スイッチを拡張した機能を持ちます。標準スイッチから分散スイッチ、分散スイッチからNSXへと、順次ステップアップしていくのはNSXを理解する一つの方法ではないかと思います。それは、私自身がNSXの認定コースを受講した際に、「分散スイッチがわかっているとNSXを理解しやすい」と感じたからです。

あらためて分散スイッチを知りたい方、将来的にネットワークも仮想化しようとプランされていらっしゃる方の一助になれば幸いです。

3回目以降は、次の内容で進めます。

#3… vSphere 6.5の分散スイッチの機能とアーキテクチャ

#4…分散スイッチの管理①

#5…分散スイッチの管理②

#6…Network I/O Control

 

◆vSphere 6.5で提供される分散スイッチの機能

下表は分散スイッチが提供する機能の一部です。

一般的なレイヤー2物理スイッチと同様に、IPアドレスまたはMACアドレスでトラフィックのフィルタリング、CoSタグまたはDSCPタグでトラフィックにマーキングすることもできます。

◆分散スイッチ提供のライセンス

分散スイッチは、次の製品のエディションで提供されます。

vSphere Standardエディション環境であっても、VMware NSX for vSphereを購入すれば分散スイッチを使用することができます。

(参考) VMware NSX for vSphereのエディション

https://kb.vmware.com/s/article/2145269

◆分散スイッチのアーキテクチャ

下図は、分散スイッチのアーキテクチャです。

<アップリンクポートグループ>

分散スイッチを理解するには、「アップリンクポートグループ」から。#2で「dvUplink Ports」と表現したコンポーネントです。

アップリンクポートグループは論理的な物理NICのポートです。分散スイッチを作成する際、1つ以上のアップリンクポート数を指定します。NICチーミング (フェイルオーバーおよびロードバランシング) を設定するなら、2つ以上のアップリンクポート数を指定する必要があります。

上図では3つのアップリンクポートを構成しています。「Uplink1」にはESXiホスト1のvmnic0とESXiホスト2のvmnic0を、「Uplink2」にはESXiホスト1のvmnic1とESXiホスト2のvmnic1を、「Uplink3」にはESXiホスト1のvmnic2とESXiホスト2のvmnic2を割り当てている想定です。

Uplink#が論理的な物理NICのポートであり、標準スイッチでたとえるなら、選択可能な3つの物理NICがあるのと同様です。

下図は分散ポートグループのNICチーミングの設定画面です。標準スイッチでは「有効なアダプタ」と表示されますが、分散ポートグループでは「アクティブアップリンク」と表示されます。

 

<管理プレーンとデータプレーン>

vSphere の仮想スイッチは、「データプレーン」と「管理(制御)プレーン」の2つのセクションで構成されます。標準スイッチは仮想スイッチ内に「データプレーン」と「管理(制御)プレーン」が含まれますが、分散スイッチは「データプレーン」と「管理(制御)プレーン」が分離されます。

分散スイッチの「管理プレーン」は、vCenter Serverにあり、データセンターレベルでネットワーク構成を一元管理します。「データプレーン」は、分散スイッチに関連付けられる各ホストで管理します。分散スイッチのデータプレーンセクションをホストプロキシスイッチ (または隠された仮想スイッチ) と呼びます。

vCenter Server (管理プレーン) で作成するネットワーク構成は、すべてのホストプロキシスイッチ (データプレーン) に自動的にプッシュダウンされます。そのため、vCenter Serverが停止したとしても、I/Oは停止しません。vCenter Serverの障害がネットワークトラフィックに影響されることはありません。ただしvCenter Serverが開始されるまで、新たなネットワーク構成を行うことはできません。

<参考>

参考までにNSXのコンポーネントをご紹介します。

この図では、NSXのコンポーネントを4つの役割および目的で分類しています。

NSXには論理ネットワークの管理のためにデータプレーンと分離する、「NSX Controller」や「NSX論理ルータコントロール仮想マシン」の制御プレーンがあります。

データプレーンには、分散スイッチを拡張したNSX vSwitch (L3スイッチ) があります。ESXiホストにVIBパッケージをインストールし、L2スイッチの分散スイッチをL3スイッチのNSX vSwitchに拡張します。

※NSXと分散スイッチ

ドキュメントに、「分散スイッチの計画と準備を行ってから、NSXをインストールすることがベストプラクティス」とあります。NSXへの移行を検討されている方は、次のドキュメントを参照ください。

https://docs.vmware.com/jp/VMware-NSX-for-vSphere/6.4/com.vmware.nsx.install.doc/GUID-9B22794A-AC90-418D-BAA7-199D9559CF29.html

◆分散スイッチのデータフロー

下図を例に、分散スイッチのデータフローを確認します。

たとえば、仮想マシンネットワークの分散ポートグループには4台の仮想マシン用の仮想NICのポートが割り当てられ (4個の分散ポートを使用)、VMkernelネットワークの分散ポート グループにはESXiホスト2台のvMotion用の仮想NICのポートが割り当てられた(2個の分散ポートを使用)とします。

また、仮想マシン用ネットワークは、Uplink1とUplink2を使用し、ロードバランシング設定にします。vMotion用ネットワークはUplink3を使用します。各ESXiホストのネットワーク接続を提供するために、vmnic0をUplink1へ、vmnic1をUplink2へ、vmnic2をUplink3へマッピングします。

分散スイッチは次の処理を行います。

  • 分散ポートグループの作成順に、仮想マシンおよびVMkernelにポートを割り当て、0 ~ 5のIDを使用して、ポート番号を割り当てる
  • ESXiホスト1とESXiホスト2を分散スイッチに関連付ける
  • ESXiホストの作成順に、ESXiホストの各物理NICにポート (アップリンクポート) を割り当て、上記の続きとなる6から始まるIDを使用して、ポート番号を割り当てる
  • Uplink1とUplink2は仮想マシンネットワークのポートグループのトラフィックを処理し、Uplink3はVMkernelネットワークのポートグループのトラフィックを処理する

◆ホストプロキシスイッチのパケットフロー

ESXiホスト側では、仮想マシンおよびVMkernelからのパケットを特定のポートから物理ネットワークへ送信します。

ホストプロキシスイッチは次の処理を行います。

  • ESXiホスト1上の仮想マシン1から送信されるパケットは、仮想マシンネットワークの分散ポートグループのポート0へ送信
  • 分散スイッチのUplink1とUplink2は、仮想ネットワークのポートグループのトラフィックを処理するために、パケットをホストプロキシスイッチのアップリンクポート6またはアップリンクポート7へ送信
  • パケットがアップリンクポート6を通過する場合はvmnic0へ、パケットがアップリンクポート7を通過する場合はvmnic1へ送信

 

◆まとめ

今回は、分散スイッチのアーキテクチャについてご紹介しました。

分散スイッチでは、「管理」と「データ」のセクションが明示的に分離されているため、ネットワークポリシーの構成や設定をvCenter Server側で一元管理します。一方、データの管理は各ESXiホストが行います。ホストプロキシスイッチにフォーカスすると、標準スイッチと同様ですね。

 

分散スイッチの各ポートがホストプロキシスイッチ (隠された仮想スイッチ) のポートにマッピングされていることを知ると、vCenter Serverが停止しても、プッシュダウンされたポリシーによって、I/Oに影響がないことを理解いただけたのではないかと思います。

分散スイッチと標準スイッチの異なる点の1つにポートID (番号) があげられます。標準スイッチではポートは割り当てられますが、IDは付与されません。仮想マシンの仮想NICを仮想スイッチポートに割り当てるタイミングと方法を設定するポートバインドについては次回取り上げます。

参考としてNSXのコンポーネントについてもご紹介しました。NSXは分散スイッチを拡張したものと理解すると、難しい製品なのでは?と思うハードルが下がりますね。このブログから分散スイッチを知り、さらにNSXへの興味を高めていただけたら嬉しく思います。

ここが変わった! VMware vSphere 6.5 Part 6

 

日本ヒューレット・パッカード株式会社の中川明美です。

今回は、vSphere 6.5でアップデートされたvSphere DRSの次の機能をご紹介します。

  • Predictive DRSの有効化
  • その他のオプション
    • 仮想マシンの分散
    • ロードバランシングのためのメモリメトリック
    • CPUオーバーコミットメント

vRealize Operationsと連携し、予測メトリックに基づいてリソースをバランシングするPredictive DRSは、vRealize Operationsのさらなる活用がけん引できそうですね。

 

#1: vCenter Sever Appliance_1 (コンポーネントおよびサービス / スケーラビリティ)

#2: vCenter Sever Appliance_2 (高可用性 / バックアップとリストア)

#3: 仮想ハードウェア Version 13 / VMware Tools Version 10.1

#4: 3つの管理ツール (vSphere Host Client / vSphere Client / vSphere Web Client)

#5: vSphere HA (Proactive HA / ホスト障害への応答 / 仮想マシンで許容するパフォーマンス低下)

#6: vSphere DRS (Predictive DRS / その他のオプション)

 

◆Predictive DRS◆

Predictive DRSは、vSphere DRSとvRealize Operations (以降vROps) を連携し、仮想マシンの配置とリソースのバランスを決定する機能です。

vROpsは、履歴データに基づき、近い将来の仮想マシンの予測ワークロードを分析します。vROpsではトレンドとして表示されます。

vSphere DRSは、現在の使用値 (リアルタイムメトリック)に加え、予測ワークロード値(予測メトリック)にも対応し、仮想マシンからリソースが要求される前に、仮想マシンの配置を決定することができます。

 

Proactive DRSは、vSphere 6.5 + vROps 6.4以降の環境で使用できます。

下図の画面から、Predictive DRSを有効化します。

Proactive DRSはタイムリーな移行のために1時間前 (デフォルト) の値を使用します。

 

状況によって、移行を判断するメトリックが異なります。

<現在の使用率が予測使用率を上回る場合>

現在の使用率が優先され、この値を使用して推奨が生成されます。

 

<予測使用率が現在の使用率を上回る場合>

予測使用率の値が仮想マシンの現在のデマンドとして使用されます。このデマンド値を基に、仮想マシンからリソースが要求される前にリソースが利用できる状況にします。要求前に対応するため、パフォーマンスへの影響を軽減します。

 

◆その他のオプション◆

vSphere 6.5では次の3つのAdvanced Optionsが追加されています。

<仮想マシンの分散:TryBalanceVmsPerHost>

ESXiホスト間で仮想マシンの数を均等に分散します。

DRSにより1台のESXiホスト上に多くの仮想マシンが配置される場合があります。その状況でvSphere HAが動作した場合、分散された仮想マシンと比べ、多くの仮想マシンの再起動が必要になります。このような状況を回避する際に、仮想マシンの分散は有効です。

このオプションを設定すると、各ESXiホストにはロードバランシングmaxVMsの制限が与えられます。この制限は、ロードバランシングにのみ適用されます。

 

<ロードバランシングのためのメモリメトリック>

ESXiホスト上のメモリ負荷を計算する時、「有効なメモリ」ではなく「消費されたメモリ」メトリックを使用します。

オーバーコミットされている環境では有効なメモリが適しています。有効なメモリは、アイドルメモリの25%が加算され、負荷を計算します。

オーバーコミットされていない環境では、このオプションを選択し、消費されたメモリを使用してバランシングすることもできます。

 

※仮想マシンのメモリメトリック

「有効なメモリ」はゲストOSが使用している物理メモリ量、「消費されたメモリ」は仮想マシンによって使用されるゲスト物理メモリ量 (共有メモリのうち該当の仮想マシン分を含む) を表します。

<CPUオーバーコミットメント: MaxVcpusPerClusterPct>

クラスタ内で仮想CPUと物理CPUの比率を設定し、オーバーコミットを制御します。オプションで定義された値に達すると、追加の仮想マシンをパワーオンことはできません。

オーバーコミットメント率(最小0/最大500)は、次を参考にしてください。

  • 0-99% 1vCPU未満:1pCPU (コア) ※オーバーコミットしない
  • 100% 1vCPU:1pCPU (コア)
  • 500% 5vCPU:1pCPU (コア)

このオプションはクラスタが対象です。ESXiホストを対象とする場合は「MaxVcpusPerCore」で指定します。

 

 

追加機能ではありませんが、改良点をご紹介します。

◆DRS移行のしきい値

6.5では、移行のしきい値に従来のCPUとメモリに加え、物理NICの使用率が加わりました。

CPUとメモリの統計値から移行の可否を判断することに変わりはありません。初期配置および負荷分散のために移行先のESXiホストが選択されると、次にDRSはその移行先が最適かを判断するために、ネットワーク使用率をチェックします。

移行先のESXiホストに接続される物理NICの使用率が80% (デフォルト値) を超えていれば、最適な配置ではないと判断し、別のESXiホストを使用します。

ネットワーク使用率のしきい値は、「NetworkAwareDrsSaturationThresholdPercent」で変更します。

 

 

◆vSphere DRSに関する情報◆

vSphere 6.5のDRSについての詳細な情報は、こちらを参照ください。

こちらのBlogでは取り上げなかった、パフォーマンス向上のための改良点についても述べられています。

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/drs-vsphere65-perf.pdf

 

アップデートされたDRSについては終了です。

 

 

ここからは、クラスタからESXiホストを削除する方法をご紹介します。

「メンテナンスモードにしなければクラスタからESXiホストを削除できないのですかと尋ねられることがあります。こちらで紹介する方法は、仮想マシンをシャットダウンできない場合にお試しください。可能なら、メンテナンスモードに移行後、クラスタから削除ください。

 

◆クラスタからESXiホストの削除◆

メンテナンスモードに移行せず、ホストをインベントリから除去すると、次のメッセージが表示されます。

ESXiホストをvCenter Serverから切断すると、メンテナンスモードに移行せず、ESXiホストをインベントリから除去することができます。

ESXiホストを右クリック→接続→切断と操作します。

次のメッセージの内容を確認の上、操作を進めてください。

切断後、インベントリの除去を行うと、次のメッセージが表示され、ESXiホストをクラスタから削除することができます。

ドラッグアンドドロップで、データセンター配下に置くこともできます。

◆まとめ◆

「ここが変わった! VMware vSphere 6.5」のすべての回が終了しました。

vSphereもバージョンが上がるたびに様々改善されていますね。今回取り上げた機能を使用すると、運用管理面が強化されるように思います。特にHAやDRSは、ホスト障害およびパフォーマンス低下に備えて、予防しましょうというメッセージを感じます。

今後は、HAとDRSの併用を前提に、構築設計していく必要があるのかもしれませんね。

また、「VMware Cloud on AWS」が発表され、Hybrid Cloud環境がけん引されそうですね。vRealize製品も注目を集めそうです。機会がありましたら、vRealize製品のBlogも投稿できたらと思います。