こんにちは、SCSKの前田です。
今回は、LifeKeeper for Linux の最新機能を皆さまに知っていただきたく、最新バージョン 9.9.1 のリリースノートに記載されている新機能、バグ修正/機能強化、アップグレードの注意点等をご紹介します。
LifeKeeper for Linux v9.9.1 は本記事公開時点での最新バージョンとなります。
LifeKeeperとは？（おさらい）
LifeKeeperは、ビジネスの継続性を支える「高可用性（HA: High Availability）クラスターソフトウェア」です。
サーバーやアプリケーションに障害が発生した際、その影響を最小限に抑え、システムが止まることのないよう自動で復旧・切り替えを行うのが LifeKeeper の主要な役割です。
具体的には、複数のサーバー（ノード）でクラスターを組み、稼働系サーバーで障害が発生した場合、LifeKeeper が検知し、瞬時に待機系サーバーへ処理を移行します。この一連の自動切り替え処理を「フェイルオーバー」と呼びます。
LifeKeeper の強みは、OS やミドルウェア、データベース、アプリケーションといった様々な「保護対象リソース」の状態を監視し、それらをグループ化して切り替え制御を行う点にあります。この柔軟なリソース保護と、複雑な設定なしに利用できる点が、多くの企業に採用される理由です。
リリースノートでは、この LifeKeeper の「保護能力」や「監視精度」、そして「フェイルオーバーの信頼性」をさらに高めるための新機能や改善点、対応環境の拡充などが記載されています。最新バージョンで、より堅牢で効率的なシステム運用を実現するための進化の全貌をぜひご覧ください。
新機能：LifeKeeper/DataKeeper の進化のポイント
ここでは、LifeKeeper for Linux v9.9.1 で強化された LifeKeeper Core 及び DRBD Recovery Kit の新機能についてご紹介します。
多岐にわたるOSやVMwareのバージョンサポート追加も含まれますが、本記事では主要な機能強化に焦点を当て、バージョンサポートの詳細は公式リリースノートをご確認いただくようお願いいたします。
１．Linux ASLR 仕様変更への対応：LifeKeeper Core の安定稼働を強化
LifeKeeper for Linux v9.9.1 では、LifeKeeper Core の安定稼働をさらに強化するため、共有メモリアドレスが変更されました。
この変更は、Linux カーネルの Address Space Layout Randomization (ASLR) 機能の仕様変更に対応したものです。ASLRはプロセスのアドレス空間の配置をランダム化することでセキュリティを強化する機能ですが、これにより LifeKeeper が使用する共有メモリアドレスが OS 管理のアドレスと衝突する可能性が生じていました。
今回のアップデートでは、LifeKeeper が利用する共有メモリアドレスを「37f00000」から「6ff00000」に変更することで、OS のアドレス空間との衝突リスクを排除。これにより、LifeKeeper Core の安定した動作を確保し、予期せぬ問題発生の可能性を低減します。
これは、特に最新の Linux 環境における LifeKeeper の信頼性と堅牢性を向上させる重要な変更点です。
２．HANA 環境における lksupport の高速化と柔軟なデータ収集
LifeKeeper for Linux v9.9.1 は、lksupport コマンドの HANAト レースファイル収集機能が改善され、診断データ収集の効率が大幅に向上しました。
これまでのバージョンでは、HANA リソースが存在する環境において、特に HANA トレースファイルの容量が大きい場合、lksupport コマンドによるデータ収集に時間がかかるという課題がありました。
今回のアップデートでは、lksupport コマンドに新しいオプションが追加されました。これにより、以下のことが可能になります。
HANA トレースファイルを収集から除外する：大容量のトレースファイルを除外することで、lksupport の取得時間を大幅に短縮できます。
HANA リソースに関する情報のみを収集する：HANA 関連のトラブルシューティングに特化し、必要な情報だけを効率的に取得できるようになります。
この機能強化により、HANA が稼働する大規模な環境におけるトラブルシューティングや診断作業がより迅速かつスムーズになり、運用効率の向上に貢献します。必要な情報を効率的に取得できるため、分析時間の短縮にも繋がります。
３．DRBD Recovery Kit：4ノードクラスター対応で可用性を拡大
LifeKeeper for Linux v9.9.1 の DRBD Recovery Kit は、4ノードクラスターのサポートを開始しました。
DRBD Recovery Kit が初めて導入された LifeKeeper v9.9.0 では3ノードクラスターまでのサポートでしたが、今回のアップデートにより、より大規模な環境での高可用性構成が可能になります。
この拡張により、システム設計の柔軟性が大幅に向上し、より複雑なシステム要件や高い可用性レベルが求められる環境において、DRBD を用いた堅牢な多ノードクラスターを構築できるようになります。 冗長性をさらに高めたい、あるいは地理的に分散した環境で複数拠点を活用したいといったニーズにも対応しやすくなります。
４．DRBD IP アドレス変更の簡素化：LKCLI でリソース再作成不要に
LifeKeeper for Linux v9.9.1では、DRBD リソースに関連付けられた IP アドレスの変更プロセスが大幅に簡素化されました。
これまでの LifeKeeper v9.9.0 では、DRBD リソースの IP アドレスを変更する場合、既存の DRBD リソースを一度削除し、再作成する必要がありました。これは設定変更に伴う作業負荷が大きく、ヒューマンエラーのリスクも伴うものでした。
今回の機能強化により、LKCLI コマンドを使用することで、DRBD リソースを再作成することなく、IP アドレスを直接変更できるようになりました。
この改善は、システム運用における設定変更作業の工数を削減し、効率性を高めます。また、運用中の設定変更作業に伴うサービス停止のリスクを最小限に抑え、DRBD クラスターの管理をより柔軟かつ安全に行うことを可能にします。
バグ修正・機能強化：システムの安定性と運用性を向上
ここでは、多岐にわたるバグ修正および機能強化について、主な項目を一覧でご紹介します。
LifeKeeper for Linux v9.9.1
| No | 項目 | 内容 |
| 1 | DataKeeperミラーの挙動改善： | data_corruptフラグが削除された状態でDataKeeperミラーが強制的にオンラインになった際に、そのメッセージをログに記録するようになりました。 |
| 2 | lksupportのSAP MaxDBデータ収集強化： | lksupportがSAP MaxDB固有のデータをキャプチャできるようになりました。 |
| 3 | シャットダウン時の予期せぬスイッチオーバー問題を修正： | COMM_UPとCOMM_DOWN処理の競合により、シャットダウンストラテジーを”Do Not Switch Over Resources”（デフォルト）に設定していてもLifeKeeper停止時にスイッチオーバーが発生する問題を修正しました。 |
| 4 | Recovery Kit for EC2：RouteTableリソース作成時の権限緩和： | メインルートテーブルへのec2:replaceRoute権限がなくてもRouteTableリソースが作成できるようになりました。 |
| 5 | Recovery Kit for EC2：メタデータ取得のリトライ機能追加： | Recovery Kit for EC2でメタデータの取得に失敗した場合にリトライするようになりました（デフォルトで最大4回試行）。 |
| 6 | lkcliリソース拡張時の優先順位改善： | lkcliリソース拡張時、3番目と4番目のノードに拡張する際のデフォルトの優先順位レベルが改善されました。 |
| 7 | サーバー ステータス表示のタイプミス修正： | Monitoring.cgiのサーバー ステータス出力に含まれるタイプミス（DEADではなくDAED）を修正しました。 |
| 8 | lksupportのネットワーク情報収集効率化： | lksupportが/sys/class/net内のファイルを個別に作成するのではなく、圧縮tarアーカイブとして作成し、lksupportのtarファイルに含めるようになりました。 |
| 9 | AWS PAYGイメージでのライセンスタイプ表示問題を修正： | AWSの9.7.0 PAYG（Pay-as-you-go）イメージで、不明なライセンスタイプが表示される問題を修正しました。 |
| 10 | lkbackupの使用法およびマニュアルページ更新： | lkbackupコマンドの-qオプションが-xオプションからプロンプトを削除することを示す使用法とマニュアルページを更新しました。 |
| 11 | lkbackupのバグ修正：DRBDリソースファイル： | 複数のDRBDリソースファイルがバックアップされないというlkbackupのバグを修正しました。 |
| 12 | lksupportのDRBDサブシステムファイル収集強化： | lksupportが関連するDRBDサブシステムファイルを取得し、drbd.txtに記録するようになりました。 |
| 13 | DRBDクラスターのレプリケーション再開挙動改善： | DRBDクラスター内で複数のサーバーが一時停止されている場合、再開操作によりすべてのサーバー間のレプリケーションが再開されるようになりました。 |
| 14 | STONITHインストール時のエラーハンドリング強化： | LifeKeeperが停止している状態やコミュニケーションパスが作成されていない状態でSTONITHをインストールしようとすると、エラーになるように改修しました。 |
| 15 | 多ノードDRBDクラスターでのリソース復元失敗を修正： | 2ノードを超えるクラスターで2つのノードがクラッシュした後、使用可能なノードが1つだけの場合に、DRBDリソースの復元が失敗する問題を修正しました。 |
| 16 | NFSv4ファイルシステムリソース停止失敗のバグ修正： | NFSv4でマウントされたディレクトリ内のファイルが開いたままになっていると、ファイルシステムリソースの停止（アンマウント）に失敗するバグを修正しました。 |
| 17 | LifeKeeper起動中の停止処理改善： | LifeKeeperが起動中に停止する場合、起動処理が完了するまで待つように改修しました。 |
| 18 | DRBD lkcliサブコマンドの検証機能追加： | DRBD lkcliサブコマンド（force、resume、removesys、options、status）が、渡されたタグがDRBDリソース用のものであることを検証しないバグを修正しました。 |
| 19 | Oracle Recovery Kitの強制起動制御パラメータ追加： | 強制起動を実行するかどうかを決定するデフォルトファイル調整パラメーターORA_SAFE_USE_START_FORCEが追加されました（デフォルトでは実行されません）。 |
スムーズな移行のために：LifeKeeper アップグレード時の重要事項
LifeKeeper関連製品のアップグレードを安全かつ確実に実行していただくため、以下の重要な注意点をご確認ください。
１．Perlバージョンの変更とGeneric ARKへの影響
LifeKeeper for Linux v9.8.0以降では、同梱されるPerlが5.8.8から5.32.1に大幅にアップデートされています。
LifeKeeper for Linux v9.7.0以前のバージョンからv9.8.0以降にアップデートする場合、PerlベースのGeneric ARKを使用している環境では、このPerlアップデートが既存のスクリプトに影響を与える可能性があります。
【対応】 アップグレードを実施する前に、ご利用のGeneric ARKが新しいPerlバージョンで正しく動作するか、互換性を十分に検証してください。
詳細は「Perl 5.8.8からPerl 5.32.1へのアップグレード」ドキュメントをご参照ください。
２．SAP HANA Application Recovery Kit の変更と移行
LifeKeeper for Linux v9.5.0 より、SIOS は新しい SAP HANA Application Recovery Kit をリリースしています。
従来の gen/app ベースの SAP HANA Recovery Kit は LifeKeeper v9.5.0 以降ではサポートされていません。
【対応】LifeKeeper for Linux v9.5.0 以降へアップデートを検討されている既存の SAP HANA ユーザーは、必ず新しい（ビルトインの）SAP HANA Application Recovery Kit への移行作業が必要となります。
SIOS は2022年3月31日まで、9.4.xリリースでの従来の gen/app ベースの Recovery Kit のサポートを継続しましたので、現在は新しい SAP HANA Recovery Kit への移行が必須です。
３．アップグレードパスの制限
LifeKeeper は、最大2つ前のバージョン（例：9.7.x）から現在のバージョン（9.9.1）への直接アップデートが可能です。
これよりも古いバージョンからアップデートする場合は、以下のいずれかの対応が必要です。
・旧バージョンのアンインストールと新規インストール: 最も確実な方法ですが、システム構築の手間がかかります。
・段階的なアップデート: 古いバージョンを一度サポート対象のバージョン（例：9.7.x）に一時的にアップデートし、その後、現在のバージョン（9.9.1）へ再度アップデートすることで対応可能です。
【例】古いバージョンが 9.5.x の場合、まず 9.7.x にアップデートし、その後に 9.9.1 にアップデートします。
４．lkbackup 利用時の注意点
アップグレード中に lkbackup を使用する場合、リソースの作成後に lkbackup からリストアを行うと、破損したイクイバレンシが残される可能性があります。
これは、lkbackup がバックアップ後に初めて作成されたリソースの設定ファイルを適切に把握できないためです。
【対応】
・新規リソース追加前: 新しいリソースを初めて追加する前に lkbackup からリストアしてください。
・新規リソース追加後: lkbackup の後に新しいリソースを追加した場合は、リストアを行う前にそのリソースを削除するか、リソース階層のインスタンスを削除し、リストア後に再度階層を拡張してください。
【推奨】 特定のリソースを初めて作成する際に lkbackup を実行することを強く推奨します。
５．クラスター内の LifeKeeper バージョンの互換性
同じクラスター内のすべてのシステムには、同じバージョンおよびリリースのLifeKeeperをインストールする必要があります。
通常、バージョンまたはリリースの異なるLifeKeeperには互換性がありません。
【重要】 ローリングアップデートなどの特別な手順を除き、異なるバージョンまたはリリースの LifeKeeper がクラスター内の異なるシステムで実行されている状況では、LifeKeeper を起動しないでください。システムの不安定化や予期せぬ挙動を引き起こす可能性があります。
【アップグレードの注意点】本番環境と同等環境での徹底した事前検証を強く推奨
LifeKeeper の新バージョンがもたらす革新的な機能と強化された安定性は、システムの可用性をさらに向上させる大きな機会です。しかし、その恩恵を最大限に享受し、スムーズな移行を実現するためには、周到な準備と慎重な計画が不可欠です。
特にアップグレードの実施にあたっては、本番環境と同一、または極めて近似した環境での事前検証を強く推奨いたします。
これまでの多くの導入経験から、簡易的な検証環境やPoC環境では表面化しなかった問題が、本番環境特有の複雑な構成、データ量、実際のワークロード、あるいは連携する他システムとの相互作用によって、予期せぬ形で露呈するケースが確認されています。
例えば、以下のような本番環境固有の要素が、アップグレード後の動作に影響を及ぼす可能性があります。
・OS/カーネルの細かな設定やパッチレベルの差異
・ネットワークインターフェース（NIC）の構成やドライババージョン
・ディスクI/Oの特性やストレージ連携
・Firewallやセキュリティポリシー
・LifeKeeper以外のミドルウェア（DB、アプリケーション等）とのバージョン互換性
・ネットワークレイテンシや帯域幅の制約
これらの要素は、疑似環境やPoC環境では再現が難しく、本番環境にデプロイされて初めて問題が顕在化することが少なくありません。
そのため、単なる新機能の動作確認に留まらず、本番環境で想定される高負荷時におけるLifeKeeperの挙動、フェイルオーバー時間の計測、そして多岐にわたる障害シナリオ（ネットワーク障害、ディスク障害、ノード障害など）における健全な復旧プロセスの確認までを含めた、網羅的な検証計画を立てることが極めて重要です。
本番環境へのスムーズな移行と、アップグレード後の安定稼働を確実なものとするために、この「本番環境と同等環境での徹底した事前検証」が何よりも重要なステップであると、強くご理解いただけますと幸いです。
まとめ
今回は、LifeKeeper製品の最新バージョンに記載されている新機能、バグ修正/機能強化、そしてアップグレードの注意点についてご紹介いたしました。
ビジネス継続性を支える高可用性（HA）クラスターソフトウェアとして、LifeKeeperは常に進化を続けており、およそ半年に一度のペースでアップグレードを実施しています。
今後もLifeKeeperの新機能や改善点、対応環境の拡充など、皆さまがより堅牢で効率的なシステム運用を実現できるよう、LifeKeeperに関する情報発信を続けてまいります。
最後までお読みいただき、誠にありがとうございました。
