Puncte:1

AWS Application Load Balancer reduce aplicația ASP.NET

drapel ng

Am un AWS Application Load Balancer configurat cu EC2 și un grup de scalare automată. Instanțele EC2 rulează un server web Windows+IIS. Serverul Web se conectează la o bază de date.

S-a întâmplat în unele situații (o dată la 2 luni) ca verificările de sănătate pentru ALB să înceapă să detecteze aplicația ca nesănătoasă și să elimine instanțele EC2. Există întotdeauna cel puțin 2 instanțe care rulează, iar acest lucru se întâmplă pentru toate instanțele în același timp.Încerc să înțeleg de ce se întâmplă acest lucru și nu găsesc niciun jurnal sau indicații utile despre unde provine acest lucru.


Vedeți cum instanțele scad la zero dintr-o dată pe 12/6:

în cazuri de service

Mărit:

în cazurile de service, mărite

Instanțele EC2 sunt terminate ca:

motiv de încetare

Verificarea sănătății este configurată pentru a trimite ping la o pagină care o face nu interogați baza de date, astfel încât un blocaj în baza de date nu pare cauza probabilă.

Când se întâmplă asta, timpul de răspuns crește vertiginos:

timp de răspuns la cerere

Și, de asemenea, măsurat de NewRelic:

timp de răspuns newrelic

Rețineți câteva lucruri:

  • toate fazele răspunsului sunt mai lente (timp Redis, timp .NET etc.)
  • se întâmplă tuturor serverelor să fie în același timp, așa că este puțin probabil să fie o problemă în interiorul serverului
  • s-a întâmplat întotdeauna în afara orelor de lucru când sarcina este scăzută

Configurații de scalare automată:

Capacitate minima=2
Capacitate maxima=15
Distribuția instanțelor= 50% la cerere, 50% spot
Includeți capacitatea de bază la cerere=Desemnați primele 1 instanțe ca la cerere
Strategia de alocare la cerere=Prioritizată
Strategia de alocare spot=Prețul cel mai mic - diversificat în cele 10 pool-uri cu cel mai mic preț
Reechilibrare capacitate=Oprit
Protecție de scalare a instanței=Nu este protejată de scalare
Politici de terminare=Implicit
Timp de răcire implicit=300

Configurații grup țintă:

Protocol=HTTPS
Path=/path/to/login/page
Port=Port de trafic
Prag de sănătate = 2 succese consecutive ale verificării de sănătate
Prag nesănătos=4 eșecuri consecutive de verificare a stării de sănătate
Timeout=20 secunde
Interval=25 secunde
Coduri de succes=200
Tim avatar
drapel gp
Tim
Ar putea fi ceva de genul Windows Update care repornește serverele după ce faceți corecții? Pentru a atenua acest lucru, este posibil să puteți crește pragul nesănătos pentru a oferi instanțelor mai mult timp să se recupereze. Mă întreb dacă puteți eșalona timpii de actualizare a Windows, astfel încât o instanță să rămână sănătoasă. Pentru a diagnostica mai departe, cel mai ușor ar fi să „puse în carantină” cumva serverele care eșuează verificările de sănătate pentru inspecția manuală. Împingerea jurnalelor de server în Cloudwatch Logs poate fi de ajutor atâta timp cât jurnalele sunt trimise prompt.
drapel ng
Mulțumiri. Cum să fac asta? Nu se întâmplă des și atunci când se întâmplă, cazurile sunt imediat terminate de îndată ce devin nesănătoase.
Tim avatar
drapel gp
Tim
Nu știu cum să o fac, ar trebui să fac niște cercetări, pe care să le cercetezi. Totuși, primul lucru de făcut este să vă schimbați imaginea pentru a împinge jurnalele în jurnalele Cloudwatch cât mai repede posibil, cel puțin astfel puteți vedea ce face serverul înainte ca verificările de sănătate să eșueze. Aș împinge Windows și jurnalele de aplicații.
drapel cn
Având în vedere motivul este „închiderea inițiată de utilizator”, aceasta sună ca o actualizare Windows sau se întâmplă altceva. Sau o altă sarcină programată - lucrați într-un cont care face parte dintr-o organizație AWS care ar putea avea lucruri în curs de rulare? Ultimul meu angajator avea niște lambda care ar închide instanțe pe baza etichetelor...
drapel ng
Nu există alte lucruri care rulează care ar putea afecta acel AFAIK. Actualizarea Windows ar putea fi dacă toate instanțele s-au actualizat în același timp, dar din moment ce unele dintre instanțe nou create au eșuat și ele (până la 30 de minute mai târziu, când a început dintr-o dată să funcționeze), pare foarte puțin probabil.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.