niedziela, 14 listopada 2010

ISM - Zarządzanie infrastrukturą storage

Podobnie jak sprawy związane z monitoringiem, tak samo zarządzanie storage można podzielić na cztery obszary:
  • Avaliablity
  • Capacity
  • Performance
  • Security

Avaliability Management:

Podstawowy zadaniem z działki zarządzania dostępnością urządzeń storage jest zapewnienie im braku tzw: SPOFów (Single Point of Failure), których obecność jest zagrożeniem dla ciągłości działania danego urządzenia.

Metody zapobiegania SPOFów to między innymi:
  • Dwie lub więcej niezależnych kart HBA po stronie hosta
  • Używanie oprogramowania do multipathingu
  • Używanie struktur RAID
  • Używanie dwóch niezależnych fabriców
Poprawne skonfigurowanie replikacji oraz polityki tworzenia backupów także wchodzi w skład zarządzania dostępnością. Technologie wirtualizacji mogą być pomocne przy tworzeniu architektury oraz planów działania podczas awarii (dynamiczne przydzielanie/usuwanie zasobów)


Capacity Management:

Głównym zadaniem zarządzania Capacity jest zapewnienie, że zapewniona będzie wystarczająca ilość zasobów. Podstawowe metody sprawdzania i zapewniania wystarczającej ilości zasobów to:

  • Analiza trendów zużycia zasobów
  • Odpowiednie przydzielanie (provisioning) zasobów

Performance Management:

Prawidłowe zarządzanie wydajnością jest potrzebne aby optymalnie i z maksymalna efektywnością wykorzystać dostępne zasoby, dzięki niemu możemy wykrywać wąskie gardła w naszym systemie.

Główne zadania zarządzania wydajnością to:
  • po stronie hosta: zarządzanie wolumenami, oraz architekturą bazy danych i aplikacji
  • po stronie sieci SAN: Zapewnienie wystarczającej ilości ISL z odpowiednią przepustowością
  • po stronie macierzy: Wybór typów struktur RAI , wybór rozłożenia LUNów po portach front-end


Security Management:

Pozwala na kontrolowanie dostępu do urządzeń storage.

Główne zadania:
  • po stronie hosta: tworzenie kont użytkowników, zarządzanie dostępami
  • po stronie sieci SAN: konfiguracja zoningu
  • po stronie macierzy: tworzenie kont do zarządzania macierzą, konfiguracja maskowania


Wyzywania w zarządzaniu infrastrukturą storage:

Głównym problemem w kompleksowym zarządzaniu pamięciami masowymi jest fakt, że ich środowisko może obejmować wiele różnych warstw ( bazy danych, serwery, sieć, urządzania storage ), a w każdej z nich możliwe są rozwiązania multi-vendor, w czasem bardzo skomplikowanych konfiguracjach. Macierze mogą po sieciach (zarówno SAN jak i IP ) wystawiać zasoby do najróżniejszych systemów takich jak: UNIX, Windows czy nawet komputerów klasy mainframe. Całe te, działające na różnych poziomach, środowisko, jest bardzo trudne do zarządzania i zwykle używanych jest do tego celu wiele niezależnych narzędzi.

Rozwiązaniem problemów ze zbytnią złożonością i wielością narzędzi używanych do zarządzania storage jest zintegrowanie ich w jeden centralny system zarządzania i monitorowania.
System ten powinien spełniać następujące wymagania:

  • musi zbierać informacje z wszystkich komponentów i być w stanie zarządzać nimi za pomocą jednego interfejsu
  • musi być w stanie przeprowadzić analizę wpływu awarii jednego komponentu na działania pozostałych
  • musi mieć zaimplementowany mechanizm powiadamianie (np: poprzez email lub SNMP) o zaistnieniu pewnych zdefiniowanych wydarzeń, musi być także w stanie generować raporty ogólne i per komponent
Aby ułatwić stworzenie tego rodzaju oprogramowania SNIA (Storage Networking Industry Association) stworzyła tzw: SMI-S ( Storage Management Initiative Specification), który jest abstrakcyjnym modelem opisującym sposoby zarządzania i monitorowania zasobów strorage. Model ten może być adaptowany następnie do konkretnych rozwiązań. Pozwala to na stworzenie jednego oprogramowania do zarządzania całością zasobów storage, a jednocześnie zgodność z modelem SMI-S sprawia, że sprzęt i oprogramowanie różnych  (ale przestrzegający wytycznych tego modelu) producentów będzie dobrze współpracowało z takim centralnym systemem.

Takie centralne aplikacje stworzone do zarządzania i monitorowania całej infrastruktury używanej w danym przedsiębiorstwie noszą nazwę EMP ( Enterprise Management Platform) - przykładem takiego systemu jest EMC ControlCenter.



I w ten sposób dotarliśmy do końca kursu przygotowującego do egzaminu ISM (e20-001)
Co dalej?
Najpierw powtórzę sobie cały ten materiał raz albo i dwa razy, potem przystępuję do egzaminu i mam nadzieję zostanę EMC Proven :D
Co dalej z blogiem?
W tej chwili raczej skupię się na przygotowaniach do certyfikatu, więc pisał będę mniej, pewnie pojawia się jakieś wpisy nie związane z samymi egzaminami EMC, tylko ogólnie na tematy "metastorage"-owe, ale nie wiem ile ich będzie i jak często będą publikowane.
Jeżeli uda mi się certyfikować, to od razu siłą rozpędu zaczynam przygotowywać się do kolejnego certu, najprawdopodobniej z Clariiona - ale to jeszcze daleka przyszłość.


sobota, 13 listopada 2010

ISM - Monitorowanie infrastruktury storage

Monitorowanie urządzeń storage powinno dotyczyć czterech obszarów:

  • Dostępności (Accessibility)
  • Zasobów (Capacity)
  • Wydajności (Performance)
  • Bezpieczeństwa (Security)
Dostępność (Accessibility)

O dostępności komponentu mówimy kiedy pracuje on prawidłowo, bez żadnych zakłóceń i awarii. Monitorowanie dostępności zwykle opiera się na ustawieniu pewnych predefiniowanych alarmów, dotyczących prawidlowego działania. Alarmy te definiuje na samym urządzeniu (SAN device, HBA, port, dysk, macierz, element oprogramowania) i są one przechwytywane wystąpienia. Szybkie wykrywanie i naprawa niedostępnych z powodu awarii komponentów, chroni nas przed uszkodzeniem i utratą ciągłości działania całego systemu.


Zasoby (Capacity)

Capacity odnosi się do ilości zasobów storage jakie są dostępne. Przykładami monitorowania Capacity jest np. sprawdzanie ilości wolnego miejsca na systemie plikow lub zużycie quoty na skrzynce pocztowej. Brak monitorowania Capactiy może doprowadzić do problemów wydajnościowych lub nawet dostępności danej aplikacji (przepełnienie). Zwykle dane uzyskane z monitoringu Capacity analizuje się pod względem trendów i według nich planuje przyszłą strategię zakupową dla obszaru storage.


Wydajność(Performance)

Monitorowanie wydajności jest to sprawdzanie jak efektywnie pracują nasze zasoby i w których miejscach mamy tzw "wąskie gardła". Pomiary wydajności, zwykle, polegają na cyklicznym sprawdzaniu różnych parametrów i porównywaniu ich do predefiniowanych wartości. Przykłady zasobów i parametrów jakie można objąć monitoringiem wydajnści to np: Ilość I/O do dysków , czas odpowiedzi aplikacji , utylizacja sieci itd...


Bezpieczeństwo (Security)

Monitorowanie bezpieczeństwa pozwala na wykrycie i zapobieganie nieautoryzowanych prób dostępu. Pomaga także przy śledzeniu nieplanowancyh/nieautoryzowanych zmian wykonywanych w elementach infrastruktury storage. Monitorowanie bezpieczeństwa zapewnia, że nasze dane pozostają poufne, spójne i dostępne. Może ono odbywać się na poziomie software ( np: śledzenie zmian w konfiguracji storage ) jak i  być monitorowaniem fizycznym ( czytniki kart, kamery w halach z macierzami itd...)


Monitorowanie hostów:

Serwery szczególnie te z aplikacjami typu mission-critical powinny być stale monitorowane.
Poszczególne zakresy monitoringu hostów obejmując:

  • Accessibility ( komponenty hardware: HBA,NIC,dyski wewnętrzne ; status kluczowych procesów i usług)
  • Capacity (utylizacja systemu plików, użycie table spaców i log space w bazach , zużycie quoty )
  • Performance ( Utylizacja CPU i pamięci , czasy odpowiedzi )
  • Security ( Autoryzacje i czasy logowań - szczególnie na konta root/administrator )

Monitorowanie sieci SAN:

Poszczególne zakresy monitoringu dla sieci SAN obejmują przykładowo:
  • Accessibility ( Fizyczne elementy sieci SAN i ich komponenty - zasilacze, wentylatory w switchach itd ; błędy pojawiające się w komunikacji w fabricu i zonie )
  • Capacity ( Utylizacja ISL i portów )
  • Performance ( utylizacja portów , monitorowanie opóźnień w sieci i utraty pakietów )
  • Security ( Zoning i LUN Masking , monitorowanie bezpieczeństwa fizycznego środowiska SAN)

Monitorowanie macierzy dyskowych:
  • Accessibility ( Wszystkie elementy hardware maszyny + jej wewnętrzny system operacyjny)
  • Capacity ( surowa i skonfigurowana przestrzeń , ilość przestrzeni zaalokowanej )
  • Performance ( Utylizacja portów FE i BE , czasy odpowiedzi, zużycie cache )
  • Security ( Bezpieczeństwo fizyczne , monitorowanie logowania na macierze )



Sam temat zawierał jeszcze dość dużo przykładów i różnych scenariuszy ( np: analizę dla uszkodzenia portu, HBA, switcha dla monitoringu accessibility), ale były to materiały bardzo ciężkie do wykorzystania bez kopiowania powiązanych z nimi grafik(schematów).
Ogólnie nie było tam nic odkrywczego, tylko sprawy oczywiste typu: "uszkodzenie ścieżki powoduje, że dane są przesyłane drugą z nich"

Kolejny temat to zarządzanie infastrukturą storage.

poniedziałek, 8 listopada 2010

ISM - Rozwiązania zapewniające bezpieczeństwo dla sieci SAN , NAS i IP-SAN

Zapewnienie bezpieczeństwa w sieci SAN

W tradycyjnych sieciach SAN bezpieczeństwo było zapewniane przez odizolowanie jej od sieci LAN i świata zewnętrznego. Obecnie jednak sieci SAN są coraz bardziej zintegrowane z resztą infrastruktury i nie stanowią już odrębnego środowiska. Aby zmniejszyć negatywny wpływ na bezpieczeństwo, jaki ma taka połączenie tych środowisk, wprowadzono protokół FC-SP (Fibre Channel Security Protocol), implementujący mechanizmy zabezpieczenia na styku sieci IP i LAN.
Inną metodologią zabezpieczani sieci storage (SAN , IP-SAN, NAS) jest tzw "defense-in-depth" - polega to używaniu wielu współpracujących ze sobą warstw bezpieczeństwa. Kompromitacja i spenetrowanie przez intruzów jednej z takich warstw, nie ma wpływu na inne, które dalej chronią zasoby sieci storage.


Podstawowe mechanizmy ochrony sieci SAN:

Sposoby ochrony sieci SAN można podzielić na kilka podkategorii:
  • Array-based Volume Access Control
  • Security on FC Switch Port
  • Switch-wide and Fabric-wide Access Control
  • Logical Partitioning on a Fabric: VSAN


Array-based Volume Access Control:
Są to metody, które chronią przed niepowołanym dostępem do urządzeń storage. Dwa najbardziej popularne rozwiązania tego typu to: LUN Masking i mechanizmy Zoningu
Tworzenie zon w sieci  polega na dzieleniu (logicznym) sieci SAN na mniejsze kawałki. Urządzenia zarówno source( hosty) jaki i target (macierze) widzą i są w stanie wymienić informacje jedynie z urządzeniami w tej samej zonie.
Zoning może występować w dwóch odmianach:
  • Hard/port zoning - zony są zestawiane pomiędzy portami na hostach (lub switchach) a portami na macierzy. 
  • Soft/WWN zoning - zony są zestawiane pomiędzy urządzeniami o określonych adresach WWN. Jest to rozwiązanie nieco mniej bezpieczne niż hard zoning - można wyobrazić sobie, iż intruz udaje WWN jednego z członków zony, aby zostać uprawnionym do nasłuchiwania na ruch w niej. Dla porównania przy zastosowaniu hard zoningu musiałby fizycznie odpiąć hosta z zony i wpiąć się w jego miejsce.
Tak jak zoning pozwala kontrolować dostęp danych hostów do macierzy, tak LUN masking pozwala na kontrolę dostępu do poszczególnych LUNów, wystawianych z macierzy. Robi to filtrując listę LUNów do których danych HBA ma dostęp. Silniejszą wersją LUN Maskingu obecną w macierzach EMC Symmetrix jest S_ID Lockdown

Security on FC Switch Ports:
Jest to grupa zabezpieczeń związanych z ustawieniami portów na switchach. Można wśród nich wyróżnić:
  • Port Binding - ogranicza liczbę urządzeń, które mogą używać danego portu do logowania się do fabrica. Ogranicza to zagrożenie WWPN spoofingiem przy soft zoningu.
  • Port Lockdown, Port Lockout - metody ograniczające sposób w jaki dany port może być wykorzystany. Pożna np: wyłączyć możliwość stworzenia połączenia switch-switch albo podłączenia pętli FCAL.
  • Persistent Port Disable - zapobiega włączeniu portu po reboocie switcha.


Switch-wide and Fabric-wide Access Control:
Ta kategoria opisuje mechanizmy kontroli dostępu do sieci SAN i zawiera w sobie następujące rozwiązania:
  • Access control lists - kontroluje podłączenia do SANów i autoryzuje je na podstawie zdefiniowanych polityk. Reguły opisują które HBA i porty macierzy oraz switche mogą być częścią sieci SAN i odcinają urządzenia nieuprawnione.
  • Fabric binding - chroni przed nieautoryzowanym dołączeniem do fabrica zewnętrznego switcha
  • Role-based access control - określa jaki użytkownik i z jakimi uprawnieniami może logować się do poszczególnych urządzeń w fabricu.


Logical Partitioning on a Fabric: VSAN
Mechanizm VSANów jest odpowiednikiem VLANów w sieci Ethernet - polega on na podzieleniu jednej fizycznej sieci SAN, na niezależne od siebie logiczne części. Ruch danych jest możliwy tylko w obrębie jednego VSANu; każdy port (switch, host, array) może należeć tylko do jednego VSANu.
Takie rozdzielenie urządzeń w sieci SAN pozwala na lepszą kontrolę nad dostępami i przepływem danych.


Zapewnienie  bezpieczeństwa w sieci NAS:

Sieć NAS może być narażona na wiele różnych niebezpieczeństwa takich jak na przykład: wirusy , nieuprawniony dostęp , podsłuchiwanie transmisji itd...
Pierwszym poziomem zabezpieczenia są tzw ACLs ( Access Control Lists) określające jakie uprawnienia mają poszczególni użytkownicy. Dane te są następnie uzupełniane o prawa i atrybuty powiązane z plikami i folderami w sieci. Kolejne poziomy bezpieczeństwa są zapewniane przez dodatkowe mechanizmy autoryzacji (np: Kerberos) i ochrony przed nieuprawnionym dostępem (np: firewalle)

Uprawnienia do plików w Windows:
Windows wspiera dwa rodzaje list ACL : discretionary access control lists (DACL) i system access control lists (SACL)
DACL - jest używany do wyznaczenia kto ma dostęp do plików , SACL określa jakiego rodzaju dostęp ma być audytowany (jeżeli audytowanie jest włączone). Dodatkowo w Windows istnieje pojęcie właściciela objektu - które to nadaje właścicielowi prawa do danego pliku nawet jeżeli listy DACL i SACL takiego dostępu zabraniają. Windows wspiera również dziedziczenie uprawnień, pomiędzy objektami przodkami a potomkami.
Każdy użytkownik i grupa jest identyfikowana po unikalnym numerze SID - przydzielanie i sprawdzanie uprawnień odbywa się bazując na tym atrybucie, nie na nazwie pod jaką dany user występuje w systemie.

Uprawnienia do plików w Unixie:
Podstawowymi prawami do plików w systemach Unix/Linux sa odczyt/zapis/wykonanie (Read/Write/Execute). Dla każdego pliku i folderu te prawa określone są na 3 poziomach: właściciel , właściciel grupowy , inni.

Autentyfikacja i autoryzacja współdzielonych plików:
Urządzenia NASowe używają dwóch standardowych protokołów do współdzielenia plików: NFS i CIFS. Autentyfikacja użytkownika próbującego się dostać do zasobów jest wykonywana przez pewien centralny system jak np Network Information System na systemach Unix czy Active Directory w Windowsach.
Autoryzacja określa czy dany (autentyfikowany) użytkownik ma prawo uzyskać dostęp do danego zasobu. Sposoby opisu dostępu do pliku różnią się w przypadku systemów Unixowych ( dostęp typu: rwxrwxrwx) a systemach Windowsowych (listy ACL). Jeżeli jedno urządzenie powinno wystawiać pliki zarówno dla hostów Windowsowych jak i Unixowych to musi ono obsługiwać mappowanie pomiędzy sposobami określania dostępu do zasobów.

Kerberos:
Kerberos jest to sieciowy protokół do autentyfikacji. Został zaprojektowany aby zapewnić bezpieczną autentyfikację dla aplikacji typu klient/serwer i opiera się na silnych algorytmach kryptograficznych. Jego założeniem jest umożliwić przeprowadzenie autentyfikacji klienta na serwerze poprzez niechronioną sieć.
W zastosowaniach związanych z NASami, Kerberos zwykle wykorzystywany jest przy autentyfikacji użytkowników z Active Directory.
Kerberos działa w architekturze klient-serwer. Klientem może być np: użytkownik lub host który otrzymuje service ticket. Kerberos serwer jest zwany także Key Distribution Center(KDC)

Przykładowy procesy autoryzacji z wykorzystaniem Kerberosa w środowisku skladającym się z 4 jednostek:
  • NAS Device (1)
  • Windows Client (2)
  • KDC (3)
  • Active Directory (4)
Proces autoryzacji:

Krok 1:
Użytkownik loguje się do stacji roboczej będącej częścią domeny, używając swojego ID i hasła. Następnie jego komputer wysyła do Autentication Service (AS) na KDC żadanie przesłania ticketu. KDC weryfikuje ID użytkownika w AD.
          
(2) -------ID Proof-------->(3)

Krok 2:
KDC odpowiada poprzez TGT (Ticket Granting Service). Transmisja składa się z dwóch części, jedna może być odkodowana przez klienta, druga przez KDC.

(2)<----------TGT-----------(3)

Krok 3:
Kiedy klient otrzyma TGT odsyła je do serwera KDC wzbogacone o informację na temat zasobu do którego się chce dostać.

(2)---------TGT+Server name----->(3)

Krok 4:
KDC sprawdza uprawnienia użytkownika do danego zasobu w AD

(3)-------------->(4)


Krok 5:
KDC wysyła service ticket do klienta.

(2) <--------Service Ticekt-------(3)

Krok 6:
Klient wysyła Service Ticket do zasobu z którego chce korzystać ( w naszym przypadku macierz NAS)

(2) ------Service Ticekt-------->(1)

Krok 7:
NAS udostępnia zasoby klientowi


Firewalle warstwy sieci:
NAS wykorzystuje sieć IP do przesyłu swoich danych, dlatego też zagrożenia występujące przy używaniu protokołu IP, odnoszą się także do wymiany danych poprzez macierzy NASową.
Jednym z podstawowych zabezpieczeń jest użycie firewalla i filtrowanie przychodzącego i wychodzącego ruchu bazując na adresie źródłowych, docelowym i numerze portu.
Częstą implementacją firewalli jest wykorzystanie ich do stworzenia tzw. Strefy zdemilitaryzowanej ( Demilitarized zone - DMZ).  W środowisku DMZ serwery które muszą być dostępne z sieci zewnętrznej (Intenet) znajdują się pomiędzy dwoma firewallami, natomiast serwery i macierze, które muszą być maksymalnie chronione znajdują się w sieci wewnętrznej.

Sieć zewnętrzna <---> FIREWALL<--->DMZ<--->FIREWALL<--->SIEĆ WEWNĘTRZNA


Zabezpieczanie sieci IP SAN:

Challenge-Handshake Authentication Protocol (CHAP) - mechanizm autoryzacji używany w sieciach IP , za jego pomocą inicjator i target mogą potwierdzić wzajemnie swoją tożsamość, wymieniając pewne sekretne hasło. Jest ono losową sekwencją od 12 do 128 znakówi  nigdy nie jest przesyłane bezpośrednio poprzez sieć, transmituje się tylko jego skrót (hash) stworzony za pomocą funkcji MD5.
CHAP Authentication występuje w dwóch rodzając: one way authentication i two ways authentication

One-Way CHAP Authentication:
Służy do identyfikowania Initiatora poprzez Target.
Schemat działania:
1. Initiator wysyła logon request do targetu i zestawiane jest połaczenie
2. Target wysyła do inicjatora tzw: CHAP Challange
3. Initiator wykorzystuje CHAP Challange oraz znany sobie i targetowi klucz do stworzenia hasha.
4. Hash jest wysyłany do Targetu
5. Target sprawdza czy otrzymany hash jest tym, który był oczekiwany, jeżeli tak połączenie jest autoryzowane.

Two-Way CHAP Authorization:
W tym rodzaju CHAP-sa, najpierw inicjator autentyfikuje się targetowi (one-way CHAP) a następnie ten proces zostaje odwrócony i target autentyfikuje się inicjatorowi.

Zabezpieczanie sieci IP SAN za pomocą iSNS Discovery Domains
iSNS discovery domains pełni tą samą rolę w sieciach IP SAN co zoning w FC. Dzięki temu mechanizmowi możemy podzielić całą sieć na logiczne fragmenty. Jedynie urządzenia w tej samej discovery domain mogą się ze sobą komunikować.





Wpis dość długi i na dodatek dość długo (w porównaniu do poprzednich) przygotowywany. Po części jest to sprawa dość dużej partii materiału zawartego w tym rozdziale, ale również wynika z pewnych zmian jakie zaszły ostatnio w moim życiu zawodowym. W skrócie mówiąc, ilość wolnego czasu, jaki posiadam, z niewielkiego, zmniejszyła się do ekstremalnie małego, co nie pozostanie bez negatywnego wpływu na częstotliwość aktualizowania tego blogu.
Niestety, takie życie...


czwartek, 21 października 2010

ISM - Storage Security Domains

Środowisko urządzeń storage i dostęp do danych na nich składowanych poprzez sieć, rodzi zagrożenia pod postacią ataków i próby uzyskania nieautoryzowanego wejścia i zmiany danych, lub ich uszkodzenia. Aby dobrze zidentyfikować rodzaje zagrożeń dzielimy całą sieć storage na trzy domeny:
  • Appliaction access - domena zawierająca ten fragment sieci, który jest wykorzystywany do dostępu do danych. 
  • Management access - w tej domenie znajdują się wszystkie ścieżki i urządzenia, które wykorzystuje się przy zarządzaniu i konfigurowaniu storage.
  • BURA - obejmuje wszyskie ścieżki danych i urządzania uczestniczące w procesie backup/recovery.

Application Access Domain:

W skład tej domeny wchodzą te komponenty (aplikacje, hosty, urządzania w sieci SAN itd.) które współuczestniczą w ruchu danych z/do urządzeń storage. Przykładowe zagrożenia związane z domeną Application Access to np: podszywanie się jednego hosta za drugiego, w celu uzyskania dostępu do zasobów storage, podsłuchiwanie transmisji w sieci , przeprowadzanie ataku DoS itd... Metody zapobiegawcze to przede wszystkim autentyfikacja i autoryzacja użytkowników, ważne jest także aby macierz mogła widzieć jedynie te hosty które powinny z jej zasobów korzystać.
Przykłady zabezpieczenia i kontroli dostępu użytkownika do danych (ataki typu: podszywanie się pod użytkownika): Autentyfikacja hasłami , NAS: Access Control Lists
Przykłady zabezpieczenia i kontorli dostępu hostów do danych (ataki typu: podszywanie się pod hosta): Zony w sieci SAN , LUN Maskig, iSCSI autentyfikacja wykorzystująca CHAPa
Przykłady zabezpieczeń i ochrony infrastruktury (ataki DoS, podsłuchiwanie transmisji itd...): używanie bezpiecznych protokołów IPSec i FC-SP ( Fibre Channel Security Protocol)
Przykłady zabezpieczeń danych istniejących na macierzach i taśmach (ataki bezpośrednio skierowane w dane: fizyczna kradzież ): Szyfrowanie danych, bezpieczne usuwanie.


Management Access Domain:

Za pomocą komponentów tej domeny możliwe jest zarządzanie urządzeniami storage (monitoring, wystawianie LUNów , provisioning itd...). W większości przypadków sieć zarządzająca to sieć LAN, a dostęp do samych macierzy odbywa się za pomocą CLI (Command Line Interface) lub przeglądarki sieciowej. Zagrożenia związane z Management Access Domain wiążą się z podsłuchem ruchu pomiędzy macierzami, a konsolami zarządzającymi oraz na próbach nieautoryzowanego łączenia się i zarządzania urządzeniami storage. Przeciwdziałania to wprowadzenie dwustronnej autentyfikacji (macierz identyfikuje się hostowi i host macierzy) , używanie bezpiecznych protokołów komunikacyjnych (np: SSH) przy łączeniu się do macierzy. Wydzielenie sieci LAN zarządzającej, od pozostałej infrastruktury sieciowej ( fizyczne rozdzielenie lub zdefiniowanie VLANu )


BURA Domain

BURA obejmuje sobą wszystkie urządzenia i ścieżki danych, które są wykorzystywane przez środowisko backupowe ( takie jak np: taśmy czy replikację ). Zabezpieczenie domeny BURA bazuje zwykle na specyfice działania aplikacji backupowej, gdyż musi bardzo ściśle z nią współpracować. Przykładami ataków w tej domenie to podszywanie się intruza pod serwer backupowy lub DR site, czy próba przechwycenia transmisji danych dla backupu, poprzez podsłuchiwanie kanału komunikacyjnego. Ochrona polega na wprowadzaniu szyfrowanej transmisji oraz mechanizmach autentyfikacji.





Tyle o domenach. W kolejnym odcinku telenoweli pt ISM , prześledzimy zagadnienia związane z konkretnymi
metodami zabezpieczeń w sieciach storage.

sobota, 16 października 2010

ISM - Budowa podstaw polityki bezpieczeństwa w obszarze storage

Czym jest bezpieczeństwo storage?

Jest to wdrożenie pewnych polityk, zasad i praktyk do technologii związanych ze storage. Główny nacisk jest kładziony na zapewnienie bezpiecznego(kontrolowanego) dostępu do informacji.
Podstawowy szkielet zasad i procedur ( tzw: framework ) bezpieczeństwa storage powinien obejmować następujące pojęcia:
  • Poufność (Confidentiality) - zapewnia, że jedynie upoważnieni użytkownicy mają dostęp do informacji. Każda osoba chcące przeczytać lub zapisać dane musi być zautentyfikowana i jej upoważnienia potwierdzone. Dane powinny być przechowywane i przesyłane wyłączenie w postaci zaszyfrowanej.
  • Integralność (Integrity) - zapewnia, iż dane nie zostaną niezauważalnie i bezprawnie zmodyfikowane. Dopusza zmianę jedynie dla uprawnionych do tego użytkowników.
  • Dostępność (Availability) - zapewnia że dane są dostępne zawsze i z odpowiednio dużą szybkością
  • Monitoring (Accountability) -  zapewnia, że wszystkie działania i operacje na danych będą zapisane i przechowywane w logach, w celach audytowych lub sprawdzenia w przyszłości.

Elementy wchodzące w skład bezpieczeństwa

Jednym z najważniejszych pojęć związanych z bezpieczeństwem (nie tylko storage) jest ryzyko (risk), które można opisać jako pewną miarę zagrożenia. Trzy pojęcia związane z ryzykiem to: Zasób (Asset) , Zagrożenie (Threat) i Wrażliwość (Vulnerability)

Elementy bezpieczeństwa: Zasoby
Najważniejszym zasobem jest informacja.
Inne rodzaje zasobów to hardware, software i infrastruktura sieciowa. Głównym zadaniem bezpieczeństwa jest chronienie zasobów. Planując zabezpieczenia należy pilnować dwóch rzeczy: Po pierwsze dane muszą być w łatwy sposób dostępne dla uprawnionych użytkowników i po drugie bardzo ciężko dostępne dla potencjalnych intruzów. Efektywność kosztową systemu zabezpieczeń także można ocenić za pomocą dwóch wskaźników: koszt implementacji systemu musi być nieduży, w stosunku do wartości danych w nim przechowywanych, a jednocześnie koszt przeprowadzenia ataku i uzyskanie nieuprawnionego dostępu powinien być dużo większy, niż wartość samych danych.

Elementy bezpieczeństwa: Zagrożenia
Zagrożenia są to potencjalne miejsca i sposoby ataku na naszą strukturę IT.
Można je podzielić na dwie grupy:
  • Ataki pasywne
    • Próby uzyskania nieautoryzowanego dostępu
    • Zagrożenia dla tajności informacji
  • Ataki aktywne
    • Modyfikacja danych , Denial of Service (DoS)
    • Zagrożenia dla integralności i dostępności danych

Elementy bezpieczeństwa: Wrażliwość
Należy pamiętać, że słaby punkt (wrażliwość) może wystąpić w każdym miejscu/elemencie naszego środowiska ( sieć, system operacyjny , użytkownicy , dostęp fizyczny itd.) i dodatkowo udany atak w tym miejscu może skompromitować cały system i dać intruzowi dowolny dostęp do danych.
Mówiąc o konkretnej wrażliwości systemu można przypisać jej 3 cechy:

  • Attack surface - jest związany z punktem w systemie, który intruz może wykorzystać do przeprowadzenia ataku. Przykładem może być każdy komponent infrastruktury sieciowej , taki jak np konkretny interfejs, protokół, usługa sieciowa itd...
  • Attack vector - to szereg kroków jakie muszą być wykonane aby atak się udał. 
  • Work factor - to ilość czasu i starań jakie są potrzebne aby przejść przez "attack vector"
Aby likwidować lub ograniczać wpływ wrażliwości należy stosować metody zapobiegawcze. Można je podzielić na dwie kategorie: techniczne i nie-techniczne (procedury bezpieczeństwa, fizyczna ochrona obiektów). Jeżeli chodzi o sposób działania to metody przeciwdziałania używają trzech sposobów:
  • Prewencja - likwidowanie wrażliwości lub zmniejszanie ich wpływu
  • Korekcja - usuwanie skutków ataku
  • Detekcja - wykrywanie ataków i uruchamianie mechanizmów prewencyjnych i korekcyjnych.





Już widzę, że ta sekcją będzie dla mnie najcięższa. Tematyka w miarę odległa od tego czym się zajmuję i dużo nowych pojęć. Na szczęście za niedługo już koniec ;)

Kolejny wpis będzie o: Storage Security Domains.

poniedziałek, 11 października 2010

ISM - Replikacja zdalna

Replikacja zdalna jest to tworzenie repliki w innej lokacji. Druga lokacja (macierz) na którą wykonuje się replikacje może być kilka metrów od macierzy źródła lub znajdować się na innym kontynencie.
Replikowanie zdalne zabezpiecza dane przed ich utratą spowodowaną przez lokalną katastrofę ( powódz, pożar, zamieszki itd...)

Wyróżnia się dwa podstawowe typy replikacji: Synchroniczną i Asynchroniczną. Dane pomiędzy lokacjami mogą być przesyłane na kilka sposobów, poprzez: Sieć IP, Sieć SAN, za pomocą Dense Wave Division Multiplexing (DWDM) lub Synchronous Optical Network (SONET)


Replikacja Synchroniczna:

W replikacji synchronicznej każdy zapis wykonany przez hosta zostaje przesłany z macierzy źródła, na macierz cel, następnie cel potwierdza zapis danych i dopiero po tym macierz źródłowa wysyła do hosta potwierdzenie wykonania operacji. Takie działanie powoduje, że przez cały czas, na obydwu macierzach są te same dane, dodatkowo zachowywana jest kolejność zapisów. RPO jest zerowe , RTO wynosi tyle ile potrzeba do uruchomienia aplikacji po stronie celu.
Replikacja synchroniczna ma wysokie wymagania, jeżeli chodzi o przepustowość łącza, pomiędzy dwoma lokalizacjami. Musi być ono w stanie obsłużyć maksymalne obciążenia generowane przez I/O
Ten rodzaj replikacji zwykle nie jest możliwy na odległości większe niż 100-200km


Replikacja Asynchroniczna:

W tej replikacji po wysłaniu żądania zapisu przez hosta, dane zostają zapisane na macierzy źródle i od razu host otrzymuje potwierdzenie. Źródło buforuje nowe dane i periodycznie wysyła do drugiej lokacji. RPO jest niezerowe i zależne od częstości wysyłania danych do macierzy celu. Zużycie łącza jest dużo niższe i zwykle przepustowość może być mniejsza niż typowe obciążenie I/O generowane przez hosta. Na macierzy źródle należy utrzymywać bufory na dane przygotowywane do wysłania. Ten rodzaj synchronizacji może być implementowany na długich dystansach.


Rodzaje replikacji zdalnej:

Ze względu na poziom na jakim działa replikacja zdalna, podobnie jak w przypadku replikacji lokalnej możemy wyróżnić dwa jej typy:
  • Host Based Replication
    • Logical Volume Manager (LVM) based
    • Log Shipping
  • Storage Array based
    • Support both synchronous and asynchronous mode
    • Disk Buffered - Consistent PITs


Host Based Replication: LVM Based

Odbywa się na poziomie LVMowych volume grup (więcej o LVMie jest w poprzednim wpisie). LVM, na hoście źródle, wysyła poprzez sieć IP wszyskie zapisy, do swojej volume grupy, LVM na źródle zapisuje te zmiany do volume grupy docelowej. Ten typ replikacji może działać zarówno w sposób synchroniczny jak i asynchroniczny, dane są wtedy wpierw zapisywane do log file na źródle i dopiero potem wysyłane do celu. Log file jest także wykorzystywany, jako tymczasowe miejsce przechownia zmian w przypadku utraty połączenia. Ten rodzaj replikacji pozwala utrzymywać kopię danych bez potrzeby używania sieci SAN.

Zalety:
  • Różne poziomy RAID mogą być zdefiniowane na celu i źródle
Wady:
  • Długie problemy z połączeniem siecowym, powodują powstawanie wielkich log filów.
  • Negatywny wpływ na wydajność hosta


Host Based Replication: Log Shipping

Jest to rodzaj replikacji na poziomie hosta, wykorzystywany przez bazy danych. Transakcje wykonywane na źródle są zapisywane do logu, który następnie jest periodycznie wysyłany na źródło. Źródło zapisuje loga a następnie wprowadza zawarte w nim operacje do swojej bazy. RPO jest zależne od wielkości loga i częstotliwości jego wysyłania. Zaletami tego typu replikacji jest małe zużycie CPU oraz małe wymagania dotyczące przepustowości łącza.


Storage Array Based Remote Replication

W tym rodzaju replikacji podobnie jak w przypadku lokalnym (poprzedni wpis) wszystkie operacje odbywają się i są zarządzane przez macierz - powoduje to zwolnienie zasobów CPU. Do połączenia między macierzami można wykorzystać łącze dedykowane lub współdzielone.
Replikacja Storage Based może występować w wersji synchronicznej (potwierdzenie zapisu do hosta zostaje wysłane dopiero po otrzymaniu potwierdzenia o zapisaniu zmiany na macierzy celu ) lub asynchronicznej ( potwierdzenie zapisu zostaje wysłane do hosta natychmiast, a dane ze źródła na cel są wysyłane co pewien ustalony okres czasu). W replikacji asynchronicznej stosowane są różne metody zapewnienia spójności danych , niektórzy producenci dołączają do każdego żądania znacznik czasowy, tak żeby na macierzy celowej zachować kolejność z zapisów. Innym sposobem jest zapisywanie na bufor cache przez zadany okres czasu, a następnie zablokowanie bufora w stanie spójnym i przesłanie go na drugą stronę.


Storage Array Based - Disk Buffered Replication

Jest to połączenie lokalnej i zdalnej replikacji na poziomie macierzy. Najpierw spójna kopia PIT (snapshot) jest tworzona lokalnie na macierzy źródle. Następnie ta replika jest przesyłana na macierz docelową. RPO jest zależne od częstości


Replikacja na trzy lokacje.

W replikacji synchronicznej źródło i cel nie mogą być oddalone od siebie bardziej niż około 200km. Powoduje to, że taka konfiguracja jest wrażliwa na katastrofy o lokalnym zasięgu. Rozwiązaniem jest stosowanie replikacji asynchronicznej i lokacji odległych o setki czy tysiące kilometrów. W takich konfiguracjach jednak RPO jest niezerowe i często nie akceptowalne.
Rozwiązaniem jest replikacja na trzy lokacje (Three site replication).
Replikacja tego rodzaju może odbywać się na dwa sposoby:

  • Cascade/Multi-hop
  • Triangle/Multi-target
Cascade/Multi-hop:

SOURCE----------->BUNKER---------->TARGET

W tym rodzaju replikacji przepływ danych jest następujący: Ze źródła (SOURCE) dane są synchronicznie replikowane na BUNKER a z niego asynchronicznie lub metodą Disk Buffered na TARGET

Triangle/Multi-target:
W rozwiązaniu cascade/multi-hop mamy większą niezawodność, niż przy dwóch lokacjach, ale zagrożenie nie jest wyeliminowane całkowice. Utrata BUNKER powoduje, że aplikacje działają na produkcji, ale brak jakiejkolwiek replikacji na TARGET. Wady te eliminuje rozwiązanie Triangle/Multi-target, gdzie każda lokalizacja jest połączona z dwoma pozostałymi.
Schemat przepływu danych jest następujący: Ze SOURCE dane są synchronicznie replikowanie na BUNKER oraz asynchronicznie na TARGET. Pomiędzy BUNKER a REMOTE zestawiona jest również replikacja asynchorniczne z dyferencyjną resychronizacją (Asych with Differential Resynch).
Takie rozwiązanie gwarantuje, że po utracie lokacji dane nie dość że są dostępne, to jeszcze mamy rozwiązanie DR (Disaster Recovery) - czyli jesteśmy w stanie przetrwać utratę drugiej lokalizacji.


SAN Based Remote Replication

Ten rodzaj replikacji może odbywać się pomiędzy macierzami różnych producentów. Dane są przesyłane poprzez SAN/WAN. Samą replikacją steruje jedna z macierzy, nazywana "contolling array". Macierz docelowa nosi nazwę "Remote array". W SAN Based Remote Replication możliwe są dwie operacje: push i pull. Push polega na wysłaniu danych z control array do remote array , natomiast pull to przesłanie danych z remote array do control array. Obydwie te czynności nadzoruje i inicjuje control array.


Nośniki zdalnej replikacji

Aby zdalna replikacja mogła mieć miejsce między macierzami biorącymi w niej udział musi istnieć połączenie.
Przykłady takiego połączenia to:
  • ESCON i FC dla krótszych odległości
  • IP network dla dalekich dystansó
  • Sieci optyczne: DWDM i SONET


Sekcja nr 3 została oficjalnie skończona, została jeszcze część 4 opisująca zabezpieczanie i zarządzanie zasobami storage. Z racji pewnych zmian zachodzących ostatnio w moim życiu zawodowym wpisy mogą pojawiać się nieco rzadziej, choć będę chciał utrzymać poziom co najmniej jednego nowego na tydzień.
Zobaczymy czy się uda.

środa, 6 października 2010

ISM - Metody lokalnej replikacji

Metody lokalnej replikacji można podzielić na dwie kategorie:
  • Host based
  • Storage Array based
Gdy mówimy o lokalnej replikacji typu host based, to odbywa się ona z wykorzystaniem zasobów hosta (CPU) i na poziomie hosta, poprzez pracujący na nim software. W tym przypadku o lokalnej replikacji mówimy jeżeli odbywa się w zakresie jednego datacenter. Przykładami replikacji lokalnej tyou host based są: Logical Volume Manager (LVM) base mirroring i File System Snapshot

Replikacja lokalna typu Storage Array based odbywa się w obrębie jednej macierzy i wykorzystuje jej zasoby do stworzenia kopii danych. Przykładami replikacji tego typu są: Full volume mirroring , Pointer based full volume replication, Pointer based virtual replication


Replikacja host based: LVM Based Mirroring

W tej metodzie za replikację jest odpowiedzialny LVM, który składa się z trzech komponentów:
  • Wolumeny fizyczne (physical volumes) - tożsame z dyskami
  • Grupy wolumenów (volume groups) - jeden lub większa ilość wolumenów fizycznych
  • Logiczny wolumen (logical volumes) - struktura logiczna zbudowana w obrębie jednej grupy
Przy replikacji na poziomie LVMa, każda partycja logiczna (struktura w logicznym wolumenie) jest podmapowana do dwóch partycji fizycznych. Aplikacja pisze do podmapowanej partycji logicznej a sterownik LVMa zapisuje na dwie partycje fizyczne. Ta metoda jest także znana jako LVM mirroring.
Dwie zmirrorowane partycje fizyczne mogą być rozdzielone.


Replikacja host based: File System Snapshot

Snapshot FSa to replika oparta na wskaźnikach do danych. Metoda ta wykorzystuje dwie struktury bitmape i mapę bloków:
  • Bitmap : używana jest do śledzenia bloków które ulegają zmianie po stworzeniu snapshota. Początkowo cała wypełniona jest zerami.
  • Block map : zawiera wskaźniki do bloków danych które musza byc odczytane ze snapshota
Mechanizm działania snapshota jest następujący: podczas jego tworzenia, powstają także bitmapa i block mapa. Przy zapisywaniu danych stosowany jest mechanizm Copy on First Write (COFW) - oznacza to że przy pierwszej zmianie danego bloku, dane nie są nadpisywane ale przekopiowywane na nowe miejsce. Następnie bit w bitmapie odpowiadającej za ten blok danych zmienia swoją wartość z 0 na 1 , a wskaźnik w block mapie zaczyna wskazywać na miejsce do którego przekopiowano dane. 
Dzięki zastosowaniu tej metody snapshot zajmuje tylko tyle miejsca ile zajmują zmiany wykonane od czasu jego wykonania do chwili obecnej. Wadą tego typu replikacji jest wyższe zużycie CPU ( LVM musi zajmować się śledzeniem zmian).


Replikacja storage based: Full Volume Mirroring

W full volume mirroring-u do LUNa źródłowego jest przypisany (attached) LUN docelowy i między nimi ustalone jest powiązanie typu mirror. Wszyskie dane zostają przegrane z źródła do celu, nowe zmiany także są synchronizowane. LUN źródłowy i docelowy mają dokładnie te same dane.
Jeżeli cel jest w stanie: przypisany (attached) wtedy jest on niedostępny dla hostów.
Taką struktrurę można rozłączyć (detached) w takim przypadku cel staje się PIT (Point in time) repliką LUNa źródła i może zostać podłączony do hostów np w celach testowych lub do zrobienia backupu.
Po rozłączeniu zmiany zarówno na LUNie źródłowym jak i docelowym są śledzone i przy ponownym przypisaniu synchronizowaniu ulegają jedynie zmiany.


Replikacja storage based: Pointer Based Full Volume Replication

Ten typ replikacji tworzy replikę od razu dostępną po włączeniu sesji replikacyjnej ( nie ma potrzeby czekania aż istniejące dane przekopiują się ze źródła do celu ), od razu kopia jest też dostępna do wystawienia dla hostów. Czas aktywowania definiuje PIT kopii.
Pointer based, full volume repliaction może być uruchomiona w dwóch trybach:
  • Copy on First Access (CoFA)
  • Full Copy
W obydwu przypadkach, podczas aktywowania replikacji tworzona jest bitmapa dla wszystkich danych na źródle. Wskaźniki w tej bitmapie wiążą puste bloki na celu z blokami z danymi na źródle. Następnie w zależności od trybu w jakim działa replikacja dane są kopiowane ze źródła do celu.

Copy on First Access:
W tym trybie dane są kopiowane na źródło zawsze kiedy host próbuje się do nich odnieść po raz pierwszy od stworzenia PIT kopii.
Nieco dokładniejszy opis tego procesu:
  • Kiedy do źródła jest wysyłane ( po raz pierwszy) żądanie zapisu - oryginalne dane są kopiowane na cel + nowe dane są zapisywane na źródle. Dane zostają oznaczone (na bitmapie) jako przekopiowane.
  • Kiedy do celu wysyłane ( po raz pierwszy) jest żądanie odczytu - oryginalne dane są kopiowane ze źródła na cel. Dane zostają oznaczone (na bitmapie) jako przekopiowane.
  • Kiedy do celu jest wysyłane (po raz pierwszy) jest żądanie zapisu - oryginalne dane są kopiowane ze źródła na cel a następnie nadpisywane nowymi danymi. Dane zostają oznaczone (na bitmapie) jako przekopiowane.
Kluczowy tutaj jest fakt oznaczania danych jako przekopiowanych. Po tej zmianie zarówno dane na źródle jak i na celu mogą się zmieniać, co doprowadza do sytuacji, że oryginalna PIT kopia przestaje istnieć.


Full Copy Mode:
W tym trybie od razu po stworzeniu PIT kopii (aktywacji sesji replikacyjnej) rozpoczyna się proces kopiowania w tle wszystkich danych ze źródła na cel.


Replikacja storage based: Pointer Based Virtual Replication

W tym rodzaju replikacji po uruchomieniu cel zawiera tylko wskaźniki do danych na źródle. Początkowo wielkość repliki jest równa zero. W tej metodzie replikacji cel jest nazywany virtualną repliką, ponieważ nie jest LUNem czy przestrzenią dyskową ale zbiorem wskaźników.
Pointer Based Virtual Replication używa mechanizmu Copy on First Write ( CoFW)
CoFW działa następująco:

  • Kiedy do źródła jest wysyłane ( po raz pierwszy) żądanie zapisu - oryginalne dane są kopiowane do pewnego wcześniej zdefiniowanego obszaru na macierzy (tzw: save location). Wskaźnik na celu jest zmieniany na tą nową lokację. Po wykonaniu tego orginalne dane na źródle są nadpisywane. 
  • Kiedy do celu jest wysyłane (po raz pierwszy) jest żądanie zapisu - oryginalne dane są kopiowane ze źródła na save location, a następnie zmianie ulegają wskaźniki w celu. Potem wykonuje się jeszcze jedną kopię danych w save location i dopiero potem nadpisuje je nowymi danymi.



Tyle o lokalnej replikacji - pominąłem trochę materiału o szczegółach dotyczących śledzenia zmian i odtwarzania z repliki. Sprawy raczej oczywiste i wynikające już z tego co zostało napisane.
Kolejny wpis będzie o zdalnej replikacji i na tym skończymy trzecią (z czterech) sekcji przygotowujących do egzaminu na EMC Proven Associate.

czwartek, 30 września 2010

ISM - Lokalna replikacja i pojęcie spójności danych

Czym jest replikacja:

Replika - dokładna kopia.
Replikacja - proces tworzenia repliki.
Lokalna replikacja - replikowanie danych w obrębie jednej macierzy lub w obrębie jednego data center.


 Wykorzystanie replik:

  • Alternatywne źródło backupów - przeważanie backupy robi się z volumenów produkcyjnych, jednak powoduje to dodatkowe obciążenie wydajnościowe dla tych urządzeń. Aby uniknąć spadku wydajności można robić replikę PIT ( point-in-time) i jej używać jako źródła do backupu. Dodatkową zaletą takiego wykorzystania replik jest zmniejszenie okna backupowego.
  • Szybsze odtworzenia - wykorzystanie replik pozwala na szybsze odtworzenie danych, w przypadku ich utraty lub awarii.
  • Redukcja obciążenia volumenów produkcyjnych - niektóre działania np: raportowanie można wykonywać na replikach zamiast na "głównych" danych. Pozwala to na odciążenie volumenów produkcyjnych.
  • Testowanie - repliki można wykorzystywać do różnego rodzaju testów. Najczęstszym przypadkiem są upgrady aplikacji i OSów - najpierw przeprowadza się je na replice i sprawdza czy działanie systemu jest poprawne.
  • Migracja danych - lokalne repliki mogą zostać wykorzystane do przeprowadzenia migracji danych nie wpływających na niedostępność systemów produkcyjnych.

Typy replik:

Repliki możemy podzielić na dwa typy z punktu widzenia RPO: 
  • PIT (Point-in-time)
  • Continuos
Repliki PIT są wykonywane w danej chwili i zawierają dane produkcyjne z pewnego określonego punktu w czasie. RPO jest niezerowe i oczywiście zwiększa się razem z upływem czasu, który minął od stworzenia repliki. Repliki tego typu mogą być wykonywane przed przeprowadzeniem pewnych działań, mogących spowodować korupcję danych ( np wgrywnie patchy). 
Repliki continuos polegają na ciągłym utrzymywaniu dokładnej repliki danych produkcyjnych. Zmiany dokonywane na źródle są od razu sygnalizowane i synchronizowane z repliką. RPO przy tego typu replikcji jest bliskie (lub równe) zero.


Cechy dobrej repliki:

Aby uznać mechanizm replikacyjny i replikę za "dobrą" powinny być spełnione następujące warunki:
  • Spójność (Consistency) - podstawowa cecha każdej repliki. Zapewnia, że dane zostały skopiowane w sposób właściwy i pełny oraz, że replika jest spójna z danymi produkcyjnymi
  • Odtwarzalność po awarii - musimy być w stanie odtworzyć dane z repliki po ich uszkodzeniu/utracie na produkcji
  • Używalność - musimy być w stanie, w razie potrzeby, uruchomić produkcję bezpośrednio na danych zreplikowanych (zachodzi to w przypadku gdy nie tylko utracone/uszkodzone zostały dane źródłowe, ale także sam sprzęt (macierz) źródłowy jest niedostępny)

Spójność danych:

Warunkiem koniecznym do działania i używalności repliki jest aby dane na niej były spójne.
Większość systemów plików i baz danych buforuje dane w pamięci, zanim zapisze je na dyski - aby replika była spójna, należy zadbać, aby wszystkie dane buforowane były zapisane na dyskach, w momencie jej tworzenia. Dla systemów plików spójność z repliką można zapewnić na dwa sposoby. Metoda offline polega na odmontowaniu FSa przed zrobieniem repliki, natomiast sposób onlinowy na wyczyszczeniu bufora hosta (Flush host buffer)  przed replikacją. Podobne dwie metody są możliwe przy pracy z bazami danych: baze można zamknąć przed zrobieniem jej repliki (offline) lub przełączyć na specjalny tryb (hot backup mode), jeżeli zależy nam na replikacji w online.


Spójność systemu plików: Flushing Host Buffer

FS buforuje dane w pamięci RAM hosta, żeby przyśpieszyć działanie aplikacji. Zbuforowane informacje są periodycznie zrzucane na dyski. W systemach UNIXowych zajmuje się tym sync demon, który czyści ram z danych zbuforowanych, co pewien ustalony interwał. Wykonanie repliki, kiedy system jest podmontowany i zbuforowane dane nie są nagrane na dyski, kończy się niespójną kopią. Replika z odmontowanego systemu jest zawsze spójna, gdyż automatycznie przed procesem odmontowanie, zachodzi zrzut wszyskich danych zbuforowanych w pamieci na dysk.


Spójność bazy danych: Dependent Write I/O

Dependent Write jest to żądanie zapisu, które nie będzie wystawione przez aplikację, zanim inny, powiązany z nim zapis nie zostanie zakończony. Przykładem Dependent Write w bazach danych jest zlecenie zapisu do bazy, które jest zależne, od udanego zakończenia zapisu do loga. Dependency Write zapewniają iż baza pozostanie spójna, nawet w przypadku utraty zasilania (power outage).
Dependent Write także musi zostać zachowane, jeżeli chcemy wykonać spójną replikę bazy danych ,w trybie online. W tym przypadku "flush host buffer" z RAMu na dyski, który jest potrzeby aby zachować spójność FSa, także musi być wykonany z zachowaniem "zapisów zależnych", czyli wykonywanych w odpowiedniej kolejności.


Spójność bazy danych: Holding I/O

Kolejną metodą zapewnienia spójności onlinowej repliki jest wstrzymanie I/O do i z bazy, stworzenie repliki, a następnie ponowne uruchomienie I/O. Większość baz posiada umiejętność przetrwanie w stanie spójnym przerwy w dostawie prądu, co w działaniu jest dość podobne do wstrzymania I/O.





Muszę przyznać, że całkiem ciekawe te materiały dotyczące replikacji. Może dlatego, że nigdy za bardzo nie zastanawiałem się nad zachowaniem spójności danych na poziomie wyższym niż samej macierzy.
Kolejny wpis ( i chyba jeszcze następny też) będzie dalej poruszał się w obrębie replik.

poniedziałek, 27 września 2010

ISM - Backup i odtworzenie - techniki wykonywania oraz topologie

Ten wpis jest bezpośrednią kontynuacją poprzedniego, dalej zajmujemy się procesem składowania i odtworzenia ( Backup/Recovery).
Przed rozpoczęciem muszę jednak ostrzec potencjalnego czytelnika: ten wpis jest pełen moich schematów wykonanych w technice ASCII-ART. Dalszą lekturę polecam jedynie osobą o dużej odporności na szok estetyczny. Może kiedyś zainwestuję w Visio, ale na razie musi wystarczyć funkcjonalność klawiatury :D

OK, zostaliście ostrzeżeni...

Topologie Backupu:


Możemy wyróżnić cztery topologie w jakich wykonujemy backup:

  • Direct Attached Based Backup
W tej metodzie urządzenie storage, na które wykonujemy backup, jest bezpośrednio podłączone do klienta. Do serwera backupu wysyłane są jedynie metadane. Taka konfiguracja nie obciąża sieci LAN przesyłem danych ale  nie sprawdza się przy dużych środowiskach.

TOPOLOGIA:
---- LAN
---- FC SAN

                                metadane                                                                        Data
Backup serwer <----------------------------------------Backup client -----------------------------------------> Backup device
                                             LAN




  • LAN Based Backup
W LAN Based Backup wszystkie serwery są podpięte do sieci LAN i poprzez to połączenie wysyłają dane do storage nodów, które następnie przysyłają je na urządzenie składujące. Wykorzystanie tej topologii powoduje zmniejszenie wydajności sieci.


TOPOLOGIA:
---- LAN
---- FC SAN

                                                                   Data
                                       Storage Node ----------------------->Backup Device
                                              |  
                                              |                Metadata
Backup Client --------------------------------------------->Backup Server



  • SAN Based Backup
SAN Based Backup jest także zwany LAN-free backupem. Jest to najlepsza topologia backupu w sytuacjach gdy urządzenie na którym składujemy kopie zapasowe jest współdzielone przez wielu klientów.


TOPOLOGIA:
---- LAN
---- FC SAN


                                    ----------------------------------------Storage node
                            LAN    |                                                |     | FC SAN      
                                    |Metadane                                    |     |    DATA                      
Backup server <=====---------------------Backup client ---------       ---------------------->Backup device

                                                                                                     
    • Mixed ( SAN/LAN) Backup
    Ta topologia łączy w sobie rozwiązania oparte na SANie z rozwiązaniami LANowskimi.


    Sposoby backupowania zasobów NAS:

    W środowisku NAS można zaimplementować backup na 4 rodzaje:


    • Server based
                                                                                    Storage
                                                                                         |
    Backup client--------------------NAS Head----------------------Backup device
                                       |                                                 |
                                       ----------Backup server-------------------
                                                     /storage node

    NAS Head otrzymuje dane ze stroge poprzez sieć i wysyał je do backup klienta. Backup klient wysyła te dane dalej do storage noda który zapisuje je na Backup device. Wynikiem takiego rozwiązania jest duże obciązenie sieci SAN oraz serwera produkcyjnego.

    • Serverless
                                                                                    Storage
                                                                                         |
    Backup client--------------------NAS Head----------------------Backup device
                                       |                                                 |
                                       ----------Backup server-------------------
                                                     /storage node

    W tym typie backupu, udział sieciowy jest bezpośrednio podmontowany do storage noda , dzięki temu unikamy przeciążenia sieci i zaangażowania mocy serwera produkcyjnego.

    • NDMP 2-way
                                                                                    Storage
                                                                                         |
    Backup client--------------------NAS Head----------------------Backup device
                                       |                                
                                       ----------Backup server
                                                     /storage node

    NDMP (Network Data Management Protocol) to protokół definiujący przesył danych z zasobu NASowego na urządzenie backupujące ( macierz , biblioteka ) bez udziału serwera backupu. Do serwera backupu trafiają jedynie metadane. Obciązenie sieci LAN związane z backupem NASa jest zredukowane do minimum.

    • NDMP 3 way

    Rozwiązanie podobne do NDMP 2 way ale do transportu danych z NAS Storage do Backup Device używa się sieci LAN ( zwykle dedykowanej ). Rozwiązanie takie musi zostać zastosowane w przypadku monolitycznych NASów ( gdzie NAS storage jest zintegrowany z NAS head i nie ma dostępu do SANa)


    Technologie przechowywania danych (backupów):

    Backup na taśmy:

    Taśmy magnetyczne (Magnetic tapes) to tradycyjne medium do przechowywania backupów, jest bardzo popularne głównie ze względu na koszty. Napędy taśmowe (Tape Drives) są używane do pisania i czytania danych z taśm. Dostęp do danych jest sekwencyjny (sequential). Zapis dokonywany przez napęd jest zapisem streaming( jeden backup zapisywany naraz jednym "strumieniem") lub multistreaming ( kilka backupów zapisywanych naraz, dane są ułożone na przemian ).

    Biblioteki taśmowe:
    Urządzenie do przechowywanie dużej ilość napędów taśmowych oraz taśm magnetycznych to biblioteka taśmowa (Tape Library). Biblioteka składa się ze slotów, w których umieszczane są kasetki z danymi, do przenoszenia taśm pomiędzy slotami oraz napędami służą roboty (robotic arm , picker , accessor). Biblioteką taśmową steruje oprogramowanie do wykonywania backupów na backup serwerze. Oprócz standardowych slotów w bibliotece znajduje się także klika import/export slotów (lub mailslot) służących do dodawania i usuwania kasetek z biblioteki bez przerywania jej pracy.
    Czas jaki upływa od momentu wydania do biblioteki polecenia pod-montowania kasetki, a wykonaniem tego przez bibliotekę nazywamy load to ready time. Zwykle jest on z zakresu od sekund do minut.

    Ograniczenia taśm:
    • prędkość działania - taśmy są bardzo wolne
    • dostęp sekwencyjny
    • brak możliwości dostępu do danych przez kilka hostów jednocześnie
    • zużywanie się taśm
    • duże wymogi dotyczące warunków przechowywania i transportu

    Backup na dyski:

    Ostatnio coraz więcej backupów wykonuje się nie na taśmy magnetyczne ale na dyski. Zaletą tego typu rozwiązania jest o wiele większa wydajność systemów dyskowych nad bibliotekami taśmowymi. Dodatkowo dostęp do dysków jest możliwy przez wiele hostów jednocześnie.
    W niektórych rozwiązaniach dane zeskładowane na dyskach zostają potem przeniesione na taśmy.

    Virtual Tape Library (VTL):
    VTL jest to system dyskowy z odpowiednim modułem zarządzającym, który na zewnątrz prezentuje zasoby dyskowe pod postacią biblioteki taśmowej ( z kasetkami, napędami , robotami itd.). Oprogramowanie na serwerze backupu widzi bibliotekę taśmową i nie jest w stanie rozpoznać że w rzeczywistości wysyła dane na dyski. 





    Trochę chaotyczny jest ten wpis, dodatkowo okraszony niezbyt czytelnymi "diagramami".
    Mam nadzieję, że przy odrobinie samozaparcia, uda się zrozumieć temat.

    W kolejce czekają tematy związane z replikacją i z tego co widzę całkiem ciekawie i obszernie jest ona wyjaśniona. Za parę dni się przekonamy :D



    piątek, 24 września 2010

    ISM - Backup i odtworzenie - podstawy



    Czy jest backup?
    Backup - dodatkowa kopia danych, używana gdy dane pierwotne zostały stracone lub uległy uszkodzeniu.
    Backup może być wykonany poprzez kopiowanie danych lub mirroring danych. Mirroring od kopiowania różni się tym, iż kopiowanie uruchamia się w pewnym momencie w czasie i stan systemu na tą chwilę zostaje zdublowany; mirroring działa cały czas i cały czas utrzymywane są dwa identyczne obrazy danych.


    Dlaczego robi się backupy:

    Przede wszystkim dlatego, żeby móc odzyskać dane w wypadku ich utraty. Dodatkowo niektóre organizacje i firmy (sektor bankowy, służba zdrowia itd) są prawnie zobligowane do przechowywania kopii swoich danych.

    Ogólnie rzecz biorąc są trzy powody składowania(backupowania) danych:
    • Disaster Recovery (DR) - odzyskanie danych po katastrofie w centrum komputerowym
    • Operational - odsyskanie danych straconych w wyniku wypadku lub błędu podczas normalnej pracy systemu
    • Archival - archiwizowanie danych historycznych (emaile , transakcje itd...) 


    Założenia backupu:

    Przed rozpoczęciem backupowania danych ich właściciel (biznesowy) powinien odpowiedzieć na następujące pytania:
    • Jakie są potrzeby dotyczące RPO & RTO?
    • Jak dane będą odtwarzane?
    • Jakich danych dotyczą najczęstsze prośby o odtworzenie?
    • Które dane muszą być backup-owane?
    • Jak często dane muszą być backupowane?
    • Jak długo zajmie wykonanie jednej kopii?
    • Ile kopii należy stworzyć?
    • Jak długo powinniśmy trzymać kopie?
    Mniej istotne (ale wciąż ważne) kwestie do rozważania przy ustalaniu polityki backupowej to między innymi:
    • Przechowywanie kopii danych (w lokacji macierzystej lub zdalnej)
    • Zdolność do obsłużenia przez system backupowy różnych platform i architektur
    • Ilość i wielkość plików (dużo małych, czy mniejsza ilość większych)
    • Podatność danych na kompresję


    Częstość i rodzaj wykonywanych backupów:

    Po zapoznaniu się ze środowiskiem oraz danymi, które mamy zamiar backupować, przyszedł czas na wybór rodzaju i częstotliwości wykonywania kopii.

    Wyróżnia się trzy rodzaje backupów:
    • Pełny (Full Backup) - kompletna kopia danych na systemie/voluminie, który backupujemy. Przy odtworzeniu danych wystarczy jak odzyska się dane tylko z niego
    • Różnicowy lub Kumulacyjny (Cumulative or differential backup) - kopia tylko tych danych, które zmieniły się od ostatniego pełnego backupu.Przy odtworzeniu potrzebujemy, oprócz backupu kumulacyjnego, także ostatni pełny backup.
    • Inkrementalny ( Incremental backup) - kopia zawierająca tylko te dane, które zmieniły się od czasu ostatniego pełnego lub inkrementalnego backupu (zależy który był później). Do odtworzenia danych potrzebujemy ostatni pełny backup oraz wszystkie następujące po nim backupy inkrementalne.
    Jest jeszcze czwarty rodzaj backupu:
    • Syntetyczny ( synthetic or constructed full backup) - jest to backup pełny, ale nie stworzony bezpośrednio na systemie, tylko złożony/sklejony z ostatniego pełnego backupu, połączonego z wszystkimi następującymi po nim backupami inkrementalnymi lub różnicowymi.


    Metody backupowania:

    Sam proces przeprowadzania backupu także można przeprowadzić za pomocą kilku metod:

    Backup hot (online) i cold (offline) :
    Backup, który odbywa się przy włączonej aplikacji, nazywa się backupem hot. Jeżeli podczas robienia kopii aplikacja jest wyłączona, to mamy do czynienia z backupem cold. Backup hot wiąże się z pewnymi problemami, które należy rozwiązać, aby tworzenie kopii się udało. Przede wszystkim na działającym systemie część plików jest otwarta i używana, pliki takie są "zablokowane" przez system operacyjny i może być niemożliwe zrobienie ich kopii. Są dwie metody obejścia tego problemu:
    Po pierwsze, możemy spróbować zbackupować te pliki po jakimś czasie, licząc na to, że zostały już "zwolnione". Rozwiązanie te ma kilka wad: wydłuża nam się czas wykonania kopii, dodatkowo niektóre pliki mogą być otwarte przez cały czas.
    Kolejnym sposobem backupu hot systemów jest wykorzystanie agentów, zainstalowanych na systemach. Agenci, współpracując bezpośrednio z OSem, są w stanie skopiować nawet używane pliki. Użycie agentów wiąże się jednak z utratą wydajności.

    Point in Time (PIT) replika:
    PIT jest to metoda tworzenia kopii, w sytuacji gdy niemożliwe jest ani wyłączenie systemu dla przeporowadzenia backupu cold, ani nawet zaakceptowanie utraty wydajności, związanej z backupem hot.
    Ta metoda powoduje chwilowe "zamrożenie" systemu i stworzenie PIT repliki, która jest montowana na drugim serwerze. Backupuje się tą drugą kopię, podczas gdy wersja oryginalna działa bez zakłóceń.

    Bare metal recovery (BMR):
    BRM jest to backup jest to kopia systemu , razem ze wszyskimi metadanymi , konfiguracjami i resztą ustwień. BRM obejmuje także kopię takich ustawień jak wygląd partycji, systemów pliku, systemu operacyjnego i innych. BRM pozwala na odtworzenie nie tylko danych ale także całego środowiska ( OS, baza itd...) na którym te dane są przetwarzane.


    Architektura środowiska backupowego:

    W środowisku do backupu można wyróżnić trzy główne elementy:
    • Backup client - system, którego dane będą składowane. Jest na nim zainstalowany agent aplikacji do backupu.
    • Backup server - serwer koordynujący procesy składowania w naszym środowisku. Przechowuje katalog, w którym znajdują się informacje o wszystkich backupach,  metadane potrzebne do prawidłowej obsługi składowań.
    • Storage node - Jest to host, który kontroluje i przeprowadza wysyłanie danych do urządzeń storage ( macierze, biblioteki).
    Często backup server i storage node to jedna fizyczna maszyna.


    Proces backupu:
    1. Backup serwer utrzymuje harmonogram wykonywania składowań. Kiedy nadchodzi ustawiona pora serwer rozpoczyna proces.k
    2. Backup serwer pobiera dane dotyczące danego składowania z katalogu.
    3. Backup serwer wydaje, do storage node, polecenie załadowania odpowiedniego backup medium (np: taśmy do napędu)
    4. Backup serwer instruuje backup klienta, jakie dane mają być wysłane do storage noda i jakie metadane do backup serwera.
    5. Backup klinet wysyła dane do storage noda
    6. Storage node wysyła dane do urządzenia storage (macierz, biblioteka)
    7. Storage node wysyła informacje, gdzie zostały zeskładowane dane do backup serwera
    8. Backup serwer uaktualnia katalog.


    Proces odtworzenia:
    1. Użytkownik inicjuje backup
    2. Backup serwer przegląda katalog i sprawdza które dane muszą być odzyskane
    3. Dane są przesyłane do backup klienta
    4. Storage node wysyła metadane do backup serwera
    5. Backup serwer uaktualnia katalog



    Kolejny wpis dalej będzie związany z backup/restore. 

    wtorek, 21 września 2010

    ISM - Business Continuity czyli zachowanie ciągłości działania

    Zakończyliśmy w poprzednim wpisie drugą sekcję ( z czterech ) przygotowujących do egzaminu z ISMa.
    Teoretycznie jesteśmy w połowie drogi, ale praktycznie nieco dalej. Jest to związane z faktem, że dwie ostatnie sekcje są nieco krótsze niż pierwsze.

    W każdym razie przez kilka następnych wpisów przewijać się będą motywy dotyczące dostępności do danych, replikacji , backupów itd...


    Zachowanie ciągłości działania i dostępność informacji:

    Najpierw definicja zachowania ciągłości działania:
    "Business Continuity is preparing for, responding to, and recovering from an application outage that adversely affects business operations."

    Businnes Continuity (BC) jest zaimplementowanym w przedsiębiorstwie procesem, obejmującym wszystkie działania, zarówno związane z IT jak i nie, które musza zostać przeprowadzone aby zminimalizować i usunąć wpływ nieplanowanej przerwie w świadczeniu usług. BC musi zapewnić, że dane nie zostaną utracone i będą dostępne.

    Kolejna definicja dotyczy dostępności informacji (Information Availability):
    "Information Availability (IA) refers to the ability of an infrastructure to function according to business expectations during its specified time of operation."

    IA zapewnia, że osoby korzystające z danych, będą miały do nich dostęp. IA można  określić na trzech poziomach:
    • Accessibility: stan, kiedy potrzebne informacje, są dostępne dla uprawnionych użytkowników. Czas kiedy to zachodzi nazywa się uptime. Czas, kiedy dane nie są dostępne, nazywany jest downtime.
    • Reliability: odnosi się do zapewnienia, że dane które otrzymaliśmy, są dokładnie tymi danymi o jakie poprosiliśmy.
    • Timeliness:  definiuje w których momentach dane muszą być dostępne.


    Przyczyny niedostępności informacji:

    Ogólnie możemy wróżnić trzy główne przyczyny niedostęności danych:
    • Planowane wyłączenia (Planned Outages) - wyłączenie maszyn w celu przeprowadzenia różnych działań konserwująco-sprawdzających ( pathowanie , rozbudowa , testowanie itd...). Tego typu wyłączenia stanowią około 80% z wszyskich przypadków niedostępności danych.
    • Nieplanowane wyłączenia (Unplanned Outeges) - wyłączenie maszyn nieplanowane i nieoczekiwane. Głównie związane jest z incydentami takimi jak: uszkodzenia komponentów fizycznych, błedy softwarowe (korupcja bazy danych, bug) lub błędy człowieka. Tego rodzaju wyłączenia to mniej więcej 20% z wszystkich przypadków niedostępności.
    • Katastrofy (Disaster) - Odpowiadają za mniej niż 1% przypadków niedostępności danych. Związane są z katastrofami naturalnymi (powodzie, trzęsienia ziemi, pożary) jak i spowodowanymi przez człowieka (np: skażenie budynku, atak terrorystyczny)

    Wpływ braku usług (downtime) na biznes:
    • Lost Productivity - z powodu niedziałania systemu, nasi pracownicy nie mogą wykonywać swoich obowiązków - strata= ilość godzin downtimu *( ilość pracowników * średnia godzinna stawka + średni zarobek firmy w godzinę)
    • Damaged Reputation - utrata zaufania i reputacji zarówno u klientów, jaki i dostawców, partnerów biznesowych oraz na rynku
    • Lost Revenue - utrata dochodu, starty związane z zatrzymaniem działalności firmy ( brak sprzedaży, inwestycje które nie zostały przeprowadzone itd.)
    • Financial Perfromance - straty związane z utratą wartości akcji , zmniejszeniem wiarygodnosci kredytowej itd...
    • Other Expenses - dodatkowe opłaty dotyczące wynajęcia supportu do naprawy uszkodzenia , koszty zamówienia i transportu części itd...

    Jak zmierzyć dostępność informacji:

    Linia czasu:

    >---Incydent --- Wykrycie --- Diagnoza --- Naprawa --- Odbudowa --- Przywrócenie Usług --- Incydent --->

    Czas pomiędzy incydentem a przywróceniem usług to MTTR ( Mean Time to Repair )
    Czas pomiędzy przywróceniem usług a kolejnym incydentem to MTBF ( Mean Time Between Failure )

    Dostępność informacji mierzymy następująco:

    IA = system uptime / ( system uptime + system downtime )

    lub

    IA = MTBF / ( MTBF  + MTTR )



    Bardzo często dostępność informacji podaje się wykorzystując tzw "Levels of '9s'":

    %Uptime %Downtime Downtime per Year
    98%
    2%
    7,3 dnia
    99%
    1%
    3, 65 dnia
    99,9%
    0,1%
    17h 30min
    99,99%
    0,01%
    52min 30sek
    99,999%
    0,001%
    5min 15sek
    99,9999%
    0,0001%
    31sek

    Przykładowo, mówiąc o "five 9s available"  (bardzo wysoka dostępność) oznacza to system, który może podczas roku być trochę ponad 5 minut niedostępny nieplanowo.


    Terminologia związana z Bussines Continuity:

    • Disaster recovery - jest to proces przywracania systemu, danych i całej infrastruktury potrzebnej do wznowienia pracy przedsiębiorstwa po katastrofie. Polega na przywróceniu poprzedniej kopii danych i rozpoczęcia pracy od ostatniego punktu czasowego, z którego mamy zrobioną kopię danych.
    • Disaster restart - jest to proces ponownego uruchomienia pracy przedsiębiorstwa po katastrofie, wykorzystujący kopię (mirror) danych i aplikacji. Disaster restart zwykle jest związany z technikami replikacyjnymi.
    • Recovery Point Objective (RPO) - jest to okres czasu wstecz, z którego dane muszą być odzyskane po katastrofie. Duże RPO oznacza dużą tolerancję biznesu na utratę danych. Przedsiębiorstwa ustalają minimalną częstotliwość robienia backupów lub replikacji bazując na RPO. Przykładowo RPO=24h oznacza, że wystarczy nam raz na dobę robiony backup danych, z kolei RPO=0 ( czyli nie akceptujemy żadnej utraty danych) wymaga replikacji synchronicznej do drugiego zapasowego data center.
    • Recovery Time Ojective (RTO) - to jest czas który mamy, aby odzyskać nasze dane i aplikacje po katastrofie. Oznacza jak długi downtime przedsiębiorstwo może wytrzymać. 


    Proces BCP ( Business Continuity Planning ) 

    Proces BCP ma za zadanie zidentyfikować potencjalne ryzyka i słabe punkty naszego systemu ioraz przygotować firmę na przypadek utraty ciągłości działania. BCP jest zadaniem nie tylko działu IT, ale wszystkich jednostek tworzących dane przedsiębiorstwo. 
    Działania jakie powinny być częścią BCP to:
    • Identyfikacja krytycznych zadań biznesu
    • Zebranie informacji jakie dane są używane podczas tych zadań
    • Przeprowadzenie BIA ( Business Impact Analysis ) - analiza ryzyka
    • Zaprojektowanie planu zachowania ciągłości i planu DR ( Disaster Recovery )
    • Przeszkolenie ludzi, testowanie, dbanie o aktualność planów


    Działania wspierające zachowanie ciągłości:

    • Redukcja SPOFów ( Single Point of Failure )
    SPOF jest to punkt (element) w systemie, którego uszkodzenie powoduje przerwę w działaniu systemu. SPOFem może być pojedynczy zasilacz w serwerze, kabel , karta HBA , port w macierzy , kontroler w macierzy itd... Aby usunąć SPOFy najczęściej stosuje się redundancję, czyli zwielokrotnienie danego komponentu, tak aby uszkodzenie jednego z nich, nie wpłynęło na pracę całego systemu.
    • Używanie oprogramowania do multi-pathingu
    Używanie multi-pathingu jest jedną z technik usuwania SPOFów, w połączeniach między hostami/switchami SAN a macierzami.  Polega na łączeniu tych komponentów za pomocą więcej niż jednej ścieżki danych i kontrolowanie tego za pomocą dedykowanego oprogramowania na hoście ( np PowerPath)
    Oprogramowanie takie bardzo często oprócz zapewnienia redundancji, steruje także równomierną dystrybucją ruchu na każdą ze ścieżek (load balancing). 
    Jednak nawet w przypadku utraty jednej ze ścieżek oprogramowanie nie przełączy automatycznie I/O na inna - system musi wpierw wykryć awarię.
    • Backup i replikacja
    Po rozpoznaniu wymagań dotyczących RPO i RTO dla danego przedsiębiorstwa czy systemu, można wybrać rodzaj zabezpieczenia danych tak aby być w stanie spełnić wymagania biznesu.



    Pierwszy temat z trzeciej sekcji ISM za nami.
    W kolejnych skupimy się dokładniej na zagadnieniach związanych z backupem i replikacją.