1

クラウドでホストされる Web サービスの開発を開始していますが、一般的なクラウド SLA が提供するよりも高い可用性が必要です。

Windows Azure などの一般的な SLA では、99.9% の可用性、つまり 1 か月あたり最大 43 分のダウンタイムが約束されています。桁違いに優れた可用性 (1 か月あたり 5 分未満のダウンタイム) を探しています。問題のその部分を解決するためにいくつかの負荷分散されたデータベース バックエンドを構成できますが、Web サーバーにボトルネックが見られます。Web サーバーに障害が発生すると、顧客はサービス全体を利用できなくなります。別の単一障害点を導入することなく、そのリスクを軽減するオプションは何ですか? それぞれに次の解決策と欠点があります。

  1. SRV レコード: インフラストラクチャ全体を複製し (データベースが同期していることに注意してください)、ドメインの SRV レコードを追加して、www.example.com にアクセスしようとしているユーザーが自動的に example.cloud1.com に転送されるようにします。または、それが example.cloud2.com に対してオフラインの場合。グーグルで調べてみると、SRV レコードはどの主要ブラウザでもサポートされていないようですが、本当ですか?

  2. 2 番目の A レコード: 代替として追加の A レコードを追加します。欠点: a) 私のホスティング プロバイダーでは、2 つ目の A レコードを追加する可能性は見当たりませんが、1 つだけです...それは正常ですか? b) 2 つのサーバーのうち 1 つのサーバーがダウンした場合、ユーザーが自動的に別のサーバーにリダイレクトされるのか、それとも全ユーザーの 50% が 404 またはその他のエラーを受け取るのかがわかりません。

ベストプラクティスの手がかりをいただければ幸いです

乾杯、セバスチャン

4

2 に答える 2

1

インスタンスの可用性、つまりクラウド プロバイダーによって指定された場合の SLA は、「インスタンスの正常性は、ハイパーバイザーまたはファブリック コントローラーのコンテキストで実行されているサーバーです」を意味します。そうは言っても、アプリ、OS、またはインスタンス内で実行されているほとんどのものが原因でインスタンスが失敗しないように、努力を払う必要があります。DevOps が見逃しがちなことはほとんどありません。たとえば、OS の更新とパッチの設定を忘れてしまうなど、そのようなことはよくありません。

可用性に関する基本的な公理は、冗長性です。アプリケーション/インフラストラクチャの冗長性が高まると、アプリの可用性が向上します。

Azure Traffic Managerを調べてから、アーキテクチャを再検討することをお勧めします。SRV レコードまたは A レコードについて心配する必要はありません。トラフィック マネージャーの CNAME だけでうまくいきます。

トラフィック マネージャーの考え方は単純です。トラフィック マネージャーにドメイン名の後に立つように指示することができます (アプリのドメイン名解決)。その後、トラフィック マネージャーは、ラウンド ロビン、災害管理などの要因を考慮して、要求の送信先を決定します。 .

Traffic Manager とマルチリージョン インフラストラクチャのセットアップを組み合わせることで、高可用性の目標に向かって進みます。

リンク

Azure Traffic Manager の概要

Cloud Power: Traffic Manager を使用して Azure Web サイトをグローバルにスケーリングする方法

于 2014-06-03T10:45:40.463 に答える