2015年5月31日日曜日

vCloud Air を学ぶ(4) クラウド上で独自の仮想マシンを作る

いわゆるIaaSサービスは、すでにOSがインストール済みのテンプレートを選択することで、自分の仮想マシンとして利用できるようになるのが一般的です。
では、テンプレートに存在しないOSを利用為たいときはどうすればいいのでしょうか?

他のメジャーIaaSサービスでは、ちょっと作業が大変そうですが、vCloud Airは、楽なんです。

そう、vCloud Directorがあるからです。

APIもコマンドも利用せず、GUIから、OSのイメージISOファイルをアップロードし、仮想マシンを作成後、ISOをマウントすることができます。

カタログ機能で好きなカタログを作成後、仮想マシンにISOがマウント可能です。



近いうちに、テンプレートからの仮想マシンの展開ではなく、自分でOSからインストールする手法を具体的にお伝えしたいと思います。

2015年5月24日日曜日

vCloud Air を学ぶ(3) Airの管理基盤

vCloud Airの基盤は当然、vSphereです。
ただ、そのままvCenter Serverを、一般ユーザーに公開してしまうと、VPCのようなシェアード型の場合他ユーザーの 仮想マシンが操作できてしまうといった問題が生じます。

そのため、 vCloud Airを契約したユーザーに提供されるのは、vCloud APIを経由した、WEBコンソールとvCloud Directorの画面となります。

WEBコンソールは、簡単に操作ができるのが特徴ですが、自ら希望するOSのISOイメージからのかそうマシン展開等、ちょっとイレギュラーに作業ができず、そういった詳細な設定をする場合は、vCloud Directorの画面を操作することになります。

ちなみに、vCloud Directorは、VMwareの一般に発売されている製品で有り、組織内におけるプライベートクラウドを構築する際の製品になります。


WEBコンソール画面



vCloud Director画面




vCloud Directorをお使いの化であれば、おわかりの通り、仮想マシンはvAppという単位で管理をしていきます。

では、次回からは実際に仮想マシンを構築するところを見てみたいと思います。


2015年5月22日金曜日

ラージページにおけるTPSの動作について

先日のvSphere6のアップデート情報の中で、仮想マシンのメモリー情報の重複排除機能(TPS)がデフォルト無効になった話をしました。

そもそもWindows7等々のOSは、メモリー管理にラージページ(2MB)を使用しており、この場合、比較で2MB単位で同一のページを重複排除するとなるとそうそう同じブロックがあることはないわけで、実質重複排除の効果はそこまで無いと言われています。

そのため、現行のESXiの動作としては、

Windows Vista/7等々の新しいアーキテクチャーのOSにおいては、ESXiホストのメモリー容量が枯渇するまでは、デフォルトでTPSは動作しないようになっています。

ちなみに、XP時代と同じようにTPSをESXiホストのメモリー空き容量にかかわらず動作させるには、

VM単位での設定: monitor̲control.disable̲mmu̲largepage = TRUE
ESXi単位での設定 : Mem.AllocGuestLargePage = 0

のパラメーターを設定することで動作可能となります。

ちなみに、ラージページの場合、2MBのメモリー情報を4KBに分割して重複排除を行うため、ホストの不可を考え、デフォルトでは重複排除が不要なときしか動作しよう担っているのだと思われます。

VMware KBより
Transparent Page Sharing (TPS) in hardware MMU systems (1021095) 

2015年5月20日水曜日

vCloud Air を学ぶ(2) ハイブリッドクラウドの意味


今日はvCloud Airの"ハイブリッドクラウド" という意味について解釈を考えてみたいと思います。

vCloud Airは、「真のハイブリッドクラウド」という表現をしているのをよく見ます。
ハイブリッドというと、車のイメージが強いですが、ハイブリッドカーもガソリンと電気の両方のエネルギーを効率よく使うという仕組みです。vCloud Airも、オンプレのリソースとパブリッククラウドのリソースを上手に使い分けましょうという意味をさしています。

実際、いろいろなパブリッククラウドサービスがありますが、現在オンプレの環境をすべて、パブリッククラウドの持って行くことは、現実的に可能なのでしょうか?
SOHOや小規模な企業であれば可能でしょうが、ある程度の規模の会社であれば、ADや大容量のファイルサーバー、基幹システムホストとの連携サーバーなど、なんらかのサーバーはオンプレで運用しざるを得ないケースがあると思います。

その際に、他社のクラウドサービスの場合は、そのクラウドサービスのWEB画面から仮想マシンの設定やネットワークの設定を行い、オンプレ側はvSphereであれば、vCenter Serverを経由して、vSphere Web Clientを使って、設定することになるかと思います。

だいたいお察しが付くかと思いますが、この場合、パブリッククラウドとオンプレの環境で別々のコンソールを使い、別々の概念で管理を行う必要があり、管理が一元的ではなくなってしまいます。

もっと、突き詰めて考えてみましょう。今までオンプレだったサーバーを、AWSに引っ越しました。
実際のオンプレ仮想マシンのAWSへの投入に対する情報はたくさん有り、簡単に移行できました。

では、もっと安いクラウドサービスができてそのサービスに引っ越すことになりました。
または、仮にAWSのパフォーマンスだと、業務に支障が出ることがわかり、一旦オンプレにその仮想マシンを戻すことになりました。

さあ、この際の手順はAWSから詳細な手順は、どれだけあるのでしょうか?
仮想マシンをお引っ越しする際の回線費用はどうでしょうか?

Windowsの仮想マシンであればまだ、よいのですが、AWS Linuxでサーバーを構築した後、それをオンプレに引っ越しできるのでしょうか?

オンプレに戻すのに手探りで仮想マシンを戻すとなれば、危険性もありますし、調査等に時間を要すれば、業務にも支障が出ます。

いずれも頑張ればできないことはないですが、時間的な問題、コスト的な問題、面倒な手間のかかる事が予測できます。

 vCloud Airは、オンプレもvSphere基盤の環境、vCloud Airの基盤もvSpherer基盤であり、VMware Toolsの入ったオンプレの仮想マシンをそのまま、vCloud Airにポイっと持って行けばそのまま動作します。また、vCloud Airで構築した仮想マシンも、VMware Toolsをインストールしますので、その仮想マシンをオンプレに簡単に持ってくることができます。

仮想マシンの持ち込みも持ち出しも、前回の投稿の通り、vCloud Airはリソース貸しのサービスですので、トラフィック量等に関係なく固定料金の支払いでOKです。

では、先ほど問題提起した管理の面は、パブリックとオンプレで分かれるのかと言うと、
厳密言えば管理区分としては分かれますが、1つのコンソール画面で、オンプレvSphere環境とvCloud Airの仮想マシンを管理できます。

その統合管理を支えるツールとして
  • vCloud Connector  (vCC)
  • vCenter Serverにプラグインである VCHS Plugin
の2つが用意されています。

vCCは、オンプレの仮想マシンのvCloud Airへのお引っ越しや、vCloud Airからオンプレへのシームレスなお引っ越しのオペレーションが可能です。

現実を考えた時に、オンプレとパブリッククラウドを、お互いの良さを利用し、かつ効率的な管理を実現する、それがvCloud Airの目指すところで有り、ハイブリッドクラウドなのだと思います。

今後、AWSやAZURU、vCloud Airなどそれぞれのパブリッククラウドを統合的に管理できるツールが出てくることは想定できますが、それぞのサービスでできることは、違っていますので各サービスのできることだけができるツールとなると設定できる項目はかなり減ってくるでしょう。

基本的にvSphereでできることは、 vCloud Airでもできるということになりますので、この2点間において仮想マシンに対する設定内容は同じですので、オンプレとクラウドで同じ操作感が得られます。

まさに、vCloud Airは、vSphereをオンプレで使う人にとってのハイブリットクラウドの解を目標としたサービスだと思います。

2015年5月19日火曜日

vCloud Air を学ぶ(1) サービス編

google先生に聞いてみても、日本語のvCloud Airの情報というのは非常に少ないですね。
せっかくなので、私が調べたvCloud Airの情報をまとめておきたいと思います。

vCloud Airは、VMwareがサービスする(厳密に言うと日本は、VMwareとソフトバンクグループの合弁会社)、vSphere環境で構築されたパブリッククラウドサービスです。

VMwareが目指すクラウドは、オールクラウドではなく、ハイブリットクラウドです。
このハイブリッドクラウドについては、また別の機会にお話ししたいと思います。

vCloud Airのまず第一の大きな特徴は、「リソース貸し」という考え方と言うことです。

AWSで、実際に見積もりをとってみると、すべてが従量制のため一定の条件に基づいてしか見積もりを出すことができず、実際の請求額を推測することは非常に難しいと思います。
特に通信量なんて想定することが難しく、 請求をみてびっくりと言うこともよく聞きます。

vCloud Airは、リソースのセット(CPUのクロック、メモリ、HDDなど)が1セットとなって提供されその提供されたリソースの中で、リソースが許される分だけ仮想マシンを構築してよいというサービスであり、金額も従量制ではなく、リソースに対する費用だけとなり、要はよりMAXに近いリソース使わなければ損をすると言うことになります。

vCloud Airには、3つのサービスがあります。


 ※IT価値創造塾より(http://vmware-juku.jp/solutions/vcloudair-dr/3/


占有型クラウド(Dedicated Cloud)  【通称:DC】
こちらは、いわゆる物理サーバーを貸しきりで使えるサービスとなります。クラウドの悪い点であるシェアによるマルチテナントの誰かにリソースを大きく消費され、他のサービス利用者が影響を受けるケースが、このDCでは起きえないと言うことになります。お値段もそれなりですが...

共有型クラウドサービス(Virtual Private Cloud) 【通称:VPC】
こちらが、一般的なシェアード型のクラウドサービスになります。
価格も比較的手頃で、2TBと20GBのvRAMとなれば、仮想マシン4~5台ぐらいの環境にはもってこいではないかと思います。

災害復旧サービス (Disaster Recovery) 【通称:DR】
こちらは、他のクラウドサービスではあまり目にしない、vSphereユーザーのための、DRサービスです。vSphere Replicationを利用して、Repliaction先をvCloud Airにすることができるのです。
DRの災対サイト側のコストというのは、なかなか上申しにくいものですが、このDRサービスを使えば、ストレージもサーバーもデーターセンターの契約も必要なく、DR環境が構築できます。

DCとVPCが通常の仮想マシンを立てるクラウドサービス、DRが災害対策用のサービスと言うことになります。ちなみに、DRの場合は通常は本番サイトで仮想マシンが起動していますから、仮想マシンが停止していることが条件です。もし本番サイトにトラブルがあった場合、DRサイトで仮想ましwの起動できますが、ずっとDRサイト側で本番運用することはできません。(厳密に言うとできなくはないですが、DRサービスの通常料金にプラスで料金が発生します)



2015年5月15日金曜日

vSphere6で、「廃止されたVMFSボリュームが見つかりました。」と表示される。

vSphere6の検証をいろいろしていると、ホストに「!」のアイコンが表示されていました。
内容を見ると、「廃止されたVMFSボリュームがホスト上に見つかりました。ボリュームを最新んバージョンにアップグレードすることを検討してください。」と表示されています。



しかし、VMFS5とNFS以外に構成した記憶はなく、なぜだろうと思っていたところ、
こんなKBがありました。

VMware vSphere 6 の環境で、ESXi ホストに次の偽陽性警告が表示される:廃止された VMFS ボリューム (2115503)

原因として、「この問題は、最初の検出時に、ファイルシステムのバージョンが不明な場合に発生します。」と記載があります。

要は、誤検知ですね。
実際にストレージにLUNを追加する作業をしたのですが、その際にRAWのLUNがESXiから見えてしまうと(一瞬たりとも見えないなんてことはあり得ないと思いますが)、知らないフォーマットが来たぞ、これはきっとVMFS3だという認識をするみたいです。(たぶん、VMFS5以外のフォーマットのLUNが見えると全部このメッセージが出そうな気がします)

解決策としては、管理エージェントを再起動する必要があるそうです。

SSHでESXiにログインし、

/etc/init.d/hostd restart
/etc/init.d/vpxa restart

で、解決できます。

リモートマネージメントの再起動方法
Restarting the Management agents on an ESXi or ESX host (1003490)

ちなみに、VMFS3をマウントした場合は、正常な状態としてこのメッセージが表示されますので、混同無きようにどうぞ。

ご参考までどうぞ。

vSphere6 アップデート情報(7) NFS4.1の対応と注意点

vSphere6になり、ストレージ周りの対応としては、VVOLとVSANという大きな柱の実装や機能アップが注目されましたが、NFS4.1の対応というのも、NetAppユーザーにはうれしい話しではないかと思います。

しかし、NFS4.1を利用するには注意点が必要です。

VMwareドキュメント 「NFS プロトコルと ESXi」を参照するとこのような表が出てきます。





SDRSやSRM、VVOLなどサブセットのシステムや新しめの機能に対応していないということです。その他にも、

NFS 4.1 では、ハードウェア アクセラレーションはサポートされていません。この制限のため、NFS 4.1 データストアでシック仮想ディスクを作成することはできません。 


という記載があります。

結構、機能制約が多い(=限定的サポート)と言った感じがまだあります。

また、KBを見ると


という、なんともうれしくない情報があります。

こちらは、要約すると、NFS4.1を利用していてそのホストがAll Path Down(APD)が生じた場合、ファイルロックが解除されるため、APD状態から復活してもファイルロックが無くなっているため、仮想マシンを起動し続けることができず、パワーダウンするという内容です。
ちなみに、解決法はなしです。

そもそもAPDにならないようにチーミング等の冗長化を行って頂くことが前提だとは思いますが、APDにより障害発生時に、NFS4.1を利用している場合、ファイルロックが無くなり、他のESXiから見るとただのパワーダウン状態にしか見えないため、HA によるフェールオーバーが本当に可能なのかが、ちょっと不明なところですね。

いずれにしても、NFS4.1を利用する場合は、事前検証と利用できる機能の確認が必要です。

2015年5月11日月曜日

vSphere Replicationについて(3) vSphere6上で稼働するハードウェアバージョンV11の仮想マシンは、vSphere5.5上でレプリケート可能?

前回は物理的な要因で仮想マシンが構成することができないスペックのものをレプリケート&稼働できるかを確認しました。

では、vSphere6とvSphere5.5が混在している環境で、vSphere6からサポートされた仮想マシンバージョンv11の仮想マシンを、vSphere5.5の環境下でレプリケート&稼働できるのかを確認してみました。

結果から申しますと、レプリケートはなんらもんだ無く成功します。


では、実際にリカバって見ましょう。

リカバリ先のホストを選択する画面で、



チェックに引っかかってしまいました。vCenter Server 6で管理をしているため、レプリケートはするが、実際にリカバリする際、その仮想マシンを稼働させるホスト選択時に仮想マシンバージョンがチェックされるという動作のようです。

レプリケートされた側のストレージの中を見ると、以下のようになっています。


これをみるとわかるように、VMDKはそのままに、vmx等のファイルは拡張子の後ろに管理バージョン的なものが付与されています。このvmxのファイルの中身を開くと、普通のvmxファイルの為このファイルを直接編集して仮想マシンバージョンの値(virtualHW.version)を、10等にするとvSphere 5.5でも動作するのかもしれませんが、さすがにこれはサポート対象外ですので、仮にできたとしても自己責任にてどうぞ。

ということで、vSphere5.5のホストに接続されDataStoreにvSphere6でサポートされたハードウェアバージョン11の仮想マシンを、vSphere Replicatinでレプリケートさせることは可能です。但し、実際にリカバリする際に、リカバリする仮想マシンを稼働させるホストを選択する際にバージョンのチェックが行われ、今回の場合ですとチェックに引っかかり、vSphere5.5のホスト上でのリカバリはできないという結果になりました。

vSphere Replicationでのレプリケーションの際には、仮想マシンバージョンの事前確認をお忘れ無く。(いざというときのDRですので・・・)

2015年5月10日日曜日

vSphere Replicationについて(2) 本番サイトで8vCPUの仮想マシンをDRサイトで2コア物理CPUしか無い環境で、レプリケート&稼働するのか?

前回の項でvSphere ReplicationでDRサイトを構成する場合、本番サイトとDRサイトで同じスペックのマシンやストレージを用意する必要は無いと記載しました。
では、本番サイトにXeon-E5-2670などのハイエンドなCPUを搭載し、DRサイトにXeon E5220など一昔前のサーバーを利用したいケースが有るかと思います。

この場合、E5-2670は、8コア(ハイパースレッドで16コアに見える) E5220は、2コア (ハイパースレッドで4コアに見える)と、CPUのコア数がだいぶ違います。

では、本番サイトで8vCPUの仮想マシンを運用しこの仮想マシンをDRサイトにvSphere Replicationでレプリケートした場合はどうなるのか?という質問を頂きました。

想定される答えは、そもそもレプリケートできない(事前チェックでひっかかる)もしくは、レプリケートはできるが、パワーオンできないのどちらかだと思います。

が、たしかにやったことがないですし、これが前提チェックではねられるのであれば、本番環境ではハイスペックで、DRサイトだったらちょっと遅くてもよいので低スペックのサーバーで稼働をという考えはできなくなってしまいます。

今回は、検証として以下のような環境で試してみました。

 

さて、実際にやってみると、レプリケートまでのウィザードは何事もなく完了しました。


実際のレプリケートも、きちんと完了しました。

では、本番サイトの仮想マシンの電源を落として、障害が発生した状態に見立てて、
DRサイト側でリカバってみましょう。
※本番サイトの仮想マシンの電源が落ちないと、vSphere Replicationからリカバリはできません。


 最初の滑り出しは、OKですね。


ウィザードを薦めていき、リカバリする仮想マシンを稼働させるESXiの選択で、スペックの低いマシンを選択しましたが、「検証は成功しました」と出ています。


 では、リカバリ後に電源ONにチェックを入れて、リカバリさせてみましょう。

問題なく、リカバリが始まりました。


ちょっとすると、右下になんらかのメッセージが・・・



でましたね。何となく期待通りのメッセージです。4個のCPUが必要ですが、ホストハードウェアには2個しか有りません。と・・・。(今回は、2ソケット、4コアで仮想マシンを構成したからこういったメッセージが出たようです)

リカバリされた仮想マシンは、きちんとインベントリに表示されますので、仮想マシンの編集を選択します。

CPUのところで、怒られていますので、ハードウェアサポート内のCPU数に変更します。


さて、パワーオンしてみると

見事起動しました!!

仮想マシンも無事です!





ということで、結論は、本番サイトとDRサイトで、物理CPUコア数が異なり、DRサイト上で物理コア数が足りない仮想マシンを、DRサイトにレプリケートできるかというと、レプリケート自身は可能だが、リカバリ時の仮想マシンパワーオン時にエラーが出る。手でリカバリした仮想マシンを編集し、稼働可能なスペックに変更することで稼働する!

ということです。
ちなみに、VMのコミュニティサイトでは、本番サイトをintel CPUで、DRサイトをAMDのCPUで環境を構築してもきちんと稼働するという話が出ています。
ただし、ハードウェアの構成が異なっているため、ハードウェアの再検出による再起動要求や、場合によっては再アクティベーションがゲストOS上で要求されるようです。(これも理屈からするとたしかにそうですね)

(参考)
VMware Communityより
vsphere replication cpu compatibility


ちなみに、フェイルバックは、逆方向のレプリケートを手動で作成する必要がありますので、このときにスペックの低い仮想マシンが本番環境にレプリケートされてしまうことには要注意です!





2015年5月9日土曜日

vSphere Replicationについて(1) あるある都市伝説ネタのご紹介

HyperV Replicaの登場により、VMwareにおいても、vSphere5.1から、Essential Plus以降のエディションに標準搭載されるようになりました。

VMwareのDRに対する取り組みは元々、ストレージのレプリケーション機能と連携した、VMware Site Recovery Manager(SRM)という製品があります。この製品で、ストレージでコピーされた仮想マシンをDRサイトで起動するまでの管理を行い、本番サイトとDRサイトの間のデーターコピーはストレージにお任せという形になります。

しかし、本番サイトとDRサイト間にレプリケーションが可能なストレージを用意するというのはコスト面から考えても決して安いものではなく、そこでストレージに変わって仮想マシン単位でレプリケーションをする機能を作った仮想アプライアンスが「vSphere Replication」になります。

SRMを利用しつつ、ストレージレプリケーションではなく、vSphere Replicationを利用し、DRサイトを作ることで、より手軽なDRが作成できるようになりました。

さらに、先ほど書いたようにvSphere5.1の発表と同時に、vSphere ReplicationがEssential Plus以上で無償で利用できるようになったため、SRMのようにリカバリサイトでの稼働の自動化はできないももの、定期的な仮想マシンの同期ができれば、災害対策バックアップとしてだけでも十分な利用が可能です。

しかし、vSphere Replicationをあまり活用しているケースを聞きません。

ここで、私の聞いたvSphere Replication 都市伝説をご紹介します。


<質問>
vSphere Replicationって、別にSQL Serverが必要なんでしょ?。予算ないから無償のHyper-V Replicaのほうがいいかな...。

<回答>
vSphere Replicationには、EmbededのDBが用意されており、VMのドキュメントには「最低限の利用」が可能と記載があります。実際にはレプリケーションする仮想マシンのスペックやRPOによってはたしかに、外部DBが必要かもしれませんが、個人的には小規模の環境では、EmbededDBを利用することで十分ではないかと思います。ちなみに、SQL Server以外にOracleがサポートされます。

VMware vSphere Replication 6.0 ドキュメント センターより
vSphere Replication がサポートするデータベース



<質問>
vSphere Replicationを利用するには、本番サイトとDRサイトに1つずつ、合計2つのvCenter Serverが必要なんでしょ?Essential Plusだったら、vCenter Server Foundationが1つしかライセンスがないから追加で買わないと行けないのですよね。vCenter Serverの必要スペックもvRAM 8GBとか考えると、DRサイト側のハードスペックも足りないし、追加のvCenter Serverの費用もかかるのであきらめます・・・。

<回答>
この質問意外と多いんですよね。マニュアルにも1つのvSphere Replication アプライアンスと1つのvCenterが紐付くという旨の記載があります。つまり、1つのvCenterに2つ以上のvSphere Replication アプライアンスを管理できないというのは、事実です。
でも、サイトごとにvCenter Serverが必要なんていう決まりも、vSphere Replicationまたぎでのレプリケーションしかサポートされないと言うことはどこにも記載がありません。
そうです。管理された2台以上のESXiで、1つのvCenter Serverに管理した上で、vSphere Replicationを利用することで、筐体間レプリケーションが可能です。

図にすると
小規模な環境で、本番サイトとDRサイトをそれぞれ別の場所に設置して、1つのvCenter ServerでESXiのホストを管理する形でもよいですし、本番用ESXiとバックアップ用ESXiを隣において、1つのvCenter Server上で管理し、筐体間レプリケーションが可能です。
あくまでも置き場所の問題で、本番サイトとDRサイトでWAN通信が発生し、効率的な転送を行いたい場合は、それぞれのサイトにvCenter ServerとvSphere Replication Apllianceを配置し、サイト間の通信をvSphere Replication Applianceにお任せするという構成になります。
※VMwareとしては、バックアップとしてData Protectionがありますが、バックアップはバックアップで必要な機能だと思いますが、バックアップには"リストア"の作業が必要です。
vSphere Replicationは基本丸っとコピーですから一応"リストア"というタスクはありますが、バックアップデーターを戻す作業と比べると、かかる時間はごくわずかです。



<質問>
本番サイトとDRサイトに同じサーバーやストレージの構成なんでしょ?。本番サイトにはある程度お金がかけられても同じ環境をDRにもなんて、役員会で却下ですよ。

<回答>
仮想化の良さはハードウェアに依存しないことです。質問の見解は、仮想化の良さをなくすような話になってしまいます。たしかに、Site Recovery Managerが出た当時は、ストレージ間レプリケーションだったため、基本同じメーカーのストレージ(同じモデルシリーズのストレージ)だったこともあり、またストレージの種類にもよりますが基本、LUN単位でのレプリケーションがほとんどだったと思いますので、レプリケーションが不要な仮想マシンまでもレプリケートの対象になってしまうことがありました。このイメージがへんな形で残ってしまっているのだと思います。
vSphere Replicationは、仮想マシン単位でレプリケート対象を決められますし、vSphere(ESXi)が、本番とDRのそれぞれのサイトで稼働していれば、ハードウェア・ストレージの種別は問いません。

本番サイトは、仮想マシンが100台有るので、SASディスクの高級なFCストレージとXeonの4Wayの高級なサーバーを、DRサイトには最低5台の仮想マシンが稼働すればいいので、Xeonの1Wayサーバーに、SATAディスクのDASで...。という環境でもOKです!!

VMが稼働する環境であれば、本番とDRで同じサーバーモデルやスペックをそろえる必要はありません。



<質問>
うちの大事な仮想マシンは、10TBもあります。WAN回線はフレッツ光程度以上のものはコストが高く引くつもりもないので、レプリケーションなんて無理ですよね。

<回答>
必ずしも無理ではないです。まずはRPO(復旧地点)が15分前までという設定をしたときと24時間という設定をしたときでは、転送されるデーター量は異なるでしょう。また、常にマスターデーターがコピーされているわけではなく、たしかに一発目はフルローン的に全データーがコピーされますので可能であればローカルで行った上で、DRサイトの持って行けば、CBTによる変更ブロックだけの転送となるため、毎日10TBの変更があれば話は別ですが、変更分がすくなければ、余裕だと思います。また、vSphere6からは、Replicationの通信にネットワーク圧縮の機能も追加されていますので、こちらも機能的には期待できそうです。


ということで、vSphere Replicationあるある質問でした。
実は結構使い前有るんですよ。vSphere Replicationって...。
手軽ですので、vSphere6からは、vSphere Replicatioのレプリケーションにネットワークの圧縮機能やvmdkの未使用領域をレプリケート対象から外すなどの機能追加もあり、さらに適用の範囲は広くなっていると思います。

バックアップとレプリケーションをうまく使い分けることで、コストバランスのとれたDRの現実解が必ず見えてくると思います。

2015年5月5日火曜日

vSphere6 アップデート情報(6) FT機能のアップデートについて



vSphere6の機能の中で、待ちわびていた人も多いと思われる、FTのマルチvCPU対応。


まずは、現行までのFTのおさらいを。

今までのFTは、VMware Workstaionに搭載された、Record/Replayテクノロジーの機能を応用して作られていました。このRecord/Replayテクノロジーとは、マスターの仮想yマシンの命令情報をセカンダリーの仮想マシンに転送し、同じ命令を流すことで常に同期された仮想マシンができるという仕組みでした。

「処理を行う前の命令情報を2つの仮想マシンで同時に流す」ということは、マルチコアに仮想マシンになった場合、その命令がどのコアで実行されるかはわからないため、マスターとセカンダリーで違うコアで1つの命令が処理されてしまうと、処理の不一致が発生してしまいます。

これが、マルチコアのFTに対応できない理由でした。

で、vSphere6からは命令が処理された結果情報を仮想マシン間で同期されるように変更されました。また、従来はFTの仮想マシンに対して1つのVMDKをマスターとセカンダリーがともにつかんでいる状態でしたが、vSphere6からは、仮想マシンをFT設定した時点でフルクローンの仮想マシンが作成されます。

マスターの仮想マシンが起動し何らかの処理がなされると、その処理結果の内容をもう1台の仮想マシンにすべて送られるという仕組みです。

従来は、CPU命令だけをコピーしていたのですが、命令処理後の内容をコピーしていく高千に変わりましたので、RAMの情報、HDDの情報など従来のFTよりもコピーされる内容は多くなっています。
そのため、FTログ同期NICが、10Gbpsのみのサポートとなっています。

また、マルチコアといえども、たくさんの処理が行われるとそれが全部セカンダリーのマシンに転送されるため、シングルの仮想マシンと比べるとやはり速度は遅くなると思われます。ネットワーク通信の処理を行うと、ネットワーク通信情報の同期と処理内容の同期が走るため、このパターンもかなり速度が低下するような気がしますね。

ちょっと改善された点としては、Thinディスクがサポートされた点でしょうね。

FT機能はは、vSphere6 StandardおよびEnterpriseは、2vCPUまでのサポート。

Enterprise Plusにしないと、4vCPUをサポートされない点もあわせて注意をしたい点です。

2015年5月3日日曜日

vSphere6 アップデート情報(5) vCenter Server で利用するDBについて

vSphere6は、vCenter Serverにかなり大きな変更が入っています。
そのほとんどは、vCenter をまたいだなんらかの操作(vMotionやメディアサーバーなど)ができるようになったためです。vCenter Serverのリンクモードのアーキテクチャーが大きく変えたことで実現できた話ですが、その話は以前に書いた通りです。今回はvCenter Serverで利用できるデーターベースサーバーについて変更点を見てみたいと思います。

ちょっと昔の話ですが、vCenter Server 4.xや5.0時代は、そもそもvCenter Serverを構成するには、別途SQL Serverを用意しておかないといけないという暗黙の了解がありました。(OracleでもOKですが)

vCenter Serverのインストールが大変面倒ということもあり、vSphere5.1時代になって、アプライアンス版が登場しましたが、こいつも外部DB(Oracle Only)を接続しないと、Windows版vCenter Serverの標準DBである、SQL Server Expressと同等の「いわゆる最小の構成(ホスト5台、仮想マシン50台)が適用されていました。5.5になって、アプライアンス版は少し対象台数が増えましたが、6.0になってさらに管理可能台数が増えました。

まずは、おさらいもかねて...

アプライアンス版
vCenter Serverの
バージョン
最大管理可能
ホスト
最大管理可能
仮想マシン
DB
5.1520DB2
5.51003,000Postgres
61,00010,000Postgres


と実用に十分なスペックになっています。 まあ、アプライアンス版は5.5からある程度使いものになっていたのですがさらに、 Windows版を見てみましょう。

Windows版
vCenter Serverの
バージョン
最大管理可能
ホスト
最大管理可能
仮想マシン
DB
5.1520SQL Server Express
5.5520SQL Server Express
620200Postgres

そうなんです。Windows版もバンドルされるDBが、vPostgresに変わったことにより、最大数がホスト20台、仮想マシン200台に格上げされています。この規模であれば、中堅規模まではバンドル版DBでいけそうですね。 これで、Windows版のvCenter Serverを入れるのも楽になります。 ただし、6.0からは、アプライアンス版とWindows版の機能差異がなくなりましたので、あえてWindowsを選択するということ自体がなくなるかもしれません。

2015年5月2日土曜日

vSphere6 アップデート情報(4) メモリーの重複排除(透過的ページ共有)はデフォルトでは有効ではありません

結構衝撃的な話なのですが、仮想化して集約率を上げるには、複数の仮想マシンの透過ページ共有(TPS)がデフォルトで無効になっています。
つまり、同じWindows Server 2012 R2を10台起動した場合、OS部分はどの仮想マシンも同じなのでそのメモリーは共有して、メモリーの空き容量を有効に使う機能です。

なぜTPSが無効になったかというと、研究機関からメモリーを共有された仮想マシン間で、相手の仮想マシンに侵入することができる(メモリー内容を見ることができる)可能性が論理的にある(かなり要約)という学術結果が発表されたそうで、その対処のようです。
ただ、これは机上の論理であり実際にはあり得ないとVMwareは考えているようです。

詳しくは 
セキュリティの考慮事項および仮想マシン間透過的なページ共有の禁止 (2100628) 
をご確認ください。

個人的にはいらんこと研究してと思わなくもないのですが、一応従来通りに動作をさせることは可能です。

ちなみに、この機能変更はvSPhere6というよりも、vSphere5系の最近のアップデートでも同じデフォルト値が変更となっています。


参考:

Security considerations and disallowing inter-Virtual Machine Transparent Page Sharing (2080735)



ちなみに、ESXi (vSphere5.5 Build 2143817)では、
デフォルト0で、最大値が1となっています。

これが、vSphere6では、デフォルト2となります。

で、TPSを有効にする際のパターンが増えています。
動作
0すべての仮想マシンでTPSが有効
1salt値が一致する仮想マシン間でTPSが有効
(なければ、原則TPSを共有)
2salt値が一致する仮想マシン間でTPSが有効
(salt値がなければ、
仮想マシンのUUIDが一致する仮想マシン間でTPSが有効)
※仮想マシンのUUIDが一致することはないので事実上無効


さあ、ここで出てくる「salt値」なのですが、仮想マシンごとに
sched.mem.pshare.salt というパラメーターは、自動的に付与されません。
そのため、手動でこのパラメーターを作成する必要があります。

特にVDIにおいては、たくさんの仮想マシンを個別で設定することはできませんので
Horizon View Administratorのプールでsalt値の設定がデフォルトでできるようになっています。


そもそも オーバーコミットを前提としたサイジングはあまりお勧めではないと思いますが、
リソースの節約という意味では非常に大きな機能ですので、抑えておいたほうがよい変更点ですね。