アドナンスVMストレージ・オプションはパフォーマンスを改善することができますが、物理LUNが正しく設定されいなければ、その恩恵からは遠いものになります。
LUN設定ではハードウェア選択、I/O最適化、VM配置などすべてが重要な要素となります。
●ハードウェアとLUNの構成
LUNを提供するハードウェアによってVMパフォーナンスは全然違ったものになります。ディスク。サブシステムへの負荷を軽減するためにはユーザのホストシステムと似たリソース・レベルでのハードウェアを選択することです。6コア・プロセッサーと128GB RAM付のクラスター・サーバと１GBリンクでiSCSI SATAのSANに接続するようなデザインは推奨されません。明らかに転送かディスク・レイテンシー・レベルでストレージ・ボトルネックが発生します。
ユーザの仮想インフラの最善のLUN(logical unit number)でVMのパフォーマンスを改善することができます。それらはディスク・タイプ、I/O最適化、ハードウェア、RAIDレベル等のLUNコンフィグレーションに依存します。 しかしLUNに搭載可能なLUN数はユーザのインフラとテストとディプロイ環境に依存しいます。
●VMパフォーマンスを拡張できるディスク・オプション
仮想化ではハイパーバイザは、コンピュート・リソースのアローケーションと共有が簡単に、ワークロードと他の機能が使いやすくマイグレートできるように基で稼働する物理ハードウェアからワークロードを取り除きます。最新のハイパーバイザと仮想化準拠のプロセッサーは若干のオーバーヘッドを課しますが、仮想化レイヤに起因するパフォーマンス・ぺナルティがあります。
Volume Shadow Copy Service (VSS)
Volume Shadow Copy Service (VSS)はWindowsサービスで、Windows Server 2003で管理者がバックアップ・トランザクションの一貫性を提供するように導入されました。これは、一貫した方法でデータ・コピーを取ることでプロセス全体を調整し、アプリケーションがオンラインであることを確実にします。実際にはVSSはデータのコピーを作成する訳ではなく、現状のデータ状態を保存し、その時点での状態が一貫性があることを確実にします。基本的に、VSSはそのサービス自体と、VSS requestor, VSS provider,VSS writerの3つの補充コンポーネントとのスムースなコラボレーションと調整を行います。
VSS requestorは捕捉するデータをフリーズさせるコンポーネントです。
仮想マシン（VM）のようなワークロードは、ストレージ・ロケーションが適正な容量とパフォーマンスを提供していいればストレージ・ロケーションには影響されません。
ローカルなデータ・ストレージは、単純に多少優れたパフォーマンスをもたらすことができます。それは6Gbps(SAS)のようなディスク・インターフェイスは高速ストレージ・タスク専用だからです。またローカル・ストレージはネットワーク経由のデータ転送には依存しません。それによりネットワークのボトルネックと中断から解放されます。
ディスク・レイテンシー（待ち時間）には最も注意すべきです。シングル・ディスクは、1つのスピニング・プラッタを持っているのみなので、プラッタはリード/ライト・ヘッドの基でセクターを回転するので回転待ち時間が起きます。シーク（検索）レイテンシーはリード/ライト・ヘッドがプラッタを越えたコンセントリック・トラック間の移動で発生します。メカニカルなディスク・レイテンシー以外にもインターフェイス（Serial-attached SCSI (SAS)等）はディスクの内部のリード/ライト・スピードよりさらに高速で、通常キャッシュはライト中に埋められ、リード中に空になります。メカニカルなシステムは単純にインターフェースとホスト·サーバーに容易についていくことはできません。
VMware vCenter Server Appliance5.5 のデフォルトの設定では、ローカルのrootアカウントのパスワード有効期限は最初に電源をオンにしてから90日間です。パスワードの有効期限を許可している場合は、90日を過ぎますとアカウントが無効になりアクセスできなくなります。
rootアカウントが無効化されロックされることを防ぐには、設定を変更します。
また、有効期限が切れてしまいVMware vCenter Server Appliance5.5 にログインできなくなった場合は、ロックの解除をする必要があります。
仮想化でどのようなメモリー管理テクニックが利用可能かを事前に認識することで、仮想化でのメモリー問題の多くを回避することができます。それらは重複するファイルを統合したり、逆にエラーの場合にファイルをコピーしたい場合等があります。また物理サーバからもっとメモリーが必要な時や、逆に物理サーバが仮想マシンからメモリーを回収する必要がある場合などがあります。
Hyper-V環境でiSCSIイニシエータは親OSでも、仮想マシン(VM)内のどちらでも実行させることが可能です。問題はそのオプションを選択する前にiSCSIイニシエータに何をさせたいかです。
どちらかのオプションを選択しなければならない唯一の状況はゲスト・クラスタリングです。もしゲスト・クラスタを構築し、iSCSI経由でゲスト・クラスタ共有ボリュームに接続した時にはVM内でiSCSIイニシエータを稼働させる必要があります。そうでなければゲスト・クラスタはその共有ストレージは適切に使用できません。
仮想マシンイメージ・ファイルをストアするにはVMwareではデータストアを使用します。ESXiの設定ではローカルのデータストアを使用する手法が最も簡単です。ただ仮想サーバ全体がダウンした時にすべてが無くなることになるので賢い手段とはいえません。
故障・災害から回避するための環境を設定するために仮想マシンのイメージ・ファイルを他のマシンへストアします。これは専用のストレージ・サーバ、NAS(Network-attached Storage)アプライアンス、ハイエンドSAN製品などのサーバを設定することです。この3つは基本的には同じソリューションを提供しますが、価格には大きな違いがあります。
Amazon Web Services(AWS)は現状のEC2 Compute Unitsを補完するサーバのパフォーマンスとキャパシティの新たな計測を Elastic Compute Cloud管理コンソールに追加しました。
vCPU(仮想CPU)はAmazonのEC2インスタンス・ディスクリプション・ページ上での計測単位である一方、ECU(EC2 Compute Units)はAWS管理コンソールからは隠れています。vCPUへの変更も課金には影響を与えません。
Veeam社は今年も第3者の調査機関に仮想化におけるデータ保護の調査を依頼し、2013年版のレポートを発表しました。今年もEnterprise企業とSMB（Small Medium Business)に対するレポートを発表しています。SMB対象企業は米国(US)、イギリス(UK)、フランス(FR)、ドイツ(GE)の従業員250から1000名の500人のCIOを対象に行われました。
よく聞かれる質問：Windows2008で稼働するアプリケーションをvSphere 5.1環境に移行したら、パフォーマンスは改善したがタイムアウト問題が発生した。プロトコール・アナライザーで確認したらサーバがアプリケーションにリセット・フラグを発行していた。どうすればいいのか!?
ネットワーク・パフォーマンス問題が起きた時にトラブルの原因がどこにあるのかを見極めるのは非常に困難です。特に仮想インフラは高度に複雑化した時はさらに厄介です。ユーザのシステムを深く調査無しでは正確な回答を出すことは難しいです。トラブルシュートが必要になります。しかしシステムを検証するために必要なツールとタイムアウトを診断する簡易ツールがあります。
(1)統合率にフォーカスし過ぎ
仮想マシン(VM)/サーバの数値でサーバ統合の統合率として測ります。統合率は物理サーバの許容量と仮想化したいワークロードのタイプに依存します。高い統合率は可能ですが、それがビジネス的にベストとは限りません。高い統合率はサーバに加重負担をかけ、災害時における故障サーバからのワークロードのリスタートを困難にします。最後に理想的なサーバ統合率の特定はバランスを取ることです。
仮想化技術と仮想マシン（VM)の一般化に伴い、その事業継続（BC:Business Continuity)と ディザスタリ・リカバリー(DC：Disaster Recovery )アクティビティについて考えることは重要なことです。
これらはユーザの仮想化BC/DRプラン、ドキュメント化、活動のヒントです。
1.何を仮想化するか、しないかを決定する。
RSSフィードを取得する
