Wirtualizacja bez macierzy? Żaden problem. Dariusz.Puchalak@osec.pl
Dariusz Puchalak 20 lat Linux/Unix Sysadmin 8+ lat trener Od roku w OSEC
http://www.osec.pl 6+ lat na rynku doświadczona kadra (ACNI, RHCA) specjalizacja open-source
Tradycja kontra inowacje.
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
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. :(
Dlaczego macierz??
Dlaczego macierz? Wspólny storage czyli: (Możliwa lub) łatwa migracja wirtualek na inne systemy HA (wysoka dostępność) Wysoka wydajność
Czy można bez macierzy??
Rozwiązania programowe. iscsi DRBD.* == Software Defined Storage
Software Defined Storage, czyli: GlusterFS sheepdog Ceph Inne.
Software Defined Storage Tylko w konteksie wirtualizacji. Nie będzie ani słowa o OpenStack bo to inna filozofia.
Skalowalność.
Skalowalność.
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.
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 :(
Dostęp do danych w SDS.
Omawiany tylko dostęp blokowy.
Architektura Software Defined Storage.
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
SDS - pojemność. Zwiększenie pojemności porzez: Dodanie dysków Dodanie kolejnych nodeów
SDS wydajność. Zwiększenie wydajności porzez: Dodanie dysków Dodanie kolejnych nodeów
SDS wydajność. Prawdopodobnie najważniejszy parametr: Poprawne zaprojektowanie i zaimplementowanie sieci!!!
SDS wydajność sieci. 10 Gbps Ethernet ew. linki 1Gbps spięte razem.
SDS podstawowe pojęcia. Quorum Cluster Połączenia sieciowe
Skalowalna wirtualizacja?
Skalowalna wirtualizacja?
Architektura Software Defined Storage.
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.
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.
Zarządzalność Self Healing Self Manage Snapshots Rollback COW (Copy on Write) Backups full and incremental
GlusterFS
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 2005-2006 roku. Brak specjalnych wymagań sprzętowych. Brak Single Point Of Failure
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 2005-2006 roku. Brak specjalnych wymagań sprzętowych. Brak Single Point Of Failure
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
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
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.
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)
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 = 4+2 11 = 8+3 12 = 8+4
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)
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
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).
Sheepdog
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
Sheepdog - wymagania System plików wspierający rozszerzone atrybuty Kernel >= 2.6.32
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)
Sheepdog - możliwości Repliki Erasure coding ( kody korekcyjne )
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.
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). :)
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). :)
Sheepdog uproszczony workflow. Skonfigurować i uruchomić klaster Przygotować dedykowany system plików z obsługą rozszerzonych atrybutów. Z formatować klaster Używać ;>
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)
Sheepdog zalety i wady Zalety: Prosty ideowo Skuteczne automatyczne mechanizmy naprawy Wsparcie dla DISCARD/UNMAP Wady: Brak wsparcia przez tzw. komercyjne Linuksy.
Ceph
Ceph z odległości 10 000m Rozproszony system obiektowy Redudantny Wysoce wydajny Skalowalny Brak wąskich gardeł Brak specjalnych wymagań sprzętowych. Brak Single Point Of Failure
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
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
Pytania? Dariusz.Puchalak@osec.pl
Dziękuję. :)