OSベースに変わるので、一時的に別IPアドレスで仮想アプライアンスをデプロイしてデータを移行することになるわけだけれども、まぁ色々とハマりどころはある。ある中で、何をまずやっておけばいいかといえば、VCSA6.0仮想アプライアンスのrootアカウントのパスワード変更。6.5のリリースノートにも下記のように記載があるので、おそらくこれが原因で上手くいかない場合が多く発生しているのではないかと推測している。check)に失敗する。VCSAのrootパスワードそのものがわからん!もしくはログインすらできん!という場合はKB2069041参照。項目はどれもアップグレード作業実施前に目を通しておいて損はない気がする。リリースからこれまでいろいろな人達が踏んできた課題の主な項目そのものだと思われるので。Console)にadministratorアカウントでログインできない場合VirtualizationvSANについて色々どうにかしたい場合に必要になるRVCだが、ログイン時に使用されるドメインはデフォルトドメインとして指定されている対象が使用される。アカウントを意味するということになる。Clientにおいてホームから[管理]-[シングルサインオン]-[構成]配下の[アイディンティティソース]タブを選択し、デフォルトに指定したいドメインを選択して[デフォルトドメインに指定]ボタンをクリックする。設定は即時反映される。その上で、RVCにログインする。以下はVCSAのローカルShellからログインしている場合の例。(2088096)https://kb.vmware.com/kb/2088096その他、諸々の環境からRVCに接続したい場合については、以下のBlogが参考になる。なって起動しない場合の対処方法Server備忘録メモ。はやくフロントエンドのJavaは全部HTML5に置き換わればいいのさ。list]に対象のアドレスを追記してみる以下のあたりをフォルダごとごっそり消してみる。かなっている状態の場合は、おそらくこれで改善する。Source)もちろん、自己責任で。〆を飾る?最終エントリーとなります。参加されたvExpertな皆さん、お疲れ様でした。Calendarが面白いネタで25日間に渡ってリレーされていますので、それらをじっくりと読んでみるのも面白いかもしれませんよ。〆てみたいと思います。ぶっこみすぎじゃね?と言われることがあるんですが、別に私自身はそんなつもりないんですけれどもね。中の人ではないからこそ書けることがあると思っています。NSXはいってみれば「競合」している部分があるのは事実でしょう。別の会社の、それぞれの会社の戦略の中で開発・買収・提供が行われている製品同士なのですから、それはアタリマエのことです。NSXは大半の範囲については異なる位置づけの製品だと思います。言ってみれば、ルータとスイッチぐらいには異なる製品です。ネットワーク製品というくくりでは同じであっても、ルータとスイッチの使われ方や役割は異なることは誰もがおわかりでしょう。NSXは根本的な製品の位置づけが異なると考えています。ACIの視点からみたNSXの位置づけについて考えてみたものとなりますが、世の中にあまりこうした視点でNSXについて書かれた情報はない気がしますので、何か参考になればいいなと思います。NSXは数多くある管理対象として扱うことができるアプリケーションの1つです。ESXiホスト上の仮想マシンに対して様々なサービスを提供するアプリケーションです。NSXはお互いサポート対象ではありませんよね?と言われることがありますが、Windows上で動作するアプリケーションが、そのWindows自身の動作環境となっているハードウェアのベンダーに制約要件を持たない*1ように、NSXというネットワークを使ったアプリケーションをACIがサポートする・しないという制約条件はありません。ACIは主にサーバが配置されるデータセンター向けのネットワークファブリックを基盤としたソリューションです。ACIは連携する・しないはさておき、IPプロトコルを用いた通信である限り*2、あらゆる機器からのあらゆる通信に対応します。UNIXからの通信であっても、物理サーバからの通信であっても、そしてNSXからの通信であっても、そこに区別はありません。ACIはネットワークファブリックとSDNを融合したソリューションです。NSXはSDNとNFVを融合したソリューションといえます。SDN部分で一部重なっている機能がありますが、ACIはNFV的な機能は自身では提供していませんし、NSXはすべてをソフトウェアだけで実現するためにネットワークファブリックは自身で提供していません。製品の思想というか根幹の部分の考え方の違いとしかいいようがありませんが、「一部の仮想化環境のみを対象としたものではない、あらゆるネットワーク接続デバイスすべてを結びつけるネットワーク」に対するSDNは、ネットワークファブリックをベースとしているからこそ可能となると私は考えています。Controllerを制御プレーンとして使用する仕組みになっています。基本的にはOVSDBを拡張したような仕組み?(教えて詳しい人。)を使ってデータプレーンとなるNSX仮想スイッチや、NSX対応した物理スイッチを制御します。Controllerとその共通言語でつながっている範囲でしかそのVXLANを解釈することができませんので、ACIがNSXによって制御されているVTEPによって包まれたVXLANを解釈することは残念ながらできません。MP-BGPを使う仕組みが標準化していけば、マルチベンダーで真の互換性のあるVXLAN相互接続が可能になるかもしれませんが、VXLANはフレーム仕様は標準化されていてもマルチキャストに依存した当初の構成ではネットワークの構成における制約や、柔軟な制御が難しいなどの課題があったため、現時点では各社が独自の制御プレーンの実装を進めてしまうという残念な状況が現時点のステータスです。そもそもの話としてVXLANについて個人的に思うこととしては、VXLANを誰もが必要とするなら、VXLANが登場した当初にみんな飛びついたはずなのです。VXLANが今だにまだ一般化したと言えない理由は、VXLANをVXLANとして意識する使い方は、そんなに多くの人が望んでいるものではないのではないでしょうか。VLANの約4000という壁やら、マルチテナント対応やら、L3を超えたL2接続性やらと、ベンダー側はVXLANのメリットを訴えますが、逆にVXLANの存在を意識させない使い方にこそVXLANの価値はあるのではないかと思います。ACIでもマルチテナントを実現するなどの手段として内部的にVXLANを使ってはいますが、それらを意識して構成・管理するような必要性は全くありません。意識せずに使うことができるVXLANがその裏側にはあるわけです。そんなわけで、ACIはNSXのVXLANを連携によって認識はしませんが、各ESXiホストにあるVTEP間の通信はVLANに紐付いた単なるUTPパケット通信ですので、当たり前ですが認識できます。VXLANになっているのでしょうが、だからどうこうといった問題はまったくありません。EthernetフレームであればL2スイッチング、IPパケットであればL3ルーティングできるという部分は一般的なスイッチと違いは一切ありません。NSX仮想スイッチは分散仮想スイッチに依存していますので、ACIのvCenter連携によって作成された分散仮想スイッチに対してであっても、NSX仮想スイッチの実体としてのポートグループを作ることも可能です。別の分散仮想スイッチを使用することも可能です。UCSでは標準的に使われている論理NIC)を分離するかどうかという構成次第での設計となります。Group)にどの単位でマッピングするのかも自由なところも、NSXを使う場合であってもACIをネットワークファブリックとして使うことのメリットの1つといえます。クラスター単位やポッド単位、ラック単位など、通信量やエラー状況を把握したい単位でNSXがVXLAN通信のためのVTEPポートとして使用するVMkernelのポートグループをEPGにマッピングすれば、ACI側からも通信の量やエラーを把握するヘルススコアなどを把握することが可能となります。EPG間のContractとしてVXLAN通信に使用する4789/utpだけを通す様に構成しておくことで、セキュリティ的にも望ましい状態を作り出すことができます。■NSXのVXLANは使わなくてもいいNSXのマイクロセグメンテーション機能がセキュリティなのかと言われると、私としてはあるなら使ったほうが程度のものだと思ったほうがいいのではないかと思っています。仮想マシン単位の隔離だけでは、なぜ侵入が発生したのか、どういう経路だったのか、どのアプリケーションがどういう動作をして、どこに通信しようとしているのか、そして究極的にどう問題を解決するのか等のセキュリティ的な確認・対応をしてくれるものではないからです。インフラ基盤がvSphereベースなので分散ファイアウォールを使いたい場合や、アンチウィルス連携など仮想化環境と蜜に連携しているからこそ可能となる機能を必要としている方もいるでしょう。NSXを選択する理由としてそれらの機能をつかいたから、という方もいらっしゃるかもしれません。した場合に、ネットワークそのものもNSXのVXLAN機能を使わなければならないかというと、実はそうではありません。NSXのVMkernelモジュールを展開すると、VXLANの構成を行わなくても分散ファイアウォールなどの機能は使用可能となります。Controllerの展開も不要です。Controllerに依存していないからです。Group)とContractによるネットワークのポリシー管理、ACIが提供するハードウェアベースの分散ルーティングやスイッチング、L3接続などの機能を活用し、vSphereだけに限定されない物理サーバや物理ファイアウォール・ロードバランサなども柔軟にネットワークに組み込むことを可能としつつ、分散ファイアウォールを使ってNSXのセキュリティグループを活用することが可能となります。Composerからも、APICのGUIからも、仮想マシン毎に認識することができるようになります。Grapthを組み合わることによって、より柔軟かつ実用的なネットワークを構成することが可能となります。Controllerによって管理できるハードウェアVTEPとして連携できる物理スイッチは、単にNSX仮想スイッチに接続した仮想マシンと通信できる物理サーバを接続できるだけです。NSXを使わなければ、それこそどんなスイッチであってもVLANさえ処理できれば物理サーバと仮想マシンの間で通信できる構成を作ることになんの制約もないのに、NSXにしたが故に拡張OVSDBベースでのNSX連携できるスイッチでないと接続性を構成できないとか、あまりよくわかりません。物理スイッチ連携を使用する場合は分散ルーティングの機能が制限されるなど、組み合わせと構成がややこしい気がします。冒頭にも書きましたが、NSXであっても1つのアプリケーションとして扱ってしまうような、直接的な連携はせずともそれ単体でも様々な機能を提供することができて、必要であれば置き換え/代替することも可能で、NSXにはない機能も提供するACIのようなソリューションを組み合わせておいたほうが、なにかと利用者にとってもメリットが大きいのではないかと思うのですが、いかがでしょうか?NSXを使わなくてもACIは使うことができますし、NSXの機能の多くを置き換えることも可能です。ACIは単なるSDN専用のネットワークソリューションではないので、コントローラによって統合管理されたあたかも巨大なL2/L3スイッチとして使うことができるネットワークファブリックとして使うだけでも多くのメリットを得ることができます。無理してSDN的な使い方やAPI制御、各種連携などをしなければ使えないというものでもありません。話が大きくなりすぎてしまう気もしますが、元々同じコンピュータであったネットワーク・サーバ・ストレージがそれぞれの役割に特化していったのは、それぞれの役割に特化して分離することによるメリットがあったからです。HCIなど、いわゆるエンタープライズ向けの市場において最近はトレンドのゆり戻りの流れの中でこれらの要素を統合する流れであるように思いますが、逆に先を行くクラウドの中ではあらためてハードウェアの機能を活用する実装への揺り返しが進みつつあったりします。どちらがよいとかではなく、いずれにしてもソフトウェアだけ、でもハードウェアだけでもない、それぞれのいい面を上手く引き出していくことが価値を生み出す手段としてより重要になっていくでしょう。ネットワークは、あらゆるネットワークに接続してくる要素(=点)をつなぎ合わせるいわば面ですので、限られた点だけを対象とした面では、全体的な面にはなりえません。ある特定の仮想化基盤、ある特定のアプリケーション、ある特定のシステムのためだけのネットワークを作るのであればそれでもいいかもしれませんが、vSphereなどのサーバ仮想化が目指したところは、アプリケーションごと・システムごとの垂直なIT基盤の作り方から、共通化された統合的なIT基盤への発展であったはずです。あるならば、それに対応したネットワークは、特定の要素にだけ対応するネットワークではなく、あらゆる要素に共通のポリシー・管理性を提供できるような包括的な仕組みを提供できるネットワークソリューションであるべきなのではないかと、私は思います。Year!!*1:もちろん、特定のハードウェアに依存したアプリケーションにはハードウェア要件がありますけど。仮想マシン情報に基づく制御もグループ内セグメンテーションもおまかせあれ。VMwareも会社が大きくなり、製品ラインナップも際限なく増え続けており、もう知らない製品とかよくわからない製品も増えてきましたね。Calendarではエキスパートな皆様が色々な製品について説明してくれるので、このシリーズを通して目を通してみるのはなかなかよい1年の総決算かと思います。本エントリーはみんな大好きvSphereの基本?に立ち返り、分散仮想スイッチについて書いてみたいと思います。連携における分散仮想スイッチですけどね。ACIはvSphereとも仲良しですよ、いや本当に。これほどvSphereとの組み合わせで価値を提供できるネットワークもないんじゃないかと、はい。分散仮想スイッチは、一定以上の規模のvSphereベースの仮想化基盤を運用されている方にとっては、必須ともいえる機能でしょう。ESXiホストの台数が増えてくると、ホスト毎に標準仮想スイッチを個別に設定・管理する様な運用は現実的ではありません。分散仮想スイッチはESXiホストの枠を超えて、vCenterサーバによって管理されているデータセンターの範囲内であたかもESXiサーバを跨って伸びた巨大な仮想スイッチが存在する様なイメージで管理することができます。1000vの2つが、商用レベルで現時点でも選択肢となりえる分散仮想スイッチソリューションといえるでしょう。1000vはリリースされていませんが、近いうちにリリースされるでしょう。