CloudFlare-Ausfall

Ein sehr interessantes Video vom Cloudflare-Ausfall am Wochenende. Golem meint:

Rund 785.000 Websites waren am Wochenende für rund eine Stunde offline.

Die Frage, die mir inzwischen dreimal gestellt wurde, lautete: „Darf ein solcher Fehler passieren?“ – darauf kann ich allerdings keine eindeutige Antwort geben. Bei Cloudflare arbeiten Menschen und Menschen machen Fehler – man sollte natürlich, gerade bei solch wichtigen Änderungen, dringend mit mindestens acht Augen über die Routerregeln schauen, bevor man sie aktiviert. Blöd gelaufen ist eigentlich nur, dass die Regel sich über die ganzen Router verteilt hat – und somit einige Websites vom Netz genommen hat.

Wie man mit einem Fehler umgeht – das ist doch die entscheidende Frage. Wie also ging Cloudflare mit dem Problem um? Offen und transparent:

The cause of the outage was a system-wide failure of our edge routers. CloudFlare currently runs 23 data centers worldwide. These data centers are connected to the rest of the Internet using routers. These routers announce the path that, from any point on the Internet, packets should use to reach our network. When a router goes down, the routes to the network that sits behind the router are withdrawn from the rest of the Internet.

cloudflare_outage.png.scaled1000

Und was wollen die Jungs und Mädels bei Cloudflare nun besser machen? Folgende Aussage gibt’s auf dem verlinkten Blogeintrag:

We let our customer down this morning, but we will learn from the incident and put more controls in place to eliminate problems like this in the future.

In diesem Sinne: Hut ab, Cloudflare!

Wie überwache ich meine Server?

Desöfteren wurde ich gefragt, wie ich meine und die Maschinen meiner Kunden überwache. Oft fielen hier die Worte Nagios und Cacti / Munin. Sinnvollerweise benötigt man hier allerdings einen eigenen (v)Server in einem Rechenzentrum. Bei mittlerweile rund 20 Kunden, die ich überwachen muss, ist das gar keine so leichte Aufgabe. Es muss ein externer Dienst her.

Weiterlesen…Wie überwache ich meine Server?

How-To: Munin 2.0 auf Debian Squeeze

Munin ist eine Software mit Status- und Prozess-Visualisierung und, meiner Meinung nach, eine bequemere Alternative zu Cacti.

Letztlich ist es wohl eine Glaubensfrage, ob man Cacti oder Munin nutzt, und darüber lässt sich bekanntlich nicht streiten. Leider ist die Installation von Munin 2.0 hier nicht wirklich zielführend beschrieben, weshalb es mich auch ein wenig Zeit gekostet hat, CGI zum Laufen zu bekommen.

Am Ende fragte ich mich, was mir nun solche Kopfschmerzen bereitet hatte und möchte meinen Lesern das Leben ein wenig einfacher gestalten.

Ich übernehme keine Haftung für etwaig entstandene Schäden. Bitte erst denken, dann Befehle abtippen.

Debian Backport

Am Anfang steht das Backport-Repository vom Debian-Projekt. Um dies in unser System einzufügen, öffnen wir die /etc/apt/sources.list und fügen am Schluss folgende Zeile ein:

deb squeeze-backports main

Ein beherztes apt-get update und apt-get install munin -t squeeze-backports später, ist Munin auch schon installiert. Standardmäßig ist in der munin.conf unter /etc/munin/ nur der localhost eingetragen, was für die ersten Tests aber durchaus ausreicht.

Apache-Konfiguration

Am Anfang steht ein kurzes apt-get install libapache2-mod-fcgid und ein a2enmod fcgid.

        DocumentRoot /var/cache/munin/www
        ServerName munin.example.com
        Alias /static /etc/munin/static
        # Rewrites
        RewriteEngine On
        # HTML
        RewriteCond %{REQUEST_URI} !^/static
        RewriteCond %{REQUEST_URI} .html$ [or]
        RewriteCond %{REQUEST_URI} =/
        RewriteRule ^/(.*)           /usr/lib/munin/cgi/munin-cgi-html/$1 [L]
        # Images
        # - remove path to munin-cgi-graph, if present
        RewriteRule ^/munin-cgi/munin-cgi-graph/(.*) /$1
        RewriteCond %{REQUEST_URI}                 !^/static
        RewriteCond %{REQUEST_URI}                 .png$
        RewriteRule ^/(.*)  /usr/lib/munin/cgi/munin-cgi-graph/$1 [L]
        # Ensure we can run (fast)cgi scripts
        ScriptAlias /munin-cgi/munin-cgi-graph /usr/lib/munin/cgi/munin-cgi-graph

        Options +ExecCGI
                SetHandler fcgid-script
                SetHandler cgi-script
        Allow from all
        ScriptAlias /munin-cgi/munin-cgi-html /usr/lib/munin/cgi/munin-cgi-html
                Options +ExecCGI
                        SetHandler fcgid-script
                        SetHandler cgi-script
                Allow from all

                Options +ExecCGI
                        SetHandler fcgid-script
                        SetHandler cgi-script
                Allow from all

                SetHandler None
                Allow from all

                Order allow,deny
                #Allow from localhost 127.0.0.0/8 ::1
                Allow from all
                Options None

                ExpiresActive On
                ExpiresDefault M310

Fehlt noch ein a2ensite munin und ein /etc/init.d/apache reload und schon sollte Munin, vorallem der Zoom, funktionieren.

Fragen und/oder Anmerkungen bitte in die Kommentare.
Fragen via E-Mail werden nicht beantwortet!

Serverumzug

Diese Website läuft nun auf einer neuen Maschine. Vorher hatte ich ein Setup aus getrenntem Mail- und Webserver, allerdings war dies den Verwaltungsaufwand absolut nicht wert.

Ich kündigte also die beiden Maschinen und suchte eine neue, stärkere Maschine – und wurde bei rackplace fündig, die mir ein individuelles Angebot mit folgender Konfiguration zukommen ließen:

  • 1 HE Supermicro
  • Intel Xeon E5506
  • 8GB DDR3 ECC
  • 2×1 TB SATA HDD
  • 1 IPv4-Adresse
  • 1 /64 IPv6-Subnetz

Preis bleibt natürlich geheim – bei Interesse hilft euch rackplace sicher weiter.