Moin!

Ich gebe meinen Senf mal an zentraler Stelle dazu, weil ich die diversen Stellen hier im Thread nicht sofort wiederfinde, an denen es besser passen würde. Außerdem kann ich so viel besser zusammenhängend ranten. :)

Ok, "Server" ist das Thema. Aktuelle Situation: Es gibt noch zwei Server mit 2GB und zwei Kernen, und einen mit 4GB und acht Kernen. Auslastung im Betrieb insgesamt sehr gering, Traffic entsprechend, ein internes Gigabit-Netz erlaubt schnellen Datentransfer z.B. für Backups, die wechselseitig gespeichert werden. Festplattenkapazität ist 36GB (Odin, RAID-1), 72GB (Ve, RAID-1) und WHOAH (Heimdall, RAID-irgendwas). Betriebssystem auf allen Kisten Gentoo "uralt". Die Sun-Server haben einen internen Service-Prozessor, der den Hauptserver steuert, so dass man auch Remote booten und ins Server-BIOS kommen kann. Heimdall hat IIRC irgendwas adäquates, da bin ich mir allerdings nicht sicher.

Erfahrungswerte:

Wenn nicht gerade Netzteile durchbrennen, sind die Server hardwareseitig recht pflegeleicht. Irgendein Absturz aufgrund ungeklärter Überlast hat es manchman notwendig gemacht, einen Server zu rebooten. Der Reboot erforderte dabei immer, dass man ihn nicht nur via Serviceprozessor auslöst, sondern danach den Bootvorgang auch manuell via Konsole überwacht und ggf. auf dem Server remote noch eine "Taste drückt", damit irgendeine Abfrage passend beantwortet war und der Server endlich hochgefahren ist.

Problem an der Sache: Wenn der Server nicht 100% sauber und ohne Interaktion hochfährt, und man sich immer wieder dran erinnern muss, was zu tun ist, damit das mit manueller Einflussnahme geschieht, ist das sehr nervig und würde eigentlich erfordern, dass man sich mal intensiver mit dem Bootprozess auseinandersetzt. Das Problem dabei wiederum ist, dass sämtliche Server im Livebetrieb sind und ständiges Rebooten den Betrieb unangenehm stören würde.

KONSEQUENZ 1: Mindestens ein Server muss verfügbar sein, um administrativ Szenarien durchzuspielen, ohne dabei den Live-Betrieb zu stören.

Die zweite, wichtige und regelmäßige Aufgabe ist das Einspielen von Programmupdates der Distribution. In diesem Punkt empfinde ich Gentoo als eine Zumutung. Es ist einem halbwegs erfahrenen Gentoo-Rootuser zwar möglich, das Update anzustoßen und die Kompilierung abzuwarten (hoffentlich dauert das nicht zu lange), in der Folge werden aber häufig auch Updates für Konfigurationsdateien notwendig, die in einem recht aufwendigen Merge-Prozess mit den eigenen Anpassungen zusammengeführt werden müssen.

Dies bedeutet: Derjenige, der das Update macht, muss von allen Konfigurationsdateien, die in diesem Schritt als updatenotwendig angezeigt werden, inhaltlich Ahnung haben. Das bedeutet: Er muss von sämtlichen Serverkomponenten, die irgendjemand mal via Gentoo-Emerge installiert hat, Ahnung haben - oder er macht wahrscheinlich was kaputt. Das wiederum bedeutet, dass der Job eines Gentoo-Serveradmins nur etwas für Leute ist, die den ganzen Tag nichts anderes machen, als Gentoo-Server zu administrieren, und die die Installation von Software für jemanden, der genausoviel Ahnung hat, exzellent dokumentieren können, damit derjenige den Job ebenfalls machen und/oder übernehmen kann.

Dies gilt insbesondere für die mit Gentoo vorhandene Möglichkeit, nicht nur Konfigurationen individuell anzupassen, sondern auch eigene Patches und Pakete in den Kompilierungsprozess mit einfließen zu lassen. Gewiss, Gentoo hat bei SELFHTML ein paar Bugs erst lösbar gemacht, die durch fehlerhafte Software von Upstream nicht schnell gelöst wurden - sowas ist aber tatsächlich nur was für Hardcore-Entwickler und -Admins und engt den Kreis der potentiellen Administratoren sehr ein.

KONSEQUENZ 2: Gentoo würde ich als OS nicht wieder nehmen wollen.

Ein weiteres Problem, dass beim Serverbetrieb immer wieder auftritt, ist die erforderliche Update-Frequenz für eigentlich alles, was man mal so installiert hat. Im Prinzip muss man regelmäßig updaten, damit das Delta der Veränderungen, die jedes Update mit sich bringt, nicht zu groß wird. Das gilt für Betriebssystemkomponenten natürlich auch, insbesondere allerdings für die eingesetzte Standardsoftware der Webapplikationen. SELFHTML hat an ein paar Stellen Standardsoftware im Einsatz, beispielsweise "Trac" als Ticketsystem und Dokumentations-Wiki. Hier schlägt ein Update der Software unter Umständen mit großem Migrationsaufwand zu: Wenn das Update inkompatible Änderungen zum bestehenden System erfordert, insbesondere wenn wichtige Plugins noch nicht verfügbar sind, auf die man nicht verzichten kann, oder die für die neue Version gar nicht angeboten werden, weil vielleicht deren Funktionalität nicht mehr realisierbar oder überflüssig ist.

KONSEQUENZ 3: Standardsoftware gerne - aber nur der gefühlte Marktführer verspricht, dass im Problemfall soviel Hilfe-Ressourcen online auffindbar sind, dass man durch Recherche auftretende Probleme beheben kann. Vorsicht bei x-beliebigen Plugins! Vorsicht bei irgendwelcher gehypten Softwareversion "0.x", die sich noch intensiv in der Entwicklung befindet. Installation bitte auch unabhängig vom OS (wie Gentoo Webapplikationen installiert, gefällt mir gar nicht).

Auf der anderen Seite benutzt SELFHTML diverse Software-Eigenentwicklungen. Hier hat man zur Abwechslung mal keine Update-Probleme, denn es gibt meist keine Updates vom Entwickler mehr. Umso schlimmer, wenn dann Probleme auftreten, die man beheben muss. Es ist keine Freude, wenn man in jahrealtem PHP-Code mit exotischen Template-Engines irgendeinen Bug sucht und nicht fixen kann, weil keinerlei Dokumentation existiert, keinerlei Tests, und der Entwickler längst nicht mehr erreichbar ist. Genauso blöd, wenn offenbar zugehörige Dateien, die verlinkt sind, in der Versionsverwaltung nicht eingecheckt wurden. Dieses Chaos ist nur noch dadurch zu steigern, dass die Entwickler nicht nur exotisches PHP benutzen, sondern quer durch den Garten im Prinzip jede erdenkliche Programmiersprache, so dass der ideale Kandidat für den Betrieb der Softwarelandschaft im Prinzip perfektes Wissen in mindestens zehn Sprachen haben muss, damit er überhaupt eine Chance hat, den Wildwuchs im Zaum zu halten - von Problemen nach Updates der zugrundeliegenden Engines mal ganz abgesehen.

KONSEQUENZ 4: "Würde das jemand machen - kannst auch deine bevorzugte Sprache benutzen" - no way! Standards definieren und einhalten. Man kann über PHP ja sagen, was man will, aber es ist definitiv die Skriptsprache mit der größten Community verglichen mit anderen Skriptsprachen - es ist zu vermuten, dass sich dafür recht leicht Experten finden lassen. Wildwuchs erschwert die Wartung vor dem Lebensende der Software.

- Sven Rautenberg