オーストラリアの大手エネルギー企業: SAP アプリケーションを最新化して Azure パブリック クラウドへ移行

  • Article

執筆者: Cameron (MSFT SAP Program Manager)

このポストは、2017 年 3 月 27 日に投稿された Large Australian Energy Company Modernizes SAP Applications & Moves to Azure Public Cloud の翻訳です。

 

この記事では、オーストラリアの大手エネルギー企業 (以下、「同社」) で最近実施された SAP ソリューション移行プロジェクトを技術的な面から概説します。このプロジェクトは、サポート期限切れの HPUX と Oracle のプラットフォームから、Azure パブリック クラウド上で稼働する最新の SQL Server 2016 ソリューションへの移行を 12 か月間で行いました。この記事ではOS/DBマイグレーション、Unicode変換、SAPアップグレードに加え、Azureパブリッククラウドへの移行という複数の要素が関わったプロジェクトの技術的な側面に着目し紹介します。

この移行プロジェクトは、同社とマイクロソフト プラットフォーム上での SAP 運用を専門とする SAP コンサルティング企業であるBNWコンサルティング社によって、無事に完了しています。

1.  移行前のプラットフォームとその課題

同社は 1996 年に SAP R/3 を導入し HPUX と Oracle 上に展開しました。HPUX と Oracle は、当時、SAP アプリケーションを運用するプラットフォームとして一般的なものでした。時間の経過と共にアプリケーションが増え、SAP Business Warehouse、Supply Chain Management、Enterprise Portal、GRC、PI、MDM、SRM などが展開されました。UNIX ベースのプラットフォームがサポート切れとなったことから、同社は SAP の稼働に利用可能な複数のオペレーティング システム、データベース、ハードウェア プラットフォームについて適正評価を実施しました。その結果、Azure、Windows 2012 R2、SQL Server 2016 が選ばれました。

次のような要因が考慮されました。

  1. この 10 年から 15 年の間で、標準的な Intel プラットフォーム製品のパフォーマンスと信頼性が大幅に向上している。
  2. UNIX ベンダーはこれらの技術に対する新たな投資をしておらず、SAP のような標準的なパッケージアプリケーションは、全般的に UNIX からシフトしている。
  3. SQL Server 2016 には、SAP BW と統合できる列ストア機能がある。これにより十分なパフォーマンスを確保できるため、高価な Business Warehouse Accelerator (BWA) をソリューションから除くことができる。
  4. Azure パブリック クラウド プラットフォームは成熟しており、SAP からの認定とサポートが完全に揃っている。
  5. Windows と SQL Server 2016 では高可用性とディザスター リカバリーの技術が改善しており、さらに高い SLA に対応することが可能。
  6. Azure クラウドには Azure Site Recovery (ASR) と呼ばれる統合ディザスター リカバリー ツールがあり、DR のSLA と運用環境のシステムに影響を与えることなく、いつでも DR のテストを行うことができる。
  7. Azure クラウドには SAP との強力なパートナーシップを示すロードマップが発表されている。たとえば、4 TB の HANA アプライアンスの提供、Azure 仮想マシンでの HANA の認定などがある。
  8. 総合的なテクニカル プラットフォームとして各種の機能が提供され、サポート窓口が統一されている。技術力の高いパートナーも存在している。

移行前のプラットフォームは、使用していた Oracle 11g のサポート切れという問題だけでなく、Oracle のデータベース圧縮に関する制約の問題もありました。Oracle 上での BW FEMS プッシュダウン対応についてはロードマップがなく、当時の SAN ストレージは容量不足で刷新が必要でした。

Windows、SQL Server、Azure への移行前の SAP アプリケーション全体は次の SAP 製品で構成されていました。

SAP ECC 6.0 EHP 5 (非 Unicode)

SAP BW 7.30 (非 Unicode)

SAP BWA 7.20

SAP Business Objects 4.1 SP6

SAP SRM 7.31

SAP SRM TREX 7.1

Content Server 6.40

SAP SCM (非 Unicode)

SAP SCM LiveCache 7.7

SAP PI 7.3

SAP EP 7.3

SAP GRC 7.02

SAP Gateway 7.31

SAP Solution Manager 7.1

SAP MDM 7.1

SAP Console

2. 新しい構成

Azure (オーストラリア リージョン)、Windows 2012 R2、SQL Server 2016 Service Pack 1 で構築する新しい構成に移行するには、いくつかの製品について OS / DB マイグレーション、Azureへの移行、Unicode 変換を同時に行う必要がありました。新しい構成は以下のとおりです。

SAP ECC 6.0 EHP 7 (Unicode)

SAP BW 7.40 (Unicode)

SAP Business Objects 4.2 SP2 pl4

SAP SRM EHP2

SAP SRM TREX 7.1

Content Server 6.5

SAP SCM EHP3 (Unicode)

SAP SCM LiveCache 7.9

SAP PI 7.4

SAP EP 7.4

SAP GRC 10

SAP Gateway 7.4

SAP Solution Manager 7.2

SAP SLD/ADS 7.4

SAP MDM 7.1

SAP Console

オペレーティング システム: Windows 2012 R2 Datacenter

データベース: SQL Server 2016 SP1 Enterprise Edition

データベース サーバーの VM タイプ: GS5 (BW)、G4 (ERP)、D14v2 (その他の SAP)、DS12v2 (MaxDB/TREX)

SAP アプリケーション サーバーの VM タイプ: D12v2、D14v2

ストレージ: すべての DBMS サーバー (SQL Server、MaxDB、TREX) で Azure Premium Storage を使用、その他のすべてのワークロードでは Standard Storageを使用

ネットワーク接続: ExpressRoute 及び HighPerformance ゲートウェイ

Azure デプロイメント モデル: Azure Resource Manager (ARM)

3. アップグレード、Unicode 変換、OS と DB マイグレーション

SAP の OS/DB マイグレーションに関して、同社のパートナーである BNW Consulting は、同社にとってのメリットを最優先し、ビッグ バン的な一括移行は推奨しませんでした。一括移行では、本稼働環境全体を 1 回の週末中に Azure に移行することもあります。このような方法は技術的には可能ですが、相当なリソースを必要とし、メリットはあまり多くありません。

今回の場合は、移行を段階的に進めることで成功を収めました。まずは、比較的小規模な NetWeaver システムを対象にし、Azure への移行、アップグレードまたは再インストールを行いました。次に、BW システムです。既存のデータセンター内で、高速なIntel Windows サーバーで R3load を実行しエクスポートしました。一般的に言って、HPUX などの UNIX プラットフォームでの R3load のパフォーマンスは、Intel ベースのプラットフォームでのパフォーマンスよりもかなり低くなります。ダンプ ファイルは FTP と SAP MigMon を使用して転送し、パラレルインポートしました。BW は、最新の Support Pack Stack を適用した BW 7.40 にアップグレードしました。移行に合わせ、データベースの Unicode 変換を行いました。

最後に、SAP ECC 6.0 システムを Azure に移行し、EHP5 から EHP7 にアップグレードし、Unicode変換を行いました。

インポートの速度を上げるため、SQL Server トランザクション ログ ファイルを一時的に GS5 DB サーバーの D: ドライブ (非永続ディスク) に置きました。ログ用の追加の容量を、P30 Premium ディスク 6 個で構成される Windows 記憶域スペースに確保しました。

SAP アプリケーション サーバーのセットアップと構成は、全プロファイル パラメーターを Default.pfl に記述することで非常に簡略化することができました。SAP アプリケーション サーバーごとに構成を変える理由はなく、構成の統一により問題発生時の対応が大幅に軽減されます。

実装パートナーは、40 以上の 非SAP アプリケーションへとの 200 以上のインターフェイスをテストし、必要な修正を行いました。

4.  SQL Server 2016 Enterprise Edition SP1 の SAP 向け機能

SQL Server 2016 には、SAP ユーザーに大きなメリットをもたらす機能が多数あります。

  1. 列ストアの統合：ストレージの大幅な削減とパフォーマンスの大幅な向上を実現できます。このテクノロジは、RS_BW_POSTMIGRATION フェーズ時に自動的に適用されます。また、レポート MSSCSTORE を使用することでも適用できます。多くの顧客が SAP Business Warehouse Accelerator を廃止しており、SQL Server の列ストアにより、同等またはそれ以上のパフォーマンスを実現しています。
  2. SQL Server AlwaysOn は、DB標準機能の統合 HA/DR ソリューションであり、簡単にセットアップできます。
  3. SQL Server の透過的なデータ暗号化 (TDE) は、のデータベースおよびデータベースのバックアップを保護できます。TDE は Azure Key Vault サービスと統合されています。
  4. SQL Server の BLOB ストレージへのバックアップにより、Azure ストレージ上の URL パスを指定して、バックアップを複数のファイルに直接書き込むことができます。SQL Server AlwaysOn セカンダリ データベースから完全バックアップとトランザクション ログ バックアップを取得することができます。これにより、プライマリ データベースの負荷を減らせます。また、DR データセンターにおけるオフサイト バックアップを簡単に作成することもできます。
  5. SQL Server 2016 は、エンタープライズ SAN レベルのスナップショットと同様のAzure ストレージ レベル「スナップショット」をサポートしています。現時点では、4 時間ごとの取得、48 時間の保持が可能です。SQL 2016 には 1 TB 超の大きなバックアップを作成する機能があり、同社はすべての SAP アプリケーションのバックアッププロセスを統一して簡略化することができました。
  6. SQL Server のデータベース圧縮はデータベースのサイズを劇的に減らせます。

SQL Server 2016 のデータベース圧縮の結果は次のようになりました。

SAP コンポーネント HPUX /Oracle での DB サイズ Windows / SQL Server での DB サイズ 備考
SAP BW 7.40 7.7 TB 2.3 TB 7.3 から 7.4 へのアップグレード、Unicode 変換、列ストアとフラット キューブ
SAP ECC 6.0 3.1 TB 1.5 TB 7.3 から 7.4 へのアップグレード、EHP5 から EHP7 へのアップグレード、Unicode 変換
SAP SRM 261 GB 126 GB
SAP SCM 122 GB 53 GB 7.0 EHP1 から EHP3 へのアップグレード、Unicode 変換

SQL Server 2016 の列ストアにより、SAP BW のユーザー クエリとデータロードが劇的に改善しました。SAP BW on HANAのフラット キューブ機能は、SQL Server ユーザも利用できます。下のグラフは、Oracle (SAP BWA あり) と SQL Server 2016 (BWA なし) のパフォーマンスの比較です。このグラフは、本稼働の数週間後に同社がデータを取得し作成したものです。

グラフ 1. パフォーマンス比較: オンプレミス HPUX/Oracle + BWA 対 Windows 2012 R2/SQL Server 2016 + SQL Server フラット キューブおよび列ストア

このほか、BW プロセス チェーンの実行時間が 50% 短縮されました。これにより、ユーザーはより最新のデータでレポートを見ることができるようになりました。

5. Azure の構成

このプロジェクトでは、次のような Azure 独自の機能を活用して SAP ソリューションのパフォーマンスと回復性を高めました。

  1. 可用性セット: SQL Server のサーバー、ASCS サーバー、SAP アプリケーション サーバーには、常に少なくとも 1ノードは稼働させるために可用性セットを構成しました。
  2. Premium Storage: SQL Server や、DBMS のようなワークロードには Premium Storage を使用し、高 IOPS と安定した10 ミリ秒未満のレイテンシを実現しています。
  3. ILB に対する複数 IP アドレス: Azure 内部ロード バランサー (ILB) の複数フロントエンド IP アドレスを設定する機能を使用し、（SAP BW、ECCなど用にそれぞれ必要な）ASCS コンポーネントを 単一のASCS クラスターに統合しました。
  4. ストレージ ピニング: SQL Server AlwaysOn の各ノードに個別のストレージ アカウントを使用しました。これにより、あるストレージ アカウントの障害により両方のノードのストレージが使用できないという事態を避けることができます。この機能は現在、新機能「Managed Disks」として Azure に組み込まれています。
  5. ネットワーク セキュリティ グループ: ネットワーク ACL をVNet 、サブネット、または仮想マシンごとに作成しました。
  6. Azure ExpressRoute:顧客サイトと Azure データセンターの間の暗号化された専用 WAN リンクによる高速接続を実現しています。
  7. Active Directory グループ ポリシー: SAP サーバーとサービス アカウントを Active Directory のあるコンテナー内に設定し、Windows オペレーティング システムの強化対策のためにグループ ポリシーを適用しました。これにより、サービスとパッチ適用の必要性を減らせます。SQL Server 用のサービス アカウントの構成において、Lock Pages In Memoryを有効にし、ボリューム メンテナンス タスクの実行権限を許可しました。パッチ適用の必要性を減らすために、Internet Explorer をWindows Server 2012 R2 から削除しました。このような展開構成を採用している顧客の多くでは、定期的なパッチ適用を削減し、更新およびパッチ適用サイクルを年単位に変更することが可能になっています。

6. 高可用性と災害復旧

プライマリ データセンター内のすべての SAP アプリケーション コンポーネントにおいて高可用性が確保されています。つまり、個々のサーバーやサービスの障害がシステム停止を引き起こすことはありません。SQL Server は同期 AlwaysOn で保護されており、RPO は 0 秒、RTO は 10 ～ 45 秒です。SAP ASCS サービスは Windows クラスタリングで保護されます。

Azure には共有ディスクをサポートする機能がないため、BNW AFSDrive というディスク レプリケーション ツールを使用してクラスターに共有ディスクを展開しています。

災害復旧サイトは、真に回復性の高い DR 機能を提供するために、地理的に完全に分離されている必要があります。求められる SLA を達成するには、完全に独立した電力、WAN リンク、統制サービスおよびセキュリティが必要です。

今回の災害復旧ソリューションでは、1 つの SQL Server と ASCS ノードを DR サイトに構成しました。災害により DR サイトでの運用が数日以上続く可能性を考慮するのであれば、DR ソリューションにも高可用性を確保すべきです。

7. パートナー提供の製品とサービス

BNW StopLoss: 大規模エンタープライズ顧客の要件として、移行元データベース内の 1 行 1 行がすべて正確に SQL Server に移行されることの絶対的な保証が必要です。SAP Migration Toolは、エクスポート及びインポートの基本的な行数の確認はできますが、認定資格のないコンサルタントがこのツールを使用すると不整合が発生する可能性があります。BNW StopLoss ではこのような可能性を排除できます。BNW StopLoss は、エクスポートする行をスキャンして行数をカウントしながら、非同期で移行先 SQL Server データベース内の行数をカウントします。行数が一致しない場合、警告を発行します。

BNW AFSDrive: Azure には、共有クラスター ディスクをサポートする機能がありません。BNW AFSDrive は、2 台以上の Azure VM 間で仮想的に共有クラスター ディスクを作成できます。BNW AFSDrive は、Windows 2012 R2 および Windows 2016 で認定され、サポートされています。

BNW CloudSnap: ディスクやストレージのクローンを作成する Azure の技術を使用して、SQL Server、Oracle、Sybase のデータベースをコピーできます。CloudSnap ユーティリティはディスクをわずかな時間だけ静止させ、データベースのチェックポイントを作成します。この技術により、手間をかけることなくバックアップやシステムのコピーを作成できます。

8. Azure のメリット

同社は、サポート切れの HPUX プラットフォームを置き換えることができました。パフォーマンスの向上とデータ量の削減を実現する SQL Server 2016 SP1 の多くの機能を活用し、高コストな BWA 専用アプライアンスを廃止しました。移行と同時に、すべてのアプリケーションを最新のバージョンにアップグレードし、パッチ適用とUnicode 変換も行いました。今回実現したソリューションにより、同社は、2025 年 12 月 31 日までサポート及びメンテナンスがされる最新のプラットフォーム上で SAP アプリケーションを安定運用できるようになりました。

テスト環境は以前よりもはるかに短時間で作成でき、データの最新化も行えるようになりました。BW と ECC のパフォーマンスが大幅に向上しました。

データベース管理作業 (バックアップ、データベース整合性チェック、復元など) の時間は、HPUX/Oracle のときに比べて劇的に短縮されました。

システム全体のパフォーマンスと応答時間も大きく改善しました。さらに、HA/DR ソリューションも強化され、DR ソリューションは簡単にテストできるようになりました。

リンクと Note

SAP と Azure のパートナー: BNW Consulting – https://www.bnw.com.au/ (英語)

第三者の Web サイト、SAP、およびその他の情報源からの内容は、批判、論評、報道、教育、学問、研究を目的とする公正な使用 (英語) に基づいて再利用しています。