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ą.

ISM - Z głową w chmurach po raz drugi..

To w sumie drugi wpis na tym blogu na temat przetwarzania w chmurze. Z tego względu dość znacznie go skrócę ale i tak nie uniknę powtórzenia niektórych informacji. Przedstawiona zostanie pewna wizja przetwarzania w chmurze z perspektywy EMC i pod kątem przygotowania do egzaminu ISMowego.  Będziemy się także skupiać bardziej na zagadnieniach związanym z użyciem i przeniesieniem infrastruktury storage do chmury.
W celu dopełnienia wiadomości polecam sięgnięcie do wpisu sprzed kilku miesięcy:  http://metastorage.blogspot.com/2010/07/cloud-z-gowa-w-chmurach.html


Wyzwania związane z tradycyjnym storage:

Tradycyjne zarządzanie Storage nie jest przystosowane do administrowania wielo-petabajtowymi środowiskami. Rozbudowa infrastruktury, związanej z pamięciami masowymi, jest dokonywana poprzez dodawanie dodatkowych macierzy, co zwiększa stopień skomplikowania architektury, utrudnia zarządzanie i staje się bardzo nieefektywne kosztowo.


Cloud Storage Infrastructure:

Następujące zalety i cechy przetwarzania w chmurze są charakterystyczne dla sekcji storage:

• Infinite Scale - chmura umożliwia łatwe zarządzanie, dowolnie dużą ilością macierzy (różnych typów), rozlokowanych w wielu lokalizacjach. Wszystkie zasoby storage tworzą pule o określonych parametrach, które łatwo następnie dzielić i wystawiać do konkretnych hostów. Skalowalność takiego rozwiązania jest w zasadzie nieograniczona, a stopień skomplikowania systemu zarządzającego pozostaje stały.
• No Boundaries - chmura agreguje zasoby różnego typy, umieszczone w dowolnych lokalizacjach.
• Self-Healing - Chmura skupia się na ochronie danych nie na ochronie infrastruktury fizycznej takiej jak np: dyski czy macierze. Dane mogą być rozdystrybuowane i replikowanie po wszystkich lokacjach obejmujących daną chmurę, przez co nie są wrażliwe nawet na bardzo poważne katastrofy (disaster)

Definicja Przetwarzania w Chmurze (cloud computing):

Cloud Computing is an emerging IT development, deployment and delivery model, enabling real-time delivery of products, services and solutions over the Internet (i.e. enabling cloud services).

Z samą chmurą wiąże się też inny sposób definiowania roli i działania sektora/działu IT. Otóż przechodzi się na model "usługowy" czyli przedsiębiorstwa zamawiają lub wykupują konkretne usługi (np: usługa dostarczenia 10TB powierzchni dyskowej o wydajności 3000IOPS), zamiast zamówienia i administrowania komponentami fizycznymi (np: macierzy + dyski)

W zależności od rodzaju usług które są dostarczane wyróżniamy:

• SaaS (Software as a Service)
• StaaS (Storage as a Service)
• CaaS (Computing as a Service)
• HaaS (Hardware as a Serivce)

Cechy chmur:

• Usługa jest dostarczana przez firmę zewnętrzną - przedsiębiorstwa mogą wynająć firmę zewnętrzną do dostarczenia im usług IT, które do niedawna musiały być realizowane w dedykowanym data center - mówimy wtedy o tzw: "chmurze publicznej"
• Dostęp poprzez Internet - usługi świadczone przez chmurę są dostarczane poprzez sieć , zwykle Internet.
• Minimalny lub brak umiejętności IT potrzebny do wdrożenia chmury - rozwiązania chmurowe zwykle są bardzo proste do implementacji, a następnie nie wymagają żadnej wiedzy specjalistycznej w obsłudze.
• Provisioning - zasoby są dostarczane "na żądanie". Istnieje duża elastyczność w formułowaniu potrzeb.
• Ceny - rozwiązania "chmurowe" zwykle są bardzo atrakcyjne kosztowo. Dodatkowo płaci się tylko za tylko za to, co jest potrzebne.

---

I w ten sposób doszliśmy do połowy materiału obowiązującego przy egzaminie E20-001.

Teraz chwila wytchnienia, a potem zaczynamy sekcję 3 związaną z procesami BCP ( Bussines Continuity Processes)

ISM - Virtual Provisioning - ułuda obfitości

Ten wpis będzie dość krótki. Jego tematem jest "virtual provisioning" zwany także "thin provisioning-iem".
W kilku słowach jest to metoda wirtualizacji storage polegająca na prezentowaniu systemowi operacyjnemu/aplikacji lunów o zadanej wielkości, gdy w rzeczywistości ilość przydzielonego im miejsca jest dużo mniejsza i w razie potrzeby zwiększana dynamicznie w tle.
Thin provisioning jest obecnie dość powszechnie stosowany. Przykładem, z którym prawie każdy się spotkał, są hostingi skrzynek mailowych. Pojemność Gmaila to w chwili obecnej ponad 7 GB na skrzynkę, Google, oczywiście, nie przydziela, każdej osobie mającej u nich konto, całej tej przestrzeni w momencie założenia skrzynki (choć tak to wygląda z pozycji osoby korzystającej). Wielkość za-alokowanej rzeczywiście przestrzeni jest równa ilości danych jakie na tym koncie się znajdują i w razie potrzeby powiększana ( aż do 7GB "z hakiem)", gdy użytkownik przechowuje coraz więcej danych.
W rezultacie zamiast inwestowania w gigantyczne ilości storage ( 7GB na każdego użytkownika ), Google musi zapewnić tylko tyle aby pomieściły się tam faktycznie umieszcone dane ( idę w zakład że 99% użytkowników nie przekracza 500MB).

W terminologii EMC "virtual provisioning" jest czymś więcej niż "thin provisioning", ponieważ polega nie tylko na wystawieniu mniejszej ilości miejsca, niż komunikuje się to hostowi, ale dodatkowo umożliwia łatwe zarządzanie i monitorowanie takiej struktury - według mnie to raczej chwyt marketingowy, ponieważ inni producenci także umożliwiają nie tylko tworzenie ale i zarządzanie Thin LUNami.


Tworzenie Thin LUNów:

Aby stworzyć tradycyjnego LUNa najpierw tworzymy struktury zwane grupami RAID a następnie na tych grupach tworzymy LUNy o zadanej wielkości.
Przy Thin LUNach także mamy RAID grupy ( zwane jednak bardo często Thin Pool-em) złożone z dysków  , tworzymy również LUNy i podejemy ich wielkość, ale zajmują one tylko tyle miejsca, ile danych zostanie fizycznie na nich umieszczonych. Na Thin LUNach można także robić over-provisionig, czyli ustalać ich wielkość na większą niż wielkość całej RAID grupy, na której się je konstruuje.
Dodawanie dodatkowych dysków do Thin Pooli jest czynnością nie zaburzającą jej działania.


Zalety Virtual Provisioningu:

• Redukcja kosztów administracyjnych ( łatwiejszy provisioning , over-provisioning ułatwia rozszerzanie Grup RAIDowych )
• Redukcja kosztów storage  ( zwiększa się szybkość replikacji , lepsza utylizacja przestrzeni )
• Redukcja kosztów operacyjnych ( Mniejsza ilość dysków powoduje zredukowanie kosztów energii , chłodzenia oraz zajętości powierzchni w data center )
• Zmniejszony downtime aplikacji ( nie trzeba odmontowywać / wyłączać File systemów aby je powiększyć )

Porównanie Tradycyjny LUN vs Thin LUN:

Mimo, iż posiada wiele zalet w niektórych przypadkach warto użyć Tradycyjnych LUNów zamiast Thin.

Thin LUNy są lepsze gdy:

• Zależy nam na optymalizacji zużycia przestrzeni
• Zależy nam na optymalizacji zużycia energii
• Uniknięciu przestojów związanych z rozszerzaniem wystawionej aplikacją przestrzeni

Tradycyjne LUNy są lepsze gdy:

• Aplikacja ma bardzo duże wymagania wydajnościowe ( obsługa I/O do i z Thin luna jest nieco bardziej czasochłonna)

---

Na dzisiaj tyle...

A w następnym "odcinku" pobujamy się nieco w chmurze.

ISM - Wirtualizacja - podstawy

Po omówieniu różnych architektur i sposobów, w jaki możemy zestawiać nasze środowisko storage, nadszedł czas na zmianę tematu. Kilka następnych wpisów będzie na temat wirtualizacji. Początkowo bardzo ogólnie, potem wyspecjalizujemy się w stronę wirtualizowaniu storage. Oczywiście, ponieważ ISM jest certyfikatem "podstawowym", nie ma się co nastawiać na bardziej zaawansowane informacje, większość będzie na poziomie bardzo elementarnym i, co by tu nie mówić, raczej oczywistym dla wszystkich siedzących w IT.

Zaczniemy od definicji:

Virtualization - "Technique of abstracting physical resources in to logical view"

Nieco potocznie można powiedzieć że wirtualizacja (ogólnie) polega na  łączeniu wszystkich fizycznych urządzeń danego typu ( serwer , storage , networking itd...)  w pule, a następnie tworzeniu i wydzielaniu, ich logicznych odpowiedników.


Zalety wirtualizacji:

• Lepsza utylizacja i wykorzystanie zasobów IT
• Łatwiejsze zarządzanie
• Redukcja downtime-u ( zarówno planowanego jak i nieplanowanego )

Zakres wirtualizacji:


Wirtualizację można stosować do różnych rodzajów urządzeń. Kilka najbardziej standardowych przykładów jej zastosowania to:

• Wirtualizacja pamięci - Każda aplikacja widzi swoją własną przestrzeń dyskową, niewspółdzieloną z innymi programami i niezależną od pamięci fizycznej. Do zarządzania pamięcią wirtualną i mapowania pomiędzy jej adesami, a adresami w pamięci fizycznej, stosowane są aplikacje nazywane Virtual Memory Menager (VMM). W większości współczesnych implementacji wirtualnej pamięci, przestrzeń adresowa podzielona jest ciągłe bloki o określonej wielkości, zwane stronami (pages). Proces, zwany stronicowaniem (paging), przenosi nieaktywne strony z pamięci fizycznej i zapisuje je na dyski twarde. Dzięki temu możemy efektywne wykorzystać dostępną pamięć fizyczną, poprzez trzymanie w niej jedynie aktywnej zawartości. Plik, na dysku twardym, w którym przechowywane są dane z RAMu nazywany jest plikiem wymiany (swap file). 
• Wirtualizacja sieci - podobnie jak w przypadku wirtualizowania pamięci, wirtualizacja sieci sprawia, że każda aplikacja widzi swoją własną sieć logiczną, niezależną od fizycznej. Przykładem wirtualizacji sieci są VLANy ( Virtual LAN) - sieć fizyczna jest podzielona (wirtualnie) na logiczne. Komputery i aplikacje nie widzą struktury fizycznej oraz hostów które się w niej znajdują, z wyjątkiem tych znajdujących sie w tym samym VLANie. Odpowiednikiem VLANów w środowisku SAN są VSANy.
• Wirtualizacja serwerów - polega (oczywiście w gigantycznym uproszczeniu) na tworzeniu maszyn wirtualnych, a następnie uruchamianiu dużej ich ilości na jednym ( lub większej ilości) hostów fizycznych. Na maszynach wirtualnych instaluje się system operacyjny oraz aplikacje. Są one odizolowane od fizycznej części hardware. 
• Wirtualizacja storage - polega na prezentowaniu do hostów logicznych zasobów storage, stworzonych na zasobach fizycznych. Przykładami wirtualizacji storage są: volume management na poziomie hosta , tworzenie LUNów, wirtualizacja taśm magnetycznych (VTL)

Wirtualizacja storage:

Organizacja SNIA (Storage Networking Industry Association) rozłożyła sposoby wirtualizacji storage na "części pierwsze" i zaproponowała ich trzystopniową klasyfikację:

LEVEL 1: Co jest tworzone? - czyli wirtualizacja różnych urządzeń w obrębie storage

• Block virtualization
• Disk virtualization
• Tape , Tape Drive , Tape Library Virtualization
• File System , File/Record Virtualization
• Other Devices Virtualization

LEVEL 2: Gdzie jest tworzone? - czyli w którym miejscu infrastruktury uruchamiany wirtualizację

• Host Based VIrtualization (Path management , Volume Management , Replication)
• Network Based Virtualization (Path redirection , Load balancing - ISL trucking , Zoning )
• Storage Device Virtualization (Access control , Replication , RAID )

LEVEL 3: W jaki sposób wirtualizacja jest zaimplementowana?

• In-band Virtualization (wirtualizacja odbywa się na ścieżce danych)
• Out-of-band Virtualization (środowisko wirtualizacyjne znajduje się poza ścieżką danych)

Wyzwania stawiane przed wirtualizacją storage:

Aby implementacja wirtualizacji storage była opłacalna, muszą być rozważone pewne kwestie, w których może ona pogorszyć działanie naszego środowiska.

Najważniejsze z takich kwestii to:

• Skalowalność i wymagania wydajnościowe : Przed zwirtualizowaniem nasze środowisko storage składa się z niezależnych macierzy, z których każda ma określoną wydajność i pojemność. Dla każdej z nich, niezależnie, wyznaczane są pewne progi. Po zwirtualizowaniu mamy jedną "pulę" storage , należy zadbać, aby na tym poziomie, wydajność spełniała założone kryteria.
• Funkcjonalność: Macierze dysponują różnoraką dodatkową funkcjonalnością poza samym składowaniem i udostępnianiem danych ( np: Thin Provisioning , Replikacja , Automated Tiering itd...). Środowisko po zwirtualizowaniu również powinno zezwalać na stosowanie tych mechanizów.
• Zarządzanie: Po zwirtualizowaniu naszego storage , nowe mechanizmy zarządzające powinny zintegrować się z fizycznymi macierzami i zezwalać na wygodne zarządzanie.
• Wsparcie: Wprowadzenie wirtualizacji nie powinno utrudnić identyfikacji problemów sprzętowych w warstwie fizycznej. Zwirtualizowanie storage może sprawić, że pewne dane diagnostyczne, mogą być niejasne lub niekompletne, ponieważ między punktem ich zbierania a samym sprzętem, znajduje się jeszcze warstwa wirtualizacyjna.

Wirtualizacja na poziomie bloku:

Wirtualizacja na poziomie bloku odbywa się w sieci SAN, pomiędzy hostami a macierzami. Cały ruch pomiędzy tymi urządzeniami przechodzi przez wirtualizator. Środowisko macierzy może być heterogeniczne, ale do samych hostów prezentowane jest jedno wirtualne urządzenie storage. Ponieważ same fizyczne macierze nie są widoczne dla hostów, można bez przerw w dostępie danych re-konfigurować środowisko np: dodając nowe urządzenia. Bez zakłóceń można także przeprowadzać migrację danych między fizycznymi macierzami.

Wirtualizacja na poziomie pliku:

Używana jest w środowisku NAS. Likwiduje powiązanie między plikiem i fizyczną lokacją, gdzie on się znajduje. Bez wirtualizacji, do dostępu do pliku, jest używana cała ścieżka (struktura katalogów, folderów itd.) Klienci NASa, kontaktują się z serwerami plików, a te udostępniają im zasoby z podłączonej macierzy, poprzez podanie im ścieżki fizycznej do tych plików. Po zwirtualizowaniu ścieżki fizyczne zostają zastąpione ścieżkami logicznymi. Pozwala to, między innymi, na migracje plików między serwerami plików, bez potrzeby przekonfigurowywania klientów ( nie zmienia się ścieżka dostępu ).

---

Kolejny wpis dotyczyć będzie "thin provisioning" ( nazywanego także niekiedy "virtual provisioning"). Jest to przykład wirtualizowania storage, a sama funkcjonalność jest bardzo często spotykana w macierzach klasy "enterprise" i "mid-range".
A chwilę potem temat który już się raz pojawił w tym blogu a mianowicie "Cloud computing"

ISM - CAS - Content Addressed Storage

CAS, czyli Content Addressed Storage, jest to system przechowujący pewne specyficzne dane, których główną cechą jest to że nie ulegają zmianie. Ilość takich niezmienialnych danych (fixed content) rośnie bardzo gwałtownie. Dodatkowo zwykle wymagana jest ich ciągła dostępność i odczyt przez wielu użytkowników jednocześnie; powoduje to pewne trudności w zarządaniu nimi w "tradycyjny" sposób.
Przykładem fixed content są: Emaile , projekty CAD/CAM, kontrakty , fotografie , dane medyczne , video , audio, dane pomiarowe itd...


Tradycyjne rozwiązania dla archiwizacji danych:

Wyróżnić można 3 tradycyjne kategorie rozwiązań dla przechowywania danych archiwalnych: online , nearline , offline.

• Online archive: Storage jest bezpośrednio połączony z hostem i dane są natychmiast dostępne.
• Nearline archive: Strorage jest podpięty do hosta i dane są przechowywane lokalnie ale urządzenie musi zostać podmontowane lub załadowane zanim uzyskany zostanie dostęp do informacji
• Offline archive: Storage nie jest bezpośrednio przyłączony do hosta. Wymagana jest ręczna interwencja zanim uzyskany zostanie dostęp do danych.

Archwa bardzo często przechowywane są na urządzeniach WORM (Write Once Read Many ) - np: CD-ROMie , dzięki temu można być pewnym że nie zostały zmodyfikowane.

Tradycyjne rozwiązania mają wady które powodują, utrudnienia w skutecznym zarządzaniu danymi niezmienialnymi:

• Taśmy magnetyczne są bardzo wolne, dodatkowo często zmieniają się ich standardy
• Nośniki optyczne są drogie i mało pojemne
• Odzysk plików z taśm lub nośników optycznych jest bardzo czasochłonny
• Zarówno taśma jak i nośniki optyczne są wrażliwe na uszkodzenia i wpływ czasu na ich jakość

CAS:

Odpowiedzią na rosnące zapotrzebowanie na przechowywanie danych niezmienialnych jest technologia CAS ( Content Addressed Storage ). CAS jest systemem dedykowanym do przechowywania danych typu "fixed content". Podstawową jednostką danych dla systemu CAS jest obiekt. Obiektem nazywamy w tym przypadku dane (plik) i jego atrybuty. Dla CASu ważne jest nie tyle położenie danego obiektu ( tak jak w tradycyjnym zarządzaniu storage) ale jego zawartość. Dodatkowo z każdego obiektu robiony jest tzw: hash , zwany także content adress (CA). CAS jest rozwiązaniem typu single-instance storage (SIS), który automatycznie wykrywa (poprzez porównywanie CA) i redukuje wszystkie zdublowane obiekty.

Zalety stosowania CASu:

• Autentyfikacja i integralność treści : Ponieważ każdy obiekt ma przypisany do siebie unikalny skrót, który go identyfikuje, niemożliwa jest zmiana jego treści bez wykrycia tego faktu. Jeżeli obiekt został zmieniony na skutek uszkodzenia, to z kopii odzyskiwana jest oryginalna postać. Jeżeli była to zmiana zamierzona, to liczony jest nowy skrót , a przechowane zostają obydwie wersje obiektu (aktualna i zastąpiona)
• Niezależność o położenia: Dostęp do obiektu odbywa jest niezależny od jego położenia, które jest transparentne dla aplikacji zgłaszającej zapotrzebowanie na dane. Adresowanie odbywa się bez podawania informacji o ścieżkach katalogów, URLach czy folderach.
• Single-instance storage (SiS) : Dzięki temu, że adresem obiektu jest jego unikalny skrót, wygenerowany na podstawie zawartości, mamy gwarancję, że przechowywana jest tylko jedna kopia. Jeżeli na systemie zostaje zeskładowany obiekt o identycznej treści, niż istniejący już w systemie, to zamiast przydzielać mu dodatkowe miejsce, system skieruje wskaźnik ( skrót ) nowego obiektu do tego już obecnego.
• Wymuszenie retencji: Obiekt, oprócz samych danych, zawiera także meta-date, opisujące jego atrybuty oraz polityki, które się do niego odnoszą. Między innymi jest tam zawarta informacja o retencji i czasie przez jaki obiekt ma być przechowywany. Przed upłynięciem tego okresu niemożliwe jest usunięcie obiektu.
• Niezależność od technologii
• Szybkość działania

Architektura rozwiązań CAS:

Klient uzyskuje dostęp do macierzy typu CAS poprzez połączenie siecią LAN i wykorzystując do tego serwer z uruchomionym CAS API. Server ten umożliwia, aplikacji na kliencie, magazynowanie i przeglądanie danych z macierzy CAS.

CAS działa w strukturze nazywanej RAIN ( Redundant Array of Independent Nodes ). Składają się na nią węzły storage i węzły dostępu do sieci, połączone w cluster i komunikujące się za pomocą wewnętrznej sieci LAN. Klienci łączą się do systemu CAS używając niezależnej, zewnętrznej sieci LAN.

Węzły storage zwierają tanie i o dużej pojemności dyski ATA. Każdy węzeł ma także swój system operacyjny, z oprogramowaniem udostępniającym funkcjonalność CAS.

Podczas instalowania CAS clustra, każdemu z węzłów zostaje przypisana rola. Węzeł może być węzłem storage, access lub dual.
Węzły storage przechowują dane, czasem nazywa je się węzłami back-end. Zadaniem węzłów access jest udostępnić serwerowi dostęp do węzłów storage, poprzez wewnętrzny LAN. Ilość węzłów access zależy od ilości użytkowników, którzy będą korzystali z zasobów CAS. Pamięć dyskowa węzła skonfigurowanego jako access jest niewykorzystana. Takie węzły zwykle występują w instalacja CAS starszego typu.
Węzeł dual działa jak węzeł storage i access jednocześnie. Jest spotykany w konfiguracjach typu "pure node access".


Terminologia CAS:

• API ( Application Programming Interface ) - implementacja interfejsu, która określa w jaki sposób klienci wysyłają swoje zapytania do serwera. CAS API jest umieszczone na serwerze aplikacji i odpowiada za przechowywanie i pobieranie objektów z systemu CAS.
• BLOB ( Binary Large Object ) - dane bez opisu (metadanych).
• CA ( Content Address ) - adres obiektu wygenerowany za pomocą algorytmu haszującego wykonanego na binarnej reprezentacji obiektu. Zmiana nawet pojedyńczego znaku w obiekcie powoduje całkowitą zmianę CA , dlatego też może być ona używana do jako "odcisk palca" obiektów. CA jest używane przez serwer do zlokalizowania obiektu na macierzy CAS
• C-Clip - Wirtualna paczka zawierająca dane (BLOB) i powiązane z nim CDF. C-Clip ID to CA wysyłane do aplikacji klienta.
• CDF ( C-Clip Descriptor File ) - Plik XMLowy tworzony przy tworzeniu C-Clipa , zawiera CA oraz wszyskie metadane związane z obiektem (wielkość, format , data wygaśnięcia itd.)

Proces składowania obiektów przez CAS:

1. Użytkownik za pośrednictwem aplikacji wysyła do CAS API informację o danych do zarchiwizowania
2. API oddziela dane (BLOB) od metadanych, CA jest liczone
3. CA i metadane objektu są umieszczane w CDF . C-Clip ( BLOB+CDF) zostaje przesłany do CAS 
4. System CAS jeszcze raz przelicza CA i porównuje go z tym które otrzymał (weryfikacja poprawności)
5. Tworzone są kopie CDF i BLOB , a następnie do API wysyła się potwierdzenie zeskładowania obiektu. Do API wysyła się takżę C-Clip ID, które będzie przechowywane na serwerze aplikacji.
6. Aplikacja używając C-Clip ID może odczytać dane z CAS

Proces odczytu obiektów z CAS:

1. Użytkownik lub aplikacja wysyła żądanie dostępu do obiektu
2. Aplikacja przeszukuje tablicę C-Clip ID w poszukiwaniu C-Clip ID obiektu którego dotyczyło zapytanie
3. Za pośrednictwem API , żądanie jest wysyłane razem z C-Clip ID do systemu CAS
4. CAS dostarcza obiekt.

---

W kolejnych wpisach zmienimy nieco tematykę i zajmiemy się wirtualizacją.

ISM - FCOE - Fibre Channel over Ethernet

FCoE czyli Fibre Channel over Ethernet jest jeszcze nowszym "wynalazkiem", do przesyłu danych blokowych poprzez sieci LAN, niż przybliżone funkcjonalnością rozwiązania iSCSI i FCIP. Jak sama nazwa wskazuje jest to protokół, który pozwala przesyłać dane FC poprzez Ethernet.
FCOE nie wykorzystuje jednak "standardowego" Ethernetu, ale jego rozbudowaną wersję czyli tzw: CEE ( Converged Enhanced Ethernet) zwany także DCE (Data Center Ethernet) - przy czym ta druga nazwa jest zastrzeżona przez Cisco. Główne zmiany pomiędzy tym "wzbogaconym", a "normalnym" Ethernetem są związane z wyeliminowaniem tzw: "frame drops" i utraty pakietów podczas transmisji.


Zalety FCOE:

• Mniejsze koszta - redukcja ilości kabli, switchy, hba etc... spowodowana zastępieniem dwóch niezależnych środowisk SAN i LAN, jednym.
• Zmniejszone wymaganie na moc i chłodzenie
• Konsolidacja infrastruktury sieciowej

W przypadku zastosowania FCOE, hosty nie muszą mieć dwóch rodzajów kart sieciowych osobno dla sieci LAN (NIC) i sieci SAN (HBA), zostają one zastąpione jedną o nazwie CNA ( Converged Network Adapter ), która konsoliduje zarówno ruch network jak i storage. Powoduje to ograniczenie okablowania, zużycia portów oraz zapotrzebowania na moc i chłodzenie.


Fizyczne komponenty:

CNA składa się z trzech układów (ASIC):

• 10 Gigabit Ethernet
• Fibre Channel
• Menlo ASIC ( używany do enkapsulacji FC frames w Ethernet frames)

Dopuszczalne są dwa rodzaje kabli:

• Copper Base Twinax - wersja atrakcyjna kosztowo , skaład się z dwóch par kabli miedzianych pokrytych ochraniającą otuliną
• Standard optical

Ramka FCOE:

Ramka FCOE skłąda się z następujących części:

• Ethernet Header ( zwykły nagłówek ethernetowy , Ether type = FCoE )
• FCoE Header  ( Control Information: Version and Ordered Sets (SOF & EOF ) )
• FC Header ( zwykły nagłówek FC )
• FC Payload ( do 2112 Bajtów )

Standardowa ramka ethernetowa ma 1,5KB lub mniej , natomiast ramka FC - 2112 bajtów danych + nagłówek. Aby "zapakować" ramkę FC do Ethernetowej wymagana jest obsługa jumbo frames (2180 - support ) tak aby zapobiec dzielenia jednej ramki FC na dwie Ethernetowe.

FCoE, w przeciwieństwie do iSCSI nie może być uruchomione na dowolnej sieci Ethernetowej. Wymaga specyficznego rozszerzonego Ethernetu i obsługi Jumbo Frames.

Ehternet z którego korzysta FCoE musi być bezstratny , żadna z ramek nie może być utracona poprzez cały okres trwania transmisji. Ponieważ "zwykły" Ethernet nie zapewnia tego, aby to uzyskać trzeba wykorzystać pewne opcjonalne funkcjonalności opisane w standardzie IEEE 802.3x. Stosuje się tzw: PAUSE , która pozwala portowi docelowemu wysłanie polecenia czasowego wstrzymania transmisji do portu źródłowego, jeżeli zachodzi niebezpieczeństwo utraty danych.


Porównanie stosów protokołów w poszczególnych rozwiązaniach:

1. SCSI - Najbardziej "zwięzłym" sposobem transmisji jest czyste SCSI , nie ma wtedy żadnej dodatkowej warstwy.
2. FC - Następnie mamy FC gdzie komendy SCSI są enkapuslowane w protokole FCP : SCSI --> FCP
3. FCoE - Kolejny rozwiązanie to FCoE , w tym przypadku SCSI jest enkapsulowane w FCP następnie w FCoE i całość w ramce Ethernetowej: SCSI --> FCP --> FCoE --> Ethernet
4. iSCSI - Bardziej skomplikowane ( więcej dodatkowych nagłówków do przetworzenia ) ma iSCSI : SCSI --> iSCSI --> TCP --> IP --> Ethernet
5. FCIP - Największa ilość dodatkowych warstw jest zastosowana w FCIP: SCSI --> FCP --> FCIP --> TCP --> IP --> Ethernet

---

Ten wpis nie był zbyt rozbudowany , samo FCoE nie zajmuje zbyt dużo miejsca w materiałach EMC do kursu ISM. Osobiście też nie miałem okazji spotkać sie z tymi rozwiązaniami w praktyce.
Następnym razem zaczniemy zaznajamiać się z CASem ( Content Addressed Storage )

ISM - IP SAN - czyli jak schować SANa w LANie

Przyszła kolej na omówienie dość nowych ( w porównaniu do na przykład takiego FC, nie mówiąc już o SCSI ) rozwiązań, znanych zbiorczo pod nazwą IP SAN. W skrócie można powiedzieć, że chcemy wykorzystać "normalną" sieć do przesyłania danych blokowych. Można to robić albo wprost używając iSCSI, albo enkapsulując tradycyjne FC w ramkach  TCP/IP, mamy wtedy do czynienia z FCIP.


Tradycyjnie w sieci SAN mamy blokowe I/O, przesyłane przez sieć Fibre channel. Z kolei rozwiązanie typu NAS wysyłają pliki poprzez sieci IP-based. IP SAN to próba połączenia zalet z tych dwóch rozwiązań: Z jednej strony wydajność i skalowalność sieci SAN, z drugiej niski współczynnik TCO (Total Cost of Ownership) charakteryzujący NASy.

Użycie protokołu IP i sieci na nim opartych do blokowego transportu danych ma następujace zalety:

• Łatwiejsze zarządzanie
• Można wykorzystać istniejącą infrastrukturę LAN
• Koszty sprzętu i oprogramowania są mniejsze w porównaniu do SANa
• Lepsze działanie w sieciach multi-vendor
• Możliwe do uzyskania są większe odległości
• Rozwiązanie dotyczące bezpieczeństwa są bardziej rozbudowane niż w sieciach SAN

Protokoły używane w IP SAN:
Obecnie używane są dwa protokoły do przesyłu danych blokowych poprzez sieci IP: iSCSI i Fibre Channel over IP (FCIP)

iSCSI polega na enkapsulacji poleceń SCSI w ramkach IP przeprowadzane poprzez hosta ( za pomocą normlanej karty NIC lub specjalizowanego iSCSI HBA). Po drugiej stronie znajduje się macierz iSCSI lub iSCSI Gateway, który łączy ze sobą sieci LAN i SAN.
FCIP wymaga użycia dwóch FCIP gateway które pozwalają przesłać dane pomiędzy dwoma niepołączonymi SANami za pomocą sieci IP ( LAN/WAN)


iSCSI:

Łączy ze sobą hosty,storage i iSCSI gateway-e. Przenosi blokowe dane poprzez sieć IP. SCSI komendy są enkapsulowane i wysyłane jako pakiety TCP/IP

Są trzy możliwości podłączenia i skonfigurowania iSCSI po stronie hosta:

1. Wykorzystując normalne karty NIC. Jest to najłatwiejsza w implementacji i najmniej kosztowna metoda. Oprócz zwykłej karty sieciowej wymaga jeszcze softwarowego inicjatora dla zapewnienia funkcjonalności iSCSI. Główną wadą tego rozwiązania jest zmniejszenie wydajności serwera, ponieważ wszyskie operacje związane z przesyłąniem oraz enkapsulowaniem i dekapsulowaniem iSCSI muszą być wykonywane przez CPU hosta.
2. NIC z TOC ( TCP Offload Engine ) - w tych rozwiązaniach karta NIC dodatkowo przejmuje na siebie wszyskie operacje dotyczące TCP. Procesor dalej obciążony jest przetwarzaniem funkcjonalności związanej z iSCSI
3. iSCSI HBA - obsługuje cały stos protokołów związanych z TCP/IP i iSCSI przez co obciążenie procesora jest najmniejsze. Dodatkowo użycie iSCSI HBA pozwala na bootowanie hosta z sieci SAN. Bez tego funkcjonalność ta musi być wbudowana w system operacyjny.

Stos protokołu iSCSI:

Ethernet ( Layer 2 Data Link ) ---> IP ( Layer 3 Network ) --> TCP ( Layer 4 Transport ) --> iSCSI ( Layer 5 Session ) --> SCSI ( Layer 7 Application )

Topologie iSCSI:

iSCSI może być zaimplementowane w dwóch topologiach: native i bridged

• Native - nie wymaga żadnych komponentów FC, cała komunikacja odbywa się po sieci IP
• Bridged - w komunikacji używa się zarówno sieci IP jak i FC, a konwersja sygnału odbywa się w iSCSI Gateway-ach.

Jako trzecią topologię można też wyróżnić Połączenie FCP i Native iSCSI - sytuacja ta zachodzi kiedy macierz posiada zarówno porty iSCSI jak i FC i wystawia swoje zasoby do hostów jednocześnie na tych dwóch protokołach.

Internet Storage Name Server:

Aby komunikacja po iSCSI mogła się odbyć, inicjator musi znać położenie targetu z którym chce nawiązać połączenie. Proces discovery może odbyć się za pomocą dwóch metod: SendTargets discovery i internet Storage Name Service (iSNS).

W SendTargets discovery, każdy inicjator, ręcznie ma skonfigurowane informacje o targetach, które pozwalają mu nawiązać z nimi discovery sesję. Inicjator wysyła SendTargets polecenie i target odpowiada list nazw i adresów targetów dostępnych dla danego hosta.
iSNS umożliwia automatyczne wykrycie ( bez discovery session ) urządzeń iSCSI. Inicjatory i targety powinny być skonfigurowane i automatycznie rejestrować się na iSNS serwerze. Kiedy inicjator chce poznać listę targetów do których ma dostęp, wysyła zapytanie do iSNS serwera.

Discovery Domains - odpowiednik zone sets w środowisku iSCSI.

Adresacja (nazewnictwo) iSCSI:

Wyróżnia się dwa rodzaje nazw (adresów) iSCSI:

• iSCSI Qualified Name (IQN):  Firma musi mieć zarejestrowaną własną domenę aby móc używać nazw IQN. Jest ona potrzebna ponieważ zawiera się ona w adresach IQN przyporządkowanych danemu przedsiębiorstwu. 
• Extended Unique Identifier (EUI): Unikalny globalnie identyfikator bazujący na IEEE EUI-64 standardzie. Składa się z 24 bitowej części odpowiadającej za identyfikację firmy i 40 bitowego ID konkretnego urządzenia.

FCIP (Fibre Channel over IP):


FCIP łączy w sobie zalety protokołu FCP oraz IP, pozwala na łączenie ze sobą odległych środowisk SAN poprzez tworzenie wirtualnego połączenia FC poprzez sieć LAN/WAN. Jest to możliwe poprzez użycie specjalnych urządzeń (FCIP Gateway) które enkapsuluje ramki FC w pakietach TCP/IP

FCIP Link - każde połączenie między 2 niezależnymi "wyspami" SANowymi

FCIP Routery (Gatewaye) są widziane przez urządzenia w fabricu jako normalne FC switche.

---

Kolejny wpis będzie na temat FCOE ( Fibre Channel over Ethernet) a potem przejdziemy do CAS (Content Addressed Storage).
Za niedługo miną 2 miesiące od kiedy rozpocząłem wpisy związane z certyfikatem e20-001 i jak na razie nawet nie jesteśmy w połowie materiału. Dobrze było by przyśpieszyć, ale nie wiem czy w natłoku innych zajęć będzie to możliwe...