Grosse Sitecore Solutions in wartbare Module herunterbrechen

In diesem Artikel möchten wir (Matthias Gmür und Mark Lowe) ein Thema beleuchten, welches uns in den letzten Jahren bei einigen unserer Kunden beschäftigt hat: Die Architektur von grossen Sitecore Solutions.

(mehr …)

Software Design mit Sitecore

6ServiceSchema

Helmut Balzert beschreibt den Begriff Software Architektur als „eine strukturierte oder hierarchische Anordnung der Systemkomponenten sowie Beschreibung ihrer Beziehungen“. Unabhängig davon welche Definition des Begriffes man nehmen möchte, im Normfall handelt es von einer Summe teilbarer Einheiten, welche in irgend einer … Weiterlesen

Sitecore 8 – Architekturanforderungen

Mit der Einführung der Sitecore Experience Database (xDB) ab Sitecore Version 7.5 wurde das Sammeln von Analyticsdaten grundlegend verändert. Eine neue Datenbank, Collection Database genannt, wird dazu verwendet, die Informationen über Besucher und Besucherinteraktionen zu sammeln und zu speichern. Die … Weiterlesen

Sitecore & Azure

Wie bringt man Sitecore auf Microsofts Azure Cloud Services?

Ein Weg um Sitecore in die Cloud zu stellen, ist der direkte Weg über das manuelle Einrichten von Sitecore Instanzen via Cloudservices oder virtuellen Servern, die Azure einem anbietet. Um aber wirklich auf Wolke 7 zu schweben, hat sich Sitecore ein Modul ausgedacht: Sitecore Azure!

Sitecore Azure
Das Sitecore Azure Modul lässt sich einfach vom Sitecore Development Network (SDN) herunterladen. Zusammen mit einer 27 Seiten starken Dokumentation zum Installieren und Konfigurieren der Anwendung.

Ausgangspunkt ist eine lauffähige Sitecore Instanz des Projekts. Auf diese Sitecore Instanz wird über den „Installation Wizard“ von Sitecore das „Sitecore Azure“ Modul installiert. Also ganz so, wie man es sich von Sitecore gewohnt ist!

Tipp: Es lohnt sich die Einschränkungen und Anforderungen vorher gründliche durchzulesen.

Mit dem Tool installieren sich eine Menge Items und Files in Sitecore. Für den Sitecore Benutzer ersichtlich ist danach aber lediglich ein neuer Eintrag in der Programmstartliste.

Mit der Installation wurde aus der Sitecore Instanz ein „Deployment Center“. Das Deployment Center ist nun der Dreh- und Angelpunkt des Geschehens, egal welche Sitecore-Azure-Architektur (Azure Delivery/Azure Live Mode/Azure Authoring + Delivery) Sie nun einsetzen.

Hinweis: Bei der Azure Delivery Architektur dient das Deployment Center auch als Editing Instanz. Bei den anderen nur als Deployment Center.

Delivery Architektur

Ist das Modul installiert, ein Zertifikat generiert und ein „Environment“-File bezogen (Sitecore) steht Ihnen die ganze Welt offen. Dies zeigt sich anhand einer Weltkarte  mit einer Auswahl an möglichen Standorten. Die Standorte entsprechen den physischen Azure Datacentern, auf welche Sitecore nun eingespielt werden kannn.
Mit wenigen Klicks fährt eine Content Editing (CE) Farm oder Content Delivery (CD) Farm Instanz hoch, frei skalierbar.

CE und CD Instanzen einfach Verwalten.

Ein Blick in die Azure Administrationsseite lohnt sich! Mit jeder erstellten Farm werden nämlich SQL Azure Datenbanken oder Cloudservices eingerichtet. Die Namen sind zwar sehr gewöhnungsbedürftig, dafür logisch aufgebaut. Es hilft zu verstehen was Sitecore genau macht. Die Dokumentation liefert hier nämlich kaum aussagekräftige Informationen. Ein Blick auf die anfallenden Gebühren ist sowieso ratsam.

Stolpersteine
Mit dem einen oder anderen Stolperstein ist dann aber doch zu rechnen.
Leider ist nur wenig davon dokumentiert, was und wie Sitecore die Dinge genau macht.
Einige Stolpersteine vorweg:

  • Der „Data“-Folder Pfad in der Sitecore Konfiguration darf nicht relativ angegeben werden.
  • Der „Data“-Folder darf nicht im Sitecore Webverzeichnis liegen.
  • Die Sitecore Konfigurationen dürfen nicht in separate Dateien ausgelagert werden. Alles in Web.config.

Hat man erst einmal den Dreh raus, funktioniert Sitecore Azure einwandfrei. Und merkt man wie einfach die Skalierung dann von der Hand geht, ist man restlos überzeugt.

 

Sitecore Architektur-Varianten

Nach der Entscheidung, ein neues  Content Management System einzuführen, stellt sich früher oder später die Frage, welche Netzwerk-Architektur Verwendung finden soll. Die Entscheidungsgrundlage für die Auswahl der Architektur-Variante ist insbesondere:

  • die Anforderung an die Verfügbarkeit des Systems
  • die Anforderung an die Laststabilität des Systems
  • die Anforderung an die Sicherheit des Systems
  • die bereits bestehende Infrastruktur
  • das zur Verfügung stehende Budget

Nachfolgend werden mögliche Sitecore Netzwerk-Architekturen für verschiedene Internet Szenarien vorgestellt und deren Vorteile und Nachteile kurz beleuchtet.

Eine Sitecore Netzwerk-Architektur besteht aus mehreren Komponenten: dem sogenannten Content Management Server (nachfolgend CM genannt), der primär für die Erfassung von Content für die Autoren dient und dem Content Delivery Server (nachfolgend CD genannt), der als sogenannter Front-End Server fungiert. Weiterhin erforderlich ist ein SQL Server, der den Content sowie die Konfigurationseinstellungen beinhaltet. Der SQL-Server enthält dafür drei Sitecore Datenbanken: Master, Web und Core. Der Content wird in der Master-Datenbank verwaltet und im Rahmen des Veröffentlichungsprozesses auf die Web-Datenbank transferiert. Die Core-Datenbank beinhaltet die Sitecore Einstellungen sowie die Security Informationen von Sitecore.

Stand-Alone-Architektur

Hierbei übernimmt ein einzelner Server sowohl die Funktion des CM als auch des CD.

Vorteile dieser Architektur:

  • Einfache Installation und Administration
  • Keine Load-Balancer Konfiguration notwendig
  • Schnelle Inbetriebnahme möglich

Nachteile dieser Architektur:

  • Aus Gründen der Performance sollte CM und CD nicht zusammen auf einem Server installiert werden. Denn sobald die Autoren ihre erstellten Seiten veröffentlichen, wird der Server für einen kurzen Moment ausgelastet. Dies könnte die Performance des Internet Auftritts beeinträchtigen.
  • Sollte der Server ausfallen, ist die Erreichbarkeit des Internet-Auftritts nicht mehr gewährleistet.
  • Beim Veröffentlichen von Seiten durch die Autoren wird zudem der Cache geleert, dies bedingt eine längere Ladezeit der Webseiten beim erstmaligen Aufruf nach der Veröffentlichung.

Netzwerk-Architektur mit separatem CM und CD

Diese Architekturvariante sieht jeweils einen separaten Server für CM und CD vor:

Vorteile dieser Architektur:

  • Autoren greifen auf einen dedizierten CM Server zu und belasten somit nicht den CD Server. Der Veröffentlichungsprozess beeinträchtigt die Performance der Website nicht.
  • Der Cache wird durch den Veröffentlichungsprozess nur inkrementell geleert. Damit bleiben kurze Ladezeiten für den übrigen Internet-Auftritt gewährleistet.
  • Bei einem Ausfall des CM kann der CD kurzzeitig die Aufgaben des CM übernehmen. Der Internet-Auftritt bleibt also weiterhin kontrollierbar. Allerdings gelten die Einschränkungen eines Stand-Alone-Systems.

Nachteile dieser Architektur:

  • Bei einem Ausfall des CD ist der Internet-Auftritt für Besucher nicht mehr erreichbar.

Netzwerk-Architektur  mit einer durch eine Firewall getrennten CM und CD Umgebung

Bei dieser System-Architektur liegt das Augenmerk auf der Sicherheit des Systems. Dazu werden die CD und die CM Server durch eine Firewall getrennt. Der CD und der SQL-Server (Database1) befinden sich in der DMZ und der CM und der SQL-Server (Database2) im LAN.

Vorteile dieser Architektur:

  • Der CM ist nicht von aussen zugänglich und wird durch eine Firewall geschützt.
  • Der CD verfügt über einen eigenen SQL-Server. Dies dient der Optimierung der Performance.
  • Bei einem Ausfall des CM kann der CD kurzzeitig die Aufgaben des CM übernehmen. Der Internet-Auftritt bleibt also weiterhin kontrollierbar. Allerdings gelten die Einschränkungen eines Stand-Alone-Systems.

Nachteile dieser Architektur:

  • Bei Ausfall des CD können die Benutzer auch hier nicht auf den Internet Auftritt zugreifen.

Architektur mit zwei CD und Load-Balancing (Hochverfügbarkeit)

Diese Sitecore Architektur gewährleistet sowohl eine hohe Verfügbarkeit als auch eine hohe Sicherheit. Dabei befinden sich zwei CD Server mit Load-Balancer sowie der SQL-Server (Database 1) in der DMZ. CM-Server und SQL-Server (Database 2) befinden sich im LAN.

Vorteile dieser Architektur:

  • Der CM ist von aussen nicht zugänglich und wird durch eine Firewall geschützt.
  • Der CD verfügt über einen eigenen SQL-Server. Dies dient der Optimierung der Performance.
  • Die beiden CD gewährleisten eine hohe Verfügbarkeit, da bei dem Ausfall eines CD der andere noch von aussen erreichbar bleibt und somit die Verfügbarkeit des Internet-Auftritts weiterhin gewährleistet.
  • Bei einem Ausfall des CM kann einer der CD kurzzeitig die Aufgaben des CM übernehmen. Der Internet-Auftritt bleibt also weiterhin kontrollierbar.

Nachteile dieser Architektur:

  • Variante erfordert mehr Aufwand für die Konfiguration.
  • Diese Lösung stellt umfangreichere Hardware-Anforderungen als die vorgenannten Varianten.

Fazit und Empfehlung

Nachdem nun mehrere mögliche Sitecore Architekturen mitsamt ihren Vor- und Nachteilen vorgestellt wurden, wird deutlich, dass das Aussprechen einer generellen Empfehlung nicht sehr sinnvoll ist. Vielmehr hängt die Auswahl der geeigneten Architektur-Variante sehr stark von den individuellen Anforderungen an das System und der verfügbaren Infrastruktur ab. Allerdings kann festgehalten werden, dass zum einen der gemeinsame Betrieb von CM und CD auf einem Server aufgrund der hohen Lastspitzen im Veröffentlichungsprozess nicht empfehlenswert ist und zum anderen der Einsatz von einem CM-Server und mehreren CD-Servern mit Load-Balancing eine nahezu beliebige Skalierbarkeit und Performance sowie eine enorme Flexibilität des Systems ermöglichen.