SafeKit：オールインワンの SANレス高可用性（HA）＆ アプリケーション・クラスタリング・ソフトウェア

SafeKit は、単一のソフトウェア製品で Windows および Linux 向けに以下の機能を提供します。

• ロードバランシング（負荷分散）
• 同期リアルタイム・ファイルレプリケーション
• アプリケーションの自動フェイルオーバー
• サーバ障害後の自動フェイルバック

いいえ。SafeKit は導入が非常にシンプルであり、高度な専門知識は必要ありません。

いいえ。SafeKit は既存のサーバ、仮想マシン、またはクラウド上で動作します。共有ディスクや SAN ストレージは不要です。

いいえ。SafeKit は標準的な Windows および Linux エディションで動作し、データベースの Enterprise エディション等のライセンスも必要ありません。

SafeKit は以下の問題を解決します：

• ハードウェア障害（問題の20%）：コンピュータ室全体の完全な停止を含みます。
• ソフトウェア障害（問題の40%）：重要なプロセスの再起動を含みます。
• ヒューマンエラー（問題の40%）：その使いやすさにより、操作ミスを防止します。

以下に対して、リアルタイム・レプリケーションとフェイルオーバーを実装できます：

• あらゆる種類のアプリケーション、ファイルディレクトリ、およびサービス
• データベース
• Hyper-V または KVM の仮想マシン全体
• Docker、Podman、およびクラウドアプリケーション

SafeKit は、以下の要件を不要にすることでコストを削減します：

• ネットワークロードバランサや専用プロキシサーバー
• 共有ディスクやレプリケーション機能付き SAN ストレージ
• オペレーティングシステムやデータベースの Enterprise エディション
• 専門的なクラスターメンテナンススキル

いいえ。データレプリケーション（複製）は、単にサーバーAからサーバーBへデータをコピーする行為に過ぎません。レプリケーションは重要ですが、それ自体が高可用性を提供するわけではありません。HAスタックの他のコンポーネントがなければ、レプリケーションは単なる「パッシブコピー（受動的なコピー）」であり、活用するには手動での時間のかかる介入が必要になります。

• サーバーAがクラッシュしても、データレプリケーションソフトは自動的にユーザーの接続先をサーバーBに切り替えることはありません。
• アプリケーションが停止したことを検知することもありません。
• サービスを再起動することもありません。

多くのベンダーは、ホストベースのレプリケーション、フェイルオーバー、およびロードバランシングを実現するために、複数の異なる製品を「つなぎ合わせる」ことを要求します。このような断片的なアーキテクチャは、ミッションクリティカルなシステムにとって危険な戦略です。

• 脆弱な統合： レプリケーションに製品A、クラスタリングに製品Bを使用すると、いわば「積み木」のような不安定な状態になります。OSのアップデートやセキュリティパッチの適用ごとに、これら独立したエンジン間の脆弱な通信リンクが切断されるリスクが生じます。
• 高い認知負荷とヒューマンエラー： 複数のインターフェースを管理することは、ミスを誘発します。システム障害というプレッシャーのかかる状況下で、問題診断のために異なるGUIを行き来したり、異なるCLI構文を使用したりすることは、混乱を招き、ダウンタイムの延長につながります。
• ベンダー間の責任転嫁： フェイルオーバーが失敗した際、レプリケーション担当ベンダーがクラスタリングツールを非難するといった事態が起こり得ます。その結果、ユーザーは解決策が見えないまま板挟みになります。オールインワン・ソリューションであれば、責任の所在が明確になります。
• 複雑なメンテナンス： 断片的なシステムは、個々のコンポーネントごとに専門的なスキルを必要とします。そのため、メンテナンスが困難になり、時間の経過とともに維持コストが大幅に増大します。

リカバリを自動化し、ダウンタイムを排除するために、オールインワン製品は以下の複数の技術的要素を同時に管理する必要があります。

• ホストベース・レプリケーション： 共有ストレージ（SAN）に依存せず、サーバー間で重要なアプリケーションデータをリアルタイムかつ同期的に複製します。これにより、データ損失ゼロ（RPO=0）を保証し、高価なハードウェアへの依存を排除します。
• 仮想IPアドレス (VIP)： ユーザーに対して単一の接続ポイントを提供します。障害発生時、ソフトウェアが VIP を障害ノードから正常なノードへ移動させるため、ユーザーは設定を変更する必要がありません。
• ハードウェアおよびソフトウェアのエラー検知： 物理サーバーと特定のソフトウェアプロセスの両方を常に「ハートビート」監視し、ハングアップやクラッシュを即座に特定します。
• カスタマイズ可能な起動スクリプト： アプリケーションによって起動方法は異なります。オールインワンツールでは、カスタムスクリプトを使用して、複雑なサービスを正しい順序で確実に起動させることができます。
• 自動フェイルオーバー： 人の手を介さず、あるサーバーから別のサーバーへの移行プロセス全体をオーケストレーション（調整）するインテリジェンスです。

フェイルオーバー・マネージャーとデータ・レプリケーションが別々の製品である場合、それらは「同期」していない可能性があります。

潜む危険性： フェイルオーバーが発生しても、レプリケーションによる最新データの送信が完了していない場合、サーバーBは古いデータや破損したデータでアプリケーションを起動してしまいます。

オールインワンの SANレス HA ソリューションは、フェイルオーバー・メカニズムがレプリケーションの状態を常に把握していることを保証します。データが最新であることが保証されている場合にのみ、バックアップノードでのアプリケーションの起動を許可するため、アクティブノードの競合やデータの損失を防ぐことができます。

技術ガイドでは見落とされがちで、従来の HA ソリューションでは不十分に実行されることも多い「自動フェイルバック」ですが、真のレジリエンス（回復力）を実現するためには最も重要な要件です。真のオールインワン製品は、障害時と同様に「通常状態への復帰」をスマートに処理します。障害が発生したサーバーがオンラインに戻った時点では、データが最新ではありません。そのため、HA ソフトウェアは以下の処理を行う必要があります。

1. 稼働中のノードから復旧したノードへ、バックグラウンドでデータを再同期します。
2. 稼働時間を維持： この再同期は、稼働中のノードで実行されているアプリケーションを中断することなく行われなければなりません。
3. 冗長性の回復： データのミラーリング（同期）が完了すると、クラスターは自動的に保護状態に戻り、次のイベントに備えます。

ホストベース・レプリケーションに採用されている技術的手法は、既存のアプリケーション設定をどの程度変更する必要があるかに大きく影響します。

• ブロックレベル・レプリケーションの課題： 多くの SANレス・ソリューションは、ディスク/ブロックレベルで複製を行います。これはアプリケーションにとって透過的ではありません。データを特定の、新しく作成された「複製用ディスク」ボリュームに移動させるために、アプリケーションを完全に再構成する必要があります。これには多くの場合、複雑な移行作業やアプリケーションロジックの変更が伴います。
• SafeKit ファイルレベルの優位性： SafeKit はファイルレベルでホストベース・レプリケーションを行うため、アプリケーションに対して完全に透過的です。データを特別なディスクに移動させる必要はありません。既存のアプリケーションフォルダを複製するように SafeKit を設定するだけです。これらのフォルダはシステムディスク上に置いたままでも運用できるため、アプリケーションが既にインストールされている場所でそのまま保護することが可能です。

障害後の再同期時間（ステップ 3）

• 1 Gb/s ネットワーク ≈ 1 テラバイトで約 3 時間。
• 10 Gb/s ネットワーク ≈ 1 テラバイトで約 1 時間、またはディスク書き込み性能によりさらに短縮。

代替案

• 大量データの場合は、外部共有ストレージを使用。
• より高価で、より複雑。

• 障害後の再同期時間の性能（ステップ 3）。
• 両ノード間で各ファイルを確認する時間。

代替案

• 多数のファイルを仮想ハードディスク／仮想マシンにまとめる。
• この場合、仮想ハードディスク／仮想マシンを表すファイルのみがレプリケートおよび再同期される。

• 各 VM は独立したミラーモジュールで動作。
• 同一クラスタで最大 32 個のミラーモジュールが稼働可能。

代替案

• 外部共有ストレージと別の VM クラスタリングソリューションを使用。
• より高価で、より複雑。

• 同一サブネット内の 2 ノードで仮想 IP アドレスの自動フェイルオーバー。
• 再同期のための十分な帯域幅（ステップ 3）と、同期レプリケーションに適した低レイテンシ（通常ラウンドトリップ 2ms 未満）。

代替案

• 2 ノードが異なるサブネットにある場合、仮想 IP アドレス用のロードバランサを使用（SafeKit でサポート、特にクラウド環境）。
• 高レイテンシネットワークでは非同期レプリケーションを用いたバックアップソリューションを使用。

SafeKit Webコンソールは、重要なアプリケーションの高可用性を統合制御するための直感的なインターフェースを提供します。わずか数ステップでSafeKitミラークラスターを構成し、ビジネスの継続性を確保できます。

• アプリケーションのフェイルオーバー（「Macros」タブ）： 障害発生時に自動的に再起動する特定のアプリケーションサービスを定義します。
• ハートビートネットワーク： クラスターノード間で相互の健全性と可用性を継続的に監視し、フェイルオーバーの決定を同期するために使用される専用の通信経路です。
• 仮想IP管理： フェイルオーバー後にクライアントが透過的に再接続できるように、仮想IP（VIP）を設定します。
• リアルタイムレプリケーション： ホストベースの同期型バイトレベルレプリケーションを行う重要なディレクトリを選択します。
• チェッカー（監視機能）： アプリケーションの健全性を監視し、プロセスの障害が検出された場合に自動復旧をトリガーします。

SafeKitクラスターには専用のスプリットブレインチェッカーが組み込まれているため、3台目のウィットネスマシン（監視サーバー）や追加のハートビートネットワークを必要とせずに、ネットワークの分断（孤立）問題を解決できます。詳細については、クラスターにおけるハートビート、フェイルオーバー、およびクォーラムをご覧ください。

SafeKit管理コンソールは、高可用性インフラストラクチャの一元化されたビューを提供します。管理者はこれにより、クラスターの運用状態を監視し、データ同期をリアルタイムで追跡できます。

2ノードのミラークラスターでは、各サーバーの役割がコンソールに明確に表示されます。

• PRIM（プライマリ）： 現在アプリケーションを実行し、仮想IPを管理しているアクティブなノードです。ローカルストレージへの書き込みと、セカンダリノードへのリアルタイムレプリケーションを実行します。
• SECOND（セカンダリ）： 同期型のバイトレベルの更新データを受信している待機（スタンバイ）ノードです。プライマリが深刻な障害に見舞われた場合、即座に処理を引き継ぐ（テイクオーバー）準備ができています。
• ALONE（単独运行）状態： クラスターが単一のノードで動作している場合（メンテナンス中や障害発生後など）に視覚的なアラートで通知し、冗長性が一時的に失われていることを示します。
• 再同期の進捗： 障害が発生したノードが復旧すると、バックグラウンドでのデータ再組み込み中、そのステータスがオレンジ色に変わり、「正常状態への復帰」フェーズにおいてもダウンタイムが発生しないようにします。

単なるステータスアイコンの表示にとどまらず、インターフェースにはワンクリックで実行できるフェイルオーバー制御機能が用意されています。これにより、計画メンテナンス時にプライマリの役割を手動で再割り当てでき、ユーザーの業務への継続的な可用性を確保できます。

ファームモードの SafeKit クラスターは、サービスの高い可用性と拡張性を実現するために設計されています。構成は、流入するトラフィックを同時に両方のノードに分散させることに焦点を当てています。

• 負荷分散サービス（[マクロ] タブ）: すべてのノードでアクティブに維持する特定のアプリケーションサービス（例: Apache、IIS、Nginx）を定義します。
• ハートビートネットワーク: ノードがファームから離脱したかどうかを検出するために使用される通信経路であり、離脱を検出すると即座に負荷の再配分をトリガーします。
• 仮想 IP（ファーム VIP）: ミラークラスターとは異なり、ファーム VIP はカーネルフィルタリングアルゴリズムを使用してノード間で共有され、ネットワークトラフィックを分散します。
• 負荷分散ルール: 送信元 IP アドレスまたはポートに基づいて、トラフィックの分散ポリシーを定義します。
• チェッカー: アプリケーションの健全性を監視し、プロセスの障害が検出された場合に自動再起動をトリガーします。

ファームモードでのクラスター監視により、すべてのノードがアプリケーションのパフォーマンスに貢献するアクティブ・アクティブ（Active-Active）構成のインフラストラクチャを可視化できます（この例では2つのノードを表示しています）。

• UP 状態（2つのノードで50%ずつ）: 健全なファームでは、両方のノードが「UP」（50%）状態にあり、共有された仮想 IP を介して両方のノードがクライアントからのリクエストをアクティブに受信し、処理していることを意味します。
• 自動再配分（再バランシング）: 1つのノードが障害で停止した場合、残りのノードがトラフィックの100%を引き受ける様子がコンソール上に視覚的に表示されます。生存しているノードはすでにアクティブ状態であるため、「フェイルオーバー」による遅延はありません（数秒程度の検出時間を除く）。
• ノードの組み込み: 修復されたノードが再起動されると、状態が「STOP」から「UP」へと遷移し、管理者の介入なしに自動的に自身の割り当て分の負荷の受信を開始します。
• データ同期なし: ファームモードのクラスターでは、ノードがステートレスであるか、バックエンドのデータベースを共有している（ミラークラスターで別途保護可能）ことが前提となるため、「オレンジ色」の再同期状態は存在しないことに注意してください。

単なるステータスアイコンの表示にとどまらず、インターフェースからはワンクリックでノードを管理できます。計画メンテナンスのために手動でノードを停止または起動させることができ、その間も共有仮想 IP がユーザーの活動を妨げることなく自動的にトラフィックを再配分します。