none
Postfach Migration von 2010 zu 2016 unglaublich langsam RRS feed

  • Frage

  • Hallo,

    ich bin gerade dabei, von Exchange 2010 SP3 CU12 (vier Maschinen, d.h. 2x CAS Cluster plus 2x DAG) auf Exchange 2016 CU1 (zwei Maschinen) zu migrieren. Sowohl Quelle als auch Ziel arbeiten mit Datenbanken als DAG. Die Quelle hat vier Datenbanken, das Ziel zur Zeit acht. Die Zielserver haben momentan 32 GB Ram zugewiesen, nutzen diese aber nur zu weniger als 50%.

    Leider ist das Migrieren von Postfächern unglaublich langsam. Ich habe innerhalb eines guten Tages nur knappe 25 GB an Daten migrieren können. Damit würde die Migration Jahre dauern...

    Beide Exchange Server liegen auf einem schnellen SAN, sind via 10G Netz verbunden und liefern bei einfachen Kopier-Tests zwischen den Volumes problemlos über 500 MB/s lesend/schreibend. Die Disk Queue ist demnach auch quasi nicht nennenswert. Oder anders gesagt: die Systeme langweilen sich.

    Die entsprechenden Einstellungen in der Registry für das Umgehen des MRS scheint es in 2016 nicht mehr zu geben. Ein New-MoveRequest mit -Priority Emergency wird gefühlt nicht wirklich schneller durchgeführt. 

    Aktuell hätte ich eigentlich gerne keine Beschränkungen, sondern vollen Dampf für das Verschieben. An welcher Stellschraube müsste ich da drehen?

    Gruß, Windingo


    • Bearbeitet Windingo Dienstag, 21. Juni 2016 13:22
    Dienstag, 21. Juni 2016 13:21

Alle Antworten

  • Moin,

    als erstes würde ich versuchen festuistellen, auf welcher Seite es hakt. Nimm ein großes Postfach, exportiere es in eine PST (die ebenfalls auf dem schnellen SAN liegen sollte). Importiere die PST dann in das Zielsystem. So wie sich Dein Move-Verhalten darstellt, dürftest Du deutlich unterschiedliche Zeiten sehen (oder auf beiden Seiten deutlich zu lange - das könnte auch sein ;-) )


    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.

    Donnerstag, 23. Juni 2016 21:34
  • Danke für den Tipp. Das Exportieren vom alten System geht relativ zügig, der Import aufs neue System dauert dann ewig.

    Da beide Systeme auf dem gleichen SAN liegen, muss es also irgendwie wohl an der Konfiguration meines neuen Exchange liegen.

    Freitag, 24. Juni 2016 08:47
  • Hast Du auf den Exchange Servern (2010 - HT & 2016) Dir schon mal die Konfigurationsdatei "MSExchangeMailboxReplication.exe.config" unter "C:\Program Files\Microsoft\Exchange Server\V14\Bin" näher angeschaut? Hier kannst Du festlegen wieviel Postfächer Du in welchem Fall verschieben kannst.

    Abschnitt: <MRSConfiguration

    MfG Paul

    Ps.: das war das erste was mir einfiel ;-)

    Freitag, 24. Juni 2016 10:34
  • Auf den neuen Servern sehen die m.E. relevanten Einstellungen so aus:

        MaxActiveMovesPerSourceMDB="20"
        MaxActiveMovesPerTargetMDB="20"
        MaxActiveMovesPerSourceServer="100"
        MaxActiveMovesPerTargetServer="100"
        MaxActiveJobsPerSourceMailbox="5"
        MaxActiveJobsPerTargetMailbox="2"
        MaxTotalRequestsPerMRS="100"

    Auf den alten Servern

        MaxActiveMovesPerSourceMDB = "5"
        MaxActiveMovesPerTargetMDB = "2"
        MaxActiveMovesPerSourceServer = "50"
        MaxActiveMovesPerTargetServer = "5"
        MaxTotalMovesPerMRS = "100"

    Allerdings ist leider auch das Verschieben eines einzelnen Postfachs langsam und nicht nur das Verschieben von mehreren Postfächern.

    Oder gibt es da noch andere Parameter, auf die ich einen Blick werfen sollte?

    Freitag, 24. Juni 2016 11:22
  • Allerdings ist leider auch das Verschieben eines einzelnen Postfachs langsam und nicht nur das Verschieben von mehreren Postfächern.

    Oder gibt es da noch andere Parameter, auf die ich einen Blick werfen sollte?

    Deswegen sind es ja auch in diesem Fall nicht die relevanten Parameter ;-)

    Ja, da gibt es noch andere, aber als erstes würde ich das Logging einschalten (auch dort in der Datei: SessionStatisticsLogEnabled = true, WLMResourceStatsLogEnabled = true), eine kleine PST reinschieben und gucken, ob da was sinnvolles steht.


    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, 24. Juni 2016 11:50
  • Moin,

    was Du noch machen kannst, ist unterHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchange ResourceHealth den Wert von MRS auf 0 setzen und dann MRS neu starten.


    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.

    Samstag, 25. Juni 2016 20:31
  • Ja, davon hatte ich auch schon gelesen. 

    Allerdings gibt es diesen Registry-Eintrag bei Exchange 2016 nicht. Der komplette Service-Eintrag "MSExchange ResourceHealth" ist nicht mehr vorhanden. 

    Samstag, 25. Juni 2016 22:53
  • Moin,

    was für einen Durchsatz hast du, wenn du von einem Share (z.B. dem alten Exchange) etwas auf den neunen Server kopierst?

    Wenn ich das richtig gelesen habe, ist das eine VM, was ist der Host (Hypervisor), welche Karte ist physisch verbaut?

    Wieviele Cores und RAM hat der 2016, warum habt ihr den noch nicht auf CU2 angehoben?

    ;)


    Gruß Norbert

    Montag, 27. Juni 2016 19:17
    Moderator
  • Den Durchsatz hatte ich oben kurz erwähnt. Etwas über 500 MB/s durchgängig beim Kopieren zwischen den VMs alt und neu.

    Die Hosts sind Teil einer VMWare Farm, haben ESXi 6, je zwei Intel CPUs a 12 Kerne a 2,5 GHz mit HT also 48 Kerne und jeweils 512 GB Ram. Die Hosts sind untereinander über 10G Brocade Switches und 10G Intel Adapter redundant verbunden. 

    Die neuen Exchange VMs sind momentan mit je 8 vCPUs und je 32 GB Ram konfiguriert. 

    CU2 kam leider eine Woche zu spät raus. ;-) Ich plane das mal fürs nächste WE ein. Andererseits hatte ich irgendwie mal den Wunsch, bis dahin die Postfächer schon lange verschoben zu haben. 

    PS: Gruß in die Nachbarschaft. Man sieht sich bestimmt mal wieder beim Port Piet. ;-)

    Montag, 27. Juni 2016 19:27
  • Moin Ingo,

    Mensch, lange nix von dir gehört!

    Alles im Lot - schick doch mal ´ne Mail... ;)

    Einzige Idee wäre, das dir das Offloading bei der VM in die Suppe spuckt, hatte ich jetzt auch ein paar mal, bislang kein Muster erkennbar gewesen.

    Schalte mal Testweise aus, passiert ja nix, allerdings ist die VM für ein paar Sekunden von LAN.
    Ist ja schnell wieder umgestellt. 

    Soll bei VMware und Exchange sowie SQL Best-Practice sein, gibt dazu sogar ein Whitepaper von VMware, müsste ich jetzt aber erst suchen.

    Ich kenne das von verschiedenen Karten.

    ;)


    Gruß Norbert

    PS: der Name ist cool...
    Montag, 27. Juni 2016 20:37
    Moderator
  • Ich habe mittlerweile

    - das Offloading testweise abgeschaltet

    - auf CU2 aktualisiert

    ...aber leider beides ohne Erfolg.

    Mal ein wenig Statistik:

    Name                            : ProcessedStats1
    StartTime                       :
    EndTime                         : 01.07.2016 09:30:09
    MigrationDuration               : 3 day(s) 23:22:03
    MailboxCount                    : 4
    TotalGBTransferred              : 78,97
    PercentComplete                 : 61,79
    MaxPerMoveTransferRateGBPerHour : 1,09
    MinPerMoveTransferRateGBPerHour : 1,01
    AvgPerMoveTransferRateGBPerHour : 1,05
    MoveEfficiencyPercent           : 95,57
    AverageSourceLatency            :
    AverageDestinationLatency       :
    IdleDuration                    : 237,49 %
    SourceSideDuration              : 85,80 %
    DestinationSideDuration         : 10,24 %
    WordBreakingDuration            : 6,22 %
    TransientFailureDurations       : 0,30 %
    OverallStallDurations           : 1,37 %
    ContentIndexingStalls           : 0,00 %
    HighAvailabilityStalls          : 0,00 %
    TargetCPUStalls                 : 0,03 %
    SourceCPUStalls                 : 0,00 %
    MailboxLockedStall              : 1,34 %
    ProxyUnknownStall               : 0,00 %

    Freitag, 1. Juli 2016 07:31