SAP HANAの3ノード以上の構成をサポート
SAP HANAの冗長化構成を組む際に、待機系を複数にする構成のサポートを開始しました。
これまでは稼働系/待機系の2ノード構成しかできませんでしたが、3ノード以上の構成が可能になります。
これによって待機系ノードを複数の場所に置くことができるようになり、災害復旧(DR)対策をより盤石にすることができます。
LifeKeeper for Linux v9.7 v9.6.2 v9.6.1 v9.6 v9.5.2 v9.5 v9.4.1 v9.4 v9.3 v9.2 v9.1 v9.0
LifeKeeper for Windows v8.9.2 v8.9.1 v8.9.0 v8.8.0
Windows環境で、保護するアプリケーションの設定は3ステップで完了、多様なアプリケーションを簡単に保護することが可能になりました。
LifeKeeperは、オプション製品の「ARK」を使用することで、スクリプトの作成なしにHAクラスターシステムを構築できることが特徴です。従来はARKが用意されていないアプリケーションを保護対象とする場合には「GenericARK」というフレームワークを用いて保護対象とすることができました。但し、それにはスクリプトの開発が必要で、導入のハードルとなるケースがありました。
LifeKeeper for Windows v8.9.2以降では、「Quick Service Protection」を利用することで、GUI上での簡単な操作で、保護対象に設定できるアプリケーションが拡大しました。
※専用ARKが用意されているアプリケーションは対象外となります。Linux版では、LifeKeeper for Linux v9.1以降で利用可能となっています。
Protection Suite for Windowsにて、OCIがサポートされました。ご利用に際しては、Generic ARK for Load Balancer probe reply という、Load Balancerへの応答を行うためのスクリプトが必要となります。
スクリプトはLifeKeeper/DataKeeper User Portalサイトよりご入手ください。
DataKeeperを利用しない共有ストレージ構成であってもDataKeeperのインストールが必要ですが、v8.9.2よりLifeKeeperとDataKeeperのインストールを
統合した形で実行できるようになりました。これよりインストール作業がさらに簡易になります。
SAP HANAの冗長化構成を組む際に、待機系を複数にする構成のサポートを開始しました。
これまでは稼働系/待機系の2ノード構成しかできませんでしたが、3ノード以上の構成が可能になります。
これによって待機系ノードを複数の場所に置くことができるようになり、災害復旧(DR)対策をより盤石にすることができます。
2022年5月にリリースされたRHEL9のサポートを開始しました。
RHEL9では、ハードウェアのパフォーマンスをより引き出せる改善が行われているほか、企業で重要となるセキュリティやガバナンスを向上させる機能が追加されています。
今回サポートを開始したので、冗長化構成を組む際にはぜひご検討ください。
そのほかにもSLES 15 SP4、Miracle Linux 8.6 のサポートを開始しました。
DataKeeperのリソース作成時やミラーサイズの変更時に、問題となる構成をユーザーが選択した場合に、それを検知し警告します。設定の不備によるフェイルオーバーの失敗リスクを低減できます。
AWS上でリージョンをまたいだHA構成がサポートされました。東京リージョンと大阪リージョンをまたいだHAクラスタ構成が可能となり、大規模災害やリージョン全体に及ぶシステム障害の影響からシステムを守ることができます。Recovery Kit for Route 53が必要です。
また、リージョン内のアヴェイラビリティゾーンをまたいだ構成に付加して、別リージョンにStandbyノードをもう1つ配置する、3重化構成もサポートしております。詳細なシステム構成やサポート条件についてはお問い合わせください。
これまでWindows版では、特定のノード情報に紐づいた"ノードロックライセンス"を提供してきました。v8.9.1からは、特定のノード情報に依存しない、"非ノードロックライセンス"として提供します。これによりハードウェア情報が固定されないクラウド上でも、ハードウェア故障等が発生した場合でも、ライセンスの再取得と再設定が不要となります。
Azure上で、Azure共有ディスクを可用性ゾーン内の共有ストレージとした構成をサポートしました。
これまではデータレプリケーション構成しかとれませんでしたが、LifeKeeperによるAzure上でのクラスタ構成の選択肢が広がりました。
共有ディスク構成+Quorum Witness Kit(Any Storage構成)利用時に、待機ノードからディスクへのアクセスを抑止する機能を実装しました。
これにより、SCSI Reservationを利用できない構成でも、意図しないアクセスによるデータ破損を防ぐことができるようになりました。
Any Storage構成とは何かについては、こちらの記事をご覧ください。
これまでWebサイトでGenericスクリプトとして配布していた「GenLB」(Generic ARK for Load Balancer probe reply)が、本リリースから製品純正のARKとして製品に同梱されるようになりました。
これにより、Microsoft AzureやGoogle Cloud™ 環境でLoad Balancerの負荷分散対象インスタンスへのヘルスチェックプローブを待ち受けて応答する仕組みを、ユーザーが簡単に使用できるようになります。
「GenLB」について詳しく知りたい方はこちらをご覧ください!
Google Cloud上でロードバランサー構成を採用している環境で、LifeKeeperが動作するための Gen LB ARK の提供を開始します。Google Cloud 環境では、クライアントからHAクラスターのActiveノードへのルーティング制御に Load Balancer のヘルスチェックを利用します。しかし、アプリケーション側のポートに対してヘルスチェックを行うと、アプリケーション側でヘルスチェックに応答するポートが必要になり、ポートの確保がアプリケーション依存になります。Gen LB ARK を利用すると、LifeKeeper 側でヘルスチェックに応答するポートを確保できるため、アプリケーションに依存せずに Google Cloud 上のHA構成を採ることが可能です。Gen LB ARK は、こちらから入手いただけます。
本機能を利用することにより、DataKeeper構成におけるスプリットブレイン状況のリスクを大幅に低減できるようになります。詳細はドキュメントサイトをご参照ください。
Recovery Kit for Oracle Cloud Infrastructureを利用することで、Oracle Cloud Infrastractureの仮想マシンのプライベートIPをLifeKeeperで制御できるようになります。LifeKeeperで提供される多くのARKも併せてサポートされます。
UDPが無効になっているNFSを保護する際に、「NFS_RPC_PROTOCOL=tcp」を設定する必要がなくなりました。
LifeKeeper固有のcritical_nfs_mounts_<tag>ファイルの使用をサポートするようになりました。これにより、特定のサーバー上の特定のSAPリソースに対してこのファイルに追加されたNFSマウントエントリ(たとえば、/ sapmnt / <SID> NFS共有用)は、リソー
スがインサービスになる前にマウントされます。
LifeKeeper for Linux v9.6.1のオンラインドキュメントを見る
Azure Fence Agentの提供する、STONITHデバイスをLifeKeeperで使用できるようになりました。従来より Azure 上のスプリットブレイン対策として推奨していた、Quorum/Witness と組み合わせることもでき、より強固な対策とすることも可能となります。詳細はこちらをご参照ください。
NFS ARKの起動・監視処理を見直し、動作を改善しました。詳しくは、オンラインドキュメントをご参照ください。
LifeKeeper for Linux v9.6のオンラインドキュメントを見る
v9.5.0から提供してきた機能強化されたCLI機能ですが、本バージョンではこれまでご利用いただけなかったSAPやWebsphere MQなど、複数のRecovery Kitにおいて新たに拡張されたCLIが利用できるようになりました。
CLIの特徴とGUIとの差異について(1:11)※2022年9月時点
CLIの詳細は、オンラインドキュメント の LifeKeeper for Linux テクニカルドキュメンテーション > コマンドラインインターフェイス > LKCLIガイド をご参照ください。
v9.4から提供してきたスタンバイノード監視機能ですが、本バージョンではこれまでご利用可能だったDMMP RKに加えて、NASやマルチパス RKにおいても利用できるようになりました。詳しくは、オンラインドキュメントをご参照ください。
LifeKeeper for Linux v9.5.2オンラインドキュメントを見る
これまでGeneric ARK用のスクリプトを提供しておりましたが、インストールと設定に関わる手間を削減し、より分かりやすいインターフェースをご提供できるApplication RecoveryKit(ARK)として提供できるようになりました。
※Single Server Protectionを除く
Azure上でのAvailability Zone(AZ)をまたいだHAクラスター構成に対応しました。 これにより、万一の広域障害時にも別のAZへ自動的に切り替えることで運用を継続し、障害のダメージを最小限に抑えることが可能になります。
※Single Server Protectionはサポート対象外となります
LifeKeeperは以前より、充実したGUIを提供してまいりましたが、コマンドラインによるシステム構築や運用には完全には対応できておりませんでした。そのような状況を改善すべく、LifeKeeper for Linux 9.5.0よりCLIによる構築、運用をサポートするための拡張を行いました。
今回の実装では主に以下3つを実現します。
CLIによる構築、運用等の操作 | コミュニケーションパスの作成、削除 リソースの作成、拡張、削除 依存関係の作成、削除 DataKeeperのミラーの停止、再開 |
---|---|
CLIによるパラメータの変更 | スイッチバックの設定 フェイルオーバのON/OFF 仮想IPリソースのアドレスをソースアドレスとして利用するかの設定 |
既存システムのクローン作成 | 作成済みのLifeKeeperクラスタからコミュニケーションパス及びリソース情報をexportし、別のLifeKeeperクラスタにインポートする。既存システムと同じ構成、設定のクローンを作成することが可能です。 |
※Single Server Protectionはサポート対象外となります
LifeKeeperからPowerShellとPowerCLIを用いてVMwareハイパーバイザを直接制御することにより、VMwareで作成された仮想ハードディスクをLifeKeeperの共有ストレージとして安全に使用できるVMDK ARKを実装しました。
これにより、VMDKによる共有ディスク構成でも待機系からのアクセス制限を行い、quorum/witness モードで必要な第三のサーバーを立てることなく、SCSI Reservationと同じレベルの堅牢度を実現する事が可能となりました。VMwareハイパーバイザを制御するために必要なソフトウェアは全てVMDK ARKに同梱されており、LifeKeeper側で設定を行うためお客様でソフトウェアのインストールと設定を行う必要はございません。
LifeKeeper for Linuxでは従来、それぞれの共有ストレージとLifeKeeperの組み合わせでテストを行い、正常に動作することが確認できたものを「認定済ストレージ」としてサポトしています。今後はそれに加え、未認定のストレージでも、LifeKeeper の I/O Fencing機能を組み合わせて使用することで、サポートが受けられるようになりました。
通常HAクラスターソフトウェアは常時「監視」を行い、監視の中で障害を検知するとフェイルオーバー(ActiveノードからStandbyノードへの切り替え)などの復旧処理が行われるように作られています。LifeKeeper for Linux v9.4では新たにスタンバイノードの監視機能が追加されました。これによりより安全なフェイルオーバーが可能になります。
すでに取得していた、SAP Netweaver 7.xにおける認定(NW-HA-CLU 750)に加え、新たにS/4HANAにおけるHAクラスターの認定(S/4-HA-CLU-1.0)を取得しました。
Oracle Databaseの最新バージョンである、Oracle Database 19cのサポートが追加されました。19cでは、従来のStandard Edition 2ライセンスでのRAC構成がサポートされない事がOracle社の管理構成ガイドに記載されております。
当社ではこれまでOracle RACを利用されていたお客様が、可用性を落とすことなく19cを利用できるソリューションやOracle DBMSに代わるデータベースのご紹介も用意しております。
従来のQuorum Witness 機能に、storageモードが追加されました。
これにより、さまざまな環境下に於いて、共有ストレージを介してQuorum/Witness判定を実施することが出来るようになりました。
スプリッドブレインの発生リスクを大幅に軽減しながら、高い信頼度でシステムのフェールオーバーを実施することが可能となります。
現在利用可能なQuorumモードは以下の通りです。
Quorumモード | モード別概要説明 |
---|---|
majority(default) | コミュニケーションパスを通じて疎通確認を行い、Quorum チェックを行います。 クラスター内の過半数のノードと疎通ができることで、Quorum チェック成功と判断します。 本モードは3ノード以上のクラスターで動作可能です。2ノード構成の場合は、Witness 専用のノードを追加する必要があります。 |
tcp_remote | コミュニケーションパスから独立したホストに対して、指定されたポート上の TCP/IP サービスに接続確認を行い、Quorum チェックを行います。 指定されたホストの過半数に接続できることで、Quorum チェック成功と判断します。 別途、接続確認用のホストが必要です。 |
storage | 共有ストレージを Witness デバイスとして用いる Quorum モードです。 クラスター内のすべてのノードからアクセスできる共有ストレージを用いた合意システムで、共有ストレージを介してノードの情報交換を行います。 共有ストレージにアクセスできることで、Quorum チェック成功と判断します。 本モードは2ノードのクラスターから動作可能で、最大4ノードまでサポートされます。別途、共有ストレージが必要です。 なお、Quorum モードに storage を選んだ場合、Witness モードについても storage を選択しなければなりません。 |
none/off | Quorum チェックが無効になっています。この設定では、常に Quorum チェック成功と判断されます。 |
注)storageモードは、v9.3以降のバージョンをご使用時に利用可能となります。
なお、storageモード利用時に、利用可能な共有ストレージは以下のとおりです。
ストレージ種別 | 利用可能な共有ストレージ |
---|---|
block | 物理ストレージ、RDM(物理互換)、iSCSI(VM内イニシエーター)、VMDK |
file | NFS |
aws_s3 | Amazon Simple Storage Service (S3) |
LifeKeeper for Linux v9.2リリース時には、Nutanix社のハイパーバイザーであるAcropolis Hypervisor(AHV)を
Single Server Protectionのサポート対象に加えましたが、v9.2.1からは、LifeKeeperもAHV上でのサポート対象に加わりました。
現在利用可能な組み合わせは以下の通りです。
HAソフトウエア | Hypervisor | 仮想共有ディスク | 管理ツール | 特記事項 |
---|---|---|---|---|
Single Server Protection for Linux | AHV | - | Prism | |
LifeKeeper for Linux | AHV | ABS | Prism | Quorum/Witness Kitの利用が必須 |
LifeKeeper for Linux | ESXi | VMDK | vCenter | Quorum/Witness Kitの利用が必須 |
LifeKeeper for Linux | ESXi | ABS | Prism & vCenter | Quorum/Witness Kitの利用が必須 |
LifeKeeperは「Recovery Kit for EC2™」を提供しており、これまでも以下A、Bの2つの接続形態をサポートしておりました。
A及びBの接続形態の詳細は、「Recovery Kit for EC2™管理ガイド」をご参照ください。
LifeKeeper for Linux v9.2からは、上記のA、B二つのパターンに加えて、「Recovery Kit for Route 53™ 」を利用して以下の2つの接続形態もサポートいたします。
参考情報:AWS Direct Connectを使った上記以外のパターンでの検証例 株式会社クラスメソッド様には、AWS Direct Connectを使用し、EC2上のHA構成の「サイボウズ ガルーン」をオンプレ環境から利用するケースの検証結果をブログ記事として公開を頂いております。 |
Hyper Converged Infrastructureは次世代の仮想基盤として注目を集め、その用途も企業の基幹システムやデータベースへと広がっています。この流れを受け、
LifeKeeperは、オプション製品の「ARK」(Application Recovery Kit)を使用することにより、ハード障害、OS障害、そして主要なミドルウエアやアプリケーションの障害からの自動復旧が可能なHAシステムを、簡単に短期間で構築できることが大きな特徴でした。
専用のARKが用意されていないアプリケーションを保護対象とする場合にも「GenericARK」と呼ばれるフレームワークが用意されており、任意のアプリケーションをLifeKeeperの保護対象とすることが可能です。但し、この「GenericARK」を使用するにはアプリケーションの起動、停止、監視を司るスクリプトの開発が必要となり、LifeKeeper導入の際のハードルとなるケースがありました。
LifeKeeper for Linux v9.1からは、新機能"Quick Service Protection"を利用することにより、GUI上での簡単な設定のみでLinux上の一般的なサービスをLifeKeeperの保護対象とすることが可能となりました。
※専用ARKが用意されているアプリケーションは対象外となります。
いくつかの簡単な選択と入力のみでLifeKeeper上に保護対象となるリソースが完成!
従来のLifeKeeperでは、複数のクラスターシステムの状態を把握するには、それぞれのクラスター毎にGUIを立ち上げて個別に確認を行う必要がありました。
"LifeKeeper API for Monitoring"は、外部システムからLifeKeeperの状態を参照することが可能なAPIです。各種統合運用管理ツールからこのAPIを呼び出すことにより、それらのツールの画面上でLifeKeeper を含めたシステム全体の一元的なモニタリングが可能となり、特にクラウド環境や大規模システムにおける運用性の向上に貢献します。
ITインフラにおける構成管理、展開作業を自動化するツールである“Chef”による自動構成を実現するための機能を実装しました。これによりサーバー環境を構築する際のスピードアップを実現し、同じ構成のサーバーを短時間で大量に複製することが可能となるほか、人為的な作業ミスを排除することが可能となります。
※Chefのサポートはv9.5.0までです。ご注意ください。
多くのインフラ構築・運用を行うエンジニアの利便性と作業効率向上が実現されます。
vSphereの各種機能とLifeKeeperの連携や共存により、アプリケーションを含めたトータルなシステムとして、高い可用性が実現されます。
インフラにおける構成管理、展開作業を自動化するツール。Rubyでプログラミングをするように、インフラの構成管理をコードによって行える。
Chef Clientで実際に設定されるインフラの構成情報を書いたプログラムのことです。Rubyの文法をベースにしてChefのDSL(Chef固有の命令)を使って記述します。たとえば、ミドルウエアをインストールして、サービスを起動するなど、従来、対象の端末にログインしてコマンド操作/各種スクリプトで行っていた処理などを、すべてRubyのコードで書きます。
作成したレシピを実行するために必要になる設定ファイルのひな形やパラメータ一覧などをまとめたものが、CookBookです。CookBookの中には、Recipeも含まれます。
サーバー環境を構築する際の圧倒的なスピードアップが実現します。
これまでのやり方とは比べ物にならないほどスピーディーにインストレーション/コンフィギュレーションが可能となり、省力化が可能
再現性
同じ環境のサーバーを短時間で大量に複製可能
確実性と正確性
自動化により、人為的な作業ミスを排除することができる
設定ミスによる様々なトラブル(システムダウンを含む)を防止