SIOS HANAマルチターゲット・オートメーションが期待以上である理由

    ※この記事は翻訳されたものです。本記事の原文はこちら
    (寄稿:カスタマーエクスペリエンス担当バイスプレジデント Cassius Rhue)

    ラリー(仮名)はSIOSのお客様で、高可用性とディザスターリカバリー対応(HA/DR)を実現するために、過去にレプリケーションソリューションを導入していました。ラリーがSIOSのLifeKeeperとDataKeeperレプリケーションを使用して、Linux用の2ノードレプリケーションソリューションをテストするPoCを実施した際、彼の最優先事項はデータインテグリティの保護でした。ラリーのPoCテストのリストには、データベースの起動/停止、バックアップノードへのデータベースの移行、メンテナンス作業、サーバーのフェイルオーバーなど、標準的な項目が含まれていました。ラリーは、アプリケーション、データベース、ストレージ、サービスをあるサーバーから別のサーバーへ速やかに切り替えること(グレースフルマイグレーション)と、高速にフェイルオーバーすること(突然の強制マイグレーション)の両方が可能なソリューションを強く求めていました。しかし、彼はさらに力強く、そのような活動によってデータが失われることがあってはならないと主張しました。

    スプリットブレインを回避してデータインテグリティを保護する

    これらの標準的なテストに加え、ラリーは「スプリットブレイン」シナリオを強制的に試行するための特別なテストを追加しました。スプリットブレインとは、クラスターのメンバーが互いに通信できないにもかかわらず、動いていて操作可能な状態にあり、その後共通のリソースを同時に所有する場合に発生する状況で、2人のバスの運転手がハンドルの取り合いをしているようなものです。スプリットブレインはその破壊的な性質により、データ損失やデータ破損を引き起こす可能性があり、どちらのノードがアクティブな状態を維持し(バスを運転し)、どちらのノードがディスクへの書き込みを停止すべきかを決定するメカニズムを使用することで回避するのがベストです。

    クォーラムやクォーラム+ウィットネス機能を導入しているクラスターでは、スプリットブレインが起こるのは比較的まれですが、クラスター構成にノードが追加されるたびに、スプリットブレイン解決の難易度は指数関数的に上昇します。3つ以上のノードを持つマルチターゲット構成では、クラスタリングソフトウェアは正しいノードへのフェイルオーバーをオーケストレーションするだけでなく、ノード間で適切な調整を行いながらDR保護を維持するために、新しいプライマリーノードから第3のノードへのレプリケーションを自動的に切り替えなければなりません。他のクラスタリングソリューションでは、このような複雑な動作を手動でスクリプト化し、フェイルオーバー時に手動で更新し、正常なオペレーションに戻す必要があります。

    SIOS LifeKeeperとSAP HANA Application Recovery Kit(ARK)の機能と改良のため、ラリーはスプリットブレインのシナリオを試すのに苦労しました。しかし、最終的にスプリットブレインについて考察し、データを保護するためのSIOS製品のロジックを理解することは、とても有益でした。ラリーは、SIOSのクラスタリングソフトウェアが提供するデータ保護設計が高度に洗練されていることを知り、SIOS LifeKeeperを選択したのです。

    SIOS HANAマルチターゲット・オートメーションの強み

    ラリーのような状況は、SIOSのHANAマルチターゲット・オートメーションが想像以上に優れている9つの理由のうちの1つに過ぎません。ここで、その9つの理由をご紹介します。

    1. 強化された保護

    SIOSのソリューションは、マルチターゲットでのHANAデータベースリソースの保護を簡素化します。ウィザードベースのオプションは、現在の構成を素早く検出し、LifeKeeper構成に情報を正確に追加します。エラーの検出は簡潔でありながら有益で、ユーザーが問題を解決して時間を節約するのに役立ちます。

    2. 合理化された管理

    ナタリー(仮名)はHANAのマルチノード構成を担当していました。サーバーに障害が発生したり、メンテナンスが必要になったりすると、ナタリーはさまざまなスクリプトやツールを活用して必要なアクションを実行していましたが、拡張性がありませんでした。そこでSIOS LifeKeeperを導入すると、ナタリーとチームは、HANAの停止や再起動、HANAシステムのレプリケーションなど、すべてのコアタスクを実行するためのシンプルなUIを手に入れました。さらに、災害が発生した場合、チームは最新の手順書を探したり、適切なスクリプトのコピーを探したり、午前2時にナタリーに電話したりする代わりに、単一の簡素化されたSIOS UIを使用できるようになりました。

    3. 簡素化されたモニタリング

    SIOSのUIでの直感的なステータスレポートにより、チームはレプリケーションのステータスを素早く判断できるようになりました。監視ボードや自作スクリプトの寄せ集めではなく、単一のツールを使用することで、管理を簡素化し、時間を節約できます。

    4. 自動化されたリカバリー

    HANA HSRソリューションの中には、これら2つのノード間でHANAレプリケーションのフェイルオーバーを実行できるものもあります。しかし多くの場合、管理者はシステムのフェイルオーバー後にレプリケーションを再登録しなければなりません。3つ以上のノードの場合、管理者は3番目または4番目のノードで登録を更新する方法を理解できるでしょうか? syncとasyncを適切に使い分けられるでしょうか?マルチターゲットレプリケーションで3ノード、あるいは4ノードを扱うことができるSIOSのソリューションは、障害発生後のターゲットノードの登録をシームレスに自動化します。

    5. 柔軟性と拡張性

    HANAクラスターを2ノード、3ノード、4ノードの組み合わせで保護できるため、お客様は可用性とディザスターリカバリーの両方のレベルを柔軟に引き上げることができます。クォーラムを使用する2ノードのお客様は、災害に対する可用性保護が得られ、HANAの「Takeover with Handshake」機能を活用して、ほぼゼロのダウンタイムでメンテナンス活動を処理することができます。3ノードを導入しているお客様は、非同期レプリケーションを備えた3番目のノードを別のデータセンターまたはリージョンにデプロイすることで、ディザスターリカバリー機能を強化することができます。さらに、3ノードを導入しているお客様は、ストレージクォーラムを備えた4番目のノードを導入することで、データセンター全体で障害が発生した場合にも、高可用性とディザスターリカバリーを実現することができます。

    6. データ保護

    ラリーの問題に話を戻しましょう。彼はプライマリーノードAでHANAを実行し、ノードBとCへのマルチターゲットレプリケーションを行っていました。手動による作業が失敗に終わったらどうなるでしょうか?どのノードがプライマリーだったのでしょうか?ノードAがクラッシュしたとき、データは同期していましたか? 間違ったノードを起動しないようにするにはどうすればいいでしょうか?マルチターゲットHSR構成で3つ以上のノードをサポートすることに加え、新しいHANA ARKには、災害やスプリットブレインが発生した場合に役立つ管理ツールが追加されています。

    HANA_DATA_OUT_OF_SYNC_<tag>フラグは、ユーザーが誤って間違ったシステムにデータベースをリストアしてしまうことを防ぎます。また、HANA_LAST_OWNER_<tag>フラグにより、管理者はスタンバイノードが同期していない場合に、プライマリーシステムでいつアクションが実行されたかを把握できます。このフラグは管理者に、このノードが最後のオーナーであり、レプリケーションが再開されるべき場所であることを伝えます。

    HANA_DATA_CONSISTENCY_UNKNOWN_<tag>は、スタンバイノード間のすべての通信が一時的に失われ、その後復元された際に、SIOSがレプリケーションを自動的に解決し、復元するのに役立ちます。ベストプラクティス、クォーラムの展開、適切なチューニングと併せて使用すれば、ラリーのような管理者はスプリットブレインを回避し、スプリットブレインが発生した場合でも安全に復旧できるようになります。

    7. レポーティング、パフォーマンス、ディザスターリカバリー

    もちろん、マルチターゲットの真のメリットは、追加のノードと、これらのノードによって使えるようになる機能にあります。同じデータセンターで3つのノードを使用することで、DRサイトのノードを維持しながら、logreplay_readaccessパラメーターを介してより多くのレポートを作成できる可能性が広がります。さらに、SIOSはさまざまなレプリケーションモードをサポートしているため、ユーザーは同期ノードと非同期ノードを使用してデータセンター(またはリージョン)全体のパフォーマンスを向上させることができます。

    8. 継続的なテスト

    皆さんのチームは、自作のスクリプトをどのくらいの頻度でテストしていますか?設定、管理、夜間のシナリオに関して、手順書をどれくらいの頻度でレビューしていますか?HANAマルチターゲットソリューションは、SIOSのエンジニア、QA、カスタマーエクスペリエンスの専門家によって継続的にテストされているだけでなく、リリースとアップデートのたびに、HANAのフェイルオーバーとリカバリーのプロセスについてもテストと検証が続けられています。

    9. 豊富なドキュメント

    少し前に、私たちのチームは、クラスター管理であるお客様と一緒に仕事をしました。そのお客様の前任者は自社の環境について非常に知識が豊富でしたが、スタッフの昇進と組織再編により、多くのIT担当者はほとんど知らないシステムを担当することになりました。運用手順書や構成のドキュメントについて尋ねても、お客様は以前のチームや以前の管理者が作成した資料を見つけることができませんでした。
    SIOSのマルチターゲットソリューションには、堅牢な自動化、管理、監視、リカバリー、データ保護に加え、LifeKeeperによって制御されるHANAマルチターゲットシステムの実装、運用、管理について、詳細で使いやすいドキュメントが含まれています。

    さいごに

    SIOSのトータルソリューションを活用することで、お客様は一貫性のあるタイムリーな監視と検知、高速で信頼性の高い効率的なリカバリー、高可用性とディザスターリカバリー保護を保証する、完全に自動化されたソリューションのメリットを享受できます。SAP HANAマルチターゲット・オートメーションに関する詳細については、サイオスの担当者にお問い合わせください。

    関連記事

    SNSでもご購読できます。