Im ersten der Teil dieser Serie sind wir der Frage nachgegangen, was onpremise bereitgestellt werden muss, um die Verfügbarkeit von E-Maildiensten wie in Exchange Online (99,9%) sicherzustellen und für jedes Postfach 50 GB oder 100 GB wie in Exchange Online bereitzustellen. Wir kamen zu dem Schluss, dass eine onpremise Installation vom Kostenvolumen für KMUs deutlich im Nachteil gegen über Exchange Online ist, wenn sie in diesem Punkten mithalten soll.
Wir sind dabei davon ausgegangen, dass insgesamt vier Exchange Server in zwei Datacentern bereitgestellt werden müssten, um auch bei einem Standortausfall die Verfügbarkeit zu sichern. Für ein Unternehmen mit 150 Postfächern sind wir bei einem garantierten Speicherplatz von 50 GB bei fast 10 TB Plattenplatz pro Exchange Server gelandet, bei 1.500 Postfächer bei fast 100 TB pro Exchange Server.
Betrachten wir die Sache einmal anders. Wenn wir annehmen, dass die Ausfallsicherheit damit erreicht ist, dass alle Wartungsarbeiten für die Benutzer ohne Ausfall durchgeführt werden können und ein Standortausfall bei unseren Überlegungen keine Rolle im Hinblick auf die Verfügbarkeit der E-Maildienste spielt, dann kann die onpremise Implementierung schon von der Zahl der Server und den Anforderungen an die übrige Infrastruktur deutlich smarter ausfallen und damit kostengünstiger werden.
Mit zwei Exchange Servern, die in einer Database Availalibity Group die Postfächer redundant speichern, erreichen wir, dass es keine wartungsbedingten und geplanten Ausfälle mehr gibt, sehen wir von Wartungsarbeiten ab, die die gesamte Infrastruktur des Standortes betreffen. Auch ungeplante Ausfälle sind in dieser Konfiguration selten und meistens auf Fehler in der Konfiguration und im Monitoring zurückzuführen – z.B. durch volllaufende Festplatten, weil ein längerer Ausfall des Backups nicht wahrgenommen wurde.
Betrachten wir den benötigten Plattenplatz. Muss man wirklich jedem Benutzer 50 oder 100 GB garantieren? In zahlreichen Projekten haben wir an Hand einer Einteilung der Postfächer nach Größenklassen und – wo wir die Daten zur Verfügung hatten – an Hand von monatlichen Zuwachsraten für die Datenbanken differenzierte Anforderungen ermitteln können.
In einem Projekt stellte sich bei zirka 1.300 Benutzern heraus, dass nur 10% der Postfächer über 15 GB Speicherplatz konsumierten, 80% weniger 500 MB belegten. Selbst wenn wir diese Postfächer mit 2 GB in unsere Berechnungen mit einbeziehen, kommen wir zu einen deutlich geringeren Speicherplatzbedarf, als wenn auch für diese sparsamen Verbraucher 50 GB in Rechnung gestellt werden:
| Anzahl Postfächer | Benötigtes Speicherplatzkontingent in GB | Bedarf in GB |
| 1040 | 2 | 2.080 |
| 130 | 15 | 1.300 |
| 130 | 20 | 2.600 |
| Summe | 6.680 | |
| Zuschlag für Aufbewahrung gelöschter Objekt, Index | 1.989 | |
| Gesamt | 8.619 | |
| Bedarf bei 50 GB / Postfach | 84 TB |
Selbst wenn wir großzügiger aufschlagen, werden 10 TB je Server also 20 TB für beide Server ausreichen.
In einem anderen Fall hatten wir die Daten, um die Zuwachsraten über 3 Monate im Rückblick ermitteln zu können. Dabei konnten wir die ursprüngliche Absicht des Kunden, jedem Benutzer 30 GB Postfachspeicher zu garantieren gegenrechnen. Die Ausgangslage waren 3 TB belegter Speicherplatz durch die Exchange Datenbanken bei 1.400 Postfächern. Nur wenige Postfächer belegten mehr als 20 GB. Die gewünschten 30 GB hätten fast 55 TB pro Server erfordert. Selbst wenn sich der für Postfächer benötigte Speicherplatz in 3 Jahren vervierfachen würde, sind 12 TB pro Server ausreichend. Die zurückliegenden Zuwachsraten waren konstant etwa 25% pro Jahr. Eine Fortschreibung hat nach 3 Jahren einen Speicherplatzbedarf von rund 6 TB pro Server ergeben, nach 5 Jahre dann 9,5 – 10 TB.
Was wir sehen ist: Mit realistischeren und bescheideneren Annahmen was die Verfügbarkeit der Dienste und die Ressourcenbereitgestellung betrifft, sinken die Investitionskosten deutlich, auch wenn beide Server in zwei Bandabschnitten untergebracht werden. Die Betriebskosten sind deutlich geringer, als im Entwurf der ersten Folge.
Nach wie vor man kann mit Exchange eine kostengünstige onpremise Implementierung erstellen, die ausreichende Verfügbarkeit und ausreichend Ressourcen zur Verfügung stellt.
Wir setzen fort.
