Simple is Beautiful

■[家]オール電化：電気代028,029,030 (+024) - 2011/09/22〜2011/10/20 (29日間), 10/21〜11/21(32日間), 11/22〜12/19(28日間), 05/24〜06/20 (28日間)

前回のレポート時(…といっても、9月の話ですが…)に無くしてしまったと書いた6月分の電気代が思わぬところから出てきました(^_^;)。ということで、めでたく欠番であった24回分もそっと加えつつ、昨年10月〜12月分のレポートです。

10月、11月は一昨年と比べて暖かかったこともあり、電気代は対前年比マイナスとなりましたが、急に寒くなった12月は逆にプラス。しかも大幅に…。やはり床暖房やオイルヒーターなどの暖房器具を使い始めるとすぐに電気代に現れます。

さて、では今回もグラフを。

• 電気代：請求額

黒線が2011年、緑線が2010年、赤線が2009年となります。

火力発電所依存となったこともあり、じわじわと電気代のベースとなる1kWhあたり燃料調整費が上がり続けていますので、あまり比較しても意味がない気がしてきていますが…まぁ支払額という意味では記録する価値もあるかな、と。

今回で通年の電気代は締まったわけですが、2010年の通年合計電気代13万2798円に対して、2011年は15万1930円と2万円弱の増でした。ま、9月を除いて全ての月で前年を上回ったわけですから当たり前ですけど。

• 電気代：時間帯別内訳

このグラフはやめることにしました。ま、あまり意味がないので…。

燃料調整費は10月分からついにプラスに。どんどん増加中。毎月のことですが、やはり朝晩時間枠(am7-am10, pm5-pm11枠)の電気代が問題ですね。共働きなので、平日日中はそんなに使わないので、昼間時間枠の電気代が割高なのは別にかまわないのですが…。

• 電気使用量

最後にkWh単位での電気使用量の推移。2011年は実線、2010年は太めの点線、2009年は細めのて点線で示しています。

12月は朝晩は279kWh、昼は94kWh、夜は403kWでした。やはり寒くなるとエコキュートがお湯を作るために沸かすにも、元々の水の温度が下がるので電気代が増えますね。

さて、今月は年間を通じて最も高い電気代となっている1月。いくらになることやら…。

ツイートする

Permalink | コメント(0) | トラックバック(0) | 13:13

■[Virtualization]Dell AIM + VMware ESX - Networking

ちょっと12月ドタバタとしていて、エントリーがまったく書けていませんでした…。このまま何も書かずに年を越してしまうのもなんなのですが、じっくりとエントリーを書いている余裕もあまりないm(_ _)mということで、世の中的にはあまり知られていないDellのエンタープライズ向けソフトウェア製品、Dell Advanced Infrastructure Manager (AIM)のご紹介を軽くさせて頂ければと思います…。

AIMはインフラ環境を統合管理するソフトウェア製品ですが、VMware vSphereやHyper-Vなどと組み合わせることによって仮想化環境についても統合的に管理することができるようになります。また、管理サーバとなるAIM Controllerは仮想アプライアンスとしても提供されていますので、比較的容易にVMware vSphere上にAIM環境を構築することもできます。

AIMが行うネットワークに対する管理は、物理的なスイッチに対しても仮想スイッチに対しても基本的には同じです。AIMで管理されているOSイメージ(Personaと呼ばれています)は、物理的な要素とは切り離されていますので、Server1で起動していたPersonaを次回起動時にはServer2で起動させることができます。また、ServerをPoolとして扱い、Pool内で空いているServerのいずれかで起動するようにさせてしまうことも可能です*1。この際、Personaが起動するServerが変化することに対して、Networkの構成が付随してこないと困ることになります。たとえば、VLAN10に接続する構成を持つPersona Aと、VLAN20に接続する構成を持つPersona Bがあるとして、あるサーバにおいてPersona Aが起動する際には接続先のネットワークはVLAN10に、Persona Bが起動する際にはVLAN20に自動的に構成されていないと、いくらPersonaの起動先が物理Serverに縛られないといっても使い物にならないわけです。このように、Personaが必要とするNetworkを、Personaの起動するServerの接続先に合わせて自動的に構成する仕組みが連動することで、AIMは「イメージと物理的な要素との切り離し」を実現しています。

さて、今回のエントリーはAIMとESXの組み合わせについてのご紹介ですので、その部分に絞り込んで。

AIMによってESXホストを管理するためには、ESXホストをAIMに対してVMRack(AIMの管理対象として登録するHypervisorの名称)として登録する必要があります。

VMRack登録はウィザード形式で行うことができます。AIMがサポートするHypervisorはVMware vSphereだけでなく、Hyper-VやXenなどにも対応しています。

ウィザードには"Automatically configure VMware standard switches."という項目があり、AIMによる仮想スイッチの管理を有効化することができます*2。

AIMから仮想スイッチを管理するために、ESXホストをVMRackとして登録する際にはvCenterサーバについての情報を合わせて構成します。

AIMはIPMIを通じてサーバの電源ステータスを管理するため、VMRackとして登録したESXホストについてはAIMの管理画面から電源操作を行うことができます。Local Disk Booted型ではないVMRackであれば、他のPersonaと同様に起動先のサーバを選択したり紐付けをプール化したりすることも可能です。

AIMはVMRackとして管理しているESXホストに対して、自動的に紐づけられたPersonaに必要となる仮想スイッチとポートグループ(VLAN)を構成します。

この構成情報はAIMから管理しているため、AIM Controller側からもステータスを把握することができます。

AIM側ではNICをChannelとして紐づけることで物理的な差異を吸収するとともに、冗長化を構成しています。そのため、AIM側で構成を変更すればもちろん仮想スイッチの構成が自動的に変更されます。仮想スイッチの接続先となっている物理スイッチ側の構成も連動して変更されますので、動的なインフラとして使用することが可能です。

AIM側でChannelとして管理されているNICのグルーピングが、ESX側の仮想スイッチでは紐づけられるvmnicとして構成されます。

物理サーバ、仮想化環境、そしてシステムイメージの管理をAIMに一元化することにより、システム環境は物理的な縛りのないリソースへと移行することができます。ネットワークブートするシステムイメージは事前に構成を済ませておくことにより、必要に応じて物理サーバ上でネイティブにも、仮想化環境上で仮想マシンとしても稼働させることが可能です。

今回のエントリーでは詳しく紹介しませんでしたが、AIMの機能をvSphere Clientを通じて管理するためのResource Managerと呼ばれるプラグインも提供されています。Resource Managerを使用することにより、AIMによるESXと仮想マシンの管理をより慣れたかたちで行って頂くことができます。

これらを組み合わせて使用することにより、AIMは仮想化によってもたらされた動的なリソースとしてのITインフラを物理環境にまで拡張することができます。

ツイートする

Permalink | コメント(0) | トラックバック(0) | 09:44

■[Storage]仮想化されたストレージってどういうことだろう？(3)

さて、第3回のエントリーです。

第1回ではネットワークロードバランス機能について、第2回では容量ロードバランス機能について書いてきました。ネットワークロードバランスは、ストレージとサーバ間の通信部分についての最適化を行い冗長性と拡張性を提供するための仕組みです。容量ロードバランスは、ストレージがスケールしたり逆にシュリンクしたりする際にデータの分散配置を最適化するための仕組みです*1。

第3回となる今回は、自動パフォーマンスロードバランス機能(Automatic Performance Load Balancer / APLB)について書きます。

前回のエントリーで書いたように、容量ロードバランスに基づいてグループ化されている複数のストレージ筐体に分散して配置されたサブボリュームは、容量の比率配分という意味では最適化されたといえますが、まだこの時点ではパフォーマンス面では最適化されてはいません。いくら容量ベースで分散が行われたとしても、アクセスが頻繁に行われるサブボリュームが特定の筐体に集中的に配置されてしまっていたとすると、いくら筐体を増設してもパフォーマンスはスケールアップしないということになってしまいます。そこでさらにパフォーマンス状態に基づいてサブボリューム配置の最適化を行う機能が、自動パフォーマンスロードバランス機能です。

最もシンプルなパターンとして、同一性能で同一容量のストレージ筐体2台で構成されたストレージシステムの場合を考えてみたいと思います。容量ロードバランス機能によって、2台の筐体に均等に分散配置されたサブボリュームは、その後サーバからのI/O要求が行われることによりアクセス頻度の高い「ホット」なサブボリュームとアクセス頻度の低い「コールド」なサブボリュームがあることがわかります。

この例では、同一仕様のストレージ筐体にあるボリュームを構成するサブボリュームがそれぞれ8個ずつ配置されています。赤いサブボリュームはホット、青いサブボリュームはコールドであることを意味しています。ここでは、左側の筐体にはホットなサブボリュームが3つ、右側の筐体にはホットなサブボリュームが5つ配置される状態となっており、容量としてはバランスしていてもパフォーマンスという意味ではまだバランスしていないということとなります。自動パフォーマンスロードバランス機能は、この状態が確認されると各筐体に均等にホットなサブボリュームが配置されるように、サブボリュームの再配置処理を行います。

なお、基本的にはパフォーマンスの最適化＝サブボリュームの再配置はあくまでも容量ロードバランスの比率を維持したままで実行される、という点です。そのため、自動パフォーマンスロードバランスによる最適化が行われても、容量ロードバランスによる配置比率の最適化が崩れてしまうことはありません。

どういう基準でサブボリュームをホットもしくはコールドと判定するのかについてはストレージベンダーの腕の見せ所です。I/Oアクティビティや、レイテンシ状態など、基準とすることができる指標は数多くありますが、あまりにも複雑化すると最適化計算の負荷が高くなってしまいます。また、最適化をどの程度のタイミングで実行するのかもポイントとなります。高頻度に判定を行えばそれだけより最適化されることとなりますが、一時的なI/O要求にもいわば過敏に反応してしまうこととなるため、ムダな再配置処理が行われる比率が高まってしまうこととなります。逆に、最適化頻度の間隔を開ければ長期的な傾向に基づいて判断が行われるためより適切に再配置が行われることとなりますが、最適化されるまでに時間がかかることや、短期的なI/O要求の変化に対しては最適化が対応しないなどのデメリットもあります。

EqualLogicの場合は、筐体内での再配置が必要な一部のモデル*2を除き、基本的にはグループを構成する複数の筐体間での最適化については基本的には各筐体毎のレイテンシ状態だけを基準として比較を行い、一定の基準値*3をトリガーとしてパフォーマンスのロードバランス処理が行われる仕組みとなっています。レイテンシだけを基準としているのは、筐体のモデルやRAIDレベルなどがバラバラの筐体でグループが構成されたとしても1つのルールだけで対応することができるシンプルなアルゴリズムとすることができるためです。また、以前のFirmwareでは長期的な傾向に基づく最適化のみでしたが、現在は短期的なI/O状態に対しても最適化対応できるようになっています。

容量ロードバランスは新しく筐体がストレージに追加された場合や、ボリュームの拡張が行われた場合などだけに実行されるバランス機能ですが、自動パフォーマンスロードバランス機能はボリュームが作られてから削除されるまでのライフサイクル全般にわたって最適化の役割を担い続けるという意味で、最も重要なパフォーマンス最適化機能といえます。

次回は、この自動パフォーマンスロードバランス機能は実質的には階層化、Tieringの仕組みとして使うことができますので、その点にフォーカスを当てて書いてみたいと思います。

ツイートする

Permalink | コメント(0) | トラックバック(0) | 00:17

■[Storage]仮想化されたストレージってどういうことだろう？(2)

もう少しブログのエントリーを書かないと、と思いつつ、ついつい…1ヶ月が経過してました。前回のエントリーはこちら。

さて、前回はネットワークロードバランシング機能(NLB)について書きましたので、今回のエントリーでは残りの2つのうち、容量ロードバランス機能(Capacity / CLB)について書いていきたいと思います。3つ目の自動パフォーマンスロードバランシング機能(APLB)とまとめて書こうと思っていたのですが、ちょっと長くなってしまいそうですので。

仮想化されたストレージでは、動的なデータの配置が行われます。最初は1台の筐体で構成されていたストレージシステムに対して、2台目、3台目と動的に追加し、サービスを停止することなくストレージの容量を拡張できることが求められます。そのためには、サーバ側に認識されるボリュームは物理的な筐体、さらにはRAIDに紐付られることなく配置され、拡張できる必要があります。もちろん逆に、3台で構成されていたシステムから、1台の筐体を取り除くことについても動的にできることも重要です(使用容量などの理由で取り除けない場合もあり得ますが)。

EqualLogicはサブボリュームの集合としてボリュームを構成しています。統合的に管理されているEqualLogicが1台の場合は、当然すべてのサブボリュームが1台の筐体内に配置されていますが、2台目が増設された時点で、自動的にサブボリュームは2台目のEqualLogicにも分散配置されます*1。この動作はサーバからは透過的に処理されており、サーバからのI/O処理を優先する形でサブボリュームの再配置(つまりは筐体間のサブボリュームの移動)が行われています。また、前回のエントリーで書いた通り、EqualLogicはGroup IPというかたちで仮想IPアドレスをサーバに対する窓口としているため、筐体が増えてもサーバ側では何の設定変更・追加も必要ありません。

ただし、EqualLogicの筐体が増設に伴ってどこまででもサブボリュームが分散配置されるかというと、そうではありません。EqualLogicは通常、3台の筐体までの範囲でサブボリュームを分散配置します。ここで誤解しないで頂きたいのは、では3台以上のEquaulLogicでGroupを構成してもパフォーマンス的なスケールはしないということではありません。たとえば、筐体A,B,C,D,Eの5台のEqualLogicで統合されたGroupを構成していた場合、Volume1はA,B,C、Volume2はC,D,Eといったように配置されるようなこともありますので、全体としてはパフォーマンスはスケールしていくこととなります。また、3台のEqualLogicでは必要容量が確保できない場合などでは、4台以上のEqualLogicのサブボリュームが分散されることもあります。

EqualLogicはRAIDをあくまでもサブボリュームを保護する仕組みとしてしか使用していないため、ボリュームの容量やパフォーマンスとRAIDは直接的には結び付きません*2。もちろん、RAID50よりもRAID10の方がパフォーマンス(特に書き込み…といってもランダムI/Oだと話は難しいところですし、コントローラのキャッシュもありますが…)がよいですし、リビルド時のパフォーマンスインパクトやリビルド所要時間などにも違いがありますので、さまざまな観点に基づいてRAIDレベルは考慮する必要はあります。EqualLogicは自律的にサブボリュームの配置を最適化しますので、基本的にはボリュームの配置は自動的な調整に任せてしまうことが最適となります。

サブボリューム単位のサイズをどの程度とするかについては、ストレージシステム設計におけるバランスを考慮して考えられています。サブボリュームのサイズが小さいとどのブロックがどのサブボリュームにあるのかについての管理テーブルが肥大化してしまうため、CPUやメモリにかかる負荷が大きくなってしまいます。逆に、サブボリュームのサイズが大きいとストレージの仕様効率は低下しますが管理しなければならないサブボリュームの数を減らすことができます。当然のことながら、コストはCPUやメモリの方がコストは高いリソースですので、ある程度の大きさのサブボリュームサイズとされる場合が多いでしょう。具体的なサイズについては、ストレージベンダー毎のノウハウと言える部分もあるため、公開されていない製品が多いかと思います。

容量のロードバランスはボリュームの構成時にサブボリュームの配置を行っておしまい、というわけではありません。ストレージが使用されていく中で、読み書きが頻繁なサブボリュームや、ほとんどI/Oの発生しないサブボリュームなどが出てきますので、それらの配置が最適となるように再配置のプランニングが行われ、自動的に最適化が行われます。再配置の処理中は一時的にサブボリュームの配置はアンバランスとなることがありますが、基本的には各筐体の論理容量に基づく比率に従ってサブボリュームは分散配置されます。

また、パフォーマンスの最適化のためとは別に、各筐体の空き容量に基づく再配置の処理も行われることがあります。複数の筐体の中で空き容量が一定以下となった筐体ができた場合、サブボリュームの再配置はパフォーマンスの最適化よりも優先して処理されます。もちろん、筐体の増設などによりGroup全体の容量が拡張された際には、改めてパフォーマンスに基づく最適化が処理されます。

こうした容量に対するロードバランスはもちろんトランザクション処理として実行されており、サブボリュームの再配置とメタデータの書き換えの両方が完了したことを確認したうえで、移動元側のサブボリュームのデータが削除されます。

次回は最後のロードバランス機能、自動パフォーマンスロードバランス機能(Auto Performance / APLB)について書きたいと思いますが、すでにこのエントリーでも一部のパフォーマンスロードバランスに触れてしまっていますね(^_^;)。

さて、仮想化ストレージの真骨頂は最後のロードバランス機能、自動パフォーマンスロードバランス、です。これについては、また次回。1ヶ月後にならないようにしたいと思います…。

ツイートする

Permalink | コメント(0) | トラックバック(1) | 09:28

■[家]オール電化：電気代025,026,027 - 2011/06/21〜2011/07/21 (31日間), 07/22〜08/21(31日間), 08/22〜09/21(31日間)

電気代6月分(第24回)ですが、「電気ご使用量のお知らせ」を紛失してしまいました…。やはり4ヶ月もほったらかしにしていると…反省。いつか出てくることを期待して、とりあえず第24回は欠番扱いということで…m(_ _)m

さて、電気使用量ですが、7月と8月は昨年よりも使用量が多い状況(7月は+17kWh, 8月は+35kWh)でしたが、9月は大幅に下回ることができました(-118kWh)。…といっても、単に去年が猛暑で9月の電気使用量が多かっただけともいえるかもしれませんが。

太陽光発電は興味もありますし、色々と調べてはいるのですが、状況的に国・都・市の来年度予算における補助などがどうなるかを見極めてから具体的なプランを検討していきたいと思っています。

さて、では今回もグラフを。

• 電気代：請求額

黒線が2011年、緑線が2010年、赤線が前年(2009年)となります。

5月、6月と同様に、10月、11月は年間を通じて最も電気使用量が少なくなる月ですので、久々に1万円を下回ることを期待。

• 電気代：時間帯別内訳

続いて、時間帯別の内訳。

このグラフの管理はもうやめようかと思ったのですが、今回だけは継続。ポイントは水色のマイナス線「燃料調整費」で、3月の震災以降どんどんマイナスがなくなっていってついに9月分ではわずか-46.70円に。翌月分も＋になることが予定されているので、この項目は記録をつけ始めて以来始めて、マイナス項目ではなくプラス項目に転じそう。

• 電気使用量

最後にkWh単位での電気使用量の推移。今年は実線、2010年は太めの点線、2009年は細めのて点線で示しています。

このグラフ、3年分ぐらいにしておいた方がいいですかね。それ以上重ねてもグチャグチャになりそうですので…。さて、今年の冬がどうなるかですが、オール電化住宅に済んでいて、電気使用量が増えるのは夏よりも冬なので、この冬の電気使用量がどうなるのか、ちょっと心配ではあります。

さて、ちゃんと毎月、「電気ご使用量のお知らせ」が届いたらすぐにエントリー書かないと駄目ですね。

ツイートする

Permalink | コメント(0) | トラックバック(0) | 23:41

■[Storage]仮想化されたストレージってどういうことだろう？(1)

サーバの仮想化に続いて、ストレージの仮想化を具現化する製品が色々と登場し、そして今後、ネットワークの仮想化に関する技術が、具体的に製品化されようとしています。どの技術も興味深いのですが、今回のエントリーではストレージの仮想化について書いてみたいと思います。

ストレージを仮想化する方法や実装される階層は色々とあります。物理ディスクを抽象化し可用性を実現するRAID技術も一種のストレージ仮想化技術ですし、最近ではサーバが認識するボリュームがRAIDにより構成される論理ボリュームとも結びつかず、物理的ではない論理的なRAIDを実装しているストレージ製品も多く登場しています。サーバとストレージの間に入って実際のストレージを隠蔽する形態であったり、ストレージ自身の機能であったり、さらには汎用OSに導入して使用するソフトウェアタイプもあります。

いわゆるスケールアウト型のストレージ製品の多くでは、各ストレージ筐体にディスクだけでなくコントローラも搭載され、それぞれの筐体が自律的に動作しながらも協調的に動作する、いわば自律分散型のストレージモデルがよく使われています。これにより、ストレージは動的な拡張・縮退・変更に対応し、いわゆる仮想化されたストレージといわれる機能を実現しています。

さて、では動的に拡張できて、サーバから認識される領域が抽象化されたかたちで実装されていればそれで十分仮想化されているかといえば、そうではないでしょう。スケールアウトとは、単に容量が拡張されるだけではなく、それに合わせてパフォーマンスも最適化される必要があります。サーバからの接続も、ボリュームの配置も、さらにはボリュームを構成するサブボリューム単位*1についてまでもが自律的に最適化されることによって、ストレージはパフォーマンスの面でも仮想化されたとえいるかと思います。

たとえば、Dell EqualLogicは、スケールアウト型のストレージとして、3つのロードバランス機能を有しています。

1. ネットワークロードバランス機能 (Network Load Balancer / NLB)
2. 容量ロードバランス機能 (Capacity Load Balancer / CLB)
3. 自動パフォーマンスロードバランス機能 (Auto Performance Load Balancer / APLB)

1つ目のNLBについては、ストレージとサーバとの間でのパフォーマンス最適化機能なので、残りの2つとは異なるレイヤーにおける機能といえます。EqualLogicは統合的に管理される複数の筐体でGroup IPをシェアしており、個々のインターフェイスもそれぞれ個別のIPアドレスが構成されています。iSCSIはプロトコルの仕様としてリダイレクトの仕組みがあるため、EqualLogicはGroup IPに対して接続を求めてきたサーバからのリクエストに対して、最も余裕のあるインターフェイスのIPアドレスに対してセッションをリダイレクトすることにより、サーバからの通信が最適となるようにふりわけます*2。

もちろん、単にセッションを振り分けるだけではストレージとして機能しません。EqualLogicでは一般的に、複数の筐体にまたがってボリュームが構成されるので、ボリュームに対するアクセス＝筐体に対するアクセスとはなりません。同じボリュームに対するアクセスであっても、あるサブボリュームは筐体Aに、別のサブボリュームは筐体Bに配置されているということになります。そのため、EqualLogicによってセッションが割り振られた先の筐体にアクセスしたいサブボリュームが存在するとは限らないわけです。サーバが要求してきたサブボリュームを自身が所有していなかった場合、EqualLogic筐体はそのサブボリュームを持つ筐体から当該のサブボリュームのデータを受け取り、サーバに対してデータを返す動作を自動的に処理しています*3。

これでも良いのですがさらに、サーバ側が自身が割り当てられているボリュームについて、事前にどの筐体から構成されてるのか、さらには各サブボリュームをどの筐体が所有しているかを把握していれば、より最適化された接続を行うことが可能になります。これを実現しているのが各OSごとに提供されているEqualLogicに最適化された専用のマルチパスドライバです。マルチパスドライバが導入されたサーバは、それぞれのボリュームについて、どの筐体がどのサブボリュームを所有しているのかについての情報をEqualLogicと連携しながら同期管理し、必要とするサブボリュームのデータを各筐体に直接セッションを構成して取得することが可能となります。この仕組みにより、EqualLogic筐体間でのサブボリュームデータの受け渡しのための通信を不要とし、さらにはボリュームに対するアクセスを並列的に、ボリュームを構成する筐体それぞれと行うことにより、通信パフォーマンスを最適化することができます。

2つ目のCLBと、3つ目のAPLBについては一連の処理となりますので、次へ続くということで、続きのエントリーにてまとめてご説明したいと思います。

ツイートする

Permalink | コメント(0) | トラックバック(2) | 00:55

■[Virtualization]vSphere 5.0 - Auto Deploy

あー…忙しさに追われて、1ヶ月以上エントリーに間隔が空いてしまいました。本当はvSphere 5.0 概要シリーズをリリース前に終えるつもりでいたのですが、終えるどころかStorageだけ書いてそこで止まってしまっています…(もし楽しみにして頂けていたとしたら、すみません)。アウトプットするのも大変なんですが、アウトプットしないのもいろんなモノを溜め込んでしまうのでなんとも悶々としてしまいます。

さて、今回は概要シリーズからちょっとはずれてAuto Deployについて絞り込んで短めのエントリーを書きたいと思います。

Auto Deploy機能のベースはPXEブートによるイメージの展開なので、そこには特に新しさはありませんが、ポイントはイメージとホストのプロファイル情報の管理を統合したことによってディスクレスサーバに対するパッチやモジュールの展開や、設定情報の修正などの「運用フェーズにおける変化」に対応できる仕組みとなっている点でしょう。もちろん、展開時だけでは運用は成り立ちませんので、VMwareは他にも様々な機能を用意することによって、Auto Deployを用いた展開を使用しても運用が成り立つようにしています。

具体的には、インストールファイルや修正パッチ、サードパーティ製を含めたモジュールの構成などをまとめたイメージプロファイル、個別ホストの設定情報を管理するホストプロファイル、ログファイルやコアダンプをリモートに出力する仕組み、そしてvCenter側で持っているホストに対する管理構成の4つの機能をひとつなぎとすることで仕組みがつくられています。

現時点のAuto DeployはvCenterの機能としては完全には統合されていないため、基本的にはPowerShellベースのコマンド操作により管理を行う必要があります。ま、コマンド操作もいいんですが、vSphere ClientからGUIで管理したり確認したりすることができるようになれば、よりこの機能を使用するユーザが増えるのではないかとは思っています。まぁこの機能を使おうとするようなユーザであれば、コマンドでの管理で問題はないのかもしれませんが…(^_^;)。

Auto Deployは、PXEブートによりDHCPリクエストとTFTPによるgPXEイメージのロードに続いて、httpリクエストが届けられるところから始まります。gPXEイメージはAuto Deployを構成するモジュールの1つとして提供されますが、DHCPサーバおよびTFTPサーバの機能については既存のものを使用することになります(vCenter Applianceを使用する場合は、TFTPサーバ機能なども組み込まれています)。

リクエストを受けたAuto Deployは、そのホストを登録するクラスタを判断し、使用するイメージプロファイルとホストプロファイルを選択します。初回ブート時はプロファイルを収集してきますが、2回目以降は自身にキャッシュした情報を使用します。

イメージプロファイルに基づいてロードされたホストに対して、ホストプロファイルを適用することでホストは個別情報を持ち、個別化されます。イメージプロファイルとしてロードするイメージにVIBを組み入れることが可能ですので、サードパーティ製のドライバやモジュールなどもまとめて展開することが可能です。また、ホストプロファイルはかなり詳細な構成についても含めることができるようになったため、たとえばiSCSIソフトウェアイニシエーター使用時におけるバインディングやJumbo Frameの構成、詳細設定で定義するような項目などについても問題なく適用することができます。

そして最後にvCenterサーバに対してホストを登録し、クラスタ関連の定義を反映させればAuto Deployを使用したホストの展開は完了となります。

イメージプロファイルもホストプロファイルもホストに対して直接設定することなく構成することが可能なため一元的な管理が可能となるメリットはありますが、その分Auto DeployおよびvCenterサーバに全てのホストのプロファイル情報がまとめられるため、これらの情報はしっかりと管理する必要があります。

PowerCLIのAuto Deploy関連コマンドそのものについても書こうかと思いましたが、それはまた追々m(_ _)m。

次回は中身が完全リニューアルされたVMware HAについてでも書きたいなとは思いますが、いつものことながらどうなることやら…。

ツイートする

Permalink | コメント(0) | トラックバック(0) | 23:42