1. TOP
  2. LifeKeeper/DataKeeper
  3. LifeKeeperの新機能

LifeKeeperの新機能

LifeKeeper for Linux　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.8.0

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が利用できるようになりました。詳しくは、オンラインドキュメントをご参照ください。

スタンバイノード監視機能の強化

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はサポート対象外となります

LifeKeeper_img_200423.png

詳細はこちら

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側で設定を行うためお客様でソフトウェアのインストールと設定を行う必要はございません。

img-vmdk.png

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では新たにスタンバイノードの監視機能が追加されました。これによりより安全なフェイルオーバーが可能になります。

詳細はこちら

imgactive-monitor.png

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）を取得しました。

img-sap-certified-s4hana.png

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上のクラスターノードへの接続

img_spec-ec21.png

B：同一VPC(Virtual Provate Cloud)内に存在するクラスターシステムへの接続

img_spec-ec22.png

A及びBの接続形態の詳細は、「Recovery Kit for EC2™管理ガイド」をご参照ください。

LifeKeeper for Linux v9.2からは、上記のA、B二つのパターンに加えて、「Recovery Kit for Route 53™ 」を利用して以下の2つの接続形態もサポートいたします。

C：AWS Direct Connectを使用し、オンプレミス環境のクライアントから専用ネットワークを経由し、VPC内のクラスターノードへ直接接続

img_spec-ec23.png

D：他のVPC上のクライアントからのクラスターノードへの接続

img_spec-ec24.png
C及びDの接続形態の詳細は、http://jpdocs.us.sios.com/に掲載されている「AWS Direct Connect 接続クイックスタートガイド」をご参照ください。

　

参考情報：AWS Direct Connectを使った上記以外のパターンでの検証例

株式会社クラスメソッド様には、AWS Direct Connectを使用し、EC2上のHA構成の「サイボウズ ガルーン」をオンプレ環境から利用するケースの検証結果をブログ記事として公開を頂いております。

　

Hyper Converged Infrastructureへの対応

Hyper Converged Infrastructureは次世代の仮想基盤として注目を集め、その用途も企業の基幹システムやデータベースへと広がっています。この流れを受け、

  • Nutanix社のハイパーバイザーであるAcropolis Hypervisor（AHV）をサポート対象に加えました（Single Server Protectionのみ）。検証レポートはこちら
  • VMWare社のvSAN環境におけるLifeKeeperの動作検証を完了し、「仮想環境構成ガイド」を更新しました。新しいレポートはこちら

2016年8月1日 LifeKeeper for Linux v9.1で強化された機能

  • Quick Service Protection
  • LifeKeeper APIs
    • LifeKeeper API for Monitoring
    • Zabbix Sample Module for LifeKeeper API

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"を選択
img_spec-qsp1.png
  • 保護対象とするサービスをマウスで選択
img_spec-qsp2.png

  • いくつかの簡単な選択と入力のみでLifeKeeper上に保護対象となるリソースが完成！

img_spec-qsp3.png

LifeKeeper APIs

従来のLifeKeeperでは、複数のクラスターシステムの状態を把握するには、それぞれのクラスター毎にGUIを立ち上げて個別に確認を行う必要がありました。

img_spec-api.png

"LifeKeeper API for Monitoring"は、外部システムからLifeKeeperの状態を参照することが可能なAPIです。各種統合運用管理ツールからこのAPIを呼び出すことにより、それらのツールの画面上でLifeKeeper を含めたシステム全体の一元的なモニタリングが可能となり、特にクラウド環境や大規模システムにおける運用性の向上に貢献します。

img_spec-api4.png

img_spec-api2.jpg

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でプログラミングをするように、インフラの構成管理をコードによって行える。

img_spec-chef1.png

Recipe

Chef Clientで実際に設定されるインフラの構成情報を書いたプログラムのことです。Rubyの文法をベースにしてChefのDSL（Chef固有の命令）を使って記述します。たとえば、ミドルウエアをインストールして、サービスを起動するなど、従来、対象の端末にログインしてコマンド操作／各種スクリプトで行っていた処理などを、すべてRubyのコードで書きます。

CookBook

作成したレシピを実行するために必要になる設定ファイルのひな形やパラメータ一覧などをまとめたものが、CookBookです。CookBookの中には、Recipeも含まれます。

Chefで何が変わるの？

サーバー環境を構築する際の圧倒的なスピードアップが実現します。

img_spec-chef2.png

  • これまでのやり方とは比べ物にならないほどスピーディーにインストレーション/コンフィギュレーションが可能となり、省力化が可能

  • 再現性
    同じ環境のサーバーを短時間で大量に複製可能

  • 確実性と正確性
    自動化により、人為的な作業ミスを排除することができる

  • 設定ミスによる様々なトラブル（システムダウンを含む）を防止

こんな場合にもChefで解決！

  • 開発チームが使った環境を、運用チームへ引き継ぎたい。
  • テスト環境で入念な検証作業を行い不具合を出し尽くした。できればこの環境をそのまま本番環境へ移行したい…
  • アメリカにあるサーバーにLifeKeeperを入れなければならない。
    但し、現地にはLifeKeeperを知っている人はおらず、どうやって環境構築を行ったものやら…
  • 今度の案件は100台以上の仮想サーバーにLifeKeeperを入れなければならないのだが、それぞれのサーバーにインストールしてコンフィギュレーションをすることを考えると途方に暮れてしまう。
    そもそもうちの会社の体力では荷が重すぎるかもしれない…