11 września 2011

Migracja skrzynek pocztowych w Exchange 2010

W poprzednich wersjach Exchange do migracji skrzynek pocztowych wykorzystywane było zadanie move-mailbox - dla Exchange 2003 wywoływane najczęściej z konsoli Active Directory Users and Computers (poprzez Exchange Tasks), dla Exchange 2007 wywoływane bezpośrednio z panelu akcji konsoli Exchange Management Console po zaznaczeniu konkretnego usera lub z poziomu management shella poprzez cmdlet move-mailbox. Domyślnie zadanie umożliwiało multitasking – równoległe migrowanie czterech skrzynek, ale gdy uruchomiliśmy zadanie dla innej grupy skrzynek to mogliśmy tę liczbę zwielokrotnić. Ja przeważnie uruchamiałem średnio 4 zadania równolegle, co pozwalało mi na równoległe migrowanie 16 skrzynek. W Exchange 2010 sytuacja wygląda nieco inaczej – dla grupy skrzynek wykonujemy cmdlet new-moverequest, którre to zadanie sprawdza, czy skrzynkę można zmigrować i wrzuca zadanie do kolejki. Osoby, które wykonywały takie zadanie zauważały, że jakbyśmy tego nie realizowali, to po zleceniu realizacji zadania local move request, możemy tylko obserwować kolejkę migrowanych skrzynek, ewentualnie zatrzymać proces migracji. Domyślnie jednak można zauważyć, że jednocześnie migrowane są wyłącznie dwie skrzynki.

Cy możemy to zmienić? Jeżeli lepiej przyjrzymy się procesom realizowanym przez serwer to okaże się, że możemy znacząco “podkręcić” szybkość migracji. Za proces migracji skrzynek odpowiedzialna jest usługa Mailbox Replication Service (MRS), która jest uruchomiona na wszystkich serwerach Exchange 2010 z rolą Client Access. MRS jest również odpowiiedzialna za import i export danych z plików .pst, a także odtwarzanie skasowanych lub odpiętych skrzynek. Konfiguracja MRS jest możliwa do zmiany poprzez edycję pliku konfiguracyjnego MSExchangeMailboxReplication.exe.config, który domyślnie możemy znaleźć w katalogu <Exchange Installation Path>\Program Files\Microsoft\Exchange Server\V14\Bin\.

W pliku (który musimy otworzyć na eskalowanych uprawnieniach) znajduje się sekcja MRSConfiguration, w którym możemy modyfikować parametry migracji. Jak dla mnie najistotniejsze są parametry:

  • MaxActiveMovesPerSourceMDB   - Ile równoległych zadań może być realizowanych dla źródłowej bazy danych (eksport, migracja, etc). Możliwe są wartości z przedziału od 0 do 100. Domyślna ilosć to 5 równoległych zadań.
  • MaxActiveMovesPerTargetMDB - Ile równoległych zadań może być realizowanych dla docelowej bazy danych (import, migracja, odtwarzanie). Możliwe są wartości z przedziału od 0 do 100. Domyślna ilosć to 2 równoległe zadania.
  • MaxActiveMovesPerSourceServer - Ile równoległych zadań może być realizowanych przez MRS dla docelowego serwera. Możliwe są wartości z przedziału od 0 do 1000. Domyślna ilość to 50 równoległych zadań.
  • MaxActiveMovesPerTargetServer - Ile równoległych zadań może być realizowanych przez MRS dla docelowego serwera (import, migracja, etc). Możliwe są wartości z przedziału od 0 do 1000. Domyślna ilość to 5 równoległych zadań.
  • MaxTotalMovesPerMRS   - Ta wartość określa ilość zadań, które może jedna instancja MRS realizować równolegle. Możliwe są wartości z przedziału od 0 do 1024. Domyślna ilość to 100 równoległych zadań.

Pełna lista modyfikowalnych parametrów znajduje się na stronie pomocy technicznej dla Exchange 2010. Wystarczy zatem zwiększyć parametr MaxActiveMovesPerTargetMDB z 2 do 10, żeby dla jednej bazy docelowej mieć 10 migrowanych skrzynek równolegle. Dla 5 baz docelowych i 5 źródłowych da nam to 50 równoległych zadań migracyjnych.

UWAGA: Nie jest wymagany restart żadnych serwisów – MRS od razu zauważy zmianę parametrów i uruchomi kolejne wątki.

Zwiększając ilość wątków migracyjnych musimy pamiętać o ograniczeniach, szczególnie, gdy docelowy serwer ma bazy działające w ramach DAG. Exchange Active Manager stara się ograniczać sytuacje, gdy CopyQueueLength rośnie powyżej 10 plików, a także ReplayQueueLength nie powinien przekroczyć 50.

Na szybko, żeby nie mieć dodatkowych problemów w trakcie migracji można tymczasowo wyłączyć weryfikację dla docelowych baz danych komendą (znowu nie ma potrzeby restaru usług):

Set-MailboxDatabase -DataMoveReplicationConstraint None

Po zakończeniu migracji powiinniśmy jednak ponownie włączyć weryfikację parametru:

Set-MailboxDatabase -DataMoveReplicationConstraint SecondCopy

Brak komentarzy: