※この記事は翻訳されたものです。本記事の原文はこちら
SAPのダウンタイムをどのように削減するかを考えることは、ソリューションの初期設計時に検討すべき重要な事柄です。既存のSAP環境に変更を加えることもできますが、ダウンタイムが問題となるような既存の本番環境では、変更がより困難になる可能性があります。
SAP環境には、ASCS（セントラルサービス）、HANA DB、NFSノード、SAPアプリケーションサーバーなど、単一障害点と見なされ得る典型的なコンポーネントがいくつかあります。理想的には、これらは高可用性構成で冗長サーバーを使用して保護するべきです。
SAPのHA/DRが目指すべき到達点
SAPのHA/DRコンポーネントを設計する際の目標
SAPの高可用性/ディザスターリカバリーコンポーネントを設計する際の中核となる目標は次のとおりです。
- ダウンタイムの最小化
- データ損失の排除
- データインテグリティの維持
- 柔軟な構成の実現
今日の最新のクラウド環境では、基盤となるハードウェアのインフラは通常、複数の冗長NIC、冗長ストレージ、ハードウェアのアベイラビリティゾーンを使用することで障害から十分に保護されていますが、それでもSAPアプリケーションが動き、リクエストに応答することを保証するものではありません。
SIOS Protection Suiteのような高可用性ソリューションを使用することで、インテリジェントな高可用性とローカルディスクレプリケーションが導入され、SAPアプリケーションとサービスを継続的に監視・保護し、障害が検出されると自動的に冗長ハードウェアに切り替えることができます。
HAで保護されていないSAP構成の例
ここで、HAで保護されていないSAP構成の簡単な例を考えてみましょう。次の図のようになります（図1）。
図1：HAで保護されていないSAP構成
この環境が、顧客に衣類を販売するために使われているウェブサーバーからのトランザクションを処理するために使用されている場合、SAPは、販売の処理、注文の追跡、在庫の追跡、およびこれらのトランザクションに基づく複数の自動注文などの提供を行います。
ここで、この販売処理環境（図1）がHAなしでクラウドに構成されていると想像してみましょう。なぜそのように構成したかというと、クラウド環境のハードウェアが高度に冗長化されていれば、障害から保護するのに十分だとアーキテクトが考えたためです。HANA DBに問題が発生してシャットダウンした場合、データベースをバックアップして実行するために必要な一般的な手順を見てみましょう。
- HANAがHANAシステム レプリケーションで構成されている場合でも、セカンダリーHANA DBシステムへのフェイルオーバーは自動化されません。そのため、障害が検出され、停止が通知された後、HANAに詳しい人が修正する必要があります。
- 問題が解決するまで、ウェブサーバーからのリアルタイムトランザクションは停止されます。
この小規模な衣料品小売業者がウェブベースの販売で年間約1000万ドルを売り上げているとすると、1時間あたりの売上は、年間を通じて平準化すると約1150ドルに相当します。ピーク時には1時間あたりの売上はさらに多くなります。
IBMのレポートによると、1時間当たりの平均ダウンタイムコストは1万ドルです。
HA/DRを使用したSAP環境の例
図2：HA/DRを使用したSAP環境
もしHAソフトウェアが使われていれば（図2）、HANA DBのフェイルオーバーは自動的に行われ、ウェブサーバーの中断も設定されたタイムアウトの範囲内に収まり、売上が失われることは全くなかったでしょう。アラートも生成され、システムダウン発生時よりもゆっくりと原因を調査・診断できたはずです。
顧客の規模が拡大すると、システムダウンが発生した場合、解決するために数十万ドルの費用がかかり、かなりの人的リソースを費やすことになる可能性が非常に高くなります。
IBMの別のレポートによると、回答者の44％が2カ月に1度、35％が毎月、計画外停止を経験しているとのことです。
まとめ
計画停止自体も潜在的な問題であり、回答者の46％が毎月の計画停止を、29％が毎年の計画停止を報告しています。アプリケーションやサービスをHAソフトウェアで保護すると、保守作業中に稼働中のシステムにサービスを移動させることができるため、このような計画停止を削減することもできます。
お問合せ
高可用性・災害復旧ソリューションの詳細については、サイオステクノロジーの担当者までお問い合わせください。
