SCSK 大口です。
前回の記事は以下です。
今回は、主に、SAP運用に関するトピックのうち、AWS のブログで取り上げられていることを中心に整理していきます。
SAP監視
SAPの監視は、専用の監視サーバを置くというアプローチがいままでのシステム構成では多いです。私も過去に関わった導入プロジェクト、移行プロジェクトでは、監視システムを導入することは多かったです。
CloudWatch を利用すると、監視システムを監視するといったアプローチが不要になるので効率化できる部分だと考えらます。
AWS のブログを見ていると、CloudWatch を活用するアプローチがいくつか紹介されていました。
Jco (SAPを呼ぶライブラリ)を Lambda に入れて監視するアプローチですが、これは以前はできなかったことで、Lambda の Endpoint を VPC に出せるようになったことで実現できるようになりました。
Jco を使うアプローチは監視に限らず、いろいろ活用できそうです。
SAP HANA に関する記事は以下のものがあります。
また Amazon CloudWatch Application Insights で、SAP HANA がサポートされました。HANAのパフォーマンス監視はこちらに切り替えるのがいいかもしれません。
バックアップ
SAPのバックアップについても、AWS ソリューションの活用をすることが提案されています。
この記事に有益な情報がたくさんあるので以下に整理します。
SAP HANA
AWS BackInt Agent for SAP HANA を導入して、S3にバックアップを取る設定ついて以下に紹介されています。AWS Launch Wizard であらかじめインストールできたりします。
SAP Backint Agent for Amazon S3 というのもあり、こちらは、SAP Note.2935898 に記載があり、Python3.7に依存しているものも用意されています。こちらはオプションとの位置づけなので理由がなければ、AWS が提供する Backint Agent を利用するということ良いでしょう。
AnyDB
データベース共通の対応として S3 に転送することが推奨されています。転送は、AWS Systems Manager を使って自動化することができます。
Oracle Database
データバックアップは、Oracle Secure Backup(OSB) Cloud Module を導入することで S3 にバックアップが取れる機能があります。OTN から Module をダウンロードして設定することで、RMAN SBT(テープデバイス)として見えるようになり、SBTの並走数の拡張設定が可能なのでバックアップパフォーマンスの向上も可能です。
データベース全体としては、クラッシュ整合性(複数のEBS間でのバックアップタイミングの整合性）がとれたバックアップとリカバリーについての記載が以下にあります。Oracle ASM を AWS 上で構成してテストしています。
SAP ASE Database
データバックアップは、ホワイトペーパーの手順に基づいて AWS Storage Gateway の Amazon S3 File Gateway を構成を構成しバックアップ先に指定ができます。
データベース全体としては、クラッシュ整合性の取れたバックアップを取得するスクリプトのサンプルが以下に示されています。
Microsoft SQL Server
MS SQL Serverにある VSS (Volume Shadow Copy Service)機能を利用して一貫したDBバックアップを作成できます。以下に具体的な手法が書かれています。
そのほか
そのほかいくつかのバックアップのポイントについての記述もあります。
- Amazon S3レプリケーション時間制御機能により、AWSのサービスレベルアグリーメントに基づいて、予測可能な時間枠でAmazon S3オブジェクトをレプリケーションする
- DRリージョンでS3 標準 – 低頻度アクセス（S3 標準 – IA）クラスを選択することで、DRリージョンにバックアップを低コストで保存
- AWS Backupは、Amazon EBS、Amazon EFS、Amazon EC2、Amazon DynamoDB、Amazon Aurora、AWS Storage Gatewayなどのサービスのバックアップを管理するコントロールプレーンを提供
- スナップショットは、/usr/sap/* や /sapmnt/* などのSAPファイルシステムをバックアップする
- EBSスナップショットでデータベースをバックアップする場合は、データベースを「バックアップモード」にするか、スナップショットが起動する前にデータベースをシャットダウンする
SAP HANA の場合のデータベースの静止点を取るコマンドは以下のヘルプのリンクが提示されています。
- Amazon EFSファイルシステムはsaptransとsapglobalファイルをホストするために使用できる。
- AWS DataSyncを使用して、Amazon EFSをDRリージョンにレプリケーションする。
- AMI (Amazonマシンイメージ)バックアップは、すべてのEBSボリュームを含むEC2インスタンス全体の完全復旧可能なコピーを作成できる。
ディザスタリカバリ
先ほどの記事にディザスタリカバリ(DR)に関する言及があります。例として、以下の絵が示されています。
この記事の中には、障害のパターンを以下に分けて復旧例が記述されているので要確認です。
- シナリオ1: Amazon EC2の障害
- シナリオ2: Amazon EBSの障害
- シナリオ2a: 独立または単一のAmazon EBS ボリュームの障害
- シナリオ3: アベイラビリティーゾーンの障害
- シナリオ4: リージョンの障害
DR は3つのパターンが考えられると思います。
以下のAWSのブログに考え方が書かれています。
SAPに対して適用できそうな表に整理してみます。
| 手法 | コスト | RPO/RTO | 手法 | フェールオーバー |
|---|---|---|---|---|
| パッシブDR | 小 | 数時間単位 | S3 クロスリージョンレプリケーション、AWS Backup クロスリージョンバックアップ、AMIリージョン間コピー | AMIからインスタンス起動、S3 からバックアップをリストア、ログ適用、DNS変更 |
| パイロットライトDR | 中 | 数十分単位 | DBレプリケーション(ログ適用)、S3 クロスリージョンレプリケーション、AWS EFS を AWS Dayasync で同期、AMIリージョン間コピー | AMIからインスタンス起動、DNS変更 |
| ウォームスタンバイDR | 大 | 数分単位 | DBレプリケーション(ログ適用)、S3 クロスリージョンレプリケーション、AWS EFS を AWS Dayasync で同期、AMIリージョン間コピー | 停止していたAPサーバの起動、DNS変更 |
SAP HANA を利用したパッシブ災害対策については以下のブログが参考になります。
また、「スナップショットを使用したSAP HANA データベースの自動化された回復手順を作成する方法」というブログも確認したほうがよさそうです。
監査対応
SAPシステムは、会社の財務管理の中心に位置づけられることが多いので監査対応は、一つのポイントだと考えられます。
そこで、AWS Config を利用して SAP システムを評価してみようという試みが紹介されています。
Part2 にあるパラメータ login/no_automatic_user_sapstar は、監査でも設定内容についてのチェックを求められる項目の一つなので、この活用というのは、いいアプローチと考えられます。
SAPジョブ運用
Exam Guide に、AWS Step Function が項目とあがっています。以下の話を指しているのかなと考えています。
SAP にはジョブコントローラーが搭載されています(T-cd: SM37)。ただ、依存性のあるジョブのコントロールが難しいという問題があり、多くのカスタマでは、ジョブ管理ツールを導入しています。それについて、Serverless でできるように、AWS SAP Professional Services が、Simple Scheduler を開発したとの記事です。
日本国内ではサポートされるのかはわかりませんが、同様の機能をプロジェクトで開発してもいい内容だとは思います。Serverless を活用できれば管理対象サーバや購入するライセンスが減らせます。
セキュリティ
運用の中でセキュリティは、大事な要素の一つです。
SAPは会計のデータなど社内での重要データを扱うことが多いので、構築時に、運用に備えて、EBS の暗号化をしておくことは、強く推奨される事項だと考えています。
また、OSの定期的なパッチ適用も SSM を利用することで効率化できると考えられます。
SAPアプリケーションも、最近は、CVE の発番がされたケースもあります。そういった場合は、SAPノートが作成されてリリースされるので、その内容に基づいて対応することになります。
インスタンス運用コストの削減
Exam Guide に、Cost Management と記載があって、SAPでよく言われる話を紹介しておきます。また、サンプル問題の問3で取り上げられています。
SAPシステムでは、構築時は「３ランドスケープ」と呼ばれる構成を取ることが推奨されています。開発に使用する開発環境(DEV)、結合テストなどに使われる検証環境(QAS)、本番利用される本番環境(PRD)の3つの環境を構築、管理することが推奨されています。
移行などを経て本稼働を迎えると、本稼働において利用するインスタンスは、24時間稼働することになります。一方で、開発環境(DEV)や検証環境(QAS)は、利用頻度が落ちてくるのが一般的です。
そこで、本番稼働をするインスタンスは、リザーブドインスタンスを活用し、開発環境や検証環境は、オンデマンドインスタンスとして、平日で、9:00 – 18:00 までの利用にすることでコスト削減を図るという考え方です。
本番稼働インスタンスには、リザーブドインスタンスまたは、Saving Plan を適用、開発機、検証機には、オンデマンド運用で時間で制限して運用費用を削減します。
関連するリンクを以下に示します。
まとめ
今回は、運用の側面からまとめてみました。
その1からその6まで、とても長い記事になってしまいましたが、最後まで読んでいただきありがとうございました。SNS でコメントいただいたりしているようで、ありがとうございます。
次回は、その7として、このシリーズのまとめとβ試験を受けてきてのコメントを書きたいと思います。