Category: SAP*


AWS Partner Network(APN) テクノロジーパートナー ATADATA: SAP on AWS移行時の強力な手助け

AWSパートナープログラム部門にてマイグレーション領域のグローバルプログラムリードを務めるKalpan Ravalによる記事です。

多くのエンタープライズのお客様は、AWSサービスの活用によりビジネスのイノベーションを促進し、以前よりもっと安全に環境を構築し、技術的負債を捨て、コストを削減しています。その結果、さらにお客様がAWSに移行しようとし、高度に自動化された移行作業の数が増えています。実績に基づく経験と高品質なツールを使用してリスクを軽減し、主要なワークロードの移行の実現を支援するために、お客様はますますAWS移行コンピテンシーパートナーを頼みにしていることが分かっています。

SAP環境は多くの場合に複雑であり、多くのビジネスワークフローにおいて中心的な役割を果たします。SAPワークロードのある様々なインフラストラクチャタイプによっては、さらに複雑さが増します。x86の観点からは、仮想マシンと物理マシンの両方でWindowsとLinuxのワークロードがあり、大量のCPUコアとRAMが実行されます。加えて、Oracle、SQL Server、またはSAP HANAなどのトランザクション性の高いデータベース用に数十台のディスクドライブもあります。ミッションクリティカルなSAPワークロードを移行する場合、その方法とベンダーを慎重に選択する必要があるという結論が導かれます。私たちは、SAP on AWSを評価いただくために参考となる多くのリソースを提供しています。また、AWS移行コンピテンシーパートナーのページとSAPコンピテンシーパートナーのページから、支援依頼が可能なAPNパートナーのリストをご覧ください。今日は、私たちのAPNアドバンスドテクノロジーパートナーで移行コンピテンシーを取得しているATADATA(アタデータ)について少しお話しし、同社のプラットフォームを使用してSAPワークロードをAWSに移行する方法を説明します。

大規模なSAPワークロードの移行

ATADATAには、SAPを含む大規模なエンタープライズワークロードの移行を可能にする総合的なプラットフォームとして機能する複数のエージェントレスな自動化モジュールがあります。これらのモジュールは、自動的なライブマイグレーションだけでなく、ディスカバリー、アプリケーションのマッピング、コスト予測、移動グループの作成と有効化、移行するワークロードの同期化のために、個別に、または統合製品として使用できます。総合的な移行プラットフォームであることに加えて、ソリューションセットは迅速に導入でき、完全に自己完結しており、エンタープライズ環境向けに設計されています。

自動化された移行の有効化と実行に必要な典型的なワークフロー:

 

    • ATAvisionディスカバリーモジュールによるアプリケーションの検出とマッピング

ディスカバリーと計画策定は、あらゆる移行において不可欠なフェーズです。アプリケーション全体を移行、あるいは変換することを目的とするかどうかに関わらず、対象領域の地図なしではプロジェクトの効率性とタイムラインが失われるでしょう。これは、SAPの移行において非常に重要です。SAPは非常に複雑で、多くのモジュールでは、接続先はオンプレミス環境の外に広がる複雑なサプライチェーンにまたがる多数のエンドポイントにまで及び、ビジネスラインに影響を及ぼす可能性があります。これらの依存関係を把握することは、どのサーバーを一緒に移動する必要があるのか​​、そのインフラストラクチャの依存関係を理解し​​、最も影響の少なく都合のよい移行時期を知る上で非常に重要です。

ATADATAプラットフォームが持つエージェントレスのATAvisionモジュールを使用することで、移行を最適にできるようSAPの依存関係が検出されます。移行アーキテクトは、相互に依存し合うアプリケーションとサーバーが密接に結びついているかどうかを知る必要があります。ATAvisionは、この目的のために設計されており、組み込まれたインテリジェンス機能を使用してアプリケーション通信によって関連するインフラストラクチャをグループ化します。

    • ATAvisionディスカバリーモジュールによる移行の移動グループの作成とコスト予測

ATAvisionは、移行の移動グループとそれを組み込んだ段階計画を策定するために必要な情報を提供するよう開発されました。ATAvisionは、スプレッドシートを手動で作業し、ピボットテーブルを使用してサーバーを移動グループに結びつける移行アーキテクトもまだありますが、SAPなどのシステムで特に役立つ移動グループの自動作成ができるようになりました。

ルールを定義するだけで、ロジックが引き継がれます。自動的な移動グループテクノロジーがもたらすインテリジェンスとスピードにより、膨大な作業時間を節約し、スプレッドシートに頼っていたときの人為的ミスのリスクを軽減できます。

さらに、移行前に、クライアントおよびアプリケーションチームは、個々の移動グループごとのAWS使用量を予測したり、収集された属性の数をフィルタリングしたりすることができます。

    • ATAmotion移行モジュールを使用したポイント・ツー・ポイントの移行とAWSへの同期

ATAmotionはATADATAのコア製品であり、独自のマルチスレッドクローンエンジンと高度なAWS APIとの統合ポイントによって可能になる、大規模なエンタープライズワークロードを移行するという使命を持って開発された堅牢なアーキテクチャを備えています。

ATAmotionのポイント・ツー・ポイントの定義とはどういうことでしょうか?データは中間ステージやイメージライブラリー、ストレージバケットを経由せずにソースマシンからVPC内で指定されたクライアントサブネットにあるAmazon Elastic Compute Cloud(Amazon EC2)上のターゲットインスタンスに直接流れます。このアーキテクチャでは、基盤となるOSやデータベースの種類に関係なく、数多くの稼働中のSAPワークロードの移行を同時にサポートできるため、複雑なSAP環境の場合でも移行期間を数週間から数時間に短縮できる可能性があります。

ATAmotionは、Windows Serverのバージョン2003 32bitから2016まで、Red Hat Enterprise Linux、SuSE Enterprise Linux、Debian、OpenSuSE、CentOS、Oracle Linux、Amazon Linux、Fedora、Ubuntuといったすべての一般的なLinuxディストリビューションをサポートしています。あらゆるクラウド環境またはオンプレミス環境からAWS(米国) GovCloudリージョンを含むすべてのAWSリージョンへの移行、あるいはリージョン間の移行をサポートしています。移行が大陸をまたがったり低帯域幅の場合、ATAmotionはコピーの遅延または中断を監視し、データコピーを正常に完了させる最も効果的な方法を見つけます。

ATAmotionソフトウェアは、サポートされているWindows / Linuxのいずれかで実行中のデータ集約型のSAPアプリケーションを、実質的にダウンタイムなしで移行することができます。これは主に、ATAmotionはクライアントホストのCPU使用率が非常に低く、数MBのメモリしか消費しないため、このような低いリソース使用率のおかげでサービスを中断しないからです。そして、ATAmotionはすべてのファイルシステムを移行します。オペレーティングシステムとそのデータがいくつかのLVM論理ボリュームと物理ボリュームに分割されているかどうかは関係なく、固定パーティションを使用して100個のディスクに格納されている場合であっても、ツールがターゲットサーバ上に同じデバイス構造を再作成するため同じままの構成になります。

さらに、その構造に基づいてデータを移動するための適切な方法を選択するインテリジェンス機能があります。データがファイルシステムに格納されている場合、ファイルベースのコピーアルゴリズムを使用してデータがコピーされます。しかし、ファイルシステムが存在しないデータベースの一般的なシナリオであるRAWデバイスに格納されている場合は、ブロックコピーアルゴリズムを使用してデータがコピーされます。

最後に、ATAmotionには、複数の自動化された同期手法が組み込まれているため、カットオーバー前、カットオーバー中に様々なカットオーバー戦略が取れます。

SAP on AWS移行時におけるATADATAプラットフォームのメリット

  • 単一のベンダー管理で、エンド・ツー・エンドのシームレスなAWS移行が可能になる
  • 検証済みのAWS移行パートナーソリューションによりリスクを削減し、SAPワークロードをAWSに移行できる
  • AWSへの移行を開始する前に既存のSAP環境を完全に把握できる
  • 数十のSAPワークロードを同時に移行するような予定を早められる(数週間ではなく数時間で検討)
  • レガシーなメソドロジーとテクノロジーに伴うコストの削減と人的ミスの軽減ができる
  • AWSへの旅の一環として高度な自動化を活用できる
  • リソース集中型のオンプレミスハードウェアを廃止できる

もしあなたが既存のSAPワークロードのAWS移行を検討しているエンタープライズのお客様またはサービスプロバイダーでしたら、今すぐATADATAの自動化と明確な専門技術を活用することができます。ATADATAの詳細については、www.atadata.com/awsをご覧ください。


このブログの内容や意見は著者のものであり、第三者の製品を保証するものではありません。AWSはこの記事の内容や正確さについての責任は負いません。

 

翻訳はPartner SA 河原が担当しました。原文はこちらです。

SAP on AWSにおけるVPCサブネットのゾーニングパターン

この記事は、Amazon Web Services(AWS)のソリューション アーキテクト、Harpreet SinghとDerek Ewellによるものです。

企業のファイアウォール内に存在する必要があるSAPランドスケープの設計は比較的簡単ですが、内部からも外部からも接続する必要があるSAPアプリケーションの場合はそうではありません。これらのシナリオでは、必要なコンポーネントとその配置場所について悩むことがよくあります。

この一連のブログ記事では、SAPアプリケーションにおけるAmazon Virtual Private Cloud(Amazon VPC) サブネットのゾーニングパターンを紹介し、例を用いてその使用方法を説明します。セキュリティグループルートテーブルおよびネットワークアクセスコントロールリスト(ACL)の構成と合わせて、よくあるお客様シナリオに基づいた詳細な図で補足しながら、接続経路ごとにいくつかのアーキテクチャ設計パターンを説明します。

アプリケーションを配置するサブネットを正しく見極めるには、アプリケーションへの接続方法を理解することが必要です。SAPアプリケーションに接続する方法をいくつか見てみましょう。

  • 内部専用接続: これらのアプリケーションは内部的にのみ接続します。SAPサポートチームを除き、外部からの接続は許可されていません。この場合、ユーザーまたはアプリケーションは、専用線または仮想プライベートネットワーク(VPN)を介して接続された企業ネットワーク内に存在する必要があります。SAP Enterprise Resource Planning(ERP)、SAP S/4HANA、SAP Business Warehouse(BW)およびSAP BW/4HANAはほとんどの組織で内部専用接続が必要なアプリケーションです。
  • 内部および管理された外部接続: これらのアプリケーションは内部的に接続しますが、既知の外部の関係者に限定した接続も提供します。例えば、内部プロセスからSAP PI(Process Integration)やSAP PO(Process Process Orchestration)を使用することができますし、既知の外部の関係者もホワイトリストに登録されたIPアドレスからソフトウェアのインターフェースに接続することができます。さらに、SAP SuccessFactors、SAP Cloud Platform、SAP AribaなどのSaaS(Software as a Service)ソリューションとの統合は、AWS上で実行されるSAPソリューションに機能を追加する場合にも望まれます。
  • 内部および管理されていない外部接続: SAP hybrisや社外に公開するSAP Enterprise Portalなどのアプリケーションがこのカテゴリーに分類されます。これらのアプリケーションには一般に外部接続が可能ですが、管理、構成および他の内部アプリケーションとの統合のためのコンポーネントなど、内部接続用のコンポーネントがあります。
  • 外部専用接続: ほとんどのコンポーネントが外部から接続可能であっても、アプリケーションにはバックアップ、接続制御、インターフェースなどの基本的な管理タスクのために内部から接続できる必要があるため、稀なシナリオです。このシナリオは滅多にないため、この一連のブログ記事では説明しません。

このブログ記事では、最初のカテゴリーのアプリケーション(内部でのみ接続可能なアプリケーション)で取り得るアーキテクチャパターンについて説明します。今後の記事で、残りの2つのシナリオについて説明します。3つすべてのシナリオにおいて、パッチ、更新プログラムの適用およびその他の関連するシナリオに対処するために、ネットワークアドレス変換(NAT)デバイス(IPv4の場合)Egress-Onlyインターネットゲートウェイ(IPv6の場合)を使用して、AWSリソースからインターネットに接続すると仮定します。さらに、この接続は、インバウンド(インターネットからAWSクラウドへの)接続要求を制限または排除する方法で管理します。

内部専用接続におけるアーキテクチャ設計パターン

このカテゴリーのSAPアプリケーションについて、データベースとアプリケーションサーバーを同じプライベートサブネットまたは分離したプライベートサブネットに配置する2つの設計パターンを見ていきます。

単一のプライベートサブネットにあるデータベースとアプリケーションサーバー

この構成には3つのサブネットがあります。

  • パブリックサブネット: SAProuterとNATゲートウェイまたはNATインスタンスをこのサブネットに配置します。SAPから指定されたパブリックIPアドレスのみがSAProuterに接続できます。詳細は、SAPノート28976 – リモート接続データシートを参照してください。(SAPノートの閲覧にはSAPサポートポータルへの接続が必要です)。
  • 管理用のプライベートサブネット: Microsoft System Center Configuration Manager(SCCM)などの管理ツール、管理者または踏み台ホストをこのサブネットに配置します。このサブネット内のアプリケーションは、エンドユーザーが直接接続するのではなく、エンドユーザーをサポートするために必要です。このサブネット内のアプリケーションは、パブリックサブネットに配置されたNATゲートウェイまたはNATインスタンスを介してインターネットに接続できます。
  • アプリケーションとデータベース用のプライベートサブネット: データベースとアプリケーションをこのサブネットに配置します。SAPアプリケーションは、SAP GUI経由またはSAP Webディスパッチャを介したHTTP/S経由でエンドユーザーから接続できます。エンドユーザーはデータベースに直接接続することはできません。

異なるプライベートサブネットにあるデータベースとアプリケーションサーバー

この構成には4つのサブネットがあります。パブリックサブネットと管理用のプライベートサブネットは以前のシナリオと同じ機能を持ちますが、3つ目のサブネット(データベースとアプリケーション用のプライベートサブネット)が2つに分割されています。データベース用のプライベートサブネットには、ユーザー環境からアクセスできません。

これらの2つのアプローチの間に大きな違いはないことが分かります。ただし、2つ目の方法では、データベース用のサブネットを別のルートテーブルとネットワークACLで保護することで、データベースをより安全に保護します。これにより、データベース層への接続をより効果的に制御、管理できます。

私たちの知識を活用

実装例を検討することで、詳細に落とし込んでみましょう。

シナリオ例

お客様は、SAP S/4HANA、SAP FioriおよびSAP BW on HANA(ABAPとJava)を導入する必要があります。これらのアプリケーションは、企業ネットワークからのみ接続可能である必要があります。SAML(Security Assertion Markup Language)によるシングルサインオン(SSO)のために、Active Directory(AD)またはActive Directory フェデレーション サービス(ADFS)との統合も必要です。SAP BWはレガシーアプリケーションとのファイルベースの統合も行い、この目的でSSHファイル転送プロトコル(SFTP)サーバーと通信します。SAP社はサポートのためにこれらのシステムに接続できる必要があります。SAP Solution ManagerのデータベースにはSAP ASEを採用し、SAPアプリケーションの集中監視および変更管理に使用します。すべてのアプリケーションは、SUSE Linux Enterprise Server(SLES)上で稼働していると仮定します。

AWS上のソリューション

この例では、ソリューション要素あたり1つのEC2インスタンスしか想定していません。ワークロードが水平方向にスケールする場合、または高可用性が必要な場合は、機能的に類似した複数のEC2インスタンスを同じセキュリティグループに含めることができます。この場合、セキュリティグループにルールを追加する必要があります。企業ネットワークとVPC間の接続には、IPsecベースのVPNを使用します。Red Hat Enterprise Linux(RHEL)またはMicrosoft Windows Serverを使用している場合は、セキュリティグループ、ルートテーブル、およびネットワークACLに設定変更が必要な場合があります。詳細については、オペレーティングシステムの製品マニュアル、またはAmazon Elastic Compute Cloud(EC2)のセキュリティグループのルールのリファレンスなど、その他の情報源を参照してください。プライマリーのADまたはADFSサーバー、レガシーSFTPサーバーなどの特定のシステムはオンプレミスに残ります。

ソリューションのアーキテクチャ図は以下です。

このアーキテクチャ図の設定例は以下を想定しています。

以下の表は、セキュリティグループの構成例です。セキュリティグループで定義されるルールの概要を示しています。正確なポート番号または範囲については、SAP製品のマニュアルを参照してください。

ネットワークトラフィックのフローは、以下のようなルートテーブルによって管理されています。

*AWS Data Providerは、Amazon CloudWatch、Amazon S3およびAmazon EC2のAWS APIに接続できる必要があります。詳細は、「AWS Data Provider for SAP Installation and Operations Guide」を参照してください。

インスタンスに追加の層のセキュリティが必要な場合、以下の表に示すようなネットワークACLを使用できます。ネットワークACLは高速かつ効率的で、前述の表に示すセキュリティグループに加えて、別の制御層を提供します。セキュリティの推奨事項については、「AWS Security Best Practices」を参照してください。

ある特定の時に(OSパッチ適用など)、EC2インスタンスから追加のインターネット接続が必要な場合があります。ルートテーブル、ネットワークACLおよびセキュリティグループは、この接続を一時的に許可するように調整できます。

ここまでの概要と今後の予定

このブログ記事では、内部専用接続が必要なアプリケーションにおけるサブネットのゾーニングパターンを例に説明してきました。他のサブネットのゾーニングパターンについては、このシリーズの次の記事を参照してください。

AWS上でSAPアプリケーション用のVPCを設定した皆様の経験についてもお聞きしたいと思います。この記事に関するご質問やご提案がありましたら、お気軽にお問い合わせください。

翻訳はPartner SA 河原が担当しました。原文はこちらです。

SAP Database Migration Option(DMO)を使ったAWSへの移行

Somckit Khemmanivanhは、Amazon Web Services (AWS)のSAPソリューションアーキテクトです。

このブログ記事では、SAP Software Update Manager(SUM)の機能であるDatabase Migration Option(DMO)を使って、AnyDBデータベースからAWS上のSAP HANAに移行する方法を説明します。SAPでは、SAP社がサポートするSAP HANA以外のソース・データベース(DB2、Oracle、SQL Serverなど)を指すときに、AnyDBという用語を使用しています。ここでは、オンプレミス・アーキテクチャからAWSへの移行オプションについて説明します(ここで留意すべきは、SAP HANAがターゲット・プラットフォームでない場合、他にも多くの移行オプションがあることです。詳細はホワイトペーパーMigrating SAP HANA Systems to X1 Instances on AWSをご覧ください)。

SAP HANAは完全なインメモリーで、列指向に最適化され、また圧縮されたデータベースです。 SAP社により認定されたSAP HANAシステムでは、160+ GB RAMから2TB RAMまでのシステムでSAP HANAデータベースをスケールアップ構成として稼働できます。また、最大14TBまでの認定されたスケールアウト構成も利用可能です。AWSであれば、このシステム構成の柔軟性により、ビジネスとITのニーズに合わせて拡張することができます。もしこれ以上のメモリーを要求するワークロードがある場合は、ぜひご連絡ください。私たちは、お客様要件にお応えできるよう取り組みたいと考えています。

DMOの概要については、SAP Community Networkをご覧ください。大まかには、AnyDBで稼働するSAPシステムをSAP HANAデータベースに移行する際にDMOを使うことができます。また、DMOにより、SAPシステムのソフトウェア・アップグレードとユニコード変換を移行時に合わせて行うこともできます(Enhancement Package(EHP) 8以降、ユニコードは必須)。 標準的なDMOのプロセスでは、ソースのAnyDBをターゲットのSAP HANAデータベースにオンラインかつ直接移行します。

sap-hana-dmo-process

図1: SAP HANA DMOのプロセス

移行先がAWS上のSAP HANAシステムである場合、この直接の移行プロセスを容易にするためにネットワーク接続を確立する必要があります。加えて、標準的なDMOのプロセスにおいて、SAP Note 2277055 – Database Migration Option (DMO) of SUM 1.0 SP18に記載されているように、特定の制限があります(SAPノートの参照には、SAP Service Marketplaceの資格情報が必要です) 。このSAPノートには、ネットワーク接続を介して(つまり、データセンター間で)DMO転送を実行する際の制限事項が説明されています。私たちが行ったテストと経験では、レイテンシーはDMOの実行時間に多少の影響を及ぼします。私たちは、お客様のアーキテクチャと設計を評価し、可能な解決策を提示する支援もいたします。 ぜひ、sap-on-aws@amazon.comまでお問合せください。

AWSでは、標準のDMOの範囲を超えた追加の移行オプションもご用意しています。AWSアドバンスドテクノロジーパートナーのATADATAが提供するATAmotionのような移行自動化製品を使うことで、ソース・システムを(オンプレミスのネットワークから)AWS上に複製し、複製されたシステムからDMOを使ってSAP HANAに移行できます。AWSのパートナーが提供するそれ以外の移行ツールやサービスは、AWSパートナーソリューションファインダーから探していただけますでしょうか。

一旦ソース・システムをAWS上に持ち込めば、AWSサービスの俊敏性と柔軟性を活用して、移行をテストしたり、本番移行を実施したりできます。シナリオの一例として、DMOによるダウンタイム最適化のテストを複数実施するなどがあります。それぞれのテストにおいて、EC2インスタンスのサイズ変更を活用することで、異なるシステムサイズや組合せを試すことができます。

大まかなプロセスとツールについて説明しましたので、ここからは2つの移行オプションに含まれる手順を説明します。まず、標準的なDMOの移行プロセスから始めます。このプロセスでは、現行のSAPシステムがオンプレミスのデータセンター内にあり、AWSに接続する必要のある単一のコンポーネントがDMOサーバーであることが前提となります。移行中、DMOサーバーはソース・データベースからターゲットのSAP HANAデータベースにデータをエクスポートします。この移行プロセスは以下のステップで構成されます:

      1. AWSアカウントを作成していない場合は作成します。
      2. WebサイトAWS Answersに掲載されているAWS Single VPC Designの図のように、データセンターとAWSリージョン間の仮想プライベートネットワーク(VPN)、またはAWS Direct Connect接続を確立します。設計上の考慮事項と詳細については、”Internal-Only VPC”の項を参照してください。vpc-connectivity-for-dmo

        図2: DMOによる移行のためのVPC接続

      3. SAP HANAデータベースインスタンスとSAPアプリケーションインスタンスを展開します(導入手順はSAP HANA Quick Startを参照してください)。
      4. DMOサーバーを構築します(DMOサーバーはオンプレミスでもAWS上どちらでも使うことができます)。DMOサーバーは 、ソースのデータベースサイズ、性能要求、システムリソース、およびダウンタイムなどの要件に応じて、独立したサーバーまたはSAPアプリケーションサーバーと同じ場所に配置できます(このステップの詳細はSAP社資料を参照してください)。
      5. オンプレミスのDMOサーバーとAWS上のSAP HANAデータベースインスタンス間の接続をテストします(詳細については、APNブログのAmazon VPC for On-Premises Network Engineersシリーズを参照してください)。
      6. DMOを使用して、オンプレミスのデータベースをAWS上のSAP HANAデータベースに移行します(詳細はSAP社資料を参照してください)。
      7. SAP HANAデータベースインスタンスに接続する新しいSAPアプリケーションサーバーをAWS上にインストールします(詳細はSAP社資料を参照してください)。

dmo-migration

図3: 標準的なDMOのアーキテクチャ

2つ目の移行オプションとして、AWSパートナーツールを使用してソース・システムをAWS上に複製した後、SAP HANAに移行する方法を説明します。このプロセスを使用するには、現行のSAPシステムがオンプレミスのデータセンター内に存在する必要があります。この手順は、標準的なDMOのプロセスに似ています:

      1. AWSアカウントを作成していない場合は作成します。
      2. WebサイトAWS Answersに掲載されているAWS Single VPC Designの図のように、データセンターとAWSリージョン間のVPN、またはAWS Direct Connect接続を確立します。設計上の考慮事項と詳細については、”Internal-Only VPC”の項を参照してください。
      3. AWS上にソース・システムを複製します。ATAmotionを使う場合は、ATADATAコンソールを使用してこの複製処理を実行します。
      4. SAP HANAデータベースインスタンスとSAPアプリケーションインスタンスを展開します(導入手順はSAP HANA Quick Startを参照してください)。
      5. AWS上にDMOサーバーを構築します。DMOサーバーは 、ソースのデータベースサイズ、性能要求、システムリソース、およびダウンタイムなどの要件に応じて、独立したサーバーまたはSAPアプリケーションサーバーと同じ場所に配置できます(このステップの詳細はSAP社資料を参照してください)。
      6. ステップ3の複製されたソース・システムに対してDMOで移行プロセスを実行します。AWS上の移行プロセスを完了します(詳細はSAP社資料を参照してください)。詳細については、SAP文書を参照してください。
      7. SAP HANAデータベースインスタンスに接続する新しいSAPアプリケーションサーバーをAWS上にインストールします(詳細はSAP社資料を参照してください)。

partner-migration図4: ATADATAを組み合わせたDMOのアーキテクチャ

次に、両方の移行オプションに共通するアーキテクチャーと設計のいくつかの側面について説明します。

ネットワーク接続(帯域とレイテンシー)

データセンターとAWS間のネットワーク接続には、転送する必要のあるデータ量がどれくらいなのか、移行をどれくらいの時間で完了したいかによって、VPNまたはAWS Direct Connectを使用します。転送するデータ量は、ターゲットのSAP HANAデータベースのサイズと相互関係にあります。例えば、ソースのデータベースサイズが2TiB未満の場合、ターゲットのSAP HANAデータベースのサイズは250から600GiBになります(この見積もりは、SAP HANAの標準的な1:4または1:5倍の圧縮率を前提としていますが、より高い圧縮率のときも見受けられます)。お客様はネットワーク越しに200から250GiBの転送を行う必要があります。SAP Note 1793345 – Sizing for SAP Suite on HANASAP Note 1736976 – Sizing Report for BW on HANAに記載のあるSAPサイジングレポートからターゲットのデータベースサイズを見積もることができます。

移行プロセス中に切断があるとデータを再送信する必要があるため、信頼性の高いネットワーク接続を確立することをお勧めします。AWS Direct ConnectはVPN接続よりも高い信頼性と帯域を提供します。

SAPアプリケーションサーバー

DMOはソース・データベースをターゲットのSAP HANAデータベースに移行するだけで、SAPアプリケーションサーバーを設定しません。そのため、DMOによる移行が完了した後、AWS上に新しいSAPアプリケーションサーバーを構築する必要があります。以下のような様々なインストールシナリオから選択できます:

組織の要件、制約、サイジング、コスト、複雑さ、その他のトレードオフに基づいて最適なインストールオプションを決定する必要があります。

SAPアプリケーションサーバーのインストールと設定プロセスを合理化するために、多くのAWSの技術が利用できます。これらには、AWS CloudFormationテンプレートスナップショットからのAmazon Machine Image (AMI)の作成、そしてAmazon EC2 Run commandなどがあります。このトピックについては、今後のブログ記事で説明する予定です。

SAP仮想ホスト名

SAPシステムは、DNSまたはローカルのホストファイルを通じてホスト名を解決します。私たちは、SAPシステムのSAP仮想ホスト名と組み合わせてDNSを使用することをお勧めしています。SAP仮想ホスト名を使用すると、AWS上で同じ仮想ホスト名を維持できるため、移行が容易になります。詳細は、SAP Note 962955 – Use of virtual or logical TCP/IP host namesを参照してください。

小さく始めましょう

SAPの移行は複雑で、潜在的な問題を最小限に抑えるためにも適切な計画が必要です。SAP on AWSとAWSそのものの理解を深めるために、まずは小規模なスタンドアロンSAPシステムを対象にすることをお勧めします。サンドボックス、開発、トレーニング、デモ、およびSAP IDES(Internet Demonstration and Evaluation System)環境がそのようなシステムとして見込めます。SAP DMOによる移行を続行しない場合は、現行のソース・システムを元通りお使いいただけます。再有効化するだけです。

ご不明な点がありましたらsap-on-aws@amazon.comまでご連絡ください。SAP on AWSでサポートが必要な特定の問題については、コンポーネントBC-OP-LNX-AWSもしくはBC-OP-NT-AWSのSAPへのサポートメッセージを作成してください。

読んでいただきありがとうございました!

— Somckit

翻訳はPartner SA 河原が担当しました。原文はこちらです。

SAP HANA on AWSの展開 – どのような選択肢が?

Sabari RadhakrishnanはAmazon Web Services(AWS)のパートナー ソリューション アーキテクトです。

SAPアプリケーションをSAP HANAプラットフォーム上に移行、または新規で構築する予定がありますか?もしそうであれば、AWSがSAP HANAのワークロードを実行するためにどのような選択肢を提供しているか知りたいのでは、と思っています。本ブログ記事では、SAP HANAに必要となる主なインフラストラクチャ・コンポーネントおよびAWS上にSAP HANA仮想アプライアンスを構築するためのビルディング・ブロックについて説明します。本記事により、展開方法について深くご理解いただけると幸いです。本記事は、ブログシリーズとして、SAP on AWSに関する様々な情報を公開する最初の記事ですので、頻繁に確認していただければと思います。

SAP HANA Tailored Data Center Integration (TDI) モデルに準拠している場合、メモリー、コンピュート、ストレージ、そしてネットワークの4つがSAP HANAに必要となる主要なインフラストラクチャ・コンポーネントになります。これらの中で、メモリーがデータサイズに依存する唯一の変数となっています。コンピュート、ストレージ、ネットワーク要件はメモリーサイズから算出されるか、あらかじめ定義されています。例えば、メモリーサイズに基づいたコンピュートに必要なコア数の決定には、SAP社が設定した標準的なコアとメモリー比率の要件があります。ストレージについては、メモリーサイズに関係なく、SAP HANA Hardware Configuration Check Tool (HWCCT) ガイドに記載されているように、異なるブロックサイズやその他のKPIにおける特定のスループット要件を満たす必要があります。 最後にネットワークですが、特にスケールアウト構成において、メモリーサイズに関係なく、SAP HANAのノード間で最小9.5 Gbpsのスループットを実現する必要があります。

ここ数年、AWSはSAP社と密に連携して、AWSプラットフォーム上でSAP HANAのワークロードを実行するためのコンピュートおよびストレージ構成の認証を取得しています。どのように我々はこれを実現したのでしょうか。その答えは、 AWSがAmazon Elastic Compute Cloud (Amazon EC2)のインスタンスを様々なメモリーサイズで設計し、コンピュートのための適切なコアとメモリー比率を含むSAP HANAの厳しい性能要件を満たすことです。加えて、Amazon Elastic Block Store (Amazon EBS)は多くの場合にTDIモデルのストレージKPIを満たしています。そしてEC2インスタンスのネットワーク帯域幅は、スケールアウト構成のノード間通信で必要な9.5 Gbpsを満たしています。

それではこれらのビルディング・ブロックと構成オプションについて詳細をみていきましょう。

メモリーとコンピュート

AWSでは様々なワークロードに対応できるよう、いくつかのEC2インスタンスのタイプをご用意しています。 メモリー最適化のR3とR4インスタンス、そして大容量メモリー最適化のX1インスタンスといったSAP HANAのワークロードに最適な2つのEC2インスタンスのタイプがあります。これらのインスタンスファミリーは、SAP HANAのようなインメモリーワークロード専用に設計されています。このインスタンスタイプとインスタンスファミリーにはSAP HANAのワークロードを実行するための様々なコンピュートオプションがあります。OLAP(online analytical processing)用途、例えばSAP Business Warehouse on HANAやSAP BW/4HANA、データマートなどにおいて、SAP社の完全サポート対象として244GiBから2TBまで垂直方向に、また最大14TBまで水平方向にスケールすることができます。AWSラボでは、最大25ノードの展開、つまり合計50 TBのRAMのテストに成功していることもご認識ください。OLTP(online transaction processing)用途、例えばSAP Business Suite on HANA、SAP S4/HANA、SAP CRMなどにおいては、今日現在で244GiBから2TBまで垂直にスケールすることが可能です。最新のCPU世代でAWSが新しいインスタンスタイプを提供し続けるにあたり、弊社はSAPと密に連携して、それらのインスタンスタイプでもSAP HANAのワークロードのために認証を取得していくつもりです。SAP HANAワークロードの本稼働環境で使用できる認定EC2インスタンスタイプをすべて表示するには、SAP社が認定およびサポートするSAP HANAハードウェアディレクトリーのCertified IaaS Platformsのページを参照してください。特定のインスタンスファミリーでは、非本稼働用途においてr3.2xlargeやr4.2xlargeといった小さいインスタンスサイズを使用することでTCOを削減することもできます。クラウドネイティブなインスタンスにより、SAP HANAのメモリー利用量に合わせて64GiBから2TBに増やすことを、またはその逆に減らすことも、数分でシームレスに変更できる柔軟性があることも覚えておいてください。SAP HANAの導入において、これまでにはない俊敏性がもたらされます。

次の表と図は、これまで説明してきたメモリーとコンピュートの選択肢を整理したものです。

HANA_on_AWS

本稼働ワークロードの選択肢
インスタンスタイプ メモリー (GiB) vCPU SAPS
x1.32xlarge 1,952 128 131,500
x1.16xlarge 976 64 65,750
r4.16xlarge 488 64 76,400
r3.8xlarge 244 32 31,920
非本稼働ワークロードの選択肢
インスタンスタイプ メモリー (GiB) vCPU SAPS
r4.8xlarge 244 32 38,200
r4.4xlarge 122 16 19,100
r4.2xlarge 61 8 9,550
r3.4xlarge 122 16 15,960
r3.2xlarge 61 8 7,980
 — SAP Business One, version for SAP HANAについてはこれ以外のインスタンスとメモリーサイズが利用可能です。このトピックは別のブログを参照してください。

ストレージ

AWSでは、SAP HANAの永続ブロックストレージに複数のオプションを用意しています。性能重視のデータやログボリューム用に2つのSSD-backed EBSボリュームタイプ(gp2io1)があり、またSAP HANAバックアップ用にコスト最適化および高いスループットのHDD-backed EBSボリューム(st1)があります。

  • 汎用SSD (gp2) ボリュームタイプでは、ボリュームあたり最大160MB/sのスループットを実現できます。TDIモデルの要件である最大400MB/sのスループットを達成するためには、SAP HANAのデータとログファイル用に3つのボリュームをストライピングする必要があります。
  • プロビジョンドIOPS SSD (io1) ボリュームでは、ボリュームあたり最大320MB/sのスループットを提供し、スループット要件を満たすには少なくとも2つのボリュームをストライピングする必要があります。
  • スループット最適化HDD (st1) ボリュームでは、大きなブロックサイズでのシーケンシャルな読み書きで最大500MB/sのスループットを実現できます。そのため、st1はSAP HANAバックアップの保存先に理想的な候補となります。

重要な点の1つとして、それぞれのEBSボリュームがAWSのアベイラビリティゾーン内で自動的に複製されることで、障害から保護され、高い可用性と耐久性を提供することがあります。 これにより、性能を最大限に引き出すためにオペレーティングシステムレベルでRAID 0アレイが構成でき、一方でボリュームの保護(RAID 10またはRAID 5)は心配する必要がなくなります。

ネットワーク

SAP HANAのネットワーク性能は、特にスケールアウト構成において重要な要素になります。すべてのEC2インスタンスは一定のネットワーク帯域幅を提供しており、X1のような最新のインスタンスファミリーでは、SAP HANAの要求に合わせて最大20 Gbpsのネットワーク帯域幅を提供します。さらに多くのインスタンスでは、Amazon EBSストレージ接続のための独立したネットワーク帯域幅を持っています。例えば、もっとも大きいX1インスタンス(x1.32xlarge)では、20 Gbpsのネットワーク帯域幅と10 Gbpsの専用ストレージ帯域幅を持ちます。 R4インスタンス(r4.16xlarge)では、20 Gbpsのネットワーク帯域幅と12 Gbpsの専用ストレージ帯域幅を持ちます。 以下はSAP認定インスタンスのネットワーク機能の簡単な概要になります。

本稼働ワークロードの選択肢
インスタンスタイプ ネットワーク帯域幅 (Gbps) EBS専用の帯域幅 (Gbps)
x1.32xlarge 20 10
x1.16xlarge 10 5
r4.16xlarge 20 12
r3.8xlarge 10*

* ネットワークとストレージのトラフィックは同じ10 Gbps ネットワークインターフェイスを共有

オペレーティングシステム(OS)

SAP社では、SUSE Linux Enterprise Server(SLES) またはRed Hat Enterprise Linux(RHEL)上でのSAP HANAの実行をサポートしています。どちらのOSディストリビューションもAWS上でサポートされます。さらに、お客様はAWS Marketplaceで提供されるSUSEまたはレッドハットのSAP HANA固有イメージを使って容易に開始することができます。また、お客様自身のOSサブスクリプションを持ち込むことも可能です。SAP HANA on AWSのOSに関する選択肢の詳細については、今後のブログ記事をご期待ください。

すべてをまとめて構築

“AWSがTDI同様にSAP HANAのビルディング・ブロックを提供するのは素晴らしいことですが、AWS上でこれらのコンポーネントをまとめてSAPの要件を満たすシステムを構築するにはどうすればよいですか?”と思うかもしれません。AWSのお客様からも数年前にこの質問を受けており、AWS Quick Start for SAP HANAを開発しました。 このクイックスタートでは、AWS CloudFormationテンプレート(Infrastructure as Code)とカスタムスクリプトを利用して、ストレージやネットワークを含むAWSインフラストラクチャ・コンポーネントの展開を支援します。クイックスタートは、SAP HANAインストールに必要となるオペレーティングシステムの設定も行います。また、お客様自身のSAP HANAソフトウェアとライセンスを持ち込むことで、SAP HANAソフトウェアのインストールもできます。クイックスタートは、世界中の多くのAWSリージョンで使用できるセルフサービスのツールです。SAP HANAシステムのインフラストラクチャの展開は、シングルノードであるかスケールアウトシステムであるかに関係なく、一貫して予測可能で繰り返し可能な方法で、1時間未満で提供されます。SAP HANAクイックスタートの実行は、AWS re:Invent 2016 カンファレンスにてSAP社との共同講演で実演した録画されたデモをご覧ください。

SAP HANAの構築には、AWSクイックスタートを利用したインフラストラクチャの展開を強く推奨します。ただし、クイックスタートを使用できない場合(たとえば、独自のOSイメージを使用する場合など)には、SAP HANA環境を手動で構築し、ビルディング・ブロックを自分で配置することができます。ストレージとインスタンスタイプについては必ずrecommendations in the Quick Start guideに従ってください。この特定の目的のために、SAP HANA on AWS – Manual Deployment Guideでステップ・バイ・ステップの手順も提供しています。(RHELを含む最新OSバージョンの手順を含む本ガイドはすぐに更新される予定です。)

バックアップとリカバリー

信頼性の高い方法でSAP HANAデータベースをバックアップおよびリストアする機能は、ビジネスデータを保護する上で非常に重要です。SAP HANA純正のツールを使用してデータベースをEBSボリュームにバックアップし、最終的にバックアップされたファイルをAmazon Simple Storage Service (Amazon S3)に移行することで、耐久性を高めることができます。Amazon S3は、スケーラビリティと耐久性に優れたオブジェクトストレージのサービスです。Amazon S3のオブジェクトは、リージョン内の複数の施設に重複して格納され、99.999999999の耐久性を実現します。Commvault、EMC NetWorker、Veritas NetBackup、IBM Spectrum Protect(Tivoli Storage Manager)などのエンタープライズクラスのバックアップソリューションを選択することもできます。これらのソリューションは、Amazon S3およびSAP HANA Backintインタフェースと統合されています。これらのパートナーソリューションは、SAP HANAデータベースをAmazon S3に直接バックアップし、エンタープライズクラスのソフトウェアを使用したバックアップ・リカバリーの管理に役立ちます。

高可用性(HA)と災害対策(DR)

HAとDRは、SAP HANA上で実行されるビジネスクリティカルなアプリケーションにとって重要です。AWSは、アップタイムとリカバリーの要件(RTO / RPO)に応じたHAとDRソリューションを構成できるよう、世界中の複数のAWSリージョンと各AWSリージョン内の複数のアベイラビリティゾーンを含むいくつかのビルディング・ブロックを提供しています。コスト最適化ソリューションまたはダウンタイム最適化ソリューションのどちらを探している場合でも、SAP HANA HA/DRアーキテクチャにいくつかの独自オプションを用意しています — これらの詳細については、SAP HANA HA/DR guideを参照してください。今後のブログ記事でこのトピックについて詳しく説明する予定です。

移行

実際の移行には、SAP標準のツールセットとして提供されるSAP Software Provisioning Manager(SWPM)やDatabase Migration Option(DMO) of the Software Update Manager(SUM)、または3rdパーティーの移行ツールを使って、任意のデータベースで実行されているSAPアプリケーションをSAP HANA on AWSに移行できます。 SAPのAWSへの移行プロセスは、一般的なオンプレミスの移行シナリオとほぼ変わりません。オンプレミスのシナリオでは、通常、同じデータセンター内にソースシステムとターゲットシステムが存在します。AWSに移行する場合の唯一の違いは、ターゲットシステムがAWS上に存在することです。そのため、AWSを自社のデータセンターの拡張と考えることができます。また、移行中に、オンプレミスのデータセンターでエクスポートされたデータをAWSに転送するための様々なオプションもあります。これらの選択肢の理解をより深めるために、Migrating SAP HANA Systems to X1 Instances on AWSを参照することをお勧めします。

その他の検討事項として、運用、サイジング、スケーリング、Amazon CloudWatchのようなAWSサービスとの統合、ビッグデータソリューションなどがあります。これらは今後のブログ記事で詳細を取り上げる予定です。それまでの間に、AWS Quick Start for SAP HANAを使ってSAP HANA on AWSを開始してみてはいかがでしょうか。AWS上で実行されるSAPワークロードの詳細については、SAP on AWS websiteのホワイトペーパーもご覧ください。

最後に、現在利用可能なシステムサイズを超えて拡張するシステムが必要な場合は、当社までご連絡ください。 私たちはお客様の要件について話し合い、その実装に関してご協力いただけることを嬉しく思います。

– Sabari

翻訳はPartner SA 河原が担当しました。原文はこちらです。

新発表 – X1インスタンスのクラスタによるSAP HANAの稼働

SAP HANAの大規模ワークロードにおける新しい利用方法をお伝えするために、私の同僚のSteven Jonesが寄稿してくれました。

Jeff;


AWSクラウド上でSAP HANAのような大規模なインメモリデータベースやインメモリアプリケーションを稼働させるため、Amazon EC2 メモリ最適化インスタンスファミリーに新しいX1インスタンスタイプとして、2TBのRAMを搭載したx1.32xlargeの利用開始を5月に発表しました。

X1インスタンスのシングルノード構成でのSAP HANAにおけるSAP認定取得を同時に発表し、それ以来、SAP S/4HANAとSuite on HANAといったOLTP、またBusiness Warehouse on HANAにBIといったOLAPにおける幅広い用途で、世界中の多くのお客様にご利用いただいています。とはいえ、クラスタ化されたX1インスタンスによるスケールアウト構成でのSAP HANAの提供のご要望も多くいただいていました。

SAP認定プロセスに応じたSAP HANAスケールアウト構成の広範囲なテストとベンチマークを終え、本日、高度に最適化された次世代データウェアハウスSAP BW/4HANAの新発表と同時に、X1インスタンスの最大7ノード、つまり14TBのRAMに対応したSAP BW/4HANAを含むOLAPシナリオの大規模スケールアウト構成におけるSAP認定取得を発表できることを嬉しく思います。 拡張性、柔軟性、コスト効果の高いSAP社の新しいフラッグシップのデータウェアハウスであるSAP BW/4HANAのローンチを私たちがサポートできることに非常に興奮しています。

以下は7台のX1インスタンスで稼働する大規模(14TBメモリ)なスケールアウト構成を表示したSAP HANA Studioのスクリーンショットです:

そして、これはほんの始まりに過ぎません。私たちは他のサイズでのX1インスタンスを利用可能にする計画があり、より大きな50TBメモリまでのクラスタ構成を研究室でテストしています。もし、14TBメモリを超える大規模なスケールアウト構成が必要な場合は、ご支援しますので、ぜひご相談ください。

コストと複雑性の削減
多くのお客様が複数のR3インスタンスによるスケールアウト構成でSAP HANAを稼働してきました。今回の新しい認定により、コストと複雑性の両方が削減できる、より少ないインスタンス数での大規模スケールアウト構成に統合できる可能性があります。統合戦略における詳細はSAP HANA Migration Guideをご参照ください。

柔軟性のある高可用性オプション
AWSプラットフォームでは、可用性が求められるSAP S/4HANAやSAP BW/4HANAのような環境で使われる重要なSAP HANAを保護するために、お客様のご要望に応じた様々なオプションを提供しています。実際に、従来型のホスティングプロバイダーやオンプレミスのスケールアウト構成でSAP HANAを稼働しているお客様からは、ハードウェア障害に迅速に対応できるように予備のハードウェアやスタンバイノードを購入し非常に高額なメンテナンス契約料を支払わなければならない、とよくお伺いします。他には、残念ながら、何も起こりませんようにと祈って、この余分なハードウェアをなしで済ませようとされています。

AWSプラットフォーム上で活用されている便利なオプションの一つは、Amazon EC2 Auto Recoveryと呼ばれるソリューションです。AWSに起因するハードウェア障害や問題が発生したときに自動的に正常なホスト上で復旧するよう、EC2インスタンスを監視するAmazon CloudWatch アラームを簡単に作成できます。復旧されたインスタンスは、アタッチされたEBSボリュームやホスト名、IPアドレス、AWSインスタンスIDなどの構成情報も元のインスタンスと同じものです。Amazon CloudWatchの標準料金(例えば、米国東部では月当たりアラームごとに0.10ドル)が適用されます。実質、ハードウェア異常への迅速な復旧のために、私たちの持つ空いているキャパシティをすべてお客様の予備機として活用することが可能です。

開始方法
最新のAWS Quick Start Reference Deployment for SAP HANAを使うことで、十分にテストされたX1インスタンスでのシングルノード構成、およびスケールアウト構成のSAP HANAの本稼働環境を1時間もかからずにご利用いただけます。

Amazon Web Services上でのSAP HANAの導入を計画される際には、ベストプラクティスとガイダンスとしてSAP HANA Implementation and Operations Guide もご確認ください。

AWSとSAPのエキサイティングな共同発表に立ち合いに、9月7日にベイエリアにいらっしゃいませんか?ここから登録いただき、サンフランシスコでお会いしましょう!

来られないでしょうか?SAPをご利用のお客様にAWSとSAP社が共同でご提供する価値を知っていただくためにも、太平洋標準時で9月7日朝7時から9時のライブストリーミングにご参加ください。

皆様のご参加をお待ちしております。

Steven Jones, Senior Manager, AWS Solutions Architecture

翻訳はPartner SA 河原が担当しました。原文はこちらです。

EC2のX1インスタンス – メモリー重視のワークロードに対応可能

多くのAWSのお客様はメモリー性能を必要とするビッグデータ、キャッシング、および分析系のワークロードを実行しており、増え続けるメモリー量に対応したEC2インスタンスについてのご要望をいただいていました。

昨年の秋、初めて新しいインスタンスタイプX1についての計画をお伝えしました。今日、このインスタンスタイプのインスタンスサイズx1.32xlargeが利用可能になったことを発表します。このインスタンスの仕様は以下です:

  • プロセッサー: 2.3GHzの4 x Intel™ Xeon E7 8880 v3 (Haswell) – 64コア / 128 vCPUs
  • メモリー: Single Device Data Correction (SDDC+1)を実現した1,952 GiB
  • インスタンスストレージ: 2 x 1,920 GB SSD
  • ネットワーク帯域幅: 10 Gbps
  • 専用のEBS帯域幅: 10 Gbps (デフォルトでEBS最適化、追加料金不要)

Xeon E7 プロセッサーはターボ・ブースト2.0(最大3.1GHzまで)、AVX 2.0AES-NI、そして非常に興味深いTSX-NI命令をサポートしています。AVX 2.0(Advanced Vector Extensions)は、HPCやデータベース、ビデオ処理といったワークロードの性能を向上できます; AES-NIは、AES暗号化を使用するアプリケーション速度を向上します。新しいTSX-NI命令は、トランザクションメモリーと呼ばれる素晴らしい機能をサポートします。この命令は、並列性が高いマルチスレッドアプリケーションにおいて、メモリーアクセスを必要としたときに行われる低レベルのロックとアンロックの数を削減することで、非常に効率的な共有メモリーの使用を可能とします。

X1インスタンスは、米国東部(バージニア北部)、米国西部(オレゴン)、欧州(アイルランド)、欧州(フランクフルト)、アジアパシフィック(東京)、アジアパシフィック(シンガポール)、そしてアジアパシフィック(シドニー)リージョンで準備ができており、利用申請をしていただければできるだけ早く稼働させようと思っています。また、あまり遠くない将来に、X1インスタンスを他のリージョンで、および他のインスタンスサイズを提供する計画があります。

米国東部(バージニア北部)リージョンの場合、3年契約の一部前払いで1時間あたり3.970ドルでご利用いただけます; 詳細な情報はEC2の料金ページをご覧ください。今日時点で、リザーブドインスタンスDedicated Host Reservationsを購入することができます; スポット価格は短期的なロードマップにあります。

x1.32xlargeが動いているスクリーンショットをいくつか記載します。lscpuで4ソケットにわたり128vCPUsが搭載されていることが表示されています:

システム起動時のカーネルがアクセス可能な総メモリーです:

topコマンドでは膨大な数のメモリーとプロセスが表示されています:

エンタープライズ規模のSAPワークロードに対応可能
X1インスタンスは、本稼働ワークロードにおけるSAP認定を取得しています。SAP HANAに必要とされるSAP OLAPとOLTPの両ワークロードの性能要件を満たしています。

お客様は、オンプレミスからAWSに移行できますし、もちろん新規構築することもできます。次世代ビジネススイートSAP S/4HANA、または以前のバージョンのどちらも稼働させることができます。

現在、多くのAWSのお客様が、複数のR3インスタンスを並べたスケールアウト構成でSAP HANAを稼働させています。これらのワークロードの多くは1台のX1インスタンスで実行できるようになります。この構成であれば、構築も容易で、運用コストも抑えられます。後述していますが、構成オプションの詳細情報は最新のSAP HANA Quick Start にて提供いたします。

X1インスタンスで実行された環境をSAP HANA Studioでみると次のようになります:

X1インスタンスでSAP HANAを稼働させる場合、災害対策(DR)や高可用性(HA)においても複数の興味深いオプションがあります。例えば:

  • 自動リカバリー – RPO (Recovery Point Objective)とRTO(Recovery Time Objective)にもよりますが、EC2 Auto Recoveryを使うことでシングルインスタンスで稼働することができるかもしれません
  • ホットスタンバイ – 2つのアベイラビリティゾーンでX1インスタンスを稼働し、SAP HANAシステムレプリケーションによって予備インスタンスと同期することができます
  • ウォームスタンバイ / 手動フェイルオーバー – プライマリーのX1インスタンスとセカンダリーには永続ストレージが付与された小さなインスタンスで構成することもできます。フェイルオーバーが必要となった場合、セカンダリーインスタンスを停止し、インスタンスタイプをX1に変更し、再起動します。このユニークなAWSならではのオプションであれば、低コストを維持しながら、迅速な復旧が実現できます

今日のローンチにあわせてSAP HANA Quick Startを更新しています。新規のVPCもしくは既存のVPC内に、十分に検証済みのSAP HANAが1時間以内で利用可能です:

このクイックスタートは 、インスタンスと関連するストレージを構成し、SAP HANAと前提となるOSパッケージをインストールするのにお役立ちいただけます。

また、私たちはSAP HANA Migration Guideも公開しました。現行のオンプレミスもしくはAWS上で稼働するSAP HANAワークロードのAWSへの移行をお手伝いします。

Jeff;

翻訳はPartner SA 河原が担当しました。原文はこちらです。