Änderungen
Archiv:2011/IT/Dokumentation/Webcache (Quelltext anzeigen)
Version vom 1. Februar 2019, 11:48 Uhr
, 11:48, 1. Feb. 2019JanRei verschob die Seite IT/Dokumentation/Webcache nach Archiv:2011/IT/Dokumentation/Webcache
{{Hinweis|Diese Seiten enthält Informationen, die vor allem für Mitarbeiter und Interessierte wichtig sind. }}
Es wird diskutiert, den Hauptserver zukünftig durch verteilte, davorgeschaltete Webcaches (Reverse Proxies) zu entlasten, die im DNS-Round-Robin angesprochen werden.
Vorrangiges Ziel ist, die wahrgenommene Verfügbarkeit der Websysteme zu erhöhen. Dies soll einerseits durch die Entlastung des zentralen Servers durch Cacheing geschehen, andererseits auch durch Vorhalten von dezentralen Kopien, die auch bei Ausfall des Zentralservers weiter ausgeliefert werden (stale-if-error). Dies unterscheidet sich vom "klassischen" Loadbalancer-Ansatz, bei dem Anfragen von einem Loadbalancer auf mehrere Zentralserver verteilt werden.
Ansprechpartner für die Hauptsysteme und DNS stehen in [[AG IT-Infrastruktur]]
Vorteil der Cache-Lösung gegenüber den Static [[Mirrors]] ist, dass diese
eine "Fire&Forget" Lösung sind:
* alle Funktionen verfügbar (Edits werden durchgereicht)
* keine weitere Arbeit (Anpassungen, Updates) benötigt
* erzeugen keine zusätzlichen Peak-Lasten auf dem Originalsystem (z.B. für periodische Updates)
Der [https://wiki.piratenpartei.de/NRW:Arbeitsgruppe/Technik/Varnish Varnish Cache des LV NRW] wird für die [https://wiki.piratenpartei.de/NRW:Arbeitsgruppe/Technik/Varnish/LTW2012 Landtagswahl NRW 2012] entsprechend konfiguriert.
== Domains / Webpräsenzen==
{| {{prettysorttable}}
|-
! Domain !! Original-IP !! Status !! Stand
|-
| www.piratenpartei.de || 94.23.165.40 || nur zentral || 24.09.
|-
| wiki.piratenpartei.de || 94.23.165.40 || nur zentral || 24.09.
|}
== vorhandene Reverse-Proxies ==
Um per DNS-RoundRobin verteilbar zu sein, müssen produktiv genutzte Reverse Proxies auf Port 80 betrieben werden. Port 443 muss per IP-Forwarding auf die Webserver [[#HTTPS-Forwarding|weitergeleitet]] werden.
{| {{prettysorttable}}
|-
! IP !! Domain !! Provider/Standort !! Servertyp || Proxy !! Cache !! max. Traffic !! Logging !! [[#HTTPS-Forwarding|HTTPS]] !! Status !! Stand !! Ansprechpartner
|-
| 195.50.185.61 ||deinschild.de || Boreus, Stralsund || VPS || squid3 || maximal 5GB || UL || Kein Logging || Nein || DOWN (503) || 2009-09-25 || [[Benutzer:tbe|tbe]]
|-
| 81.169.133.97 ||srv02.9it.de || Berlin || Root || squid3 || 5GB || 2TB || Kein Logging || Nein || DOWN || 2009-09-25 || [[Benutzer:rpr|Rüdiger Pretzlaff]]
|-
| 78.46.171.190 || piraten.docx.org || Topnetworks / Hetzner || Linux-VServer|| squid3 || 5GB || 1TB || Kein Logging || Nein || DOWN || 2011-03-31 || [[Benutzer:DocX|DocX]]
|-
| 84.38.66.191 || prauscher.homeip.net || ispOne / Frankfurt || Linux-VServer|| squid3 || 5GB || 500 GB || Kein Logging || Nein || UP || 2009-09-25 || [[Benutzer:Prauscher|Prauscher]]
|-
| 84.19.191.213 || piraten.geekig.de || nbiserv, Erfurt || Hardware || squid2.7 || 10 GB || 6000 GB || kein Logging || Ja || DOWN || 2009-09-26 || [[Benutzer:data|data]]
|-
|}
Beim Typ wird unterschieden zwischen Hardware und (providerseitig) virtuell. Bei letzterem ist zu beachten, dass hohe Last eventuell zu Reaktionen des Providers führen kann, siehe piratenpartei.net bei der Europawahl 2009.
'''Testsysteme, die auf anderen Ports laufen:'''
{| {{prettysorttable}}
|-
! IP !! Domain !! Provider/Standort !! Servertyp || Proxy !! Cache !! max. Traffic !! Logging !! Status !! Stand !! Ansprechpartner
|-
| 87.230.9.130:8080 ||21studios.de:8080 || Hosteurope, Köln || VPS || squid3 || maximal 5GB || 500GB || Kein Logging || DOWN wg. Serverwechsel || 2009-07-13 || [[Benutzer:21studios|21studios]]
|-
|}
== Proxy-Software ==
Wichtig für die Funktion zur Entlastung der Hauptserver sowie sind folgende Funktionen:
* Cacheing der Webseiten, um möglichst viele Abfragen schon vor dem Hauptserver abfangen zu können
* Bei Wegbrechen des Hauptservers soll der Proxy statt der "neuen" Fehlermeldung möglichst die bisherigen Webseiten ausliefern (stale-if-error, siehe http://www.mnot.net/blog/2007/12/12/stale)
** Als Feature für 3.2 geplant. ([http://bugs.squid-cache.org/show_bug.cgi?id=2255 Tracker Bug])
* Ab Squid 3.2 wird es auch Stale-while-revalidate geben. Siehe Links oben.
* großer Cache (optimal: in den die gesamte Site passt) um einen Ausfall des Hauptservers möglichst viele Anfragen noch aus dem Cache bedienen zu können
=== [http://www.squid-cache.org/ Squid] ===
Squid 2.7 beherrscht sowohl stale-while-revalidate als auch stale-if-error.
Für Squid v3 kann folgende Konfiguration genutzt werden:
# squid3 Konfiguration
# fuer forum.piratenpartei.de + wiki.piratenpartei.de + *.piratenpartei.de
# -----------------------------------------------------------------------------
# hier die IP des Caches statt 444.333.222.11 eintragen!
http_port 444.333.222.111:80 accel defaultsite=www.piratenpartei.de vhost
# ggfs. Spool-Location und Size eintragen, hier: 5 GByte = 5000 MByte
cache_dir ufs /var/spool/squid3 5000 16 256
# das war's - Standard konfig folgt...
# -------------------------------
# die echten Webserver und was darauf laeuft
cache_peer 178.19.71.116 parent 80 0 no-query originserver name=wiki_pp
cache_peer_domain wiki_pp wiki.piratenpartei.de
cache_peer 178.19.71.20 parent 80 0 no-query originserver name=forum_pp
cache_peer_domain forum_pp forum.piratenpartei.de
cache_peer 178.19.71.117 parent 80 0 no-query originserver name=www_pp
cache_peer_domain www_pp .piratenpartei.de
# -------------------------------
# ACL - wir erlauben nichts anderes als zu den Piraten-Seiten
acl piraten dstdomain .piratenpartei.de
http_access deny !piraten
# default ACLs
acl Safe_methods method GET HEAD PUT POST
http_access deny !Safe_methods
acl Safe_ports port 80
http_access deny !Safe_ports
# -------------------------------
# Logging - "none" = off
access_log none
# nur fuer Debugging:
# access_log /var/log/squid3/access.log
# -------------------------------
# Done
# [[Benutzer:Votan|Votan]] 14:24, 24. Mai 2012 (CEST)
=== [http://varnish.projects.linpro.no/ Varnish] ===
Auch wenn die Feature-Liste [http://varnish.projects.linpro.no/wiki/VarnishFeatures#Gracefulhandlingofdeadandslowbackends anderes behauptet] beherrscht Varnish stale-if-error - dies muss allerdings über die VCL "programmiert werden (siehe http://varnish.projects.linpro.no/wiki/VCLExampleGrace )
Mögliche Konfiguration (RFC):
backend wiki_pp {
.host = "wiki.piratenpartei.de";
.port = "80";
.probe = {
.timeout = 500m;
.interval = 10s;
.window = 3;
.threshold = 2;
.request =
"GET /Hauptseite HTTP/1.1"
"Host: wiki.piratenpartei.de"
"Connection: close";
}
}
backend forum_pp {
.host = "forum.piratenpartei.de";
.port = "80";
.probe = {
.timeout = 500m;
.interval = 10s;
.window = 3;
.threshold = 2;
.request =
"GET /index.php HTTP/1.1"
"Host: forum.piratenpartei.de"
"Connection: close";
}
}
backend www_pp {
.host = "www.piratenpartei.de";
.port = "80";
.probe = {
.timeout = 500m;
.interval = 10s;
.window = 3;
.threshold = 2;
.request =
"GET /index.php HTTP/1.1"
"Host: www.piratenpartei.de"
"Connection: close";
}
}
sub vcl_recv {
if (req.request != "GET" &&
req.request != "HEAD" &&
req.request != "PUT" &&
req.request != "POST" &&
req.request != "CONNECT") {
error 403 "Forbidden";
}
if (req.http.host == "wiki.piratenpartei.de") {
set req.backend = wiki_pp;
} elsif (req.http.host == "forum.piratenpartei.de") {
set req.backend = forum_pp;
} elsif (req.http.host ~ ".piratenpartei.de$" || req.http.host == "piratenpartei.de") {
set req.backend = www_pp;
} else {
error 403 "Forbidden";
}
if (req.request != "GET" && req.request != "HEAD") {
/* We only deal with GET and HEAD by default */
return (pass);
}
if (req.http.Authorization || req.http.Cookie) {
/* Not cacheable by default */
return (pass);
}
# stale-if-error
if (req.backend.healthy) {
# stale-while-revalidate
set req.grace = 2m;
} else {
set req.grace = 1h;
}
return (lookup);
}
sub vcl_fetch {
if (!obj.cacheable) {
pass;
}
if (obj.http.Set-Cookie) {
pass;
}
set obj.grace = 1h;
set obj.prefetch = -30s;
return (deliver);
}
=== [http://nginx.net Nginx] (+[http://code.google.com/p/ncache/ ncache]) ===
Nginx beherrscht mit dem HttpProxyModul inzwischen detailliert konfigurierbare Cache-Mechanismen, siehe [http://wiki.nginx.org/HttpProxyModule]
Ältere Forenbeiträgen zufolge scheint er empfindlicher hinsichtlich Expiring zu reagieren und so nur eingeschränkt zu cachen. Dies wurde bisher nicht überprüft.
Inzwischen kann eine stale-if-error Funktion konfiguriert werden.
[http://wiki.nginx.org/ReverseProxyCachingExample]
[[Category:IT-Infrastruktur]]
== HTTPS-Forwarding ==
Da HTTPS (HTTP via SSL, port 443) nicht vom HTTP-Proxy verarbeitet werden kann, ohne dass jeder Reverse-Proxy ein gültiges Zertifikat bekommt (was z.Zt. nicht möglich ist), müssen HTTPS-Anfragen auf IP-Ebene direkt an den Piratenpartei-Server weitergeleitet werden.
Im Kernel müssen die nötigen Optionen (netfilter/iptables, MASQUERADE target) aktiviert sein. IPv4-Forwarding muss erlaubt sein (`sysctl net.ipv4.ip_forward` muss 1 sein). Mit den folgenden iptables-Kommandos kann nun das IP-Forwarding für Port 443 an den Piratenpartei-Server eingerichtet werden:
iptables -A PREROUTING -t nat -p tcp --dport 443 -d x.x.x.x -i eth0 -j DNAT --to 94.23.165.40:443
iptables -A FORWARD -t filter -p tcp --dport 443 -d 94.23.165.40 -i eth0 -j ACCEPT
iptables -A POSTROUTING -t nat -p tcp --dport 443 -d 94.23.165.40 -o eth0 -j MASQUERADE
* x.x.x.x muss durch die IP-Adresse, die du für den Piratenpartei-Reverse-Proxy verwendest, ersetzt werden (wichtig wenn der Server mehr als eine IP-Adresse hat, sonst werden alle HTTPS-Verbindungen zu den Piratenpartei-Servern weitergeleitet!).
* eth0 muss evtl. auch ersetzt werden, falls bei dir ein anderes Interface mit dem Internet verbunden ist.
Es wird diskutiert, den Hauptserver zukünftig durch verteilte, davorgeschaltete Webcaches (Reverse Proxies) zu entlasten, die im DNS-Round-Robin angesprochen werden.
Vorrangiges Ziel ist, die wahrgenommene Verfügbarkeit der Websysteme zu erhöhen. Dies soll einerseits durch die Entlastung des zentralen Servers durch Cacheing geschehen, andererseits auch durch Vorhalten von dezentralen Kopien, die auch bei Ausfall des Zentralservers weiter ausgeliefert werden (stale-if-error). Dies unterscheidet sich vom "klassischen" Loadbalancer-Ansatz, bei dem Anfragen von einem Loadbalancer auf mehrere Zentralserver verteilt werden.
Ansprechpartner für die Hauptsysteme und DNS stehen in [[AG IT-Infrastruktur]]
Vorteil der Cache-Lösung gegenüber den Static [[Mirrors]] ist, dass diese
eine "Fire&Forget" Lösung sind:
* alle Funktionen verfügbar (Edits werden durchgereicht)
* keine weitere Arbeit (Anpassungen, Updates) benötigt
* erzeugen keine zusätzlichen Peak-Lasten auf dem Originalsystem (z.B. für periodische Updates)
Der [https://wiki.piratenpartei.de/NRW:Arbeitsgruppe/Technik/Varnish Varnish Cache des LV NRW] wird für die [https://wiki.piratenpartei.de/NRW:Arbeitsgruppe/Technik/Varnish/LTW2012 Landtagswahl NRW 2012] entsprechend konfiguriert.
== Domains / Webpräsenzen==
{| {{prettysorttable}}
|-
! Domain !! Original-IP !! Status !! Stand
|-
| www.piratenpartei.de || 94.23.165.40 || nur zentral || 24.09.
|-
| wiki.piratenpartei.de || 94.23.165.40 || nur zentral || 24.09.
|}
== vorhandene Reverse-Proxies ==
Um per DNS-RoundRobin verteilbar zu sein, müssen produktiv genutzte Reverse Proxies auf Port 80 betrieben werden. Port 443 muss per IP-Forwarding auf die Webserver [[#HTTPS-Forwarding|weitergeleitet]] werden.
{| {{prettysorttable}}
|-
! IP !! Domain !! Provider/Standort !! Servertyp || Proxy !! Cache !! max. Traffic !! Logging !! [[#HTTPS-Forwarding|HTTPS]] !! Status !! Stand !! Ansprechpartner
|-
| 195.50.185.61 ||deinschild.de || Boreus, Stralsund || VPS || squid3 || maximal 5GB || UL || Kein Logging || Nein || DOWN (503) || 2009-09-25 || [[Benutzer:tbe|tbe]]
|-
| 81.169.133.97 ||srv02.9it.de || Berlin || Root || squid3 || 5GB || 2TB || Kein Logging || Nein || DOWN || 2009-09-25 || [[Benutzer:rpr|Rüdiger Pretzlaff]]
|-
| 78.46.171.190 || piraten.docx.org || Topnetworks / Hetzner || Linux-VServer|| squid3 || 5GB || 1TB || Kein Logging || Nein || DOWN || 2011-03-31 || [[Benutzer:DocX|DocX]]
|-
| 84.38.66.191 || prauscher.homeip.net || ispOne / Frankfurt || Linux-VServer|| squid3 || 5GB || 500 GB || Kein Logging || Nein || UP || 2009-09-25 || [[Benutzer:Prauscher|Prauscher]]
|-
| 84.19.191.213 || piraten.geekig.de || nbiserv, Erfurt || Hardware || squid2.7 || 10 GB || 6000 GB || kein Logging || Ja || DOWN || 2009-09-26 || [[Benutzer:data|data]]
|-
|}
Beim Typ wird unterschieden zwischen Hardware und (providerseitig) virtuell. Bei letzterem ist zu beachten, dass hohe Last eventuell zu Reaktionen des Providers führen kann, siehe piratenpartei.net bei der Europawahl 2009.
'''Testsysteme, die auf anderen Ports laufen:'''
{| {{prettysorttable}}
|-
! IP !! Domain !! Provider/Standort !! Servertyp || Proxy !! Cache !! max. Traffic !! Logging !! Status !! Stand !! Ansprechpartner
|-
| 87.230.9.130:8080 ||21studios.de:8080 || Hosteurope, Köln || VPS || squid3 || maximal 5GB || 500GB || Kein Logging || DOWN wg. Serverwechsel || 2009-07-13 || [[Benutzer:21studios|21studios]]
|-
|}
== Proxy-Software ==
Wichtig für die Funktion zur Entlastung der Hauptserver sowie sind folgende Funktionen:
* Cacheing der Webseiten, um möglichst viele Abfragen schon vor dem Hauptserver abfangen zu können
* Bei Wegbrechen des Hauptservers soll der Proxy statt der "neuen" Fehlermeldung möglichst die bisherigen Webseiten ausliefern (stale-if-error, siehe http://www.mnot.net/blog/2007/12/12/stale)
** Als Feature für 3.2 geplant. ([http://bugs.squid-cache.org/show_bug.cgi?id=2255 Tracker Bug])
* Ab Squid 3.2 wird es auch Stale-while-revalidate geben. Siehe Links oben.
* großer Cache (optimal: in den die gesamte Site passt) um einen Ausfall des Hauptservers möglichst viele Anfragen noch aus dem Cache bedienen zu können
=== [http://www.squid-cache.org/ Squid] ===
Squid 2.7 beherrscht sowohl stale-while-revalidate als auch stale-if-error.
Für Squid v3 kann folgende Konfiguration genutzt werden:
# squid3 Konfiguration
# fuer forum.piratenpartei.de + wiki.piratenpartei.de + *.piratenpartei.de
# -----------------------------------------------------------------------------
# hier die IP des Caches statt 444.333.222.11 eintragen!
http_port 444.333.222.111:80 accel defaultsite=www.piratenpartei.de vhost
# ggfs. Spool-Location und Size eintragen, hier: 5 GByte = 5000 MByte
cache_dir ufs /var/spool/squid3 5000 16 256
# das war's - Standard konfig folgt...
# -------------------------------
# die echten Webserver und was darauf laeuft
cache_peer 178.19.71.116 parent 80 0 no-query originserver name=wiki_pp
cache_peer_domain wiki_pp wiki.piratenpartei.de
cache_peer 178.19.71.20 parent 80 0 no-query originserver name=forum_pp
cache_peer_domain forum_pp forum.piratenpartei.de
cache_peer 178.19.71.117 parent 80 0 no-query originserver name=www_pp
cache_peer_domain www_pp .piratenpartei.de
# -------------------------------
# ACL - wir erlauben nichts anderes als zu den Piraten-Seiten
acl piraten dstdomain .piratenpartei.de
http_access deny !piraten
# default ACLs
acl Safe_methods method GET HEAD PUT POST
http_access deny !Safe_methods
acl Safe_ports port 80
http_access deny !Safe_ports
# -------------------------------
# Logging - "none" = off
access_log none
# nur fuer Debugging:
# access_log /var/log/squid3/access.log
# -------------------------------
# Done
# [[Benutzer:Votan|Votan]] 14:24, 24. Mai 2012 (CEST)
=== [http://varnish.projects.linpro.no/ Varnish] ===
Auch wenn die Feature-Liste [http://varnish.projects.linpro.no/wiki/VarnishFeatures#Gracefulhandlingofdeadandslowbackends anderes behauptet] beherrscht Varnish stale-if-error - dies muss allerdings über die VCL "programmiert werden (siehe http://varnish.projects.linpro.no/wiki/VCLExampleGrace )
Mögliche Konfiguration (RFC):
backend wiki_pp {
.host = "wiki.piratenpartei.de";
.port = "80";
.probe = {
.timeout = 500m;
.interval = 10s;
.window = 3;
.threshold = 2;
.request =
"GET /Hauptseite HTTP/1.1"
"Host: wiki.piratenpartei.de"
"Connection: close";
}
}
backend forum_pp {
.host = "forum.piratenpartei.de";
.port = "80";
.probe = {
.timeout = 500m;
.interval = 10s;
.window = 3;
.threshold = 2;
.request =
"GET /index.php HTTP/1.1"
"Host: forum.piratenpartei.de"
"Connection: close";
}
}
backend www_pp {
.host = "www.piratenpartei.de";
.port = "80";
.probe = {
.timeout = 500m;
.interval = 10s;
.window = 3;
.threshold = 2;
.request =
"GET /index.php HTTP/1.1"
"Host: www.piratenpartei.de"
"Connection: close";
}
}
sub vcl_recv {
if (req.request != "GET" &&
req.request != "HEAD" &&
req.request != "PUT" &&
req.request != "POST" &&
req.request != "CONNECT") {
error 403 "Forbidden";
}
if (req.http.host == "wiki.piratenpartei.de") {
set req.backend = wiki_pp;
} elsif (req.http.host == "forum.piratenpartei.de") {
set req.backend = forum_pp;
} elsif (req.http.host ~ ".piratenpartei.de$" || req.http.host == "piratenpartei.de") {
set req.backend = www_pp;
} else {
error 403 "Forbidden";
}
if (req.request != "GET" && req.request != "HEAD") {
/* We only deal with GET and HEAD by default */
return (pass);
}
if (req.http.Authorization || req.http.Cookie) {
/* Not cacheable by default */
return (pass);
}
# stale-if-error
if (req.backend.healthy) {
# stale-while-revalidate
set req.grace = 2m;
} else {
set req.grace = 1h;
}
return (lookup);
}
sub vcl_fetch {
if (!obj.cacheable) {
pass;
}
if (obj.http.Set-Cookie) {
pass;
}
set obj.grace = 1h;
set obj.prefetch = -30s;
return (deliver);
}
=== [http://nginx.net Nginx] (+[http://code.google.com/p/ncache/ ncache]) ===
Nginx beherrscht mit dem HttpProxyModul inzwischen detailliert konfigurierbare Cache-Mechanismen, siehe [http://wiki.nginx.org/HttpProxyModule]
Ältere Forenbeiträgen zufolge scheint er empfindlicher hinsichtlich Expiring zu reagieren und so nur eingeschränkt zu cachen. Dies wurde bisher nicht überprüft.
Inzwischen kann eine stale-if-error Funktion konfiguriert werden.
[http://wiki.nginx.org/ReverseProxyCachingExample]
[[Category:IT-Infrastruktur]]
== HTTPS-Forwarding ==
Da HTTPS (HTTP via SSL, port 443) nicht vom HTTP-Proxy verarbeitet werden kann, ohne dass jeder Reverse-Proxy ein gültiges Zertifikat bekommt (was z.Zt. nicht möglich ist), müssen HTTPS-Anfragen auf IP-Ebene direkt an den Piratenpartei-Server weitergeleitet werden.
Im Kernel müssen die nötigen Optionen (netfilter/iptables, MASQUERADE target) aktiviert sein. IPv4-Forwarding muss erlaubt sein (`sysctl net.ipv4.ip_forward` muss 1 sein). Mit den folgenden iptables-Kommandos kann nun das IP-Forwarding für Port 443 an den Piratenpartei-Server eingerichtet werden:
iptables -A PREROUTING -t nat -p tcp --dport 443 -d x.x.x.x -i eth0 -j DNAT --to 94.23.165.40:443
iptables -A FORWARD -t filter -p tcp --dport 443 -d 94.23.165.40 -i eth0 -j ACCEPT
iptables -A POSTROUTING -t nat -p tcp --dport 443 -d 94.23.165.40 -o eth0 -j MASQUERADE
* x.x.x.x muss durch die IP-Adresse, die du für den Piratenpartei-Reverse-Proxy verwendest, ersetzt werden (wichtig wenn der Server mehr als eine IP-Adresse hat, sonst werden alle HTTPS-Verbindungen zu den Piratenpartei-Servern weitergeleitet!).
* eth0 muss evtl. auch ersetzt werden, falls bei dir ein anderes Interface mit dem Internet verbunden ist.