SQL Server on Linux 用に永続メモリ (PMEM) を構成する

適用対象: SQL Server - Linux

この記事では、Linux 上の SQL Server 2019 (15.x) 以降のバージョン用に永続メモリ (PMEM) を構成する方法について説明します。

概要

SQL Server 2019 (15.x) では、永続メモリを使用するインメモリ機能が多数導入されました。 この記事では、SQL Server on Linux 用に永続メモリを構成するために必要な手順について説明します。

注意

用語エンライトメントは、永続メモリ対応ファイル システムの操作の概念を伝えるために導入されました。 ユーザー スペース アプリケーションからファイル システムへの直接アクセスは、メモリ マッピング (mmap()) を使用することで容易になります。 ファイルのメモリ マッピングを作成すると、アプリケーションは、I/O スタックを完全にバイパスするロード命令またはストア命令を発行できます。 これは、ホスト拡張アプリケーション (SQLPAL と Windows または Linux OS がやり取りできるようにするコード) の観点からは、"エンライトメントされた" ファイル アクセス方法と見なされます。

PMEM デバイスの名前空間を作成する

デバイスを構成する

Linux では ndctl ユーティリティを使用します。

  • ndctl をインストールして、PMEM デバイスを構成します。 詳しくはこちらをご覧ください。
  • ndctl を使用して名前空間を作成します。 名前空間は、PMEM NVDIMM 間でインターリーブされ、デバイス上のメモリ領域へのさまざまな種類のユーザースペース アクセスを提供できます。 fsdax は、SQL Server の既定のモードであり、望ましいモードです。
ndctl create-namespace -f -e namespace0.0 --mode=fsdax --map=dev

fsdax モードを選択し、システム メモリを使用してページごとのメタデータを格納しています。 --map=devを使用することをお勧めします。 このオプションでは、メタデータを名前空間に直接格納します。 現時点では、--map=mem を使用したメタデータのメモリへの格納は試験段階です。

ndctl を使用して名前空間を確認します。

サンプル出力を次に示します。

# ndctl list -N
{
  "dev":"namespace0.0",
  "mode":"fsdax",
  "map":"dev",
  "size":4294967296,
  "sector_size":512,
  "blockdev":"pmem0",
  "numa_node":0
}

PMEM デバイスの作成とマウント

例: XFS

mkfs.xfs -f /dev/pmem0
mount -o dax,noatime /dev/pmem0 /mnt/dax
xfs_io -c "extsize 2m" /mnt/dax

例: EXT4

mkfs.ext4 -b 4096 -E stride=512 -F /dev/pmem0
mount -o dax,noatime /dev/pmem0 /mnt/dax

技術的な考慮事項

  • 前に説明したように、XFS または EXT4 への 2 MB のブロックの割り当て
  • ブロックの割り当てと mmap の不整合により、4 KB へのサイレント フォールバックが発生する
  • ファイル サイズを 2 MB の倍数 (剰余 2 MB) にする必要がある
  • Transparent Huge Pages (THP) を無効にしない (ほとんどのディストリビューションでは既定で有効化)

デバイスを ndctl を使用して構成し、作成とマウントを行ったら、そこにデータベース ファイルを配置するか、新しいデータベースを作成できます。

次のコマンドを使用して fsdax モードで構成されている場合は、SQL Server のデータ ファイル (MDFS、NDFS) と tempdb ファイルを PMEM デバイスに格納できます。 これは、SQL Server のログ (LDFS) ファイルの格納には使用しないでください。トランザクション ログは、セクター アトミックの保証を提供するストレージ上に存在する必要があるためです。

ndctl create-namespace -f -e namespace0.0 --mode=fsdax --map=dev

前のコマンドで map オプションを設定する前に、次の点に注意してください。

  • このデバイスのこれらの NVDIMM ページ エントリにアクセスして更新するときのパフォーマンスを最適にするには、-map=mem を使用することをお勧めします
  • NVDIMM の容量が大きすぎる (512 GB を超える) 場合は、–map=dev を設定します。これにより、IO スループットに影響し、パフォーマンスが低下します

PMEM デバイス上の SQL Server ログ ファイルについては、セクターとブロック変換テーブル (BTT) を使用するように PMEM デバイスを構成します。 これにより、ストレージ デバイスのこのテクノロジ用の SQL Server ログ ファイルに必要なセクターのアトミック性が提供されます。 また、ワークロードのパフォーマンスの検証を実行することもお勧めします。 このソリューションとクラス最高の NVMe SSD の間でワークロードに対する SQL Server のログのパフォーマンスを比較してから、ニーズに最適なソリューションを選択し、パフォーマンスを向上させることができます。

ndctl create-namespace -f -e namespace0.0 --mode= sector

強制フラッシュ動作を無効にする

PMEM デバイスは O_DIRECT (ダイレクト I/O) セーフであるため、強制フラッシュ動作を無効にすることができます。

Note

ストレージ システムでは、すべてのキャッシュされた書き込みまたはステージングされた書き込みが安全かつ持続的であると見なされるようにすることができます。それには、デバイスに対して発行される書き込みが、システムのクラッシュ、インターフェイスのリセット、電源の障害があっても保持されるメディア上に保持され、そのメディア自体がハードウェア冗長であることを保証します。

  • データベース (.mdf.ndf) およびトランザクション ログ (.ldf) ファイルは、SQL Server 2017 (14.x) CU 6 以降のバージョンでは、既定で writethroughalternatewritethrough を使用しません。強制フラッシュ動作を使用するためです。 トレース フラグ 3979 では、データベースおよびトランザクション ログ ファイルに対する強制フラッシュ動作の使用を無効にし、writethrough ロジックと alternatewritethrough ロジックを使用します。

  • データベース スナップショット、データベース整合性チェック用の内部スナップショット (DBCC CHECKDB)、プロファイラー トレース ファイル、拡張イベント トレース ファイルなど、SQL Serverで FILE_FLAG_WRITE_THROUGH を使用して開かれるその他のファイルでは、writethroughalternatewritethrough の最適化が使用されます。

SQL Server 2017 (14.x) CU 6 で導入された変更について詳しくは、KB 4131496 を参照してください。 強制ユニット アクセス (FUA) の内部構造について詳しくは、FUA の内部構造に関する記事を参照してください。

SQL Server と強制ユニット アクセス (FUA) I/O サブシステム機能

サポートされている Linux ディストリビューションの特定のバージョンでは、データの持続性を提供する FUA I/O サブシステム機能がサポートされます。 SQL Server では FUA 機能を使用して、SQL Server のワークロードに対して非常に効率的で信頼性の高い I/O を提供します。 Linux ディストリビューションによる FUA サポートと SQL Server へのその影響について詳しくは、「SQL Server On Linux: 強制ユニット アクセス (FUA) の内部構造」を参照してください。

SUSE Linux Enterprise Server 12 SP5、Red Hat Enterprise Linux 8.0、Ubuntu 18.04 では、I/O サブシステムでの FUA 機能のサポートが導入されています。 SQL Server 2017 (14.x) CU 6 以降のバージョンを使う場合は、SQL Server による FUA でのハイ パフォーマンスで効率的な I/O 実装のために、次の構成を使用する必要があります。

次の条件が満たされている場合は、次の推奨構成を使用してください。

  • SQL Server 2017 (14.x) CU 6 以降のバージョン

  • FUA 機能をサポートする Linux ディストリビューションとバージョン (Red Hat Enterprise Linux 8.0、SUSE Linux Enterprise Server 12 SP5、または Ubuntu 18.04 以降)

  • SQL Server ストレージ用の XFS ファイル システム

  • FUA 機能をサポートし、そのために構成されている記憶域サブシステムまたはハードウェア、およびその両方

推奨構成:

  1. 起動時のパラメーターとしてトレース フラグ 3979 を有効にします。

  2. mssql-conf を使用して、control.writethrough = 1control.alternatewritethrough = 0 を構成します。

上記の条件を満たさない他のほぼすべての構成については、次のように構成することをお勧めします。

  1. トレース フラグ 3982 を起動時のパラメーターとして有効にし (Linux エコシステムの SQL Server に対する既定値です)、トレース フラグ 3979 が起動時のパラメーターとして有効になっていないことを確認します。

  2. mssql-conf を使用して、control.writethrough = 1control.alternatewritethrough = 1 を構成します。

Kubernetes にデプロイされた SQL Server コンテナーに対する FUA のサポート

  1. SQL Server では、overlayfs ではなく、マウントされた永続化ストレージを使用する必要があります。

  2. ストレージは XFS ファイルシステムを使用し、FUA をサポートする必要があります。 この設定を有効にする前に、お使いの Linux ディストリビューションおよびストレージ ベンダーと協力して、OS とストレージ サブシステムが FUA オプションをサポートしていることを確認する必要があります。 Kubernetes では、次のコマンドを使用してファイルシステムの種類に対するクエリを実行できます。ここで <pvc-name>PersistentVolumeClaim です。

    kubectl describe pv <pvc-name>
    

    出力内で、XFS に設定されている fstype を探します。

  3. SQL Server ポッドをホスティングするワーカー ノードは、FUA 機能をサポートする Linux ディストリビューションとバージョンを使用する必要があります (Red Hat Enterprise Linux 8.0、SUSE Linux Enterprise Server 12 SP5、または Ubuntu 18.04 以降)。

上記の条件が満たされている場合は、次の推奨 FUA 設定を使用できます。

  1. 起動時のパラメーターとしてトレース フラグ 3979 を有効にします。

  2. mssql-conf を使用して、control.writethrough = 1control.alternatewritethrough = 0 を構成します。