Dieser Artikel wurde maschinell übersetzt.

Prognose: Bewölkt

Bereitstellungsdomänen für Windows Azure

Joseph Fultz

In letzter Zeit habe ich sehr viele Gedanken um die Bereitstellung von Anwendungen gegeben. Es stellt sich heraus, dass für Anwendungen, die Matrix für Fehler Toleranz und Upgrade Pfad ein bisschen schwierig wird — und noch schwieriger, wenn Anwendungen eine Mischung aus Dienstleistungen, eine Web-Benutzeroberfläche und Back-End-Prozesse. Fügen Sie in geografische Verteilung und die Logistik werden noch mehr davon.

In großen IT-Organisationen, eine minimale Bereitstellung jedweder Anwendung Web Server beinhaltet häufig zwei Server, die geographisch voneinander getrennt sind. Das leicht bewegt bis zu vier Servern, wenn zwei Server für die erwartete Last angegeben sind und Sie eine Spiegelungs-Site mit der gleichen Konfiguration haben (natürlich, Datenbank und andere unterstützende Serverinfrastruktur können drücken die Zahl noch höher). Was passiert, wenn das Unternehmen mehrere Standorte, wie Nordamerika und Europa, Nahost und Afrika (EMEA) bedient? Jetzt das Setup auf beiden Seiten des Atlantiks repliziert wird, begannen drehen was zwei Web-Server in acht Server für Geo-Failover und staging Vermögenswerte näher an die Verbraucher.

Schließlich, eine Anwendung auf diesen Servern bereitgestellt wird und alles ist reibungslos zusammen — und dann einige freche Developer erstellt neue Funktionalität und die Bereitstellung aktualisieren möchte.

Wie Sie sich vorstellen können, braucht es ein gutes Stück der Planung bestimmen die Reihenfolge in der Server Verbindungen ablassen wird, erhalten aktualisiert und getestet und dann in den Pool zurückgestellt werden. Einige Leute verbringen spät in die Nacht arbeiten durch Upgrade-Pläne, und das ist auch beim gibt es keine wirklichen Probleme.

Windows-Azure nicht beseitigen die Notwendigkeit eines Upgrade-Plans, aber es dauert viel von der Komplexität von aktualisieren indem Sie behandeln die meisten davon als Teil des Gewebes. In dieser Spalte ich werde Abdeckung Schuld und Upgrade-Domänen, und schreiben Sie ein wenig Code, um ein Upgrade auf die Bereitstellung anwenden.

Fehler- und Upgrade-Domains

Windows-Azure umfasst die Konzepte der Schuld und Upgrade-Domänen, die fast vollständig von ihren Namen beschrieben werden. Fehlertoleranz Domänen definieren eine physische Einheit der Bereitstellung für eine Anwendung und werden in der Regel auf Rack-Ebene zugeordnet. Durch die Platzierung von Fehlertoleranz Domänen in separaten Rack, trennen Sie Instanzen der Anwendungsbereitstellung Hardware genug, die es ist unwahrscheinlich, dass alle zur gleichen Zeit fehlschlagen würde. Weiter sollte ein Fehler in einer Schuld Domäne nicht das Scheitern eines anderen Niederschlag. Wenn Sie eine Rolle mit zwei konfigurierten Instanzen bereitstellen, sorgt das Gewebe die Instanzen in zwei verschiedenen Fehlertoleranz Domänen aufgewachsen sind. Leider mit Fehlertoleranz Domänen haben Sie keine Kontrolle über wie viele Domains verwendet werden oder wie Rollen sie zugeordnet werden.

Upgrade Domains sind eine andere Sache. Sie haben die Kontrolle über diese Domänen und inkrementelle oder fortlaufende Aktualisierungen in einer Bereitstellung durch Aktualisieren einer Gruppe von Instanzen gleichzeitig ausführen. Fehlertoleranz Domänen über physische Bereitstellung der Rollen sind, beziehen sich auf logische Bereitstellung Upgrade Domänen. Da eine Upgrade Domäne eine logische Gruppierung von Rollen ist, gäbe es eine einzelne Webanwendung leicht in fünf verschiedenen Upgrade-Domänen in nur zwei separaten physischen Bereitstellungen (Fehlertoleranz Domänen) unterteilt. In diesem Fall möglicherweise um eine Webanwendung aktualisieren, Sie alle Rollen in Gruppe 0 (Upgrade Domäne 0) und dann alle Rollen in Gruppe 1 und so weiter aktualisieren. Sie können mehr endliche Kontrolle ausüben, indem einzelne Rollen eine zu einem Zeitpunkt in jeder Domäne aktualisieren Aktualisieren.

Zusammenfassend wird eine Anwendung, die mehr als eine Instanz muss in mindestens zwei Fehlertoleranz Domänen aufgeteilt werden. Um die Aktualisierung einer Web-Anwendungs in der gesamten Farm einfacher zu machen, sind Rollen in logischen Gruppierungen zusammen, die zur gleichen Zeit aktualisiert werden.

Die Bereitstellung-Konfiguration anzeigen

Der Windows-Azure-Verwaltungskonsole zeigt eine Spalte Domäne aktualisieren, aber keine Fault Domain-Spalte (siehe Abbildung 1). (Anmerkung, die Domäne und Domäne aktualisieren sind austauschbare Begriffe. Die Dokumentation oft bezieht sich auf Domänen aktualisieren, aber in der API it's called eine Domäne aktualisieren.)

Abbildung 1 der Windows Azure-Verwaltungskonsole

In Abbildung 1Sie können sehen, dass die Zahlen für meine vier Bereitstellungen von 0 bis 3 laufen. In der Standardeinstellung Windows Azure verwendet fünf Update-Domänen für jeden Dienst und ordnet sie in einem Round-Robin-Stil. Dies ist etwas, das Sie in der Service-Definition-Datei ändern können, indem Sie das UpgradeDomainCount-Attribut des Elements ServiceDefinition die gewünschte Anzahl der Upgrade Domains zuweisen. Finden Sie Links für jeden der Schemas für Web und Arbeitsprozess Rollen am msdn.microsoft.com/library/ee758711. Um eine WebRole nur drei Upgrade Domänen verwenden zu erzwingen, legen Sie beispielsweise die UpgradeDomainCount in der Service-Definition-Datei:

<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>

Dies ist wichtig, da die Anzahl der Update-Domänen letztlich Ihren Plan und Ausführung betrifft. Leider gibt es keine Spalte, mit der Sie Fehler Domäne Zuordnungen zu sehen. Durch das Schreiben von etwas Code, jedoch können Sie ziehen wieder den Vorhang ein wenig über die Bereitstellung und sehen beide Aktualisieren von Fehlertoleranz und Domäne Domäne Zuordnungen, als Abbildung 2 zeigt.

Abbildung 2 suchen Rolleninformationen

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();

}

Dieser Code zeigt keiner kleinen Klasse, dass ich so definiert, dass um die relevante Informationen zu speichern. Und leider, wenn ich diese schöne geschachtelte Schleife, die durch die Rollen und die Instanzen geht haben, die API ermöglicht den Code auf der Seite zum Zurückgeben von Daten mit Bezug auf nur die bestimmte Instanz, den Code ausführen ausgeführt wird. Damit der Code erzeugt eine kleine Raster mit den aktuellen WebRole Informationen drin (siehe Abbildung 3), ohne andere Instanzinformationen.

Abbildung 3 aktuelle WebRole Informationen

Dieser Code bietet einen kurzen Blick auf das aktuelle WebRole Fehler- und Upgrade Domänen, aber du musst die erhalten Bereitstellung REST URI verwenden, um umfassendere Daten zu erhalten. Es gibt die Bereitstellung XML enthält, unter anderem Elemente für <Configuration/> und für jede der <RoleInstances/>. Nachdem Sie die Konfiguration geholt haben, können Sie ändern und legen Sie sie wieder. Werfen Sie einen Blick an meinem Artikel vom Oktober 2010 (msdn.microsoft.com/magazine/gg232759) Beispiele für die viele der Vorgänge, die hier beteiligt sein würde.

Upgrade-Strategien

Es gibt zwei grundlegende Strategien für die Aktualisierung einer Windows Azure-Bereitstellung: vor-Ort-Aktualisierungen und virtuelle IP (oder VIP) tauschen. VIP-Swap ist der einfachere Ansatz und erlaubt die vollständige Prüfung der neue oder aktualisierte Anwendung vor dem Öffnen die Tore für die Öffentlichkeit. Darüber hinaus kann die Anwendung bei voller Auslastung ausgeführt, sobald es aktiv ist. Probleme sollte es wenn der Swap abgeschlossen ist, setzen schnell Sie die vorherige Version wieder während die neue Bereitstellung wird an ihnen gearbeitet.

Hier finden Sie eine gute Referenz, die beschreiben, was kann nicht getan werden kann und in jedem Bereitstellungsmodell der bei bit.ly/x7lRO4. Hier sind die Punkte, die eine Wahl erzwingen könnte:

• In-Place-Aktualisierung oder das Löschen und das Bereitstellen sind erforderlich, wenn der Typ oder die Anzahl der Endpunkte ändern.
• VIP tauschen oder löschen und Bereitstellung erforderlich sind, wenn die Rolle Name oder Update Anzahl der Domäne ändern oder die Größe der lokalen Ressourcen zu verringern.

Anders als diese Punkte und einige SDK Version Überlegungen liegt es an Ihnen zu entscheiden.

Austauschen der VIP der Test- und Produktionsumgebungen Umgebungen ist eine ziemlich gute Lösung für viele, wenn nicht den meisten Fällen beim Roll-out einer neuen Version. Manchmal ist es die einzige Möglichkeit, die Website vor allem beim vornehmen von Änderungen, zu halten, aber wenn Sie eine große Bereitstellung aktualisieren, eine weitere vollständige Bereitstellung der Erziehung umständlich sein kann. Es gibt auch Kosten verbunden mit der Bereitstellung von eine vollständige Kopie — eine Compute Stunde berechnen für jede Instanz und dann die zusätzliche Compute-Stunden für die beiden ausgeführten Kopien bereitgestellt.

In Web-Farmen sind heute, Aktuelles in der Regel durch eine Farm von entweder ausgerollt: unter einem Server offline zu einem Zeitpunkt, Modernisierung, bringen den Server online und wieder in den Bauernhof-Pool; oder die Farm in Segmente unterteilen und entwässert die Verbindungen auf ein Segment zu einer Zeit, dann aktualisieren jedes Segment bringt es online und an der Farm zurückgegeben, und schließlich zum nächsten Segment bewegen.

Ein in-Place-Aktualisierung funktioniert wie das zweite Muster. Jedoch aktualisieren, desto mehr Domänen verwendet, desto mehr ähnelt das Muster die erste Option. Der Vorteil der Verwendung einer größeren Anzahl von Domänen Upgrade ist, dass die Sitekapazität während der gesamten Aktualisierung nur durch die Größe des Segments wird verringert.

Die primäre Herausforderung, dass herkömmliche nicht-Cloud-Bereitstellungen Gesicht für Wolke Bereitstellungen identisch ist: beim Ausführen von parallelen Updates werden gemischte Versionen der Anwendung ausgeführt werden. Die Instanzen möglicherweise liefern unterschiedliche Darstellungen, verwenden unterschiedliche Daten und Stromleitungen und so weiter. Dies kann zu Website Fehler oder sogar unerwünschte Benutzererfahrungen führen, und kann es völlig inakzeptabel für Ihr Unternehmen. Darüber hinaus setzt es eine schwere Belastung auf die Entwicklung und Test-Teams um sicherzustellen, dass die Anwendung ausgeführt wird, wenn mehrere Versionen im Spiel sind.

Was tun Sie, wenn Sie können nicht VIP Swap verwenden und Anforderungen an die Verfügbarkeit bereitstellen und Delete entgegen? Sie könnten versuchen, mit nur zwei Update-Domänen und eine in-Place-Aktualisierung, die eine einzelne Version der Anwendung ausgeführt, während der Bereitstellung hält. Der Nachteil: die Hälfte der Kapazität Ihres Aufstellungsortes wird während des Übergangs nicht verfügbar sein.

Das Raster in Abbildung 4 könnte helfen, Sie prüfen, welche Vorgehensweise, bei der Durchführung eines Upgrades zu beschäftigen.

Abbildung 4 Upgrade Entscheidungsmatrix

Strategie für die Bereitstellung	Vorteile	Nachteile
Löschen und bereitstellen	Alle Änderungen können vorgenommen werden	Anwendung nicht verfügbar bei
VIP-Swap	Vollständige Anwendungskapazität Die meisten Änderungen können vorgenommen werden Teste die neue Bereitstellung in Inszenierung Schnell durch Ausführen einer VIP Swap wieder rückgängig machen	Schluckauf im Dienst bei swap Umständlich zu bringen zwei vollständige Bereitstellungen bei größeren Bereitstellungen Die Anzahl oder Typ der Endpunkte kann nicht geändert werden.
In-Place-Aktualisierung: 2 Update-Domänen	Nur eine Version gleichzeitig ausgeführt Können Anzahl und Typ von Endpunkten ändern Nicht erforderlich vollständige Bereitstellung	Website-Kapazität um die Hälfte zurückgegangen Einige Operationen können nicht ausgeführt werden
In-Place-Aktualisierung: 3++ Update-Domänen	Weitere Sitekapazität bei Aktualisierung Können Anzahl und Typ von Endpunkten ändern Nicht erforderlich vollständige Bereitstellung	Mehrere Versionen gleichzeitig ausgeführt werden Einige Operationen können nicht ausgeführt werden

Update an Ort und Stelle

Schöne Fortschritte wurden in der Fähigkeit, das Upgrade innerhalb der Verwaltungskonsole und über Skripte auszuführen. Für kleine und mittelständische Unternehmen mit einer relativ geringen Anzahl von Bereitstellungen, ist es am einfachsten zu verwalten die Updates über die Windows Azure Management Console, gezeigt Abbildung 5.

Abbildung 5 Windows Azure Management-Konsole

Wie Sie in der oberen linken Ecke des Bildschirms sehen können, ist eine manuelle Aktualisierung ausgeführt. Dazu müssen Sie auf die Schaltfläche Start zur Einleitung des Prozesses für jede Upgrade-Domäne – das ist der manuelle Teil davon. Sobald das Update gestartet wird, zeigt die Konsole was geht in den Instanzen in jeder Domäne, wie in Abbildung 6.

Abbildung 6 Update Aktivität

Das Handbuch funktioniert Push Methode gut für kleinere Bereitstellungen. Für größere Bereitstellungen oder solche, wo Sie die Build-Test-Bereitstellung automatisieren möchten, sollten Sie einen skriptgesteuerten Ansatz. Sie können automatisieren den Prozess mit dem Befehlszeilentool CSManage, die Sie, von herunterladen können bit.ly/A6uQRi. CSManage wird das Upgrade zu initiieren und gehen Sie durch den Prozess der Aktualisierung ein Update-Domäne zu einem Zeitpunkt von der Befehlszeile aus. Obwohl dies hilfreich ist, gibt es ein Maß an Feinabstimmung, die nur mit der REST-API direkt erreicht werden kann.

Anpassen Ihrer Upgrade-Strategie mit Fehlertoleranz Domänen

Wenn für einen oder anderen Grund, den Sie sich entschieden haben, nicht die Update-Domänen von 0 bis n gehen und stattdessen Ihre eigenen Start-Punkt oder Bestellung verwenden möchten, müssen Sie einen Blick auf die Kombination von Update und Fehlertoleranz Domänen. Das Raster in Abbildung 7 macht es deutlich, dass wenn Sie Upgrade-Domäne 1 aktualisieren, und Fault Domain 0 während der Aktualisierung Fehler, die Seite ganz herunter wäre. Dies sollte normalerweise durch den Stoff gedeckt werden, und das Raster zeigt, dass wenn das Update in Reihenfolge geschieht, es werden immer verschiedene Fehlertoleranz Domänen ausgeführt.

Abbildung 7 Domain Matrix

Instance	Domäne	Fehler-Domain
0	0	0
1	1	1
2	2	0

Die Lektion ist hier, mögliche Konsequenzen bei der Planung berücksichtigt und nicht "etwas, das bereits fix".

Nachbereitung

Wenn Sie eine Windows-Azure-Anwendung entwerfen, müssen Sie berücksichtigen Bereitstellungsarchitektur. Windows Azure stellt die Funktionalität des Gewebes um sicherzustellen, dass eine Anwendung nicht aufgrund einer einzigen Hardware-Fehler, Schuld und bietet eine einfache, automatische Art die Bereitstellung inkrementell aktualisieren wird. Noch, die Unterstützung für eine in-Place-Aktualisierung ist etwas, das in der Anwendung entwickelt werden muss — und das Update, das geschoben wird.

Sie können einen Windows-Azure-Service mit VIP Swap oder ein zwei-Upgrade-Domain, in-Place-Plan, wo eine vollständige in-Place-Aktualisierung werden nicht unterstützt, aktualisieren. Schließlich gibt es UI und programmatischen Mittel, um die Bereitstellung und Updates zu kontrollieren, so dass Sie können eine geplante Aktualisierung oder sogar eine Build-Test-Bereitstellung planen oder eines geplanten Updates verwenden.

Joseph Fultz ist Softwarearchitekt bei Hewlett-Packard Co. und Mitglied der HP.com Global IT-Gruppe. Zuvor war er als Software-Architekt für Microsoft und arbeitet mit Top-Tier-Unternehmen und ISV-Kunden definieren Architektur und Design-Lösungen.

Dank der folgenden technischen Experten für die Überprüfung dieses Artikels: Don Glover