Cisco HyperFlex HX シリーズ
著者：Robert Quimbey
Cisco HyperFlex™ システムでは、ハイパーコンバージド システムが持つ力を最大限に活用できます。エンドツーエンドのソフトウェア定義型インフラをベースとしており、Cisco Unified Computing System™（Cisco UCS®）サーバによるソフトウェア定義型コンピューティングや、強力な Cisco HyperFlex HX データ プラットフォームを利用したソフトウェア定義型ストレージが統合されています。また、Cisco® アプリケーション セントリック インフラストラクチャ（Cisco ACI™）ソリューションとスムーズに統合する、Cisco UCS ファブリックのソフトウェア定義型ネットワーキングも統合されています。こうしたテクノロジーにより接続とハードウェア管理を一元化することで、統合されたリソース プールをビジネス ニーズに合わせて提供できる、適応性の高い統合クラスタが実現します。
Cisco HyperFlex HX データ プラットフォーム 2.0
Cisco HyperFlex システムは、エンドツーエンドのソフトウェア定義型インフラストラクチャ/ハイパーコンバージド ソリューションを目指しており、従来製品における妥協をすべて排除しています。ハイブリッド/オールフラッシュのメモリ ストレージ構成と各種の管理ツールにより、事前に構成されたクラスタを活用し、1 時間以内で稼働開始できます。このクラスタは、Microsoft Exchange Server の要件に適合するように、リソースを個別に拡張できます（図 1）。Cisco HyperFlex アーキテクチャの詳細については、シスコのホワイト ペーパー『ハイパーコンバージェンス用の次世代データ プラットフォーム）』を参照してください。
Cisco HyperFlex システムで稼働する Microsoft Exchange Server
Cisco HyperFlex HX シリーズ ノードは Exchange Server を完全にサポートしますが、現時点で Microsoft 社はメールボックス サーバのNFS データ ストア利用をサポートしていません。NFS は、HyperFlex 分散ファイルシステムにおける pNFS と似た独自の実装により、コンピューティング ノードとコンバージド ノードの両方によって使用され、HX データ プラットフォーム上のデータ ストアに接続されています。こうした構成はシスコによって十分に検証されています。Cisco HyperFlex HX シリーズ ノードは、コンバージド ソリューションよりもパフォーマンスを向上させ、複雑さを大幅に軽減します。コンバージド ソリューションの欠点は、拡張が困難な多数のパフォーマンスサイロ化したシステムで数十～数千もの追加オブジェクトを管理する必要があることです。一方、HyperFlex では、データストアは 1 つのみでサイロやパフォーマンスのホットスポットは存在しません。全体的なキャパシティと、コンピューティング ノード/コンバージド ノードは、ノードや物理ディスクの追加といった簡単な作業を除けば、管理オーバーヘッドの発生なしにシームレスに拡張できます。Cisco HyperFlex システムは、自動的に自己修復を行い、クラスタ内で利用可能なデバイスすべてにデータを自動的に再配置するため、デバイスやノードが追加されると、クラスタ全体で集計され全体キャパシティとパフォーマンスが向上します。
Microsoft Exchange Server 2016
Microsoft Exchange Server 2016 は、Microsoft 社の最新（2 番目）リリース バージョンで、管理型コードを使用する Microsoft Exchange Server 2013 の後継となる製品です。新機能の詳細については、Technet の記事「Exchange 2016 の新機能」を参照してください。
Cisco HyperFlex システムで稼働する Microsoft Exchange Server：VMware におけるベスト プラクティス
Cisco HyperFlex システムに Exchange Server を実装する場合は、https://blogs.vmware.com/apps/files/2016/07/Microsoft_Exchange_Server_2016_on_VMware_vSphere_Best_Practices_Guide.pdf [英語] に記述されている VMware のベスト プラクティスに従ってください。
次の各項では、Exchange Server を効果的に実装するための主要な設計ガイドラインおよび構成を示します。
高い可用性
高可用性はメッセージング管理者にとって非常に重要であるため、管理者は多数のツールを選択・使用してその実現に取り組んでいます。HX データ プラットフォームでは、ストレージ ファイル システム レイヤに可用性が組み込まれており、すべてのデータが二重または三重に書き込まれています（レプリケーション ファクタ 2（RF2）またはレプリケーション ファクタ 3（RF3））。HX データ プラットフォームでは、プライマリ コピーがあるプライマリ ストレージ コントローラを使用できない場合、仮想マシンに影響を及ぼすことなく、データのコピーをプライマリ に昇格させることができます。ノードまたはハイパーバイザの障害から保護するために、クラスタ内の他のノードで仮想マシンを起動するように VMware High Availability（HA）を設定できます。
Exchange Server データベース可用性グループ（DAG）が展開されている場合は、Exchange Server 自体のデータベース レイヤに高可用性オプションが組み込まれています。使用可能な機能は、導入されている Exchange Server のエディションによって異なります。これらの高可用性機能については、以下の項で説明します。
Microsoft Exchange Server データベース可用性グループ（DAG）
DAG は、共有ストレージを使用しない、データベース ミラーリングに代わるエンタープライズ ソリューションです。DAG は Exchange Server 2010 で初めて実装されました。「DAG」とは、それぞれが Exchange データベースのコピーを保持できる、最大 16 台の Exchange サーバのグループです。実稼働環境では、通常は 3 ～ 4 のデータベース コピーが使用されます。
データベースを導入する場合は、単一障害点を取り除くことで、電源、ネットワーク、または問題の蓄積によってクラスタに障害が発生した場合の可用性が向上します。複数のクラスタが近接する場合のベスト プラクティスは、図 2 に示すように、複数のクラスタ全体に DAG を拡張することです。図 2 では、1 つのノード上にデータベースのコピーが 1 つしかありません。各データベースの少なくとも 1 つのコピーが別個の Cisco HyperFlex クラスタに存在します。同じデータベースのコピーを格納する Exchange Server 仮想マシンが、同じ物理ホスト上に存在することを防ぐ方法については、本書の「VMware Distributed Resource Scheduler のアフィニティ対策ルール」セクションで、Exchange Server 可用性の向上に関する情報を参照してください。
Microsoft フェールオーバー クラスタリング
Microsoft Windows 2012 R2 のフェールオーバー クラスタリング機能では、ネットワークの一時的な問題がわずか 5 秒でも続いた場合に、特定のノードに障害が発生したと別のノードが判断できるよう、非常にアグレッシブなタイムアウト値を使用しています。2012 R2 のデフォルト タイムアウト値を Windows 2016 と同じ値に増やすホットフィックスが提供されています。詳細については、Elden Christensen 氏による Windows ブログ「Tuning Failover Cluster Network Thresholds（フェールオーバー クラスタのネットワークしきい値の調整）」を参照してください。
これらのデフォルト値については、VMware 社も変更を推奨しています。詳細については、VMware 社のサイト「Exchange 2016 Best Practices Guide（Exchange 2016 ベスト プラクティス ガイド）」を参照してください。
サイジングの考慮事項
サイジング要件には複数の要因が関係する可能性があります。Exchange のコンピューティングとストレージの両方の要件を正確に見積もるには、Exchange 2013 および Exchange 2016 用の Exchange Server Role Requirements Calculator を使用する必要があります。このツールは、必要なサーバ数、キャパシティ、1 秒あたりの I/O 回数（IOP）を見積もります。5 年前の Exchange では、現在の 10 ～ 20 倍の IOP が必要でした。また、同じ時期に使用されていた大容量ハードディスク ドライブ（HDD）SAN の能力は、ノンパリティ SATA スピンドルあたり約 10 ～ 15 IOP 程度でした。クラスタには、Exchange が必要とするより数倍多くの I/O ヘッドルームがありますが、Outlook のオンラインモード ユーザには現在も 2 倍の IOP ペナルティが設定されているため、VMware Storage I/O Control を実装して、他の仮想マシンの負荷やバックアップ ジョブによって Exchange に過度の遅延が発生しないようにする必要があります。
Cisco HyperFlex ハイブリッド システムとオールフラッシュ システムの両方を使用する場合、キャパシティ リソースおよびコンピューティング リソースは IOP における非常に大きなボトルネックとなり得るため、慎重な計画が必要になります。最近サポートが発表された 4 プロセッサ ソケットの Cisco UCS B460 ブレード サーバと Cisco UCS C460 ラック サーバのコンピューティング ノードは、ノード数の削減に貢献します。4 ノード クラスタは、ストレージ IOP の観点から言えば、15 ～ 20 万ユーザをサポートできます。ただし、使用されている特定の CPU のコアと SPECint2006 レート値によって異なりますが、ノードに含まれるコンピューティング リソースでは 1,000 ～ 2,000 ユーザしかサポートできないことがあります。このユーザ数は、プロセッサを検索し、その値を Exchange Server Role Requirements Calculator の入力タブに入力することによって特定できます。Calculator は完全な対称性を想定しているため、必要なデータベースおよびサーバの数の値が増える可能性があることに注意してください。Calculator の計算値は、適切な計画によりバランスを取る必要があります。アフィニティ対策ルールを使用して、同一データベースのコピーが同一の物理サーバに存在することを防いでください。
キャパシティの要件を満たす際は、Cisco HyperFlex HX240c ノードのデータ永続階層に最大 23基のストレージ ドライブと、より多くのコンバージド ノードを追加できます。インライン圧縮とデータ重複排除によって節約可能な容量については、以下のセクションでご説明します。
データ重複排除
データ重複排除は、メモリ、SSD、HHD（ハイブリッド クラスタの場合）を含む、クラスタ内のすべてのストレージで使用されます。頻繁に使用されるブロックのみに対してフィンガープリントとインデックスを作成することにより、少量のメモリで高い重複排除率を実現でき、クラスタ ノード内の価値の高いリソースであるメモリ使用量を節約できます。データ重複排除による圧縮率は、ユーザのメールボックス内のコンテンツによって異なります。ただし、多くの場合は OS とアプリケーションのバイナリ ファイルだけでも大幅に重複排除できます。Microsoft Office ドキュメント添付ファイルを多用する環境では、さらに高い重複排除率を達成できます。添付ファイルが多用される環境では一般に 10 ～ 35 % の重複排除率を達成でき、添付ファイルなしの小容量メールボックスでは 5 ～ 15 % となります。
インライン圧縮
HX データ プラットフォームではデータ セットに対して高性能のインライン圧縮を行うことで、パフォーマンスを損なうことなくストレージ容量を節約できます。新規の変更は圧縮されて新しい場所に書き込まれ、既存の（古い）データは削除対象としてマークされます（そのデータをスナップショット内で保持する必要がある場合を除く）。変更されたデータは、書き込み操作に先立って読み取る必要がないため、典型的に発生する読み取り-変更-書き込みペナルティが回避され、書き込みのパフォーマンスが大幅に向上します。Exchange Server のクラスタ全体の圧縮率の平均は 10 ～ 15 % ですが、インゲスト暗号化などの一部のオプションを使用すると、達成可能な圧縮率が大幅に低下します。
シン プロビジョニング
HX データ プラットフォームでは、ディスク容量を予測して購入・インストールする必要がないため、長期間使用されないままになるリスクを回避し、ストレージを効率的に使用できます。仮想データ コンテナ（データ ストアおよび仮想マシン ディスク（VMDK）ファイル）では、アプリケーションに多量の論理スペースが提供されます。一方、必要な物理記憶域の量は、書き込まれるデータによって決定されます。ビジネス要件に応じて、既存ノードのストレージを拡張したり、ストレージ集約型ノードを追加してクラスタを拡張したりできます。必要になる前の段階で容量確保のためにストレージを購入しておく必要性はなくなります。
データベースとログ ファイルのサイジング
データベースにデータが書き込まれることで、ユーザのデータベース ファイルとトランザクション ログは拡大します。これらのファイルの動作は、バックアップ モデルによって異なります。通常は、実稼働データベースがバックアップされ、完全バックアップが完了するとトランザクション ログが切り捨てられます。バックアップを使用する場合、トランザクション ログの論理ユニット番号（LUN）はバックアップ期間変更率の 3 倍以上にする必要があり、通常は 3 日間の変更に対応できるようにします。このアプローチでは、週末にかけてバックアップが失敗しても、トランザクション ログの保存領域が不足することは避けられます。
Exchange のネイティブ データ保護機能では、少なくとも 3 つのデータベースの（時間差なし）コピーを必要とします。Microsoft ボリューム シャドウ コピー サービス（VSS）バックアップは実行されず、データベース上では循環ログが有効化されます。この構成におけるトランザクション ログは、バックアップの失敗から保護するためのバッファ（追加スペース）を必要としません。
データベース サイズの選択
最小規模のデータベースには、1 つのオープン トランザクション ログ ファイルと Exchange データベース（EDB）ファイルがあります。データベースのサイズは、構成内の合計データベース数に直接影響を与えます。また、サービス レベル契約（SLA）で指定された時間内でデータベースを復元できるように注意を払う必要もあります。同一のデータベースのコピーが同一の物理ホストに存在しないようにすることが重要なので、少数の大規模データベースを使用する場合は、DGA のノード間でデータベースのバランスを取るのが難しい場合があります。
論理ユニット番号のレイアウトの選択
仮想マシンでは、LUN（論理ディスク）は、Cisco HyperFlex データ ストアに保存されている VMDK ファイルを示します。通常、Microsoft Windows 仮想マシンにディスクを追加すると、そのディスクはオフラインになります。ディスクを使用するには、オンラインにして初期化し、フォーマットする必要があります。
グローバル一意識別子パーティション テーブルと ReFS の選択
New Technology File System（NTFS）パーティションを初期化する場合は、グローバル一意識別子（GUID）パーティション テーブル（GPT）が推奨されます。ファイル システムの冗長性が十分に確保されていて、2 テラバイト（TB）を超えるパーティションに使用できるためです。NTFS は、1990 年代に Exchange が登場して以来推奨されているデフォルト ファイル システムです。新しい Resilient File System（ReFS）は、Exchange 2013 で暫定的にサポートされ、現在は Exchange 2016 でサポートされています。Microsoft 社では、Exchange 2016 推奨アーキテクチャでは、ReFS の整合性ストリームを無効にすることを推奨しています。新しい ReFS を使用する場合は、DAG の作成時にそのことを宣言する必要もあります。
ReFS を使用してディスクをフォーマットするには、Microsoft PowerShell で次のように入力します。
DAG の作成中に ReFS を宣言し、再シードで同一のファイル システムが使用されるようにするには、次のように入力します。
アロケーション ユニット サイズの選択
フォーマットについて、Microsoft 社は 64 KB のアロケーション ユニット サイズ（AUS、「クラスタ サイズ」とも呼ばれる）を推奨しています。設定をデフォルトのままにする場合、非常に大きなパーティショニングでない限りサイズは 4 KB になります。ユーザ データベースとユーザ トランザクション ログの両方を保管するディスクには、64 KB AUS が推奨されます。
ReFS を使用してディスクをフォーマットし、AUS を 64 KB に設定するには、PowerShell で次のように入力します。
ページ ファイル、OS、データベース、ログの分離
多くの環境では、単一の DAG 内で数千ものデータベースを運用しています。これらのデータベースのほとんどでは、必要とされる IOPS は非常に小さく、ワークロードとファイル タイプを慎重に分離することが考慮されていません。データベースが拡大する場合や、非常に負荷が高いユーザ ワークロードが含まれる少数のデータベースの場合は、あらゆる要素を分離することでパフォーマンスが向上します。また、少なくともファイルシステムのフラグメンテーションが防止されます。Exchange では、PowerShell を使用して簡単にファイルを移動できますが、データベースは移動の際にマウントを解除する必要があるため、移動時にはサービスが中断します。move コマンドは次のようになります。
サービスを中断する必要がない場合は、新しい場所に新しいデータベースを作成し、次のコマンドを使用してユーザを新しいデータベースに移動できます。
移動後に古いデータベースを削除するには、次のコマンドを使用します。
理想としては、最大 4 つの VMware 準仮想化 Small Computer System Interface（PVSCSI）コントローラに分散された個別の VMDK に、あらゆる要素を分離するべきです。その場合は、分離された VMDK でページ ファイルのサイズを 1 x RAM + 257 MB にし、完全なメモリ ダンプを保存できるようにする方法が推奨されます。環境によっては、カーネル メモリ ダンプに多くの空き容量があれば十分な場合があります。カーネル ダンプのサイジングについては、Microsoft 社のブログ「Page File—The Definitive Guide（ページ ファイル ガイド）」を参照してください。
最適なパフォーマンスを得るには、データベースのデータ ファイルとログ ファイルを、複数の PVSCSI コントローラに分散します。各コントローラの番号は 0 から 3 です。コロンに続く 2 つ目の番号は、LUN 番号またはディスク番号です。たとえば図 3 の「1:3」は、ディスク 3 のコントローラ 1 を示しています。
Microsoft Exchange Server のライセンス
Microsoft 社では複数のバージョンの Exchange Server ライセンスを提供しています。それぞれに各種のエディションがあり、さまざまな方法で提供されるため、ライセンスの具体的な条件については Microsoft 社までお問い合わせください。Exchange Server は 2 つのエディションが提供されています。Standard エディションは最大 5 個のメールボックス データベースをサポートし、Exchange エディションは最大 100 個メールボックス データベースをサポートします。Exchange Server を実行するには、物理サーバまたは仮想マシンのライセンス コストに加え、ユーザごとにクライアント アクセス ライセンス（CAL）が必要になります。CAL は、Standard または Enterprise としてライセンス供与されます。
Exchange CAL は、Standard CAL のユーザに適用されるアドオンです。この CAL では、次の機能を利用できます。
● ジャーナリング（ユーザごと）、デジタルライブラリ、ジャーナル暗号化解除
● ユニファイド メッセージング
● インプレース アーカイブと保持
● データ損失防止（DLP）
● Information Protection and Control（IPC）
データ保護
Cisco HyperFlex システムでは、迅速なバックアップとレプリケーションのためのスナップショットと、高速で効率的なテスト・開発を可能にするクローンがサポートされています。
スナップショット
HX データ プラットフォームはメタデータベースのゼロコピー スナップショットを使用して、バックアップ操作やリモート レプリケーションを容易にします。これらの機能は、データを常時利用できる必要がある企業にとってきわめて重要です。スペース効率の高いスナップショットにより、物理ストレージ容量の消費を心配せずに、データのオンライン バックアップを頻繁に実行できます。スナップショット データはバックアップ リポジトリに移動することができ、またスナップショットが保持されている場合は、ただちに復元することが可能です。
● 高速なスナップショットの更新：スナップショットに変更されたデータが含まれている場合、このデータは新しい場所に書き込まれ、メタデータが更新されます。読み取り、変更、書き込みという手順を実行する必要はありません。
● 高速なスナップショットの削除：スナップショットは迅速に削除できます。HX データ プラットフォームでは、少量のメタデータのみを削除します。デルタディスク技術を使用するソリューションで必要となる、長時間の統合プロセスは不要です。
多くの基本的なバックアップ アプリケーションでは、データ セット全体、または前回のバックアップ以降に変更されたすべてのブロックが、ストレージあるいはオペレーティング システムが処理可能な速度で読み取られます。Cisco HyperFlex システムは Cisco UCS を基盤にして構築されており、各ホストで非常に高速な 10 ギガビット イーサネットが使用されるため、少数の同時バックアップ ジョブでもバックアップ スループットが 1 秒あたり何ギガバイトにも達します。そのため、このプロセスはパフォーマンスに影響します。Microsoft Windows Server Backup などの基本的なバックアップ アプリケーション、特に何らかの形式のブロック変更トラッキングを使用する初回のバックアップ操作などは、ピーク時以外の時間にスケジュールする必要があります。
Veeam Backup and Replication Version 9.5（v9.5）などのフル機能のバックアップ アプリケーションでは、バックアップ アプリケーションが利用できるスループットを制限して、遅延の影響を受けやすいアプリケーションを稼働時間中に保護できます。Veeam v9.5 Update 2 のリリースによって、Veeam は HX データ プラットフォームのネイティブ スナップショットを統合した製品になりました。HX データ プラットフォームのネイティブ スナップショットでは、デルタディスク スナップショットのパフォーマンス低下が発生せず、またスナップショットを削除するために、スナップショット統合中に多量のディスク I/O 操作を行う必要はありません。
Exchange Server 管理者にとって特に重要になるのは、アプリケーション認識型のエージェントレス VSS 休止スナップショットを作成する機能です。Veeam Explorer for Exchange Server は、個々のアイテムのきめ細かい復元機能と E-Discovery オプションを提供します。Veeam Explorer for Exchange Server は、バックアップ リストア ポイントから Exchange Server データベースを復元できるので、ロールフォワード リカバリや、個人用ストレージ テーブル（PST）へのアイテムのエクスポートを、仮想マシンや Exchange Server をオフラインにすることなく実行できます。Veeam Explorer for Exchange はオブジェクト レベルのエクスプローラで、Veeam バックアップ ファイル内の Exchange データベースを即座に開きます。Exchange 管理者は、復旧時間を短縮しつつ、個々のアイテム レベルで復元できます。
クローン
HX データ プラットフォームにおけるクローンは、書き込み可能なスナップショットです。テスト環境や開発環境で Exchange Server インフラのコピーを迅速にプロビジョニングする目的で使用されます。高速でスペース効率の高いクローンによって、ストレージ ボリュームのレプリケーションが迅速になるため、仮想マシンをメタデータ操作だけでレプリケートすることが可能になります。クローンでは、仮想マシンでデータが書き込まれるか変更された場合のみ、ディスク領域が消費されます。このアプローチでは、何百個ものクローンの作成や削除を数分で行えます。フルコピー方式と比較すると、このアプローチは時間を大幅に節約し、IT の俊敏性や生産性を高められます。Exchange Server 管理者は実稼働データベースのクローンを簡単に作成して、Exchange Server、Windows、またはカスタム フロントエンド アプリケーションのパッチやアップデートと互換性をテストできます。テストが完了したら、クローンは簡単に削除できます。
ストレージ構成：追加データ ストアの構成
HX データ プラットフォームのほとんどの導入では、1 つのデータ ストアで十分であり、それによって管理対象も少なくなります。HX データ プラットフォームは分散ファイル システムであるため、データをローカルに保持する従来のシステムで発生するような問題に影響されません。VMDK は、物理ノードで利用可能なストレージに保持される必要はありません。設定されたコピー数のデータを保存する領域がクラスタ内にあれば、VMDK を保持することができます。同様に、仮想マシンをクラスタ内の別のノードに移動するのは、ホスト移行になるため、データ自体は移動しません。
ただし場合によっては、データ ストアを追加することが有効な場合もあります。たとえば、管理者が HX データ プラットフォームのデータ ストアを追加して、他のワークロードから Exchange を分離することがあります。パフォーマンス メトリックはデータ ストア レベルにフィルタリングできるため、ワークロードまたは仮想マシンの分離が必要になる場合があります。重要なのは、仮想マシン内のすべての VMDK が同じデータ ストアに存在することです。データ ストアは常にクラスタにシン プロビジョニングされます。ただし、データ ストアの作成時にデータ ストアの最大サイズを設定することで、ワークロード、一連の仮想マシン、またはエンド ユーザのディスク領域がクラスタ全体で枯渇して他の仮想マシンに影響することを防止できます。
追加データ ストアのもう 1 つの効果的な用途は、高性能の Exchange Server でスループットと遅延を改善することです。VMware ESX ホスト上のすべての仮想マシンでの累積 IOP が 10,000 IOP を超えると、システムのキューデプスに到達してしまいます。ESXTOP では、物理ディスクの NFS ボリュームで、アクティブなコマンドとコマンド カウンタをモニタリングする必要があります。各仮想マシンの VMDK 全体を単一のデータ ストアに保持しながら仮想マシンを複数のデータ ストアに分割するか、ESX の 256 というキュー制限を増やすことで、ボトルネックを緩和できます。
データ ストアのキューがパフォーマンスの問題を引き起こしている場合（カーネル待ち時間よりもゲストの待ち時間が長い場合など。ESXTOP レポートで特定可能）は、次の手順に従います。
● 各ノードの VMware ESXi シェル プロンプトで次のコマンドを使用して、データ ストアのキューの深度を 256（デフォルト）から 1024 に増やします。
次のコマンドを使用して、この変更を確認するクエリを実行できます。
The value of MaxQueueDepth is 1024.
● 1 つのデータ ストア内には I/O 要求が少ない Exchange 仮想マシンを導入し、別のデータ ストア内には I/O 要求が多い Exchange 仮想マシンを導入することが可能かどうかを確認します。このように複数のデータ ストアを使用すると、パフォーマンスの要件に基づいてデータ ストアごとにキュー深度を設定できます。
仮想マシンの構成
このセクションでは、仮想マシンの構成に関するベスト プラクティスを示します。
仮想マシンのコンピューティング リソースとメモリ リソース
Microsoft 社は、以前に Exchange 2013 で推奨される最大コア数および最大メモリ サイズに関してガイダンスを公開しており、現在は Exchange 2016 にも適用されています。このガイダンスでは、仮想マシンあたり最大 96 GB のメモリと、24 コアの使用を推奨しています。同社では、仮想 CPU（vCPU）と物理 CPU との 1:1 の比率を推奨しています。だだしこの構成では、1 ～ 3 台の Exchange Server 仮想マシンを保持するだけで、ほとんどのノードはコンピューティング リソース全体を消費することになります。分散データ ストア内のクラスタ全体のストレージ デバイスすべてを使用してコンピューティング専用ノードを追加できる機能は大きな効果があり、Exchange 内のユーザあたりのストレージ コストの削減に役立ちます。
SCSI コントローラ
ディスク I/O はスタック内の多数のレベルでキューイングされるため、ボトルネックが発生する場所を把握することは、設計上の決定に役立ちます。仮想マシンで最も影響の大きい要素は、SCSI コントローラに設定されたキュー深度です。仮想マシンでは、デフォルトで LSI Logic 製 SAS SCSI コントローラが使用されます。キュー深度は 32 で、これは変更できません。これに対して VMware では、デフォルトのキュー深度が 64 である PVSCSI コントローラを推奨しています。Exchange Server が動作する仮想マシンで、必要とする IOP が 500 未満であれば、多くの場合デフォルト設定で十分であるため、ハイパーコンバージェンスが簡素化されます。ただし経験のある Exchange Server 管理者であれば、さらに慎重を期して、パフォーマンスやバックアップの目的で、別のディスクにあらゆる要素を分離することがあります。Cisco HyperFlex では、Exchange Server で PVSCSI コントローラを使用することがベスト プラクティスになります。
従来、PVSCSI コントローラはブート デバイスとしてはサポートされていませんでした。仮想マシンには最大 4 つの SCSI コントローラを設定できるため、1 つをブート用に使用し、さらに最大 3 つの PVSCSI コントローラをデータベースとトランザクション ログに使用してきました。Windows Server の最新バージョンでは、ドライバが Windows に正常にインストールされたことを確認した後で、元のコントローラ（SCSI コントローラ 0）を PVSCSI に変更できます。
PVSCSI のキュー深度
Exchange Server 導入時のキュー深度は、一般にはデフォルト設定で十分です。新バージョンの Exchange で発生する可能性は低いですが、Exchange 仮想マシンが 500 の IOP のしきい値に近づいた場合は、VMware ナレッジ ベースで説明されているように、PVSCSI キューの深度をデフォルトの 64 から 254 に増やすことを検討してください。その場合は、RequestRingPages と MaxQueueDepth の値を、それぞれ 32 と 254 に増やす必要があります。キュー深度は SCSI コントローラごとに設定するため、PVSCI コントローラを追加して、仮想マシンが保持できる未処理の IOPS の合計数を増やすことを考慮してください。
キュー深度が不足していることを表す現象としては、Cisco HyperFlex のユーザ インターフェイスまたは ESXTOP に表示される Cisco HyperFlex パフォーマンス チャートに示す遅延と比較して、ゲスト システムの遅延が 10 % 以上大きくなることが挙げられます。既存ライブ環境でこの値を確認するには、コントローラ上のすべての VMDK におけるアクティブなキュー深度の累積が、集中的な I/O 処理中のコントローラのキュー深度より大きい状態が続いているかどうかを、Windows Performance Monitor でチェックしてください。たとえば、別個の VMDK にある 2 つのデータベース ファイルで、LSI SAS コントローラの使用中にキューが急増して 80 の状態が続いている場合は、PVSCSI に切り替えることで、コントローラのキュー深度を 2 倍（32 から 64）にできます。各 VMDK を PVSCSI コントローラに配置することで、最大キュー深度がさらに 2 倍（合計 64 からそれぞれ 64、つまり 128）になります。PVSCSI キューのレジストリ設定を 64 から 254 に変更すれば、この例ではデータベースで使用可能な最大キュー深度が 128 から 508 になります。
VMDK のレイアウト
小型の Exchange Server であれば、システム全体を収めた単一の VMDK（C: ドライブ）のみで十分に実行できます。データベースで IOPS 数が増加した場合は、ワークロードを個別の VMDK に分離することでパフォーマンスが向上します。すべてのワークロードを個々の VMDK に分離することがベスト プラクティスになります。OS、ぺージング ファイル、データベース、およびトランザクション ログ用に個別に VMDK を作成します。LUN のレイアウト ガイダンスに従い、導入するユーザ データベース ファイル数（アクティブおよびパッシブの両方）を考慮してください。
VMXNET3 ネットワーク インターフェイス カード
仮想マシンの帯域幅が毎秒 1 ギガビットに近づいた場合は、デフォルトの VMware E1000 ネットワーク カードから VMXNET3 ネットワーク インターフェイス カード（NIC）に切り替えることを検討してください。VMXNET3 は最高のパフォーマンスが得られるように設計されており、VMware ツールのインストールが必要になります。VMXNET3 NIC で受信側スケーリング（RSS）を有効にすることで、ネットワーク ドライバによって着信 TCP トラフィックが VMXNET3 アダプタのゲスト仮想マシン内の複数の CPU に分散されます。
仮想 CPU Non-Uniform Memory Access
仮想 CPU Non-Uniform Memory Access（vNUMA）により、NUMA トポロジがゲスト オペレーティング システムに提供されます。マルチソケット マザーボードではメモリ DIMM がソケットに割り当てられるため、他のソケットに割り当てられているメモリにアクセスしたときに、CPU で実行中のプロセスのパフォーマンスが低下します。シンプルなガイドラインとして、CPU コア数を物理 CPU 上の 1 つの NUMA ノードにある CPU コア数以下にして、仮想マシンのサイジングを行う方法があります。ほとんどの場合、そのコア数がプロセッサのコア数になりますが、該当しない場合もあります。さらにコアが必要な場合は、NUMA ノードで複数のコアを使用します。Exchange は、NUMA を認識しませんが Windows 2012R2 および 2016 は認識します。ただし、パフォーマンス テストの結果を見ると、vNUMA を有効にする利点はありません。Exchange は、vNUMA や CPU のホット アドからメリットが得られないため、VMware では Exchange Server 仮想マシンに対して CPU ホット アドを有効化しないよう推奨しています。
仮想ソケットあたりの仮想コア数
仮想マシンを設定する場合は、仮想ソケット（vSocket）の数と、ソケットあたりの仮想コア（vCore）の数の両方を設定できます。VMware では、ソケットあたりコア数を 1 に設定し、Exchange Server 仮想マシンに CPU を割り当てながら仮想ソケット数を増やしていくことを推奨しています。
高性能 VMware ESX ポリシー
Cisco HyperFlex システムでは、ESX 電源ポリシーが [ハイパフォーマンス（High Performance）] に設定されます。この設定を [ハイパフォーマンス（High Performance）] に維持することが、ストレージ コントローラのパフォーマンスにとって重要です。
CPU とメモリ予約
Exchange Server はコンピューティング リソースを大量に消費するため、ハイパーバイザ、オペレーティング システム、および Exchange Server がコンピューティング リソースとメモリ リソースに関して競合しないように、慎重に調整する必要があります。Exchange Server 仮想マシンでメモリと CPU 予約を設定するという予防策を講じることで、オーバープロビジョニングされたサイズの小さい仮想マシンによる予期しないリソース消費を防止できます。仮想マシンでパフォーマンスが最重要である場合は、プロビジョニングされたメモリと同量のメモリを予約し、仮想マシンのリソース割り当て設定で、数メガサイクルに相当する少なくとも 1 つの CPU コアを予約します。Microsoft 社では、Exchange に対してメモリ リソースのオーバーコミットをサポートしていません。CPU は最大 2:1 の比率でオーバーコミット可能ですが、同社では CPU をオーバーコミットしないことをベスト プラクティスとしています。
メモリのオーバーサブスクリプションと動的メモリ割り当て
「メモリのオーバーサブスクリプション」とは、ESX ホストに存在する容量以上のメモリを仮想マシンに割り当てることです。動的メモリ割り当てとは、実行中の仮想マシンへのメモリのホット アドです。どちらのプロセスも悪影響はありませんが、Microsoft 社ではいずれの機能も Exchange Server 仮想マシン上でサポートしていません。この機能がサポートされていない一部の理由は、Exchange によるサービス起動時のメモリ割り当て方法に起因しています。このメモリ割り当て方法はストア プロセスが C# で書き直された Exchange 2013 から変更されています。動的なプロセスを使用する代わりに、すべてのメモリ割り当てが静的にサービス起動時に設定されます。
Exchange 仮想マシンへの割り当てメモリを増減する方法でサポートされているのは、仮想マシンをシャットダウンし、仮想マシンの設定を直接編集/変更する方法です。
VMware ESX の構成
この項では、VMware ESX の構成に関するベスト プラクティスを示します。
VMware vSphere Storage I/O Control
VMware vSphere Storage I/O Control（SIOC）を使用することで、他の仮想サーバがストレージ I/O 領域をすべて消費してしまい、クラスタ内の他の仮想マシンが必要とする、クラスタの合計 IOPS の一部である I/O 領域が枯渇することを防止します。残念ながら、SIOC では I/O のサイズが区別されません。しかし、データ ストア単位で有効にし、遅延しきい値を設定できます。しきい値に達すると、データ ストアの I/O 処理全体にシンプルな Quality of Service（QoS）ポリシーが適用されます。
仮想マシン間における VMware ESX メモリの共有
デフォルトでは、仮想マシン間のページ共有はセキュリティ上の懸念から無効化されていますが、この機能には単なる仮想マシン内のページ共有以上のメリットがあります。この設定は、メモリ領域を解放するためのメモリの重複排除と言えます。これに関しては、VMware の『vSphere リソース管理』ホワイト ペーパーの「仮想マシン間でのメモリの共有」セクションで詳しく説明されています。
VMware ESX の reqCallThreshold 値
デフォルトでは、ESX の reqCallThreshold 値は 8 です。これは、しきい値に達するまで、仮想ホスト バス アダプタ（vHBA）キュー内の I/O が下位のレイヤにフラッシュされないことを意味します。VMware バージョン 11 のハードウェアを使用した、遅延の影響を受けやすいデータベースでは、この値が小さくなると遅延が低減する場合があります。この値は、仮想マシンの VMware VMX ファイルで、または ESX でグローバルに小さくすることができます。正確な設定については、VMware のホワイト ペーパー「Performance Best Practices for VMware vSphere 6.0（VMware vSphere 6.0 のパフォーマンスのベスト プラクティス）」を参照してください。
VMware Distributed Resource Scheduler のアフィニティ対策ルール
Exchange Server で DGA などの高可用性機能を使用する場合は、VMware Distributed Resource Scheduler（DRS）でアフィニティ対策ルールを設定し、同一のデータベースのコピーが含まれている各仮想マシンを異なる物理ホストに分離するように指示します。2 つのコピーの DGA 内で両方の仮想マシンが同じ物理サーバに置かれている場合、物理サーバに障害が発生すると、データのコピーすべてが VMware HA とともに新しいホストに移動され、Exchange Server データベースが停止します。アフィニティ対策ルールによって、ホストが停止しても VMware が仮想マシンを分離してホストも分離し、（Exchange Server がデータベースのパッシブ コピーを有効化するため）サービスの可用性に影響しなくなります。
アフィニティ対策ルールは、サーバの物理的な領域を大幅に消費する大型の仮想マシンを導入する場合に、クラスタのバランスをとるためにも役立ちます。たとえば、それぞれが ESX ホストのメモリまたはコンピューティング サイクルの 40 % を消費する、3 つの大型の Exchange Server 仮想マシンを導入する場合は、1 つのホストに複数の仮想マシンが配置されないようにするアフィニティ対策ルールを適用できます。この設定では、たとえば実稼働環境で使用するホスト リソースを 75 % 未満に義務付ける SLA を作成できます。これにより、障害が発生したホストに対応し、その後に他の稼働中のホストに VM のフェールオーバーを行う場合でも十分なリソースを活用できるため、重要サービスに影響を与えずに済みます。
まとめ
Cisco HyperFlex HX データ プラットフォームは、新しい IT 消費モデルに対応するハイパーコンバージド インフラストラクチャ環境向けに、革新的なデータ ストレージを実現します。プラットフォームのアーキテクチャおよびソフトウェア定義型ストレージ アプローチは、専用の高性能な分散ファイル システムを実装し、エンタープライズクラスの幅広いデータ管理サービスを提供します。分散ストレージ テクノロジーを再定義するイノベーションによって、適応型 IT インフラストラクチャに必要なハイパーコンバージド インフラストラクチャを実現するデータ プラットフォームが得られます。
ハイブリッドおよびオールフラッシュ構成の Cisco HyperFlex システムにより、利用成長に合わせた拡張が可能になり、運用コスト（OpEx）と資本コスト（CapEx）の両方を削減できます。またコンピューティング、ストレージ、およびネットワーク リソースのコンバージェンスも簡素化されます。必要なリソースをすぐにサイジングして取得できるため、コンバージド ノードにディスクを追加した後や、コンバージド ノード自体を追加した後でも、自動再調整によってストレージを簡単にスケーリングできます。コンピューティング リソースがさらに必要になった場合は、Cisco UCS 認定ラック サーバあるいはブレード サーバを、コンピューティング専用ノードとしてクラスタに追加できます。
本書に示す Exchange Server のベスト プラクティスは、高性能の仮想マシン（500 IOPS 以上）向けのガイドラインです。Exchange Server を含むほとんどの仮想マシンは、ストレージ、ESX、仮想マシン、または Exchange Server レイヤでの複雑な設定を行うことなく機能します。
従来の多くのストレージ システムとは異なり、VMDK サイズやデータ ストアの拡張も簡単です。Veeam と Cisco HyperFlex システムを統合することで、デルタディスク統合が不要になり、クラスタに対する影響が軽減されるとともに、各アプリケーションで一貫したスナップショットによるリカバリ機能が追加されます。ネイティブのクローニングはスペース効率に優れ、高速であるため、Exchange Server 管理者は実稼働データにすばやくアクセスしてテストし、ストレージ容量を追加することなく最適化できます。
詳細情報
● 共有ストレージを使用した Microsoft Cluster Service および Windows Server Failover Clustering の VMware サポート：https://kb.vmware.com/kb/2147661 [英語]
● Microsoft Exchange Server ライセンス：https://products.office.com/ja-jp/exchange/microsoft-exchange-server-licensing-licensing-overview
● VMware vSphere 6.0 のパフォーマンスに関するベスト プラクティス：http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-perfbest-practices-vsphere6-0-white-paper.pdf [英語]
● VMware と Microsoft Exchange Server のベストプラクティス：https://blogs.vmware.com/apps/files/2016/07/Microsoft_Exchange_Server_2016_on_VMware_vSphere_Best_Practices_Guide.pdf [英語]
● Cisco HyperFlex ホワイト ペーパー：http://www.cisco.com/c/dam/en/us/products/collateral/hyperconverged-infrastructure/hyperflex-hx-series/white-paper-c11-736814.pdf
● Microsoft Exchange 2016 コアおよびメモリ ガイダンス：https://blogs.technet.microsoft.com/exchange/2015/10/15/ask-the-perf-guy-sizing-exchange-2016-deployments/ [英語]
● VMware vSphere リソース管理ホワイトペーパー：http://pubs.vmware.com/vsphere-60/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-601-resource-management-guide.pdf [英語]
● Microsoft Exchange Server Role Requirements Calculator：http://aka.ms/E2016Calc
フィードバック