ブログトップ 記事一覧 ログイン 無料ブログ開設

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

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 |

2017/03/24 (金)

[] Java Web Startのアプリケーション (.jnlp) で unable to launch the application となって起動しない場合の対処方法

備忘録メモ。はやくフロントエンドのJavaは全部HTML5に置き換わればいいのさ。

  • Java Control Panel
    • [General] - [Network Settings]でProxy経由になっている場合は "Direct Connection" にしてみる
    • [General] - [Settings]で[Delete Files]をしてみる
    • [Security] - [Exception Site list]に対象のアドレスを追記してみる
  • 以下のあたりをフォルダごとごっそり消してみる。
    • C:\Users\username\AppData\Local\Sun
    • C:\Users\username\AppData\Local\Oracle
    • C:\Users\username\AppData\LocalLow\Sun
    • C:\Users\username\AppData\Roaming\Oracle

Detailsを表示させた際に以下の例のように (Unknown Source) とかなっている状態の場合は、おそらくこれで改善する。…たぶん。

com.sun.deploy.net.FailedDownloadException: Unable to load resource: https://x.x.x.x/ucsm/unpacked/ccore.jar
at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

もちろん、自己責任で。

2016/12/25 (日)

[]Cisco ACIとVMware NSXは競合製品なのか?

本エントリーは 2016年の vExpert Advent Calendar の〆を飾る?最終エントリーとなります。参加されたvExpertな皆さん、お疲れ様でした。年末休暇で暇な皆さま、このAdvent Calendarをはじめとして、多くのAdvent Calendarが面白いネタで25日間に渡ってリレーされていますので、それらをじっくりと読んでみるのも面白いかもしれませんよ。

さて、では vExpert Advent Calendar の最後に、こんなタイトルで 〆てみたいと思います。たまにぶっこみすぎじゃね?と言われることがあるんですが、別に私自身はそんなつもりないんですけれどもね。中の人ではないからこそ書けることがあると思っています。

では、本題。

結論から書いてしまえば、たしかにごく一部の部分においてCisco ACI (Application Centric Infrastructure) とVMware NSXはいってみれば「競合」している部分があるのは事実でしょう。別の会社の、それぞれの会社の戦略の中で開発・買収・提供が行われている製品同士なのですから、それはアタリマエのことです。しかし、私の個人的な見解としては、Cisco ACIとVMware NSXは大半の範囲については異なる位置づけの製品だと思います。言ってみれば、ルータとスイッチぐらいには異なる製品です。ネットワーク製品というくくりでは同じであっても、ルータとスイッチの使われ方や役割は異なることは誰もがおわかりでしょう。ルータにスイッチポートを搭載することができても、スイッチがルーティングの機能を持つようになっても、今でも両方の製品が使われているように、Cisco ACI とVMware NSXは根本的な製品の位置づけが異なると考えています。

本エントリーは、どちらかといえばCisco ACIの視点からみたNSXの位置づけについて考えてみたものとなりますが、世の中にあまりこうした視点でNSXについて書かれた情報はない気がしますので、何か参考になればいいなと思います。

Cisco ACIから見てVMware NSXとは

Cisco ACIから見ると、VMware NSXは数多くある管理対象として扱うことができるアプリケーションの1つです。つまり、VMware ESXiホスト上の仮想マシンに対して様々なサービスを提供するアプリケーションです。Cisco ACIとVMware NSXはお互いサポート対象ではありませんよね?と言われることがありますが、Windows上で動作するアプリケーションが、そのWindows自身の動作環境となっているハードウェアのベンダーに制約要件を持たない*1ように、NSXというネットワークを使ったアプリケーションをACIがサポートする・しないという制約条件はありません。

f:id:takaochan:20161224184013p:image

Cisco ACIは主にサーバが配置されるデータセンター向けのネットワークファブリックを基盤としたソリューションです。先日のエントリーでも書きましたが、Cisco ACIは連携する・しないはさておき、IPプロトコルを用いた通信である限り*2、あらゆる機器からのあらゆる通信に対応します。UNIXからの通信であっても、物理サーバからの通信であっても、そしてNSXからの通信であっても、そこに区別はありません。

割り切った書き方をすると誤解を生じる可能性があるので難しいのですが、Cisco ACIはネットワークファブリックとSDNを融合したソリューションです。対して、VMware NSXはSDNとNFVを融合したソリューションといえます。SDN部分で一部重なっている機能がありますが、ACIはNFV的な機能は自身では提供していませんし、NSXはすべてをソフトウェアだけで実現するためにネットワークファブリックは自身で提供していません。そしてSDN部分。製品の思想というか根幹の部分の考え方の違いとしかいいようがありませんが、「一部の仮想化環境のみを対象としたものではない、あらゆるネットワーク接続デバイスすべてを結びつけるネットワーク」に対するSDNは、ネットワークファブリックをベースとしているからこそ可能となると私は考えています。

■VXLAN on VXLAN?

VMware NSXはVXLANを使うことができますが、NSX Controllerを制御プレーンとして使用する仕組みになっています。基本的にはOVSDBを拡張したような仕組み?(教えて詳しい人。)を使ってデータプレーンとなるNSX仮想スイッチや、NSX対応した物理スイッチを制御します。つまりNSX Controllerとその共通言語でつながっている範囲でしかそのVXLANを解釈することができませんので、ACIがNSXによって制御されているVTEPによって包まれたVXLANを解釈することは残念ながらできません。

Ciscoなど、各社の間でVXLAN EVPN仕様の標準化が進められていますので、将来的には制御プレーンとして独自仕様ではなくEVPN 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 on VXLANになっているのでしょうが、だからどうこうといった問題はまったくありません。EthernetフレームであればL2スイッチング、IPパケットであればL3ルーティングできるという部分は一般的なスイッチと違いは一切ありません。

f:id:takaochan:20161224184012p:image

また、NSX仮想スイッチは分散仮想スイッチに依存していますので、ACIのvCenter連携によって作成された分散仮想スイッチに対してであっても、NSX仮想スイッチの実体としてのポートグループを作ることも可能です。もちろん、別の分散仮想スイッチを使用することも可能です。これらは、アップリンクに使用する物理NIC(もしくは、Cisco UCSでは標準的に使われている論理NIC)を分離するかどうかという構成次第での設計となります。

f:id:takaochan:20161224184011p:image

f:id:takaochan:20161224184010p:image

ACIのEPG (End Point Group)にどの単位でマッピングするのかも自由なところも、NSXを使う場合であってもACIをネットワークファブリックとして使うことのメリットの1つといえます。クラスター単位やポッド単位、ラック単位など、通信量やエラー状況を把握したい単位でNSXがVXLAN通信のためのVTEPポートとして使用するVMkernelのポートグループをEPGにマッピングすれば、ACI側からも通信の量やエラーを把握するヘルススコアなどを把握することが可能となります。また、EPG間のContractとしてVXLAN通信に使用する4789/utpだけを通す様に構成しておくことで、セキュリティ的にも望ましい状態を作り出すことができます。

f:id:takaochan:20161224184010p:image

f:id:takaochan:20161224184009p:image

■NSXのVXLANは使わなくてもいい

NSXのマイクロセグメンテーション機能がセキュリティなのかと言われると、私としてはあるなら使ったほうが程度のものだと思ったほうがいいのではないかと思っています。仮想マシン単位の隔離だけでは、なぜ侵入が発生したのか、どういう経路だったのか、どのアプリケーションがどういう動作をして、どこに通信しようとしているのか、そして究極的にどう問題を解決するのか等のセキュリティ的な確認・対応をしてくれるものではないからです。しかし、ほぼインフラ基盤がvSphereベースなので分散ファイアウォールを使いたい場合や、アンチウィルス連携など仮想化環境と蜜に連携しているからこそ可能となる機能を必要としている方もいるでしょう。そして、NSXを選択する理由としてそれらの機能をつかいたから、という方もいらっしゃるかもしれません。

さてそうした場合に、ネットワークそのものもNSXのVXLAN機能を使わなければならないかというと、実はそうではありません。NSXのVMkernelモジュールを展開すると、VXLANの構成を行わなくても分散ファイアウォールなどの機能は使用可能となります。また、NSX Controllerの展開も不要です。なぜならNSXの分散ファイアウォールやNSX EdgeなどはNSX Managerから直接管理されており、NSX Controllerに依存していないからです。つまり、ネットワークそのものはACIで構成し、ネットワークファブリックを活用した10/40/100GbEトラフィック性能や、EPG (End-Point Group)とContractによるネットワークのポリシー管理、ACIが提供するハードウェアベースの分散ルーティングやスイッチング、L3接続などの機能を活用し、vSphereだけに限定されない物理サーバや物理ファイアウォール・ロードバランサなども柔軟にネットワークに組み込むことを可能としつつ、分散ファイアウォールを使ってNSXのセキュリティグループを活用することが可能となります。

f:id:takaochan:20161224184008p:image

当然ながら、仮想マシンを含め、すべてのネットワーク接続をACI側で確認することができるようになるため、この組み合わせだとNSXのService Composerからも、APICGUIからも、仮想マシン毎に認識することができるようになります。

NSXが提供する分散ファイアウォールと、各社LB/FW連携によって構成されるEPG間や外部L3接続との間に挿入されるACI管理のセキュリティ機能であるService Grapthを組み合わることによって、より柔軟かつ実用的なネットワークを構成することが可能となります。

■単なる連携よりも、代替できたり、ない機能を提供したりできる方がよくないですかね?

NSXと連携するスイッチにしておきたいからと、Nexus/ACIではないスイッチだけを選択肢として考えることがあるかもしれませんが、NSX 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基盤への発展であったはずです。であるならば、それに対応したネットワークは、特定の要素にだけ対応するネットワークではなく、あらゆる要素に共通のポリシー・管理性を提供できるような包括的な仕組みを提供できるネットワークソリューションであるべきなのではないかと、私は思います。

そんなわけで、Cisco ACIとVMware NSXは競合製品なのかどうか、あなたはどう思いますか?

Happy Holiday season and New Year!!

*1:もちろん、特定のハードウェアに依存したアプリケーションにはハードウェア要件がありますけど。

*2:IPに加えて、FCoE NPVによるFC通信にも対応

2016/12/18 (日)

[]分散仮想スイッチもACIの一部です! 仮想マシン情報に基づく制御もグループ内セグメンテーションもおまかせあれ。

本エントリーは、 vExpert Advent Calendar 12/18 分となります。

VMwareも会社が大きくなり、製品ラインナップも際限なく増え続けており、もう知らない製品とかよくわからない製品も増えてきましたね。そういう意味でも、vExpert Advent Calendarではエキスパートな皆様が色々な製品について説明してくれるので、このシリーズを通して目を通してみるのはなかなかよい1年の総決算かと思います。

さて、本エントリーはみんな大好きvSphereの基本?に立ち返り、分散仮想スイッチについて書いてみたいと思います。ただし、Cisco ACI (Application Centric Infrastructure) との連携における分散仮想スイッチですけどね。ACIはvSphereとも仲良しですよ、いや本当に。これほどvSphereとの組み合わせで価値を提供できるネットワークもないんじゃないかと、はい。

分散仮想スイッチは、一定以上の規模のvSphereベースの仮想化基盤を運用されている方にとっては、必須ともいえる機能でしょう。ESXiホストの台数が増えてくると、ホスト毎に標準仮想スイッチを個別に設定・管理する様な運用は現実的ではありません。分散仮想スイッチはESXiホストの枠を超えて、vCenterサーバによって管理されているデータセンターの範囲内であたかもESXiサーバを跨って伸びた巨大な仮想スイッチが存在する様なイメージで管理することができます。

…で、そんな分散仮想スイッチですが、市場の中ではVMware標準の分散仮想スイッチ(以下、vDS)と、CiscoのNX-OSベースでの管理・運用を可能としたNexus 1000vの2つが、商用レベルで現時点でも選択肢となりえる分散仮想スイッチソリューションといえるでしょう。本エントリーの公開時点ではまだ正式に vSphere 6.5対応したNexus 1000vはリリースされていませんが、近いうちにリリースされるでしょう。きっと。

さて、ここからが本題です。

Ciscoはデータセンター向けの統合ネットワーク基盤としてACIを提供しています。ACIはSDNの一種として見られることも多いのですが、私としてはSDN的にも使えるし、これまでのネットワークの延長線としてよりシンプルに管理・運用できるネットワークとしても使えるし、さらには単なるSDNに留まらない、現実的なスケール性や管理性を併せ持ちつつAPI制御や各種管理ツールとの連携なども可能とするネットワーク技術だと思っています。

ACIではスイッチハードウェアのNexus 9000とコントローラであるAPICを使って、アプリケーション視点の論理モデルをデザインするだけで自動的に仮想・物理の壁を越えた構成が作られる仕組みを実現しています。

f:id:takaochan:20161217210213p:image

ACIでは様々な識別子に基づいてあらゆるネットワーク接続要素(End Point = サーバ、F/W、L/B、ルータなど)をEPG (End Point Group)としてグルーピングし、EPGEPGの間を通信ルールを定めたContractで結びつけるとそのEPG間での通信ができるようになったり、通信ルールとして定めたF/WやL/Bなどを使用する構成とすることができたりします。本エントリーはACIと分散仮想スイッチにフォーカスしますので、ACIの技術については必要最小限のみとしますが、「アプリケーション視点の論理モデル」を構成する2つの要素、EPGとContractについてはこの後の説明をご理解いただくうえで必要となりますので、覚えておいてください。

f:id:takaochan:20161217210214p:image

ACIはネットワークですので、どのベンダーのどんなネットワーク機器であっても、仮想マシンでも物理サーバでも、UNIXでもホストコンピュータであっても、IPプロトコルさえ使っていればご利用頂けます*1。そんなわけで、もちろんvSphere環境との組み合わせでもご利用頂けます。ACIとvCenterの間で管理連携せずに使用するのであれば標準仮想スイッチでももちろんご利用頂けますが、分散仮想スイッチが使用可能なのであれば、vCenterサーバとACIの管理コントローラであるAPIC (Application Policy Infrastructure Controller)とを管理連携を構成すると、もはや分散仮想スイッチをACIファブリックネットワークの一部として一体化してご利用頂くことができるようになります。ハードウェアの性能や可用性・信頼性に基づきつつもソフトウェアの管理性・柔軟性を活用することができる、という点がACIのメリットと言えるでしょう。

APICとvCenterの管理連携を構成すると、このようにAPIC側からもvCenterを通じて仮想マシンやvDSのネットワーク情報等を確認することができるようになります。

f:id:takaochan:20161217210209p:image

もちろんvDSをACIと連携して使用できますし、このエントリーでご紹介する様々な機能も使えますので、多くの場合においてはvDSをそのままご利用頂ければと思うのですが、CiscoはACI用として拡張されたNexus 1000vとして、Application Virtual Switch (以下、AVS)の提供もしています。ACIと組み合わせてしか使用できない代わりに!? AVSは特に追加コストなくご利用いただけますし、通信プロトコルとしてVLANだけでなくVXLANを使用することも出来るなどの機能的な違いもありますが、vDSとAVSのどちらを選ぶのかは、私個人としてはAVSを使用するとメリットのあるパターンに該当する場合にはAVSを、それ以外の場合にはvDSを使うという判断で良いのではないかと思います。

AVSを選ぶべき、もしくは選ぶと管理がしやすくなるパターンとしては、以下の4つがあります。

  1. ESXiホストがACIファブリックを構成しているNexus 9000もしくはNexus 2000 (FEX)に直接接続もしくは1段のみスイッチを挟んで接続されていない(つまり2段以上のスイッチを挟む)構成の場合
  2. 同一ESXiホスト上の仮想マシン間の通信についても通信監視を構成したい場合
  3. L4 StatefullなFirewall機能をFirewall専用機を使わずに構成したい場合
  4. ESXiホストにブレードサーバを使用している場合

1〜3についてが要件となる場合は、AVSを使用する必要があります。

1は接続検出の方式の違いによる理由です。vDSの場合はCDP/LLDPを使った隣接検出が使用されますが、AVSの場合はOpFlexプロトコルを使った連携動作が使用されます。

f:id:takaochan:20161217210210p:image

2はACIファブリックが持つ柔軟な通信のミラーリングなどの機能を活用するためにAVSをホスト内ではスイッチングを行わないモードとして使用する方式です。Nexusシリーズにおいて遠隔拡張ポートとして使用できるFEXことNexus 2000シリーズと同じような構成をACIファブリックとAVSの間で構成するようなパターンといえるでしょう。

f:id:takaochan:20161217210211p:image

3はAVSが持つStatefull機能を使って、行きパケットに対する戻りパケットを認識することによって、SYN+ACKアタックのような攻撃からネットワークを守りたい場合などに使用できます。

4のブレードサーバをESXiホストとして使用する場合については、AVSでVXLANモードとして構成することによりネットワークを追加で必要とする際に都度VLANをブレードサーバとACIファブリック間をつなげるスイッチに設定する作業を不要にすることが出来るという意味で「管理がしやすくなる」パターンといえます。

f:id:takaochan:20161217210212p:image

さて、本日はACIと分散仮想スイッチ(vDS/AVS)を組み合わせることによってもたらされるメリットの1つとして、uSeg EPG機能とIntra EPG Isolation機能を御紹介します。これらはいずれも、いわゆるマイクロセグメンテーションだと紹介すればVMwareなヒトにはわかりやすいのでしょうが、マイクロセグメンテーションだけに限られない、非常に面白い機能です。

uSeg EPG機能

ACIの基本は、EPGEPGを結びつけるContractであると説明しましたが、「どのようにEPGに紐付けるのか」こそが重要なポイントとなります。仮想マシンEPGに紐付ける場合、通常は分散仮想スイッチ連携を用いる場合にはEPGに紐付いて自動的に作成されるポートグループに仮想マシンを接続することによって、そのEPG仮想マシンが接続された状態となりますが、これだけがEPG仮想マシンを紐付けるやり方ではありません。uSeg EPGは、通常のEPGとポートグループとの紐付けに優先して、特別な条件に合致する仮想マシンに対して異なるEPGへのマッピングを実現する方法です。

特別な条件としては、IPアドレスやMACアドレスも使用できますし、さらにはvCenterサーバから得た情報を活用することも可能になっています。使用可能なvCenter情報は色々な種類があり、連携対象のvCenter毎や、ゲストOS種別、Hypervisor種別、データセンター、VM ID、VM名、vNIC毎などがあります。もちろん、これらの条件を複数組み合わせて識別条件とすることが可能です。

f:id:takaochan:20161217210215p:image

これらの条件に合致するEPGに対してどのような通信ルールを適用するのかについても、Contract次第です。特定の文字列を仮想マシン名に含むVMだけを対象としたり、あるゲストOSがインストールされているVMにだけに特別な通信ルールを適用させたりなど、この機能によって、これまでは簡単に出来なかった動的なネットワーク制御が可能となります。

なお、このuSeg EPG機能は、vDS*2であってもAVSであっても使用できます。Hyper-Vホストと連携している場合でも使用でき、今後KVMやContainer連携でも使用できるようになっていく予定です。

Intra EPG Isolation機能

EPGEPGの間では、Contractによって通信が許可されない限りVLANが同じであろうと同じサブネットに属していようと通信できない状態が基本となるのですが、同一EPG内についてはデフォルトでは一切の通信制限がない状態となっています。Intra EPG Isolation機能を有効にすると、いわばPrivate VLANとして動作し、EPG内のEnd Point同士の間では通信はできなくなります。他のEPGとの間については、元の通りContract次第で通信可否は決定されます。

f:id:takaochan:20161217210216p:image

このIntra EPG Isolation機能ももちろんvDS/AVSの両方で使用可能ですし、物理サーバの場合であっても使用できます。Hyper-VおよびKVMについては今後対応予定です。

もちろん、uSeg EPG機能とIntra EPG Isolation機能は併用することができます。uSeg EPG機能については、APICAPIを通じて取得可能な情報であれば、どのようなものであっても条件情報として使用することができるので、今後、より様々な情報が使用できるようになっていく可能性があります。

また、ACIはvSphereやHyper-Vなどの仮想化基盤とも、シスコ以外の各社の物理・仮想両方のL/BやF/Wとも連携が可能となっていますので、仮想マシンEPGへの紐付けのマッピングにおける柔軟性と、各社L4-7デバイスとの連携の2面を結びつける、非常に面白いネットワークの仕組みを提供できる基盤となっています。

vCenterサーバとの連携だけにとどまらず、ACIはvRealize Automation/Orchestratorとの連携や、vCenterプラグインを通じたvSphere Web Client経由での管理機能の提供など、様々な連携がすでに提供されています。こちらはvCenterプラグインで、ASAによるF/WとF5のL/Bが挟み込まれたContractを参照している画面です。

f:id:takaochan:20161217210217p:image

今後も引き続き、両社の技術の連携によって様々な価値をご提供できたらいいですね。

*1:最新のACIではFCoE NPVにも対応していますので、SANも統合可能です。

*2:vDSの場合ESXiホストが、物理サーバの場合は当該物理サーバが、接続されているACIファブリック構成スイッチが-EXモデルである必要があります。

2016/11/25 (金)

[]VCSAの構成(vCenterとPSCの面倒な関係)

こちらのKBにある推奨構成パターンのうち、2番目のPSC外だしのvCenter x2台構成を管理しているのだが、時刻同期やメンテ対応などで色々と面倒。今後はHA化もできるし、PSC内蔵パターンでシンプルに構成するのがいいとは思うのだが、その場合はMulti vCenter構成にすることに制約が出てくるのが悩ましい。vCenter内蔵のPSCを他のvCenterから使ったり、PSC内蔵のvCenter同士を同期する構成は非サポートになると書かれているし、どうしたものかね。

f:id:takaochan:20161125112442p:image

動作確認のためにMulti vCenter構成にしているだけなんだけど。

2016/11/22 (火)

[]VCSAのShellモード(Appliance Shell/Bash Shell)

自分で設定しておいて忘れていたのだけれども、vCenter Server Applianceは普通以下のAppliance Shellがデフォルトになっている。

この場合、Bash Shellに移行するには KB2100508 にあるとおり、shell.set --inabled true したうえで shell すればよい。

Using username "root".

VMware vCenter Server Appliance 6.0.0.20000

Type: vCenter Server with an external Platform Services Controller

Last login: Tue Nov 22 01:11:50 2016 from 172.16.254.1
Connected to service

    * List APIs: "help api list"
    * List Plugins: "help pi list"
    * Enable BASH access: "shell.set --enabled True"
    * Launch BASH: "shell"

Command>

でも、私の環境では自分で昔設定したんだろうけど、Bash Shellが最初に表示されるようになっていた。上記KBにもあるけれど、おそらく chsh -s /bin/bash root してデフォルトをBashに変更していたっぽい。

この状態からデフォルトのAppliance Shellに戻すには、まぁKBにあるとおり chsh -s /bin/appliancesh root して一旦Shellをログアウトすればよい。

ただの備忘録。

2016/11/11 (金)

[]VSAN6.2へのアップグレードプロセスが10%でエラー

もうこれはKBあるので、こちらで。

英語の本家:https://kb.vmware.com/kb/2144882

日本語版:https://kb.vmware.com/kb/2145528

あー、超面倒。

[]VSAN6.2へのアップグレードがオブジェクトアクセスエラーで出来ない場合の対処方法

VSANのディスクフォーマットをアップグレードしようとしたらこんなエラーががががが。

f:id:takaochan:20161111172604p:image

ちょいと調べたら、このオブジェクトへのアクセス権ステータスをどうにかしないとアップグレードできないということなので、対処。

対処にはRVCが必要。ま、vCenter Server Appliance (VCSA)に入っているので、それを使うのが一番手っ取り早いかと。

VCSAにログインして、Bash Shellに一旦入ってから、rvc account@localhost でRVCに入れる。デフォルトのadministrator@vsphere.localのままならlocalhostだけでもOK。ローカルの管理者アカウントを変更しているなら、こんな感じで。

f:id:takaochan:20161111172606p:image

あとは、普通にcdコマンドでパスを移動してDC配下のComputersに行くか、さらにその下のクラスタに移動して、vsan.purge_inaccessible_vswp_objects コマンドを実行。Computersにいるならクラスタ名を、クラスタにいるなら . を引数につけて実行。

f:id:takaochan:20161111172605p:image

確認メッセージで Y を押せば、オブジェクトの削除が行われる。ま、本当にそのオブジェクトを消していいかどうかはご自分でご判断を。

とりあえずこれで、この問題は解決。

2016/01/27 (水)

[] vCenter Server Appliance 6.0 がディスクのエラー(Bad Block)で正常起動できなくなった際の対処メモ(当然ながら自己責任版)

※本エントリーを参考にして操作を実施した結果、問題が発生しても責任は負いません。自己責任で参考にしてください。本操作を実施することにより、VMwareからの正式なサポートを受けられなくなる可能性があります。

vCenter Server Appliance (VCSA) はファイルシステムとしてLVMで構成されているが、突然の電源断やディスク容量の枯渇などによってファイルシステムに破損などが生じた場合に、正常に起動できなくなることがあります。

その場合は、fsckをするしかないのですが、デフォルトではroot権限がDisableとなっていてbashが起動できないため、ちょっと対処が必要となります。

VCSAは複数の仮想ディスクで構成されています。特定のディスクがrwでマウントできないなどの状況となった場合には、roマウントした上で機能が制限されたコマンドプロンプト状態となります。

しかもこの場合にはrootアカウントでログインした上で、"shell.set --enabled True"コマンドでShellを有効化してShellコマンドでShellに入れとメッセージが出るのですが、そもそもshell.setコマンドが"unknown command"として受け入れてくれない場合があります。というか、これが使える状況なら以下の操作は不要です。

f:id:takaochan:20160126102155p:image

この場合はもはやどうにかしてbashにたどり着かないとfsckもなにもないので、以下の手順を行います。

1. Ctrl+Dコマンドで再起動し、GRUBブートローダ画面でスペースキーを押すなどして自動起動を停止する

2. "p"を押してrootのパスワードを入力する

f:id:takaochan:20160126102154p:image

3. "e"を押して起動オプションの編集モードに入る

4. (おそらく2行目にある) "kernel /vmlinuz-3.0.xxxx"で始まる行を選択し、"e"を押す

f:id:takaochan:20160126102153p:image

5. 起動オプションに"init=/bin/bash"を追記する

f:id:takaochan:20160126102152p:image

6. Enterキーを押してGRUBのメニュー画面に戻る

7. "b"を押して起動する

8. Bashで起動するので、まずはroでマウントしてしまっている/dev/sdaXについてfsckを実行する

以下の例では /dev/sda3 にBad Blockが検出されている

f:id:takaochan:20160126102151p:image

f:id:takaochan:20160126102150p:image

9. 再起動する(おそらくCtrl+Dでは正常に再起動できないので、仮想マシンとしてリセットするしかない)→ここで正常にVCSAが起動できた場合は以下の手順は不要。念のためもう一度F12&F11キーで正常操作としての再起動を行って問題ないことを確認する ※ここで再起動をしておかないと、PSCとの間で正常に連携できない状態となっている可能性があります

10. LVMの / (root)がマウントできない状態となっていて再度vCenterが起動しない場合は、改めてCtrl+Dで再起動した上で、1.〜7.までの手順を再度実施する

f:id:takaochan:20160126102156p:image

11. Bash画面で"chsh -s /bin/bash root"を実行し、Shellの変更が設定されたことを確認のうえでVCSAを再起動する(仮想マシンとしてのリセット)

f:id:takaochan:20160126102425p:image

12. rootパスワードを入力してログインすると、ファイルシステムのリカバリが可能なコマンドプロンプト状態(repair filesystem)#で起動するので、"fsck /dev/mapper/log_vg-log"コマンドでチェックを実施する

f:id:takaochan:20160127075828p:image

13. Ctrl+Dコマンドで再起動する

14. めでたく正常にVCSAが起動することを確認する

なお、本手順を踏んでVCSAとしては正常に起動したとしても、vCenterとしての正常動作ができるかどうかまではわかりません。DBレベルで修復不可能な状態になっていた場合は、残念ながらサービスとしては回復できない可能性があります。

また、PSCを分離している場合は、PSCの復旧後にしばらく(10分程度でいいかと思いますが…)時間をあけてからVCSAを起動してください。