OCI File Storage上のE-Business Suite: デプロイメントおよび構成のベスト・プラクティス (2023/03/16)

OCI File Storage上のE-Business Suite: デプロイメントおよび構成のベスト・プラクティス (2023/03/16)

https://blogs.oracle.com/cloud-infrastructure/post/ebs-fss-deployment-configuration-best-practices

投稿者: Vinoth Krishnamurthy


Oracle E-Business Suite(EBS)は、Oracleの主要な製品ラインの1つです。EBSは、複数のアプリケーション層ノードおよびサーバーにアプリケーションサービスを分散およびロードバランシングすることで、より高いパフォーマンスを実現します。これらのサーバーでは、同じファイルシステムを同時に読取りおよび書込みする必要があり、すべてのアプリケーション層ノードにマウントできる共有ファイルシステムが必要です。また、共有ファイルシステムにより、ノード障害に対する高可用性と高い耐障害性が向上します。


多くのお客様は、Oracle Cloud Infrastructure(OCI)上でEBSアプリケーションを実行し、オンプレミスまたは他のクラウド・プロバイダから移行するプロセスにおいて、より多くのことを行っています。OCI File Storageサービスは、最大8エクサバイトまで自動的にスケーリングする、フルマネージドなエラスティック・ファイルシステムです。NFSv3マウント・ポイントを介してアクセスできます。OCI File Storageには次の利点があります。


  • デプロイが容易: 数回のクリックで、共有ファイルシステムを作成してOCI Computeインスタンスにマウントできます。詳細な手順については、「ファイルシステムの作成およびファイルシステムのマウント」を参照してください。
  • Elastic: ストレージを事前にプロビジョニングすることなく、ファイルシステムへの書込みを開始できます。ファイルシステムは最初のバイトから開始し、最大8エクサバイトまで書き込まれるときに自動的にスケーリングされます。お客様が支払うのはFile Storageに格納されたデータのみです。そのため、ストレージのプロビジョニングが不要で、初期費用やストレージ容量の計画が不要です。
  • 完全管理: サーバーへのパッチ適用などのオペレータのメンテナンス作業が不要になります。
  • 高可用性: ファイルシステム内のデータには常にアクセスできます。ファイルシステムのコンテンツは、ユーザーによって完全に所有および制御されます。
  • 耐久性: ファイルシステム内のデータは、非常に一貫性が高く永続的です。



このブログでは、EBSシステムをインストールおよび保守するOracle Applicationsデータベース管理者およびアーキテクトが、共有ファイルシステムが必要なファイルストレージを利用してOCIにEBSのデプロイメントシナリオをいくつか提供し、最適なパフォーマンスのためのFile Storageの使用に関するベストプラクティスを提供します。



デプロイメントシナリオ


オンプレミスまたは他のクラウド・プロバイダからOCIへのリフト・アンド・シフトであれ、OCIでの新しい実装であれ、File Storageは、従来のネットワーク・アタッチ・ストレージ(NAS)アプライアンスまたはカスタムビルド・ネットワークファイルシステム(NFS)サーバーと同様に機能する共有ファイルシステムを提供し、運用の観点からシームレスにします。


EBSの運用ニーズに応じて、OCI File StorageをEBSシステムトポロジに組み込むための多くの導入アプローチと設計が可能です。EBSデータベース層では、RMANバックアップ、エクスポート先およびインポート先にFile Storageを使用することもできます。


次のイメージは、EBSデプロイメントのFile Storageに関する高レベルのサンプルトポロジを示しています。


図1: 複数のEBSアプリケーション、Webおよびデータベースサーバーで使用される単一のFile Storageマウントターゲットおよびファイルシステム



図2: 高いIOPS要件に対応した複数のファイルシステムとマウントターゲット


OCIシナリオでE-Business SuiteのOCI File StorageにEBSを実装すると、より多くのネットワークトポロジを見つけることができます。



ベストプラクティス


様々なEBSユーザーベースサイズと同時処理ボリュームを備えたOCI File Storageの多くのEBSデプロイメントの経験に基づいて、File Storageのパフォーマンスを最適化するためのいくつかのベストプラクティスを策定しました。



計画ステージ


  • リージョンおよび可用性ドメイン: 移行する必要があるEBS環境を現在実行しているオンプレミス・データ・センターまたは他のクラウドプロバイダに最も近いOCIリージョンを選択します。また、すべてのインスタンスとマウントターゲットを同じ可用性ドメインに格納することをお薦めします。ローカルピアリング接続またはリモートピアリング接続を使用することで、インスタンスおよびマウントターゲットを異なる可用性ドメインまたはリージョンに配置できますが、この構成によりレイテンシが増加し、パフォーマンスに影響する可能性があります。
  • Computeインスタンスイメージ: すべてのOracle LinuxイメージにはLinuxカーネルバージョンが付属しており、オペレーティングシステムコールの実行に若干の差異が示されています。カーネルバージョンが4.14.35.1902.301.1より前の Oracle Linux 6および7には、ディレクトリトラバースをループさせるNFSクライアントのバグがあるため、遅延が発生します。そのため、ls、du、find、rsync、chmod、chownなどのOS操作は、特にディレクトリに多くのファイルがある場合に、時間がかかる場合があります。EBSサーバーには常に最新のOracle Linuxイメージを使用していることを確認してください。
  • Computeインスタンスシェイプ: ネットワーク帯域幅およびCPU能力が高い大きいシェイプでは、同時操作を利用してパフォーマンスを改善できます。File Storageは、同時操作や大きな読取り/書込みサイズによりパフォーマンスが向上し、rsizeおよびwsizeのNFSマウントオプションによって処理されます。次の表に、異なるシェイプの2つのインスタンスでのEBS管理タスクの所要時間を示します。
  • 移行オプション: File Storageには現在、ファイル転送サービスがありません。Rsyncは、通常、ファイルシステムの同期に使用されます。サイズに応じて、移行するEBS環境の共有ファイルシステム、rsyncのパフォーマンスは多くの顧客に許容されます。転送速度を速くするには、fpsyncを推奨します。Fpsyncは、パラレルrsyncプロセスを生成することでrsyncをパラレルに実行するオープンソースユーティリティです。Fpsyncは並列転送を実現するために、より多くの計算能力を必要とします。rpmは、OCI Oracle Linuxのyumリポジトリ内で使用できます。fpsyncを使用してオンプレミスからOCI File Storageにファイルシステムデータをコピーするステップは、オンプレミスからFile Storageサービスへの同期を参照してください。
  • 単一のファイルシステム内のEBS環境の数: ファイルが作成されると、NFSサーバーによってそのファイルのファイル識別子が生成されます。File Storageは同じですが、64ビットの設計を使用するため、File Storageでファイルが削除されているにもかかわらず、ファイル識別子は常に増加します。32ビットであるプログラムでは、ファイル識別子が2**(32-1)、または4,294,967,295に達し、ファイルの作成が失敗した場合、ファイルの作成に制限があります。EBSでは、コンカレントマネージャや要求のログアウト・ファイルなどの古いファイルを定期的にパージする場合があります。ただし、この現象により、DeveloperのOracle Home実行可能ファイル(32ビット)などのEBSのプログラムは、新しいファイルを作成できません。影響には、tnspingが失敗する、アプリケーションサービスの起動スクリプトが正常に完了しないなどが含まれます。この状況は、単一のファイルシステムに格納されているEBS環境が多すぎる場合に発生します。そのため、OCIに移行する場合は、すべてのEBS環境を単一のファイルシステムに移行するのではなく、複数のファイルシステムを使用してください。また、FSSファイルシステムでEBS共有ファイルシステムを拡張する場合は、EBS環境のリフレッシュを実行するたびに新しいファイルシステムを使用してください。



実行ステージ


OCIでEBSを実行するための次のベストプラクティスは、インフラストラクチャレイヤーに基づいて分類されます。


ネットワークレイヤーでのイングレスおよびエグレスルールの構成: OCI File Storageのマウントターゲットは、1つ以上のエクスポートパスを介してファイルシステムへのアクセス権を付与するネットワークエンドポイントです。マウントターゲットは、同じサブネットまたは異なるサブネットおよび仮想クラウドネットワーク(VCN)に存在できます。マウントターゲットおよびComputeインスタンスがホストされているサブネットおよびVCNに応じたイングレスおよびエグレスルールの設定の詳細は、VCNへのセキュリティ・ルール構成を参照してください。インスタンスでコマンドshowmount -e <MountTarget_IPaddress>を実行して、マウントターゲットへの接続およびエクスポートを確認します。エクスポートパスが表示されない空のリストは、インスタンスからファイルシステムにアクセスできないことを意味します。


NFSレイヤーには、次のベストプラクティスがあります。


  • マウントターゲットのレポートされたサイズの設定: ファイルシステムを作成すると、デフォルトの論理最大サイズ制限は8エクサバイトになります。Oracle Universal Installer (OUI)などの32ビットプログラムを持つE-Business Suiteは、空き領域チェック中に8エクサバイトの値を読み取ることはできず、失敗します。「マウントターゲット」ページのレポートされたサイズフィールドでは、ユーザー定義の値を使用できます。値はいつでも変更でき、ファイルシステムを再マウントしたり、ファイルシステムがマウントされているインスタンスを再起動する必要はありません。この設定はエクスポートセットレベルであるため、変更はマウントターゲットの下のすべてのエクスポートに適用されます。
  • エクスポートオプションの使用: ネットワークセキュリティルールまたはネットワークセキュリティゲートウェイ(NSG)によってマウントターゲットにアクセスできるComputeインスタンスが決まりますが、ソースCIDRおよびアクセスモードを使用したエクスポートオプションによって、インスタンスとそのファイルシステムへのアクセスがさらに制限されます。たとえば、10.0.0.1/24 CIDRのインスタンスによるマウントターゲットへのアクセスを許可し、デフォルトのエクスポートオプションに0.0.0.0/0ソースCIDRを指定すると、10.0.0.1/24未満のすべてのインスタンスがファイルシステムにアクセスできます。ただし、10.0.0.1/24のうち、ファイルシステムへの読取り/書込みおよび読取り専用アクセス権を持つことができるものを指定できます。ファイルシステムへのクライアントアクセスの制御方法の詳細は、NFSエクスポート・オプションの作業を参照してください。
  • マウント: NFSクライアント(インスタンス)およびサーバー(File Storage)でNFSマウントオプションを自動的にネゴシエートする明示的なNFSマウントオプションを使用しないことをお薦めします。マウントオプションなしでマウントした後、grep <MountTarget_IPaddress> /proc/mountsコマンドを実行して、選択されているデフォルト値を確認できます。次のベストプラクティスをお薦めします。

    • 読取りおよび書込みのパフォーマンスを最適化するには、rsizeおよびwsizeのNFSマウントオプションの値を1,048,576未満に設定しないでください。指定しない場合、rsizeおよびwsizeのデフォルト値は1048576です。
    • 12.1.3 では、OACoreコンポーネントの設計要件のため、ノロックマウントオプションが必要です。12.2はweblogicサーバーで実行されるため、ノロックは必要ありません。
    • E-Business Suiteの同時処理のログディレクトリと出力ディレクトリは、多数のファイルを格納する傾向があり、これによってディレクトリトラバースパフォーマンスが低下する可能性があります。ls、du、find、rsyncなどのコマンドはディレクトリトラバースを実行し、より多くの時間を必要とします。mountコマンドでnordirplus mountオプション(-o nordirplus)を使用します。このコマンドは内部でディレクトリトラバース方式を変更するため、パフォーマンスが向上する可能性があります。
    • ネステッドマウントの回避: サブディレクトリマウントが許可されている間は、あいまいさが発生し、ファイル/フォルダ検索の問題が発生する可能性があるため、ネステッドマウントを回避してください。ネストされたマウントの例として、システムAが/mnt/File Storage-A/マウントポイントとしてマウントされ、ファイルシステムBが/mnt/File Storage-A/folder-Bとしてマウントされています。



アプリケーションレイヤーには次のベストプラクティスがあります。


EBSストレージスキームオプションを使用して、単一のログおよび出力フォルダ内のファイル数を制限できます。ストレージスキームでは、日付、製品、ファイル数などに基づいて、コンカレント処理要求のサブディレクトリ構造が作成されます。このように、1つのサブディレクトリ内のファイル数は、同時処理のログおよび出力ファイルの保持ポリシーに影響を与えずに比較的小さくできます。My Oracle Support Doc ID 2794300.1の「コンカレント処理ログおよび出力ファイルの場所の構成」セクションを参照してください。


表1: 2つの異なるシェイプで実行されているEBS 12.2の管理者タスクのパフォーマンス比較


Sl no

Administrative task

Command

VM.Standard2.2

VM.Standard2.24

1

Copy EBS app tier from local disk to File Storage

parcp -P <threads> /u01/install/APPS/fs1 /fss/install/APPS

where <threads> is number of threads that depends number of cpu cores.

parcp is part of File Storage parallel tools developed by the File Storage team and it parallel copies folders

11 min

threads: 32

5 min

threads: 96

2

Configure the EBS environment

perl adcfgclone.pl appsTier dualfs

116 min

99 min

3

Generate forms

workers=$((`nproc`*2))

adadmin workers=$workers interactive=n restart=y stdin=n menu_option=GEN_FORMS

50 min

7 min

4

Generate reports

workers=$((`nproc`*2))

adadmin workers=$workers interactive=n restart=y stdin=n menu_option=GEN_REPORTS

12 min

3 min

5

Generate product jar files

workers=$((`nproc`*2))

adadmin workers=$workers interactive=n restart=y stdin=n menu_option=GEN_JARS

22 min

13 min

6

Relinking application binaries

workers=$((`nproc`*2))

adadmin workers=$workers interactive=n restart=y stdin=n menu_option=RELINK

7 min

6 min

7

JSP compilation

perl ojspCompile.pl --compile --flush

33 min

24 min

8

Online patching prep phase

adop phase=prepare

134 min

57 min

9

Online patching fs_clone phase

adop phase=fs_clone force=yes

157 min

132 min

10

Prepare app tier for cloning

perl adpreclone.pl appsTier

18 min

11 min




自分で試してみる


次のステップでは、データベース層をローカルディスクに、アプリケーション層をOCI File Storageに、EBSシステムを構築できます。


  • Oracle Cloud Marketplaceには、12.2.8から12.2.11までのOracle E-Business Suiteリリース用のデモインストールイメージがあり、My Oracle Supportドキュメント2764690.1で単一ノードのEBS環境を準備するステップが用意されています。
  • ファイルシステムの作成」ドキュメントに従ってFile Storageリソースを作成し、「ファイルシステムのマウント」ドキュメントを使用してEBSインスタンスにファイルシステムをマウントします。
  • File Storageのマウントポイントがインスタンスで使用可能な場合は、実行エディションディレクトリfs1をFile Storageのマウントポイントにコピーします。コピーにはcp、rsyncまたはtarを使用できます。fss-parallel-toolsを確認して利用し、より高速なコピーを作成します。
  • コピーが完了したら、コマンドadcfgcloneを実行して、EBSアプリケーション・ファイルシステムを再構成します。
  • マルチノードエクスペリエンスのために新しいアプリケーションノードを追加するには、「Oracle E-Business Suite Release 12.2 with Rapid Clone (Doc ID 1383621.1)のクローニング」の項5.3「既存のシステムへの新しいアプリケーション層ノードの追加」を参照してください。


Oracle Cloud Infrastructure File Storageサービスのブートボリュームおよびマルチノードアプリケーション層にデータベースがあるE-Business Suite環境が、検討の準備ができました。


詳細は、次の資料を参照してください。


  • File Storageサービスとその機能(スナップショット、クローン、レプリケーションなど)の詳細は、OCI File Storageサービスのドキュメントを参照してください。
  • Oracle Cloud Infrastructure File Storageサービスを使用したOracle E-Business Suiteリリース12.2または12.1.3のアプリケーション層ファイルシステムの共有(ドキュメントID 2794300.1)
  • マウントの問題、ファイルアクセスの問題、またはパフォーマンスの問題に関係なく、File Storageサービスに問題が発生した場合は、サービスリクエストを作成する前にファイルシステムのトラブルシューティングに進みます。


コメント

このブログの人気の投稿

Oracle Database 19cサポート・タイムラインの重要な更新 (2024/11/20)

Oracle GoldenGate 23aiでMicrosoft Fabricでのオープン・ミラーリングがサポートされるようになりました (2024/11/19)

Oracle Database Service for Azure(ODSA)とOracle Interconnect for Azureの比較 (2022/08/15)