Die Schnelligkeit einer Website, sprich die Ladezeit beim Aufruf von Seiten und bei verschiedenen Klicks hängt natürlich nicht nur von der darunterliegenden Performance (RAM, CPU, Speicher). Techniken wie Caching, Datenkompression, Minifying beispielsweise haben einen großen Einfluss auf die Ladezeit, die Ressourcennutzung und somit auf die Anzahl Nutzer die gleichzeitig die Website besuchen können. Da diese Techniken mehr oder minder von der Hosting-Infrastruktur unabhängig sind, vergleichen wir hier nur die Hostingtypen.

Traditionell besteht das Shared Hosting nur aus einem Webserver (oft old school Apache) und es werden möglichst viele Websites darauf betrieben. Die Websites teilen sich die Ressourcen. Es ist zwar möglich die maximale RAM Nutzung zu bestimmen aber eine Garantie den RAM auch nutzen zu können gibt es nicht - die anderen Websites sind gleichberechtigte Partner und alle versuchen, sich die Ressourcen zu nehmen, die sie brauchen und maximal nutzen dürfen.

Solche Plattformen sind für anspruchsvolle Setups mit vielen Besuchern/Nutzern nicht wirklich geeignet.

Für anspruchsvollere WordPress Websites kann man auch eine eigene virtuelle Maschine (VM) nutzen, die mit keinen anderen Websites geteilt wird. So stehen die Ressourcen wirklich dediziert für die WordPress Instanz zur Verfügung. Entsprechend wird eine leistungsstarke VM  für viele Fälle in denen es darauf ankommt, viele HTTP Anfragen zu bearbeiten, die passende Lösung sein.

Verfügbarkeit ist nicht nur ein Marketing-Wert. Mit einer professionellen Infrastruktur (in einem zertifizierten Datacenter) mit nachweislichen Maßnahmen zur Vermeidung von Ausfällen wie z. B. Redundanz von Netzwerkverbindungen, Servern und RAID-Systemen lässt sich die Verfügbarkeit durchaus verlässlich interpretieren. Außerdem werden in solchen Fällen meist auch Service Level Agreements vereinbart, die nicht vorgesehene Incidents regeln.

Wenn ein Webserver, die Datenbank und die Daten allesamt auf einem (virtuellen) Server laufen, hat man ein tendenziell performantes Setup. Wenn aber die darunterliegende Hardware kaputt geht, geht gar nichts mehr. Dann muss ein Backup auf einem neuen Server eingespielt werden (und die IP muss ggf. zum neuen umgeroutet werden).

Damit ein physikalischer Ausfall nicht gleich alle Dienste (Webserver, Datenbankserver, Daten) trifft und einen Totalausfall mit sich bringt, kann man die Dienste getrennt von einander betreiben.

Sie können Daten auf einem NAS ablegen, das auf einer anderen Hardware liegt. Wenn also die VM ausfällt, kann eine neue aufgesetzt werden, die Daten müssen aber nicht erst kopiert werden, die Datenpartition wird einfach (z. B. per NFS) eingebunden. Dasselbe kann mit dem Datenbank-Server gemacht werden.

So haben wir 3 Server für unsere WordPress Anwendung. Das klingt zunächst nicht schlecht, aber so toll ist es auch nicht, denn ein einzelner Server-Ausfall wird nicht abgefangen. Fällt die Datenbank aus oder die Datenpartition, ist die WordPress Website down. Es wird also geboten, für Redundanz der einzelnen Komponenten zu sorgen.

Im SaaS Web Hosting Portfolio gab es bislang entweder Private Cloud Shared Hosting oder Private Cloud single VM Hosting. Damit lassen sich Websites mit vielen Besuchern, großem Ressourcen Verbrauch und hoher Verfügbarkeit nicht ganz so gut abbilden. Das Public Cloud Multi Server Setup ist nun die Antwort auf solche Anforderungen. Es lässt sich übrigens auch in der SaaS Web Private Cloud einrichten...

Parallel laufende Webserver

Der Webserver wird redundant betrieben: es laufen parallel zwei oder mehr Server (mit Nginx). Sie greifen alle auf dieselbe NFS Datenpartition zu.

Cloud NAS

Die Cloud NAS ist ein redundantes NFS Server-System, das sich ein Festplatten-Pool (RAID) teilt, sodass ein einzelner NFS-Server Ausfall abgefangen werden kann.

Galera Cluster

Die Datenbank Server werden als Galera Cluster (mindestens 3 Server) zusammengeschaltet. Selbst wenn 2 Server ausfallen geht der Anwendung das Licht nicht aus. Das Cluster wird als Reverse Proxy (localhost) zu der WordPress Installation eingebunden - so muss WordPress nicht selbst entscheiden, welchen Server für die DB Verbindung benötigt wird.

Master/Slave Load Balancer

Damit die Webserver parallel betrieben werden können, benötigt das Setup einen Load Balancer, der die eingehenden HTTP-Anfragen an die Webserver verteilt. Um einen Load Balancer Ausfall zu verkraften, bekommt dieser auch einen Zwillingsbruder.

Failover IP

Mit der Failover IP kann die öffentliche IP (die mit der Website Domain matcht) dynamisch zwischen den Load Balancer wechseln. Das geschieht automatisch: wenn der Slave Load Balancer merkt, dass der Master ausgefallen ist, beantragt er die Zuweisung der IP.

Hier geht es zu den SaaS Web Managed WordPress Hosting Angeboten.