Wie funktioniert ein Server-Rz bzw. die Cloud?

[kfranzk]

Sorry Freunde,
ich bin bestenfalls halbgebildet im PC und IT-Bereich und verstehe das Arbeiten in der Cloud nicht.
Deshalb diese Fragen eines Laien:

• Basieren die Server von z.B. AWS oder Azure u.a. üblicherweise auf X86/64 ?
• Läuft darauf native Linux?
• Und darauf ein VM und jeder Kunde erhält eine Umgebung wie sein eigenes Windows- oder Linux-/LAN?
• Oder muss er seine Anwendungen in Linux portieren (compilieren, linken..)?
• Was ist eine Instanz, ein virtuelles X86/64 System?
• Was machen Kunden mit anderen Unix-Derivaten wie AIX (auf risc-Basis)?
• Ist das, was z.B. HPE als Server bietet auf Intel-Basis, oder gibt es da noch eine eigene Architektur?
• Was machen Kunden mit z/OS oder i/OS Host-Rechnern, bekommen die eine Power-Umgebung??

=> Alles evtl. etwas viel auf einmal, aber vielleicht kann mir das ja jemand kurz und einfach erklären!
Gruß Konrad

 

[wahli]

Die darunter liegende Software/Hardware spielt eigentlich keine Rolle. Es wird ein Linux-OS sein. Größere Cloud-Anbietern werden das OS individuell angepasst/erweitert haben.

Ansonsten ist der Begriff "Cloud" ein relativ allgemeiner Begriff wie z. B. "Internet"...Da passt der Link von #2. Dazu kannst du dann spezifische Fragen stellen.

 

[mibbio]

@r0b0t ja wieder so eine Nicht-Antwort: 'Such doch selber nach einer Antwort...' ==> Also Forum einstellen!

Unter dem Link stehen sehr viele Schlagworte und Begriffe, aber ich finde nichts zur eingesetzten Software.

Das liegt halt daran, dass es keine allgemeine Antwort auf deine Frage gibt. Cloud ist im Grunde auch nur ein "schönerer" Bergriff für Rechenzentrum, was wiederum erstmal nur eine Ansammlung von Servern (+ Klimatisierung) ist, die bei irgendeinem Anbieter steht.

Was die jeweilige Software angeht, hängt halt stark vom Verwendungszweck des Rechenzentrums bzw. der einzelnen Server ab. Wenn man das beantworten wollen würde, müsste man hier einen Roman schreiben, um alle Möglichkeiten und Konstellationen abzudecken. Da ist man mit einer Suche bei Google oder Wikipedia deutlich schneller.

 

[h3@d1355_h0r53]

Im Prinzip kann man aus deinen Fragen mehrere Masterarbeiten ableiten, richtig oder falsch gibt es da auch nicht und jeder kann es so machen wie er will bzw. ist das teilweise auch Betriebsgeheimnis, bei anderen öffentliche Vorlage für Cloudinfrastruktur generell.

Prozessoren können alles sein. AWS hat z.B. teilweise durch Partnerschaft mit Intel Xeon Prozessoren im Einsatz. AMD Epyc hat generell stark aufgeholt. Und für manche Einsatzzwecke entwickeln die Anbieter komplett eigene Hardware, wie z.B. aktuell Youtube um Videos zu verarbeiten im Hintergrund. Da ist immer die Frage für was die Server benutzt werden. Bei Facebook oder Social Networks im Speziellen gibt es z.B. viel mehr Server (und daran anhängend CDNs), die dir die Daten einfach ausgeben, da mehr gelesen wird als geschrieben. Die Schreibserver bilden einen kleinen Anteil am Serverpark und geben die Inhalte erst nach und nach an die Leseserver weiter. Früher hat man das gerade bei Facebook bemerkt, da war der eigene Post oftmals noch gar nicht sichtbar beim Neuladen der Seite. Das ist jetzt stark vereinfacht erklärt, aber im Prinzip kannst du alles rankloppen was rechnen kann. Ein großes Unternehmen, deren Dienste du aufgezählt hast, hat zu Beginn der Pandemie und dem damit verbunden hohen Zugriff auf die Clouddienste jegliche verfügbare zusätzliche Hardware in z.B. Sporthallen aufgestellt und irgendwie online gebracht um die sprunghafte Last bewältigen zu können. Die Software darauf kann alles sein, von unangepassten Linux Varianten wie auch selbst geschrieben - je nach Anwendung bzw. je nachdem was man den Kunden anbieten möchte. Wer besondere Konstellationen benötigt wird diese auch irgendwo finden, ob virtualisiert oder nicht. Angebot und Nachfrage.
Um deine nicht gestellten Fragen zu beantworten: Das "Problem" in Deutschland ist aber, dass viele die Cloud nicht verstehen. Anstatt den Server im Betrieb wird halt ein Dedicated Server im Rechenzentrum gemietet und man ist in der "Cloud". Yeah. Viele kleine und mittlere Unternehmen sind da nicht weitergekommen als das. Die Integration in die Cloud findet kaum statt. Stichwort "serverless", d.h. da laufen zwar überall noch Server, aber als Anwender kümmert das einen nicht was da passiert, sondern man schreibt einfach Code und lässt diesen ausführen bzw. Container/Apps werden bei Bedarf ausgeführt und vom Anbieter entsprechend skaliert.
Als vereinfachtes Beispiel musst du dir nur überlegen wie man in Deutschland ein Netflix entwickeln würde. Beispiel RTL Now bzw. jetzt RTL+. Das lief alles im eigenen Rechenzentrum von CBC, der Technikfirma der RTL Gruppe. So würden das viele machen, Hardware mieten oder eben selbst bereitstellen und dann sich um die ganze Frickelei kümmern was aber den Vorteil hat, Sachen ggf. auch schnell umzusetzen und anzupassen auf beiden Seiten. Entwicklung und Technik sind nicht getrennt, Technik frisst Ressourcen. RTL Now ist dann zu AWS mirgriert. Das dauerte ungefähr ein Jahr, das monolithische System wurde dann in Apps/Container gesplittet und die Entwicklung wurde komplett umstrukturiert. Technisch viele Neuerungen: Anstatt PHP jetzt Kotlin/Spring Boot, Gitlab CI statt Jenkins und Entwickler haben nicht mehr auf ihnen mehr oder weniger fremde Hardwaresystem ihre Software gestartet.
Große Dienste wie von dir genannt unterteilen ihren Markt gar nicht mehr primär in Umsatz sondern wie gut das Land es versteht Dienste in die Cloud zu migrieren. Deutschland ist da komplett abgehängt. In Europa sind das v.a. Isreal, die verstehen, was die Cloud kann.
Ob das gut oder schlecht ist muss dann jeder selber wissen. Der Weg in die Cloud ist leicht. Der Weg daraus möglich, wird aber bewusst sehr schwierig gestaltet. Aber wer eine gute Idee hat wie Netflix kann das im Handumdrehen umsetzen auf diese Art und Weise und sich um sein Geschäftsmodell kümmern und eben erstmal weniger um die IT, welches Betriebssystem auf welchem Server läuft und und und...

 

[BrollyLSSJ]

• Basieren die Server von z.B. AWS oder Azure u.a. üblicherweise auf X86/64 ?
• Läuft darauf native Linux?
• Und darauf ein VM und jeder Kunde erhält eine Umgebung wie sein eigenes Windows- oder Linux-/LAN?
• Oder muss er seine Anwendungen in Linux portieren (compilieren, linken..)?
• Was ist eine Instanz, ein virtuelles X86/64 System?
• Was machen Kunden mit anderen Unix-Derivaten wie AIX (auf risc-Basis)?
• Ist das, was z.B. HPE als Server bietet auf Intel-Basis, oder gibt es da noch eine eigene Architektur?
• Was machen Kunden mit z/OS oder i/OS Host-Rechnern, bekommen die eine Power-Umgebung??

Mit Cloud habe ich nicht so viel zu tun, versuche aber trotzdem die Fragen soweit zu beantworten, wie ich es weiß. Da wir in der Firma ESXi zur Virtualisierung nutzen, sollte das meines Wissens nach auch auf AWS oder Azure zutreffen.

1) Meistens. Die werden da aber sich selber Server zusammen bauen und nicht unbedingt was von DELL oder HPE kaufen. Gibt aber je nach Anwendungsfall, sofern AWS und Azure es bereit stellen, auch andere Hardware. Gehe ich bei 6) drauf ein.
2) Ja, sollte ein von Amazon und Co. selbst erstelltes Linux Derivat sein.
3) Da laufen mehrere VMs drauf. Das ist ja der Sinn der Virtualisierung. Es kann hier aber durchaus sein, dass hier mehrere VMs für einen Kunden als auch mehrere Kunden Ihre VMs drauf betreiben.
4) Wenn es die Anwendung für z.B. Ubuntu nicht gibt, müsste er die selber kompilieren. Das kommt immer drauf an, was der Kunde hier laufen lassen will.
5) Je nach Anforderung kann eine Instanz eine VM oder mehrere VMs sein (z.B. ein SQL Server und ein Applikationsserver). Ist Definitionssache. Meistens sollte es aber gleichbedeutend mit einer VM sein.
6) Man kann auch mit PowerPC / AIX virtualisieren. Wie das genau funktioniert, weiß ich nicht. Aber da könnte wie bei den *BSD Derivaten "bhyve" zum Zuge kommen. Da habe ich aber keine Erfahrung mit (ich nutze halt VMware in unserer Firma, AIX wird von den Linux Kollegen betrieben).
7) HPE hat z.B. auch AIX Systeme und andere Hersteller (Fujitsu, DELL, etc.) auch. Kommt immer drauf an, was virtualisiert werden soll. HPE hat und DELL haben auch AMD basierte Server (Epyc). Meistens kann man aber, obwohl beides x86 ist, AMD und Intel nicht mischen. Bei VMware z.B. gibt es den sogenannten EVC Modus. Der sorgt dafür, dass neuere CPUs auch nur das Feature Set von älteren CPUs wiedergeben (z.B. wird AVX512 bei neueren CPUs damit deaktiviert, weil ältere CPUs dies nicht können). Damit kann man also auch neuere CPUs in ein vorhandenes Cluster mit aufnehmen. Wenn dann die älteren Server ersetzt worden sind, kann man den EVC Modus höher setzen, dass alle dann z.B. nun auch AVX512 nutzen. Man kann nur bei VMware den EVC Modus eben nur auf Intel oder nur auf AMD stellen, aber nicht mischen. Deswegen muss man zur Erweiterung des Clusters immer noch den gleichen CPU Hersteller kaufen, wie das Cluster aktuell betrieben wird. Ausnahme ist halt beim kompletten Neu-Aufbau (VMs kann man zwischen AMD und Intel migrieren, die müssen dann aber ausgeschaltet sein).
8) Ja, die bekommen dann entsprechend eine Power Umgebung. Siehe 6).

Ansonsten hat @h3@d1355_h0r53 dir ja auch schon gut geantwortet.

 

[RalphS]

Da wird grad ein bißchen arg viel zusammengeworfen.

Ganz grundlegend:
1. In der Cloud gibt es keine Server. Das "traditionelle" Client-Server-Modell existiert dort nicht.
2. Es folgt, daß Heimgeräte und die meiste Heimsoftware trotz Namens nichts mit "Cloud" zu tun haben kann.
3. Ein anschauliches Beispiel insbesondere für den gemeinen Windowsnutzer ist, man ahnt es, die Microsoft Cloud:

A. Man meldet sich nicht an einem Server an, sondern bei einem Provider. Bei Windows findet man diesen entweder in Form der Windowsanmeldung selber oder über ein dediziertes Portal (letztlich verwendet Windows aber dieselben APIs).

B. Es gibt keine Freigaben, die man mountet, sondern es gibt einen Freigabedienst. Bei Microsoft ist das Onedrive. Der bindet die "Cloud-Dateidaten" direkt ein. Wo die Daten liegen? Weiß ich als Anwender nicht. Soll ich auch gar nicht wissen. Muß ich nicht wissen.
C. Es gibt weitergehende Ressourcen (fast) beliebiger Natur, die mir meine Cloud als Dienst bereitstellen kann. Auch hier sind Quelle und Ziel voneinander losgelöst. Es gibt, wie in 1 genannt, keinen Server; ich sehe meine bereitgestellte VM, aber wo die läuft und ob das von "jetzt" auf "nachher" dieselbe VM ist, das weiß ich nicht. Wenn es nicht gerade eine besondere Affinität geben muß, dann sehr wahrscheinlich nicht.

Die Technik darunter ist ebenfalls komplett losgelöst von "der Cloud". Das ist die Idee. Der Anwender soll absolut nichts mehr von der Implementierung mitbekommen (müssen). Es ist völlig egal, ob das Windows Hosts sind oder Linux oder BSD oder sonst was. Üblicherweise sind es anonyme VMs, die nach Bedarf erzeugt und weggeworfen werden, bereitgestellt über HyperV (via SCVMM oder wie die das inzwischen nennen), via vSphere/Horizon (dasselbe) oder sonst irgendeine Hypervisor-I basierte Plattform. Obendrauf das Cloud-Management-Tool der Wahl für die Definition und Bereitstellung der ausgewählten Dienste und das war's. Klar, etwas vereinfacht, aber grundsätzlich ist eine Cloud nicht viel mehr als ein statusloser Load-Balancing-Cluster mit der zusätzlichen Eigenschaft, daß dieser nicht lokal beschränkt ist.

Natürlich gibt es technisch ein paar Spezifika, allen voran (denke ich zumindest) der Anspruch der Statuslosigkeit. Wenn ich einen solchen Status hätte, dann müßte ich diesen bei jeder Aktion irgendwie mitgeben, denn ich weiß von einem Aufruf zum nächsten ja nicht, ob ich noch dort hinkomme, wo ich eben war; wenn ich das wollen würde, wäre das ebenfalls ein zu übertragender Status. "Status haben" heißt auch, Parallelisieren wird erschwert, weil spätestens wenn ich denselben Status an zwei Maschinen gebe zur weiteren Verarbeitung, sich dieser Status dann innerhalb dieser beider Maschinen unterscheiden würde. Dasselbe gilt für lokal angebundenen Speicher. Wenn ich was lokal speichere und ich greife beim nächsten Mal auf eine ganz andere VM, dann ist mein lokal gespeicherter Kram dort natürlich nicht vorhanden, wenn ich ihn nicht grad replizieren will -- was Zeit und Bandbreite kostet. Und schon landen wir - im weitesten Sinne - bei Cluster shared Volumes und - konkreter -- bei objektbasiertem Speicher ("S3").

Aber für das Arbeiten mit der Cloud in diesem Sinne ist das alles unerheblich. Das was man als Anwender sieht, das ist real nicht da bzw. nicht in der Form da, wie man es sieht oder erwarten würde.

 

[h3@d1355_h0r53]

@RalphS Naja, so ganz richtig ist das nicht. Natürlich stehen da Server und je nachdem wen du fragst sagt dir jemand von AWS was anderes als ein Mittelständler, der sich paar vServer mietet. Azure beschreibt die Cloud z.B. als globales Netzwerk von Servern, die untereinander vernetzt sind. Die Definition in die Richtung findet man überall. Als Käufer/Mieter einer serverless Cloud hat man in der Tat gar nichts mehr damit zu tun. Es kann cloudbasierte Infrastruktur geben, da kann es sehr wichtig sein welche Hardware angeboten wird, d.h. welche cloudbasierten Systeme es gibt. Aber eben wie du schreibst auch die cloudbasierten Anwendungen, die einen weiteren Teilbereich darstellen. Das Thema ist so breit und das Wort "Cloud" hat keine eindeutige Definition. Der TE hat ja nach konkreten Dingen bezüglich der Server gefragt. Wie vielschichtig das Thema ist erkennt man ja was hier geschrieben wurde.

 

[kfranzk]

Danke Freunde, das war jetzt sehr ausführlich.
Es bleibt dennoch meine Basisfrage nach Hardware-Architektur und Betriebssystemen.
Nach meinem Verständnis sind doch Programme, die für verschiedene Hardware-Architekturen entwickelt wurden, auf einer anderen HW-Architektur (X86/64, ARM-Risc, Power-Risc HPE-Risc...) nicht lauffähig.

Jetzt stelle ich mir einen Betrieb mit über Jahrzehnte gewachsenen Anwendungen auf verschiedenen Systemen vor.

• Da mag die gesamte Auftragsbearbeitung auf einem VM-VSE/370 laufen.
• Das CAD-System läuft auf DEC-Unix oder AIX auf Risc-Basis.
• Das Vertriebssystem läuft auf IBM AS/400 (i-Series).
• Da läuft HR also ein Personal-System auf Exel-Basis auf Intel.

Jetzt geht der Kunde zu Azure oder AWS oder Google o.a. und will die Systeme und die Systembetreuung outsourcen.
Alte Anwendungen umzustellen auf eine neue Archtektur geht nur sukzessive und sprengt Zeit- und Kostenrahmen.
Eine reine Windows oder Linux-Umgebung in ein externes RZ zu portieren wäre doch zu einfach.

Deshalb noch einmal meine Fragen:

• Können diese RZ-Anbieter wie Azure oder AWS o.a. für obigen Fall eine Lösung anbieten?
• Laufen solche Alt-Anwendungen gemeinsam unter irgendeinem VM?
• Haben diese Anbieter nur X86/64 Rechner?
• Oder müssten dann diese Anbieter sich solche kompatiblen Rechner als HW selbst hinstellen?

Gruß Konrad

 

[wahli]

Speziell für eine Architektur geschriebene Programme laufen nur auf dieser Architektur. In einer VM könnte das noch funktionieren.
Du vermischt da ziemlich viel. VM, Virtualisierung, Cloud,...

 

[BrollyLSSJ]

Nach meinem Verständnis sind doch Programme, die für verschiedene Hardware-Architekturen entwickelt wurden, auf einer anderen HW-Architektur (X86/64, ARM-Risc, Power-Risc HPE-Risc...) nicht lauffähig.

Du kannst z.B. mit QEMU auch eine ARM VM auf einem x86 Host laufen lassen. QEMU unterstützt noch mehr Architekturen. Ist je nach CPU und unterstützten Befehlssatz aber auch langsamer. Gewisse Dinge können z.B. mit SSE oder AVX beschleunigt werden. Der Rest wird halt irgendwie in der CPU emuliert. Das muss dann halt entsprechend mal getestet werden (je Anwendung).

Bei Wikipedia (Englisch) gibt es eine kleine Übersicht, welche Host CPU Architektur und welche Guest (VM) CPU Architektur der jeweilige Hypervisor unterstützt.

 

[kfranzk]

In der oben genannten Übersicht finde ich ein VM das auf Power und x86 läuft und folgende Gastsysteme kann:
Linux PowerPC, x86; AIX, IBM i
Das kommt doch dem, was ich mir vorstelle, schon sehr nahe. Aber ob die genannten Service-Anbieter das nutzen und anbieten???

PowerVM	IBM	POWER4, POWER5, POWER6, POWER7, POWER8	POWER4/5/6/7/8, x86 (PowerVM-Lx86)	PowerVM Firmware	Linux PowerPC, x86; AIX, IBM i	Proprietary

 

[Evil E-Lex]

Jetzt stelle ich mir einen Betrieb mit über Jahrzehnte gewachsenen Anwendungen auf verschiedenen Systemen vor.

• Da mag die gesamte Auftragsbearbeitung auf einem VM-VSE/370 laufen.
• Das CAD-System läuft auf DEC-Unix oder AIX auf Risc-Basis.
• Das Vertriebssystem läuft auf IBM AS/400 (i-Series).
• Da läuft HR also ein Personal-System auf Exel-Basis auf Intel.

Jetzt geht der Kunde zu Azure oder AWS oder Google o.a. und will die Systeme und die Systembetreuung outsourcen.

Ein Kunde der diese proprietären Legacy-Hardwarearchitekturen verwendet, würde niemals zu Azure oder AWS gehen und erwarten, dass seine Legacy-Hardware dort als VM weiterlaufen kann. Der Kunde würde stattdessen die Anwendungen auf die jeweiligen Clouddienste migrieren.
@RalphS hat in seinem Beitrag gut erklärt, wie "die Cloud" funktioniert.

 

[RalphS]

@h3@d1355_h0r53 Sicher, das ist arg vereinfacht.

Kerngedanke, der mitgenommen werden sollte, ist folgender (sogar prinzipiell naheliegender, wenn man sich kurz zurücklehnt): der Name.

Cloud heißt "Cloud", weil das Konstrukt wie eine (Regen)Wolke etwas zeigt (guck hoch => sehe Wolke) was real aber nicht als Ganzes da ist. Es gibt nicht "die Wolke" als greifbares Konstrukt, ebensowenig wie "die Cloud". Stattdessen gibt es viele einzelne Tropfen, die ich als Betrachter weder erkennen noch unterscheiden kann - analog gibt es viele anonyme Einzel-Maschinen, die für sich genommen "nichts" können, die aber in ihrer Gesamtheit eben die Cloud darstellen.

Regenwolken stellen halt die Services Regen, Schnee, Hagel und so weiter bereit. Ein einzelner Tropfen in der Wolke da oben kann das nicht, die Wolke als Ganzes aber schon.

Das Problem in bezug auf "die Cloud" ist aber, daß es im Gegensatz zu Regenwolken das totale Buzzword geworden ist und daß ein hoher Abstrahierungsgrad da ist.
Ja, natürlich gibt es Server im Backend. Irgendeiner muß die Chose ja ausführen. Aber auf diese Server greift man als Anwender nicht zu. Der Umstand, daß man "in der Cloud" einen Server als Service bereitstellen kann, wie so viele andere Dinge auch, hat damit nicht das Geringste zu tun.

Der Umstand, daß ich über die Cloud einen Webservice bereitgestellt bekommen kann, heißt nur, daß es ein Portal gibt mit einem definierten Namen, auf den ich über http(s) zugreifen kann --- aber dort läuft der Webservice nicht. Das ist maximal ein Gateway, ein Loadbalancer, ein Anycast-Ziel, nennen wir's wie wir wollen; was es NICHT ist, ist der Webserver selbst. DER läuft auf einer Maschine, die ich weder kennen kann noch kennenlernen werde und von der ich nicht einmal weiß, ob ich mit zwei Zugriffen wiederbekomme.

Im Sinne der Cloud läuft es eher so ab:
1. Anfrage geht am Portal ein
2. Anhand der eingehenden Parameter wird eine VM erstellt, der angeforderte Service dort eingerichtet und dann gestartet
3. Der Service beantwortet die Anfrage und liefert das Ergebnis ans Portal
4. Das Portal wirft die VM mitsamt dem Service wieder weg.