Update-Strategien, HA

[Andreas Korthaus]

Hallo!

Ja, und genau das ist das Problem: es reicht gerade mal so eben nicht.

Hm, mir reicht das ;-)

Ist aber auch egal: ich verkauf' was verlangt wird, wenn es nur besser(!) ist, da kenn' ich nix ;-)

*g*

Ja, Mail und Patch geht hin und wieder gleichzeitig raus, aber der Distributor dürfte seinen Patch vorher noch testen wollen, falls es nicht gerade eine Kleinigkeit war (und es sind meist nur Kleinigkeiten, die den Ärger bereiten). Es kann daher sein, das der Distributionspatch später rauskommt, als der vom Maintainer obwohl beides das Selbe ist. Das passiert aber alles normalerweise innerhalb eines Tages.

Aber viele Distributionen arbeiten ja nicht mit denselben Versionen wie die Entwickler der Software, sondern arbeiten mit backports. Vor allem die "Enterprise Versionen" von Red Hat und Suse, aber auch Debian. Gentoo arbeitet (IMHO zum Glück) meist mit den weitgehend originalen Versionen. Und gerade in besonders alten Versionen kann ich mir gut vorstellen dass ein Patch nicht immer 100% "übertragbar" ist.

Gut, ich kann Patches in einem anderen System testen, aber ich habe keine 100% identischen Systeme, die nur für Tests zur Verfügung stehen. Bei bestimmten Anwendungen kann ich mir es z.B. nicht leisten, dass der Apache nach einem Neustart nicht mehr korrekt startet.

Dann hast Du einen Fehler im System. Was passiert denn bei Stromausfall?

Also bei jedem größeren Update führe ich hinterer einen reboot durch, alleine um zu testen dass es "im Fall der Fälle" keine Probleme gibt. Danke Apache/mod_php ("fire & forget") und DB-Transaktionen sollte es nach einen Reboot keine Probleme geben. Aus diesem Grund skaliert das ganze auch recht gut, das heißt ich könnte "Pizzaboxen" dazu packen, die über einen Loadbalancer angesprochen werden, ich kann jederzeit eine Box rausnehmen, updaten, hinzufügen... ohne Probleme. Allerdings bin ich noch nicht so weit ;-) Das einzige Problem sind Schreibzugriffe auf die Datenbank. Dies lässt sich nicht so einfach verteilen/skalieren. Lese-Zugriffe sind nicht so wild, das kann recht einfach per Master->Slave Replikation passieren, aber hier kann es bei MySQL und PostgreSQL AFAIK nur einen Master geben. Wenn allerdings jede DB auch Schreibzugriffe bearbeiten können soll - abgesehen davon dass das bei den genannten RDBMS nicht geht - entsteht ein erheblicher Overhead durch die notwendige Synchronisation der DBs. Daher fällt mir an dieser Stelle nur ein, den Master-Server z.B. per Heartbeat zu überwachen, und ggfs. dessn IP und Aufgaben zu übernehmen. Aber das bringt nur was für Verfügbarkeit, Skalierung ist hier nicht so einfach möglich. Außerdem bin ich nicht 100%ig sicher ob hier beim Umschalten - trotz Transaktionen - keine Daten verloren gehen können, oder Inkonsistenzen entstehen können. Denn dies würde IMHO voraussetzen, dass eine Transaktion erst zu Ende ist, wenn diese auch auf der Slave-Maschine erfolgreich durchgeführt wurde. Sonst kann es passiert, das die Transaktion eigentlich als abgeschlossen angesehen/gemeldet wird, auf der Slave-Maschine allerdings noch nicht, und wenn diese dann die Arbeit übernimmt, haben wir ein Problem. Oder mache ich hier einen Denkfehler?

Ja, ich schweife wohl auch etwas ab ;-)

Uns selbst wenige Sekunden downtime will ich nach Möglichkeit vermeiden. Gut, wenn da jetzt ein übler Remote-Exploit im Apache oder einem von mir eingesetzten Modul bekannt würde, der sich auch in meiner Konfiguration ausnutzen ließe, dann würde ich reagieren. Aber sonst erst Abends, denke ich.

Wofür möchtest Du denn sonst einen Patch _sofort_ einspielen? Doch nur bei sicherheitsrelevanten Fehlern und nicht jedesmal, wenn ein neues Gimmik in den Sourcetree wandert, oder?

Ja. Aber ich würde es nicht unbeding "hier und jetzt" bei jedem Fehler machen, der sich wenn überhaupt nur lokal ausnutzen ließe. Sowas dann abends. Aber mal folgendes Beispiel: Du hast einen Kernel der gut läuft, der Distributor bringt hin und wieder kleine Updates raus, die Du nicht einspielst weil Du es nicht brauchst weil es Dich nicht betrifft, oder weil es nicht so wichtig ist... Das heißt, die Distribution aktualiesiert das Kernel-Paket mehrmals, ohne dass Du diese Updates mitmachst. Dann taucht eine Lücke auf, die auch sofort gepatched wird, aber eben nur in den aktuellen Versionen. Also kannst Du entweder den Rechner abschalten oder Deine Sourcen manuell patchen oder auf einer möglichst identischen Maschine testen, und dann hoffen dass auf der Live-Maschine alles gut geht. Was würdest Du machen? Gut, Du redest wie es aussieht immer von HA-Szenarien, das macht solche Dinge in der Tat deutlich erträglicher. Aber auch teurer und komplexer. Aber da muss man ja gegenrechnen ob es auch teurer ist als downtime weil der Kernel dann doch nicht so gebootet hat wie er sollte ... ;-)
Wenn ich alleine überlege wieviel zur Zeit noch am 2.6er Kernel verändert wird, wundere ich mich dass der schon so viel eingesetzt wird. Zum einen findet dort noch die Entwicklung statt, und alleine das changelog von 2.6.8.1 -> 2.6.9 hat 1,2 MB! Und AFAIK lassen Distributoren gerne mal neue Features mit in ältere Kernel einfließen.

Aber bei mir ist dieses auch nicht nötig. Vermutlich würde eine Uptime von gut 50% ausreichen, wichtig ist eben dass es genau dann "up" ist, wenn es genutzt wird. Und das ist eigentlich nur über den Tag verteilt.

Das wäre dann über den Tag verteilt 100% und nachts 0%?

Das wäre ideal, ja ;-)

Nein, da kannst Du nicht den Durchschnitt nehmen, so funktioniert das leider nicht ;-)

Naja, wenn ich die Verfügbarkeit über das Jahr rechne, schon :) Aber ich weiß was Du meinst.

Ich kann Dir sagen, das Du selbst mit einer Uptime von 99,5% noch graue Haare kriegen würdest, das ist zu wenig, das würdest Du nämlich schon mit Win98 schaffen.

In jedem Fall ist das Leben etwas einfacher, wenn man eine Maschine fast täglich mehrere Stunden warten kann. Das geht halt bei den 99,9..% Systemen nicht. Wenn man nicht gerade einen Cluster da stehen hat.

Zumindest wenn man lokalen Benutzern vertrauen kann.

Du müßtest ihnen so weit vertrauen, das sie auch keine Fehler machen! Das kannst Du noch nicht einmal bei Dir selber, wieso dann bei anderen?

Hm. Es ist aber schon was anderes ob ich irgendwelche wildfremden Leute auf den Rechner lasse, wie z.B. im Shared Hosting mit SSH-Zugang, oder ob das 2 Admins der eigenen Firma sind. Gut, auch einer von denen kann Schaden anrichten, wenn er sauer ist... aber die Gefahr dass jemand "aus Versehen" einen lokalen Exploit ausnutzt halte ich doch eher für theoretisch, oder? Vor allem wenn die beiden Personen bereits Root-Rechte haben ist man eh ausgeliefert.

Was passiert denn, wenn der Fehler nicht veröffentlicht wird? Du weißt nichts davon, das es überhaupt einen Fehler gibt. Aber gilt das auch für _alle_ anderen? Wirklich alle? Oder ist es möglich, das dank der Nichtveröfentlichung ein Schwarzhut ganz still und heimlich den Exploit ausnutzen kann? Wie er den überhaupt gefunden hat, wo doch gar nichts veröffentlicht wurde? Nun, diese Frage zu beantworten überlasse ich einmal den werten Leser ;-)

Klar! Es gibt ja auch Firmen wo Du dafür bezahlen kannst dass Du Lücken die diese Firma findet vorher bekommst, die dann erst deutlich später veröffentlicht wird. Und wer weiß was die Admins der Firmen die hierfür bezahlen in der Freizeit treiben...
Einen gewissen Schutz versprechen ja Patches für proaktive Sicherheit, wie pax/grsecurity etc. Verwendest Du sowas? Oder sowas wie RSBAC und SELinux? Ich finde den Aufwand bei letzteren allerdings sehr hoch, außerdem würde ich keinem kompromittierten System mehr vertrauen, egal wie sicher ich mir bin dass weiter nichts passiert ist.

Dann hilft hier nur ein HA-System. Aber dies funktioniert ja in der Regel nicht mit gemieteten Root-Servern, mir wäre jedenfalls kein Anbieter bekannt, der so Dinge wie "Übernahme der IP" erlauben würde. Das heißt, man braucht "was eigenes".

Ja: drei gemietete Rootserver. Aber ich glaube nicht, das ein anständiger Host keine Möglicheit hat, den Switch nach Anweisung auf zwei Boxen umzuschalten.

Im Switch? Das heißt die Server behalten die öffentlichen IPs, es wird nur intern zu einer anderen IP weitergeleitet? Keine Ahnung. Ich kann mir nicht vorstellen dass dies ein Rootserver-Hoster ermöglicht. Vor allem nicht automatisiert. Die einfachste Lösung die ich kenne ist durch Übernahme der IP, also im Prinzip arp-spoofing, aber genau deswegen ist das von den Hostern nicht erlaubt. Soweit ich weiß - wenn Du sowas auf einem Server im Schlund-Rechenzentrum probierst, wird Dir automatisch Deine Leitung gekappt, eben weil man es auch mißbrauchen kann. Und die sagen selber, Rootserver sind nicht das richtige wenn Du eine HA-Lösung willst. Mir ist kein Hoster bekannt der das erlauben würde. Daher sehe ich nur den Weg über Housing von eigenen Servern, wo man erheblich mehr Möglichkeiten hat, wie etwa bei den SELF-Servern.

Schwieriger wird es wenn es um den DB-Server geht. Man könnte höchstens einen nebenherlaufen lassen, der im Fall der Fälle die IP und Anfragen übernimmt, wo man dann aber für Replikation und einen konsistenten Datenbestand sorgen muss. Ich bin mir nicht sicher ob sich dies mit MySQL oder PostgreSQL überhaupt "wasserdicht" realisieren lässt.

Da aber ein DB-Server eh physikalisch vom Netz getrennt sein muß, kannst Du auch die Firewall zur Replikation mißbrauchen.

Die Trennung verstehe ich, aber dass dies gleichzeitig den Einsatz einer Firewall erfordert ist mir nicht klar. Ich würde den DB-Server in einem internen Netz laufen lassen, physikalisch getrennt von dem ans Internet angeschlossenen LAN. Allerdings macht dies die Remote-Wartung nicht gerade einfacher. Wie machst Du das? Den DB-Server über einen 2. Netzanschluss ans Internet anbieten wäre wohl dämlich, oder Wartung komplett über eine Konsole? Oder von anderen, verbundenen Servern im DB-LAN aus?

Aber zur Firewall - würdest Du hier eine extra-Pizzabox einsetzen? Dies birgt in meinen Augen ein nicht zu vernachlässigendes zusätzliches Ausfallrisiko. Also spezialisierte Hardware? Das ist aber wieder nicht ganz billig. Wenn Du aber den DB-Server von Remote aus administrieren willst - was soll diese Firewall dann bringen? Wogegen willst Du Dich hiermit schützen? Gegen Fehler in der Anwendung? Das stell ich mir aber sehr kompliziert vor.

Viele Grüße
Andreas

PS: ich war mal so frei das topic etwas anzupassen :)