none
Exchange Server 2016 - SP1 & Load Balancing RRS feed

  • Frage

  • Hallo zusammen,

    Ich hätte hier 2 Fragen im Bereich Exchange anzubieten ;-)

    #1  - Kann man schon absehen wann das SP1 für den Exchange Server 2016 rauskommt denn derzeit ist ja erst das CU2 für Exchange 2016 aktuell? Vom Bauchgefühl würde ich gerne das SP1 abwarten oder ist dem Exchange Server 2016 mit dem CU2 schon zu trauen (Kinderkrankheiten bekannt)?

    #2  - Die Umstellung auf Exchange 2016 ist bei uns für nächstes Jahr geplant aber die Wirtschaftsplanung hat mich dem Thema doch etwas schneller betrachten lassen. Hier bin ich beim Thema „Load Balancing“ in folgenden Fragen ins Stocken geraten was Exchange 2016 bzw. deren Verfügbarkeit betrifft. Derzeit läuft es über CAS-Array bei 2 CAS/HT Servern

    Ist ein „Load Balancing“ bei Exchange Server 2016 notwendig bzw. ein muss?

    -          Ich gehe davon eigentlich schon aus da Wir an die 5 Server haben werden und mehreren Tausend Postfächern sprechen

    Warum sollte ein „Load Balancing“ eingesetzt werden?

    -          Lastausgleich spricht für sich

    Kann ein „Load Balancing“ mit MS Produkten realisiert werden?

    Ich wäre auch dankbar wenn Ihr mir kurz Erfahrung zum Einsatz mit Exchange 2016 und einem Load Balancer gebe könntet.

     

    Folgende Produkte habe ich bisher gefunden und bei KEMP auch schon mal angefragt aber die Preise von KEMP sind nicht ohne und da weiß ich jetzt schon das (berechtigte) Fragen bei der GeFü aufkommen werden ;-)

     

    https://kemptechnologies.com/de/microsoft-load-balancing/load-balancing-microsoft-exchange-2016/

    http://loadbalancer.org

    https://www.zenloadbalancer.com/

    https://www.frankysweb.de/exchange-2016-loadbalancing-mit-kemp-loadmaster-7-1-teil-3/

    Mit freundlichen Grüßen

    Paul



    • Bearbeitet Lexxitus Donnerstag, 21. Juli 2016 19:05
    Donnerstag, 21. Juli 2016 19:01

Antworten

  • Moin,

    hier meine persönliche Meinung:

    • CU2 kann in Produktion recht bedenkenlos eingesetzt werden, ein paar obligatorische Bugs sind bekannt und es wird bis zum kommenden Jahr ja auch mindestens CU3, wenn nicht gar CU4 verfügbar sein.
    • WinNLB ist mit Exchange 2016 endgültig gestorben, da ja nur Multirole-Boxen möglich sind und somit das Failover Clustering-Feature auf allen Knoten aktiv ist.
    • Hardware LB ist durchaus zu empfehlen; allerdings werden auch große Installationen erfolgreich mit Round Robin DNS gefahren, so sehr das Verfahren sonst belächelt werden mag. Doof ist es immer, wenn man DNS nicht selbst betreibt, denn für längere Downtimes eines Knoten möchte man ihn dann schon rausnehmen...
    • Verzichtet man auf Hardware LB, wird das Monitoring um so wichtiger.
    • KEMP ist für Exchange so ziemlich das beste, was das Preis-/Leistungs-/Support-Verhältnis anbelangt. Hat man aber schon einen anderen LB im Einsatz (so z.B. NetScaler, wenn man ein XenApp-Farm betreibt, oder einen F5 oder was auch immer), wird man in der Regel da mit aufspringen können.
    • Hardware LB macht für Exchange 2013 oder höher nur dann auch nur ansatzweise Sinn, wenn 1. mindestens zwei Stück davon im transparenten HA-Verbund betrieben werden, und 2. die Managed Availability-Monitore in das Load Balancing mit einbezogen werden. Alles darunter kann Exchange selber in Kombination mit RR-DNS genauso gut abwickeln.
    • Hardware LB ist natürlich auch dann dringend zu empfehlen, wenn zwischen den Clients und der Exchange-Organisation eine Firewall steht, in die man möglichst wenige Löcher bohren möchte oder darf.
    Gruß

    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.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.

    • Als Antwort markiert Lexxitus Freitag, 22. Juli 2016 08:35
    Donnerstag, 21. Juli 2016 20:07
  • Moin,

    ich persönlich bin kein Freund von DNS Roundrobin (egal, in welcher Größe), weil das Client-abhängig ist und ich die Clients in dieser Hinsicht nicht gut kontrollieren kann.

    Ansonsten kann ich den anderen nur in Bezug auf KEMP rechtgeben: Wenn Du einen Loadbalancer nur für Exchange suchst, findest Du in der Größenordnung fast nichts besseres am Markt. Gute Anleitung, kompetenter deutschrachiger Support.

    Und preislich liegt das garantiert drunter. Wir liegen bei 2000 Usern bei knapp 25.000 Euro Listenpreis für zwei HA-LB (allerdings virtuell, das reicht bei der Größe noch). Bei Cisco habe ich früher für den Preis nicht mal ein müdes Lächeln bekommen.

    Wenn Du einen funktionierenden LB hast, dann teste bitte ganz genau die Besonderheiten, die Micrsoft bei Active Sync und Outlook Anywhere benutzt. Die Tatsache, dass Verbindungen über einen längeren Zeitraum offen gehalten werden, mag nicht nicht Load Balancer. Wir hatten mindestens 2 bei uns (vor KEMP), die bei Active Sync kein Push-Mail hinbekommen haben, weil der LB nach wenigen Minuten die Session verwarf.

    Zum SP 1: Aber 2013 gibt es faktische keine "echten" Service Packs für Exchange mehr.

    Von der technischen Seite ist 2016 ein besseres Service Pack für 2013... :) Ansonsten der offizielle Release-Zyklus, dass alle drei Monate ein CU erscheint. Wenn MSFT der eigenen Philosophie treu bleibt, dann könnte CU 4 wieder SP 1 heißen. Ist aber nur ein Name, denn inhaltlich bekommen alle CUs den gleichen Entwicklungsaufwand.


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    • Als Antwort markiert Lexxitus Freitag, 22. Juli 2016 08:35
    Freitag, 22. Juli 2016 07:32
  • Bisher reichte DNS-RoundRobin aber durch das Wachstum wird hier ein LB Pflicht werden.

    Moin,

    jetzt können wir, da das Wochenende langsam aber unaufhaltsam naht, diesen Satz mal für eine philosophische Diskussion aufgreifen ;-)

    Ist es in der aktuellen Exchange-Architektur denn wirklich so, dass mit der Erhöhung der Anzahl der Nodes und/oder Mailboxes ein externes LB Pflicht wird? Was wäre rein technisch der Indikator dafür? Schauen wir uns das mal an:

    • Extremfall: Ein einzelner großer AD-Standort, wo ausschließlich Outlook (also kein OWA oder ActiveSync) benutzt wird. Ich meine, hier würde die optimale Lastverteilung für den Clientzugriff dadurch erreicht werden, dass man gar keinen gemeinsamen Namespace verwendet und jeden Request per Autodiscover zu demjenigen Server schickt, wo Exchange meint, dass es angemessen wäre! Kommt aber natürlich selten vor ;-)
    • Anderer Extremfall: Firewall und/oder WAN-Strecke zwischen der Gesamtheit der Clients und der Gesamtheit der Exchange Server. Hier ist natürlich sowohl ein gemeinsamer Namespace als auch eine gemeinsame IP-Adresse (und somit ein LB) optimal, und zwar unabhängig von der Größe!
    • Verwendet man einen gemeinsamen Namespace innerhalb einer Site, so weiß ein LB ebensowenig wie RR-DNS darüber bescheid, welcher Host für die konkrete Anfrage der "richtige" wäre (also wo das anfragende Postfach liegt). Dann gibt es aber auch noch den Zugriff auf die Ressourcen, Public Folders und das Archiv, die möglicherweise auf anderen Knoten liegen als das primäre Postfach, womit es eh keinen "absolut richtigen" Server für die Anfrage gibt.
    • Protokolle wie SMTP, POP3 und IMAP4 besitzen von Natur aus nicht das Maß an Resilienz, sofort zum nächsten Server zu springen.

    Meine Wenigkeit ist geneigt, daraus die folgenden Schlüsse zu ziehen:

    • HLB macht erst einmal nichts schlimmer als es ohne HLB ist/wäre, es geht also darum, welche Verbesserung ich für das Geld erwarten kann. Spielt das Geld keine Rolle, sollte gemäß dem Prinzip "nobody ever got fired for choosing IBM" HLB zum Einsatz kommen.
    • In Fällen, wo RR-DNS im Prinzip funktioniert, müsste man eigentlich nachweisen, dass die Verteilung der Anfragen auf die einzelnen Knoten stark ungleichmäßig ist (und im Zweifel auch, dass dies einen Performance Impact hat). Diesen Nachweis musste ich ein paarmal führen, und bei ausreichend vielen Clients und ausreichend kurzer TTL ist bereits der erste Teil schwierig.
    • HLB ist dann von unschätzbarem Vorteil, wenn einzelne Exchange-Server regelmäßig down sind und Protokolle (SMTP, POP3, IMAP4 oder auch Anwendungen, die EWS nutzen aber keine Retry-Logik dafür implementiert haben) verwendet werden, die den Ausfall des ursprünglich aus dem DNS bezogenen Hosts nicht verkraften können - oder gar die Eintragung einer IP-Adresse als Ziel fordern.
    • Es kann bei Entscheidung über den HLB-Einsatz durchaus nützlich sein, das Load Balancing für die drei Sparten "Downlevel-Protokolle SMTP,POP,IMAP", "Webservices OWA,EAS,EWS" und "Clientzugriff MAPI/HTTP,RPC/HTTP" separat zu betrachten. Letztere produziert i.d.R. mit Abstand die meisten Anfragen, ist aber auch am Unempfindlichsten gegenüber Host-Ausfall und "Falschrouting". Dann kann es statt einer großen F5 vielleicht doch nur eine VPX-200 werden, und die nutzt man halt nur für das Downlevel-Zeug.

    Was sagen die anderen?


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.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.

    • Als Antwort markiert Lexxitus Freitag, 22. Juli 2016 08:36
    Freitag, 22. Juli 2016 07:57

Alle Antworten

  • Moin,

    hier meine persönliche Meinung:

    • CU2 kann in Produktion recht bedenkenlos eingesetzt werden, ein paar obligatorische Bugs sind bekannt und es wird bis zum kommenden Jahr ja auch mindestens CU3, wenn nicht gar CU4 verfügbar sein.
    • WinNLB ist mit Exchange 2016 endgültig gestorben, da ja nur Multirole-Boxen möglich sind und somit das Failover Clustering-Feature auf allen Knoten aktiv ist.
    • Hardware LB ist durchaus zu empfehlen; allerdings werden auch große Installationen erfolgreich mit Round Robin DNS gefahren, so sehr das Verfahren sonst belächelt werden mag. Doof ist es immer, wenn man DNS nicht selbst betreibt, denn für längere Downtimes eines Knoten möchte man ihn dann schon rausnehmen...
    • Verzichtet man auf Hardware LB, wird das Monitoring um so wichtiger.
    • KEMP ist für Exchange so ziemlich das beste, was das Preis-/Leistungs-/Support-Verhältnis anbelangt. Hat man aber schon einen anderen LB im Einsatz (so z.B. NetScaler, wenn man ein XenApp-Farm betreibt, oder einen F5 oder was auch immer), wird man in der Regel da mit aufspringen können.
    • Hardware LB macht für Exchange 2013 oder höher nur dann auch nur ansatzweise Sinn, wenn 1. mindestens zwei Stück davon im transparenten HA-Verbund betrieben werden, und 2. die Managed Availability-Monitore in das Load Balancing mit einbezogen werden. Alles darunter kann Exchange selber in Kombination mit RR-DNS genauso gut abwickeln.
    • Hardware LB ist natürlich auch dann dringend zu empfehlen, wenn zwischen den Clients und der Exchange-Organisation eine Firewall steht, in die man möglichst wenige Löcher bohren möchte oder darf.
    Gruß

    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.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.

    • Als Antwort markiert Lexxitus Freitag, 22. Juli 2016 08:35
    Donnerstag, 21. Juli 2016 20:07
  • Am 21.07.2016 schrieb Lexxitus:
    Hi,

    Folgende Produkte habe ich bisher gefunden und bei KEMP auch schon mal angefragt aber die Preise von KEMP sind nicht ohne und da weiß ich jetzt schon das (berechtigte) Fragen bei der GeFü aufkommen werden ;-)

    mehrere tausend Postfächer und es scheitert am Loadbalancing? WEnn dir Kemp schon zu teuer ist, brauchst du bei anderen kommerziellen Anbietern gar nicht erst schauen, die sind afaik alle teurer. ;)

    Bye
    Norbert


    Frank, I never thought I'd say this again. I'm getting the pig!
    nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/

    Donnerstag, 21. Juli 2016 22:06
  • Hallo Evgenij,

    danke für deine Antwort. Gut das Du NetScaler erwähnt hast denn hier haben Wir schon eine Citrix VPX-1000 im Einsatz und da werde ich mir mal anschauen in wie weit das Produkt/Model für uns reicht.

    Wünsche ein erholsames Wochenende

    MfG Paul

    Freitag, 22. Juli 2016 06:45
  • Hallo Norbert,

    Wir wissen doch alle das bei Geld ausgeben immer Fragen kommen was ja auch berechtigt ist. Bisher reichte DNS-RoundRobin aber durch das Wachstum wird hier ein LB Pflicht werden.

    Wünsche ein erholsames Wochenende

    MfG Paul

    Freitag, 22. Juli 2016 06:51
  • Moin,

    ich persönlich bin kein Freund von DNS Roundrobin (egal, in welcher Größe), weil das Client-abhängig ist und ich die Clients in dieser Hinsicht nicht gut kontrollieren kann.

    Ansonsten kann ich den anderen nur in Bezug auf KEMP rechtgeben: Wenn Du einen Loadbalancer nur für Exchange suchst, findest Du in der Größenordnung fast nichts besseres am Markt. Gute Anleitung, kompetenter deutschrachiger Support.

    Und preislich liegt das garantiert drunter. Wir liegen bei 2000 Usern bei knapp 25.000 Euro Listenpreis für zwei HA-LB (allerdings virtuell, das reicht bei der Größe noch). Bei Cisco habe ich früher für den Preis nicht mal ein müdes Lächeln bekommen.

    Wenn Du einen funktionierenden LB hast, dann teste bitte ganz genau die Besonderheiten, die Micrsoft bei Active Sync und Outlook Anywhere benutzt. Die Tatsache, dass Verbindungen über einen längeren Zeitraum offen gehalten werden, mag nicht nicht Load Balancer. Wir hatten mindestens 2 bei uns (vor KEMP), die bei Active Sync kein Push-Mail hinbekommen haben, weil der LB nach wenigen Minuten die Session verwarf.

    Zum SP 1: Aber 2013 gibt es faktische keine "echten" Service Packs für Exchange mehr.

    Von der technischen Seite ist 2016 ein besseres Service Pack für 2013... :) Ansonsten der offizielle Release-Zyklus, dass alle drei Monate ein CU erscheint. Wenn MSFT der eigenen Philosophie treu bleibt, dann könnte CU 4 wieder SP 1 heißen. Ist aber nur ein Name, denn inhaltlich bekommen alle CUs den gleichen Entwicklungsaufwand.


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    • Als Antwort markiert Lexxitus Freitag, 22. Juli 2016 08:35
    Freitag, 22. Juli 2016 07:32
  • Bisher reichte DNS-RoundRobin aber durch das Wachstum wird hier ein LB Pflicht werden.

    Moin,

    jetzt können wir, da das Wochenende langsam aber unaufhaltsam naht, diesen Satz mal für eine philosophische Diskussion aufgreifen ;-)

    Ist es in der aktuellen Exchange-Architektur denn wirklich so, dass mit der Erhöhung der Anzahl der Nodes und/oder Mailboxes ein externes LB Pflicht wird? Was wäre rein technisch der Indikator dafür? Schauen wir uns das mal an:

    • Extremfall: Ein einzelner großer AD-Standort, wo ausschließlich Outlook (also kein OWA oder ActiveSync) benutzt wird. Ich meine, hier würde die optimale Lastverteilung für den Clientzugriff dadurch erreicht werden, dass man gar keinen gemeinsamen Namespace verwendet und jeden Request per Autodiscover zu demjenigen Server schickt, wo Exchange meint, dass es angemessen wäre! Kommt aber natürlich selten vor ;-)
    • Anderer Extremfall: Firewall und/oder WAN-Strecke zwischen der Gesamtheit der Clients und der Gesamtheit der Exchange Server. Hier ist natürlich sowohl ein gemeinsamer Namespace als auch eine gemeinsame IP-Adresse (und somit ein LB) optimal, und zwar unabhängig von der Größe!
    • Verwendet man einen gemeinsamen Namespace innerhalb einer Site, so weiß ein LB ebensowenig wie RR-DNS darüber bescheid, welcher Host für die konkrete Anfrage der "richtige" wäre (also wo das anfragende Postfach liegt). Dann gibt es aber auch noch den Zugriff auf die Ressourcen, Public Folders und das Archiv, die möglicherweise auf anderen Knoten liegen als das primäre Postfach, womit es eh keinen "absolut richtigen" Server für die Anfrage gibt.
    • Protokolle wie SMTP, POP3 und IMAP4 besitzen von Natur aus nicht das Maß an Resilienz, sofort zum nächsten Server zu springen.

    Meine Wenigkeit ist geneigt, daraus die folgenden Schlüsse zu ziehen:

    • HLB macht erst einmal nichts schlimmer als es ohne HLB ist/wäre, es geht also darum, welche Verbesserung ich für das Geld erwarten kann. Spielt das Geld keine Rolle, sollte gemäß dem Prinzip "nobody ever got fired for choosing IBM" HLB zum Einsatz kommen.
    • In Fällen, wo RR-DNS im Prinzip funktioniert, müsste man eigentlich nachweisen, dass die Verteilung der Anfragen auf die einzelnen Knoten stark ungleichmäßig ist (und im Zweifel auch, dass dies einen Performance Impact hat). Diesen Nachweis musste ich ein paarmal führen, und bei ausreichend vielen Clients und ausreichend kurzer TTL ist bereits der erste Teil schwierig.
    • HLB ist dann von unschätzbarem Vorteil, wenn einzelne Exchange-Server regelmäßig down sind und Protokolle (SMTP, POP3, IMAP4 oder auch Anwendungen, die EWS nutzen aber keine Retry-Logik dafür implementiert haben) verwendet werden, die den Ausfall des ursprünglich aus dem DNS bezogenen Hosts nicht verkraften können - oder gar die Eintragung einer IP-Adresse als Ziel fordern.
    • Es kann bei Entscheidung über den HLB-Einsatz durchaus nützlich sein, das Load Balancing für die drei Sparten "Downlevel-Protokolle SMTP,POP,IMAP", "Webservices OWA,EAS,EWS" und "Clientzugriff MAPI/HTTP,RPC/HTTP" separat zu betrachten. Letztere produziert i.d.R. mit Abstand die meisten Anfragen, ist aber auch am Unempfindlichsten gegenüber Host-Ausfall und "Falschrouting". Dann kann es statt einer großen F5 vielleicht doch nur eine VPX-200 werden, und die nutzt man halt nur für das Downlevel-Zeug.

    Was sagen die anderen?


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.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.

    • Als Antwort markiert Lexxitus Freitag, 22. Juli 2016 08:36
    Freitag, 22. Juli 2016 07:57
  • Moin,

    ich finde, Du machst Dich zu stark am Begriff "Load Balancing" fest. Denn in der Tat, kann fast kein Gerät echte Lastverteilung durchführen, da die meisten Geräte die IST-Belastung der Exchange-Server gar nicht kennen.

    Der typische Exchange Loadbalancer dient daher auch für mich nicht dazu, Last zu verteilen, sondern die Bereitstellung von Hochverfügbarkeit zu erleichtern. Ich habe bewährte, gute funktionierende Automatismen (bei auf einzelne Dienste runter), kann das zentral steuern, monitoren und messen (z. B. für SLA).

    Und es erleichtert mir auch die Wartung, weil ich dann endlich wirklich unterbrechungsfrei Server im laufenden Betrieb warten kann, wenn ich rechtzeitig den LB anweise, keine Verbindungen mehr auf einen Server zu leiten.

    Zusammengefasst ist ein LB in eine Umgebung mit mehreren Exchange-Servern, die mit eine DAG mehrere Storages usw. haben, einfach die "professionellere" Lösung im Gesamtkonzept.

    Aber eben nicht als "Lastverteilung", sondern als Komponente der "Verfügbarkeit".


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Freitag, 22. Juli 2016 08:18
  • Aber eben nicht als "Lastverteilung", sondern als Komponente der "Verfügbarkeit".


    ...und genauso sehe ich es auch ;-) Aber der Einstieg - sowohl in dem konkreten Thread (siehe OP) als auch in vielen Kundenprojekten - ist eben genau umgekehrt...

    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.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, 22. Juli 2016 08:24