中小企業向けの高いサーバー可用性

ある朝出てこないサーバーで少し怖がった後、上位の企業はビジネスに高可用性/フェイルオーバーのセットアップが必要であると判断しました。

会社には5つのメインサーバー（4x Linux、1x OpenBSD）があり、すべてを稼働させる必要があります。3台のサーバーはかなり標準（ファイル/ Web /データベース）で、4台目はほとんどのネットワークルーティングとWebプロキシを処理し、5台目は電話システムをサポートし、非標準のハードウェアを備えています。

私の上司は、サーバー障害のターンアラウンド時間は30分未満であると述べています。

この分野での私の経験は存在しません（私は「昇格した」プログラマーです）、私の質問は次のように要約されます。

• これは、平均的なサーバー管理スキルを持っている人でも試してみるべきものです。もしそうなら、私は何を読み、誰と話すべきですか？

ありがとう。

数値をまとめて、規定の「要件」を満たすためのコストを説明することから始めて、それが予算内に収まるかどうかを確認する必要があると思います。要件を満たすために使用されるすべての「通常の」方法（フェールオーバークラスタリング、「ホットマイグレーション」機能を備えたハイパーバイザーなど）に満足できない場合は、できるコンサルタントを見つけるのがよいでしょう。手伝う。

フィージビリティスタディに関連する費用が発生しますが、適切なソリューションが規定の要件に適合しないことを発見するのにかかる費用ははるかに少なくなります（つまり、管理者が期待をより現実的に設定する必要があることを意味します）より多くのお金をポニーアップする必要があります）、要件をまったく満たさず、その過程で大量のお金を吹き飛ばすことになる、半ば嫌いなことをするのにかかるよりも多くなります。

あなたのボスがその数を空中から引き出したように聞こえます。おそらく彼はいくつかの分析を行っており、さまざまなシステムのダウンタイムに関連する時間あたりのコストが何であるかを知っていますが、私はそれを疑っています。現実に結び付けられていない、空っぽの数字のように聞こえます。すべてのシステムがそのような可用性を必要とする場合、私は驚きます。ビジネスを研究する過程で、機能のサブセットのみがそのような程度のアップタイムとフォールトトレランスを必要とすることを発見するかもしれません（したがって、そのようなソリューションは最終的に低コストになります）。電話と基幹業務アプリケーションはそこにあると確信していますが、他のいくつかのシステムでのダウンタイムにはある程度の耐性があるかもしれません。

私の直感では、冗長化されたハードウェア間での仮想マシンの移行に基づいてフェイルオーバーシステムを作成するために仮想化テクノロジーを使用することで、おそらく成功するだろうと言います。予算に収まるかどうかは、ビジネスによって異なります。効果的に機能させるには、何らかのタイプのSANが必ず必要になるからです。

ただし、「従来の」フェールオーバークラスタリングを軽視しないでください。アプリケーションがそのような構成に適している場合は、間違いなく「勝利」もあります。

上司が壊滅的な障害シナリオ（火傷、洪水、竜巻、盗難など）について考えていたのではないかと思います。まだ計画されていない場合、これは一般的なビジネス継続性計画と災害復旧の不測事態に取り組む絶好の機会です。

来てあなたのビジネスを勉強し、提案をすることができる誰かから助けを得る 後悔することはありません。

「この道は多くの痛みと傷につながる...」

それで、あなたのビジネスの継続計画は何ですか？あなたは災害復旧計画ですか？

あなたはそれを議論しましたか？書き留めましたか？テスト済みですか？

「上位」と適切に会話する必要があり、サービスによって異なるため、実際に高可用性の要件の一番下に到達する必要があります。

それで、彼らがその朝感じた「苦痛ポイント」は本当に何でしたか？

でしたか？

• 電話が機能しなくなった？かなり重大な（そして目に見える）問題。そして、はい-これには「解決策」が必要になりますが、うまくいけば、これはサポート契約に基づいていますか？
• Webサイトが失敗しましたか？OK-かなり目に見えますが、予想外ではありません。巨大なWebプレゼンスがない限り、それほど重要ではありません。このサーバーを数時間停止してもかまいません。
• データベースサーバーがダウンしていますか？怖い...良いバックアップを得たことを願っています！データを失わないでください。そうしないと、ビジネスが失敗します。ただし、データがセキュリティで保護されている限り、それは重要なサーバーであり、回復計画が必要です。
• ファイルと印刷（および内部アプリなど）。ほとんどの人にとって、これはピタです。あなたがそれを修正するとき、彼らは座って朝には何もしません。

メインシステム用に高品質のハードウェアを購入したと思いますか？これらのサーバーには「デュアル」なものがすべて同梱されているため、ハードウェアを安くすることは誤った経済です。

また、サーバーを再構築し、ファンを交換し、電源を供給し、サーバーをラックに収納し、デュアルパスネットワークを冗長スイッチに構成する方法を知っていると思いますか？何が機能し、何が機能せず、何が正常で、何が間違っているかを理解するのに十分な回数これをしましたか？そうでない場合は、ヘルプとトレーニング（または少なくとも練習と経験）を入手してください。

たぶん問題の多くは恐怖だった。彼らはそのような問題が起こる可能性の手がかりを持っていなかった（そしてサーバーが彼らのビジネスにとってどれほど重要だったか）そしてあなたはあなたが何をしているのか本当に知らなかった（？）信頼の問題？

非常に高価なHAルートを下りる前に、上記のすべてを正しく取得する必要があります。ビジネスでこの高価な機器を購入することはできますか（そしてその定義のほとんどは、故障時にのみ使用され、多くの場合決して使用されません！）

Evanにはいくつかの良い点がありますが、ここでは、障害が発生した場合に1時間未満の回復時間を得るための具体的な費用対効果の高い方法を示します。

スモールビジネスとは、おそらく小さなハードウェアを意味するため、問題に直面してかなりの回復力を実際に追加するいくつかの簡単なことを行うのは、それほど多くのコストではないかもしれません。主なアイデアは、追加のハードウェアを準備することです。

まず、仮想IPの考え方に慣れます。これは、ユーザーが通信するIPアドレスですが、指定したサーバーに常駐できます。これはユーザーのIPアドレスであり、アプリケーションは通信したいと思うでしょう。そして、それは最終的にあなたが求めるソリューションにとって最も役立つでしょう。VIPを持っているということは、フェールオーバー時にアプリケーションを再構成する必要がないことを意味します。また、冗長ハードウェアを使用すると、1の代わりに2つの構成更新を行う管理オーバーヘッドの増加の影響も受けることに注意してください。

ルーティング/ウェブプロキシサーバーから始めると、ボックス自体に保存する必要がある実際の状態ではないため、おそらく最も簡単です。したがって、同じボックスの複製を取得し、同じように構成します。両方をLANセグメントに接続したままにします。インターネットが別のインターフェイスに接続していると仮定して、ケーブルが故障した場合はケーブルを交換します。ルーティングの観点から、デフォルトのルートの.1アドレス（VIP）をターゲットとするLANクライアントをすべて設定し、プロキシサーバーはサーバーAに.2アドレス、サーバーBに.3アドレスを与えます。このように、両方を構成更新のために管理できます（両方に適用されます）。フェイルオーバーするために必要な作業は、.1 IP割り当てを.2から削除して.3に移動し、インターネット接続を他のインターフェイスに移動することだけです。それほど複雑ではなく、簡単に理解できます。2台目のボックスの追加ハードウェアが必要です。インターネット側で冗長性を得ることができれば、複雑さを追加し、VRRPのようなものを使用して自動フェールオーバーを取得できます。

具体的なことは言うまでもありませんが、Webサーバーは単純なものかもしれません。同一の構成で2番目のサーバーを追加し、2つの間にvIPを作成し、障害が発生した場合にVIPをバックアップに移動します。一般に、フェイルオーバーでセッション状態が失われるかどうかは気にしません（フェイルオーバーを引き起こすのは重大な問題です）。したがって、ユーザーが再度ログインする必要がある場合、大した問題はありません。繰り返しますが、vrrpはおそらく自動フェイルオーバーに使用できます。

DBに移ると、これは非常に複雑です。ほとんどのDBには、何らかのプライマリ/セカンダリモデルがあり、元のDBをセカンダリにバックアップしてから、すべてのトランザクションログまたはDBの変更をセカンダリにコピーします。繰り返しますが、実際にDBにアクセスするアプリケーション/ユーザーのVIPとこれを組み合わせることができます。ただし、フェールオーバーはより複雑です。プライマリの障害に応じて、トランザクションログをコピーして残りのドライブを実際に起動して実行する必要がある場合があります。次に、セカンダリをアクティブにします。失われたデータを許容できる場合は、セカンダリをすぐにアクティブにすることができます。フェイルオーバー後、サーバーBがプライマリになり、サーバーAを復元し、それを新しいバックアップに変更して、最終的にサーバーbに問題が発生したときに失敗する準備を整えます。

DBとは異なり、ファイルサーバーの組み込み機能を取得するのはかなり難しいため、ファイルサーバーは常に最も難しい部分です。ただし、2番目のサーバーを使用し、ファイルシステムをスキャンして変更を検出し、新しいファイルをセカンダリにコピーするだけで、ある程度の復元力を実現できます。基本的に、cronでrsyncを実行できます。繰り返しますが、ユーザーに提供するVIPを使用し、フェールオーバーを行う場合は移動します。スクリプトでは、ファイルを転送する前に、システムがVIPの所有者であることを確認することを強くお勧めします。rsyncを間違った方向に実行して、ユーザーが行っている変更を上書きすることは本当に本当に望ましくありません。これは、ファイルが失敗した場合、一部のファイルを失う可能性があります。

私はあなたが電話システムについて何ができるかわからない...それは本当にベンダーとそれがどのようにセットアップされているかに依存する。ベンダーは、弾力性のために既製のソリューションを持っている場合があります。

警告の最後の言葉。使用するセットアップを徹底的にテストしてください。その重要な情報を失うことなくフェイルオーバーする方法を知っていることを確認してください。テストテストをテストして、必要なときに機能することを確認します。構成の変更、ソフトウェアの更新などがプライマリとバックアップの両方に適切に適用されるプロセスが整っていることを確認してください。幸いなことに、サーバーをアップグレードする場合などに、制御されたフェールオーバーを実行できる可能性があります。アクティブ/アクティブセットアップではないため、必要なときにセカンダリが機能するかどうかはわかりません。

私はテレコムで働いており、当社の機器は非常に冗長性が高く、ほとんどの場合、地理的な冗長性を含んでいます。私たちの最大の障害点は、変更後に冗長性がテストされないことと、冗長性モデルがどのように機能するかを知らないユーザーが変更を加えることです。ただし、すべての機器が数秒以内に自動フェイルオーバーをサポートする必要があるという追加の問題があります。30〜60分以内に起動して実行する必要がある場合は、フェールオーバーでの手動介入を許容できます。準備するだけです。幸運を。

他のみんなのポイントは素晴らしいので、コメントをいくつかだけ。

特にすべての場合、30分を保証することは不可能です。あなたはそれをターゲットと言うことができますが、常にXファクターがあるので、それが保証できる方法はありません。2つのISP回線があり、トラックが建物に衝突し、両方を取り出すことができます。これは、建物の反対側から配線することが重要だとは思わなかったためです。

原価計算の開始として、すべてを2倍にします。5台のサーバーがあるので、二重にする必要があります。すべてがハードウェア上にある必要はなく、仮想化することもできますが、私が言っていることがわかります。それに加えて、すべてがHAに対応している必要があり、これもコストを追加します。ルーターを新しいものに交換する必要があり、そのうち2つが必要になる場合があります。電力会社が30分以内に回復することを保証できないため、電力供給を2倍にして発電機を取得することを忘れないでください。

これらの例は、多かれ少なかれホットスタンバイのセットアップを考えています。

中小企業にとってより良いと思うのは、すべてを回復して分類する計画を立てることです。

どのサービスかを把握する

クリティカル（業務停止）

重要（ビジネスが遅くなる）

ルーチン（ビジネスはしばらくそれなしでやることができます）。

たとえば、コールセンターの電話は非常に重要であるため、1台で2台目のサーバーと2台目のISPを購入する価値があり、平均停電は約15分であるため、UPSは60分間持続します（しないでください）ワークステーションを忘れてください）。ここで、ERPは重要であると言えます。つまり、ERPがなくてもERPは機能します。たぶんあなたのコールセンターの人々はそれを使用しますが、ダウンした場合、彼らはペンと紙またはメモ帳に戻り、その後ERPを更新することができます。ダウンしている場合にそれを行う手順は、それを重要なサービスにしようとするよりも安くなる可能性があります。そして、日常的なものはプリンタのようなものかもしれませんが、それは苦痛ですが、それらがすべてダウンした場合、私たちは数日間支払うことができます。

それはまた、s ** tがいつかファンを襲った場合に何かを修正するための命令をあなたに与えます:)

出来ますか？承知しました。手頃な価格ですか？おそらく「中小企業」向けではありません。特に、上司が働くための任意の番号を教えてくれており、彼が代理プログラマーで構成されるIT部門に高可用性を要求している場合（他の場所で何度も見られ、あなたの状況が彼らのようなものだった場合、あなたのストレスレベルのためにかなり）。

フェイルオーバーは可能ですが、通常は冗長ハードウェア、サーバー間でデータを共有するためのSANなどが必要です。

あなたが言及したコールシステムハードウェアは特殊なハードウェアであり、コールセンターであることをほのめかしています。冗長にするためのオプションについては、ベンダーに相談してください。それで馬鹿げていると、そもそもサポートが無効になる可能性があります。

VMWareタイプのソリューション（またはHyper-VまたはXenServerですが、最初にVMwareとXenServerを検討します）に投資することで、おそらく冗長性を得ることができる他のシステム。次に、SAN、高速ネットワークスイッチを備えた数台の強力なサーバーを取得し、障害が発生した場合にLiveMotionを使用してハードウェアサーバー間で仮想化サーバーを移行し、必要に応じてサーバー間で負荷の一部を分散する方法を確認します。

あなたはそれらのシステムでLinuxを実行していると言いました。複数のサーバーを取得するための資金があれば、代わりにハートビートプログラムとSTONITHを使用してDRBDをセットアップし、サーバー間でデータを複製し、サーバーが使用できなくなったときに引き継ぐことができます。各サーバーを文字通り複製するシステムのセットアップと、サーバールーム（サーバールームがある場合）での電力消費と熱放散を2倍にしたいと考えています。これは、ハードウェアのコストと正気度のために行うことができます。さらに、テストする必要があり、構成中にダウンタイムが発生します。また、発生する可能性のある問題が発生する可能性があるため、時々機能しない可能性がありますたとえば、脳）。

最後は、いくつかのシステムをブランクスレートシステムとして機能させ、サーバーが停止した場合に「ブランク」システムの1つにデータを復元できる非常に優れたバックアッププランを用意する計画です。ハードウェアをオンサイトにすると、サーバーが停止した場合にサーバーにいくつかのオプションが提供されます。ただし、データの復元中はある程度のダウンタイムが発生するため、新しいサーバーにアプリケーションを適切にインストールする方法についての指示が必要です。作業の速さとデータの大きさによっては、数時間から1日か2日までダウンタイムが続く場合があります。あなたはやるええ、代わりに復旧計画で、サーバーの作業、正常なバックアップがありますか？

あなたはそれを試してみるべきですか？私の最初の反応は、もしあなたが何か提案に頭をかいたり、このようなものを考え出そうとして胃の中に穴を感じているなら、そうすべきではないということです。問題を調査してコストを計算して実装するにはコンサルティング会社が必要です。または、会社のために専用のシステム管理者を雇う必要があります。

彼らがあなたにそれをするように言っているという事実と、あなたはあなたが「ただ「促進された」プログラマであり、あなたは30分の最大失敗時間で冗長性を与えるようにあなたに言っているPHBを持っていると言っているという事実はあなたが親切であるということです小川の