ホームページ  >  記事  >  システムチュートリアル  >  災害復旧の導入を最適化し、運用と保守の責任を軽減します

災害復旧の導入を最適化し、運用と保守の責任を軽減します

WBOY
WBOY転載
2024-01-03 22:36:201198ブラウズ
###導入### 現在、ローカル負荷分散テクノロジーによりサーバー クラスターの高可用性の問題は解決されていますが、停電、光ケーブルの工事切断、自然災害などにより、データ センター全体が機能しなくなる可能性は依然としてあります。また、中国のネットワークは複数の事業者で構成されており、事業者間の相互接続の品質が低いことは紛れもない事実です。したがって、大規模なインターネット企業は、単一またはアクティブ/アクティブ データ センターで Web サイト サービスを提供することにもはや満足できず、近くのユーザー アクセスを実現するために、複数のデータ センター クラスターを異なる地域および異なる事業者に展開することを検討し始めているインターネット企業が増えています。バランスとフォールトトレランス。

現在、ローカル負荷分散技術により、サーバー クラスターの高可用性の問題は解決されていますが、停電、光ケーブルの工事切断、自然災害などにより、データ センター全体が機能しなくなる可能性は依然としてあります。また、中国のネットワークは複数の事業者で構成されており、事業者間の相互接続の品質が低いことは紛れもない事実です。したがって、大規模なインターネット企業は、単一またはアクティブ/アクティブ データ センターで Web サイト サービスを提供することにもはや満足できず、近くのユーザー アクセスを実現するために、複数のデータ センター クラスターを異なる地域および異なる事業者に展開することを検討し始めているインターネット企業が増えています。バランスとフォールトトレランス。

複数のデータセンターを展開する場合、次の 3 つの問題に直面することは避けられません。

1. 複数のデータセンターのトラフィックを分散するにはどうすればよいですか?

2. 監視を通じてネットワーク障害を適時に検出するにはどうすればよいでしょうか?

3. 複数のデータセンター サービスに災害復旧を提供するにはどうすればよいですか?

これら 3 つの問題を効果的に解決できない場合、ユーザーのアクセス品質の低下、サービスのブラックホール、顧客からの苦情につながるでしょう。 Web サイトの運用保守担当者は、営業、PM、リーダーから頻繁に挑戦されます。責任を負う対象になる。嬉しいのは、Alibaba Cloud の製品であるクラウド解決 DNS が、中小企業が複数のデータセンターでのトラフィック負荷分散を解決し、近くのユーザー アクセス、障害のタイムリーな検出、およびリアルタイムの災害復旧切り替えを実現するのに役立ったことです。

###速報### データセンターのトラフィック負荷分散 複数のデータセンターにサービスを展開する場合、データセンターごとに異なるアクセス帯域幅、サーバークラスターの異なる負荷容量、運用コストなど、多くの要因に直面する必要があります。したがって、さまざまな要因に基づいて適切なトラフィック割り当て率を設計する必要がありますが、どうすればアクセス トラフィックを正確に割り当てることができるでしょうか。クラウド解決 DNS は、いくつかのリファレンス ソリューションを提供します。

クラウド分析 DNS は、IP アドレスの位置情報 (国、地方、都市、通信事業者などを含む) を迅速に特定し、さまざまなソースからの DNS クエリに異なる応答を行うことができる、特別に設計されたインテリジェント DNS システムです。近くのアクセス、クロスネットワーク トラフィックの削減、およびグレースケール パブリッシングに対する企業のニーズを満たすように対応します。同時に、同じ場所にある異なるサービス機能を持つデータセンター クラスターの場合、WRR (加重リソース レコード) を通じて全体的なトラフィック分散計画を設定できます。

例: example.com 社の www 公式 Web サイトには 6 つのデータ センターがあり、そのうち 2 つは North China Telecom、2 つの East China Unicom が含まれ、他の 2 つは Alibaba Cloud BGP データ センターでホストされています。

1. East China Unicom の 2 つのデータ センターの帯域幅比は 3:7 です。クラウド分析を通じて回線内負荷分散を設定する場合、2 つのデータ センターのサービス IP アドレスの重みをそれぞれ 3 と 7 に設定します。 East China Unicom へのアクセスを実現するため、トラフィックは 30% と 70% の割合に従って割り当てられます;

2. 華北電信の 2 つのデータセンターの帯域比は 1:1 です。クラウド分析による回線負荷分散を設定する場合、2 つのデータセンターのサービス IP アドレスの重み付けをそれぞれ 1 として、それぞれが 50 を占めるように設定します。華北電信のアクセス トラフィックの割合 (%) 構成比率; 災害復旧の導入を最適化し、運用と保守の責任を軽減します 3. Alibaba Cloud BGP 2 つのリージョンの ECS 数の比率は 8:2 です。クラウド分析を通じてインライン負荷分散を設定する場合、2 つのリージョンのパブリック ネットワーク Elastic IP アドレスの重みを 8 に設定します。それぞれ 2 と 2 であるため、アクセストラフィックは次のようになります。 80% と 20% の割り当ての割合;

4. ネットワーク監視は各データセンターのサービス IP をリアルタイムで監視します;

5. ネットワーク監視は、監視結果をクラウド解決 DNS に定期的にフィードバックします;
6. ユーザーは、華北電信の DNS に対して www.example.com DNS クエリ リクエストを開始します;
7. 華北電信 DNS がユーザーのクエリを受信した後にドメイン名をキャッシュしない場合、クラウド解決 DNS に対してドメイン名クエリを開始します。 8. Cloud Resolution DNS は、華北電信から DNS クエリを受信すると、IP アドレス 3.3.3.3 および 4.4.4.4 にポーリングして応答します。現時点では、華北電信の DNS によって得られた結果の半分は 3.3.3.3 であり、華北電信の DNS によって得られた結果の残りの半分は 4.4.4.4 です。同様に、Cloud Analysis DNS が華東聯通から DNS クエリを受信すると、まず 5.5.5.5 を 3 回連続で返し、次に 6.6.6.6 を 7 回連続で返し、実行を繰り返します。現在、East China Unicom の DNS 結果の 30% は 3.3 .3.3 で、残りの 70% の結果は 4.4.4.4 です。
9. クラウド解決 DNS から応答を受信した後、華北電信 DNS はドメイン名解決結果をキャッシュし、最終クエリ ユーザーに返します。
10. 最後に、華北電信ユーザーの 50% が 3.3.3.3 の Web サイト サービスにアクセスし、残りの 50% の華北電信ユーザーが 4.4.4.4
の Web サイト サービスにアクセスします。

ネットワーク監視により障害を適時に検出します

1. クラウド解決 DNS は、中小企業がインテリジェントな解決と WRR を通じて近くのアクセスとトラフィック分散を実現するのに役立ちます。また、Alibaba Cloud の分散監視を効果的に組み合わせ、ネットワーク全体のダイヤル テスト プローブを使用して Web サイトの解決記録を監視します。リアルタイム。 。

2. Cloud Analysis DNS のネットワーク監視は現在、HTTP/HTTPS とカスタム URL をサポートしています。5 つの実際の Alibaba ダイヤルアップ テスト ノードの提供に基づいて、3 つの大手通信事業者の 15 の高品質ダイヤルアップ テスト ポイントが用意されています。選ばれました。同時に、最大 50 の監視タスクの構成は競合他社に完全に先んじており、ダウンタイム障害を時間内に発見できるようにし、監視範囲を拡大します。
災害復旧の導入を最適化し、運用と保守の責任を軽減します
3. 監視頻度は1分と短く、Webサイトの3秒ごとのヘルスチェックに相当し、ダウンタイム後最短3分以内に障害を検出し、グローバルシステムによるフェイルオーバーが完了します。ロードバランシング機能。
4. 誤警報の発生を防ぐため、ダウンタイム判定閾値を50%、つまり50%のノードが異常監視した場合にダウンと判定するように設定しています。
5. もちろん、DNS の有効性はオペレータのキャッシュ TTL にも影響されるため、ホスト レコード TTL を 60 秒に設定することをお勧めします。
6. モバイル開発者の場合、フェイルオーバーの感度を高めるために、Alibaba Cloud HTTPDNS サービスと併用することをお勧めします。

障害分離を実現するための回線間の切り替え ######誤った隔離###### Webサイトのサービスを運営していく上で、必ず障害が発生します。では、障害を切り分けるにはどうすればよいでしょうか?クラウド解決 DNS には、中小企業でも使用できる次のプラクティスがあります。


1. 華北電信のデータセンター クラスター 4.4.4.4 が異常な理由により大規模な障害に見舞われ、Web サイトのサービスが中断され、ユーザーのアクセスができなくなりました。 2. Web サイト監視により 2 分以内に 4.4.4.4 クラスター障害が検出され、クラウド解決 DNS システムに華北電信の IP アドレス解決を一時停止するように通知されました: 4.4.4.4;
3. Cloud Analysis DNS は、障害のある IP 解決を一時停止した後、North China Telecom DNS にのみクエリを実行し、IP アドレスを返します: 3.3.3.3. 同時に、Cloud Analysis DNS 解決ログには、障害時間、IP アドレス、および IP アドレスが記録されます。運休運転情報をSMSやメールでお知らせします。 災害復旧の導入を最適化し、運用と保守の責任を軽減します 4. 最後に、すべてのユーザー アクセス トラフィックは華北電信データ センターに転送されます: 3.3.3.3。

######回復###### Web サイトが復旧したら、トラフィックを簡単に移行するにはどうすればよいでしょうか?



1. 華北電信ユーザーのすべてのアクセス トラフィックが 3.3.3.3 に移行された後、4.4.4.4 はオフライン状態に相当し、関連する技術学生を組織して障害のあるクラスターを修復できます。
2. 修復が完了し、テストに合格すると、監視システムは華北電信データセンター 4.4.4.4 の Web サイトサービスが正常に戻ったことを自動的に検出し、クラウド解決 DNS に北華電通信データセンターの IP アドレス解決を復元するように通知します。中国電信 4.4.4.4、

3. Cloud Resolution DNS は、華北電信から DNS クエリを受信すると、IP アドレス 3.3.3.3 および 4.4.4.4 をポーリングして応答します。一定の時間が経過すると、華北電信の DNS 結果の半分は 3.3.3.3 になり、華北電信の DNS 結果の残りの半分は 4.4.4.4 になりました。

4. エンド ユーザーのアクセス トラフィックは元の構成の 50% にスムーズに移行し、ユーザーが意識することなくアクセス トラフィックがスムーズに復元されます。
オフサイト災害復旧
災害復旧の導入を最適化し、運用と保守の責任を軽減します
大規模なインターネット企業にとって、考慮しなければならないことの 1 つは、壊滅的な状況が発生したときに通常のユーザー アクセスを確保する方法です。

1. 何らかのやむを得ない理由により、華北電信のデータ センターの 2 つのアクセス IP アドレス 3.3.3.3 と 4.4.4.4 にすべて障害が発生し、時間内に復元できませんでした。 2. Web サイト監視により障害が適時に検出され、すべての華北電信回線の IP 解決を一時停止するよう Cloud DNS に通知されます。 3. クラウド解決 DNS が一時停止された後、回線間負荷分散ポリシーが有効になり、華北電信ユーザーの DNS クエリは Alibaba Cloud BGP リージョン アドレスを返します: 1.1.1.1、2.2.2.2;
4. 最後に、すべての華北電信ユーザーのアクセス トラフィックはデフォルト回線 Alibaba Cloud BGP リージョン: 1.1.1.1、2.2.2.2 にスケジュールされ、極端な状況でも華北電信ユーザーに通常のサービスを提供できるようにします

要約 クラウド解決 DNS は、高可用性、拡張性の高い権威 DNS サービスおよび DNS 管理サービスです。さまざまなグローバル負荷分散戦略を提供し、中小企業がユーザー要求をデータセンターに迅速かつ正確にルーティングできるように支援します。また、高可用性の災害復旧スイッチング機能も備えているため、一部のデータセンターに障害が発生した場合でも、 、中小企業は引き続き保証され、Web サイトのサービスにアクセスできます。

将来的には、Cloud Resolution DNS は、SLB、ECS、CDN、Cloud Shield など、より多くの Alibaba Cloud 製品と統合される予定です。アクセス ポータルからバックエンド サービスに至る 3 次元の高可用性 Web サイト ソリューションを形成し、中小企業がフルリンクの負荷分散を実現できるように支援します。

以上が災害復旧の導入を最適化し、運用と保守の責任を軽減しますの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明:
この記事はlinuxprobe.comで複製されています。侵害がある場合は、admin@php.cn までご連絡ください。