はじめに: データ/情報の計測単位

多くの場合、スループット・ネットワーク・ストレージは Mbps 単位または Gbps 単位で示されます。

Mb (メガビット) は 10 進数の接頭部であり、MiB (メビバイト) は 2 進数の接頭部なので、これらはスケールが異なることに注意してください。 また、MiB (メビバイト) は Microsoft Windows では一般にMegabyteと呼ばれていたため、さらなる混乱の原因となります。

これ以降のすべてのネットワーキングに関する記述では、Mb (メガビット) と MiB (メビバイト) は、IEC によって定義され、IEEE、国際標準化機構 (ISO)、および NIST で採用されている単位系 (SI) に基づいて使用されます。

以下に例を示します。

• 100 Mbps (メガビット/秒) は 12 MiB/s (メビバイト/秒)
• 1000 Mbps (メガビット/秒) (1 Gbps (ギガビット/秒) とも示される) は 120 MiB/s (メビバイト/秒)
• 10 Gbps (ギガビット/秒) は 1200 MiB/s (メビバイト/秒)

ネットワーキングの接続に関する考慮事項

使用可能な接続オプションの概要については、Determining access to your SAP system landscape を参照してください。

SAP システムには、多数の統合アプリケーション (レガシー・アプリケーションを含む) があり、多くの場合、ビジネス・オペレーションのフォーカル・ポイントとなります。

SAP ワークロードのほとんどの状況では、既存の内部ネットワークへの接続が必要になります。また、IBM Cloud® Direct Link 2.0 を使用し、ルーティングされた OSI レイヤー 2 または 3 接続として、安全で、低遅延、かつ高スループット (最大 10 Gbps が使用可能) の接続を行うことが推奨されます。

これらの接続オプションは、ビジネス要件によって異なります。例えば、ビジネスでクラウドを使用し、同時に既存のネットワーキング・インフラストラクチャーとセキュリティーを使用してネットワーク・フローを分離し、セキュリティー・リスクを低減する必要があるかどうかといった要件です。 このような「切断された」あるいは「プライベートのみ」の接続設計では、IBM Cloud® に追加情報を要求し、お客様のユース・ケースについて話し合うことをお勧めします。

さらに、SAP は、SAP システム階層をオンプレミスの場所とクラウドの場所にわたって分割しないよう強く推奨しており、この評価は企業に任されています。例えば、SAP は、オンプレミスの場所にあるインフラストラクチャーから実行される SAP AnyDB を保持しながら、クラウドの場所にあるインフラストラクチャーから実行される SAP NetWeaver に接続することを推奨していません。 IBM Power Virtual Servers では、このように SAP システム階層を分割することはサポートされていません。

ネットワーク・トポロジーに関する考慮事項

SAP システムの数および構成と、セキュリティーまたはパフォーマンス上の理由によるこれらのシステム間でのネットワーク・フローの配置の組み合わせによって、ネットワーク・トポロジーは大きく異なります。 このトポロジーの設計には、セキュリティー、パフォーマンス、コスト、柔軟性、および接続性に関するビジネスの要件が反映されます。

エンタープライズ・リソース・プランニング (ERP) ビジネス・アプリケーション、例えば、SAP NetWeaver および SAP HANA の高可用性を利用し、SAP システム階層アプローチを使用する実動インスタンスをホストする SAP システムを使用する場合は、以下のようになります。

• SAP NetWeaver では、1 つではなく、少なくとも 4 つのホストがあります。

  • Central Services (ASCS)
  • プライマリー・アプリケーション・サーバー (PAS)。セントラル・インスタンス (CI) とも呼ばれる
  • エンキュー・レプリケーション・サーバー・インスタンス (ERS)
  • 追加アプリケーション・サーバー (AAS)

• SAP HANA では、1 つではなく、少なくとも 2 つ (場合によっては 3 つ) のホストがあります。

  • SAP HANA 1 次ノード (SAP HANA システム・レプリケーションを使用します)
  • SAP HANA 2 次フェイルオーバー・ノード (SAP HANA システム・レプリケーションを使用します)
  • SAP HANA 3 次災害復旧フェイルオーバー・ノード (SAP HANA システム・レプリケーションを使用します)

• これは、SAP ランドスケープ内の 1 つの SAP システムを表しています。 SAP ランドスケープでは、以下が使用されます。

  • 1 トラック、5 つの SAP システム (サンドボックス > 開発 > テスト > ステージング > 実動)
  • デュアルトラック、5 つの SAP システム (サンドボックス > 新機能開発 + 保守開発 > 新機能テスト + 保守テスト > ステージング > 実動)

したがって、SAP ランドスケープでは、10 から 50 のホスト・サーバー (物理または仮想化) に分散された、30 から 50 の SAP インスタンスが必要である可能性があります。 これは、特定のビジネス・オペレーション、業種、または地理的機能のためにさらにビジネス・アプリケーションが追加される前です。

SAP ランドスケープのサイズは、ネットワーク・トポロジーに直接的な影響を与えます。

場合によって異なりますが、一般的には、SAP ビジネス・アプリケーションを使用するビジネスで必要とされるシナリオとパフォーマンスを満たすために、以下のネットワークが必要です。

• 異なる SAP システム階層アプローチを使用する SAP ランドスケープ内の複数のインスタンス間の通信用内部ネットワーク
• データベース・システムの管理およびストレージ転送用ネットワーク
• 実稼働環境で使用するネットワーク

ただし、最も単純なシナリオでは、すべての目的に 1 つのプライベート・ネットワークを使用することがあります。 これは、ビジネス要件によって異なります。

ネットワーク使用量に関する考慮事項

従来の SAP ワークロード・ネットワーク通信量は比較的少なく、1 日当たり 100 MiB 未満のネットワーク・トラフィックだと考えられます。以下に例を示します。

• SAPGUI からのユーザー・トランザクション。Windows および Java (macOS または Linux で使用)
• SAP WebGUI からのユーザー・トランザクション
• SAP NetWeaver Business Client (NWBC) からの SAP Web Dynpro アプリを使用したユーザー・トランザクション
• SAP システムと非 SAP システム間での SAP リモート関数呼び出し (SAP RFC)
• SAP システム、非 SAP システム、およびサード・パーティー (例えば、銀行、サプライヤー) の間での SAP iDOC インバウンド/アウトバウンド

ただし、極めて多くのネットワーク・トラフィックを消費する、はるかに大きな SAP ワークロード・ネットワーク通信もあります。以下に例を示します。

• SAP Fiori Launchpad およびアプリ用の SAPUI5 プリインストール・ライブラリーとテーマ。
  • SAP Web Assistant (XRayとも呼ばれます) からロードされる新規セッションごとに 10 MiB から 25 MiB (推定) これらのプリインストール・ライブラリーはブラウザーによってキャッシュされます。 キャッシュされると、ブラウザーの再始動または SAP Fiori ログアウトの後で、ブラウザー・キャッシュがクリアされるまで、新しいブラウザー・タブでライブラリーを使用できるようになります。
  • セッション内でロードされる新規 Fiori アプリ当たり 20 KiB - 500 KiB (推定)。
• SAP HANA システム・レプリケーション (HSR) (同期または非同期)。1 次ノードから 2 次 (または 3 次) ノードに対し、1 カ月当たり数ギガバイトのデータをストリーミングします。

新しい設計の SAP ソフトウェアではトラフィックが増加しているため、過去の SAP ソフトウェアで見られたネットワーク・トラフィック量を大きく超過する可能性があります。

ingress および egress の料金は発生しませんが、パブリック・インターネットを介した使用には egress 料金が発生するため、これらのデータ転送には IBM Cloud プライベート・バックボーンを使用するように SAP アプリケーションを設計することが重要です。

転送されるデータの量を見積もる必要があります。 初期のプロジェクト実装段階では、これは難しい場合があります。 ただし、少なくとも桁数の見積もりは行う必要があります。

ネットワーキング・スループット・パフォーマンスに関する考慮事項

SAP では一般に、アプリケーション・サーバーと SAP HANA データベースの間のトラフィックや、SAP Business Intelligence などの他の SAP HANA クライアントのトラフィックのために、10 Gbps (冗長) のネットワーク・スループットを使用することを推奨しています。

ローカル・ストレージで SAP AnyDB を使用する SAP NetWeaver のデプロイメントの場合は、3 層セットアップであっても、1 Gbps のネットワークで通常は十分です。

ネットワーキング待ち時間のパフォーマンスに関する考慮事項

ビジネス・オペレーションおよび非 SAP 依存システムで、待ち時間に関する特定の重要パフォーマンス指標 (KPI) を満たす必要がある場合があります。 この場合、ホストのサイト・ロケーションと、IBM Cloud プライベート・バックボーン・ネットワークを使用した待ち時間のテ間をテストする必要があります。

SAP HANA で高可用性 (HA) および災害復旧 (DR) を設計する際には、往復時間 (RTT) のメトリックを使用して待ち時間をテストする必要があります。

HA フェイルオーバーが 1 つのサイト・ロケーション内で設計されていれば、ほとんどすべての場合、これで SAP HANA システム・レプリケーションの要件に対応できます。

しかし、1 つのリージョン内の複数のサイトにわたって SAP HANA の高可用性を設計する場合、あるいは複数のリージョンにわたって災害復旧を設計する場合は、往復時間 (RTT) メトリックを使用して待ち時間を慎重にテストし、検討する必要があります。

これは、IBM Cloud では、フォールト・トレランスを備えた地理的に分散した複数のサイト・ロケーション (例えば、リスク・アセスメントが異なる) を使用することで、プラットフォームの高可用性を確保しようとするためです。 IBM Cloud がどのように高可用性と冗長性を確保している かについては、こちらをご覧ください。

特に、VPC インフラストラクチャーの場合、アベイラビリティー・ゾーンはリージョン内の地理的に分散されたロケーションで構成されます。 ほとんどのワークロードでは、この設計によりリージョン全体での冗長性が高まります。 ただし、SAP HANA システム・レプリケーションではネットワーク待ち時間が短い必要があり、現在の技術が持つ、物理的観点からのケーブルの物理データ転送の制限 (つまり、光ファイバー・ケーブルは光速より遅いこと) により、必要な往復時間 (RTT) のメトリックを満たすことが困難な場合があります。

ネットワーキング・ポートのセキュリティーに関する考慮事項

以下の情報は 、 SAP ヘルスポータル - すべての SAP 製品の TCP/IP ポートの概要です。これは、 SAP システムおよび IBM Cloud 上の IT インフラストラクチャ全体のセキュリティに必要な考慮事項の例を示しています。

使用している SAP 技術アプリケーションと対処するビジネス・シナリオに応じて、ホストごとにオープンする必要があるポートが異なります。 通常、この要件を満たすため、ファイアウォール・ポート・グループをファイアウォール・ルールと組み合わせます。 また、ホストごとに個別のファイアウォール・ルールを使用することもできますが、大抵は管理が困難になります。

以下の表に、SAP NetWeaver および SAP HANA を使用する SAP システムで使用される主要ポートの一部を示します。これらのポートは、SAP 技術アプリケーションのインスタンス番号に応じて変更する必要があります。インスタンス番号 00、01、02 は、さまざまな SAP 技術アプリケーションのデフォルトで、異なるパターンで示されます (これらのパターンは、code blocks で強調表示されています)。

ネットワーキング・トラフィック分離のセキュリティーに関する考慮事項

セキュリティーの制約のため、あるいはスループットを考慮して、ランドスケープに含まれる各種ネットワーク・トラフィックを分離することができます。

ネットワークの分離は、以下の SAP ワークロードのユース・ケースで役立ちます。

• データを交換する複数のサーバー
  • SAP データベースと SAP アプリケーション・インスタンスが異なるホスト上にある、3 層の論理アーキテクチャー内の SAP システム。
• 大量のデータを交換する複数の SAP システム
  • ネットワークのブロック・ストレージとファイル・ストレージに対する、低ネットワーク待ち時間と高ネットワーク・スループットを必要とするため、ファイアウォールを回避する必要があるデータベース・サーバー。 ただし、データベースに、他のシステムおよびネットワーク・アクセスに対する保護は依然として必要です。

ネットワークの分離を効率的に使用するには、特定の条件下で相互接続を許可する必要があります。