SAP ERP 6.0の保守が終了となる「SAP2027年問題」をきっかけに、SAP S/4HANAへの移行を検討している企業もいらっしゃるでしょう。
この記事では、SAP S/4HANAへの移行時に考慮しておきたいHANAデータベース冗長構成の選定ポイントについて、デル・テクノロジーズ株式会社の山崎様とサイオステクノロジー株式会社の西下の対談形式でお届けします。
Contents
お話を聞かせてくれた方
デル・テクノロジーズ株式会社
Data Centric Workload and Solutions部
SAP Specialist
山崎 良浩 氏
サイオステクノロジー株式会社
BC&CSサービスライン
プリセールス
西下 容史
SAP HANAへの移行の現状
ーーSAP ERP 6.0ユーザーにとって「2027年問題」という課題がありますが、デル・テクノロジーズ様としてはSAP S/4HANAへの移行が増えている実感はありますか？
山崎：S/4HANAが発表されたのが7年ほど前になりますが、これまではそれほどS/4HANAへの移行は進んでこなかったと感じています。ですが、移行を検討されている方は着実に増えているという印象です。
ただし今すぐの移行ではなく、来年・再来年に移行したいというご相談をいただくケースが増えてきています。
SAP 2027年問題とはSAP ERP 6.0のサポートが2027年に終了するという課題を総称したもの。当初は2025年で終了とされていたが、SAP社により2027年までの延長がアナウンスされた。 サポートが終了になっても継続利用は可能だが、バグ修正やパッチの提供等がなくなるためシステム障害の危険性は高まる。そのため後継バージョンであるSAP S/4HANAへの移行を検討する企業もある。 |
SAP HANA データベースは可用性の確保が重要
ーーS/4HANAではHANA データベースを利用することになりますが、考慮しておくべきことはありますか？
山崎：S/4HANAの前身であるECC（SAP ERP Central Component）の場合、データベースを冗長化することはあまり無かったと思います。しかし、HANAの場合は、冗長化するのが基本となります。
HANAはインメモリーデータベースであるため、冗長化をせず単体で運用している際に障害が起こると復旧に数十分～数時間要し、RTOが致命的に大きくなってしまいます。そのため、SAP HANAには冗長化が必要になります。
ーーインメモリーデータベースは冗長化が必要なのですね。では、HANAの冗長化でよく採用されているのはどのような方式なのでしょうか？
山崎：HANAの冗長化には、HANA System Replication（HSR）を使うケースが圧倒的に多いです。HSR機能ができた当初はログをシッピングするだけではなく、定期的にDBそのものの差分情報も同期させるため動作が重かったのですが、数年前からログシッピングだけで同期が取れるようになり、回線への負荷もそれほど高くないということでHSRが広く使われるようになりました。
HANA System Replication（HSR）とはSAP HANA データベースに含まれる、データベースを複製する機能。データの複製を行うのみで、障害を検知したり待機系のデータベースに切り替えたりする機能は含まれない。 |
vSphere HAによるSAP HANA冗長化の注意点
ーーHSRはデータを複製する機能とのことですが、vSphere環境の場合vSphere HAという機能があります。vSphere HAを使ったHANAの冗長化で気を付ける点はありますか？
山崎：HANAの冗長化でvSphere HAを使うケースはありますが、このときに気を付けることが2点あります。
まずは、HANAの状態監視と組み合わせるのが難しいという点です。vSphere HAがハードウェアの障害を検知して切り替えるのは問題ありませんが、HANAに問題が発生してそれをきっかけに切り替えるのが大変難しいと思っています。
そしてもう一点、HANAはインメモリーのデータベースですから、例えば1TB（テラ・バイト）のHANAのサーバーをvSphere HAで再起動しようとすると、起動やログインそのものは比較的速くできますが、1テラのメモリーをロードするのに20～30分かかってしまいます。
そのため、vSphere HAを使ってパフォーマンスが出てきちんと動くようになるまでに時間がかかる点もネックになります。
ただ、vSphere HAを使うことには価格的メリットもありますので全く使われていないというわけではありませんが、この2点の理由からvSphere HAはHANAの冗長化での利用は多くないのが現状です。
OSSか商用か、SAP HANA DB冗長構成選定のポイント
ーーより速い時間で切り替えたいというお客様はまた別の選択肢を検討する必要がありそうですね。HANA System Replicationと組み合わされるクラスタリングソフトにはどんなものがありますか？
山崎：オープンソースをベースにしたものと商用のクラスタリングソフトがあります。
当社で取り扱っているものでは、オープンソースベースでは、レッドハット社のRed Hat Enterprise Linux High Availability Add-On（RHEL HA Add-On）やSUSE社のSUSE Linux Enterprise Server High Availability Extension（SLES HAE）、商用ですとサイオステクノロジー社のLifeKeeper、この3つがあります。
代表的なクラスタリングソフト
| 製品名 |
OSSベース | RHEL HA Add-On（レッドハット）、 SLES HAE（SUSE） |
商用 | LifeKeeper（サイオステクノロジー） |
ーー代表的なクラスタリングソフトを3つ挙げていただきましたが、これらを使った一般的な構成例を教えてください。
山崎：先ほど挙げた3つのクラスタリングソフトの内、RHEL HA Add-OnとSLES HAEにはどちらもオープンソースのクラスタリングソフトPacemakerとCorosyncが含まれています。Pacemakerが実際の切り替えを行い、Corosyncはサーバーの間で情報を共有するという役割です。
またPacemakerに含まれる機能としてSTONITH Block Deviceというものがあります。
これはノードフェンシングを行う機能で、障害が起きたサーバーを切り離すという役割です。
これらは障害が起きたらサーバーを切り替えたりする役割で、障害そのものを検知する機能は含まれていません。
HANAの場合、検知するためのコンポーネントとして、SAP host agent、SAPHana resource agent、SAPHana Topology resource agent、HANA python hookなどを使用します。
これらによって、サーバーやHANAの状態を検知してCorosyncによって情報を伝えて、Pacemakerによって実際の切り替えが行われることになります。
＜SUSE Linux Enterprise for SAP Applicationsの標準パッケージでのクラスタ構成例＞
出典：SAP HANA System Replication Scale-Up – Performance Optimized Scenario
RHEL HA Add-OnもSLES HAEもパッケージ化されていて、導入スクリプトが提供されていますので導入は比較的簡単ではあります。
ただ運用を考えると、クラスター環境はテストを定期的に行って、きちんと動作するということを確認しないといざ障害が発生した際に切り替えが上手くいかないということもあり、大きな問題になります。
そのためテストを実施して切り替え切り戻し等が行えることが重要で、OSSベースでは、コンポーネントが多い分熟練した運用者は必須になるといえます。
ーー機能だけでなく人材面の考慮も必要ということですね。ではOSS以外の選択肢として、商用のクラスタリングソフトを使う場合の構成例についても教えてください。
山崎：OSS以外のクラスタリングソフトで提案しているものとして、サイオステクノロジー社のLifeKeeperがあります。こちらの製品にはSAP HANA Recovery Kitが付属されていて導入は簡単ですし、LifeKeeper GUIによりモニタリングも簡単という特徴があり、提案に使っています。
ーーHANAの冗長化にLifeKeeperを使う場合の構成例を教えてください。
西下：先ほど山崎様からご紹介があった通り、LifeKeeperをHANAの環境で使うには、LifeKeeperのほかにSAP HANA Recovery Kitをご利用いただくことになります。これはSAP向けのSuite製品に含まれています。
LifeKeeperの機能は大まかに2つあります。一つ目はサーバーが正常に動いているかを確認する「サーバーの死活監視」、二つ目は監視対象のアプリケーションが正常に動作しているかを確認する「リソース監視」です。
稼働系のサーバーでは、これらの監視が並行して動作しており、障害を検知した際に、待機系サーバーに自動的に「フェイルオーバー」しサービスを継続させます。
HANAの冗長化では、Recovery KitがHANAの状態を監視し異常を検知することで待機系のサーバーに自動的にフェイルオーバーします。
またLifeKeeperを使う場合でも、冒頭で山崎様がおっしゃっていたHSRを使ってクラスターノード間のデータの同期を行います。HSR単体では障害の検知や切り替えまでは行えませんが、これらの機能により障害時自動復旧し、切り替わった先でも最新のデータで継続運用が可能になります。なおHANA Recovery KitからHSRの制御を行うため、スクリプトの開発は必要ありません。
＜LifeKeeperを使ったHANAの冗長化概念図＞
ーーOSSと商用ソフトウェアという2つの選択肢をご紹介いただきましたが、それぞれの特徴について教えてください。
山崎：RHEL HA Add-Onや SLES HAEのようなOSSベースのパッケージソフト、もしくはPacemaker、CorosyncといったOSSの組み合わせの場合、OSに付属されているためコストは安く済むものの、どうしても構成要素が多くなってしまいます。そうするとある程度技術力のあるエンジニアがいないと運用が難しいという点があります。
これに対して、サイオステクノロジー社のLifeKeeperはGUIで一括管理できますので比較的簡単に運用できます。この点は弊社が提案する際の差別化ポイントになります。
西下：これまでSAP案件で多くのコンサルベンダー様からいただいたご意見にはなりますが、OSSとLifeKeeperとの違いは大きく2つございます。一つは商用ソフトならではのサポートの面、もう一つは使い勝手の面です。
一つ目のサポート面について、OSSベースのパッケージメーカー様のサポートに問い合わせても期待した回答が得られなくて苦労したといったお話を伺うこともあります。こういった経験のある方はサポートが手厚い商用のソフトウェアを選ばれる傾向があるようです。
二つ目の使い勝手について、LifeKeeperはGUI画面のウィザード形式で設定ができるという点があります。また、LifeKeeperだけの特徴としては先にご紹介した通り、HANA専用のRecovery Kitを使ってHANAの冗長化のためのスクリプトを個別に書かずに構築することができ工数削減になります。
運用時の使い勝手としてもう一つ、障害が起きてフェイルオーバーした後の切り戻し（フェールバック）もGUI上でできるという点が挙げられます。これに関しても、OSSベースのクラスタ製品を使ったことがある方から「切り替えはいいけれど、HSRのコマンドの知識がないと切り戻しが難しい」というお話を伺います。
同様に「自分はわかるからいいけれど、運用を他社にお任せする場合や社内の別部署にお願いする場合に難点になる」というお話もこれまで何度か伺いました。
どの企業もITエンジニア不足ですから、構築・運用が簡単で属人化を減らしたいお客様は商用製品を検討されるのもよいと思います。
まとめ
- SAP S/4HANAを利用する場合、インメモリーデータベースであるHANAの冗長化が必要
- HANAのデータレプリケーション機能であるHSRだけでは障害対策として不十分
- クラスタリングソフトはOSSベースか商用製品か2つの選択肢がある
- OSSベースも商用製品もメリット・デメリットがある
- LifeKeeperのメリットは構築・運用時の工数削減、属人化防止
関連情報
デル・テクノロジーズ様
SAPのお客様導入事例などをご覧いただけます。
LifeKeeper on SAPの情報はこちら。
本記事ではご紹介できなかった、SAP Netweaverの冗長構成についても解説しています。
SAP関連記事
