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日間)




vRealize Operations VA版をVMWARE Workstation(PRO)で利用する

以前にvRealize Operations Manager(vROps)をご紹介致しました。
※過去記事:vRealize Operationsカテゴリー記事一覧

vROpsは、分析ツールとして既存の仮想化基盤に採用することで、今まで見えていなかった潜在的な問題を解決するのに非常に便利なツールです。

最近では、VMware製品のディストリビューターより、VOAなる仮想化診断サービスも行われており、このVOAも、vRealize Operationsが使われています。

(参考)仮想化無料けんこう診断/VOAについて
https://www.vmware-gogo.com/p/vsom_campaign/voa/


VOAを利用せずとも、このvROpsを使って手軽に仮想化基盤を分析したいけど、今稼働している仮想化基盤に入れずに、テストで稼働させられる方法無いかという問い合わせをまれに受けます。

vROpsは、vCenter Server経由でのみ展開できるOVAファイルで展開されています。
そのため、ESXi直に展開や、Workstation等では、展開ウィザードが正しく表示されず展開ができない状況にあります。
Windows版やLinux版をVMware Workstation上で構築すれば確かに可能ですが、それも面倒ですので、バーチャルアプライアンス版をVMware Workstaion版で利用する裏技の方法をお知らせします。

※この方法はVMware社がサポートしているやり方ではありませんので、ご注意ください。

まず必要なものですが、
  • VMware Workstation PRO
    トライアル版もここからダウンロード可能です
  • vrealize Operations Manager
    トライアル版はここからダウンロード可能です。
  • 物理メモリーが16GB以上のパソコ
    (サイズ小でvRAMは16GB必要ですが、小規模であれば12GB割り当てでも動作します)
  • DHCPサーバー
    (初期キッティングに必要となります)
となります。

では早速、展開方法です。

1.まずは、VMware Workstationをインストールしておきます。
2.次に、ダウンロードした、vROpsのOVAをダブルクリックします。

 3.仮想マシン名と展開先を聞かれますので、それぞれ名称と保存先のパスを指定します。

4.使用許諾書が表示されますので、「同意する」をクリックします。

5.エラーメッセージが出るケースがありますが、その場合は続行します。
(このエラーはvCenter Serverでしか設定できないパラメーターがVMware Workstationでは表示できないため出るエラーです)

6.展開はこれで完了です。スペックは「小」で展開されますので、必要に応じてスペックを仮想マシンの設定を編集するから編集しておきましょう。

尚、監視するオブジェクトによってvROpsのVAに必要なスペックが異なります。
詳細は、こちらのKB2130551を参考にしましょう。

(参考)KB:2130551
vRealize Operations Manager 6.1 Sizing Guidelines (2130551) 


また、仮想マシンをパワーオンする前に、DHCPサーバーが存在するネットワークに属しておく必要があります。DHCPサーバーがない場合は、ネットワークアダプタを「NAT」を選択しておくことをお勧めします。(IPは、後の作業で固定にします)

7.準備ができたら仮想マシンをパワーオンします。

SuseLinuxが起動してきます。きちんとDHCPでIPが取得できているかも起動中に確認できます。

尚、起動には結構時間がかかります。

8.起動するとこのような画面が表示されます。

9.DHCPのままですと、vROpsを再起動するごとにIPが異なると正しく動作しませんのでIPの固定化の作業を行います。
まず、VMware Workstationの画面をクリックし、コンソールを触れる状態にし、「Ctrl+Alt+F1」を押し、コンソール画面を表示させます。

11.ログイン画面が確認できたら、「root」と入力し、Enterキーを押します。
12.続いてパスワードを聞かれますので、そのままEnterキーを押します。
(パスワードは設定されていません)

13.そのままパスワード変更モードに入ります。
Old Passwordを聞かれますのでそのままEnterキーを押します。

14.New Passwordで、新しいパスワードを聞かれますので比較的複雑なパスワードを入力します。(簡易的なパスワードははねられます)

15.Retry Passwordは、先ほど入力した比較的複雑なパスワードをもう一度入力します。
※このパスワードは今後メンテナンス等で必要になるケースがありますので、後からわかるようにしておいてください。

16.正しくパスワード設定が終わるとShell画面が表示されます。

17.IPアドレスを変更しましょう。今回の場合

IPアドレス:192.168.58.100
ネットマスク:255.255.255.0
デフォルトゲートウェイ:192.168.53.254
DNSサーバー:8.8.8.8

と設定します。

IPアドレスを設定するため
vi /etc/sysconfig/network/ifcfg-eth0
を開きます。

18.現行はDHCPの設定になっていますので、以下のように書き換えます。
DEVICE=eth0
BOOTPROTO=static
STARTMODE=auto
IPADDR=192.168.58.100
NETMASK=255.255.255.0
BROADCAST=192.168.58.255
NETWORK=192.168.58.0
:wqで、保存終了します。
(英語キーボードマッピングになっていますので注意してください)

19.続いてデフォルトゲートウェイを設定します。
vi /etc/sysconfig/network/routes
以下のように記入し、:wqで保存終了します。
default 192.168.58.254 eth0

20.続いてDNSを設定します。
vi /etc/resolve.conf
DHCP出取得したDNSサーバーが記載されていると思いますので、こいつを適宜書き換えてください。
namserver 8.8.8.8
と記載して、:wqで保存終了します。


21.これで設定は完了です。ネットワークサービスを再起動させて設定を反映させます。
/etc/rc.d/network restart

22.正しく情報が反映されたかを「ifconfig」と「route -n」で確認します。

↓ifconfigで設定したIPの確認

↓route -nでデフォルトゲートウェイの確認

23.アプライアンスの設定はこれで終わりです。
「exit」でシェルを終了し、「Ctrl+Alt+F2」で元の画面に戻します。
このとき。URL画面が前のIPで出ているケースがありますが気にしなくてもよいです。
このまま、ブラウザーで新たに設定したIPアドレスをhttpsで開きます。

この画面が出れば、Workstation用の設定作業は完了です。





2015年10月11日日曜日

フォールト トレランス(FT)機能のメリットとデメリットを正しく理解しよう

さて、フォールトトレランス(FT)機能のメリットは、完全無停止の環境が構築できる点です。
FT機能を使える場所とはどういったシーンで活躍できるのでしょうか?
まずは、VMwareのドキュメントを読んでみますと、

より高度なレベルの継続性、および状態情報やデータ保護の強化により、フォールト トレランスをデプロイするタイミングのシナリオが通知されます。

  • アプリケーションを常に利用できるようにしておく必要がある場合 (特に、ユーザーがハードウェアの障害中も維持しておきたい、長期にわたるクライアント接続があるアプリケーション)。
  • カスタム アプリケーションで、これよりほかにクラスタリングを行う方法がない場合。
  • カスタム クラスタリング ソリューションによって高可用性が提供されるが、これらのソリューションが複雑で構成および保持できない場合。
 と記載があります。

(参考)Fault Tolerance の使用事例
http://pubs.vmware.com/vsphere-60/index.jsp#com.vmware.vsphere.avail.doc/GUID-54BD5561-C79E-4845-8C13-AE88C9CB6681.html

FTは、高可用性な環境がアプリケーションの変更が一切不必要で構成できるという点では,確かにこれに勝る高可用性は無いと思います。

ただ、これはデメリットにもなり得るケースがあります。
FTで、カバーができない点を見ていきましょう
  •  アプリケーションサービスの異常終了の検知
    (昔はApp-HA機能があったがvSphere6で廃止)
  • OSのBSOD/Kernel Panic
    (VM-HA機能により仮想マシンリセットが行われる)
  • パフォーマンスの問題
要するに、アプリケーションやOSなど、 仮想マシンより上のレイヤーの障害を検知できないため、上位レイヤーでの障害があってもその状態を常にミラーし続けることになります。

仮にFTで同期をとっているアプリケーションサーバーがログファイルでディスクフルになってしまい、サービスアプリケーションが落ちた場合、同じ仮想マシンが同期されているため、待機系の仮想マシンでもディスクフル状態のためサービスアプリケーションは起動できない状態になります。
つまりこの場合、メンテナンスをユーザーがしない限り障害は完了しません。
これは、OSレイヤーのクラスターの場合は、サービスの異常終了を検知して、待機ノードでサービスが起動させることができます。ログディスクを共有ディスクでない場所に保存しておけばその影響も受けません。
また、OSの異常状態になった場合、FTの場合はOS再起動になるため、OS起動までの時間サービス無停止となります。この場合もOSレベルでクラスターを組んだ場合は、稼働ノード停止を検知したら、すぐに待機ノードでVIPを引き取り、サービスが起動が行われます。

パフォーマンスの問題も重要です。
vSphere6のFT機能は、10Gbpsのロギングネットワークで、CPU/RAM/ディスクIOのいわゆる仮想マシンのすべての命令を同期します。
仮に共有ディスクI/Oが10GpsのiSCSI等の場合、ディスクバスでDiskI/Oが10Gbps出ていますが、同期側はディスクI/O以外にもメモリーやCPU命令を同期するため、その遅延に足を引っ張られる可能性が有り、パフォーマンスとしては、  シングル構成に比べて劣る可能性があります。
この場合はOSクラスター(共有ディスク構成の場合)やVM-HAの場合は、同期がそもそも不要なため、このようなパフォーマンスの心配も不要です。

このため、アプリケーションの高可用性を考えた場合、FTよりもOSレベルのクラスターの方がメリットが出るケースもあります。

手軽なOSクラスターとしては、やはりWindows Serverに標準で搭載されている、「Microsoft Windows Fault Tolerance Cluster (通称:MSFC/WSFC)」でしょう。

でも、WSFCをvSphereで利用する時は、RDMで物理互換モード利用が必須なんで、メンテナンス性が悪いよねと言われていました。(かといって今時物理サーバーで構成するのもナンセンスだし)

しかし、vSphere6からは、RDM物理互換モード構成であってもvMotionがサポートされましたので、メンテナンス性も今までの仮想マシンと同じようにできます。

高可用性と行っても要件によってよく吟味する必要があります。

簡単にメリット・デメリットをまとめておきました。

機能メリットデメリット適用範囲
VM-HA
(VM High Availability)
・可用性が組めないアプリにおいても簡易的に可用性を担保できる・停止が発生するとOSの再起動が発生するため、最低でもOS起動までの停止時間が発生する。
・OS破損の場合は、回復できない。
可用性がとりあえず担保できればよいレベル
(多少の停止時間が合っても問題ないレベル)
VM-FT
(VM-Fault Tolerance)
・可用性が組めないアプリにおいても簡易的に可用性を担保できる
・物理ハード障害の場合、完全無停止でフェールオーバーが可能
・OSやアプリケーションレベルの障害の場合、検知ができない/時間がかかるケースがある。
・OS破損の場合は、回復できない。
・VM-HAに比べてパフォーマンスが落ちる
・HAに比べて、待機ノードも稼働しているためリソース効率がよくない
VM-HAよりも高可用性を望まれる場合
WSFC/MSFC
(OSクラスター)
・アプリケーションの異常終了においてもフェールオーバーが可能
・メイン系がOS異常による障害であっても待機系で稼働が可能
・待機ノードが必須のためリソース効率がFTほどではないがよくない。
・OSクラスターに対応していないアプリケーションは利用できない。
・構築が複雑
アプリケーションサービスの停止時間を限りなく短くしたい

冗長化(高可用性機能)は、適材適所で選びましょう!




vSphere6で強化されたフォールト トレランス機能(FT機能)では、共有ディスクは必要?不要?

vSphere6になって、一部の方から待望であった、FT(フォールトトレランス)機能のマルチvCPUがサポートされるようになりました。
(本件は、vSphere6 アップデート情報(6) FT機能のアップデートについて で記載しています)

ミッションクリティカルな現場では、FTによる高可用性は非常に魅力的で有り、またVMware以外のハイパーバイザーではFT機能は搭載されておらず、差別化も可能な機能でも有りあります。

さて、以前に記載したとおりFT機能は、従来のLockStepテクノロジーから全く新しいアーキテクチャーに変更されました。

ポイントは3つです。
  1. 10Gpsのロギングネットワークの構築が必須
  2. ロギングネットワークを利用し、 CPU命令/メモリー情報/ディスクI/Oのすべてが同期される
  3. 仮想マシンのVMDKは、稼働しているDatastoreと別のDatastoreに配置し、フルクローンされる
という点です。
ポイントの2点目です。従来は共有ディスクが必須で有り、ディスクI/Oは、ロギングネットワークでは同期されず、CPU命令やメモリ命令がESX(i)筐体間で同期をとっていましたが、vSphere6のFT機能は、CPU/メモリー情報に加えて、ディスクの読み書き情報もフルで同期されるため、10Gbpsのロギングネットワークが必須となりました。

従来は共有ディスクが必須であったというのはポイントですが、逆に共有ディスクの障害にはFT機能での対応できなかったというシングルポイント(欠点)が今回解決されたことはよくなった点でもあるでしょう。

アーキテクチャーの簡素図

さて、ここで疑問になる点は、FTで同期をとっている待機系を指定する際に、稼働しているデーターストアと別のデーターストアに配置する点です。
ということは、共有ディスクは不要で、FTを構築することが可能なのか???というところはコストの厳しい現場ではなんとしても気になるところですね。

vSphere6のドキュメントで可用性の項を読んでも、共有ディスクが必須という記載はどこにもありません。ということは共有ディスクなしでいけるのかと思い確認をしてみました。

まず、結論から言いますと、共有ディスクは必須です。

その理由を説明しましょう。

まず、FTで構成する際に、設定が必要なファイルが3つ有ります。この3つの配置先ストレージを選択する画面が表示されます。


この3つにポイントがあります!
まず、VMXファイル、つまり仮想マシン構成ファイルと、スプリッドブレインを防ぐためのタイブレーカーファイル共有ディスクのデーターストアにしか配置できない仕様になっています。
仮想ディスクファイルであるVMDKは、共有ディスクにこだわらず、ローカルディスクのデーターストアにも配置可能です。

たしかにスプリッドブレインを防ぐためには、クォーラムディスク的なものが必要になりそうなると共有ディスクは必要になりますね。

ただ、VMXファイルもが共有ディスクにあるということは、PDLのようなトラブルでこの共有ディスクが見えなくなると、おそらくFTの仮想マシンも停止するような気がします。
(ということは、せっかくVMDKを分けていても、結果仮想マシンは停止する・・・)

ということで、共有ディスクはFT(フォールトトレランス機能)を構成する際に必須と言うことで覚えておきましょう。


その他にも確認事項がたくさんあります。
詳しくはこちらをチェックしておきましょう。





2015年10月10日土曜日

vSphere6Update1環境下で、Horizon Viewのリンククローンのプールでリコンポーズができない

さて、vSphere6 Update1を利用為た環境下で、Horizon Viewのリンククローンデスクトップのリコンポーズ(ReCompose)ができない症状が出るようです。

確認をしてみると、ちゃんとKBが出ていました。

(参考)KB:2133018
さて、こちらを確認すると、

  • Creating and recomposing linked clone desktops fails on VMware Horizon View 6.1.x and all older releases after upgrading to vSphere 6.0 Update 1
  • The Linked Clone desktop appears to be created on vCenter, but is deleted soon after vCenter complains about either "disposable" or "internal" .vmdk files this desktop

と記載があります。

まず、組み合わせとして、Horizon Viewが6.1.1以下及び、ESXi 6.0Update1の組み合わせの環境で生じるようです。
また、ディスポーザルディスク等が作成後、削除されタスクが不正終了するようです。

さてこの問題ですが、

This issue occurs when older versions of Horizon View Composer prior to VMware Horizon 6.2 require SSL v3 to communicate with VMware ESXi hosts and SSL v3 is disabled starting with VMware ESXi 6.0 Update 1 hosts. 

と記載があり、ESXi6で、SSLv3が無効になっているために起きる症状のようです。


解決方法ですが、「Horizon View 6.2」にアップグレードしてくださいが答えとなりますが、SSLv3を有効にする方法もKBとして紹介されています。

(参考)KB:2121021

セキュリティ的にも、SSLv3を有効にするよりは、Viewを6.2にバージョンアップすることをお勧めしますが...。





「ホスト 192.168.1.X のシステム ログは非持続性ストレージに格納されます」のメッセージを消す

USBメモリーやフラッシュにESXiをインストールし、共有ディスクを利用為ている場合、このような画面に遭遇することがあります。



さて、このメッセージが出た場合、基本ローカルデーターストアにログを保存することを推奨しますが、共有ディスクしかない場合、共有ディスクに保存することもできます。

まずは順当に保存先を指定する場合ですが、
ESXiホストを選択し、「管理」タブから「設定」に進み、システムの詳細設定を開きます。
パラメーターが表示されますので、「Syslog.global.logDir」を編集します。



パラメーターの書き方は
[DataStore名]/Directory名/
となります。




これは、鉄板ネタですが一応おさらいをかねて記載しておきます。







VMware ESXi 6.0 U1a がリリースされました!

VMworldも終わり、大量にいろいろな製品がバージョンアップされ9月にまとめてリリースされましたが、ESXiが10/6にひそかに、Update1"a"となりリリースされています。

さて、このaは何がアップデートされたのでしょうか?

リリースノートを見る限り、機能アップデートに関しては、前回のUpdate1と変わりは無いようです。

(参考)vSphere6 Update1リリースノート
http://pubs.vmware.com/Release_Notes/en/vsphere/60/vsphere-esxi-60u1-release-notes.html

ただ、バグフィックスがいくつかされているようで、新しく記載されたところには「New」の文字が追加されています。


まずは、この問題です。
New Network connectivity issues after upgrade from ESXi 5.x to ESXi 6.0
After you upgrade from ESXi 5.x to ESXi 6.0, you might encounter the following issues:


    The ESXi 6.0 host might randomly lose network connectivity
    The ESXi 6.0 host becomes non-responsive and unmanageable until reboot

    After reboot, the issue is temporarily resolved for a period of time, but occurs again after a random interval
これは、ESXi5.xから6にアップグレードするとネットワークが不安定になる症状です。こちらはこのバージョン(Update1a)で解決したようです。

これは、パッチが出ており、KBも出ています。

KB2132153
VMware ESXi 6.0, Patch ESXi600-201510401-BG: Updates esx-base (2132153) 


このパッチが適用されたESXiイメージとして、Update1aがリリースされたようです。

あと解決された事項としては、
Python package import fails

The Python package import might fail on the newer Python version 2.7.9. The issue occurs as the newer version of Python is unable to locate the module pkg_resources.py resulting in the import pkg_resources statement to fail.
こちらは、Pythonパッケージのインポートが失敗する問題が解決下のことです。

さてそのほかにもVSANまわりのアップデート等も出ていますので、ちょっとトラブルシューティングの1つをご紹介します。
New Adding a host to a Virtual SAN cluster triggers an installer error
When you add an ESXi host to a cluster with HA and Virtual SAN health service enabled, you might encounter either one or both of the following errors due to a VIB installation race condition:


    In the task view, the Configuring vSphere HA task might fail with an error message similar to the following:

    Cannot install the vCenter Server agent service. ‘Unknown installer error’
    The Enable agent task might fail with an error message similar to the following:
    Cannot complete the operation, see event log for details status.

Workaround:

    To fix the HA configuration failure, reboot the host and reconfigure HA as shown here:
    Hosts and Cluster view -> click cluster name -> Manage tab -> vSphere HA
    To fix the enable agent task failure, go to the cluster view and retry the enablement of the VSAN health service as shown here:
    Hosts and Cluster view -> click cluster name -> Manage tab -> Health under Virtual SAN category, and click Retry button on top

VSANクラスターにノード追加をするときに出るエラーについてです。
ソリューションは、"リトライ"ですね。


最後に気をつけておきたい、注意事項です。
New Legacy Fault Tolerance (FT) not supported on Intel Skylake-DT/S, Broadwell-EP, Broadwell-DT, and Broadwell-DE platform Legacy FT is not supported on Intel Skylake-DT/S, Broadwell-EP, Broadwell-DT, and Broadwell-DE platform. Attempts to power on a virtual machine will fail after you enable single-processor, Legacy Fault Tolerance.

vSphere6になって、FTのアーキテクチャーが大きく変わりましたが、実は昔のFT機能(ロックステップテクノロジー採用の旧アーキテクチャ)も動作させることができたのですが、この機能は、2015年8月にintelからリリースされた最新SkylakeベースのCPUと、2015年6月にリリースされたBroadwellベースのCPUでは、サポートされないことが明記されています。ワークアラウンドはありません。新しいFTのアーキテクチャーで運用するしか方法がないと言うことになります。

すべてを紹介することはできませんが、重要事項だけご紹介させていただきました。
詳細は、リリースノートをご覧ください。

すでにUpdate1を利用されているユーザーさんは、10/4のリリースのパッチを適用するだけで、Update1a相当になるはずですので、わざわざESXiのアップグレードまでは必要なさそうです。












2015年10月7日水曜日

Hybrid Cloud Managerは、VPC/VPC Ondemandには、残念ながらまだ未対応のようです

さて、先日お伝えしたHybrid Cloud Managerですが、肝心のvCloud Airの契約情報を入れるところで、VPCやVPC Ondemandの情報を入れようとすると、はねられてしまいます。
どうやら、現行はDedicated Cloudのみの対応になっている模様です。

さて、この登録の仕方にも癖があります。

まずは、登録画面まで。
Hybrid Cloud Managerのプラグインが正しく登録されると、メニューにアイコンが表示されます。

vSphere Web Clientを起動すると、Hybrid Cloud Managerのアイコンが表示されます。
(Hybrid Cloud Managerの有無にかかわらず、標準でアイコンが表示されますが、こちらはvCloud Airの案内と登録画面へのガイダンスしかありません)
アイコンは、旧VCHS Pluginと同じアイコンが、Hybrid Cloud Managerのアイコンとなります。

Hybrid Cloud Mangaerの画面から、登録を行います。


vCloud Airの契約情報登録画面が表示されます。
登録に必要な情報と注意点は以下の通りです。


Org URLの場所は、
このvCloud Director API URLになります。

登録時のポイントは、
「Org Name」の箇所は、必ずVDCの名称と同じものを入れます。
(自分管理用の名前を入れると登録できません)

「UserName」は、ログインに利用するメールアドレス「xyz@example.com」の後ろに@をつけて、VDC名をつけることです。(xyz@example.com@VDC01)

「Org URL」は、上記の通り、vCloud Director API URLを取得し張り付けることで登録が完了します。

少々ややこしいので、こちらは注意事項として押さえておくべきポイントでした。

ちなみにDadecated Cloudは、価格も高いのでそんなにユーザーさんがいないのが現状でしょうから、Hybrid Cloud Managerの恩恵を受けられるユーザーはまだ少ないと思います。
早く、VPCやVPC Ondemandの対応を期待したいところです。



2015年10月3日土曜日

Hybrid Cloud Manager がついにダウンロード可能に!

VMWorld 2015の目玉でといってもよかった、vCloud Airのアップデートの数々。
その中で出てきた「Hybrid Cloud Manager」のリリース。

9月より提供開始と言われていましたが、vCloud Airの契約があってもMyVMwareの一覧には出てこず、入手方法が不明と言われていましたが、ついにダウンロード先が公開されました。

ダウンロードリンク先は、こちらとなります。
https://vcloud.vmware.com/jp/service-offering/hybrid-cloud-manager


こちらからダウンロードが可能なのですが、あらかじめMyVMwareにログインしておかないと、ログイン画面に飛ばされた後普通のMyVMwareトップページに進んでしまいますので、注意してください。


リリースノートもしっかりありますので、こちらで事前確認が必要ですね。


◆My VMware Hybrid Cloud Manager ページ(要My VMware ログイン済みであること)
https://my.vmware.com/en/group/vmware/details?downloadGroup=HCM100&productId=343




早速リリースノートの重要事項を見てみましょう。

まずは、既知の問題点です。

・Hybrid Cloud Service virtual appliances (Cloud Gateway, L2 Concentrator, WAN optimization) should not be removed while services are running.

Hybrid Cloud Managerから展開される各バーチャルアプライアンスを手動でインベントリから消すとおかしくなりますという話しですね。これはまあ、わからなくは無い話しです。

・The Hybrid Cloud Manager web server component might fail to initialize on appliance bootup.

Httpdサービスが、アプライアンス起動時うまく起動できないことがあるようですね。
ワークアラウンドは、

/usr/local/bin/sudo /etc/rc.d/init.d/ApacheHttpd stop

/usr/local/bin/sudo /etc/rc.d/init.d/ApacheHttpd start
で、Apacheの再起動です。
なんと、古典的ではありますが...。



あとは、考慮点ですね。

Scheduled Switchover task appears to be stuck at 80% and switchover is not initiated at the expected time.

When a client browser is running in a time zone which is behind UTC, a switchover scheduled for the current day of the week might be delayed one week.

UTCよりも時間が先のエリアを選択されていた場合、タスクが80%で停止し、週間以上タスクが遅れて実行されるようです。
これは、日本では結構イタい仕様ですね。あらかじめ、UTCで設定しておき、スケジュールは9時間遅れで指定するのがベストプラクティスでしょう。



MAC address is always retained for a VM migrated from vCloud Air to vSphere.

これは、お約束です。MACアドレスはマイグレーション時には引き継がれますという話しです。



The VM power state is incorrectly listed in the reverse migration wizard.

逆方向マイグレーションとありますので、vCloud Airからオンプレにマイグレーションする際に、仮想マシンのパワー状態が誤って表示されるようです。これはバグのような気がしますね。 ソリューションは、あらかじめ仮想マシンのパワー状態を確認しましょうとのことで、こちらも古典的な対応となります。


The migration wizard occasionally displays negative values for the Available vDC resources (CPU / RAM).

これもバグの要素が高いですが、リソースでマイナスの値が表示されるのは無視してくださいというソリューションです。


On VMs with multiple vNICs, only the first vNIC attaches to the designated network. The remaining vNICs arbitrarily connect to other networks.

マルチNICな仮想マシンを移行するときは、延伸されたネットワーク以外のネットワークを移行時に選択することができません。そのため、移行後にvCloud Air上で割り当てたいネットワークを手動で設定する必要があります。


Migration of VM fails when VM name contains special characters.

これもお約束ですね。仮想マシン名に「~`!@#$%^&*()+={[}]|\:;"'<,>.?/」な文字が入っている場合、移行に失敗するとのことです。


機能が限定されていることも有り、現行ではそこまで運用上考慮する点はなさそうですね。
vCloud Airをお使いのユーザーさん、またこれからvCloud Airを使うことを検討されている方は、是非、Hybrid Cloud Managerも導入してみましょう。