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

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. 技術的な検証の実行

VM の種類

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

ストレージ

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

ネットワーク

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

以下の条件に基づいて、ハブとスポークの仮想ネットワークアーキテクチャ、または単一の Azure 仮想ネットワーク内でのマイクロセグメンテーションのアプローチを評価します
- ピアリングされた Azure VNet 間のデータ交換によるコスト (詳細については、Azure 仮想ネットワークの価格を参照。
- 仮想ネットワークのサブネットでホストされているアプリケーションまたは VM がセキュリティリスクになる場合に、Azure 仮想ネットワーク間のピアリングを終了する機能と、NSG を使用して仮想ネットワーク内のサブネットを分離する機能の比較。
- オンプレミス、インターネット、および Azure 仮想データセンターの間のネットワークトラフィックの集中ログ記録と監査。
SAP アプリケーションレイヤーと SAP DBMS レイヤーの間のデータパスを評価およびテストします。評価の一部として、以下のことを考慮します。
- SAP アプリケーションと、SAP NetWeaver、Hybris、または S/4HANA ベースの SAP システムの DBMS レイヤーの間の通信パスへのネットワーク仮想アプライアンスの配置は、サポートされていません。
- ピアリングされていない異なる Azure 仮想ネットワークに、SAP アプリケーションレイヤーと SAP DBMS を配置することは、サポートされていません。
- Azure アプリケーションセキュリティグループ (ASG) とネットワークセキュリティグループ (NSG) を使用して、SAP アプリケーションレイヤーと SAP DBMS レイヤーの間のトラフィックフローを制御することはサポートされています。
SAP アプリケーション層および SAP DBMS 層で使用される VM 上で、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 が必要です。
SAP Note #500235 と SAP Note #1100926 に従って、SAP アプリケーションレイヤーの VM と DBMS VM の間のネットワーク待機時間をテストおよび評価します。 SAP Note #1100926 のネットワーク待機時間のガイダンスに照らして結果を評価します。ネットワーク待機時間は、中程度または良好な範囲でなければなりません。
Direct Server Return を使用するように Azure internal load balancer (ILB) のデプロイが設定されていることを確認します。この設定により、ILB が DBMS レイヤーの高可用性構成に使用される場合の待機時間が短縮されます。
Azure Load Balancer を Linux ゲストオペレーティングシステムと共に使用している場合、Linux ネットワークパラメーター net.ipv4.tcp_timestamps が 0 に設定されていることを確認します。これは、SAP Note #2382421 の一般的な推奨事項と矛盾していることに注意してください。 SAP Note は、Azure ロードバランサーと連携して動作するためにパラメーターを 0 に設定する必要があるという事実を反映して更新されています。

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

特定の Azure Availability Zones をターゲットにせずに SAP アプリケーションレイヤーをデプロイする場合は、SAP ダイアログインスタンスまたは同じ SAP システムのミドルウェアインスタンスが実行されているすべての VM が、同じ可用性セットにデプロイされていることを確認します。
- SAP セントラルサービスと DBMS の高可用性が必要ない場合は、これらの VM を SAP アプリケーションレイヤーと同じ可用性セットにデプロイできます。
パッシブレプリカを使用した高可用性のために SAP セントラルサービスと DBMS レイヤーを保護する必要がある場合は、SAP セントラルサービス用の 2 つのノードを 1 つの可用性セットにデプロイし、2 つの DBMS ノードを別の可用性セットにデプロイします。
Azure Availability Zones にデプロイする場合は、可用性セットを利用できません。代わりに、アクティブとパッシブのセントラルサービスノードを、2 つの異なる Availability Zones にデプロイする必要があります。これにより、ゾーン間の待機時間が最短になります。
Availability Zones をまたがる DBMS および SAP セントラルサービスレイヤーに対して、Windows Server または Pacemaker ベースのフェールオーバークラスターを作成する場合は、Azure Standard ロードバランサーを使う必要があることに注意してください。基本ロードバランサーでは、ゾーンごとのデプロイはサポートされていません。

タイムアウトの設定

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 VM をシャットダウンするか (Windows ゲスト OS)、オペレーティングシステムをパニックモードにすることで (Linux ゲスト OS)、フェールオーバーをシミュレートします。
  - フェールオーバーが完了するまでの時間を計測します。時間が長すぎる場合は、次のことを検討します。
    - SUSE Linux では、Azure Fencing Agent の代わりに SBD デバイスを使って、フェールオーバーを高速化します。
    - SAP HANA では、データの再読み込みに時間がかかりすぎる場合は、ストレージのパフォーマンスを上げることを検討します。
  - バックアップ/復元のシーケンスとタイミングをテストし、必要であれば調整します。バックアップ時間が十分であることを確認するだけでなく、また、復元をテストし、復元アクティビティのタイミングを確認します。復元時間が RTO の SLA 内に収まるようにしてください。ここで、RTO はデータベースまたは VM の復元プロセスに依存します。
  - DR の機能とアーキテクチャをテストします。

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

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

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

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

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

続行

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