QNAPの高可用性テスト：TS-h765eUペアでの1分未満のフェイルオーバー

高可用性は、データセンターの贅沢品から、通常の耐障害性計画における必須項目へと変化しました。中小企業やエッジサイトでは、POSシステム、監視システム、共有ストレージなどが稼働しており、これらがダウンすると1分ごとにコストが発生します。しかし、従来の解決策であるデュアルコントローラーのエンタープライズアレイは、支店のクローゼットや壁掛けラックではなく、データセンター向けに設計・価格設定されています。このミスマッチにより、小規模なIT部門はデータ保護のためのバックアップやスナップショットは確保できても、継続性のための対策が何もないという状況に陥っています。どんなに優れた設計であっても、シングルコントローラーのNASは依然として単一障害点となるのです。

QNAPにとって高可用性は目新しい分野ではなく、デュアルコントローラーハードウェアとレプリケーションベースの復旧パスを提供してきた実績があります。QuTS hero h6.0で変化したのは効率性です。新しい高可用性マネージャーは、通常のハードウェア上でオペレーティングシステムにクラスタリング機能を組み込み、2台の同一のNASユニットを単一のIPアドレスの背後でアクティブ/パッシブクラスタとして構成します。これにより、一方のユニットがダウンしても、もう一方のユニットが引き継ぎ、クライアントはほとんど気づきません。IT投資の適正化を目指す組織にとって、これは2台目のNASを追加するだけで高可用性を実現できる、つまり2級のインフラストラクチャを導入する必要がないことを意味します。

それが今回の提案です。実際にどれだけうまく機能するかを確認するため、ラボで2台のQNAP TS-h765eUシステム（Seagate IronWolf Proハードドライブとキャッシュ用のQNAP E1.S SSDを搭載）からHAクラスタを構築し、エッジロケーションで障害が発生するのと同じ方法でクラスタを破壊してみました。転送中にアクティブノードの電源を切断し、ハートビートは維持したままネットワーク接続を切断しました。どちらの場合も、疑問は同じでした。ファイル転送は継続されるのか、そして障害が発生したノードが復旧したとき、どのようなリカバリが行われるのか、ということです。

QNAP TS-h765eUの概要

TS-h765eUは、比較的シンプルなハードウェア構成であるため、HA（高可用性）の構成要素として興味深い選択肢となります。筐体は奥行きわずか292.1mm（12インチ）の1UショートデプスラックマウントNASで、小型メディアキャビネット、壁掛けネットワークラック、フルデプスシャーシが収まらないエッジ環境向けに設計されています。各ユニットは前面に4つの3.5インチSATAドライブベイ、背面に3つのE1.S/M.2 PCIe NVMeスロットを備えており、容量確保のための回転式ディスク、キャッシュや高速階層のためのフラッシュといったハイブリッドストレージとしての特性を備えています。

QNAPはこれを長期供給モデルとして位置づけており、2031年まで供給が保証されているため、複数の拠点でプラットフォームを標準化しようとしている組織にとって重要な意味を持つ。

TS-h765eUの内部には、最大3.4GHzで動作するクアッドコアチップであるIntel Atom x7405Cが搭載されており、8GBのDDR5メモリ（最大16GBまで拡張可能）とインバンドECCが組み合わされています。ネットワークは2.5GbEポートが2つ搭載されており、E1.SベイをQNAPのQXG-ES10G1Tモジュールに交換することで10GbEも利用可能になります。

製品仕様	QNAP TS-h765eU
CPU	Intel Atom x7405C クアッドコア、最大3.4GHz
メモリ	8GB DDR5、16GBまでアップグレード可能（インバンドECC対応）
ドライブベイ	4×3.5インチSATA
フラッシュスロット	3 x E1.S / M.2 PCIe NVMe
Networking	2 x 2.5GbE、オプションのQXG-ES10G1T E1.Sモジュール経由で10GbE
フォームファクター	奥行き292.1mm（12インチ）の1Uショートデプスラックマウント
オペレーティングシステム	QuTS hero h6.0 (ZFSベース)
利用状況	2031年までの長期供給モデル

 

この評価では、各ノードにSeagate IronWolf Pro 30TBハードドライブ（ST30000NT011）を4台RAID 5ストレージプールとして搭載し、さらにキャッシュとしてQNAP SSD700 E1.S 3.84TBドライブ（SSD700D1-003T84）を2台RAID 0で搭載しました。両システムとも、QuTS hero h6.0.0.3500とHigh Availability Manager 2.0.421を実行しました。

QuTS hero h6.0とHAマネージャーアーキテクチャ

QuTS hero h6.0 の目玉機能は、従来のアクティブ/パッシブ構成を採用した高可用性マネージャです。アクティブノードとなる 1 台の NAS がすべてのデータとサービスを提供します。パッシブノードとなる 2 台目の NAS は、専用のハートビート接続を介してアクティブノードと継続的に同期し、いつでも引き継ぎできる状態を維持します。クライアントはどちらのノードにも直接通信することはありません。代わりに、クラスタは単一の IP アドレスとホスト名を提供し、現在アクティブなノードがそれに応答します。フェイルオーバーが発生すると、クラスタの IP アドレスがバックエンドでトラフィックをリダイレクトするため、マップされたドライブ、iSCSI イニシエータ、およびバックアップジョブのポイントを再設定する必要はありません。

ハートビートリンクは、この設計の基盤となるものです。QNAPでは、2つのユニット間にスイッチを介さずに直接接続する必要があり、ヘルスチェックトラフィックとノード間のブロックレベルデータ同期の両方を伝送します。通常のネットワークを介してクライアント向けのトラフィックを処理するのは、別のクラスタ接続です。スプリットブレイン対策の仕上げとして、クォーラムサーバーがあります。これはネットワーク上の3番目の監視役であり、ハートビートが途絶えた際にノードが自身を昇格させるべきかどうかを判断するのに役立ちます。スプリットブレインとその防止策となる展開トポロジーについては、このレビューの後半で詳しく説明します。

QNAPによると、h6.0ではNASサービスの90%以上がHAに対応しており、JBOD拡張エンクロージャーでクラスタの容量を拡張できるとのことです。ただし、注意点もあります。h6.0のもう一つの目玉機能であるイミュータブルスナップショットは、現時点ではHAクラスタ内ではサポートされていないため、管理者は当面、2つの保護機能のどちらかを選択する必要があります。また、HAにはモデルとファームウェアが一致する同一のシステムが2台必要で、ペアリングウィザードで確認してから先に進みます。

QNAP HAクラスタの構築

クラスタの作成は、同一のハードウェアを備えた独立して構成された 2 台の TS-h765eU ユニットから始まります。指定されたアクティブ ノードから、高可用性マネージャ ウィザードが短いペアリング プロセスを実行します。ウィザードはハートビート リンクを介してパッシブ ノードを検出し、ネットワーク インターフェイスに役割を割り当てるように求めます。役割は、クラスタへのアクセス用の通信チャネルとして機能するクラスタ接続と、QNAP がデータの同期専用であり、デバイス間の直接リンクである必要があると指摘するハートビート接続です。今回の構築では、ウィザードはアダプタ 1 にハートビートを、アダプタ 2 にクラスタ接続を割り当てました。

次に、クラスタの識別を行います。クラスタのホスト名とクラスタのIPアドレスを割り当てます。これらは、以降クライアントが使用する単一のアドレスになります。私たちのクラスタは、176.16.248.34にSR-Testという名前を付け、QNAP-HA1（176.16.248.33）とQNAP-HA2（176.16.254.157）というノードの前に配置しました。この2つのノードは、ラボネットワーク上の異なる/24サブネットにあります。ウィザードは、これらのノードを問題なくペアリングしました。

設定が確定すると、ウィザードはハートビート接続の設定、環境設定、サービスの停止、システム設定の構成、サービスの開始という5つのステップからなるビルドを実行します。UIには、この間は何も電源を切らないようにという注意書きが表示されます。私たちのシステムでは、ビルド自体は約5分半で完了し、その後HA Managerがクラスターの作成を報告し、クラスターIPアドレスにリダイレクトしました。2台のスタンドアロンNASユニットからサービス提供クラスターへの移行は、ウィザードの実行時間で10分未満で完了しました。

より負荷の高い処理は初期同期で、アクティブノードがストレージプールをブロックごとにパッシブノードに複製します。HA Manager は、ダッシュボード上部に進行状況バー、アイテム数、所要時間の見積もりを表示し、同期が完了するまで切り替えとファームウェアの更新が利用できないことを警告することで、この処理を明確に示します。このフェーズ中にハートビート統計を監視することは、このプロセスで最も印象的な部分の一つでした。転送速度はおよそ 900 MB/秒から 1.2 GB/秒の範囲で、レイテンシは数百マイクロ秒でした。代表的な値としては、1 GB/秒で 232 マイクロ秒を記録しました。初期同期は約 10 分で完了し、ダッシュボードの冒頭の見積もりである 9 分とほぼ一致しました。

同期が完了すると、ダッシュボードは「良好」ステータスに落ち着きます。クラスターは正常で、ハートビートも接続されており、両方のノードのCPU、メモリ、ディスクスループット、ネットワーク統計が並べて表示され、下部にはプールごとの同期ステータスが表示されます。これは、管理者が実際に抱く2つの疑問、「クラスターは正常か？」「データは同期されているか？」に答える、情報量の多い分かりやすいビューです。

フェイルオーバーテスト1：アクティブノードの電源喪失

最初の障害シナリオは、非常に単純なものです。アクティブノードで完全な電源喪失が発生しました。クライアントからクラスタIP上のSMB共有へのWindowsファイルのコピーを開始しました。コピー対象は、Windows 11とRocky LinuxのISOイメージ、および2つのKali Linux VMアーカイブを含む6つのファイルからなる41.1GBのバッチです。その後、転送の途中でQNAP-HA1の電源を切りました。

クライアントの視点から見ると、電源を抜いてからデータ転送が再開されるまで、コピー処理は1分弱、およそ50秒間停止しましたが、エクスプローラーにはエラーは表示されませんでした。転送ダイアログは進行状況が停止したままになり、その後、QNAP-HA2がアクティブに昇格すると再開しました。HAマネージャーは、アクティブノードの役割のフェイルオーバーが進行中であることを簡単に報告した後、警告バナーを表示しました。「パッシブノードQNAP-HA1を検出できません。ノードの電源が入っていてネットワークに接続されていることを確認してください。」というメッセージが表示されました。クラスタが1つのノードで実行されている間、転送は同じクラスタIPに対してフルスピードで継続されました。これはまさに、HAが約束する、機能が低下しているが動作可能な状態です。

QNAP-HA1への電源復旧により、自動的に逆の処理が開始されました。電源喪失から約10分後、ノードは起動してパッシブメンバーとして再接続し、HA ManagerはアクティブノードQNAP-HA2からQNAP-HA1へのデータ同期を開始しました。この同期の進行状況と所要時間の見積もりはダッシュボードに表示され、ファイルコピーは中断されることなく継続されました。フェイルバックには介入は不要でした。再同期が完了すると、クラスターは約35秒間転送を一時停止し、アクティブロールをQNAP-HA1に戻した後、コピーが完了するまで実行されました。処理の終了時には、クラスターは良好な状態に戻り、転送は100%完了していました。これは、単一のコピージョブ内で、ハード電源障害、単一ノード期間、ノード復旧、およびフェイルバックを乗り越えた結果です。

フェイルオーバーテスト2：ハートビートが維持された状態でのネットワーク障害

2つ目のシナリオはより微妙で、現実世界ではより一般的と言えるでしょう。アクティブノードがクライアントとのネットワーク接続を失う（スイッチポートの故障、ケーブルの引き抜き、トランシーバーの不具合など）ものの、ノード自体は動作を続け、ハートビートリンクは維持されるという状況です。この場合、両方のノードが稼働しており、互いに認識できるため、スプリットブレイン対策が非常に重要になります。クラスタは、どちらのノードがクラスタIPを所有すべきかを決定する必要があるからです。

クラスターIPアドレスに対して同じWindowsファイルのコピーを繰り返し実行し、アクティブノード上のクラスターネットワークインターフェイスを切断しました。クラスターがサービスを別のノードに移動している間、転送は約45秒間一時停止し、その後、問題なく再開しました。HAマネージャーは障害を正確に検出し、ノード上のクラスターネットワークインターフェイスアダプタ2が切断されたことを警告し、スイッチ接続を確認するよう促しました。さらに、切断されたノードはそのインターフェイスを介してクォーラムサーバーに到達できなくなったことも指摘しました。このように、特定のインターフェイス、ノード、および結果を明示することで、一部のHA実装で採用されている一般的な劣化フラグよりも診断精度が向上しています。

ネットワークを再接続するとノードはクラスタに戻り、フェイルバックは1分以内に自動的に完了しました。アクティブな役割がQNAP-HA1に戻るまでの約30秒間の一時停止が、クライアント側で確認できる唯一の変化でした。同じコピージョブは、2回の切り替えを連続して実行しても、ファイルエラーは1つも発生しませんでした。SMBセッションがこれよりもはるかに些細なことで停止するのを経験したことがある人にとって、これは今回の取り組み全体の最大の成果と言えるでしょう。

HAを正しく導入する方法：スプリットブレインとネットワークトポロジー

弊社のようなフェイルオーバーテストはクラスタの動作を証明しますが、HAペアが本番環境でどれだけ安定して動作するかは、NASユニット自体だけでなく、周囲のネットワーク環境にも大きく左右されます。HA Managerが想定しているシナリオ（ノード障害、スイッチポートの障害、アップリンクの切断など）はすべて、2つのノード間の通信経路のうち少なくとも1つが障害発生後も維持されるという前提を共有しています。この前提を守ることがHA導入において最も重要な決定事項です。なぜなら、そうしないと、あらゆる高可用性アーキテクチャが回避しようとしている唯一の状態、つまりスプリットブレインが発生するからです。

QNAP はこのシナリオを文書化しています。スプリットブレインは、両方のノードが相互に通信を失いながらも独立して動作し続け、それぞれがアクティブな役割を引き継ぐ場合に発生します。2 つのノードがそれぞれクラスターの所有者であると信じ、書き込みを受け入れる意思がある場合、それぞれが共有リソースを同時に制御しようとする可能性があるため、データの不整合やストレージの破損につながる可能性があります。文書化されている原因は、まさに予想どおりです。ノード間のネットワーク切断、ハートビートの失敗、不安定なネットワークパスです。これらの共通点に注目してください。スプリットブレインは、単一のノード障害によって発生するのではなく、2 つの正常なノード間のすべてのパスが同時に失敗したときに発生します。これはトポロジの問題であり、トポロジによる解決策があります。

展開ルールは予想どおりに展開される。

ハートビートは、2つのノード間を直接ケーブルで接続して実行してください。QNAPはハートビートに直接リンクを必要としますが、それには理由があります。経路にスイッチ、トランシーバー、共有インフラストラクチャがないため、ハートビートを遮断できるのはノード自体のみであり、まさにイベントフェイルオーバーが想定している状況に対応できます。これらの奥行きの短いTS-h765eUユニットが隣接して設置されることが多い同一ラック環境においては、他に方法はありません。

ノードが分離されている場合は、ハートビートとクライアントのトラフィックを物理的に独立したパスで維持してください。直接ケーブル接続が不可能な場合は、クラスタ接続に使用するスイッチとは別のスイッチを経由してハートビートをルーティングしてください。両方の接続が同じスイッチを通過すると、そのスイッチが単一障害点となり、ノード間のすべてのパスを同時に切断してしまう可能性があります。これにより、通常のスイッチ障害がスプリットブレイン状態を引き起こす可能性があります。共有インフラストラクチャの1つでNASユニットを互いに分離できてしまうのであれば、2台のNASユニットを購入する意味がなくなってしまいます。これが、当社のネットワークフェイルオーバーテスト方法の背後にあるロジックです。ハートビートが接続されたままクライアント側のケーブルを抜くことで、適切に分離されたトポロジで実際に発生するスイッチまたはケーブル障害をシミュレートし、ハートビートが稼働しているため、スムーズに引き継ぎを行うことができます。

クォーラムサーバーを有効にします。QNAPの3つ目の安全対策は、ネットワーク上の監視サーバーです。これは、High Availability Manager > 設定 > フェイルオーバーポリシー > クォーラムサーバーで設定できます。ノードが直接リンクを失ってもネットワークにアクセスできる場合、クォーラムサーバーは両方のノードを監視し続け、その状態を中継します。これにより、各ノードは自身を昇格させる前に、独立したタイブレーカーとして機能します。クォーラムサーバーの接続状態は、ハートビートとともにHA Managerダッシュボードに常時表示されるため、その状態を一目で確認できます。

万が一最悪の事態が発生した場合でも、QuTS hero はスプリットブレインを防御的に処理します。接続が復旧し、ノードが再び通信できるようになると、ノードはステータス情報を交換し、両方がアクティブ ロールを保持していたことを認識し、2 つの分岐したデータセットのマージを回避するために、SMB や iSCSI を含むほとんどのサービスを意図的に停止します。その後、HA Manager は、2 つのパスを備えたスプリットブレインからの復旧ウィザードを表示します。オプション 1 では、選択した単一のノード上のデータを保持します。もう一方のノードは消去され、パッシブ メンバーとしてリセットされ、再同期されます。これは、どちら側に正しいデータがあるかがわかっている場合の高速な方法です。オプション 2 では、一方のノードでサービスを再開し、もう一方のノードをクラスタから完全に削除することで、両方のノード上のデータを保持します。これにより、手動で再参加する前にデータを検証および調整できます。これは合理的な復旧モデルですが、復旧にはダウンタイムと完全な再同期が必要です。スプリットブレインは、復旧を計画するものではなく、デプロイメント設計によって防止する状態です。上記の 3 つのルールは、ケーブルと設定パネルでの 5 分以外にコストはかかりません。

監視と管理

運用2日目の作業はHA Managerアプリで行われ、クラスタの状態、ノードごとのリソース使用量、イベントログ、手動切り替えを含むノード管理が1つの画面に統合されます。ダッシュボードの警告バナーは、テスト中に診断に十分なほど具体的であることが証明されました。一般的な劣化フラグではなく、障害が発生したインターフェースとノードを正確に特定してくれたのです。

QNAPは、HA（高可用性）機能をハードウェア自体にも組み込んでいます。HAクラスタでは、各NASのLCDパネルにクラスタ名、ノードの現在の役割、クラスタIPが表示され、ステータスLEDでHAの状態が一目でわかります。アクティブノードは緑色点灯、パッシブノードは緑色点滅、HAエラーは赤色点灯です。奥行きの短い同一のユニットが多数設置されたラックでは、ブラウザを開かなくてもアクティブノードを識別できるのは、技術者にとって嬉しい細やかな配慮です。フリート展開の場合、AMIZcloudはHAグループの中央集中型クラウド監視機能を追加し、サイト全体でクラスタの状態、レイテンシ、アラートを表示します。

最終的な考え

High Availability Manager は、私たちが試した 2 つの障害モードの両方で、そのコアとなる約束をしっかりと果たしました。アクティブ ノードでハード電源が切断された場合、Windows ファイルのコピー処理は約 50 秒間停止しましたが、失敗したファイルはゼロでした。クライアントのネットワーク接続が切断された場合は約 45 秒の遅延が発生しました。いずれの場合も、同じコピー ジョブはノードの復旧と自動フェイルバックを経て、1 分未満の一時停止が 2 回程度発生するだけで済みました。クライアント側で何かを再設定する必要は一切ありませんでした。アプリケーション、ファイル共有、ユーザー ワークフローは、フェイルオーバーの前、最中、後を通して、単一の IP アドレスとホスト名で動作し続けました。セットアップも簡単です。2 台のスタンドアロン ユニットをウィザードで 10 分以内にサービング クラスタに構成し、最初の同期に 10 分を要しました。また、ダッシュボードは、何かが壊れたときに、どのインターフェイス、ノード、接続に注意すべきかを正確に教えてくれました。

ただし、HAのコストは無視できません。あらゆるものを2つずつ購入する必要があり、パッシブノードは稼働するまで遊休状態になります。h6.0のもう一つの目玉機能であるイミュータブルスナップショットは、現在のHAクラスタでは利用できないため、管理者はどちらかを選択する必要があります。また、ハードウェアが同一である必要があるため、アップグレードはペアで行われ、予算が制約される可能性があります。

最終的にどうなるかは適切なサイジングの問題であり、HA Manager が最も効果を発揮するのは中小企業やエッジ環境への展開です。デュアルコントローラのエンタープライズアレイと比較すると、奥行きの短い TS-h765eU ユニットを 2 台使用することで、コスト面で全く異なるメリットが得られます。これは、SMB 層でデュアルコントローラを購入する主な理由となっているコントローラの損失という障害シナリオにも対応できます。DIY レプリケーション方式、スナップショットの出荷、rsync ジョブ、バックアップとリストアと比較すると、違いは復旧時間です。これらの方式はデータを保護しますが、クライアント接続の再構築に何時間もかかります。一方、HA Manager のテストでクライアントから見える最悪のイベントは、1 分間の一時停止でした。同様に重要なのは、HA Manager が吸収できない障害、つまりすべてのノード間パスが同時に切断されるという障害は、直接ハートビートケーブル、分離されたネットワークパス、および有効化されたクォーラムサーバーによって防止できることです。トポロジーに必要なのは、ケーブル 1 本と設定パネルでの 5 分だけです。

最後に、2ノード構成特有の点を1つ挙げます。クラスターが最も脆弱になるのは再同期時です。このとき、一方のノードにデータの正常なコピーが1つだけ保存され、その下のドライブがフル稼働している状態になります。これが、HA構成においてドライブの選定を真剣に検討すべき理由であり、今回の構成で使用したSeagate IronWolf Pro 30TBのようなNAS対応ディスクが、スタンドアロン構成よりも重要になる理由です。これらのディスクの役割は、この再同期時に問題が発生するのを防ぐことにあるのです。

QNAP TS-h765eUとQuTS hero h6.0は現在発売中です。詳細については、QNAP TS-h765eUの製品ページをご覧ください。

本レポートはQNAPの提供でお届けします。本レポートに記載されている見解および意見はすべて、対象製品に対する当社の公平な見解に基づいています。