Update-Strategien, HA

[Andreas Korthaus]

Moin!

("Das war jetzt etwas viel", sagte das Forum *grmpf* ;-)

OK, ich machs ganz kurz ;-)

Das einzige Problem sind Schreibzugriffe auf die Datenbank. Dies lässt sich nicht so einfach verteilen/skalieren.

Ja, das ist etwas schwieriger. Ich würde das händisch machen: DB-Betrieb analysieren und so aufteilen, das Du mehr als eine DB betreiben kannst.

Das ist aber schwierig wenn die Anwendung genau für eine DB programmiert wurde. Dann müsste man da schon ordentliche Eingriffe vornehmen, außerdem ist dies auch nur sehr begrenzt möglich. Im Normalfall verursachen relativ wenige Queries über relativ wenige, dafür große Tabellen einen verhältnismäßig großen Teil der Last. Diese Tabellen kann man aufgrund von Joins oder Views oft nicht teilen.

Das ist dann so grob, das die Firewall das leicht übernehmen kann.

Das Aufteilen? Wie soll dass den gehen? Inzwischen kann ja sogar MySQL ein binäres Kommunikations-protokoll verwenden, was willst Du da per Firewall noch machen? Du siehst nur -  "Application Server X schickt TCP-Paket an DB-Server Y". Was genau hier passiert kannst Du ja nicht so ohne weiteres parsen/interpretieren!

Wenn allerdings jede DB auch Schreibzugriffe [...] entsteht ein erheblicher Overhead durch die notwendige Synchronisation der DBs.

Nicht unbedingt, wie ich weiter unten beschrieben hatte. Ist dann aber nur eine Art Raid-1.

Was ich meine ist das was Oracle & Co. mit den Clustern machen. Das hört sich zwar alles prima an, nur verschlingt die Synchronisation hierbei sehr, sehr viel Zeit und Performance, gegenüber einer einfachen Master->Slave Replikation. Dafür hast Du dann bei einem Ausfall aber auch konsistente Daten im Cluster - ist ja auch nicht unbedingt schlecht ;-)

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.

Selbstverständlich wird das Ärger geben, es ist nur die Frage, ob Du das reparieren kannst und wie kompliziert das wird.

Wenn Daten im Nirvana sind kann man es schlecht reparieren. Irgendjemand muss dann halt das was er kurz vorm Ausfall gemacht hat, nocheinmal machen. Gut, man könnte noch das Log von der ausgefallenen Maschine haben, wenn nicht gerade diese Datei oder die Festplatte kaputt ist. Aber auch wenn man an die Daten kommt - wie schnell ist es denn dann wiederhergestellt? Ich denke, der Anwender wird den Fehler sehen, sauer sein, und die Eingabe erneut machen. Selber einspielen macht IMHO nur Sinn, wenn man die Anwendung sperrt bis alles wieder konsistent ist. Aber sowas geht ja schonmal gar nicht automatisch, und gerade das (lange downtime) wollen wir ja vermeiden.

Denn dies würde IMHO voraussetzen, dass eine Transaktion erst zu Ende ist,[...] und wenn diese dann die Arbeit übernimmt, haben wir ein Problem. Oder mache ich hier einen Denkfehler?

Du solltest Dir die Frage stellen, was denn im Schadensfall passieren könnte und vor allem: was das kostet.
Was kostet ein, in Worten: 1 verlorener Datensatz?

Wie beziffert man das? Wenn ein Datensatz verloren geht, dann ist ein Kunde sauer, und darf irgendeine Aktion erneut ausführen.

Ja, das mußt Du natürlich verfolgen und Deine Kernel-Quellen stets aktuell halten und auch immer daraus einen passenden Kernel bauen. ChangeLog und README der Patches ja nicht vergessen sich sorgfältig zu Gemüte zu führen!

Meinst Du Updates durch den Distributor?

Aber das ist normalerweise das tägliche Brot eines Admins: mit viiiel zuwenig Geld Wunder vollbringen zu müssen ,-)

*g*

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.

Nein, eigentlich nicht, das täuscht.

AFAIK ist der aber auf den meisten Root-Servern die heute gemietet werden vorinstalliert. Gut, das sind natürlich nicht die Server mit den unternehmenskritischen Anwendungen, aber auch Suse Enterprise Linux verwendet einen 2.6er Kernel, die kommende Red Hat Server-Version wird 2.6 verwenden, die aktuelle verwendet schon seit sehr langer Zeit von 2.5/6 portierte Features wie NPTL, O(1) Scheduler..., so ziemlich alle AMD64-Server benötigen einen 2.6er Kernel (und davon gibt es inzwischen nicht wenige!)...

Auf Produktionssystemen mit wertvollen,sprich teuren Daten

also sowas wie dieses Forum? ;-)

läuft mit Sicherheit noch ein 2.4er oder gar noch ein 2.2er und noch wahrscheinlicher erst gar kein Linux.

hier läuft aber 2.6 - q.e.d ;-)

In jedem Fall ist das Leben etwas einfacher, wenn man eine Maschine fast täglich mehrere Stunden warten kann.

Weiter oben hast Du noch gesagt, das Du das nicht kannst, weil die Maschine zu 100% benötigt wird?

Nein. 100% geht natürlich nicht. Ich sags mal so, zwischen 8 und 20 Uhr sollte die Maschine eine "möglichst hohe" Verfügbarkeit haben, dazwischen kann man im Prinzip machen was man will. Das heißt, wenn ich um 20 Uhr irgendwas problematisches mache, habe ich noch 12 Stunden Zeit das in Ordnung zu bringen ;-)
Bei richtigen™ HA-Systemen hast Du diese Möglichkeit nicht, eben nur mit Hilfe eines Clusters etc.

In einem Flugzeug sind auch alle Teile doppelt und dreifach (und noch mehr teilweise), obwohl zwischendurch immer genügend Zeit für eine Wartung ist.

Aber bei einer Web-Anwendung sterben auch keine 300 Leute wenn was kaputt geht ;-)

Vor allem wenn die beiden Personen bereits Root-Rechte haben ist man eh ausgeliefert.
Aber eines ist dabei natürlich nicht schlecht: man hat zwei Leute, denen man die Schuld geben kann! >;->

*g*

Und wer weiß was die Admins der Firmen die hierfür bezahlen in der Freizeit treiben...

Man muß schon wissen, was man tut, wenn man Sicherheit outsourced.

Das meine ich nicht. Ich meine sowas:

Waisman will den Fehler bereits im Mai im Rahmen des so genannten

Vulnerability Sharing Club von Immunity veröffentlicht haben. Für eine

Mitgliedsgebühr ab 50.000 US-Dollar können sich dort Firmen vorab über

Schwachstellen informieren lassen, die Immunity gefunden hat. Für die

Mitgliedschaft muss sich der Kunde allerdings verpflichten, die

Informationen nicht weiter zu geben (Non Disclosure Agreement).

http://www.heise.de/newsticker/meldung/53729

Einen gewissen Schutz versprechen ja Patches für proaktive Sicherheit, wie pax/grsecurity etc. Verwendest Du sowas?

Nein, der Effekt ist zu klein. Aber ich verfolge selbstverständlich deren Bemühungen und habe schon hin und wieder etwas übernommen, ja.

Verwendest Du nur selber gepatchte Kernel? Ich verwende eigentlich immer die originalen vanilla-sources mit grsec-patch. 2.4 natürlich :)

Oder sowas wie RSBAC und SELinux? Ich finde den Aufwand bei letzteren allerdings sehr hoch,

Ich finde den Ansatz nicht ganz gelungen, da ich ACLs z.B. als ziemlich miesen Workaround ansehe.

Warum? Das Standard-Berechtigungskonzept ist nunmal in machen Fällen etwas zu einfach, oder? Du kannst halt sehr genau festlegen was ein User oder Programm darf, und was nicht. Wofür ist das ein Workaround? Wie macht man es denn ordentlich?

Das ist etwas, was der Kudne verlnagt hatte und nnur saumäßig implementiert wurde.

Meinst Du jetzt konkret die beiden genannten Patches? Hm, gerade SELinux wird doch wirklich von vielen eingesetzt und von vielen entwickelt, unter anderem von der NSA (oh, gefährlich) ;-)

Erweiterte Rechte alleine reichen nicht, man muß schon alles einzeln verschlüsseln.

Was hat das damit zu tun? Was denn verschlüsseln? Daten? Dateisysteme?

Keine Ahnung. Ich kann mir nicht vorstellen dass dies ein Rootserver-Hoster ermöglicht. Vor allem nicht automatisiert.

Zwei Rootserver müssen nicht notwendigerweise auch zwei verschiedene Kisten sein.

Hm? Was denn sonst? Wenn es keine 2 Kisten sind, kannst Du nicht so gut an der einen arbeiten, wenn die andere läuft, auch hast Du keine erhöhte Ausfallsicherheit bzgl. Hardware. Und Du kannst nicht besonders schnell zwischen 2 Systemen umschalten.

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.

Warum bieten eigentlich die Hoster von sich aus nichts an?

Weil deren Kundschaft zum größten Teil aus Leuten besteht, die nur sehr wenig Ahnung von Linux haben, aber gerne etwas mehr Traffic hätten, gerne Wohnzimmer-Provider spielen, und evtl. einen netten Game-Server installieren möchten ;-)
Und dann passiert eben regelmäßig sowas https://forum.selfhtml.org/?t=95658&m=580503, oder https://forum.selfhtml.org/?t=95641&m=580399, oder...

Soweit ich weiß - wenn Du sowas auf einem Server im Schlund-Rechenzentrum probierst,

Äh .. Schlund? Junger Mann, ich dachte, wir reden von Hostern? >;->

Ist das keiner? Ich rede von einigermaßen großen Rechenzentren mit hervorragender Anbindung, und bei "Root-Servern" meine ich mietbare Pizzaboxen. Aber wie gesagt, gerade die größeren sind hier recht wenig flexibel. Was wäre denn ein guter "Hoster" in Deiner Interpretation des Begriffes?

Die Trennung verstehe ich, aber dass dies gleichzeitig den Einsatz einer Firewall erfordert ist mir nicht klar.

Wie willst Du das denn sonst machen?

Ich verwende für den/die "Applikations-Server" halt 2 Netzwerkkarten, eine für Internet und eine für DB-Verbindung. Dieses 2. LAN ist ein geswitchtes Netz im privaten Adressraum, an das der DB-Server angeschlossen wird. Das ist für mich bereits eine physikalische Trennung.

Wie machst Du das? Den DB-Server über einen 2. Netzanschluss ans Internet anbieten wäre wohl dämlich,

Warum nicht? Wenn da eine Firewall zwischen ist?

Aber auch hier - was bringts? Sagen wir es ist nur der sshd an diese Netzwerkkarte gebunden, akzeptiert nur das public-key Verfahren, ssh2, kein root... wie sich das gehört ;-)
Was bringt Dir jetzt noch eine Firewall dazwischen für einen zusätzlichen Vorteil? Der einzige Vorteil den ich vielleicht sehe, wäre, wenn es irgendjemand schafft, evtl. über einen verwundbaren Applikations-Server Zugriff auf den DB-Server zu erhalten, könnte eine Firewall verhindern, dass er eine remote-shell aufmachen kann. Man könnte auch verhindern dass er irgendwas aus dem Netz nachläd - zumindest auf direktem Weg. Aber wenn er eh schon so weit ist, dann ist doch sowieso alles zu spät. Also was bringt es? Ich stecke meine Energie eigentlich da rein, genau diese Situation zu verhindern, und ich wüßte nicht wie eine Firewall dabei helfen könnte. Eine Firewall ist schön und gut um verschiedene Netze sauber voneinander zu trennen, aber um einzelne, direkt aus dem Internet erreichbare Server zu schützen - wo ist da der Sinn?

Ist zwar nach Möglichkeit zu vermeiden, aber das geht ja leider selten.

ja.

Aber zur Firewall - würdest Du hier eine extra-Pizzabox einsetzen?
[...]
Also spezialisierte Hardware? Das ist aber wieder nicht ganz billig.

Doch, das ist genauso teuer wie eine Pizzabox, eher noch billiger.

Hättest Du da mal einen Link für mich? ;-)

Es gibt aber noch mehr Angriffspunkte, wogegen eine Firewall schützen kann und auch muß.

Was zum Beispiel? Wenn auf dem Server nur 1 Dienst läuft, z.B. Apache/mod_php, evtl. plus sshd, der sauber konfiguriert ist. Was gibt es dann noch für eine Firewall zu tun - außer den 2 Kleinigkeiten die ich oben schon genannt habe (remote-shell verhindern, nachladen verhindern), die evtl. einiges erschweren, aber nicht wirklich viel verhindern?

Viele Grüße
Andreas

PS: naja, ich habs wirklich versucht mit dem "kurz fassen" :)