パイロット フェーズを確認する

  • 20 分

パイロットは、プロジェクトの計画および準備を並行して実行できます。 このフェーズは、計画および準備フェーズで明らかになったオプションのテストにも使用できます。 パイロットの一環として、完全な HA/DR ソリューションおよびセキュリティ設計をセットアップして検証することをお勧めします。 場合によっては、このフェーズを使用して、スケーラビリティのテストを実行したり、SAP サンドボックス システムをデプロイしたりすることもできます。 パイロットを実行するには、お客様は、Azure に移行する重要ではないシステムを最初に特定し、続いて次のタスクを実行する必要があります。

1. Azure へのデータ転送の最適化

このアプローチと結果は、お客様の Azure への接続性に大きく依存しています。 データの量によっては、ExpressRoute、サイト間 VPN、または Azure Data Box や Azure Import/Export サービスなどのオフライン データ転送サービスを、この目的に使用できる場合があります。

2. SAP 異種プラットフォームの移行

データベース データのエクスポートとインポートが含まれる SAP 異種プラットフォームの移行の場合は、エクスポートおよびインポート フェーズをテストして最適化します。 SQL Server をターゲットとする大規模な異種の移行については、「SAP OS/DB の SQL Server への移行–FAQ」を参照してください。 移行をリリースのアップグレードまたは SAP Database Migration Option (DMO) と組み合わせる必要がない場合は、Migration Monitor/SWPM を使用できます。 詳細については、「SUM のデータベース移行オプション (DMO) – 概要」を参照してください。 どちらの場合も、次の手順を実行します。

  • ソースからエクスポートし、エクスポートしたコンテンツを Azure にアップロードして、インポートを実行する時間を測定します。 エクスポートとインポートの間のオーバーラップを最大化します。
  • ソース データベースとターゲット データベースの比較を使用して、ターゲット インフラストラクチャのサイズを適切に設定します。
  • タイミングを検証して最適化します。

3. 技術的な検証の実行

仮想マシンの種類

  • SAP サポート ノート、SAP HANA ハードウェア ディレクトリ、SAP 製品可用性マトリックス (PAM) を参照して、サポートされている Azure 仮想マシン SKU、これらの Azure 仮想マシン SKU でサポートされている OS リリース、サポートされている SAP および DBMS のリリースに関する情報の正確性を確認します。
  • インフラストラクチャと、Azure にデプロイするアプリケーション コンポーネントの、サイズ設定を検証します。 既存のアプリケーションを移行する場合は、既存のテレメトリに基づいて必要な SAPS を取得できる必要があります。 SAP のベンチマークを取得し、SAP Note #1928533 に記載されている SAPS の値と比較します。 さらに、「Azure VM に関する SAPS 評価 – 探す場所と混乱しやすい場所」に記載されている情報を参照してください。
  • 計画フェーズで選択したさまざまな仮想マシンの種類の最大ストレージ スループットおよびネットワーク スループットに関して、Azure Virtual Machines のサイズ設定を評価してテストします。 このデータは、「Azure の仮想マシンのサイズ」で確認できます。 Azure 仮想マシンのゲスト オペレーティング システムが Windows の場合、サイズ設定において、キャッシュされていないディスクの最大スループットを考慮することが重要です。 Linux の場合は、サイズ設定についてキャッシュがないディスクの最大スループットも考慮することが重要です。

Storage

  • SAP アプリケーション レイヤーを表す仮想マシンと、パフォーマンスを要求されない DBMS の展開には Azure Standard SSD ストレージ以上を使用し、パフォーマンスを要求される DBMS 仮想マシンには Azure Premium Storage を使用します。
  • Azure Standard HDD ディスクは使わないようにします。
  • Azure Managed Disks を使用します。
  • M シリーズ Azure Virtual Machines の DBMS ログ ドライブに対して、Azure 書き込みアクセラレータを有効にします。 ドキュメントに記載されている書き込みアクセラレータの制限と使用制限に注意してください。
  • DBMS 関連のストレージに関する情報については、「SAP ワークロードのための Azure Virtual Machines DBMS デプロイの考慮事項」とそのドキュメントで参照されている DBMS 固有のドキュメントを参照してください。
  • SAP HANA のデプロイについては、「Azure における SAP HANA インフラストラクチャの構成と運用」を参照してください。
  • デバイス ID を使用して、Azure データ ディスクを Azure Linux 仮想マシンにマウントしないでください。 代わりに、汎用一意識別子 (UUID) を使用します。 グラフィカル ツールを使って Azure データ ディスクをマウントする場合は注意が必要です。 /etc/fstab 内のエントリを再確認して、UUID を使用して、ディスクがマウントされていることを確認します。 詳細については、「Linux 仮想マシンを接続して新しいディスクをマウントする」を参照してください。

ネットワーク

仮想ネットワーク インフラストラクチャと、SAP アプリケーションの Azure 仮想ネットワーク間またはネットワーク内の分散を、テストおよび評価します。

  1. 以下の条件に基づいて、ハブとスポークの仮想ネットワーク アーキテクチャ、または単一の Azure 仮想ネットワーク内でのマイクロセグメンテーションのアプローチを評価します

    • ピアリングされた Azure 仮想ネットワーク間のデータ交換に伴うコスト (詳細については、Azure Virtual Network の価格を参照してください)。
    • Azure 仮想ネットワーク間のピアリングを終了する機能と、NSG を使用して仮想ネットワーク内のサブネットを (仮想ネットワークのサブネット内でホストされているアプリケーションまたは仮想マシンがセキュリティ 上のリスクになる場合に) 分離する機能の比較。
    • オンプレミス、インターネット、および Azure 仮想データセンターの間のネットワーク トラフィックの集中ログ記録と監査。

  2. SAP アプリケーション レイヤーと SAP DBMS レイヤーの間のデータ パスを評価およびテストします。 評価の一部として、以下のことを考慮します。

    • SAP アプリケーションと、SAP NetWeaver、Hybris、または S/4HANA ベースの SAP システムの DBMS レイヤーとの間の通信パス内に、ネットワーク仮想アプライアンスを配置することはサポートされていません。
    • ピアリングされていない別々の Azure 仮想ネットワーク内に、SAP アプリケーション レイヤーと SAP DBMS を配置することはサポートされていません。
    • Azure アプリケーション セキュリティ グループ (ASG) とネットワーク セキュリティグループ (NSG) を使用して、SAP アプリケーション レイヤーと SAP DBMS レイヤーの間のトラフィック フローを制御することはサポートされています。

  3. SAP アプリケーションレイヤーおよび SAP DBMS レイヤー上で使用される仮想マシン上で、Azure 高速ネットワークが有効になっていることを確認します。 Azure で高速ネットワークをサポートするための OS の要件に注意してください。

    • Windows Server 2012 R2 またはそれ以降のリリース
    • SUSE Linux 12 SP3 またはそれ以降のリリース
    • RHEL 7.4 またはそれ以降のリリース
    • Oracle Linux 7.5。 RHCKL カーネルには、リリース 3.10.0-862.13.1.el7 が必要です。 Oracle UEK カーネルには、リリース 5 が必要です。

  4. SAP Note #500235 と SAP Note #1100926 に従って、SAP アプリケーション レイヤー仮想マシンと DBMS 仮想マシン間のネットワーク待機時間をテストして評価します。 SAP Note #1100926 のネットワーク待機時間のガイダンスに照らして結果を評価します。 ネットワーク待機時間は、中程度または良好な範囲でなければなりません。

  5. Direct Server Return を使用するように Azure internal load balancer (ILB) のデプロイが設定されていることを確認します。 この設定により、ILB が DBMS レイヤーの高可用性構成に使用される場合の待機時間が短縮されます。

  6. Linux ゲスト オペレーティング システムと組み合わせて Azure Load Balancer を使用している場合は、Linux ネットワーク パラメーター net.ipv4.tcp_timestamps が 0 に設定されていることを確認します。 これは、SAP Note #2382421 の一般的な推奨事項と矛盾していることに注意してください。 SAP Note は、Azure ロード バランサーと連携して動作するためにパラメーターを 0 に設定する必要があるという事実を反映して更新されています。

高可用性とディザスター リカバリーのデプロイ

  • 特定の Azure Availability Zones をターゲットにせずに SAP アプリケーション レイヤーを展開する場合は、同じ SAP システムの SAP ダイアログ インスタンスまたはミドルウェア インスタンスが実行されているすべての仮想マシンが、同じ可用性セット内に展開されていることを確認します。

    • SAP セントラル サービスと DBMS に対して高可用性が必要ない場合は、これらの仮想マシンを SAP アプリケーション レイヤーと同じ可用性セット内に展開できます。

  • パッシブ レプリカを使用した高可用性のために SAP セントラル サービスと DBMS レイヤーを保護する必要がある場合は、SAP セントラル サービス用の 2 つのノードを 1 つの可用性セットにデプロイし、2 つの DBMS ノードを別の可用性セットにデプロイします。

  • Azure Availability Zones に展開する場合は、可用性セットを使用できません。 代わりに、アクティブおよびパッシブのセントラル サービス ノードを、2 つの異なる Availability Zones に展開する必要があります。これにより、ゾーン間の待機時間が最小になります。

  • Availability Zones 間で DBMS および SAP セントラル サービス レイヤー用の Windows Server または Pacemaker ベースのフェールオーバー クラスターを作成する場合は、Azure Standard Load Balancer を使用する必要があることに注意してください。 Basic Load Balancer では、ゾーンの展開はサポートされていません。

タイムアウトの設定

  • SAP インスタンスの SAP NetWeaver 開発者トレースをチェックして、エンキュー サーバーと SAP ワーク プロセスの間の接続が切断されていないことを確認します。 このような接続の切断は、次の 2 つのレジストリ パラメーターを設定することによって回避できます。

    • HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime = 120000. 詳細については、「KeepAliveTime」を参照してください。
    • HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveInterval = 120000. 詳細については、「KeepAliveInterval」を参照してください。

  • オンプレミスの SAP GUI インターフェイスと、Azure にデプロイされた SAP アプリケーション レイヤーの間での GUI のタイムアウトを回避するため、default.pfl またはインスタンス プロファイルで次のパラメーターを設定します。

    • rdisp/keepalive_timeout = 3600
    • rdisp/keepalive = 20

  • Windows フェールオーバー クラスタリングを使用する場合は、応答しないノードによってトリガーされるフェールオーバーを決定するパラメーターが正しく設定されていることを確認します。 Microsoft TechCommunity の記事「フェールオーバー クラスターのネットワークしきい値のチューニング」には、各パラメーターとフェールオーバー動作に対するその影響が一覧表示されています。 たとえば、クラスター ノードが同じサブネット内にある場合は、次のようにフェールオーバー パラメーターを構成する必要があります。

    • SameSubNetDelay = 2000

    • SameSubNetThreshold = 15

    • RoutingHistorylength = 30

    • 高可用性とディザスター リカバリーの手順をテストします。

      • Azure Virtual Machines (Windows ゲスト OS) をシャットダウンするか、オペレーティング システム (Linux ゲスト OS) をパニック モードにすることで、フェールオーバーをシミュレートします。

      • フェールオーバーが完了するまでの時間を計測します。 時間が長すぎる場合は、次のことを検討します。

        • SUSE Linux では、Azure Fencing Agent の代わりに SBD デバイスを使って、フェールオーバーを高速化します。
        • SAP HANA では、データの再読み込みに時間がかかりすぎる場合は、ストレージのパフォーマンスを上げることを検討します。

      • バックアップ/復元のシーケンスとタイミングをテストし、必要であれば調整します。 バックアップ時間が十分であることを確認するだけでなく、 また、復元をテストし、復元アクティビティのタイミングを確認します。 RTO がデータベースまたは仮想マシンの復元プロセスに依存する場合、復元時間が RTO の SLA 内に収まるようにしてください。

      • DR の機能とアーキテクチャをテストします。

4. セキュリティ チェックを実行する

  • 実装した Azure のロールベースのアクセス制御 (RBAC) 方法の有効性をテストします。 目標は、異なるチームに委任されたアクセスとアクセス許可を分離して制限することです。 例として、SAP Basis チームのメンバーは、特定の Azure 仮想ネットワークに Azure 仮想マシンを展開し、これらの Azure 仮想マシンにディスクを割り当てることができる必要があります。 ただし、SAP Basis チームは、新しい仮想ネットワークを作成したり、既存の仮想ネットワークの設定を変更したりすることはできません。 逆に、ネットワーク チームのメンバーは、SAP アプリケーションと DBMS 仮想マシンが実行されている仮想ネットワークに Azure Virtual Machines を展開することはできません。 また、ネットワーク チームのメンバーが仮想マシンの属性を変更したり、仮想マシンとそのディスクを削除したりすることはできません。
  • NSG ルールが想定どおりに動作していることを確認し、保護されたリソースをシールドします。
  • 保存時と転送時の暗号化を確認します。 証明書のバックアップ、保存、アクセスのためのプロセスを定義して実装します。また、暗号化されたエンティティの復元プロセスも検証します。
  • OS ディスクには Azure Disk Encryption を使用します。
  • 暗号化メカニズムを実装するかどうかを決定するときは、実際的なアプローチを検討します。 たとえば、Azure Disk Encryption と DBMS Transparent Database Encryption の両方を適用する必要があるかどうかを評価します。

5. パフォーマンスをテストする

移行シナリオでは、SAP のトレースと測定を使用し、次に基づいてパイロットと現在の実装を比較します。

  • 上位 10 件のオンライン レポート
  • 上位 10 個のバッチ ジョブ
  • クロスプレミス トラフィックに注目した、インターフェイスを介した SAP システムへのデータ転送