Interpretation des Moduls zum Lastenausgleich mit nginx

Zwei Module zur Verwendung von nginx zum Lastenausgleich:

• Upstream definiert den Ladeknotenpool.
• Das Standortmodul führt einen URL-Abgleich durch.
• Das Proxy-Modul sendet Anfragen an den von Upstream definierten Knotenpool.

Interpretation des Upstreammoduls

Die Lastausgleichsfunktion von nginx hängt vom Modul ngx_http_upstream_module ab. Die unterstützten Proxy-Methoden sind proxy_pass (im Allgemeinen für Reverse-Proxy verwendet), fastcgi_pass (im Allgemeinen für die Interaktion mit dynamischen Programmen verwendet), memcached_pass, proxy_next_upstream, fastcgi_next_pass, memcached_next_pass.

Das Upstream-Modul sollte innerhalb des http{}-Tags platziert werden.

Modul schreiben:

Upstream-Backend {
  ip_hash; 
  Server backend1.example.com Gewicht=5;
  Server backend2.example.com:8080;
  Server-Backup1.example.com:8080-Backup;
  Server-Backup2.example.com:8080-Backup;
}

Beispiel 1:

Upstream-Dynamik
  Zone Upstream_Dynamic 64k;

  Server backend1.example.com Gewicht=5;
  Server backend2.example.com:8080 Fail_Timeout=5s langsamer_Start=30s;
  Server 192.0.2.1 max_fails=3;
  Server backend3.example.com auflösen;

  Server-Backup1.example.com:8080-Backup;
  Server-Backup2.example.com:8080-Backup;
}

Syntaxerklärung:

Nginx unterstützt standardmäßig vier Planungsalgorithmen

• Beim Polling (rr) wird jede Anfrage nacheinander und in chronologischer Reihenfolge an verschiedene Backend-Server weitergeleitet. Fällt ein Backend-Server aus, wird dieser vom fehlerhaften System automatisch freigeschaltet, so dass der Benutzerzugriff nicht beeinträchtigt wird.
• Polling-Gewicht (Gewicht). Je höher der Gewichtswert, desto höher die Wahrscheinlichkeit des zugewiesenen Zugriffs. Dies wird hauptsächlich in Fällen verwendet, in denen die Leistung jedes Backend-Servers ungleichmäßig ist.
• ip_hash, jede Anforderung wird entsprechend dem Hash-Ergebnis der Zugriffs-IP zugewiesen, sodass der feste Zugriff von derselben IP-Adresse auf einen Backend-Server erfolgt, wodurch hauptsächlich das Problem der Sitzungsfreigabe für dynamische Websites gelöst wird.
• url_hash verteilt Anfragen entsprechend dem Hash-Ergebnis der besuchten URL und leitet jede URL an denselben Backend-Server weiter, was die Effizienz des Backend-Cache-Servers weiter verbessern kann. nginx selbst unterstützt dies nicht. Wenn Sie es verwenden möchten, müssen Sie das Hash-Softwarepaket von nginx installieren.
• fair, dieser Algorithmus kann die Last intelligent entsprechend der Seitengröße und der Ladezeit ausgleichen, d. h. er verteilt Anforderungen entsprechend der Antwortzeit des Backend-Servers und priorisiert Anforderungen mit kürzeren Antwortzeiten. Dies wird standardmäßig nicht unterstützt. Wenn Sie es verwenden möchten, müssen Sie das Modul upstream_fail installieren.
• least_conn Die Mindestanzahl an Verbindungen. Für die Verteilung wird die Maschine mit der geringsten Anzahl an Verbindungen verwendet.

So schreiben Sie ein Servermodul

Server-IP-Planungsstatus

Die Serverdirektive gibt die IP-Adresse und den Port des Backend-Servers an und kann auch den Status jedes Backend-Servers in der Lastausgleichsplanung festlegen.

• down bedeutet, dass der aktuelle Server vorübergehend nicht am Lastausgleich teilnimmt.
• Backup ist ein reservierter Backup-Server. Wenn alle anderen Nicht-Backup-Server ausfallen oder ausgelastet sind, wird der Backup-Computer angefordert, da dieser Cluster am wenigsten belastet ist.
• max_fails ist die Anzahl der zulässigen Anforderungsfehler. Der Standardwert ist 1. Wenn die maximale Anzahl überschritten wird, wird ein vom Modul proxy_next_upstream definierter Fehler zurückgegeben. 0 bedeutet, dass Fehlversuche verboten werden. Unternehmensszenario: 2–3. JD.com 1 Mal, ChinaCache 10 Mal. Konfigurieren Sie entsprechend den Geschäftsanforderungen.

fail_timeout, die Zeit bis zur Unterbrechung des Dienstes nach max_fails-Fehlern. JD.com ist 3s, ChinaCache ist 3s, konfiguriert entsprechend den Geschäftsanforderungen. 2-3 Sekunden sind für Routinegeschäfte angemessen.
Wenn beispielsweise max_fails 5 ist, wird der Test 5 Mal durchgeführt. Wenn das Ergebnis alle fünf Male 502 ist, wird entsprechend dem Wert von fail_timeout 10 Sekunden gewartet, bevor der Test erneut durchgeführt wird.

Wenn der Server eine Verbindung zu einem Domänennamen herstellt, ist ein DNS-Server im Intranet erforderlich, oder die Domänennamenauflösung wird in der Hosts-Datei des Load Balancers durchgeführt. Der Server kann auch direkt an den IP- oder IP-Plus-Port angeschlossen werden.

Lange Verbindung Keepalive

Upstream-Backend {
  Server backend2.example.com:8080;
  Server-Backup1.example.com:8080-Backup;
  Keepalive 100;
}

Diese Anweisung konfiguriert die maximale Anzahl inaktiver Verbindungen, die jeder Arbeitsprozess beim Upstreamserver zwischenspeichern kann.
Wenn diese Zahl überschritten wird, wird die am wenigsten genutzte Verbindung geschlossen. Die Keepalive-Direktive begrenzt nicht die Gesamtzahl der Verbindungen, die ein Arbeitsprozess zu einem Upstream-Server herstellen kann.

Standort / {
  # Unterstützt Keep-Alive
  Proxy_http_Version 1.1;
  proxy_set_header Verbindung "";
  Proxy-Passwort http://Backup;
}

• Wenn es http/1.0 ist, müssen Sie es so konfigurieren, dass der Anforderungsheader „Connection: Keep-Alive“ gesendet wird.
  
• Vergessen Sie nicht, die Unterstützung für lange Verbindungen auf dem Upstream-Server zu aktivieren.
  

Empfehlungen zur Verbindungspoolkonfiguration

• Die Gesamtzahl der langen Verbindungen ist die Gesamtzahl der langen Verbindungen im „Pool freier Verbindungen“ + „Pool freigegebener Verbindungen“.
• Erstens begrenzt die Konfiguration für lange Verbindungen nicht die Gesamtzahl der Verbindungen, die der Arbeitsprozess öffnen kann (die Anzahl der Verbindungen, die diese Begrenzung überschreiten, wird als kurze Verbindungen behandelt). Darüber hinaus muss der Verbindungspool je nach Szenario sinnvoll eingerichtet werden.

Der Pool der inaktiven Verbindungen ist zu klein, die Verbindungen reichen nicht aus und es müssen kontinuierlich neue Verbindungen hergestellt werden.
Der Pool inaktiver Verbindungen ist zu groß, es gibt zu viele inaktive Verbindungen und es kommt zu einer Zeitüberschreitung, bevor sie verwendet werden können.
Es wird empfohlen, lange Verbindungen nur für kurze Nachrichten zu aktivieren.

Interpretation des Standortmoduls

Standortfunktion: Legen Sie die URI basierend auf einer Anweisung fest.

Grundlegende Syntax:

Syntax: Standort [ = | ~ | ~* | ^~ ] uri { ... }
Standort @name { ... }
Standard: -
Kontext: Server, Standort

• = Genaue Übereinstimmung. Wenn der zum =-Zeichen passende Inhalt gefunden wird, wird die Suche sofort abgebrochen und die Anfrage sofort (mit höchster Priorität) verarbeitet.
• ~ ist case-sensitiv
• ~* unterscheidet nicht zwischen Groß- und Kleinschreibung
• ^~ stimmt nur mit Zeichenfolgen überein, nicht mit regulären Ausdrücken
• @ gibt einen benannten Ort an, der im Allgemeinen für interne Neudefinitionsanforderungen verwendet wird, Ort @name {…}

Der Abgleich erfolgt nach Priorität und nicht entsprechend der Nginx-Konfigurationsdatei.

Offizielles Beispiel:

Standort = / {
  [ Konfiguration A ]
}
Standort / {
  [ Konfiguration B ]
}
Standort /Dokumente/ {
  [ Konfiguration C ]
}
Standort ^~ /images/ {
  [ Konfiguration D ]
}
Standort ~* \.(gif|jpg|jpeg)$ {
  [ Konfiguration E ]
}

abschließend:

• / entspricht A.
• /index.html entspricht B
• /documents/document.html entspricht C
• /images/1.gif entspricht D
• /documents/1.jpg entspricht E.

Testbeispiel:

Standort / {
      Rückgabe 401;
    }
    Standort = / {
      Rückgabe 402;
    }
    Standort /Dokumente/ {
      Rückgabe 403;
    }
    Standort ^~ /images/ {
      Rückgabe 404;
    }
    Standort ~* \.(gif|jpg|jpeg)$ {
      500 zurückgeben;
    }

Testergebnisse (Schwerpunkt):

[root@lb01 conf]# curl -I -s -o /dev/null -w "%{http_code}\n" http://10.0.0.7/
402
[root@lb01 conf]# curl -I -s -o /dev/null -w "%{http_code}\n" http://10.0.0.7/index.html
401
[root@lb01 conf]# curl -I -s -o /dev/null -w "%{http_code}\n" http://10.0.0.7/documents/document.html 
403
[root@lb01 conf]# curl -I -s -o /dev/null -w "%{http_code}\n" upload/2022/web/1.gif
404
[root@lb01 conf]# curl -I -s -o /dev/null -w "%{http_code}\n" upload/2022/web/1.gif 
500

Zusammenfassung der Ergebnisse:

Reihenfolge der Übereinstimmungspriorität, =>^~ (stimmt mit einem festen String überein, reguläre Ausdrücke werden ignoriert) > völlig gleich >~* > leer >/.

Versuchen Sie, beim Arbeiten '=' voranzustellen

Erläuterung des Proxy_pass-Moduls

Die Direktive proxy_pass gehört zum Modul ngx_http_proxy_module, das Anfragen an einen anderen Server weiterleiten kann.

Schreibmethode:

proxy_pass http://localhost:8000/uri/;

Beispiel 1:

  Upstream blog_real_servers {
     Server 10.0.0.9:80 Gewicht=5;
     Server 10.0.0.10:80 Gewicht=10;
     Server 10.0.0.19:82 Gewicht=15;
  }
  Server {
    hören Sie 80;
    Servername blog.etiantian.org;
    Standort / {
    Proxy-Passwort http://blog_real_servers;
    Proxy_Set_Header-Host $host;
    }
  }

• proxy_set_header: Wenn auf dem Back-End-Webserver mehrere virtuelle Hosts konfiguriert sind, wird dieser Header benötigt, um den Hostnamen des Reverse-Proxys zu unterscheiden: proxy_set_header host $host;.
• proxy_set_header X-Forwarded-For: Wenn das Programm auf dem Backend-Webserver die IP-Adresse des Benutzers abrufen muss, ermitteln Sie sie aus diesem Header. proxy_set_header X-Weitergeleitet-Für $remote_addr;

Konfigurieren Sie den Backend-Server so, dass er die echte Frontend-IP erhält

Die Konfiguration ist wie folgt:

  log_format commonlog '$remote_addr - $remote_user [$time_local] "$request" '
           '$status $body_bytes_sent "$http_referer" '
           '"$http_user_agent" "$http_x_forwarded_for"';

httpd.conf-Konfiguration des rs_apache-Knotens

LogFormat "\"%{X-Forwarded-For}i\" %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{U
ser-Agent}i\"" kombinierte ändern Protokollierung Apache
LogFormat "\"%{X-Forwarded-For}i\" %l %u %t \"%r\" %>s %b" allgemein

Optimierungsparameter im Zusammenhang mit proxy_pass

• client_max_body_size 10 m; Die maximale Anzahl von Bytes einer einzelnen Datei, die vom Client angefordert werden darf.
• client_body_buffer_size 128k; Die maximale Anzahl an Bytes, mit der der Pufferproxy die Client-Anforderung puffert, kann so verstanden werden, dass er sie zuerst lokal speichert und dann an den Benutzer weitergibt.
• proxy_connect_timeout 600; Das Timeout für die Verbindung mit dem Backend-Server und das Warten auf eine Antwort nach dem Initiieren eines Handshakes.
• proxy_read_timeout 600; Nachdem die Verbindung erfolgreich hergestellt wurde, ist der Server tatsächlich in die Backend-Warteschlange eingetreten und wartet auf die Verarbeitung.
• proxy_send_timeout 600; Die Zeit, die der Backend-Server zum Zurücksenden von Daten benötigt, bedeutet, dass der Backend-Server alle Daten innerhalb der angegebenen Zeit senden muss.
• Proxy_buffer_size 8k; Proxy-Anforderungspuffer. Dieses Cache-Intervall speichert die Header-Informationen des Benutzers, damit Nginx Regeln verarbeiten kann. Stellen Sie es im Allgemeinen einfach so ein, dass die Header-Informationen gespeichert werden.
• proxy_buffers 4 32k; Wie oben, teilt Nginx mit, wie viel Speicherplatz zum Speichern einer einzelnen Seite verwendet werden soll, vorausgesetzt, dass die durchschnittliche Größe einer Webseite weniger als 32 KB beträgt.
• proxy_busy_buffers_size 64k; Wenn das System sehr ausgelastet ist, können Sie einen größeren proxy_buffers beantragen. Die offizielle Empfehlung lautet (proxy_buffers*2).
• proxy_max_temp_file_size 1024m; Wenn proxy_buffers den Antwortinhalt vom Backend-Server nicht aufnehmen kann, wird ein Teil davon in einer temporären Datei auf der Festplatte gespeichert. Dieser Wert wird verwendet, um die maximale Größe temporärer Dateien festzulegen. Der Standardwert ist 1024M. Er hat nichts mit proxy_cache zu tun. Wenn es größer als dieser Wert ist, wird es vom Upstream-Server zurückgesendet. Zum Deaktivieren auf 0 setzen.
• proxy_temp_file_write_size 64k; proxy_temp_path (kann während der Kompilierung verwendet werden) gibt das Verzeichnis an, in das die temporäre Proxy-Cache-Datei geschrieben wird.

Gesundheitscheck

Nginx stellt die Anweisung health_check bereit, um während des Ladens (Upstream) einen wichtigen Mechanismus zur Integritätsprüfung bereitzustellen (Hinweis: Diese Anweisung muss im Standortkontext festgelegt werden).

Unterstützte Parameter sind:

• Intervall=Zeit: Legen Sie das Intervall zwischen zwei Integritätsprüfungen fest. Der Standardwert beträgt 5 Sekunden.
• fails=number: Legt die Anzahl aufeinanderfolgender Prüfungen fest, bevor der Server als fehlerhaft betrachtet wird. Der Standardwert ist 1.
• passes=number: Legt die Anzahl der aufeinanderfolgenden Prüfungen fest, damit ein Server als fehlerfrei gilt. Der Standardwert ist 1.
• uri=uri: definiert die Anforderungs-URI für die Integritätsprüfung, der Standardwert ist "/"
• match=name: Gibt den Namen des passenden Konfigurationsblocks an, der verwendet wird, um zu testen, ob die Antwort die Integritätsprüfung besteht. Der Standardtest-Rückgabestatuscode ist 2xx und 3xx

Eine einfache Einrichtung sieht wie folgt aus und verwendet die Standardwerte:

Standort / {
  Proxy-Passwort http://backend;
  Gesundheitscheck;
}

Für die Anwendung können wir eine dedizierte API zur Integritätsprüfung definieren: /api/health_check, und nur den HTTP-Statuscode 200 zurückgeben. Und stellen Sie den Intervallwert zwischen zwei Prüfungen auf 1 Sekunde ein. Somit sieht die Konfiguration der health_check-Anweisung wie folgt aus:

health_check uri="/api/health_check" Intervall;

Matching-Methode

http {
  Server {
  ...
    Standort / {
      Proxy-Passwort http://backend;
      health_check match=willkommen;
    }
  }

  Spiel willkommen {
    Status 200;
    Header-Inhaltstyp = Text/HTML;
    body ~ "Willkommen bei nginx!";
  }
}

Übereinstimmungsbeispiel

• Status 200;: Status ist gleich 200
• Status ! 500;: Status ist nicht 500
• Status 200 204;: Status ist 200 oder 204
• Status! 301 302;: Status ist nicht 301 oder 302.
• Status 200–399;: Status liegt zwischen 200 und 399.
• Status! 400-599;: Status liegt nicht zwischen 400 und 599.
• Status 301-303 307;: Status ist 301, 302, 303 oder 307.
• Header-Content-Type = text/html;: Der Wert von „Content-Type“ ist text/html.
• Header-Inhaltstyp != Text/HTML;: „Inhaltstyp“ ist nicht Text/HTML.
• Header „Connection ~ close;“: „Connection“ enthält „close“.
• Header-Verbindung !~ schließen;: „Verbindung“ beinhaltet nicht „schließen“.
• Header Host;: Der Anforderungsheader enthält „Host“.
• Header !X-Accel-Redirect;: Der Anforderungsheader enthält nicht „X-Accel-Redirect“.
• body ~ „Willkommen bei nginx!“;: body enthält „Willkommen bei nginx!“.
• body !~ „Willkommen bei nginx!“;: body enthält nicht „Willkommen bei nginx!“.

Eine vollständige Nginx-Instanz

[root@lb01 conf]# cat nginx.conf
Arbeiterprozesse 1;
Ereignisse {
  Arbeiterverbindungen 1024;
}
http {
  mime.types einschließen;
  Standardtyp Anwendung/Oktett-Stream;
  sendfile an;
  KeepAlive-Timeout 65;
  #blog lb von oldboy um 201303
  Upstream blog_real_servers {
  Server 10.0.0.9:80 Gewicht=1 max_fails=1 Fail_Timeout=10s;
  Server 10.0.0.10:80 Gewicht=1 max_fails=2 Fail_Timeout=20s;

  }
  Server {
    hören Sie 80;
    Servername blog.etiantian.org;
    Standort / {
    Proxy-Passwort http://blog_real_servers;
    proxy.conf einschließen;
    }
  }
}
[root@lb01 conf]# cat proxy.conf 
    Proxy_Set_Header Host $host;
    proxy_set_header X-Weitergeleitet-Für $remote_addr;
    Proxy_Verbindungstimeout 90;    
    Proxy_Sendezeitüberschreitung 90;
    Proxy_Lese_Timeout 90;
    Proxy-Puffergröße 4k;
    Proxy-Puffer 4 32k;
    Proxy_Busy_Buffer_Größe 64k; Proxy_Temp_File_Schreibgröße 64k;

Erweiterungen

Für Anfragen dürfen nur die Methoden GET, HEAD und POST verwendet werden

## Erlaube nur diese Anfragemethoden ##
   wenn ($request_method !~ ^(GET|HEAD|POST)$ ) {
     Rückgabe 444;
   }

Tatsächlicher Kampf

Trennen Sie statische und dynamische Daten basierend auf URI und Standort.

Endgültige Umsetzung:

• Alle URLs mit dem Namen /static/ führen zu 10.0.0.9.
• Alle URLs mit dem Namen /dynamic/ gehen zu 10.0.0.10.
• Der Zugriff auf diese statischen Dateien erfolgt unter 10.0.0.9.
• Die URL /upload/ für den gesamten Zugriff 10.0.0.10.

[root@lb01 conf]# cat nginx.conf
Arbeiterprozesse 1;
Ereignisse {
  Arbeiterverbindungen 1024;
}
http {
  mime.types einschließen;
  Standardtyp Anwendung/Oktett-Stream;
  sendfile an;
  KeepAlive-Timeout 65;
  #blog lb von oldboy um 201303

  vorgelagerte statische_Pools {
   Server 10.0.0.9:80;
  }
  Upstream dynamische_Pools {
   Server 10.0.0.10:80;
  }
   Upstream-Uploadpools {
   Server 10.0.0.9:80;
  }

  Server {
    hören Sie 80;
    Servername blog.biglittleant.cn;
    
    Standort / {
    Proxy-Passwort http://static_pools;
    proxy.conf einschließen;
    }

    Standort /static/ { 
    Proxy-Passwort http://static_pools;
    proxy.conf einschließen;
    }
    
    Standort ~* \.(gif|jpg|jpeg)$ {
     Proxy-Passwort http://static_pools;
     proxy.conf einschließen;
    }

    Standort /dynamisch/ { 
    Proxy-Passwort http://dynamische_Pools;
    proxy.conf einschließen;
    }
    Standort /upload/ {
    Proxy-Passwort http://upload_pools;
    proxy.conf einschließen;
    }
  }
}

Implementieren Sie unterschiedliche Adressen für Apple- und Android-Telefone

Server {
    hören Sie 80;
    Servername blog.etiantian.org;
    Standort / {
    wenn ($http_user_agent ~* "android")
     {
      Proxy-Passwort http://android_pools;
     }
    wenn ($http_user_agent ~* "iphone")
     {
      Proxy-Passwort http://iphone_pools;
      }
    Proxy-Passwort http://pc_pools;
    extra/proxy.conf einschließen;
    }
    Zugriff_Abmeldung;
   }

Referenzdokumentation

Offizielle Website von nginx-proxy_pass

Dies ist das Ende dieses Artikels über die Verwendung von nginx zur Interpretation von Lastausgleichsmodulen. Weitere relevante Inhalte zum Lastausgleich von nginx finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!