Category: SAP*


AWSインスタンスの新しいSAP認定とベンチマーク結果の世界記録

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

SAP on AWSにおけるVPCサブネットのゾーニングパターン 第3回:内部および外部接続

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

VPCサブネットのゾーニングパターンに関するシリーズ記事の第1回目では、SAPアプリケーションへのいくつかの接続方法を紹介し、内部専用接続のためのAmazon Virtual Private Cloud(Amazon VPC) サブネットのゾーニングパターンについて詳細を説明しました。第2回目では、従来のアプリケーションにおけるネットワークのゾーニングをAWS上でどのように実装できるか説明しました。このシリーズの最後の記事として、内部接続と外部接続の両方を必要とするSAPアプリケーションの接続パターンを説明します。外部ソースからの接続は管理されていてもよく(つまり、既知の外部の関係者を含む)、管理されていない(つまり、公開されていてもよい)場合もあります。両方のシナリオについて説明します。

内部および管理された外部接続

外部向けインターフェースに対する信頼された外部の関係者からの接続と、内部向けインターフェースに対するSAPと非SAPシステム間またはどちらかの間の接続が必要となる、SAP Process Orchestration(PO)とSAP Process Integration(PI)がこのシナリオの典型的な例です。内部向けインターフェースは簡単に管理できます。基本的には、ルートテーブル、ネットワークアクセスコントロールリスト(ACL)、およびセキュリティグループに適切なトラフィックを定義します。しかしながら、外部接続を安全に提供することには課題があります。そこで、信頼できる外部の関係者からのトラフィックの入口と出口に着目しましょう。典型的な選択肢が4つあります。

  • 入口と出口の両方のための仮想プライベートネットワーク(VPN)接続
  • 入口用のElastic Load Balancing、および出口用のネットワークアドレス変換(NAT)ゲートウェイ
  • NATデバイス(NATインスタンスまたはNATゲートウェイ)
  • リバースプロキシ

VPN接続 (入口と出口)

信頼できる外部の関係者と専用の仮想接続を作成する場合は、VPCでVirtual Private Gateway(VGW)を使用するか、パブリックサブネット内にAWS Marketplaceで公開されているような独自のソフトウェアVPNサーバを使用することで、サイト間IPsec VPN接続を確立できます。

注釈   この記事のアーキテクチャ図では、簡単にするために単一のアベイラビリティゾーンで示しています。実際には、高可用性を実現するために、少なくとも2つのアベイラビリティゾーンにわたってソリューションを構成することをお勧めします。

図 1: 管理された外部接続のためのVPNコネクション

Elastic Load Balancing (入口) / NATゲートウェイ (出口)

Elastic Load Balancingには、次の3つのタイプがあります。

  • Classic Load Balancer
  • Network Load Balancer
  • Application Load Balancer

Classic Load Balancerは、 EC2-Classicプラットフォーム上で構築されたアプリケーションに向いています。VPCをお使いであれば、Network Load BalancerあるいはApplication Load Balancerをお勧めします。Network Load Balancerは、Open Systems Interconnection(OSI)モデルの接続レベル(レイヤー4)で動作し、TCPトラフィックの負荷分散に最適です。Application Load Balancerは、接続レベル(レイヤー7)で動作し、HTTPまたはHTTPSの負荷分散に最適です。

Secure File Transfer Protocol(SFTP)とHTTPSの2つの例を考えてみましょう。

  • SFTP: プライベートサブネットにSFTPサーバがあり、信頼できる外部の関係者から接続できる必要があるとします。このシナリオでは、パブリックサブネット内にインターネットに面するNetwork Load Balancerを配置し、プライベートサブネット内のSFTPサーバに関連付けられているセキュリティグループによって、信頼できる外部の関係者からの接続を管理できます(Network Load Balancerに関連付けられたセキュリティグループはありません)。SAP PI / POから信頼できる外部の関係者が持つSFTPサーバへのアウトバウンド(出口)トラフィックの場合には、NATゲートウェイが必要です。Amazon Route 53を使用して、組織の外部ドメイン名を登録し、ロードバランサーを完全修飾ドメイン名(FQDN)で名前解決できます。

    図 2: 外部接続のためのNetwork Load Balancer

  • HTTPS: この2つ目の例では、外部から利用可能なSAP PI / POへのWebサービスベースのインターフェイスがあるとします。このシナリオでは、接続はSSL(HTTPS)に基づいて行われるため、Application Load Balancerが入口トラフィックに最適です。既知のIPからの接続は、ロードバランサーに関連付けられたセキュリティグループによって管理されます。一方、SAP PI / POが信頼できる外部の関係者によって公開されたWebサービスを利用する必要がある場合は、NATゲートウェイが必要です。Amazon Route 53は、ドメイン名の登録とFQDN解決にも使用できます。

    図 3: 外部接続のためのApplication Load Balancer

その他の選択肢

Elastic Load Balancingを使用する代わりに、NATインスタンスとリバースプロキシを使用できます。ただし、NATインスタンスとリバースプロキシを管理する負担を取り除くため、インターネットに面する構成ではNetwork Load BalancerあるいはApplication Load Balancerを使用することをお勧めします。

  • NATデバイス: AWSでは、2種類のNATデバイス、つまりNATゲートウェイとNATインスタンスを提供しています。NATインスタンスはAmazon Machine Image(AMI)に基づいていますが、NATゲートウェイはAWSサービスとして管理されています。これらのデバイスはいずれも、プライベートサブネット内のEC2インスタンスにインターネット接続を提供します。ポート転送のNATインスタンスを有効にすることで、外部の関係者がプライベートサブネット内のEC2インスタンス上で実行されているアプリケーションに接続することもできます。前述のSFTPの例をもう一度見てみましょう。プライベートサブネット内のSFTPサーバには、既知の外部の関係者からはSAP PI / POの持つファイルベースのインターフェイスを経由して接続される必要があります。NATインスタンス(ポート転送を有効にした後)は、SFTPサーバ(プライベートサブネット内に存在)を外部からの直接接続から保護しながら、外部の関係者が接続できるようにします。NATインスタンスに関連付けられたセキュリティグループを設定すると、管理された接続として既知の外部IPからのトラフィックだけを許可できます。すべてのインターフェイスがSAP PI / POからのアウトバウンド接続に基づいている場合、NATゲートウェイが最適です。

    図 4: ポート転送のためのNATインスタンス

  • リバースプロキシ (入口) / NATゲートウェイ (出口): HTTP / HTTPSトラフィックの入口にはリバースプロキシが使用されます。パブリックサブネットのリバースプロキシは、外部の関係者からプライベートサブネット内のSAP PO / PIサーバにHTTP / HTTPS接続を確立できるようにします。入口トラフィックのリバースプロキシとしてSAP Web Dispatcherを使用することも、F5 BIG-IPのようなサードパーティ製品を使用することもできます。SAP Web Dispatcherを使用している場合は、Reverse invokeによる接続を構成することをお奨めします。前述のシナリオのように、出口トラフィックに対してはNATゲートウェイを使用できます。

    図 5: 外部接続のためのリバースプロキシ

これらの両方のシナリオ(NATおよびリバースプロキシ)では、静的パブリックIPアドレスを保持するために、Elastic IPアドレスを使用する必要があります。さらに、Amazon Route 53を使用して、ドメイン名の登録とFQDN解決を行います。

SAP Cloud Connectorなど、他のアプリケーション固有の選択肢も利用することができます。クラウドコネクタは、HTTPS経由でSAP Cloud Platformとの接続を確立します。接続は常にクラウドコネクタによって呼び出されますが、セッションが確立された後、データは双方向に(逆引き接続を介して)送信されます。クラウドコネクタはエクストラネットゾーンに配置し、NATゲートウェイ経由でインターネットに接続することをお勧めします。

図 6: SAP Cloud Platformとの連携

内部および管理されていない外部接続

この領域のアプリケーションへの内部接続は、前述のシナリオ(内部および管理された外部接続)と同様の方法で、つまり適切なルートテーブル、ネットワークACL、およびセキュリティグループを定義することによって管理する必要があります。したがって、このセクションでは、管理されていない外部接続に焦点を当てます。

SAP Fioriは、VPN接続および内部接続なしで外部接続が必要なSAPアプリケーションの一般的な例です。その他の例としては、SAP Hybrisプラットフォーム、外部から接続可能なSAP Enterprise Portal(EP)、あるいはSAP Supplier Relationship Management(SRM)などがあります。ただし、ほとんどの場合、SAPシステムへの管理されていない外部接続はHTTP / HTTPSに制限されています。SAP NetWeaver Gateway上で実行されるセントラルハブ構成のSAP Fioriフロントエンドサーバの例を考えてみましょう。

図 7: 外部接続のためのApplication Load Balancer

外部ゾーンのApplication Load Balancerは、HTTP / HTTPS要求のエントリーポイントとして機能します。ロードバランサーはSAP Web Dispatcherに要求を送信します。AWS Shieldは、特にロードバランサーとAWS WAFを組み合わせて使用​​する場合、一般的なWebエクスプロイトからSAP NetWeaver Gatewayを保護します。AWS Shieldは、AWS上で動作するWebアプリケーションを保護する、マネージド型の分散サービス妨害(DDoS)の保護サービスです。AWS Shieldには、StandardとAdvancedの2つの階層があります。AWS Shield Standardには追加料金はかかりません。

今後について
この記事では、SAPアプリケーションに内部および外部から接続するためのシナリオについて説明しました。特定のシナリオについて議論したい場合、またはこのブログの内容についてご質問やご提案がありましたら、お気軽にお問い合わせください。

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

オンプレミスの利用者がAmazon Route 53経由でSUSE HAEで保護されたSAP HANAインスタンスに接続する方法

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

このブログ記事では、AWSクラウド上のSUSE Linux Enterprise High Availability Extension(SLES HAE)によって保護されているSAP HANAデータベースに、オンプレミスの利用者が接続できるようになる、Amazon Route 53エージェントについて説明します。このエージェントは、Amazon Route 53を介して利用者を振り分ける機能を提供します。

このエージェントを利用するには、SAP Note 2309342 – SUSE Linux Enterprise High Availability Extension on AWS for SAP HANAに記載されているような、オーバーレイIPアドレスエージェントを使用して実装された高可用性フェイルオーバー用のSLES HAEの設定が必要です。(SAPノートを参照するにはSAP Support Portalの認証情報が必要です)

Route 53エージェントは、SAP HANAデータベースを保護するクラスタリソース管理フレームワークであるPacemakerを含むSLES HAEの機能を拡張します。このエージェントとオーバーレイIPアドレスエージェントを組み合せた利用方法は、SAPセントラルインスタンス(CI)を含む、AWSクラウド上のSLESでサポートされるすべての構成のSLES HAEに対して適用できます。

Route 53エージェントは、現時点では未サポートのオープンソースツールとして利用可能となっており、ソースコードはこのブログ記事の中で公開します。現在、AWSとSUSEが協力し、サポート済みツールとして本家リポジトリから利用できるように調整しています。お客様のAWSアカウントでSAP HANAを構築した後、このエージェントをインストールできます。

Route 53エージェントの仕組み

現在のオーバーレイIPアドレスエージェントでは、仮想プライベートクラウド(VPC)内のアプリケーションサーバーは、そのVPC内の保護されたSAP HANAサーバーに接続できますが、オンプレミスのアプリケーションからの接続はできません。

そのため、RDPや踏み台サーバーを経由したVPC内で管理されたSAP HANA Studioなどのアプリケーションが必要となり、オンプレミスの利用者にはいくつかの不便が生じます。Route 53エージェントは、名前ベースのアプローチを使用してオンプレミスの利用者がVPCに接続できるようにすることで、この制限を回避します。2つのエージェントは並行して動作します。オーバーレイIPエージェントは、オーバーレイIPアドレスからアクティブなノードにトラフィックをルーティングします。Route 53エージェントは、SAP HANAサーバーの名前と紐づく現在のIPアドレスを更新します。

私は、ウェブサイトScaling Bitsに、DNS Name Failover for Highly Available AWS Servicesという記事で、このエージェントの内部動作を掲載しました。この記事では、Route 53のホストゾーンの更新方法について説明しています。

Route 53エージェントは、SAPから独立しています。また、SLES HAEのSAP NetWeaverセントラルインスタンス(CI)コンポーネントとも連動します。

前提条件

この記事では、SLES Pacemaker クラスタを含む、オーバーレイIPアドレスエージェントを既にインストールしていることを前提としています。さらに、Route 53エージェントには以下が必要です。

  • SLES HAE クラスタインスタンスがRoute 53レコードを更新するためのポリシー
  • rootユーザー用のAWSプロファイル
  • Route 53のプライベートホストゾーン

ポリシーの追加

以下のポリシーをSLES HAE クラスタインスタンスに追加して、Route 53のAレコードを更新できるようにします。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt1471878724000",
            "Effect": "Allow",
            "Action": [
                "route53:ChangeResourceRecordSets",
                "route53:GetChange",
                "route53:ListResourceRecordSets",
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

rootユーザ用のAWSプロファイルの作成

エージェントは、AWSプロファイルを使用してAWS CLIコマンドを呼び出し、そしてオーバーレイIPエージェントでも同じプロファイルを使用します。ウェブサイトScaling Bitsで説明しているように、プロキシ設定が必要な場合もあります。

任意のプロファイル名を選択できます。エージェントはデフォルトの名前としてclusterを使用するため、必要に応じてリファレンスを修正する必要があります。

Route 53のプライベートホストゾーンの作成

エージェントは、Route 53 ホストゾーンのAレコードを更新します。つまり、お客様のAWSアカウント内に要求されるインフラストラクチャが必要です。プライベートホストゾーンの作成方法については、AWSドキュメントを参照してください。

以下の値が必要です。(ここでは値の例を示しています)

  • hostedzoneidZ22XDORCGO4P3T
  • fullnamesuse-service.awslab.cloud.mylab.corp. (最後のドットは重要です!)

エージェントのインストール

このブログ記事の最後に掲載しているソースコードをテキストファイルにコピーし、ディレクトリ/usr/lib/ocf/resource.d/aws 配下に置きます。このソースコードは、MITライセンスのもとで利用できます。

クラスタの設定

Pacemakerで、以下のようにクラスタの構成を編集(crm configure editコマンド)します。

primitive res_AWS_ROUTE53 ocf:aws:aws-vpc-route53 \
   params hostedzoneid=Z22XDORCGO4P3T ttl=10 fullname=suse-service5.awslab.cloud.mylab.corp. profile=cluster \
   op start interval=0 timeout=180 \
   op stop interval=0 timeout=180 \
   op monitor interval=300 timeout=180 \
   meta target-role=Started

以下の必須パラメータを適切な値に置き換えてください。

  • hostedzoneid: Route 53のホストゾーンID。これは、Route 53のレコードセットです
  • ttl: Route 53のAレコードの秒単位の有効期限(TTL)。(合理的なデフォルト値は10です)
  • fullname: IPアドレスをホストするサービスのフルネーム。例えば、suse-service.awslab.cloud.mylab.corp.(最後のドットは重要です!)
  • profile: rootアカウントのAWS CLIプロファイルの名前。/root/.aws/configファイルには、以下のようなエントリが必要です
    • [profile cluster] – clusterの場所にお客様のプロファイル名
    • region = us-east-1 (お客様が利用するAWSリージョン)
    • output = text (この設定も必要)

AWS固有の制約に関する設定

Route 53エージェントは、SAP HANAデータベースと同じノードで動作する必要があります。この制約により、必然的に同じノードに置かなければなりません。

以下の内容のaws-route53-constraint.txtというファイルを作成します。前述と同じリソース識別子を使用していることを確認してください。

colocation col_Route53 2000: res_AWS_ROUTE53:Started msl_SAPHana_SID_HDB00:Master
order ord_SAPHana 2000: cln_SAPHanaTopology_SID_HDB00 msl_SAPHana_SID_HDB00

この例では、SAP SIDがリソース名の一部としてコード化されています。この値は構成によって異なります。

このファイルを設定に追加するために、スーパーユーザーとして次のコマンドを実行します。ファイル名はaws-route53-constraint.txtです。

crm configure load update aws-route53-constraint.txt

まとめ

Route 53エージェントは、クラスタリソース管理フレームワークであるPacemakerとともに使用され、SAP HANAデータベースを保護するSLES HAEの機能を拡張します。また、アクティブなABAP SAPセントラルサービス(ASCS)サーバーを検出し、Route 53を介して利用者を振り分けることで、SAPセントラルインスタンスを保護することもできます。

エージェントは、SLES HAE SAPエージェントの依存エージェントとして実行されます。つまり、個々の管理を必要とはしません。

SLES HAEシステムにオンプレミスからの接続が必要な場合は、このエージェントをインストールすることをお勧めします。また、ご質問やご意見がある場合はお気軽にお問合せください。

Route 53エージェントのソースコード

#!/bin/bash
#
#   Copyright 2017 Amazon.com, Inc. and its affiliates. All Rights Reserved.
#   Licensed under the MIT License.
#
#  Copyright 2017 Amazon.com, Inc. and its affiliates

# Permission is hereby granted, free of charge, to any person obtaining a copy of
# this software and associated documentation files (the "Software"), to deal in
# the Software without restriction, including without limitation the rights to
# use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
# of the Software, and to permit persons to whom the Software is furnished to do
# so, subject to the following conditions:

# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.

# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
# OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
# ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
# OTHER DEALINGS IN THE SOFTWARE.

#
#
#
# OCF resource agent to move an IP address within a VPC in the AWS
# Written by Stefan Schneider , Martin Tegmeier (AWS)
# Based on code of Markus Guertler#
#
#
# OCF resource agent to move an IP address within a VPC in the AWS
# Written by Stefan Schneider (AWS) , Martin Tegmeier (AWS)
# Based on code of Markus Guertler (SUSE)
#
# Mar. 15, 2017, vers 1.0.2

#######################################################################
# Initialization:

: ${OCF_FUNCTIONS_DIR=${OCF_ROOT}/lib/heartbeat}
. ${OCF_FUNCTIONS_DIR}/ocf-shellfuncs

OCF_RESKEY_ttl_default=10

: ${OCF_RESKEY_ttl:=${OCF_RESKEY_ttl_default}}

#######################################################################

usage() {
	cat <<-EOT
	usage: $0 {start|stop|status|monitor|validate-all|meta-data}
	EOT
}

metadata() {
cat <<END
<?xml version="1.0"?>
<!DOCTYPE resource-agent SYSTEM "ra-api-1.dtd">
<resource-agent name="aws-vpc-route53">
<version>1.0</version>
<longdesc lang="en">
Update Route53 record of Amazon Webservices EC2 by updating an entry in a
hosted zone ID table.

AWS instances will require policies which allow them to update Route53 ARecords:
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt1471878724000",
            "Effect": "Allow",
            "Action": [
                "route53:ChangeResourceRecordSets",
                "route53:GetChange",
                "route53:ListResourceRecordSets",
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

Example Cluster Configuration:

Use a configuration in "crm configure edit" which looks as follows. Replace
hostedzoneid, fullname and profile with the appropriate values:

primitive res_route53 ocf:heartbeat:aws-vpc-route53 \
        params hostedzoneid=Z22XDORCGO4P3T fullname=suse-service5.awslab.cloud.sap.corp. profile=cluster \
        op start interval=0 timeout=180 \
        op stop interval=0 timeout=180 \
        op monitor interval=300 timeout=180 \
        meta target-role=Started
</longdesc>
<shortdesc lang="en">Update Route53 VPC record for AWS EC2</shortdesc>
<parameters>
<parameter name="hostedzoneid" required="1">
<longdesc lang="en">
Hosted zone ID of Route 53. This is the table of
the Route 53 record.
</longdesc>
<shortdesc lang="en">AWS hosted zone ID</shortdesc>
<content type="string" default="" />
</parameter>
<parameter name="fullname" required="1">
<longdesc lang="en">
The full name of the service which will host the IP address.
Example: suse-service5.awslab.cloud.sap.corp.
Note: The trailing dot is important to Route53!
</longdesc>
<shortdesc lang="en">Full service name</shortdesc>
<content type="string" default="" />
</parameter>
<parameter name="ttl" required="0">
<longdesc lang="en">
Time to live for Route53 ARECORD
</longdesc>
<shortdesc lang="en">ARECORD TTL</shortdesc>
<content type="string" default="${OCF_RESKEY_ttl_default}" />
</parameter>
<parameter name="profile" required="1">
<longdesc lang="en">
The name of the AWS CLI profile of the root account. This
profile will have to use the "text" format for CLI output.
The file /root/.aws/config should have an entry which looks
like:

  [profile cluster]
	region = us-east-1
	output = text

"cluster" is the name which has to be used in the cluster
configuration. The region has to be the current one. The
output has to be "text".
</longdesc>
<shortdesc lang="en">AWS Profile Name</shortdesc>
<content type="string" default="" />
</parameter>
</parameters>
<actions>
<action name="start" timeout="180" />
<action name="stop" timeout="180" />
<action name="monitor" depth="0" timeout="180" interval="300" />
<action name="validate-all" timeout="5" />
<action name="meta-data" timeout="5" />
</actions>
</resource-agent>
END
}

debugger() {
	ocf_log debug "DEBUG: $1"
}

ec2ip_validate() {
	debugger "function: validate"

	# Full name
	[[ -z "$OCF_RESKEY_fullname" ]] && ocf_log error "Full name parameter not set $OCF_RESKEY_fullname!" && exit $OCF_ERR_CONFIGURED

	# Hosted Zone ID
	[[ -z "$OCF_RESKEY_hostedzoneid" ]] && ocf_log error "Hosted Zone ID parameter not set $OCF_RESKEY_hostedzoneid!" && exit $OCF_ERR_CONFIGURED

	# profile
	[[ -z "$OCF_RESKEY_profile" ]] && ocf_log error "AWS CLI profile not set $OCF_RESKEY_profile!" && exit $OCF_ERR_CONFIGURED

	# TTL
	[[ -z "$OCF_RESKEY_ttl" ]] && ocf_log error "TTL not set $OCF_RESKEY_ttl!" && exit $OCF_ERR_CONFIGURED

	debugger "Testing aws command"
	aws --version 2>&1
	if [ "$?" -gt 0 ]; then
		error "Error while executing aws command as user root! Please check if AWS CLI tools (Python flavor) are properly installed and configured." && exit $OCF_ERR_INSTALLED
	fi
	debugger "ok"

	if [ -n "$OCF_RESKEY_profile" ]; then
		AWS_PROFILE_OPT="--profile $OCF_RESKEY_profile"
	else
		AWS_PROFILE_OPT="--profile default"
	fi

	return $OCF_SUCCESS
}

ec2ip_monitor() {
	ec2ip_validate
	debugger "function: ec2ip_monitor: check Route53 record "
	IPADDRESS="$(ec2metadata aws ip | grep local-ipv4 | /usr/bin/awk '{ print $2 }')"
	ARECORD="$(aws $AWS_PROFILE_OPT route53 list-resource-record-sets --hosted-zone-id $OCF_RESKEY_hostedzoneid --query "ResourceRecordSets[?Name=='$OCF_RESKEY_fullname']" | grep RESOURCERECORDS | /usr/bin/awk '{ print $2 }' )"
	debugger "function: ec2ip_monitor: found IP address: $ARECORD ."
	if [ "${ARECORD}" == "${IPADDRESS}" ]; then
		debugger "function: ec2ip_monitor:  ARECORD $ARECORD found"
		return $OCF_SUCCESS
	else
		debugger "function: ec2ip_monitor: no ARECORD found"
		return $OCF_NOT_RUNNING
	fi

	return $OCF_SUCCESS
}

ec2ip_stop() {
	ocf_log info "EC2: Bringing down Route53 agent. (Will remove ARECORD)"
	IPADDRESS="$(ec2metadata aws ip | grep local-ipv4 | /usr/bin/awk '{ print $2 }')"
	ARECORD="$(aws $AWS_PROFILE_OPT route53 list-resource-record-sets --hosted-zone-id $OCF_RESKEY_hostedzoneid --query "ResourceRecordSets[?Name=='$OCF_RESKEY_fullname']" | grep RESOURCERECORDS | /usr/bin/awk '{ print $2 }' )"
	debugger "function: ec2ip_monitor: found IP address: $ARECORD ."
	if [ ${ARECORD} != ${IPADDRESS} ]; then
		debugger "function: ec2ip_monitor: no ARECORD found"
		return $OCF_SUCCESS
	else
		debugger "function: ec2ip_monitor:	ARECORD $ARECORD found"
		# determine IP address
		IPADDRESS="$(ec2metadata aws ip | grep local-ipv4 | /usr/bin/awk '{ print $2 }')"
		# Patch file
		debugger "function ec2ip_stop: will delete IP address to ${IPADDRESS}"
		ocf_log info "EC2: Updating Route53 $OCF_RESKEY_hostedzoneid with $IPADDRESS for $OCF_RESKEY_fullname"
		ROUTE53RECORD="/var/tmp/route53-${OCF_RESKEY_hostedzoneid}-${IPADDRESS}.json"
		echo "{ " > ${ROUTE53RECORD}
		echo "	  \"Comment\": \"Update record to reflect new IP address for a system \", " >>	${ROUTE53RECORD}
		echo "	  \"Changes\": [ " >>  ${ROUTE53RECORD}
		echo "		  { " >>  ${ROUTE53RECORD}
		echo "			  \"Action\": \"DELETE\", " >>	${ROUTE53RECORD}
		echo "			  \"ResourceRecordSet\": { " >>	 ${ROUTE53RECORD}
		echo "				  \"Name\": \"${OCF_RESKEY_fullname}\", " >>  ${ROUTE53RECORD}
		echo "				  \"Type\": \"A\", " >>	 ${ROUTE53RECORD}
		echo "				  \"TTL\": ${OCF_RESKEY_ttl}, " >>	${ROUTE53RECORD}
		echo "				  \"ResourceRecords\": [ " >>  ${ROUTE53RECORD}
		echo "					  { " >>  ${ROUTE53RECORD}
		echo "						  \"Value\": \"${IPADDRESS}\" " >>	${ROUTE53RECORD}
		echo "					  } " >>  ${ROUTE53RECORD}
		echo "				  ] " >>  ${ROUTE53RECORD}
		echo "			  } " >>  ${ROUTE53RECORD}
		echo "		  } " >>  ${ROUTE53RECORD}
		echo "	  ] " >>  ${ROUTE53RECORD}
		echo "}" >> ${ROUTE53RECORD}
		cmd="aws --profile ${OCF_RESKEY_profile} route53 change-resource-record-sets --hosted-zone-id ${OCF_RESKEY_hostedzoneid} \
		  --change-batch file://${ROUTE53RECORD} "
		debugger "function ec2ip_start: executing command: $cmd"
		CHANGEID=$($cmd | grep CHANGEINFO |	 /usr/bin/awk -F'\t' '{ print $3 }' )
		debugger "Change id: ${CHANGEID}"
		rm ${ROUTE53RECORD}
		CHANGEID=$(echo $CHANGEID |cut -d'/' -f 3 |cut -d'"' -f 1 )
		debugger "Change id: ${CHANGEID}"
		STATUS="PENDING"
		MYSECONDS=2
		while [ "$STATUS" = 'PENDING' ]; do
			sleep	${MYSECONDS}
			STATUS="$(aws --profile ${OCF_RESKEY_profile} route53 get-change --id $CHANGEID | grep CHANGEINFO |  /usr/bin/awk -F'\t' '{ print $4 }' |cut -d'"' -f 2 )"
			debugger "Waited for ${MYSECONDS} seconds and checked execution of Route 53 update status: ${STATUS} "
		done

		return $OCF_SUCCESS
	fi

	return $OCF_SUCCESS
}

ec2ip_start() {
	# determine IP address
	IPADDRESS="$(ec2metadata aws ip | grep local-ipv4 | /usr/bin/awk '{ print $2 }')"
	# Patch file
	debugger "function ec2ip_start: will update IP address to ${IPADDRESS}"
	ocf_log info "EC2: Updating Route53 $OCF_RESKEY_hostedzoneid with $IPADDRESS for $OCF_RESKEY_fullname"
	ROUTE53RECORD="/var/tmp/route53-${OCF_RESKEY_hostedzoneid}-${IPADDRESS}.json"
	echo "{ " > ${ROUTE53RECORD}
	echo "    \"Comment\": \"Update record to reflect new IP address for a system \", " >>  ${ROUTE53RECORD}
	echo "    \"Changes\": [ " >>  ${ROUTE53RECORD}
	echo "        { " >>  ${ROUTE53RECORD}
	echo "            \"Action\": \"UPSERT\", " >>  ${ROUTE53RECORD}
	echo "            \"ResourceRecordSet\": { " >>  ${ROUTE53RECORD}
	echo "                \"Name\": \"${OCF_RESKEY_fullname}\", " >>  ${ROUTE53RECORD}
	echo "                \"Type\": \"A\", " >>  ${ROUTE53RECORD}
	echo "                \"TTL\": ${OCF_RESKEY_ttl} , " >>  ${ROUTE53RECORD}
	echo "                \"ResourceRecords\": [ " >>  ${ROUTE53RECORD}
	echo "                    { " >>  ${ROUTE53RECORD}
	echo "                        \"Value\": \"${IPADDRESS}\" " >>  ${ROUTE53RECORD}
	echo "                    } " >>  ${ROUTE53RECORD}
	echo "                ] " >>  ${ROUTE53RECORD}
	echo "            } " >>  ${ROUTE53RECORD}
	echo "        } " >>  ${ROUTE53RECORD}
	echo "    ] " >>  ${ROUTE53RECORD}
	echo "}" >> ${ROUTE53RECORD}
	cmd="aws --profile ${OCF_RESKEY_profile} route53 change-resource-record-sets --hosted-zone-id ${OCF_RESKEY_hostedzoneid} \
	  --change-batch file://${ROUTE53RECORD} "
	debugger "function ec2ip_start: executing command: $cmd"
	CHANGEID=$($cmd | grep CHANGEINFO |  /usr/bin/awk -F'\t' '{ print $3 }' )
	debugger "Change id: ${CHANGEID}"
	rm ${ROUTE53RECORD}
	CHANGEID=$(echo $CHANGEID |cut -d'/' -f 3 |cut -d'"' -f 1 )
	debugger "Change id: ${CHANGEID}"
	STATUS="PENDING"
	MYSECONDS=2
	while [ "$STATUS" = 'PENDING' ]; do
		sleep  ${MYSECONDS}
		STATUS="$(aws --profile ${OCF_RESKEY_profile} route53 get-change --id $CHANGEID | grep CHANGEINFO |  /usr/bin/awk -F'\t' '{ print $4 }' |cut -d'"' -f 2 )"
		debugger "Waited for ${MYSECONDS} seconds and checked execution of Route 53 update status: ${STATUS} "
	done

	return $OCF_SUCCESS
}

###############################################################################

case $__OCF_ACTION in
	usage|help)
		usage
		exit $OCF_SUCCESS
		;;
	meta-data)
		metadata
		exit $OCF_SUCCESS
		;;
	monitor)
		ec2ip_monitor
		;;
	stop)
		ec2ip_stop
		;;
	validate-all)
		ec2ip_validate
		;;
	start)
		ec2ip_start
		;;
	*)
		usage
		exit $OCF_ERR_UNIMPLEMENTED
		;;
esac

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

アイテリジェンスとAWSが協力してSAP顧客に価値を提供

itelligence(アイテリジェンス)とAWS: AWSクラウドを介してグローバルにSAPの価値とソリューションを提供することに注力している新しいAmazon Partner Network(APN)メンバーをご紹介します。
この記事は、Amazon Web Services(AWS)でSAP担当ジェネラルマネージャーを務めるBas Kamphuisによるものです。

 

https://www.prnewswire.com/news-releases/itelligence-announces-collaboration-with-amazon-web-services-for-cloud-solutions-300540532.html

 

世界中のトランザクションの76%がSAPシステムと何らかの形でつながっており、SAP社は引き続きERP(Enterprise Resource Planning)市場の首位を占めています。SAP社の主力ソフトウェア製品であるSAP ECC(ERP Central Component)をお使いの数万のお客様の100%が、このリリースのメンテナンスが終了する2025年までには、どこかに移行することになっているでしょう。これは、SAP S/4HANAやSAP BW/4HANAのような、インメモリデータベースSAP HANAによって強化されたイノベーションを促すためです。この変化の誘発により、SAPをご利用中のお客様とパートナーエコシステム全体が、SAPランドスケープを戦略的に見て、どのようにSAP HANAでデジタル変革を実現できるのか明確にすることを迫られています。

世界で最も成功しているSAPグローバルパートナーの1社であるアイテリジェンスは、現在SAPをご利用中のお客様の多くが直面しているこの状況と複雑さを理解しています。大規模なグローバル組織にサービスを提供し、何十年にもわたってSAP環境を実装、維持してきました。アイテリジェンスとAWSのパートナーシップは、賞を受賞するほどのSAPの実装および運用における専門知識と組み合わせて、お客様がAWSクラウドの利点(伸縮性、弾力性、セキュリティ、グローバルスケールなど)を享受できるよう注力していきます。お客様は、既存のビジネスオペレーションのリスクや混乱を招くことなく、今すぐAWSとSAPが提供するイノベーションの恩恵を受けることができます。

私たちの継続した協調では、SAPのイノベーションの活用、選択肢の拡大、コストの削減、そして価値の創造に費やす時間の短縮など、お客様が求める敏捷性を実現するためにお役立ていただける、AWSで加速するアイテリジェンスのより多くのオファリングの提供を目指しています。

現在、お客様にご活用いただけること:

  • AWSにデータセンターを移設して、オンプレミスの設備投資を廃止
  • ツールとベストプラクティスを活用して数週間かかっていたSAPシステム移行を数日で実施
  • 複数地域にまたがるビジネス継続性と災害復旧のアーキテクチャを活用して、企業のセキュリティを強化し、弾力性を向上
  • SAP HANA認定パブリッククラウドの中で最大の品揃えを持つAWS上に本稼働環境を移行し、SAPランドスケープを統合

また、アイテリジェンスのマネージドサービスにAWSを組み込むことで、お客様のIT環境の複雑さを軽減することができます。私たちは連携して、お客様のSAP環境を積極的に自動化、監視および保守するために、人工知能、機械学習やビッグデータなどのAWSサービスを統合していく計画があります。

私たちはアイテリジェンスとの関係について非常に興奮しており、SAPをご利用中のお客様に引き続き最高のソリューションとオファリングを提供するための共同イノベーションを続けていきます。AWS組織全体を代表して、私たちはアイテリジェンスのチームのコミットメントとリーダーシップに感謝を述べたいと思います。Amazon Partner Networkへようこそ。

Bas

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

近日公開: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 blogを参照してください。

もし、SUSECONに参加されるなら、以下のSUSEとAWSのセッションも確認していただけると幸いです:

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

今すぐ利用可能 – 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 DirectorySAP HANA Sizing Guidelinesも関連しています。

リザーブドインスタンス – リザーブドインスタンスのリージョン単位の柔軟性は、x1とx1eには適用されません。

【今すぐ利用可能】
x1e.32xlargeインスタンスは、米国東部(バージニア北部)、米国西部(オレゴン)、欧州(アイルランド)、そしてアジアパシフィック(東京)リージョンで、AWS Management ConsoleAWS Command Line Interface(CLI)AWS SDKs、あるいはAWS Marketplaceを通じて、オンデマンドまたはリザーブドインスタンスとしてご利用いただけます。

また、X1インスタンスのいくつかのアップグレードについてもお伝えしたいと思います:

EBS – 本日のリリースで、現行のx1.32xlargeインスタンスにおいても、EBS専用の最大14Gbpsの帯域幅とインスタンスあたり80,000IOPSをサポートしています。

ネットワーク – 今週前半、現行のx1.32xlargeインスタンスがプレイスメントグループ内で最大25Gbpsのネットワーク帯域幅をサポートしたことを発表しています。

— Jeff;

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

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に分けることはお勧めしません。

1つのVPCで複数のサブネットにするか、複数のVPCを使用して分離するか、判断するために役立つ基準は何でしょうか?

経験則はなく、一般的に、管理のし易さと組織における職務の分離によって選択されます。例えば、組織内では、Microsoft Active Directory(SAPユーザーの管理とシングルサインオン用)、電子メール、マルウェア対策など、管理ゾーンのサービスとして使用するSAP以外のアプリケーションがあるとします。これらの共有サービスは、別々のチームによって管理される場合があり、そしてその影響範囲が大きく違うため、まったく異なる変更管理プロセスが必要になる場合があります。したがって、これらの共有サービス用に個別のVPCを作成することもできます。また、AWS Organizationsを使った複数のAWSアカウント戦略を取ることにより、この共有接続を管理することもできます。

異なるVPCに外部ゾーンと管理ゾーンを配置し、イントラネットゾーンと制限付きゾーンは1つのVPCにまとめたままにすると、前回の記事のアーキテクチャがどのように見えるかを確認してみましょう。

図 3:複数のVPCにまたがったネットワークゾーンの配置

この設計に合わせていくつかの設定を変更する必要があります:

  • VPCごとに別々のVPC CIDRを使用してください。例えば、VPC CIDRとしては10.0.0.0/16しかありませんでしたが、今では次のものが必要になります。
    • 10.0.0.0/16 – イントラネットゾーン(サブネット 10.0.1.0/24)と制限付きゾーン(サブネット 10.0.2.0/24)のための一つのVPC CIDR
    • 10.2.0.0/16 – 外部ゾーンのためのVPC CIDR(サブネット 10.2.1.0/24)
    • 10.3.0.0/16 – 管理ゾーンのためのVPC CIDR(サブネット 10.3.1.0/24)
  • VPCピア接続を使用して、それぞれのVPC間の接続を確立します。
  • 必要に応じて、あるVPCから別のVPCへのトラフィックをルーティングするために、ネットワークACL、ルートテーブル、およびセキュリティグループを調整します。

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

この記事では、従来のネットワークゾーンをAWSクラウドで同等の構造に置き換えました。次回の記事では、内部および管理された、または管理されていない外部接続を必要とするSAPアプリケーションのサブネットのゾーニングパターンについて紹介して、このシリーズを締める予定です。

私たちは、SAPアプリケーションにおけるVPC設定について皆様の経験をお聞きしたいと思っています。このシリーズ記事に関するご質問やご意見がございましたら、お気軽にお問い合わせください。

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

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 S3Amazon EFS (AWS Direct Connect経由)、AWS Storage GatewayのファイルインターフェースAWS SnowballといったAWSサービスもご利用いただけます。

SUM DMOツールは、AnyDBからSAP HANAへのデータ変換時に、OS更新、リリースアップグレード/エンハンスメントパッケージの適用およびユニコード変換まで同時に実行できます。実行記録はフラットファイルに書き込まれ、AWSプラットフォーム上で迅速に展開されたSAP HANA環境に転送されます。DMO with System Moveの次の段階で、フラットファイルがインポートされ、抽出されたデータ、コード、および設定を使用して移行先のSAPアプリケーションを構築します。関連する主要なステップの概念的な流れは次のとおりです。

ステップ1では、SUM DMOツールを使用して、SAPソースデータをフラットファイルの形式でストレージ格納先にエクスポートします。利用用途や要件に応じて、この格納先は、既に設定済みの既存のAWSサービス(Amazon EFSやファイルゲートウェイなど)、またはソースサーバ上のローカルファイルシステムになります。ステップ2では、エクスポートされたフラットファイルをAWS上に転送します(注:ストレージ格納先の機能によっては、ファイルをAWS上に明示的に転送する必要はありません。例えば、Amazon EFSまたはAWS Storage Gatewayのファイルゲートウェイを使用した場合、ファイルは自動的にAWSに転送されます)。ファイルを転送している間に、AWS Quick Start for SAP HANAを使用してSAP HANA環境を展開し、オプションでSAP HANAもインストールします。SAP HANAの標準的な展開時間は、SAP HANAの大規模スケールアウトシステムの場合でも、30分から1時間未満です。最後に、ステップ3で、新しく展開されたSAP HANA環境に実際にフラットファイルをインポートする作業が行われます。

SAP Rapid Migration Test Programでは、SAP HANAライセンスを持っていないお客様は、SAPアカウントチームから限られたテストライセンスを取得することができます。お客様は、自身でDMO with System Moveを使用することも、AWS Partner Network(APN)のSAPパートナーに支援依頼することもできます。

私たちは、AWS上でのSAPアプリケーションの利用経験についてお聞きしたいと思っています。ご不明な点がありましたら、ぜひお気軽にお問合せください。

閲覧ありがとうございました!

– Somckit

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

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 Intel ® Xeon® E7 8880 V3プロセッサ)、高いメモリ帯域幅および大きなL3キャッシュを提供します。このインスタンスはVPC専用で、レイテンシとジッターを最小限に抑えながら、Elastic Network Adapterを使用して最大20Gbpsのネットワーク帯域幅を提供します。また、デフォルトでEBS最適化が行われており、最大14GbpsのEBSへの専用スループットが設定されます。

いくつかのシェルのスクリーンショットです。最初に、dmesgでブート時のカーネルメッセージを表示します:

次に、lscpuでvCPUとソケット数を他の多くの興味深い項目と共に表示します:

そして、topでは約900のプロセスを表示しています:

SAP HANA Studioの画面です:

以下の図からわかるように、この新しいインスタンスにより、大規模クラスタの認定と合わせて、EC2上でSAPを実行するためのスケールアウトオプションとスケールアップオプションの組合せを広げます。

長期的なメモリ重視のロードマップ
大規模なSAP導入の計画にはかなりの時間がかかることも分かっているので、ロードマップの一部を共有したいと考えています。

現在、サードパーティのコロケーション施設でより大規模なSAP HANA認定サーバを稼働させ、AWS Direct Connectを使用してAWSインフラストラクチャに接続することができますが、お客様は既に利用されているX1インスタンスのようなクラウドネイティブソリューションを必要としていると仰っています。

このご要望を満たすために、私たちはより多くのメモリを持つインスタンスを計画しています!2017年から2018年にかけて、8TBから16TBのメモリのEC2インスタンスを提供する予定です。これらの今後のインスタンスは、x1e.32xlargeと共に、より大きなシングルノードのSAP導入およびマルチノードのSAP HANAクラスタの作成、さらに他のメモリ重視のアプリケーションやサービスの実行を可能にします。また、小規模なインスタンスで限界に達するときに役立ついくつかのスケールアップへの余力も提供します。

できるだけ早く私たちの計画に関する詳細情報を共有していきます。

SAPPHIREで会いましょう
AWSは、SAPPHIREの539番ブースに出展しており、ブース内のシアターで私たちのチームやお客様、パートナーからの一連のセッションを予定しています。また、イベントを通じて多くのセッションに関与しています。例えば以下のようなものです(詳細は、SAP SAPIRE NOW 2017を参照してください)。

SAP Solutions on AWS for Big Businesses and Big Workloads – 5月17日水曜正午から、Bas Kamphuis (General Manager, SAP, AWS)とEd Alford氏 (VP of Business Application Services, BP)が講演

Break Through the Speed Barrier When You Move to SAP HANA on AWS – 5月17日水曜午後12時30分から、Paul Young氏 (VP, SAP)とSaul Dave氏 (Senior Director, Enterprise Systems, Zappos)が講演

AWS Fireside Chat with Zappos (Rapid SAP HANA Migration: Real Results) – 5月18日木曜午前11時から、Saul Dave氏 (Senior Director, Enterprise Systems, Zappos)とSteve Jones (Senior Manager, SAP Solutions Architecture, AWS)が講演

Jeff;

追伸 – もし、SAPの経験をお持ちで、そのキャリアをクラウドで活かしたい場合は、プリンシパルプロダクトマネージャー(AWSクイックスタート)SAPアーキテクトのポジションにご応募ください。

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

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アプリケーションのバックアップとスナップショットの保存に使用できます。
  • Amazon Glacier – このサービスは、スケーラビリティが高く、耐久性に優れ、コスト効率の高いオブジェクトストレージで、コンプライアンスや規制上の理由から長期的なバックアップ、アーカイブ、データ保管に使用できます。
  • IAM – AWS Identity and Access Management(IAM)は、AWSユーザーとグループの作成および管理に使用します。また、IAMロールによりAWSリソースへのアクセスを安全に制御することができます。
  • CloudWatch – Amazon CloudWatchは、AWSリソースの監視サービスです。SAPワークロードのリソース利用状況を収集するとともに、AWSリソースの変更に自動的に対応するためのアラームを作成するのに重要です。
  • CloudTrail – AWS CloudTrailは、AWSアカウント内で行われたすべてのAPI呼び出しを記録します。APIコールに関する重要なメトリックを取得し、SAPリソースの証跡作成を自動化できる非常に有益なサービスです。
  • AWS CLI – AWSコマンドラインインターフェイス(CLI)は、コマンドラインまたはスクリプトを使用して様々なAWSサービスを管理、操作するために使用できるツールです。このブログ後半の”AWS自動化”の項でいくつかのAWS CLIコマンドの例を確認できます。
  • Route 53 – Amazon Route 53は、スケーラビリティと可用性の高いAWS上のDNSサービスです。ホステッドゾーン、トラフィックポリシーやドメインを作成したり、AWS以外のリソースにも接続することができます。

AWSサイジングと性能

AWSプラットフォームであれば、セルフサービス方式で正しいタイプとサイズのコンピューティングリソースを展開でき、ハードウェアに大きな初期投資をする必要はありません。AWSに移行することの主な利点の1つに、ビジネスニーズの変化に合わせてリソースを調整できる拡張性と柔軟性が手に入ることが挙げられます。例えば、AWSは、SAPランドスケープをお客様の近くで安全かつ高可用な方法で運用できるよう、16のリージョンと42のアベイラビリティゾーンからなるグローバルフットプリントを提供しています。従来のオンプレミスの構成と異なり、AWSクラウドにおいては、以下に示すようにコンソールでの数クリックの操作や、簡単なAPI呼び出しで、SAP用EC2インスタンスのサイズを変更できます。

AWSマネジメントコンソールから既存のEC2インスタンスのサイズ変更

お客様が必要とする大量のリソースをすぐに利用でき、また使った分のお支払いで済みます。これにより、インフラストラクチャの設計者は、新しいプロジェクトのコンピューティング/メモリーのサイジング要件を決定する際に、バッファを加味したり推測したりすることが不要になります。また、月末や決められた期間のような特別なイベントの間だけ、既存のホストへの容量の追加やSAPアプリケーションまたはデータベース層を拡張することが容易にできます。AWSでは、リソース要件を満たすためにメモリー最適化、コンピュート最適化のインスタンスタイプを提供しており、SAP社と密に連携してどちらもSAP認定を取得しています。SAP認定EC2インスタンスのリストは、SAPノート1656099を参照してください(SAPノートの閲覧にはSAP Support Portalのユーザーが必要です)。

AWS上でSAPアプリケーションを設計するということは、すべてのSAPアプリケーションを常に稼働させる必要はないということです。サンドボックス、トレーニング、デモシステムなど、重要ではないSAPシステムのほとんどは、使用していないときには停止することができ、コストを削減できる可能性があります。

AWS上で性能を実現するための1つに、ストレージの設定方法があります。EBSボリュームはアベイラビリティゾーン内で複製されるため、データ損失から保護されています。このような理由から、EBSボリュームで最大限の性能を出すためには、RAID 0によるストライピングでよいです。これは大半のオンプレミス環境では不可能です。様々なEBSボリュームタイプと性能特性の詳細については、ブログ「SAP HANA on AWSの展開 – どのような選択肢が?」も参照してください。これらのEBSボリュームは、HANA以外のデータベースにももちろん使用できます。

AWS自動化

AWSはクラウドオートメーションのリーダーであり、基盤となるリソースをプログラム的にスクリプト化して、予測可能かつ繰返し可能な方法で操作、拡張するための複数の選択肢を提供しています。スクリプトの実行により、SAPアプリケーションサーバーの新規作成、バックアップやスナップショットの取得、最初から新しいインスタンスを構築するなど、SAPの操作を自動化できます。

稼働中のSAP HANAデータボリュームのスナップショットをバックアップ用に取得し、それらのボリュームを復元することがいかに簡単かを示す例をいくつか紹介します。これらのコマンドは容易に作成することができ、crontabやその他の時間駆動のジョブスケジューラツールからバックアップ/リカバリーの操作スクリプトの一部として簡単に実行できます。

例1: 稼働中のHANAデータボリュームのスナップショット取得

  1. SAP HANAインスタンスの停止:
    sudo su – <sid>adm -c "HDB stop"
  2. ファイルシステムの静止:
    umount /hana/data
  3. インスタンスにアタッチされているSAP HANAボリュームのIDを識別:
    aws ec2 describe-volumes --region=us-west-2 --filters Name=attachment.instance-id,Values=i-03add123456789012 Name=tag-value,Values="HANA*" --query 'Volumes[*].{ID:VolumeId,Tag:Tags}'Response:

    [
        {
            "Tag": [
                {
                    "Value": "HANA_root",
                    "Key": "Name"
                }
            ],
            "ID": "vol-071111111111111"
        },
        {
            "Tag": [
                {
                    "Value": "HANA_data #1",
                    "Key": "Name"
                }
            ],
            "ID": "vol-082222222222222"
        },
        {
            "Tag": [
                {
                    "Value": "HANA_data #2",
                    "Key": "Name"
                }
            ],
    		"ID": "vol-0733333333333"
         }
    ]
    
  4. SAP HANAボリュームのスナップショットを取得:
    aws ec2 create-snapshot --region=us-west-2 --volume-id vol-07222222222222 --description "HANA Server Data volume #1"; aws ec2 create-snapshot --region=us-west-2 --volume-id vol-08333333333333 --description "HANA Server Data volume #2
  5. SAP HANAデータボリュームのマウント(この操作はスナップショットがPending状態になれば可能):
    mount /hana/data
  6. SAP HANAを起動:
    sudo su - <sid>adm -c "HDB Start"

例2: スナップショットからデータを復元し、既存のホストにアタッチ

  1. スナップショットから新しいボリュームを作成:
    aws ec2 create-volume --region us-west-2 --availability-zone us-west-2a --snapshot-id snap-1234abc123a12345a --volume-type gp2
  2. EC2インスタンスに新しく作成したボリュームをアタッチ:
    aws ec2 attach-volume --region=us-west-2 --volume-id vol-4567c123e45678dd9 --instance-id i-03add123456789012 --device /dev/sdf
  3. 読込処理を最適化するためにボリュームの初期化(本番環境では強く推奨):
    fio --filename=/dev/xdf --rw=randread --bs=128k --iodepth=32 --ioengine=libaio --direct=1 --name=volume-initialize
  4. SAP HANAデータに関連付けられた論理ボリュームをマウント:
    mount /dev/mapper/hanaexpress-lvhanaexpressdata /hana/data
  5. SAP HANAを起動:
    sudo su - <sid>adm -c "HDB Start"

SAP on AWSで自動化を活用する方法は他にもあります:

  • Amazon Machine Images(AMI)を使用してSAPインスタンスの新しいコピーを作成できます。
  • AWS CloudFormationを使用して新しいSAPインスタンスの作成を自動化、AWS Quick Startを活用してクラウド内に新しいSAP HANA環境の展開を実現できます。

複数のアベイラビリティゾーンおよびまたはリージョンを使った可用性と災害対策

従来のオンプレミス構成のSAPシステムでは、同じ物理データセンター内で高可用性(HA)を取る必要がありました。対照的に、AWSは同じリージョン内の複数のアベイラビリティゾーンにまたがったHAを構成できます。アベイラビリティゾーンは、物理的に隔離されたデータセンターの集合体で、ネットワークのレイテンシーが低く、同じ地理的リージョンに接続されています。いくつかのお客様にとっては、この構成で災害復旧(DR)シナリオとしても十分ですが、そうでない場合、TCOの度合いによって国や都市の異なる2つ目のリージョンの利用といった複数の選択肢を用意しています。以下のSAP分散アーキテクチャの例をご覧ください。

AWS上のSAP分散アーキテクチャ

SAP運用

オンプレミス環境と比較して、AWSではAmazon CloudWatchやAWS CloudTrailなどの監視サービスを使うことができ、SAPシステムの運用においてこれまで以上の透明性と説明責任が得られます。AWSリソースへのきめ細かいセキュリティとアクセス制御には、IAMロールとポリシー、セキュリティグループ、そしてネットワークACLを使うことができます。

  • 監視サービス – CloudWatchやCloudTrailのようなサービスは、リソース使用率を監視するのにも役立ちます。CloudWatchを使用すると、ハードウェア障害が発生した場合に、インスタンスを監視して自動的に復旧するアラームを作成できます。詳細はAWSドキュメントをご覧ください。
  • セキュリティ – IAMはAWSリソースへの洗練されたアクセス制御を可能にするだけでなく、AWSアクセスキーをコピーすることなく、異なるサービス間の安全な通信を可能とするロールも作成できます。詳細はAWSドキュメントをご覧ください。
  • バックアップ – Amazon S3連携をサポートするバックアップツールのいずれかを使用する場合、S3バケットに直接データベースをバックアップできます。そうでない場合は、AWS上で既存のバックアップツールを使用して、EBSボリュームにファイルをエクスポートしてからAmazon S3と同期することもできます。

AWS簡易見積りツール

AWSでは、ハードウェアと運用コストを包括的に把握することが難しいオンプレミスの世界とは異なり、オンデマンドやリザーブドインスタンスを含むEC2インスタンスの様々な支払い方法とインフラストラクチャのコストをマッピングするツールを提供しています。

次のステップ

SAP on AWSの詳細については、以下のリソースをご覧ください:

– Rahul

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