Re: B&E: Portsupdate auf einem Produktionssystem

Wer unter hohem Blutdruck leidet und seine Pillen noch
nicht genommen hat, bitte _nicht_ weiterlesen. :-)

Uwe Laverenz <uwe(at)laverenz.de> wrote:
> Oliver Boris Fischer wrote:
> > Daher würde ich gerne wissen, wie ihr damit umgeht. Oder wie stellt ihr
> > sicher, daß bestimmte Stände der Portscollection konsistent sind? Nichts
> > wäre unangenehmer, als von einen Port abhängig zu sein, der als "broken"
> > makiert ist.... ;(
>
> Das hängt u.a. davon ab, wie man die Sache angeht: auf einem
> Produktionsserver sollte man nicht ständig updaten, sondern nur Bugs und
> Security-Probleme lösen.

Ein durchaus nachvollziehbarer Standpunkt. Aus genau
diesem Grund habe ich noch einige Rechner unter meinen
Fittichen, die noch ein 4-stable haben, nach dem Motto
»never change a running system«. Allerdings ist der
Zeitpunkt absehbar, an dem es keine offiziellen Secu-
rity-Patches mehr für 4.x geben wird.

(Ebenso gibt es natürlich Kunden, die darauf bestehen,
immer das »neuste und beste« haben zu wollen, und das
kriegen sie dann halt auch. Es gibt auch andere Gründe,
warum manchmal Produktionsmaschinen aktualisiert werden
müssen, ob man will oder nicht, z.B. um die Versions-
stände in einer größeren Farm abzugleichen, damit es
besser handhabbar ist.)

Beispiel: Änderungen im SMP-Code und »Fixes« in einem be-
stimmten GigE-Treiber führen in Kombination dazu, daß die
Web-Anwendung eines Kunden im Benchmark um 30% sinkt, was
dann unter der betreffenden SLA-Grenze liegt. Folge:
Kunde unglücklich. Folge davon: Provider unglücklich
(weil er 'ne Vertragsstrafe zahlen muß, wenn er das Problem
nicht in 4 Stunden wieder in den Griff kriegt, natürlich
ohne Downtime, da 99,95% Verfügbarkeit im Monat garantiert
werden, und die erlaubten 20 Minuten Downtime wurden be-
reits in der Woche zuvor aufgebraucht, weil die Firmware
vom Load-Balancer aktualisiert werden mußte, was entgegen
der Aussage des Herstellers nicht auf beiden Nodes nach-
einander möglich war ... Ein Unglück kommt halt selten
allein, und Kunden haben für sowas kein Verständnis, wenn
ihr Geschäftsbetrieb davon abhängt. Genau darum gibt es
ja SLAs.)

Sowas kann bei einem Update immer passieren, und selbst
mit Testsystemen ist das nicht immer im voraus festzustel-
len. Heutige Serverumgebungen sind einfach zu komplex,
daher gilt das alte Motto »never change a running system«
umso mehr.

> Genau das ist mit dem Ports-System aber eben
> nur mit viel regelmäßigem Aufwand zu machen (wenn überhaupt).

Da gebe ich Dir recht. Bei sowas halte ich portupgrade
für vollkommen tabu und ungeeignet, weil es viel zu viele
Dinge automatisch tut. Bevor man Pieps sagen kann und
überhaupt bemerkt, was da gerade passiert, funktioniert
plötzlich irgendein abstruses Package nicht mehr, von
dem man gar nicht wußte, daß es überhaupt installiert
war und wofür es gut ist. Wenn das auf meinem Rechner
daheim passiert, oder auf einem Root-Server, der eine
handvoll private Webseiten hostet, ist das natürlich
nicht tragisch und läßt sich beheben, aber das sind auch
keine »richtigen« Produktionsserver.

Die Ports-Collection ist _eigentlich_ nur für die anfäng-
liche Installation sehr gut geeignet. Danach sollte man
sie niemals updaten, sondern immer nur gezielt manuell
patchen, wenn Security-Probleme und zugehörige Patches
bekannt werden. Nur so kann man auf einem Produktions-
system halbwegs garantieren, daß nichts in die Brüche
geht.

Alternativ kann man natürlich eine Testmaschine hernehmen
(oder ein Jail) und dort beliebig updaten und intensiv
testen. Die Möglichkeit hat man aber nicht immer (die
Testumgebung muß möglichst exakt mit der Produktions-
umgebung übereinstimmen, was z.B. auch Netzwerkkomponenten
wie Filer/NAS betrifft), und es kostet enorm viel Zeit,
insbesondere auch das Testen, wenn man es richtig machen
will, wozu etwa auch Performance-Tests gehören. Siehe
obiges Beispiel.

Auf Produktionssystemen, die nicht ganz so »strikt« gehand-
habt werden müssen (weil z.B. hinreichend Redundanz vorhan-
den ist und ein Fallback kein Problem darstellt, oder weil
keine nennenswerten finanziellen Summen, Arbeitsplätze und
Firmenpleiten davon abhängen), sieht die Sache natürlich
wieder ganz anders aus.

Gruß
   Olli

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"C++ is to C as Lung Cancer is to Lung."
        -- Thomas Funke
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message