vSAN Cormac Blog ~ vSAN 6.2 キャパシティ ビュー ~ 

vSAN 6.2 の新機能の中でも、特に重複排除や圧縮のような容量効率化の機能に注目している方も多いかと思います。
この機能の他にも、新しく バージョン3になった オン ディスクフォーマット と新しいソフトウェアチェックサム機能があります。
これらの機能はキャパシティのオーバーヘッドをもたらしますが、vSAN 6.2 で導入された新しいストレージビューにより、管理者によるストレージ消費の追跡を容易にしています。

まず最初にキャパシティ オーバービューに焦点をあてた場合、vSAN データストアの全体サイズを見ることができます。 (上記の画面では 59.43 TB あります。)

併せて、重複排除と圧縮のオーバーヘッドも確認することができますが、更にファイルシステムのオーバーヘッドやチェックサムのオーバーヘッドを確認したい場合は、画面下部の使用量の内訳で詳細を表示することができます。

使用済み合計 – vSAN データストア上で、物理的にどれくらいのデータが書き込まれているのか (論理サイズとは対照的)を表しています。

これは、データストア上に存在することができる仮想ディスク、 仮想マシンのホームオブジェクト、スワップオブジェクト、パフォーマンス管理オブジェクトおよびその他の項目の組み合わせです。

その他の項目とは、例えば ISOイメージ、未登録の仮想マシン、またはテンプレートなどがあります。 画面下部の使用容量内訳の仮想マシンオブジェクトに表示されている値は、オブジェクトの種類ごとにグループ化されたときに、関連する使用量、重複排除と圧縮前の値かが計算されています。

重複排除と圧縮を行った後に、オブジェクトがどのくらいのスペースを消費しているかを確認するための情報は、この時点ではありません。

しかし、これらのスペース効率の機能によって保存されている領域の量が確認できないということではありません。

画面右上のデデュープと圧縮の概要は、スペースの節約とデデュープ (重複排除) 率がどれくらい達成しているのかを確認できるのと同様に、管理者が vSAN 上のスペース効率化の機能を無効にして重複排除と圧縮されたオブジェクトを再膨張させたい場合に有効な情報となる場合があります。

展開されている仮想マシンがより類似のものであれば、容量の節約率は高くなります。ここでは、数百の仮想マシンを展開している例です。いかがでしょうか?

これは、重複排除と圧縮を使用しないで現在のワークロードを展開した場合、11TBほどが必要になることを意味しています。 重複排除と圧縮機能を使用することで、400GB程度まで削減されました。

留意点は、「使用前 (Used Before)」の値は、レプリカ(RAID-1)とパリティ(RAID-5/6)の値も含まれることです。これは、データタイプのグループを反転させることで、すぐに確認することができます。

これで、重複排除と圧縮を無効にして、仮想マシンをもとのサイズに再膨張させた場合に必要とされる容量を確認することができます。

上記のような操作を計画している場合、この画面を参照し、利用可能な十分な容量があることを確認してください。

続いて、キャパシティビューの中で表示されているオブジェクトの説明です。

・オブジェクトタイプのグループ

パフォーマンス管理オブジェクト

パフォーマンスサービスが有効になっている場合、パフォーマンス・メトリックを格納するために作られたオブジェクトによって消費される容量

ファイルシステムのオーバーヘッド

重複排除、圧縮やチェックサムのオーバーヘッドに起因しない、容量のドライブ上のファイルシステム(VirstoFS)に取り込まれた任意のオーバーヘッド 。

重複排除と圧縮が有効になっている場合、ファイルシステムのオーバーヘッドは、 vSANデータストアの論理サイズの増加を反映して10倍に増加されます。

デデュープおよび圧縮のオーバーヘッド

重複排除と圧縮の効果を得るため、オーバーヘッドが発生します。これは、重複排除や圧縮のために必要なマッピングテーブル、ハッシュテーブル、そして他のメカニズムに関連付けられたものが含まれます。

チェックサムのオーバーヘッド

すべてのチェックサムを格納するオーバーヘッドです。重複排除と圧縮が有効になっている場合、チェックサムのオーバーヘッドは、 vSANデータストアの論理サイズの増加を反映して10倍に増加されます。

vSANデータストア上に仮想マシンやテンプレートを展開している場合は、より多くのオブジェクトが表示されます。

仮想ディスク

vSAN上に存在する仮想マシンディスク (VMDK)のオブジェクトによって消費される容量

仮想マシン ホーム オブジェクト

vSANデータストア上に存在する、VMホームの名前空間オブジェクト(仮想マシンファイルを含む)によって消費される容量

スワップ オブジェクト

vSANデータストア上に存在する仮想マシンのスワップ領域によって消費される容量。

Vmem オブジェクト

仮想マシンのスナップショット取得時に作成されるメモリオブジェクトによって消費される容量。これは仮想マシンバ ージョン10以上をつかっているときのみ表示されます。

その他

仮想マシンテンプレート、登録されていない仮想マシン、仮想マシンに関連付けられていないスタンドアローンのVMDK、手動で作成 されたvSANオブジェクト、手動で作成されたISOを保存しているディレクトリによって消費される容量。

次は、別のビューであるデータタイプを掘り下げてみてみましょう。

データタイプのグループ

プライマリ 仮想マシン データ

VMホームの名前空間、VMスワップとVMDKオブジェクトを含む、仮想マシンによって消費される容量

Virtual SAN オーバーヘッド[レプリカ・監視・RAID 5 コンポーネントなど]

レプリカや 監視 (Witness )、Raid 5 / 6 のパリティやその他のデータによって消費される容量。

一時的なオーバーヘッド

オブジェクトの移動や再構成によって、一時的に消費される容量。

使用済み – 予約超過仮想マシン

重複排除と圧縮が有効にされていない場合は、画面上のキャパシティの概要部分に表示されます。このフィールドは 「使用済み – 予約超過仮想マシン」と呼ばれます。

オブジェクト・スペース・リザベーション (OSR) を使用することを決めたら、このフィールドによりどのくらいのスペースが予約されるのかを確認することができます。この値が高い場合、オブジェクトスペースリザベーションの値を減らし、このスペースの一部を他の用途に再利用する価値があるか、再検討する必要があります

重複排除と圧縮を有効にしている場合、オブジェクト領域の予約は0%または100%に設定する必要がありま す。(これら以外の中間値を設定することはできません。)

容量の消費のされ方や重複排除/圧縮がどのように動作しているかを確認するフィールドです。

容量の観点から他の情報も項目として必要である・有用であるというご要望がある場合は、私までお知らせくださいませ。プロダクトマネージャーやエンジニアにフィードバック致します

原文 ： VSAN 6.2 Part 7 – Capacity Views 

(http://cormachogan.com/2016/02/25/vsan-6-2-part-7-capacity-views/)

VMware Storage and Availability Business Unitの シニアスタッフエンジニアCormac Horganの個人ブログを翻訳したものになります。vSANの詳細に関しては弊社マニュアル 、KBをご確認ください。また本記事はvSAN 6.2ベースに記載しております。予めご了承ください

The post VSAN Cormac Blog ~ vSAN 6.2 キャパシティ ビュー appeared first on Japan Cloud Infrastructure Blog.

3回目：VMware NSX for vShield Endpointへの移行検証サマリー

-Back Number-
#1_ vCloud Networking and Security (vCNS) の販売終了
#2_Deep Securityを実装するためのNSX
#3_ VMware NSX for vShield Endpointへの移行検証サマリー

こんにちは、ソフトバンク コマース＆サービスの中川明美です。
今回は、「vShield Endpoint(vCNS)からNSX for vShield Endpointへのアップグレード手順をご紹介します。このBlogでは簡単な手順を共有します。詳細な手順をお知りになりたい方は、この後ご紹介するURLから入手ください。

◆構成図◆
今回の手順は、下図の構成で環境を構築しています。赤点線枠のコンポーネントをアップグレードします。vSphere 6.0環境下で、NSX for vShield Endpointへ移行します。
今後、vSphere 5.5 U1 + View 5.3 + Deep Security 9.5環境下からのアップグレード手順もご紹介する予定です。

◆アップグレード手順◆
次の11ステップを進めます。












◆詳細手順◆
<アップグレード手順>
詳細手順を入手されたい方は、こちらにアクセスください。
http://campaign.vmware.com/imgs/apac/jp_dwn/PDF/techresources/20161206_NSXforvShield_Upgrade_Guide.pdf?elqTrackId=0d6a8486773f458c87c7f923b4e16016&elqaid=979&elqat=2

<新規手順>
「NSX for vShield EndpointおよびDeep Securityの新規構築」手順も準備しました。
こちらから入手ください。
http://campaign.vmware.com/imgs/apac/jp_dwn/PDF/techresources/Tips_NSX6.2.4_DS9.6SP1_PoC_20161121.pdf?elqTrackId=0d6a8486773f458c87c7f923b4e16016&elqaid=979&elqat=2

◆まとめ◆

今回のBlogでは、vSphere 6.0環境でのアップグレード手順を共有いたしました。vSphere 6.0環境をご使用のエンドユーザー様は、こちらの手順を参考にアップグレードの計画を進めていただけましたらと思います。
最後に、仮想スイッチについて補足します。NSX for vShield Endpointは、標準スイッチ(vSS)での動作をサポートしています。今回の環境は標準スイッチを構成しています。他の3つの有償エディション(Standard/Advanced/Enterprise)では、分散スイッチ(vDS)のみのサポートになります。標準スイッチはサポートされません。仮想デスクトップ環境は、より多くのESXiホストで構築されています。複数のESXiホストで構成されたクラスタ環境において、分散スイッチのメリットを享受できます。こちらのBlogで、あらためて分散スイッチの活用方法についてご紹介したいと考えています。現在標準スイッチで仮想デスクトップ環境を構築されていらっしゃる場合は、分散スイッチのメリットをご認識いただけましたら幸いです。

The post VMware NSX for vSphereへの移行 appeared first on Japan Cloud Infrastructure Blog.

今朝、私が最初に見たメールは、私の仲間の Alan Renouf からのも のでした。
Alan は、API、SDK、CLI、および Automation Frameworks （Alan 昇進おめでとう）の製品ラインマネージャーです。
このリリースでは多くの改良点があり、多くの賛辞は PowerCLI チームに送られなければなりません。
vSAN の観点からも、この PowerCLI の改良は素晴らしいものです。
補足
PowerCLI  のこれらの新機能を活用するために vSAN 6.5 にアップグレードする必要はありません。
このバージョンの PowerCLI は、vSAN 6.2 および 6.0 でも動作します。

Alan 曰く、
「今回のリリースでは、PowerCLI ストレージモジュールに大きな焦点が当てられています。 vSAN、仮想ボリューム（VVols）、および仮想ディスクの処理に関して多くの機能が追加されています。 vSAN コマンドレットは、vSAN クラスタのライフサイクル全体に焦点を当てた12個以上のコマンドレットに強化されています。 新しい PowerCLI を用いて、テストの実行や vSAN HCL データベースの更新だけではなく、vSAN クラスタ作成プロセス全体を自動化することができます」

vSAN コマンドレットの一覧を次に示します。

• Get-VsanClusterConfiguration
• Get-VsanDisk
• Get-VsanDiskGroup
• Get-VsanFaultDomain
• Get-VsanResyncingComponent
• Get-VsanSpaceUsage
• New-VsanDisk
• New-VsanDiskGroup
• New-VsanFaultDomain
• Remove-VsanDisk
• Remove-VsanDiskGroup
• Remove-VsanFaultDomain
• Set-VsanClusterConfiguration
• Set-VsanFaultDomain
• Test-VsanClusterHealth
• Test-VsanNetworkPerformance
• Test-VsanStoragePerformance
• Test-VsanVMCreation
• Update-VsanHclDatabase

この記事中で私は vSAN 固有の項目だけを強調していますが、Alan が言及するように、VMDK の管理や、Storage Policy Based Management（SPBM） や VVols の新しいコマンドレットなど、他のストレージ領域でも機能が強化されています。

VMware PowerCLI 6.5 Release 1 での変更点の詳細については、（新機能、改善点、bug fix、セキュリティ強化点、廃止予定の機能など） VMware PowerCLI Change Log を参照してください。
特定の機能の詳細内容については、「VMware PowerCLI 6.5 Release 1 User’s Guide」 を参照してください。
特定のコマンドレットの詳細内容については、「VMware PowerCLI 6.5 Release 1 Cmdlet Reference」を参照してください。
ここから PowerCLI 6.5 Release 1 を見つけることが出来ます。 すぐに入手ください！

原文：PowerCLI 6.5 Release 1 and vSAN
http://cormachogan.com/2016/11/18/powercli-6-5-release-1-vsan/
vSAN Cormac Blog 日本語版 Index
http://blogs.vmware.com/jp-cim/2016/03/vsan-index.html

VMware Storage and Availability Business Unit の シニアスタッフエンジニア Cormac Horgan の個人ブログを翻訳したものになります。vSAN の機能に関しては弊社マニュアル 、KB をご確認ください。また本記事は vSAN 6.2 ベースに記載しております。予めご了承ください。

The post PowerCLI 6.5 Release 1 and vSAN appeared first on Japan Cloud Infrastructure Blog.

今週はEMEAで開催されるテックサミットに参加するためベルリンに来ています。このイベントはEMEAのフィールドの皆さんのためのイベントです。私は、vSANのデザインとサイジングを含むいくつかのセッションを担当しました。そのセッションの一部では、トピックとしてvSAN環境でのメモリ消費について取り上げました。過去には、こちらのブログでも触れました通り、ディスクグループ構成によるホストのメモリ要件についてのみお話しをしてきました。例えば、vSANの最大構成時（ホスト毎に最大5つのディスクグループ、各ディスクグループには最大7台のディスクを割り当て可能）には、ホストのメモリを最低でも32GB消費します。しかし、これはvSANのみが消費するのではなく、ワークロードを実行するために消費されるのかもしれません。その値は構成の上限としてお考えください。上の過去のブログで触れたように、もしホストが32GB以下のメモリしか搭載していない場合は、ホスト上で作成されるディスクグループの数を減らす必要があります。
私の知っている限り、何がvSANクラスタ上のメモリ消費の一因となるのかについて、情報として共有されていませんでした。このブログで、その部分について説明をしていきたいと思います。

[Update] KB2113954でも、vSAN環境でのメモリ消費について触れられています。

vSAN環境のメモリ消費を理解するために、以下の方程式が使われます。

・BaseConsumption：ESXiホスト毎で、vSANによって消費される固定のメモリ量。この値は現在は3GBです。このメモリは、vSANのディレクトリ情報、ホスト毎のメタデータ、メモリキャッシュを格納するために使われます。vSANクラスタが16ノードを超える場合は、BaseConsumptionの値は300MB増えて、3.3GBとなります。

・NumDiskGroups：ホスト毎のディスクグループ数。1から5の範囲で設定可能です。

・DiskGroupBaseConsumption：ホストの個々のディスクグループによって消費される固定のメモリ量。この値は現在500MBです。このメモリは、主にディスクグループ毎の操作の際に使われます。

・SSDMemOverheadPerGB：SSDの各GB毎に割り当てられた固定のメモリ量。この値は現在はハイブリッド環境では2MB、オールフラッシュ環境では7MBとなっています。このメモリの大部分は、ライトバッファやリードキャッシュ用途として使われるSSD内のブロックのトラックを保持するために使われます。

・SSDSize：SSDのサイズ（GB）

注意：これらの値はvSAN 6.0,6.1,6.2を前提としています（KB2113954参照）。将来バージョンで変更される可能性があります。

それではいくつかのシナリオに沿ってメモリ消費について理解を深めていきましょう。

□シナリオ1
各ホストで32GB以上のメモリを搭載、vSANクラスタを構成するホスト数は16台以下、SSDのサイズが400GB。

例1
ホスト毎に1つのディスクグループ、ハイブリッド構成

例2
ホスト毎に3つのディスクグループ、ハイブリッド構成

例3
ホスト毎に1つのディスクグループ、オールフラッシュ構成

例4
ホスト毎に3つのディスクグループ、オールフラッシュ構成

□シナリオ2
各ホストで32GB以上のメモリを搭載、vSANクラスタを構成するホスト数は16台以上、SSDのサイズは600GB。
vSANクラスタが16台を超える場合は、BaseConsumptionは300MB増えてトータル3.3GB。

例5
ホスト毎に1つのディスクグループ、ハイブリッド構成

例6
ホスト毎に3つのディスクグループ、ハイブリッド構成

例7
ホスト毎に1つのディスクグループ、オールフラッシュ構成

例8
ホスト毎に3つのディスクグループ、オールフラッシュ構成

□シナリオ3
各ホストで32GB以下のメモリを搭載。32GBよりも少ないため、メモリの消費量は公式（SystemMemory/32）に従って直線的に減少します。SystemMemory（GB）とは、システムに搭載されるメモリの搭載量です。よって、システム搭載メモリが16GBの場合、メモリ消費量は公式から”1/2”となります。システム搭載メモリが8GBの場合、”1/4”まで減少します。

各ホストの搭載メモリが16GB、vSANクラスタを構成するホスト数は16台以下、SSDのサイズが400GBという前提で考えましょう。

例9
ホスト毎に1つのディスクグループ、ハイブリッド構成

例10
ホスト毎に3つのディスクグループ、ハイブリッド構成

例11
ホスト毎に1つのディスクグループ、オールフラッシュ構成

例12
ホスト毎に3つのディスクグループ、オールフラッシュ構成

vSAN構成におけるメモリ消費量について、いくつかの例をもとにまとめてきました。このようにして、vSANのメモリオーバーヘッドを算出することができます。特に考慮すべき点は、以下の通りです。

・ホストのメモリ搭載量が32GB以下の場合には、vSANはメモリ消費を抑制します
・16ノードを超えるvSANクラスタ環境では、追加でメモリを消費します
・オールフラッシュ構成では、ハイブリッド構成と比べて追加でメモリを消費します

The post vSANのデザインとサイジング　-　メモリオーバーヘッドに関する考慮点 appeared first on Japan Cloud Infrastructure Blog.

このトピックについて、さまざまな情報源から多くの情報が確認できると思います。
当然ですが、VMware のテクニカルマーケティングチームから発信される、最新の有益なドキュメントをチェックし、より詳細な情報や公開されているマニュアル等を参照することを強くお勧めします。
しかし、私からも vSphere 6.5 で使用できる新しい vSAN 機能の概要を説明したいと思います。
このバージョンの vSAN は6.5 と呼ばれます。

1. ライセンスに関する変更
まず最初に強調したいのは、vSAN のライセンスに関する大幅な変更です。
ライセンス条件は緩和されており、vSAN Standard ライセンスで All-Flash vSAN クラスタを展開できるようになりました。ですが、この vSAN Standard では重複排除や圧縮などのデータサービスは利用できません。これらのデータサービスを使用するには、より上位のライセンスのエディションが必要になります。

補足：vSAN 6.5 での各エディションと利用できる機能は以下の PDF P4 で確認できます
VMware vSAN 6.5 Licensing Guide

2.  iSCSI サポート
vSAN 6.5 には、vSAN クラスタ上に iSCSI ターゲットと LUN を作成するための新しい機能が追加され、これらの LUN は vSAN の外部で他の用途に使用できます。これは、vSAN クラスタに必要以上のストレージ容量があり、その容量をクラスタ外で利用する場合に便利な機能です。

この新しい機能をどのように利用できるかについては、多数の制限とサポートに関する考慮事項があることに留意ください。たとえば、これらの iSCSI LUN を ESXi ホストに提供することはできません。
本番環境で iSCSI LUN を実稼動させる前に、公式ドキュメントを参照し、出来ること・出来ないことを確認する事を強く推奨します。

3. 2 ホストでの展開における直接接続と 監視トラフィック(witness traffic)の分離
これは、リモートオフィス/ブランチオフィス（ROBO）での利用、もしくは小規模ビジネス（SMB）のユースケースで利用する場合、2台のホストで vSAN を展開することを検討している方にとって非常に興味深い改善です。
VMware は、この構成での 2つの ESXi ホストをネットワークケーブルで直接接続することをサポートし、ESXi ホスト間の物理スイッチが必要ではなくなります。
この拡張機能には、vSAN 監視トラフィックをデータトラフィックから切り離すためのメカニズムが含まれています。つまり、vSAN データトラフィックを直接接続ネットワークに残すことができ、監視トラフィックを別の VMkernel インターフェイス経由で監視ホスト/アプライアンスに送信することができます。繰り返しになりますが、 公開されている情報が豊富に存在し、この新しい構成を展開する方法の詳細がテクニカルマーケティングチームからリリースされます。これにより、2ノードの vSAN 構成を展開するコストが大幅に削減されます。

4. 512eデバイスのサポート
これは多くのお客様が求めていることです。 4K ネイティブデバイスはまだサポートされていませんが、これらの512e （エミュレーション）デバイスのサポートにより、今後はより大容量のデバイスを vSAN で使用できます。

5.  vSAN 用の PowerCLI コマンドレット
多くのお客様が求めているのは、PowerCLI コマンドレットを利用し、さまざまな vSAN タスクをスクリプト化 / 自動化することです。既に公開されたPowerCLIの新バージョン6.5には、vSAN で使用できる新しい PowerCLI コマンドレットもいくつか用意されています。
これらのコマンドレットも以前のバージョンの vSAN と下位互換性があり、以下の VMware Product Interoperability Matrixes  から、PowerCLI 6.5 と、vSAN 6.5, 6.2, 6.0 との互換性を確認できます。
VMware Product Interoperability Matrixes

また、PowerCLI 6.5 は以下より入手できます。
Download VMware PowerCLI 6.5 Release 1
VMware PowerCLI Documentation

vSAN 6.5 の便利な新機能について、皆さまに賛同いただけると確信しています。

原文：What’s new in Virtual SAN 6.5

What’s new in Virtual SAN 6.5

VSAN Cormac Blog 日本語版 Index
http://blogs.vmware.com/jp-cim/2016/03/vsan-index.html

VMware Storage and Availability Business Unitの シニアスタッフエンジニアCormac Horganの個人ブログを翻訳したものになります。vSANの機能に関しては弊社マニュアル 、KBをご確認ください。また本記事は vSAN 6.2 ベースに記載しております。予めご了承ください。

The post What’s new in VSAN 6.5? appeared first on Japan Cloud Infrastructure Blog.

3回目：ビューの活用方法②

– Back Number –
#1…最新のV4Hが使いやすくなっている！
#2…ビューの活用方法①
#3…ビューの活用方法②
#4…レポートの活用方法
#5…vRealize Log Insightとの連携

こんにちは、ソフトバンク コマース＆サービスの中川明美です。
前回お伝えしましたとおり、今回はカスタムビューの活用方法をご紹介します。

最初に、エディションごとの機能を確認します。

◆エディション◆
カスタム機能を使用するには、「Advanced」エディション以降が必要です。前回ご紹介した標準ビューの機能は、「Standard」エディションから使用できます。

◆カスタムビュー◆

下図のビューは、「CPU」「メモリ」「データストア」「ネットワーク」の4つのメインリソースのワークロードを調査するために新規作成しました。グラフが少々ひしめき合っていますが、複数リソースの相関関係の確認を前提に構成しました。

たとえば、ネットワークI/Oの遅延の原因を調べていたら、CPUの処理性能が原因だったということがあります。複数のリソースを並べたカスタムビューを活用すれば、このような相関関係を確認する場合に最適です！
先のカスタムビューを例に、「CPU」と「ネットワークI/O」の相関関係を調べたい場合は、「メモリ」と「データストアI/O」の凡例(ラベル名)を2回クリックします。そうすることで、調査対象のグラフのみ表示されます。もう一度ラベル名をクリックすれば、グラフは再表示されます。1つのカスタムビューで、表示を切り替えることにより、活用度がぐ～んと上がりますね。

ここからは、カスタムビューの作成手順を確認します。

◆カスタムビューの作成①◆

ナビゲーションパネルの「コンテンツ」ボタンをクリックします。左メニューから「ビュー」をクリックし、ビューの管理画面を表示します。「ビューの作成」ボタンをクリックします。

先のカスタムビューを例に、新規作成します。5つのステップで完成です！

◆標準ビューを利用したカスタムビューの作成◆

次は、標準ビューをコピーし、ビューを作成する方法を確認します。この方法は、表示されるデータのみを変更したい場合に適しています。
先にコピー元となるビューを確認します。下図は、「仮想マシンのワークロードデマンドサマリリスト」ビューです。仮想マシンが過去1週間に使用したリソース状況を確認することができます。仮想マシンでワークロードが高い場合、どのリソースが高いワークロードを引き起こしているかを特定することができます。
各リソースは、「5分」間隔でロールアップされ、過去「1週間(7日間)」の「平均値」が表示されます。これらはデフォルトの値です。「ロールアップ間隔」と「日付範囲(期間)」は、この画面のアイコン(赤枠)から都度変更できます。

◆カスタムビューの作成②◆

デフォルトの平均値を「最新値」に変更するカスタムビューを作成します。最新値を表示したいというご要望はよくあります。
ビューの管理画面で、変更したいビューを選択し、「ビューのクローン作成」アイコンをクリックします。

ここでは、「名前」とデータの「変換」の値を変更するだけです！

他に、何が変更できるのかを確認します。
「ロールアップ間隔」と「日付範囲」は、ビュー画面以外にウィザード内でも変更できます。

◆まとめ◆

すべてのビューをながめてみました。ビューでは、さまざまな視点からデータを得られます。そのデータをぜひ活用いただきたいです。
加えてビューは、ダッシュボードやレポートを構成するウィジェットとしても使用できます。ダッシュボードのビュー活用法はこちらのBlogで紹介しています。レポートのビュー活用法は次回のBlogでご紹介します。
実は、「vROpsをパワーアップしよう！」Blogを投稿する前は、カスタムが苦手でした。しかし、Blogを執筆する機会を得たり、ワークショップでエンドユーザー様からのご要望にお応えしたりするうちにすっかりはまってしまいました(笑)。

このBlogから、みなさんの仮想基盤がパワーアップされましたら、うれしい限りです！！

ソフトバンクC&SのサイトでvROpsを使用した仮想化健康診断の事例を紹介しています。ここでは、「vSphere環境を運用管理している方が何に困っているのか」「その困ったことにパートナーのみなさまがどのようにアプローチされているのか」を載せています。
インタビュー形式で構成しています。ぜひお仕事に役立つ情報を手に入れてください！

The post VMware vRealize Operations Manager (vROps) をパワーアップしよう！ パート2 appeared first on Japan Cloud Infrastructure Blog.

第1回 vSAN stretched clusterとは？

皆さん、こんにちは。JBCC株式会社の美谷島と申します。

突然ですが、VSAN Stretched Cluster をご存知でしょうか？

先日のvForum 2016 の VSAN Deep Dive セッションでも紹介されていました vSAN stretched Clusterの概要、構築方法などを 今回から4回にわたってご紹介していきたいと思います。

第1回ではvSAN stretched clusterとは？と題してvSAN stretched clusterの概要・メリット、サイジング方法をご紹介します。

弊社では、VMware社のvSphereやHorizonのような仮想化製品のインテグレーションに力を入れています。

その中でも、特に注目したのが ” Software Defined Storage（以下SDS）”です。SDS は一言でいうとソフトウェアでストレージ機能を実装するという技術です。仮想化基盤では可用性を持たせるために共有ストレージ装置が必要となりますが、SDS を導入すれば汎用的なx86サーバだけで共有ストレージ機能を実現できるのが強みです。また、x86サーバを追加するだけで簡単に容量とパフォーマンスを増強することができますので、オンプレミス環境であってもクラウド環境のような柔軟な拡張性が実現できるようなりました。ちなみに SDS は近ごろ大変脚光を浴びている Hyper-Converged Infrastructure のコアテクノロジーでもあります。

現在各社からたくさんの SDS 製品がリリースされておりますが、その中でも VMware 社の vSAN stretched cluster 機能 は BCP 対策も可能な高度な機能を有したストレージです。

私共はこの vSAN stretched cluster に着目して、お客様に新たな選択肢となり得るであろう BCP ソリューションをお届けするためにこれを検証することにしました。

vSAN概要

まず、stretched clusterを語る前に簡単に vSAN のおさらいをしておきますが、 vSAN は SDS 製品の中でも代表格となる製品です。 従って、 vSAN によって SDS のメリットがもれなく享受でき、その上、各ノードに SSD を配置することで、これをディスクの Read Write の IO のキャッシュとして利用することができパフォーマンス向上も期待できます。さらには、仮想マシン毎に可用性のレベルや QoS をセットすることが可能で、ポリシーベースで柔軟性があるところも他の SDS にはない、非常に大きな強みとなっています。

vSAN Stretched Cluster概要

ここからが本題となりますが、 Stretched Cluster は通常の vSAN 構成と何が違うのでしょうか。

端的にご説明しますと地理的に離れたサイト間で vSAN が組めるということです。普通に考えれば2サイトにロケーションが分かれればストレージは２つ独立して存在することになるのですが、 Stretched Cluster は2つのサイト間（地理的に離れたサーバ同士）でも1つの共有ストレージとして扱うことができます。

また、災害対策と言うと一般的には Active – Standby 構成となり、災害対策サイト側の機器は普段は稼働することなく、遊んでしまっている状態になってしまい、ちょっと勿体ない構成となってしまいますが vSAN Stretched Cluster は本番サイト、災対サイト 共に Active – Activeで構成できる ことがポイントです。

Active – Active構成にすることで以下のメリットが挙げられます。

・災害対策サイト側も Active なのでリソースを有効活用

・ゼロRTO * 1（サイト間でデータは完全同期レプリケーション）

*1 RTO ・・・ Recovery Time Objective

・各サイトにvCenterを配置する必要がなく、本番サイト1つで良い

・本番サイトから災害対策サイトへの切り替え作業が不要

（基本的にL2延伸でサイト間は利用しますので、DNSによるレコード切替、IPアドレス変更といったサイトを切り替える手順を実施する手間が省けます。）

シンプルな構成で DR 構成を組みたいといったユーザ様にとってはメリットが大きい構成だと思います。

また、通常の vSANは 同じデータを別ホストにも書き込むことで冗長性を担保していることが特徴ですが、 vSAN Stretched Cluster構成であれば別サイトのホストに可用性のためのデータを書込むことが可能になりますので、サイト障害にも、もちろん データロスなしで対応できます。

その他に必要となるコンポーネントとして witness サーバがあります。 Witness サーバとは監視サーバのことであり、サイトの死活監視をしていますので Witness サーバは両サイトとは別のセグメントで立てる必要があります。

vSAN Stretched Cluster 環境では2フォルトドメインまで立てられ、各フォルトドメインに15ホストまで構築可能です。フォルトドメインとは Disk グループで構成される障害の単位になります。

vSAN Stretched cluster の要件は以下の通りです。（一般的な vSAN の必要条件はここでは割愛します。）

・vSphere 6.0　update1以上

・最適な仮想マシンの挙動を行うためにDRSのアフィニティルールが必要となりますので、エディションはEnterprise Plus以上

・10 Gbps以上のネットワーク帯域(サイト間)

・100 Mbps以上のネットワーク帯域（サイト ー witness間）

・5 msec以下のlatency（サイト間）

・100 msec以下のlatency（サイト ー witness間）

・サイト間はL2接続

・サイト – witness間は L3 接続

既にお気づきかと思いますが、ここで肝となるのがネットワーク（vSANネットワーク）です。

そこで、vSAN ネットワークのサイジング方法をご紹介します。

サイジング

ここからはサイジングの話となります。まず、CPUやメモリ、 Diskといったサイジングについては通常のvSAN 構成と同様なので以下の VMware 社 川崎様記載のブログを参照ください。

http://blogs.vmware.com/jp-cim/2016/04/vSAN_04.html

通常のvSAN構成と違う点としては、片方のサイトが被災した場合も考慮しなければいけないのでCPU、メモリは片方のサイトで賄えるようにサイジングする必要があります。

ネットワークのサイジングについては write のスループットがポイントとなってきます。データを書き込む際の処理の動きは図4の通りとなり、サイト間の vSAN ネットワークが 5msec以内であることが必須要件となります。

データの読み込みは仮想マシンが稼働しているプライマリホスト群から直接読み込みますので別サイトにあるホストにアクセスすることはなく、WAN経由してまでvSANネットワークを使うことはありません。（図5）

そこで各ホストの write のスループットを算出することで必要となる vSAN ネットワーク帯域が判明できますのでネットワークをサイジングするときは write スループットの算出がお勧めです。

※ JBCC社における構成時の参考値

・既存に vSAN を導入している場合

…ESXTOPで算出

・vSphere 環境のみであり、新規に vSAN Stretched Cluster を導入する場合

…既存ストレージの管理画面から取得

(例)　writeスループット：1 Gbpsの場合

vSAN ネットワーク＝1 Gbps ( writeスループット)×1.4(オーバーヘッド)×1.25(障害時に走るtraffic 25 % 込)=1.75 Gbps

この場合であれば10 Gbpsの帯域で余裕ですね。

以上が vSAN Stretched Clusterの概要、サイジング方法でした。

尚、弊社ではストレージのワークロードを分析しお客様環境のIO分析をするストレージクリニックと呼ばれる無償サービスを実施していますのでwriteスループットの算出のみでなく仮想環境のサイジングを実施する際は是非ともご活用ください。

http://www.jbcc.co.jp/products/plan/storage_clinic/index.html

ただ、障害時にどのような挙動になるか気になりますよね？

JBCC は日本で最初にvSAN Stretched Clusterをお客様に提案し、ご採用頂きました。

ご採用頂くにあたり私共は、様々な検証をしました。そのときの内容を元に、次回は障害時の挙動に関してご紹介しますので是非ともご確認ください。

vSAN Stretched Clusterブログ

第1回 vSAN Stretched Clusterとは？

第2回 障害時の挙動

第3回 構築、運用ポイント

第4回 JBCC推奨構成

The post VSAN で DR / BCP を実現する VSAN Stretched Cluster ！！ ~ vSAN stretched clusterとは？ ~ appeared first on Japan Cloud Infrastructure Blog.

4回目：レポートの活用方法

– Back Number –
#1…最新のV4Hが使いやすくなっている！
#2…ビューの活用方法①
#3…ビューの活用方法②
#4…レポートの活用方法
#5…vRealize Log Insightとの連携

こんにちは、ソフトバンク コマース＆サービスの中川明美です。
今回はレポートの活用方法をご紹介します。レポートを活用するためには、カスタマイズが必要です！！

◆よくあるご質問◆

「レポートの出力期間を変更したい」と質問を受けることがあります。その場合はレポートの元となる「ビュー」の日付範囲を変更します。
レポートは、1つ以上の「ビュー」または「ダッシュボード」、もしくは両方から構成されます。データの表示は「ビュー」または「ダッシュボード」を使用し、レイアウト(配置)や出力形式(PDF/CSV)をレポートの作成ウィザードで指定します。

◆カスタムレポートの作成①◆

既存レポートの出力期間(過去の期間)をデフォルトの30日から特定の2ヶ月間に変更します。
<データタイプの確認>
ここでは、「ホストのCPUデマンドおよび使用量(%)トレンドビューレポート」をカスタムの対象にします。どのビューを元にレポートが構成されているかを確認します。レポートを選択し、「テンプレートの編集」アイコンをクリックします。

「2.ビューとダッシュボード」の「データタイプ」が表示されます。このレポートは、「ホストのCPUデマンドおよび使用量(%)トレンドビュー」というビューで構成されていることがわかります。

<ビュー/レポートの編集>
レポートのデータ表示期間を変更するには、レポートのデータタイプで指定されたビューの日付範囲を変更します。その後、変更したビューに差し替えます。この場合、ビューもレポートもコピーを作成し、変更することをお勧めします。

■ビューの編集

■レポートの編集

◆レポートの出力◆
レポートのテンプレートを実行し、レポートを出力(ダウンロード)します。


下図は、日付範囲を変更したレポートをPDFで出力した結果です。「特定の日付範囲」で指定した8月～9月の過去データが表示されています。

◆カスタムレポートの作成②◆
新規レポートを作成します。前回のBlogで作成したカスタムビューを元にレポートを作成します。
下図は、前回のBlogで作成したカスタムビューです。


<レポートの新規作成>

◆まとめ
2つのカスタムレポートの作成方法をご紹介しました。ぜひ活用してみてください！
全体を通したお話となりますが、vROpsに慣れるまでは標準の機能(ダッシュボード/ビュー/レポート)を使用してみてください。vROpsを知る段階で、カスタム機能までを習得しようとすると、「やることがいっぱい」「カスタム機能は難しい」と思ってしまうようです。
まずは、「vROpsで何ができるの？」を知ることから始めてください。その後、カスタム機能を習得するのが理想的です。カスタム機能については、ぜひこちらのBlogをご活用いただけたらと思います。

次回は、vRealize Log Insightとの連携をご紹介します。

ソフトバンクC&SのサイトでvROpsを使用した仮想化健康診断の事例を紹介しています。ここでは、「vSphere環境を運用管理している方 が何に困っているのか」「その困ったことにパートナーのみなさまがどのようにアプローチされているのか」を載せています。
インタビュー形式で構成しています。ぜひお仕事に役立つ情報を手に入れてください！

The post VMware vRealize Operations Manager (vROps) をパワーアップしよう！ パート2 appeared first on Japan Cloud Infrastructure Blog.

5回目：vRealize Log Insightとの連携

– Back Number –
#1…最新のV4Hが使いやすくなっている！
#2…ビューの活用方法①
#3…ビューの活用方法②
#4…レポートの活用方法
#5…vRealize Log Insightとの連携

こんにちは、ソフトバンク コマース＆サービスの中川明美です。
今回はvRealize Operations ManagerとvRealize Log Insightを連携した活用法をご紹介します。

仮想化健康診断では、「ワークロード」と「ストレス」の値を参考に、分析してくださいとお話しています。「ワークロード」は現在の状態を、「ストレス」は過去6週間の平均値を表わしています。
下図の「ストレス」の結果から、木曜の16時から18時、19時から20時の間で負荷が高いことがわかります。たとえば、バックアップなど定時に高負荷な状態が起きる場合は、この画面から原因を推察することができます。しかし突発的な負荷が起きた場合は、原因を調査する必要があります。その際、Log Insightで収集されたイベントから何が起きたかを調査すれば、より早く原因を特定することができます。vROpsとLog Insightを連携することで、よりパワーアップできますね。

このBlogでは、ネットワークの負荷を高めた状態を準備し、原因を特定するまでのプロセスを、連携の活用法としてご紹介します。
ネットワークの負荷を高める方法は、仮想マシン「Win7-01(192.168.250.202)」から、仮想マシン「Win7-02(192.168.250.200)」へPingコマンドを実行します。
Pingコマンドは、「-t：パケットの送受信を無限に繰り返す」と「-l：パケットのデータサイズ(バイト単位)を指定する」の2つのオプションを追加しています。今回は負荷を高めるため「-l 1000」を指定しました。-lのデフォルト値は32バイトです。
実行してしばらく経つと、「推奨」タブに、Win7-01でCPU使用量が高いためストレスが発生しているとアラートが表示されました。

◆vROpsでの分析◆
ここから順に原因を特定していきます！
「Win7-01」の「分析」タブで詳細な状況を確認します。通常とは異なる状態であることを表わす「アノマリ」が高い値を示しています。

どのリソースが高い値を引き起こしているかを、画面下部の詳細情報から確認します。
これらの情報から、「ネットワークリソース」に原因があることがわかります。

「詳細」タブの「仮想マシンのネットワークI/O診断」からは、14:40以降に受信/送信パケット数が上がっていることもわかります。

ここで、あらためてネットワークのパフォーマンスについて確認します。

◆仮想ネットワークのパフォーマンス◆
仮想ネットワークは、「スループット」や「パケットドロップ」のメトリックを使用してパフォーマンスを監視します。特に「パケットドロップ」が発生しているかを確認することはパフォーマンス劣化の原因を特定する有効な方法です。
パケットドロップは、受信と送信でパフォーマンス劣化の原因が異なります。そのため対応方法もそれぞれ異なります。

<ドロップ送信パケット>
送信パケットは、ネットワークキャパシティが足りない場合に、仮想NICから仮想スイッチポートの順でキューイングされ、いずれもキューがあふれるとドロップされます。

<ドロップ受信パケット>
受信パケットは、準備できていない場合に、仮想NICから仮想スイッチポートの順でキューイングされ、いずれもキューがあふれるとドロップされます。

「準備できる」というのは、受信する仮想マシンで、仮想CPUに物理CPUが割り当てられた状態です。物理CPUが割り当てられなければ、受信処理を行うことができません。
仮想マシンのCPU使用率は、受信パケットのドロップ数にも影響を与えます。

◆Log Insightでイベントの検索◆
下図は、「IPアドレス」と「dropped」をキーワードに、仮想マシン「Win7-01」のLogを検索した結果です。木曜(12/8)の17時前後にドロップされているイベントがあります。vROpsの「ストレス」で確認した曜日と時間が一致しています。ドロップによるパフォーマンスが劣化していることは確定しました。

参考までに、受信側の仮想マシン「Win7-02」の状況も確認してみます。
こちらの仮想マシンも、「アノマリ」で高い値を示しています。送信側の仮想マシン「Win7-01」と異なるのは、「CPU|準備完了」の値も上がっています。仮想CPUに物理CPUに割り当てられず、受信処理が行われていないことがわかります。
ネットワークのパフォーマンスが劣化している場合は、原因特定にCPUの状況も確認する必要がありますね。

◆まとめ◆
Log Insightと連携することで、詳細な日時で何が起きたのかを確認することができます。
vROpsの「詳細」タブでは日時までは確認できますが、具体的に何が起きているかまでは調査するのは厳しいですね。
仮想化健康診断で、具体的な日時で何が起きているのでしょうかと聞かれます。連携すると、このご質問にも対応できますね。ぜひご活用いただきたいと思います。
計9回（パート1 x4回、パート2 x5回）にわたり、vROpsの活用法をご紹介してきました。「このBlogで勉強しています」と声をかけていただくこともあり、嬉しいフィードバックでした。
今後も、様々な製品の活用法をご紹介していけたらと思います！

ソフトバンクC&SのサイトでvROpsを使用した仮想化健康診断の事例を紹介しています。ここでは、「vSphere環境を運用管理している方が何に困っているのか」「その困ったことにパートナーのみなさまがどのようにアプローチされているのか」を載せています。インタビュー形式で構成しています。ぜひお仕事に役立つ情報を手に入れてください！

The post VMware vRealize Operations Manager (vROps) をパワーアップしよう！ パート2 appeared first on Japan Cloud Infrastructure Blog.

1回目：仮想スイッチのお作法#1 （仮想スイッチの歴史とポートIDベースロードバランス）

– Back Number –
#1…仮想スイッチのお作法#1
#2…仮想スイッチのお作法#2

こんにちは、ソフトバンク コマース＆サービスの中川明美です。
今回は、あらためて「仮想スイッチ」について取りあげます！！
私は、2009年から2015年までVMware認定インストラクターとして、「VMware vSphere : Install, Configure, Manage (5日間)」等の公認コースを実施してきました。
インストラクターとして得た、「ここがポイントですよ！」を共有しながら、標準スイッチと分散スイッチの同じところ／異なるところをご紹介していきます。
第1回目は、仮想スイッチの歴史とロードバランスのポートIDベースについてご紹介します。

◆仮想スイッチの歴史
Version3.5の知識のままvSphereを管理運用されているエンドユーザー様にお会いすることがあります。たとえば、vSphere HAや仮想スイッチです。仮想スイッチの１つである標準スイッチは3.5から変更点はありませんから支障がないのかもしれません。
しかし「ESXiホストの管理台数が増える」「ハードウェアの進化を活用する」となると、新しい知識(機能)が必要になります。そしてベストプラクティスも変更されていきます。
私は、エンドユーザー様にアップデートされた機能に興味をもっていただきたい場合、歴史(機能の変遷)の話をします。ご存知の時点から順に歴史の話をすると、興味をもっていただける傾向があります。では、歴史のお話を！
仮想スイッチの歴史は、公認コースのテキストを使用します。
Versionが上がれば機能が増えます。機能が増えればコースのスライド内容が変わるのは当然と思うかもしれません。しかし比較してみると、機能だけではなく、「思い(ベストプラクティス)」も伝わってくる気がします。順次見ていきましょう。

◆Version 3.5
古くからVMware製品に携わっている方には、懐かしい「サービスコンソールポート」です。3.xまでは管理ネットワークの接続タイプが必要でした。この図では、1つの「標準スイッチ」に複数の接続タイプが構成されています。1Gbps物理NIC３つの構成では、パフォーマンスに支障が出そうですね。
接続タイプ：3種類のネットワーク接続

◆Version 4.0
4.0になって、用途によって仮想スイッチを分ける例が紹介されています。この時は、用途別に仮想スイッチを分けるのは一般的でしたね。課題はESXホストの物理NICの数でした。冗長化を考慮するなら、最低2倍の物理NICが必要です。

◆Version 4.1
4.1になると、冗長化を意識した、複数の物理NICが搭載された図になっています。1Gbps物理NICが主流の時のベストプラクティスが見えてきますね。上の構成図は、10Gbps物理NICを使用した分散スイッチに適していますね！

◆Version 5.5
スライドの構成は、4.1以降変更はありません。しかし、各役割のVMkernelポートが1つという構成は最近ありませんね。vMotionであれば帯域確保や、iSCSIであればパスを増やす必要があります。その場合、複数のVMkernelポートを構成します。

◆なぜVMkernelポートは複数必要？
なぜVMkernleポートが複数必要なのかを知る前に、NICチーミングの「ロードバランス」を復習します。ロードバランスは物理NICの選択方法です。デフォルト値はポートIDベースです。ここでは仮想マシンポートグループを使用して、ポートIDベース確認します。物理NICは、仮想NICが割り当てられた仮想スイッチのポートによって選択されます。たとえば、下図は、VM①の仮想NICはポート0に割り当てられています。ポート0に接続されたVM①の通信は物理NICのvmnic0を使用します。同様にVM②はvmnic1を、VM③はvmnic2を使用します。すべての物理NICが選択されたため、残りのVM④は再びvmnic0を使用して通信をします。この説明はあくまでもイメージです。ポートIDベースは名前の通り、仮想NICが割り当てられたポートをベースに物理NICを選択し、ロードバランスをします。シンプルな物理NICの選択方法ですね。デフォルト値であることは納得です！

次に、VMkernelポートはどうでしょうか？
下図は、vMotionの構成例です。この仮想スイッチには、vMotion用のVMkernelポート(vmk0)が１つ構成され、物理NICが2つ(vmnic0/vmnic1)割り当てられています。VMkernelポートはESXiホストが通信をするために必要なポートですから、IPを付与するだけなら、1つでも支障はなさそうです。ただし、デフォルトのロードバランス設定はポートIDベースですから、フェイルオーバーが起きなければvmnic1は使用されません。ポートIDベースは、仮想NICが割り当てられた仮想スイッチのポートによって物理NICが選ばれるから。。。でしたね。この構成で冗長性は満たしていますが、2つの物理NICを十分に活用しているとは言えません。

ではどのように構成するのがベストでしょうか。参考までに次のKBをご確認ください。

-vSphere における複数 NIC の vMotion-
https://kb.vmware.com/kb/2014840

VMkernelはデフォルトのポートIDベースを使用します。複数の物理NICを活用するには、活用できるように構成をする必要があります。下図のように物理NICが2つあれば、VMkernelも2つ作成し、それぞれにActive-Standbyの設定をします。この構成をすることによって、2つの物理NICを活用し、帯域を拡張することができます。パフォーマンスを上げられますね。

VMkernelポートは、vMotion以外の用途として、「管理ネットワーク」「iSCSI/NFS」「FT」がありますね。管理ネットワークは、vSphere HAハートビートに影響がありますから、私は念には念を入れてロードバランスの値として、「明示的なフェイルオーバー」の設定を行っています。iSCSIでは、ポートバインドの設定が必要な場合もあります。参考までに次のポートバインドのBlogをご確認ください。

http://ja.community.dell.com/techcenter/b/weblog/archive/2012/04/05/equallogic-vsphere-portbind

◆まとめ
ポートIDベースの物理NICの選択方法を知ると、特にVMkernelポートではNICチーミングが必要な構成であることをご理解いただけたと思います。ESXiホストが少ない場合は、複数の標準スイッチにポリシーを構成するのも煩雑ではないかもしれません。しかし、VDI環境など多くのESXiホストがある環境では、ポリシーを一元管理できる分散スイッチが注目されてきますね。
次回は、分散スイッチを活用するシチュエーションについてご紹介します。

The post 仮想スイッチのお作法～標準スイッチから分散スイッチへの道～ appeared first on Japan Cloud Infrastructure Blog.

2回目：仮想スイッチのお作法#2 （分散スイッチはいつ使用する？）

– Back Number –
#1…仮想スイッチのお作法#1
#2…仮想スイッチのお作法#2

こんにちは、ソフトバンク コマース＆サービスの中川明美です。
前回、仮想スイッチの歴史とロードバランスの1つであるポートIDベースについてとりあげました。なぜポートIDベースについてとりあげたのか？
それは、なぜその設定が必要なのか、なぜその機能が追加されたのかを理解するためには、ポートIDベースを理解することが早道だからです。
現在、NICチーミングをデフォルト設定のまま構成することは少なくなりましたね。それらの設定を変更する際、状況に応じては、分散スイッチを選択する方が運用管理の煩雑さを避けることができます。今回は、あらためて分散スイッチのよさと、いつ使うのがよいのかをご紹介します。

◆標準スイッチと分散スイッチの違い
最初に、標準スイッチと分散スイッチの異なるところ／同じところを復習します。

<異なるところ>
異なるところは、ネットワークポリシーを管理する場所です。ネットワークポリシーには、「セキュリティ」「トラフィックシェーピング」「NICチーミング」があります。
「標準スイッチ」は各ESXiホストで作成しますが、ネットワークポリシーも各ESXiホストで管理します。

「分散スイッチ」は複数のESXiホストにまたがって作成され、ネットワークポリシーはvCenterサーバーで一元管理します。仮想マシンを複数のホスト間で移行する場合でも、仮想マシンに対して一貫したネットワーク構成を提供することができます。
ポリシーは各ESXiホストにプッシュインストールされます。vCenterサーバーとの通信が遮断されたとしても、ポリシーで設定した動作に支障がない仕組みを持っています。

<同じところ>
構成するコンポーネントの概念は同じです。先に、標準スイッチからコンポーネントの名前を確認します。

Port/Port Group：
仮想NICが接続する仮想スイッチのポート(出入口)です。ポートには、「仮想マシンポートグループ」と「VMkernelポート」があります。仮想マシンポートグループは、名前の通り複数の仮想マシン用のポートです。

vmk#(0から連番)：
VMkernelポートに接続されている仮想NICには、「vmk#」という特別な名前が付けられます。ESXiホストが通信するために、vmk#にIPアドレスを付与します。

Uplink Port：
物理NIC(Uplink)が接続する仮想スイッチのポート(出入口)です。

vmnic#(0から連番)：
物理NICのことです。

Port/Port Groupの識別名：
左図では、MGMT/Production/vMotionが該当します。ネットワークポリシーの識別名でもあります。

次に分散スイッチです。

分散スイッチが標準スイッチと異なるのは次の2つです。

dvPort Group：
分散スイッチのポートグループをdvPort Groupと呼びます。ポートは複数のESXiホストに分散配置されます。

dvUplink Ports：
論理的な物理NICのポートです。論理的と表現したのは、複数のESXiホストの物理NICをグループ化し、１つのdvUplink Portに割り当てるからです。
分散スイッチでは、いくつの物理NICを割り当てるかを、「dvUplink Ports」の数として指定します。そして各dvUplink PortsにESXiホストの該当物理NICをアサインします。左図では、dvUplink Port 1に3台のESXiホストのvmnic2が割り当てられています。

※dvは「Distributed Virtual」の略

図3と図4の仮想マシンポートグループ「Production」に注目してください。
標準スイッチと分散スイッチを構成するPortとUplink Port(dvUplink Ports)は、同じ構成(図形)で描かれています。標準スイッチと分散スイッチは、単体のESXiホストで構成されるのか、複数のESXiホストにまたがって構成されるかだけの違いです！

本題に入ります！

◆vMotionを例にしたネットワークポリシー設定
前回のBlogで、下図のようにvMotion用にNICチーミングを構成することで、冗長化だけではなく、パフォーマンスの向上も期待できることをご紹介しました。それは2つの物理NICを活用できるからでしたね。

vMotionで必要な設定は次の通りです。

ESXiホストの台数が多くなると、なかなか煩雑な作業です。
たとえば、2つの物理NICを割り当てた標準スイッチで、vMotion用の設定を10台のESXiホストで構成するとなると・・・標準スイッチで、vMotion用のVMkernelポートを2つ作成し、各々でNICチーミングの設定をします。これを10回繰り返すことになります。
入力ミスや設定ミスが生じるかもしれません。分散スイッチであれば、ESXiホストが何台であろうと、ネットワークポリシーの設定は1回の作業で完了します。
管理するESXiホストの台数が多くなれば、分散スイッチに分がありますね。

◆分散スイッチはいつ使うの？
分散スイッチはいつ使うのがよいのでしょう。分散スイッチで提供される、「物理NIC負荷に基づいたルート」と「ネットワーク I/O コントロール」を例に説明します。

<物理NIC負荷に基づいたルート>
分散スイッチのみで提供しているロードバランスの方法(物理NICの選択方法)が、「物理NIC負荷に基づいたルート」です。
物理NIC負荷に基づいたルートは、ポートID と複数物理NICのアップリンク(物理NIC)数を取得し、仮想マシンのアップリンクの負荷を計算します。30 秒ごとにアップリンクを監視し、その負荷が使用量の75 パーセントを超えると、I/O の使用率が最も高い仮想マシンのポート ID を別のアップリンクへ移動します。名前の通り、負荷状況に応じて最適な物理NICを選択する方法です。
デフォルトのポートIDベースはポートによって物理NICが選択されるシンプルな方法ですから、アップリンクの負荷までは見ていません。
仮想マシンの台数が多い仮想デスクトップ環境の場合は、「物理NIC負荷に基づいたルート」を選択することをお勧めします。Horizon Bundleのライセンスでは、vSphere Desktop(vSphere Enterprise Plusと同等の機能) が含まれます。このライセンスであれば、分散スイッチを使用できますね！

<ネットワーク I/O コントロール>
CPUやメモリーのリソースコントロールと同様に、ネットワークリソースのコントロールができる機能です。設定値には、「シェア」「予約」「制限」があります。



最近注目されているHCI基盤を例に説明します。10Gbpsの物理NIC2枚構成の場合、図3のようなトラフィックごとの仮想スイッチを準備することができません。物理NICは仮想スイッチ間で共有できませんから、1つの仮想スイッチに複数のトラフィック(役割)を構成することになります。
ここで、パフォーマンスが気になりますね。分散スイッチであれば、トラフィックごとにネットワークリソースのコントロールが可能です。
デフォルトのネットワークリソースの割り当ては、すべて無制限です。帯域幅が飽和した場合に、ネットワーク I/O コントロールの「シェア値」を使用することで、帯域幅の割り当てをコントロールできます。管理者としては、より多くの仮想マシントラフィックに、より多くのiSCSIトラフィックに十分な帯域を割り当てたい、優先順位を付けたいと考えますよね。そのような場合に備え、ネットワークリソースのコントロールをご検討いただければと思います。

下図は、vSphere Web Clientのネットワークリソース割り当ての画面ショットです。

実際の設計/導入の場面では、下図のように1Gbps物理NICを接続した標準スイッチに管理ネットワークを、10Gbps物理NICを接続した分散スイッチにそれ以外のトラフィックを構成されることが多いと思います。下図は設計例の1つです。
この場合も複数のトラフィックを構成している分散スイッチは、ネットワーク I/O コントロールでのリソースコントロールをお勧めします！
1Gbpsと10Gbpsの混在環境では、「構成の上限(※)」にご注意ください。vSphere 6.5では、1Gbpsは4、10Gbpsは16です。

(※)vSphereの各バージョン毎に準備されているConfiguration maximum ガイドを参照下さい。
vSphere6.5のConfiguration maximum ガイドはこちら。

◆まとめ
今回はあらためて仮想スイッチをとりあげました。分散スイッチは、Version 4.0から「vSphere Enterprise Plus」ライセンスで提供されています。上位ライセンスのため、標準スイッチと比べて、頻繁に導入する機会はなかったのではないかと思います。
しかし、この数年注目されつつある「VMware NSX」では、分散スイッチが前提となります。また、物理NICも10Gbpsが一般的になってきましたから、ネットワーク I/O コントロールの提案もしやすくなっている状況ではないでしょうか。
提案時のエンドユーザー様はコスト重視の傾向がありますが、導入後のトレーニングでは、「先に話してくれれば。。。」とよく言われました(笑)
費用がかかるからこそ、その効果を知っていただくために、事前の勉強会も必要なのでは？と特に感じています。その際にはこちらのBlogをテキストに勉強会を企画いただけたら嬉しく思います。

The post 仮想スイッチのお作法～標準スイッチから分散スイッチへの道～ appeared first on Japan Cloud Infrastructure Blog.

みなさん、こんにちは。VMwareでパートナー様を担当させて頂いてますSEの北村です。

今後、月に1回の頻度で VMware Blog (Cloud Infrastructure Blog と End-User Computing Blog) で、ちょっとした技術的なTIPs を投稿していこうと思っておりますので、お付き合いください。

今回は次の 2点をお伝えします。

1. vSphere (vCenter Server と ESXi) がサポート対象としている Active Directory の Domain Function Level について
2. CPU の EVC 互換の確認方法

では、それぞれについて記載していきます。

1. vSphere (vCenter Server と ESXi) がサポート対象としている Active Directory の Domain Function Level について
みなさん、VMware の Knowledge Base サイト (kb.vmware.com) はご存知でしょうか？　弊社製品におけるトラブルシューティングやサポート関連の情報などを公開しているサイトになるので、是非、ご活用頂けると幸いです。

さて、以下の Knowledge Base (略して KB という言い方をします) は、vCenter Server と ESXi がサポート対象としている Active Directory の Domain Function Level について記載しているのですが、最近、この KB が更新され、昨年末にリリースされた、vSphere 6.5 の情報が追記されました。

・Versions of Active Directory supported in vCenter Server (2071592)
・Versions of Active Directory supported in VMware ESXi (2113023)

ここで、大事な事をお伝えしますが、vSphere 6.5 から Windows 2003 Domain Function Level がサポートから外れました (Windows Server 2003 の延長サポートが既に終了となっていますので、その結果が繁栄されていると思われます)。

・Versions of Active Directory supported in vCenter Server (2071592) より抜粋 (詳細は KBをご参照ください)：

・Versions of Active Directory supported in VMware ESXi (2113023) より抜粋 (詳細は KBをご参照ください)：

それに伴い、「以前のバージョンの vSphere」 と 「Windows 2003 Domain Function Level」 で利用している環境を、vSphere 6.5 へバージョンアップすると、動作の可否に関わらず、vSphere 6.5としてはサポート外の構成となってしまいますので、バージョンアップをご検討されている場合はこの点ご注意ください。

vSphere 6.5 へのアップグレードには以下のドキュメントを参考にして下さい。

1. ブラウザで、http://www.vmware.com/jp/support/support-resources/pubs/vsphere-esxi-vcenter-server-6-pubs.html へ。
2. 「vSphere アップグレード ガイド」の PDF をクリック頂き、PDF版を参照するか、「vSphere 6.5 ドキュメント センター」リンクをクリック頂き、ブラウザの左側の「目次」で、「ESXi および vCenter Server 6.5 のドキュメント」→ 「vSphere のアップグレード」 の順で、クリック頂く事で、ブラウザ上で PDF 版と同じ内容を参照頂けます。

2. CPU の EVC 互換の確認方法
みなさんは、弊社の Compatibility Guide のサイトはご存知でしょうか？ このサイトでは、弊社製品がサポートするハードウェア関連 (一部ソフトウェア) の情報を掲載しており、どのサーバ、どのCPU 、どのIOカード (NICやHBAなど) が弊社製品でサポートされているのかを確認頂く事ができます。

ちなみに、このページに掲載されている情報は、弊社が認定作業を実施していると思われがちですが、基本的には各ハードウェア・ベンダー様に認定作業を実施頂き、認定をパスしたハードウェアの情報を頂戴して弊社が掲載しています。

話を元に戻しますが、このサイトの1つとして、CPU Series というページがあります。ここでは、ESXi の各バージョンがサポート対象としている CPU や、Fault Tolerant 機能がサポート対象としている CPU、また、世代の異なる CPU 間での vMotion をサポートする為の機能、Enhanced vMotion Compatibility (EVC) を確認する事ができます。

特に、EVC は既存環境に新たに ESXi を追加する際に、既存サーバに搭載されている CPU と新たに追加するサーバに搭載されている CPU 間で vMotion、もしくは、DRS (DRSは仮想マシンの再配置を行う際に vMotion を利用しています) の互換性があるか、また、互換性を持たせる為に設定すべき EVC モードは何かを確認する事ができます。

例えば、既存環境では、① Intel Xeon E5-2690 を搭載しているサーバを使用していて、②その環境に新たに Intel Xeon E5-2690 v4 を搭載しているサーバを追加したいとします。かつ、①と②の間で vMotion または DRS を利用したいとします。

①の Intel Xeon E5-2690 は、Intel Xeon E5-2600 Series、②の Intel Xeon E5-2690 v4 は、Intel Xeon E5-2600-v4 Series になりますので、CPU Series のページで、それらを選択します。

次に、”CPU / EVC Matrix” ボタンをクリックします。

その結果 (上記) から、Intel Xeon E5-2690 (Intel Xeon E5-2600 Series) と Intel Xeon E5-2690 v4 (Intel Xeon E5-2600-v4 Series) の EVC モードが、Intel® Sandy-Bridge Generation である事がわかります。ちなみに、赤枠で囲まれた “Intel Xeon E5-2600 Series” や “Intel Xeon E5-2600-v4 Series” をクリックすると、それぞれの CPU のコードネーム (Code Name) を確認する事もできます。

どうでしょう、一見難しい様に思える異なる世代の CPU 間の EVC モードの確認が簡単に行える事をご理解頂けたと思います。

最後まで読んで頂きありがとうございます。今回は以上となります。またの機会をお楽しみに。

The post ちょっとした技術的な TIPs のご紹介 appeared first on Japan Cloud Infrastructure Blog.

6回目：V4HでHorizon RDSホストの監視

– Back Number –
#1…最新のV4Hが使いやすくなっている！
#2…ビューの活用方法①
#3…ビューの活用方法②
#4…レポートの活用方法
#5…vRealize Log Insightとの連携
#6…V4HでHorizon RDSホストの監視

こんにちは、ソフトバンク コマース＆サービスの中川明美です。
今回は、番外編として、VMware vRealize Operations for Horizon (V4H)の「Horizon RDSホスト」の監視を取りあげます。なぜ追加で取りあげることになったのか？
RDSホスト(RDSH)を使用する環境で、V4Hのよさを伝えるためにはどうしたらよいかとご相談を受けたからです。その相談に回答するように、RDSHの監視のポイントをご紹介します。

◆V4Hでは何を監視する？
「最新のV4Hが使いやすくなっている！」でお伝えした通り、V4Hはセッションやログオン時間などユーザーに関連するデータを監視します。
RDS(リモートデスクトップサービス)は、セッションの仮想化(Server Based Computing)とも言いますから、RDSホストをV4Hで監視するのは適していますね。

◆SBC(Server Based Computing)とVDI(Virtual Desktop Infrastructure)の違いは？
左図がSBC、右図がVDIの違いを説明するイメージ図です。では、これらの環境を準備する目的は何でしょうか？
「OS/アプリケーションの運用管理コストを削減したい」「働き方変革に取り組みたい」というご要望から、OS/アプリケーションの仮想化が検討されます。そして、その環境をユーザーへ提供するための方法として、SBCまたはVDIが選択肢にあげられますね。

先の目的をふまえ、ユーザーがアプリケーションを使用するための接続先として、次の3つがあげられます。「仮想マシンベースのデスクトップ」「セッションベースのデスクトップ」「セッションベースのアプリケーション」です。この環境があれば、ユーザーは場所を意識することなく、業務を実施することができます。

VMware Horizon 6.x以降では、「セッションベースのデスクトップ」はRDSデスクトッププールで、「セッションベースのアプリケーション」はアプリケーションプールで構成します。RDS(リモートデスクトップサービス)はWindows Server 2008 R2以降から提供されているサービスです。それ以前はターミナルサービスと呼ばれていました。
そして、RDSのサービスの1つである「RDSホスト(RDセッションホスト)」が、ユーザーにデスクトップセッションとアプリケーションセッションを提供します。

各種プールをまとめます！

• 「手動/自動デスクトッププール」は、物理/仮想マシンが対象であり、デフォルトは1台のマシンに1人のユーザーがリモートアクセス可能です。「仮想マシンのデスクトップ」を提供する方法です。
• 「RDSデスクトッププール」はセッションが対象であり、RDSホストにおけるデスクトップセッションをユーザーに提供します。RDSホスト上のデスクトップセッションは複数のユーザーによる同時利用が可能です。
• 「アプリケーションプール」もセッションが対象であり、複数のユーザーにアプリケーション配布が可能です。アプリケーションは、ファーム内のRDSホスト上で実行されます。

RDS環境で、「OS/アプリケーションの仮想化」を運用管理する場合、セッションがポイントとなりますね！

では、V4Hの画面から、RDSに関するどんな情報が得られるのかを、ダッシュボードごとに確認します。

◆Horizon RDS プール
「Horizon RDS プール」タブでは、「ファーム」「RDSデスクトッププールと「アプリケーションプール」のセッション数を確認することが可能です。
ファームは、RDSホストの集まりです。ユーザーが接続すると、ファーム内のRDSホストが選択され、セッションが提供されます。ファーム内のRDSホストの数は、ロードバランスの可否や提供したいアプリケーションによって検討する必要があります。
下図では、ファーム内でデスクトップとアプリケーション(ここではInternet Explore)のセッションが1つずつ提供されています。RDSホストの最大セッション数(接続数)は、デフォルト150です。設定値を無制限にすることも可能です。設定値は、RDSホストのキャパシティに応じて決めることをお勧めします。V4Hを導入後、最適な値を設定するのも一つの方法です。

キャパシティを判断する際に参考になるのが、同じタブ内にある次の情報です。
ヒートマップの健全性、トップN のCPUワークロードやPCoIP遅延などのリソース状況です。この情報から、現在のキャパシティに適した接続数であるかを判断できますね。
ファーム内に複数のRDSホストが追加されている場合は、ロードバランス(負荷分散)されます。ユーザーに新規セッションが提供される際、ファーム内で利用可能なセッション数が多いRDSホストや、CPU/メモリの負荷が低いRDSホストが選択されます。リソースでのロードバランスは、事前にスクリプトを構成する必要があります。

https://pubs.vmware.com/horizon-7-view/index.jsp#com.vmware.horizon-view.administration.doc/GUID-54966EA2-8542-43B1-A5D4-60C8B21C0AC8.htm




◆Horizon RDS ホストの詳細
「Horizon RDS ホストの詳細」タブでは、各RDSホストの情報が得られます。
V4Hは同じデータの視点を変えて表示されます。RDSホストのキャパシティに関する情報はこちらのタブの方が多くを確認できますね。

また、ユーザーがどの程度リソースを使用しているかは、管理者にとって気になるところです。「RDSホストのプロセスとユーザー」では、「サーバーサービス」「サーバープロセス」「サーバーユーザー」のリソース使用状況を取得できます。下図は、「サーバーユーザー」を取得した画面ショットです。

「ユーザーリソース消費量」では、デスクトップセッションとアプリケーションセッションを別に確認することも可能です。

◆Horizon アプリケーション
「Horizon アプリケーション」タブでは、アプリケーションプールで構成したアプリケーションの状況を確認することができます。
左の「アプリケーションプール」では、アプリケーションのインスタンス数(起動数)と起動平均時間(秒)、相関関係の情報を得られます。「アプリケーションプールの関係」では、そのアプリケーションセッションを利用するユーザー名や提供するRDSホストが存在するファームの名前を確認することができます。

「アプリケーションインスタンス」では、アプリケーションセッションを提供するRDSホストの名前や、そのセッションのリソース使用状況を確認することができます。

◆セッション
最後に、セッションのカウント方法をご紹介します。接続するRDSホストの数=セッション数です。
たとえば、左図は複数のアプリケーションが1台のRDSホストで提供されているパターンです。アクセスするRDSホストは1台ですから、セッションは「1」です。
右図は、各アプリケーションが各RDSホストで提供されているパターンです。接続するRDSホストごとにセッションをカウントしますから、セッションは「2」です。

次は、ファームで提供するアプリケーションが異なるパターンです。これは上図のパターン2と同様の考え方です。アクセスするRDSホストは2台ですから、セッションは「2」です。セッション数のカウント方法はシンプルですね！

◆まとめ
V4Hでの監視対象はおもにユーザーセッション関連です。
仮想デスクトップもRDSHも、セッションやPCoIP遅延の情報を監視するのは同じです。異なるのは、基盤の部分です。
仮想デスクトップは1ユーザーにつき仮想マシンが1台提供され、RDSは複数のユーザーにRDSホストのセッションが提供されます。
vROpsは仮想マシンのリソース状況を監視しますね。V4Hは、vROpsで対象となる仮想マシンを、提供するサービスによって「仮想デスクトップ」や「RDSホスト」と呼び、セッション状況を監視します。
1ユーザーが使用する仮想マシン(仮想デスクトップ)のセッション/リソース状況を確認するのか、複数ユーザーが使用する仮想マシン(RDSホスト)のセッション/リソース状況を確認するのか、の違いです。
呼び方が変わる、機能がAdd-Onされると、複雑に感じますね。しかし、何を監視対象としているのかの区別がつけばシンプルになります。
アプリケーションの仮想化は、働き方改革により注目されていますね！
VMware Horizon環境下で、RDSHを使用する場合は、合わせてV4Hでの運用管理も検討いただければと思います。

ソフトバンクC&SのサイトでvROpsを使用した仮想化健康診断の事例を紹介しています。ここでは、「vSphere環境を運用管理している方が何に困っているのか」「その困ったことにパートナーのみなさまがどのようにアプローチされているのか」を載せています。インタビュー形式で構成しています。ぜひお仕事に役立つ情報を手に入れてください！

The post VMware vRealize Operations Manager (vROps) をパワーアップしよう！ パート2 appeared first on Japan Cloud Infrastructure Blog.

4回目：VMware NSX for vShield Endpointへの移行検証サマリー (パート2)

-Back Number-
#1_ vCloud Networking and Security (vCNS) の販売終了
#2_Deep Securityを実装するためのNSX
#3_ VMware NSX for vShield Endpointへの移行検証サマリー
#4_ VMware NSX for vShield Endpointへの移行検証サマリー(パート2)

こんにちは、ソフトバンク コマース＆サービスの中川明美です。
12月に投稿しました3回目ではvSphere 6.0環境下での移行方法をご紹介しました。
今回は、vSphere 5.5環境下での「vShield Endpoint(vCNS)からNSX for vShield Endpointへのアップグレード手順をご紹介します。vSphere 5.5からの移行を計画されている方はぜひご参考にしてください！
このBlogでは簡易手順を共有します。詳細手順をお知りになりたい方は、ページ下部でご紹介するURLからご入手ください。

◆構成図◆
下図は、Upgrade前の構成図と、Upgrade後の構成図です。
Upgrade前はvSphere 5.5 U1環境下でvShield Endpoint(vCNS)を使用、Upgrade後はvSphere 6.0 U2環境下でNSX for vShield Endpointへ移行します。
<Upgrade前>



<Upgrade後>



◆アップグレード手順◆
次の16ステップを進めます。

1.DSVA(Deep Security Virtual Appliance)の無効化/停止/削除

2.各ESXiホストから Filter Driverを削除

3.vShield Managerの停止

4.Deep Security ManagerとvCNS / vCenterサーバーの連携解除

5. vCenterサーバー / ESXiホスト のアップグレード

6.Horizon Viewのアップグレード

7. Deep Security ManagerのDBスキーマのアップグレード

8. Deep Security Manager のアップグレード

9. NSX Managerのデプロイ

10.Deep Security ManagerとNSXの連携設定

11.Guest Introspectionのデプロイ　※詳細手順では、仮想標準スイッチ使用時の注意点を追記

12.DSVA(Deep Security Virtual Appliance)のデプロイ ※詳細手順では、既知の問題について追記

13.Security Policy / Security Groupの作成等

14.対象VMを順次有効化

15. 新規VMの自動有効化設定

16.vShield Managerを削除 手順3で停止した、「vShield Manager」仮想マシンを削除
※画面ショットは手順3の画面

◆アップグレードの詳細手順◆
詳細手順をダウンロードできます。
https://app.box.com/s/5n62ebuw8c30yg5vzwki22g4qblwdp17

◆トラブルシューティングガイド◆
Deep Security + NSXのトラブルシューティングガイドをダウンロードできます。http://campaign.vmware.com/imgs/apac/jp_dwn/PDF/DSVA_9.5-6TroubleshootingTips_NSX.pdf?elqTrackId=9bc23ac857cc422897d92420f93dc17b&elqaid=979&elqat=2

◆まとめ◆
今回のBlogでは、vSphere 5.5環境でのアップグレード手順を共有いたしました。
今回のアップグレードは仮想基盤も含まれているため、事前にどのような手順で進めるのかを知ることは有益ですよね。詳細手順ではアップグレード中に認識できた注意点についても付記しています。こちらの手順をガイドに、工数の見積り、トラブルのない導入に活用いただけましたら幸いです。

The post VMware NSX for vSphereへの移行 appeared first on Japan Cloud Infrastructure Blog.

みなさん、こんにちは。VMwareでパートナー様を担当させて頂いてますSEの北村です。

今回は Cloud Infrastructure Blog に次の3つをTIPs として投稿したいと思います。

1. vSphere Replication の数の制限について
2. vSphere Replication と Site Recovery Manager を共に使用する場合の構成について
3. vSphere 5.x と 6.x の Products Offering の KB (Knowledge Base) 紹介

では、それぞれについて記載していきます。

1. vSphere Replication の数の制限について

vSphere Replication は、ハイパーバイザー ベースで仮想マシンのレプリケーションを行う vCenter Server の拡張機能です。ストレージ・アレイ・ベースのレプリケーションを代替する機能なため、弊社の Disaster Recovery ソリューションである、Site Recovery Manager と共に使用するケースが多いですが、vSphere Replication を使用してれ保護 (レプリケーション) できる仮想マシンの数には制限 (上限) がある事はご存知でしょうか？

Operational Limits for vSphere Replication 6.x (2102453)

上記のKBでその数の制限 (上限) について説明しています。KBの中には以下の表があり、この表から、1台の vCenter Server 環境で最大 2,000台の仮想マシンを保護することができ、その際に必要となる vSphere Replication Appliance は1台、vSphere Replication Server が9台である事がわかります。つまり、1台の vSphere Replication Appliance と、9台の vSphere Replication Server が、それぞれ 200台の仮想マシンの保護を担う事で、合計 2,000 台の仮想マシンの保護を可能としています。

では、vSphere Replication Appliance と vSphere Replication Server ですが、何が違うのでしょうか？

vSphere Replication Appliance には、以下の 2つの役割があります。

1. vSphere Replication Management Server：vCenter Server や vSphere Replication Server の構成と管理
2. vSphere Replication Server：データの受信と書き込み

vSphere Replicationを使用する環境に最初に展開される Appliance は①と②の機能を有しており、200台を超える仮想マシンを保護したい環境に追加で展開される Appliance は②の機能のみ有しているという違いがあります。そして、①と②の機能を有している Appliance を vSphere Replication Appliance、②の機能のみを有している Appliance を vSphere Replication Server と呼びます。

2. vSphere Replication と Site Recovery Manager を共に使用する場合の構成について

では、Site Recovery Manager と共に使用する場合、vSphere Replication Appliance とvSphere Replication Server は、保護サイトと災害対策サイトのそれぞれにどのように配置する事になるでしょうか？

1. まず、保護サイトと災害対策サイトの双方に vSphere Replication Appliance を展開します。
2. 次に、保護対象の仮想マシンの数が 200 台以上の場合、災害対策サイトに、200 台の仮想マシン毎に vSphere Replication Server を展開します。
3. 保護サイトから災害対策サイトへの片方向のレプリケーション構成の場合、受信側となる災害対策サイトだけにvSphere Replication Server を展開すればいいとなりますが、Site Recovery Manager と共に使用している DR (Disaster Recovery) システムとして考慮するならば、サイト・フェイルオーバ後のサイト・フェイルバックまでを想定した Appliance の配置をしておくのが一般的と言えますので、保護サイトと災害対策サイトの両サイトに同じ台数の vSphere Replication Server を展開しておく事を弊社としては推奨しています。
4. 尚、当然ですが、保護サイトと災害対策サイトが双方向のレプリケーション構成の場合は、両サイトに必要な数 (仮想マシン数に応じた) だけの vSphere Replication Server を展開する事になります。

例えば、500台の仮想マシンを vSphere Replication と Site Recovery Manager を使用して、片方向のレプリケーション構成としたDRシステムの場合、保護サイトと災害対策サイトに、それぞれ、1台の vSphere Replication Appliance と、2台の vSphere Replication Server を配置する、と言う事になりますので、図にすると以下のようなイメージになります。

3. vSphere 5.x と 6.x の Products Offering の KB (Knowledge Base) 紹介

皆さん、以下の KB はご存知でしょうか？

vSphere 5.x の各エディション (一部、キット) で提供されているる機能：

• 英語版　：Product offerings for vSphere 5.x (2001113)
• 日本語版：vSphere 5.x プロダクト提供 (2073973)

vSphere 6.x の各エディション (一部、キット) で提供されているる機能：

• 英語版　：Product offerings for vSphere 6.x (2109507)
• 日本語版：vSphere 6.x の各エディションにおける機能一覧 (2111426)

これらの KB は、それぞれ vSphere で利用可能な機能を一覧表にしていますが、“ある機能が、vSphere の、どのバージョン、どのエディション (一部、キット)” で利用できるのか、という事が解るようになっています。

ではどんな時に役に立つのかと言うと、例えば、次のような疑問を持った場合に上記の KB 参照する事で疑問を解決できます。

1. Storage vMotion はどのバージョンのどのエディション (キット) でサポートされている機能なのか？
2. vSphere Replication はどのバージョンのどのエディション (キット) でサポートされている機能なのか？
3. vSphere Fault Tolerance どのバージョンのどのエディション (キット) でサポートされている機能なのか？

KBから上記の 1 から 3 の答えは、それぞれ以下である事が解ります。

vSphere 5.x の場合；

1. vSphere 5.0 の Enterprise、Enterprise Plus と、vSphere 5.1 以降の Standard、Enterprise、Enterprise Plus でサポートされる機能です。
2. vSphere 5.1 以降の Essentials Plus と、vSphere 5.0 以降の Standard、Enterprise、Enterprise Plus でサポートされる機能です。
3. vSphere 5.0 の Enterprise、Enterprise Plus と、vSphere 5.1 以降の Standard、Enterprise、Enterprise Plus でサポートされる機能です。

vSphere 6.0 の場合；

1. vSphere 6.0 の Standard、Enterprise、Enterprise Plus でサポートされる機能です。
2. vSphere 6.0 の Essentials Plus、Standard、Enterprise、Enterprise Plus でサポートされる機能です。
3. vSphere 6.0 の Standard、Enterprise、Enterprise Plus でサポートされる機能で、サポートされる vCPU の数がエディションによって異なるので注意が必要です (Standard と Enterprise の場合は 最大で 2 vCPU、Enterprise Plus は最大で 4 vCPU の vCPU を搭載した仮想マシンを Fault Tolerance 化する事が出来ます)。

注) “Product offerings for vSphere 6.x (2109507)” と “vSphere 6.x の各エディションにおける機能一覧 (2111426)” に vSphere 6.5 に関する情報の追記を関係部門に依頼中 (2017年4月28日 (金) の時点)。

最後まで読んで頂きありがとうございます。今回は以上となります。またの機会をお楽しみに。

The post ちょっとした技術的な TIPs のご紹介 appeared first on Japan Cloud Infrastructure Blog.

日本ヒューレット・パッカード株式会社の中川明美です。

vSphere 6.0とvSphere 6.5の違いを尋ねられることが多くなりました。そのご質問に、こちらのBlogで回答します！

また、バージョンアップ時にプリセールスのみなさまからよくご質問をいただく内容をふまえ、vSphere 6.5の変更点をお伝えします。次の6回構成です。

#1: vCenter Sever Appliance_1　(コンポーネントおよびサービス / スケーラビリティ)

#2: vCenter Sever Appliance_2　(高可用性 / バックアップとリストア)

#3: 仮想ハードウェア Version 13 / VMware Tools Version 10.1

#4: 3つの管理ツール　(vSphere Host Client / vSphere Client / vSphere Web Client)

#5: vSphere HA (Proactive HA / ホスト障害への応答 / 仮想マシンで許容するパフォーマンス低下)

#6: vSphere DRS (Predictive DRS / その他のオプション)

1回目と2回目は、vCenter Server Applianceのアップデートについてです。併せてWindows版との違いも説明します。

■ vCenter Server Applianceに含まれるソフトウェア ■

vCenter Server Appliance 6.5は、下表のソフトウェアで構成されます。

6.5からPlatform Services ControllerとvCenter ServerはPhoton OS上で動作します。Project PhotonはVMwareがコンテナ向けにリリースした軽量Linux OSです。

Update ManagerはvCenter Server Appliance 6.5ではサービスとして提供されます。そのためインストール不要です。Windows版のUpdate Managerはコンポーネントとして提供されるため、従来通りインストールが必要です。

vCenter Server Appliance 6.5は仮想ハードウェアバージョン10 (ESXi 5.5以降でサポートされるバージョン) で提供されます。仮想ハードウェアバージョン10ですから、vCenter Server 6.5は、ESXi 5.5以降のホストまたはvCenter Server 5.5 以降のインスタンスのインベントリに含まれる ESXi ホストまたは DRS クラスタにデプロイできます。

～ハードウェアリプレース時～

ハードウェアリプレース時には、vSphereの移行方法(導入手順)に関わるため、最新のvCenter Serverの配下に既存のESXiホストが動作可能なのかをよく尋ねられます。

下図は、「VMware Product Interoperability Matrices」の画面ショットです。vCenter Server 6.5ではESXi5.5以降のホストを配置可能です。

■ vCenter Serverのコンポーネントとサービス ■

6.0と6.5で、「Platform Services Controller」と「vCenter Server」のコンポーネントがインストールされるのは変わりません。「Platform Services Controller」は6.0から提供されているコンポーネントです。

6.5で追加されたサービスは、Webブラウザを使用するvSphere ClientとUpdate Managerです。先に述べたとおり、Update ManagerはAppliance版に追加されます。

Syslog CollectorはWindowsと明記しているとおり、Windows OS上にインストールするサービスです。vCenter Server ApplianceでのLog収集はLinux OS に組み込みの Rsyslogサービスを使用します。

ESXiホストにLocalディスクを搭載しない場合は、トラブルシューティングのためにDump CollectorやSyslog Serverを別途準備しておく方がよいですね。

■ vCenter Serverのスケーラビリティ ■

vCenter Serverのキャパシティについてです。6.0と6.5では約2倍の差があります。

Appliance版とWindow版のデータベースにかかるコストで比較すると、ESXiホストを20台以上管理する場合、vCenter Server Appliance  6.5に分がありますね。

最大構成数は、パブリックのドキュメントを参照しています。

vCenter Server Appliance 6.5は上表から判断できるように、外部データベースをサポートしません。Window版でサポートしている外部データベースの詳細はこちらでご確認ください。

http://www.vmware.com/resources/compatibility/sim/interop_matrix.php#db

◆参考情報◆

ハードウェア要件とポート情報を付記します。

■ Platform Services Controllerのハードウェア要件 ■

規模に関わらず、2 個の vCPU と 4 GB メモリです。

■ vCenter Serverのハードウェア要件 ■

規模に合わせて、ハードウェア要件は異なります。Window版は最小推奨ハードウェア要件となりますから、vCenter Serverに同居するサービスによってメモリサイズを考慮した方がよいと思います。

■ Platform Services Controller アプライアンスのストレージ要件 ■

Platform Services Controller アプライアンスのストレージ要件は 60 GB です。

■ vCenter Server Applianceのストレージ要件 ■

このストレージ要件には、vCenter Server Appliance でサービスとして実行される vSphere Update Manager の要件も含まれています。インストール中に3つのストレージサイズを選択することが可能です。

■ Windows での vCenter Server および Platform Services Controller の最小ストレージ要件 ■

各フォルダの最小ストレージ要件は、インストール時のデプロイ モデルによって異なります。

■ vCenter ServerおよびPlatform Services Controllerに必要なポート ■

必要なポートはこちらで確認できます。

http://pubs.vmware.com/vsphere-65/index.jsp#com.vmware.vsphere.install.doc/GUID-925370DD-E3D1-455B-81C7-CB28AAF20617.html

◆まとめ◆

1回目は、Platform Services ControllerとvCenter Serverの概要についてでした。

プリセールスの方には必要なコンポーネントやハードウェア要件を、導入エンジニアの方には設定値レベルで必要な情報と思われるものをリストアップしました。

今後は、vSphere 5.5からvSphere 6.xにアップグレードされるお客様が増えてくるのではないかと思います。今回のテーマの5.5と6.xの違いは、vCenter Single Sign-OnがvCenter Serverコンポーネントに存在するか否かです。

6.5のアップデートでは、Enterprise Plusを前提とする機能も散見しますが、それらはパフォーマンスを改善する機能として提供されます。

2回目はvCenter Server Applianceの高可用性とバックアップです。お楽しみに！

The post ここが変わった！ VMware vSphere 6.5 Part1 appeared first on Japan Cloud Infrastructure Blog.

みなさん、こんにちは。VMwareでパートナー様を担当させて頂いてますSEの北村です。

今回は、Site Recovery Manager (SRM) のコンパチビリティに関連した次の2点について、Cloud Infrastructure Blog に投稿したいと思います。

1. SRM がサポート対象としている vCenter Server と ESXi のバージョンについて
2. SRM の Guest Operating System Customization Support について

では、それぞれについて記載していきます。

1. SRM がサポート対象としている vCenter Server と ESXi のバージョンについて

例えば、SRM 6.5 がサポートしている vCenter Server のバージョンは 6.5 ですが、SRM 6.5 がサポートしている ESXi のバージョンは、vCenter Server 6.5 がサポートしている ESXi と同じバージョンになります。 この事は、Compatibility Matrixes for VMware Site Recovery Manager 6.5 の vCenter Server Requirements と ESXi Server Requirements で確認できます。

ただし、SRM 環境で異なるバージョンの ESXi が混在している場合、仮想マシン・ハードウェア・バージョンなど、vSphere としての互換性が求められる場合があります。 つまり、SRM の保護サイトが vSphere 6.5 ( vCenter Server も ESXi もバージョンは 6.5) で、災害対策サイトが vCenter Server 6.5 と ESXi 6.0 の場合、仮想マシン・ハードウェア・バージョン 13 は、ESXi 6.0 ではサポートされませんので、この様なサイト間では、使用される仮想マシン・ハードウェア・バージョンは 11 より以前のバージョンである必要があります。 この様に、SRM 環境においては、保護サイトと災害対策サイトの 2つのサイトを 1つのシステムとして考える必要があります。

参考情報：Virtual machine hardware versions (1003746)

図1：SRM 6.5 ドキュメント ページ

図2：Compatibility Matrixes for VMware Site Recovery Manager 6.5 ページ

SRM の Compatibility Matrixes は、それぞれの SRM のバージョン毎に存在しています。 上記、図1は最新バージョンの SRM 6.5 のドキュメント ページです。 オレンジ色で囲われている “Site Recovery Manager 6.5 の互換性マトリックス” をクリックすると、図2の SRM 6.5 の Compatibility Matrixes のページが表示されます (他の SRM のバージョンでも同様です)。 Compatibility Matrixes のページは英語表記のみでの提供となっています。

2. SRM の Guest Operating System Customization Support について

SRMでは、仮想マシンの IP 設定をカスタマイズする機能を提供しています。この機能を使う事で、仮想マシンが災害対策サイトで起動されるときに、今まで使用していた保護サイトの IP 設定を災害対策サイトの IP 設定に上書きする事ができます。この事を “SRM のゲスト OS の IP カスタマイズ” と、言ったりするのですが、このカスタマイズのサポート対象となるゲストOSのマトリックスを公開しています。

図3：Compatibility Matrixes for VMware Site Recovery Manager 6.5 ページの プルダウンメニュー

図3の SRM 6.5 の Compatibility Matrixes のページで、プルダウンメニューから Guest Operating System Support を選択すると、次の図4のページが表示されます。

図4：SRM 6.5 Compatibility Matrixes ページ

このページ (図4) で、SRM 6.5 でサポート対象となる Guest Operating System Support と Guest Operating System Customization Support について説明していますが、Guest Operating System Customization Support の中で、SRM のゲスト OS の IP カスタマイズのサポート対象を PDF：VMware Guest OS Customization Support Matrix で公開しています。

また、仮想マシンによっては、複数の IP アドレスが割り当てられている場合がありますが、”SRM のゲスト OS の IP カスタマイズ“ としてサポートされる構成について、KB (Knowledge Base) を公開しています (英語のみ)。

以下は SRM 6.5 の KB になりますが、SRM 5.8 以降、Operational Limits for Site Recovery Manager X.X (X.X は、5.8、6.0、6.1、または、6.5) という KB を公開しています (KB のサイト で “Operational Limits for Site Recovery Manager” というキーワードで検索すると、他の SRM のバージョンの KB も検索結果から参照できます)。

Operational Limits for Site Recovery Manager 6.5 (2147110)

上記 KB 内で、IP Customization Maximums for Site Recovery Manager 6.5というセクションに記載されている内容 (以下はその抜粋) がサポートされる構成となります。

=== KB2147110 より抜粋 ===
IP Customization Maximums for Site Recovery Manager 6.5
If you implement IP customization for recovered virtual machines, you can configure a maximum of one IP address for each NIC, using DHCP, static IPv4, or static IPv6. For static IPv4 or IPv6 addresses, you provide the following information per NIC:
・1 IP address
・Subnet information
・1 gateway server address
・2 DNS servers (primary and secondary)
====================

上記、KBのポイントは、「仮想マシンの個々 (複数) の vNIC に、それぞれ 1つの IP アドレスが割り当てられている構成がサポートされる構成」 という点です。

似ている構成として、「仮想マシンの 1つ vNIC に複数の IP アドレスが割り当てられている構成」 も考えられますが、以下の KBで公開されている通り、この構成は、SRM の IP カスタマイズではサポートされませんので、ご注意ください。

Can I use multiple IP addresses mapping to a single NIC with vCenter VMware Site Recovery Manager’s IP customization? (2129186)

今回触れた SRM の Compatibility Matrixesですが、日々の活動の中で、意外と存在を知られていない、と感じる事が続いた為、今回はこの件をピックアップしてブログにさせて頂きました。

最後まで読んで頂きありがとうございます。今回は以上となります。またの機会をお楽しみに。

The post ちょっとした技術的な TIPs のご紹介 (2017.05) appeared first on Japan Cloud Infrastructure Blog.

□ご紹介

vSANは、最も重要なワークロードを稼働させる信頼性の高いインフラとして、7000社を超えるお客様に使われ、現在も成長を続けています。この流れをさらに促進させるべく、VMwareはパートナー様と連携し、次世代ハードウェアにいち早く対応させることを明言しています。
コンポーザブルインフラストラクチャはお客様が採用を検討する次世代プラットフォームであり、vSANとして初めて認証を受けた最初のコンポーザブルインフラストラクチャであるHPE Synergyを発表できることは非常に光栄です。これは、我々の成熟したお客様が稼働させる従来のアーキテクチャのワークロード、および次世代のワークロードにとって非常に画期的な位置づけの製品です。
HPE Synergyの構成詳細については、以下vSAN VCG（VMware Compatibility Guide）を参照下さい。
AF-6：http://www.vmware.com/resources/compatibility/detail.php?deviceCategory=vsan&productid=41543&deviceCategory=vsan&details=1&vsan_type=vsanreadynode&page=1&display_interval=10&sortColumn=Partner&sortOrder=Asc
AF-4
http://www.vmware.com/resources/compatibility/detail.php?deviceCategory=vsan&productid=41542&deviceCategory=vsan&details=1&vsan_type=vsanreadynode&page=1&display_interval=10&sortColumn=Partner&sortOrder=Asc

□従来のHCIとコンポーザブルHCI

コンポーザブルインフラストラクチャの定義については、次のセクションにて記載をします。しかしその前に、基本的なご質問として良く聞かれるのが、“コンポーザブルインフラストラクチャはHCIとして使用することができるのか？”です。答えは“Yes”です。

基本的な違いは、コンポーザブルインフラストラクチャでは“コンピューティング”と“ストレージ“が構成要素として分かれていることです。従来のHCIは、インフラの成長に合わせて”コンピューティング“と”ストレージ“を一緒に拡張させていました。しかし、ワークロードに対してより柔軟に対応していかなければいけません。HCIの恩恵を維持するためには、”コンピューティング“および”ストレージ“からの要求に対して個別にスケールアウトさせていく必要があります。コンポーザブルインフラストラクチャはHCIの世界でそのような考えを実現するための構成要素です。

□コンポーザブルインフラストラクチャとは？

コンポーザブルインフラストラクチャは、3つの要素（ソフトウェアで定義する仕組み、流動的なリソースプール、統合されたAPI）から構成されています。流動的なリソースプールとは、変化する各アプリケーションの要求に対して、構成要素として分かれている“コンピューティング”、“ストレージ”を柔軟に組み合わせるために必要な要素です。そしてソフトウェアで定義する仕組みとは、自動化（サーバやストレージの仮想化）をより促進することによってIT管理者の運用管理をシンプルにしていきます。最後に、統合されたAPIにより、サイロ化された運用を統合し複雑さを排除する単一の管理インターフェースを提供します。このインフラによって年に1-2回程度のインフラストラクチャのアップデート等が発生した際にも、継続的なサービス提供と、アプリケーションの展開を手助けすることができるようになります。

□HPE Synergy

HPE Synergyとは、フレームと呼ばれる10Uのボックスで、12個のハーフサイズのモジュラーを搭載、もしくは6個のフルサイズのモジュラーを構成するベイが存在しています。これらのベイは、最大12台のサーバを搭載可能であり、最大4台のストレージモジュールを搭載することも可能となっています。さらに、ストレージモジュール毎に最大40のSFF（スモールフォームファクタ）ドライブベイを持っています。
以後のセクションで、vSAN視点におけるHPE Synergyの構成について見ていきたいと思います。

□なぜvSANとSynergyを組み合わせるのか？

HPE Synergyは、今までの HPE BladeSystemからの進化と、柔軟に構成を組めるコンポーザブルインフラストラクチャーの第1弾であり、ここで詳細を学ぶことができます。
https://h20195.www2.hpe.com/V2/GetDocument.aspx?docname=A00006129ENW
それ以外にも、HPE Synergyがもたらす主要な利点がありますが、それらはvSANと組み合わせることによって実現可能となっています。

□分離されたストレージとコンピューティング

ビジネスはより動的になってきており、事前に計画し、必要なワークロードを予測することは困難です。企業は、動的に拡張できるプラットフォーム（コンピューティングとストレージの両方）を求めています。このプラットフォームの最大の利点はストレージとコンピューティングが独立して拡張できることです。

選択された構成シナリオ（以下のHPE SynergyのおけるvSAN展開の選択肢のセクションで説明します）では、単一のHPE Synergyフレームは、最大80 SFF（2.5インチ）ドライブまたは最大10台のコンピューティングサーバーを保持できます。

小規模(3台のコンピューティングサーバと1台のストレージモジュールを部分的に搭載)から始めて、ワークロードに応じて、コンピューティングまたはストレージを追加することができます。

これは今日のビジネス環境において大きな利点です。オーバープロビジョニングを避けることによって先行的な投資を最小化するだけでなく、必要に応じた拡張を可能にする柔軟性を提供します。例えば新しいワークロードがコンピューティングのみを要求する場合は、フレーム内でコンピューティングモジュールを拡張することができます。
実際には、単一のフレーム（筐体）内に最大40台のドライブを搭載した10ノードのvSANクラスタを構築し、ビジネス需要の増加に応じてフレームを追加することで拡張できます。

任意のワークロードに対する単一のインフラストラクチャ：

エンタープライズ企業では、従来のインフラストラクチャで従来のアプリケーションを稼働させ、新しいクラウドネイティブアプリケーションやモバイルアプリケーション等の次世代アプリケーション用途として異なるインフラストラクチャとツールで作り上げる戦略を採用することが期待されています。
しかし、vSANは、従来および次世代のアプリケーション用途として稼働しています。我々はお客様との話し合い、vSANの導入状況を把握することで、日々学んでいます。次の図は、お客様がvSAN環境で実行しているユースケースを表しています。

ここから、vSANは「バイモダルコンピューティング」（従来および新世代のワークロード）に対応すべきである、という事が明確に分かります。
HPE Synergyのアーキテクチャと管理ソリューションは、従来のビジネスアプリケーションと新しいビジネスアプリケーションの両方に対応し、企業が単一のインフラストラクチャでvSANユースケースを実行できるよう支援します。

フレーム間の高速インターコネクト：

HPE Synergyは同じ論理エンクロージャー・サーバー内のフレーム間のイーサネット接続にマスター・サテライト・トポロジーを使用しているため、サーバーのデータ・トラフィックは、トップ・オブ・ラックで導入された環境下でも – 異なるサーバーのフレーム間でも – レイテンシを発生させずに最大20Gbpsの高速イーサネット接続を提供できます。

□なぜ Synergy は vSAN に適しているのか？

HPE Synergyとは：フレームが コンピューティング、ストレージ、ファブリック、冷却、電力、およびスケーラビリティのリソースをプールするインフラストラクチャです。
フレーム内の重要な要素の1つは、ローカルディスクストレージが単一フレーム内でのみアクセス可能であることです。これは、フレーム内のサーバに対して全てのディスクを割り当てる必要があることを意味します。vSANの基本は、ホスト（ESXi）で使用可能な全てのローカルストレージディスクを、全てのサーバが共有する単一のデータストアに集約することです。
従来のラックサーバの場合、コンピューティングとストレージは独立して拡張されません。
しかし、HPE Synergyでは、ストレージを拡張して別々に計算することで、集約を実現できます。これにより、vSANなどのHCIソリューションに最適といえます。

HPE SynergyのおけるvSAN展開の選択肢:

単一フレーム内のHPE SynergyプラットフォームでvSANを構成、および複数のフレームを跨いでvSANを構成し、かつコンピューティングとストレージを構成するなど、方法は数多くあります。実際に選択肢はほぼ無限大です。

しかし、vSANの配備の観点から、1つのフレーム内に3つの基本的な構成（完全集約化）でのみ展開頂くをご提案しています。
※以下に記載のあるSATAとは、HDDを指しているのではなく、SATA インターフェースで接続されたSSD を指しています。
※vSANで認定された ディスクは 「SAS SSD」「SATA SSD」「SAS HDD」「Nearline SAS」 の4種類です。

1xストレージモジュール{D3940（12ドライブ）}と3x Compute Servers {SY 480}ハーフハイトサーバーを備えた1つのフレーム：

これらのコンピューティングサーバーのそれぞれは、1つのディスクグループ内に4つのドライブ（1つのキャッシュ+ 3つのキャパシティ）をサーバーごとに構成しています。最適な選択は、SASドライブをキャッシュ層として、SATAドライブをキャパシティ層として使用することです。

2つのストレージモジュール{D3940（80ドライブ）}と8×Compute Servers {SY 480}ハーフハイトサーバーを備えた1つのフレーム：

これらのコンピューティングサーバーは、グループ毎に2つのディスクグループ（1つのキャッシュ+ 4つのキャパシティ）の計8つのドライブが構成されています。最適な選択は、SASドライブをキャッシュ層として使用し、SATAドライブをキャパシティ層として使用することです。

1xストレージモジュール{D3940（40ドライブ）}および10x Compute Servers {SY 480}ハーフハイトサーバーを備えた1つのフレーム：

これらのコンピューティングサーバーは、1台のサーバーにつき1つのディスクグループとして4つのドライブ（1つのキャッシュ+ 3つのキャパシティ）で構成されています。最適な選択は、SASドライブをキャッシュ層として、SATAドライブをキャパシティ層として使用することです。
SynergyでのオールフラッシュvSAN構成での3つの展開例として、以下の表を参考にしてみましょう。

単一フレーム内でのvSAN構成例
もう一度繰り返しますが、vSANを構成するには初めに3台のコンピューティングサーバーが必要です。上記は、単一フレーム内での構成例です。この新世代のハードウェアがさらに普及するにあたり、ユーザーが望むその他構成について更に考えていきます。

HPE SynergyとHPE BladeSystemとの比較：

HPEサイトには素晴らしい文書があり、ここで読むことができます。しかし、私はここでの比較で紹介したいと思います：

□どのような導入事例がHPE Synergy にはないのでしょうか？

HPE Synergyは単一のインフラストラクチャとして多くのユースケースをカバーしていますが、現時点でHPE Synergyに向かない用途もあります。

1. ストレージモジュールでNVMeドライブが必要なアプリケーション：

ストレージモジュールにNVMeデバイス並みのパフォーマンスを必要とするニッチなワークロードが存在する可能性があります。
今日のHPE Synergyプラットフォームは、ネイティブPCIeの代わりにSASインターフェイスを使用しているため、ストレージモジュール上でNVMeをサポートしていません。
ただし、HPE Synergyは、vSANのキャッシュ層デバイスとして使用される可能性のあるサーバーモジュールでNVMeサポートを提供しています。

2.大容量のDASストレージ：

ご存知のように、3.5 “ドライブは2.5″ドライブより容量が大きいです。現在のHPE Synergyストレージモジュールは3.5 “ドライブをサポートしていません。
ワークロードとして大容量ストレージを必要とし、パフォーマンスを必要としないDAS指向アプリケーションがいくつかあります。

このような場合、Synergyは最もコスト効率の高いストレージソリューションを提供しない可能性があります。パフォーマンスと高密度ストレージの両方を必要とするアプリケーションであれば、Synergyは依然としてそのようなワークロードに最適なプラットフォームです。

まとめ：

組織がこの新世代のプラットフォームを採用して従来のアプリケーションや次世代のアプリケーションを稼働させるにあたり、VMwareは、HPEさんのようなパートナー様と密接に連携して、vSANの有効性を証明していきます。

HPE Synergyは、ストレージとコンピューティングを分割して管理する最適なHCIを提供することで、お客様は要求に基づいて環境を成長させることができます。

vSANハードウェアに関するご質問は、vsan-hcl@vmware.comまでお問い合わせください。

The post HPE Synergy – 最初のコンポーザブル インフラストラクチャー (HCI) – vSAN on Synergy の構成が認証されました appeared first on Japan Cloud Infrastructure Blog.

日本ヒューレット・パッカード株式会社の中川明美です。

今回はvSphere 6.5から提供される、「vCenter Server Appliance の高可用性」と「vCenter Server ApplianceとPlatform Services Controllerアプライアンスのファイルベースのバックアップとリストア」についてご紹介します。

#1: vCenter Sever Appliance_1　(コンポーネントおよびサービス / スケーラビリティ)

#2: vCenter Sever Appliance_2　(高可用性 / バックアップとリストア)

#3: 仮想ハードウェア Version 13 / VMware Tools Version 10.1

#4: 3つの管理ツール　(vSphere Host Client / vSphere Client / vSphere Web Client)

#5: vSphere HA (Proactive HA / ホスト障害への応答 / 仮想マシンで許容するパフォーマンス低下)

#6: vSphere DRS (Predictive DRS / その他のオプション)

vCenter Server停止時の影響範囲は？

VMware製品に初めて関わる方からは、vCenter Server停止時の影響範囲についてよく質問されました。プリセールス時には可用性も含めて提案しますから気になりますね。

最近はvCenter Server停止時の質問は減りましたが、復習をかねて影響範囲について確認しましょう。

vCenter Serverが停止して困るのは、vCenter Serverが提供している機能を使用できない時です。たとえば、仮想マシンのクローン作成やvMotion(仮想マシンの移行)を行う時です。

vSphere HAや分散スイッチは、新規作成や設定変更時にはvCenter Severが稼働している必要があります。しかし機能の継続には支障ありません。vSphere HAや分散スイッチは、ESXiホスト側で管理する仕組みを持っているからです。

最近の質問は、「vCenter Single Sign-Onサービスが停止したら、vSphere Web ClientからvCenter Serverにログオンできなくなるの？」です。次から次へと疑問は尽きませんね。

Platform Services Controller (PSC) の可用性

こちらのBlogでは、vCenter Serverの可用性を中心に進めます。vCenter Single Sign-Onサービスを含むPSCの可用性については、組み込みのPSCか外部のPSCを選択するかで方法が異なります。組み込みのPSCはvCenter Serverを保護すれば同時にPSCも保護されます。

外部のPSCの可用性については、こちらをご確認ください。

http://pubs.vmware.com/vsphere-65/index.jsp#com.vmware.psc.doc/GUID-62CC201A-01ED-4116-8604-FF123481DAFC.html

ｖCenter Server の可用性

vCenter Serverを長く停止させるわけにはいけませんから、少しでもダウンタイム (サービスの停止時間) を短くする方法を検討する必要があります。

vCenter Serverの可用性については、いくつかの方法が提供されてきました。シンプルな方法として選択されてきたのはvSphere HAですね。

vSphere 6.5では、vCenter Server Applianceを対象に、「vCenter High Availability」が追加されました。ハードウェア障害からの保護だけではなく、 パッチ適用などサービスを停止しなければならない際にダウンタイムの短縮に役立ちます。

<補足情報>

vSphere 6.0のドキュメントになりますが、vSphere HAとMicrosoft Cluster Serviceで構成するvCenter Serverの可用性についてまとめられています。参考にしてください。

http://pubs.vmware.com/vsphere-60/index.jsp#com.vmware.vsphere.vcenterhost.doc/GUID-4A626993-A829-495C-9659-F64BA8B560BD.html

以下はvCenter Server の高可用性に関する VMware の KBです。こちらも参考にしてください。

-英語版-
Supported vCenter Server High Availability Options
https://kb.vmware.com/kb/1024051

-日本語版-
サポート対象の vCenter Server 高可用性オプション
https://kb.vmware.com/kb/2089839

vCenter High Availability

vCenter HAは3つのvCenter Server Applianceインスタンスから構成します。

1つ目のインスタンスは、Activeノードとして使用されます。Activeノードのクローンが2回作成され、Passiveノードと監視ノード用に構成されます。

Activeノードに障害が発生すると、自動的にPassiveノードに役割を引き継ぎます。監視ノードはクォーラムを提供し、スプリットブレインの状態から保護します。

vSphere 6.5から提供される機能ですから、ESXiホストも6.5で構成できればよいですね。

vCenter HAのハードウェア要件とソフトウェア要件はこちらをご確認ください。

http://pubs.vmware.com/vsphere-65/index.jsp#com.vmware.vsphere.avail.doc/GUID-8FD87389-8CC9-4298-8B08-A1526FB44524.html

設定方法はシンプルです。下図のウィザードにあるように、vCenter HAネットワーク用のIPアドレスを設定します。環境に応じて、「Passive」と「監視」の仮想マシンをどのESXiホスト、どのデータストアに配置するかを指定します。事前にESXiホスト上にvCenter HAネットワーク用のポートグループを作成しておく必要があります。

vCenter Server ApplianceおよびPlatform Services Controllerアプライアンスのバックアップ

vSphere 6.0から、vSphere Data Protectionを使用して、vCenter Server、vCenter Server Applianceまたは Platform Services Controller を含む仮想マシンのイメージベースのバックアップができるようになりましたね。vCenter Serverを、vSphere Data Protection アプライアンスが実行されているESXi ホストに直接緊急リストアできることは特徴の一つです。

<補足情報>

vSphere Data ProtectionはｖSphere 6.5が最後の提供となります。

https://blogs.vmware.com/partnernews/2017/04/vsphere-dp-eol.html

vSphere 6.5 では、vCenter Server Appliance 管理インターフェイスを使用して、vCenter Server Appliance と Platform Services Controller アプライアンスのファイルベースのバックアップを提供します。バックアップはvCenter Server Appliance 管理インターフェイスを、リストアはvCenter Server Applianceの GUI インストーラを使用します。

< vCenter Server Appliance 6.5のバックアップ>

vCenter Server Appliance 管理インターフェイス (https://vCetner Server ApplianceのFQDN or IPアドレス: 5480) を使用してバックアップします。

バックアップデータは、指定したリモート システム(たとえばFTPサーバー)に、HTTPS/ HTTP/ SCP / FTPS/ FTPのいずれかを使用してストリーミングされます。

< vCenter Server Appliance 6.5のリストア>

リストアは、次の2つの手順で実施されます。

1. vCenter Server Appliance 6.5 Installerでovaファイルのデプロイ
2. vCenter Server Appliance 管理インターフェイスでバックアップデータの転送

１の手順でovaファイルのデプロイ完了後、 vCenter Server Appliance 管理インターフェイスへリダイレクトされ、2の手順のリモートシステムにあるデータを、新しくデプロイされた vCenter Server Appliance にコピーします。

リストア後、vCenter Server Applianceと Platform Services Controller アプライアンスのデプロイタイプにより、スクリプト /usr/bin/vcenter-restore を実行します。

詳しくは、こちらをご確認ください。

http://pubs.vmware.com/vsphere-65/index.jsp#com.vmware.vsphere.install.doc/GUID-67C7D3ED-2A52-4960-95EC-03C4EE3F5E34.html

◆まとめ◆

今回は、ｖSphere 6.5で提供された、vCenter HAとvCenter Server Appliance と Platform Services Controller アプライアンスのファイルベースのバックアップをとりあげました。

可用性については、vSphere HAを選択するべきか、vCenter HAを選択するべきか。

vSphere HAはDRSの非アフィニティルールと構成することを推奨しています。vCenter HAはESXiホストが3台以上およびDRSを構成することを推奨しています。ｖSphere HAもｖCenter HAも1つのvCenter ServerライセンスとｖSphere Standardのライセンスで構成可能です。DRSを使用するならvSphere Enterprise Plusのライセンスが必要です。

どちらの機能を選択し、どのように設計(構成)するかは、運用コストの費用対効果を考慮する必要がありますね。

Windows版のvCenter Serverの場合は、vSphere HAまたはMicrosoft Clustering Serviceのどちらかを検討することになります。

次にバックアップですが、サードパーティ製品を使用して仮想マシンのバックアップを取られていることが多いと思います。コスト面からvSphere Data Protection を検討されていた方もいらっしゃるかと思いますが、先に述べたようにvSphere 6.5が最後のリリースとなりますからご注意ください。

vCenter Server Applianceをご使用であれば、正常に動作するアプライアンスを復元できるようにバックアップデータを取りますから、こちらもお勧めかもしれません。

次回は仮想ハードウェア Version 13  VMware Tools Version 10.1ついてご紹介します。

The post ここが変わった！ VMware vSphere 6.5 Part2 appeared first on Japan Cloud Infrastructure Blog.

日本ヒューレット・パッカード株式会社の中川明美です。

今回は、vCenter ServerやESXiホストをアップグレードする際に、アップグレードの可否が検討される「仮想ハードウェア」と「VMware Tools」についてご紹介します。

現在設定されているバージョンが仮想マシンの継続稼働に問題があるのか、最新バージョンにアップグレードしたらどんなメリットがあるのかを知っておくことは、大事なポイントであると思います。

また、仮想ハードウェアのアップグレード時には仮想マシンを再起動するダウンタイムが発生します。「いつ」「誰が」実施するのかも考慮する必要がありますね。

#1: vCenter Sever Appliance_1　(コンポーネントおよびサービス / スケーラビリティ)

#2: vCenter Sever Appliance_2　(高可用性 / バックアップとリストア)

#3: 仮想ハードウェア Version 13 / VMware Tools Version 10.1

#4: 3つの管理ツール　(vSphere Host Client / vSphere Client / vSphere Web Client)

#5: vSphere HA (Proactive HA / ホスト障害への応答 / 仮想マシンで許容するパフォーマンス低下)

#6: vSphere DRS (Predictive DRS / その他のオプション)

◆仮想ハードウェアバージョン13◆

ｖSphere 6.5で提供される最新の仮想ハードウェアバージョンは、「13」です。

下表は、「13」から提供される機能です。これらの機能は、「仮想マシンに ESXi 6.5 以降との互換性(仮想ハードウェアバージョン13)が設定されている」こと、「サポートするゲスト OS が仮想マシンにインストールされている」ことが前提です。

※仮想ハードウェアはESXiホストで使用できる物理ハードウェアに対応します。仮想ハードウェアバージョン13では最大6TBのメモリをサポートします。しかしESXiホストに6TBの物理メモリが搭載されていなければ、仮想マシンに割り当てることはできません。

仮想ハードウェアもアップグレードしなければならないの？

たとえば下図のように、ｖCenter Server 5.5をｖCenter Server 6.5へ、vSphere ESXi 5.5の一部をvSphere ESXi 6.5へアップグレードした例を使い、仮想ハードウェアバージョンのアップグレード可否について確認します。ここではあえてこの構成にしています。

アップグレードしない場合 (仮想マシンの互換性を変更しない)

構成例ではESXiホストのバージョンが5.5と6.5の混在環境のため、仮想マシンの互換性は古いESXiホストとの互換性を維持するために、「ESXi 5.5以降以降 (ハードウェアバージョン 10)」を選択します。言い換えると、仮想マシンの互換性は変更せず、仮想マシンの稼働を継続します。

仮想マシンの互換性を「ESXi 6.5以降」に変更すると、その仮想マシンをESXi 5.5または6.0  ホスト上で実行することができません。たとえば、仮想マシンの互換性が「ESXi 6.5以降」である仮想マシンを、ESXi 5.5ホストへ移行することができません。

また、すべてのESXiホストが6.5であったとしても、最新の仮想ハードウェア機能を使用しないのであれば、必ずしも最新の仮想ハードウェアバージョンを選択する必要はありません。

私はESX 4.0 ホスト上で作成した仮想マシンをovfファイルにエクスポートし、新しいバージョンのESXi ホスト上で継続的に使用したことがあります。これは互換性により可能となります。

vSphere ESXi 6.5では、仮想マシンの互換性に、「ESX/ESXi 4.0 以降 (ハードウェアバージョン 7) 」を選択できます。これは仮想ハードウェアバージョン 7以降の仮想マシンを、ESXi 6.5ホスト上に配置できることも意味します。

VMware製品、ストレージやネットワークベンダーから提供されるovfファイル (仮想アプライアンス) は、互換性を考慮し「ESXi 5.0以降 (ハードウェアバージョン 8) 」で提供されているのを見かけますね。

アップグレードする場合 (仮想マシンの互換性を最新の「ESXi 6.5以降」に変更する)

6.5で提供される最新の仮想ハードウェア機能を使用したい場合は、すべてのESXiホストを6.5で構成し、仮想マシンの互換性に「ESXi 6.5以降」を選択します。

仮想マシンの互換性のデフォルト値

ESXi 6.5ホスト上で新規に作成する仮想マシンの互換性は「ESXi 6.5以降」が選択されます。

互換性のデフォルト値は仮想マシンを作成する ESXi ホストのバージョンによって決まります。デフォルトの互換性の設定値をESXiホストのバージョンとは異なる値にしたい場合には、こちらを参照ください。

http://pubs.vmware.com/vsphere-65/index.jsp#com.vmware.vsphere.vm_admin.doc/GUID-FD9DC4FF-4420-4FCA-AEF4-6E19AFF869F5.html

◆VMware Tools バージョン10.1.x◆

vSphere 6.5 に付属している VMware Tools のバージョンは 10.1です。10.1はメジャーリリースで、2017年5月18日に10.1.7がリリースされています。

最新のゲスト OS はVMware Tools 10.1.xに対応し、レガシー ゲスト OS はVMware Tools 10.0.12 に対応します。

VMware Tools 10.1.xでサポートされるゲスト OSです。

VMware Tools 10.1で提供されている機能です。

VMware Toolsもアップグレードしなければならないの？

仮想ハードウェアと同様にVMware Tools も最新バージョンへのアップグレードは必ずしも必要ではありません。VMware Tools の新しいバージョンは、複数のホ ストのバージョンと互換性があります。追加された機能や性能が環境にとって必要かどうかを検討後、実行ください。

下図は互換性リストの一部です。

◆仮想マシンのアップグレードのダウンタイム◆

仮想マシンをアップグレードする時、必要なダウンタイムはゲスト OS と実行するアップグレードの種類によって異なります。VMware Tools のアップグレードから開始します。

Linux ゲスト OS の多くは、VMware Tools の現在のバージョンではアップグレード後の再起動が不要です。以前のバージョンでは、「PVSCI」「VMXNET」「VMXNET3」ドライバのアップグレード後にゲスト OS を再起動する必要があります。

◆参考◆

1. ESX/ESXiホストでサポートされる仮想ハードウェアはこちらのKBを参照ください。
   Hardware features available with virtual machine compatibility settings (2051652)

2. ESXi 6.5ホストでバンドされないVMware Tools ISOイメージは、My VMwareからダウンロードできます。バンドルされていない、特定のオペレーティング システム用の VMware Tools をダウンロードする場合は、VMware Tools 10.1.0 リリース ノートなどに記載されている手順を参照ください。

3. ESXiホストのバージョンに関係なく、最新のVMware Tools をインストールまたはアップグレードする方法についてはこちらのKBを参照ください。
   Installing and upgrading the latest version of VMware Tools on existing hosts (2129825)
   こちらのVMware vSphere Blogはコメントも含め参考になります。
   https://blogs.vmware.com/vsphere/2015/09/vmware-tools-lifecycle-why-tools-can-drive-you-crazy-and-how-to-avoid-it.html
   ※ESXi 6.5ホストにバンドルされる3つのISOイメージです。

4. 仮想マシンのアップグレードについては、こちらのドキュメントを参照ください。
   https://docs.vmware.com/jp/VMware-vSphere/6.5/com.vmware.vsphere.vm_admin.doc/GUID-EE77B0A9-F8FF-4785-BEAD-B6F04EE04492.html

◆まとめ◆

今回は、最新の「仮想ハードウェア」と「VMware Tools」をご紹介しました。

本文内では、仮想マシンのアップグレードは必ずしも必要ではないと述べていますが、アップグレードすればパフォーマンスや運用の利便性を向上する機能を使用できます。ダウンタイムを考慮し、仮想マシンのアップグレードを検討いただけたらと思います。

ダウンタイムは仮想ハードウェアのアップグレード時には必ず発生しますから、「仮想マシンの互換性アップグレードのスケジュール設定」やUpdate Managerを利用して計画的に進めることをお勧めします。

今回のBlogを書くにあたり、あらためて「仮想ハードウェア」と「VMware Tools」について調べてみました。KBやドキュメントを読むと、新たな発見があり、とても楽しかったです。

お時間が許せば、参考にあげているKBやドキュメントもぜひ参照いただければと思います。

次回は、vSphere 6.5で使用する管理ツールについてご紹介します。

The post ここが変わった！ VMware vSphere 6.5 Part3 appeared first on Japan Cloud Infrastructure Blog.