Hallo @ll,
wir betreiben für einen unserer Kunden eine Exchange Umgebung mit 3.700 Benutzerpostfächern mit einer DAG, als VMs unter VSphere. Einer der Exchange Server wird als reiner Backupserver verwendet, d.h. dort liegen alle DBs als passive Kopie und dieser wird aktuell mit VEEAM gesichert (HotAdd mit Veeam Proxy VM). Nun zur eigentlichen Frage/Problem.
Während der Backupzeiten und vor allem beim auflösen/löschen des Snapshots meldet unser Monitoring in letzter Zeit öfters, dass dieser Server nicht verfügbar ist. Ein Login über die VMWare Konsole ist dann auch nicht möglich, die VM scheint eingefroren zu sein und ist erst nach einiger Zeit wieder verwendbar. Wir vermuten, dass die IOs der lokalen Platten nicht ausreichend sind um den Snapshot aufzulösen und gleichzeitig die Exchange LOGs zu überprüfen und auf Platte in die Datenbanken zu schreiben. Weiterhin ist dann die 8 Core CPU völlig am Anschlag, weshalb die Physik dann wahrscheinlich keine Ressourcen mehr hat und deshalb die VM nicht reagiert.
Noch ein bisschen was zum Systemaufbau. Alle DAG Member sind physikalisch gleich aufgebaut - 1 CPU mit 8 Cores, 92GB RAM, 2 x SSD für OS + Programme, 6 x 6TB SAS 7.2k HDDs für DBs + LOGs. Die produktiven VMs sind mit 6 vCPUs + 64GB RAM konfiguriert, die VM von der das Backup gemacht wird hat 8 vCPUs + 64GB RAM. Für die VMs die produktiv für die Clients zur Verfügung stehen reicht das aktuell auch aus. Als Techniker sage ich in der aktuellen Situation, dass der Backupserver hardwaretechnisch aufgerüstet bzw. ausgetauscht werden muss. Also mehr CPU-Leistung und mehr und schnellere Platten, bestenfalls sogar SSDs. Da das aber Geld kostet, ist das zwar einfach gesagt aber... Naja, Ihr kennt das ja sicherlich ;-).
Was meint Ihr?
Danke schon mal vorab und LG
André
Hallo André,
ich fürchte ganz so einfach lässt sich das Problem nicht lokalisieren. Kannst du ein paar mehr Informationen zu der Umgebung liefern? Ich hab es so verstanden, dass alle Exchange Server virtuell laufen, liegen die VMs denn auch alle auf dem gleichen Storage (6 x 6 TB)? Oder hat jeder der Exchange Server seine eigenen Disks?
Erfahrungsgemäß ist hier oft das Storage der Flaschenhals, von daher würde ich vielleicht gezielt einmal die IO Queues während und nach dem Backup, also wenn der Snapshot aufgelöst wird, im Auge behalten. Auch die Latenz in Richtung Storage könnte Aufschluss über eine mögliche Überlastung geben. Laufen vielleicht auch weitere Backup Jobs parallel? Wenn ich es richtig verstanden habe, ist ja die Anmeldung an der Exchange VM nicht möglich, das würde ja erst einmal nicht dafür sprechen, dass der Backup Server mehr Leistung benötigt. Oder habe ich hier etwas falsch verstanden?
Gruß,
Frank
Hallo Frank,
sorry, vielleicht hab ich mich nicht ganz korrekt ausgedrückt. Zur Umgebung noch ein paar mehr Infos:
Jede Exchange VM läuft auf einem eigenen physikalischen Host, mit jeweils 6x6TB Festplatten für DBs/LOGs (RAID5). Auf 3 der physikalischen Hosts laufen noch weitere VMs, auf 2 Stück jeweils 1 DC mit 2 vCPUs/4GB RAM, auf dem Backupserver 1 VM als VEEAM Proxy für HotAdd mit 4 vCPUs/12GB RAM. Es handelt sich bei den Platten SAS Platten mit 7200rpm. Wir gehen davon aus, dass jede Platte so ca. 150 IOPS liefert, x 6 Stück ergibt also ca. 900 IOPS.
Als Backupserver bezeichne ich 1 der Exchange Server aus der DAG, der von allen Datenbanken passive Kopien hält. An diesem kann ich mich dann nicht anmelden, während der Snapshot aufgelöst wird. Diesen sichern wir regelmäßig. Mit dem VEEAM Backupserver bzw. mit den Repository Servern haben wir keine Probleme.
Die Latenzen auf dem Exchange Server der gesichert wird sind zu den Backupzeiten "unterirdisch", also ziemlich hoch. Hab jetzt aktuell keine Daten zur Hand, kann ich aber nachliefern. Gerade läuft kein Backup.
Viele Grüße
André
Hallo André,
Danke für die Infos. Anhand deiner Infos würde ich hier tatsächlich auf Überlastung des Storage tippen, bin mir da sogar sehr sicher. Bei einem RAID5 mit 6 x 7200 rpm Disks kannst du nicht einfach 6 x 150 IOPS rechnen. Hier gibt es einen Rechner der dir einen Anhaltspunkt gibt, welchen IO Durchsatz du ungefähr erwarten kannst:
https://wintelguy.com/raidperf.pl
Bei angenommen 150 IOs per Disk landet man bei einem RAID5 gerade einmal bei 360 IOPS. Der reale IO Wert der Disk wird sich vermutlich eher zwischen 60 - 70 IOPS bewegen (Alles auf einem RAID5 (DB + Logs), Lesezeit und Positionierungsdauer erhöht sich). Nehmen wir daher mal gute 80 IOPs pro Disk an, dass macht bei einem RAID5 192 IOPS. Eine Exchange 2016 Mailbox braucht je nach Message Profil ca. 0,07 IOPS, macht bei 3700 Mailboxen: 259 IOPS. Das Storage wird also den regulären Betrieb noch schaffen, dürfte sich aber schon am oberen Ende der Leistungsfähigkeit bewegen.
Kritisch wird es dann während und nach dem Backup: Während des Backups erhöht sich ja die Leserate und die damit angeforderten IOs ganz erheblich (Normalbetrieb + Backup). Nach dem Backup wird es sogar noch kritischer, denn der VMware Snapshot muss aufgelöst werden, sprich alle Änderungen aus dem Snapshot müssen in das VMDK geschrieben werden, zusätzlich wird Exchange versuchen seine Logs zu löschen, wenn das Backup erfolgreich war.
Wenn hier also eine Überlastung vorliegt müsstest du das anhand der Storage Queue und anhand der Latenz in Richtung Storage auf dem ESX Server sehen können. Du kannst dafür beispielsweise das Tool "esxtop" verwenden.
Ich würde daher behaupten mit einem RAID5 aus 6 Disks ist da kein Blumentopf zu gewinnen.
Gruß,
Frank
Hey Frank,
vielen Dank für Deine ausführliche Antwort. Den Link zum RAID Rechner werde ich mir auf jeden Fall gut aufheben ? . Ich werde das nochmal verifizieren bzw. lief aktuell ein Backup, daher habe ich jetzt aktuelle Werte.
Wir haben Lese-Latenzen während dem Backup zwischen 50ms und 100ms, beim Snapshot löschen Spitzenwerte von bis zu 222ms. Die Schreib-Latenzen sind in Ordnung, vermutlich hilft hier aber der Cache des RAID Controllers. Außerdem sieht man während der Löschung des Snapshots, dass die Exchange Copy/ReplayQueueLength nach oben geht. Heute gab es ein extremes Beispiel, da gleichzeitig auch noch ein Restore einer kompletten Mailbox gelaufen ist. Ein paar Screenshots habe ich angehängt.
Latenz während dem Backup:
Latenz beim Snapshot löschen:
QueueLength:
Das es mehr "Wummmms" für den Backupserver braucht, scheint klar zu sein.
Die Frage die sich mir/uns natürlich stellt, sind wir mit unserem Konzept was Backup angeht überhaupt noch richtig unterwegs, bei dieser Größe. Oder sollten wir lieber auf andere Mittel setzen, z.B. NativeDataProtection mit mehreren zeitversetzten Kopien? Das ist unsere größte Umgebung, ansonsten haben wir Firmen mit maximal ca. 1.000 Postfächern. Da läuft das mit VEEAM prima, ohne großartige Schwierigkeiten.
Viele Grüße
André
Hallo André,
deine Screenshots zeigen ziemlich deutlich, dass das Storage völlig überlastet ist. Ein RAID5 für den Backup Server ist natürlich ungünstig, vielleicht könnte man dies in ein JBOD umwandeln, dann geht zumindest nicht mehr ganz so viel Performance für das Raid drauf. Wenn eine Platte im Backup Server ausfällt, ist das ja nicht unbedingt kritisch. Wenn die Kiste halt mal nen Tag offline ist, Reseed der Datenbank und gut ist.
Zeitversetzte Kopien anstatt eines Backups mittels Veeam (oder welche Software auch immer eingesetzt wird), finde ich eher nicht so toll. Zeitversetzte Kopien machen meiner Meinung nach Sinn um möglichst schnell eine defekte Datenbank wieder online zu bekommen. Die Wiederherstellung eines bestimmten Postfachs oder sogar Elements aus einem Postfach zu einem bestimmten Zeitpunkt ist da aber eher gar nicht bzw. nur sehr eingeschränkt möglich.
Generell würde ich behaupten, dass du durchaus auch größere Umgebungen mittels Veeam und Snapshots sichern kannst, das Storage muss nur in der Lage sein, diese Anforderungen auch zu bedienen. Je nach Konzept könnte man vielleicht auch drüber nachdenken, die Datenbanken mittels Veeam Agent (ohne VMware Snapshot) direkt auf den beiden produktiven Exchange Servern zu sichern (natürlich zeitversetzt). Ist halt eine Frage des Konzepts...
Gruß,
Frank
Hallo Frank,
nochmal vielen Dank für Deine Unterstützung. Mit Deinem enormen Fachwissen in Deinen Artikeln hast Du mir schon mehr als einmal weitergeholfen. ?
Da ich bisher noch nicht mit zeitversetzten Kopien gearbeitet habe, habe ich auch überhaupt keine Erfahrungswerte. Was die Wiederherstellung von einzelnen Elementen angeht, ist das bei VEEAM natürlich schon sehr elegant gelöst, geht schnell und ist zudem auch noch "idiotensicher" in der Handhabung. Das es mit Exchange Bordmitteln nicht so einfach ist, musste ich zuletzt 2011 leidlich erfahren. Seitdem bin ich schon etwas "verwöhnt". Wir werden uns auf jeden Fall etwas für den Backupserver überlegen (müssen), das umwandeln in ein JBOD wird uns denke ich nicht dauerhaft helfen.
Merci und viele Grüße aus Underfrangn ?
André
Hallo André,
hier noch eine gute Übersicht für Backupüberlegungen im produktiven Umfeld. Auch von einem Frank, aber von einem anderen :). Ich hoff, es ist ok, wenn ich direkt verlinke.
https://www.msxfaq.de/exchange/admin/backupextrem.htm
Es gibt in diesem Umfeld sehr viele Optionen und noch mehr Möglichkeiten, diese umzusetzen. Für dich als Admin ist es elementar, das die Leute nach einem Ausfall (weiter)arbeiten können. Da hilft es schon manchmal, einfach einen weiteren Server mit einer passiven Kopie, ggf an einem anderen Ort (anderes RZ) mitlaufen zu haben. Standardmässig würden diese DB Kopien nie aktiv gehen, aber in einem Disasterfall ja. Dann hast du die Option, Backups zu recovern und den Usern nachträglich die fehlenden Elemente wieder in die Datenbanken zu schieben. Ich habe bisher bei noch keinem Kunden eine DAG ab Exchange 2010 so kaputt gesehen, dass man sie nicht wieder über eine weitere Kopie der jeweiligen DAG auf healthy bekommen hat. Das ist ggf auch pures Glück, aber was ich sagen will ist, dass das Konstrukt der Database Availability Group ansich schon sehr robust und "fehlertolerant" ist. :) (im Vergleich zu CCR und LCR davor)
Gruß,
Monthy
Hey Monthy,
danke auch für Deine Infos. Zur DAG und zum Backupkonzept hatten wir uns 2017 schon lange Gedanken gemacht. Damals stand die Migration von einem anderen Mailsystem zu MS Exchange an, mit einer vom Kunden angegeben Datenmenge von ca. 10TB. Als wir das Altsystem zum ersten mal gesehen haben, waren es dann schon fast 20TB und inzwischen sind wir bei fast 30TB. Die Server laufen gerade mal seit Mitte 2018 produktiv. Damit kann doch keiner rechnen, also mit so einem rasanten "Wachstum"!
Ich weiß was Ihr jetzt sagen werdet, warum verwendet Ihr kein Archiv? Das gibt es schon, ist aber ein anderes Thema um das es in diesem Thread nicht geht ?. Wir werden jetzt in Kürze erstmal eine CPU mit mehr Cores einbauen, zum Test. Wenn das schon Besserung in Bezug auf die Erreichbarkeit der VM bringt, dann werden wir eine 2. CPU vom selben Typ einbauen wie die aktuell verbaute.
Mehr Platten werden sowieso benötigt, da die vorhandenen spätestens Ende 2020 voll sein werden. Wahrscheinlich werden nochmal 6 HDDs in den Server eingebaut und in einem externen Shelf weitere 12 HDDs. Sind dann also gesamt 24 HDDs. Ein RAID wird es auf jeden Fall bleiben, über den RAID level diskutieren wir aktuell noch (5 oder 1+0). Eine Überlegung war noch, ob wir die Datenbanken und LOGs auf separate RAIDs legen sollen. Also 18 Spindeln für die Datenbanken und 6 Spindeln für die LOGs. Was meint Ihr dazu?
Danke Euch allen und viele Grüße
André
Puh, ordentliche Datenmengen sind das. Ganz grob über den Daumen im Schnitt ca 6 GB pro User?
Ich stell mal ketzerisch die Frage, ob nicht ein ordentlicher Schwung von Usern in die Cloud könnte? Dann haste die und deren Postfächer sowie das Backup diesbezüglich aus dem Sinn.
Auch die Frage, ob man nicht die Exchange Archivierung nutzen könnte, wenn es eure Lizenz erlaubt. Hier würde ich den Vorteil sehen, dass man auch dann das Archivpostfach in die Cloud schieben kann und das Produktive bleibt onPrem. ne sinnvolle Retentionpolicy drauf und schwupps ist ein Großteil der Daten ausgelagert. Damit sollte man die OnPrem Daten auch um einiges nach unten korrigieren können, für die ihr verantwortlich seid.
Gruß,
Monthy
Hallo Monthy,
die Cloud sind wir in diesem Fall für unseren Kunden. Eine öffentliche Cloud ist keine Option. Wie geschrieben haben wir schon eine Archivierung implementiert, bei der die Archivierungsregeln allerdings alles andere als hilfreich für die Datenmenge in den Exchange Postfächern sind. Das soll aber nicht Thema dieser Diskussion sein.
Ihr habt mir beide schon sehr viel geholfen, von daher denke ich kann dieser Thread auch abgeschlossen werden. Wenn das in Franks Forum so gedacht ist.
Viele Grüße und nochmal vielen herzlichen Dank!
André