Solaris ZFS - 一般的な Oracle 設定 - テクニカルレポート Data ONTAP を基盤にした Oracle データベースネットアップ Jeffrey Steiner

9 一般的な Oracle 設定

20.3 Solaris ZFS

優れたパフォーマンスを実現するためには、Solaris ZFSをインストールして注意深く設定してください。

カーネル

信頼できるZFSパフォーマンスを実現するには、LUNのアライメント問題に対するパッチをSolaris カーネルに適用する必要があります。この修正は、Solaris 10のパッチ147440-19と Solaris 11の SRU 10.5に含まれています。ZFSではSolaris 10以降のみを使用してください。

LUN 構成

LUNを構成するには、次の手順を実行します。

1. タイプがsolarisのLUNを作成します。

2. IMTで指定されているホストユーティリティキット（HUK）をインストールします。

3. HUKの指示に忠実に従います。基本の手順についてはこのセクションで大まかに説明しますが、

詳しい手順は最新のドキュメントを参照してください。

a. host_configユーティリティを実行してsd.conf/sdd.confファイルを更新します。

SCSIドライブがData ONTAPのLUNを正しく検出できるようになります。

b. host_configユーティリティの指示に従い、マルチパスI/O（MPIO）を有効にします。

c. リブートします。この手順は、変更をシステム全体に認識させるために必要です。

4. LUNをパーティショニングし、適切にアライメントされていることを確認します。アライメントを直接テストして確認する方法については、「付録3：WAFLアライメントの検証」を参照してください。

zpool

zpoolを作成する場合は、その前に「LUN構成」セクションの手順を実行してください。この手順を

正しく完了しないと、I/Oのアライメントが原因で、深刻なパフォーマンス低下が起きる恐れがあります。Data ONTAPのパフォーマンスを最適化するためには、I/Oがディスクの4Kの境界にアライメントされている必要があります。zpool上に作成されたファイルシステムは、パラメータashift で制御される実効ブロックサイズを使用します。これは、コマンドzdb -Cを実行することで確認できます。

ashiftのデフォルト値は9で、これは2^9、つまり512バイトを意味します。パフォーマンスを最適化するには、ashiftの値が12（2^12=4K）である必要があります。この値はzpoolの作成時に設定され、変更はできません。つまり、ashiftが12以外のzpoolのデータは、新しく作成したzpoolにデータを複製して移行する必要があります。

zpoolを作成したら、次に進む前にashiftの値を確認してください。値が12以外の場合はLUN が正しく検出されていないので、作成したzpoolを削除し、関連するホストユーティリティのドキュメントに記載された手順をすべて正しく実行したかどうかを確認し、再度zpoolを作成します。

zpool と Solaris LDOM

Solaris LDOMには、I/Oのアライメントが正しくなければならないもう1つの要件があります。

LUNが4Kデバイスとして正しく検出されても、LDOM上の仮想vdskデバイスにはI/Oドメインの設定が引き継がれません。そのLUNを基盤にしたvdskは、デフォルトの512バイトブロックに戻ります。

追加の構成ファイルが必要です。まず個々のLDOMにOracleのバグ15824910のパッチを適用し、

設定オプションを追加できるようにします。このパッチは、現在使用されているすべてのSolarisバージョンに組み込み済みです。LDOMにパッチを適用すると、適切にアライメントされた新しいLUNを設定できるようになります。手順は次のとおりです。

1. まず、新しいzpoolで使用するLUNを指定します。この例ではc2d1デバイスです。

root@LDOM1 # echo | format Searching for disks...done AVAILABLE DISK SELECTIONS:

0. c2d0 <Unknown-Unknown-0001-100.00GB>

/virtual-devices@100/channel-devices@200/disk@0

1. c2d1 <SUN-ZFS Storage 7330-1.0 cyl 1623 alt 2 hd 254 sec 254>

/virtual-devices@100/channel-devices@200/disk@1 2. ZFS poolに使用するデバイスのvdcインスタンスを取得します。

root@LDOM1 # cat /etc/path_to_inst

# # Caution! This file contains critical kernel state

# "/fcoe" 0 "fcoe"

"/iscsi" 0 "iscsi"

"/pseudo" 0 "pseudo"

"/scsi_vhci" 0 "scsi_vhci"

"/options" 0 "options"

"/virtual-devices@100" 0 "vnex"

"/virtual-devices@100/channel-devices@200" 0 "cnex"

"/virtual-devices@100/channel-devices@200/disk@0" 0 "vdc"

"/virtual-devices@100/channel-devices@200/pciv-communication@0" 0 "vpci"

"/virtual-devices@100/channel-devices@200/network@0" 0 "vnet"

"/virtual-devices@100/channel-devices@200/network@1" 1 "vnet"

"/virtual-devices@100/channel-devices@200/network@2" 2 "vnet"

"/virtual-devices@100/channel-devices@200/network@3" 3 "vnet"

"/virtual-devices@100/channel-devices@200/disk@1" 1 "vdc" << We want this one

3. /platform/sun4v/kernel/drv/vdc.confを編集します。

block-size-list="1:4096";

デバイスインスタンス1には、4,096のブロックサイズが割り当てられます。

もう1つの例として、vdskのインスタンス1～6を4Kのブロックサイズに構成する必要があり、/etc/path_to_instが以下のように設定されているとします。

"/virtual-devices@100/channel-devices@200/disk@1" 1 "vdc"

"/virtual-devices@100/channel-devices@200/disk@2" 2 "vdc"

"/virtual-devices@100/channel-devices@200/disk@3" 3 "vdc"

"/virtual-devices@100/channel-devices@200/disk@4" 4 "vdc"

"/virtual-devices@100/channel-devices@200/disk@5" 5 "vdc"

"/virtual-devices@100/channel-devices@200/disk@6" 6 "vdc"

4. 編集後のvdc.confファイルは次のようになります。

block-size-list="1:8192","2:8192","3:8192","4:8192","5:8192","6:8192";

注意

vdc.confを設定およびvdskを作成したあと、LDOMをリブートする必要があります。この手順は省略しないでください。ブロックサイズの変更が有効になるのはリブートのあとです。zpoolの設定を続行し、前述のように、ashiftが正しく12に設定されていることを確認してください。

ZIL

一般に、ZFS Intent Log（ZIL）を別のデバイスに配置する理由はありません。このログはメインのプールとスペースを共有できます。ZILを別に使用する主な理由は、最新のストレージアレイで書き込みキャッシュ機能を備えていない物理ドライブを使用する場合です。

logbias

OracleデータをホストするZFSファイルシステムでは、logbiasパラメータを設定します。

zfs set logbias=throughput <filesystem>

このパラメータを使用すると、全体的な書き込み量が削減されます。デフォルトでは、書き込みデータはまずZILにコミットされ、その後メインのストレージプールにコミットされます。この手法では、最も低レイテンシのメディア上の単一のI/Oトランザクションでデータがコミットされるため、

SSDベースのZILデバイスおよびメインのストレージプール用の回転式メディアなど、シンプルなディスク構成に適しています。

独自のキャッシュ機能を備えた最新のストレージアレイを使用する場合、この手法は通常必要ありません。例えばレイテンシの影響を受けやすいランダムライトが大量に発生するワークロードなど、

ごくまれな状況においては、単一のトランザクションで書き込みをログにコミットした方が望ましい場合があります。ログに書き込まれたデータは最終的にメインのストレージプールに書き込まれるため、書き込み処理が二重に発生し、ライトアンプリフィケーションという状況を招きます。

ダイレクト I/O

Oracle製品を含め、多くのアプリケーションでは、ダイレクトI/Oを有効にすることでホストのバッ

ファキャッシュを迂回できます。ただしZFSファイルシステムでは想定する結果が得られず、ホストのバッファキャッシュが迂回されてもZFS自体がデータをキャッシュし続けます。この場合、

I/Oがストレージシステムに達しているかどうか、またはI/OがOSにローカルにキャッシュされているかどうかの予測が難しく、fioやsioなどのツールを使用してパフォーマンステストを実行すると誤った結果になることがあります。また、こうした総合的なテストで、ZFSと他のファイルシステムのパフォーマンスを比較することもきわめて難しくなります。現実には、実際のユーザワークロードでファイルシステムのパフォーマンスにほとんど違いはありません。

複数の zpool

ZFSベースのデータを、Snapshotをベースにバックアップ、リストア、クローニング、アーカイブする処理は、zpoolレベルで実行する必要があり、通常は複数のzpoolが必要です。zpoolはLVM ディスクプールに似ており、同じルールで構成する必要があります。例えばデータベースの場合、

データファイルをzpool1に、アーカイブログ、制御ファイル、Redoログをzpool2に配置するレイアウトが最も適しています。このレイアウトでは、データベースがホットバックアップモードに設定される標準のホットバックアップを実行し、続けてzpool1のSnapshotコピーを実行できます。次にデータベースのホットバックアップモードが解除され、ログがアーカイブされ、

zpool2のSnapshotコピーが作成されます。リストア処理では、ZFSファイルシステムをアンマウントしてzpoolを完全にオフラインにし、続けてSnapRestoreのリストア処理を実行します。その後、zpoolを再度オンラインにしてデータベースをリカバリできます。

filesystemio_options

Oracleパラメータfilesystemio_optionsは、ZFSでは異なる動作をします。setallまたは directioを使用した場合、書き込み処理は同期されてOSのバッファキャッシュを迂回しますが、

読み取りはZFSによってバッファされます。この場合、I/OがZFSキャッシュによって代わりに処理されることがあるため、ストレージのレイテンシと総I/Oが表示される値よりも低くなり、パフォーマンス分析が困難になります。

21 まとめ

本ドキュメントの冒頭で述べたように、Oracle環境のストレージ構成は、環境による違いがあまりにも大きいため、本当の意味でのベストプラクティスはほとんどありません。データベースプロジェクト1つ取ってみても、ミッションクリティカルなデータベース1つで構成されていることもあれば、5,000のレガシーデータベースで構成されていることもあり、規模も数ギガバイトから数百テラバイトと様々です。クラスタウェアや仮想化などのオプションを使用すると、さらに多様になります。

ドキュメント内テクニカルレポート Data ONTAP を基盤にした Oracle データベースネットアップ Jeffrey Steiner 2016 年 11 月 TR-3633 重要本レポートに指定された環境構成バージョンがお客様の環境に対応しているかどうかは Interoperability Mat (ページ 53-72)