Nginx Reverse Proxy - Versuchen Sie Upstream A, dann B, dann erneut A

Question 1

Wichtige Punkte:

Kümmern Sie sich nicht um upstreamBlockierungen für ein Failover, wenn durch das Pingen eines Servers ein anderer hochfährt – es gibt keine Möglichkeit, nginx mitzuteilen (zumindest nicht der FOSS-Version), dass der erste Server wieder hochgefahren ist. nginx probiert die Server bei der ersten Anfrage der Reihe nach aus, nicht jedoch bei Folgeanfragen, ungeachtet aller - backup, weight- oder fail_timeout-Einstellungen.
DumussAktivieren Sie diese Option recursive_error_pages, wenn Sie ein Failover mithilfe error_pagebenannter Standorte implementieren.
Aktivieren Sie diese Option proxy_intercept_errors, um vom Upstream-Server gesendete Fehlercodes zu verarbeiten.
Die =Syntax (z. B. error_page 502 = @handle_502;) ist erforderlich, um Fehlercodes am benannten Ort korrekt zu verarbeiten. Wenn =sie nicht verwendet wird, verwendet nginx den Fehlercode aus dem vorherigen Block.

Hier ist eine Zusammenfassung:

server {
    listen ...;
    server_name $DOMAINS;

    recursive_error_pages on;

    # First, try "Upstream A"
    location / {
        error_page 418 = @backend;
        return 418;
    }

    # Define "Upstream A"
    location @backend {
        proxy_pass http://$IP:81;
        proxy_set_header  X-Real-IP     $remote_addr;
        # Add your proxy_* options here
    }

    # On error, go to "Upstream B"
    error_page 502 @handle_502;

    # Fallback static error page, in case "Upstream B" fails
    root /home/nginx/www;
    location = /_static_error.html {
        internal;
    }

    # Define "Upstream B"
    location @handle_502 { # What to do when the backend server is not up
        proxy_pass ...;
        # Add your proxy_* options here
        proxy_intercept_errors on;          # Look at the error codes returned from "Upstream B"
        error_page 502 /_static_error.html; # Fallback to error page if "Upstream B" is down
        error_page 451 = @backend;          # Try "Upstream A" again
    }
}

Ursprüngliche Antwort/Forschungsprotokoll folgt:

Ich habe folgenden ~~besseren~~ Workaround gefunden, der eine Verbesserung darstellt, da er keine Client-Umleitung erfordert:

upstream aba {
    server $BACKEND-IP;
    server 127.0.0.1:82 backup;
    server $BACKEND-IP  backup;
}

...

location / {
    proxy_pass http://aba;
    proxy_next_upstream error http_502;
}

Bringen Sie den Kontrollserver dann einfach dazu, bei „Erfolg“ 502 zurückzugeben, und hoffen Sie, dass dieser Code nie von den Backends zurückgegeben wird.

Update: nginx markiert den ersten Eintrag im upstreamBlock immer als inaktiv, sodass es bei aufeinanderfolgenden Anfragen die Server nicht der Reihe nach durchprobiert. Ich habe versucht, weight=1000000000 fail_timeout=1den ersten Eintrag zu ergänzen, aber ohne Erfolg. Bisher habe ich keine Lösung gefunden, die keine Client-Umleitung erfordert.

Bearbeiten: Eine weitere Sache, die ich gerne wüsste – um den Fehlerstatus vom error_pageHandler abzurufen, verwenden Sie diese Syntax: error_page 502 = @handle_502;– dieses Gleichheitszeichen veranlasst nginx, den Fehlerstatus vom Handler abzurufen.

Bearbeiten: Und ich habe es zum Laufen gebracht! Zusätzlich zum error_pageobigen Fix musste ich nur noch aktivieren recursive_error_pages!

Answer