Ugrás a főmenüre.
Web 2009.06.01. Amazon, Cloud computing, Hosting

Automatikus skálázódás az Amazon EC2-n

Nagyon jelentős változás, hogy az EC2 már nem "buta", tud skálázódni, monitorozható és kapott terheléselosztást is. Bár ezek a képességek szép neveket kaptak (CloudWatch, Elastic Load Balancing, Auto Scaling), gyakorlatilag API kiegészítésekről van szó, nem grafikus felhasználói felülettel rendelkező szolgáltatásokról.
Automatikus skálázódás az Amazon EC2-n

Ezek a kiegészítések a már ismert Amazon-os szokás szerint mennek (autentikáció, Query vagy SOAP API), jól illeszkednek az eddigiekbe.

CloudWatch

A legfontosabb elem a CloudWatch, azaz a monitoring, erre épül a többi, ez szolgáltatja a működéshez szükséges adatokat. A legkisebb monitorozási időegység 1 perc, ennél rövidebb izéket nem tud mérni, de általában nincs is rá szükség. Ezeket lehet mérni szerverenként:

  • CPU használat (százalék)
  • hálózati forgalom (összes interfész) kifelé, befelé (bájt)
  • háttértár használat (operation, bájt) írás/olvasás

A következők pedig csak a terheléselosztáshoz (Elastic Load Balancing) figyelhetők:

  • latency (kérések és válaszok közötti idő, ahogy a load balancer látja)
  • kérések száma per másodperc
  • "egészséges" és "beteg" szerverek száma (értsd: hány bírja és hány van leterhelve)

Mivel a CloudWatch időszakot mér (a legkisebb ugye 1 perc), a adatok többsége öt formában érhető el: minimum érték, maximum érték, szumma, átlag, minták (értékek) száma. Nemcsak szerverenként, hanem összesítve is kérhetőek az adatok (dimension), ezek lehetségesek:

  • adott szerverpéldány (instance)
  • szerverpéldány típus (pl. m1.small)
  • image (csak azok a szerverek, amik egy adott image-et futtatnak)
  • szerverfarm
  • autoscaling csoport név (lehet saját csoportokat csinálni, ezekbe szerverazonosítókat pakolni stb.)
  • terheléselosztó (load balancer) neve (tehát azok a szerverek, akik ugyanazon az elosztón lógnak)

Elastic Load Balancing

Terheléselosztáshoz eddig egy külön EC2 szerverpéldányt kellett létrehozni és futtatni, de most már van rá beépített szolgáltatás. Egy elosztónak saját DNS neve van, ahhoz kell intézni a kéréseket. Lehet a portokat egymáshoz rendelgetni (hányasra érkezzen a kérés, de a szerverpéldány melyiken dolgozza fel) és meg lehet határozni a protokollt is (TCP vagy HTTP). A bejövő port csak a 80-as, 443-as vagy 1024-től felfelé lehet. Ebből lehet látni, hogy inkább a HTTP és HTTPS a "célközönség".

A terheléselosztó figyeli a szerverpéldányokat, időnként megvizsgálja mindet. Ehhez be lehet állítani, hogy milyen URL-t kérjen le, mennyi legyen a timeout és azt is meg lehet mondani neki, hogy hány sikertelen kísérlet után minősítse "betegnek" az adott szerverpéldányt. Tehát nem a CPU, háttértár, stb. terhelést figyeli, hanem azt, hogy az adott szerver tud-e elfogadható időn belül válaszolni.

Auto Scaling

Ő az a komponens, aki beállítható CloudWatch mérési szabályok alapján szerverpéldányokat indít vagy állít le. Autoscaling csoportokat lehet létrehozni, ezekhez pedig szabályokat adni. Nem egyszerűen image-eket indít, hanem indítási konfigurációkat (launch configuration), amik egy csomó környezeti dolgot határoznak meg és adatok is átadhatók vele az induló szerver számára.

GUI-t neki!

Van már most is jónéhány startup, aki hasonlót kínál (pl. RightScale), az ő működésüket biztosan meg fogja változtatni az ügy, az árakat pedig remélem lefelé (eddig borsos volt). Már alig várom, hogy valami jó kis asztali klienst építsenek rá, amivel egyszerűen lehet konfigurálni a farmunkat.

Persze ez nem oldja meg a magasabb szinteken lévő skálázódást, pl. egy replikált MySQL farmhoz az Amazon API-nak semmi köze.

Árak

Egy terheléselosztó 1 havi futtatása 18 USD (smafu), viszont minden rajta átfolyt sávszél 0.008 USD/GB, azaz kb. 8 USD per terabájt. Ez kedvező, sokkal olcsóbb, mint egy dedikált EC2-s terheléselosztó szerver.

Az Auto Scaling ingyenes, viszont minden szerverhez CloudWatch mérést is indítania kell, a CloudWatch viszont pénzes megint. Minden vizsgált szervernél 0.015 USD per óra, azaz kb. 11 USD havonta szerverpéldányonként. Hát, hát. 10 szervernél mondjuk elég jó, csak oda még minek.

0 hozzászólás - Te lehetsz az első!

Új hozzászólás
A sortörések automatikusak. Csak az üzenet kitöltése kötelező, a többi mező opcionális. A megadott e-mail címet nem tesszük közzé. Engedélyezett HTML tagek: p, a, strong, em, blockquote, ul, ol, li, dl, dt, dd.

Legutolsó hozzászólások

Diszkórobbanás a 90-es években és a legendás Campari diszkó: Árpika Palotáról: Szia ZooLou :-9 Te melyik részen melóztál?

Teh early agez... (így kezdődött) 1990-1992: Tamás Hölzer: Szia Gábor! Hozzájárulsz, hogy a http://zenci-blog.blogspot.com/p/disco-story.html blogban linkeljem a diszkó "történelmed"? Üdv; tamás

Diszkórobbanás a 90-es években és a legendás Campari diszkó: ZooLou: Finucsi, PG, Függöny, Dj Tökimanó, Barbi, Kacsa, Virág, Feri, Erzsi, Jana, és még sokan a csapatból! Én is lehúztam egy kis időt ott,...

A csatlakozás az iPhone Developer Program-hoz szívás: Nyéki Zoltán: Sziasztok, Arról nincs információtok vagy tanácsotok, hogy egy magyarországi kisvállalkozásnak hogy kell regisztrálnia az Applenél, hogy...

Rólam és a blogról: Szanto Peter: Szia, en is szeretnek veled app fejlesztes ugyben beszelni:) Ha aktualis szamodra uj projekt befogadasa, akkor kerlek irj. koszi, p

iMect means internet, media and other cool things. We're a small company located in Hungary. There is a big footer on every page where you can discover what we do and what happens with us.

Az iMect jelentése: internet, média és egyéb király dolgok. Egy kis magyar cég vagyunk. Minden oldalon van egy nagy lábléc, ahol felfedezheted, hogy mivel foglalkozunk.