Hier stelle ich unterschiedliche Hosting Szenarien vor, die für den Einsatz von High Performance Drupal Projekte eingesetzt werden können.

1 Server - V1

Umsetzung mit einem Reverse Proxy (z.B. Varnish)

  • Webserver Server
  • Datenbank Server
  • Solr Server
  • Memcache Server
  • Reverse Proxy
  • File Storage
  • Opcode Cache

Zusammenfassung

Kosten: sehr gering Horizontale Skalierung aller Instanzen: Nein Redundanz aller Instanzen: Nein

Falls Amazon EC2 zum Einsatz kommt, kann das vorkonfigurierte AMI Mercury dazu eingesetzt werden.

1 Server - V2

Umsetzung mit Drupal Boost Modul

  • Webserver Server
  • Datenbank Server
  • Solr Server
  • Memcache Server
  • File Storage
  • Opcode Cache

Zusammenfassung

Kosten: sehr gering Horizontale Skalierung aller Instanzen: Nein Redundanz aller Instanzen: Nein

2 Server - Webserver-Varnish / DB

1x Webserver-Varnish

1x Datenbank Server

Zusammenfassung

Kosten: gering Horizontale Skalierung aller Instanzen: Nein Redundanz aller Instanzen: Nein

3 Server - 2x Webserver-Varnish / DB

3 Server - Webserver-Varnish / 2xDB

4 Server - 2x Webserver-Varnish / 2x DB

Bei diesen Szenario werden jeweils 2 Nodes für den Webserver und die Datenbank eingesetzt. Die Webserver sind identisch aufgebaut und greifen auf den gleichen File Storage zurück (z.B. NFS, ClusterFS, u.s.w., SAN). Für die zweit Datenbankserver wird Replikation eingesetzt: 1 Datenbank Master und ein Datenbank Slave.

2x Webserver-Varnish Server

  • Webserver Apache
  • Reverse Proxy Varnish

Es ist ein Load Balancer erforderlich, der die Requests an den beiden Nodes verteilt. Reicht die Leistung der beiden Nodes nicht aus, kann einfach ein weiterer Node hinzugeschaltet werden, indem ein Clone eines bestehenden Nodes erstellt wird (nur die Netzwerkkonfiguration muss auf dem Clone angepasst werden)

1x MySQL Master (SPOF)

Der Master führt alle Schreibzugriffe auf die Datenbank aus. Sofern ein Projekt zum Einsatz kommt, welches sehr wenige Schreibzugriffe erzeugt, kann der Master auch Lesezugriffe übernehmen.

SPOF. Single Point of Failure - Fällt diese Komponente aus, ist das Projekt nicht mehr lauffähig.

1x MySQL Slave

Ein MySQL Slave führt nur Lesezugriffe auf die Datenbank aus - ohne Ausnahme! Ein weiterer MySQL Slave kann einfach hinzugefügt werden, sofern die Leistung für Lesezugriffe nicht durch einen Slave erbracht werden kann.

ab 12 Server

  • 2 DB Master
  • 2 oder mehr DB Slave
  • 2 oder mehr Webserver
  • 2 oder mehr Varnish
  • 2 oder mehr Solr
  • 2 oder mehr CDN Server (oder Einbindung eines externen CDN Netzwerkes)
  • 2 oder mehr File Storage
  • 2 oder mehr Gearman (asynchrone Jobs z.B. über Drush, Drupal Cron)

Zusammenfassung

Kosten: sehr hoch Horizontale Skalierung aller Instanzen: ja Redundanz aller Instanzen: ja

Aktualisiert: