2014-03-07 7 views
8

Ich habe Autoscale verwendet, um zwischen 2 und 1 Instanzen eines Cloud-Service zu wechseln, um die Kosten zu senken. Dies funktioniert meistens, außer dass von Zeit zu Zeit (nicht sicher, was das Muster hier zu sein scheint), der Akt des Hochskalierens (1-> 2) sowohl Instanzen zu recyceln, einen Dienstausfall für Benutzer verursacht.Azure Autoscale startet laufende Instanzen neu

Unter der Annahme, dass in RoleEntry als Reaktion auf Topologieänderungen nichts Besonderes passiert, warum würde die Skalierung von 1 -> 2 die bereits laufende Instanz neu starten?

Zusätzliche Hinweise:

  • Es ist klar, beide Instanzen sind Recycling von im Management Portal an den Instanzen Registerkarte suchen. Der Ausfall kann auch durch Klicken auf die öffentliche Website bestätigt werden.
  • Es passiert nicht konsequent, aber ich bin mir nicht sicher, was das Muster ist. Es fühlt sich an, als wenn die 1-Instanz-Konfiguration mehrere Tage lang ausgeführt wurde. Wenn die 1-Instanz-Konfiguration jedoch nur für einige Stunden ausgeführt wurde, können Sie ohne Ausfallzeiten nach oben und unten skalieren.
  • Die erste Instanz kommt immer viel schneller zurück als die zweite Instanz, die eingeführt wird.
+0

Wie bestimmen Sie, dass beide Instanzen recyceln? – kwill

+0

@kwill Wird auf dem Instanzen-Tab im Verwaltungsportal gemeldet ... Ich kann bestätigen, indem ich auf die Website klicke und sehe, dass sie nicht mehr reagiert. – Nariman

Antwort

1

Das war schon immer so. Wenn 1 Server ausgeführt wird und Sie zu 2+ wechseln, wird der ursprüngliche Server neu gestartet. Um eine vollständige SLA zu erhalten, müssen Sie immer über 2 Server verfügen.

+0

Ja, das sollte die Antwort sein. Microsoft warnt sogar davor, auf vielen VMs eine Rolle zu spielen, bevor Sie Ihren Service veröffentlichen. In der Tat können Sie eine Eigenschaft festlegen, um Bereitstellungen für nur eine Instanz zu verhindern. –

+0

Irgendwelche Links zur offiziellen Dokumentation? Ich dachte, die Empfehlung, mehr als eine Instanz zu haben, war immer darauf zurückzuführen, dass Sie Instanzen in verschiedenen Fehlerdomänen für MS-Neustart-Instanzen für Windows-Updates haben oder Wartungsarbeiten durchführen. Wo sagen sie, dass die Skalierung von 1 Instanz auf 2 Instanzen Ausfallzeiten verursacht? – OffHeGoes

0

Sie sollten dieses Verhalten steuern können. In der roleEntrypoint gibt es ein Ereignis, das Sie abfangen können, RoleEnvironmentChanging.

Eine Schale von Code in Ihre Lösung zu setzen aussehen wird ...

RoleEnvironment.Changing += RoleEnvironmentChanging; 

private void RoleEnvironmentChanging(object sender, RoleEnvironmentChangingEventArgs e) 
{ 
} 

RoleEnvironment.Changed += RoleEnvironmentChanged; 

private void RoleEnvironmentChanged(object sender, RoleEnvironmentChangedEventArgs e) 
{ 
} 

Dann innerhalb der RoleEnvironmentChanged Methode können wir erkennen, was die Änderung und Azure sagen, ob wir neu gestartet werden sollen oder nicht.

if ((e.Changes.Any(change => change is RoleEnvironmentConfigurationSettingChange))) 
{ 
    e.Cancel = true; // don't recycle the role 
} 
+0

Ich glaube, dass, wenn Sie 1 Server haben, es immer noch neu gestartet und aus der LB gezogen wird, unabhängig von der Behandlung von Changed Event. Dies basiert auf zahlreichen Kommentaren von AzureWatch Kunden – Igorek

+0

Danke Igor, ich werde versuchen, eine Auszeit an diesem Wochenende zu machen, um zu überprüfen. :) – BrentDaCodeMonkey

+0

Ich werde versuchen, einige Details zusammenzustellen, wenn ich eine Chance bekomme, aber im Wesentlichen ist Igor richtig. Was passiert, wenn die zweite Instanz den Status "Bereit" erreicht, wird der erste aus der LB-Rotation genommen, um die Topologieänderung zu verarbeiten.Während dieser Zeit, wenn Instanz 2 eine lange w3wp Aufwärmzeit hat, werden Clients Timeout oder haben wirklich lange laufende Anfragen. – kwill

0

Nariman, siehe meinen Kommentar zu Brents Post für einige Informationen darüber, was passiert. Sie sollten in der Lage sein, dies mit dem folgenden Code zu beheben:

public class WebRole : RoleEntryPoint 
{ 
    public override bool OnStart() 
    { 
     // For information on handling configuration changes 
     // see the MSDN topic at http://go.microsoft.com/fwlink/?LinkId=166357. 
     IPHostEntry ipEntry = Dns.GetHostEntry(Dns.GetHostName()); 
     string ip = null; 
     foreach (IPAddress ipaddress in ipEntry.AddressList) 
     { 
      if (ipaddress.AddressFamily.ToString() == "InterNetwork") 
      { 
       ip = ipaddress.ToString(); 
      } 
     } 

     string urlToPing = "http://" + ip; 
     HttpWebRequest req = HttpWebRequest.Create(urlToPing) as HttpWebRequest; 
     WebResponse resp = req.GetResponse(); 
     return base.OnStart(); 
    } 
} 
+0

Das macht eine Anfrage an sich, w3wp aufzurufen, damit eine Endbenutzeranfrage nicht notwendig ist? Ich würde viel lieber, dass OnStart nicht auf dieser bereits laufenden Instanz aufgerufen werden. – Nariman

+0

Dieser Code wird nur auf Instanz 2 ausgeführt - Instanz 1 wird bereits ausgeführt und wird nicht wiederverwendet. Wenn dieser Code in Instanz 2 ausgeführt wird, wird Instanz 2 daran gehindert, den Status Bereit zu erreichen, bis w3wp bereit ist. Dies bedeutet, dass, wenn Instanz 1 vorübergehend aus der Load-Balancer-Rotation entfernt wird, Instanz 2 bereit ist, Datenverkehr zu empfangen. – kwill

+0

Ich sehe Instanz 1 aus der LB entfernt (mit Topologie geändert Ereignisauslösung) lange vor Instanz 2 ist in Bereitschaft und in Bereitschaft. Ich denke, dass das Topologieänderungsereignis bereits vor der Erstellung der zweiten VM auftritt – Nariman