9
Exchange2019 Hauptspeicherbedarf
Hallo,
stehe vor dem Umheben von 2016 (läuft klaglos mit meinen ~25 Mailboxen und rund 200GB DAG auf 16GB RAM) auf 2019 - mein 3rd-Party rät dazu wg.einiger ALtlasten auf dem 2016 die er nicht wegkonfiguriert bekommt - es gibt da wirklich verwirrende Fehlermeldungen, obwohl das Ding seit etlichen Monaten recht klaglos läuft.
Sei's drum, dann sollen die eben umheben.
Nun kommen aber die Anhänger der reinen Lehre hervor, die auf die Sizing-XLS von MS verweisen - da geht unter 128GB + 64GB mal gar nix.
Ich ahne schon warum das so dargestellt wird und habe recherchiert - die Aussagen Anderer sind hier eindeutig: alles heiße Luft, MS will keine KMU On-Prem Exchange mehr und daher schreiben die Mondzahlen auf, damit jeder entweder kostenmäßig hinten runter fällt oder aber im Zweifel ein unkalkulierbes weil unbekanntes Risikio nimmt.
Bin selber seit langem Programmierer: so übel kann selbst .NET nicht sein dass man für das bischen was die da tun, soviel Speicher verbrät. Es geht eben nicht um ein Hosting-System mit 5000+ Usern..., und es ist wurscht, ob die Antwortzeit 0,5s oder 0,8s ist.
Was denkt Ihr?
Danke Euch
stehe vor dem Umheben von 2016 (läuft klaglos mit meinen ~25 Mailboxen und rund 200GB DAG auf 16GB RAM) auf 2019 - mein 3rd-Party rät dazu wg.einiger ALtlasten auf dem 2016 die er nicht wegkonfiguriert bekommt - es gibt da wirklich verwirrende Fehlermeldungen, obwohl das Ding seit etlichen Monaten recht klaglos läuft.
Sei's drum, dann sollen die eben umheben.
Nun kommen aber die Anhänger der reinen Lehre hervor, die auf die Sizing-XLS von MS verweisen - da geht unter 128GB + 64GB mal gar nix.
Ich ahne schon warum das so dargestellt wird und habe recherchiert - die Aussagen Anderer sind hier eindeutig: alles heiße Luft, MS will keine KMU On-Prem Exchange mehr und daher schreiben die Mondzahlen auf, damit jeder entweder kostenmäßig hinten runter fällt oder aber im Zweifel ein unkalkulierbes weil unbekanntes Risikio nimmt.
Bin selber seit langem Programmierer: so übel kann selbst .NET nicht sein dass man für das bischen was die da tun, soviel Speicher verbrät. Es geht eben nicht um ein Hosting-System mit 5000+ Usern..., und es ist wurscht, ob die Antwortzeit 0,5s oder 0,8s ist.
Was denkt Ihr?
Danke Euch
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 667451
Url: https://administrator.de/contentid/667451
Ausgedruckt am: 22.11.2024 um 06:11 Uhr
9 Kommentare
Neuester Kommentar
Hi,
Auf meinem 2019 Exchanger (VM) hab ich 128GB zugewiesen.
Habe auch nicht soviel Mailboxen drauf, sind 10 Stück.
Der braucht nicht so viel wie gesagt wird. er dümpelt im Höchstfall so mit 32 gb vor sich hin!
Auf einer Test Domäne hab ich ihn mit 16 gb installiert und geht auch sehr gut!
Gruß
Abramelin
Auf meinem 2019 Exchanger (VM) hab ich 128GB zugewiesen.
Habe auch nicht soviel Mailboxen drauf, sind 10 Stück.
Der braucht nicht so viel wie gesagt wird. er dümpelt im Höchstfall so mit 32 gb vor sich hin!
Auf einer Test Domäne hab ich ihn mit 16 gb installiert und geht auch sehr gut!
Gruß
Abramelin
Hallo,
ich habe bei einem Kunden einen Win2019 mit Exchange 2019 der mit 16GB RAM für 25 Postfächer total glücklich ist.
Storage ist ein Hardware mit 3 Enterprise SATA-SSDs als Raid5.
Stefan
ich habe bei einem Kunden einen Win2019 mit Exchange 2019 der mit 16GB RAM für 25 Postfächer total glücklich ist.
Storage ist ein Hardware mit 3 Enterprise SATA-SSDs als Raid5.
Stefan
moin...
mein Exchange 2019 Cu9 läuft auf nem Raspi mit 4 GB Ram, als Storage nutze ich nen 2 GB USB Stick....
und natürlich an einem IBM P70 Monitor... und die Tastatur macht noch Klack..... 55 Postfacher und 33k modem!
Jungs, echt jetzt.. natürlich braucht es nicht immer 128 GB+ Ram... es kommt auch nicht auf die Postfächer an, sondern was der Exchange zu tun hat...
ich habe Exchange Server (Kunden), die haben 64GB Ram und NVMe Speicher, und stehen unter vollast... haben aber nur 10 Konten und 5 Freigaben! aber einen heftigen Mailflow, und Server mit 128 GB Ram, 5 DBs 50 Konten, und was soll ich sagen, die VM langweilt sich, und der Ram dümpelt so bei 10 GB rum....
lieber @winacker
gönne deine Exchange2019 DAG pro VM erstmal mindesten 32GB Ram, du wirst merken, wenn du mehr brauchst.
die frage ist ja, was macht deine DAG, hast du einen LB, machst Failover oder Switchover über DNS? wie hoch ist dein Mail durchsatz?
Kalender / Räume etc...
Frank
mein Exchange 2019 Cu9 läuft auf nem Raspi mit 4 GB Ram, als Storage nutze ich nen 2 GB USB Stick....
und natürlich an einem IBM P70 Monitor... und die Tastatur macht noch Klack..... 55 Postfacher und 33k modem!
Jungs, echt jetzt.. natürlich braucht es nicht immer 128 GB+ Ram... es kommt auch nicht auf die Postfächer an, sondern was der Exchange zu tun hat...
ich habe Exchange Server (Kunden), die haben 64GB Ram und NVMe Speicher, und stehen unter vollast... haben aber nur 10 Konten und 5 Freigaben! aber einen heftigen Mailflow, und Server mit 128 GB Ram, 5 DBs 50 Konten, und was soll ich sagen, die VM langweilt sich, und der Ram dümpelt so bei 10 GB rum....
lieber @winacker
gönne deine Exchange2019 DAG pro VM erstmal mindesten 32GB Ram, du wirst merken, wenn du mehr brauchst.
die frage ist ja, was macht deine DAG, hast du einen LB, machst Failover oder Switchover über DNS? wie hoch ist dein Mail durchsatz?
Kalender / Räume etc...
Frank
1
moin...
statistich und nach murphy fällt ein Raid 5 öfter auseinander, als ein raid 10 oder1... das ein raid1 oder 10 zu 99% zugriff auf die Daten lässt, ist dir ja bewusst, je nachdem ist dein Raid5 meistens schrott (besonders wenn der Kunde an der tastatur war). natürlich hat heute jeder ne ordentlich Datensicherung und Mailstore- macht es aber einfacher.
Stefan
Frank
Zitat von @StefanKittel:
Hallo,
ich habe bei einem Kunden einen Win2019 mit Exchange 2019 der mit 16GB RAM für 25 Postfächer total glücklich ist.
Storage ist ein Hardware mit 3 Enterprise SATA-SSDs als Raid5.
na ja.. mit nem SSD Raid 5 würde ich nix machen, lieber ein Raid10 oder Raid1.Hallo,
ich habe bei einem Kunden einen Win2019 mit Exchange 2019 der mit 16GB RAM für 25 Postfächer total glücklich ist.
Storage ist ein Hardware mit 3 Enterprise SATA-SSDs als Raid5.
statistich und nach murphy fällt ein Raid 5 öfter auseinander, als ein raid 10 oder1... das ein raid1 oder 10 zu 99% zugriff auf die Daten lässt, ist dir ja bewusst, je nachdem ist dein Raid5 meistens schrott (besonders wenn der Kunde an der tastatur war). natürlich hat heute jeder ne ordentlich Datensicherung und Mailstore- macht es aber einfacher.
Stefan
Danke Euch,
nochmal zur Eingrenzung:
wir haben kein Failover, keinen Cluster und ca. 100 Mails/Tag (plus 400 SPAM, die aber im Grossteil die Sophos vorher wegfischt).
Werde da mal mit 16GB starten - hat jemand eine Idee, woran ich merke ob das nicht reicht?
Schon klar, wenn lahm und Swap etc.pp., dann sehe ich das auch.
Es gibt aber auch Angstmacher, die sagen dass der EXCHG. dann komische Dinge tun KÖNNTE die man so nicht nachvollziehen kann
nochmal zur Eingrenzung:
wir haben kein Failover, keinen Cluster und ca. 100 Mails/Tag (plus 400 SPAM, die aber im Grossteil die Sophos vorher wegfischt).
Werde da mal mit 16GB starten - hat jemand eine Idee, woran ich merke ob das nicht reicht?
Schon klar, wenn lahm und Swap etc.pp., dann sehe ich das auch.
Es gibt aber auch Angstmacher, die sagen dass der EXCHG. dann komische Dinge tun KÖNNTE die man so nicht nachvollziehen kann
Moin Frank,
RAID 1 ist eine reine Spiegelung und ist nur bei 2 HDD's oder SSD's sinnvoll.
Die Gesamtspeicherausbeute entspricht der grösse des kleinsten einzelnen Datenträgers und die Performance ist auch entsprechend dürftig, vor allem beim Schreiben.
Bei RAID10 verlierst du die Hälfte der Gesamtkapazität aller Datenträger und auch die Performance ist, vor allem beim Schreiben,
keineswegs besser wie beim RAID5, zumindest nicht dann, wenn man einen anständigen RAID Controller mit einer eigener ASIC verwendet.
Ein modernder Hardware-RAID-Controller berechnet den Parity Bit eines RAID5 im Halbschlaf, so das der eigentlicher Vorteil von RAID10, nämlich die besagte und fehlende Paritybitberechnung beim Schreiben, im Betrieb so gar nicht mehr ins Gewicht fällt. Der Kapazitätsverlust durch RAID10 im Vergleich zu RAID5 ist dagegen deutlich spürbarer.
RAID5 verkraftet ohne Probleme den Ausfall von einem Datenträger und das reicht bei SSD's auch vollkommen aus.
Mann sollte bei der Wahl der SSD's für den Server lediglich auch eine SSD, die für den Serverbetrieb gedacht ist auswählen und nicht gerade die billigsten 0815 SSD's aus dem Konsumerbereich nehmen.
Habe die letzten 10 Jahre > 50 All-Flash SAN's implementiert, alle mit RAID5 und bei keinem ist bisher auch nur eine einzige SSD gestorben.
Die blöden MUX Adapter, die wir anfänglich bei den All-Flash SAN's verwendet haben, sind schon hin und wieder verreckt aber nicht die SSD's selbst.
Die ersten SSD's gabs von Intel und die hatten nur SATA und nicht SAS und waren daher eigentlich für HA untauglich, aber dank eines MUX-Adapters konnten auch diese bereits schon SAS und konnten somit bereits schon damals (erstes ausgeliefertes AllFlash-SAN ~ Anfang 2011) in dem einen oder anderen HA-SAN verwendet werden. 😎
Beste Grüsse aus BaWü
Alex
na ja.. mit nem SSD Raid 5 würde ich nix machen, lieber ein Raid10 oder Raid1.
RAID 1 ist eine reine Spiegelung und ist nur bei 2 HDD's oder SSD's sinnvoll.
Die Gesamtspeicherausbeute entspricht der grösse des kleinsten einzelnen Datenträgers und die Performance ist auch entsprechend dürftig, vor allem beim Schreiben.
Bei RAID10 verlierst du die Hälfte der Gesamtkapazität aller Datenträger und auch die Performance ist, vor allem beim Schreiben,
keineswegs besser wie beim RAID5, zumindest nicht dann, wenn man einen anständigen RAID Controller mit einer eigener ASIC verwendet.
Ein modernder Hardware-RAID-Controller berechnet den Parity Bit eines RAID5 im Halbschlaf, so das der eigentlicher Vorteil von RAID10, nämlich die besagte und fehlende Paritybitberechnung beim Schreiben, im Betrieb so gar nicht mehr ins Gewicht fällt. Der Kapazitätsverlust durch RAID10 im Vergleich zu RAID5 ist dagegen deutlich spürbarer.
RAID5 verkraftet ohne Probleme den Ausfall von einem Datenträger und das reicht bei SSD's auch vollkommen aus.
Mann sollte bei der Wahl der SSD's für den Server lediglich auch eine SSD, die für den Serverbetrieb gedacht ist auswählen und nicht gerade die billigsten 0815 SSD's aus dem Konsumerbereich nehmen.
Habe die letzten 10 Jahre > 50 All-Flash SAN's implementiert, alle mit RAID5 und bei keinem ist bisher auch nur eine einzige SSD gestorben.
Die blöden MUX Adapter, die wir anfänglich bei den All-Flash SAN's verwendet haben, sind schon hin und wieder verreckt aber nicht die SSD's selbst.
Die ersten SSD's gabs von Intel und die hatten nur SATA und nicht SAS und waren daher eigentlich für HA untauglich, aber dank eines MUX-Adapters konnten auch diese bereits schon SAS und konnten somit bereits schon damals (erstes ausgeliefertes AllFlash-SAN ~ Anfang 2011) in dem einen oder anderen HA-SAN verwendet werden. 😎
Beste Grüsse aus BaWü
Alex
off topic: zum Thema Speicher bin ich positiv überrascht von einem QNAP NAS mit 5 4TB-HDD (RAID5), welches mit 10GBit eingebunden ist (alle HV-Bleche hängen da ebenfalls mit 10GBit dran).
Ich hatte z.B. früher einen dedizierten Backup-PC mit VEEAM laufen mit lokaler HDD (8TB) als primäres Backup-Target, von da wurde auf 2nd Targets verteilt.
Mehr als ~150MB/s waren da primär nie drin - zu erwarten.
Bin jetzt im Zuge der Virtualisierung mit dem primären Target auf das NAS gegangen - 300-400 MB/s sind da auch schreibend durchaus machbar, ds NAS verteilt die Schreibzugriffe über die Platten (Was allerdings bei QNAP gar nicht funktioniert, ist das Cachen via SSD, bringt 0,0)
Auf den Hosts selbst arbeite ich mit RAID10-SSD, entweder mit Intel oder demnächst AMD Raid on-board.
Habe viele (3-4) klassischen dedizierten RAID-Controller testweise durch, da gab es deutlich mehr Probleme als Vorteile (klar, ich kann im Fehlerfall den Controller tauschen und müsste nicht an das Board - ist mir aber sowohl als auch in den letzten 20 Jahren nicht untergekommen).
Dafür habe ich das Theater mit den aktuellen Triebern, etc.pp.: die RAID-Adapter kommen mir immer ein bischen so vor wie Technik aus dem Holozän...
Ich hatte z.B. früher einen dedizierten Backup-PC mit VEEAM laufen mit lokaler HDD (8TB) als primäres Backup-Target, von da wurde auf 2nd Targets verteilt.
Mehr als ~150MB/s waren da primär nie drin - zu erwarten.
Bin jetzt im Zuge der Virtualisierung mit dem primären Target auf das NAS gegangen - 300-400 MB/s sind da auch schreibend durchaus machbar, ds NAS verteilt die Schreibzugriffe über die Platten (Was allerdings bei QNAP gar nicht funktioniert, ist das Cachen via SSD, bringt 0,0)
Auf den Hosts selbst arbeite ich mit RAID10-SSD, entweder mit Intel oder demnächst AMD Raid on-board.
Habe viele (3-4) klassischen dedizierten RAID-Controller testweise durch, da gab es deutlich mehr Probleme als Vorteile (klar, ich kann im Fehlerfall den Controller tauschen und müsste nicht an das Board - ist mir aber sowohl als auch in den letzten 20 Jahren nicht untergekommen).
Dafür habe ich das Theater mit den aktuellen Triebern, etc.pp.: die RAID-Adapter kommen mir immer ein bischen so vor wie Technik aus dem Holozän...
moin...
Bei RAID10 verlierst du die Hälfte der Gesamtkapazität aller Datenträger und auch die Performance ist, vor allem beim Schreiben,
keineswegs besser wie beim RAID5, zumindest nicht dann, wenn man einen anständigen RAID Controller mit einer eigener ASIC verwendet.
nun, bei den heutigen preisen ist das mit der kapazität echt wurst.
ich würde im singel server bereich das eh nicht mehr nutzen, eher schon PM1735 im Raid1.. da hast du IO leistung satt
RAID5 verkraftet ohne Probleme den Ausfall von einem Datenträger und das reicht bei SSD's auch vollkommen aus.
kommt auf die SSDS an...
Habe die letzten 10 Jahre > 50 All-Flash SAN's implementiert, alle mit RAID5 und bei keinem ist bisher auch nur eine einzige SSD gestorben.
das sind äpfel und birnen, du glaubst nicht was kunden so alles selber verbauen....
Zitat von @MysticFoxDE:
Moin Frank,
RAID 1 ist eine reine Spiegelung und ist nur bei 2 HDD's oder SSD's sinnvoll.
Die Gesamtspeicherausbeute entspricht der grösse des kleinsten einzelnen Datenträgers und die Performance ist auch entsprechend dürftig, vor allem beim Schreiben.
ja klar.. viele kleine KMUs haben das aber so...Moin Frank,
na ja.. mit nem SSD Raid 5 würde ich nix machen, lieber ein Raid10 oder Raid1.
RAID 1 ist eine reine Spiegelung und ist nur bei 2 HDD's oder SSD's sinnvoll.
Die Gesamtspeicherausbeute entspricht der grösse des kleinsten einzelnen Datenträgers und die Performance ist auch entsprechend dürftig, vor allem beim Schreiben.
Bei RAID10 verlierst du die Hälfte der Gesamtkapazität aller Datenträger und auch die Performance ist, vor allem beim Schreiben,
keineswegs besser wie beim RAID5, zumindest nicht dann, wenn man einen anständigen RAID Controller mit einer eigener ASIC verwendet.
Ein modernder Hardware-RAID-Controller berechnet den Parity Bit eines RAID5 im Halbschlaf, so das der eigentlicher Vorteil von RAID10, nämlich die besagte und fehlende Paritybitberechnung beim Schreiben, im Betrieb so gar nicht mehr ins Gewicht fällt. Der Kapazitätsverlust durch RAID10 im Vergleich zu RAID5 ist dagegen deutlich spürbarer.
das ist schon richtig, allerdings wenn kein guter Controller dranhängt, geht das mal eben schnell schief- und wenn der kunde die falsche taste drückt... ist ende...ich würde im singel server bereich das eh nicht mehr nutzen, eher schon PM1735 im Raid1.. da hast du IO leistung satt
RAID5 verkraftet ohne Probleme den Ausfall von einem Datenträger und das reicht bei SSD's auch vollkommen aus.
Mann sollte bei der Wahl der SSD's für den Server lediglich auch eine SSD, die für den Serverbetrieb gedacht ist auswählen und nicht gerade die billigsten 0815 SSD's aus dem Konsumerbereich nehmen.
das stimmt, aber dann stehst du vor ner Samsung EVO oder schlimmer.... da hast du keine fragen mehr.Habe die letzten 10 Jahre > 50 All-Flash SAN's implementiert, alle mit RAID5 und bei keinem ist bisher auch nur eine einzige SSD gestorben.
Die blöden MUX Adapter, die wir anfänglich bei den All-Flash SAN's verwendet haben, sind schon hin und wieder verreckt aber nicht die SSD's selbst.
Die ersten SSD's gabs von Intel und die hatten nur SATA und nicht SAS und waren daher eigentlich für HA untauglich, aber dank eines MUX-Adapters konnten auch diese bereits schon SAS und konnten somit bereits schon damals (erstes ausgeliefertes AllFlash-SAN ~ Anfang 2011) in dem einen oder anderen HA-SAN verwendet werden. 😎
Beste Grüsse aus BaWü
Alex
FrankDie ersten SSD's gabs von Intel und die hatten nur SATA und nicht SAS und waren daher eigentlich für HA untauglich, aber dank eines MUX-Adapters konnten auch diese bereits schon SAS und konnten somit bereits schon damals (erstes ausgeliefertes AllFlash-SAN ~ Anfang 2011) in dem einen oder anderen HA-SAN verwendet werden. 😎
Beste Grüsse aus BaWü
Alex
Hallo,
das kann ich durchaus so wiedergeben.
Bei mir läuft der Exchange 2019 auf einem Server 2019 in einer Testumgebung, 10 Postfächer auf 16 GB RAM ohne Probleme.
Da Testumgebung liegt die Installation sogar auf einer 2,5 SSHD (Firecuda) (ohne RAID). Entsprechend langsam natürlich die Installation bzw. Update - aber es funktioniert. Clients (Outlook/Smartphones) können ohne Probleme mit arbeiten.
Auslastung jetzt gerade bei 10,7 GB.
Ich denke ebenfalls, dass in dieser Größenordnung 128 GB etwas überdimensioniert sind - und den Grund warum MS das macht, hast du (denke ich) auch schon geliefert.
Gruß
das kann ich durchaus so wiedergeben.
Bei mir läuft der Exchange 2019 auf einem Server 2019 in einer Testumgebung, 10 Postfächer auf 16 GB RAM ohne Probleme.
Da Testumgebung liegt die Installation sogar auf einer 2,5 SSHD (Firecuda) (ohne RAID). Entsprechend langsam natürlich die Installation bzw. Update - aber es funktioniert. Clients (Outlook/Smartphones) können ohne Probleme mit arbeiten.
Auslastung jetzt gerade bei 10,7 GB.
Ich denke ebenfalls, dass in dieser Größenordnung 128 GB etwas überdimensioniert sind - und den Grund warum MS das macht, hast du (denke ich) auch schon geliefert.
Gruß
