Instalacja poprawek dla Skype for Business (wcześniej również dla Lync) z pozoru jest prostym zadaniem dla administratora. W przypadku systemu operacyjnego, lokalnych instancji SQL Express czy np. .Net Framework instalacja aktualizacji czy poprawek proces jest stosunkowo prosty z punktu widzenia technicznego i jeżeli nie wymaga restartu serwera, to dla użytkowników systemu nie ma przerwy w dostępie do usług. Instalacja poprawek dla Skype for Business wymaga wyłączenia usług na danym serwerze, a to już użytkownicy zauważą. Jeżeli system pracuje w godzinach biurowych jako platforma komunikacji IM, to nie jest to duży problem. Jednak w przypadku gdy system świadczy również usługi głosowe i konferencyjne, a na dodatek musi pracować w trybie 7x24, to wymagane są nie tylko dodatkowe serwery - poole typu Enterprise, ale i dodatkowe kroki przygotowawcze.
Zespół produktowy Skype for Business (wcześniej również Lync) wyszedł naprzeciw oczekiwaniom bardziej wymagających klientów i wprowadził mechanizmy zarówno wysokiej dostępności, połączonej z rozłożeniem obciążenia - wieloserwerowe pule typu Enterprise (rysunek poniżej)
jak i disaster recovery (jakoś nie przepadam za polskim tłumaczeniem tego określenia) realizowane poprzez parowanie pul (kolejny rysunek).
Parowanie pul polega na replikowaniu informacji o użytkownikach rejestrujących się w danej puli i w przypadku awarii przełączenie ich na zapasową bazę w drugiej puli, co pozwala w miarę bezproblemowo kontynuować pracę (w trakcie przełączenia użytkownik jest na chwilę wylogowywany). Konfigurację taką można zastosować nawet na pulach typu standard (parowanie działa w obie strony, czyli użytkownicy pracują w obu pulach, które nawzajem się zabezpieczają).
Wdrożenie pul wieloserwerowych wymaga znaczącego zwiększenia kosztów wdrożenia - dodatkowe maszyny Windows Server, licencje na dodatkowe serwery Skype for Business, obowiązkowy load balancer oraz zewnętrzny serwer SQL w wersji co najmniej Standard. Oczywiście chcąc zapewnić pełną wysoką dostępność SQL powinien być również wdrożony w konfiguracji clustrowej (dla Skype for Business 2019 mirroring nie jest wspierany, zalecana konfiguracja to grupy Always On). Jednak w przypadku środowiska, gdzie Skype for Business jest podstawową platformą komunikacyjną i konferencyjną, jest to naprawdę dobra inwestycja.
Mając sparowane pule serwerowe możemy wykonać operację pool failover na czas instalacji poprawek, a po jej zakończeniu failback, wtedy użytkownik tylko na czas przełączenia na chwilę traci dostęp do zasobów.
Trochę wstęp mi się rozwinął, więc więcej szczegółów na temat procedur operacyjnych przedstawię w drugiej części artykułu.
Zespół produktowy Skype for Business (wcześniej również Lync) wyszedł naprzeciw oczekiwaniom bardziej wymagających klientów i wprowadził mechanizmy zarówno wysokiej dostępności, połączonej z rozłożeniem obciążenia - wieloserwerowe pule typu Enterprise (rysunek poniżej)
jak i disaster recovery (jakoś nie przepadam za polskim tłumaczeniem tego określenia) realizowane poprzez parowanie pul (kolejny rysunek).
Parowanie pul polega na replikowaniu informacji o użytkownikach rejestrujących się w danej puli i w przypadku awarii przełączenie ich na zapasową bazę w drugiej puli, co pozwala w miarę bezproblemowo kontynuować pracę (w trakcie przełączenia użytkownik jest na chwilę wylogowywany). Konfigurację taką można zastosować nawet na pulach typu standard (parowanie działa w obie strony, czyli użytkownicy pracują w obu pulach, które nawzajem się zabezpieczają).
Wdrożenie pul wieloserwerowych wymaga znaczącego zwiększenia kosztów wdrożenia - dodatkowe maszyny Windows Server, licencje na dodatkowe serwery Skype for Business, obowiązkowy load balancer oraz zewnętrzny serwer SQL w wersji co najmniej Standard. Oczywiście chcąc zapewnić pełną wysoką dostępność SQL powinien być również wdrożony w konfiguracji clustrowej (dla Skype for Business 2019 mirroring nie jest wspierany, zalecana konfiguracja to grupy Always On). Jednak w przypadku środowiska, gdzie Skype for Business jest podstawową platformą komunikacyjną i konferencyjną, jest to naprawdę dobra inwestycja.
Mając sparowane pule serwerowe możemy wykonać operację pool failover na czas instalacji poprawek, a po jej zakończeniu failback, wtedy użytkownik tylko na czas przełączenia na chwilę traci dostęp do zasobów.
Trochę wstęp mi się rozwinął, więc więcej szczegółów na temat procedur operacyjnych przedstawię w drugiej części artykułu.
