2015年11月1日日曜日

vRealize Operations 6.0/6.1に、Management Pack for vCloud Airが対応!

vCloud Airのリソース監視も、vRealize Operations Manager(vROps)でできるのが「Management Pack for vCloud Air」です。

このプラグイン自体は、2014年末よりリリースされていましたが、以前のバージョンでは、vROps6.0移行で動作させると動かなくはないのですが、どうも挙動が怪しかったように認識していました。

と、今、確認をしてみると 「vRealize Operations Management Pack for vCloud Air 2.0」として、管理パックが新しくなっています!


リリースノートを見ると2015/9/15のアップデートとあります。

では、What's Newから見ていきましょう
  • vRealize Operations 6.0以降用に再設計されています。
  • 仮想マシン、仮想マシン演算処理、仮想データセンターとクラウドリソースのメトリックメを取得可能。
  • ヘルス、リスクと効率バッジ表示のサポート。
  • EdgeGatewayオブジェクト、関係およびネットワーキングのメトリックをサポートします。
  • 演算ダッシュボードとネットワークダッシュボードを更新しました。
  • Cloud、EdgeGateway、テンプレート、および仮想マシンの横断的なインベントリ表示
  • モニターオブジェクトで、ヘルス、リスク、効率の監視アラートが可能。
  • すべてのオブジェクトの容量分析をサポートします。
  • vCloud Airへの安全な接続。証明書が信頼できない場合は、証明書を受け入れるか拒否するかを選択が可能。
  • オプションは、監視のためのクラウド、仮想データセンターや仮想マシンをフィルタリングします。
  • 仮想マシンの電源操作のサポート。
  • vCloud Airのリソースを設定可能。
  • オンプレミスのvSphereリソースからクラウドリソースを区別するため、新しいアイコンを採
  • 管理パックの安定性とパフォーマンスを改善しました。
なんだか、だいぶ機能が上がっていますね。
仮想マシンの電源操作が可能になったのは大きいですね。

ただ、Know Issuesに気になる文言があります。
Management Pack 2.0 supports only environments with Advanced Networking Services. If you would like to continue monitoring environments without vCloud Air Advanced Networking Services, it is recommended that you do not upgrade to management pack 2.0.
どうやら、Management Pack2.0を入れるためには、「Advanced Networking Services」が必須のようです。

となると、現行はDedicated Cloudしかサポートされていないのでしょうか・・・。
OndemandやVPCのサポートがされないかは実際に試してみたいと思います。

(参考)

vRealize Operations Managerで、512bitのSSL証明書を使ったvCenter Serverと接続する

先日出会わしたトラブルについて、そのソリューションをご紹介します。

vRealize Operations Manager(vROps)を設置しようと、vCenter ServerのIPをいれて登録しようとしたところ、「java.security.cert.certificateexception」が表示され、vCenter Serverと接続ができない症状が発生。

接続先のvCenter Serverは、5.1とのことで、そんなに古くない。
(というか、vROpsは、vCenter Server 4.0からサポートされている)

さてさて、このExceptionは、およそJAVAまわりで出ていて、vROpsの問題ではないように思えます。

JREの問題で、512bitのような証明書は、デフォルトで受け付けられないようになっています。

まずは、vCenter ServerのSSL証明書を調べます。

C:\ProgramData\VMware\VMware VirtualCenter\SSL\rui.crt

を確認して、証明書のビット数を確認します。

ジャスト512bitでした。

どうも、vCenter Server 4.xからアップグレードをしたようで、アップグレードの場合前までの証明書が継続して使われるため、512bitのままで動作していたようです。

※確かに、FireFox等でvSphere Web Clinetでも、証明書セキュリティで画面が表示されませんでした


512bitの証明書は確かに古いですが、かといって本番環境でvCenter ServerのSSL証明書を入れ直すとなれば、入っているプラグインやvCenter Serverと連携するアプライアンスで証明書の際受け入れを行う必要があり、これはこれで結構大変な話しです。

ということで、JREのセキュリティパラメーターを変更することで、この問題を回避することができます。


≪ 方法 ≫

1.まずvROpsのアプライアンスにシェルでログインします。
2.以下のファイルをvi等のエディタで開きます。
/usr/java/jre-vmware/lib/security/java.security
3.以下の項を探します。
Security.setProperty="jdk.certpath.disabledAlgorithms=MD2,RSAjeySize < 1024"
4.1024を512に書き換えて、保存終了します。
Security.setProperty="jdk.certpath.disabledAlgorithms=MD2,RSAjeySize < 512"
5.vROpsアプライアンスを再起動します。


これで、OKです。

5年前後の仮想化基盤リプレースで、vROpsでリソース情報を収集して、最適なサイジングを!と思いながら、vROpsを導入しようとすると、こういったことに出くわすことはあるかと思います。

おそらくこの手法は、正式にメーカーサポートされない可能性がありますので、行う場合は自己責任にてよろしくお願い致します。





2015年10月24日土曜日

パブリッククラウドで困った時、すぐに頼れる先はありますか?

パブリッククラウドで、うまく動作しない事やトラブルが発生したときに、どうしますか?

インフラサービスのキッティングでトラブルや想定していない事象に出くわすことは、必ずしも平日の通常勤務時間とは限りません。

しかし、大半のパブリッククラウドは、メールベースの24時間受付とベストエフォートな回答がほとんどです。

しかし、vCloud Airは、電話サポート24時間受け付けており、連絡先も公開されています。

開通でトラブルケースもパブリッククラウドの場合、まれにありますがこういった時、連絡先がわからず、連絡するまでに時間を要するケースもありますが、vCloud Airは、すぐに保守サポートと会話ができるというのは大きなポイントです。

vCloud Airの日本サポートはこちらから確認できます。
https://www.vmware.com/support/contacts/japan.html

ワールドワイドで連絡先が出ているパブリッククラウドは、珍しいことですが、ユーザーにとっては大変ありがたい話しです。

強固な基盤と、困ったときにサポート連絡ができるのは、vCloud Airの良さと行っていいと思います。


Hybrid Cloud Managerで仮想マシンの移行がさらに便利に

Hybrid Cloud Managerでできることを前回おさらいしましたが、vCloud Connector時代からの優位性であった、オンプレvSphere上の仮想マシンを、vCloud Air上に簡単に持って行くことができるという、この便利な機能。

vCloud Connector自信は、仮想マシンを裏でOVF化し、vCloud DirectorにそのOVFを転送するという仕様でした。(ということは、仮想マシンの停止をしないと、vCloud Connector経由で仮想マシンを持って行けなかったという仕様になります)

この仕様は、Hybrid Cloud Managerの登場により大きく変わるようです。


Hybrid Cloud Managerの仮想マシンマイグレーションの画面を見ると、移行手法が
  • vMotion based migration
  • Replication based migration
とあります。

つまり、OVFでの転送ではなくなり、vMotionによる移行(こちらはかなり話題になりましたが、現行リリースのHybrid Cloud Managerでは利用できません)と転送効率のよい、 vSphere Replicationベースが選択可能です。このvSphere Replicationベースは、仮想マシンがパワーオン状態であってもレプリケートが可能ですし、最終的にvCloud Air上で仮想マシンを稼働する際に、仮想マシンの停止時間を最小限に抑えることができます。これは、他のクラウドサービスでは、実現できない手法です。(他社クラウドサービスはあくまでもオンプレの仮想マシンファイルを変換して、ファイルとして転送することしかできません)

さらに、仮想マシンの移行をスケジューリングする機能もあります。

開発用とでvCloud Air上で稼働していた仮想マシンを、本番環境で利用するため夜間に、vCloud AirからオンプレのvSphereに持ち帰るときも、タイマー設定が可能ですから、残業して夜間にオペレーションをすると行ったことは不要になります。

ただ、仮想マシンをマイグレーションすることは、何かしの方法で他のパブリッククラウドでも可能になってきておりますが、"効率よく"仮想マシンをパブリッククラウドに持って行ける(または、オンプレへの持ち帰り)のは、vCloud Airだけということは、押さえておきたいことですね。








Hybrid Cloud Managerでできることと何が必要か?

Hybrid Cloud Managerがリリースされてだいぶ日がたちましたが、vCloud Air側の環境がDedicatedでないと動作しないことや、Air側にもManager用の実装をお願いしたいと行けないなどの諸条件が有り、そう簡単に検証ができない事実がわかりました。

簡単に使えないのは残念ですが、まずは、Hybrid Cloud Managerで何ができるのかをしっかりと押さえておく必要があります。

  • オンプレ仮想マシンを仮想マシンのvCloud Airへの移動またその逆
  • ネットワークの延伸(L2延伸)
単純に言えば、できることはこれだけです。(将来、仮想マシンの管理もできるという話しですが、今のところその機能は実装されていないようです)

では、展開されるアプライアンスを把握したいと思います。


こちらを見るとわかりますが、
  • Hybrid Cloud Gateway
  • WAN Optimization Service
  • Network Extemsion Service
  • Cloud vMotion ( Comming soon)
とあります。まだ利用ができないCloud vMotionもメニューとしては存在しますが、ボタンが押せなくなっています。(これかひょっとすると隠しパラメーターがあったりすのかな?)

Hybrid Cloud Gatewayは、オンプレのvCenterとvCloud Airをつないで管理を行う仮想マシンのようです。(この役割は、Hybrid Cloud Managerアプライアンスではないようです)

WAN Optimization Serviceは、WAN最適化を行うアプライアンスとのことです。
Network Extemsion Service(アプライアンス名称はLayer 2 Concentrator)は、L2延伸を行うために必要です。

ネットワーク延伸やWAN最適化を行わない場合は、その2つのアプライアンスは不要ですが、Hybrid Cloud Gatewayは、Hybrid Cloud Managerを利用する上で必須のアプライアンスとなります。

それぞれのVA要件を見ておきましょう。

VMvCPUsRAMDescription
Hybrid Cloud Manager412GBWAN Optimizer (optional)
Hybrid Cloud Gateway22GBThe Hybrid Cloud Gateway (HCG) maintains a secure channel between a vCenter and a vCloud Air Dedicated Cloud. The channel secures access for vSphere protocols that are not tenant-aware, and provides intelligent routing capabilities to avoid networking "middle mile" problems.
Layer 2 Concentrator (optional)1512MBThe Network Extension Service extends a Layer 2 (L2) network extension from a vCenter with a vSphere Distributed Switch (vDS) to a Dedicated Cloud.
WAN Optimizer (optional)814GBThe WAN optimizer, if installed, communicates only with the Hybrid Cloud Gateway. It uses software-defined WAN optimization techniques such as data deduplication and line conditioning to improve the performance for any workload passing through the Hybrid Cloud Gateway.

見ていると、WAN最適化は、vCPU8コア、14GBメモリーが必要と言うことで、かなりのスペックを要します。またHybrid Cloud Manager自信も、12GBのメモリーが必要と言うことで、管理系の仮想マシンだけでかなりのリソースを必要とすることは、あらかじめ押さえておく必要があります。(リソースは、オンプレ側に必要になることを忘れないようにしておきましょう)


では、最後に通信アーキテクチャーも確認しておきましょう。

(参考)vCloud® Air Hybrid Cloud Manager™ Installation and Administration Guide
P5参照

この図を見る限り、オンプレに展開された、L2Extention Cloud(Layer 2 Concentrator VA)、WAN最適化VA(WAN Optimizer)、Hybrid Cloud Gatewayがそれぞれオンプレに展開されて、vCloud Airは、DRサービスのvSphere Replicationと同じように、あらかじめvCloud Air上に展開されていることが前提(自分で展開するのではなく、VMware社によって展開されるバックエンドのVA)でそのVA同士がIPSECトンネル上で通信をするようです。

こうなると、L2延伸はNSXで実装されている、SSL-VPNではなく、IPSEC上で行われることになりそうですね。

この理屈から行くと、Hybrid Cloud GatewayがIPSECトンネルをはり、WAN最適化は、Hybrid Cloud Gatewayと付随して稼働することようです。

詳しくは、Hybrid Cloud Magaerのマニュアルを参考にするとわかりやすく記載されています。

vCloud® Air Hybrid Cloud Manager™ Installation and Administration Guide





2015年10月17日土曜日

「Unexpected status code: 503 vCenter Server」の対処法

最近、検証環境で色々試していると、
が出て、
次に


となって、vCenter Serverが触れなくなる現象が多発!!

vCenter Serverを再起動すれば直るが、結構しょっちゅう(半日に1回程度)起きる症状で、その度の再起動は、 正直時間もかかるし面倒だし、困ったもんだと思っていました。
または、30分ぐらい待っておくと直ることもある。
(サービスが落ちて再起動しているのか???)

この症状、アプライアンス版を利用為ていたときはあまり見た記憶が無いのですが、最近、UpdateManagerが、vSphere Web Clientに対応したことも有り、Windows版のvCenter Serverに再構築してから起き出した気がする・・・。

構成はこんな感じ
  • マシン:仮想マシン(ハードウェアバージョン11)
  • vCPU:2コア
  • vRAM:12GB
  • OS:Windows Server 2012 R2
  • DB:SQLServer 2014 Standard (vCenter Serverと同居)
といった感じ。
ちなみに、vCenter Serverと連携してるプラグインは、
  • NSX Manager
  • vSphere Replication
  • Site Recovery Manager
  • Hybrid Cloud Manager
  • Update Manager(vCenter Serverに同居)
といっ感じです。

さて、KBを調べてみると

KB:2092991
vCenter Server が「503 サービスを使用できません」というエラーを返す

がありました。
こちらは、Windows Server 2008/2008 R2のバグで、TIMED_WAITのソケットが解放されないバグによってソケットを使い切るのが原因という話しでした。

さて、今回はWindows Server 2012 R2のため、このバグには直接該当しませんが、そうそう思い出してしまいました。Windows Serverの仕様を・・・。

Windows Server 2008以降では、動的ポートの範囲が「49152 ~ 65535」となります。

昨今では、vCenter Serverとの通信を行うアプライアンスやプラグインが多く存在するため、このポート枯渇が原因な可能性は確かに捨てきれません。

netstat -anで見てみると・・・

うーん、なんか怪しい感じです。

ということで、
https://support.microsoft.com/ja-jp/kb/929851
にお世話になりまして、まずはポート拡張を・・・。
netsh int ipv4 set dynamicport tcp start=1025 num=64510
netsh int ipv4 set dynamicport udp start=1025 num=64510
netsh int ipv6 set dynamicport tcp start=1025 num=64510
netsh int ipv6 set dynamicport udp start=1025 num=64510

ちゃんと反映されたかの確認も・・・。
netsh int ipv4 show dynamicport tcp
netsh int ipv4 show dynamicport udp
netsh int ipv6 show dynamicport tcp
netsh int ipv6 show dynamicport
あとは、念のためソケットのタイムアウト値も変更しておきましょう!

こちらはレジストリでの変更となります。

パラメーターの場所は
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters


こちらにDWORD32ビットで
TcpTimedWaiteDelay
を作成し、10進数で「30」と入力します。


あとは、OSの再起動で完了です。

いままでのもやもやはこれでおそらく解消されるはず・・・。
※vSphere Web ClientのError:1009は、おそらく別の問題でも出るので直らないでしょうけど・・・。

(参考)
Windows Vista および Windows Server 2008 では TCP/IP の既定の動的ポート範囲が変更されている 

Detecting Ephemeral Port Exhaustion in Windows 7 / 8 / 2012





2015年10月12日月曜日

バックアップとDRをうまく使い分けよう(VDPとvSphere Replicationの違いについて)

仮想化基盤で悩むのはやはりバックアップですね。
VMware Data Protection Advance (通称VDPA)が無償化されましたが、やはり細かいところまでのバックアップ設定は、商用のサードパーティーバックアップソフトに比べて見劣りすることろがあるのは事実です。

そんな時に、vSphere Replciationをバックアップソフト代わりに使うことで解決できるケースもあります。

バックアップとして見たときに、VDPAとvSphere Replicationの特徴を見てみましょう。



メリットデメリット
VMware
DataProtection Advance
・ファイルベースでのリカバリが可能
・バックアップファイルの圧縮と重複除外機能が搭載される
・長期バックアップが可能
・VA内に接続されたVMDK内にバックアップファイルが保存される
 (別途Avamer/DataDomain連携は可能)
・細かいスケジュール設定ができない
・バックアップした仮想マシンをすぐに起動できない
・仮想マシンが多い場合1日のジョブですべてのバックアップが終わらない可能性がある
vSphere Replication・常に差分で同期されるため、最短15分前までリカバリが可能。
・24世代のRPOを元に希望した場所で即仮想マシンを起動可能
・短期間のバックアップが可能
・データーは圧縮されずに保存される
・ファイルベースでのリカバリができない
・バックアップした仮想マシンを停止しないと、バックアップした仮想マシンを起動できない。

VDPは、圧縮されて重複除外されるのがメリットですが、スケジュールに従ってバックアップをとるため、直前に戻すことやバックアップにかかる時間に関してはデメリットがあります。
vSphere Replicationはその点、常に同期されるため、バックアップジョブという存在無く常に最新のデーターが保存されるため俊敏性に優れています。

これは言い換えると、バックアップとDRの違いそのものでもあります。

バックアップとDRは、リカバリの時間やどの時点でのバックアップが必要かという話しで選択が変わってきます。

バックアップから即リカバリして使いたいといった場合は、極力直前の状態まで戻して使いたいといった場合は求められる状況が異なるということをしっかり押さえておく必要があります。

vSphere Replicationなら、24世代のスナップショットを保持可能(最大24時間のRPOで24日間)