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


    sobota, 18 września 2010

    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)


    czwartek, 16 września 2010

    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.

    środa, 15 września 2010

    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"

    sobota, 11 września 2010

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

    wtorek, 7 września 2010

    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 )




    niedziela, 5 września 2010

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