vSphereや他の仮想環境に大規模VMをディプロイする場合には負荷分散と高可用性バランスに注意を払います。負荷分散と高可用性バランスはいつも簡単に実行できるわけではなく、自動のvSphereロードバランシングとHAツールはいつも高度の非対称環境でのタスク次第ではありません。
絶対的なRAMとCPU消費ではVM全体は分かりません。例えば最近の２Pサーバは簡単に512GB RAMを搭載できます。もし高いRAM要求で、低CPU使用率のサーバに384GB VMが常駐していていれば、低RAM要求で、高VPU使用率のの小さなVMを追加できますか？
Windows 8ではデフォルトで表示されているのにWindows Server 2012ではデフォルトで表示されていない「ディスク」の読み書き情報。
VMware vSphere内またはMicrosoft Hyper-V内のいずれを問わず、VMが正しく動作するには、仮想プラットフォームでOSとVMオブジェクトの両方が機能している必要です。どちらか一方を失えば、VMは動作しません。これは当たり前にように思うかもしれないが、多くのバックアップ ツールは、仮想化を意識して設計されていません。このような従来型ツールは、VMを構成するファイルを保護することに注意を集中し、プラットフォーム内のVMのメタデータには全く注意を払ってません。
VMwareで仮想マシンのスナップショットを作成する際に以下のようなエラーが発生することがあります。
・Create virtual machine snapshot VIRTUALMACHINE File <unspecified filename> is larger than the maximum size supported by datastore ‘<unspecified datastore>’
・File is larger than the maximum size supported by datastore
・仮想マシンのスナップショットの作成 VIRTUALMACHINE ファイル VIRTUALMACHINE/VIRTUALMACHINE.vmx はデータストア「[unspecified datastore]」がサポートする最大サイズを超えています。
通常、vSphereではスナップショットを仮想マシンの構成ファイルである.vmxと同じディレクトリに保存しています。しかし、VMFSのディスクサイズ制限(記事はこちら)により、スナップショットが作成できない場合やスナップショットを別のデータストアで管理したい場合などには必要に応じて、この保存先を変更する必要があります。
Windows Server 2012のリリースは仮想化での多くの新規改善がなされました。その大きな1つがVHDXファイル・フォーマットです。Windows Server 2012はこの新規フォーマットをサポートし、Hyper-V管理者はVHDフォーマットを使用することもできます。この2つの仮想ディスク・フォーマットVHD と VHDXの比較について考えてみます。
●仮想化リカバリー
仮想化ではVDHDやVMDKのような仮想ディスクファイルにファイルとフォルダをカプセル化することが可能です。これらのディスク・ファイルはすべての内部データを保存した仮想ディスクファイルをキャプチャしたデータベースのような動作をします。
仮想サーバをバックアップするなかでのこの新規アプローチは災害準備の景色をほとんど一夜で変えました。仮想ディスク・ファイルのバックアップでは仮想サーバのリストアではファイルのリストアが要求されます。ファイル・オン・ディスクでの、以前のバックアップ・ソリューションで苦しめられたパーシャル・バックアップ、オープン・ファイル、リストアの失敗などの問題は過去のものになりました。仮想リカバリによりバックアップは色々な状況で有効なものとなりました。
VMwareシンプロビジョンではどのようにオーバサブスクリプションに対処するのが最適でしょうか？
VMware環境でのストレージ・オーバサブスクリプションはvSphereデータストアでロジカル・スペースを物理的に利用可能以上に割当てる処理です。オーバサブスクリプションの使用は有意義なものです。それはダウンタイム無く、仮想マシン（VM)のキャパシティを増やすことができ、リソースを消費することなく標準デザインを構築できます。しかしオーバサブスクリプションした環境が物理スペースを使用し切った時に、VMスタートアップ・フェイル、スナップショット作成フェイル、低パフォーマンスと最終的なVMクラッシュ、データ損失など問題は予想不可能です。
ディザスター・リカバリ(DR)/ビジネス継続(BC)にインパクトを与える仮想化戦略
●物理サーバ数の低減：これは物理スペース、消費電力、メンテナンスの視点ではいいことですが、必要なOS,アプリケーション、データ間で使用可能なリソースを分けるということは重要なことです。
●システムに渡るインパクトの低減：ユーザの仮想サーバ内にアプリケーションがある場合、システムが他のシステムにインパクトを与える可能性は低減されます。（特に変更がある時に）
仮想環境での基本的な活動は本質的に物理ストレージ環境と同じです。クリティカルなシステムとデータを確認し、それらのバックアップとリカバリ機能を確立し、その特定したクリティカルなシステムとデータのリカバリ性をテストと検証をする必要がまだあります。しかしユーザ企業が総合的なディザスタ・リカバリ（DR)戦略/BC（ビジネス継続）プログラムを認めていても、特に大企業では何百、何千というサーバを保有する大企業では仮想化環境用途が大きな作業となっています。完全なDR/BCソリューションの開発、ディプロイ、サポート、テストは予算、人員、リソースを要求されます。
仮想マシン(VM)のクローン化、コピー、エクスポートは、時間がかかり、大量のリソースを消費する可能性があります。また、VMの電源を切断する必要がある場合には、業務に影響を及ぼす可能性もあります。しかし、VeeamZIPを使用すれば、VMを簡単にバックアップして、どんなホストにもリストアできます。
バックアップ、レプリケーション、ディザスタリ・リカバリ（DR)を統合することは中小企業(SBM)のニーズと予算には最適なものです。それらをスタートするには：
ディスク・ベースのバックアップ・ツール：オフサイトへのレプリケーションをサポートする製品の確認。よいものは同様にバックアップ時間も削減できるでしょう。毎晩のバックアップに代わって、ディスク上の変更のあった仮想ディスク・ブロックのコンスタントで確実なストリームが可能です。VMとホスト上のリソース使用上でこれを少ない労力で実行できるツールが必要です。
SMBファイル共有でVMをストアする機能はWindows Server 2012 と Hyper-V 3.0でマイクロソフトがリリースしたものです。これ以前にVMをストアするオプションは直接続のストレージ、SCSIパススルー・ディスク、FC-SAN、iSCSIストレージなどがありました。
スタンドアローンのHyper-Vサーバの場合、SMBストレージにVMを移動できるということはVM使用のローカル・ストレージでのホスト・サーバにプロビジョンが不要になります。VMはディスクI/O単位で要求され、ストレージ・アレーはほとんどの場合、適切なVMのパフォーマンスのために要求されます。ユーザはVMに必要な充分なフリー・スペースを持つ高パフォーマンスなファイル・サーバを所有しているなら専用のストレージ・アレーの出費を回避することができます。
1台以上のvCenter本番サーバを持つ多くのVMware管理者はvCenterのディプロイを物理環境のままにすることを選択しています。専用のvCenterサーバにすることで100%の仮想化に不安、不信を持つユーザをなだめているようです。管理者のなかには大規模なデータセンタで多くのホストを管理するには物理環境の方が安定していて、管理が簡単と考えているようです。
RSSフィードを取得する
