Drücke „Enter”, um zum Inhalt zu springen.

Cloud Low Level Erklärung

admin 0

Zuletzt aktualisiert am 7. April 2021

Gehen wir mal ein paar Jahre zurück …. ( oder Jahrzehnte…?)

Da gab es sehr häufig Serverlandschaften wie diese, für jeden Dienst oder Aufgaben einen eigenen Server, jeder dieser Server hatte am besten noch einen eigenen Backup Server der nur darauf wartete
das sein Master ausfiel um im Notfall tagesaktuell weiter arbeiten zu können.
Während viele Backup Server vor sich hin schlummerten waren andere Systeme völlig ausgelastet.
Die gesamt Auslastung in unserem Beispiel lag also häufig weit unter 50% während es bei einigen
Systemen schon zu Verzögerungen in der Bedienbarkeit kommt.  

Einen großen Schritt hinsichtlich der Auslastung haben wir in den letzten Jahren durch Virtualisierung
erreicht. Meisten umgesetzt durch den Marktführer VMware.
Bleiben wir bei unserer kleinen Server Landschaft. Da wir ja 35 % angenommen haben,
kommen wir ja mit der Hälfte der Rechner Kapazität aus.
Statt das Betriebssystem fest an einen Rechner zu binden, installieren wir eine Virtualisierung
Software von VMware auf unserer Server genannt ESXi. Damit ich hier nicht zu weit aushole
schaut doch einfach mal hier rein https://de.wikipedia.org/wiki/VMware_vSphere
ESXi ermöglicht uns nun mehrere Betriebssysteme auf einer Hardware Komponente abzubilden.
Es wird also Hardware virtuell dargestellt. Ich kann nun die verfügbare Hardware auf meine installierten
Betriebssysteme verteilen. Durch zusätzliche Software dem VCenter kann ich mehrere Server oder sogar Standorte zu „Custer“ zusammenfassen. Man kann die installierten Betriebssystem bei Ausfall
drag and drop umziehen oder bei Auslastung die Betriebssystem umziehen auf Server die weniger
ausgelastet sind. Ich weiß VCenter kann noch viel viel mehr aber es soll ja einfach bleiben.

wir können die Hardware noch besser „ausreizen“…. in dem wir die vorhandene Hardware „überbuchen“
Ich versuchen das mal an einem Beispiel in meinem kleinen Testsystem zu beschreiben.
Ich haben dort einen kleinen Intel Nuk mit einer  I3 CPU mit 4 Kernen und 8 GB RAM
Dort habe ich 3 Ubuntu Server 20.04 installiert. Ich habe jedem Betriebssystem 2 Kerne und 4 GB RAM
zugewiesen obwohl ich die gar nicht zur Verfügung habe.
Da anzunehmen ist das alle 3 Systeme nur selten auf 100´% laufen macht das Sinn. Bei einer
Vollauslastung würden sich wie dargestellt die System Ressourcen  und Rechenzyklen
gleichmäßig teilen. Hätte man den Systemen  2 und 3 je 1 Core und 2 GB Ram zugeteilt
und Rechner 1 so gelassen, hätte er im Auslastungsfall die doppelte Menge an Rechenzyklen
zur Verfügung bekommen. Auf diese Art  und weise kann man selbst in großen Rechenzentren gut und sicher an eine Hardware Auslastung von 85% bis 90% kommen.

Unser Thema ist ja Cloudifizierung und Kubernetes, können wir damit die Resourcen noch weiter auslasten. Eher nicht und unser kleines Beispiel eines kleinen Unternehmen mit ein paar Servern
und viele verschieden Betriebssystem in die Cloud umzuziehen macht nicht all zu viel Sinn.
Ich denke sowas ist nach wie vor in der Virtualisierung bestens aufgehoben.

Versuchen wir es mit einem anderen Beispiel. In den letzten Jahren sind
Internet Anwendung -> Applikation -> App’s > Microservices
also Dienste die wir uns über einen Browser darstellen lassen nahezu explodiert.
Häufig werden hier Daten in Datenbanken gesammelt , die dann auf über eine Internetseite
oder App’s aufbereitet zur Verfügung gestellt werden.
Stellen wir uns all so eine Datenbank von einem Deutschland weitem Wetterdienst vor.
Wir haben eine Datenbank die von unzähligen Wetterstationen mit Unmengen Sensoren
mit Daten gefüttert wird. Auf der anderen Seite möchte jedes Bundesland seinen
Bürgern eine eigene administrierbare Wetterplattform zur Verfügung stellen.
Was würden wir jetzt in unserer VM Plattform machen.
16 mal das gleiche Betriebssysteme aufsetzen, mit 16 Webservern und allem was dazu gehört.

Und hier starten wir nun mit unseren Cloudsystem bestehend aus dem Basis System Linux,
einem Container System in unserem Fall Docker und einem Verwaltungtool Kubernetes.
Statt alles 16 mal neu zu installieren, packen wir unsere 16 Wetterapps in Container
und benutzen alles andere was schon gegeben ist vom Betriebssystem mit.

Wir verwalten unsere Applikation über eine
Schnittstelle „API“ Application Programmig Interface ( Wikipedia)
Das kann das Comand Line Tool Kubectl, Scripte ober auch Webfrontends wie z.B. das
Kubernetes Dashboard sein. ( siehe auch Technik Blog )

Ähnlich unserem V Center von VMware können wir mit einer übergeordneten API „Cluster API“
mehrere Cluster zusammenfassend administrieren.

 

Wie bekommen wir unsere Anwendung in den Container ( Pod )

 

 

 

Schreibe einen Kommentar