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
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.
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.
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?
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.
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.
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.
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!
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.
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 ;-)
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
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
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
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.
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
Sheeva P. (sheevaplug) und Johannes O. (jojo_2) - vielen Dank für den Inhalt. Sehr interessant...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.