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 Nova-volume ISCSI CEPH, RBD (KVM) SHEEPDOG (KVM) VSA (Zadara) Glance SWIFT S3 RBD SWIFT PLNOG Warszawa 2012 Tomasz Paszkowski 2
CEPH Rozproszony sieciowy system przechowywania danych zbudowany w architekturze scale-out (cloud friendly). PLNOG Warszawa 2012 Tomasz Paszkowski 3
CEPH OpenSource SPOF free Brak tzw. wąskich gardeł Brak specjalnych wymagań sprzętowych (commodity hardware) Wydajny (limitem jest jedynie szybkość dysków) Aktywnie rozwijany Aktywna społeczność zgromadzona wokół projektu (irc, lista mailingowa) PLNOG Warszawa 2012 Tomasz Paszkowski 4
CEPH, RBD Rados Block Device (RBD), dwa główne komponenty systemu: mon - nadzorca systemu osd - storage daemon, per pojedyńczy dysk (urządzenie blokowe) PLNOG Warszawa 2012 Tomasz Paszkowski 5
CEPH, RBD, MON MON nadzorca systemu. Bardzo lekki proces który odpowiedzialny jest za: Zarządzanie klastrem (min. polityka dystrybucji danych na dyski twarde, lista węzłów) Pośredniczy przy inicjacji połączenia od klientów, dalsza komunikacja bezpośrednio z klastrem (osd) Wbudowany tryb active/active Brain split, nie możliwy. Quorum N/2+1 (min. 3, nie parzysta suma) PLNOG Warszawa 2012 Tomasz Paszkowski 6
CEPH, RBD, OSD OSD storage daemon. Odpowiedzialny za zapis/odczyt danych z dysków. Każdy dysk/urządzenie blokowe ma dedykowany proces (izolacja awarii) Replikuje zapisy danych na kolejne węzły (dowolna ilość kopi danych Pełen load balancing przy odczytach Journaling DO wyboru tryb (ack-writeahead/commitparallel)! PLNOG Warszawa 2012 Tomasz Paszkowski 7
CEPH, RBD, Architektura PLNOG Warszawa 2012 Tomasz Paszkowski 8
CEPH, RBD, Pule Pule: Przechowują obiekty Definicja reguł dostępu i autoryzacji (ACL+ AUTH) Definicja ilości kopi danych (RAID) Definicja ilości PG Definicja algorytmu rozmieszczenia danych (CRUSH) PLNOG Warszawa 2012 Tomasz Paszkowski 9
CEPH, RBD, PG Placment group: Zawiera obiekty podzielone na 4MB bloki Przydział bloku do PG na podstawie funkcji hash z block # Ilość PG w puli determinuje na maksymalnie ile różnych urządzeń może trafić obiekt PG powiązana z dyskami twardymi za pomocą algorytmu CRUSH PLNOG Warszawa 2012 Tomasz Paszkowski 10
CEPH, RBD, Crush Crush: Algorytm odpowiedzialny za deterministyczne rozmieszczenia PG na dyskach Brak bazy danych. Przypisanie PG do dysków oparte o funkcje hash Algorytm ma na celu takie umieszczanie danych aby unikać trzymania kopi na tych samych: dyskach, serwerach, szafach, rzędach szaf, stref szaf PLNOG Warszawa 2012 Tomasz Paszkowski 11
CEPH, RBD, Crush PLNOG Warszawa 2012 Tomasz Paszkowski 12
CEPH, RBD, OSD Jak budować OSD: Każdy zapis wykonywany dwa razy: journal + storage Journal powinien być na SSD lub architektura jeden dysk + jeden dysk journal. OSD trzyma bloki danych w systemie plików. Najwydajniejszy to btrfs. Najbezpieczniejszy XFS. Ext4 jako złoty środek (uwaga limit na xattr) Dyski do OSD można podłączać w dowolnej technologi, na której można zamontować PLNOG Warszawa 2012 Tomasz Paszkowski 13
CEPH, RBD, client Jak podłączyć RBD do serwera: Modprobe rbd; echo "192.168.1.1,192.168.2.1 name=rbduser,secret=dupa.8 rbd userimage1" > /sys/bus/rbd/add Natywne wsparcie w Qemu/KVM (bezpośrednio z hypervisora). Z pominięciem całego narzutu kernel space: qemu-systemx86_64 --drive format=rbd,file=rbd:rbd/userimage1 Libvirt wspiera rbd PLNOG Warszawa 2012 Tomasz Paszkowski 14 RadosGW. Fastcgi RESTfull module
CEPH, RBD, RadosGW C++ (performance) fastcgi Atomic PUT (temporary PUT, clone) Atomic GET (data tag) Scale-out ready! RGW vs Swift (dobrze oskryptowany rsync) PLNOG Warszawa 2012 Tomasz Paszkowski 15
CEPH, RBD, Co w planach Baza danych Key/value z prawdziwego zdarzenia (przeróbka projektu leveldb). Caching Distributed key/value store with cache!! ROCKS!!!! PLNOG Warszawa 2012 Tomasz Paszkowski 16
CEPH, LEVELDB PLNOG Warszawa 2012 Tomasz Paszkowski 17
CEPH, RBD, Co w planach Libvirt storage pool Implementacja base image (qcow) tzw. image layering PLNOG Warszawa 2012 Tomasz Paszkowski 18
Qcow image layering qemu-img info /var/lib/nova/instances/instance-00000007/disk image: /var/lib/nova/instances/instance-00000007/disk file format: qcow2 virtual size: 2.0G (2147483648 bytes) disk size: 44M cluster_size: 2097152 backing file: /var/lib/nova/instances/_base/36a8aff19301b9751da6041732b329c3714bc9c1 actual path: /var/lib/nova/instances/_base/36a8aff19301b9751da6041732b329c3714bc9c1 Copy on write image Oszczędność przestrzeni dyskowej Obraz ściągany z glance tylko raz (openstack) per serwer W przypadku rbd tylko jedna kopia obrazu na cały cloud!!!!!! PLNOG Warszawa 2012 Tomasz Paszkowski 19
Dlaczego nie Enterprise? PLNOG Warszawa 2012 Tomasz Paszkowski 20
Scale-out vs Scale-up Scale-out Dużo, bardzo dużo Commodity (tanio, bardzo tanio) Architektura gotowa na obsługę awarii, awaria pojedynczego komponentu nie ma znaczenia dla systemu Rozbudowa systemu o dowolne komponenty (dowolne serwery, dyski twarde,...) Prawdzie rozwiązanie cloud PLNOG Warszawa 2012 Tomasz Paszkowski 21
Scale-out vs Scale-up Scale-up Pojedyncze bardzo rozbudowane komponenty Enterprise (drogo, bardzo drogo) Architektura gotowa na obsługę awarii, awaria pojedynczego komponentu ma wpływ na wydajność całego systemu (np. redundatne kontrolery w macierzy enterprise) Vendor & Technology lock in! To nie jest cloud! PLNOG Warszawa 2012 Tomasz Paszkowski 22
Dlaczego nie iscsi? PLNOG Warszawa 2012 Tomasz Paszkowski 23
Dlaczego nie iscsi iscsi @ Linux (Solaris) HA tylko z DRDB (maks. 2 węzły w active/active). Dodatkowo potrzebny peacemaker do ustawiania aktywnego targetu Qemu nie rozpoznaje urządzeń iscsi (konieczne urządzenie blokowe). Dodatkowy kod w kernel space do wykonania. ISCSI @ Enterprise Scale-out vs Scale-up PLNOG Warszawa 2012 Tomasz Paszkowski 24
Dlaczego nie glsuter/inny poprzez fuse? Wielokrotne kopiowanie danych: Qemu(us) - fuse (ks) fuse (us) tcp/ip (ks) Qemu-rbd(us) tcp/ip ks PLNOG Warszawa 2012 Tomasz Paszkowski 25
OpenStack PLNOG Warszawa 2012 Tomasz Paszkowski 26
CEPH, RBD, OpenStack GLANCE Obraz systemów można trzymać bezpośrednio w rbd: rbd_store_pool=pool rbd_store_chunk_size=4 rbd_store_chunk_size=/etc/ceph/ceph.conf That's all :-) PLNOG Warszawa 2012 Tomasz Paszkowski 27
CEPH, RBD, OpenStack novavolume Obraz systemów można trzymać bezpośrednio w rbd: --volume_driver=nova.volume.driver.rbddriver --rbd_pool=rbd qemu-img convert -f qcow2 -O rbd /srv/qemuimages/userimage.qcow2 rbd:rbd/userimage PLNOG Warszawa 2012 Tomasz Paszkowski 28
Pytania? ss7pro@gmail.com PLNOG Warszawa 2012 Tomasz Paszkowski 29