Wirtualne systemy dyskowe na platformie OpenStack

Transkrypt

Wirtualne systemy dyskowe na platformie
OpenStack (KVM)
Tomasz Paszkowski
PLNOG 2012 Warszawa 06.03.2012 r.
[email protected]
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
2
CEPH
Rozproszony sieciowy system przechowywania
danych zbudowany w architekturze scale-out
(cloud friendly).
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)
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)
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 parzystaPLNOG
suma)
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/commitPLNOG Warszawa 2012 Tomasz Paszkowski
parallel) !
7
CEPH, RBD, Architektura
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)
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
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, PLNOG
strefWarszawa
szaf
2012 Tomasz Paszkowski
11
CEPH, RBD, Crush
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 OSDPLNOG
można
podłączać
Warszawa 2012
Tomasz Paszkowski w dowolnej
technologi, na której można zamontować
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
●
RadosGW. Fastcgi RESTfull module
14
CEPH, RBD, RadosGW
●
C++ (performance) fastcgi
●
Atomic PUT (temporary PUT, clone)
●
Atomic GET (data tag)
●
Scale-out ready !
●
RGW vs Swift (dobrze oskryptowany rsync)
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 !!!!
16
CEPH, LEVELDB
17
CEPH, RBD, Co w planach
●
●
Libvirt storage pool
Implementacja base image (qcow) tzw. image
layering
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 !!!!!!
●
19
Dlaczego nie Enterprise ?
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
21
●
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 !
22
Dlaczego nie iSCSI ?
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
–
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
25
OpenStack
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 :-)
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
28
Pytania ?
[email protected]
29

Wirtualne systemy dyskowe na platformie OpenStack

Transkrypt

Podobne dokumenty

Kliknij i zobacz informator!

Komputerowe przetwarzanie danych - Wydział Inżynierii Produkcji

Załącznik nr 5 do SIWZ

283 —M - Genealogy Indexer

23/11/2010 Podróże kulinarne