SCSK 大口です。
前回の記事は以下です。
今回は、前回に引き続き、SAP インスタンスの構成について考えていきます。
SWPM と SUM
Exam Guide に、SWPM や SUM と出てきますが、これは、SAP の導入やパッチ適用をするツールです。以下の表に示します。
| 略称 | フル名称 | 用途 |
|---|---|---|
| SWPM | Software Provisioning Manager | SAPソフトウェアの導入をするツール |
| SUM | Software Update Manager | SAPソフトウェアのアップデートをするツール |
SUM には、DMO(Data Migration Option)というものがあります。DMO は、SAP の Database を Migration するのに使うツールですが、主に、HANA に Migration するときに使います。
また、AWS のサービスにも、DMS(Database Migration Service) がありますが、同様に Database の Migration をするツールです。どちらも Migration するツールで、AWS の DMS の Migration できる Database に、SAP ASE があるので、ひっかけ問題かというぐらい紛らわしさなので要注意です。
インスタンスの構成
SWPM のガイドにも記載があるのですが、ここからは選択できるインスタンスの構成を示します。
※挿絵は導入ガイドから引用しています。
Standard System
1つのホストに、SAPインスタンスとDatabaseインスタンスを導入したシステムを言います。図示をすると以下です。SAP認定された EC2 のインスタンスに導入します。
名前の通り、スタンダードな構成で、PoC や開発環境でよく採用されます。AWS で置き換えてみたときに、コストが一番安く運用できるものと考えられます。
Distributed System
SAPインスタンスとをDatabaseインスタンスを別々のホストで実行する形態を指します。ASCS と PAS を同じホストにも入れられますし、別のホストに入れることもできます。
一番選ばれるパターンとしては、Database を1つの EC2 インスタンスに導入し、下記の図では分かれている ASCS インスタンス、PAS インスタンス、Host with Global Transport Directory を 1つのEC2インスタンスに導入する形です。
EC2 のインスタンスは、AutoRecovery の機能がありますが、データベースだけ高可用性構成をとり、SAPを導入したインスタンスは、AutoRecovery を使って構成するという考え方もあります。
High-Availability System
Standard System や、Distributed System の構成を踏まえて、今度は、高可用性の構成を考えていきます。Windows環境の場合は、以下のようなインスタンス配置がよくあるパターンと思います。AWS の環境では、Windows 環境の Oracle は使用できないため、事実上、SQL Server を使って高可用性の構成を取る場合に使われます。
Linux で移行する場合は以下の構成が考えられます。Windows の図と書き方が異なるのですが、ほぼ、同様の構成で、ASCS / ERS をクラスタに入れて構成します。配置的にも、Windows と考え方は同様です。SAP HANA でもこちらの考え方になります。
高可用性構成をAWS上に展開する場合、以下のブログに配置例が示されています。SIOS クラスタリングソフトウェアを使った例です。
この場合のポイントとしては、EFS に SAP の実行ファイル(/usr/sap、/sapmnt)を入れることは出来るのですが、共有ストレージに DB を入れる構成は、サポートされていないことです。ミラーリングだけがサポートされています。
クラスタリングソフトウェアは、SAP で認定されているものは、SIOS、SLES HA、Red Hat HA、CLUSTERPRO です。また、Windows クラスターでも構成できます。
Red Hat HA や、SLES HA については SAP Netweaver での具体的な設定について紹介されていますので以下が参考になります。
クラスタリングで使うIPアドレスに関連して、サンプル問題の問5 を見ていると、Overlay IP について設問の中で問われています。
Overay IP は、以下のURLに説明がありアーキテクチャー図が示されています。
先ほどのクラスタリングは、図にあるように、Database の部分と、SAP の部分を別個にクラスタリングの設定をします。(この図では、SAPの部分だけですが、Database についても高可用性ソフトウェアを使うのであれば同様な考え方ができます)
クラスタの設定では、IP アドレスを指定する必要がありますが、そのアドレスは、SAPやDatabaseインスタンスがいる VPCとは異なるアドレス体系を取る必要があり、ここについて、Transit Gateway を用いて、そのアドレスを SAP のある VPC に与えるようにします。これを Overlay IP と呼んでいます。
以下に具体的な設定例が示されており
Transit Gateway 上で SAPインスタンスのいる 10.0.0.0/16のVPCに対して、172.16.1.0/26 というクラスタに割り当てる IP を Static に切ることで、同じ VPC の中で IP アドレスを使用してクラスタリングの設定をすることができます。
そのほか、SAP HANA における NLB を使った例なども AWS のドキュメントでは解説されていいます。高可用性の構成は出題のポイントになる部分だと思うので、関連するドキュメント類は確認しておいた方がよさそうです。
可用性構成に関するデータベースの推奨事項
可用性構成に関して、各データベースで制約があったり推奨事項が AWS のドキュメント上で紹介されているので、以下に示します。
SAP HANA
SAP HANA に関しては高可用性構成についてホワイトペーパーが出ているので確認したほうがよさそうです。
HANA Replication についてもホワイトペーパーでも解説あると思いますがそれに関連したAWSブログも紹介しておきます。
Oracle
Oracle は先ほど紹介したブログの中で紹介されていますが、ほかに確認しておきたい記事を以下にまとめます。
まずは、Data Guard に関する記事があります。ここまで聞かれるかはちょっとわからないですがリンクを示しておきます。
SAP Blog を見てみるとこのあたりの話も含めて紹介されている記事がありましたので参考までに。最近の記事ですし英語ですがとてもよくまとまっていて必見です。
Microsoft SQL Server
SQL Server ですが高可用性については以下の記事が参考になります。
IBM DB2
IBM DB2 は、「IBM Db2 HADR と Pacemaker を用いた高可用性ガイド」という項目が用意されて解説されています。このあたりを確認しておくのがよさそうです。
SAP ASE
面白いところとして、SAP ASE は、AWS DMS でサポートされています。
まとめ
今回はインスタンスの構成について導入ガイドをもとに紹介し、各データベースの制約事項なども整理してみました。SAP の導入ガイドは読みにくい資料ではあるのですが、構成図は参考になると思いますので、ぜひ、一度見てみてください。
個人的には、このあたりの資料は、AWS のサイトにある資料の方が分かりやすいです。SAP にも、もっと頑張ってもらいたいです。
次回は、移行について考えていきます。
その4の記事は以下です。
変更履歴
2022.01.04 可用性構成に関するデータベースの制約について、タイトルを変更して内容を調整