IaaS jó vertikális skálázódással

Fórumok

A virtuális szerver a cloud-ban közmű-szerű manapság, de ahogy nézem, a legtöbb helyen (Amazon AWS, Google Compute, Rackspace, stb) a horizontális skálázódás a szépen megoldott (annyi új VM-et húzol fel, amennyi éppen kell, van rá több helyen autoscaler segítség, minden). A vertikális skálázódás (egy instance CPU-ját, RAM-ját állítjuk, ahogy épp kell) jóval-jóval macerásabb, szinte mindig újraindítást jelent. Vannak olyan alkalmazások, ahol nem triviális horizontális rendszerben gondolkodni vagy az áttervezés költsége elég magas... Tudtok olyan megbízható, nagy szolgáltatót, ahol van lehetőség menet közben átméretezni a virtuális gépeket? RAM és CPU kellene csak, a diszk maradna perzisztens. A francia Gandi.net félig-meddig tudja emlékeim szerint, de nem determinisztikus, ha épp nincs resource, akkor rebootolnak, előre nem lehet tudni... azt hiszem ez volt a support válasza legutóbb. Szóval van ennél jobb vertikális skálázódás a piacon?

Hozzászólások

Virtuozzo technológia is pl tudja ezt.
Szerintem a gond ott van, hogy arra vannak beállva, hogy olcsó (1-2 socket) gépeken adnak el kicsi (1-4 core) virtuális gépeket 90% -ban, ilyen a piac. Egy 8->16 vcpu, 16->32 gb váltáshoz azért kell a reboot, hogy szabad gépre kerülj. Nem nagyon látom, hogy ez mitől változna.

Plusz még azt is érdemes tudni, hogy a VPS idővel "fárad", illetve azonos pénzért azonos szolgáltatónál is lehet eltérő teljesítményt kapni, mert mindig van valamennyi overbooking és ha sikerül terheltebb VPS mellé költözni vagy terheltebb VPS kerül rá utólag arra a fizikai gépre, amin a saját VPS van, akkor ott lassulni fognak a szolgáltatások.

Ezen lehet segíteni, hogy az ember hetente egy-két node-ot újrahúz, hozzáad a cluster-hez, aztán a régit eldobja, ez általában automatizálható feladat, nem fáj és közben lehet a komponenseket frissíteni is.

Az eredeti kérdésre pedig az lenne a válasz, hogy ha a cloud-ban futó szoftver képtelen horizonális skálázhatóságra, akkor sajnos nem való cloud-ba, kell venni alá fizikai infrastruktúrát, storage-t, mentést ésatöbbit, ha pedig ez drága, akkor elgondolkodni azon, hogy lehet horizonálisan skálázhatóvá tenni.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Az ötdolláros VPS szolgáltatóknál van mindig. Normális helyen nincs. Azt próbálnák meg, hogy az általam pénzért megvett erőforrást odaadják másnak."

Tudod, ez pont olyan, hogy hiába vettél meg x Mbps sávszélességet papíron, mindenki nem fog tudni egyszerre x Mbps-en kommunikálni abban a DC-ben, illetve hiába vettél x IOPS storage sávszélességet, ha az összes VPS épp írna vagy olvasna az adott host-on, akkor sokfelé oszlik el az az I/O sávszélesség, ha épp egyedül teszed ezt, akkot Tied az egész... ugyanez CPU-ban is igaz. Memória van dögivel, arra nem jellemző az overbooking, minden más erőforrásra igen. :)

És hidd el, hogy a csodás Azure esetén is van ilyen... maximum nem írják le a brossúrába vagy nem olvastad az apró betűs részt, az egész virtualizációt azért találták ki, hogy ne az igénybevételi csúcsokra kelljen méretezni az infrastruktúrát.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Amennyire tudom, az Azure node-okon nincs overcommit.

Nyilván vannak speciális kérdések, pl. a storage. Egy subscription-höz IIRC 100*500 TB adat tartozhat, értelemszerűen erre nincsenek felkészítve a DC-k, de itt sem egy adott node-on van race condition, mert ahogy fogy a hely, a storage is bővül.

"Amennyire tudom, az Azure node-okon nincs overcommit."

Ahha... nyilván, tehát például az x Gbps az garantált és nem elérhető maximum sávszélesség? :)

"Nyilván vannak speciális kérdések, pl. a storage. Egy subscription-höz IIRC 100*500 TB adat tartozhat, értelemszerűen erre nincsenek felkészítve a DC-k, de itt sem egy adott node-on van race condition, mert ahogy fogy a hely, a storage is bővül."

Nagyszerű, de a storage méretének nincs köze ahhoz, hogy mekkora az aktuális _IOPS_ per storage egy adott időpillanatban, ami a pillanatnyi teljesítményt meghatározza. Szerintem kevered a shared resources fogalmát (például network, IOPS, CPU, memory access, satöbbi) és a reserved resource forgalmát (például IP cím, memória méret, disk terület, satöbbi).

Például ha van az adott fizikai gépen 100 virtuális gép, ha ebből 99 éppen nem csinál semmit, akkor a maradék egy kapja a teljes memória, hálózat és I/O sávszélességet, illetve a maximális CPU erőforrást a beállított felső limitig. Ha pedig mind a 100 éppen teljes erőből dolgozna, akkor a fenti erőforrások százfelé oszlanak el. Ennek semmi köze nincs ahhoz, hogy hány TB a storage és hány GB a memória.

Persze megteheted, hogy minden erőforrást egyformán osztasz el, de akkor a virtualizáció egyik legnagyobb előnyét veszted el... ott lesznek a fizikai hardvereid és alig lesznek kihasználva.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

> Ahha... nyilván, tehát például az x Gbps az garantált és nem elérhető maximum sávszélesség? :)

Erre a kérdésre nem tudok válaszolni, mert az Azure networköt annyira sem ismerem, hogy meg tudjam mondani, mennyi az a bizonyos "x", úgyhogy nem mennék bele SLA-kérdésekbe.

> a maradék egy kapja a teljes memória, hálózat és I/O sávszélességet, illetve a maximális CPU erőforrást a beállított felső limitig

Nem, nem kapja. Próbáld ki! :)

Azt fontos megérteni, hogy az Azure célcsoportja nem feltétlenül a hobbiprojektek. Egy adott VM DigitalOcean-ön 80 dollár havonta, Azure-ban ugyanaz 270. Cserébe tud egy csomó mindent, amit a DO nem, például hogy amiért fizetsz (pl. dedikált CPU magok), az a tiéd, más nem piszkíthat oda.

Pont ezért fizetsz akkor is, amikor a VM ki van kapcsolva.

> ott lesznek a fizikai hardvereid és alig lesznek kihasználva.

Szolgáltatói szempontból nézd: ha az ügyfélnek az az érték, hogy dedikált erőforrást kap, és ezért hajlandó fizetni, akkor nekünk nem érdekünk, hogy 100%-on pörögjön minden. Az ügyfél azért fizeti a háromszoros felárat, mert a két szolgáltatás teljesen másról szól. Az Azure "fő" szolgáltatása nem is a VM, nem érdemes összehasonlítgatni VPS szolgáltatókkal.

"Nem, nem kapja. Próbáld ki! :)"

Tehát van az adott hoston mondjuk 1Gbps hálózati sávszélesség, van rajta mondjuk 100 kis virtualizált gép és ezért a sávszélessége mindegyiknek le van vágva 10Mbps-re? Nem tudom elhinni. Ahogy azt se, hogy limitálják a virtuális gép memória sávszélességét vagy a local SSD IOPS-t.

"Egy adott VM DigitalOcean-ön 80 dollár havonta, Azure-ban ugyanaz 270. Cserébe tud egy csomó mindent, amit a DO nem, például hogy amiért fizetsz (pl. dedikált CPU magok), az a tiéd, más nem piszkíthat oda."

Harmadszor írom le, hogy a CPU-t kicsit, a memóriát szinte alig szokták túltervezni, nem ezek a tipikus shared resource-ok. De mindegy, ne olvasd el vagy értsd meg.

"Pont ezért fizetsz akkor is, amikor a VM ki van kapcsolva."

DO-nál és Vultr-nél is fizetsz, ha ki van kapcsolva a VM... szóval akkor mi van? :)

"Az Azure "fő" szolgáltatása nem is a VM, nem érdemes összehasonlítgatni VPS szolgáltatókkal."

Neked ebből van valami certificate-ed, vagy csak önjelölt módon próbálsz szakérteni, mert még erősen dolgozik benned a lojalitás?

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

> Neked ebből van valami certificate-ed, vagy csak önjelölt módon próbálsz szakérteni, mert még erősen dolgozik benned a lojalitás?

Köszönöm kérdésed, a helyzet kicsit bonyolult. A cert ugyan még nincs meg, így tulajdonképpen igen, önjelölt módon próbálok szakérteni szakértek, de csak azért, mert még nem váltottam be a vizsga vouchert.

De amúgy egyszer légyszi nyisd már meg az azure.com-t, tudom, hogy :effort:, meg minden, de megéri. :) Még az IOPS kérdésedre is választ kapsz.

"Köszönöm kérdésed, a helyzet kicsit bonyolult. A cert ugyan még nincs meg, így tulajdonképpen igen, önjelölt módon próbálok szakérteni szakértek, de csak azért, mert még nem váltottam be a vizsga vouchert."

De azért a részletekről fogalmad nincs és gyakorlatban nem tesztelted ezt a kérdéskört, jól látom?

"De amúgy egyszer légyszi nyisd már meg az azure.com-t, tudom, hogy :effort:, meg minden, de megéri. :) Még az IOPS kérdésedre is választ kapsz."

Megvolt, lásd fenn.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

> Az Azure "fő" szolgáltatása nem is a VM, nem érdemes összehasonlítgatni VPS szolgáltatókkal.

Még jó, hogy onnan indultunk ki, hogy „VPS idővel "fárad", illetve azonos pénzért azonos szolgáltatónál is lehet eltérő teljesítményt kapni, mert mindig van valamennyi overbooking” -> a VPS-en van overbooking
Majd eljutottunk oda, hogy az Azure nem VPS.

Kezd egy kicsit zavaró lenni, s a kollega itt nem is volt annyira troll.
--
blogom

> Majd eljutottunk oda, hogy az Azure nem VPS.

Nem egészen ide jutottunk el, de így kontextuson kívül tényleg nem hangzik jól. A lényeg: ha az Azure-t DO-ként akarod használni, valószínűleg drága lesz. (Értsd: van egy VPN-em, amit kb. csak nyílt wifikhez használok, egy ötdolláros szolgáltatónál. Eszembe nem jutna Azure-ra rakni.)

Oda próbáltam eljutni egyébként, hogy az Azure node-okon nincs overbooking, az más kérdés, hogy közösségi erőfeszítésekkel sikerült megint tüzet gyújtani és olajat öntözni rá.

"Oda próbáltam eljutni egyébként, hogy az Azure node-okon nincs overbooking, az más kérdés"

DO-nál és Vultr-nél sincs memória és storage overbooking, a CPU overbooking is minimális. Azure-nál is van network, memory access, I/O és CPU overbooking. Ha azt mondod, hogy nincs, akkor halványlila fingod nincs a virtualizációról.

"A lényeg: ha az Azure-t DO-ként akarod használni, valószínűleg drága lesz."

Az Azure és az Amazon nem azért drágább, mert nincs overbooking, hanem például azért, mert garantált és redundáns a storage, míg a DO-nál és a Vultr-nél nincs semmi garancia arra, hogy amit letárolsz, az holnap ott lesz vagy a snapshot holnap is működik vagy a backup lefut minden nap az adott időben, továbbá nincs semmilyen SLA a szolgáltatásra, ha holnap becsukják a boltot, akkor becsukták a boltot.

Nem az overbooking hiánya miatt kerül többe, az egész másképp és más elvek mellett működik.

"közösségi erőfeszítésekkel sikerült megint tüzet gyújtani és olajat öntözni rá"

Szóval elkezdesz szakmai balfaszságokat előrángatni, aztán még Neked áll feljebb, ha nincs igazad... :/

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Nem, a reserved instance csak azt garantalja, hogy lesz szabad kapacitas a gep inditasara (illetve kevesebbe kerul orankent, ha vettel reservation-t).
"Noisy neighbour" problema ellen a reserved instance sem ved.

Amazonnal mas gondok is vannak... pl kissebb fajta instance-ok (nagyjabol m1.large-ig bezarolag) kerulhetnek regi Xeon5400, ddr2-es vagy uj Xeon5600+, ddr3-as gepre is, es eleg eszreveheto teljesitmenykulonbseg van koztuk. Csak az egeszen nagy instance tipusoknal (xlarge +) garantalt, hogy ujfajta gepet kapsz ala.
---
Régóta vágyok én, az androidok mezonkincsére már!

So-so. Alapbol annyit csinal, hogy a kert instanceok rendelkezesre fognak allni, azt, hogy csak a te instanceaid legyenek a fizikai gepen, azt nem.

(Forras: http://aws.amazon.com/ec2/faqs/#Reserved_Instances)

Amire te gondolsz, az a Dedicated Instance (http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/dedicated-instanc…), ami megint egy kulon dolog. Lehet ilyet is csinalni EC2-n, es akkor "csak" a sajat VPSeid kozott lesz "athallas".

--
|8]

Ez is keveredés. A reserved instances azt jelenti, hogy nem fizetsz érte annyit, mintha futnának, de ha kell, akkor el tudod indítani (például egy másik felhasználónak a spot instance rovására). Ha nincs reserved instance-od, akkor is el tudod indítani az esetek nagy részében, de ez nem garantált, lehet, hogy várnod kell, mert éppen nincs szabad erőforrás.

De ennek semmi köze ahhoz, hogy zavarhat-e egy másik instance, mert elzabálja az I/O vagy CPU erőforrást, ismétlem: nem a memóriából és/vagy a disk területből jut kevesebb, hanem azokból, amelyeket egyszer már felsoroltam.

Egy kérdést azért feltennék: kb. hány szervered van cloud szolgáltatóknál és melyikeknél?

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Köszi, ezt mondta algernon is, kettővel feletted. :)

Feltettem egy kérdést egy konkrét, fizetős szolgáltatásórl, mivel sosem használtam AWS-t. Nem a kifejezés szó szerinti jelentése érdekel, mert angolul én is tudok, hanem hogy mi jár a pénzemért. ;)

szerk: ja, ez kimaradt
AWS: 0
DO: elég sok volt, jellemzően nem egyszerre. párhuzamosan egyszerre kb. 1
Azure: elég kevés, de ide migrálódtak be PaaS-ként a DO-s és Azure-os VM-ek

"de ha a node-ban 16 giga RAM van, akkor csak 4*4 GB-s instance indulhat"

Szinte az összes cloud szolgáltatónál ez van... ettől még kiszedhető teljesítmény változhat attól függően, hogy mit csinálnak a szomszédok, mert van egy csomó shared resource (írtam már: network, I/O, memory bandwidth, kis mértékben CPU, IRQ, stb.).

"AWS: 0 DO: elég sok volt, jellemzően nem egyszerre. párhuzamosan egyszerre kb. 1"

Ahja... mert nekem most átlagosan ~30 gépem van havi ~150-200 dollár közötti összegekért általában három szolgáltatónál, Azure-t is volt már, most épp nincs. Szóval én próbáljam ki, hogy melyiknél mennyi az overbooking? Ahm...

Mit akarsz bizonyítani?

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Gábor, nyertél. :)"

Ez nem arról szól, hogy nyertem-e vagy sem, hanem arról, hogy mennyi szolgáltatásod van éles üzemben metrikákkal mérve.

"Ez ha jól számolom, akkor pont az 5 dodós VPS."

Nem, 5 és 40 dollár között vegyesen, különféle időtartamokban, mert ugye a cloud nem arról szól, hogy fix számú géped van hónapokon át, hanem arról (is), hogy pár órán át tesztelsz mondjuk 8db 64GB memóriájú géppel...

"Azt még elárulod, hogy Azure-ban mid volt?"

Nem tudom név szerint, 1 és 2 CPU, 1,75/3G körüli gépekkel játszottam, de például nem volt stabil az IOPS.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"hogy lehet horizonálisan skálázhatóvá tenni" +1, amíg ez nem megoldott, addig SPOF lesz a dolog, és a magas rendelkezésre állás is ugrott. Persze ahhoz, hogy megoldódjon több lábon is meg kell támasztani az rendszert és lehetőleg minden automatizálni is kell mindent, plusz az alkalmazásokat is fel kell készíteni rá, ami nem kevés pénz. Az a kérdés, hogy mi kevesebb veszteség?

-
Konténerezett Hadoop és Cassandra cluster konfigurálása - első rész

Mind a Virtuozzo, és az erre épülő OpenVZ így csinálja, ha nincs szabad kapacitás az adott node-on, akkor live át lehet mozgatni (persze ennek ideje van, ez eset függő, hogy mi a gyorsabb, a live mozgatás, vagy stop-start. Ha a gépnek van mondjuk 16 giga memóriája ami tele van, akkor sokszor a stop-start gyorsabb).

MikroVPS

Ez két külön lépés. Mondjuk beesik a kérés, hogy adott VPs-t át kell méretezni (mondjuk +5 gb ram), de a node-on ahol van, csak 4 giga van szabadon mondjuk. Ekkor előbb át kell mozgatni a VPS-t egy olyan node-ra, ahol van +5gb szabad ram. A mozgatás lehet live, vagy nem live, live esetén freeze-lve lesz a vps, kidumpolódik a memória, stb. ez átmásolódik a másik gépre, és visszatöltésre kerül, nem live esetén leállítás, majd az új helyen elindítás. Adott környezettől függ, hogy mi a gyorsabb, pl. egy sok memóriát használó mysql szerver esetén gyorsabb a leállítás, majd elindítás, míg sok gigányi memóriát kidumpol, átmásol és visszatölt.

MikroVPS

Feliratkozok.

Nekem kisebb léptékben kellene ilyesmi, bár inkább a szabadon konfigurálhatóság lenne a lényeg. A legtöbb helyen "csomagokra" lehet előfizetni, ami x tárhelyet, y memóriát és z cput jelent. Ha nekem y+512MB memóriára van szükségem - és csak arra - akkor is le akarják nyomni a torkomon a plusz tárhely és cpu költségeket, amiket persze meg is kapok, de minek, aka másik csomag.

Gondolom, hogy ez a tervezhetőség miatt van. Mivel nem azonnal kell, így egy olyanba is belemennék hogy igény bejelentés után egy-két héttel, esetleg hónappal később élesedik a beállítás.

Amazon, Google Cloud gondolom nem garázs szolgáltatók, és ott én _hangsúlyozom én_ csak templatekkel találkoztam, és jártunk úgy, amit a kolléga is említ. De ha lehet is kedvedre csinálni konfigurációkat, annak az ára lehet húzósabb.

-
Konténerezett Hadoop és Cassandra cluster konfigurálása - első rész

megkövetlek, benéztem most az awsbe (nem használom sokat), és bár minden vackot külön lehet managelni, cpu izére valóban csak templatek vannak.

utoljára azt hiszem pl az arubánál láttam proci/mem/storage csúszkát: szerk kivettem a linket, szó ne érje a ház elejét. Use your google fu.

mondjuk azt nem tudom, lehet-e állítgatni kreálás után, mert sose használtam, de mivel Lacyc mondta, hogy az sem baj, ha átfutási idő, akár azt is el tudom képzelni, hogy elstartorlja az újat, aztán költözik...

Alapvetően az occóVPS-nél van ez. Egyszerűen az automatizáltan elérhető folyamatokon kívül nem foglalkoznak semmivel, ami külön egyedi beállítást igényel. (Még úgy is, hogy ha ugyanannak a szolgáltatónak van occó és mondjuk úgy hogy normál VPS szolgáltatása, akkor az occóra azt fogja mondani, hogy ami ott van csomag azzal főzzél vagy válts a másik szolgáltatásra.)

Ha gondolod írj privátot, mi egyedi VPS-ekben utazunk, bár relatív kis cég vagyunk.

Nem az automatizálás miatt van, hanem ahogy fentebb írták a tervezhetőség miatt. Van X hdd-d, Y RAM-od, Z cpu-d egy szreverbe, ezeket felosztod kapsz csomagokat, szépen tervezhető az erőforrás igény.

Egyedinél, meg mivan, ha bekapcsol mondjuk 10 olyan embert akinek kell 10 tera hdd, meg 1 giga ram mondjuk, akkor eltolodik az egész erőforrás igény, nem egyenletesen lesz kihasználva a rendelkezésre álló kapacitás.

MikroVPS

IBM - SoftLayer.
Ha jol tudom akkor tudja ezt, de azert kerdezz ra.

Sajnos nem tudja:

Ewan J: Hello, thank you for contacting SoftLayer. How can I help you today?

Aron: Hello Ewan! I would like to ask questions about vertical scalability. How a virtual machine resizing works? Can it happen without downtime?

Ewan J: Hi Aron

Ewan J: OK, depends what you mean by AutoScale. If you mean spining up new servers as needed, then yes, there is no downtime needed.

Ewan J: But if you mean upgrading the Virtual server you are using (ie adding Ram, Storage, Cores etc), then there would be downtime