Jag har använt Alibaba Cloud SLB lastbalanserare i mer än 5 år, och jag har använt den sedan den initiala interna betan av Alibaba Cloud, och efter implementeringen uppstod följande fel:
Fel uppstår intermittent, efter att ha startat initialt finns inget 502-gatewayfel, efter att ha väntat en minut dyker felet upp, backend Windows Server IIS-containern ASP.NET webbplatsen.
Klicka på IIS från servern för att öppna webbläsaren, du kan bläddra normalt, SLB:s lastbalanseringsproblem indirekt, det är första gången jag stöter på det.
Lösning:
Problemet förekommer främst i inställningarna för "Health Check Method", standardinställningarna är följande:
Backend-hälsokontrollen begärs i huvudet, och om motsvarande statuskod returnerar 2xx eller 3xx anses backend-servern vara normal.
Vi försökte göra en header-förfrågan på tre sätt: först körde jag det lokala projektet direkt och testade det lokalt.
Test 1:
Använd postbudstestet som visas nedan:
Om vi återvänder till 404 Not Found-tillståndet, vet vi faktiskt vad som orsakade det.
Test 2:
Använd curl-testning enligt nedan:
C:\Users\itsvse>curl -i -X HEAD http://localhost:60155/
Warning: Setting custom HTTP method to HEAD with -X/--request may not work the
Warning: way you want. Consider using -I/--head instead.
HTTP/1.1 404 hittades inte
Cache-Control: private
Content-Length: 4432
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/10.0
X-SourceFiles: =?UTF-8?B?QzpccHJvamVjdFxteVxDb2RlU2hhcmluZ1xDb2RlU2hhcmluZy5XZWJVSVxIb21lXEVycm9yNDA0?=
X-Powered-By: ASP.NET
Date: Tue, 13 Aug 2019 03:53:04 GMT
curl: (56) Recv failure: Connection was reset
Även en statuskod 404 återlämnas.
Test 3:
Den här gången testade vi direkt på den officiella servern, genom curl-testet under PowerShell, som visas i figuren nedan:
Du kan se att samma sida efterfrågas via huvudet,Ibland återvänder404Statuskod, ibland returnerad200Statuskod, vilket bekräftar de intermittenta 502-fel vi stötte på i början.
Vad orsakar att asp.net ibland returnerar 404- och 200-statuskoder?
Eftersom vår startsida har en cache, när användaren använder get-metoden för att begära startsidan, kommer sidan att cachelagras framgångsrikt, och sedan kommer head och get alltid att returnera den cachade sidan, och returnerar även 200-svarskoden, om ingen användare gör en get-metod-förfrågan efter att cachen har gått ut, endast head-metodförfrågan via kommandot, kommer ett 404-fel att inträffa. Det uppskattas att få människor kommer att stöta på denna typ av problem.
Lösningen är att kontrollera alla svarskoder i hälsokontrollläget, som visas i figuren nedan:
Hur man felsöker hälsokontroller vid Layer 7 Listening (HTTP/HTTPS):Inloggningen med hyperlänken är synlig.
(Slut)
|
Publicerad på 2019-08-13 14:42:43
|
|
|
|
