ホットスペアホストとコールドスペアホスト？
同一のホットスペアホストがある複数のホストがあり、パッチが適用されて更新されているため、同じソフトウェアと構成が必要になります。障害が発生した場合、ネットワークケーブルが切り替えられ、DHCPサーバーが新しいMACアドレスで更新されます。通常、変更が必要なものがもう少しあるため、これが最適なケースです。
ホットスペアのホストを用意するのは電力の無駄であり、それを維持するのに時間の無駄だと思います。フェイルオーバーの場合は構成の変更が必要になるため、次のように質問します。
ホットスペアは古い学校をホストしていて、今はもっと良い方法がありますか？
ホットスペアホストを用意する代わりに、コールドスペアにし、ハードドライブを取り出してプライマリホストに配置し、RAIDを1から1 +1に変更するのが理にかなっています。障害が発生した場合は、ネットワークケーブルを変更し、DHCPサーバーを更新し、ハードドライブを取り出してコールドスペアに挿入し、電源を入れるだけです。私が見ているように、利点は2x2ディスクが常に同期しているため、1つのホストのみを維持し、フェイルオーバー時に構成を変更する必要がないことです。
それはいい考えですか？
Sobriqueは、手動介入によって提案されたソリューションが最適になる方法を説明しています 、および ewwhiteはさまざまなコンポーネントの障害の可能性について話します 。これらのIMOはどちらも非常に良い点であり、強く検討する必要があります。
しかし、これまで誰もコメントしていないように思われる問題が1つあり、少し驚いています。あなたは以下に提案します：
[現在のホットスペアホスト]をコールドスペアにし、ハードドライブを取り出してプライマリホストに配置し、RAIDを1から1 +1に変更します。
これは、OSがディスク上で行うことからユーザーを保護するものではありません。
ディスク障害から実際に保護するだけです。ミラー（RAID 1）からミラーのミラー（RAID 1 + 1）に移行することで、最初からの影響を大幅に軽減できます。各ミラーセットのディスク数を増やして（たとえば、2ディスクRAID1から4ディスクRAID1に）、通常の操作中の読み取りパフォーマンスを向上させることで、同じ結果を得ることができます。
それでは、これが失敗する可能性のあるいくつかの方法を見てみましょう。
- システムアップデートをインストールしていて、何かが原因でプロセスが途中で失敗したとします。 電源とUPSの障害 があるか、異常な事故が発生してカーネルのバグが発生している可能性があります（Linuxは最近かなり信頼できますが、それでもリスクはあります）。
- 更新によって、テスト中に検出されなかった問題が発生する可能性があります（システムの更新をテストしますか？）。プライマリを修正するときにセカンダリシステムへのフェイルオーバーが必要になります。
- ファイルシステムコードのバグが原因で、ディスクへの誤った無効な書き込みが発生している可能性があります。
- たぶん、太った（または悪意のある）管理者は
rm -rf ../*またはrm -rf /*の代わりにrm -rf ./*。 - おそらく、独自のソフトウェアのバグが原因で、データベースの内容が大幅に破損している可能性があります。
- たぶん、ウイルスがなんとか侵入します。
たぶん、たぶん、たぶん...（そして、提案されたアプローチが失敗する可能性のある方法は他にもたくさんあると思います。）しかし、結局、これは「2つのセットが常に同期している」「利点」に要約されます。時々あなたはそれらを完全に同期させたくない。
正確に何が起こったかに応じて、ホットスタンバイまたはコールドスタンバイのいずれかをオンにして切り替える準備をするか、適切なバックアップを行う必要があります。いずれにせよ、ミラーのRAIDミラー（またはRAIDミラー）は、障害モードにハードウェアストレージデバイスの障害（ディスククラッシュ）以外の多くのことが含まれる場合は役に立ちません。 ZFSのraidzNのようなものは、いくつかの点で少し良くなる可能性がありますが、他の点ではまったく良くなりません。
私にとって、これは、意図が何らかの災害フェイルオーバーである場合、最初から提案されたアプローチを無効にするでしょう。
はい、少し古い学校です。最近のハードウェアはそうではありませんただ失敗するそれほど頻繁ではありません。アプリケーションの可用性を高める（常に可能とは限りません）か、個々のホストの復元力を高めるために必要な項目に焦点を当てます...
ホストの場合：
- より良いハードウェアを購入します。
- サポート契約を結んでいることを確認してください。
- [〜＃〜] register [〜＃〜]サーバーのサポート契約（スペアパーツは登録データに基づいてローカルにストックされます！）
- 冗長電源、（ハードウェア？）RAID、冗長ファンを使用します。
- サーバーが上記の冗長機能に対応できない場合は、障害が発生した場合に自己修復できるように、予備のシャーシまたはコンポーネントを手元に置いておきます。
故障の頻度が低い順に、ディスク、RAM、電源、ファンが最も頻繁に見られます...システムボードやCPUの場合もあります。しかし、これらの最後の2つは、サポート契約を開始する必要がある場所です。
それはかなり非効率的です-特に、切り替えを行うための手動介入への依存のためです。
私はホットDRサイトを運営している場所で働いてきました。文字通り、プライマリと同じサーバーで、すぐに使用できるようになっています。ただし、DRの切り替えは自動化されたプロセスです。ケーブル接続、ちょっとした手間、切り替えについては話していませんが、ボタンを押すと、すべてが1つのサイトから別のサイトに切り替わります。
このアプローチは非常に費用がかかりますが、それはビジネス上の決定です。許容できるリスクと、目標を達成するために必要なお金です。原則として、リカバリ時間の目標には指数曲線があります。ゼロに近づくほど、コストが高くなります。
しかし、それがあなたの質問です。何is回復時間の目標、およびそれを達成するための最も効果的な方法は何ですか。サーバーが起動するのを待つのに数分かかります。午前4時にポップになったときに、誰かが調整と「回復タスク」を実行するのにどのくらい時間がかかりますか？
そして、許容できる停止はどのくらいですか？
「ホットリカバリ」を実行している場合は、クラスタリングを検討することをお勧めします。 VMWareをうまく利用してクラスタリングをかなり安くすることができます-'フェイルオーバー'からVM-物理的なものからでも-冗長ハードウェアを実行していないことを意味します（まあ、N + 1 2Nではなく）。
RTOが十分に長い場合は、ボックスのスイッチをオフにします。 RTOで十分であるため、バックアップからのコールドリビルドで問題がない場合があります。
それが古い学校であるという事実は、必ずしもホットスペアの使用を悪い考えにするわけではありません。
あなたの主な関心事は、理論的根拠、あなたが実行するリスクは何か、そしてホットスペアを実行することでそれらをどのように軽減するかです。私の認識では、ホットスペアはハードウェア障害にのみ対処するため、これは珍しいことではありませんが、実行する唯一のオペレーショナルリスクでも、最も可能性の高いものでもありません。 2番目の懸念は、代替戦略がより多くのリスク削減または大幅な節約を提供するかどうかです。
複数の手動フェイルオーバー手順を使用してホットスペアを実行すると、時間がかかり、失敗する可能性がありますが、HAクラスタースイートが主要なクラスター機能に変わる自動フェイルオーバーもあるようです。
もう1つは、同じ場所でのホットスタンバイまたはコールドスタンバイでは、地域の災害が発生した場合にビジネス継続性が提供されないことです。
ホットスペアまたはコールドスペアを持つという概念は依存していますhowアプリケーションは最初に構築されます。
つまり、データとサービスの負荷が複数のマシンに分散するようにアプリケーションが構築されている場合、システムを停止する単一のマシンの概念はなくなるはずです。そのような状況では、ホットスペアは必要ありません。代わりに、個々のマシン/コンポーネントが停止したときに処理するのに十分な余剰容量が必要です。
たとえば、標準のWebアプリケーションには、通常、Webサーバーとデータベースサーバーが必要です。 Webサーバーの場合は、2つ以上の負荷を分散するだけです。人が死んだとしても、大したことはありません。データベースは、参加しているマシン間ですべてのデータが同期されるマルチマスターになるように設計する必要があるため、通常はより困難です。したがって、単一のDBサーバーではなく、2つ（またはそれ以上）のデータニーズに対応することになります。グーグル、アマゾン、フェイスブックなどの大規模なサービスプロバイダーはこの道を進んでいます。開発時間にはより多くの初期費用がかかりますが、スケールアウトする必要がある場合は利益が得られます。
さて、アプリケーションがそのように構成されていない場合、またはアプリをレトロフィットすることが単に禁止されている場合は、ホットスペアが必要になる可能性があります。