Souborové systémy v cloudu
Filip Hubík @ MetaCloud ([email protected])Adam Tomek @ MetaCloud
Masarykova univerzita a CESNET
7.10.2014
Obsah a cíle prezentace
ObsahI Představení MetaCloud skupinyI Definice problematiky
I Cloud a úložištěI Náhled na souborové systémy
I Ceph podrobněI Gluster podrobněI Benchmarking
I Testovací infrastrukturaI Výsledky testů
I Závěr a otázkyCíle přednášky
I Vytvořit základní představu o vhodnosti použití vybranýchdistr. soub. systémů v cloudovém prostředí
I Porovnat měřením jejich vlastnosti na testovací infrastruktuřea dopomoci tak k případnímu rozhodování o jejich nasazení
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 2 / 37
Kdo jsme
MetaCloud teamI Cloudové služby pro akademické sféryI Spolupráce dvou iniciativ
I CESNET – MetaCentrum – XenI Masarykova univerzita – CERIT-SC – KVM
I Hybridní cloudI Malá až střední velikostI OpenNebula middlewareI Více jak 3 roky zkušenostíI Doprovodné aktivity (HA, support, . . . )I Výzkumné projektyI Kontakt: [email protected]
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 3 / 37
Úvodem - architektura cloudu
Typy cloudů:I Service
(SaaS)I Platform
(PaaS)I Infrastructure(IaaS)
* as a service [3]
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 4 / 37
Úvodem - skladba IaaS cloudu
Jádrem cloudu na IaaS úrovni jeI Middleware (uživ. rozhraní, scheduler, API, managment, . . . )
I OpenNebula, Openstack, CloudStack, NimbusI Virtualizace HW (Xen, KVM, VMWare, . . . )
I Množství uzlůI CPUI PamětI Síťové prostředky (OpenFlow + Open vSwitch)
I Úložiště obrazů a dat („Image storage“)I Základní rozhodnutí ovlivňující dlouhodobý provoz clouduI Různé formáty obrazů (QCOW, RDB, RAW, VDI, . . . )I Velikost obrazu alokována předemI Problém - distribuce obrazů cloudem
I Kopírování (rsync, scp, ftp, . . . )I Distribuovaný souborový systémI Jiné přístupy (SAN/NAS magie, replikace, vzdálená úložiště &
marketplace, . . . )
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 5 / 37
Typy souborových systémů
I Lokální – klasické FS, žádné sdílení dat mezi uzlyI Síťové – lokální + síťový protokol, klient/server 1:N model
(NFS, FTP)I Distribuované – data jsou transparentně distribuována mezi
více uzlů úložiště, M:N model (DFS, AFS)I Paralelní – konkurentní I/O operace nad soubory, „striping“
(GPFS, Ceph, Gluster(!), MooseFS, HDFS, Lustre, . . . )I Symetrické – metadata umístěna na klientské i serverové částiI Asymetrické – metadata umístěna na klientské nebo serverové
částiI Sdílené – sdílený přístup všech uzlů, zámky
I Klastrované – symetrické, přímý přístup k blokovému zařízení,drahá kapacita, SAN (GFS, OCFS, . . . )
I „User-space“ – běží mimo kernel v uživatelském prostoruI Objektové – data objekty + metadata + globalID, ne
struktura, ploché, méně metadatI Globální – každý uzel stejný pohled
. . . a další + některé typy lze kombinovatHubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 6 / 37
Požadavky na FS v cloudu
I Každý host dokáže spustit každou VMI Distribuovanost (levná a heterogenní infrastruktura)I Lineární škálovatelnost kapacity a propustnostiI Eliminace SPOF (metadata server)I Konkurentní přístup k datůmI Vysoká dostupnost, tolerance chybI Ideálně paralelní I/O operaceI Správa přístupu (různé části úložiště různá ACL)I Open-sourceI Live migraceI Snapshoty bez podpory obrazu
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 7 / 37
Požadavky na škálovatelnost
KapacitaI Vertikální - počet disků na stroj (omezeno řadičem)
PropustnostI Horizontální - počet strojů formujících úložiště
Problémy u distribuovaných FSI Linearita - kapacita úložiště musí být rovna součtu kapacit
jedn. strojůI Síťová infrastuktura musí mít dostatečnou propustnost
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 8 / 37
Vhodné souborové systémy
Cíleny pro použití v clouduI CephI GlusterFS
Další možné variantyI GPFS - proprietární, problémy s XenI HDFS - metadata server SPOF, Copy-On-Write modelI MooseFS, XtreemFS - poměrně mladý, vyhodnocováníI Lustre - supercomputingI . . .
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 9 / 37
Souboj titánů
Ceph v produkci (Inktank, později Red Hat)
GlusterFS v produkci (Gluster, poté Red Hat)
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 10 / 37
Ceph
I Částečně POSIX distribuovaný soub. systémI Nativně objektový, blokový (RBD), souborový (CephFS)I Metadata oddělena i neoddělenaI CephFS není v produkční fázi (08-2014)I „Rados block device“ – vhodné pro cloud bez FUSEI Rozsáhlé možnosti konfigurace (v testech výchozí hodnoty)I Komplexní ACLI CRUSH algoritmus
I Dynamický, load balancing, prokládání nativně, replikaceI Stavební kameny
I OSD – CPU, paměť, síťové rozhraní, diskový prostorI Monitor – Informuje OSD o změnách topologie („cluster map“)I MDS – Metadata server (CephFS)I Klient – Jádro >= 3.9
I Není infiniband pouze TCPHubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 11 / 37
Ceph – architektura
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 12 / 37
GlusterFS
I Distribuovaný POSIX FS primárně na souborové úrovniI Není centralizovaný metadata server (elastický hash)I Teoretická velikost až 72 ∗ 106 zettabyte (XFS subvol.)I Integrace s QEMU (blokově bez FUSE, libgfapi - drive
file=gluster://server[:port]/volname/image[?transport=...])I HA a samoopravné vlastnostiI Souborový systém v otevřené formě, user-space modelI Georeplikace (asynchronní replikace)I Pasivní load balancing, prokládání, replikace (synchr.)I Dynamická práce se svazkyI Globální namespaceI RDMA, TCPI Nejsou snapshoty! (potřeba použít QCOW)I Jednoduchá konfigurace
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 13 / 37
Gluster – architektura a API
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 14 / 37
Gluster – terminologie a použití
TerminologieI Brick – zákl. stavební kámen, úl. prostor zapojen do volumeI Volume (svazek) – log. org. souborů, globální namespaceI Klient – uzel připojující volume (i server)I Server – uzel, na kterém leží brickI Translator – kód prováděný nad daty (modulárnost)
I Storage, Debug, Encryption, Scheduler, Protocol, . . .I Subvolume – brick, který už byl zpracován translatorem
Módy organizace dat ve svazkuI DistribuceI ReplikaceI Prokládání
Příklad tvorby svazkuI $ gluster volume create vol0 replica 2 stripe 2
server1:/data/gv0 server2:/data/gv0 server3:/data/gv0server4:/data/gv0
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 15 / 37
Distribuovaný mód
I Data distribuována na úrovni souborůI Žádná redundanceI Obdoba RAID0 či JBODI Selhání uzlu znamená ztrátu dat
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 16 / 37
Replikace
I RedundanceI Selhání disku
I Self-healingI Manuální intervence („Split-brain“ scénář)
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 17 / 37
Distribuovaná replikace
I Koefient replikace r=2I Počet bricků musí být nasobek rI Redundance + propustnost při čtení
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 18 / 37
Prokládání („striping“) souborů
I Dělení na úrovni souborů (RAID0)I Velmi velké souboryI Vhodné pro vysoce konkurentní prostředí (DB, HPC)I Počet bricků roven koeficientu prokládání
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 19 / 37
Distribuované prokládání
I Předchozí výhody + škálovatelnostI Počet bricků násobkem koeficientu prokládání
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 20 / 37
Prokládaná replikace
I Obdoba RAID1+0I Velké soubory ve vysoce par. prostředí (MapReduce)
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 21 / 37
Distr. prokládaná replikace
I Výhody předchozího + škálovatelnostI MapReduceI Počet bricků násobkem násobků obou koeficientů
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 22 / 37
Gluster – georeplikace
I Asynchronní replikace (checkpointing)I Inkrementální – rsyncI Master/slave modelI LAN, WANI Zálohování datI Čas musí být synchronizován na všech uzlech (NTP)I V cloudu použítí s QCOW real-time snapshotyI Kaskádování (cíl = zdroj)
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 23 / 37
Testovaná architektura
HardwareI 10 klientských uzlů, 4 serverové uzly stejného typuI Intel Xeon CPU E5472 3.00GHz, 2GB RAMI Disk
I 250GB na uzelI hdparm – 192MB/s čteníI iozone – cca 190MB/s čtení i zápisI dd – 40MB/s zápis
I Odstranění virt. vrstvy (bez Xen či KVM)I Gluster nutno připojovat přes FUSEI Debian 7 Wheezy (jádra >= 3.9, 3.14-0.bpo.2-amd64)I XFS (produkční u obou FS)I IPoIB (Ceph neumí RDMA!) – 4X DDR (20 Gb/s)
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 24 / 37
Testovací konfigurace
IozoneI V praxi 1-10 souběžných procesů na uzel (menší cloud)
I Souběžné vytížení úložiště ze strany klientůI Velikost obrazů 1-4GB na uzelI Verze 3.397I Distribuovaný režim (parametr -+m)I Velikost záznamu (record size) 256kB
CephI Verze 0.80.4 (06-2014)I Koeficient replikace 2, min repl. 1, prokládání výchozíI pg_num & pgp_num = 256I Obrazy připojeny přímo přes RBD blokové zařízení
GlusterFSI Verze 3.5.2 (09-2014)I Koeficient replikace 2, prokládání 2I Obrazy připojeny přes FUSE (pokud není uvedeno jinak)
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 25 / 37
Gluster 1-9 uzlů, 1 proces/uzel
I DR mód ovlivněn replikací, DS pomalejší nelineární
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 26 / 37
Ceph 1-10 uzlů, 4GB image
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 27 / 37
Initial write, 1-10 procesů/uzel
I Jak se v tom vyznat?I Ceph - konst., Gluster DR 1 pr. lineární, další log.
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 28 / 37
Rewrite, 1-10 procesů/uzel
I Obdobný stav
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 29 / 37
Read, 1-10 procesů/uzel
I 1 pr. DR 1-6 lineární, 7-10 klesá, Ceph pro 1 uzel taktéž
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 30 / 37
Re-read, 1-10 procesů/uzel
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 31 / 37
Random read, 1-10 proc./uzel
I Ceph někde rychlejší než DS
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 32 / 37
Random write, 1-10 proc./uzel
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 33 / 37
Výsledky měření - závěr
CephI Kam se poděla škálovatelnost? Konstantní?
I Nejspíš silně omezena RBD vrstvou na uzluI Pravděpodobně CRUSH - větší infrastrukturyI Gluster ukázal že to jdeI Nativní striping také hraje proti
GlusterI Také omezen, ale snáší to lépeI Škáluje lineárně či logaritmickyI Ve stripingu propustnost klesá pro >=6 uzlůI Ale pozor na čtení pro >= 8 uzlůI Gluster padal ve stripingu pro 8 a 10 uzlů
Doporučení pro cloudI Gluster v distribuovaném replikovaném módu
* Výsledky pouze simulují běh v clouduHubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 34 / 37
Další aktivity
I Bakalářská práce, další výzkumI Testování Xen vs. KVM
I Srovnání z pohledu vhodnosti pro cloudové využití
I Testování kompatibility Ceph a GlusterFS s virtualizačnívrstvou (problém s GPFS)
I Hrátky s parametry Cephu i GlusteruI Revalidace podivné škálovatelnosti Cephu
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 35 / 37
Konec
– Díky za pozornost –
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 36 / 37
Literatura
[1] Ceph offfical site – http://ceph.com[2] Gluster offical site – http://www.gluster.org[3] http://www.katescomment.com/iaas-paas-saas-definition[4] Cloud Storage for the Modern Data Center, Copyright 2011,Gluster, Inc.[5] http://www.inktank.com/partners/ceph-at-the-red-hat-summit/[6] http://yourstory.com/2011/09/yourstory-exclusive-california-based-indian-entrepreneurs-powering-petabytes-of-cloud-storage-the-gluster-story/ [7] GlusterFS Cloud Storage, John MarkWalker[8] Red Hat documentation –https://access.redhat.com/documentation
Hubík, Tomek (MUNI+CESNET) Masarykova univerzita 7.10.2014 37 / 37