この記事は機械翻訳されたものです。

予測: 曇り

Windows Azure 展開のドメイン (機械翻訳)

Joseph Fultz

最近、私は多くの考え、アプリケーションの展開に与えてきた。 アプリケーションでは、フォールト トレランスおよびアップグレード パスについては、マトリックスは少しトリッキーが実は — とアプリケーション サービスは、Web UI とバック エンド プロセスが混在がもトリッキー。 地理的な分布を追加し、物流がさらにしみついてになります。

大規模な IT 組織で、最小の展開、Web またはアプリケーションのサーバーにはしばしば地理的に離れている 2 つのサーバーが含まれます。 これは、簡単に 2 つのサーバーが指定されている、予想される負荷を同じセットアップとミラー サイトがあると最大 4 台のサーバーを移動 (もちろん、データベースとその他のサポートのサーバー インフラストラクチャがまだ高いプッシュすることができます)。 どのような場合、会社北アメリカ、ヨーロッパ、中東およびアフリカ (EMEA) などの複数の場所を提供しています？ セットアップは、大西洋の両側にレプリケートを取得今、何回転 2 つの Web サーバーとしてを地域のフェイル オーバーと消費者に近いの資産をステージングの 8 つのサーバに開始。

最終的には、アプリケーションがこれらのすべてのサーバーに配置され、すべてスムーズに沿って実行です — といくつかの生意気な開発者新しい機能を作成し、展開を更新します。

ご想像のとおり、サーバー接続をドレインします、取得更新、テスト、順序を決定し、プールに戻さする計画の良い少しかかります。 アップグレードの計画を通じて取り組んで深夜いくつかの人々 を過ごすし、も現実の問題が存在しない場合。

Windows Azure、アップグレード計画を排除しないが、ほとんどのファブリックの一部としてそれを処理することによりアップグレードの複雑さの多くしています。 この列はカバー障害ドメインとアップグレード ドメイン、するつもりで少しアップグレード、展開全体にわたって適用するコードの記述。

障害およびアップグレード ドメイン

Windows Azure には、障害のドメインおよび両方はほぼ完全に自分の名前で記載されているアップグレードのドメインの概念が含まれます。 障害ドメインは、アプリケーションの展開の物理的な単位を定義して通常、ラックのレベルが割り当てられます。 障害ドメインを別のラックに配置することによって、アプリケーションの展開と同時に、すべて失敗する可能性が高いではないハードウェアを十分のインスタンスを区切ります。 さらに、1 つの障害ドメインの失敗別の障害を沈殿する必要がありますしません。 構成の 2 つのインスタンスの役割を展開すると、ファブリックのインスタンスが 2 つの異なる障害ドメインで育てられるを保証します。 残念ながら、障害のドメインは、あなたがどのように多くのドメインまたはどのように役割を割り当てられているかの制御あります。

アップグレードのドメインは、別の問題です。 これらのドメインを制御してインスタンスのグループを同時にアップグレードすることによって、展開全体にわたって増分またはローリング アップグレードを実行できます。 障害のドメイン役割の物理的な展開についてである一方、アップグレード ドメイン論理の展開に関連しています。 アップグレード ドメイン ロールの論理的なグループであるため、単一の Web アプリケーションは簡単に 5 つの異なるアップグレード ドメインのみ 2 つ独立した物理展開 (障害ドメイン) に分かれてあります。 この例では、Web アプリケーションを更新するには、グループ 0 (アップグレード ドメイン 0) のすべてのロールおよびグループ 1 のすべてのロールから、更新可能性があります。 個々 のロールの 1 つを一度に更新ドメインごとに更新することにより有限制御を行使することができます。

要約すると、1 つ以上のインスタンスを必要とするアプリケーションには、少なくとも 2 つのエラー ドメインに分割されます。 Web アプリケーションをファーム全体で容易にアップグレードするのには、役割を同時に更新される論理的なグループに結合されます。

展開の構成の表示

Windows Azure の管理コンソールを更新ドメイン列が障害ドメイン列ではない示しています (を参照してください図 1)。 （ドメインをアップグレードしてドメインを更新あります交換条件。 ドメインをアップグレードする多くのマニュアルを参照が API では、更新プログラムのドメインと呼ばれる）。

図 1 は、Windows Azure の管理コンソール

図 1私の 4 つの展開の番号 0 から 3 を実行することを見ることができます。 既定では、Windows Azure 5 更新ドメインごとのサービスを使用し、ラウンド ロビン スタイルに割り当てます。 これは ServiceDefinition 要素の upgradeDomainCount 属性に必要なアップグレードのドメイン数を割り当てることによってサービス定義ファイルを変更することができるものです。 Web と労働者の役割でのスキーマの各リンクを見つけること msdn.microsoft.com/library/ee758711。 唯一の 3 つのアップグレード ドメインを使用して、WebRole を強制するには、たとえば、upgradeDomainCount サービス定義ファイルで設定します。

<ServiceDefinition name="<service-name>" xmlns=”https://schemas.microsoft.com/ServiceHosting/2008/10/
      ServiceDefinition” upgradeDomainCount="3">
  <WebRole name="<web-role-name>" vmsize="[ExtraSmall|Small|Medium|Large|ExtraLarge]"
    enableNativeCodeExecution="[true|false]">
    ...
</WebRole>
</ServiceDefinition>

更新ドメイン数は最終的にあなたの計画と実行に影響するので、これは重要です。 残念ながら、障害ドメインの割り当てを表示する列はありません。 少しのコードを記述することで、しかし、カーテン、展開と参照の両方がドメインと障害のドメインの割り当てとして更新を少し引き戻すことができます図 2 を示しています。

図 2 ロール情報の検索

protected void GetRoleInfo()
{
  List<RoleInfo> RoleInfos = new List<RoleInfo>();

  foreach (var role in RoleEnvironment.Roles)
  {
    RoleInfo info = new RoleInfo();
    info.RoleName = role.Value.Name;

    foreach (RoleInstance roleInstance in role.Value.Instances)
    { 
      info.InstanceId = roleInstance.Id;
      info.FaultDomain = roleInstance.FaultDomain.ToString();
      info.UpgradeDomain = roleInstance.UpdateDomain.ToString();
           
    }
    RoleInfos.Add(info);
  }
  GridView1.DataSource = RoleInfos;
  GridView1.DataBind();

}

このコードは関連性の高い情報を格納する定義、小さなクラスを表示されません。 残念ながら、私は、ロールと、インスタンスを通過このニースの入れ子になったループが、API のコードを実行している特定のインスタンスにのみ関連するデータを返すには、ページで実行されるコードことができます。 したがって、小さなグリッドで現在の WebRole 情報だけで、コードを生成 (を参照してください図 3)、他のインスタンスの情報がないです。

図 3 現在 WebRole 情報

このコードは、現在 WebRole のドメイン、障害とアップグレードを簡単に見て提供しますが、展開の残りの部分の取得 URI を使用してより包括的なデータを取得する必要があります。 展開は、他のものの間では、要素が含まれている XML を返します <Configuration/> それぞれのための <RoleInstances/>。 構成をフェッチした後、それを変更し、それを戻します。 私の 2010 年 10 月のコラムを見て (msdn.microsoft.com/magazine/gg232759) ここに関与すると、同じ操作の多くを表示する例。

アップグレード戦略

Windows Azure 展開を更新するための 2 つの基本戦略です。インプレース アップグレードおよび仮想 IP (VIP) スワップ。 VIP スワップの簡単なアプローチでありを完全にゲートを開く前に、新規または更新されたアプリケーションのテストします。 また、できるだけ早くそれは生きているアプリケーション フル操業で実行できます。 新しい展開作業中ですが、スワップが完了したらは、問題が必要、あなたすぐに以前のバージョン戻る場所に置くことができます。

でき、各配置モデルで実行することはできないものを説明する良い参照を見つけること bit.ly/x7lRO4。 選択を強制的かもしれないポイントを次に示します。

• インプレース更新削除や展開の種類やエンドポイントの数を変更するときに必要です。
• VIP スワップまたは削除し、展開、役割名または更新ドメイン カウントを変更するとき、またはローカル リソースのサイズを小さくとが必要です。

これらのポイントと SDK バージョン事項以外は、それを決定する次第です。

VIP、ステージング環境と運用環境のスワップはかなり良いソリューションの多くは、いない場合はほとんど、新しいバージョンを展開するときの場合します。 それは大規模な展開をアップグレードする場合は、別の完全展開をもたらす面倒なことができますが変更はほとんど利用のサイトを維持する唯一の方法があります。 完全なコピーを導入に関連するコストもある-1 つの計算時間充電各インスタンスと、追加の計算時間の 2 つの実行中のコピー [展開の。

Web ファームで今日では、更新プログラム一般的に、ファームをいずれかの展開します。一度に 1 つのサーバーをオフラインを取って、アップグレード、サーバーのオンライン化、ファーム プールに返す; または、時に、1 つのセグメントに接続をドレイン ファームのセグメントに分割し、各セグメントのアップグレード オンラインにするため、ファームに返すと最後に、次のセグメントに移動します。

場所では、2 番目のパターンのような作品を更新します。 ただしより多く使用されるより多くのパターンの最初のオプションようなドメインをアップグレードします。 多数のアップグレード ドメインを使用しての利点は、サイト キャパシティは、セグメントのサイズによって、全体のアップグレード中に減少です。

従来の非雲展開顔は雲の展開は、主な課題:ローリング アップグレードを実行すると、混在バージョンのアプリケーションが実行されます。 インスタンス可能性がありますさまざまな映像を提供、さまざまなデータとサービスの接続を使用してなど。 これは、サイトのエラーまたはも望ましくないユーザー エクスペリエンスにつながることができ、お客様のビジネスを完全に容認できない場合があります。 また、再生で複数のバージョンがある場合、アプリケーションが実行されるかどうかを確認するには、開発とテスト チームの重い負担を置きます。

どのような場合は VIP のスワップを使用することはできず、可用性の要件を削除を妨げる展開？ あなたは、唯一の 2 つの更新プログラムのドメインと、一括更新を実行する、展開時に実行中のアプリケーションの単一のバージョンを保持を使用してみます。 欠点:あなたのサイトの容量の半分の移行時に使用できません。

グリッドの図 4 、アップグレードの実行に使用する方法を検討する際に役立ちます。

図 4 アップグレードの決定マトリックス

一括アップグレード

管理コンソール内とスクリプト経由の両方のアップグレードを実行する機能で良い進歩がなされました。 展開の数が比較的控えめな中堅企業、中小企業にとっては、それを通して Windows Azure の管理コンソールを使用するに示すように、更新を管理する最も簡単です図 5。

図 5 Windows Azure の管理コンソール

画面の左上隅を見ることができる、手動のアップグレードを実行しています。 これは、ドメインごとにアップグレード プロセスを開始するには [スタート] ボタンをクリックする必要があります — それのマニュアルの一部です。 更新が開始されると、コンソールのインスタンス内の各ドメインで起こっているものがのようが表示されます図 6。

図 6 更新アクティビティ

マニュアル、押しボタン メソッドも小規模な展開では動作します。 大規模な展開や、ビルド、テスト、展開プロセスを自動化するには、スクリプト化されたアプローチを選択する必要があります。 CSManage コマンド ライン ツールからダウンロードすることができますを使用して、プロセスを自動化することができます bit.ly/A6uQRi。 CSManage、アップグレードを開始し、コマンドラインから一度に 1 つの更新プログラムのドメインのアップグレード プロセスを歩きます。 これは便利ですが、REST API を直接使用してのみ実行することができます微調整のレベルです。

障害のドメインとアップグレードの戦略をカスタマイズします。

1 つの理由または別のない 0 ～ n 更新ドメインを歩くと、代わりに独自の開始ポイントまたは順序を使用することを決定した場合、更新プログラムと障害のドメインの組み合わせを見てする必要があります。 グリッドの図 7 ドメイン 1、アップグレードを更新され障害ドメイン 0 には、更新中に障害が発生した場合は、サイトを完全にダウンだろうことは明らかです。 これは、通常、ファブリックで覆われている必要がありますしかし、更新プログラムの順序で場合は、常にあること異なる障害ドメインを実行して、グリッドに表示されます。

図 7 ドメイン マトリックス

ここでの教訓は、計画時に、潜在的な影響を考慮して」はすでに取り組んでいる何かに修正されていない」です。

まとめ

Windows Azure アプリケーションを設計しているとき、展開アーキテクチャを考慮する必要があります。 Windows Azure エラー アプリケーション 1 つのハードウェア障害のために、増分の展開を更新するには、簡単に、自動方法を提供するは発生しませんを確認するには、ファブリックの機能を提供します。 インプレース更新にアプリケーションが設計されていないもののサポートはまだ、— と押されている更新プログラム。

VIP スワップまたはアップグレード-ドメインを 2 つ、場所での計画を完全な場所で更新をサポートすることはできませんを使用して、Windows Azure サービスを更新することができます。 最後に、両方の UI とスケジュールされた更新を実行またはもビルド、テスト、展開のスケジュールまたはスケジュールされた更新を使用できるように、更新プログラムの展開を制御するプログラムのことです。

Joseph Fultz*、ヒューレット ・ パッカード株式会社グッドエイチピードットコム グローバル IT グループの一部としての作業でするソフトウェア アーキテクトです。 以前、彼はマイクロソフト、一流企業と ISV の顧客のアーキテクチャと設計のソリューションを定義するためのソフトウェアアーキテクトだった。*

この記事のレビュー、技術スタッフのおかげでに： Don Glover