A KOPI Plágiumkeresıdinamikus MTA SZTAKI skálázási kísérleteieprints.sztaki.hu/7272/1/micsik-webkonf13.pdfdsd.sz taki.hu MTASZTAKI Department of Distributed Systems 4 A KOPI

MTA SZTAKI

Department of Distributed

Systems

A KOPI Plágiumkeresı dinamikus skálázási kísérletei

Micsik András

dsd.sztaki.huMTA SZTAKIDepartment of Distributed Systems

2

Bevezetés

� DSD = Department of Distributed Systems

vagyis: Elosztott Rendszerek Osztály� szotar.sztaki.hu

� kopi.sztaki.hu� lod.sztaki.hu

� radio.sztaki.hu

� szavazas.sztaki.hukopi.sztaki.hu


3

Terjedıben a plagizálás


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: 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ó


5

A KOPI Portál


6

Használat

1.

2.

3.


7

Eredmények


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

KOPI Portál

KOPI Motor

Keresőőőőmotor

1. A felhasználó feltölti a dokumentumot

2. Új dokumentum kérése

3. Teljes szöveges keresések

Feldolg. sor

4. Eredménykészítés

Dokumentum index


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


10

Skálázás


11

A skálázás módjai

Vertical scaling„Scaling up”

Horizontal scaling„Scaling out”


12

Skálázási lehetıségeink

KOPI motor

MySQL

NLP Eszközök

KOPI Portál

Feldolg. sor

1-75

KOPI motor

MySQL

NLP Eszközök

Keresımotor

Dokumentum

index partíció

Keresımotor

Dokumentum

index partíció

Aggregátor

Keresımotor

Dokumentum

index partíció

Keresımotor

Dokumentum

index partíció

Aggregátor

1-7


13

Kísérleti architektúra


14

BonFIRE: elosztott felhıtesztkörnyezet


15

A KOPFire kísérlet

Skálázóalgoritmus

Mérések

BonFIRE API parancsok

Skálázásimőveletek


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)


17

A BonFIRE felhasználói portál


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


19

BonFIRE API

� REST API� Experiment descriptor: JSON vagy OCCI<compute xmlns="http://api.bonfire-

project.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/fr-inria/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


20

Yours Restfully...

� VM létrehozásvm = experiment.computes.submit(...)

� Szoftver futtatásvm.waitForState(‘RUNNING’)vm.ssh do ….

� Megfigyelésvalues =

experiment.zabbix.metric('system.cpu.util[,system,avg1]', :type => :numeric, :hosts => vm).values

� Leállításvm.update(:status => ‘STOPPED’)vm.delete


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


22

Mit mérjünk?

� 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� …

0 200 400 600 800

0.0

00

.01

0.0

20

.03

0.0

40

.05

0.0

6

cps

De

nsi

ty


23

Sokféle cps metrika

� 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

A dokumentum a sorbanA dokumentum feldolgozása

t1t2 t3

t4


24

Méretezés

� Mi a rendszerkomponensek optimális aránya?� KOPI Engine VM – process-ek – Fulltext Cluster – thread-ek


25

Teljesítménynövekedés


26

NFS a felhık között?


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� Tempomat: Adott sebességet közelítı

� Stb.


28

Skálázási módszerek

0 5 10 15 20 25

01

23

45

6

greedy

time

nu

mb

er

queue sizekopi engines

0 5 10 15 20 25 30

01

23

45

6

step

time

num

ber


0 5 10 15 20 25

01

23

45

6

speed

time

nu

mb

er


0 10 20 30 40 50 60 70

01

23

45

6

thrifty

time

num

ber



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álisgépekben futnak


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


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


32

2012 januári forgalom szimulációja

0

20

40

60

80

100

120

140

160

180

speed100

speed130

speed80

fix 1 fix 2 greedy thrifty stepper

worst speed

avg speed

speed sd

cost (hours)

Költségszámítás megkezdett órák alapján


33

2012 júniusi forgalom szimulációja

0

50

100

150

200

250

speed100

speed130

speed80

fix 1 fix 2 greedy thrifty stepper

worst speed

avg speed

speed sd

cost

Költségszámítás megkezdett órák alapján


34

Két módszer összehasonlítása

greedy

0

20

40

60

80

100

120

140

160

180

1 2 3 4 5 6 7 8

month

worst speed

avg speed

cost

stepper

020406080

100120140160180200

1 2 3 4 5 6 7 8

month

worst speed

avg speed

cost


35

Végsı összehasonlítás

0

20

40

60

80

100

120

140

160

180

200

fix 1

fix 2

spee

d 80

spee

d 10

0sp

eed

130

stepp

ergr

eedy

thrif

tyworst speed

avg speed

cost

A megjelenített értékek 8 hónap átlagai


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


37

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

www.bonfire-project.eu

[email protected]

Documents

A KOPI Plágiumkeresıdinamikus MTA SZTAKI skálázási kísérleteieprints.sztaki.hu/7272/1/micsik-webkonf13.pdfdsd.sz taki.hu MTASZTAKI Department of Distributed Systems 4 A KOPI