Fórumok
A jövőben szeretnék egy hosting céget alapítani (elsődlegesen virtualizálással foglalkozna). Ehhez kellene nekem egy kezdetnek megfelelő konfiguráció. Xen alapú VPS-ek futnának rajta. Számítana a nagy kapacitású háttértár is, de fontos a költséghatékonyság (max 200-300k-ból jó lenne, ha meglenne).
Gondolkoztam azon is, hogy szerver alkatrészekből én magam építem meg, de árban szinte rosszabbul jönnék ki, mint brand géppel. Várom a javaslatokat. (A dolog egyébként legalább fél év múlva indulna, szóval van idő szépen mindent átgondolni)
(Moderátorok: véletlenül létrehoztam írásként, az törölhető)
A válaszokat előre is megköszönöm!
Hozzászólások
hp-bol lehet ilyen aron kapni ha jol lattam, ml110 g6, teszel bele egy rakat ramot azt kesz is
Akciós szerverek, olyan áron vannak amit írsz, viszont ha megtöltöd rammal, akkor könnyen kerülhet a duplájába is :/
Ubuntu 10.04, Thinkpad x61s
1) az mindenképpen helyes meglátás, ha alkatrészekből építed árból rosszabban jössz ki - szerintem SLA-ban is.
2) VPS kiszolgáláshoz szerintem mindenképpen 2 utas szervert vegyél (minimum) - és nem volna hátrány a redundáns tápegység sem - főleg ha üzleti jelleggel csinálod.
3) Szintén az üzleti jellegből indulva elgondolkodnék (illetve célirányosan inkább azt választanám) egy osztott háttértáron. így egy gép leállása nem veszélyeztet szinte semmit - max az aggregált kiadható CPU-t.
4) Ha csak játszani akarsz (megismerni a lehetőségeket) akkor indulj el egy ML110 - ML150 kategóriával, de ezeket én
NEM használnám a fenti szolgáltatáshoz (maximum tartalék jelleggel), inkább DL360 v DL380 szerverekben gondolkodnék (avagy alternatív gyártó hasonló szintű szervereiben: 2utas, redundáns táp, SOK memóriaslot)
"max 200-300k-ból "
Ehömm.... Ha üzletszerűen akarsz virtualizációval foglalkozni, és el is tudod adni a szolgáltatást, akkor ez kevés lesz.
A fontosabb paraméterek:
1. Min. 4 diszk, de inkább 6, BBWC raid kártyával (min. 128 vagy 256MB memóriával).
A diszk io szokott a legelső szűk keresztmetszet lenni egy ilyen szervernél. Az össz diszkkapacitás kevésbé lényeges, 1T körül bőven elég első körben. Ha ezt kinövöd, akkor már anyagilag is indokolt egy külső storage.
2. Memória. Legalább 12GB, de inkább 32+. A memória egyébként sztem. a legolcsóbb tényező.
3. Cpu-ból elég egy jó minőségű 4 magos HT-s pl. Xeon E5520, vagy vagy jobb. Nem árt, ha 2 utas alaplapod van, hogy esetleg később bővíthető legyen.
És természetesen redundáns táp.
Egy ilyen vasra szerintem alsó hangon nettó 500K körül érdemes tervezni.
Ha nagyon korlátozottak a forrásaid, akkor inkább a diszkre szánj több pénzt (a darabszámra kell rámenni, nem a kapacitásra), mert memóriát vagy processzort lényegesen egyszerűbb bővíteni, mint diszket. (Meglévő raid5, vagy raid10-et bővíteni úgy, hogy rajta laknak a VM-ek, elég szopó....)
Ha Xen, akkor javaslom a Citrix Xen szerverét. Hostingra is ingyenesen használható, és már az ingyenes verzió is tud live migration-t (ami igazából csak onnantól érdekes, ha van legalább 2 vasad, és egy külső storage-od), de ami még lényegesebb , hogy veszett egyszerűen telepíthető és konfigurálható.
Szerver típusokból az utóbbi időben nekem a Dell jött be, legutóbb hasonló célra R510-et vettünk.
Attól függetlenül, hogy milyet választasz, szerintem a fő szempont az legyen, hogy 4 nél több diszk beleférjen, úgyhogy valószínűleg a 2 rack unit méret körüliek lesznek a nyerők.
Xenhez nem értek, de VMware kapcsán kb ugyanezeket lehetne elmondani.
Ami még fontos, hogy minimum 4, de inkább 8GB-os RAM modulokból építkezz.
Túl nagy lokális lemez kapacitásra azért is felesleges berendezkedni, mert túl "sok" virtuális gép nemcsak I/O miatt lesz/lehet szűkös, hanem a függés is túl nagy lesz az egyetlen vastól (azaz egy leállás azt jelenti, hogy minden ügyfél áll). Azaz SATA lemezt nincs is értelme venni, csak SAS-ban érdemes gondolkodni.
A "tákolós" és "brand" szerverek között van egyfajta középút (például Intel szerverek), ez alá biztosan nem adnám. Egy darab vas esetén 24x7-es supporton is érdemes gondolkodni, de ennek előfeltétele valami normálisabb márka választása.
A fentieken kívül megfontolandó megfelelő számú hálókártyát betenni már az elején, ugyanis a következő lépés jó eséllyel iSCSI tároló lesz: bővítéskor nem kell mindenkit leállítanod, lehet egyenként is migrálni a virtuális gépeket (nem tudom, a Xen tud-e Storage VMotiont, illetve milyen lehetőségei vannak - gondolom VMware Enterprise licencet úgyse fogsz venni az elején).
A memória egyébként sztem. a legolcsóbb tényező.
Ezt most nem fogom tudni jól megfogalmazni, meg amúgy sem értek hozzá (annyira biztosan nem, mint te), de a múltkor láttam egy ilyen szerver-összekattintgatást a HP oldalán, fix keretből. Valahogy az volt a benyomásom, hogy a memória a legeslegdrágább tényező. Miért:
(Itt jön az, hogy nem fogom tudni megfogalmazni általánosságában, konkrétumokat meg nem akarok/tudok írni:) képzeljük el, hogy mondjuk elmegyünk a megadott keret 2/3-áig egy nagyjából kiegyensúlyozott szerver összekattintgatásával. (A host alapvetően CPU- és viszonylag diszk-intenzív guest-ek alá kellett.) A 2/3-nál természetesen szeretnénk feljebb menni (elkölteni minden pénzt), és lehetőleg megtartani a kiegyensúlyozottságot is. És akkor kiderült, hogy innentől "arányosan" növelni a memóriát a plusz CPU-kkal nem lehet, mert a RAM iszonyatosan drága -- ha hozzáadunk még egy kicsi RAM-ot, az elviszi az összes maradék pénzt, és CPU-ra nem jut. Ugyanakkor ha a 2/3 büdzsétől felfelé csak CPU-kat rakunk a dobozba, akkor abból még fér egy szakajtónyival. (Ugyanez áll fenn CPU helyett (sok, kicsi, független) diszket értve.)
Egyszóval én úgy láttam, hogy fajlagosan a RAM a legdrágább.
Heccből megnéztem azt is, hogy mennyibe kerülne egy "üzleti" asztali HP PC-t felbővíteni 2G-ről 6G-re: a plusz 4G RAM ára eléri a gép eredeti árának egyharmadát.
Ezekkel "egyetértek" (nem mintha sokat számítana a véleményem, a méretezés nem része szigorúan véve a szakmámnak):
A diszk io szokott a legelső szűk keresztmetszet lenni [...] Memória. Legalább 12GB, de inkább 32+.
Ezen viszont nagyon meglepődtem:
Cpu-ból elég egy jó minőségű 4 magos HT-s pl. Xeon E5520, vagy vagy jobb.
Nekem ez borzasztóan alultáplált masinának tűnik. Amit az ügyfelek bérelt virtuális gépeken futtatnak, annak nem kell CPU?
Köszi!
Memóriát tudsz venni kingston-t is pl.
Az esetek 90%-ban egy szerver előbb fogy ki a diszkio-ból, mint cpu-ból. A legtöbb ilyen VPS mit futtat? webszervert, fileszervert, torrentszervert, levelezőszervert. Egyik sem túl cpu intenzív, hanem diszk intenzív felhasználás. Akinek kell CPU az ált. vagy cloud, vagy rendelkezik háttérrel, ergo nem hozzád megy. Persze, ha van egy jó storage-d, akkor már érdemes nagyobb CPU-ban, ill több szerver beszerzésén is gondolkodni már. Illetve nézd meg, hogy a legtöbb VPS szolgáltató mennyi CPU-t ad a vps-éhez :).
"Egyszóval én úgy láttam, hogy fajlagosan a RAM a legdrágább."
Egy E5630-as cpu áráért Dell-hez kapsz kb. 16GB gyári ramot. (kb 56k+áfa egy 8GB-s kit, R510-bw való E5630-as pedig nettó 104k+)
16GB-ram ra tervezhető kb 12-15 vps, viszont ennyit nem biztos, hogy egy cpu elvisz.
Ráadásul egy alsó kategóriás szerverbe belefér 64-128+GB ram, és max. 2 cpu. Nagyon sanszos, hogy a cpu lesz a limit a szerverben a végén, innentől kezdve a cpu a drágább.
"Heccből megnéztem azt is, hogy mennyibe kerülne egy "üzleti" asztali HP PC-t felbővíteni 2G-ről 6G-re: a plusz 4G RAM ára eléri a gép eredeti árának egyharmadát."
Vagyis a memória triplázása a gép árát a harmadával dobta meg.
Mennyibe került volna bele 3-szor annyi cpu? :)
"Nekem ez borzasztóan alultáplált masinának tűnik. Amit az ügyfelek bérelt virtuális gépeken futtatnak, annak nem kell CPU?"
Átlagos webszerver/mail szerver vps elég kevés cpu-t eszik. Jobb, ha memória van alatta bőven, mert pl. akkor a diszket is kevésbé nyúzza. Kezdő szervernek nem rossz, mert ugye ez a topic erről szól.
+1
A HP DL380G7-ben (esetleg G6-ban is) CPU-nként 3-3 bank van 3-3 slottal.
Ha indításból 12G-vel (teljesítmény miatt 3x2G/CPU) indulsz, a a slotoknak csak 1/3-át használod ki. Azaz a fajlagosan legolcsóbb modullal később is tudod bővíteni a gépet 36G-ig, de ha később már több pénzed lesz akkor egy körben veszel 6x4G (6x~32e) majd mégegyszer ennyi RAM-ot. Azért a 60G már elég tudhat lenni... (és simán tudod fokozatosan bővíteni)
Ennyi pénzből amazon cloud-on tudsz bérelni vps-t, ennek a 3-4x-e (1m HUF) csak a brand hw.
Attól függetlenül, hogy milyen feladatra virtualizáltunk, egy dolog mindig kevés volt: a RAM, illetve a gépbe pakolható mennyiség. Ergó olyan gépet vegyetek, amibe lehet jó sokat tenni.
Sajnos Xen esetében nem lehet a fizikai memóriát túlhazudni (vannak próbálkozások - ballooning stb. de nekem ezek nem jönnek be), így a memória a szűk keresztmetszet.
Hiába van redundáns tápod, ha nincs redundáns alaplapod. Erre egy gép sajna nem elég, ha az SLA-t fel akarod tornászni, akkor klaszter kellene.
igen, és itt jönnek a kérdések a 9esekkel kapcsolatban.
a következő opciók lehetnek:
- Xen futtatása Kemari-val (v hasonlóval)
- hot standby (normális szerver általában nem elhasal hanem shutdown-ol gond esetén - ilyenkor tudsz domU-t migrálni)
- cold standby vas (kiveszed a cuccot és átrakod)
- 4-8 órás szervíz (uaz mint a fenti csak lassabban, külsős cég által)
- NBD garancia (legkésőbb köv munkanap kijönnek megnézni és elindítják a garanciát)
jönnek a köv. kérdések, hogy mekkora SLA-t szeretnél biztosítani.
ennek függvényében eldöntheted, hogy
- szimpla tápos gép elég-e
- raid van-e
- memória raid kell-e
sajnos ha hardver hibád van, akkor baj van, mivel áll a cucc
ha szerencséd van, ki tudod javítani egy óra alatt, ha nincs, napokig áll
minimális klaszter esetében (2 gép) már jobb a helyzet, csak ide meg be kell fektetni
ha teljes virtualizálsz is, akkor kell a CPU flag, az meg legalább egy "újabb generációs" procis gép
http://wiki.xensource.com/xenwiki/HVM_Compatible_Processors
nem is beszélve arról, hogy nem árt egy közös diszkrendszer (SAN), ahol tárolod a virtuális
gépeket. Ez már ugye 3db gép. (bár ide elég egy P4-es is, elviszi)
Költség, költség, költség.
A "fault tolerance" megoldások játéknak jók, de sokesetben feleslegesek, ugyanis szofveresen is megoldható a rendelkezésre állás virtuális gép szintjén.
Ha a SAN nem cluster akkor ugyanott vagy mintha nem csinálnál clustert. Nem hiszem, hogy egy P4 elviszi.
Igen, ott is lehet fokozni a redundanciát.
A második dolog nem hit kérdése, hanem tény.
Szia,
a fajlagosan legolcsobb CPU-t kell venni:
cpu specINT_rate ertek adja a teljesitmenyet,
az arba beleveszed a hazat, az alaplapot, a kartyakat, licenszeket, egyszoval mindent a memorian kivul.
2009-ben az igy kapott fajlagosan legolcsobb CPU az dualprocis alaplapban dual intel xeon E5520 volt. Azota 1-2 generacio jott ki intelbol, es AMD-bol is, varhatoan nem az xeon E5520 a legjobb.
Az alaplapot teli kell rakni a fajlagosan legolcsobb memoriabol: cost/GiB
Ha az igy kapott gep neked draga (nincs meg az indulo toke ilyen gep vasarlasahoz) akkor tudjad, hogy barmit veszel, az fajlagosan dragabb lesz, ergo a szolgaltatasodat fajlagosan dragabban tudod csak adni, mint az elegendo indulotokevel rendelkezo konkurensed. (vagyis ne vagj bele)
amit kihagytam:
indulasi koltseg 60% -> diszk hattertar
indulasi koltseg 40% -> szerver (mint amit fentebb irtam)
ha egy igy telirakott szerver 0.7M -ben all meg, akkor neked 1M kellene kolteni diszkekre, tehat 1.7M indulotoke kellene.
Ha az igy telirakott szerver 0.4-ben megall, akkor eleg az indulashoz 1M forint.
A fajlagos koltseg-ter nem homogen, es nem is emelkedik egyik-masik iranyba. Elofordulhat, hogy egy teljesen mas (sokkal olcsobb vagy sokkal dragabb) konfiguracioval alig valamivel dragabb fajlagos koltseget is el lehet erni, es akkor az igy keletkezo versenyhatranyt mas modon kompenzalni lehet (olcsobban szamitod a munkaerodet, vagy megnyero a modorod vagy barmi egyeb).
A diszk:szerver = 60:40 arany az jopar nagyvallalati project leszurt tanusaga.
ez csak akkor teljesul ha helyre is szukseg van, nem feltetlen kellenek gigaszi meretek mindenhez... van amikor eleg 1gb is, csak gyozd kiszolgalni
igen. viszont a sok hostolt vps ad egy átlagot, ami nagyon hasonló a legtöbb szerveren....
az oke, de ezt a 60-40et nem lehet altalanositani akkor sem szerintem:)
'storage' alatt hozzaveszem a raid vezerlot, a diszkek elhelyezesere szolgalo helyet, stb.
Arrol van szo, hogy valamirevalo terhelesnel nem boldogulsz el 1 tengellyel. sok diszk kell, akkor is, ha keves adatod van. 4 diszk meg beteheto a szerverhazba, 4 diszkes raid kontroller meg olcsoert van, 8 diszk eseten viszont mar muszaj valami specialisat venni, legyen akar csak egy supermicro haz az.
a HP DL350/380 gépekben SFF esetén 8, LFF esetén 6 slot van.
a 350-ben van hely egy extra cage-nek is (akár második vezérlővel).
kontroller van alaplapon P410 (PN-től függően ZM-től 1G FBWC) persze ezek nem speciálisan storage-nak kialakított vasak. elképzelhető lenne még 1U szerver külső csatlakozó-kivezetéssel 4-8-12 helyes SATA hdd házhoz.
sub
-------------------------
127.0.0.1 SWEET 127.0.0.1
Mi is tervezünk hasonlót. Mi ilyesmire gondoltunk első körben:
Xeon52XX
8 GB ram
raid10
-------------------------
127.0.0.1 SWEET 127.0.0.1
Xeon 52xx?? A 8GB nagyon halovány lesz.
Még nem tudom milyen xeon legyen, 55-ös sorozat az biztos.
8 giga meg azért, mert nem az első hónapban fogunk kiadni annyit, hogy megteljen a 8 Gb. mivel a ram ára folyamatosan csökken, így felesleges egyből 64 gigát belepakolni.
Bár az tény, hogy minket nem annyira köt az ár, mint a topic indító kollégát.
-------------------------
127.0.0.1 SWEET 127.0.0.1
Ha most új gépben gondolkodtok, akkor 56xx-es sorozat és 3x4GB memóval induljatok szerintem. Aztán majd kiderült merre kell fejlődni.
Megfontolom, kösz az ötletet
-------------------------
127.0.0.1 SWEET 127.0.0.1
A baj az, hogy az ECC-s RAM ára aranyár. No persze nem a Kingston kategória, hanem a brand. Lehet próbálkozni előbbivel is...próba cseresznye.
Néztél mostanában memó árakat? A Kingstonnak megvan a saját adott szerverhez certifikált típusa, ami általában a fele a "brand"-nak, viszont minőségben egyenértékű.
van a Kingston-al rossz tapasztalatod? nekem nincs. amihez eddig eladták, azzal ment is (mint a gyári)
Az a vicces, hogy egy csómó "brand" memóriát valójában a Kinston gyárt.
Nem értem mi bajotok van a kingstonnal. Nekem évek óta olyan memóriáim vannak, gond nélkül futnak.
-------------------------
127.0.0.1 SWEET 127.0.0.1
Szerintem pont zwei-nek nincs velük baja. :) Meg nekem sincs, sőt szintén évek óta nagy örömmel használjuk mindenféle gépekben. Azért kedvencem egy régi SHG2-es Intel Xeonos lap volt ami CSAK a megadott Kingstonnal (KVR266R72 vagy vmilyen és utódjai) ment, semmi mással, igaz 2-3 másféle memón kívül nem próbálkoztam.
Azért neki válaszoltam, mert ő volt feljebb :D
-------------------------
127.0.0.1 SWEET 127.0.0.1
Egyetértek, a Kingston jó választás. Pl. a 4GB-os Kingston ECC reg RAM (KVR1333D3D4R7S/4G) simán megfizethető és teljesen megbízható modul.
+1
dupla táppal egy ilyen gép (ennyi RAM-al) kis mázlival 5-600e körül lehet is. (persze 1 CPU-val)
"8 giga meg azért, mert nem az első hónapban fogunk kiadni annyit, hogy megteljen a 8 Gb. mivel a ram ára folyamatosan csökken, így felesleges egyből 64 gigát belepakolni."
Ezzel azert vigyazz. Memoriat csak leallassal lehet boviteni, vagyis ket node-val szamolva 8G ram felhasznalas utan mar boviteni kell, ha nem szeretnel ugyfelet veszteni az indulashoz tul kozeli shutdown-nal. En azt mondom, hogy node-nkent olyan 16-24G az mar realisabb osszegnek tunik.
Arrol nem beszelve, hogy a 8G az hipp-hopp megtelik, jon negy 1G-s VPS igeny, meg ket 768-as, es mar 6G-nel jarunk.
--
Mi nemrég vettünk cisco szervereket következő felállásban
3 db UCS C200M2 esek kökvetkezp kiépítésben
Elsőben 1db E5620 cpu meg 1 táp, a másik kettőben 2db X5650 es cpu 2 táp
Mindkét gépben alapban 3x2G ram volt. Disk nem volt bennük.
Ehhez rendeltünk még 12db 8G-s ram modult. A ram modulok ára a 3 szerver árának majd a fele volt :>
Ubuntu 10.04, Thinkpad x61s
Köszönöm a javaslatok, sok hasznos információval gazdagodtam!
Ennyiert beballagsz az Amazonhoz, vagy valamelyik nagy VPS szolgaltatohoz, es kotsz veluk viszonteladoit - esetleg. Egy ketnode-s, ket storage-s, egy controlleres rendszer ennek legalabb a 5x-oseba faj. Epp most rakunk ossze olyan hardvereket, amik akar erre is alkalmasak lennenek, es a legolcsobb ertelmes valasztassal se tudsz 200k ala menni.
Egy ilyen rendszerbe a memoriat fosni kell, a diszket szintugy, minimalis redundancia nelkul bele sem szabad vagni a dologba, megtervezett backup nelkul pedig meg gondolkodni sem szabad rajta.
--
Ott a pont. Minimum két kiszolgáló vas, közös, gyors storage (sok diszk, raid10-ben, cache-sel megtámogatott vezérlőn), mentőeszköz, monitoring, amiből megbízható, időgarantált módon érkezik sms-ben a riasztás, ha gond van, a 7*24-es rendelkezésre álláshoz humánerőforrást tekintve kell minimum öt bevethető ember (jó, 3-4 fővel is el lehet döcögni, de akkor az jelentős kötöttségekkel jár)...
Lehet óccsópistikehostingbété-ként indítani, de abból, ha nem adsz valami tényleg extra pluszt, akkor nem lehet kinőni.
"Minimum két kiszolgáló vas, közös, gyors storage (sok diszk, raid10-ben, cache-sel megtámogatott vezérlőn), mentőeszköz, monitoring"
... vagy kitalalsz egy okos architekturat, es ennel sokkal jobb szolgaltatast epitesz a toredekebol. :)
--
"You're NOT paranoid, we really are out to get you!"
Nagyon nem lehet csalni. Picit... hat esetleg. Lassuk, mi az amit el lehet hagyni.
- monitoring - el lehet, vegulis a felhasznalok a legjobb monitorozok
- mentoeszkoz - lehet elni nelkule, ez vegulis felho, a felhok pedig atmeneti kepzodmenyek. Neha eltunnek.
- kozos gyors storage - hat, el lehet hagyni. Nincs live migracio, de enelkul meg lehet elni. Kar, hogy ha egy node leall, akkor azokat az ugyfeleket nem fogja vigasztalni, hogy a vilag masik fele meg boldog.
- egyik node - igen, felesleges ketto. Majd ha bovules van. Live migracio ugy sincs, tiz embert meg egy gep is elbir.
- masik node - na igen. Nincsenek felhasznalok. Az idealis allapot. Megpihenhetunk.
--
Játszani tényleg jóval kevesebb is elég. Garantált szolgáltatáshoz meg nem. És itt a "garantált"-on van a hangsúly.
Jó, persze lehet a közös storage helyett belső diszkeken drbd-vel tükrözni-trükközni, ergo a storage, mint céleszköz elhagyható. Viszont ha bejön egy harmadik node...
Dehogynem.
Pl. a kozos storage arra valo, ha tobb geprol ugyanazt a kozos adatot szeretned elerni. A jelen eset viszont nem ez, itt az adatot jellemzoen egy gep akarja elerni (ahol fut a vm), es ez csak ritkan valtozik (ha kezzel at akarjuk rakni, vagy ha az adott gep megdoglik). Tehat siman lehet a vm-et lokalis diszken tartani, csak a replikaciorol kell gondoskodni. Pl. csinalsz egy gyuru topologiat, es mindegyik replikal a szomszedaira.
Skalazhato a vegtelensegig, cserebe olcso.
Ha nem blokkeszkozt adsz a juzereknek, akkor egesz pontosan lehet tudni, hogy minimalisan mit es mikor kell replikalni, es a deduplikacio is hatekonyabb.
BBWC-s vezerlo: iszonyat draga, kis tulzassal 2 gep vezerloinek arabol vehetsz egy harmadik gepet. Ha tenyleg keves az i/o teljesitmeny, lehet cache-elni ssd-re, ami olcsobb, cserebe a vezerlo cache-enel osszehasonlithatatlanul nagyobb.
Mentoeszkoz: errol mond le az ember a legkevesbe szivesen, de pl. a redundancia+snapshotolas is egy jo irany lehet.
"Játszani tényleg jóval kevesebb is elég."
Felreertesz: nem elsosorban azt mondom, hogy az indulo toke lehet ennek toredeke, hanem a vm-enkenti koltseg.
"És itt a "garantált"-on van a hangsúly."
Garantalt ez sosem lesz, akkor sem, ha a vilag minden penzet rakoltod. Eleg egy bug a xenben, meg valaki, aki nem birja a keped...
--
"You're NOT paranoid, we really are out to get you!"
"Pl. csinalsz egy gyuru topologiat, es mindegyik replikal a szomszedaira."
Hihihi... ezt ugye te se gondoltad komolyan? Mondd, hogy nem...
A jelenlegi replikacios megoldasok - tul azon, hogy baromi sok I/O-t esznek -, egyszeruen nem alkalmasak ilyesmire. Sem a sebesseguk, sem a stabilitasuk nem megfelelo, es nem mindegy, hogy mikortol szamit az adat replikaltnak, es a replikacio mely szakasza az, amikor az illeto gep megdoglott. Raadasul minel tobb gepen megy ilyen tomentelen adat replikacioja, annal tobb a hibalehetoseg. Ez nem egy LDAP szerver, hogy ha nem jott ossze a replikacio, akkor legfeljebb ujra nekifutunk.
A mentes lecserelese snapshottinggal egy vicc. Ez a sufnihostingok tipikus megoldasa. Ha megdoglik a node-ban a lvm (mert ilyen is van), akkor legalabb a vm es annak mentese is elveszett. Milyen kenyelmes...
Egyebkent a blokkeszkozokkel kevesebb gond van, mint a fajlokkal, ezt garantalom neked. Mar csak amiatt az egyszeru ok miatt is, hogy a fajlok eseteben plusz egy reteg van (fajlrendszer), ami semmi egyeb masra nem jo, mint plusz egy hibalehetoseg.
En biztos vagyok benne, hogy nem akarnal egy ilyen rendszert uzemeltetni a mindennapokban.
--
csak egy dologra reagalok, de van tobb mas baromsag is: LVM snapshot vs fs inkonzisztenciarol hallottal mar?
meg hogy letezik "normalis" snapshotting (pl VM memoriat snapshotolod tavoli iSCSI SAN -ra), a SAN meg redundans?
nem mindenki sufnituningol am PCbol :-)
Nem sikerult a szalat elolvasnod. Kedves eax forumtars eppen azt boncolgatja, hogy a SAN mint olyan, na az nincs, helyette van local disk, es azt replikalgatjuk.
Illetve a snapshotting itt mint backup jott elo, amit te mondasz, az meg tok mas. Lecci, olvasd at a teljes szalat, mert amit beirtal, az masrol szol. Dolgozok en is virtualizacioval, sejtem egy picit, hogy mirol van szo.
--
Gaborka, nem veletlenul nem neked valaszoltam am, jo lenne, ha nem szolnal bele a felnottek dolgaba.
Szoval csak roviden:
"A jelenlegi replikacios megoldasok - tul azon, hogy baromi sok I/O-t esznek -, egyszeruen nem alkalmasak ilyesmire."
Mondod te.
"Hihihi" - mondja az iparban kb. mindenki, aki 10 storage szervernel tobbet latott mar egy helyen.
"Raadasul minel tobb gepen megy ilyen tomentelen adat replikacioja, annal tobb a hibalehetoseg."
Ezt nem sikerult megertened egeszen. Egy gep k (legyen mondjuk ketto) masikra replikal. Akkor is, ha csillio geped van.
"Ez nem egy LDAP szerver, hogy ha nem jott ossze a replikacio, akkor legfeljebb ujra nekifutunk."
CAP-tetel megvan?
"Ha megdoglik a node-ban a lvm (mert ilyen is van), akkor legalabb a vm es annak mentese is elveszett."
Ezt sem sikerult megertened. Snapshot+redundancia. Arrol mar ne is beszeljunk, hogy te snapshotnal csak az lvm-re tudsz asszocialni. :)
"plusz egy reteg van (fajlrendszer), ami semmi egyeb masra nem jo, mint plusz egy hibalehetoseg"
Ha te komolyan nem erted, hogy ha latod a filemuveleteket, az mennyiben tud javitani pl. a replikacio (, snapshot, dedup, backup, ...) hatekonysagan, akkor ezt most fejezzuk be. Nem, egyebkent is fejezzuk be.
"nem akarnal egy ilyen rendszert uzemeltetni a mindennapokban"
Az biztos is. Halalosan unalmas lenne. Osszerakni sokkal izgalmasabb.
--
"You're NOT paranoid, we really are out to get you!"
Deduplikaciohoz nem kell a vm diskeket fajlrendszerre tenni. En egeszen kozelrol ismerek olyan termeket, ami shared storage (SAN), iSCSI-n ajanlja ki a tarhelyet, van benne dedup, replikacio, HA, atomgyors, es nem kell vele sakkozni. Windows alapu.
A gyuru topologia ugye arrol szol, hogy van n gep korbe kotve. Mivel minden gepen folyamatosan vannak io muveletek, es - a legrosszabb esettel szamolva - boven van irasi muvelet is, szerintem egy gepnek eleg a sajat irasait replikalni, a masik N-2 gep irasi muveletet nem igazan fogja akarni. Arrol nem beszelve, hogy igy nagyon sok ido, mire a gyuru korbe er, plusz, ha valaki kiszakad a gyurubol, akkor ido ujrakotozgetni a szalakat. Azt mar meg sem emlitem, hogy az utolso replikacios hullamnak el kell ulnie ahhoz, hogy barmely masik gep atvehesse a kiesett gep funkcionalitasat, plusz helyre kell allitani a gyurut, hogy a replikacio is mukodjon.
A shared storage igazabol azert jo, mert ha be kell tolni egy uj node-t a rendszerbe, akkor nem kell megvarni, mig valamelyik node meltoztatik attolni a szukseges imageket, hanem egybol tudja hasznalni. Raadasul egy bovites a te altalad felvazolt rendszerre iszonyu plusz terhelest ro, hiszen a diskimageket - most mindegy, milyen formaban -, de le kell replikalni valahonnet. Es ahol egy node-n van harminc vm, ott mar bizony bottleneck tud lenni az I/O.
A "jelenlegi replikacios megoldasok" alatt en elsosorban a drbd-re gondoltam. Igen, volt tobb drbd alapu kesz doboz a kezeim kozt, es igen, mindegyik elverzett. Az I/O-ban. Mert attol, hogy ipari megoldas, meg nem lesz alkalmas mindenre.
--
"Deduplikaciohoz nem kell a vm diskeket fajlrendszerre tenni."
Nyilvan nem kell, csak h-a-t-e-k-o-n-y-a-b-b.
"A gyuru topologia ugye arrol szol, hogy van n gep korbe kotve."
Fizikailag? Nem feltetlenul. Nyilvan ugy meg olcsobb, cserebe tobb a limitacioja.
"a masik N-2 gep irasi muveletet nem igazan fogja akarni"
N-2??
Ugy sehogysem skalazodna. Inkabb konstans 2.
"nagyon sok ido, mire a gyuru korbe er"
??
Nem er korbe, ez nem a token-ring. :)
"plusz, ha valaki kiszakad a gyurubol, akkor ido ujrakotozgetni a szalakat"
Ha fizikailag vannak osszedugva, akkor ez igaz. Ez all szemben a switchek nehany szazezres-millios arcedulajaval.
"plusz helyre kell allitani a gyurut, hogy a replikacio is mukodjon"
Ez viszont inkabb lehetoseg, mint hatrany. Ha meghal a storage-ed egyik kontrollerje, hogy tudod helyreallitani a redundanciat? Csak ugy, ha veszel egy masikat...
"A shared storage igazabol azert jo, mert ha be kell tolni egy uj node-t a rendszerbe, akkor nem kell megvarni, mig valamelyik node meltoztatik attolni a szukseges imageket, hanem egybol tudja hasznalni."
Ez igaz. Cserebe viszont ha uj storage-t kell a rendszerbe tolni...
"Raadasul egy bovites a te altalad felvazolt rendszerre iszonyu plusz terhelest ro, hiszen a diskimageket - most mindegy, milyen formaban -, de le kell replikalni valahonnet."
Annyira nem iszonyu, a 2 szomszedos geprol kell lehuzni a cuccot. Egy ejszaka alatt megvan.
"A "jelenlegi replikacios megoldasok" alatt en elsosorban a drbd-re gondoltam"
Jahat, arra szot se vesztegessunk. :)
--
"You're NOT paranoid, we really are out to get you!"
Alapvetoen azert jobb a shared storage, mert oneki nem kell a sajat eroforrasait I/O -n kivul masra forditania. Ha a node-k direktben replikalnak korbe, akkor viszont a user elol veszed el az I/O-t.
A gyuru topologiarol. Ha jol ertettem, ugye te azt mondod, hogy minden virtualis gep megvan mindegyik node-n, pont azert, hogy a redundancia ne seruljon, vagyis barmelyik VM elindithato legyen barhol. Ehhez azonban nem eleg az, ha a node csak kozvelten szomszedjanak adja at az infot, es ezzel itt vege, hanem a kozvetlen szomszedoknak megint replikalni kell az o szomszed(ai)nak, hiszen csak igy lesz mindenutt konzisztens replikad.
Marpedig ebben az esetbe a replikacio node-nkent novekvo adatmennyiseg replikalasat varja el a node-ktol, plusz a bejovo adatok feldolgozasat. Ha ehhez meg hozzavesszuk, hogy az idiota userek elvarjak, hogy a vm-jeik emberi korulmenyek kozott mukodjenek, akkor oda jutunk, hogy 2-3x nagyobb node-kat kell betervezni a clusterba, mint amekkorara akkor lenne szukseg, ha shared storage lenne.
Cloud eseteben az az elsodleges szempont, hogy a node-kon minel kisebb terheles legyen, hogy minel tobb kapacitas jusston az ugyfeleknek, hiszen minel tobb szabad kapacitasod van, annal tobb gepet tudsz eladni -> annal tobb beveteled lesz. Vagyis minel kevesebb feladatot kell a node-kra bizni.
Meg ha azt az idealis esetet is veszem alapul, hogy elegseges a kozvetlen szomszedokra replikalni, akkor is tobb eroforrast veszek igenybe mint az feltetlenul szukseges.
Na ezert eri meg storage-t venni. Mert a storage lehet effektive kisebb teljesitmenyu gep is, mint a node, de cserebe a vilagon senkit nem zavar, ha a storage szoftver 100%-on eszi a CPU-t, mert a gepnek maganak ez a feladata, ezen kivul mas szolgaltatas a gepen nem fut. Lehet, hogy elsore barbarsagnak tunik erre egy komplett gepet dedikalni, de a bovulesek soran boven behozza az arat. Raadasul az uj storage node betolasa se egy katasztrofalis dolog, mert az ugye sync, tehat ha este tizkor engedem fel azt a sync labat, mert akkortol kevesebb az effektiv irasmuveletem, akkor a vilagon senki sem fog nyuglodni.
Plusz altalaban a storage node-k parban szinkronizaltak. Vagyis ha mar van 2 storage node-om, akkor nem biztos, hogy erdemes a 3.-ra is atmozgatni a mar meglevo adatokat (ez erosen fugg a vallalasoktol). Inkabb akkor eleve 2 plusz node-dal bovitek, es azok full szuz teruletek lesznek. Annak az eselye, hogy ket fuggetlen gep egyszerre - vagy kozel egyszere - meghal, nyilvan megvan, de az meg egy bevallalhato riziko, es mivel a storage-kbe a legdragabb maga a winyo, barmikor ossze lehet rakni egy atmeneti gepet, amibe betolod a winyot es zorog tovabb a felho. Persze ehhez illik egy alaplap+vezerlo+haz kombot kulcsrakesz allapotban tartani a raktarban, de hat node-kbol is kell.
--
"Alapvetoen azert jobb a shared storage, mert oneki nem kell a sajat eroforrasait I/O -n kivul masra forditania."
Igy van, ha vegtelen penzt feltetelezunk. Mivel viszont a penz veges, eldonthetjuk, hogy akarunk-e kb. a feleert storage-t venni (meg fizetni utana a hostingdijat), vagy veszunk belole tobb gepet, amin ha nem is ketszer, de mindenkeppen tobb vm tud futni.
"a user elol veszed el az I/O-t"
Miota letezik I/O utemezes, ez nem igaz.
"Ha jol ertettem, ugye te azt mondod, hogy minden virtualis gep megvan mindegyik node-n, pont azert, hogy a redundancia ne seruljon, vagyis barmelyik VM elindithato legyen barhol."
Nem. Minden vm legyen meg 3 node-on. Praktikusan a 3 egymas mellettin.
"2-3x nagyobb node-kat kell betervezni a clusterba, mint amekkorara akkor lenne szukseg, ha shared storage lenne"
Rosszul kozelited meg. Azt mondod, hogy az I/O a bottleneck. Oke, tegyuk fel.
X I/O-hoz kell N darab diszk, K-szoros redundanciaval K*N diszk, akkor is, ha storage-ben vannak, meg akkor is ha kis barsonyparnakon, es pillangok viszik hozzajuk az I/O request-eket.
Innentol az a kerdes, hogy mi olcsobb: a K*N diszket egyenletesen szetszorni a gepekben, vagy venni nekik egy kulon dobozt.
Nb: ez a kulon doboz kifejezetten nem olcso. :)
A gyakorlatban viszont ennel bonyolultabb a helyzet, egyreszt az olvasast nem replikalod, masreszt SAN-on nincs mese, ha jon az I/O req, azt ki kell szolgalni. Replikacional viszont csalhatsz: pl. irhatod a cuccot eloszor mindharom gepen SSD-re, es utana nagy egybefuggo blokkokban a diszkekre, kaphat a tavoli node-okon alacsonyabb prioritast (ha van kapacitas, szinkron, ha nincs, aszinkron <1s RPO-val), osszevarhatsz a lokalis node-on tobb I/O-t amig konzisztens allapotba nem kerul, szelsoseges esetekben irhatod a cucc felet erre, masik felet arra, es ha lecseng a terheles, akkor kiegyenlited, stb.
Nyilvan nem allitom, hogy ez most itt a vilagmegvaltas, ezek csak otletek, de egy sima RAID1-hez kepest egeszbiztosan csokkentheto az I/O terheles legalabb 20-30%-al.
"minel tobb szabad kapacitasod van, annal tobb gepet tudsz eladni"
Ennek csak az egyik modja az, hogy leveszel valamilyen feladatot a gepekrol. A masik modja, hogy egyszeruen tobb gepet veszel.
"a bovulesek soran boven behozza az arat"
A bovulessel van a legnagyobb baj. Indulaskor a nulla terhelesre is venned kell egy urraketat, aztan amig el nem ered a normalis kapacitasat, addig csak amortizalodik, fogyasztja a villanyt, es foglalja a helyet a rackben. Aztan amikor kinovod, akkor ki kell rakni, venni helyette egy nagyobb urraketat, es minden kezdodik elolrol.
"Raadasul az uj storage node betolasa se egy katasztrofalis dolog"
Nono, az a storage, amibe csak igy node-okat (kontrollert) tudsz beletolni, az egy kb. ertelmezhetetlen arkategoria. Talan a symmetrix tud ilyet...
"Plusz altalaban a storage node-k parban szinkronizaltak ... barmikor ossze lehet rakni egy atmeneti gepet, amibe betolod a winyot es zorog tovabb a felho"
Na, ez viszont nem (az a) storage.
--
"You're NOT paranoid, we really are out to get you!"
Szerintem azt mondja, hogy minden node adata rajta és a rá következőn találhatóak meg, azaz minden csak és kizárólag két node-on. Az első node adatai az első és második node-on, a második saját adatai a második és harmadik node-on, és így tovább, az utolsóé mag önmagán és az elsőn.
Ebben a felállásban ha kiesik egy node, akkor a következő át tudja venni a szerepét - igaz, hogy az őt megelőzőnek nem lesz replikája, azaz ott sérül az üzembiztonság. Ha meg az 1. node-ról mondjuk a 4. node-ra kell mozgatni egy vm-et, akkor azt a replikációs "gyűrű" megkerülésével történő másolással lehet, ami időben messze több, mint akár egy iscsi eszközt máshova csatolni, akár egy NFS-en eleve látható konfig alapján a megfelelő node-on elindítani a vm-et, mindenféle másolgatás nélkül.
Az nfs-szervert persze lehet drbd-vel duplikálni, hogy ha megpusztul, akkor a másik át tudja venni a szerepét.
Nézzétek el nekem, de nagyon nem ismerem HP ML110 G szériájú szervereket, viszont lenne 1-2 kérdésem vele kapcsolatban:
A célpont egy HP ML110 G6 X3430 lenne, debiannal virtualizálásra használnánk(xen) az egyik kisebb vállalatunknál. Az anyagi lehetőségek eléggé kötöttek, ezért is szemeltem ki ezt(br. 160e ft).
- A debian squeeze alapból lekezel minden hardware-t(gyanítom, igen) vagy kell valamit mókolni esetleg?
- A hardware-s raid megeszik akármilyen sata hdd-t vagy csak a hp által dedikáltakat?
- Tudom managelni a hardveres raid-et konzol alól valamivel(ne kelljen leállítani a gépet, hogy a raid kártya bios-át elérjem)? Mivel látom, hogy nem hot-swap-os így cserénél értelemszerűen tudom, hogy le kell állítani, viszont infót szeretnék leállítás nélkül is kapni az egyes hdd-k állapotáról.
ML110 Gx-nél azért annak a HW RAID-nak utánna néznék :) Ha nem veszel hozzá kártyát, akkor alaplapon csak Fake RAID van.
- Debian 5.0/6.0-val nem lesz HW gondod
- SATA diszket bármilyet tehetsz bele, HP is csak átcimkéz, most éppen seagate-eket.
- ha rendes HW RAID kártyát veszel, akkor mindegyik ismerthez van CLI, ha fake raid akkor általában virt. OS-ok nem (XenServer, VMware, etc.) is fogják RAID-nak látni, tákolni kell és soft raid lesz, de ahhoz is van "cli" (mdadm)
Megmondom őszintén nekem is gyanús az a raid, ezért kérdeztem meg itt. Az iponon olvastam egy hozzászólást és ott említette a srác, hogy tartalmaz egy P212 6Gb SAS/SATA hardveres raid vezérlőt 256MB cache memóriával és BBWC akkumulátorral.
Itt ni: http://www.ipon.hu/webshop/product/_hp_proliant_ml110_g6_1_x_x3430_4700…
igen, ebben a PN-ben van raid vezérlő,cciss pontosabban hpsa driver támogatja is.
ps: kíváncsi lennék, hogy valaki próbálta-e már a CCISS helyett a HPSA-t és ha igen, pozítív tapasztalata van-e?
(főképpen E200 / P400 ügyben érdekelne)
Bar a G6-ost nem neztem reszletesen, de a korabbi ML110G-k kellemetlen pontja a ram, ami nem tul eljterjedt tipus, igy meg Kingstonban is sulyos arban van a bovites, raadasul 4 slot van benne max.
nem hiszem, hogy ilyen gépben túl népszerű lenne a 4x2G-nél nagyobb memória - aki 16G-t akar az már inkább "normális" vasat vesz szerintem.
a 2G memória modul bele ~12-13e+Áfa áron van, HP-ból. szerintem a 3xx szériába sem olcsóbb a RAM...
Igen, 8GB a max 4 slotban 2GB-os modulok. http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&c…
Árajánlatot még most fogok kapni rá.
hát 8gb ramba olyan rettentő sok virtuális gépet ugye nem fogsz belerakni...
az ML110-es mint 100k HUF, 1utas gépbe? ne röhögtess már, hogy rettentő sok virtuál gépet akarsz belerakni...
Nem is cél rettentő sok virtuális gépet belerakni. De azért az a 7,5GB elég sok mindenre elég, ha az ember fia okosan gazdálkodik vele.
jaja, majdnem masfel VM elmegy vele! :)
Nem Java hostingra kell :-)
--
Oda ahova nekünk kell, bőven elég ez hidd el. :)
Van -e barmilyen meresed ami bizonyitja, hogy HW raidnek manapsag van letjogosultsaga (ar/)teljeseitmeny szempontbol ?
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
Pont ezért kérdeztem meg másokat is, hátha van valakinek tapasztalata ezzel a szerverrel illetve a benne lévő hw-raid-el kapcsolatban. Megmondom neked őszintén, hogy nem a hw-raid miatt esett a választásom erre, de ha már adják hozzá, csak ki akarom próbálni.
Egyébként meg van, kamera rendszerek terén(a cégnél nem nekem ez a feladatom, csak besegítettem). Amíg egy adott konfiguráció sw-raid-el max 16 ip kamerát(vga,1Mpx,2Mpx) tud kiszolgálni(a kiszolgálás azt jelenti, hogy a biztonsági szolgálat real time megfigyelésre vagy visszakeresésre használja) addig hw-raid-el ez 64db. Hozzáteszem egyedül itt használunk hw-raid-et, minden máshol soft-raid van(ez már bevált, bizonyított). Én is tartok kicsit a hw-raid rugalmasságától(mivel nem ismerem), ugye soft-raidnél kikapja az ember a diszkeket akár egy másik gépben pedig összeállítja. Itt pedig gondolom csak az adott típusú raid vezérlő képes összeállítani/szinkronizálni a diszkeket.