ディザスタ リカバリ ソリューションの実装は、1) 時間 2) リソース 3) 金額の 3 つの要因に依存します。
ほとんどの組織は、IT インフラストラクチャとアプリケーションが問題なく稼働している場合、DR について考えることさえありません。彼らのほとんどは、何かが壊れてビジネスに大きな悪影響が生じた場合にのみ、DR について考えます。
システム管理者、または IT の稼働を維持する責任を負う人物であれば、常に作業を行う必要があります。災害復旧について。会社が時間と予算を割り当てたかどうかに関係なく、DR のいくつかの側面に取り組むことができます。
以下は、DR を計画する際に考慮すべきさまざまな項目のリストです。このリストは決して包括的ではありませんが、DR を開始するための十分なアイデアを提供するはずです。
<オール>
回復力のあるプライマリ データセンター。 セカンダリ リモート データセンターを計画する前に、プライマリ データセンターのすべてのコンポーネントが高度に冗長化されていることを確認する必要があります。セカンダリ リモート データセンターを使用しなくても、ほとんどの災害 (自然災害を除く) から迅速に回復できるように、プライマリ データセンターを可能な限り回復力のある設計にする必要があります。たとえば、本番データベースの場合、同じデータセンターでフィジカル スタンバイ データベースを実行し、すべての本番サーバーでデュアル NIC カードと HBA カードを構成し、ロード バランサーを使用して複数の Web サーバーを構成し、冗長構成を使用してサーバーを 2 つの電源回路に接続します。サーバーの電源など
リモート セカンダリ データセンター。 回復力のあるプライマリ データセンターを実装する場合、冗長なリモート データセンターを使用する目的は、主に地震、火災、洪水などの自然災害に対応することです。これは非常に明白かもしれませんが、言及する価値はあります。これを行うと、プライマリ データセンターとセカンダリ データセンターの両方が同じ都市にあり、DR の目的に反します。プライマリ データセンターがカリフォルニアにある場合は、東海岸のどこかにセカンダリ データセンターをセットアップしてください。
DR データセンターで本番コンポーネントを複製する すべてのハードウェアとアプリケーションをプライマリ データセンターからセカンダリ データセンターにレプリケートする必要はありません。システム管理者または技術担当者は、DR サイトにレプリケートする必要があるすべての重要なハードウェアとソフトウェアをすばやく特定できますが、ビジネスにとって重要なアプリケーションを特定するには、他の部門の助けが必要になる場合があります。重要なビジネス機能を IT インフラストラクチャ コンポーネントにマッピングし、それらすべてのインフラストラクチャ コンポーネントとアプリケーションおよびデータが DR サイトに複製されるようにする必要があります。
ストレージ プラン。 プライマリ DR で重要なアプリケーションをサポートする何らかの種類の SAN ストレージ (または NAS ストレージ) がある場合は、DR サイトにも同様の SAN ストレージ (または NAS ストレージ) が必要です。パフォーマンス上の理由から、DR サイトの本番サーバーは、プライマリ サイトの本番サーバーと同じ仕様にする必要があります。ただし、ストレージについては、大手ベンダーのハイエンド SAN ストレージがプライマリ サイトにある場合は、小規模ベンダーの同様のハイエンド SAN ストレージを実装することを検討してください。これにより、同じ構成で同様のパフォーマンスを実現するための費用が大幅に削減される可能性があります。 .
データを継続的に DR サイトに複製する プライマリ データセンターとディザスター データセンターの間でデータを同期することは、DR の実装を成功させるための重要な側面です。 DR サイトにレプリケートする必要があるすべてのアプリケーションをリストアップしたら、これらすべてのアプリケーションについて、これら 2 つのサイト間でデータを同期する方法を理解する必要があります。たとえば、ストレージ ベンダーが提供するレプリケーション テクノロジを使用してブロック レベルで Oracle データベースをレプリケートしたり、datagurad を使用して Oracle レベルでデータをレプリケートしたりできます。どちらにも長所と短所があります。それらを慎重に分析し、予算と DR の範囲に合ったものを選択する必要があります。
手動の方法で初期データを複製します。 初めて DR サイトをセットアップするときは、最初のデータ同期をどのように行うかを決定する必要があります。たとえば、サイズが非常に大きいデータ ウェアハウス データベースをレプリケートする場合、データベースの初期バックアップをネットワーク経由でリモート サイトにコピーすることはできません。これは、帯域幅を占有する可能性があるためです。代わりに、プライマリ データセンターでテープ バックアップを作成し、それをセカンダリ データセンターで使用して初期データベースをセットアップできます。初期設定が完了したら、サイト間でなんらかの形式の自動増分同期を実装できます。
RTO は Recovery Time Objective の略です。 管理チームと協力して、ビジネスで許容できる RTO を特定します。たとえば、組織が許容できる RTO を 8 時間と決定する場合があります。つまり、災害後、最大 8 時間以内にすべての重要なアプリケーションが DR サイトで完全に動作するはずです。 RTO は、DR ソリューションの実装に費やす金額に直接影響します。たとえば、1 時間の RTO には、24 時間の RTO に必要なコストよりもはるかに高価な、非常に高度な DR ソリューションが必要になる場合があります。
RPO は Recovery Point Objective の略です。 RTO と同様に、経営陣と協力して、ビジネスにとって許容できる RPO を決定する必要があります。たとえば、組織が許容可能な RPO を 2 時間と決定したとします。つまり、災害後、サービスをセカンダリ DR にフェールオーバーすると、2 時間のデータ損失はビジネス上許容されます。たとえば、災害が午後 3 時に発生した場合、DR サイトでシステムを復元すると、午後 1 時時点の本番データのみが含まれます。つまり、午後 1 時から午後 3 時までのデータが失われました。簡単に言えば、RPO が 2 時間の場合、ビジネスは災害時に 2 時間分のデータを失うことを厭わないはずです。
自動フェールオーバーか手動フェールオーバーか? 障害発生後に自動フェールオーバーを行うか、手動でフェールオーバーを行うかを決定しました。ほとんどの場合、誤った信号に基づいて DR サイトに自動的にフェールオーバーしたくないため、手動での介入は許容されます。フェイルオーバー後、プライマリ データセンターに戻るには多くの作業が必要になることに注意してください。
ネットワーク フェイルオーバー。 データ レプリケーションに重点を置いているが、DR のネットワーク面にはあまり重点を置いていない DR 計画を見てきました。ネットワーク チームと協力して、複製する必要があるすべてのネットワーク インフラストラクチャを特定する必要があります。たとえば、本番 URL がフェールオーバー後に DR サイトを指していることを確認するための DNA フェールオーバー。顧客用の VPN 接続を確立している場合は、VPN 接続をフェールオーバーする方法を特定します。プライマリ データセンターでファイアウォール ルール (またはセキュリティ関連のもの) を作成/変更する場合、それらのセキュリティ ポリシーを継続的に DR サイトに複製する方法を特定する必要があります。
リモート ハンドのセットアップ。 問題をデバッグするために、リモート データセンターにアクセスするための適切な計画が必要です。 DR サイトに KVM をセットアップして、オフィスから DR サイトにあるハードウェアのコンソールにアクセスできます。または、誰かが物理的に DR サイトに行って指示を実行できる、何らかの形式の手動リモート ハンド サービスを計画する必要があります。
毎年の DR テスト。 いくつかの組織は、DR サイトのセットアップに多くの時間と費用を費やしていますが、実際の DR 状況では期待どおりに機能しないことに気付くだけです。年に 1 回、現在の DR 構成を検証して、DR サイトが適切に機能し、元の目的を満たしていることを確認する必要があります。すべてが適切に構成されていれば、重要なアプリケーションをプライマリ サイトから DR サイトに手動でフェールオーバーし、そこで数日間実行できるはずです。これは、DR サイトがリアルタイムの負荷を処理する方法を確認するのにも役立ちます。
QA プラットフォームとしての DR サイト DR サイトを災害時のみに使用する代わりに、QA プラットフォームとして使用して、アプリケーションのパフォーマンスと負荷のテストを行うことができます。プライマリ データ センターの追加のテスト インフラストラクチャに投資する必要がないため、これは役立つ場合があります。このアプローチを採用すると、プライマリ サイトから DR サイトに継続的にデータを同期することになります。ただし、負荷テストを行うときはいつでも、DR サイトの現在の状態のチェックポイントを取得し、QA テストを実行し、すぐに前のチェックポイントにロールバックしてプライマリ サイト データの同期を続行する追加のソリューションを実装する必要があります。そこから。
DR 対応計画。 DR サイトを実装したら、実際の災害が発生した場合に自分とチームがどのように対応するかについて、明確な DR 計画を立てる必要があります。組織内のさまざまな部門と協力し、DR 対応チームの一員となる主要なリソースを特定し、DR 対応計画における彼らの特定の役割を特定します。 DR 対応計画は、DR が発生したときに何をする必要があるか、誰がそれらのタスクを実行するか、およびそれらのタスクをどのような順序で実行するかについての簡単な段階的な指示です。
DR サイトを持っていませんか? 多くの組織には DR サイトがありません。それらのいずれかで働いており、重要なアプリケーションと IT インフラストラクチャを担当している場合は、DR 計画を作成し、DR に時間と費用を費やすことの重要性について経営陣を教育する責任があります。彼らの承認。 3 つの異なる DR 計画を考え出します。1 つは $$$、もう 1 つは $$、もう 1 つは $ です。前に説明したように、DR 計画はさまざまな要因によって異なる可能性があり、コストもその 1 つです。詳細な DR 計画を経営陣に提示した後、それでも承認されない場合でも、少なくとも、最善を尽くして優れた DR 計画を作成したことを実感できます。
災害を宣言するタイミング これを事前に明確に識別する必要があります。 DR サイトにいつ切り替えるかについて、非常に明確な基準が書かれている必要があります。つまり、どの基準が DR フェイルオーバー基準をトリガーしますか? DR はいつ開始しますか?どの時点で DR を宣言し、DR サイトへのフェイルオーバーの作業を開始しますか?これらの質問に対する答えは明確に定義され、組織のすべての部門によってレビューされ、最終的にこれらの基準が経営陣によって承認される必要があります。本番環境がダウンしている場合、誰かが誤って本番環境で何かを削除したため、DR がトリガーされない場合があります。組織によっては、プライマリ サイト自体のバックアップからデータを復元した方がよい場合があります。他の組織の場合、ビジネスはバックアップから復元するまで待つことができず、DR サイトに切り替える必要があります。
バックアップ、バックアップ、バックアップ。 バックアップは、DR 計画において非常に重要な要素です。前述したように、実際の自然災害が発生しない限り、DR サイトを使用しないことを目標にする必要があります。そのため、プライマリ サイトでの強力なバックアップ戦略は非常に重要です。すべての重要なアプリケーションをバックアップする必要があります。データベースをバックアップするときは、バックアップを 4 つの場所に保存します。バックアップは、テスト サーバーで復元して継続的に機能していることを検証しないと、ほとんど役に立ちません。
パッチを適用しています。 プライマリ サイトのハードウェアに OS パッチを適用したり、ファームウェアをアップグレードしたり、何らかの構成管理を行ったりする場合、それらを DR サイトで継続的に実行するための戦略が必要です。プライマリ サイトの OS 構成が DR サイトと異なる状況にはなりたくありません。
DR の成功は多くの要因に左右されます。 トップマネジメントの祝福、適切な予算配分、すべての事業部門からの関与、強力な DR 計画、強力な技術リソース、完全にテストされた DR 実装。最も重要なのは、ビジネス目標に沿った明確に定義された DR 範囲が、DR を成功させるために非常に重要であることです。
DR ドキュメント 適切な DR 計画には、多くのプロセスを確立する必要があります。これらのプロセスはすべて適切に文書化する必要があります。たとえば、DR ストライキ時のエスカレーション プロセスを説明するドキュメント。 DR サイトへのフェイルオーバーを実行するために何をする必要があるかを説明する技術文書。 DR に関与するすべてのチーム メンバー、彼らの責任、DR 中の連絡方法を記載したコミュニケーション ドキュメント。顧客に何を伝える必要があるか、および災害時に顧客に連絡する方法を知っている顧客サポート チーム向けのドキュメント。 DR サイトが稼働した後に QA チームがテストする必要があるすべてをリストした DR テスト ドキュメントなど
ディザスタ リカバリの表面をなぞっただけです。上記以外にもたくさんあります。システム管理者、または IT アプリケーションとインフラストラクチャの責任者であり、DR 計画がない場合は、DR 戦略を開始するためのリマインダーとしてこれを検討してください。