読者です 読者をやめる 読者になる 読者になる

VMwareな日々

VMware環境関連の管理者/導入/トラブルシュートなどに役立ちそうな情報を備忘録として掲載とその他を少々投稿していくブログ

Virtual Volumesのメリット

久々の更新です。しばらく社内でVMware以外の製品トレーニングに追われており、なかなかVMware製品の知識まとめが出来ておりませんでしたがぼちぼち再開をしていきます。

来週から久しぶりにvSphere 6.0 Install, Configure, Manageを2週間立て続けに行います。それ以降は7月末まで、vSAN 6.2 Configure & Manageをぶっ続けです。

 

さて、今回はVirtual Volumes(略称VVOL)についてです。

vSphere 6.0からリリースされた機能ですね。最近のVMwareさんのストレージ系機能の強化は手厚いですね。今回はメリットを紹介致します。

 

Virtual Volumesを利用する際のメリット

  • VAAIによるオフロード
    スナップショットはクローンなどの操作をこれまでvmkernel側にて処理していたものが、
    ストレージ側にてこの処理を実行するため、仮想環境側のリソースに余裕が出る。
    これらのストレージ処理時にCPUやメモリなどのリソースが利用されることがなくなる。

  • ストレージ管理者と仮想基盤管理者間でのコミュニケーションが円滑になります
    例えば、VMを保存する場合のデータストアの選定時に、管理画面上では各データストアが、"レプリケーションにより保護されているか?"であったり、”RAID 10なのかRAID 5”なのか確認ができません。
    逐一ストレージ管理者に質問、確認が必要です。Virtual Volumesを利用すれば、仮想マシン作成時のインターフェースでこれを確認し、VMに対し適切なストレージ選びが可能となります。

  • 過剰なディスクプロビジョニングがなくなる
    VMFSを利用している場合、一度フォーマットされた領域は縮小出来ません。(以下のナレッジに記載がありますね)

    kb.vmware.com

    つまり、ストレージの管理者からすれば、一度仮想化基盤管理者に渡したVMFSは、そのLUNを削除するまで帰ってきません。ですので、領域のアサインの意思決定には慎重です。
    ですが、VVOLで利用されるストレージコンテナーと呼ばれる領域は、拡張、縮小がサポートされています。この点で言えば、ストレージの領域に関して柔軟性ある判断にて領域の確保ができるといえます。

  • ストレージが持つ機能を、仮想マシン単位で利用するかどうか選定できる
    通常ハードウェアストレージが持つ機能には次のようなものがあります。
    スナップショット、レプリケーション、クローン

    これらはLUN単位で実施されるため、単一のLUNに対し、100台のVMが存在する場合、これらのオペレーションはこの100台に対して実行されます。
    必要な仮想マシンがそのうち10台だけであれば、次のような手法であれば10台に対しスナップショットが利用出来ます。
    1. 10台のために別のLUNを作成する
    2. 10台のスナップショットはVMware ベースのものを使う

    1.の場合、管理対象が増えてしまうのが難点です
    2.の場合、スナップショット取得時のリソースはvmkernelのものを使うので、パフォーマンスの懸念があります。

    VVOLを利用すれば、仮想マシン単位で、ストレージのこれらの機能を利用できます。

 

これら以外にもメリットは多くありますが、代表的なものを例を上げて記載してみました。

ストレージの管理が楽になる"VASA"って何?

VASAです、VASA

vSphere Storage API for Storage Awarenessの略称です。

似た単語で、”VAAI”がありますがこれはまた別回にて紹介します。

 

VASAを使うことで、ハードウェアストレージの操作や管理をvCenter Serverから行うことができるようになります。

これにより管理性、操作性、効率性が向上し、管理者の負担を減らすための機能だといえます。

例えば、次の図を見ていただいてLUNの情報で何がわかるでしょうか。

f:id:instructor8010:20170416231855p:plain

2つのLUNがあること、その名称、容量などです。

 

但し次の情報はわかりません。

RAIDレベル何で保護されているのか?レプリケーションにより保護されているのかどうか?暗号化されているのだろうか?IOPSはどれくらいだろうか?

 

例えば仮想マシンを配置する場合に、用途に応じて上記のような情報をベースに配置箇所を考える必要が出てくるわけです。

”別に社内の担当者に尋ねればわかるし問題ない”という方もいると思います。

もちろんそれでいいんですが、不在時であったり、提供された情報が正しいとは限りません。スピードと情報の正確さを取るのであればVASAを利用してストレージを操作、管理するのがベターといえます。

Dell EMC Equallogicに関する過去のDellの記事で言えば下記のブログでもう少し詳細の画像などが確認できます。

EqualLogicとvSphere連携の紹介【第五回】Prifile-Driven StorageとVASA (VMware vStorage APIs for Storage Awareness) - テックセンター - Blog - テックセンター - Dell コミュニティ

”ストレージポリシー”というものをユーザーがvCenter Server上で作成します。

例えば”Performance"という名前のポリシーを作ってみます。

そこに対し、RAIDレベルやディスクのインターフェース規格など条件を紐付けていきます。

例えばRAID10SASなどのようなイメージです。この選択肢は各ベンダーごとにVASAで利用ができる選択項目に違いがあります。

作成したポリシーを、仮想マシンの仮想ハードディスクに対して適用してやることで、管理者は簡単に想定したパフォーマンス、保護レベルを得やすくなります。

条件としては、次の通りです。

  • ストレージがVASAに対応していること
  • vSphere 5.0以上であること

    www.vmware.com

 

 

出張 in 廈門 <NSX Day 5 編 & 帰国>

久しぶりの更新となりました。2日ほど前に帰国しましたが、前回の更新から本日に至るまで色々ありました。

 

ちなみにこれはNSX最終日のディナーでした。T-Boneステーキだそうです。見た目は小さいですが意外とこれで量は多いです。

f:id:instructor8010:20170416111207p:plain

 

 さて、5日目のNSXトレーニングですがセキュリティとマルチvCenter Server環境についてのトレーニングでした。

特に印象的だったのは”ファイアウォール”でした。設定が数クリック、しかも細かい設定ができるという印象です。

ネットワークデバイスの操作と言えば、個人的にはコマンドラインというイメージが強いです。しばらく触らないとコマンドラインは思い出すのが結構大変です。(常時触ってなさいよ、というのは無しでお願いします)

後はコマンド出力からルールを判断するのは苦手です。

NSXファイアウォールは、私のような人間には視覚的にファイアウォールの状態を判断し易いので管理が比較的ラクです。

例えば次の図で赤枠の下の方を見ると、3層Webサーバー(Web、App、DB)に対するファイアウォールルールが組まれています。

f:id:instructor8010:20170416153850p:plain

行数が、1つのルールとなっており、赤枠内は次のようなルールです。

  • ルール番号2
    アクセス元:不特定多数
    アクセス先:Web Tierという名前のグループに属している2台のWeb サーバー
    アクセス方式:HTTPSまたはSSHのみ
    操作:通信を許可する
  • ルール番号3
    アクセス元:Web Tierに属する2台のWeb サーバー
    アクセス先:Applicationサーバーが接続されている論理スイッチ
    アクセス方式:TCPポート番号8443(MyAppという名称でポート番号とプロトコルを定義しています)
    操作:通信を許可する
  • ルール番号4
    アクセス元:Applicationサーバーが接続されている論理スイッチ
    アクセス先:Databaseサーバーが接続されている論理スイッチ
    アクセス方式:MySQLに対する通信
    操作:通信を許可する

今まで操作を行ってきたファイアウォール製品と同じように設定が組めます。
また視覚的かつvSphere環境上のオブジェクト(仮想マシン、スイッチ、クラスターなど)に対してファイアウォールの送信元、送信先を設定でき、粒度が高い設定が可能です

 

また細かい設定などは別稿でしっかり記載をしたいと思います。

----------------------------------------------------------------------------------------------------------------------

NSXトレーニングを終え、次の週は別のハイパーコンバージド製品のトレーニング受講か~と思いきや”トレーニングではなく試験”との情報が舞い込みます。。。

 

ということで土日は大急ぎで製品学習を行い、月火の2日間であるハイパーコンバージド製品の認定トレーナー試験を受験し、何とか合格となります。

(金曜から月曜にかけてはほぼ寝ずに常に学習、VMware Certified Instructor Workshopの試練を思い出しました)

 

こちらが合格当日の夕飯、中華料理のレストランです。
スティックに具材がついており、出汁のスープに通して頂く鍋と蒸鶏(左奥)、
スペアリブに唐辛子パウダーが付いた料理(手前左)、野菜が練り込まれた豆腐(手前右)

f:id:instructor8010:20170416161449p:plain

そして無事試験を終え、帰国です。

f:id:instructor8010:20170416161819p:plain

こちら出国審査後の通路にて

中国出張ということもあり、中華料理がメインだったのでこういうジャンクフードが無性に食べたくなります。

f:id:instructor8010:20170416161915p:plain

お土産店、お菓子、パンダのぬいぐるみ、中国風の衣服など、日本ではあまり見ないものが印象出来でした。

f:id:instructor8010:20170416162028p:plain

 免税店にて、自宅と会社向けにお茶をお土産に買ってみました。厦門福建省ですから烏龍茶は有名ですね。

f:id:instructor8010:20170416164212p:plain

さて、ということで無事帰国しいつもの日常に戻りました。

また次回からはブログも通常運行に戻る予定ですのでぜひ皆さんアクセスいただければ幸いです。

 

出張 in 廈門 <NSX Day 4 編>

4日目が終わりました、こちらが本日のディナー

毎朝来るホテルのビュッフェに来ました

f:id:instructor8010:20170406233154j:image

ビールが飲み放題なので、青島ビールを数本頂きました

 

本日は主にEdgeゲートウェイサービスについて学びました

 

ネットワークの世界では、North-South型ネットワークを提供するコンポーネントです

つまりインターネットや別データセンターなどの組織外への通信の出入り口になる部分です

 

VMware NSXでは仮想マシンアプライアンスとして、エッジサービスゲートウェイVM(以外ESG VM)が提供され、次のような機能を実装出来ます

 

ネットワークのこうした製品はWindowsCisco製品でやって来ましたが、全部GUIで数秒で出来てしまうのが大変楽です

 

また、特定のハードウェアベンダーに依存しない操作性であるので、特にネットワーク製品によくある"コマンドを覚え直す"ような事が起きないので楽です

 

単一のESG VMにこの機能を持たせても良いし、負荷を分けるために複数のESG VMを立ててもよし

 

ちなみに接続先は物理アップリンクと分散ロジカルルーターとなります

 

こちらの記事も後にエッジサービスゲートウェイの詳細を増やす予定です😄

出張 in 廈門 <NSX Day 3 編>

こちらも備忘録です。本日は分散ルーティング、L3レイヤーをやりました。

概ね以下のブログの内容と同じです。

ネットワーク仮想化をネットワークの基本から理解する 第3回:分散ルーティング - Layer3 の世界 - Japan Cloud Infrastructure Blog - VMware Blogs

論理ルーターコントロールVM(Logical Router Control VM)なるものを仮想マシンベースで作成後、各ESXiホストに分散ルーターが分散配置され、これを分散論理ルーターと呼称します。(Distributer Logical Router、以下DRL)

 

ルーターへの設定適用は論理ルーラーコントロールVMに対し行いますが、
設定値は、コントローラークラスター→netcpa→ESXiノード内の分散ルーターの順にデータが転送されます。

これはルーティングで重要なルーティングテーブルについても同様です。

 

<編集中>

出張 in 廈門 <NSX Day 2 編>

今日の内容は完全に備忘録です。後ほど訂正、加筆予定。

  • 論理スイッチ
    NSX環境で利用するL2~L7機能を提供するスイッチ
    vSphere Web Clientから作成し、分散スイッチに対してvmkernelポートグループとして表示される。
    論理スイッチを5個作成すれば、5つのvmkernelポートグループが作成される。
    VXLAN IDは24ビット(2の24乗、つまり16万個のVXLAN IDが用意出来る)を使い表現される。

  • トランスポートゾーン
    論理スイッチを含めることが出来る箱のような存在であり、ネットワークの境界線となる
    トランスポートゾーンに対しクラスターを参加させ、参加をしたクラスター達は同一のネットワーク内に居るといえる。但しネットワーク通信が相互通信出来るかは

  • VTEP
    VXLAN Tunneling End Point
    VXLAN環境の通信では、VXLAN向けに通信をカプセル化、解除を行う役割を担う

出張 in 廈門 <NSX Day 1 編>

本日より、VMware NSXコース in 厦門が始まりました。

mylearn.vmware.com

観光日記みたいになっていましたが、仕事です。一緒に受ける人がほぼネットワーク熟練者ばかりです。CCIEホルダーも居るようで、なかなかシニアな経歴の人が多く刺激的です。

 

さて、話を元に戻すとNSXが何かというとネットワーク仮想化製品です。

f:id:instructor8010:20170403231010p:plain

といっても、ネットワークの仮想化ってのがそもそもピンと来ない人が多いと思います。加えて言うなら、ネットワーク自体が苦手で、避けたい人も多いと思います。

 

ネットワーク機器の運用管理で抱える大きな課題は次の通りです。

  • ケーブリング
  • ネットワーク・トポロジー
  • ベンダー単位で異なるコマンドライン
  • 変更、構築には多くの時間やネットワーク環境への十分な理解が必要

ケーブリングについては、”Data Center Cabling”でググれば画像検索で色々画像がでてきます。きれいなもの、汚いもの色々あります。

汚いのは例外ですが、きれいなものは一度固定で組むと、あとでネットワーク構成を変えるときの作業が大変です。

社内組織の変更や戦略の変更などがあれば、IT資産の運用手法が変わることも多いです。

 

またITベンダーの価格競争の結果、既存環境強化の予算で購買出来る製品は常に特定のベンダーのものとは限りません。つまりマルチベンダー構成になる可能性は大いに有りえます。

 

IT管理者からすればありえないことですが、ファイナンス部門からすればそんなことはお構いなしだったりします。こうなると管理者は複数の管理コマンドを覚える必要が出るわけです。

 

後はESXiやvCenter Serverなどの登場により、仮想マシンがより迅速にデプロイ出来るようになったものの、ネットワーク側の度重なる調査や調整でビジネスの速度が鈍化することなども有りえます。

 

どの問題も単一でも大変ですが、複合的に起きると更に面倒です。
こうした問題、課題をクリアにしてくれるのがVMware NSXだと考えて頂くと良いでしょう。

※勿論ここで挙げている例は一部にしか過ぎません。

VMware NSXでは、”NSX Manager”と呼ばれるアプライアンス仮想マシン)を展開し、これを通じ上記の問題を解決するための様々な要素をデプロイ、設定していきます。

NSXではレイヤー構造が次のように有り、NSX Managerは管理機能をユーザーに提供します。

f:id:instructor8010:20170403233854p:plain

 

次に制御としては、コントローラークラスターという考え方があり、一般のスイッチで言うテーブル情報を保持し、データIOはこれらの情報に基づいて提供されます。

具体的には最低3台のコントローラークラスターノードを構成し、これらがIOのルールを制御しています。

本日は概要的な内容でしたので、この2つが中心の実習操作を行い終了。

明日からコアな内容に入っていきます。今日の内容の加筆も明日少し行う予定です。