Piratenwiki Mirror

Archiv:2011/IT/Dokumentation/Webcache

< Archiv:2011/IT/Dokumentation
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 Varnish Cache des LV NRW wird für die Landtagswahl NRW 2012 entsprechend konfiguriert.


Domains / Webpräsenzen

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 weitergeleitet werden.

IP Domain Provider/Standort Servertyp Proxy Cache max. Traffic Logging 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 tbe
81.169.133.97 srv02.9it.de Berlin Root squid3 5GB 2TB Kein Logging Nein DOWN 2009-09-25 Rüdiger Pretzlaff
78.46.171.190 piraten.docx.org Topnetworks / Hetzner Linux-VServer squid3 5GB 1TB Kein Logging Nein DOWN 2011-03-31 DocX
84.38.66.191 prauscher.homeip.net ispOne / Frankfurt Linux-VServer squid3 5GB 500 GB Kein Logging Nein UP 2009-09-25 Prauscher
84.19.191.213 piraten.geekig.de nbiserv, Erfurt Hardware squid2.7 10 GB 6000 GB kein Logging Ja DOWN 2009-09-26 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:

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 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)
  • 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


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
# Votan 14:24, 24. Mai 2012 (CEST)

Varnish

Auch wenn die Feature-Liste 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);
}

Nginx (+ncache)

Nginx beherrscht mit dem HttpProxyModul inzwischen detailliert konfigurierbare Cache-Mechanismen, siehe [1]

Ä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. [2]

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.
Abgerufen von „https://wikimirror.piraten.tools/wiki/index.php?title=Archiv:2011/IT/Dokumentation/Webcache&oldid=55527342“