小規模な操作の単一障害点に関する質問


9
  1. 障害が発生したときにオンラインになるのを待機しているクラスターまたはスペアサーバーを用意する余裕がない場合は、1台のサーバーが提供するサービスを2台のサーバーに分割する可能性があります。したがって、サーバーAがダウンすると、クライアントは電子メールなどのアクセスを失う可能性があり、サーバーBがダウンすると、ERPシステムへのアクセスを失う可能性があります

    最初はこれの方が信頼性が高いように見えますが、単にハードウェア障害の可能性を高めるだけではありませんか?したがって、1つの障害が生産性に与える影響はそれほど大きくはありませんが、2倍の障害に備えることができます。

    私が「ビーフが少ない」と言うとき、私が本当に意味しているのは、品質の低下ではなく、コンポーネントのスペックの低下です。したがって、視覚化用に1台のマシン仕様を使用するのに対して、それぞれの負荷を軽減するために2台のサーバー仕様を作成しました。

  2. 多くの場合、サービスを維持するためにクラスタリングまたは移行を使用できるように、SANが推奨されます。しかし、SAN自体はどうですか?障害が発生する場所にお金をかけるとしたら、それは基本的なサーバーハードウェアではなく、ストレージに関係しています。なんらかの冗長SANがない場合、それらの冗長サーバーは私に大きな自信を与えません。個人的には、小規模な運用では、冗長コンポーネントとローカルドライブを備えたサーバーに投資する方が理にかなっています。SANの価格と柔軟性が費用対効果に優れている大規模な運用にはメリットがあります。しかし、小さな店では、少なくともフォールトトレランスではなく、私は議論を見ていません。

回答:


7

これはすべてリスク管理に要約されます。ITシステムの適切なコスト/リスク分析を行うと、どこにお金を費やすか、どのリスクに対処できるか、またはどのリスクに対処する必要があるかを理解するのに役立ちます。すべてに関連するコストがあります...これにはHAとダウンタイムが含まれます。

私は小さな場所で働いているので、この苦労を理解しています。私の中のITオタクはどこにも単一障害点を望んでいませんが、それをすべてのレベルで実行するコストは現実的な選択肢ではありません。しかし、ここに私が莫大な予算なしにできることがいくつかあります。ただし、これは必ずしも単一障害点を取り除くことを意味するわけではありません。

Network Edge:T1とComcast Businessの2つのインターネット接続があります。CARP for HAを使用して、pfSenseを実行している古いコンピューターのペアにファイアウォールを移動することを計画しています。

ネットワーク:ネットワークコア用にいくつかの管理されたスイッチを取得し、ボンディングを使用して2つのスイッチ間で重要なサーバーを分割することにより、スイッチの障害によってデータクローゼット全体が取り出されるのを防ぎます。

サーバー:すべてのサーバーにはRAIDと冗長電源が搭載されています。

バックアップサーバー:メインファイルサーバーほど強力ではない古いシステムがありますが、メインファイルサーバーのスナップショットを1時間ごとに取得するraid5にいくつかの大きなsataドライブがあります。これがダウンした場合にプライマリファイルサーバーになるように役割を切り替えるためのスクリプトを設定しています。

オフサイトバックアップサーバー:オンサイトバックアップと同様に、所有者の家の1つへのVPNトンネルを介してサーバーに毎晩バックアップを行います。

仮想マシン:Xenを使用して仮想マシン内で多数のサービスを実行する1組の物理サーバーがあります。これらはメインファイルサーバーのNFS共有で実行されており、必要に応じて物理サーバー間でライブマイグレーションを行うことができます。


ありがとう!しかし、私は本当に、クラスタリングやレプリケーションなしで1台ではなく2台のサーバーを使用することについて質問しています...本質的には2台のサーバー間でサービスを分割するだけです。そして、NASまたはSANがストレージに使用されている場合、それは単一障害点を再現するだけではありませんか?コンポーネントの観点からは、確かに常に冗長性があります(ドライブなど)。しかし、RAIDコントローラーがフリークしてアレイが壊れた場合、それは役に立ちません。
Boden、2010年

ええ、私はかつてRAID5アレイを失い、ホットスワップシャーシの動作不良の回路が原因で、チェーン全体がねじ込まれました。これは、以前のパラレルバスの場合と同じように、最新のシリアルの同等の問題ではありません。単一障害点の排除は、あなたが話している規模では費用対効果が高くありません。失敗のコストが非常に高い場合を除いては、そうではありません。提案は1つありますが、別のコメントでそれを行います。
3dinfluence 2010年

サーバーが2つしかない場合は、これを行うことができます。両方のサーバーに十分なストレージ容量/ RAMがあり、仮想化をサポートしていると仮定します。両方のサーバーでXenをセットアップできます。それぞれにcronジョブをセットアップして、仮想マシンの状態を保存し、結果のファイルを他の物理マシンに毎晩コピーします。そうすれば、システム障害が発生した場合でも、残りのハードウェアですばやく復旧して実行できます。少なくともその日には、これまでに起こった変化は何も起こらない。
3dinfluence 2010年

それは興味深い提案です。ただし、サーバーのコストが大幅に増加する可能性があります。それぞれが他方の負荷を実行できる必要があります(ただし、パフォーマンスが低下する可能性があります)。あなたはそのようなお金を使うつもりですが、それではなぜ2台の同じサーバーを1台でホットスタンバイとして使用しないのですか?
Boden

これはすべてコスト/リスク管理に戻ります。あなたは次のような質問に答えるのに最適な立場にあります。サービスをパフォーマンスが低下した状態で実行している場合、サービスがダウンしている場合よりも優れていますか?最後のスナップショット以降のすべての変更を緩めますか?あなたはいくつかのバックアップ戦略でそれを回避することができるかもしれません。規模の経済が有利に働かなければ、単一障害点のないポイントに到達するのは困難です。アマゾンクラウドはオプションかもしれません。しかし、仮想化によってこれは変わりつつありますが、そこにはまったく変化がなく、おそらく2台のサーバーではそうではありません。シープドッグのようなプロジェクトは面白そうだ。
3dinfluence 2010年

5

これは多くの答えのある質問だと思いますが、多くの小規模なショップではいくつかのサーバーソリューションが機能することに同意します。しかし、それは何が失敗するかに依存します。

冗長電源を除くすべてのベースをカバーするのは非常に困難で、高品質の電源と適切なバックアップが役立ちます。

重要なシステムにはBackup Exec System Recoveryを使用しています。毎日のバックアップではなく、回復ツールとして。可能な場合は、別のハードウェアに復元できます。また、ソフトウェアを使用して、バックアップイメージを仮想マシンに変換します。サーバーに障害が発生し、ハードウェアの修理を待つ必要がある場合は、別のサーバーまたはワークステーションでVMを起動し、足を引きずることができます。完璧ではありませんが、すぐに稼働できます。


3

SANについて:使用するほとんどすべてのものが冗長になります。単一のエンクロージャーであっても、内部にはデュアル電源、デュアルコネクタ、およびデュアル「ヘッド」があり、それぞれにすべてのディスクへのリンクがあります。デルが販売しているMD3000のようにシンプルなものでも、これらすべての機能を備えています。SANはボックスの中核となるように設計されているため、ランダムなハードウェア障害が発生してもほぼ耐えられるように構築されています。

そうは言っても、冗長性が常に最良の選択肢であるとは限らないという点があります。特に、複雑さが増す場合。(そしてそれは)尋ねるより良い質問は... "会社はダウンタイムをどれだけ受け入れるか"です。1日か2日のメールサーバーの損失が大きな問題ではない場合は、そのうちの2つを気にする必要はありません。しかし、Webサーバーの停止により毎分実際のお金が失われるようになった場合は、適切なクラスターを作成するために時間を費やす必要があります。


2

サーバーが多いほど、何かが壊れる可能性が高くなります。これは、それを見る1つの方法です。もう1つは、1つが壊れると、あなたが言っているように、きしみが100%上昇することです。

最も一般的なハードウェア障害は、上記のようにHDです。操作をどれだけ分割したいかに関係なく、ストレージをRAID化する必要があります。

運用の安定性とパフォーマンスの両方のために、1つの大規模なサーバーではなく、いくつかのサーバー(もちろんRAID化されている)に投票しました。ソフトウェアがリソースを要求するたびにぶつかることが少なくなり、乱雑さが減り、より多くのディスクが読み書きされるなどになります。


2

私は個人的に複数のサーバーを選びます。このシナリオでは、機器の故障が発生する可能性は低いと思います。はい、故障する可能性のある機器は他にもありますが、特定のユニットが故障する確率は一定でなければなりません。

非冗長/非HA構成で複数のサーバーを使用すると、障害が発生した場合に一部の作業を別のサーバーにオフロードできるようになります。だから、私のプリントサーバーがダウンしたとしましょう。プリントサーバーを修正しているときに、いくつかのプリンターをファイルサーバーにマップできれば、操作への影響は少なくなります。そして、それが本当に重要なのです。ハードウェアの冗長性についてよく話しますが、ハードウェアは運用を継続するためのツールにすぎません。


まあ、2枚のチケットを購入すると、実際にはそれほど大きな違いはないものの、宝くじに当たる確率は高くなります。6時間の修理が必要な1台のサーバーは、6時間の完全なダウンタイムによる損失を考慮に入れても、2台よりも安くなる可能性があります。一部のサービスは2台目のサーバーにすばやく移動できることに同意しますが、大きなサービスを移動するのに必要な時間は、障害が発生したサーバーを修復する時間よりも長くなる場合があります。「かもしれない」がキーワード。それは興味深い問題です。ご返信いただきありがとうございます。
Boden、2010年

1

私は小さな店(1人のIT部門)で働いており、どのような状況でも複数のサーバーを1つのサーバーに交換することはありません。サーバーのいずれかがダウンした場合は、現在欠落しているサービスを別のマシンに追加するか、スペアPCにセットアップするかを選択できます。ほとんどの場合、1〜2時間の停止で生活できますが、すべてのシステムの完全な停止で生活することはできません。私はどのサーバーもPCに置き換えることができますが、少なくとも一時的には、一度にすべてのサーバーを置き換えるのに十分なほど強力ではない場所にあるか、すぐに手に入れることができます。


1

元の投稿では、クラスターに余裕がないと仮定していますが、2つのサーバー(バックアップを含まない)のソリューションを検討しています。これは、クラスタを起動するのに十分な3つのサーバーが手元にあることを意味します。

SPoFを回避でき、中小規模のビジネスにも適切な中間ソリューションがあります。SANストレージを使用しないノード間レプリケーションです。

これは、たとえばProxmoxでサポートされています(ただし、XCP-ng / XenServerとおそらくESXiでもサポートされていると思います)。

3ノードのセットアップを考えてみましょう。すべてRAID、冗長PSU、冗長ネットワークを備えています。

  • ノードAとBには、CPUと大量のRAMが搭載されています。
  • ノードCはCPU / RAMでより控えめですが、多くのストレージがあり、高可用性ウォッチドッグおよびホストバックアップにクォーラムを提供するために使用されます。

次に、2つのオプション:

  1. すべてのVMは通常ノードAで実行され、ノードBで複製されます(適切なCPU sepcsが必要です)
  2. VMはノードAとBの間で分割され、ノードAからノードB、ノードBからノードAに相互に複製されます。

この種類のセットアップは、約1分のダウンタイム(ほぼVMの起動に必要な時間)で、ネットワーク障害、ノード全体の障害、および主要なノード障害(3つのうちのいずれか)を許容できます。欠点は、最後のレプリケーション以降のデータの損失です(これは、設定やハードウェアのパフォーマンスによっては、最低1分、最高数時間になる場合があります)。

2番目のオプション(VMは通常ノードAとBに分割されます)では、どのVMがオンラインに戻ることができるかを優先する必要があります。VMの負荷は通常2つのサーバーに分割されるため、それらすべてを単一のノードで実行すると、ノードのRAMが使い果たされるか、CPUが混雑する可能性があります。


0

「これは最初は信頼性が高いように見えますが、単にハードウェア障害の可能性を高めるだけではないのですか?」

  • ハードウェアの観点からは、それが実際に障害の可能性を高める方法はわかりません。ここには多くの変数があり、確率を調査したことはありませんが、単純化しすぎます。Dellが100,000ごとに1台の不良サーバーを作成するとします。チャンスが100,000分の1から100,000分の2(または50,000分の1)に変化しました。つまり、可能性は2倍ですが、それでも規模が大きいため、実際にはその可能性はそれほど変わりません。
  • ここでは視点が重要だと思います。「2倍の失敗に備えています。」多分あなたの観点からですが、あなたが与えた両方のシナリオで、電子メールは1つのサーバーで実行されており、ERPは1つのサーバーで実行されています。 したがって、EメールまたはERP(これはビジネスが関心を持っていること)の観点からは、実際には同じです。彼らが孤独になったり、自分のスペースが好きにならない限り;-)
  • 人の目から見てもいいと思います。人の過ちによる失敗の可能性が高いと思います。このようにすると、誰かが一度に1台のサーバーのみを台無しにする可能性があります。また、ロードなどの問題を特定しやすくなります。電子メールとWebサイトの両方がサーバー上で実行されている場合、問題がどこにあるかを見つけるために余分な時間がかかります。

これほど単純で大きな頑丈なサーバーが、良くも悪くも作られていることは決してありません。彼らはより高品質の部品を持っているかもしれませんが、おそらくより多くの熱を作り、適切に冷却されません。ビーフィーサーバーはより多くのRAMやより多くのCPUなどを備えているので、結局のところ、両方のシナリオで同じくらい多くのCPUを持っているので、サーバーは考えるのに適切なユニットではないかもしれません。

チャンスの複雑さのため、最も費用対効果の高いものは何でも私は思います。ライセンスを支払う必要がある場合、ライセンス構造によっては、1台の大きなサーバーの方が数台の小さなサーバーよりも安くなる場合があります。


ハードウェア障害の可能性が高まると思います。MTBFの1/2、両方のサーバーが同じであり、同じ時間と負荷で実行されると仮定した場合
Scott Lundberg 2010年

スコット:もう少し説明するために更新しました。また、私は本当にそれが遠近法についてだと思います。
Kyle Brandt

また、サーバーは同じではありません...
カイル・ブラント

失敗の可能性が高まります。2つのドライブを持つRAID0は、単一のドライブよりも早く故障する可能性が高くなります。もちろん、その場合はすべてを失うので、私が説明している状況と完全に類似しているわけではありません。サービスをすべて1つで実行するのではなく、2つのサーバーに分割します。単一の障害の結果はそれほど悪くはありませんが、障害が発生する可能性のあるハードウェアが増えました。
Boden

更新していただきありがとうございます!申し訳ありませんが、少なくとも "beefy"に関して、私の質問をもう少しよく修飾する必要がありました。ここで私が話しているのは、たとえば、デュアルプロセッサ、1トンのRAM、8台のハードドライブを搭載した1台のHP DL380と、シングルプロセッサを搭載した2台のDL380で、メモリとハードドライブが少なく、コントローラーメモリが少ないなどです。単なる例ですが、「ビーフの少ない」サーバーのビルド品質が単一の「ビーフィー」サーバーと同じであると想定しています)はい、この方法で2つのサーバーのコストが高くなりますが、いつ価値があるのでしょうか?
Boden

0

私のデフォルトのアプローチは、集中型インフラストラクチャを回避することです。たとえば、これは意味しない無SANノーロードバランサを。このような集中型のアプローチを「モノリシック」と呼ぶこともできます。

私はソフトウェアアーキテクトとして、お客様のインフラストラクチャと連携しています。つまり、独自のプライベートデータセンターを使用するか、AWSなどを使用することになります。そのため、私は通常、SANを使用するかどうかを制御できません。しかし、私のソフトウェアは通常複数の顧客にまたがっているので、ネットワーク上の分離された個々のマシンで実行されるかのように構築します。

電子メールの例

メールはレガシーシステム(機能する)なので奇妙です。今日電子メールが発明された場合、おそらくWebサーバーでRESTFul APIを使用し、データは通常のツール(トランザクションレプリケーション、増分バックアップ)を使用して複製できるデータベースにあります。

ソフトウェアアーキテクチャソリューションは、Webアプリケーションが利用可能なノードのリストの1つに(ランダムに)接続し、それが利用できない場合、別のノードに(ランダムに)接続しようとすることです。サーバーがビジー状態の場合、クライアントがサーバーを開始する可能性があります。ここでは、ロードバランサーがWebファームに接続する必要はありません。また、高可用性のためにSANは必要ありません。部門や地理ごとにデータベースを分割することもできます。

商品とは...

したがって、高価な1台または2台のサーバーと内部冗長性対策を備えたSANを使用する代わりに、いくつかの汎用低電力低コストマシンを使用できます。

  • シンプルさ -冗長性は純粋にデバイスの数に由来します。マシンの数で冗長性を簡単に確認できます。そして、より正確に彼らが失敗する可能性が高いと推定し、その準備をします。

  • 冗長性のパーセンテージ -2台のサーバーがある場合、1台に障害が発生すると、残り1台(50%)になります。10台のコモディティサーバーがあり、1台が故障した場合、残り9台(90%)

  • 在庫 -近くのどのショップからでも手頃な価格で簡単に入手できる商品デバイス。

  • 互換性 -ファイバーチャネル、およびディスクボリュームフォーマット、コモディティデバイス、ソフトウェアアーキテクチャに関するあらゆる種類の標準により、単一のデバイスモデルやブランドに縛られることはありません。

  • パフォーマンス -2つのデバイスがSAN上にある場合、それらは同じ部屋にある必要があります。コモディティマシンアプローチでは、5つのオフィスがある場合、各オフィスに2つあり、オフィス間にVPN WAN冗長性があります。これは、ソフトウェアと通信が1ms未満のアクセス時間でLAN上にあることを意味します。

  • セキュリティ -高レベルの冗長性を利用して、通常のプロセスとしてノードを簡単に再構築できます。一体型の2サーバークラスタを再構築したいですか?マニュアルを入手してください。マシンを頻繁に(自動化して)再構築することで、ソフトウェアを最新の状態に保ち、ハッカーやウイルスがネットワークに足を踏み入れるのを防ぎます。

注:複数のスイッチとゲートウェイルーターの冗長性が必要です。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.