Department of Distributed Systems A KOPI Plágiumkeresı dinamikus skálázási kísérletei Micsik András
Bevezetés DSD = vagyis: Elosztott Rendszerek Osztály szotar.sztaki.hu kopi.sztaki.hu lod.sztaki.hu radio.sztaki.hu szavazas.sztaki.hu kopi.sztaki.hu 2
Terjedıben a plagizálás 3
A KOPI Plágiumkeresı A kopi.sztaki.hu portál 2004-ben indult egynyelvő plágium keresési szolgáltatással (magyar és angol nyelveken) 2009: 10.000 regisztrált felhasználó 2011-ben a világon elsıként bemutattuk a fordítási plágiumkeresıt Ez képes detektálni, ha valaki például az angol Wikipedia-ból lefordított bekezdéseket használ fel Az új algoritmus számítási igénye nagyságrendekkel nagyobb, mint az egynyelvő plágiumkeresésé 2013: 25.000 regisztrált felhasználó 4
A KOPI Portál 5
Használat 1. 2. 3. 6
Eredmények 7
A plágiumkeresés folyamata A plágiumkeresés folyamata A felhasználó feltölti a dokumentumot A KOPI Motor új feladatot kér a Portáltól A KOPI Motor feldolgozza a dokumentumot Eközben teljes szöveges kéréseket ad ki a Keresımotornak A KOPI Motor összeállítja az eredményt és visszaküldi a Portálnak A felhasználó értesítést kap, hogy az eredmény elkészült. Az eredmény egy listát tartalmaz az esetlegesen másolt részekrıl és a plágium valószínőségérıl 2. Új dokumentum kérése KOPI Portál Feldolg. sor KOPI Motor Keresőmotor Dokumentum index 1. A felhasználó feltölti a dokumentumot 4. Eredménykészítés 3. Teljes szöveges keresések 8
A kísérletrıl A cél: stabil szolgáltatásminıség fenntartása Egy dokumentum ellenırzése igen változó, nagyban függ a mérettıl, tipikusan 10-50 perc Amikor túl sok dokumentum érkezik be, ez akár több napra is nıhet A kísérlet során Modellezzük a tipikus felhasználói tevékenységet Különféle skálázási módszereket mérünk heterogén felhı-szövetségekben 9
Skálázás 10
A skálázás módjai Vertical scaling Scaling up Horizontal scaling Scaling out 11
Skálázási lehetıségeink KOPI Portál Feldolg. sor KOPI motor NLP Eszközök MySQL KOPI motor NLP Eszközök MySQL 1-75 Aggregátor Aggregátor Keresımotor Keresımotor Keresımotor Keresımotor 1-7 Dokumentum index partíció Dokumentum index partíció Dokumentum index partíció Dokumentum index partíció 12
Kísérleti architektúra 13
BonFIRE: elosztott felhı tesztkörnyezet 14
A KOPFire kísérlet Mérések Skálázó algoritmus Skálázási mőveletek BonFIRE API parancsok 15
BonFIRE lehetıségek VM típusok (lite, small, large, stb. + egyedi) Adatblokkok OS vagy DATA, perzisztens, shared, stb. Több blokk is kapcsolható egy VM-hez Hálózat VM-ek elérhetık: SSH gateway, VPN Speciális lehetıségek: AutoBahn, Virtual Wall, háttérforgalom generálás, stb. Monitorozás Elasticity as a Service Értesítések (RabbitMQ) 16
A BonFIRE felhasználói portál 17
Monitorozás Egységes monitorozási lehetıség Zabbix-szal Fizikai gépek Virtuális gépek ECO metrics Saját mérések 18
BonFIRE API REST API Experiment descriptor: JSON vagy OCCI <compute xmlns="http://api.bonfireproject.eu/doc/schemas/occi"> <name>my-vm</name> <instance_type>lite</instance_type> <disk> <storage href="/locations/fr-inria/storages/165" /></disk> <nic> <network href="/locations/frinria/networks/47" /> </nic> <location href="/locations/fr-inria" /> </compute> Restfully (Ruby) experiment.computes.submit( :name => "VM#{experiment['id']}", :instancetype => "small", :disk => [{ :storage => inria.storages.find{ s s['name'] == SERVER_IMAGE_NAME}, :type => "OS" }], :location => inria ) CLI (parancssor) bfcompute create vm0' '/locations/de-hlrs/storages/2088' 23617 19
Yours Restfully... VM létrehozás vm = experiment.computes.submit(...) Szoftver futtatás vm.waitforstate( RUNNING ) vm.ssh do. Megfigyelés values = experiment.zabbix.metric('system.cpu.util[,system,a vg1]', :type => :numeric, :hosts => vm).values Leállítás vm.update(:status => STOPPED ) vm.delete 20
KOPFire rendszerelemek VM típusok (3 felhıben): (Experiment controller) KOPI Frontend KOPI Engine Fulltext Aggregator Fulltext Engine Adatpartíciók: Kis index: 5 x 2.5 GB blocks Nagy index: 11 x 7.2 GB blocks 3 felhıben közvetlenül 4. felhıbıl NFS-en keresztül 21
Mit mérjünk? Density 0.00 0.01 0.02 0.03 0.04 0.05 0.06 0 200 400 600 800 cps Kell egy metrika a feldolgozási sebesség mérésére: cps (characters per second) Fontos még: Sorban várakozó fájlok és karakterek száma Feldolgozó egységek száma 22
Sokféle cps metrika t1 t2 A dokumentum a sorban A dokumentum feldolgozása t4 t3 cps feldolgozott karakterek / utolsó n perc = pillanatnyi feldolgozási sebesség pcps (processing cps) dokumentum mérete / (t3 t2) qcps (queue cps) dokumentum mérete / (t4 t1) = a felhasználó által érzékelt sebesség 23
Méretezés Mi a rendszerkomponensek optimális aránya? KOPI Engine VM process-ek Fulltext Cluster thread-ek 24
Teljesítménynövekedés 25
NFS a felhık között? 26
Skálázási lehetıségek Különbözı skálázási algoritmusokat próbáltunk ki A sorban várakozó dokumentumok száma alapján Kapzsi Takarékos Óvatos Feldolgozási sebesség alapján Stb. Tempomat: Adott sebességet közelítı 27
Skálázási módszerek greedy step number 0 1 2 3 4 5 6 queue size kopi engines number 0 1 2 3 4 5 6 queue size kopi engines 0 5 10 15 20 25 time 0 5 10 15 20 25 30 time speed thrifty number 0 1 2 3 4 5 6 queue size kopi engines 0 5 10 15 20 25 number 0 1 2 3 4 5 6 queue size kopi engines 0 10 20 30 40 50 60 70 time time 28
Hibatőrés A skálázás során idınként amúgy is rá kell nézni az infrastruktúrára......ilyenkor szoftver és hardver hibákat is ki lehet küszöbölni......mivel a komponensek már virtuális gépekben futnak 29
Szimuláció Pár órás tesztek nem elegendıek Hogyan lehetne több havi futáson vizsgálni a skálázódást? -> Szimuláció! Az alapadatok ismertek, pl. VM-ek indításához, leállításához szükséges idı Adott VM válaszidejének átlaga, eloszlása 30
Szimulációk értékelése Mit kell nézni egy hónapos futás esetén? Legrosszabb feldolgozási esetek Átlagos feldolgozási idı A feldolgozási idı szórása A becsült költségek 31
2012 januári forgalom szimulációja 180 160 140 120 100 80 60 worst speed avg speed speed sd cost (hours) 40 20 0 speed 100 speed 130 speed 80 fix 1 fix 2 greedy thrifty stepper Költségszámítás megkezdett órák alapján 32
2012 júniusi forgalom szimulációja 250 200 150 100 worst speed avg speed speed sd cost 50 0 speed 100 speed 130 speed 80 fix 1 fix 2 greedy thrifty stepper Költségszámítás megkezdett órák alapján 33
Két módszer összehasonlítása greedy 180 160 140 120 100 80 60 40 20 0 1 2 3 4 5 6 7 8 month worst speed avg speed cost stepper 200 180 160 140 120 100 80 60 40 20 0 1 2 3 4 5 6 7 8 month worst speed avg speed cost 34
Végsı összehasonlítás 200 180 160 140 120 worst speed 100 avg speed 80 cost 60 40 20 0 fix 1 fix 2 speed 80 speed 100 speed 130 stepper greedy thrifty A megjelenített értékek 8 hónap átlagai 35
Összefoglalás Terhelési problémák tesztelésére jó lehetıség egy cloud testbed A skálázás nem csak gyorsít, de más elınyökkel is jár, pl. hibatőrés A BonFIRE testbed Elérhetı lesz legalább 2014 ıszéig Nyílt hozzáférés 1 napon belül 36
www.bonfire-project.eu kopi.sztaki.hu Köszönöm a figyelmet! micsik@sztaki.hu 37