目次
はじめに
In Memory Databaseとして有名なSAP社のHANA Databaseは、データベースを複数のHANAシステム間で複製し、データを保護する機能が標準で提供されています。HANA System Replication(HSR)という名称で呼ばれています。他のデータベース OracleではDataGuard、SQL ServerではAlways Onという同様な機能が提供されています。
SAP HANA Database のReplication機能は、他のデータベースとは異なり、データベースの複製に特化しています。他のデータベースでは一般的にプライマリと呼ばれる稼働系のデータベースが停止した場合に、セカンダリと呼ばれる待機系のデータベースをプライマリとして自動的に切り替える機能が提供されています。SAP HANA Databaseではこの部分の機能が提供されておらず、製品単独ではコマンドを使用し手動でデータベースも切り替えを実施するか、別途クラスタ製品とのインテグレーションを実施する必要があります。
今回は、SIOS社のLifeKeeper for Linux v9.3とSAP HANA2.0 SPS03を使って、SAP HANA System Replicationを構築します。サーバ環境としては、Amazon Web Services(AWS)のEC2を使用します。
今回作成するシステムは、次のような構成です。
AWSの２つのAvailability ZoneにそれぞれHANA2.0 SPS3をインストールしたサーバを用意します。各サーバの名称と通常稼働時の役割を次のように設定します。
呼称 ホスト名 IPアドレス/CIDR HANA Replicationの状態
プライマリサーバ SLTYO020 172.31.1.120/20 HANA Primary
セカンダリサーバ SLTYO021 172.31.32.130/20 HANA secondary
この構成でプライマリサーバが停止し使用できなくなった場合、セカンダリサーバを起動する必要があります。クラスタ製品がない場合、手動で対応する必要があります。この場合の流れを下記に記載します。
手動フェイルオーバー方法
HANA Studioで稼働状態を確認した画面です。HANA Replication状態をプライマリサーバから確認したもので、待機系(SECONDARY_HOST)がsltyo021になっており、同期状態(REPLICATION_STATUS)が有効(ACTIVE)であることを確認します。
ここでプライマリサーバに障害が発生し、プライマリサーバが停止したとします。
プライマリサーバが停止したことを監視システム等で確認します。例えば、Zabbixなどの監視ツールからアラートメール等を受けるなどの対応が必要です。
セカンダリサーバにログインし、SAP HANAのコマンドでHANA secondary状態からをHANA primaryに切り替えます。下記はHANA Studioからの切替画面です。これでセカンダリサーバ上のHANA データベースにアクセスできるようになります。
プライマリサーバが復旧し利用可能となった場合、セカンダリサーバ上のHANAがHANA primaryからプライマリサーバ上のHANAにReplicationを行い、データを保護します。下記では、コマンドで再設定を実施しています。
ap1adm@SLTYO020:> hdbnsutil -sr_register --remoteHost=SLTYO021 --remoteInstance=00 --replicationMode=syncmem --operationMode=logreplay --name=new_secondary
adding site ...
nameserver sltyo020:30001 not responding.
collecting information ...
updating local ini files ...
done.
ap1adm@SLTYO020:/usr/sap/AP1/HDB00> HDB start以上のようにクラスタソフトウェアで保護されていないHANAシステムのReplicationは、手動での切り替え操作が必要となります。次に記載するクラスタソフトウェアのLifeKeeperでは、障害発生によりサーバへのアクセスができなくなった場合に備えて、このような処理を自動化することができます。
LifeKeeperによるHANA Databaseの保護
HANA DBとLifeKeeperをインストールした２台のサーバに加えて、Quorum Serverとして一台追加した構成にて検証を行います。
Quorum Serverの詳しい説明は省略致しますが、監視先の相手側サーバとの通信がなくなった場合、一方のサーバが停止しているのか、自サーバのネットワークの問題かを切り分けるため、Quorum Serverとの通信を行うことで多数決で判断するような仕組みになっています。
主な作業工程
構成の整理を事前に行い、設定を進めます。作業工程は次のとおりです。
１．HANAインスタンスの作成
２．LifeKeeper for LinuxとHANA ARKのインストール
３．LifeKeeper for Linuxの初期設定
４．LifeKeeperでのHANA ARKの設定
５．動作確認
工程１．HANAインスタンスの作成
HANA用のEC2インスタンスは、事前に作成しAMI化したものから、プライマリサーバとセカンダリサーバを作成します。他の方法として、CloudFormationを使用するか、手動でインストールを行うことができます。
工程２．LifeKeeper for LinuxとHANA ARKのインストール
SIOS Protection Suite インストレーションガイドに従い、LifeKeeper for Linuxのインストールを行います。
HANA用のLifeKeeperスクリプト(HANA ARK)をインストール手順に従い、実施します。
工程３．LifeKeeper for Linuxの初期設定
インストール直後は、２台のHANAサーバのLifeKeeperは、次のように独立した２台のシステムになっており、初期設定が必要です。通信設定を行い、一つのクラスタとして設定します。
通信設定を行うと、２台のHANAサーバを一つのクラスタとしてまとめることができます。
工程４．LifeKeeperでのHANA ARKの設定
LifeKeeperによるHANA クラスタ化設定は、GUIメニューからウィザートに従い実行できます。
①クラスタリソースの作成をメニューから実行
②各種設定情報の入力を実施
実行サーバ名やLifeKeeperでHANAの起動・停止・監視を行うスクリプト名の登録を行います。下記では、HANAの起動を行うスクリプトの登録を行っています。
リカバリキットの種類選択
登録サーバ設定
起動スクリプト設定
停止スクリプト設定
監視スクリプト設定
ローカルリカバリスクリプト設定
③HANAのレプリケーション設定をクラスタに設定
HANAのレプリケーション設定を登録します。この登録を行うことにより、LifeKeeperがセカンダリサーバからのレプリケーションを設定してくれます。
HANAレプリケーション用の設定
LifeKeeper上の管理名称設定
ファイルオーバ対象サーバ
④HANA DatabaseがLifeKeeperにより2台のサーバでクラスタ化された画面
これで動作確認の準備ができました。
工程５．動作確認
プライマリサーバが停止した場合、HANA primaryが自動的にセカンダリサーバへ切り替わるかを確認します。
①プライマリサーバを停止します。
rebootコマンドの実行でプライマリサーバに障害が発生したことを再現します。
SLTYO020:~ # reboot -f -p
②LifeKeeperによるHANA Databaseの自動切り替え
プライマリサーバからのレスポンスが無いことをLifeKeeperが検知し、セカンダリサーバをHANA primaryに切り替えます。
プライマリサーバ(右側)が停止
セカンダリサーバ(左側)がHANA DatabaseのHANA primaryとして起動
セカンダリサーバ(SLTYO021)からプライマリサーバ(SLTYO020)に自動的にレプリケーションが設定される。
プライマリサーバの停止から、セカンダリサーバのへのファイルオーバ、セカンダリサーバ上のHANAからからプライマリサーバ上のHANAサーバへの逆レプリケーションまでの一連の処理が、LifeKeeperにて実施されます。HANA製品のみでレプリケーションしている場合には、HANAのコマンドを手動で実行する必要がある操作です。LifeKeeperを使用することにより、HANAサーバで障害が発生した場合の運用が簡略化されることがわかります。
最後に
SAP HANAのみをLifeKeeperでクラスタ化しましたが、LifeKeeper for LinuxではSAP HANAだけではなく、SAP ERP等のNetWeaver環境を含めてクラスタ化を行うことも可能です。例えば、下記のような構成もLifeKeeperではウィザードでのクラスタ設定が可能です。このような構成には、SAP ARKやEC2 ARKなどの他のLifeKeeper用のツールが必要となります。このような場合、構成が複雑となるため、設計及びテストが重要となります。
LifeKeeperで設定した場合、次のような状態となります。この場合も複雑なファイルオーバ操作を自動化することができ、障害対応時間を短縮することが可能です。
- カテゴリー
この記事をシェアする
