こんにちは、SCSKの小川です。 パブリッククラウドが主流となる中、いまだオンプレのシステム稼働の需要は高く、お客様環境に個別の仮想基盤が多く稼働しています。 そのため、VMware問題に悩むお客様も多く、新たな仮想基盤へのリプレースの提案依頼が増えてきています。 今回は、新たなオンプレ仮想基盤ソリューションとして、everRunを紹介します。 VMware以外の仮想基盤ソリューションをご検討中の方は、ぜひご確認ください！   everRunとは everRunはStratus社が提供する高信頼性仮想化システムを実現するソフトウェアソリューションです。 ●everRunシステム構成イメージ everRunの最大の特徴は、仮想マシン毎に設定した保護レベルが設定できることです。 最も信頼性を高める「Fault Tolerant（FT）構成」の場合、 仮想マシンを「無停止」「無瞬断」で稼働 させられます。 ＜設定可能な保護レベル＞ 仮想マシン毎に以下の3つの保護レベルから選択可能 FT（Fault Tolerant）　CPUステータス・メモリ同期 / HDD同期 / ネットワーク冗長化 HA (High Availability）  HDD同期 / ネットワーク冗長化  ※CPUステータス・メモリ同期は行わない 無し      　　　　　　　（障害時仮想マシンは停止）   everRunの採用ポイント 一般的な仮想基盤ソリューションの比較結果を以下に記載します。 製品比較表（ 筆者の見解）   品名 製品タイプ 主な特長・機能 可用性／冗長性 運用管理 サポート体制 ライセンス／価格 VMware vSphere/ESXi ハイパーバイザー型 仮想化ソフトウェア 業界標準・高い安定性、多機能性、 高度な管理、仮想ネットワークや ストレージ連携 vMotion/HA/DRSなど 多彩な冗長・可用性機能、 ホスト構成2台～ vCenterによる集中管理 ○⇒ ？(見直し中) グローバル・国内とも充実 ○⇒ ？(見直し中) サブスクリプション （最近体系が変更） Microsoft Hyper-V ハイパーバイザー型 仮想化ソフトウェア Windows OSと統合、 シンプルな運用、コスト効率、 Active Directory連携 クラスタ―構成、 ライブマイグレーション、 ホスト構成2台～ SCVMMなど管理ツール △ Microsoft標準 サポート ◎ Windows Serverライセンス含む Nutanix AHV ハイパーコンバージド インフラ（HCI） ※KVMベース 仮想化＋ストレージ＋ネットワークが一体化、スケーラブル、 運用自動化 分散ストレージ、 障害時自動復旧、 ホスト構成3台～ Prismによるシンプル管理 ○ Nutanixから一元サポート × ハード＋ソフトサブスクリプション Stratus everRun フォールトトレランス 仮想化ソフトウェア ※KVMベース サーバ障害時の自動切替・ゼロダウン、追従型ハードウェア冗長 完全な冗長化、ミラーリング、 ホスト構成2台／セット Webベース管理ツール ○ Stratus社サポート ○ ノード数による ライセンス 凡例 赤字：主な留意点 everRunの採用ポイント 強み：シンプルな構成・運用、専用の管理ツールによる分かりやすい操作性、低コストな導入・運用を実現します。 弱み：1対1の2台構成 　　　⇒ VMwareのようなN対1構成による拡張性が無いため、原則小規模単位の導入を推奨します。   お客様の声 ＜お客様の業種：製造業＞ システム要件で自社サーバ室でVMware環境を運用していたが、VMware問題に伴いサポート体制やコストに不安を感じていました。 そのため、HWの保守切れに伴いVMware以外の仮想基盤にリプレースを検討していた。 everRunを知らなかったため初めは抵抗感を感じたが、丁寧な製品紹介を聞いた結果、以下の理由でeverRunの採用を決定しました。 　①KVMベースのため、他社製品と主要機能の範囲では大きな差は無いと感じた。 　②工場系システムに対して、VMwareの可用性を超えるFT環境を、容易にかつ安価に導入することができる。 　③国内の導入事例も多い。（国内600件以上の導入実績）   さいごに everRunは、VMwareのコストやサポート面への不安を背景に、国内でも着実に採用が進む新たな仮想化基盤の選択肢です。 特に小規模で高可用性が求められる現場、限られたITリソースでシステムを安定稼働させたいお客様におすすめです。 オンプレ仮想環境の継続活用にお悩みの方は、ぜひご検討ください。 詳しい内容をお知りになりたいかたは、以下のメールアドレスにご連絡ください。 お問い合わせ： west-marketing-info@scsk.jp

こんにちは　SCSK 野口です。 前回の記事 (LifeKeeper for Windows v8.11.0) では基本要件やノード設定についてご紹介いたしました。 まだ、お読みではない方はこちらのリンクからご覧ください。 LifeKeeper for Windows のインストール要件 今回は LifeKeeper for Windows の基本要件について、まとめてみました。バージョン v8.11.0 時点のまとめとなるためご注意ください。 blog.usize-tech.com 2025.11.19 本記事では「LifeKeeper for Windows v10の基本要件や変更点」についてご紹介いたします。 LifeKeeper for Windows v10になってから基本要件が変わっていないか、新機能が追加されていないか注目していきます。 基本要件について システム要件 LifeKeeper for Windows v10は、以下のシステム要件を満たす必要があります。(2026年1月時点) なお、LifeKeeper for Windows v8.11から変更された箇所は赤文字で記載しております。 ※ プロセッサーについてはこちらのリングからご確認ください。 Windows Server プロセッサーの要件   LifeKeeper for Windows v10でも、システム要件はほぼ変わってないね！ オペレーティングシステム LifeKeeper for Windows v10は、以下のオペレーティングシステム（OS）がサポートされています。(2026年1月時点) ■サーバーコンポーネント ・Microsoft Windows Server 2025 Standard / Datacenter Editions ・Microsoft Windows Server 2022 Standard / Datacenter Editions ・Microsoft Windows Server 2019 Standard / Datacenter Editions ・Microsoft Windows Server 2016 Standard / Datacenter Editions ※ 全てのバージョンで Microsoft .NET Framework 4.5.2以上が必要です。 ■ユーザーインターフェイス コンポーネント ・Windows 11 ・Microsoft Windows Server 2025 ・Microsoft Windows Server 2019 ・Microsoft Windows Server 2016 ※ 全てのバージョンで Microsoft .NET Framework 4.5.2以上が必要です。 LifeKeeper for Windows v10では、Windows Server 2016 以降から使用できるんだね！ ストレージとアダプタ LifeKeeper for Windows v10は、以下のストレージとアダプタ要件を満たす必要があります。(2026年1月時点) また、共有ストレージを使用することも、複製ストレージを使用することもできます。 ■ストレージデバイス ・アプリケーション要件に基づき、必要なデータストレージの種類と数を判断する ・共有ファイルを使用する場合、ディスクアレイ(RAID)に配置する ・多数のハードウェア RAID 周辺機器を使用することができる ■アダプタ ・構成タイプと周辺機器数から、必要な SCSI または FCホストアダプタの種類と数を判断する ・選択したアダプタを Microsoft がサポートしており、ドライバを入手できることが重要である ※ ストレージとアダプタ、それから周辺機器については、Microsoft のサポートが前提となります。 詳細情報については、こちらのリンクからご確認ください。 Microsoft のハードウェア互換リスト ■ 共有ストレージ構成 ・LifeKeeper for Windows によって保護されるディスクはすべてパーティションに分割する ・Windows ディスクの管理ユーティリティを使用し、共有ディスクアレイのパーティション (ボリューム)を構成する ・パーティションは NTFS ファイルシステムで フォーマット する ・コミュニケーションパスに使用する小さい raw(未 フォーマット ) パーティションを指定 *¹ ・クラスタ内の他のサーバの電源を投入して、すべてのサーバが共有ディスクを認識している ・バックアップサーバから、共有ボリュームのドライブの割り当てが最初のサーバとまったく同じにする ・ディスクの管理ユーティリティを開くのは 1 度に 1 台のサーバだけにする (推奨) ・クラスタ内の各サーバで、これらのフォルダのファイル共有属性をオンにする *² ※ ダイナミックディスクは共有ストレージではサポート対象外です。 *¹  共有ディスクコミュニケーションパスを使用する場合に必要です。 *²  共有ボリュームでファイル共有を作成した場合に必要です。 ■ 複製ボリューム構成 (DataKeeper) ・Windows ディスクの管理ユーティリティを使用し、複製されるディスクパーティション (ボリューム) を作成する ・パーティションは NTFS ファイルシステムで フォーマット する ※ ソースボリューム と ターゲットボリュームには同じドライブレターを割り当ててください。 LifeKeeper for Windows v10でも、ストレージとアダプタ要件は変わってないね！ 変更点について LifeKeeperの用語 LifeKeeper v10になってから、以下のように LifeKeeperの用語変更されました。(2026年1月時点) ■リソース拡張の際、拡張元サーバと拡張先サーバの呼称が変更されました。 拡張元： Template Server  →「 Primary Server 」 拡張先： Target Server/Target Node →「 Standby Server/Standby Node 」 ■ サーバの待機状態を表す用語が変更されました。 待機状態： Standby →「 Passive 」    使用例： Active / Passive ■リカバリーキットの表記が変更されました。 表記： ～ Recovery Kit →「 Recovery Kit for ～ 」 ■サポートマトリックスの名称が変更されました。 名称： サポートマトリックス →「 認定 情報 」 LifeKeeper for Linux v10も同様に用語変更されたわよ！ LifeKeeper for Windows v10から廃止された機能 LifeKeeper for Windows v10から、以下の機能が廃止されました。(2026年1月時点) ■ 製品：LifeKeeper Core ・DISKCAコミュニケーションパスのサポートを廃止。 ■製品：Recovery Kit for Microsoft Internet Information Services ・LifeKeeperは、Microsoft Windows Serverの全バージョンにおいて、 SMTP仮想サーバー機能を廃止。この機能は将来のリリースで削除される予定。 ■製品：Recovery Kit for LAN Manager ・LAN Managerはサポートされなくなり、今後のリリースでLifeKeeperの機能から削除される予定。 なお、新しいLifeKeeper Web Management Console (LKWMC) では使用不可。 ■製品：Recovery Kit for IP Address ・IPリソースのバックアップネットワークアダプターを廃止。 以前のバージョンでバックアップネットワークアダプターを設定していた場合は無視。 IPリソースのバックアップアダプター設定は、 v10にバージョンアップしたら『無視』されるから注意だね！ LifeKeeper for Windows v10の新機能 LifeKeeper for Windows v10から、WebベースのGUI (LKWMC) 「LifeKeeper Web Management Console」がリリースされました。(2026年1月時点) LifeKeeper for Windows v10の LKWMCを使用する場合、以下のような要件があります。 動作環境 ■ クライアント環境(OS) ・Windows 11 (64bit) ・Windows Server 2016 (64bit) ・Windows Server 2019 (64bit) ・Windows Server 2022 (64bit) ・Windows Server 2025 (64bit) ■ ブラウザー ・Google Chrome (最新版) ・Microsoft Edge (最新版) ・Mozilla Firefox (最新版) ファイアウォールの設定 ■ クラスタ対象サーバ間の双方向で許可が必要 ・TCP 5000       : REST API サーバ通信で使用    （LKWMC 用） ■GUIクライアントとクラスタ対象サーバ間の双方向で許可が必要 ・ TCP 5110       : GUI サーバ通信で使用            （LKWMC用） ※ その他の新機能についてはこちらのリングからご確認ください。 LifeKeeper for Windows Version10の新機能 LifeKeeper for LinuxのLKWMCと同じポートを使用してるわね！ まとめ 今回は LifeKeeper for Windows v10の基本要件や変更点についてご紹介しましたが、いかがでしたか。 ・システム要件では、LifeKeeper for Windows v10になってもほとんど変更されていないこと。 ・オペレーティングシステムでは、Windows Server 2016 以降から使用可能になってること。 ・変更点では、LifeKeeper for Windows v10から、LKWMCがリリースされ使用可能になっていること。 詳細情報をご希望の方は、以下のバナーからSCSK Lifekeeper公式サイトまで

LifeKeeperの『困った』を『できた！』に変える！サポート事例から学ぶトラブルシューティング＆再発防止策 こんにちは、SCSKの前田です。 いつも TechHarmony をご覧いただきありがとうございます。 LifeKeeperを導入し、システムの高可用性を実現する上で、アプリケーションリソースの保護は非常に重要な要素です。しかし、アプリケーションARKは、その特性ゆえに、設定のわずかな見落とし、予期せぬ通信障害、そしてバージョンアップによる仕様変更など、多岐にわたる要因で『困った』事態に直面することがありますよね。 本連載企画「LifeKeeper の『困った』を『できた！』に変える！サポート事例から学ぶトラブルシューティング＆再発防止策」では、まさにそんな「なぜかアプリケーションが切り替わらない」「エラーが出て起動できない」といった、LifeKeeper運用の現場で実際に発生した問い合わせ事例を基に、トラブルの原因、究明プロセス、そして何よりも『再発防止策』に焦点を当てて深掘りしていきます。今回の第三弾では、アプリケーションARK特有の「落とし穴」に焦点を当て、その解決と再発防止の鍵を探ります。 はじめに LifeKeeperの心臓部とも言えるアプリケーションリソースの保護は、システムの高可用性を実現する上で不可欠です。専用ARKから汎用ARKまで多岐にわたりますが、その複雑さゆえに設定ミスや連携アプリケーション側の要因で予期せぬトラブルが発生しがちです。 本記事では、 LB Health Check、MySQL、IIS、そしてGeneric ARKを用いたJP1/Baseのリソース構築・運用で実際に発生したサポート事例 を元に、アプリケーションARK特有の「落とし穴」を深掘りします。 通信障害、バージョン間の仕様変更、ホスト名の制約、スクリプトの依存性など、様々な角度から原因と対策を学ぶことで、アプリケーションの安定稼働と再発防止につなげるヒントを提供します。 その他の連載企画は以下のリンクからどうぞ！ 【リソース起動・フェイルオーバー失敗の深層 #1】EC2リソースが起動しない！クラウド連携の盲点とデバッグ術 – TechHarmony 【リソース起動・フェイルオーバー失敗の深層 #2】ファイルシステムの思わぬ落とし穴：エラーコードから原因を読み解く – TechHarmony 今回の「困った！」事例 ケース1：ロードバランサーとの連携トラブル – ヘルスプローブの落とし穴 lbhcリソース作成中にエラー(140251)が発生する、LB Health Checkリソース作成時のエラーについて 事象の概要:  LifeKeeper for Windows環境でLB Health Checkリソース作成・起動時にエラーが発生し、リソース作成に失敗。 ロードバランサーからの正常性プローブがLifeKeeper側で受け取れない状況 に陥りました。 発生時の状況:  LBHCリソース作成後のリソース起動でロードバランサーとの通信がタイムアウト（エラーコード140251）しました。Azure内部ロードバランサーからの通信は許可済みと認識されていたにも関わらず、プローブが到達しませんでした。また、LifeKeeperのホスト名に小文字が混在している環境でした。 原因究明のプロセス:  初期には HC_TIMEOUT の調整やデバッグログ取得を試みましたが、デバッグログからも最終的にプローブを受け取れていない状況が判明。さらに、ホスト名に小文字が含まれることがLifeKeeper for Windowsの既知の不具合であり、リソース情報取得エラーの原因であることが明らかになりました。 判明した根本原因:  1. ロードバランサーからの正常性プローブがLifeKeeper側で受け取れていない通信経路上の問題、および 2. LifeKeeper for Windowsのホスト名が小文字混在であったことによるリソース情報取得エラーが複合的に発生していました。 ケース2：データベースARK特有の設定ミス – MySQLのパスワードとログパスの罠 MySQLリソース作成時のエラーについて 事象の概要:   MySQLリソース作成時 に「Invalid parameter value」エラーが発生し、さらにその後log-binのパスに関するエラーが発生。 リソース作成が成功しません でした。 発生時の状況:   my.cnf 内のMySQLユーザーパスワードに「$」が含まれており、ダブルクォーテーションで囲んでいましたがエラーが解消されませんでした。また、 log-bin パラメータがファイル名のみで指定されていました。既存システム（LifeKeeper v9.3.2）ではファイル名のみで動作していましたが、新システム（LifeKeeper v9.9.0）ではエラーとなりました。 原因究明のプロセス:  サポートとのやり取りにより、パスワードの特殊文字（「$」）を正しく扱うためにはシングルクォーテーションで括る必要があること、および log-bin のパスはLifeKeeper for Linux v9.6以降ではフルパス指定が必須になったことが判明しました。 判明した根本原因:  1. MySQLユーザーパスワードに特殊文字（「$」）が含まれる場合の記述ルール（シングルクォーテーションで括る）の不理解、および 2. LifeKeeper for Linuxのバージョンアップに伴うMySQL ARKの仕様変更（ log-bin のフルパス指定必須化）への追従不足が原因でした。 ケース3：WebサーバーARKの特性理解不足 – IISの拡張前処理スクリプト IISリソース拡張前処理スクリプト実行時のエラーメッセージについて 事象の概要:  IISリソース作成時の拡張前処理スクリプト実行中にエラーメッセージが発生しましたが、 その後の拡張はエラーなく実行され、IISリソースの作成自体は完了 しました。 発生時の状況:  既にボリュームリソースが拡張済みであったにも関わらず、IISリソースの拡張前処理スクリプト内で再度ボリューム拡張を試みていました。 原因究明のプロセス:  サポートの確認により、このエラーは既にボリュームリソースが拡張されているため発生する、運用上問題のない情報メッセージであることが確認されました。 判明した根本原因:  拡張前処理スクリプトが、既に拡張済みのボリュームに対し再度拡張処理を行おうとしたため発生する、意図されたエラーメッセージであり、IISリソースの拡張自体には影響がありませんでした。 ケース4：Generic ARK利用時の注意点 – スクリプト依存とサポート範囲 Generic ARK リソース (JP1/Base)における quickCheck の仕組みについて 事象の概要:  Generic ARK（JP1/Base）における quickCheck の動作について問い合わせ。ネットワークメンテナンスに伴う通信断の影響で、 quickCheck が失敗しOSが再起動しました。 発生時の状況:   quickCheck スクリプト内で名前解決を使用しており、通信断により名前解決ができず quickCheck が失敗したと推測されました。 原因究明のプロセス:  問い合わせたGeneric ARKがサポート対象外であることが判明し、お客様が作成したスクリプトの内容に依存するため、LifeKeeper製品としての詳細な案内はできませんでした。 判明した根本原因:  サポート対象外のGeneric ARKを利用しており、スクリプトの内容（名前解決への依存）が起因する問題であったため、LifeKeeper製品としての根本原因は特定できず、スクリプト作成者による詳細確認が必要でした。 「再発させない！」ための対応策と学び 具体的な解決策: LB Health Checkリソース関連:  ネットワークセキュリティグループ(NSG)やファイアウォールで、ILBのIPアドレスからのプローブ用ポートへの通信を確実に許可する。 HC_TIMEOUT の設定値を環境に合わせて調整する。 LifeKeeper for Windowsを導入するサーバーの ホスト名は、すべて大文字で設定 する 。 MySQLリソース関連:  MySQLユーザーのパスワードに 特殊文字（「$」など） を使用する場合は、 必ず 「’」（シングルクォーテーション）で文字列全体を括って 設定する。 my.cnf 内の datadir 、 log-bin 、 log-tc パラメータは、LifeKeeper for Linux v9.6以降では共有ディスク上の 絶対パス(フルパス) で指定する。 IISリソース関連:  IISリソース作成時の拡張前処理スクリプト実行中に、既に拡張済みのボリュームに関するエラーメッセージが表示された場合、その後の IISリソース拡張が 成功 していれば、運用上問題ないメッセージとして認識 する。 Generic ARK関連:  利用するアプリケーションがLifeKeeperのサポート対象であることを事前に確認する。Generic ARKで利用するスクリプトは、 作成者が動作内容（特に外部依存性） を詳細に把握し、デバッグログ出力やエラーハンドリングを適切に実装する。 再発防止策（チェックリスト形式）:   ARK のサポート範囲と互換性確認: 専用ARK利用時もGeneric ARK利用時も、対象アプリケーションとLifeKeeperのバージョンがサポートされているか、 サポートマトリクス で事前に確認する。   OS/LifeKeeper バージョンアップ時の仕様変更確認:  OSやLifeKeeper本体のバージョンアップを行う際は、リリースノートやドキュメントを詳細に確認し、 ARK固有の仕様変更（例: MySQL ARKの log-bin パス指定） がないか確認する。   ARK 固有の設定ファイル（例: my.cnf）の厳格な管理:  アプリケーションARKが参照する設定ファイルは、LifeKeeperの要件（例: パスワードの記述ルール、パスの絶対指定）に沿って適切に設定・管理する。   通信経路とセキュリティ設定の徹底確認:  ロードバランサーのヘルスプローブやアプリケーション間の通信など、LifeKeeperが監視・利用する通信経路について、 ファイアウォールやネットワークセキュリティグループの設定を構築前に徹底的に確認 し、必要なポートが解放されていることを保証する。   命名規則（ホスト名・ユーザー名など）の遵守:  LifeKeeperが動作する環境では、ホスト名やユーザー名にLifeKeeperの制約（例: Windows版でのホスト名の大文字制約 ）がないか事前に確認し、 命名規則を遵守 する。   Generic ARK 利用時のスクリプト詳細把握:  Generic ARKを利用する場合は、スクリプトの作成者が動作内容（特に外部依存性、名前解決など）を詳細に把握し、デバッグログ出力やエラーハンドリングを適切に実装する。   LifeKeeper ログの日常的な監視とエラーコード理解:  LifeKeeperログに記録されるエラーメッセージやエラーコードの意味を正確に理解し、日常的に監視することで異常を早期に検知・対処できる体制を整える。 ベストプラクティス: 設計段階での詳細な要件定義:  アプリケーションリソースを保護する際は、LifeKeeperの要件、アプリケーションの要件、ネットワークの要件を詳細に定義し、設計書に落とし込む。特に通信要件や設定ファイルのパス、パスワードポリシーは入念に検討する。 公式ドキュメントの積極的活用:  各ARKの管理ガイド、処理概要、リリースノート、動作環境リストなど、SIOSが提供する最新の公式ドキュメントを常に参照し、推奨設定や既知の制約を把握する。 検証環境での徹底的なテスト:  OSアップデート、LifeKeeperバージョンアップ、アプリケーション設定変更など、システム構成に影響を与える変更は、必ず本番適用前に検証環境でLifeKeeperリソースを含むシステム全体の動作テストを実施する。 運用フローとチェックリストの確立:  リソース作成、変更、OSアップデートなどの主要な運用タスクについて、具体的な手順と確認項目を記した運用フローとチェックリストを確立し、ヒューマンエラーを防止する。 サポート活用と情報共有:  疑問点やエラー発生時には、積極的にSIOSサポートに問い合わせ、得られた知見はチーム内で共有しナレッジとして蓄積する。 まとめ 本記事では、LB Health Check、MySQL、IIS、Generic ARKといったアプリケーションリソースに関連する様々なトラブル事例を取り上げました。 これらの事例から、アプリケーションARKの安定稼働には、LifeKeeper本体やARKの仕様への深い理解に加え、連携するOSやアプリケーションの設定、そして基盤となるネットワーク通信環境の綿密な確認が不可欠であることが明らかになりました。 特に、OSやLifeKeeperのバージョンアップに伴う仕様変更への追従、設定ファイル記述ルールへの注意、そしてGeneric ARK利用時のスクリプト内容への詳細な把握が、トラブルを未然に防ぐ鍵となります。 日々の運用でこれらの点を意識し、公式ドキュメントの活用と検証を徹底することで、「困った！」を「できた！」に変え、より堅牢なクラスタ環境を構築・維持できるでしょう。 次回予告 次回の連載では、「クラスタの予期せぬ停止を防ぐ！ネットワーク構成のトラブルシューティング」と題し、LifeKeeper環境におけるネットワーク関連のトラブル事例とその解決策、安定稼働のためのベストプラクティスを深掘りします。どうぞご期待ください！ 詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで