Virtual Study

19 czerwca 2016

Przełączanie baz w ramach DAG

Co miesiąc Microsoft wypuszcza poprawki bezpieczeństwa, a raz na kwartał pojawiają się również paczki poprawek Cumulative Updates dla Exchange. W przypadku serwerów pracujących w ramach DAG wymaga to przełączenia baz na inny serwer oraz kilku dodatkowych operacji. W wielu miejscach można znaleźć skrypty, przygotowujące serwer w DAG do instalacji poprawek i przełączenie baz na inny serwer, np. przygotowane przez Michaela von Horenbeeka.
Dobrze jest jednak zrozumieć mechanizm, wykorzystywany w trakcie przełączania, a także odpowiednio zaplanować sposób przełączania, zwłaszcza w organizacji, gdzie serwery w ramach DAG znajdują się w dwóch lokalizacjach. Poniżej postaram się opisać to zagadnienie na przykładzie dwóch lokalizacji, gdzie w każdej z nich znajdują się dwa serwery - DAG ma 4 serwery.
Pierwszym atrybutem, który odpowiada za odpowiednie przełączanie baz danych w ramach DAG jest DatabaseCopyAutoActivationPolicy, który może mieć trzy wartości - unrestricted, blocked albo intrasiteOnly. Atrybut definiowany jest dla każdego serwera osobno.
W pierwszym przypadku, baza może przełączyć się na dowolną replikę, w tej samej lub drugiej lokalizacji, co może nie być dla nas optymalne w przypadku wyłączenia pojedynczego serwera - baza może się przełączyć do zapasowej lokalizacji, co nie jest naszą intencją (przełączenie do zapasowego ośrodka powinno nastąpić w przypadku niedostępności obu serwerów w ośrodku podstawowym).
W drugim przypadku, jeżeli ustawimy parametr na serwerach w zapasowej lokalizacji na wartość blocked, przełączanie jest zablokowane, co w przypadku awarii jednego serwera w lokalizacji podstawowej wymusi przełączenie na drugi serwer w tej samej lokalizacji ale w przypadku awarii całego ośrodka podstawowego, nie nastąpi przełączenie do zapasowej lokalizacji , czyli również nie uzyskamy wymaganej funkcjonalności.
W przypadku trzeciej wartości atrybutu - intrasiteOnly przełączanie baz danych będzie ograniczone do serwerów w tym samym site, czyli w przypadku awarii całej lokalizacji również nie uzyskamy automatycznego przełączenia do lokalizacji zapasowej.
Z pomocą przychodzi nam drugi atrybut - DatabaseCopyActivationDisabledAndMoveNow. Został on wprowadzony w Exchange 2013 po to, żeby umożliwić realizację przełączenia wymuszonego. W momencie gdy zostanie on ustawiony na $true, a wartość DatabaseCopyAutoActivationPolicy na unrestricted, to po awarii serwera w ośrodku podstawowym, przełączenie na taki serwer będzie możliwe tylko wtedy, gdy nie będzie dostępna inna zdrowa replika bazy danych - czyli zgodnie z założeniami, jeżeli obie repliki w ośrodku podstawowym ulegną uszkodzeniu/wyłączeniu baza przełączy się na serwer w ośrodku zapasowym, a w momencie, gdy jedna z kopii w ośrodku podstawowym uzyska status healthy, zostanie wymuszone przełączenie na ten serwer - czyli automatyczny powrót do ośrodka podstawowego. Zatem żeby bazy były dostępne na serwerach w ośrodku podstawowym i przełączały się automatycznie do ośrodka zapasowego, na wszystkich serwerach w obu ośrodkach musi być ustawiona wartość domyślna polisy AutoActivation (unrestricted) oraz na obu serwerach w ośrodku zapasowym musi być zmieniony atrybut DatabaseCopyActivationDisabledAndMoveNow na wartość $true poprzez wykonanie komendy:
set-mailboxserver -DatabaseCopyActivationDisabledAndMoveNow $true
Oczywiście, żeby automatycznie przełączenie między ośrodkami nastąpiło, File Share Witness musi znajdować się w trzeciej lokalizacji sieciowej.
Bardzo ciekawie to zagadnienie opisał Paul Cunningham na swoim blogu.

Brak komentarzy: