スタンドアロンESXiホストを管理するためにVMware Host Clientを使用してみる

VMwareホストクライアントは、vSphere Flashベースのクライアントよりも高速で安全ですが、まだ十分ではありません。 ESXiホストの管理に使用できるその他のツールがいくつかあります。

VMwareホストクライアントは、単一のESXiホストに接続して管理するHTML5ベースのユーザーインターフェイスです。vCenterおよびvSphere Web Clientが使用できない場合、VM、ネットワーク、ストレージなどのホストリソースを管理し、個々のVMまたはホストのトラブルシューティングを行います。もともと、VMware Labsによる開発として開発されたVMware ホストクライアントは、各ESXiデプロイメントにバンドルされています。

VMwareホストクライアントはvSphere Flashベースのクライアントよりも高速ですが、それはまだ比較的新しいものであり、まだすべてを管理することはできません。 それを念頭において、他のホスト管理ツールを見てみましょう。

ESXi エンベデッドホストクライアントは、ネイティブのHTMLおよびJavaScriptアプリケーションです。 ESXiホストはエンベデッドホストクライアントに直接サービスを提供し、その結果、クライアントは既存の製品よりも優れたパフォーマンスを発揮します。

エンベデッドホストクライアントは、ESXiインストールISOにvSphereインストールバンドルファイル(.vib)として含まれています。クライアントは急速な開発サイクルを経ているため、最新の.vibを定期的に更新する必要があります。ダウンロードしてインストールすることができます。

.vibファイルを更新するには、Manage > Package > Install Updateに移動します。 ESXiユーザーインターフェイスにアップデートをインストールします。(図1)

図1 : ESXiエンベデッドホストクライアントを介してVIBアップデートをインストール

図2に示すように、vSphereホストクライアントは、個々のVMに接続するためのコンソールの起動、VMの電源投入、VMの一時停止、スナップショットの取得、仮想ディスクの統合など、すべてのVM操作を実行します。

図2 : vSphereクライアントホストを介した単一のホスト管理

ホストがVMwareクラスタに含まれていても、VMwareホストクライアントは引き続きホストの構成を変更できます。 クライアントは、管理者がすべてにアクセスできるようにします。

たとえば、iSCSIストレージを設定する場合や、少なくともiSCSIイニシエータをアクティブにする場合などです。 Storage > Adapters > Configure iSCSIの順に選択し、表示されるメニューからEnabledを選択します。図3 : VMwareホストクライアントでiSCSIストレージを設定

VMwareホストクライアントは高速です。純粋なHTML5クライアントとJavascriptなので、Webブラウザプラグインは必要ありません。 Adobe Flashも必要ありません。 また急速に進化しています。 VMwareは現在利用可能なホストクライアントとvSphere HTML5クライアントの両方で動作することが難しく、機能は限定されています。

目標は、vSphereインフラストラクチャ全体がAdobe Flashプラグインに依存しないようにすることです。Adobe Flashプラグインは遅く、セキュリティ上の脆弱性があります。vSphere HTML5クライアントの今後のリリースは、現在のFlashベースのvSphere ウェブクライアントのすべての機能と同等にすることです。

個々のホスト管理にとって、VMwareホストクライアントはESXiの希望です。 Windowsベースのクライアントは引き続き存在しますが、ESXiが新しくリリースされるたびにますます限定的になります。 VMwareは、vSphere 6.5でのアップデートに、C#クライアントのサポートを含んでいませんでした。

タグ:

Windows Server 2016におけるHyper-V 2016の5つの機能

Hyper-V 2016には数多くの新機能が搭載されているため、それらをすべて紹介するのは難しく、
時間が限られている場合、この5つの重要な機能を最初に見せてください。

仮想環境管理を容易にするための多数のHyper-V機能がありますが、機能が非常に多く、実際に使いこなすまでが困難で時間がかかります。 機能は、克服すべき課題と最終的に管理者の責任をどのように緩和するのかによって区別されます。 Hyper-Vの各バージョンには、新しく改良された機能が導入されています。

Hyper-V 2016の新機能および改良された機能を日常的に使用するため、最も重要な機能を特定するために数十程度の機能を検証し、その中でのトップ5をご紹介します。

Shielded VM

ハイプロファイルのセキュリティ侵害がますます一般的になってきているため、データを保護することが重要です。 Hyper-V 2016のShielded VM機能は、その負担を軽減します。そのため、このリストでは一番重要としました。

Shielded VM機能は、BitLockerを介して仮想ハードディスクを暗号化し、仮想トラステッドプラットフォームモジュールを使用して第2世代のVMを保護し、アテステーションプロセスを完了します。 セキュアブートとホストガーディアンサービスは、Hyper-V 2016のShielded VM機能でも役割を果たします。
セキュアブートは、ブート時にShielded VMへのアクセスを防ぎます。 ホストガーディアンサービスでは、シールドVMを指定されたホスト上でのみ実行できます。 これらの措置を講じることで、データを紛失や盗難から保護することができます。

Nested Virtualization

Hyper-V 2016のNested Virtualization機能により、管理者はVM内のホストを仮想化することができます。 現在、このHyper-V機能には、コンテナのサポートを含むいくつかのプロダクション用途があります。 コスト削減とコンテナの柔軟性とVMが提供するセキュリティを組み合わせることで、Nest Virtualizationは両方の分野のベストを表しています。

Nested Virtualizationにより、企業は開発/テスト環境とトレーニングのためにハードウェアにお金を節約できます。 このHyper-V 2016の機能は、プライベートクラウドでも機能します。Nested Virtualizationを使用したプライベートクラウドを作成すると、他の部門がVMを作成してリソース消費量を引き続き制御できます。

プロダクションチェックポイント

チェックポイントはHyper-Vの機能ではしばらく利用されていましたが、運用環境ではサポートされていませんでした。 今までは、本番環境のVMにチェックポイントを適用すると、その上に実行されているアプリケーションに損害を与えることがありました。

Hyper-V 2016には、Standard CheckpointまたはProduction Checkpointのいずれかを使用するオプションがあります。 覚えておくべき重要なことは、ゲストOSによってテクノロジが異なることです。 Windows OSを実行しているVMの場合、Production Checkpointはボリュームシャドウコピーサービスを使用してVMとそのアプリケーションを一貫性のある状態にします。そのため、アプリケーションに損害を与えることなくチェックポイントを作成できます。
Linuxを実行しているVMの場合、Production Checkpointはファイルシステムバッファをフラッシュして一貫したチェックポイントを作成します。

クラスタローリングアップグレード

クラスタローリングアップグレード機能により、管理者はダウンタイムなしに既存のWindows Server 2012 R2クラスタをWindows Server 2016クラスタにアップグレードできます。 この機能を使用する前は、管理者はクラスタをオフラインにして新しいOSをインストールし、アップグレードしたクラスタをオンラインに戻してすべてのワークロードを再起動する必要がありました。

クラスタローリングアップグレード機能を使用すると、アップグレード中にVMおよびスケールアウトファイルサーバーのワークロードを継続して実行し、それらのメンテナンスタスクの実行に伴うコストを削減できます。 クラスタがネイティブWindows Server 2016クラスタとして動作するかどうかをWindowsに指示するクラスタの機能レベルを上げない限り、必要に応じてクラスタを以前のOSバージョンに戻すこともできます。

ホストリソース保護

仮想環境でのリソース消費を管理することは難しいことです。 しかし、Hyper-V 2016のホストリソース保護機能は、いくつかの作業を処理します。

この機能により、VMが大量のリソースを消費することを防ぎ、隣接VMのパフォーマンスに対する悪影響を軽減します。 システムが異常に過剰な仮想CPUアクティビティを検出すると、ハイパーバイザはそのVMに割り当てるCPUリソースをより少なくします。 この機能はデフォルトでは無効になっています。 これを有効にするには、Set-VMProcessor PowerShellコマンドレットを使用します。 Hyper-V 2016でリソース消費を管理する方法は他にもありますが、ホストリソース保護機能は、無視されたVM設定や誤った設定ミスの心配を排除します。

タグ: ,

vSphereパフォーマンスを最大化させるための仮想化ハードウェア基準

仮想化には多くの課題があり、仮想ハードウェアを選択したときはいくつかの重要な基準を考える必要はあります。それらはホスト上に置く仮想マシン(VM)の数やLUN(logical unit number)があります。

もし、それらの数値を決めない時は、仮想インフラはパフォーマンスの低減に陥ります。ここではVMware vSphereインフラでのそれら数値について考えてみます。

・仮想化ハードウェア連係割合:

詳細な連係割合をえるたの2つの手法:

○スケール・アップ:この手法ではユーザは現状の物理サーバへリソースを追加するか、新規で、さらに強力なホスト(例:48コアと512GBメモリをサポートできる8ソケットサーバ)を追加する。

○スケールアウト:このアプローチは小さな、物理マシン(例:8コアと128GBメモリをサポートする2ソケット・サーバ)を追加する、それでいくつかのマシン間でリソース負荷を分散できます。

各手法の長所と短所:スケールアップではユーザがいくつかの物理サーバを購入しますが、サーバが故障している期間多くの数のVMがクラッシュするリスクは増加します。一方スケール・アウト時、ユーザは多くの物理サーバを購入・管理します。しかしスケール・アウト・アーキテクチャはさらに柔軟なクラスタ・デザインを提供し、このデザインでサーバ故障は少ないVMに影響します。

多くのユーザはスケール・アウトを選択し、大型と小型サーバ間のスイート・スポットは4-6コアでメモリが256BMでの2から4CPUソケットのサーバです。
中規模VMワークロードでは、2ソケット、ミッドレンジ・サーバは16対1の圧縮比で、4ソケット・サーバは32対1に届きます。これらの仮想化ハードウェア統計はワークロードの依存します。

・仮想CPUカウントの覚え
VM対ホスト比率は一般的なパフォーマンス測定です。VMが複数の仮想CPU(vCPU)を使用できることで、vCPU対物理CPU(pCPU)比率はさらに制度の高いハードウェア測定です。慎重な比率は通常4対1です。

例えば12CPUコアを持ったホストは48 vCPUのサポートが可能です。CPUワークロードが低い場合は、 8対1 vCPU対pCPU比率に届くことが可能で、重たいワークロードではたった2対1です。

VMにアサインされた多重vCPUs (or vSMP)はまたvCPU対pCPU比率に影響します。 VMware CPUスケジューラにとってはシングルの vCPU VM用にCPUタイムを割り振ることは簡単です。ホスト上のトータルなVM数は、もしvSMP VMがいくつかあれば増加します。(特に4以上のvCPUでは)

・大きな絵を描く
仮想化はリソース使用を合理化し、DRS(Distributed Resource Scheduler)やDPM(Distributed Power Management)のような高度な機能はホスト・リソースをバランス化し無駄なアクティビティを削減します。

VMwareのHA(High Availability)機能はフェイル・オーバしたVMからのリソース負荷を吸収するために他のホスト用に充分な予備容量を持つ必要があります。ユーザのワークロードといくつ同時ホスト障害から保護したいかで、ユーザはホストを70%の使用率で稼動することができます。

・LUNと共有ストレージ・パフォーマンス
共有ストレージ(またはLUN)で稼動するVMの数はまた重要な測定基準です。1つのLUNで多数のVMはメタデータ・ロッキング問題(SCSIリザベーション)を発生させます。

LUN上で常駐するVMの最適な数はいくつかの変数に依存しますが、次のアドバイスは基準値です。

○VM/LUNの平均数は14-16
○アプリケーション・サーバのような軽いI/Oワークロード用:100VM+/LUN
○アプリケーション・インテンシブなディスクI/O用:8-10 VM/LUN
○低から中程度のワークロード:20-22 VM/LUN

いくつかのケースではLUNのさらなるVMを配置できます。特に低I/O要求な仮想デスクトップ・インフラ・インプリメンテーション。

ユーザのストレージ・サブシステムはこの方程式では大きな役割を背負っています。RAIDグループでのディスク・スピンドルや大きなキャッシュがあれば、多くのVMを可能とします。

・100%仮想化を避ける
vSphereの成熟と改善により、どんなワークロードの仮想化が可能です。100%の仮想化データ・センターはもちろん達成可能ですが、それをすべきということにはなりません。

仮想環境は複雑で、その依存性と故障は大きな影響があります。ドメイン・ネーム・サーバ、ダイナミック・ホスト・コンフィグレーション・プロトコール、AD(アクティブ・ディレクトリ)は接続するデータ・センター・サーバとクライアントはクリティカルなサービスです。ストレージ・エリア・ネットワーク(SAN)や、ネットワーク・スイッチなどのメジャーなコンポーネントの損失はユーザの大部分の仮想環境の提供を不可能とします

物理サーバで稼動するクリティカルなサービスは依存度が低いです。それで、環境障害による影響は少ないです。物理サーバは事故後の回復が早いです。結果としてユーザ環境の90%から95%の仮想化は充分です。

勿論、仮想化は数値ですが、仮想ハードウェア目標に挑戦的にならないことです。データセンター・パフォーマンスとアップタイムは最も重要な数値です。パフォーマンスと利用度を犠牲にすることなく確実な仮想化ハードウェア数値を達成するには、ユーザはアーキテクチャとコンフィグレーションを決定する影響を理解することが必要です。

クラウド移行中の一般的なIPアドレス問題について

ローカルデータセンターからパブリッククラウドへの移行中、多くの組織はIPアドレスを取り巻く潜在的な問題を見落としています。
まず、クラウドプロバイダがアドレス割り当てをどのように管理しているかを理解する必要があります。

クラウドプロバイダとクラウドインスタンスのアクティビティは、通常、IPアドレスの範囲と可用性を制限するため、パブリッククラウドでワークロードが使用するアドレスは、通常、構内で使用するアドレスとは異なります。

たとえば、Webサーバなどの社内サービスをAmazon Web Servicesなどのパブリッククラウドに移行する場合、社内サービスのIPアドレスを移行およびパブリッククラウドに移行することが理想的です。このとき、インスタンスはそのアドレスを採用します。しかし、これは単に起こりません。その代わり、パブリッククラウドプロバイダは、ワークロードに適用されるサービスおよびインスタンスの仮想IPアドレスなど、内部および外部IPアドレスの限られたプールを所持しています。オンプレミスのIPアドレスがクラウドプロバイダに適切にルーティングされるように強制することはできません。

IPアドレスの問題に追加することは、プロバイダが通常動的にそれらを割り当てるという事実です。インスタンスが停止すると、ワークロードの再開時にクラウドのアドレスが変更される可能性があります。このすべては、他のワークロードが新しく移動されたワークロードにアクセスする必要がある場合、さらに面倒です。たとえば、新しく移動したワークロードが、他のワークロードに必要なデータベースまたは別のバックエンドシステムである場合、移動したサービスを新しいIPアドレスで見つけることができなくなるため、他のサービスは使用できなくなります。

しかし、この移行を容易にし、主要なIPアドレスの問題を回避するのに役立ついくつかの方法があります。

まずパブリッククラウドユーザーは、通常、インスタンスに割り当てられたIPアドレスに対して一定の制御権を持ちます。たとえば、Webサーバなどのカスタマーサービスでは静的IPアドレスが必要です。クラウドプロバイダは通常、静的IP割り当てを提供して、インスタンスの再起動時にアドレスが変更されないようにします。結果のアドレスは、元のオンプレミスのIPアドレスと一致する可能性はほとんどありませんが少なくともIPアドレスを選択して、インスタンスの存続期間を通じて変更されないことを確認できます。

次に、新しく移動したワークロードの新しいクラウドIPアドレスを選択した後、パブリックドメインネームシステム(DNS)を新しいアドレスに更新します。更新要求の有効期間が短く設定されているため、更新プログラムはインターネットを介して迅速に移行されます。パブリックDNSエントリを更新すると、そのサービスへの以降の参照はパブリッククラウドプロバイダを参照します。

 

 

【VMware】vSphereのセキュリティ設定について

VMware vSphereのセキュリティ設定方法を紹介します。

1)GUIでの設定方法

①vSphere Clientを起動して「構成」→「セキュリティプロファイル」をクリックします。

②画面左上の「プロパティ…」をクリックします。


③Portの設定が可能です。

2)コマンドでの操作方法

■コマンド例

service firewall start
ファイアウォールの起動


service firewall restart
ファイアウォールの再起動

esxcfg-firewallコマンドESXのセキュリティの確認、設定が可能です。

esxcfg-firewall -q 
ESXの設定の確認

esxcfg-firewall –openPort 【ポート番号】,tcp,in,apc
ポートの解放

タグ: ,

【VMware】スナップショット・ファイルのロケーション変更方法

デフォルトではスナップショットは各VMのホーム・ディレクトリに書き込まれています。ユーザはVM上でボリューム・スペースを取られないように、このロケーションを変更したいということがあるかも知れません。それはそれぞれ各VM上のスナップショット用の新たなワーキング・ディレクトリを指定することで可能です。この方法を選択したときにはスナップショットと.vswpファイルの両方がこのディレクトリに書き込まれます。

注)もしVMが共有ストレージにあり、ローカル・ストレージをロケーションとして指定した時は、vMotion、 High Availability、 Distributed Resource Schedulerなどホスト間でVMを移動させる機能は使用できません。

1. VMをパワーオフし、ESX サービス・コンソール または ESXi Tech Support Modeでログインします。

2. nano (ESXのみ) または vi (ESX/ESXi)エディタでVMのVMXファイルを編集

3. 次のシンタックスを使用して新たなラインを追加:
workingDir=”/vmfs/volumes/SnapVolume/Snapshots/”

4.もしVMディレクトリに.vsmpファイルを残したい時はVMXファイルに次のラインを追加します:
sched.swap.dir = “/vmfs/volumes/VM-Volume1/MyVM/”
これはオプションです。
さらにすでにある「sched.swap.derivedName」パラメータのアップデートを心配する必要はありません。それはVMがパワーオンした各時点でVMによって生成され、コンフィグレーション・ファイルに書き込まれます。

5. ユーザがVMと.vswpをパワーオンした時に、.vmsnとスナップショット(delta-vmdk)ファイルはこのディレクトリにロケートされます。

適切に削除されなかったスナップショットの取り扱い方法

ソース:SearchVMware.com

タグ:

VMwareメンテナンス・チェックリスト:毎日、毎週、毎月のタスク

あるベテランVMware管理者からの推奨:

毎日のVMwareメンテナンス・タスク:

●アラーム用のメールボックスの確認
一旦適切なアラームが構成されれば、その後は多くの努力を必要としません。

●サーバ・ルームへ足を運ぶ
アラームを設定していても、ホストのコンポーネント表示を実際に確認する方が正確に見分けることができます。

●vCenterに目を配る
完了していないタスクを確認したり、ESX(i)ホスト・パフォーマンスを確認したり、すべが順調かどうかを感じ取ります。

毎週のVMwareメンテナンス・タスク:

●vCenterデータベースのバックアップ
もし、仮想環境が頻繁に変更がある時は、さらに頻繁なバックアップが必要です。

毎月のVMwareメンテナンス・タスク:

●ストレージのクリーンナップ
不要なスナップショットがあれば、それらを削除する

●サポート契約の確認
もし切れてサポートが受けられないことにならないように。

●将来的な改善を計画する
どのように改善できるか? その方法を考える。

ソース:Mak King

VMware HAの検出方法とトラブル時のチェック項目

●高可用性

VMwareの高可用性を実現するには、VMwareHA(以下HA)とFTがあります。

HA・・・故障時のリカバリ方法は、仮想マシンをパワーオンからやり直すというものです。そのため、サービスが回復するまでには一定の時間を要します。
FT・・・仮想マシンの実行はそのまま継続されるため、メモリ上のデータも含めデータロスは発生しません。

FTの方が、より高可用性を実現できると言えますが、FTを実現するにはCPUの制限があったり、ライセンスがAdvanced以上である必要があるなど、条件がある程度必要です。一方のHAは、CPUの制限がなかったり、ライセンスがEssentials以外であれば何でもよいなど、比較的条件が軽めになっています。


※HAのイメージ

●HAの障害検出方法

HAは以下の方法でチェックされます。

・Faild host
15秒ごとにESXホストがハートビートをVMHAエージェントに投げ、受信ができない場合ホストがシャットダウンする

・Isolation response
12秒ごとにpingを実行し、できなかったらVMをシャットダウンする

●HAができないときのチェックポイント

まずは基本的なことではありますが、HAに必要な下記が欠けていないか確認します。

・vCenter Server
・2台以上のESXホストからなるvSphereクラスタ
・仮想マシンの格納領域として、クラス内のすべてのESXホストからアクセス可能な共有ストレージ(FC・iSCSI・NASなど)
・ハートビートをやり取りするためのネットワーク(サービスコンソールネットワークと共有可能)

上記すべて問題なければ、VMware公式にある「vSphere Availability Guide」の「VMware HA Checklist」(25ページ)をチェックしてみましょう。
http://www.vmware.com/pdf/vsphere4/r41/vsp_41_availability.pdf

シン・プロビジョニングの誤解 [VMware]

多くのユーザはディスクIOPS(input/output operations per second)の大容量を生成可能な 仮想マシン(VM)用シック仮想ディスクで困っています。(調査ではシックのパフォーマンスで利点は名ばかりであると指摘していますが。)しかしユーザはほとんどディスクIOPSを生成しないサーバ・ベースのVM上でシン仮想ディスクを使用しています。

確かにシンプロビジョニングはすばらしいディスク節約を提供します。

シン仮想ディスクの作成が簡単になる前は、シック仮想ディスクが非常に大きい場合はディスク・スペースを無駄にしていました。しかしシック・ディスクが小さ過ぎると、VM内でのフリー・スペースを使い果たすこともあります。

●克服しなければならないシン・プロビジョニングの問題:

シン・プロビジョニングが問題を抱えているわけではありません。落とし穴に気がついていなければ、シン・ディスクは大きな問題を引き起こします。

例えばロジカル・ユニット・ナンバー(LUN)/ボリューム全体を消費する仮想ディスクを作成する可能性があります。もし10VMを作成して。それぞれ40GBのシン仮想ディスクを持っていたとします。最初はシン・ディスクは2MBを消費するのみですが、容量がいっぱいになると、ディスクは合計で400GBを消費します。結果としてロジカル・ユニット・ナンバー/ボリュームが350GBになるようなことが起こってしまいます。

このシナリオは極端な例ではありません。急速にシン・ディスクを膨張させる一見無害なVMがいくつかあります。最初にWindows内で仮想ディスクをどのようにフォーマットするか気をつけましょう。WindowsではQuick Formatオプションを決して使わないように教えられました。すなわちQuick Formatは多くの環境で実際にディスク・アクセスをスロー・ダウンさせます。

しかし、シン・プロビジョニング・ディスクでフル・フォーマット・オプションを使用した場合、仮想ディスクのすべてのブロックにライトして。シン仮想ディスクを最大サイズまで膨張させます。同じボリュームにフル・フォーマットしたいくつかのVMが存在していることを想像してください。

推奨:シン仮想ディスクでは、WindowsではQuick Formatオプションを使用する。

図1:

●シン・ディスクが縮小しない

VMware Toolsの圧縮機能が関連する偶然的なシン・ディスクの膨張は削除したファイルで消費されたディスク・スペースの取り戻しです。テンプレートへVMを作成する前にユーザがディスクのディフラグとディスクを最適化する圧縮機能を使用することを推奨します

Windowsのファイルを削除した時は、ディスクから実際に削除したことにはなりません。それは単にファイル・システム内で上書きとして記されただけです。それ故、削除ファイルはディスク・スペースを消費します。

図 2:

圧縮機能はすべての仮想ディスク/テープやOSには利用できません。VMware Toolsのバージョンによっては利用不可能です。

このプロセスによってデフラグメンテーションと圧縮機能はシン仮想ディスクでは稼動できません。両プロセスはファイルを移動させたり、ディスクにライトするため、シン仮想ディスクのサイズの増加の原因となります。

もしレギュラー的に大きなファイルを作成したり削除したりするタスクがある時は、直ぐにシン仮想ディスクが増加し。フリー・スペースはストレージ・アレーには戻りません。では、どのようにこの迷子的なディスク・スペースを改善できるのか? ユーザは仮想ディスク内での削除したファイルを安全に移動できるCオプションでSDeleteを使用できます。

これにより仮想ディスクは短期間では大きくなります。しかしVMwareの Storage vMotionと仮想ディスクを実サイズへ圧縮するシン・ディスク・オプションを使用できます。

ソース:SearchVMware.com

タグ: ,

Veeam Continuous Data Protectionでも使用されるVMware VAIO(vSphere APIs for I/O)フィルタリングとは

Veeam Availability Suit v10の一部であるVeeam Continuous Data Protectionは、VAIO (vSphere APIs for I/O)フィルタリングを使用してスナップショットに関連する問題を回避し、RPOとRTOを削減します。

Veeam Availability Suit V10にはVeeam Continuous Data Protectionが含まれています。
Veeam Continuous Data Protectionは、リカバリポイントを短縮することが目的のスナップショットレスレプリケーションメカニズムです。

従来、VeeamはVMwareのスナップショット技術を利用して、VMディスクを解放してレプリケーションとバックアップのためにVMの変更されたブロックを処理しましたが、Veeam CDPはI/O(VAIO)フィルタリング用のvSphere APIを活用して、スナップショットの欠点を回避し、同じ結果を達成します。2017年5月のVeeamONの公式発表によれば、VeeamONのCDPは、リカバリポイントの目標をわずか5秒で達成でき、リカバリ時間の目標をさらに短縮することができます。

VMware VAIOとは?

VMware VAIOは、サードパーティのベンダーが独自の機能や製品を設計して実装できるフレームワークです。VMwareのストレージフレームワークであるVirtual Volumesと同様に、VAIOはエコシステムが使用できる一連のAPIです。基本的には、VAIOを使用すると、組織はゲストOSと仮想ディスクの間にI/Oフィルタを作成できます。組織では、このカスタムフィルタをいくつかの異なるフィルタクラス、つまりレプリケーションフィルタ、暗号フィルタ、キャッシングフィルタを使用して開発できます。VMから出力されるすべての単一のI/Oは、ディスクにコミットされる前に一度に1つずつフィルタを通過する必要があります。

これらのすべての追加ステップでは、VMware VAIOがパフォーマンスに悪影響を及ぼすか、またはI/Oが処理されるときにインフラストラクチャに遅延が発生すると考えられます。幸い、VAIOフィルタリングに関連するオーバーヘッドはほとんどありません。従来のI/Oパスでは、ゲストOSはVM内の仮想SCSI(vSCSI)デバイスドライバ経由で書き込みを送信します。vSCSIドライバは、VMkernelのvSCSIバックエンドへのチャネルを開きます。VMkernelは、ファイルシステム内の場所を開いて書き込みを処理し、次にI/Oをファイルデバイスレイヤ(FDL)に渡します。FDLは物理デバイスにアクセスし、書き込みをディスクにコミットします。

VMware VAIOは、単純にパスに1つのステップを追加します。VMkernelがI/OをFDLに渡した後、VAIOはステップインします。VMにフィルタポリシーが設定されている場合、I/Oはユーザ領域に返され、データが物理デバイスに送信される前にカスタマーI/Oフィルタを通過します。VMにフィルタポリシーが設定されていない場合、I/Oは正常に処理され、物理デバイスに直接送信され、物理デバイスはディスクへの書き込みをマップしてコミットします。

VMware VAIOは新しい技術であり、2015年9月以降に一般的にしか利用できないため、多数のVAIO認定製品を見ることはほとんどありません。また、サードパーティベンダーがこの機能を利用して実際に製品を開発するまでには時間がかかりますが、主にキャッシュ領域にあるベンダーがすでに取り組み始めています。VAIOが最初に暗号化フィルタを提供しておらず、VAIO暗号化フィルタがESXi 6.5で利用できるようになったため、暗号化スペース内のベンダーは調整に時間がかかる可能性が高くなります。

VAIO認定製品の採用は、今後大幅に増加します。なぜなら、重要なエンタープライズストレージのパフォーマンスとデータ保護を提供する可能性があるからです。 VMware VAIOは、レプリケーション、キャッシング、暗号化、ウイルス対策、セキュリティなどの標準となりそうです。 うまくいけば、VMworld 2017で、VAIOとそのサポートされているエコシステムについてのより多くのニュースが聞けるかもしれません。

タグ: , ,

vSphere Web Clientを使用したESXiの時刻同期の設定方法について

インストールが完了すると、管理者はESXiの時刻同期を最優先に設定する必要があります。
設定しない場合、アプリケーションの障害、VMの問題などが発生する可能性があります。

ESXiの時刻同期設定がオフの場合、VM、アプリケーション、およびファイルサーバに問題が発生する可能性があります。ESXi 6.5のインストール後、管理者にとって最も重要なことの1つは、時間同期を設定することです。

ホストが同期していない場合、VMの同期がとれていない可能性があります。VMが同期していない場合、一部のアプリケーションの動作が停止することがあります。たとえば、Kerberosチケットが期限切れになったり、ドメインコントローラがサイト間で同期しないため、フィルサーバのリソースへのアクセスの提供が停止される可能性があります。

5分以上同期していないコンピューターとサーバーは認証されません。
フォレストルートドメインのプライマリドメインコントローラエミュレータの手動時間ソースを構成することは非常に重要です。

ESXiの時刻同期とNTP設定を構成する

ESXiの時刻同期を設定するには、vSphere Web Clientを開き、適切なESXiホストを選択し、[設定]>[時間設定]>[編集]をクリックし、[ネットワークタイムプロトコル(NTPクライアントを有効にする)]を選択します。

次に、[NTPサービススタートアップポリシー]ドロップダウンメニューを開き、[ホストで開始して停止する]を選択します。すべてのNTPサーバーを[NTPサーバ]テキストボックスに追加します(図A)。

この例では、VMwareでホストされているNTPサーバのプールである[vmware.pool.ntp.org]を使用しました。

 

図A.ESXiの時刻同期を設定する

NTPサーバの追加が完了したら、NTPサービスの設定を更新するために必ず再起動してください。再起動しないと、サービスは停止状態になり、すぐに設定が適用されません。

これらの手順を実行して再起動すると、外部ソースから時刻を取得するようESXiホストを正常に設定しました。これは、ほとんどの環境で最適な設定です。

代替案

稀に使用している環境によっては、上記の構成が失敗します。ホストがインターネットにアクセスできず、NTPサーバを使用するアクセス権がない場合があります。または、インターネットを使用するオプションではない、隔離された非常に安全な環境である可能性があります。これらにシナリオには、代替案を必要としています。

通常、最善の方法は、ドメインコントローラと同期することです。ドメインコントローラのNTP設定は、組織内のすべてのデスクトップおよびサーバシステムに時間サービスを提供するため、最新の状態にする必要があります。

したがって、[vmware.pool.ntp.org]を[NTPサーバ]テキストボックスに入れるのではなく、組織のWindowsドメインコントローラサーバの完全修飾ドメイン名またはIPアドレスを入力します。

VMware vSphere 6.5のStorage I/O Controlとは

VMware Storage I/O controlは、vSphere のストレージ品質を向上させるのに役立ちます。
vSphere 6.5はStorage  I/O control機能をVMストレージポリシーに統合します。

仮想化は企業に多大な利益をもたらしますが、仮想マシンのI/O要求は問題になる可能性があります。すべてのVMはあるレベルのストレージトラフィックを発生させ、その結果生じる1秒当たりのI/O 操作は競合を招き、重要なワークロードのパフォーマンスを低下させる可能性があります。

Storage IOPSを制御することで、管理者は、他の重要なI/OニーズのVMを枯渇させることなく、すべてのVMワークロードが適切なI/O にアクセスできるようになります。しかし、すべてのシナリオでStorage I/O controlが完璧でないため、管理者は最良の結果を得るために技術を慎重に適用する必要があります。VMware vSphere 6.5のStorage I/O controlの概念をピックアップし、管理者が直面する潜在的な問題のいくつかを解決してみませんか?

Storage I/O controlは、環境内のVM間のストレージI/O 競合を回避または緩和することにより、サービスのストレージ品質を向上させるvSphere機能です。

仮想化エンジニアは、I/Oスロットリングの必要性がある程度発生することを長い間理解していました。Storage I/O  controlがなければ、各VMは独立してストレージリソースにアクセスする必要があります。限られたI/O帯域幅やビジー状態のVMが不必要に大量のストレージI/O帯域幅(「騒々しい隣人」と呼ばれる)を必要とします。
したがって、いくつかのStorage I/O control方式は、長いvSphereのアーキテクチャの一部となっています。

通常、Storage I/O controlはデフォルトで無効になっており、VMware vCenterを介してストアごとに意図的に有効にする必要があります。有効にすると、Storage I/O controlはデフォルトで30ミリ秒となります。
管理者は組織のパフォーマンスニーズに合わせて変更・構成することができます。

vSphereはI/Oキューを使用して有限数の「I/Oスロット」を分割し、ストレージアクセスが必要なVM間で共有します。VMはI/Oキューへの要求を行い、より多くのVMが「I/Oスロット」を利用可能とする要求がある場合に競合が発生します。競合と過度の待ち時間が発生し、VMがストレージのアクセスに時間がかかりすぎて、適切なワークロードのパフォーマンスが損なわれます。

過度の遅延が発生すると、Storage I/O controlによって、各VMキューに送信できる要求の数が制限されることにより、VMが作成できるストージ要求の数が事実上制限されます。
理想的には、これはI/O競合を緩和するはずです。Storage I/O controlメカニズムは、Storage I/Oレイテンシを検出し、必要に応じてI/Oキューを抑制するために必要な計算をすべて行い、トラフィックの要求が緩和されたときに後退します。

古いバージョンのvSphereでは、vSphere環境内の他のポリシー駆動型操作の外に存在していた時間がかかり、エラーが発生する可能性がある手動プロセスであるため、管理者はディスクとVMのStorage I/O controlを個別に有効化および設定する必要がありました。

VMwareのvSphere 6.5リリースにより、Storage I/O control構成の設計がVM Storage Policy に変更されました。

管理者がデータストアのStorage I/O control を有効にし、適切なストレージレイテンシのしきい値を選択すると、VMまたはディスクファイル(.vmdkファイルなど)にポリシーを適用できます。

 

タグ:

vSphereのStorage I/O Control にはどのような問題が存在するのか

Storage I/O Controlは共有ストレージの問題を処理する有効な方法ですが、全ての仮想マシンに必ずしも適しているわけではありません。

Storage I/O Controlは、ストレージレイテンシを使用して、データセンター内の仮想マシンに提供されるI/Oキュー共有を管理します。Storage latencyが増加(悪化)し、定義したしきい値を超えると、I/Oシェアが減少し、VMのストレージ使用量が減少します。これにより、負荷の低い他VMのStorage I/O Control 帯域幅がさらに広がり、データセンターに問題が発生します。

Storage I/O controlは、偶発的に発生する共有ストレージの問題を処理するのに効果な方法ですが、必ずしもすべてのVMに適しているわけではありません。一部のVMワークロードでは設計上、ストレージI/Oが大量に必要で、Storage I/O controlを呼び出すと、ワークロードのパフォーマンスに望ましくない影響を及ぼす可能性があります。

管理者は、各VMの基本的な要件を理解し、Storage I/O controlを適用することが利益よりも害を及ぼすかどうかを判断することが重要です。Storage I/O controlは、オールオアナッシングなものではないことに注意してください。管理者はストレージの圧迫を緩和し、VMへのパフォーマンスへの影響を最小限に抑えるために、IOPSの最小値、最大値、および共有値を含め、動的に構成可能であるため、管理者は即座にルール設定を調整できます。

場合によっては、ストレージを大量に消費するVMを別のホストに再配置し、ストレージを集中的に使用するVMをパフォーマンスの良いストレージリソースに接続するか、そのホスト上のワークロードを再調整して、Storage I/O Controlの使用を行います。

管理者がStorage I/O controlの問題を回避する方法

管理者は、パフォーマンスの監視とレポートを使用して、Storage I/O controlがワークロードに及ぼす影響、または最終的にはビジネスに対するVMのパフォーマンスを監視する必要があります。

Storage I/O controlが適切に実装され、vSphereホスト用に適切に構成されているかどうかの問題以外にも、Storage I/O controlの実装では、いくつかの共通の技術的問題が派生する可能性があります。たとえば管理者は、Storage I/O controlが期待どおりに動作していないこと、VMが適切に優先順位付けされていないこと、または規則が間欠的にしか適用されないことを発見する可能性があります。

共通ルート問題は、複数のvCenter Serverインスタンスがデータストアを管理する場合に発生します。これにより、各vCenter Serverインスタンスが異なる構成を採用している場合、コンフリクトやStorage I/O controlの動作が不安定になる可能性があります。たとえば、1つのvCenterがStorage I/O controlを一方向に構成し、別のvCenterが別の構成で構成します。ストレージI/O制御は時々正しく動作するかもしれませんが、すべてではありません。各データを管理するvCenter Serverインスタンスが1つのみであることを確認し、vCenter Serverインスタンスが必要な構成を使用していることを確認します。

管理者は通常、問題のあるデータのStorage I/O controlをチェックして切り替えることによって、これらのタイプの問題に対処できます。たとえば、データストアのプロパティをチェックし、Storage I/O controlを有効にします。

すでに有効になっている場合は、Storage I/O controlをオフに切り替えて、変更を保存します。その後、再度有効にして変更を保存します。これは、最初に有効にした後にデータストアを使用するホストの数が変更された場合に役立ちます。

次に、データストアプロパティのIOPSしきい値(ストレージI/O制御の詳細設定)を確認します。レイテンシのしきい値が適切なレベルに認定されていることを確認してください。デフォルト設定は30ミリ秒です。レイテンシが変更された場合は、インフラストラクチャに適した設定になっていることを確認します。

VMwareはStorage I/O controlを設計してVMの優先順位付けを行いましたが、すべてのVMは同じ数のI/O共有とIOPS制限を持っています。Storage I/O controlが開始された時に、特定のVMが優先順位を示していない場合、管理者はI/O共有とIOPS制限がクラスタ内の各VMに対して設定されていることを確認する必要があります。クラスタのリソース割り当てダイアログのストレージセクションはこれを保持しません。管理者は、vSphere Clientインベントリ内の個々の仮想ディスクのI/O共有とIOPS制限を変更することができます。

また管理者は、ホストシステムにログオンすることで、Storage I/O control の動作やエラーについての詳細な情報を収集することもできます。
ログスペースを節約し、ログアクティビティの不必要なパフォーマンスへの影響をを防止するために、再度ログを使用不可にすることができます。

最後に、実際の物理ストレージプラットフォームとそのプール/階層化機能について検討します。
たとえば、互換性のない自動階層機能を備えたストレージアレイ上のデータストアへStorage I/O controlを適用すると問題が発生することがあります。
VMwareのStorage I/O controlとの互換性を有効にするために、ストレージアレイのソフトウェアを更新するか、またはデータストアを別のストレージリソースに再配置する必要があります。

タグ:

回避すべき5つのVMwareセキュリティ欠陥【仮想化プラットホーム VMware vSphere】

VMwareセキュリティ違反は軽く取り扱われるべきではありません。特に法令順守が注目されて、さらにクラウド・コンピューティングに向かっている現状では。

仮想ホストは多くのワークロードを背負い、悪質な人間がホストに対して許可のないアクセスを行ったなら、その人間はすべての仮想マシン(VM)を危険にさらす可能性があります。そこで仮想管理者はVMwareセキュリティ違反を防ぐために特別な注意が必要になります。VMwareセキュリティ違反が起きる可能性のあるいくつかの弱点があります。

●VMwareをセキュリティ・レスに構築する
VMware vSphereはかなり安全ですが、コンフィグレーションやリモート・アクセス設定に配慮を怠るとセキュリティ欠陥に影響を受けやすくなります。

デフォルトで管理者が楽になるようにVMwareは多くの機能を停止させることができますが、それらの機能はセキュリティを弱くさせます。例えばESXでは管理者は通常Webユーザ・インターフェイスを利用します。そしてESXiではITプロはSSH接続経由でリモート・コンソールへのアクセスが可能です。これらはユーザの仕事をやり易くしますが、認証されていない人間への攻撃ベクトルを開くことになります。

さらに大きな脆弱性は、ホストの管理コンソールです。それは仮想インフラ全体へのドアで、多く鍵を渡すべきではありません。しっかり管理コンソールをロックし、本当に必要な時だけに使用します。考えられる他の分野ではVMデータストア、管理とストレージ・ネットワーク・トラフィック、仮想ネットワーク、アプリケーション。プログラミング・インターフェイス、VMホスト相互接続、vCenterサーバ役割と許可、サードパーティ・アドオンです。

結論:弱点を理解し、それを堅固なものとする。

●VMの移植性は、VMwareのセキュリティ侵害につながる
VMの移植性は盗みのチャンスを増加させますが、それらのセキュリティ侵害は強力なバックアップ・ストラテジーがあれば、簡単に回避できます。

仮想化はサーバ全体(OS、アプリケーション、設定)を1つの仮想化ディスク・ファイルへカプセル化します。カプセル化は仮想化の長所ですが、簡単に弱点にもなりえます。

物理サーバを盗むためにアタッカーは物理的にデータセンターに侵入し、マシンを運びだす必要があります。しかしVM全体はネットワーク経由でデータセンターの外にコピーされ、ポータブル・ストレージ装置に運びだされます。一旦誰かが仮想ディスク・ファイルを持ち出せば、彼はファイル・システムにアクセスするためにそれを簡単にマウントでき、VMware Playerなどのツールを使用して、どのワークステーション上でも使用ができます。

これらのVMwareセキュリティ侵害を防ぐために、物理ストレージとホストの両レベルでVMが常駐するデータストアを保護しなければなりません。ストレージ・ネットワークが適切に保全されていることと、vSphereホストのみがVMデータストアLUN(logical unit numbers)にアクセスしていることを確実にしてください。

管理コンソールやvSphereクライアントのような一般的なツールはホストからVMをコピーすることができます。vSphereクライアント内のDatastore Browserを使用してファイルをリードするパーミッションを削除し、管理コンソールにアクセスできる人間を制限します。またディスク・ツー・ディスクのVMバックアップアプリケーションを使用しているなら、適切にバックアップ・リポジトリを保護します。それはVMイメージ全体がそこに保持されているからです。

●VLAN経由でのVMwareセキュリティ侵害を防ぐ
VMネットワーク・コンフィグレーションは簡単に変更できます。それ故に適正な予防措置が取られていなければセキュリティ侵害を招くことになります。

もし物理サーバをVLAN(virtual local area networks)間で移動させる場合、通常はスイッチ・ポート・コンフィグレーションのVLANを変更してネットワーク・グループを使用します。仮想ホストは通常VLANタギングを使用し、それは1つの物理スイッチ・ポートは複数のVLANをサポートすることを意味します。VMのvNIC(virtual network interface card)はそれでホスト上でマルチ・ポート・グループを使用するようにコンフィグレーションされます。ホストの仮想ネットワークはVM設定のエディットとvNIC用の新たなVLANを選択することでVLAN間でのVMの移動を簡単にすることができます。

このデザインは誰でも簡単に1ネットワークから他へVMを簡単に移動でき、複数のvNICを追加することで複数のネットワークに参加できるということを意味します。同様にVMを安全なネットワークから少し安全度が低いネットワークへ移動できます。

またVMが2つの仮想ネットワークをブリッジすることも可能で、侵入者が外部ネットワークからユーザの内部ネットワークへのパスを作ることになります。これらのセキュリティ侵入を防ぐにはVMの仮想ネットワーク設定変更に要求される許可を固定させることです。望ましいのはネットワーク管理者のみがこれらのアクセス権を持ち、VMを管理するサーバやアプリケーション管理者に持たさないことです。

●隔離(アイソレーション)でVMwareセキュリティ侵害を回避する
仮想インフラ・トラフィックがストレージと管理データとして同じ物理ネットワーク上で移動した場合、ユーザのVMはセキュリティ侵害に会う可能性があります。これらのエンドポイント間でのすべてのトラフィックは暗号化されていないため、ワイアー上で誰でもデータを盗む可能性があり、それらはストレージ装置に転送された機密情報だったり、vMotion中のホスト・メモリ内のデータが含まれます。

トラフィック分離無しでは:ホスト、ストレージ装置、vCenterサーバ、管理者間での核のトラフィック用の保護レイアーの追加。プライベート・データが空中で盗まれるリスク。物理ネットワークを移動する仮想インフラ・ネットワークをできるだけ分離すべきです。例えば通常のVMネットワーク・トラフィックから離れた物理的に隔離されたネットワーク上の管理とストレージ・トラフィックを管理することです。

この実践にはESXサービス・コンソール、ESXi管理コンソール、VMKernel、vCenterサーバ用のネットワークが含まれます。これらのコンポーネントのコミュニケーションはお互いに頻繁で、外部ネットワーク接続の必要性を制限します。

ファイアウオールの使用はプライベート・ネットワークを保護してくれ、管理、ドメイン・ネーム・サービス、アップデートなどに許可されたトラフィックのみを許します。大体のトラフィックは暗号化されていますが、アイソレーション(分離)はセキュリティ侵害に対して防御の特別なレイアーを追加します。例えば、vMotionトラフィックが暗号化されていなければホストのメモリー内容はVMがあるホストから他へ移動するたびにプレイン・テキストで送られます。

またホストからストレージ装置へのネットワーク・ベースのストレージ・トラフィック(例:iSCSIと NFS)の物理的分離。iSCSIでは許可されていない接続と防ぐために双方向のチャレンジ-ハンドシェイク認証プロトコールで安全を図ります。アイソレーションはストレージ・トラフィックを保護するだけでなく、ネットワーク上のパフォーマンス向上と他のデバイスとのコンテンションを削減できます。

●ユーザ・アカウントでVMwareセキュリティを改善
ESXサービス・コンソールとESXi管理者コンソールのルート・アカウントを保護する。それが障害を受けたとき、可能マシンを含むホスト上のすべてが障害を受けます。

ESXサービス・コンソールとESXi管理者コンソールはLinux OSの改良版として稼動します。それらはルート・アカウントを持ち、フルのパーミッションを持つスーパー・ユーザ・アカウントです。ルート・アカウントの使用をできるだけ控え、各ユーザにプレビレッジの低いアカウントを作成します。それにより各ユーザの使用度が分かる監査データを提供することができます。

ESXではフル・アクセスを与えることなく、ユーザ・アカウントに特定のプリビレッジを与える「sudo」を設定することができます。ESXとESXiの両方で、su コマンドを使用してアカウントにスーパーユーザ・プリビレッジをテンポラリーに与えることができます。

デフォルトではルート・アカウントはSSH接続からコンソールへはリモートでログインできません。SSH経由で簡単にルート・アクセスできても、VMwareはそれを許していません。また各ホストでそれぞれのローカル・ユーザ・アカウントを管理するよりも、コンソール・アクセスでActive Directory認証を設定することができます。

最後にルート・アカウントを保護するためにはパスワードを定期的に変更し、利用をできるだけ控えることです。

●オンプレ環境とクラウド間のセキュリティ
今後のオンプレの仮想環境とクラウド間でのセキュリティ対策が重要視されています。 HyTrust (ハイトラスト)は 仮想環境からクラウドへのアクセス制御(CloudControl)とVM、インスタンスの暗号化でプライベート/パブリッククラウドのワークロードを確実に保護(DataControl)できる・セキュリティ・ソリューションです。

タグ: ,

Windows Server 2016でのReFSファイル・システムの優位性

ReFS (Resilient File System)はWindows Server 2012で紹介されたストレージ技術で、それ以降に新機能や改善が追加されています。Hyper-V  VMホスト用としてNTFSからReFSに移行するには納得する理由が必要とするでしょう。

Hyper-VでReFSを使用することで即にスピードと効率化の2つを得ることができます。最初の方はVMチェック・ポイントはメタデータ・アップデートで行われ、Hyper-V 2016内のディスクでは非常に高速で、これは「Production Checkpoint」と呼ばれます。2番目は固定サイズのVHDやVHDXファイルをプロビジョンしたときに即に有益で、ReFSはユーザに利益をもたらします。あるMicrosoft MVPのテストではNTFSでの500 GB VHDXファイルのプロビジョニングで2441秒(約40分)係ったものが同じサイズでReFSでは13秒というレポートもあります。Hyper-V 2016でこの機能はInstant Fixed Disk Creationとして知られています。このWindows Server 2016での2つのブランドはユーザに大きな利益をもたらします。

この2つの機能はユーザのHyper-Vとクラスタ・デザインをどのように設計するか、ユーザがどのようにVM(仮想マシン)を使用し、管理し、ディプロイするかを変革します。

クラスタの設計

ストレージ・プロビジョン・プロセスの一部はReFSで実フォーマットしたボリュームです。これは非常に簡単です。ReFSはまだデフォルト・オプションではなく、フォーマット時のボリュームはNTFSです。ReFSボリュームは他のボリュームと並んでおり、そのプロパティを選択するまでは識別されません。もう一つの良いアイデアは、ボリュームを自己の文書化でネームすることです。以下の図では「REFS」は「NTFS」ボリュームと並んでいます。他の例として、例えば「REFS VM Storage」のような名前をつけることができます。 ここではReFSボリュームです。

VM(仮想マシン)の起動と管理

ReFSからのHyper-V利点として「Production Checkpoint」として知られているメタデータを更新することでディスク上のストレージ・オペレーションの実行がチェックポイントで可能となります。実行中のVM上のチェックポイントからブロックを移動すると、激しいI / Oが作成されます。ReFSが提供するメタデータ・アップデートはそれらを効率的にします。例えばマイクロソフトは稼働するVM上でチェックポイントを使用することを推奨していません。しかしWindows Server 2016では話は別になります。ユーザはいつでも「Production Checkpoint」を活用することができます。もしユーザがもっとそれを使用する必要や、共通タスクとして自動化したいならPowerShellからHyper-Vチェックポイントをコールすることもできます。

VMのディプロイ

固定サイズのVHDXドライブをほぼ即に実行できるようになりました。状況は、VMの導入だけでなく、VMの管理に関連するストレージに戻ってきました。ダイナミック・サイズが使用された時にオーバー・スブスクリプション(過剰予約)に関する2つのタイプの心配があります。物理ストレージボリューム全体とゲストVM内です。オーバーサブスクリプションを監視することは一つですが、いっぱいになると別のものになります。

次のように適切に設定されていなければ問題がおこることが想定されます。

  • 稼働するHyper-V内でのストレージ・ボリューム
  • ゲストVHDXドライバが動的に拡張するように設定されている
  • CSV / SMB3ストレージボリュームは、オーバーサブスクライブされているためにいっぱいになる

ダイナミック・ドライブ最終的にがいっぱいになる可能性があり、このボリュームに多数のVMがある場合は、その影響が大きくなる可能性があります。ゲスト・ドライバ内でストレージをフル・アロケートするためにReFS機能を活用することはこの潜在的な問題を回避することができます。ゲストオペレーティングシステムについて色々心配があります。固定サイズで、フルにHyper-VのVMを使用してホストを健全な状態で保持しましょう。

Veeam Backup & Replication Ver9.5ではこのReFS機能をフルに活用することができます。

実行結果: ReFSを使用してVeeam Bacup & Replicationで1カ月間毎日Synthetic(合成)バックアップを実行。676GBのバックアップで106GBを消費。

タグ: , , ,