Sitecore ist ein verbreitetes Customer Experience Management System. Wie man es sicher und hochverfügbar betreibt, zeigt Hosting Experte Markus Häfeli vom Zürcher Hoster aspectra in diesem Blog Beitrag.
Die Sitecore Umgebung umfasst folgende Komponenten: Zwei IIS Instanzen mit .Net Framework für Sitecore Author und Sitecore Delivery. Eine SQL Server-Datenbank für die Benutzerdaten und eine noSQL Datenbank (z.B. MongoDB) für die flüchtigen Session-Daten. Diese vier Komponenten werden beim Hosting auf separaten Servern betrieben und je nach Bedürfnis mit zusätzlichen High Availability-Systemen (HA) ergänzt.
Soll eine Sitecore Umgebung bei einem externen Hoster betrieben werden, empfiehlt es sich, auch die System Integrationstest- (SIT) und User Acceptance Test (UAT)-Umgebung am gleichen Ort aufzubauen. Das schafft eine Vergleichbarkeit mit der Produktion und garantiert die hohe Verfügbarkeit auch bei den Test-Umgebungen.
Sicherheit
Grundvoraussetzung eines sicheren Betriebs von Sitecore ist eine vorgeschaltete Web Application Firewall (WAF). Das heisst nicht, dass Sitecore ein speziell unsicheres CMS ist, die WAF dient aber zur Unterstützung. Sie übernimmt neben dem Schutz der Applikation vor bösen Zugriffen aus dem Web auch die Aufgaben der Authentifizierung und der Lastverteilung.
Die Authentisierung erfolgt in unserem Beispiel gegen einen externen Identity Provider (IDP). Der Benutzer erhält dort nach erfolgter Authentisierung ein SAML Token, welches die WAF prüft. Zur anschliessenden Autorisierung bei Sitecore wird ein JSON Web Token (JWT) verwendet.
Die Funktion Loadbalancing kommt zum Zuge, wenn die Delivery-Server redundant ausgelegt wurden. Sie dient nicht nur zur Verteilung der Last auf mehrere Systeme, sondern trägt auch zur Ausfallsicherheit und zur Wartbarkeit der Systeme bei. Ein einzelner Server kann zur Wartung aus dem Verbund entfernt werden, ohne Unterbruch der Applikation.
Eine weitere Voraussetzung für den sicheren Betrieb ist eine strikte Trennung der Netzwerkzonen. So befinden sich die Webserver von SIT, UAT und Produktion in jeweils getrennten DMZ. Diese DMZs werden wiederum aufgeteilt in je eine Zone für Author und Delivery. Die Datenbanksysteme werden ebenfalls in separaten privaten Zonen ohne Verbindungen zum Internet platziert. Die Mongo DB-Server für kurzlebige Session-Daten können in der DMZ platziert werden, da dort nur webservernahe Daten abgelegt sind. Sie könnten aber durchaus auch in der privaten Zone betrieben werden, was dann bei den Firewall-Regeln zu berücksichtigen wäre. Auf der MongoDB ist die Authentifizierung bei der Datenbankverbindung unbedingt einzuschalten, um hier ein offenes Scheunentor zu schliessen.
Verfügbarkeit
Es empfieht sich wie bereits erwähnt, die Sitecore Delivery-Server redundant auszulegen, also auf zwei oder mehr Server zu verteilen. Dabei ist auch eine Geo-Redundanz in Betracht zu ziehen. Die Delivery-Server laufen dann an unterschiedlichen RZ-Standorten.
Die Verfügbarkeit der Mongo DB lässt sich durch ein Replica Set erhöhen. Dieses besteht aus einer ungeraden Anzahl Mongo DB Installationen, wobei eine davon die Arbiter Funktion übernimmt. HA beim SQLServer lässt sich am einfachsten durch ein Log Shipping-Setup mit zwei Servern realisieren (Active / Standby).
Nun muss man sich entscheiden, inwieweit die Redundanz auch auf der UAT ausgelegt werden soll. Dafür spricht, dass die Architektur der UAT-Umgebung sich so weit wie möglich an der produktiven Umgebung orientiert, damit auch die HA-Mechanismen in der UAT funktionieren. Es lassen sich darauf auch aussagekräftige Performancetests durchführen. Andererseits werden für die UAT-Umgebung Ressourcen und Lizenzen reserviert, welche die meiste Zeit brach liegen. Hier muss also der goldene Mittelweg gefunden werden.
Es kommt ganz schön etwas an Windows Servern zusammen durch Trennen der Funktionen, Erzeugen von Redundanz und Nachbau der produktiven Umgebung für SIT und UAT. Je nachdem wie konsequent man dies ausgelegt hat, sind es gegen 20 Server. Die virtuellen Systeme werden auf mindestens zwei physische ESX-Hosts verteilt, wobei die redundanten Systeme auf unterschiedlichen Hosts laufen sollen.
Neben den Standard Windows Server-Monitorings inkl. Datenbank und Webserver, soll das Funktionieren von Sitecore selbst überwacht werden. Aussagekräftig sind dabei sogenannte Health Checks auf der Website. Solche Funktionen sollen vom Entwickler in der Applikation zur Verfügung gestellt werden und im Idealfall auch die Verbindung zur Datenbank prüfen. Das Monitoring ruft diese Health Checks von ausserhalb über HTTP regelmässig auf, prüft die Antwort und alarmiert im Fehlerfall.
Eine Systemarchitektur für Sitecore umfasst schnell 20 Server. Das scheint auf den ersten Blick viel, ist aber nötig, um einem gehobenen Anspruch an Sicherheit und Verfügbarkeit gerecht zu werden.
Lesen Sie mehr über Sitecore und Customer Experience Management:
