中小企業向けの高いサーバー可用性
ある朝起動しないサーバーに少し恐怖を感じた後、高層ビルは、ビジネスに高可用性/フェイルオーバーのセットアップが必要であると判断しました。
5つのメインサーバー（4x Linux、1x OpenBSD）があり、会社が運営するにはすべてを実行する必要があります。サーバーのうち3つはかなり標準的（ファイル/ Web /データベース）で、4つ目はほとんどのネットワークルーティングとWebプロキシを処理し、5つ目は電話システムをサポートし、非標準のハードウェアを備えています。
上司は、サーバー障害のターンアラウンドタイムは30分未満である必要があると述べています。
この分野での私の経験は存在しません（私は「昇進」した単なるプログラマーです）ので、私の質問は本当に次のように要約されると思います。
- これは、平均的なサーバー管理スキルを持った人でも試してみるべきものですか。もしそうなら、私は何を読むべきですか、そして私は誰と話すべきですか？
ありがとう。
まず、数値をまとめて、記載されている「要件」を満たすためのコストを説明し、予算内に収まるかどうかを確認する必要があると思います。要件を満たすために使用されるすべての「通常の」方法（フェイルオーバークラスタリング、「ホットマイグレーション」機能を備えたハイパーバイザーなど）に慣れていない場合は、できるコンサルタントを見つけることをお勧めします。手伝う。
実現可能性調査に関連するコストは発生しますが、適切なソリューションが規定の要件に適合しないことを発見するためのコストは大幅に削減されます（つまり、経営陣が期待をより現実的に設定する必要があります。中途半端なことをするのにかかる費用よりも多くのお金を稼ぐ必要があります。
上司がその番号を空中から引き出したようです。おそらく彼はいくつかの分析を行い、さまざまなシステムのダウンタイムに関連する1時間あたりのコストが何であるかを知っていますが、私はそれを疑っています。それは現実に結び付けられていないいくつかの空の数字のように聞こえます。すべてのシステムがそのような可用性を必要としているとしたら、私は驚きます。ビジネスを研究しているうちに、機能のサブセットだけがそのような程度の稼働時間とフォールトトレランスを必要とすることに気付くかもしれません（したがって、そのようなソリューションは最終的にコストが低くなります）。電話と基幹業務アプリケーションはそこにあると確信していますが、他のいくつかのシステムではダウンタイムに対してある程度の許容範囲があるかもしれません。
私の直感によると、仮想化テクノロジーを使用して、冗長ハードウェア間での仮想マシンの移行に基づくフェイルオーバーシステムを作成することで、おそらく勝利を収めることができるでしょう。それがあなたの予算に合うかどうかはあなたのビジネスに依存します、なぜならそれを効果的に機能させるためには確かにある種のSANが必要だからです。
ただし、「従来の」フェイルオーバークラスタリングを軽視しないでください。アプリケーションがそのような構成に適している場合は、そこにも間違いなく「勝利」があります。
あなたの上司は壊滅的な失敗のシナリオ（建物の火傷、洪水、竜巻、盗難など）について考えたのだろうか。それがまだ計画されていない場合、これは、一般的な事業継続計画と災害復旧の緊急事態に取り組む絶好の機会になります。
入ってあなたのビジネスを研究し、推薦をすることができる誰かからいくつかの助けを得てください。あなたはそれを後悔することはありません。
「この道は多くの痛みと傷をもたらします...」
それで、あなたのビジネスの継続性計画は何ですか？あなたは災害復旧計画ですか？
あなたはそれについて話し合ったことがありますか？書き留めましたか？それをテストしましたか？
サービスごとに異なるため、「上位」と適切に会話し、高可用性の要件を実際に理解する必要があります。
では、彼らがその朝に感じた「問題点」は本当に何だったのでしょうか。
でしたか？
- 電話が機能しなくなった？かなり大きな（そして目に見える）問題。そして、はい-これには「解決策」が必要ですが、うまくいけば、これはサポート契約の下にありますか？
- Webサイトが失敗しましたか？ OK-かなり目に見えますが、予想外ではありません。巨大なWebプレゼンスがない限り、それほど重要ではありません。このサーバーを数時間停止しても問題ありません。
- データベースサーバーがダウンしていますか？怖い...あなたが良いバックアップを得たことを願っています！データを失わないでください。そうしないと、ビジネスは失敗します。ただし、データが安全である限り、重要なのはサーバーであり、復旧計画を立てる必要があります。
- ファイルと印刷（および内部アプリなど）。これはほとんどの人にとってPITAです。彼らは座って、朝は何もしないので、修正します。
メインシステム用に高品質のハードウェアを購入したと思いますか？これらのサーバーにはすべてが「デュアル」ボックスに含まれているため、ハードウェアを安くすることは誤った経済です。
また、サーバーを再構築し、ファン、電源装置を交換し、サーバーをラックに収納し、デュアルパスネットワークを冗長スイッチに構成する方法を知っていると思いますか？何が機能し、何が機能しないか、何が正常で何が間違っているかを理解するのに十分な回数、これを実行しましたか？そうでない場合は、ヘルプとトレーニング（または少なくとも練習と経験）を取得してください。
多分問題の多くは恐怖でした。彼らはそのような問題が発生する可能性があるという手がかりを持っていませんでした（そしてサーバーが彼らのビジネスにとってどれほど重要であるか）そしてあなたはあなたが何をしているのか本当に知りませんでした（？）信頼性の問題？
非常に高価なHAルートを進む前に、上記のすべてを正しく行う必要があります。企業はこの高価な機器を購入することができますか（そして、そのほとんどは、定義上、障害が発生した場合にのみ使用され、多くの場合、使用されることはありません！）
他のみんなのポイントは素晴らしいので、コメントをいくつかだけ。
特にすべてについて、30分を保証することは不可能です。あなたはそれを目標と言うことができますが、常にXファクターがあるので、それが保証される方法はありません。 2つのISP回線があり、建物の両端からそれらをルーティングすることが重要であるとは思わなかったため、トラックが建物に衝突して両方を取り出した可能性があります。
原価計算の開始として、すべてを2倍にします。サーバーが5つあるので、2倍にする必要があります。すべてがハードウェア上にある必要はありません。仮想化することはできますが、私が何を意味するかはわかります。その上、すべてがHAに対応している必要があり、これもコストが増加します。ルーターを新しいルーターに交換する必要があり、そのうちの2つが必要になる場合があります。電力会社が30分以内に復旧することを保証できないため、給電を2倍にして発電機を入手することを忘れないでください。
これらの例は、多かれ少なかれホットスタンバイ設定を考えています。これは、上司が考えていることだと思います。
私が中小企業にとってより良いと思うのは、すべてを回復して分類する計画を立てることです。
どのサービスであるかを把握する
クリティカル（ビジネス停止）
重要（ビジネスが遅くなる）
ルーチン（ビジネスはしばらくの間それなしでやり遂げることができます）。
たとえば、コールセンターの電話は批判的であるため、2台目のサーバーと2台目のISPを購入する価値があり、平均停電時間は約15分なので、60分間続くUPSを入手できます（しないでください）。ワークステーションも忘れてください）。ここで、ERPが重要であるとしましょう。つまり、少しの間、それがなくても機能できます。コールセンターの人々はそれを使用しているかもしれませんが、ダウンしている場合は、ペンと紙に戻すことができます。メモ帳を作成してからERPを更新します。ダウンした場合の手順は、重要なサービスにしようとするよりも安くなる可能性があります。通常の手順は、プリンタのようなものかもしれません。苦痛ですが、それらがすべてダウンした場合、私たちは数日間期限を迎えることができます。
それはまた、ある日本当にファンに打撃を与えた場合に問題を修正するための命令を与えます:)
出来ますか？承知しました。手頃な価格ですか？おそらく「中小企業」ではないでしょう。特に、上司が任意の数の仕事をしてくれる場合、彼は副プログラマーで構成されるIT部門に高可用性を要求しています（他の場所で何度も見られますが、決してありません）。あなたの状況が彼らのようなものだった場合、あなたのストレスレベルにはかなりです）。
フェイルオーバーは可能ですが、通常は冗長ハードウェア、サーバー間でデータを共有するためのSANなどが必要です。つまり、専任の管理者を雇わない場合は、資金を調達してください。
あなたが言及したあなたのコールシステムハードウェアは特殊なハードウェアであり、あなたはコールセンターであることをほのめかしました。それを冗長にするためのオプションについてベンダーに相談する必要があります。それでグーフィングすると、そもそもサポートが無効になる可能性があります。
他のシステムでは、VMWareタイプのソリューション（またはHyper-VまたはXenServerですが、最初にVMwareとXenServerを検討します）に投資することで、ある程度の冗長性を得ることができます。次に、SAN、高速ネットワークスイッチを備えた2台の強力なサーバーの取得を検討し、LiveMotionを使用して、障害が発生した場合にハードウェアサーバー間で仮想化サーバーを移行し、必要に応じてサーバー間の負荷の一部を分散します。
あなたはそれらのシステムでLinuxを実行していると言いました。複数のサーバーを取得するためのお金があれば、代わりにハートビートプログラムとSTONITHを使用してDRBDをセットアップし、サーバー間でデータを複製し、サーバーが使用できなくなったときに引き継ぐことを検討できます。あなたは、文字通り各サーバーを複製し、サーバールーム（サーバールームがある場合）の電力消費と熱放散を2倍にするシステムのセットアップを検討しているでしょう。それはハードウェアとあなたの正気のコストのために行うことができます。さらに、テストする必要があり、構成中にダウンタイムが発生します。また、対処しなければならない問題が発生する可能性があるため、機能しない可能性があります（分割）たとえば、脳）。
最後は、いくつかのシステムを白紙の状態のシステムとして機能させ、サーバーが停止した場合にデータを「空の」システムの1つに復元できるようにするための非常に優れたバックアップ計画を立てる計画です。ハードウェアをオンサイトに設置すると、サーバーが停止した場合にいくつかのオプションが提供されます。ただし、データの復元中にはダウンタイムが発生するため、アプリケーションを新しいサーバーに適切にインストールする方法についての説明が必要です。作業の速度とデータの大きさによっては、ダウンタイムが数時間から1日か2日続く場合があります。あなたdoサーバーのバックアップが機能していて、正常に機能していて、復旧計画が整っていますね。
あなたはそれを試みるべきですか？私の最初の反応は、あなたが提案のいずれかで頭をかいたり、これを考えようとして胃に穴を感じたりしているなら、そうすべきではないということです。コンサルティング会社が問題を調べてコストを計算し、それを実装する必要があります。または、専任のシステム管理者を雇って会社のためにそれを行う必要があります。
彼らがあなたにそれをするように言っていて、あなたが「ただ「昇進した」プログラマーであり、最大30分の失敗時間で冗長性を与えるようにあなたに言っているPHBを持っているという事実はあなたが親切だということです小川のアップ。
Evanはいくつかの良い点を挙げていますが、障害が発生した場合に1時間未満の回復時間を取得するための特定の費用効果の高い方法がいくつかあります。
中小企業はおそらく小さなハードウェアを意味するので、問題に直面したときに実際にかなりの回復力を追加するいくつかの単純なことを行うのに多くのコストはかからないかもしれません。主なアイデアは、追加のハードウェアを準備することです。
まず、仮想IPの考え方に慣れてください。これは、ユーザーが通信するIPアドレスですが、指定した任意のサーバーに存在できます。これはあなたがユーザーであるIPアドレスであり、アプリケーションは話したいと思うでしょう。そして、それはあなたが求めるどんな解決策にとっても最終的に最も役立つでしょう。 VIP）があるということは、フェイルオーバー時にアプリケーションを再構成する必要がないことを意味します。また、冗長ハードウェアがあると、2つの構成を行うため、管理オーバーヘッドが増加するという影響もあることに注意してください。 1の代わりに更新します。
ルーティング/ Webプロキシサーバーから始める場合は、ボックス自体に保存する必要のある実際の状態ではないため、おそらく最も簡単です。したがって、同じボックスの複製を取得して、同じように構成するだけです。私は両方をLANセグメントに接続したままにし、インターネットが別のインターフェイスにあると仮定して、ケーブルに障害が発生した場合はケーブルを交換します。ルーティングの観点から、デフォルトルートの.1アドレス（VIP）をターゲットにするようにすべてのLANクライアントを設定し、プロキシサーバーはサーバーAに.2アドレスを、サーバーBに.3アドレスを与えます。このようにして、構成の更新のために両方を管理できます（両方に適用されます）。フェイルオーバーに必要なのは、.2から.1 IP割り当てを削除し、それを.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分以内に稼働する必要がある場合は、フェイルオーバーの手動介入を許容できます。あなたはただ準備する必要があります。幸運を。