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