IT初心者のための仮想化のメリット - (物理環境の課題編)
今回は2017年 vExpert Advent Calendar 第2弾です。
今回は、初心に帰りまして、仮想化のメリットをよりわかりやすく説明出来ればと思います。
特に物理サーバー、物理システムとの対比ということで大きく2つの利点を挙げたいと思います。私個人が特に感じる仮想化の利点は次の通りです。
- システムのデプロイの時間短縮
- 物理的な設置作業が楽になる
1. システムのデプロイの時間短縮
例えば、物理システムに対してOSをインストールするのには通常30分~1時間くらいの時間がかかります。(勿論OSの種別やハードウェア構成により時間は依存します)
但し、ここに至るまでには次のような下準備があって初めてインストール作業が開始出来るわけです。
- システムが接続されるネットワークデバイス、ストレージデバイスとの互換ドライバー、ファームウェアのバージョン確認
- 上記で確認をしたデバイスドライバー、ファームウェアの準備、ダウンロード
- OS及び上記の更新ファイルを含んだデバイスの準備
- 導入作業を行う場所が、デバイスの持ち込み制限がある場合は持ち込み申請
- OSインストール前に、互換性維持のためにハードウェアのファームウェアやBIOSの更新
まず、システムに対する互換性というのを確認しないといけません。
- OSとサーバー
- OSとNIC、ストレージアダプター
- OSとSANストレージ
以上のように物理サーバーごとに例えば次のように複数の点においての互換性を気にする必要があります。例えば社内に50台サーバーが存在する場合は、最大で50回この作業を行う必要があります。(Windows Server, Linux, などなど)
例えばWindows Serverに対し、Dell PERC H730PというRAIDコントローラーの互換性を調べる場合は次のページを確認します。
Windows Server Catalog - for Dell PERC H730P
このような作業を、サーバーに搭載されているデバイスの数、デプロイするサーバーの数だけ行う必要があります。インストールするOSの種別が多ければ多い程、調査に要する時間は比例的に増えていきます。
仮想化を採用してしまえば、VMware vSphere ESXiに対しての互換性をチェックしてしまえば、確認にかかる時間は大幅に短縮されると言えます。
VMware Compatibility Guide - System Search
メディアなどの記憶媒体は、昨今セキュアである環境への重要性が高まっている状況では持ち込み許可が簡単には降りないケースも珍しくはありません。
特にOSメディアは、OSインストール時にフォーマット(ストレージデバイスの初期化)が行えてしまいますし、それによってデータロストなどが発生してしまうなども怖いですよね。
更には、ファームウェアやドライバーインストールなどは、ハードウェアベンダー、デプロイされているオペレーティングシステムによっても更新手法が異なりますので、ここでも手順書の作成やシステムごとの違いにより、異なる手順を覚えるのも時間的にロスが大きくなります。
最近では、どのベンダーもOSが未インストール状態でもファームウェア更新が出来るような仕組みがハードウェアに組み込まれていたりします。
※Dell EMCの場合は、Lifecycle Controllerと呼ばれるUEFIベースの機能によりBIOS、NIC、HBAのファームウェアなどの更新が出来ます。
ここまでの内容について言えば、ESXiを導入する際にも、ESXi向けに同様の確認や準備は必要とは言えますが、仮想化の場合、ゲストOSレベルでのこれらの調査は不要または限定的な状況に於いて必要となるため、大幅な準備時間の短縮になると言えます。
また、忘れてはならないのは仮想環境には"クローン”や”テンプレート”という、数クリックで同一のシステムをデプロイ出来てしまう機能もありますね。
2. 物理的な設置作業が楽になる
この点について言えばシンプルです。
仮想化＝物理サーバーの台数縮小化と言うのは有名なメリットです。
そして、物理サーバー環境における典型的な課題は次のようなイメージです。
見ての通りですが、大量のケーブルです。
当然ながらこれらよろしくない例です。
ケーブルの壁が、排熱の妨げや保守作業の妨げになります。
以前に私がコールサポートエンジニアだった時代に、お客様から"背面がケーブルだらけでケーブルの抜き差し作業が出来ません”と言われたことがありました。
少し話を元に戻しますと、物理サーバー1台辺り、例えば次のようなケーブルが存在するわけです。
ストレージの利用有無と性質次第でケーブルの種類は変わりますが、例えば電源装置が冗長化されているような環境では、2本の電源ケーブルが登場するなど、本数も1台のサーバー辺りでも複数本になります。
ケーブルが増える＝差込口についても考慮要となるわけですから、ネットワークスイッチもポート数が足りなくなったり、あるいは電源についても同様のことが言えます。
また、システム自体は重量もある程度あるため、ラックへの搭載作業も基本的には複数名で行うことが大前提となります。
Dell PowerEdge R740xd 設置および操作マニュアル
仮想化をすることで、設置台数を減らせるため、こうした作業工数も減りますね。
また、台数が減る事で次のような利点も生まれますね。
- 排熱が減るため、サーバールームの空調費用がコストダウン
- 電源利用元に当たるサーバーが減るため、電気代が減る
- 物理サーバーが減るため、保証管理対象が減る
- ラックに搭載する機器が減るため、ラック設置時の予測積載量が低減する
仮想化をすることで単純にコストが減るとは言いますが、具体的にはお客様の視点ではこれらの利点があるということですね。
今回はこれで以上となります。
仮想化は確かに素晴らしく、今後もITインフラを支える標準的なシステムとなると思いますが、これは裏を返せば、物理サーバー環境に於ける問題提起があったからこそ生まれたものだという裏付けにもなりますね。
勿論物理サーバー環境にも良い点はあると言えますので、それぞれの性質を理解した上で、仮想化が適する環境には積極的に仮想化を利用して頂きたいと思います。
VMware製品の効果的な学習方法 - Free e-learning編
今年よりvExpertとして活動をさせていただいているのですが、いよいよvExpert アドベントカレンダーに参加させて頂きます。
皆様、技術的な内容やトレンドであるvSAN, vCloud, NSXなどを記事にされていますが私はテクニカルインストラクターを普段しておりますので、それらしい内容で今回は提供してみたいと思います。
まず、私はかれこれIT業界に入ってやっと10年程なのですが、最も身につく学習方法は”実機を触る”という事でした。
この点については、過去の連載記事で”VMware ハンズオンラボ”について紹介しておりますので、これを参照したい人はこちらの記事をご覧ください。
今回はそれ以外の方法の紹介としまして、VMwareが無償提供しているe-Learningがありますのでこれを紹介します。
ページを開いていただきますと、各言語ごとに提供コースが分かれています。
見た感じ、やはり英語での受講ビデオがダントツに多いです。
12/1時点では、日本語提供のものはこちらです。
受講にはVMware myLearnアカウントが必要となりますが、無償です。
試しに”VMwareのネットワークの仮想化の基礎”を受講してみると次のような画面が開きました。
音声も日本語ですし、スクリプトは、上記画像内左側の”ノート”という所から、音声スクリプトを確認することが出来ます。
トレーニング内のQuizなどを終え、コースを修了すると、次のように合格証が発行されます。
より多くの科目を受けてみたいという方は英語であれば多くの科目を受講出来ますので、是非チャレンジしてみてください。
サーバー管理者のためのVMware NSX入門 - MACアドレステーブル(前編)
今回はサーバー管理者がVMware NSXを管理する際に、必要最低限知っておいて欲しいネットワーク知識として、MACアドレステーブルについて紹介します。
まずこれを語る前には、”ネットワークハブとネットワークスイッチの違い”を理解する必要があります。
人間の世界でも、対個人間でのやり取りには様々な個人に対して付帯されている識別子が利用されることは一般的です。
- 氏名
- 会社名、所属団体名
- メールアドレス
- 電話番号
- 住所
それぞれは異なる性質、異なるフォーマットですが一個人や一組織対して付帯されるものです。
ネットワークの世界ではこれに近いものとしては例えば次のようなものがあります。
今回のテーマにあるMACアドレスですが、一般的にネットワークインターフェイスカード(以下NIC)が持つポート単位で存在する識別子です。
ここで本題に戻りますが、ネットワークハブもスイッチも、見た目は似ており、単一の筐体に多くのネットワークポートを持っています。
これらに対し、一般的にはLANケーブルを使い、コンピューターやサーバーのNICポートを接続します。
物理レイヤーでの結線や見た目はハブもスイッチも同じです。
内的な通信方式の違いが、これら二者の違いです。
まずは、MACアドレスに対する振る舞いは次のように異なります。
- ネットワークハブは、自身に接続されたデバイス(コンピューターやサーバー)のMACアドレスを記憶しない
- ネットワークスイッチは、自身に接続されたデバイス(コンピューターやサーバー)のMACアドレスを記憶する(どのポートの先に、どのMACアドレスのデバイスがいるかを記憶する)
この、スイッチだけが持つMACアドレスと物理ポートの関連付け情報を”MACアドレステーブル”と呼びます。
これにより、コンピューターやサーバーに対して通信データを送信する際に、次の違いが出ます。
- ハブを利用している環境では、送信先ではないデバイスにも通信データが送られてしまい、無駄にネットワークの帯域幅を利用してしまう、セキュアではない通信となる。
- スイッチを利用している環境では、スイッチはMACアドレステーブルがあるお陰で、通信先のみを選定してデータ送信を必要最低限な相手にのみ送信することが出来る。
つまり、スイッチは効率的な通信を行うデバイスであり、それはMACアドレステーブルのお陰である事が分かりました。
続編として、次回はMACアドレステーブルの生成のプロセスと其の課題について触れたいと思います。
VMware NSX と ネットワークエンジニアの働き方
本日無事にVCP6.5-DCVの受け終わりまして、漸くVMware NSXに集中出来ます。
折角なのでNSXの事もブログに書こうと思いましてこの回に至るのですが、vSAN同様に素晴らしいブログも多く、ネタ探しも大変なわけです。
そこでまず”VMware NSXを導入すると、ネットワークエンジニアの働き方がどの様に変化するか”を私なりに考えて見たいと思います。
※これは私個人の意見ですので、人によってはまた違った解釈などもあるかもしれません。
お題:VMware NSXは、ネットワーク管理者の在り方をどのように変えるか？
まずお題に入る前に、私が特に強調したいのは、NSXはサーバー管理者とネットワーク管理者のためのソリューションだと考えています。
vSANの場合はこれが違います。
vSAN=サーバー管理者がストレージ管理を行う
NSX=サーバー管理者とネットワーク管理者でインフラを管理を行う
vSANの場合、基本的に既存インフラからSANストレージを無くすことが出来ます。
しかしNSXの場合、スイッチやルーター、LANケーブルが無くなるか、と言われればそんなことは有りません。(vSANであれ、SANであれ、スイッチは必要ですよね)
VMware NSXのコンセプトをvSAN同様に考えてしまうと、ネットワーク管理者からすると”自分の今まで培ったスキルが活かせない”、”VMware NSXを導入する事で自分の仕事が他の人に奪われるのでは”と考えてしまうかも知れません。
既存のネットワークインフラでは、レイヤー毎に製品が異なり、その為管理チームが違い、縦割りな管理形態とスキルセットにより運用がされており、これにより環境のデプロイ速度の鈍化、チーム連携が難しい、サポートが必要な時には複数のベンダーに問い合わせるなどの潜在的な問題があったと言えます。
こうした課題を解決してくれるのがVMware NSX だと言えるでしょう。
- 単一製品でレイヤー2-7までを対応出来る
- 単一製品なので、レイヤー間で操作性も大きな違いがない
- シングルベンダーなので、問い合わせ先もシンプル化する
- 仮想マシンが主役なので、物理スイッチのポート数やケーブルの種別やケーブリングなどによる管理負荷が減る
こうして見ると、ネットワーク管理者の業務がシングルレイヤーに対する管理から、マルチレイヤーに対する管理にシフトしていると言えます。
一言に、"ネットワークエンジニア”と言いましても、会社毎に業務範囲も違うでしょうから、その点はご容赦頂けると幸いです。
ここまでで私がお題に対して申し上げたい結論は次の通りです。
- VMware NSXを導入したからと言って、社内ネットワークエンジニアの業務タスクがなくなる事はない(アンダーレイネットワークは無くならない)
- VMware NSXの管理にはシングルレイヤーからマルチレイヤーネットワーク管理スキルが必要となる(ネットワークエンジニアのワークロードがシフトすると言える)
- 殆どのネットワーク管理レイヤーが、VMware製品として統合されるため、製品の互換性などを考えたり、ベンダー毎の保証レベルやサービスレベル、または保守契約やインシデント管理をする必要がなくなる。(シングルベンダーなのでインシデント対応のシンプル化)
以上です。VMware NSXとの付き合い方というのは、これまでのネットワーク管理者の課題を新しいカタチで変えてくれるものだ、と言えるのではないでしょうか。
ESXi ストレージ パスの見え方, 考え方(Dell Storage MD編)
前回のDell Storage SC編に続き、今回はDell Storage MDのESXiのパスの見え方を紹介してみたいと思います。
前回の記事を参照したい人は、こちらのリンクから閲覧が可能です。
さて、まずは恒例の物理トポロジーの確認からです。
ホワイトボードの左側が192.168.40.x/24で、右側が192.168.41.x/24です(中央の点線が境目)
今回は、イニシエーターとターゲット間のスイッチが冗長化されていない構成です。
勿論、エンタープライズの環境では高可用性は重要なポイントですから、スイッチも二重化することで、よりこの環境の可用性は高まると言えますね。
※今回はテスト環境のため1つのスイッチでストーリーをこのまま進行します。
※遠隔地にある環境を利用したのですが、Cisco Discovery Protocolを利用したおかげで、2つのNICポート(vmnic0と1)が同じスイッチに接続されている事が分かりました。
イニシエーター側が使うIPアドレス
- 192.168.40.76/24
- 192.168.41.76/24
ターゲット側が使うIPアドレス(各色は、ホワイトボード上の色と対応しています)
- 192.168.40.36/24(ストレージプロセッサ上段の左側ポート)
- 192.168.40.37/24(ストレージプロセッサ下段の左側ポート)
- 192.168.41.36/24(ストレージプロセッサ上段の右側ポート)
- 192.168.41.37/24(ストレージプロセッサ下段の右側ポート)
この環境に対し、ランタイム名によってこのシステムを見てみると、ランタイム名の各項目は次のような意味合いを持ちます。
- vmhba - iSCSIアダプターを示す
今回はソフトウェアiSCSIアダプターであり、複数の物理ポートが存在してもvmhbaは1個となっている。
ハードウェアiSCSIアダプターを搭載しているシステムの場合は、デュアルポートならvmhbaが2つ、クァッドポートならvmhbaが4つ登場します。 - Channel - ストレージIOの送信元物理ポートから送信先物理ポートを示す
イニシエーターからDell Storage MDのiSCSI IOポートまでのパス
チャネルでは、送信元と送信先のポート毎にナンバリングがされています。
Channel = Source IPとDestination IPの組み合わせによるPathである。 - Target - Dell Storage MD システムそのものを示す
この事例では、本システムはTarget ID 0として、ESXiが認識しています。
複数のDell Storage MDにアクセスをするESXiの場合は、Target番号を使い、物理的なストレージシステムを差別化します。
ターゲットナンバーで製品が違いますね(T0=MD3200i / T1=MD3000i) - LUN - Dell Storage MD内のLUN(ボリューム)を示す
これは、他のストレージシステムとも同様で、ストレージ内部のボリューム(ホストにマウントする単位)の識別子である。
これらを総括して見ますと、次のようなレイヤー構造が見えてきます。
特に右側の紫のvmhba/Channel/Target/LUNを意識してご覧頂くと、上図の解説がわかりやすいと思います。
物理ストレージシステム自体が単一のターゲットとして振る舞うため、そこまでの道筋の番号をチャネルで表現しているのがDell Storage MDと言えます。
今回は以上となります。そのうちDell Storage PSシリーズでも同じ内容を掲載したいと思います。
vSAN アーキテクチャ ー Distributed Object Manager（DOM）
vSAN アーキテクチャー編始めてみました。
vSANは実は複数のソフトウェアの集合体、と考えていただくことが可能です。
今回は、Distributed Object Manager (略称DOM)の紹介です。
<役割と紹介>
- オブジェクトの可用性の制御と初期IOのリクエストを担当している
- オブジェクトはDOMレイヤーに存在しており、LSOMオブジェクトコンポーネントにDOMがvSANオブジェクトまたはVMDKを展開している
- DOMは全てのミラー化されたコンポーネントに対しIOが同期されていることを保証する
- DOM Clientにて受け取ったIOは、DOM Ownerに転送される
- オブジェクトごとにDOM Ownerは1つであり、必ずオブジェクトのローカルに存在しているとは限らない
- DOMはカーネルスペースに存在しており、監視用デーモンはなく、動作の再起動にはホストの再起動が必要である
- 動作ログはvmkernel.logで追うことが出来る
前回紹介をしました、”CLOM(Cluster Level Object Manager)”と名前が似ており、今回もオブジェクトにまつわるソフトウェアです。
前回のCLOMがポリシー通りの配置になるようにオブジェクトのケアをしていたのに対し、DOMはストレージIOを司ると理解すれば、違いは明確だと言えます。
DOMは全てのvSANノード上で動作をしており、4ノードvSANだったとすれば、4ノード全てでDOMは動作しているといえます。
また、DOMには細かく言えば3つのロールがあり、次の通りです。
- DOM Client
仮想マシンからのストレージIOを受信し、オブジェクトにそれを渡す際に、DOM Ownerに対し渡す役割を行う（DOM Ownerにとっての仮想マシンサイドのインターフェース役） - DOM Owner
オブジェクトごとに存在するオーナーであり、ストレージパスやオブジェクトの再同期など、オブジェクトの管理を行う役目を果たす
DOM Ownerがダウンする、あるいはネットワーク的に他ノードと疎通不可になる場合は、即座に他のDOMが新しいDOM Ownerとして選定される
また、DOM Ownerは、CLOMと通信を行うためのインターフェースを/dev/dom(左記のものは、/dev/char/vmkdriver/domのシンボリックリンク)として持っている。
例えば、仮想マシンの新規作成時には、CLOMがポリシー遵守出来るかをチェックし、其の結果問題無い場合は、CLOMがDOM Ownerに仮想マシン作成指示を出すが、その際の動きが、/var/log/clomd.logに記録される。
（イベント事例としては、CLOMFetchDOMEventなどで検索をすれば表示されます） - DOM Component Manager - LSOMに対するフロントエンドの役割であり、DOM OwnerからのIOを受信し、LSOMにそれを渡す役目を果たす。
これらの位置関係としては、以下のようなイメージである。
[仮想マシン]→[vSCSI]→[DOM Client]→[DOM Owner]→[DOM Component Manager]→[LSOM]→[Physical Drives]
esxtopコマンドでxオプションを使えばDOMの上記3種のストレージアクティビティも関しが出来ますので、IOを司っている、と言われても至極当然な気がします。
vSAN Observerで見た場合には、次のように各DOMとLSOMに対するタブが存在します。
以上となります。やや難しめの記載もあったかもしれませんが、”オブジェクトレベルでのIO担当”がDOMと考えれば概要としてはバッチリかなと思います。
この役割ってハードウェアレイヤーではRAIDコントローラーのような役割とも表現が出来そうですね(パス提示と再同期およびIO担当という点より)
------------------------------------------------------------------------------------------------------------
<備考：本記事で参考にした資料>
https://blogs.vmware.com/vsphere/files/2014/08/Monitoring-with-VSAN-Observer-v1.2.pdf
ESXi ストレージ パスの見え方, 考え方(Dell Storage SC編)
久しぶりにDell Storage SCの講義を行いましたが、その中でvSphere ESXiに対するLUNマウントを実施しまして、パスの見え方について解説をしたので、記事にしてみたいと思います。
まず、今回の環境は次のようなトポロジーです。
ストレージの世界では、IOを発行する側がイニシエーター(Initiator)、IOを受けてデータを保持する側がターゲット(Target)と呼びますよね。
また、ファイバーチャネルの世界では、イニシエーターとターゲット間の接続にWorld Wide Name(ワールドワイドネーム、以下WWN)にて相互に識別をしますが、上図では緑色でそれを簡単に示しました。
本来WWNは、以下のように大変長いため、上図では末尾の文字だけを緑で書きました。
上記の環境を、vSphere Web ClientとDell Storage Manager(Dell Storage SC/PS用の管理ツール)で見た際には次のように見えます。
Dell Storage SCでは、１つのシステム内にストレージコントローラーが2つ存在し、冗長性とロードバランシングを提供します。
単一のボリュームは、この2つのコントローラーのうた1つをアクティブコントローラーと呼ばれるIOを提供してくれる役割に選定します。
同一ストレージシステム内に複数のボリュームが存在する場合は、ボリュームごとにアクティブコントローラーが異なります。（これによりIOの負荷が分散されます）
上図では、ボリューム名"VMware ESXiボリューム1"は、コントローラー”21106”がアクティブコントローラーであり、このコントローラーがダウンした場合はコントローラー”21105”がIO提供をするためのセカンダリコントローラーとなっています。
ご覧を頂くと、アクティブコントローラー側が持つ全てのWWNが、ターゲットWWNとして見えていることが確認出来ますね。
ちなみに、アクティブコントローラーを再起動し、コントローラーの疑似障害を発生させました。
Dell Storage SCは、ターゲットWWNをNPIVによって”仮想WWN”を生成し、コントローラーの障害が発生した場合に、仮想WWNをバックアップコントローラーに移動させ、IOパスをフェイルオーバーさせます。
以上です。ストレージの見え方というのは製品の仕様によっても少々異なることがありますので、その点ご容赦ください。
ちなみにイニシエーターWWNは次のようにトポロジーと紐付いています。
加えて、4つのパスも上記オレンジで表現していますので、参考に頂ければ幸いです。
以上です、よい週末をお過ごしください。
----------------------------------------------------------------------------------------------------
<補足>
フェイルオーバーした仮想WWNは、”ポートリバランス(再調整)”にて、フェイルバックします。
仮想WWNがフェイルオーバーしているよう場合には、次の警告が出ますので、”ポートの再調整”をクリックすれば、ポートのフェイルバックが完了します。
仮想WWNポートが無事戻りました。
