none
Exchange 2013 Storage Sizing bei MultiRole Server als VM RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo,

    bei unserem Exchange 2013 MultiRole Server, welcher als VM auf einem 2016er Hyper-V Failover Cluster läuft, sollen neue Datenbanken mit neuen Speichergrenzwerten angelegt werden.

    Nun bin ich mir mit der Erstellung der VHDX Dateien für die jeweiligen Datenbanken nicht ganz sicher. Ist es besser, immer für die Log Dateien und die Datenbank (+Index) ein separates Volume anzulegen - also bei 3 Datenbanken 6 Volumes?

    Auf dem Storage liegt dann doch alles nur auf dem selben großen LUN (12x 7.2k HDD's RAID6).

    Die drei Datenbanken sollen in mit unterschiedlichen Postfachgrenzwerten (0,5GB; 2GB; 3GB) angelegt werden.

    Darin befinden sich dann ca. 500 Mailboxen (100, 360, 40).

    Weiterhin bin ich mir bei der Bestimmung der Größen der 6 Volumes nicht ganz sicher.

    Lt. Exchange Sizing Tool und eigenen Berechnungen, kommt da schon einiges an Speicher zusammen (ca. 2,6TB bei 100 Tagen Deleted Items Retention, Average Mail Size 300kB, 50 Average Messages / Day über alle Profile).

    Habe ich mich da verrechnet oder muss ich die Volumes wirklich so groß dimensionieren? Lt. der ganz simplen Speicherplatzberechnung Anzahl Postfächer * Speichergrenzwert kommt man ja nur auf sehr blauäugige 890GB.

    Dass es mehr wird, ist mir klar. Aber das Verhältnis 890GB zu 2,6TB ist schon recht groß (gut, ich habe mit den 2,6TB gut gerechnet, pro Postfach +15%).

    Vielen Dank schon einmal vorab & Gruß,

    Karl-Heinz



    • Bearbeitet Mr. Fuchs Donnerstag, 19. Juli 2018 12:30 Gramatik
    Donnerstag, 19. Juli 2018 12:28
    |

Antworten

  • Question
    Anmelden
    0
    Anmelden

    Moin,

    der Role Requirements Calculator liefert in den seltensten Fällen Empfehlungen, die man 1:1 in das wirkliche Leben übernehmen kann. Das sind eher Anhaltspunkte zum Nachdenken.

    Eine Aufteilung der Volumes bei einer VM mit nur einem SAN-Volume ist nur dann wirklich sinnvoll, wenn Du

    a. nicht nur virtuelle Festplatten, sondern auch virtuelle SCSI-Controller aufsplittest, vielleicht nicht gleich 6 Stück, aber mindestens 2 oder 3.

    b. mehrere Pfade vom Hypervisor zum Storage hast, wovon mehr als einer gleichzeitig aktiv ist.

    c. Du auch eine I/O-Last erwartest, die das rechtfertigt.

    Ich würde bei Deinen Eckdaten DB und Logs nicht trennen, sondern eher ein Volume pro (DB+Logs) machen.

    Deleted Items Retention kommt auf das Quota drauf, daher ist Quota*Anzahl < Verbrauch dieses Profils. Bei 100 Tagen kommst Du bei dem kleinsten Profil auf 143 GB Umschlag, was vorgehalten werden muss, mehr also als die 50 GB Quota.

    Wichtig ist auch zu berücksichtigen, dass Backup ausfallen kann und Du somit neben dem Overhead durch Retention auch noch Logs für X Tage vorhalten musst, bevor Du sie wieder abgeschnitten bekommst. Da ist der Mailzuwachs mal 1,20 oder so zu nehmen. Wenn ich von 21 Tagen Ausfall ausgehe, komme ich bei Deinen Zahlen auf 230 GB, 1365 GB und 192 GB, also ca. 1787 GB für alle drei.

    Das ist aber eine pessimistische Schätzung.

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Donnerstag, 19. Juli 2018 18:31
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin,

    ich bin ein großer Fan davon, Quotas direkt an Postfächer zu vergeben. Es wird immer Ausnahmen geben, und auf diese Weise musst Du nicht prüfen, ob das Quota geerbt oder angepasst wurde.

    Und wenn man das dann macht, ist es gerade sehr schön, wenn große und kleine Mailboxen gemischt sind, denn große Mailboxen produzieren erfahrungsgemäß auch mehr Traffic. Auf die gleichmäßige Verteilung muss der 1st level Support nur bedingt achten, denn Exchange provisioniert ja je nach Auslastung, wenn man gar keine DB angibt.

    In Deinem Beispiel würde ich mit 3-4 Datenbanken einsteigen, mehr ist ganz bestimmt nicht erforderlich. Ich habe in einer öffentlichen Verwaltung 2.300 User in zwei Datenbanken (iSCSI aus der VM heraus), und es gibt I/O-mäßig keine Probleme.

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.


    Freitag, 20. Juli 2018 13:30
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Moin,

    der Role Requirements Calculator liefert in den seltensten Fällen Empfehlungen, die man 1:1 in das wirkliche Leben übernehmen kann. Das sind eher Anhaltspunkte zum Nachdenken.

    Eine Aufteilung der Volumes bei einer VM mit nur einem SAN-Volume ist nur dann wirklich sinnvoll, wenn Du

    a. nicht nur virtuelle Festplatten, sondern auch virtuelle SCSI-Controller aufsplittest, vielleicht nicht gleich 6 Stück, aber mindestens 2 oder 3.

    b. mehrere Pfade vom Hypervisor zum Storage hast, wovon mehr als einer gleichzeitig aktiv ist.

    c. Du auch eine I/O-Last erwartest, die das rechtfertigt.

    Ich würde bei Deinen Eckdaten DB und Logs nicht trennen, sondern eher ein Volume pro (DB+Logs) machen.

    Deleted Items Retention kommt auf das Quota drauf, daher ist Quota*Anzahl < Verbrauch dieses Profils. Bei 100 Tagen kommst Du bei dem kleinsten Profil auf 143 GB Umschlag, was vorgehalten werden muss, mehr also als die 50 GB Quota.

    Wichtig ist auch zu berücksichtigen, dass Backup ausfallen kann und Du somit neben dem Overhead durch Retention auch noch Logs für X Tage vorhalten musst, bevor Du sie wieder abgeschnitten bekommst. Da ist der Mailzuwachs mal 1,20 oder so zu nehmen. Wenn ich von 21 Tagen Ausfall ausgehe, komme ich bei Deinen Zahlen auf 230 GB, 1365 GB und 192 GB, also ca. 1787 GB für alle drei.

    Das ist aber eine pessimistische Schätzung.

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Donnerstag, 19. Juli 2018 18:31
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Evgenij,

    vielen Dank für deine ausführlichen Antworten. Bin bzgl. der VM Last auch der Meinung, dass das bei dem o.g. Szenario nicht allzu viel bringen wird, bzw. wahrscheinlich nur Schönheitscharacter hat und die Performance nur marginal beeinträchtig.

    Wollte von Beginn an nur 3 Volumes erstellen, dann hat mich der Sizing Calcuator doch noch ins grübeln gebracht.

    Auch die Größe der Volumes werde ich eher in deiner empfohlenen Größe anlegen und sicherheitshalber den Exchange besser monitoren. Dann bekomme ich frühzeitig mit, falls doch etwas aus dem Rahmen laufen sollte und kann nachbessern.

    Zwei Fragen hätte ich aber noch:

    Reichen in meinem Szenario die 3 Stück Exchange Datenbanken oder sollte ich doch lieber mehr anlegen?

    Der Sizing Calculator hat mir 12 Datenbanken mit gerundet 42 Mailboxen/Datenbank empfohlen. Jetzt komm' ich doch etwas ins grübeln, ob z.B. die eine Datenbank mit ca. 360 Nutzern nicht vielleicht zu stark frequentiert ist.

    Falls ich mehrere Datenbanken anlegen sollte:

    Wie wird das dann mit der Aufteilung der Nutzer gehandhabt? Ich hätte ja die Quotas an den Datenbanken festgemacht. Für den 1st Level Support wäre klar ersichtlich, welcher User in welche Datenbank gehört. Wenn ich aber mehrere Datenbanken a la Exchange Sizing Calculator mit ca. 42 Nutzern / Datenbank anlege, dann müsste ich die Quotas pro Benutzer bzw. Benutzergruppen einstellen. Zudem müsste der 1st Level Support immer zusehen, dass jede Datenbank immer ähnlich viele Mailboxen enthält wie die anderen Datenbanken.

    Ist doch den Aufwand nicht wert, oder?

    Vielen Dank & Gruß,

    Karl-Heinz

    • Als Antwort markiert Mr. Fuchs Freitag, 20. Juli 2018 13:58
    • Tag als Antwort aufgehoben Mr. Fuchs Freitag, 20. Juli 2018 13:58
    Freitag, 20. Juli 2018 12:07
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin,

    ich bin ein großer Fan davon, Quotas direkt an Postfächer zu vergeben. Es wird immer Ausnahmen geben, und auf diese Weise musst Du nicht prüfen, ob das Quota geerbt oder angepasst wurde.

    Und wenn man das dann macht, ist es gerade sehr schön, wenn große und kleine Mailboxen gemischt sind, denn große Mailboxen produzieren erfahrungsgemäß auch mehr Traffic. Auf die gleichmäßige Verteilung muss der 1st level Support nur bedingt achten, denn Exchange provisioniert ja je nach Auslastung, wenn man gar keine DB angibt.

    In Deinem Beispiel würde ich mit 3-4 Datenbanken einsteigen, mehr ist ganz bestimmt nicht erforderlich. Ich habe in einer öffentlichen Verwaltung 2.300 User in zwei Datenbanken (iSCSI aus der VM heraus), und es gibt I/O-mäßig keine Probleme.

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.


    Freitag, 20. Juli 2018 13:30
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Evengij,

    toll. Danke für deine Ratschläge.

    Ist schön, auch mal Erfahrungen aus der Praxis zu hören. Die ganze Exchange Sizing Calculator Geschichte ist, wie du schon erwähnt hast dazu da, Denkanstöße zu geben. Aber man kann sich da auch schnell "verrennen".

    Also: Fall gelöst.

    Vielen Dank noch einmal für die Unterstützung.

    Gruß,
    Karl-Heinz

    Freitag, 20. Juli 2018 13:57
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Mr. Fuchs,

    da du ohnehin alles virtualisiert hast kannst du ja jederzeit problemlos erweitern. Gegen deine Aufteilung spricht sicher nicht dagegen. Auch hier kannst du jederzeit eine DB dazu geben falls dir dein Konzept nicht ausreicht. Nicht vergessen ab 5  benötigst du eine Enterprise Exchange Version.

    Wir haben ein ähnliches Konzept VMWare über 1000 Postfächer (mehrere DBs und unterschiedliche Quotas auf die DBs) und es klappt sehr gut. Einmal habe ich eine DB erweitert um Ressourcenpostfächer einfach zu handeln und ggf. bei Lizenzüberprüfungen zählen zu können. Also kein Problem wenn einmal im Betrieb etwas verändert wird. Gerade mit Quotas finde ich mehrere DBs sehr praktisch. Zusätzlich macht es das ganze etwas übersichtlicher. 

    Chris


    Freitag, 20. Juli 2018 13:58
    |