Skip to main content
Enterprise applications
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

論理インターフェイス

共同作成者 kaminis85
PDF

Oracleデータベースにはストレージへのアクセスが必要です。Logical Interface（LIF；論理インターフェイス）は、Storage Virtual Machine（SVM）をネットワークに接続し、さらにデータベースに接続するネットワーク配管です。各データベースワークロードに十分な帯域幅を確保し、フェイルオーバーによってストレージサービスが失われないようにするには、LIFを適切に設計する必要があります。

このセクションでは、SAN のみの環境向けに最適化されたASA r2 システムの主要な LIF 設計原則の概要を説明します。より詳しい説明については、 "ONTAPネットワーク管理に関するドキュメント"。データベース アーキテクチャの他の側面と同様に、ストレージ仮想マシン (SVM、CLI では vserver と呼ばれる) と論理インターフェイス (LIF) の設計に最適なオプションは、スケーリング要件とビジネス ニーズに大きく依存します。

LIFの戦略を立てる際は、主に次の点を考慮してください。

  • *パフォーマンス。*ネットワーク帯域幅は Oracle ワークロードに十分ですか?

  • *耐障害性。*設計に単一点障害はありますか？

  • *管理性。*ネットワークを無停止で拡張できますか？

これらのトピックは、ホストからスイッチ、ストレージシステムまで、エンドツーエンドの解決策に適用されます。

LIFタイフ

LIFには複数のタイプがあります。 "LIFタイプに関するONTAPのドキュメント" このトピックのより包括的な情報を提供しますが、機能的にはLIFを次のグループに分類できます。

  • *クラスタおよびノードの管理LIF。*ストレージクラスタの管理に使用するLIF。

  • * SVM管理LIF。* REST APIまたはONTAPI（ZAPIとも呼ばれます）を使用してSVMへのアクセスを許可するインターフェイス。Snapshotの作成やボリュームのサイズ変更などの機能に使用できます。SnapManager for Oracle（SMO）などの製品では、SVM管理LIFにアクセスする必要があります。

  • *データ LIF*SAN プロトコル専用のインターフェース: FC、iSCSI、NVMe/FC、NVMe/TCP。NAS プロトコル (NFS、SMB/CIFS) はASA r2 システムではサポートされていません。

メモ 両方とも IP プロトコルを使用しているにもかかわらず、iSCSI (または NVMe/TCP) と管理トラフィックの両方にインターフェイスを構成することはできません。iSCSI または NVMe/TCP 環境では、個別の管理 LIF が必要です。回復力とパフォーマンスを確保するには、ノードごとにプロトコルごとに複数の SAN データ LIF を構成し、それらを異なる物理ポートとファブリックに分散します。AFF/ FASシステムとは異なり、 ASA r2 では NFS または SMB トラフィックが許可されないため、NAS データ LIF を管理用に再利用するオプションはありません。

SAN LIFの設計

SAN環境でのLIFの設計は、マルチパスという1つの理由で比較的簡単です。最新のSAN実装では、クライアントは複数の独立したネットワークパス経由でデータにアクセスし、アクセスに最適なパス（複数可）を選択できます。その結果、SANクライアントは使用可能な最適なパス間でI/Oの負荷を自動的に分散するため、パフォーマンスに関してはLIFの設計は容易に対処できます。

あるパスが使用できなくなった場合、クライアントは自動的に別のパスを選択します。その結果、設計がシンプルになるため、一般にSAN LIFの管理性が向上します。だからといって、SAN環境の方が常に簡単に管理できるわけではありません。SANストレージには、NFSよりもはるかに複雑な要素が多数あるからです。単純に、SAN LIFの設計が容易であることを意味します。

パフォーマンス

SAN 環境における LIF パフォーマンスに関する最も重要な考慮事項は帯域幅です。たとえば、ノードごとに 2 つの 32Gb FC ポートを備えた 2 ノードのASA r2 クラスタでは、各ノードとの間で最大 64Gb の帯域幅が許可されます。同様に、NVMe/TCP または iSCSI の場合、Oracle ワークロードに十分な 25GbE または 100GbE 接続を確保します。

耐障害性

SAN LIF は、NAS LIF と同じ方法でフェイルオーバーません。ASA r2 システムは、回復力のためにホスト マルチパス (MPIO/ALUA) に依存します。コントローラのフェイルオーバーにより SAN LIF が使用できなくなった場合、クライアントのマルチパス ソフトウェアはパスの損失を検出し、I/O を代替パスにリダイレクトします。ASA r2 は、完全パスの可用性を回復するために、少し遅れて LIF の再配置を実行する場合があります。ただし、パートナー ノードにアクティブ パスがすでに存在するため、これによって I/O が中断されることはありません。定義されたすべてのポートでのホスト アクセスを復元するために、フェイルオーバー プロセスが実行されます。

管理性

HA ペア内でボリュームが再配置される場合、SAN 環境で LIF を移行する必要はありません。これは、ボリュームの移動が完了すると、 ONTAP がパスの変更について SAN に通知を送信し、SAN クライアントが自動的に再最適化を行うためです。SAN を使用した LIF の移行は、主に主要な物理ハードウェアの変更を伴います。たとえば、コントローラの無停止アップグレードが必要な場合、SAN LIF は新しいハードウェアに移行されます。FC ポートに障害があることが判明した場合、LIF を未使用のポートに移行できます。

設計上の推奨事項

NetApp は、 ASA r2 SAN 環境に対して次の推奨事項を示しています。

  • 必要以上の数のパスを作成しないでください。パスの数が多すぎると管理全体が複雑になり、一部のホストでのパスのフェイルオーバーで原因の問題が発生する可能性があります。さらに、一部のホストでは、SANブートなどの構成でパスが予期せず制限されます。

  • ごく少数の構成では、LUNへのパスが4つ以上必要です。LUNにパスをアドバタイズするノードが3つ以上あると、LUNを所有するノードとそのHAパートナーに障害が発生した場合、LUNをホストしているアグリゲートにアクセスできなくなるため、その価値には制限があります。このような状況では、プライマリHAペア以外のノードにパスを作成しても役に立ちません。

  • 参照可能なLUNパスの数はFCゾーンに含めるポートを選択することで管理できますが、一般には、ターゲットとなるポイントをすべてFCゾーンに含め、LUNの可視性をONTAPレベルで制御する方が簡単です。

  • デフォルトで有効になっている選択的 LUN マッピング (SLM) 機能を使用します。SLM を使用すると、新しい LUN は、基盤となるアグリゲートを所有するノードとそのノードの HA パートナーから自動的にアドバタイズされます。この配置により、ポート セットを作成したり、ポートのアクセス可能性を制限するためにゾーニングを構成したりする必要がなくなります。各 LUN は、最適なパフォーマンスと回復力の両方に必要な最小限の数のノードで利用できます。

  • LUNを2つのコントローラの外部に移行する必要がある場合は、追加のノードを次のように追加できます。 lun mapping add-reporting-nodes コマンドを実行して、LUN が新しいノードでアドバタイズされるようにします。これにより、LUN 移行用の LUN への追加の SAN パスが作成されます。ただし、新しいパスを使用するには、ホストで検出操作を実行する必要があります。

  • 間接トラフィックを過度に気にしないでください。I/Oが大量に発生する環境ではレイテンシがマイクロ秒単位で重要になるため、間接トラフィックは避けることを推奨しますが、一般的なワークロードではパフォーマンスに目に見える影響はごくわずかです。