Konzepte, die entstehen – Konzepte, die vergehen
Nach längerer Abstinenz möchte ich heute ein Thema aufgreifen, welches mich schon einige Monate beschäftigt.
Nach dem Virtualisierungs- Hype reden nun alle von Microsegmentierung und Container a la Docker. Dabei bin ich alles andere als ein Docker Spezialist. Ich habe mir einfach einiges zum Thema Container angelesen und angesehen. Worum es mir in diesem Beitrag geht ist aber ein Nachdenken darüber, welche Konzepte wir im Rechenzentrum / DataCenter [RZ] schon so hinter uns haben und was dabei, vom Grundkonzept her, wieder auftaucht.
Container sind für mich so ein Phänomen. Doch am besten fange ich einfach mal ganz weit vorne an. Also nach IT Massstäben Steinzeit.
(Dieser Artikel erhebt dabei weder Anspruch auf Vollständigkeit, absolut korrekte Darstellung, sondern meine private Ansicht)
Wie das mit dem Großrechner so begann
Der gute alte Mainframe, bis heute in einigen Branchen immer noch die tragende Säule der IT im RZ. Sicher ist ein Mainframe von heute nicht mit dem von vor 20 oder mehr Jahren zu vergleichen aber vom Konzept funktioniert er immer noch so. Sehr effizient aufeinander abgestimmte Komponenten. Dauerbetrieb mit Wartung im Betrieb möglich. Hohe Ein- und Ausgabe Kapazität bei der Bearbeitung von Massendaten.
©pcmag.com – Sehr alter Mainframe
Heute hat der Mainframe sicher gelernt, ähnlich wie die x86 Server, virtuelle Maschinen auszuführen (z.B. Z-Linux auf IBM). Im Prinzip ist die Grundarchitektur aber gleich geblieben.
Nichts desto trotz wurden die Programme als einzelne „Jobs“ auf dem System ausgeführt, jedes in seiner Umgebung, geschedult und von den anderen, wenn gewünscht, abgeschottet.
Die Dezentralisierung des RZ beginnt
Mit dem Aufkommen immer leistungsfähiger Endgeräte (PC’s) kam nun die Idee auf, Aufgaben und Verarbeitung von Daten zu dezentralisieren und auf die PCs auszulagern. Windows™ sei Dank wurde die Bedienung nun auch für „angelernte“ Laien 😉 immer einfacher. Problem dabei – viele Dokumente und Daten wurden jetzt im Unternehmen verteilt und waren unter Umständen nur per „Turnschuh“ Transport erreichbar.
Zentrale Datenhalden und Druckdienste
Nun begann die Zeit der zentralen Datenhalden und Druckdienste. Bereitsteller wie NOVELL™ Banyan Vines™ (Wer kennt das noch?) sowie der Anfangs verschmähte Spät-Kommer Windows Advanced Server (später NT und noch später einfach Windows Server 2000 und folgende).
Banyan Vines – Novell Netware – Windows NT Advanced Server
Hier konnte man, wenigstens im Anfang, nur File und Druckdienste, sowie eine zentrale Userverwaltung beziehen. Später kamen dann Versuche dazu, z.B. eine Datenbank auch auf dem Server zu platzieren (Btrieve by Novell usw.). Diese „Dienste“ liefen auf den Servern mit und zwar meist „nicht dediziert“, also mit den File und Druckdiensten zusammen.
Bitte bedenken! Die zentrale Datenverarbeitung machte zu dieser Zeit immer noch der „Host“ im Hintergrund. Nur griff man jetzt nicht mehr per Grün- oder Amber-Terminal auf diesen zu, sondern per Terminalemulation. Davon lebten zu dieser Zeit ein paar Firmen recht gut (Hummingbird etc.).
Für spezielle Aufgaben gab es auch schon die verschiedenen UNIX Anbieter. Graphik war z.B. die Domäne von Silicon Graphics™ und SUN Microsystems™.
Spezialisierte Server Systeme
Nach dieser Phase der „einfachen zentralen Dienste“ starben die ersten Protagonisten dahin und Microsoft startete durch.
Gerade Microsoft schaffte auch eine Art Microsegmentierung ;-), denn bis heute ist es ratsam jede Serverfunktion auf eine oder mehrere separate Windows Server Maschinen(physikalisch oder heute VM) zu verteilen. Durch dieses Konzept entstanden plötzlich eine große Anzahl von Server Systemen im RZ. Statt einem großen Host und vielleicht einer Handvoll Peripherie Systemen explodierte die Anzahl der Server im RZ geradezu. Viele klassische IT Abteilungen hatten damit schwer zu kämpfen, zumal zentrale Management Tools noch eher rar waren.
Ausserdem entstand nun eine Art „Religionskrieg“ zwischen den Verfechtern der verschiedenen Systeme.
- Auf der einen Seite die altvertrauten Host- Menschen mit ihren „Big Iron“ Systemen. Dicke, zuverlässige aber nicht im neuen Sinn flexible Systeme die zudem sehr teuer waren.
- Auf der anderen Seite diverse UNIX Derivate (SUN Solaris, HP UX, IBM AIX usw.) die jeder den Alleinherrscher- Status beanspruchten (und schlußendlich daran scheiterten!). Alles irgendwie Unix, aber inkompatibel und jeder mit Eigenarten.
- Und zuletzt Microsoft mit Windows Server, die im Hintergrund so langsam einen Service nach dem anderen übernahmen (sicher auch auf Grund der immer leistungsfähiger werdenden Intel Systeme an sich).
Aber jeder Service und Dienst wollte hier gern ein eigenes System haben. Angefangen von AD, DHCP, DNS die man noch irgenwie zusammen betreiben kann über Exchange, MS SQL, SharePoint etc. Eben alles was so auf Windows Server lief und läuft. - … alle anderen Systeme mit weniger Verbreitung lasse ich hier mal weg. Dieses ist dabei meine private Einschätzung – ohne Wertung im Detail.
Die Virtualisierung beginnt
Durch die immer günstiger werdende Rechenleistung auf x86 Seite schafft es die Lösungsgemeinschaft Intel – Microsoft tatsächlich, daß viele Server Systeme eine nicht unerhebliche Zeit des Tages vor sich hin „ideln“, also mehr mit sich als mit der eigentlichen Aufgabe beschäftigt sind.
Das macht sich vor allem die Firma vmware™ zu eigen und baut einen Hypervisor der es schafft, vielen virtuellen Maschinen vorzugaukeln, sie würden auf dedizierter Handware laufen, obwohl sie zusammen mit anderen auf einem oder wenigen physikalischen Servern leben. Funktionen wie das Verschieben solcher VMs im laufenden Betrieb (vMotion) und vieles mehr räumen jetzt im RZ wieder etwas auf. Die Komplexität wird meiner Meinung nach aber nicht weniger, denn immer neue Services verlangen immer mehr neue VMs die z.T. mit 90% gleichem Basis Stack unterwegs sind.
Man muß bedenken, hier laufen immer noch separate Systeme mit hoher Redundanz, nur eben nicht auf einzelnen physikalischen Servern, sondern gepackt als VM auf mehrere Hypervisoren. Diese bringen selbstverständlich viele viele Vorteile mit sich. Die optimale Ausnutzung der Serverhardware tritt dabei immer mehr in den Hintergrund.
Gerade die immer weiter vordringenden Linux Systeme mit dem klassischen Software Stack (z.B. LAMP := Linux, Apache Webserver, MySQL DB und PHP) bringen uns auf neue „ALTE“ Ideen!
Der Container erscheint
So wie vmware im Virtualisierungs- Umfeld sicher als ein Pionier und Vorreiter gelten darf, kann man die Firma Docker™ für den Bereich Container sehen.
Dabei sind Container, wenigstens unter Unix/Linux eher ein alter Hut.Cgroups und Namespaces sind bekannte Linux Funktionen die hier aufgegriffen wurden und „abgerundet“ als Container Technologie der neue Hype sind.
VMs versus Container
Was haben wir denn nun hier vor uns? Einfach abstrahiert haben wir den einzelnen Applikationen nur die für sie spezifischen System DDLs bzw. Libraries und Umgebungsanteile mitgegeben und führen diese auf EINEM Operating System aus. Also nicht 5 oder 10 vollständige Linux Systeme, sondern nur ein Linux System auf dessen Kernel und Ressource mehrere Applikationen mit Ihrem Applikationsstack laufen.
Gesteuert wird dieses durch die Container Engine. Riesen Vorteil. Die einzelnen Container sind kleine Pakete (im Gegensatz zu einer vollständigen VM) und durch verschiedene Techniken auch noch portabel zwischen mehreren Linux Hosts (bei entsprechender Vorbereitung sogar zwischen verschiedenen Distributionen!).
Haupt Punkt dabei: Das ganze ist aktuell hauptsächlich für Linux Applikationen vorhanden, aber auch Microsoft schraubt an diesem Konzept. Hyper-V 2016 soll es z.B. ermöglichen Docker Container auszuführen.
(Linked Clones verbinden nur Storageseitig mehrere gleichartige Systeme mit einer „Systemplatte“, das ist eine Verbesserung, aber keine vollständige wie Container)
Zusammenfassung
Was macht nun das „Hatten wir schon“ aus? Nach meinem Empfinden haben unsere IT Urgroßväter ihre Programme für den Mainframe (Host) schon damals, ähnlich wie wir heute Container, geplant und betrieben. Alles was Ein- und Ausgabe, Zugriffe auf Netz etc. betraf, lieferte der Host. Die Programme liefen in Ihrer Umgebung als einzelne Jobs die man schedulen und priorisieren konnte und die von Host zu Host, bzw. Hostbereich zu Hostbereich, portabel waren. Genau das Konzept findet man bei Containern wieder.
Für Container spricht die höhere Packungsdichte als bei VMs und das schnelle Starten der Container, da das OS ja schon läuft. Das Thema Sicherheit bedarf dagegen sicher einer separaten Betrachtung. Falls ich mal Zeit finde dazu vielleicht irgendwann mehr.
Somit sind wir vom RZ und dem Host über die Dezentralisierung wieder zurück ins RZ und wenn wir einen „Container-Cluster“ als Host betrachten, auch wieder bei unseren „Jobs“ die nun Applikationen in Containern darstellen. Hochflexibel, schnell zu deployen und in Massen zu betreiben. Alte Host-Hasen werden sich da doch gleich zuhause fühlen (wenigstens vom Konzept her).
Fazit
Diese, zugegeben, mit wenig technischer Tiefe aber dafür mehr Humor dargestellte Evolution vom Host zum Container, hilft vielleicht doch das eine oder andere Neue leichter zu verstehen und durchaus über neue Konzepte im Licht von Bekanntem nachzudenken.
Neben Docker gibt es übrigens auch noch weitere Anbieter solcher Lösungen, wie Kubernetes (Google), LXD (Canonical) oder Rocket/rkt (CoreOS). Auch vmware hat einen“Docker-Basis VM“ im Angebot (Project Photon).
dervirtuellewirt 