Amazon Web Services ブログ

Category: SAP

近日公開:AWS MarketplaceにおけるSLES for SAP

AWSでSAP Partner Solutions Architectを務めるSabari Radhkrishnanによる記事です。   Amazon Web Services(AWS)とSUSEは、SUSE Linux Enterprise Server(SLES)を共同のSAP顧客に提供できるよう、長年に渡って協力してきました。AWSが2012年にSAP HANA Oneを含むSAPワークロードのプラットフォームとして初めて認定されてから、お客様はAWS上でSAPアプリケーションを実行するためにSLESオペレーティングシステムを使用してきました。AWSが2014年にSAP HANAのインスタンスとして認定されてからは、お客様はAWS上のSAP HANAの展開にもSLESを使い始めました。2015年に、SUSEの独自のサブスクリプションプログラムを通じて、SLES for SAPがAWS上で利用可能になりました。2016年には、SLES for SAPをオンデマンドイメージとしてAWS Marketplaceから利用できるようになり、既存および新規のお客様がミッションクリティカルなSAPワークロードをより簡単に始められるようになっています。 共同のSAP顧客に最高の体験を提供するための継続的な取り組みの一環として、2017年第4四半期にAWSのオファリングとしてSLES for SAPがAWS Marketplaceから利用できるようになることを本日発表します。これは、約7年前にSLESを提供開始して以来、AWSとSUSEによる2つ目の共同リストになります。SAP HANAのようなインメモリ・ワークロード用に特別に設計されたX1およびX1eインスタンスの提供により、開発、テストおよび本番環境のSAPワークロードをAWS上で稼働するお客様が増えています。 新しいSLES for SAPは、AWSとSUSEの共同サポートが受けられ、競争力のある価格で提供されるため、AWS上でSAPワークロードをより簡単に実行できるようになります。AWSとSUSEは、AWS上のSAPワークロード向けのOSを最適化し、強化するために協力し続けます。 SLES for SAPには、HAE(High Availability Extension)が含まれているため、SAP HANAインスタンスをアベイラビリティゾーンをまたがってシームレスにフェールオーバーできます。このソフトウェアには、ページキャッシュ管理やSAPワークロード用に最適化されたカーネル設定といった様々な拡張機能も含まれています。さらに、SLES for SAPイメージは長期サービスパックサポートに対応しているため、お客様は最新から2つ前のサービスパックを最大18ヶ月間使用することができます。SLES for SAPを使用する利点の詳細は​​、SUSE Webサイトを参照してください。 お客様は、AWS Quick Start for SAP HANAを使用して、SAP HANAワークロード用のSLES for SAPを簡単に始めることができます。このクイックスタートは、AWS、SAP、そしてSUSEのベストプラクティスに従って、SAP HANAの導入に必要なインフラストラクチャの構築と設定を1時間以内で行うのに役立ちます。 お客様は、引き続きSUSEのBYOS(bring-your-own-subscription)プログラムを活用することで、既存のサブスクリプションを使用してAWS上でSAPワークロードを実行することができます。詳細は、 http://aws.amazon.com/suseを参照してください。SAP on AWSの詳細については、http://aws.amazon.com/sapをご覧ください。 この発表の詳細については、SUSE […]

Read More

今すぐ利用可能 – 4TBメモリ搭載のEC2インスタンス

今年の初めに、最大16TBメモリ搭載のEC2インスタンスを提供する計画をお伝えしました。本日、4つのAWSリージョンで4TBのDDR4メモリを搭載した新しいx1e.32xlargeインスタンスが利用可能になったことを発表いたします。以前の記事で書いたように、これらのインスタンスは、SAP HANAなどのメモリ重視のインメモリアプリケーションのために設計されています。 既に多くのお客様が、既存のx1.32xlargeインスタンス上で本稼働SAPアプリケーションを実行しています。本日のリリースによって、これらのお客様は、より大きなデータセットを保管・処理できるようになり、非常に大規模な本番環境でも稼働できるようになりました。 x1e.32xlargeは、x1.32xlarge同様に、4ソケットのIntel Xeon E7 8880 v3 Haswellプロセッサ 2.3GHz (128vCPUs)で実行され、大きなL3キャッシュやメモリ帯域幅を持ち、CステートとPステート制御による最適なパフォーマンスを提供します。 ネットワーク面では、インスタンスごとに最大8つのElastic Network Interfaces(ENIs)をサポートし、Elastic Network Adapter(ENA)によって、EC2プレイスメントグループ内で起動したときに最大25Gbpsのネットワーク帯域幅を提供します。インスタンスはデフォルトでEBS最適化されており、EBSボリューム専用の14Gbpsの帯域幅があり、インスタンスあたり最大80,000IOPSをサポートします。インスタンスには、1,920GBのSSDボリュームのペアも含まれています。 【いくつかのメモ】 x1e.32xlargeに関して、いくつか覚えておくべき事項があります: SAP認定 – x1e.32xlargeインスタンスは、SAP Business Suite on HANA(SoH)、SAP Business Warehouse on HANA(BWoH)、次世代ERPであるSAP S/4HANAや次世代データウェアハウスソリューションであるSAP BW/4HANAの本稼働HANA環境としてSAP社から認定およびサポートされる大規模なクラウドネイティブインスタンスです。もし、お客様が既にX1インスタンスでSAP HANAワークロードを実行されているのであれば、迅速かつ容易にスケールアップすることができます。SAP HANA on the AWS Cloud Quick Start Reference Deploymentは更新済みで、SAPとAWSのベストプラクティスに従って高い性能と信頼性を実現した構成の導入を支援します。SAP HANA Hardware DirectoryとSAP HANA Sizing Guidelinesも関連しています。 リザーブドインスタンス – リザーブドインスタンスのリージョン単位の柔軟性は、x1とx1eには適用されません。 【今すぐ利用可能】 x1e.32xlargeインスタンスは、米国東部(バージニア北部)、米国西部(オレゴン)、欧州(アイルランド)、そしてアジアパシフィック(東京)リージョンで、AWS Management Console、AWS Command Line Interface(CLI)、AWS SDKs、あるいはAWS […]

Read More

SAP on AWSにおけるVPCサブネットのゾーニングパターン 第2回:ネットワークのゾーニング

この記事は、Amazon Web Services(AWS)のソリューション アーキテクト、Harpreet SinghとDerek Ewellによるものです。 VPCサブネットのゾーニングパターンに関するシリーズ記事の第1回目では、SAPアプリケーションへのいくつかの接続方法を紹介し、内部専用接続のためのAmazon Virtual Private Cloud(Amazon VPC) サブネットのゾーニングパターンについて詳細を説明しました。この第2回となる記事では、従来のアプリケーションにおけるネットワークのゾーニングをAWS上でどのように実装できるか説明します。 従来のオンプレミス環境の実装モデルでは、アプリケーションは様々なネットワークゾーンに分離されています: 制限付きゾーン: これは最も安全なゾーンで、機密データを管理します。例えば、会計や人事ソリューション、コンテンツリポジトリやファイルサーバー用のデータベースをここに配置します。 イントラネットゾーン: このゾーンは、制限付きゾーン内のデータベースにアクセスするアプリケーションサーバーを対象としています。例えば、SAP Advanced Business Application Programming(ABAP)、Java Central ServicesといったSAPアプリケーションサーバーをここに配置します。企業ネットワークに接続されるエンドユーザーのデバイスもこのゾーンにも配置されます。 エクストラネットゾーン: このゾーンには、SAP Process Orchestration(PO)やSAP Process Integration(PI)、SSH File Transfer Protocol(SFTP)サーバー、SAP TREXなどのミドルウェアを配置します。このゾーンは、外部ゾーンと内部ゾーンの間の中間ゾーンとして機能します。 外部ゾーン: このゾーンでは、インターネットに直面しているアプリケーションとアプライアンスを管理し、内部ゾーンのアプリケーションの入口または出口のポイントとして機能します。このゾーンに配置されるソリューションの例としては、Network Access Translation(NAT)インスタンス、リバースプロキシ、およびSAProuterです。 管理/共有サービスゾーン: 上記のすべてのゾーンで必要とされるMicrosoft Active Directory、管理サーバー、SAP Solution Manager、あるいはDNSサーバーなどのアプリケーションをこのゾーンに配置します。 インターネットゾーン: このゾーンは管理しませんが、ビジネスパートナーやSaaSプロバイダなどが管理するアプリケーションに接続するときは、このゾーンと連携します。 図 1:様々なネットワークゾーン 従来の環境では、ファイアウォールのルールを定義することによってゾーン間のトラフィックの流れを制御しています。AWSでは、サブネットレベルのステートレスなファイアウォールであるネットワークアクセスコントロールリスト(ネットワークACL)、インスタンスまたはElastic Network Interfaceレベルのステートフルなファイアウォールであるセキュリティグループ、そしてトラフィックがどこに向けられるかを決定する一連のルールとなるルートテーブルを使用してトラフィックの流れを制御します。 では、これらのゾーンをどのようにAWSに合わせて展開するのでしょうか? 前回の記事で紹介したアーキテクチャでは、私たちは暗黙的にゾーンを定義し、サブネットレベルでアプリケーションを分離しています。エクストラネットゾーンを除くすべてのゾーンについて説明しました。 図 2:サブネットレベルの分離によるネットワークゾーンの配置 もちろん、サブネットはAWS上のアプリケーションを分離する唯一の方法ではありません。ゾーンごとに異なるVPCを使用してアプリケーションを限定することもできます。例えば、管理ゾーンに専用のVPCを作成し、VPCピア接続を使用して、(他のVPC内にある)他のゾーンと接続することができます。ただし、SAPアプリケーションサーバーやデータベースなど、密接に関連するコンポーネントを別々のVPCに分けることはお勧めしません。 […]

Read More

AWS上へのSAP移行 FAST with the SAP Rapid Migration Test Program

Somckit Khemmanivanhは、Amazon Web Services(AWS)のSAPソリューションアーキテクトです。 お客様がオンプレミス環境でSAP HANA以外のデータベース(AnyDB)で稼働するSAPアプリケーションを利用されている場合、AWSが提供するSAP Rapid Migration Test Programにより、今すぐAWS上のSAP HANA(あるいはSAP ASE)ベースのアプリケーションに移行していただけます。SAP Rapid Migration Test Program(Fast AWS and SAP Transformationを略したFASTとも呼んでいます)では、SAPアプリケーション(SAP ECCやSAP Buisness Warehouse)をAnyDBで稼働中のお客様のSAP HANA on AWS移行、またはSAP ASE on AWS移行を支援するため、SAPとAWSが協力して開発した一連のプロセス、手順、ツールを提供します。 お客様自身の社内リソース、リモートコンサルティング、またはコンサルティングパートナーを活用し、FASTを適用することで、SAPシステムをAWS上に移行し、同時にSAP HANAにアップグレードすることができます。AWSは、AWSプラットフォームの柔軟性とスケールが評価され、このイニシアチブの開発およびローンチパートナーとしてSAP社に選ばれました。SAPとAWSはプログラムのパイロット段階から連携し、わずか48時間で、またインフラストラクチャコストはわずか1,000ドルで移行が完了できることを確認しています。 FASTの一環として、SAPアプリケーションの移行テストを加速させるために、SAP社はSoftware Update Manager(SUM)のDatabase Migration Option(DMO)を機能拡張しています(SAP Note 2377305を参照、SAPノートの閲覧にはログイン認証が必要です)。このSUM 1.0 SP 20の機能拡張は、DMO with System Moveと呼ばれ、特別なエクスポートおよびインポートプロセスにより、オンプレミス環境からAWS上に直接移行することができるようになっています。AWS Quick Start for SAP HANAでAWS上にSAP HANAインスタンスを迅速に展開し、SAPアプリケーションを素早く構築することができます。さらに、SAPフラットファイルをAWS上に転送するときに、Amazon S3、Amazon EFS (AWS Direct Connect経由)、AWS […]

Read More

EC2インメモリ処理のアップデート: 4TBから16TBのメモリ搭載インスタンスと34TBのSAP HANAスケールアウト

毎月数回、シアトルのエグゼクティブブリーフィングセンターでお客様と話をします。私たちのイノベーションのプロセスを説明し、各AWS製品のロードマップがお客様の要望とフィードバックによってどのように決められているかやりとりします。 その良い例が、SAP社のビジネスソリューションのポートフォリオにとってAWSを魅力的な場所にするための私たちの取り組みです。長年にわたり、お客様はAWS上で大規模なSAPアプリケーションを本番環境で稼働しており、このワークロードに対応するように設計されたEC2インスタンスを提供することに努めてきました。SAPシステムは間違いなくミッションクリティカルであり、SAP社はいくつかのEC2インスタンスのタイプとサイズで彼らの製品を利用できるよう認定しています。私たちは、AWSをSAP製品にとって堅牢で信頼できる基盤にし、認定を取得するために、SAP社と密に連携しています。 ここで、この分野での最も重要なお知らせを簡単にまとめておきます: 2012年6月 – AWS上で利用可能なSAP認定ソリューションの範囲を拡大しました 2012年10月 – AWS上でSAP HANAインメモリデータベースを本番稼働できるようになりました 2014年3月 – 最大244GBのメモリを搭載したcr1.8xlargeインスタンスでSAP HANAが本番稼働し、テスト用途のクラスタはさらに大きく作成できるようになりました 2014年6月 – r3.8xlargeインスタンスのSAP認定と合わせて、SAP HANA導入ガイドとAWS CloudFormationテンプレートを公開しました 2015年10月 – SAP HANA、Microsoft SQL Server、Apache SparkやPrestoを実行するために設計された2TBメモリを搭載したx1.32xlargeインスタンスを発表しました 2016年8月 – X1インスタンスのクラスタを使用して、最大7ノードつまり14TBメモリの本番稼働SAP HANAクラスタを作成することができるようになりました 2016年10月 – 1TBメモリを搭載したx1.16xlargeインスタンスを発表しました 2017年1月 – r4.16xlargeインスタンスでSAP HANA認定を取得しました 現在、幅広い業界のお客様がSAPアプリケーションをAWS上で本番稼働させています(SAPとAmazon Web Servicesのページには、多くのお客様成功例が掲載されています)。 私の同僚のBas Kamphuisが最近、SAPとクラウドによるデジタルジャーニーのナビゲートという記事を書きました(閲覧には登録が必要)。彼は、デジタルトランスフォーメーションにおけるSAPの役割について説明し、それをサポートするクラウドインフラストラクチャの主要な特性を検証しながら、他のホスティングオプションと比較してクラウドのほうが多くの利点を提供していると指摘しています。彼がこの記事でこれらの利点をどのように紹介しているかは以下のとおりです: SAPアプリケーションの本稼働環境としてAWSがより良い場所になるよう、引き続き取り組んでいます。私たちが取り組んでいることのいくつかを以下に示します: より大きなSAP HANAクラスタ – スケールアウトのSAP HANAクラスタを最大17ノード(34TBメモリ)まで構成できるようになりました 4TBのインスタンス – 今度、4TBメモリ搭載のx1e.32xlargeインスタンスを提供します 8から16TBのインスタンス – 16TBまでのメモリを搭載したインスタンスを計画しています 詳細をみてみましょう! より大きなSAP HANAクラスタ SAP社と連携し、x1.32xlargeインスタンスを使用した最大17ノード(34TBメモリ)のスケールアウトクラスタでSAP認定を取得したことをお知らせします。これは、現在のクラウドプロバイダから提供される最大のスケールアウト構成であり、AWS上で非常に大きなSAPワークロードを展開することができます(詳細は、SAP HANA認定ハードウェアディレクトリのx1.32xlargeインスタンスを参照してください)。スケールアウトクラスタの構築および展開方法については、SAP HANA on AWSクイックスタートを参照してください。 メモリ重視のX1ファミリの拡張 お客様のご要望に対応し、確実な成長経路を提供するために、このインスタンスファミリおよび他のインスタンスファミリに引き続き投資します。 今年後半には、複数のAWSリージョンで、オンデマンドとリザーブドインスタンス両方の形式のx1e.32xlargeインスタンスを利用できるようにする予定です。このインスタンスは、(x1.32xlargeの2倍の)4TBのDDR4メモリ、128個のvCPU(4つの2.3 GHz […]

Read More

SAP on AWSクラウド設計入門

Rahul Kabraは、Amazon Web Services(AWS)のパートナー ソリューション アーキテクトです。 SAPワークロードをAWS上に移行することを真剣に検討し始めると、AWS上のSAPアーキテクチャはどのようにすべきか、オンプレミスやプライベートクラウドで稼働する場合とどこが違うのか、ビジネスにどういった利点があるのか、おそらく気になってくるでしょう。この入門用のブログでは、これらのトピックの多くに触れ、AWS上へのSAPワークロードの移行および運用に向けた準備を整えるための重要な情報をお伝えします。 AWSがもたらす俊敏性と拡張性をSAPワークロードで実際に活用するために、AWS上のSAPランドスケープの設計では、考え方を少し変える必要があります。また、SAPアーキテクチャが様々なAWSサービスをどのように活用し、これまでに比べて可用性が高く、セキュリティが強化された環境が提供されているかを理解することも重要です。SAP on AWSの概要を理解するために、様々なアーキテクチャのコンポーネントを探ってみましょう。 SAP関連の主要なAWSサービス 以下が、SAPワークロードの展開を始めるために知っておいたほうがよい主要サービスの一部です: Amazon VPC – Amazon Virtual Private Cloud(Amazon VPC)は、AWSクラウドの論理的に隔離された区画を提供し、すべてのAWSリソースを展開します。このサービスは、関連して許可されたネットワークトラフィックだけがVPCに出入りできるよう制御する仮想ネットワーキングの機能とセキュリティを提供します。SAPのためのVPC設計およびアーキテクチャパターンの詳細については、以前投稿したブログ「SAP on AWSにおけるVPCサブネットのゾーニングパターン」を参照してください。 Amazon EC2 – Amazon Elastic Compute Cloud(Amazon EC2)は、SAPアプリケーションサーバーとデータベースをインストールできる仮想ホストを提供します。AWSは、小規模で多目的のインスタンスからSAP HANAのようなインメモリーワークロードを実行できる大容量メモリーのインスタンスまで、SAPワークロードを実行するために認定された複数のインスタンスファミリーを提供しています。 Amazon EBS – Amazon Elastic Block Store(Amazon EBS)は、AWSが提供するブロックベースのストレージサービスであり、SAPアプリケーションおよびデータベースに関連するデータ、ログファイルおよびバックアップボリュームを格納するために使用します。AWSでは複数のEBSボリュームタイプを用意しており、SAPアプリケーションのSAPS、IOPS、スループット要件に合わせて活用することができます。 Amazon EFS – Amazon Elastic File System(Amazon EFS)は、多数のEC2インスタンスから接続できる共有ファイルシステムを提供します。このファイルストレージは、/usr/sap/transや/sapmnt/<SID>などの共有ファイルをマウントする必要があるSAPスケールアウト構成で特に役立ちます。 Amazon S3 – Amazon Simple Storage Service(Amazon S3)は、スケーラブルで耐久性の高いオブジェクトベースのストレージサービスで、SAPアプリケーションのバックアップとスナップショットの保存に使用できます。 […]

Read More

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はこの記事の内容や正確さについての責任は負いません。 […]

Read More

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 […]

Read More

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データベースにオンラインかつ直接移行します。 図1: SAP HANA DMOのプロセス 移行先がAWS上のSAP HANAシステムである場合、この直接の移行プロセスを容易にするためにネットワーク接続を確立する必要があります。加えて、標準的なDMOのプロセスにおいて、SAP Note 2277055 – Database Migration Option (DMO) of SUM 1.0 […]

Read More

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 […]

Read More