Category: 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アプリケーションのバックアップとスナップショットの保存に使用できます。 […]

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

この記事は、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 […]

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

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

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

多くの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.0、AES-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 […]