Hyper-V内で動的メモリを使用する場合のリスク

仮想化は組織に非常に人気があります。仮想化により、複数のサーバーを1つのホストに結合することでハードウェアをより有効に活用でき、HA機能を提供し、加熱/冷却、SQL Serverライセンス、ハードウェアなどのさまざまなコストを削減できます。私は、組織が物理環境から仮想環境に移行するのを支援するために組織との数多くのプロジェクトに関与し、組織がこれらのメリットを体験できるように支援してきました。

この記事で共有したいのは、動的メモリを使用してWindows Server2012R2でHyper-Vを操作しているときに遭遇した特有の問題です。仮想化に関する私の知識のほとんどはVMwareに関するものでしたが、現在は変化していることを認めなければなりません。

VMwareでSQLServerを使用する場合は、常にメモリの予約を設定することをお勧めします。そのため、Hyper-Vでこの動的メモリ機能に遭遇したときは、調査を行う必要がありました。動的メモリを使用することの利点とシステム要件の多くを説明する記事（Hyper-V動的メモリ構成ガイド）を見つけました。この機能は、仮想マシンの電源をオフにすることなく、多かれ少なかれメモリを仮想マシンに提供できるという点で非常に優れています。

Hyper-Vをいじってみると、仮想マシンのプロビジョニングは簡単で習得しやすいことがわかりました。少しの努力で、顧客の体験をシミュレートするラボ環境を構築することができました。素晴らしいハードウェアを提供してくれた上司の功績です。私は、i7プロセッサ、32GBのRAM、および2つの1TBSSDを搭載したDellM6800を実行しています。この獣は、私が取り組んできた多くのサーバーよりも優れています。

ラップトップでVMwareWorkstation11を使用して、4つのvCPU、24 GBのRAM、および100GBのストレージを備えたWindowsServer2012R2ゲストを作成しました。ゲストが作成されてパッチが適用されたら、Hyper-Vの役割を追加し、Hyper-Vでゲストをプロビジョニングしました。新しいゲストは、2つのvCPU、22 GBのRAM、およびSQL Server2014RTMを実行する60GBのストレージを備えたWindowsServer2012R2で構築されました。

それぞれ動的メモリを使用して、3セットのテストを実行しました。テストごとに、AdventureWorks2014データベースに対してRedGateのSQLData Generatorを使用して、バッファープールをいっぱいにしました。最初のテストでは、スタートアップRAMの値として512MBから始めました。これは、Windows Server 2012 R2を起動するための最小メモリ量であり、バッファープールが約8GBで増加しなくなったためです。

テストごとに、テストテーブルを切り捨て、ゲストをシャットダウンし、メモリ設定を変更して、ゲストのバックアップを開始します。 2番目のテストでは、スタートアップRAMを768MBに増やしましたが、バッファプールのサイズは12GB強にしか増えませんでした。

3番目の最後のテストでは、スタートアップRAMを1024MBに増やし、データジェネレーターを実行すると、バッファープールを16GB弱に増やすことができました。

これらの値を少し計算すると、バッファプールはスタートアップRAMの16倍を超えて大きくなることはありません。スタートアップRAMが最大メモリのサイズの1/16未満の場合、これはSQLServerにとって非常に問題になる可能性があります。スタートアップRAMの値が1GBのSQLServerを実行している64GBのRAMを備えたHyper-Vゲストについて考えてみましょう。この構成では、バッファープールが16GBを超えて使用できないことを確認しましたが、スタートアップRAMの値を4096MBに設定すると、バッファープールを16倍に増やすことができ、64GBすべてを使用できるようになります。

バッファプールがスタートアップRAM値の16倍に制限されている理由について私が見つけた唯一の参考資料は、ホワイトペーパー「HVDMでSQLServerを実行するためのベストプラクティス」の8ページと16ページにあります。このドキュメントでは、バッファキャッシュ値は起動時に計算されるため、静的な値であり、増加しないことを説明しています。ただし、SQL Serverは、ホットアドメモリがサポートされていることを検出すると、バッファプールの仮想アドレス空間用に予約されているサイズを起動メモリの16倍に増やします。このドキュメントには、この動作がSQL Server 2008 R2以前に影響することも記載されていますが、テストはWindows Server2012R2とSQLServer2014で実施されたため、Microsoftに連絡してベストプラクティスドキュメントを更新します。

ほとんどの本番DBAは仮想マシンをプロビジョニングしたり、そのスペースで頻繁に作業したりせず、仮想化エンジニアは最新かつ最高のSQL Serverテクノロジを研究していないため、バッファプールが動的メモリを処理する方法に関するこの重要な情報が多くの人に知られていないことを理解できます。人の。

記事をフォローするだけでも誤解を招く可能性があります。 Hyper-V動的メモリ構成ガイドの記事では、スタートアップRAMの説明は次のとおりです。

仮想マシンを起動するために必要なメモリの量を指定します。この値は、ゲストオペレーティングシステムを起動できるように十分に高くする必要がありますが、最適なメモリ使用率と潜在的に高い統合率を可能にするために、できるだけ低くする必要があります。

誰にとって、ホストまたはゲストのための最適なメモリ使用率？仮想化管理者がこれを読んでいた場合、オペレーティングシステムの起動に許可されている最小メモリを意味していると判断する可能性があります。

SQL Serverを担当するということは、環境に影響を与える可能性のある他のテクノロジについて知る必要があることを意味します。 SANと仮想化の導入により、これらの環境の状況がSQL Serverにどのように悪影響を与える可能性があるか、さらに重要なことに、これらのシステムの責任者に懸念事項を効果的に伝達する方法を完全に理解する必要があります。 DBAは、SANでストレージをプロビジョニングする方法や、VMWareまたはHyper-V環境をプロビジョニングまたは管理する方法を必ずしも知っている必要はありませんが、動作の基本を知っている必要があります。

SANがストレージアレイ、ストレージネットワーク、マルチパスなどとどのように連携するか、およびハイパーバイザーが仮想化内のCPUのスケジューリングとストレージ割り当てとどのように連携するかについての基本を知ることにより、DBAは問題が発生したときの通信とトラブルシューティングを改善できます。。何年にもわたって、私は多くのSANおよび仮想化管理者と協力してSQLServerの標準を構築してきました。これらの標準はSQLServerに固有のものであり、必ずしもWebサーバーやアプリケーションサーバーに適用されるわけではありません。

DBAは、SQL Serverのベストプラクティスを完全に理解するために、SANおよび仮想化の管理者に実際に依存することはできません。そのため、DBAの専門分野が私たちに与える影響について、できる限り最善を尽くす必要があります。

テスト中、Paul Randalのブログ投稿「無駄なバッファプールメモリからのパフォーマンスの問題」からのクエリを使用して、AdventureWorks2014データベースが使用しているバッファプールの量を決定しました。以下のコードを含めました：

SELECT
    (CASE WHEN ([database_id] = 32767)
        THEN N'Resource Database'
        ELSE DB_NAME ([database_id]) END) AS [DatabaseName],
    COUNT (*) * 8 / 1024 AS [MBUsed],
    SUM (CAST ([free_space_in_bytes] AS BIGINT)) / (1024 * 1024) AS [MBEmpty]
FROM sys.dm_os_buffer_descriptors
GROUP BY [database_id];

このコードは、どのデータベースがバッファプールの大部分を消費しているかをトラブルシューティングする場合にも役立ちます。これにより、高コストのクエリの調整に集中する必要があるデータベースを知ることができます。 Hyper-Vショップの場合は、サーバーに悪影響を与えるような方法で動的メモリを構成できるかどうかを管理者に確認してください。