A KOPI Plágiumkeresı dinamikus skálázási kísérletei MTA SZTAKI. Department of Distributed Systems. Micsik András

Átírás

1 Department of Distributed Systems A KOPI Plágiumkeresı dinamikus skálázási kísérletei Micsik András

2 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

3 Terjedıben a plagizálás 3

4 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: 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: regisztrált felhasználó 4

5 A KOPI Portál 5

6 Használat

7 Eredmények 7

8 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

9 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 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

10 Skálázás 10

11 A skálázás módjai Vertical scaling Scaling up Horizontal scaling Scaling out 11

12 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

13 Kísérleti architektúra 13

14 BonFIRE: elosztott felhı tesztkörnyezet 14

15 A KOPFire kísérlet Mérések Skálázó algoritmus Skálázási mőveletek BonFIRE API parancsok 15

16 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

17 A BonFIRE felhasználói portál 17

18 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

19 BonFIRE API REST API Experiment descriptor: JSON vagy OCCI <compute xmlns=" <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'

20 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

21 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

22 Mit mérjünk? Density 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

23 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

24 Méretezés Mi a rendszerkomponensek optimális aránya? KOPI Engine VM process-ek Fulltext Cluster thread-ek 24

25 Teljesítménynövekedés 25

26 NFS a felhık között? 26

27 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

28 Skálázási módszerek greedy step number queue size kopi engines number queue size kopi engines time time speed thrifty number queue size kopi engines number queue size kopi engines time time 28

29 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

30 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

31 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

32 2012 januári forgalom szimulációja worst speed avg speed speed sd cost (hours) 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

33 2012 júniusi forgalom szimulációja 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

34 Két módszer összehasonlítása greedy month worst speed avg speed cost stepper month worst speed avg speed cost 34

35 Végsı összehasonlítás worst speed 100 avg speed 80 cost fix 1 fix 2 speed 80 speed 100 speed 130 stepper greedy thrifty A megjelenített értékek 8 hónap átlagai 35

36 Ö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

37 kopi.sztaki.hu Köszönöm a figyelmet! micsik@sztaki.hu 37