SAP HANA に最適化された次世代 ERP の登場 従来の SAP Business Suite SAP S/4HANA 基幹系 情報系 基幹系 + 情報系 SAP GUI SAP Business Suite ERP CRM SRM SCM PLM BI Tools SAP Fiori, S/

Transcription

1 基幹系システムの The New Normal ~SAP on AWS~ アマゾンウェブサービスジャパン株式会社パートナーソリューションアーキテクト河原哲也 2016/6/3 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

2 SAP HANA に最適化された次世代 ERP の登場 従来の SAP Business Suite SAP S/4HANA 基幹系 情報系 基幹系 + 情報系 SAP GUI SAP Business Suite ERP CRM SRM SCM PLM BI Tools SAP Fiori, S/4HANA Analytics SAP Business Suite Simplified Suite シンプル化 コードプッシュダウン ( 一部 ) CDS View コピー Any DB DWH SAP HANA アプリケーション層がボトルネック 基幹系 (OLTP) と情報系 (OLAP) は別々 SAP HANA( インメモリー ) を前提に再設計 基幹系 (OLTP) と情報系 (OLAP) の融合

3 クラウドは今や SAP においてもニューノーマル 昨年の今ごろ そして 今年は X1 出典 :SAP ニュースルーム SAP Business Suite on AWS の本稼働認定は 2012 年 11 月 SAP ERP の国内導入は約 2,000 社 (H/W 更新は 5~7 年が一般的 ) 128 vcpus / 1,952 GiB メモリー SAP HANA に最適 SAP S/4HANA on AWS が本格化

4 本日お伝えしたいこと X1 インスタンスの SAP 認定詳細 SAP HANA on AWS 構築自動化の仕組み

5 本日お伝えしたいこと X1 インスタンスの SAP 認定詳細 SAP HANA on AWS 構築自動化の仕組み

6 Amazon EC2 X1 インスタンス インスタンスタイプ x1.32xlarge の仕様 プロセッサー : Intel Xeon E v3 (2.3 GHz) x 4 ソケット, 64 コア / 128 vcpus メモリー : SDDC+1 を実現した 1,952 GiB インスタンスストレージ : 2 x 1,920 GB SSD ネットワーク帯域幅 : 10 Gbps 専用の EBS 帯域幅 : 10 Gbps ( デフォルトで EBS 最適化 追加料金不要 )

7 SAP 認定 SAP HANA IaaS Platforms シングルノード構成で 1,952 GiBメモリーの OLAP と OLTP 両方に 唯一対応 (2016 年 6 月 3 日現在 ) 出典 :CERTIFIED SAP HANA HARDWARE DIRECTORY

8 SAP 認定 SAP NetWeaver Platforms セントラル構成で 131,500 SAPS / 24,060 SD ユーザー を達成 (Cert: ) 出典 :SAP Standard Application Benchmarks in Cloud Environments

9 SAPS これまでの SAP 認定 EC2 インスタンス群 50,000 m4.10xlarge 40,000 c4.8xlarge 10 ギガビット拡張ネットワーキング r3.8xlarge 30,000 c3.8xlarge 20,000 c4.4xlarge c3.4xlarge m4.4xlarge r3.4xlarge 10,000 c4.2xlarge m4.2xlarge c3.2xlarge r3.2xlarge 0 c4.xlarge c3.xlarge m4.xlarge r3.xlarge c4.large c3.large m4.large r3.large メモリー [GiB]

10 SAPS X1 インスタンスが加わったことで , , ,000 x1.32xlarge 110, ,000 90,000 80,000 70,000 60,000 50,000 40,000 30,000 20,000 10,000 0 m4.10xlarge c4.8xlarge r3.8xlarge c3.8xlarge c4.4xlarge m4.4xlarge c3.4xlarge r3.4xlarge c4.2xlarge c3.2xlarge m4.2xlarge r3.2xlarge c4.xlarge m4.xlarge c4.large c3.xlarge r3.xlarge c3.large m4.large r3.large ,000 1,200 1,400 1,600 1,800 2,000 メモリー [GiB]

11 すべての SAP ワークロードを on AWS で SAP S/4HANAの必要メモリー XS/S (128GB-256GB) = 48% M/L (512GB-1TB) = 38% XL/XXL (2TB-48TB) = 14% 出典 :SAPPHIRE NOW Keynote - Your Road to SAP S/4HANA and Beyond X1 インスタンス (x1.32xlarge) のシングルノード構成で 100% に近いお客様の SAP S/4HANA 環境をカバー

12 本日お伝えしたいこと X1 インスタンスの SAP 認定詳細 SAP HANA on AWS 構築自動化の仕組み

13 SAP HANA も必要なときに 必要なだけ SAP HANA アプライアンス (H/W) 数カ月 業者に連絡見積り 発注受け入れ準備納品 設置構築 設定稼働 Web から数クリックで稼働 ~1 時間 SAP HANA on AWS 数千倍のスピード感で利用可能 その他のメリット スタートアップ費用が不要 スペック変更が容易 世界中で利用可能など

14 AWS CloudFormation テンプレート AWS CloudFormation スタック JSON 形式ファイル パラメータの定義リソースの定義アクションの定義 フレームワーク スタックの作成スタックの更新エラー検知とロールバック AWS サービスの構成 幅広いサービスをサポートスタックイベント履歴カスタマイズ可能

15 Quick Start for SAP HANA デプロイガイド CloudFormation テンプレート { "AWSTemplateFormatVersion": " ", "Description": "(0007) Deploy AWS infrastructure and SAP HANA on AWS", "Parameters": { "VPCCIDR": { "Description": "CIDR block for the Amazon VPC to create for SAP HANA deployment", "Type": "String", "Default": " /16", "AllowedPattern": "[a-za-z0-9]+\\..+" }, "HANAInstallMedia": { "Description": "Full path to Amazon S3 location of SAP HANA ~( 略 )~

16 AWS の Web サイトから呼び出すだけ

17

18

19 サーバーとストレージ構成における 6 つの特徴 OS 種類とバージョンが 選択可能 インスタンスタイプには R3 と X1 から選択 ノード数が入力可能 EC2 Auto Recovery の 設定有無が選択可能 データベースファイル用 EBS ボリュームのタイプには 汎用 SSD と PIOPS が選択可能 データベースファイル用 EBS ボリュームの暗号化の 設定有無が選択可能 バックアップ領域用 EBS ボリュームは新しい スループット最適化 HDD

20 SAP HANA 構成における 4 つの特徴 ドメイン名 SAP HANA の マスターとワーカーノード のホスト名が入力可能 SAP HANA インストール メディアの格納先は S3 SAP HANA ソフトウェアの インストール有無が選択可能 管理用 Windows サーバーの 展開有無が選択可能

21

22 1 時間未満で SAP HANA を利用可能 VPC CIDR ( 例 : / 16) Amazon S3 Root volume /usr/sap volume プライベートサブネット ( 例 : / 24) SAP HANA ( マスター ) パブリックサブネット ( 例 : / 24) RDP ( オプション ) SAP HANA Studio RDP SSH Internet SAP HANA インストールメディアバケット HANA data/log volumes HANA backup volume HANA shared volume Router Internet gateway Root volume マスターの NFS 共有をマウント VPC NAT gateway バックアップスナップショット /usr/sap volume HANA data/log volumes SAP HANA ( ワーカー ) 踏み台 Inbound SSH Elastic IP Virtual Private Cloud Availability Zone

23 設計 / 構築から運用を網羅したホワイトペーパー 料金見積り サイジング SAP HANA 移行 実装と運用 バックアップ / リカバリー 高可用性と災害対策

24 SAP HANA on AWS 4 つの移行シナリオ R3 X1 R3 R3R3 R3 X1 R3( シングルノード ) を X1 に変更複数の R3( マルチノード ) を X1 に集約 X1, R3 X1, R3 Any DB から X1 or R3 へ DC/DB 移行 AWS 外の HANA から X1 or R3 へ DC 移行

25 本日お伝えしたこと X1 インスタンスの SAP 認定詳細 すべての SAP ワークロードを on AWS で SAP HANA IaaS Platforms で唯一 1,952 GiB メモリーの OLAP/OLTP 両方で認定取得 セントラル構成で 131,500 SAPS を達成 SAP HANA on AWS 構築自動化の仕組み Quick Start for SAP HANA(AWS CloudFormation) により必要な時に 必要なだけ SAP HANA を利用可能

26

27 基幹系システムの The New Normal ~Oracle on AWS~ アマゾンウェブサービスジャパン株式会社ソリューションアーキテクト辻正史 2016/6/3 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

28 Oracle Database on AWS

29 AWS における Oracle の傾向 Oracle Database は AWS 上でフルサポート エンタープライズ用途においても Oracle Database の ワークロードをアマゾン ウェブ サービス 以下AWS 上 で稼働させることは一般的になっている

30 2 つの Oracle Database on AWS フルマネージドな Amazon RDS for Oracle Database とセルフマネージドな Oracle Database on Amazon EC2 の 2 種類が選択可能 Amazon RDS for Oracle Database Oracle Database on Amazon EC2 ( 以下 RDS for Oracle) ( 以下 Oracle on EC2)

31 Amazon RDS for Oracle Database フルマネージドなサービス RDS for Oracle 数クリックでデータベースが起動 運用機能が実装済 容易に Multi-AZ 構成を構築可能 サービスとして提供するため Oracle Database が稼働している OS 層を隠ぺいする仕様

32 Oracle Database on Amazon EC2 セルフマネージドな Oracle on EC2 環境 EC2インスタンスにインストール オンプレミス環境同様の管理 ファイルベースの移行も可能 オンプレミス環境同様の管理が可能となり パッケージソフトウェア等での利用に制限が無い

33 本セッションの紹介内容 設計 運用への影響を減らすため Oracle on EC2 を選択する場合にも AWS 上で検討すべき項目を紹介 インストール ストレージ構成 バックアップ方式 高可用性 移行方式

34 インストール

35 インストーラが認識するホスト名 インストーラは OS に設定されているホスト名を認識 インストーラは自動でホスト名を取得し Oracle Database を構成する設定ファイルにホスト名に依存した値を設定 Hostname listener.ora インストーラ tnsnames.ora

36 EC2 のホスト名 EC2 のホスト名は自動で設定 EC2 環境では通常 ip 等のホスト名が自動で設定される ~]$ hostname ip ~]$ データベースサーバー名を変更したい場合 EC2 ホスト名の変更が必要

37 EC2 のホスト名の変更方法 Red Hat Linux 7 の場合 以下のコマンドでホスト名を固定化する [root@ip ~]# hostnamectl set-hostname server.domain.company.co.jp --static OS 再起動後もホスト名が維持されるように /etc/cloud/cloud.cfg に下記の行を追加する preserve_hostname: true

38 インストーラーが認識するホスト名を指定 環境変数 ORACLE_HOSTNAME で指定 明示的にホスト名をインストーラーに認識させる場合 環境変数 ORACLE_HOSTNAME で指定可能 ~]# export ORACLE_HOSTNAME=server.domain.company.co.jp

39 ストレージ構成

40 ストレージの選択 Oracle Database 専用のボリュームマネージャー ASM を利用 Amazon Elastic Block Store(EBS) を ファイルシステムとして構築 Automatic Storage Management(ASM) で管理 の 2 パターンが考えられるが ASM の利用を推奨

41 ASM と EBS について ASM は EBS との組み合わせに適している ASM はブロックデバイス (EBS) を複数束ねて 一つのディスクグループを構成することが可能 このブロックデバイスは動的に追加 削除することが可能で AWS において EBS と相性が良い 容量拡張 / 縮小 IO 性能向上 DG:SYSTEM ASM DG:DATA

42 EBS のボリュームタイプに応じた利用方法 ASM のディスクグループ毎に EBS のボリュームタイプを分け Tiered Storage を構成可能 ディスクグループ SYSTEM ASM DATA OLD_DATA io1: 高い IOPS を発揮する最高パフォーマンスの SSD ボリューム EBS ボリュームタイプ io1 io1 st1 st1: 高いスループットを発揮する低コストの HDD ボリューム

43 EBS 概要 ボリュームタイプ ユースケース ボリューム毎の最大 IOPS ボリューム毎の最大スループット Solid State Drive (SSD) プロビジョンド汎用 SSD IOPS SSD (io1) (gp2) I/O 性能に依存する NoSQLデータベースやリレーショナルデータベース 起動ボリューム 低レイテンシを要求するアプリケーション 開発 テスト環境 Hard Disk Drive (HDD) スループットコールドHDD (sc1) 最適化 HDD (st1) ビッグデータ スキャンする頻度が DWH ログデー低いデータタ処理 20,000 10, (16 KB I/O size) (16 KB I/O size) (1 MB I/O size) (1 MB I/O size) 320 MB/s 160 MB/s 500 MB/s 250 MB/s 月額料金 ( 東京リージョン ) $0.142/GB + $0.074/ 設定 IOPS 値 $0.12/GB $0.054/GB $0.03/GB

44 バックアップ方式

45 Oracle on EC2 環境のバックアップ オンラインバックアップには Oracle Recovery Manager(RMAN) が必須 ASM はブロックデバイスをまたいだデータの再配置を行うことがあり このタイミングで EBS スナップショットを取得した場合 不整合が発生する可能性がある この点からも RMAN の利用を推奨 なお Oracle Secure Backup を利用することで直接 S3 にバックアップを取得可能

46 バックアップデータは S3 への格納を推奨 Oracle Secure Backup を利用することで直接 S3 にバックアップ可能 EC2 S3 Oracle ASM RMAN Oracle Secure Backup Backup Set

47 Oracle Secure Backup を利用しない方法 RMAN のバックアップセットをファイルシステムに作成 Oracle Secure Backup は有償オプションのため開発環境やテスト環境で使用するのは冗長 RMAN の出力先を EBS(st1/sc1) とすることでコスト削減が可能 EC2 S3 Oracle ASM RMAN RMAN 領域 EBS Snapshot

48 システムバックアップ 製品バイナリおよび ASM は データと分けてバックアップ Oracle on EC2 ファイルシステム ASM RMAN バックアップ ファイルシステム 製品バイナリ Data RMAN 領域 S3 構成変更時 定期

49 高可用性方式

50 Multi-AZ 構成を意識した高可用性構成 Multi-AZ 構成を採用し AZ 障害にも対応可能なアーキテクチャデザインが重要 プロダクション環境で Multi-AZ を意識する場合 一般的に Oracle Data Guard が選択肢となる Availability Zone A Availability Zone C Oracle プライマリ Data Guard Oracle スタンバイ ライセンスが必要

51 Data Guard におけるコスト削減案 1 EC2 インスタンスの縮小 スタンバイ側の EC2 を小さくすることで 必要な EC2 コストおよび Oracle Database ライセンスの節約が期待できる フェイルオーバーが発生した場合は 必要なサイズの EC2 インスタンスに変更可能 Availability Zone A Availability Zone C Oracle プライマリ Data Guard Oracle スタンバイ ライセンスが必要

52 Data Guard におけるコスト削減案 2 スタンバイ側の EBS のコスト削減 スタンバイ側は検索処理が発生せず IOPS も小さくなる この場合 コストが低い st1 sc1 の利用も考えられる フェイルオーバー時は io1 に変更可能 Availability Zone A Availability Zone C EBS io1 ASM Oracle プライマリ Data Guard Oracle スタンバイ ASM EBS sc1

53 Data Guard を利用しない AZ 障害対策 プライマリ DB のスナップショットから戻す テスト 開発環境において Data Guard は過剰 定期的なスナップショットから戻す運用 S3 Availability Zone A Oracle Availability Zone C Oracle ホスト名を固定していないと AMI から起動した際に自動でホスト名が変更され 正常に動作しないことが考えられる

54 AWS における RAC (Real Application Cluster) セルフマネージド環境の RAC 構築手順が公開されている あくまで セルフマネージド環境の RAC であり 開発 テスト用途に適している

55 AWS では RAC が必要なケースは少ない 従来 RAC が解決してきた課題のいくつかはクラウドが解決済で この場合 RAC オプションが不要となる 主な課題 RAC オンプレミス環境 AWS 環境 可用性 ノード障害時にも 稼働ノードで即座に処理を再実行可能 障害時は別 H/W で即時 DB を再起動可能 リソース活用 HA 構成におけるリソースの無駄を解決スタンバイの H/W リソースは不要 拡張性ノード追加によるキャパシティ増加必要に応じたインスタンスタイプの変更 ノード障害時 即座に処理の再実行を求められるシステムで RAC は有効 他の課題は AWS も解決可能で AWS への移行を視野に検討してみる価値がある

56 移行方式

57 移行方式 Oracle on EC2 では RMAN 等を利用したファイルベースの移行が可能 主に以下の方式が利用可能 Oracle Recovery Manager Oracle Data Pump AWS Database Migration Service AWS Import/Export Snowball

58 その他

59 Oracle Database Standard Edition 2 AWS 上で稼働させる Oracle Database Standard Edition 2 に関するライセンスポリシーが追加 詳細は以下を参照 Virtual Core については以下を参照

60 まとめ ホスト名の変更 / 固定化 ASM は EBS と相性がよい バックアップは RMAN システムバックアップとデータを個別にバックアップ Multi-AZ 構成として Data Guard

61 参考資料 AWS ホワイトペーパー AWS での Oracle データベースの稼働に関するベストプラクティス Oracle データベースを AWS に移行するための戦略 AWS での Oracle データベースの IOPS のニーズを判別する Amazon EC2 で Oracle ワークロード用のオペレーティングシステムを選択する Amazon EC2 の Oracle データベースの高度なアーキテクチャ

62 Thank you!