Simple is Beautiful このページをアンテナに追加 RSSフィード

2005 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2012 | 01 | 02 | 04 | 05 | 07 |
2013 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 09 | 10 | 12 |
2014 | 01 | 02 | 03 | 04 | 07 | 08 | 09 | 11 | 12 |
2015 | 01 | 02 | 04 | 05 | 06 | 12 |
2016 | 01 | 11 | 12 |
2017 | 03 | 04 | 05 | 06 |

2017/04/20 (木)

[] vCenter Server Appliance のアップグレード 6.0 -> 6.5

SUSEベースからPhoton OSベースに変わるので、一時的に別IPアドレスで仮想アプライアンスをデプロイしてデータを移行することになるわけだけれども、まぁ色々とハマりどころはある。

が、色々ある中で、何をまずやっておけばいいかといえば、VCSA6.0仮想アプライアンスのrootアカウントのパスワード変更。vSphere 6.5のリリースノートにも下記のように記載があるので、おそらくこれが原因で上手くいかない場合が多く発生しているのではないかと推測している。

-Attempts to upgrade a vCenter Server Appliance or Platform Services Controller appliance with an expired root password fail with a generic message that cites an internal error

During the appliance upgrade, the installer connects to the source appliance to detect its deployment type. If the root password of the source appliance has expired, the installer fails to connect to the source appliance, and the upgrade fails with the error message: Internal error occurs during pre-upgrade checks.

Workaround:

  1. Log in to the Direct Console User Interface of the appliance.
  2. Set a new root password.
  3. Retry the upgrade.

日常操作的にはまったく問題なくrootアカウントでのSSHログインなどはできるので気付きづらいが、vCenterサービスに対するSingle Sign-onとしては有効期限が切れている場合、サービスの制御ができないのでアップグレード処理(Pre-upgrade check)に失敗する。

f:id:takaochan:20170420143703j:image

VCSAのrootパスワードそのものがわからん!もしくはログインすらできん!という場合はKB2069041参照。

この点以外にも、リリースノートに書かれている "Upgrade Issues" の項目はどれもアップグレード作業実施前に目を通しておいて損はない気がする。リリースからこれまでいろいろな人達が踏んできた課題の主な項目そのものだと思われるので。

2013/12/23 (月)

[][]分散スイッチングと分散ルーティング (3)

さて、このシリーズを終わらせないと年が越せない(^_^;)ということで、vExpert Advent Calendar連続投稿中の @interto さんにも鬼振り?されちゃったりしていますが、今年最後のエントリーになるかもですがいってみましょー。

すでに何を書くつもりだったのか半ば忘れているのですが、前々回のエントリーで「オーバーレイプロトコルと集中管理を組み合わせることによって、何が可能となるのか」について書くと予告していたみたいなので、そのあたりから始めてみます…。ただ、せっかく広げるなら今年最後だし最大限の大風呂敷を!ということで、オーバーレイプロトコルに限らず、OpenFlowでもSDNでもなんでもいいんですが、様々な方式を使ったネットワークの集中管理によって、何が可能になるのか、考えてみたいと思います。風呂敷広げすぎて、もはや畳めない、というオチになりそうですし、そもそもタイトルの分散スイッチングと分散ルーティング、からすでにだいぶ乖離してしまっている気もしますが…気にしない!

なお、本エントリーではWANやオフィス/キャンパスネットワークではなく、基本的にデータセンターネットワークを対象にしております。

集中管理されたネットワークのメリットとデメリット

そもそも、なぜデータセンターのネットワークを集中管理したいのでしょうか?それは、サーバ仮想化などによってインフラを動的なリソースとして扱う様になってきたことに伴って、ネットワークもまた同じように、よりリソース的に扱いたいから、つまりは動的な変化と拡張に対応させたいから、といった感じではないでしょうか。さらには、集中管理することによって、次のステップとしての自動化がより実現しやすくなるから、ということも理由といえるかもしれません。

ネットワークの集中管理をするべきなのかどうか、その判断基準はネットワーク規模の大小、ではありません*1。どちらかといえば、メリットの大小、こそが重要なポイントです。つまり、ネットワークを集中管理することによって得られるメリットがとても大きいのであれば、小規模のネットワークであったとしても集中管理を検討すべきですし、逆にどんなに大規模なネットワークだとしても自律分散動作の方が適しているのであれば、ネットワークは集中管理に移行するべきではない、といえます。

また、集中管理=自動化ではないことは理解しておく必要があるでしょう。前述したとおり、確かに集中管理することによって自動化へは一歩前進することができます。なぜならば、管理対象への接点が1箇所になることによって、自動化はより実現しやすくなるから、です。しかし、集中管理されたネットワークは、単にそれだけでは自動化には結びつきません。また、何でもかんでも管理しようとすることは、逆に自動化を阻害することにも繋がる場合もあり得ますので注意が必要です。たとえばOpenFlowはフロー制御を集中管理するための仕組みを作ろうとしている取り組みですが、全ての通信に対してOpenFlowによってルールを定義しようと思ったらおそらくそれは非常に困難であり、自律分散に基づくネットワークよりも大きなメリットにはなり得ない場合もあるかもしれません*2

単に複雑性にはふたをしてしまおう、というアプローチにも注意が必要です。たとえば、物理ネットワークのトポロジーを一切意識する必要のない論理ネットワークをオーバーレイによって実現する手法はとても便利ですし、手軽に実現できる「自由にネットワークを構成する」手法ではあるのですが、この手法をネットワーク全体に広げるべきなのかどうかはよく考えてから行うべきであるといえるでしょう。たとえば、VMwareは先日、『VMware NSX Virtualization Network Design Guide』(PDF)というドキュメントを公開しましたが、このドキュメントにおいては、VMware NSXを導入するネットワークにおいては、その基板となる物理ネットワークとしてはいわゆるSpine-Leafトポロジーのフルメッシュアクティブなネットワーク(つまりはEthernet Fabric構成)を構成することが望ましいと記載されています。オーバーレイのネットワークであっても、最終的にはパフォーマンスや安定性などの性能は物理ネットワークに依存するため、(理論的にはIPリーチャビリティさえあればどんな物理ネットワークでも可、とはいえども)物理ネットワークにはボトルネックのない、フラットかつスケールするネットワークが必要とされます。

f:id:takaochan:20131223082717p:image

また、オーバーレイによる論理ネットワークは、仮想マシンと同様に自由に、手軽に構成・追加できるが故に、いわゆるスプロール現象ともいわれる、無秩序な増加が起きてしまう可能性がありえます。VXLANなどのオーバーレイプロトコルによって、VLAN数という制約は超えられるかもしれませんが、それでもむやみなネットワークの増加は、セキュリティ面でも問題を引き起こす可能性があるなどのため、仮想マシンの増加以上に望ましくはない状態となる可能性があり得ます。運用管理にオーバーレイネットワークを組み込むのであれば、ネットワークの追加だけではなく、管理ルール、そして不要になったネットワークの適切な削除までを含めて管理できる方法を明確にしておくべきです。

また、論理ネットワークを構成する、ということは物理ネットワークとは別の、しかし物理ネットワークの影響を受ける新たなネットワークを増やすということに他なりません。それぞれをどういうポリシーで、誰が、どのような方法で管理するのか。それぞれのトポロジーをどう把握し、トラブルシュートや影響範囲の対応は問題なく行うことが可能か、など、導入するのであれば考慮すべき事項は多くあります。

このように、気軽に新しいネットワークを構成することができるということは、大きなメリットであると同時に、デメリットにもなり得る、という点をしっかりと理解した上で集中管理されたネットワークの導入は検討されるべきです。

なぜネットワークを集中管理したいのか?

結局のところ、何のためにネットワークを集中管理したいのか、その目的がぶれないようにすることこそが重要でしょう。ネットワークの管理は、目的ではなく手段であるべきです。ビジネスのスピードに対してITインフラ提供のスピードが足を引っ張っていて、その原因がネットワークの構成や管理に時間がかかることにあるのであれば、ネットワークの管理方法について改善を検討すべきであり、その結果として集中管理する手法が適していると判断したのであれば、そこで始めて「どうやってネットワークを集中管理するか」の検討を始めるべきなのです。

ネットワークを集中管理する方法には様々な手法があります。ネットワークの集中管理、というとらえ方を、単に1箇所にControllerとなる要素を配置するという方式だけに制限せずに、複数台のデバイスから構成されるネットワークを一体化して管理するバリエーションと捉えれば、ハードウェア中心の取り組みからソフトウェア中心の取り組み、両者を組み合わせた方式、オープンソースプロジェクトからベンダーによる独自実装まで、まさに様々、です。

  • 独自管理ツールによる構成管理
  • 裏側では単にTelnet/SSHでネットワーク機器に接続してコマンドによる構成を投げ込んでいる類のツールを使った構成管理
  • SNMPによる構成管理
  • NETCONFによる構成管理
  • OpenFlowによる構成管理
  • onePKなどのオープンではあってもベンダー独自のAPIによる構成管理
  • Cisco FabricPathやBrocade VCSなどといったTRILLベースのEthernet Fabricネットワーク
  • AvayaやHuaweiなどのSPBベースのEthernet Fabricネットワーク
  • Junipar QFabricなどの独自ベースのEthernet Fabricネットワーク
  • Cisco Application Centric Infrastructure (ACI)によるオーバーレイプロトコルも包含したEthernet Fabricネットワーク

などなど…。

f:id:takaochan:20131223085140j:image

どの方式を選択するのか、選定のポイントはコストパフォーマンスやらベンダーロックイン回避やら、ユーザによって重要視するポイントは色々あるでしょうが、結局のところは最もユーザにとってもメリットが大きいと判断した方式を選択することになるでしょう。もちろん、メリットだけではなくデメリットもしっかりと確認し、妥協できない点があるのであれば、そもそも集中管理方式を選択しない、という選択肢もあるはずです。

また、点を統合するサーバ仮想化に対して、ネットワークは面を構成する要素であるため「他に影響を与える要素」です。サーバであれば物理から仮想に変わっても、影響を受けるのはそのサーバ自身と、そのサーバとの通信を行うシステムやユーザに限られますが、ネットワークは点と点をつなぎ合わせる線の集合としての面、ですのでサーバ仮想化のようには、単純に物理から引きはがす、ということは容易ではありません。合わせて、本エントリーシリーズのタイトルでもある分散スイッチングや分散ルーティングなどの技術も、整合性を確保するためには基本的には対象範囲のネットワーク全体が集中管理されているからこそ実現できる方式といえます。

ネットワークの目的は点と点を結びつけること、ですが、現在ではそこに様々な要素が複雑に介在しています。セキュリティ、パフォーマンス、暗号化、ロードバランシング、最適化、帯域制御、等々…。ネットワークの集中管理は、柔軟性や拡張性といった大きなメリットを得ることができますが、単純な「点と点を結びつける」ネットワークならまだしも、これらの様々な要素が結びついたネットワークを集中管理したいと考えるのであれば、必要としている要素はどのように組み込むことができるのか、きちんと押さえていく必要があります。置き換える手法はあるかもしれませんが、それに伴って利便性が向上するなどのメリットが生まれるのかどうかも重要な考慮点です。

究極的には、ユーザにとって、さらにはビジネスにとって価値がある、利便性が向上する、課題が解決する、それらの目的のために、メリットを提供することができるネットワークの集中管理とはどういう方式なのか。コストパフォーマンスはどの程度なのか。その方式にすることによるデメリットはどういう部分で、それは許容できたり、妥協できるものなのか。技術の進歩は日進月歩であり、今、解決できていない問題であっても、近い将来、それを解決する技術が登場するかもしれません。選択肢は数多く、どうしても決断が必要な部分はいつであっても出てくるでしょうが、軸とする目的の部分だけはぶれることのない判断が必要でしょう。

サービス化していくITリソース

ネットワークを集中管理するやり方には様々な方式があり、OpenFlowとEthernet Fabricなんかは対極にあるような気もしてしまうのですが、意外と目指している方向性は似たような感じで、使い分けというか、融合というか、次第に実用的で現実的?な仕様と実装に終着しつつあるように思えます。管理手法としても、GUIの見た目や操作性などに注目が向くのですが、CLIの使い勝手やトラブルシュート性、Scriptingのためのインターフェイスやバリエーション、そしてなんといってもAPIのオープン性など、総合的な管理性を持っていることがより重要になっていくでしょう。

ITインフラを構成する要素としては、ざっくり分類するとOS/Hypervisor、サーバ、ネットワーク、ストレージといった感じに分類できるかと思いますが、これらの中で、ネットワークはCLIに最適化されすぎていたが故に、GUIAPIなどといった他のインターフェイスへの対応が遅れていたのかもしれません。しかし、ここ数年で急速にネットワークは集中管理への対応と合わせて、それらへの対応が急速に充実しつつあります。API制御されたネットワークがどのような使われ方をするようになるのか、その下準備が急速に進んだ2013年から、その使われ方が次第に明確になっていくであろう2014年へと、まだまだネットワークまわりは興味深い動きが続くことになるでしょう。

f:id:takaochan:20131223085141j:image

正直、これまでのPrivate Cloudは、Public Cloudの後追いというか、ぶっちゃけ劣化コピーのような感じがあったような気がします。しかし、ITインフラリソースを所有しない・管理しないということから得られるメリットに対して、ITインフラを所有し管理することによって得られる自身のために最適化されたITリソースのメリットはもっとあってよいと思います。

PublicにしろPrivateにしろ、ITリソースはよりサービス化することが求められるようになっていくでしょう。新しいネットワークのカタチが、どのような使われ方をされるようになっていくのか。楽しみですね。

The tomorrow's entry of vExpert Advent Calendar return to @interto .

Merry Christmas!! & A Happy New Year!!

今年も1年間、ありがとうございましした。来年も、よろしくお願いします。

*1:もちろん、人間による人海戦術ではもはやどうすることもできない超大規模環境においては、もはや考えるまでもなく自動化が必要であり、その手法としてネットワークの集中管理は使用されているわけですが。

*2:そもそもの問題点としては、エントリーできるフロー数には制限があり、大規模環境が必要とするすべてのフローをプログラマブルに制御することは事実上困難です。自律分散制御の中に、意図した制御のための処理のためにフロー制御を混ぜ込むような使い方が現実的なのかもしれません。

2013/01/31 (木)

[][]Nexus 1000V 事始め

さっそく週1回更新の目安から遅れが生じ始めております…(^_^;) まぁ無理してまでは書くつもりはないのですが、なによりもアウトプットすることによって自分の中で整理がつけられるメリットは大きいので、気合いを入れすぎずに続けられたらとも思っています。自分のために…m(_ _)m

さて、ちょうど数日前に最新バージョンの日本語版のNexus 1000V 4.2(1)SV2(1.1) インストレーション アップグレードガイドがリリースされましたので、今回はNexus 1000Vについてです。というか、Nexus 1000Vは実は?かなり奥深いので、今回のエントリーではほんのさわり部分についての紹介までとなります。

本当は、まずはとても簡単に行うことができる「Nexus 1000Vのインストール方法」について書こうかと思っていたのですが、インストールそのものは簡単でも まずはNexus 1000Vの構成するために必要な環境やパラメータ項目について把握していないと、その簡単さが逆に伝わりづらいかと思いましたので、まずはその辺りから、です。

Nexus 1000VはCiscoが提供するHypervisor向けの拡張 分散仮想スイッチです。各種Hypervisor向けのNexus 1000Vが提供済もしくは提供予定となっていますが、今回はひとまず 最も先行して提供が開始されているVMware vSphere向けのNexus 1000Vを前提として書いていきたいと思います。

なお、現在Nexus 1000VはEssential EditionとAdvanced Editionの2つのEditionが提供されており、Essential Editionは無償での提供となっています*1。Essential Editionといっても、VLAN, ACL, QoS, LACP, SPAN/ERSPAN, NetflowなどのL2機能一式と管理に必要となる一通りの機能は全て含まれていますし、さらにはVXLANやvPathなどといったNexus 1000Vの大きなウリ機能、vCenter Plug-inやvTrackerなどのVMware連携機能についても使用可能です。ぶっちゃけ、ほとんどの環境においては、Essential Editionで十分かもしれません(^_^;)*2。でも、Advanced Editionに含まれるVSG (Virtual Security Gateway)はとても便利です!

f:id:takaochan:20130131001323j:image

ただ、誠に残念ながら、Nexus 1000VのEssential Editionが無償になっても、VMware vSphere側が3rd Party製を含めた分散仮想スイッチ機能を最上位EditionであるEnterprise Plusでのみ使用可能な機能の1つとしているために、継続的にNexus 1000Vを使用したい場合はVMware vSphereのEnt+ライセンスが必要となります。が、まぁ期限付きの検証などであれば、Nexus 1000V側もライセンスなどを登録することなくEssential Editionとして使用できますので、評価・試用の範囲であればすぐにお試し頂けます。

さて、本題。インストールするために必要な前提知識をざっと編、です。

Nexus 1000VはVSM(Virtual Supervisor Module)とVEM(Virtual Ethernet Module)の2つのモジュールから構成されています。

VSMはその名の通りSupervisorの役割を果たすモジュールで、実体はOVAファイル形式で提供される仮想アプライアンスです。分散仮想スイッチはvCenterに管理されている多数のESXホストから構成される、仮想化環境全体の通信を一元的に制御する重要なスイッチ階層におけるコントロールプレーン扱いとなりますので、ハイエンドのコアスイッチとして用いられるNexusやCatalystと同様に冗長化を構成することが可能です。VSMでは、Nexusシリーズに共通するNX-OSが実行されます。

もう一方のモジュールであるVEMは、各ESXホストにインストールするVIBパッケージです。VSMがコントロールプレーンであるのに対して、VEMはいわばスイッチング処理のためのラインカード的な役割を果たします。VIBによってESXにインストールされるVEMは、Hypervisorに組み込まれるカーネルモジュールと、VSMとの連携などを管理するユーザランド側のVEMエージェントから構成されています。VSMによって管理される各ESXそれぞれに配置され、VSMによって管理されますが、スイッチング処理自体はVSMを経由したりすることはありません。

f:id:takaochan:20130131001322j:image

VSMは仮想アプライアンス、つまりは仮想マシンですのでCPU/RAM/HDD/NICそれぞれ必要構成があります。特にネットワークについては3つのNICを構成し、それぞれコントロールVLAN、パケットVLAN、管理VLANの3つのネットワークに接続するよう構成します。それぞれのネットワークの用途は以下の通りです。

  • コントロールVLAN…VSM-VEM間のコントロールメッセージ交換に使用されるネットワーク
  • パケットVLAN…VEMからVSMへのCDP等のパケットを転送するために使用されるネットワーク
  • 管理LAN…VSMとvCenterサーバ間の接続や、SSHなどでの管理接続を受けるために使用されるネットワーク

仮想的なモジュールスイッチとなりますので、いわゆるファブリックバックプレーンなどはありません。そのため、ネットワークをファブリックとして使うためにこうしたちょっと特殊なネットワーク構成を必要とする、といえるかもしれません。

VSMはL2コントロールモードもしくはL3コントロールモードのいずれかで構成します。L2コントロールモードの場合は、VSMとVEMは必ず同じサブネット範囲に接続している必要があります。L3コントロールモードの場合は、VSMとは異なるサブネットにVEMを配置することができます。L3コントロールモードの場合は、パケットVLANは使わずにVMkernelを通じてVSMとVEMが通信します。L3コントロールモードであってもL2環境で使用できますし、パケットVLANも不要となりますので、基本的にはL3コントロールモードで構成することが推奨されています*3

なお、VSMを冗長構成で構成する場合でも、プライマリとセカンダリはActive/Standby形式で動作するため、IPアドレスは1つのみ必要となります。ただし、L3コントロールモードであっても冗長構成のVSM同士を別のサブネットに配置することはできません。

ま、だいたいこれくらいを理解しておけばNexus 1000Vのインストールを構成することができます!(^_^;)。

*1:2.1より。Essential Editionに対して有償となりますがサポートを付加することも可能です

*2:Advance Editionでのみ使用可能な機能としては、TrustSec SXP対応やDHCP snooping, IP Source Guard, ARP Inspectionなどがあります

*3:標準インストールでインストールする場合は、自動的にL3コントロールモードでのインストールが行われます。

2012/05/07 (月)

[][]「できるPRO VMware vSphere 5」のご紹介 - 5/8発売

ネットワールドのシステムエンジニアの方々が書かれた「できるPRO VMware vSphere 5 (できるPROシリーズ)」が明日5/8に発売されます。

同じシリーズの「できるPRO Vmware vSphere 4 (できるPROシリーズ)」が発売されたのが、2009年10月でしたら、それからすでに2年半が経過、vSphere 5がリリースされてからもすでに半年以上が経過していますので、やっと(^_^;)の発売です。なお、本エントリーはここで紹介することを条件にして本書をタダで頂いてしまいましたので、そのお約束を果たすために書いています(多少、宣伝っぽい書き方になっていますが、ステマではありませんので明記させて頂きます)。もちろん、いい書籍だと思うから書いていますよ!

本書は始めてVMware vSphere 5を触ってみる方向けの内容となっており、評価ライセンスを使って一通りの機能について触ってみる際に活用できる章立てとなっています。本格的な導入を前に、とりあえず評価してみたいとお考えの方や、VMwareの他の製品を使用されていた方がvSphereにも取り組んでみようとされる場合などに活用できるのではないでしょうか。

全体的な章立ては、以下の通りです。

  • 基礎知識編
    • 第1章 VMware vSphereについて知ろう
  • 構築編
  • 拡張編
    • 第7章 VMware vCenter Serverをインストールしよう
    • 第8章 共有ディスクを利用しよう
    • 第9章 仮想マシンを展開しよう
    • 第10章 仮想マシンを移動しよう
  • 運用・管理編
    • 第11章 可用性を高めよう
    • 第12章 バックアップをとろう
    • 第13章 VMware vSphereのライセンスを適用しよう

第1章は サーバ仮想化とは、から始まって、VMware vSphereの全体的な機能の紹介、ライセンスモデル、VMware vSphereを用いたシステム構成についての考え方などが紹介されています。さすがライセンスを販売する販社でもあるネットワールドさんによる執筆なので、ライセンスについての説明は丁寧に書かれています(こういう場合はどう考えればいいの?というパターン例もいくつか紹介されています)。vRAMなど、vSphere 5から新しく導入されたライセンスモデルや、vSphere 4から変更されたエディションと機能の紐付けなどがありますので、すでにvSphere 4を理解されている方も改めてざっと目を通しておくとよいかもしれません。

第2章からは具体的にインストール〜基本設定の解説に入っていきます。ESXi 5.0を導入するために必要なハードウェア要件から始まり、VMwareウェブサイトでの評価版ライセンスキーの申請・入手方法、バイナリファイルの入手手順なども丁寧に画面キャプチャ付きで紹介されているところが「できる」シリーズらしいところです(^_^;)。ESXiのインストール自体は非常にシンプルですが、とりあえず触ってみている方には、こうして画面キャプチャ付きで手順を紹介してもらえると、迷うことなく操作を進めることができるかと思います。

第3章では、インストールされたESXiを管理するために使用するvSphere Clientの導入から始まり、vSphere Clientを通じたESXi管理画面について一通り紹介がされた上で、SSHでの接続方法や再起動・シャットダウン方法などについてが説明されています。

第4章では、ゲストOSの導入手順として、WindowsとLinuxの代表例としてWindows Server 2008 R2と、CentOS6.2を仮想マシンに導入する流れが説明されています。ここで作成した2つの仮想マシンをそのまま使用するかたちでこの後の章が作られていますので、実際に本書を片手にvSphereの評価をされる方はここでちゃんと両方の仮想マシンを作成しておくことをオススメします。

第5章では、初期インストール時では一定範囲だけのカスタマイズであった仮想マシン構成について、より細かく構成する方法が紹介されています。ディスク容量の変更や新しい仮想ディスクの追加、メモリの増量やネットワークアダプタやUSBの構成、CPUの追加、さらにはスナップショットの利用など、仮想マシンならではの柔軟なリソース構成変更や管理が可能であることが、本章の操作を通じてご理解頂けるのではないかと思います。

第6章では、仮想マシンをネットワークに接続するために理解する必要がある、仮想スイッチやポートグループなどについて説明がされています。

仮想化とはいわばこれまでなかった新しいレイヤーを導入することとなりますので、ハードウェアともOSとも異なる新たな階層を管理するということはどういうことなのか、第2章〜第6章までの構築編を通じて、具体的に体験頂ける流れとなっています。

第7章からは、vSphereを活用する上では欠かせないvCenter Serverによる統合的な管理を行う形式についての解説が始まります。第7章はvCenter ServerのインストールからESXiの登録や管理画面の紹介、そしてvSphere Web Clientの使用方法などについてが説明されています。なお、本章では第4章で仮想マシンへ導入したWindows Server 2008 R2を使用する形で説明がされていますので、仮想マシン的な操作と導入されたvCenter Serverを通じた操作がごちゃ混ぜになってしまわないようきちんと整理して理解を進めて下さい…(^_^;)

第8章では、複数台のESXホストを統合的に使用する上では必須とも言える共有ディスクについての解説がされています。FC / iSCSI / NFS などが仮想マシンを配置するためのデータストアとして使用できるため、ここではイメージを掴んでもらうために正式にサポートされる構成ではありませんが、CentOS(しかもゲストOSの…)をNFSサーバと仕立てて接続してみるおためしパターンが紹介されています。

第9章では、仮想マシンの展開(クローン及びテンプレート、仮想アプライアンスのインポート)方法、その際に使用することができるゲストOSのカスタマイズ方法、vCenter Converter Standaloneを用いたP2VやV2V方法などが解説されています。それぞれに執筆の担当範囲が分担されているからかと思いますが、なぜか全体的な記載レベル感と比較してけっこうvCenter Converterによる移行方法が詳しく書かれています。

第10章では、移行(コールドマイグレーションとホットマイグレーション)方法についてさらっと紹介されています。

第7章〜第10章の拡張編は、サーバの仮想化機能そのものではありませんが、仮想化を活かすためにはかかせない機能が一通り紹介されています。この段階こそが、仮想化のメリットというか、仮想化を行うことの価値とも言える部分ですので、考え方によってはここが最も重要な部分といえるかもしれません。

第11章では、複数台のESXホストから構成される仮想化インフラを個別のサーバ単位ではなく「インフラ」として扱うためのベースとなるクラスタという概念についての説明から始まり、vSphere HAおよびvSphere FTについて解説されています。これらの機能は物理的なサーバからOS環境が切り離されているからこそ実現できる機能であり、仮想化の面白さというか、柔軟性を生み出すポイントともいえる部分です。

第12章では、バックアップについて、ライセンス的にはEssentials Plus以上(フルに活用するためにはHot-addが必要となりますので、Enterprise以上となってしまいますが…)で使用することができるData Recoveryを使ったバックアップとリストア方法について書かれています。Data Recoveryは機能も限定されたバックアップツールですが、VMware標準のツールなだけあって、vSphere Clientを通じて管理ができることや、Windows / Linux それぞれに対応したファイル単位でのリストア機能もあること、重複排除などの先進機能を標準的に使用できることなど、けっこう使い勝手の良いバックアップツールです。

そして最後の13章では、ここまでの評価で本格的にvSphereを導入するのでしたらライセンスを適用してね、ということでライセンスの適用方法が。さすがです…。

全体的に本書の特徴でもある点が、操作手順を追う流れが重視されており、「なぜそうするのか」や「どうしてこうなるのか」などについての説明は最小限にとどめられています。まずは触ってみて、ざっくりと「どんな感じなのか」、「どう操作すれば良いのか」を体験してもらう際の手引きとして使用頂くことを想定した作りのために、流れを重視してあえてそういう記載方法がとられているのかと思っています。ぜひ本書を通じて一通りの操作について体験された方で、より本格的にVMware vSphereの世界に入っていこうとされる方は、「どう操作すれば良いのか」のレベルからさらに一歩踏み込んで、「なぜそうする必要があるのか」を考えながら、そして調べながら改めて手順をおさらいしてみると、よりスキルが身につくかと思いますし、より理解が進むのではないかと思います。

最後に、本書の執筆メンバーでもあり、本書を私に渡してくれた工藤さんの好きなvSphereの機能「vhv.allow = "TRUE"」はぜひググってみることをオススメします(^_^;)。我が家もそうですが、一定の要件とリソースさせあれば1つの物理マシン上に沢山のESXやその他の仮想化Hypervisorが…

2008/09/20 (土)

[][]Vyatta 4.0.2を使ってみました。

都合があって仮想マシンでFirewall Routerを作りたかったので、どれにしようかなーと考えてVyattaのCommunity Editionを選択。VyattaはLinuxをベース(とはいえ、完全にカスタマイズされている)としたソフトウェアルータ(アプライアンス版もある)だが、非常にハイエンドかつ高機能・多機能。Community Editionといってもサポートや修正パッチの適用が限定的なだけで、機能的な制約はほぼないらしい。

Vyattaウェブサイト

今回は仮想マシンとして作成するので、元々仮想マシンイメージ化されているzipファイルをダウンロード。Vyattaのダウンロードはこちらから。仮想マシンイメージは"VC4 - VMware Virtual Appliance"とあるリンクからダウンロードできる。

ドキュメントもこちらからダウンロードできる。"Quick Start Guide"はすぐダウンロードできるが、"Command Reference"は登録が必要。

VyattaCommunityEdition4.zipをダウンロードして解凍、このVirtual ApplianceはOVFではなく普通の仮想マシンイメージで提供されているので、VMware仮想マシンとして登録すればOK(ESXな人はV2V的にインポートしてくださいな)。

NICの接続構成や不要なデバイスを整理するなど、仮想マシンの構成を整えてから起動。デフォルトで"root"アカウントと"vyatta"アカウントが登録されていて、どちらもデフォルトパスワードは"vyatta"。

Vyattaは"Operation Mode"と"Configuration Mode"で構成されている。ログインして最初はOperation Mode。ネットワーク機器のお約束というか、"?"でコマンド一覧が表示される。コマンドのtab補完も機能しているし、コマンドも整理されているので直感的だ。

基本コマンド

  • Operation ModeからConfiguration Modeへのモード変更
$ configure
  • 設定内容を反映
# commit
  • 設定内容を保存
# save
# save Hoge (標準config以外への保存を行う場合)
  • Configuration ModeからOperation Modeへのモード移行
# exit
# exit discard (設定内容を保存せずにexitする場合)

さて、では基本設定。

  • ホスト名を設定
# set system host-name HogeHoge
  • ドメイン名を設定
# set system domain-name HigeHige.local
  • ユーザアカウントにパスワードを設定
    • プレインテキストでパスワードを設定しても、commitした段階で暗号化される
# set system login user **** authentication plaintext-password ######
# set interface ethernet eth0 address 192.168.1.0/24
  • DNSを設定
# set system name-server 192.168.1.100
  • Default G/Wを設定
# set system gateway-address 192.168.1.254

つづいて色々な拡張的な?設定

# set service ssh
  • DHCPサーバを設定
# set service dhcp-server shared-network-name HOGE subnet 192.168.100.0/24 start 192.168.100.101 stop 192.168.100.199 
# set service dhcp-server shared-network-name HOGE subent 192.168.100.0/24 default-router 192.168.100.254
# set service dhcp-server shared-network-name HOGE subent 192.168.100.0/24 dns-server 192.168.100.10
  • NAT設定
# set service nat rule 1 soruce address 192.168.100.0/24
# set service nat rule 1 outbound-interface eth0
# set service nat rule 1 type masquerade

さて、最後にFirewall設定。VyattaのFirewallはルールセットを作成してそこにルールとして定義を構成していき、設定したルールセットをInterfaceを通過する3種類の通信に対して適用する形式になっている。3種類の通信はin, out, local。"in"はそのインターフェイスに対して入ってくる通信、"out"はそのインターフェイスから出て行く通信、そして"local"はそのインターフェイス自身に対する通信。これらの定義を各インターフェイスに定義すればFirewallが定義できる。

以下は初期設定として使えるであろうダダ通し定義がされたルールセット。本来Firewallは「許可した通信以外は遮断する」ことが常識だろうが、まぁまずは使ってみて理解するためにはいいかな。

  • Firewallルールセットの作成
# set firewall name SAMPLE
  • Firewallルールセットにルールを作成
    • ルールは1〜1024の数字で管理される。つまり、1つのルールセットに対して最大で1024個までのルールが定義できる。当然ながら?ルールは1から順番に判断に使用されていくので、最初は数字の間隔を開けて定義することが推奨。あとから間にルールを定義できる。
# set firewall name SAMPLE rule 10
  • ルールに許可・拒否・遮断の3種類のアクションを設定(以下は許可の例)
# set firewall name SAMPLE rule 10 action accept
  • ルールに内容を設定(以下は全てのプロトコルを設定する例)
# set firewall name SAMPLE rule 10 protocol all

以上で設定したFirewallルールセットはこんなかんじ。

# show firewall name SAMPLE
name SAMPLE {
     rule 10 {
         action accept
         protocol all
     }
}

ここからは作成したFirewallルールセットをインターフェイスの通信に対して適用する。

  • eth1のin通信に対してSAMPLEルールセットを適用する
# set interface ethernet eth1 firewall in name SAMPLE

これでcommitすれば設定が適用される。

ま、機能はここで紹介した分なぞほんの第一歩なぐらいあるので、いろいろやってみてください。

2008/09/08 (月)

[]オンデマンド検証センター?

Amazon EC3 / S2じゃないけれども、最近は自社の検証施設でも実機を目の前にして作業することは少なくなった。というか、基本的に実機どころか機器が設置されている場所に立ち入って作業することが、物理的な検証が必要な場合以外は基本的にない。インターネット経由で機器を操作できるので、別のオフィスにいても、(嫌だけど)自宅にいても機器を操作することが出来る。そういう意味で、現地に行っても100Km彼方でも出来ることは同じだ。

お客様先で作業するとき以外はディスクメディアを使用することも基本的にない。Deamon ToolsでISOファイルをマウントできるし、仮想化であればISOファイルを簡単にメディアとしてマウントさせられる。データの保管や用意もファイルサーバにどんどん置いておけるし、そもそも現地にいないのだから逆に物理媒体はデータ化してしまわないと使えない。

SSHやリモートデスクトップだけでなく、サーバのリモート管理ツールを使うことによって、再起動操作やBIOSレベルの設定、ファームウェアの適用なども問題なくできる。ストレージ装置などの周辺機器もそのほとんどがWebブラウザインターフェイスかTelnet/SSHインターフェイスがあるので全く問題ない。

唯一物理作業をしないといけないのは配線作業だが、これも基本構成を決めて配線してしまっておいてあとはどうにかするというスタンスで望めばいい。お客様の所に導入するのであればしっかりとした設計が必要だが、検証環境なのであれば(パフォーマンス検証などを実施するのでない限り)極論つながりさえすればいいわけだ。

すでにアプリケーション検証は仮想マシン環境で行われることが多い。数多くのシステムを必要とする検証も、ほとんど仮想マシンでできる。たとえばストレージ接続が必要なマシンだとしても、iSCSIソフトウェアイニシエータでどうにかなる。

サービスの裏側には実体が必ず必要であり、それは今後もなくなることはないが、次第にいかようにでもなる柔軟度が高まってきている。ハードウェアは次第に物理的な制約を乗り越えつつあるが、同時に実体が見えづらくなってきているとも言える。

はたして10年後にはどんなインフラがブームになっているんでしょうね。

2008/01/17 (木)

[]kernek:"Network" (3) sk_buff構造体主なメンバー/netstatによるTCPのステータス

sk_buff構造体の主なメンバー

メンバー名内容
skソケットバッファを持つソケットオブジェクト
tstampパケットの到達時刻
devデータ入出力先デバイス名
hトランスポート層ヘッダー(=TCP/UDPなど)
nhネットワーク層ヘッダー(=IP/ICMPなど)
macデータリンク層ヘッダー(=Macアドレスなど)
data_lenデータ長
mac_lenデータリンク層ヘッダー長
protocol配送に利用するプロトコル
truesizeバッファサイズ

netstatによるTCPのステータス(netstat --tcpコマンドを実行して表示されるState列の表示ステータス)

netstatコマンドのState状態
ESTABLISHED接続状態
SYN_SENT接続試行状態
SYN_RECV接続要求受信状態
FIN_WAIT1ソケットクローズ/切断中
FIN_WAIT2相手側からの切断待ち
TIME_WAIT相手側からの切断再送待ち
CLOSEDソケット不使用
CLOSE_WAIT相手側は切断しており、ソケットのクローズ待ち状態
LAST_ACK相手側は切断、ソケットもクローズ、確認(acknowledgement)待ち状態
LISTEN接続待ち状態
CLOSING自身・相手双方のソケットはクローズしているが、すべてのデータが送られていない状態

netstat実行例

[root@tkcent1 ~]# netstat --tcp
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             State      
tcp        1      1 192.168.3.103:33493         218.150.79.120:http         LAST_ACK    
tcp        1      0 192.168.3.103:56018         203.127.221.98:http         CLOSE_WAIT  
tcp        1      0 192.168.3.103:46381         centos.at.multacom.com:http CLOSE_WAIT  
tcp        0    178 192.168.3.103:33495         218.150.79.120:http         ESTABLISHED 
tcp        1      0 192.168.3.103:56021         203.127.221.98:http         CLOSE_WAIT  
tcp        1      0 192.168.3.103:46377         centos.at.multacom.com:http CLOSE_WAIT  
tcp        1      0 192.168.3.103:46375         centos.at.multacom.com:http CLOSE_WAIT  
tcp        0      0 ::ffff:172.16.108.132:ssh   ::ffff:172.16.108.1:51803   ESTABLISHED 
[root@tkcent1 ~]#