Exchange 2019 Bevorzugte Architektur (Preferred Architecture)

Microsoft hat Details zur bevorzugten Architektur für Exchange 2019 veröffentlicht. Dabei handelt es um eine ganze Reihe von Best Practises für eine Exchange 2019 Umgebung.

Der Artikel findet sich hier:

Hier folgt noch eine kleine Zusammenfassung der wichtigsten Punkte und ein paar kleine Anmerkungen meinerseits.

Namespaces

Die Best Practise sieht 4 DNS Namen für eine Exchange 2019 Umgebung vor. Die Namen grenzen die Protokolle von einander ab:

  • Autodiscover: autodiscover.contoso.com
  • HTTP Clients: mail.domain.de
  • IMAP Clients: imap.domain.de
  • SMTP Clients: smtp.domain.de

Alle DNS-Namen müssen auf dem Zertifikat vorhanden sein. In diesem Fall müsste das Zertifikat also 4 DNS-Namen enthalten. Wenn IMAP nicht genutzt wird und ein vorgeschalteter SPAM-Filter eingesetzt wird, entfallen die Namen für IMAP und SMTP, somit muss das Zertifikat nur 2 DNS-Namen enthalten (mail.domain.de und autodiscover.domain.de).

Hier ein Beispiel der empfohlenen Architektur mit zwei Rechenzentren und einer DAG:

Exchange 2019 Bevorzugte Architektur (Preferred Architecture)

Quelle: Exchange 2019 preferred architecture

Die DAG wird in diesem Fall über 2 RZs gespannt. In jedem RZ gibt es einen Loadbalancer der die Last auf die lokalen Exchange Server verteilt. Die Clients werden in diesem Fall via DNS Round Robin oder GeoDNS auf die jeweilgen RZs verteilt.

Natürlich lässt sich Exchange 2019 auch weiterhin in nur einem Rechenzentrum betreiben, auch ohne DAG und Loadbalancer.

Server Hardware

Virtualisierung wird unterstützt, allerdings empfiehlt Microsoft Exchange 2019 mit dem Betriebssystem direkt auf der Hardware zu installieren. Wenn eine DAG mit mehreren Servern über mehrere Rechenzentren eingesetzt wird, macht es auch wenig Sinn eine Virtualisierungsschicht einzusetzen, in diesem Fall gibt kaum noch einen Mehrwert. Einzelne Server lassen sich aber nach wie vor auf Hyper-V oder VMware betreiben.

Die Hardware Empfehlung lautet wie folgt:

  • 2HE Server mit Platz für 12 oder mehr Laufwerke
  • 2 Prozessoren mit bis zu 48 CPU Kernen
  • Bis zu 256 GB RAM (128 GB RAM Minimum. Ja, auch weniger funktioniert, aber es wird halt nicht empfohlen)
  • RAID-Controller mit Schreibcache (BBU, battery-backed write cache)
  • Der RAID-Controller muss den gleichzeitigen Betrieb von HDDs und SSDs unterstützen

Storage

Die Best Practise sieht ein RAID1 für Betriebssystem, Exchange Installation, Logfiles (nicht Datenbanklogs) und Transportdatenbank vor. Für die Datenbanken und Transaktionsprotokolle wird ein JBOD aus SAS-HDDs mit 7200rpm empfohlen.

Wenn das neue Feature MCDB (Metacache Database) eingesetzt werden soll, müssen zusätzlich SSDs in den Servern verbaut werden. Hier gelten die folgenden Empfehlungen:

  • je 3 HDDs sollte 1 SSD verbaut werden (Standard SAS SSDs, Mixed Used)
  • 5-10% der Kapazität der HDDs sollten als SSD-Kapazität vorhanden sein
  • Kein RAID für die SSDs erforderlich (dienen nur als “Read-Cache”)

Die folgende Abbildung zeigt eine entsprechende HDD/SSD Konfiguration:

  • 2 HDDs für das Betriebssystem und Exchange 2019
  • 12 HDDs für Exchange Datenbanken und Logs
  • 1 HDD als DAG AutoReseed Spare Disk
  • 4 SSDs für die Metacache Database

Exchange 2019 Bevorzugte Architektur (Preferred Architecture)

Quelle: Exchange 2019 preferred architecture

Filesystem

Nach wie vor wird NTFS für das Betriebssystem und die Exchange Installation eingesetzt. Für die Datenbanken und MCDB wird ReFS empfohlen (mit abgeschaltetem Integrity Feature).

DAG

Für die DAG wird eine einzelne Netzwerkkarte empfohlen (Kein Teaming). Je nach Design wird eine dritte Seite für das DAG-Witness benötigt. Wenn nur zwei Rechenzentren vorhanden sind, kann nun das Witness auch in Azure abgelegt werden. Alternativ lässt sich weiterhin ein lokales Witness nutzen, in diesem Fall sollten Witness und PAM im gleichen Rechenzentrum liegen.

Anmerkung / Meinung

Microsoft platziert Exchange 2019 als reines Enterprise Produkt. Nach wie vor ist es aber möglich Exchange 2019 auch in kleineren Umgebungen zu betreiben, Dazu wird allerdings ein Volume License Vertrag mit Microsoft benötigt. Der Weg ist hier aber schon recht klar vorgezeichnet: Cloud.

Die Zeiten als Exchange noch mit einem SBS Server mitgeliefert wurde, sind vorbei und kommen auch nicht wieder. Gerade die SBS Kunden können aber von Office 365 profitieren. Anstatt einen verstaubten Server im Abstellraum zu betreiben, können diese Office 365 nutzen und damit sogar mehr Dienste als nur Exchange nutzen. Klar, ganz ohne lokalen Server wird es bei vielen kleinen Kunden nicht gehen, vorprogrammiert ist aber: Kein lokaler Exchange Server für kleine mittlere Unternehmen. Vielleicht werden dann ja wieder mehr Domino Server installiert :-)

6 Kommentare zu “Exchange 2019 Bevorzugte Architektur (Preferred Architecture)”

  1. Hallo Frank,

    will MS tatäsächlich zurück zur Hardware und weg von VM?! Wieso DAS den?! Wir planen für 2019 ein Upgrade auf Exchange 2019 mit VM-HA, möchte mir aber ungern zwei HW-Server reinstellen müssen. Immerhin wird es ja „noch“ unterstützt- wie du /MS schreibst…. bin gespannt und verfolge das Thema weiter….

  2. Hat schon jemand Erfahrungen mit Exchange 2019 on-premise in kleinen Netzen? Ich bin bei einem IT-Dienstleister tätig, unsere konservativ geprägte Kundschaft ist gegenüber Cloud aktuell noch mehr als verschlossen, auch wenn wir das natürlich bereits im Portfolio haben. Wie verhält sich ein 2019er denn, wenn man ihm nur 4 Kerne und 18 – 24GB RAM gibt? Ich vermute mal, dass er ja nicht viel anders sein wird als ein 2016er mit weiteren Features, oder?

    1. Ich betreibe einen Exchange 2019 seit kurzen in einem kleinen Netzwerk.
      Es hat 10 Postfächer mit einer Grösse zwischen 100 MB und 1.5 GB.
      Dazu einen PublicFolder mit knapp 20GB.
      Heruntergeladen werden bei mir die Mails mit einem POP3 Downloader (leider habe ich keine fixe IP) und der Versand erfolgt über einen SmartHost.

      Das absolute minimum für den ExchangeServer sehe ich bei 10GB RAM. Mit 12GB läuft er schon recht anständig und belegt stabil etwa 80% des Speichers. Der virtuellen Maschine sind 4 Cores (Xeon E3) zugewiesen, welche bis 85% ausgelastet sind.

      Ich hoffe das hilft Dir weiter.

  3. Was ich recht komisch finde, ist das man für die Datenbanken ein JBOD nehmen soll und in der Abbildung der Platten noch eine Spare Platte drinnen ist.
    Das ist doch bei JBOD absolut überflüssig, da ja JBOD keine Redundanz anbietet wo die Spare Platte sinnvoll wäre.
    Ist für mich irgendwie nicht logisch das ganze.

    1. Hallo Sebastian,
      Die Spare Disk ist keine Spare Disk für den RAID Controller, sondern für den Exchange Server. Fällt eine Disk aus kann Exchange die Spare Disk online schalkten und ein AutoReseed der Datenbanken durchführen die auf der defekten Disk lagen. Das Feature nennt sich DAG AutoReseed und wurde bereits mit Exchange 2013 eingeführt (wenn ich mich richtig erinnere).
      Gruß,
      Frank

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.