Wirtualizacja bez macierzy? Żaden problem.

HTML
DOWNLOAD

Wielkość: px

Rozpocząć pokaz od strony:

Download "Wirtualizacja bez macierzy? Żaden problem. Dariusz.Puchalak@osec.pl"

Edward Cybulski
9 lat temu
Przeglądów:

1 Wirtualizacja bez macierzy? Żaden problem.

2 Dariusz Puchalak 20 lat Linux/Unix Sysadmin 8+ lat trener Od roku w OSEC

3 6+ lat na rynku doświadczona kadra (ACNI, RHCA) specjalizacja open-source

4 Tradycja kontra inowacje.

5 Model tradycyjny. Macierz sprzętowe (zwielokrotniona wewnątrz). Serwery podpięte pod macierz interfejsem SAN: Fibre channel (na bogato) SAS (wersja ekonomiczna) Serwery podpięte pod macierz interfejsem NAS (wersja ekonomiczna): NFS iscsi

6 Wady modelu tradycyjnego. Biznesowo: Koszt Koszt Skalowalność i związany z tym koszt Technicznie: Brak licencji na ten element który by się przydał, bo za drogo. :(

7 Dlaczego macierz??

8 Dlaczego macierz? Wspólny storage czyli: (Możliwa lub) łatwa migracja wirtualek na inne systemy HA (wysoka dostępność) Wysoka wydajność

9 Czy można bez macierzy??

10 Rozwiązania programowe. iscsi DRBD.* == Software Defined Storage

11 Software Defined Storage, czyli: GlusterFS sheepdog Ceph Inne.

12 Software Defined Storage Tylko w konteksie wirtualizacji. Nie będzie ani słowa o OpenStack bo to inna filozofia.

13 Skalowalność.

14 Skalowalność.

15 Dlaczego Scale-Out? Scale Out: Dużo, tanio, bardzo dużo i bardzo tanio. ;> Rozbudowa o dowolny sprzęt. Przygotowane do awarii pojedynczych komponentów (w tym całych serwerów) na poziomie oprogramowania.

16 Dlaczego nie Scale-Up? Scale Up: Pojedyncze rozbudowane i drogie komponenty. Przygotowanie na awarie pojedynczych komponentów na poziomie sprzętu (np.. redudantne kontrolery). Drogo (czasem nawet bardzo drogo). :( Vendor Lock-In :(

17 Dostęp do danych w SDS.

18 Omawiany tylko dostęp blokowy.

19 Architektura Software Defined Storage.

20 Architektura SDS. Skalowalność - Scale-up/Scale-out Zdecentralizowany? Wysoka dostępność Wysoka wydajność Typowy sprzęt serwerowy Fizyczny sprzęt lub chmura Połączenia do danych w technologiach dobrze znanych *Ethernet, Infiniband

21 SDS - pojemność. Zwiększenie pojemności porzez: Dodanie dysków Dodanie kolejnych nodeów

22 SDS wydajność. Zwiększenie wydajności porzez: Dodanie dysków Dodanie kolejnych nodeów

23 SDS wydajność. Prawdopodobnie najważniejszy parametr: Poprawne zaprojektowanie i zaimplementowanie sieci!!!

24 SDS wydajność sieci. 10 Gbps Ethernet ew. linki 1Gbps spięte razem.

25 SDS podstawowe pojęcia. Quorum Cluster Połączenia sieciowe

26 Skalowalna wirtualizacja?

27 Skalowalna wirtualizacja?

28 Architektura Software Defined Storage.

29 Odporność na awarie. Odporność na awarię poszczególnych komputerów wchodzących w skład SDS można zapewnić poprzez: Rozproszenie danych na wielu serwerach. Replikację - kosztowne do strony wymaganych dysków. Erasure Coding (kody korekcyjne) znacząco ogranicza ilość wykorzystanej przestrzeni dyskowej.

30 Skalowalność. Skalowalność rozwiązań można zapewnić poprzez: Load Balancing rozkładanie obciążenia Zwiększenie wydajności I/O poprzez: dodanie kolejnych urządzeń (dysków/serwerów) wykorzystanie dysków SSD.

31 Zarządzalność Self Healing Self Manage Snapshots Rollback COW (Copy on Write) Backups full and incremental

32 GlusterFS

33 GlusterFS Rozproszony system plików działający w przestrzeni użytkownika. Skalowalny do Petabajtów i tysięcy klientów. Brak osobnego node/ów dla metadanych metadane w pełni rozproszone. Powstał w roku. Brak specjalnych wymagań sprzętowych. Brak Single Point Of Failure

34 GlusterFS Rozproszony system plików działający w przestrzeni użytkownika. Skalowalny do Petabajtów i tysięcy klientów. Brak osobnego node/ów dla metadanych metadane w pełni rozproszone. Powstał w roku. Brak specjalnych wymagań sprzętowych. Brak Single Point Of Failure

35 GlusterFS - workflow Komputer (min. 2 szt. - może być nawet maszyna wirtualna) Linux Dysk System plików z obsługą rozszerzonych atrybutów (np. ext4, xfs) Instalujemy glusterfs

36 GlusterFS - workflow Na posiadanej wolnej przestrzeni tworzymy nowy system plików (brick) Montujemy Tworzymy katalog w miejscu zamontowania Dodajemy serwery z glusterfs do klastra (Trusted Storage Pool) Wskazujemy glusterowi gdzie ma tzw. bricks. Tworzymy gluster volume Wskazujemy QEMU gdzie jest gluster volume Uruchamiamy maszyn wirtualne korzystające z klastra

37 GlusterFS rozszerzony workflow Brick tworzymy na LVM'ie typu Thin (co nam da możliwość wykonywania snapshotów) Aby lepiej wykorzystać dyski SSD i HDD używamy LVM cache.

38 GlusterFS typu wolumenów Striped (jak RAID-0) Distributed (jak stripe, ale rozdziela dane) Replicated (jak RAID-1) Striped-Replicated (jak RAID-10, ale rozdziela dane) Distributed-Replicated (jak RAID-10) Distributed-Striped-Replicated (wysoce dostępny i wysoce wydajny) Dispersed Erasure Coding (w trakcie)

39 GlusterFS dispersed Określamy odporność na awarię według wzoru: N = k + m N ilość bricks K tyle musi działać aby móc odzyskac dane M tyle może nie działać aby móc odzyskać dane Typowe wartości: 6 = = = 8+4

40 GlusterFS Elastic Hashing Algoritm Brak trzymania indeksu dla metadanych Każdy node może zlokalizować dane bez odpytywania innego serwera Dostęp równoległy (np. dla 2 replik/kopii w sieci są od razu 2 strumienie danych do serwerów)

41 GlusterFS Self Healing i Split Brain Rozwiązywany bardzo skutecznie w sposób automatyczny (od wersji 3.3) Gdy automat nie zadziała dla niektórych danych, można wymusić ręcznie Wsparcie dla quorum Server side Client side

42 GlusterFS zalety i wady Zalety: Bardzo prosty ideowo Skuteczne automatyczne mechanizmy naprawy Wsparcie dla DISCARD/UNMAP Wady: Brak zaawansowanych mechanizmów np. pozwalających lepiej wykorzystać dyski SSD Kontrola tylko na poziomie adresów IP. Nie sprawdza się jeśli klient ma mieć bezpośredni dostęp do serwerów GlusterFS (możliwość wycieku danych).

43 Sheepdog

44 Sheepdog Rozproszony system obiektowy stworzony do współpracy z QEMU. Wykorzystuje technologię klastrową (Corosync lub Apache ZooKeeper) Brak osobnego node/ów dla metadanych metadane w pełni rozproszone. Powstał w 2010 roku. Brak specjalnych wymagań sprzętowych. Brak Single Point Of Failure

45 Sheepdog - wymagania System plików wspierający rozszerzone atrybuty Kernel >=

46 Sheepdog - możliwości Snapshot Klonowanie Backup przyrostowy Snapshot na poziomie całego klastra Discard (thin-storage/ssd) Automatyczny rebalancing: Lokalny (dla dysku) Globalny (dla node'a)

47 Sheepdog - możliwości Repliki Erasure coding ( kody korekcyjne )

48 Sheepdog - możliwości Automatyczne: Rebalancing po dodaniu nowego serwera Naprawa danych utraconych w wyniku awarii serwera kopiowanie inne serwery aby utrzymać wymagany stan nadmiarowości Powrót danych na stare miejsce po naprawie uszkodzonego serwera.

49 Sheepdog - SPOF Brak Single Point Of Failure dla backendu w QEMU. SPOF występuje dla iscsi (tgt). Ale jest iscsi Multipathing (od v.0.9.1). :)

50 Sheepdog - SPOF Brak Single Point Of Failure dla backendu w QEMU. SPOF występuje dla iscsi (tgt). Ale jest iscsi Multipathing (od v.0.9.1). :)

51 Sheepdog uproszczony workflow. Skonfigurować i uruchomić klaster Przygotować dedykowany system plików z obsługą rozszerzonych atrybutów. Z formatować klaster Używać ;>

52 Sheepdog snapshots Sheepdog posiada bardzo przyjemne wsparcie dla snapshotów (obraz systemu, lub obraz systemu + RAM). Poprawne wykonanie snapshota na działającym systemie wymaga użycia qemu-ga na kliencie (cache w pamięci)

53 Sheepdog zalety i wady Zalety: Prosty ideowo Skuteczne automatyczne mechanizmy naprawy Wsparcie dla DISCARD/UNMAP Wady: Brak wsparcia przez tzw. komercyjne Linuksy.

54 Ceph

55 Ceph z odległości m Rozproszony system obiektowy Redudantny Wysoce wydajny Skalowalny Brak wąskich gardeł Brak specjalnych wymagań sprzętowych. Brak Single Point Of Failure

56 Ceph z bliska RADOS RBD block device Wsparcie dla QEMU ISCSI RBD gateway (dla VMWARE, HYPER-V) OSD Object Storage Daemon MON Ceph Monitor (min. 3) CRUSH Controlled Replication Under Scalable Hashing PG Placement Groups (100 Placement Groups na 1 OSD) Pools Journal

57 Ceph wymagania. CPU min. 6 rdzeni (12 wątków) Minimum 32GB RAM 300 GB SAS 15k RPM na system (RAID-1) 2xSSD Min. 12TB SAS 7.2k RPM 2x10Gbit/s Ethernet

58 Pytania?

59 Dziękuję. :)

Podobne dokumenty

Wirtualne systemy dyskowe na platformie OpenStack (KVM) Tomasz Paszkowski PLNOG 2012 Warszawa 06.03.2012 r. ss7pro@gmail.com

Wirtualne systemy dyskowe na platformie OpenStack (KVM) Tomasz Paszkowski PLNOG 2012 Warszawa 06.03.2012 r. ss7pro@gmail.com PLNOG Warszawa 2012 Tomasz Paszkowski 1 Wirtualne systemy dyskowe w OpenStack