Forum: PC-Programmierung Webhosting-Anbieter - was "werkelt" im Hintergrund?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Anton M. (andman2020)


Bewertung
0 lesenswert
nicht lesenswert
Guten Tag,

ich interessiere mich für die Technik, die bei klassischen 
Webhosting-Anbietern im Hintergrund läuft. Ich kenne das leider nur aus 
meiner Sicht als Kunde und da arbeiten scheinbar viele verschiedene 
Kunden irgendwie auf einem einzelnen physischen Server, ohne sich in die 
Quere zu kommen. Es scheint auf Kundenseite diverse Verwaltungs-Tools zu 
geben wie z.B. Plesk, wo man per Mausklick seine gewünschte 
Konfiguration zusammenstellen kann. Aber wie sieht das große Gesamtbild 
bzw. die Technik dahinter aus?

Irgendein Betriebssystem muss ja im Hintergrund laufen. Gibt es da so 
eine Art Gold-Standard für Web-Hosting oder ist es im Grunde egal ob ich 
Debian, Ubuntu, etc. Headless installiere?

Kommmt immer Virtualisierung zum Einsatz und wenn ja welche wäre 
besonders gut dafür geeignet?

Ich kenne mich mit Virtualisierung nicht so gut aus und frage mich wie 
bei Webhosting die "innere" Sicherheit gewährleistet wird, wo doch jeder 
Kunde z.B. FTP, PHP, Datenbanken und einen Webserver benötigt? Man 
findet Unmengen an Informationen über die "äußere" Sicherheit, also wie 
man Server nach außen hin absichert, aber wie gewährleistet man die 
"innere" Sicherheit? Sorgen Tools wie Plesk hier auch gleich für die 
notwendige Trennung?

Ich kann mir irgendwie nicht vorstellen, dass Webhoster für jeden Kunden 
eine komplette eigene virtuelle Maschine laufen lassen. Weiß jemand, 
welche Techniken oder Konzepte da im Hintergrund zum Einsatz kommen?

Vielen Dank und viele Grüße
Anton

von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Anton M. schrieb:
> Irgendein Betriebssystem muss ja im Hintergrund laufen. Gibt es da so
> eine Art Gold-Standard für Web-Hosting

Meistens irgendwas Unixoides, egal ob eine der diversen 
Linux-Distributionen, *BSD, Solaris etc.

Anton M. schrieb:
> Kommmt immer Virtualisierung zum Einsatz

Nein.

Anton M. schrieb:
> frage mich wie bei Webhosting die "innere" Sicherheit gewährleistet
> wird, wo doch jeder Kunde z.B. FTP, PHP, Datenbanken und einen Webserver
> benötigt?

Multiuser-Betriebssysteme bieten einige Möglichkeiten dafür. Passende 
Permissions sind das Minimum, etwas sicherer bekommt man es z.B. noch 
mit chroot()-Umgebungen für die einzelnen Kunden, so dass man "fremde" 
Teile des Filesystems gar nicht erst sieht.

Aber erstaunlich oft wird bei der Sicherheit auch gepfuscht, so dass Du 
Zugriff auf andere Kundenverzeichnisse hast und dort an brisante Dinge 
wie deren Datenbank-Zugangsdaten kommst.

von sid (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
Es muss nichteinmal mehr ein OS im Hintergrund arbeiten, nein...
der BIOS des Servers muss nur auf den LAN Wakeup hören, das reicht schon 
mittlerweile.

Viele solche "virtuellen" Server arbeiten wie der Name schon sagt rein 
virtuell;
die werden meist als Gast innerhalb eines HostOS gebootet
(das wird zumeist ein Linuxderivat sein, obschon auch viele noch MS 
Hosts nutzen)
und falls der Platz knapp wird startet die Verwaltungssoftware einen 
neuen physischen Rechner (hier kommt das WOL ins Spiel)
der kann vollständig ohne OS sein;
das nötige Bootimage wird einfach per NAS eingebunden und startet als 
LiveSystem, damit lässt er sich mit demselben image als dedicated server
betreiben oder
mit einem "parentimage" wahlweise als Host für mehrere virtuelle images 
im Gastmodus.
das parentimage kann hier wieder alles sein,
Linux ist aber durchaus wahrscheinlich (selbst wenn die Verwaltung auf 
windows läuft sogar) es gibt aber Wahlmöglichkeiten und demnach auch 
Unterschiede.

Nun zum Sicherheitsaspekt:
der virtuelel Rechner hat keinen Zugriff auf die physischen Geräte mit 
Ausnahme der ihm zugeteilten Teile der Netzwerkkarte.
er schreibt in der Regel nichteinmal auf Festplatten sondern auf 
virtuelle Festplatten die nur Containerdateien auf realen festplatten 
sind.
Es gibt keine Möglichkeit dass er direkt auf eine andere Virtuelel 
Maschine zugreift,
es sei denn er nimmt den Weg über die Netztwerkkarte
(womit der Angriff ein externer Angriff würde ;))

Da nie zwei virtuelle Systeme wirklich zeitgleich auf einen einzigen 
Prozessorkern zugreifen können, ist selbst der geschickteste Zugriff 
sinnlos.
Der komplette stack wird beim wechsel von systemA auf systemB gelöscht.
Ähnliches gilt für die RAM verteilung,
jede virtuelle Maschine hat nur begrenzte feststehende Ramadressen zur 
verfügung, und kann ausserhalb weder lesen noch schreiben.
Und obschon eine manipulations hier nicht völlig auszuschliessen ist,
ist sie doch nahezu unmöglich,
mit ECC Ram scheitert der versuch schon recht früh, ohne ist es 
wahrscheinlicher, dass das attackierte System schlicht abstürzt und 
neustartet um den Fehler zu beheben.

Nene, interne Angriffe sind höchst unwahrscheinlich,
eben weil nahezu alles virtualisiert ist bis auf ein Netzwerk.
UNd falls es NICHT virtualisiert ist ist es dediziert.. läuft also in 
der Tat auf einem eigenen Server und hat somit auch keinen Zugriff auf 
Nachbarsysteme (ausser über das Netzwerk) und man dreht sich im Kreis ;)

'sid

PS und damit: keine Angriff ausser übers Netzwerk möglich.
PPS naja, ich kenne kein System was nicht so arbeitet, heisst nicht, 
dass nicht eventuell ein schlecht programmiertes oder eins für spezielle 
Anwendungen existiert, welches shared ressources stark vereinfacht 
anbietet mit dem interne Angriffe möglich wären.

von Hmmm (Gast)


Bewertung
2 lesenswert
nicht lesenswert
sid schrieb:
> ich kenne kein System was nicht so arbeitet

Du hast ganz offensichtlich nicht die geringste Ahnung vom Thema 
Webhosting. Warum muss man krampfhaft eine Antwort auf eine Frage 
schreiben, die man nicht sinnvoll beantworten kann?

von adian (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Anton M. schrieb:
> ich interessiere mich für die Technik, die bei klassischen
> Webhosting-Anbietern im Hintergrund läuft. Ich kenne das leider nur aus
> meiner Sicht als Kunde und da arbeiten scheinbar viele verschiedene
> Kunden irgendwie auf einem einzelnen physischen Server, ohne sich in die
> Quere zu kommen. Es scheint auf Kundenseite diverse Verwaltungs-Tools zu
> geben wie z.B. Plesk, wo man per Mausklick seine gewünschte
> Konfiguration zusammenstellen kann. Aber wie sieht das große Gesamtbild
> bzw. die Technik dahinter aus?

Üblicherweise, besteht ein Klassischer Hoster für Webseiten aus 
Loadbalancer, Frontend mit Standard Webserver (Apcahe und nginx werden 
gerne genommen), Datenbankserver und Storage backend. Außerdem brauchst 
Du noch etwas Verwaltung, wie DNS-Server, Email-Server, Provision 
Systeme, Moitoring, Deployment Systeme (gerne mit eigenem Netzwerk um 
den Kundentraffic nicht zu beeinträchtigen) und Jumphosts (idealerweise 
mit Out of Band Zugängen).

Jede Komponente ist redundant um einen Single Point of failure zu 
vermeiden. Außerdem achtet der Webhoster darauf das alle Seine Systeme 
für den Kunden Mandanten fähig sind (und laut Management gerne als 
Whitelabel, aber das wird selten konsequent durchgezogen). Wichtig 
hierbei für den Webhoster ist vor allen, dass er möglichst viele Kunden 
auf ein System bekommt. Virtualisierung macht für den Klassischen 
Webhoster als Security measurement für den Kunden wenig Sinn! So ein 
Frontend kostet in der Anschaffung gerne mal 20K Euro, ein Backend das 5 
Fache, wenn Du da jeden Kunden in einen Virtuellen Environment 
verpackst, verschwendest Du zu viel Ressourcen und wirst zu teuer.

Anton M. schrieb:
> Irgendein Betriebssystem muss ja im Hintergrund laufen. Gibt es da so
> eine Art Gold-Standard für Web-Hosting oder ist es im Grunde egal ob ich
> Debian, Ubuntu, etc. Headless installiere?

Ein Goldstandard gibt es nicht, aber es ist eigentlich immer ein Linux 
oder selten auch ein Unix System. Die Distribution Variiert auch, oft 
mal werden aber mindestens eigene Pakete von den Großen Hostern erstellt 
und auf interne Sourcearchive geladen mach mal werden sogar eigene 
Distributionen gepflegt.
Pets and cattles sind die Stichwörter beim Betreiben eines Webhoster. 
Einen einzelnen Server kann man vielleicht noch über eine GUI Pflegen 
(das wäre dann ein Pet), aber wenn du ein dutzend Systeme hast willst du 
die Headless über die Konsole Administrieren (cattles) und alles was 
nicht in x Minuten repariert werden kann, sogt für eine neu Installation 
der Defekten Komponente. Auf jeden Fall werden meistens Linux Systeme 
vorgezogen, die Server zentrisch sind. Ubuntu würde ich persönlich nicht 
dazu zählen, sondern dann wahrscheinlich ein Debian nehmen (aber das ist 
nur meine Meinung)

Anton M. schrieb:
> Kommmt immer Virtualisierung zum Einsatz und wenn ja welche wäre
> besonders gut dafür geeignet?

Beim Webhosting, nicht um die Kunden zu separieren, siehe weiter oben. 
Die Kosten wären unverhältnismäßig hoch, denk dran ein Webspace gibt es 
schon ab 1 Euro Pro Monat und der Durchschnittsvertrag läuft 24 Monate. 
Hin und wieder werden aber interne Dinge wie ein Webserver für mehere 
Kunden virtualisiert.

Anton M. schrieb:
> Ich kenne mich mit Virtualisierung nicht so gut aus und frage mich wie
> bei Webhosting die "innere" Sicherheit gewährleistet wird, wo doch jeder
> Kunde z.B. FTP, PHP, Datenbanken und einen Webserver benötigt?

Shared Webhosting gibt es seit den 90er des letzten Jahrhundert, 
Virtualisierung ist viel jünger. Der Prozess des Kunden muss auch nicht 
als Root laufen im gegenteil, Sie sind nicht privilegiert. Unix und 
Linux sind seit Stunde 0 Mehrbenutzer Systeme. Hier wird also lieber mit 
rootjails, ACLs, capabilitys, cgroups, mandatory access control, private 
Mountspaces und ähnlichen dafür gesorgt das die Benutzer sich nicht in 
die quere Kommen, statt zu virtualisieren.

Anton M. schrieb:
> Ich kann mir irgendwie nicht vorstellen, dass Webhoster für jeden Kunden
> eine komplette eigene virtuelle Maschine laufen lassen. Weiß jemand,
> welche Techniken oder Konzepte da im Hintergrund zum Einsatz kommen?

Machen Sie ja auch nicht, aber wenn Du eine gewisse Erfahrung hast und 
Dein System gut überwachst kannst Du ein paar 100 Kunden auf jede 
Webserver Instanz lassen. Mit der Zeit bekommst Du dann auch eine Metrik 
welcher Kunde besonders viel Traffic verursacht und je nach 
Geschäftsmodell trennst Du diese Kunden dann auf unterschiedliche 
Systeme oder bringst Sie alle auf das gleiche, damit sie möglichst bald 
woanders den Traffic verursachen.

von Blechbieger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
In den frühen 2000er liefen alle de-Domains die bei Strato registriert 
waren (mehrere Zehntausend) auf einem einzigen Sun-Server als virtuelle 
Domains eines Apache. Da das damals meistens nur statische Seiten und 
klein waren und nur wenig besucht wurden ging das gut.

von Bastler (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Anton M. schrieb:
> Aber wie sieht das große Gesamtbild
> bzw. die Technik dahinter aus?
>
> Irgendein Betriebssystem muss ja im Hintergrund laufen. Gibt es da so
> eine Art Gold-Standard für Web-Hosting oder ist es im Grunde egal ob ich
> Debian, Ubuntu, etc. Headless installiere?

Das meist verwendete Betriebssystem in diesem Bereich dürfte Linux sein. 
Distro wird jeder Hoster so sein eigenen Liebling haben, oder evtl. auch 
seine eigene bauen oder eine anpassen.

Virtualisierung wird schon vorkommen, aber nicht pro Kunde; braucht man 
ja auch nicht. Ein Web-Server muss ja nur eine Domain auf ein bestimmtes 
Verzeichnis mappen. Dazu benötigt man keine Virtualisierung.

Die ganze Software die man als Hoster braucht, gibt's im Prinzip 
komplett als Open-Source. Die ganze Kunst in diesem Geschäft ist, die 
Betriebskosten durch bedingungslose Automatisierung zu minimieren, und 
da fängt das Know-How an.

von Coronianer (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
adian schrieb:
> Shared Webhosting gibt es seit den 90er des letzten Jahrhundert,
> Virtualisierung ist viel jünger.

Ich bezweifel, dass es Webhosting schon 1966 gab.
Also nein, Virtualisierung ist sehr viel älter!

von Coronianer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
adian schrieb:
> Unix und
> Linux sind seit Stunde 0 Mehrbenutzer Systeme. Hier wird also lieber mit
> rootjails, ACLs, capabilitys, cgroups, mandatory access control, private
> Mountspaces und ähnlichen dafür gesorgt das die Benutzer sich nicht in
> die quere Kommen, statt zu virtualisieren.

Naja, ACLs, Capabilities, cgroups und mandatory access control gibt es 
bei Linux nicht seit Stunde 0. Das ist erst Stück für Stück 
dazugekommen.

von Johannes O. (jojo_2)


Bewertung
2 lesenswert
nicht lesenswert
Da gibt es verschiedene Lösungen. Hier ein paar persönliche Erfahrungen 
im Serverbetrieb mit dem Xen Hypervisor, was eher so die unteren Layer 
bedient. Es gibt da aber noch viel mehr Lösungen.

Ich kann mir auf einem Host nahezu beliebig viele Gast-Systeme 
einrichten. Diese sind ordentlich voneinander getrennt. Sie haben ihren 
eigenen Festplattenplatz. Haben RAM fest zugeteilt bekommen. Haben eine 
Maximalanzahl an CPU Kernen die sie verwenden dürfen. Und sogar ne 
eigene MAC-Adresse und IP bekommen sie üblicherweise bei mir. Von außen 
betrachtet sieht es in der Tat so aus, als würden auf diesem einen 
Netzwerkport mehrere Rechner dahinter laufen. Das ist aber alles "nur" 
virtualisiert und läuft auf einer Hardware.
Beispiel hier: Ein schöner Server (Schöne CPU, ein paar dutzend GB ECC 
RAM, zwei Festplatten im RAID1, ...) hat einige VMs drauf laufen, z.B., 
Webserver, Router, Gameserver.


Anton M. schrieb:
> Ich kann mir irgendwie nicht vorstellen, dass Webhoster für jeden Kunden
> eine komplette eigene virtuelle Maschine laufen lassen. Weiß jemand,
> welche Techniken oder Konzepte da im Hintergrund zum Einsatz kommen?
Kommt drauf an. Wenn du dir nen "V-Server" zulegst, dann hast du einen 
virtualisierten Server. Das dürfte eine SEHR häufige Konfiguration sein. 
D.h. du hast vollständige Kontrolle über diesen Server, sprich: Du legst 
das OS fest, spielst Updates ein, konfigurierst das alles auf 
Betriebssystemseite.
Nachteil: Jeder Kunde braucht sein eigenes OS, d.h. das benötigt recht 
viel Speicherplatz und auch ein wenig CPU Power. Es geht aber auch 
billiger:


Anton M. schrieb:
> Ich kenne mich mit Virtualisierung nicht so gut aus und frage mich wie
> bei Webhosting die "innere" Sicherheit gewährleistet wird, wo doch jeder
> Kunde z.B. FTP, PHP, Datenbanken und einen Webserver benötigt?

Wenn du "nur" Webhosting haben willst, dann gibt es da Alternativen ohne 
Virtualisierung zu benötigen. Über verschiedene Benutzer kannst du 
Rechte festlegen, wer zum Beispiel was lesen und schreiben darf. Das 
geht allein schon über Benutzerrechte ganz gut. Datenbanken haben dann 
teils nochmal ein eigenes Usermanagement, d.h. ich könnte dir Zugriff 
auf 3 Datenbanken geben, auf die jemand anderes keine Rechte hat. Da 
kommt es aber auch immer stark auf die Anforderungen drauf an, wie stark 
das getrennt werden soll und muss (Datenschutz!).
Vorteil: Es läuft ein OS, der Betreiber aktualisiert das System. 
Jenachdem wie gut das konfiguriert ist, kann aber ein einzelner User den 
Server mehr oder weniger leicht stören (Stichwort Forkbombs etc.)


sid hat leider ein paar Halbwahrheiten verbreitet:

sid schrieb:
> Nun zum Sicherheitsaspekt:
> der virtuelel Rechner hat keinen Zugriff auf die physischen Geräte mit
> Ausnahme der ihm zugeteilten Teile der Netzwerkkarte.
Nein, mir ist nicht mal klar was du genau meinst. Das virtuelle System 
hat auf das Zugriff, was du ihm zuweist. Du kannst ganze Geräte 
durchreichen. Oder aber gar keine. Und eine Netzwerkkarte hat keine 
"Teile". Oft wird das mit einer Bridge gelöst, d.h. deine VM bekommt 
eine virtuelle Netzwerkkarte die mit der physischen Netzwerkkarte 
verbunden wird. Ggf aber mit Filtern dazwischen.

> er schreibt in der Regel nichteinmal auf Festplatten sondern auf
> virtuelle Festplatten die nur Containerdateien auf realen festplatten
> sind.
Eher nicht.
Containerdateien verwende ich ungern, weil du dann zwei mal ein 
Filesystem dazwischen hast (einmal im Gast, einmal im Host) und das die 
Performance runter zieht. Mit Xen kannst du beispielsweise (aber nicht 
nur!) direkt auf ein logical volume schreiben.
Außerdem ist selbst im Host die Festplatte auf einem üblichen Server 
NICHT "real" sondern du siehst nur das Device, das dir dein 
Raidcontroller zur Verfügung stellt. Erst dieser verteilt die Daten 
wieder auf reale Festplatten.

> Es gibt keine Möglichkeit dass er direkt auf eine andere Virtuelel
> Maschine zugreift,
> es sei denn er nimmt den Weg über die Netztwerkkarte
> (womit der Angriff ein externer Angriff würde ;))
Spectre, Meltdown, ... um mal ein paar Angriffe zu nennen, die 
INSBESONDERE in virtualisierten Umgebungen relevant sind.
Auch ansonsten gibt es Möglichkeiten: Der Gast kann auf den Host 
ausbrechen und andere Gäste manipulieren.
Inwiefern das über die Netzwerkkarte allerdings funktionieren würde, 
hängt von der Config ab.

> Der komplette stack wird beim wechsel von systemA auf systemB gelöscht.
Nein. Der Stack bleibt da, die Daten drauf brauchst du noch. Das, was 
sich ändert ist z.B. der Stack Pointer.

> Ähnliches gilt für die RAM verteilung,
> jede virtuelle Maschine hat nur begrenzte feststehende Ramadressen zur
> verfügung, und kann ausserhalb weder lesen noch schreiben.
> Und obschon eine manipulations hier nicht völlig auszuschliessen ist,
> ist sie doch nahezu unmöglich,
> mit ECC Ram scheitert der versuch schon recht früh
ECC Ram hat damit erstmal GAR NIX zu tun. ECC ist 
reliability/availability. Höchstens in Fällen wie Rowhammer kann (muss 
aber nicht) ECC helfen.
Wenn jemand vom System her den RAM manipuliert dann wird das mit ECC 
nicht auffallen. Die Prüfsummen werden nicht in Software/vom OS 
berechnet, das macht der Memory-Controller in Hardware. Du bekommst ne 
Mitteilung wenn was nicht passt. Direkten Zugriff auf die low-level 
Fehlerkorrektur/Erkennungsinformationen hast du normalerweise nicht.

> ohne ist es
> wahrscheinlicher, dass das attackierte System schlicht abstürzt und
> neustartet um den Fehler zu beheben.

> Nene, interne Angriffe sind höchst unwahrscheinlich,
LOL. Genau das ist einer der interessantesten Angriffsvektoren, weil du 
schon direkt am System bist. Auch hier wieder: Spectre, Meltdown, etc.

> eben weil nahezu alles virtualisiert ist bis auf ein Netzwerk.
Auch Netzwerk lässt sich virtualisieren. In der einfachsten Form z.B. 
mit Hilfe eines VLANs.

Und übertreib mal nicht, nicht alles was sich cool anhört ist auch 
richtig ;-)

von A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Anton M. schrieb:
> Kommmt immer Virtualisierung zum Einsatz und wenn ja welche wäre
> besonders gut dafür geeignet?

Ich kenne einerseits einen recht frischen VServer von IONOS, der als 
"echte" VM per VMware daher kommt. Und andererseits einen alten VServer 
von Strato, der per Virtuozzo teilvirtualisiert implementiert ist.

Die VMware VM enthält einen eigenen Kernel, die Virtuozzo VM jedoch 
teilt den Kernel mit allen anderen VMs auf dem Host.

: Bearbeitet durch User
von Donauwelle (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Anton M. schrieb:
> Ich kann mir irgendwie nicht vorstellen, dass Webhoster für jeden Kunden
> eine komplette eigene virtuelle Maschine laufen lassen. Weiß jemand,
> welche Techniken oder Konzepte da im Hintergrund zum Einsatz kommen?

https://dashboard.uberspace.de/tech

von georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
sid schrieb:
> der virtuelel Rechner hat keinen Zugriff auf die physischen Geräte mit
> Ausnahme der ihm zugeteilten Teile der Netzwerkkarte

Wozu? Der User muss doch nicht auf das firmeninterne Netzwerk des 
Hosters zugreifen, der würde sich das auch verbitten.

Es genügt für die üblichste Form des hostings per HTTPS oder FTP ein 
root-Verzeichnis für den Kunden zugreifbar zu machen, und der Kunde hat 
nichts anderes zu tun, als die Dateien seiner Website dorthin 
hochzuladen. Einen Zugriff auf physikalische Geräte braucht er nicht, 
nur Speicherplatz.

Eine VM braucht man dafür nicht oder wenn dann nur eine ganz kleinen 
Teil der Funktion, alles andere ist aus Sicherheitsgründen abgeschaltet. 
Ich habe von den Hostern meiner Webseiten eine URL, mit der ich auf mein 
jeweiliges root-Verzeichnis zugreifen kann, und das wars auch schon. Im 
Prinzip könnte ich auch eine VM mieten und alles selbst verwalten, 
Betriebssystem, Updates usw. aber warum sollte ich mir das antun?

Georg

von Sheeva P. (sheevaplug)


Bewertung
2 lesenswert
nicht lesenswert
Johannes O. schrieb:
> Anton M. schrieb:
>> Ich kann mir irgendwie nicht vorstellen, dass Webhoster für jeden Kunden
>> eine komplette eigene virtuelle Maschine laufen lassen.

Das kommt im Wesentlichen darauf an, was der Kunde braucht -- und 
bezahlen will. Für eine einfache statische Website ist nicht viel nötig: 
einen System- oder virtuellen User mit Zugang per FTP/SFTP/SCP sowie 
Lese- und Schreibrechten nur auf ein genau definiertes Verzeichnis, 
einen virtuellen Host im Webserver einrichten: läuft. Heute wird sowas 
oft als "Web-Visitenkarte" oä. angeboten. Derart sollen in der Frühzeit 
des Internet bei einem großen deutschen Webhoste mal mehrere Millionen 
Domains auf einer einzigen Sun Enterprise 10000 (E10k) gelaufen sein...

Dann gibt es Webhoster, die sogenannte "Website-Baukästen" anbieten: da 
kann sich der Kunde mehr oder (meist) weniger frei auf einer Website des 
Hosters eine Seite zusammenklicken und mit Inhalten füllen. Daraus 
werden dann oft statische Dateien aus den Datenbankinhalten generiert, 
und wie zuvor beschrieben serviert.

In eine ähnliche Kategorie fallen Systeme, bei denen der Kunde nur eine 
bestimmte Applikation braucht, beispielsweise ein 
Content-Management-System wie Wordpress, Magento, oder Typo3. Solche 
Systeme werden dann in einer mal mehr, mal weniger gut abgesicherten und 
isolierten Umgebung dynamisch betrieben und brauchen zum Betrieb 
natürlich eine Datenbank und eine Instanz der betreffenden Software.

Das sind die -- aus Hostersicht -- relativ einfachen Fälle, in denen der 
Kunde keinerlei Zugriff auf eine Shell hat. Oder auf irgendeine andere 
Funktionalität, welche die Software oder der Hoster nicht vorsehen.

Wenn der Kunde etwas mehr will, also zum Beispiel eigene Software oder 
besondere Erweiterungen benutzen, gibt es im Wesentlichen zwei Modelle: 
entweder "Managed Hosting", bei dem sich der Hoster je nach Umfang der 
vereinbarten Leistungen um System- und eventuell auch die Softwarepflege 
kümmert. Nicht immer, aber häufig werden schon für solche Systeme eigene 
Server* aufgesetzt.

Die nächste Stufe wäre dann etwas, das häufig als Rootserver bekannt 
ist: also ein Server, auf den der Kunde Shellzugriff und üblicherweise 
Root-Rechte hat. Natürlich muß hier ein eigener Server* her, schon um 
die Isolation gegenüber anderen Kunden des Webhosters zu gewährleisten.

(* "Eigener Server" heißt hier in der Regel: eine virtuelle Maschine mit 
einem eigenen Betriebssystem, meistens ein Linux oder *BSD.)

Für Kunden mit noch höheren Anforderungen, weil sie beispielsweise 
besonders hohe Zugriffszahlen haben, gibt es dann die dedizierten 
Server, also eine eigene, für diesen einen Kunden exklusive 
Serverhardware.

Und dann gibt es Kunden, die sogar noch höhere Anforderungen haben, etwa 
weil sie Kreditkartendaten verarbeiten (PCI-DSS), Versichertendaten für 
Health Insurer auf dem amerikanischen Markt (HIPAA) verarbeiten oder 
anderweitig in einem regulierten Umfeld arbeiten, wie (in Deutschland) 
beispielsweise Banken und Versicherungen, die den Regularien der BAFIN 
unterliegen. Die bekommen üblicherweise auch dedizierte Maschinen, 
allerdings mit zusätzlichen Schutzmechanismen: separate Käfige für den 
physikalischen Zugangsschutz, selbstverschlüsselnde Festplatten, 
meistens auch ein Zugang über eine Zwei-Faktor-Authentifizierung mit 
einem VPN.

Und dann gibt es Kunden, die ihre eigene Hardware benötigen oder haben 
wollen, aus den unterschiedlichsten Gründen: mal will einer Redis nutzen 
und braucht dafür eine Maschine mit viel Arbeitsspeicher und einer CPU 
mit wenigen, aber sehr schnellen CPU-Kernen und schnellem Speicher, mal 
will einer die CPU(s) der Grafikkarte für schnelle, hochparallelisierte 
Anwendungen nutzen, beispielsweise für das Machine Learning oder 
ähnliches Numbercrunching. Wenn Kunden eigene Hardware ins 
Hoster-Rechenzentrum schrauben (lassen), nennen Webhoster das meistens 
"Housing".

Dazu gibt es natürlich noch weitere dieser "klassischen" Modelle, etwa 
Kunden, die Hochverfügbarkeit oder Distributed Computing brauchen. Die 
können quasi dedizierte kleine Netzwerke mit virtuellen oder dedizierten 
Maschinen mieten; der Vorteil ist, daß die Maschinen physikalisch eng 
gekoppelt sind und nicht über drölfzig Switches miteinander 
kommunizieren müssen.

Und obendrein gibt's dann die -- aus klassischer Sicht -- "Exoten" aus 
dem Bereich des Cloud Computing. Häufig sind die auf den Mischbetrieb 
eigener Softwareangebote (zB. Load Balancer, Datenbank, Cache, 
Suchmaschine, Kubernetes) ausgelegt, die mit kundeneigener oder 
-spezifischer Software ergänzt werden, die meist mittels Docker und 
ähnlicher Containertechnologien gepackt und deployt wird. Amazon AWS, 
Microsoft Azure, Google Compute Cloud sind wohl die bekanntesten.

> Containerdateien verwende ich ungern, weil du dann zwei mal ein
> Filesystem dazwischen hast (einmal im Gast, einmal im Host) und das die
> Performance runter zieht. Mit Xen kannst du beispielsweise (aber nicht
> nur!) direkt auf ein logical volume schreiben.

Bitte verzeih', aber da muß ich vehement widersprechen. Du hast 
ansonsten einen hervorragenden Beitrag verfaßt, lieben Dank, aber das 
hier... sorry. Ich beschreibe das hier nur für für die verbreitetste 
Engine, Docker, aber für andere Engines wie LXC und proxmox gilt 
Ähnliches.

Ein Docker-Container benutzt zunächst im Wesentlichen ein gestapeltes 
Dateisystem, dessen untere Layer aus den Images alle(!) readonly sind. 
Auf diesen Layern liegt dann ein containerspezifischer Readwrite-Layer. 
Wenn eine der Applikation(en) in Deinem Container nun die Datei 
"klausdieser.txt" zum Lesen öffnen will, schaut der Overlay-Treiber von 
oben nach unten in die einzelnen Layer, ob die gesuchte Datei dort 
vorhanden ist. Befindet sich die Datei im obersten Containerlayer, wird 
ein Dateihandle auf den dazugehörigen Dateisystempuffer zurückgegeben; 
sonst sieht das Betriebssystem absteigend in den darunter liegenden 
readonly-Layern nach, ob die gesuchte Datei dort vorhanden ist. Wenn sie 
in einem der RO-Layer gefunden wird, gibt das Betriebssystem (je nach 
Modus für open(2)) einen Handle zurück, dessen Lesezeiger auf die 
gesuchte Datei, und dessen Schreibzeiger auf eine neue Datei im obersten 
Read-Write-Layer zeigen. Wobei das natürlich nicht ganz richtig ist; 
wenn die Datei nicht mit dem Flag O_DIRECT (man open(2)) für den 
"Direkt"zugriff geöffnet wird, läuft das natürlich alles über den 
Dateisystempuffer des Betriebssystems.

Aber das ist trotzdem noch nicht alles, denn Docker -- und andere 
Containerengines wie LXC und proxmox -- haben natürlich Storage- und 
Volume-Treiber, mit denen sie direkt auf bestimmte Storages zugreifen 
können. Der Logical Volume Manager unter Linux ist Dir sicherlich ein 
Begriff, und vielleicht hast Du auch schon von BTRFS, DRBD, ud ISCSI 
gehört. Manche Containerengines haben auch Plugins/Treiber für sehr 
moderne Storage-Backends wie GlusterFS oder Ceph.

Fazit 1: Ja, der erste Zugriff beim Öffnen einer Datei über die 
Dateisystemlayer kostet ein paar CPU-Ticks und womöglich einige 
Speicherzugriffe. Das gilt aber nur, wenn -- und nur wenn -- die Datei 
noch nicht in den Dateisystempuffer ge-mmap(2)-t worden oder mit 
O_DIRECT geöffnet worden ist.

Fazit 2: Es ist sinnvoll (und wird in der Dokumentation von Docker auch 
mehrmals wärmstens empfohlen), seine Images mit möglichst wenigen Layern 
zu erzeugen.

Fazit 3: Wer in einen Container schreibt, ist eh bekloppt. Denn wenn der 
Container (per Definition ein Wegwerfobjekt, und im Prinzip nur ein 
Image mit einem RW-Layer und eine Konfiguration für ein Image) gelöscht 
wird, sind die geschriebenen Daten unwiederbringlich hinfort.

Fazit 4: Wer mit einer Persistenzschicht arbeitet, hat ganz andere 
Probleme als ein paar Ticks für den Zugriff auf Overlays, das kennst Du 
sicher von Xen, KVM, VMWare und Virtualbox. Denn jeder Dateizugriff ist 
langsam, und zwar völlig egal, auf was für einer Hardware die Datei 
liegt -- rotierender Rost, SSDs, PCIe-SSDs und sogar NVMEs. Wenn ich 
ohnehin 200.000 CPU-Ticks plus die Latenzen vom Dateisystem selbst plus 
denen vom Dateisystempuffer plus den Latenzen der Busse plus die 
Latenzen vom darunterliegenden Hardwaregerät habe, spielt das gestackte 
Dateisystem so ziemlich überhaupt keine Rolle mehr.

von Anton M. (andman2020)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

vielen Dank für eure ausführlichen Antworten. Für ein paar Erklärungen 
muss ich noch etwas Recherche betreiben, aber im Großen und Ganzen 
verstehe ich die Antworten und habe dadurch einen guten Überblick 
bekommen.

Tausend Dank und viele Grüße
Anton

von Obermayer F. (Firma: tbd) (foikei)


Bewertung
0 lesenswert
nicht lesenswert
Sheeva P. (sheevaplug) und Johannes O. (jojo_2) - vielen Dank für den 
Inhalt. Sehr interessant...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.