ホットスペアホストとコールドスペアホスト？

複数のホストがあり、同じホットスペアホストがあり、パッチが適用されて更新されているため、同じソフトウェアと構成に非常に近くなります。障害が発生した場合は、ネットワークケーブルが切り替えられ、DHCPサーバーが新しいMACアドレスで更新されます。これは最良のケースです。通常、修正が必要なものが少し多いためです。

ホットスペアホストを用意するのは電力の浪費であり、それを維持するのに時間の浪費だと感じています。フェイルオーバーの場合は構成の変更が必要なので、次のことを質問します。

ホットスペアホストは古い学校で、今より良い方法がありますか？

ホットスペアホストを使用する代わりに、コールドスペアにして、ハードドライブをプライマリホストに配置し、RAIDを1から1 + 1に変更することは理にかなっていますか。障害が発生した場合は、ネットワークケーブルを変更し、DHCPサーバーを更新し、ハードドライブをコールドスペアに挿入して電源を入れるだけです。私が見ると、2x2ディスクは常に同期しているので、フェイルオーバー時に1つのホストのみを維持し、構成を変更する必要がないという利点があります。

それは良い考えですか？

Sobriqueは、手動による介入があなたのsup-最適であることが提案された解決策原因について説明し、様々な部品の故障の可能性についてewwhite会談を。これらのIMOはどちらも非常に優れた点であり、強く検討する必要があります。

しかし、今のところ誰もコメントしていないように見える問題が1つあります。次のことを提案します。

[現在のホットスペアホスト]をコールドスペアにし、ハードドライブをプライマリホストに配置して、RAIDを1から1 + 1に変更します。

これは、OSがディスク上で行うことからユーザーを保護するものではありません。

ミラー（RAID 1）からミラーのミラー（RAID 1 + 1）に移行することで、最初からの影響を大幅に減らすことで、ディスク障害から本当に保護するだけです。各ミラーセットのディスク数を増やすことで同じ結果を得ることができ（たとえば、2ディスクRAID 1から4ディスクRAID 1へ）、通常の操作中の読み取りパフォーマンスが大幅に向上します。

それでは、これが失敗する可能性があるいくつかの方法を見てみましょう。

• システムアップデートをインストールしていて、何かが原因でプロセスが途中で失敗したとします。おそらく電源とUPSの障害が発生している、またはあなたがひどい事故に遭って、致命的なカーネルバグに遭遇したかもしれません（最近のLinuxはかなり信頼できますが、それでもリスクはあります）。
• おそらく、更新により、テスト中に把握できなかった問題（システム更新をテストしますか？）が発生し、プライマリを修正する間、セカンダリシステムへのフェイルオーバーが必要になります。
• ファイルシステムコードのバグが原因で、ディスクに誤った無効な書き込みが行われる可能性があります。
• 多分ファットフィンガー（または悪意のある）管理者がするrm -rf ../*か、rm -rf /*代わりにrm -rf ./*。
• たぶん、あなた自身のソフトウェアのバグがデータベースの内容を大いに破壊する原因になるかもしれません。
• ウイルスがこっそり侵入したのかもしれません。

多分、多分、多分...（そして、あなたの提案したアプローチが失敗する可能性がある多くの方法があると確信しています。）しかし、結局これはあなたの "2つのセットが常に同期している" "利点"に要約されます。完全に同期したくない場合があります。

正確に何が起こったかに応じて、ホットスタンバイまたはコールドスタンバイをオンに切り替えたり、適切なバックアップを行う準備ができている場合です。どちらの方法でも、障害モードにハードウェアストレージデバイスの障害（ディスククラッシュ）以外の多くのものが含まれている場合、ミラーのRAIDミラー（またはRAIDミラー）は役に立ちません。ZFSのraidzNのようなものは、いくつかの点では少し優れている可能性がありますが、他の点ではまったく優れていません。

私にとって、これは、意図が何らかの種類の災害フェイルオーバーである場合、提案されたアプローチを最初から実行不可能にするでしょう。

はい、少し古い学校です。最近のハードウェアは、それほど頻繁に故障するだけではありません。アプリケーションの可用性を高める（常に可能とは限りません）か、個々のホストの回復力を高めるために必要なアイテムに焦点を当てます...

ホストの場合：

• より良いハードウェアを購入します。
• サポート契約があることを確認します。
• サーバーのサポート契約を登録します（スペアパーツは登録データに基づいてローカルに在庫されています！）
• 冗長電源、（ハードウェア？）RAID、冗長ファンを使用します。
• サーバーが上記の冗長機能に対応できない場合は、障害が発生した場合に自己修復できるように、予備のシャーシまたはコンポーネントを手元に用意してください。

障害の発生頻度が低い順に、ディスク、RAM、電源、ファンが最も頻繁に表示されます...システムボードまたはCPUが時々あります。しかし、最後の2つは、サポート契約が交わすべき場所です。

それはかなり非効率的です-特に切り替えを行うための手動介入に依存しているためです。

私はホットなDRサイトを運営している場所で働いていました-文字通り、プライマリと同じサーバーで、すぐに行く準備ができています。ただし、DRスイッチオーバーは自動化されたプロセスです。つまり、ケーブル配線、少しいじる、スイッチではありません。ボタンを押すと、サイト間ですべてが反転します。

このアプローチは驚くほど高価ですが、それはビジネス上の決定です-許容可能なリスク対目的を達成するために必要なお金。原則として、目標復旧時間には指数曲線があります。ゼロに近づくほど、コストが高くなります。

しかし、それが実際の質問です。復旧時間の目標は何ですか、それを達成するための最も効果的な方法は何ですか。サーバーが起動するまで数分かかります。午前4時にポップになると、誰かが調整と「回復タスク」を行うのにどのくらいの時間がかかりますか？

また、許容可能な停止時間はどれくらいですか？

「ホットリカバリ」を実行している場合は、クラスタリングを検討することをお勧めします。VMWareを上手に使用すると、クラスタリングがかなり安くなる可能性があります。つまり、物理マシンからでもVMに「フェイルオーバー」するということは、冗長ハードウェアを実行していないということです。（まあ、2NではなくN + 1）。

RTOが十分に長い場合は、ボックスをオフにします。RTOは、バックアップからのコールド再構築が問題なく十分であることに気付く場合があります。

それが古い学校であるという事実は、必ずしもホットスペアの使用を悪い考えにするわけではありません。

あなたの主な関心事は、根拠、あなたが実行するリスクは何か、そしてホットスペアを実行することでそれらをどのように軽減するかです。私の考えでは、ホットスペアはハードウェア障害にしか対処しないため、これは珍しいことではありませんが、実行する唯一の運用リスクでも、最も可能性も高いものではありません。2番目の懸念は、代替戦略がリスクの軽減または大幅な節約を提供することです。

複数の手動フェイルオーバー手順でホットスペアを実行すると時間がかかり、失敗する可能性がありますが、HAクラスタースイートが自動クラスター化してメジャークラスタースタックになることもあるようです。

もう1つは、同じ場所でのホットスタンバイまたはコールドスタンバイでは、ローカルな災害が発生した場合にビジネスの継続性が提供されないことです。

ホットスペアまたはコールドスペアの概念は、最初にアプリケーションをどのように構築するかによって異なります。

つまり、アプリケーションがデータとサービスの負荷が複数のマシンに分散するように構築されている場合、システムを停止させる単一のマシンの概念はなくなるはずです。そのような状況では、ホットスペアは必要ありません。代わりに、個々のマシン/コンポーネントが死んだときに処理するのに十分な過剰容量が必要です。

たとえば、標準のWebアプリケーションには通常、Webサーバーとデータベースサーバーが必要です。Webサーバーの場合は、2以上をロードバランスします。人が死んだとしても、大したことはありません。データベースは、参加するマシン間ですべてのデータが同期されるマルチマスターになるように設計する必要があるため、通常はより困難です。したがって、単一のDBサーバーの代わりに、2つ（またはそれ以上）のサーバーができ、どちらもデータのニーズに対応しています。グーグル、アマゾン、フェイスブックなどの大規模なサービスプロバイダーがこの道を進んでいます。開発期間には先行投資が多くなりますが、スケールアウトが必要な場合は効果があります。

アプリケーションがこのように構成されていない場合、または単にアプリケーションをレトロフィットすることが禁止されている場合は、はい、おそらくホットスペアが必要になります。