Linux の場合
Linux OSに固有の設定に関するトピック。
Linux NFSv3 TCPスロットテーブル
TCPスロットテーブルは、NFSv3でホストバスアダプタ(HBA)のキュー深度に相当します。一度に未処理となることのできるNFS処理の数を制御します。デフォルト値は通常16ですが、最適なパフォーマンスを得るには小さすぎます。逆に、新しいLinuxカーネルでTCPスロットテーブルの上限をNFSサーバが要求でいっぱいになるレベルに自動的に引き上げることができるため、問題が発生します。
パフォーマンスを最適化し、パフォーマンスの問題を回避するには、TCPスロットテーブルを制御するカーネルパラメータを調整します。
を実行します sysctl -a | grep tcp.*.slot_table コマンドを実行し、次のパラメータを確認します。
# sysctl -a | grep tcp.*.slot_table sunrpc.tcp_max_slot_table_entries = 128 sunrpc.tcp_slot_table_entries = 128
すべてのLinuxシステムに sunrpc.tcp_slot_table_entries`ただし、次のようなものがあります。 `sunrpc.tcp_max_slot_table_entries。どちらも128に設定する必要があります。
|
|
これらのパラメータを設定しないと、パフォーマンスに大きく影響する可能性があります。Linux OSが十分なI/Oを発行していないためにパフォーマンスが制限される場合もあります。一方では、Linux OSが問題で処理できる以上のI/Oを試行すると、I/Oレイテンシが増加します。 |
Linux NFSv4.X セッションスロット
NFSセッションスロットは、NFSv4.XにおけるNFSv3スロットテーブルに相当するものです。デフォルト値は通常64です。180という値は、ONTAPのセッション制限と一致するため最適です。
max_session_slots パラメータの設定例:
# cat /etc/modprobe.d/nfsclient.conf options nfs max_session_slots=180
起動時にロードされるカーネルモジュールがこのパラメータを使用します。NFSv3のスロットテーブルパラメータとは異なり、動的ではありません。変更を有効にするには、再起動が必要です。
|
|
これらのパラメータを設定しないと、パフォーマンスに重大な影響を与える可能性があります。linux OSが十分なI/Oを発行していないため、パフォーマンスが著しく制限される可能性があります。 |
Linux NFSのマウントオプション
次の表に、単一インスタンスのLinux NFSのマウントオプションを示します。
| ファイルタイプ | マウントオプション |
|---|---|
ADRホーム |
|
制御ファイル データファイル REDO ログ |
|
ORACLE_HOME を参照してください |
|
次の表に、RACのLinux NFSマウントオプションを示します。
| ファイルタイプ | マウントオプション |
|---|---|
ADRホーム |
|
制御ファイル データ・ファイル REDO ログ |
|
CRS /投票 |
|
専用 |
|
共有 |
|
シングルインスタンスとRACマウントオプションの主な違いは、 actimeo=0 をマウントオプションに移動します。このオプションを使用するとホストOSのキャッシングが無効になるため、データの状態について、RACクラスタ内のすべてのインスタンスが一貫した情報を認識できるようになります。ただし、 init.ora パラメータ filesystemio_options=setall ホストのキャッシングを無効にした場合と同じ効果がありますが、引き続きを使用する必要があります。 actimeo=0。
理由 actimeo=0 共有の場合は必須です ORACLE_HOME を導入すると、Oracleパスワードファイルやspfileなどのファイルの整合性が維持されます。RACクラスタ内の各インスタンスに専用の `ORACLE_HOME`の場合、このパラメータは必要ありません。
一般に、データベース以外のファイルは、シングルインスタンスのデータファイルと同じオプションを使用してマウントします。ただしアプリケーションによっては要件が異なる場合があります。マウントオプションを使用しない noac および actimeo=0 これらのオプションは、ファイルシステムレベルの先読みとバッファリングを無効にするため、可能であれば可能です。これにより、原因抽出、変換、ロードなどのプロセスで重大なパフォーマンスの問題が発生する可能性があります。
ACCESSとGETATTR
一部のお客様は、ACCESSやGETATTRなどのIOPSがワークロードを占有する可能性が非常に高いことを指摘しています。極端なケースでは、読み取りや書き込みなどの処理が全体の10%にまで低下することがあります。これは、を含むデータベースでは正常に動作します。 actimeo=0 および / または noac Linuxの場合:これらのオプションは、Linux OSを原因して、ストレージシステムからファイルメタデータを定期的にリロードします。ACCESSやGETATTRなどの処理は影響力の低い処理で、データベース環境ではONTAPキャッシュから処理されます。読み取りや書き込みなど、ストレージシステムに真の需要を生み出す純粋なIOPSとみなすべきではありません。ただし、特にRAC環境では、これらのIOPSにはある程度の負荷がかかります。この状況に対処するには、DNFSを有効にして、OSのバッファキャッシュをバイパスし、不要なメタデータ処理を回避します。
nconnect
nconnectは比較的新しいマウントオプションです。これにより、NFSクライアントは指定されたマウントポイントに対して複数の独立したTCP/IP接続を開き、I/Oを多重化することが可能になります。その結果、インフライトの処理が増加し、特に高帯域幅ネットワークにおいてパフォーマンスが向上します。linuxでサポートされている最大値は16ですが、NetAppは4~8の値を推奨します。その結果、単一インスタンスのパフォーマンスは、単一パス用に構成されたdNFSクライアントと同等のものとなります。dNFSとは異なり、nconnectは複数のIPアドレスとTCP/IPリンクにまたがる多重化構成を行うことはできません。
RACを使用する場合、追加のメタデータトラフィックが発生するため、nconnectはdNFSよりもパフォーマンス オーバーヘッドが大きくなります。詳細については、link:#Linux%20Direct%20NFS%20and Oracle %20AC[Linux Direct NFS and Oracle RAC]を参照してください。
Linux Direct NFS
(a)DNFSが有効で、(b)ソースNFS共有が単一のサーバに複数回マウントされ、(c)ネストされたNFSマウントがある場合、 `nosharecache`と呼ばれる追加のマウントオプションが必要です。この構成は、主にSAPアプリケーションをサポートする環境で見られます。たとえば、NetAppシステム上の単一のNFS共有に、 `/vol/oracle/base`にあるディレクトリと `/vol/oracle/home`にある2つ目のディレクトリがあるとします。 `/vol/oracle/base`が `/oracle`にマウントされ、 `/vol/oracle/home`が `/oracle/home`にマウントされている場合、同じソースから発生するネストされたNFSマウントになります。
OSは、 `/oracle`と `/oracle/home`が同じソース ファイル システムである同じNFS共有に存在することを検出できます。その後、OSはデータへのアクセスに同じデバイス ハンドルを使用します。これにより、OSキャッシングやその他の特定の処理の利用が向上しますが、DNFSと干渉します。DNFSが `/oracle/home`上の `spfile`などのファイルにアクセスする必要がある場合、誤ってデータへの間違ったパスを使用しようとする可能性があります。その結果、I/O処理が失敗します。これらの構成では、そのホスト上の別のNFSファイル システムとソースNFS共有を共有するすべてのNFSファイル システムに、 `nosharecache`マウント オプションを追加します。これにより、Linux OSは強制的にそのファイル システムに独立したデバイス ハンドルを割り当てます。
Linux Direct NFSとOracle RAC
DNFSを使用することで、Linux OS上のOracle RACにおいて特別なパフォーマンス上のメリットが得られます。これは、Linuxには直接I/Oを強制する手段がなく、RACではノード間の整合性を保つために直接I/Oが必要となるためです。回避策として、Linuxでは `actimeo=0`マウントオプションを使用する必要があります。これにより、ファイルデータはOSキャッシュから即座に破棄されます。このオプションにより、Linux NFSクライアントは属性データを常に再読み込みすることになり、その結果、レイテンシとストレージコントローラへの負荷が増加します。
DNFSを有効にすると、ホストNFSクライアントをバイパスし、この問題を回避できます。複数のお客様から、DNFSを有効にした際にRACクラスターのパフォーマンスが大幅に向上し、ONTAPの負荷(特に他のIOPSに関して)が大幅に減少したと報告されています。
Linux Direct NFSとoranfstabファイル
マルチパスオプションを指定してLinuxでDNFSを使用する場合は、複数のサブネットを使用する必要があります。他のOSでは、を使用して複数のDNFSチャネルを確立できます。 LOCAL および DONTROUTE 単一のサブネット上に複数のDNFSチャネルを設定するためのオプション。ただし、これはLinuxでは正しく機能せず、予期しないパフォーマンスの問題が発生する可能性があります。Linuxでは、DNFSトラフィックに使用するNICをそれぞれ別 々 のサブネットに配置する必要があります。
I/Oスケジューラ
Linuxカーネルでは、ブロックデバイスへのI/Oのスケジュール方法を低レベルで制御できます。デフォルト値はLinuxのディストリビューションによって大きく異なります。テストでは、通常はDeadlineが最良の結果を提供することが示されていますが、場合によってはNOOPがわずかに改善されています。パフォーマンスの違いはごくわずかですが、データベース構成から最大限のパフォーマンスを引き出す必要がある場合は、両方のオプションをテストしてください。CFQは多くの構成でデフォルトであり、データベースワークロードのパフォーマンスに重大な問題があることが実証されています。
I/Oスケジューラの設定手順については、該当するLinuxベンダーのドキュメントを参照してください。
マルチパス
一部のお客様では、マルチパスデーモンがシステムで実行されていなかったために、ネットワーク停止中にクラッシュが発生しました。最近のバージョンのLinuxでは、OSとマルチパスデーモンのインストールプロセスによって、これらのOSがこの問題に対して脆弱なままになる可能性があります。パッケージは正しくインストールされていますが、再起動後の自動起動が設定されていません。
たとえば、RHEL5.5のマルチパスデーモンのデフォルトは次のようになります。
[root@host1 iscsi]# chkconfig --list | grep multipath multipathd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
これを修正するには、次のコマンドを使用します。
[root@host1 iscsi]# chkconfig multipathd on [root@host1 iscsi]# chkconfig --list | grep multipath multipathd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
ASMミラーリング
ASM ミラーリングでは、 ASM が問題を認識して代替の障害グループに切り替えるために、 Linux マルチパス設定の変更が必要になる場合があります。ONTAP 上のほとんどの ASM 構成では、外部冗長性が使用されます。つまり、データ保護は外部アレイによって提供され、 ASM はデータをミラーリングしません。一部のサイトでは、通常の冗長性を備えた ASM を使用して、通常は異なるサイト間で双方向ミラーリングを提供しています。
に表示されるLinux設定 "NetApp Host Utilitiesのマニュアル" I/Oが無期限にキューイングされるマルチパスパラメータを指定します。つまり、アクティブなパスがないLUNデバイス上のI/Oは、I/Oが完了するまで待機します。これは、SANパスの変更が完了するまで、FCスイッチがリブートするまで、またはストレージシステムがフェイルオーバーを完了するまで、Linuxホストが必要な時間だけ待機するために、通常は推奨されます。
この無制限のキューイング動作により、ASMミラーリングで問題が発生します。ASMは、代替LUNでI/Oを再試行するためにI/O障害を受信する必要があるためです。
Linuxで次のパラメータを設定します。 multipath.conf ASMミラーリングで使用されるASM LUNのファイル:
polling_interval 5 no_path_retry 24
これらの設定により、ASMデバイスに120秒のタイムアウトが作成されます。タイムアウトは、 polling_interval * no_path_retry 秒として。状況によっては正確な値の調整が必要になる場合がありますが、ほとんどの場合は120秒のタイムアウトで十分です。具体的には、コントローラのテイクオーバーまたはギブバックが120秒以内に実行され、I/Oエラーが発生しないようにしてください。この場合、障害グループはオフラインになります。
A下限 no_path_retry この値を指定すると、ASMが代替障害グループに切り替えるのに必要な時間を短縮できますが、これにより、コントローラのテイクオーバーなどのメンテナンス作業中に不要なフェイルオーバーが発生するリスクも高まります。ASMミラーリングの状態を注意深く監視することで、このリスクを軽減できます。不要なフェイルオーバーが発生した場合、再同期が比較的短時間で実行されると、ミラーを迅速に再同期できます。追加情報については、使用しているOracleソフトウェアのバージョンに対応するASM高速ミラー再同期に関するOracleのマニュアルを参照してください。
Linuxのxfs、ext3、ext4のマウントオプション
|
|
* NetAppでは*デフォルトのマウントオプションを使用することを推奨しています。 |