Architecture Journal: Massenhosting von Hochverfügbarkeitsarchitekturen

Veröffentlicht: 18. Jun 2007

Von Shaun Hirschman, Mathew Baldwin, Tito Leverette, Michael Johnson

Skalierbarkeit und Hochverfügbarkeit sind wesentliche, jedoch miteinander konkurrierende Eigenschaften von Hosting-Infrastrukturen. Ob Sie nun ein Open Source-Ingenieur, Bezieher von kommerziellen Lösungen oder IT-Ingenieur bei Microsoft sind, es scheint keine „Patentlösung“ zu geben. Dieser Artikel konzentriert sich auf die erforderlichen Komponenten, die notwendig sind, um eine optimale Umgebung zu erzeugen, die skalierbar, zuverlässig, sicher und einfach zu warten ist – bei gleichzeitiger Bereitstellung von Hochverfügbarkeit (High Availability, HA).

Auf dieser Seite

Einführung
Die Geschichte der Hostingbranche und ihre aktuellen Probleme
Überlegungen bei der Planung von Hochverfügbarkeitsarchitekturen für das Massenhosting
Modelle der Lastverteilung
Skalieren von Microsoft IIS für das Massenhosting
Der Trend: Isolierung und Skalierung
Das Szenario des gemeinsamen Anwendungspools
Planen des Anwendungspools für die Hochverfügbarkeit
Konfigurationsreplikation
Inhaltsspeicherung
SQL-Cluster
Schlussbemerkung
Die Autoren

Einführung

Skalierbarkeit und Hochverfügbarkeit sind wesentliche, aber miteinander konkurrierende Eigenschaften von Hostinginfrastrukturen. Ob Sie nun ein Open Source-Ingenieur, Bezieher von kommerziellen Lösungen oder IT-Ingenieur bei Microsoft sind, es scheint keine „Patentlösung“ zu geben.

Bei der Untersuchung verschiedener Aspekte einer Hostinginfrastruktur lassen sich vorhandene Technologien finden, die kombiniert werden können, um die „Patentlösung“ zu erzeugen. Dieser Prozess wird auch dabei helfen, die Lücken aufzudecken, die überbrückt werden müssen. Die „ultimative“ Plattform muss eine Infrastruktur liefern, die eine dichte Anzahl an Kundenkonten berücksichtigen kann sowie skalierbar und hoch redundant ist.

Dieser Artikel konzentriert sich auf die erforderlichen Komponenten, die notwendig sind, um eine optimale Umgebung zu erzeugen, die skalierbar, zuverlässig, sicher und einfach zu warten ist – bei gleichzeitiger Bereitstellung von Hochverfügbarkeit (High Availability, HA). Einzelne Anwendungsanbieter bis hin zu räumlich verteilten Hostern mit einer hohen Hostingdichte können von einer solchen Lösung profitieren. Aber: Existiert sie? Wenn nicht, was sind die Schwierigkeiten, die uns heute hemmen, und wie nah können wir an sie herankommen?

Die Geschichte der Hostingbranche und ihre aktuellen Probleme

Um die Komplexität einer Webhostingplattform vollständig zu verstehen, müssen wir zunächst verstehen, wie der Hostingmarkt begann und wie er sich bis zu seinem aktuellen Zustand entwickelt hat. Bevor traditionelles Hosting Gestalt anzunehmen begann, waren einfache statische Websites populär und für die breite Öffentlichkeit relativ neu. Die Infrastruktur, die aufgebaut wurde, um diese Tendenz zu unterstützen, war gleichermaßen elementar und konzentrierte sich mehr darauf, so viele Kunden wie möglich anzuziehen, anstatt hochwertige Dienste, wie z. B. interaktive Anwendungen und Hochverfügbarkeit, bereitzustellen.

Beginnen wir damit, die klassische Architektur zu beschreiben, die auf Microsoft basierende Hoster in der Vergangenheit eingesetzt haben: Ein einzelner, eigenständiger Webserver mit FTP-Diensten, auf dem IIS ausgeführt wird und bei dem der Inhalt lokal auf dem Server gehostet wird. Jedes eigenständige System ist mit bestimmten Kosten verbunden: Hardware, Softwarelizenzen, Netzwerk, Strom, Rackplatz und andere Kosten. Einige Hoster haben dies sogar bis zum Extrem getrieben, indem alle Dienste auf einem einzelnen Server für x Kunden gehostet werden. Sie haben zum Beispiel Server mit Microsoft IIS, SQL, Mailserversoftware von Drittherstellern und lokalen Speicher für gehosteten Inhalt.

Von diesen Maschinen können leicht Images erstellt und schnell bereitgestellt werden, besonders wenn kostengünstige Pakete an Kunden verkauft werden sollen, die lediglich ein paar Seiten und nichts Komplexeres hosten möchten.

Während diese Art der Plattform zunahm, fingen zahlreiche Probleme an, ihre hässlichen Fratzen zu zeigen: Anforderungen an die Sicherung und Wiederherstellung, Verbrauch von teurem Platz im Datacenter, Strom pro Server, Kunden mit starker Auslastung und allgemeine Verwaltung. Zusätzlich zu den Problemen der Plattform gab es eine steigende Nachfrage der Kunden und die Fortschritte in neuer Webtechnologie. Technologien, wie z. B. PHP, Cold Fusion, ASP, JSP und ASP.NET, entstanden und lieferten komplexere Plattformen, die vom Wunsch der Verbraucher nach reichhaltigerer Funktionalität und dem Wunsch nach besseren Geschäften angetrieben wurden. Damit wurden wiederum neue Anwendungen ausgestattet, die Datenspeicher, wie SQL und andere verwandte Technologien, erforderten. Nachdem neue Anwendungen entstanden, wurde das Geschäftspotential um diese Anwendungen herum deutlich und wurde nachgefragt.

In einem Versuch, den Gewinn zu maximieren und die Verwaltung zu vereinfachen, führten die Hoster alle Dienste, die zur Unterstützung ihrer Kunden notwendig waren, weiterhin auf einem eigenständigen Server aus. Dies erzeugte eine größere Last auf einem einzelnen Server, belastete ihn und reduzierte die Anzahl der Websites, die er versorgen konnte. Die Nachfrage der Verbraucher stieg schneller an, als es die Hardwaretechnologie unterstützen konnte. Hoster mussten jetzt nach außen skalieren, indem sie Dienste über mehrere Server hinweg aufspalteten und isolierten, anstatt mit schnellerer Hardware vertikal zu skalieren.

Die Hostingbranche war weiterhin als Antwort auf die hohe Nachfrage nach webbasierten Diensten, wie z. B. dynamische Websites und E-Commerce-Einkaufswagen, mit konkurrierenden Unternehmen ausgelastet. Dieser boomende Markt zwang Hoster dazu, ihre Dienste von anderen durch Vereinbarungen nach Dienstebene (Service Level Agreements, SLAs) zu unterscheiden. Die Hoster waren nicht nur gezwungen, Dienste preiswert bereitzustellen, diese mussten auch immer verfügbar sein. Das wurde von den Verbrauchern untermauert und von der wachsenden Abhängigkeit der Unternehmen vom Web und ihrer Nachfrage nach zunehmend interaktiven, komplexen Anwendungen. Das Schaffen hochverfügbarer Dienste wird normalerweise in weitere Server übersetzt, um Redundanz sowie neue Anforderungen an Leistung, Sicherheit und Verwaltung zu unterstützen. Wie können Hoster mit der vorhandenen Software- und Hardwarearchitektur skalieren und diese Dienste unterstützen?

Angesichts dieser Branchenentwicklungen boten Softwaretechnologieunternehmen die Grundlage für diese Dienste in der Erkenntnis an, dass ihre aktuellen Betriebssysteme nicht in der Lage waren, den Bedarf der Hoster zu erfüllen. Es war immer noch ein hohes Maß an Kommunikation mit dem Systemadministrator erforderlich, um den Betrieb so reibungslos wie möglich zu gestalten. Selbständige Dienstleister und Brancheningenieure wurden sich der Lücken in den Diensten im Hinblick auf Software und Hardware bewusst und setzten ihren eigenen Schwerpunkt auf die Entwicklung von Technologien, um die Lücken zu füllen und gleichzeitig davon zu profitieren.

Zu diesem Zeitpunkt begannen die Hoster den Aufbau von Plattformen zu erwägen, die skalierbarer sind und eine höhere Dichte pro Gerät erreichen können. Sie müssen sich auch einfacher verwalten lassen. Ein guter Anfang beim Aufbau dieser Art von Architektur ist, sich die verschiedenen Dienste anzusehen, die der Hoster unterstützen und verwalten muss.

Überlegungen bei der Planung von Hochverfügbarkeitsarchitekturen für das Massenhosting

Wenn sich Hoster hinsetzen und beginnen, über die Technologien nachzudenken, die sie zusammenfassen können und wie sie eine Plattform erstellen können, um viele Websites und Dienste zu unterstützen, kommen eine Anzahl von zentralen Anforderungen in Betracht. Diese Anforderungen reichen von der Benutzer- oder Anwendungsdichte bis hin zur Art der Features und Dienste, die unterstützt werden sollen und ihre Auswirkung auf das zugrunde liegende System – ASP.NET, PHP, SQL und andere – und schließlich die Kosten pro gehosteter Site oder Anwendung. Das Hauptziel beim Entwurf einer gehosteten Plattform ist, die Skalierbarkeit, Verfügbarkeit, Dichte und Preisparität zu optimieren, während ein präzises Maß an Sicherheit so weit wie möglich beibehalten wird und die Kunden voneinander isoliert sind.

Diese Dienste lassen sich in umfangreiche Segmente zerlegen, mit den folgenden grundlegenden Architekturteilen: IIS-Cluster, SQL-Cluster, unterstützende Infrastrukturdienste, wie z. B. Active Directory-Dienste, System Center Operations Manager, zentralisierter Speicher entweder auf einem SAN (Storage Area Network) oder einem NAS (Network Attached Storage), SSL-Offloadcluster, FTP-Cluster und andere vergleichbare Cluster.

Die Aufteilung dieser Dienste in mehrere Segmente erlaubt es dem Hoster, die Architektur auf unterschiedliche Art und Weise zu skalieren. Ein Hoster könnte einen SQL-Cluster anders als einen Webcluster skalieren, durch den sich eine andere Reihe von Problemen der Architektur offenbaren kann.

Ein weiterer Faktor, der die Architektur beeinflusst, ist die Unterstützung für veraltete Anforderungen. Das beste Beispiel dafür sind die Microsoft FrontPage-Servererweiterungen (FPSE). Sie werden immer noch von Tausenden von Kunden verwendet und sind notwendig, wenn die Massenhosting-Plattform sie gewinnen möchte. Diese Erweiterungen werden normalerweise von kleinen Läden verwendet, um einfache Sites zu erstellen. Sie werden nach wie vor von Entwicklungstools, wie etwa Microsoft Visual Studio und Microsoft Visual Web Developer, für die Funktionalität zum Hochladen von HTTP-Inhalten verwendet, obwohl Microsoft von ihrem Gebrauch abrät. Veraltete Komponenten, wie z. B. FPSE, können von großen Hosts nicht einfach ohne einen Verlust der Kundenbasis entfernt werden.

Im Folgenden sollen einige dieser Cluster innerhalb der Architektur näher betrachtet werden. Das größte Stück ist der Webcluster, und das zweitgrößte ist der SQL-Cluster. Beachten Sie, dass sich Hoster von anderen Unternehmen, wie z. B. internen IT-Abteilungen, hauptsächlich durch ein Merkmal unterscheiden. Sie werden versuchen, so viele Sites oder Datenbanken auf einem Cluster wie möglich unterzubringen. Deswegen können Hoster mit bestimmten Unternehmenslösungen nichts anfangen. Abgesehen davon können Hoster nicht immer kontrollieren, welche Anwendungsarten auf einem Server platziert werden, und deshalb können sie die Kapazität nicht genau so definieren, wie es ein typisches Unternehmen kann.

Abbildung 1: Lastverteilungsmodell einer Anwendung

Modelle der Lastverteilung

Weil es mehrere Web-Front-Ends gibt, müssen die Hostingarchitekten viele Optionen für das Verteilen der Konfiguration über alle Webserver hinweg berücksichtigen. Diese Konfiguration hängt von der Art des Lastverteilungsmodells ab, das ausgewählt wird. Es gibt verschiedene Modelle für die Verteilung der Last über mehrere Web-Front-Ends hinweg. Im Folgenden werden zwei besprochen, die in Hostingszenarios verbreitet sind. Diese sind die Anwendungslastverteilung und die verbundene Lastverteilung.

Anwendungslastverteilung

Die Anwendungslastverteilung beschreibt ein Modell, bei dem die Last über mehrere Knoten von Web-Front-Ends hinweg verteilt wird und das auf der Funktion des Servers basiert. Dieses Modell basiert normalerweise auf Anfragen und beeinflusst die Routingfähigkeiten der Anwendungsschicht, was viele Lastverteiler in Netzwerken jetzt unterstützen. Durch dieses Modell können Hoster die Webfarm auf Basis der Serverauslastung aufteilen. Wer sich eine typische Implementierung dieses Modells ansieht, wird feststellen, dass Server, die dynamischen Inhalt anbieten - wie z. B. ASP.NET oder PHP - von Servern getrennt sind, die für statischen Inhalt bestimmt sind (siehe obige Abbildung 1).

Diese Konfiguration lässt sich sogar noch genauer gestalten, indem die dynamischen Server nach ihrer spezifischen Funktion aufgeteilt werden. Das bedeutet, dass kleinere Teilfarmen für jeden Anwendungstyp erstellt werden. Der gesamte ASP.NET-Datenverkehr würde zu einer ASP.NET-Teilfarm und der gesamte PHP-Inhalt würde zu einer anderen Teilfarm weitergeleitet werden. Weil Server mit dynamischem Inhalt normalerweise mehr Ressourcen benötigen, kann der Hoster durch diesen Entwurf eine andere Hardwarekategorie für diese Sites verwenden, als für die Sites, die für statischen Inhalt notwendig sind.

Die meisten Hoster müssen die Kosten beim Entwurf ihrer Plattform berücksichtigen. Deshalb könnte das Modell der Anwendungslastverteilung einfach deswegen nicht immer realisierbar sein, weil es die Anzahl der betreffenden Server erhöht. Die Anwendungslastverteilung erhöht auch die Komplexität der Serververwaltung und erzwingt ein erhebliches Vertrauen in die Ausstattung des Netzwerks.

Abbildung 2: Szenarios für 1:1-Anwendungspools

Verbundene Lastverteilung

Ein Hoster könnte sich dafür entscheiden, ein verbundenes Lastverteilungsmodell zu implementieren, um die Kosten minimal zu halten und auch die Verwaltung der Plattform weniger komplex zu gestalten. Wir verstehen unter einem verbundenen Lastverteilungsmodell ein Modell, bei dem sich alle Server genau die gleiche Konfiguration teilen. Jeder Server in der Webfarm ist auch in der Lage, sowohl statischen als auch dynamischen Inhalt zu bedienen. Beim Entwurf eines Anwendungspools für Systeme, auf denen IIS ausgeführt wird, ist es bei diesem Modelltyp äußerst wichtig, die Skalierung zu maximieren.

Skalieren von Microsoft IIS für das Massenhosting

Innerhalb eines Massenhosting-Unternehmens, das sich auf die Microsoft-Plattform konzentriert, gibt es einen ständigen Druck, die Dichte auf jedem Server in der Farm zu erhöhen. Durch eine komplexe HA-Architektur erhöht der Hoster sein Dichtemodell. Leistungsengpässe kommen jedoch immer noch vor, insbesondere bei Anwendungspools.

Beim Entwurf eines Anwendungspools für IIS ist es extrem wichtig, eine maximale Dichte zu erreichen. Wenn für die Entwurfsplanung des Anwendungspools nicht genügend Zeit eingeräumt wird, könnte dies zu unerwarteten Leistungs- und Stabilitätsproblemen führen. Bei Anwendungspools geht es tatsächlich um Isolierung, und es gibt einen direkten Zusammenhang zwischen dem gewählten Grad der Isolierung und der Anzahl der Anwendungen, die auf einem Server platziert werden können. Wenn Anwendungspools entworfen werden, müssen die Anforderungen gegenüber der Sicherheit und der gewünschten Stabilität abgewogen werden. Hoster müssen zwischen zwei Anwendungspoolszenarios wählen: einem 1:1-Szenario oder einem gemeinsamen 1:n-Anwendungspoolszenario. Beachten Sie, dass die 1:1-Anwendungspoolszenarios in Abbildung 2 dazu neigen, mehr in Richtung Isolation, aber weg von einer Skalierung zu gehen. Das verteilte Anwendungspoolszenario tendiert andererseits in Richtung eines höheren Skalierungsgrads, während es sich von der Isolierung entfernt. Hoster würden im Idealfall eine Lösung auswählen, durch die sie die Skalierung maximieren können, ohne auf Isolierung und Sicherheit zu verzichten.

Der Trend: Isolierung und Skalierung

Ein 1:1-Isolierungsszenario wird definiert durch das Vorhandensein eines Anwendungspools, der einer einzelnen Anwendung oder in einem gemeinsamen Webhostingszenario einer einzelnen Website zugewiesen wurde. Dadurch kann ein Hoster ein hohes Maß an Isolation erreichen, weil jede Website oder Anwendung innerhalb eines einzelnen Prozesses ausgeführt wird und keine Ressourcen auf dem Server mit anderen geteilt werden. Dies ist eine optimale Lösung für Hoster oder unabhängige Softwarehersteller, die einem Kunden versichern müssen, dass andere Kunden auf demselben Server keinen Zugriff auf seine wichtigen Daten haben. Dieses Szenario hat in Massenhosting-Szenarios jedoch seine Grenzen. Obwohl es das gewünschte Maß an Isolierung und Sicherheit aufgrund der Speicheranforderungen bietet, verfehlt es seinen Zweck, dem Hoster die gewünschte Skalierung zu liefern. Während jeder Anwendungspool läuft, verbraucht er Speicher und irgendwann wird ein Engpass erreicht.

Die Einführung dynamischen Codes in die Plattform fügt einen vollständig neuen Grad an Komplexität hinzu. ASP.NET-Anwendungen erhöhen zum Beispiel die Speichermenge, die für den Anwendungspool benötigt wird. Dies wird zu einem Problem für die Hoster, weil es die Anzahl dynamischer Websites begrenzt, die auf einem Server ausgeführt werden können. Sie beginnen zu erkennen, dass sie nur in Hunderte, anstatt in Tausende, von Seiten skalieren können, die der Leistungsmaßstab für die meisten Verbesserungen in der Hardwaretechnologie ist. Insbesondere bot die Einführung einer 64-Bitarchitektur vielen Hostern den Luxus, ihren Servern enorme Speichermengen hinzuzufügen. Während sie dadurch in der Lage sind, über mögliche Engpässe hinwegzugehen, könnte dies auch andere Probleme aufdecken.

Das Szenario des gemeinsamen Anwendungspools

Ein gemeinsames Anwendungspoolszenario beschreibt eine Situation, bei der sich mehr als eine Anwendung oder Website im gleichen Anwendungspool befindet. Es gibt zwei unterschiedliche Konfigurationen für gemeinsame Anwendungspools. Die erste ist Eins-zu-N, wobei der Hostinganbieter einen einzelnen Anwendungspool einer festgelegten Anzahl an Websites zuordnet. Die zweite ist eine Eins-zu-Alle-Konfiguration, wobei der Host alle Websites in einem einzigen Anwendungspool platziert. Ein gemeinsames Anwendungspoolszenario erlaubt eine bessere Skalierung, weil dadurch das System keinen Speichereinschränkungen ausgesetzt wird, die durch einen Eins-zu-Eins-Anwendungspoolentwurf auferlegt werden.

Es gibt einige Befürchtungen, dass Websites und Anwendungen in einem gemeinsamen Anwendungspool möglicherweise Zugriff auf die Daten von anderen haben könnten. Bestimmte Schutzmaßnahmen müssen ergriffen werden, um sicherzustellen, dass diese Anwendungen und Websites sicher sind. Jede Website muss zum Beispiel einen eindeutigen anonymen Benutzer haben, und eine Zugriffssteuerungsliste sollte auf die Webdateien angewendet werden. Die ASP.NET-Anwendungen sollten auch mit Codezugriffssicherheit konfiguriert und auf eine mittlere Vertrauensebene eingestellt werden. Diese Schritte tragen dazu bei, dass Anwendungen und Websites auf dem Server sicher sind, selbst in einem gemeinsamen Anwendungspool.

Da alle Anwendungen unterhalb des gleichen Prozesses ausgeführt werden, mangelt es den gemeinsamen Anwendungspools an der Isolierung, die viele Hostinganbieter verlangen. Dies kann in HA-Szenarios zu einem Problem werden, weil eine problematische Anwendung Auswirkungen auf alle anderen Websites und Anwendungen im gleichen Pool hat. Eine Anwendung könnte zum Beispiel den Anwendungspool dazu veranlassen, neu zu starten oder – im schlimmsten Fall – vollständig herunterzufahren. Es ist auch schwieriger für Systemadministratoren, ein Problem zu identifizieren, wenn es mehrere Sites und Anwendungen in einem einzelnen Pool gibt. Obwohl Tools verfügbar sind, die es Hosts erlauben, Probleme innerhalb eines Anwendungspools zu isolieren, lässt sich diese Anforderung erheblich einfacher erreichen, wenn ein 1:1-Anwendungspool für das Websitemodell verwendet wird.

Planen des Anwendungspools für die Hochverfügbarkeit

Hoster werden damit konfrontiert, einen Mittelweg zwischen dem Erhalten eines hohen Grades an Isolierung und einer Maximierung der Skalierung zu finden. Viele von ihnen sind deshalb gezwungen, eine Mischform der oben genannten Anwendungspoolszenarios zu verwenden. Ein typisches Szenario würde mehrere Anwendungspools umfassen, von denen jeder einem bestimmten Zweck dient. Websites, die nur statischen Inhalt enthalten, könnten zum Beispiel alle in einem einzigen gemeinsamen Anwendungspool platziert werden. Dies ist möglich, weil statischer Inhalt nicht mit den Sicherheits- und Leistungsproblemen in Zusammenhang steht, den es bei dynamischem Inhalt gibt. Alle anderen Anwendungspools könnten für Sites vorgesehen werden, die dynamischen Inhalt enthalten. Dadurch kann der Hoster diesen Sites größere Ressourcen zuteilen. Diese Konfiguration ist in gemeinsamen Hosting-Umgebungen verbreitet, bei der eine einzelne Plattform Kunden bedienen muss, die statischen und dynamischen Inhalt haben.

Konfigurationsreplikation

Eine andere grundlegende Anforderung für Massenhosting und HA-Umgebungen ist das Aufrechterhalten des Zustands und der Konfiguration über alle Web-Front-Ends in der Farm hinweg. Obwohl es andere Konfigurationen gibt, die auf jedem Front-End vorhanden sein müssen, ist die wichtigste die des Webservers. Einige Webserver bieten Unterstützung für einen zentralisierten Konfigurationsspeicher. Für Webserver, die dies nicht unterstützen, muss eine Softwarelösung implementiert werden, um die Konfiguration über alle Server hinweg zu replizieren.

Inhaltsspeicherung

Eines der zentralen Prinzipien einer hochgradig skalierbaren Massenhosting-Plattform, denen Architekten gegenüberstehen, ist das Festlegen des Orts, an dem der zu hostende Kundeninhalt platziert werden soll. In den meisten Fällen geht es um Inhalte, die entweder innerhalb von SQL oder auf einem Datenträger existieren. Da das Front-End der Architektur aus Clustern besteht, die Tausende von Sites enthalten können, ist es ungeeignet, den Inhalt auf integrierte, direkt angeschlossene Datenträger zu begrenzen. In den folgenden Abschnitten werden die verschiedenen Speicherarchitekturen unterteilt, die bei Hostingunternehmen gebräuchlich sind.

DAS (Direct Attached Storage)

DAS ist eine der häufigsten und klassischen Speichermethoden, die von Webhostingunternehmen verwendet werden. Es handelt sich um eigenständige Webserver, bei denen der Inhalt lokal gespeichert wird. Der primäre Vorteil dabei: Wenn ein einzelner eigenständiger Server ausfällt, geht nicht die gesamte Kundenbasis offline. Eines der Hauptprobleme ist, dass die Kundensites für jegliche Art von Hardwarefehlern anfällig sind und nicht nur für einen Fehler des Datenträgersubsystems. Diese Art der Konfiguration führt zu zusätzlichen Problemen, wie z. B. Beschränkungen der Dichte, Migrationsproblemen und fehlende Hochverfügbarkeit für die Websites und die Lastverteilung.

NAS (Network Attached Storage)

Die meisten Hosts, bei denen eine hochgradig skalierbare Plattform läuft, haben sich entschieden, NAS als ihren zentralisierten Remotespeicher für alle ihre Kunden zu verwenden. In einer hochverfügbaren Microsoft Windows-Umgebung erfolgt der Zugriff auf das NAS über CIFS (Common Internet File System), in der Regel über ein dediziertes Speichernetzwerk. Der Webinhalt der Kunden wird zentral auf dem NAS gespeichert, wobei der Pfad zum NAS mithilfe eines verteilten Dateisystems (Distributed File System, DFS) in einen logischen Pfad übersetzt wird. Die Kombination von NAS und DFS ermöglicht einem Windows-basierten Hoster, Kunden über mehrere NAS-Speichersubsysteme hinweg zu verteilen. Dadurch wird die Auswirkung eines globalen Problems für die Kunden begrenzt.

Die Optimierung von CIFS, TCP/IP und NAS spielt eine wichtige Rolle dabei, wie skalierbar das NAS bei der Anzahl der gleichzeitigen Kundensites ist, für die es Inhalte bedienen kann. Durch unzureichende Optimierung des NAS könnten Hosts Probleme einschleppen, die sich auf die gesamte Kundenbasis auswirken können. Hosts mindern dies jedoch auch, indem sie mehrere NAS-Subsysteme für unterschiedliche Kundensegmente verwenden sowie Speichernetzwerke und Schnittstellen für diese Art des Datenverkehrs festlegen.

Viele NAS-Subsysteme besitzen die Spiegelungs- und Snapshotfähigkeit. Diese Technologien werden von Hostern wirksam eingesetzt, um einen stabilen Prozess für Notfälle und eine Wiederherstellung zu erhalten – wenn insbesondere berücksichtigt wird, dass im Speichersystem Zehntausende von Kundeninhalten vorhanden sein können.

Da Technologien wie z. B. SQL keinen Remotespeicher für ihre Datenbanken über CIFS unterstützen, ist dies ein Problem bei einem reinen NAS-Speichersubsystem. Dadurch werden die Hoster in der Art der Dienste eingeschränkt, die sie anbieten können.

SAN (Storage Area Network)

Viele Speichersysteme von Unternehmen sind in der Lage, als SAN und als NAS zu operieren, wobei der wichtigste Unterschied die Methode ist, mit der sie angeschlossen werden. Im Falle eines SAN sind die grundsätzlichen Methoden Fiber Channel (FC) und iSCSI.

Hostingunternehmen sind in der Lage, hochverfügbare und skalierbare SQL- und E-Mail-Systeme aufzubauen, wie etwa Microsoft Exchange, indem für diese Arten von Clustern die Fähigkeiten eines SAN als zentralisierter Speicher verwendet werden. Je fortschrittlicher das SAN, desto mehr Möglichkeiten hat das Hostingunternehmen, um solche Aufgaben wie Snapshot- und Wiederherstellungsverwaltung innerhalb von SQL oder Exchange durchzuführen.

Einer der Hauptkritikpunkte eines unternehmensweiten Speichersystems sind die anfallenden Kosten. Hosts sind vorsichtig genug, um sicherzustellen, dass das Produkt, das sie einsetzen möchten, eine genügend hohe Rendite (ROI) besitzt, um die Kosten eines SAN zu rechtfertigen.

SQL-Cluster

SQL ist ein zentraler Dienst, den viele Hosts der Mehrzahl ihrer Kunden anbieten. Dies ist jedoch auch einer der Schlüsselbereiche, den viele Hosts nicht als Cluster implementieren. Dafür gibt es verschiedene Gründe, wobei die wichtigsten Gründe Kosten und Lizenzierung sind. Die Hosts, die tatsächlich mit einem hochverfügbaren SQL-Cluster arbeiten, müssen ihre Architektur jedoch so entwerfen, dass sie dabei die richtige Art der Cluster-Methodologie auswählen, durch die eine Vielzahl an Datenbanken unterstützt werden kann.

Im Gegensatz zu anderen Unternehmen, bei denen der SQL-Cluster aus einer relativ kleinen Anzahl an Datenbanken besteht, setzen Hostingfirmen Hunderte, wenn nicht gar Tausende von Datenbanken in einem einzelnen Datenbankcluster ein. Dieser Cluster muss sowohl in der Leistung als auch in der Betriebszeit robust sein. Hosting-Unternehmen haben keine Kontrolle darüber, wie die Kunden ihre Anwendungen schreiben. Deshalb bringt es einige sehr spezielle Probleme mit sich, wenn ein Cluster für das Massenhosting entworfen wird. In einer Hostingumgebung hat jeder Kunde 1–N Datenbanken, die ihm zugewiesen wurden. Diese Datenbanken können auf einem einzelnen Cluster gespeichert oder über mehrere Cluster verteilt werden. Der häufigste Cluster, den ein Hoster für Massen-SQL-Hosting aufbauen würde, ist der standardmäßige Aktiv-Passiv-SQL-Cluster. Während sich jedoch Hosts das Hosting von Software als Dienst (software-as-a-service, SaaS) erschlossen, wandelten sich die Anforderungen an einen SQL-Cluster von der Knotenredundanz hin zur Datenredundanz. Dies führte zu weiteren Problemen, weil dieselben Systeme immer noch zahlreiche Datenbanken hosten.

Es gibt keine wirklich gute und kosteneffektive Möglichkeit, eine skalierbare, hochverfügbare und dichte SQL-Clusterplattform zu erstellen. Jede Clustertopologie hat ihre Nachteile, die mit der Tatsache kombiniert ist, dass die Hosts keine Kontrolle über den Entwurf einer Kundenanwendung haben. Der ideale SQL-Cluster würde Hosts ermöglichen, eine Lastverteilung zusammen mit einer Datenbankspiegelung durchzuführen, ohne mit den Problemen von Transaktionskonflikten umgehen zu müssen, wobei eine sehr dichte Anzahl von Datenbanken über den Cluster hinweg beibehalten wird.

Schlussbemerkung

Dienstanbieter müssen sich fortlaufend der Herausforderung anpassen, die steigende Kundenachfrage nach neuen Diensten zu erfüllen, die einen größeren Vorteil für kleine und mittelgroße Unternehmen, Entwickler, Kunden und Designer bieten. Sie müssen umfangreiche Dienste bereitstellen, um die Loyalität der Kunden zu erhalten und um ihre Geschäftsziele zu erreichen. Dienstanbieter suchen nach Möglichkeiten, die Erwartungen für eine „ultimative“ Webplattform zu erfüllen, die dabei hilft, die Gesamtbetriebskosten (Total Cost of Ownership, TCO) zu verringern und effektiv und effizient Kundenzufriedenheit zu erzeugen.

Wenn auf eine Webplattformlösung verwiesen wird, die Web Services, Datenspeicherung und Datenbankspeicher einschließt, tritt innerhalb einer dieser Komponenten unvermeidlich ein Engpass auf. Eine Lösung ist nur so stark wie ihr schwächstes Glied. Grundsätzlich muss sich jede Komponente einer Lösung mit effizienter Redundanz und Rentabilität nach außen und nach oben skalieren lassen.

Dieser Artikel handelt nicht davon, welche Technologien (Open Source oder Closed Source) die Lücke füllen können oder es in einigen Bereichen bereits getan haben, sondern stattdessen von den zugrunde liegenden Architekturproblemen, die sich nicht „im Bewusstsein“ befinden, wenn Technologien entwickelt werden. Heutzutage reicht es nicht aus, Technologie um der Technologie willen in dem Versuch zu erzeugen, eine Nische auszufüllen. Nur durch Strategie, Planung und Entwicklung umfangreicher Lösungen werden wir in der Lage sein, umfangreiche Anforderungen zu unterstützen. Die Welt wächst, der Bedarf steigt, und es ist nur logisch, wenn die Infrastrukturen auch wachsen.

Die Autoren

Shaun Hirschman hat über acht Jahre im Hostingbereich gearbeitet und ist mit den entsprechenden geschäftlichen und technischen Herausforderungen besonders vertraut. Bevor er 2006 zu Microsoft stieß, begann er in der Hostingbranche im technischen Support und stieg zu einer Position als leitender Windows-Systemadministrator auf. Shaun Hirschman besitzt beträchtliches technisches Wissen und Erfahrung mit auf Microsoft basierenden Systemen. Er genießt es vor allem, mit topaktuellen Software- und Hardwaretechnologien zu spielen und dadurch seinen Wissensdurst zu stillen.

Mathew Baldwin arbeitete in den letzten 10 Jahren im Bereich der gehosteten Dienste. In der Vergangenheit hatte er Rollen als Architekt, leitender Systemingenieur und regulärer Troubleshooter inne und war bei mehreren Unternehmen, die Hostingdienste anbieten, als Berater für auf Microsoft basierende Plattformen tätig. Er war maßgeblich daran beteiligt, die erste hochverfügbare, geclusterte Windows 2003-Plattform mit freigegebenem Hosting auf den Markt zu bringen, und arbeitete eng mit Microsoft in verschiedenen Initiativen zusammen. Er arbeitet momentan als leitender Architekt für Affinity Internet.

Tito Leverette arbeitete über acht Jahre im Hostingbereich. Er begann seine Karriere bei Interland, Inc. (heute Web.com). Bevor Tito Leverette zu Microsoft kam, war er Architekt im Web-Plattformteam von SunTrust, Inc., der neuntgrößten Bank in den USA. Er hat viele Jahre Erfahrung im Entwerfen, Erstellen und Bereitstellen von Webinfrastrukturen für große Unternehmen sowie im Hosting von Kunden. Er ist Absolvent des Georgia Institute of Technology (Georgia Tech).

Michael Johnson verbrachte mehr als sieben Jahre als Angestellter im Bereich der Webdienstanbieter, wo er hochgradig skalierbare Anwendungen und Lösungen auf Basis von Microsoft-Produkten entwickelt und geplant hat. Er arbeitet momentan als ein Webarchitekt für Microsoft.