Procedury odtwarzania usług w farmie SharePoint
Slaba motywacja moze wynikac z niezrozumienia zlozonosci lub krytycznosci systemu…
Dlaczego wiele przedsiebiorstw nie posiada udokumentowanych i przetestowanych planów odtwarzania uslug? Bo nie dysponuje odpowiednim budzetem, nie posiada srodowiska testowego, zdaniem wlasciciela usluga nie jest wystarczajaco krytyczna, itd. Jezeli utrzymujesz lub jestes wlascicielem uslug dzialajacych w farmie SharePoint, kontynuuj prosze lekture. Mam nadzieje, ze zachece Cie do stworzenia, zweryfikowania i przetestowania procedur odtwarzania uslug.
Wezmy pod uwage typowa wieloserwerowa farme SharePoint Server 2007/2010/2013. Uzytkownicy korzystaja ze standardowych uslug SharePoint. Dodatkowo srodowisko uzywane jest, jako platforma aplikacyjna hostujaca rozwiazania tworzone przez programistów.
Jak wiemy, SharePoint Server jest produktem udostepniajacym bardzo szeroki wachlarz funkcji i uslug, z których moze korzystac przedsiebiorstwo, m.in.:
- zarzadzanie dokumentami, wiedza i trescia
- wyszukiwarka przedsiebiorstwa
- platforma intranetowa lub internetowa firmy
- inteligentna platforma biznesowa
- platforma aplikacyjna.
Przykladów wykorzystania produktu jest wiele, ale bardzo prawdopodobne jest to, ze w zaleznosci od dojrzalosci firmy, szybciej lub nieco pózniej, SharePoint stanie sie bardzo krytycznym srodowiskiem, wymaganym do prawidlowego funkcjonowania przedsiebiorstwa. Wlasciciel uslugi, powinien zapewnic odpowiednia dostepnosc systemu tak, aby ewentualne przerwy w dzialaniu uslugi w minimalnym stopniu zagrozily funkcjonowaniu przedsiebiorstwa.
Mam kopie zapasowe i nie zawaham sie ich uzyc!
Jak najczesciej wykonujemy kopie zapasowe farmy SharePoint? Nie znam dokladnych statystyk, ale z moich doswiadczen, dosc popularne sa dwa sposoby:
- kopie zapasowe wszystkich baz danych SharePoint
- kopie zapasowe wirtualnych maszyn (o ile wirtualizacja jest wykorzystywana w farmie)
Jaki jest problem z tymi kopiami bezpieczenstwa? W przypadku wystapienia pewnych scenariuszy awarii, mozemy nie byc w stanie z nich skorzystac (bo sa nie wspierane), albo tak wykonane kopie nie wystarcza do pelnego odtworzenia uslugi.
Po kolei, zacznijmy od baz danych. Przede wszystkim, odtwarzanie niektórych typów baz danych w SQL Server nie jest wspierane. Przykladowo odtwarzanie bazy danych konfiguracji moze spowodowac, ze jej stan nie bedzie zgodny ze stanem pewnych obiektów znajdujacych sie np. w bazach danych uslug lub zawartosci; albo ze stanem plików konfiguracyjnych przechowywanych na serwerach w farmie (np. pliki cache procesu OWSTimer). Inny przyklad, to odtwarzanie bazy danych uslugi wyszukiwania. Operacja nie jest wspierana, bo moze spowodowac powstanie osieroconych obiektów w bazie danych konfiguracji oraz prawdopodobnie sprawi, ze indeks pelnotekstowy znajdujacy sie na dysku bedzie niezgodny z zawartoscia odtworzonej bazy danych.
Jaki jest problem z uzywaniem kopii zapasowych wirtualnych maszyn lub snapshot’ów? Tego typu podejscie swietnie sprawdza sie, gdy jest wykonywana zmiana w srodowisku i chcemy sie przed nia zabezpieczyc. Wtedy przy wylaczonych serwerach SharePoint, wykonujemy kopie zapasowe lub snapshot’y wszystkich serwerów oraz baz danych SharePoint. Gdy potrzebujemy powrócic do poprzedniego stanu farmy, mozemy skorzystac z wykonanych wczesniej kopii zapasowych.
Snapshot’y lub kopie zapasowe wirtualnych maszyn nie powinny byc jednak wykonywane na dzialajacych serwerach SharePoint, bo nie jestesmy w stanie zagwarantowac spójnosci pomiedzy serwerami oraz bazami danych SharePoint. Przykladowo tego typu podejscie moze spowodowac, ze indeks wyszukiwania znajdujacy sie na serwerach w roli obslugi kwerend, moze nie byc zgodny ze stanem bazy danych wyszukiwania. Moze równiez dojsc do rozsynchronizowania sie lokalnych plików cache uslugi OWSTimer z bazami danych.
Z jakich kopi zapasowych powinnismy w takim razie korzystac? Oczywiscie z takich, które zawsze zagwarantuja nam odtworzenie uslugi podczas wystapienia okreslonych scenariuszy awarii w czasie zgodnym z SLA (service level agreement) zdefiniowanym dla naszej uslugi. Narzedzi jest wiele. Przykladowo mozemy uzywac starego i dobrego narzedzia stsadm -o backup/restore w produkcie MOSS 2007 lub nowszego odpowiednika, cmdlet’ów Windows PowerShell, Backup-SPFarm I Restore-SPFarm w SharePoint 2010/2013. Farma SharePoint moze byc równiez chroniona za pomoca narzedzia Microsoft Data Protection Manager.
Wiedze mam w glowie i wydaje mi sie, ze to wystarczy
Jedna z uslug, która regularnie dostarczam, jest wsparcie przy planowaniu kopii zapasowych, tworzeniu oraz testowaniu procedur odzyskiwania srodowiska. Z doswiadczenia wiem, ze bez udokumentowanego i przetestowanego planu odtwarzania, moze okazac sie, ze w sytuacji kryzysowej dzial IT nie jest w stanie szybko odtworzyc serwera, uslugi lub farmy SharePoint. Moze to wynikac z np.:
- braku udokumentowanej procedury odtwarzania dla scenariusza awarii, który wystapil
- blednej i nieprzetestowanej procedury odtwarzania
- niekompletnej wiedzy dotyczacej konfiguracji farmy oraz zmian wykonanych na serwerach
- braku dokumentacji opisujacej konfiguracje farmy SharePoint.
Czy jestescie przygotowani na odtwarzanie uslug hostowanych w farmie SharePoint w nastepujacych sytuacjach?
- Awaria serwera webowego, na który zostaly wdrozone niestandardowe rozwiazania
- Awaria serwera aplikacyjnego, na którym dzialaja uslugi SharePoint
- Awaria serwera bazodanowego
- Wystapienie niespójnosci (na poziomie plikowym) w bazach danych róznych typów
- Niewlasciwie wdrozona w farmie zmiana, której cofniecie nie jest wspierane
- Koniecznosc odtworzenia bazy danych zawartosci do konkretnego miejsca w czasie
- Koniecznosc odtworzenia pojedynczego dokumentu, witryny, zbioru witryn
W zaleznosci od sposobu wykonywania kopii zapasowych, z którego korzystacie, moze okazac sie, ze ww. operacje sa bardzo skomplikowane lub nawet nierealizowalne. Na przyklad, gdy posiadacie tylko kopie zapasowe wszystkich baz danych i musicie odtworzyc cala farme (przywrócic pierwotna topologie serwerów, konfiguracje farmy oraz niestandardowe zmiany wykonane na serwerach).
OK, napisze procedure… tylko jak?
Typowa procedura odtwarzania zawiera nastepujace informacje:
1) Cel procedury
2) Definicje terminów uzytych w dokumencie
3) Wydarzenia wyzwalajace wykonanie procedury
4) Kroki procedury oraz role odpowiedzialne za ich wykonanie
5) Kroki weryfikujace poprawnosc wykonania procedury
6) Informacje o powiazanych dokumentach, plikach i lokalizacjach
Procedura powinna byc napisana w taki sposób, aby dowolna osoba techniczna zajmujaca sie utrzymaniem uslugi, nie miala watpliwosci jak wykonac poszczególne kroki. To bardzo ogólny opis, ale prawdziwy niezaleznie od tego, czy procedura bedzie zawierala 40 kroków wykonywanych manualnie, czy moze w ramach niej zostanie uruchomiony pojedynczy skrypt Windows PowerShell.
Podsumowujac zagadnienie…
Bardzo chcialbym Was zachecic do zweryfikowania swoich procedur odtwarzania uslug i zastanowienia sie, czy sa one kompletne oraz realizowalne, biorac pod uwage aktualna konfiguracje srodowiska oraz typy wykonywanych kopii zapasowych. Nastepnie goraco zachecam do przetestowania tych procedur w srodowisku nieprodukcyjnym i upewnienie sie, ze procedury sa rzeczywiscie prawidlowe oraz gwarantuja dotrzymanie ustalen opisanych w umowie SLA.
Nie zycze nikomu koniecznosci korzystania z procedur odzyskiwania uslug, ale jak dobrze wiemy, na swiecie nie ma rzeczy idealnych. Nie ma bezawaryjnych serwerów oraz macierzy dyskowych, niemylacych sie programistów oraz administratorów systemów, bezblednych programów oraz idealnie dzialajacych procesów IT. Jestes wlascicielem uslugi? Stwórz i przetestuj procedury odtwarzania uslugi w róznych scenariuszach wystapienia awarii. Badz
proaktywny i spij spokojnie.
Zródlo: https://dilbert.com/strips/comic/2000-08-15/
Przy okazji polecam zapoznanie sie z nastepujacymi artykulami:
Plan for business continuity management (SharePoint Server 2010)
Plan for backup and recovery in SharePoint Server 2010
How to protect SharePoint with DPM 2010 whitepaper
Best practices for virtualization: Do not use snapshots in a production environment