Szerverek, előzetes tervezés
Adva van egy nagyobb projekt, tervezési fázisban. Befektetőt szeretnénk hozzá találni, ehhez viszont előre, a lehetőségekhez mérten pontosan becsülni kellene a költségeket. Megvan, hogy mikor hány ember kell, mennyi a fizetésük, stb, stb. De a szervernél elakadtunk, mármint inkább elakadtam.
Biztosan kell egy fejlesztői szerver, amin majd futnak a tesztelések, szerintem erre egy 1 CPU-s (4 magos Xeon), 2-4 GB RAM-mal és SATA-s merevlemezzel bőven megfelel. Vagy még talán sok is :?
A gond az, hogy vhogy kalkulálnom kellene, mennyi és milyen vas kell majd az éles rendszer alá! Ezt hogyan becsülhetném, ha egyszer az alkalmazásról még csak azt tudjuk, mit kell csinálni, azt még nem, hogyan fogja csinálni? Ja, és hogy sokan fogják használni a világ különböző pontjain.
Eredetileg úgy gondoltuk, hogy minden szervert megduplázunk, ha az egyik kiesne, egy másik vegye át a helyét. De jobban végig gondolva, lehet érdemes lenne azt csinálni, hogy ha mondjuk van 10 gép a világ különböző pontján, akkor ezek mellé veszünk még 2-3 tartalékot, és azok figyelnék, kiesett-e vmelyik. De akkor ezeknek meg 5-5 adatbázissal kell szinkronban lenniük :-/
A másik, hogy most nem világos, mekkora költséget kell számolnom egy-egy szerver fenntartásához... Van itt áram, meg sávszél, meg hogy most állóházas vagy rack... Van ez ügyben tapasztalata vkinek? 30-40-50 ezer? Egyébként állóházasat vagy rack-et érdemes inkább?
Rengeteg kérdés, és nekem meg mondanom kéne vmit, hogy "blokkonként" 1 millió a szerverek és 100 ezer a fenntartásuk havonta. Kb.
■ Biztosan kell egy fejlesztői szerver, amin majd futnak a tesztelések, szerintem erre egy 1 CPU-s (4 magos Xeon), 2-4 GB RAM-mal és SATA-s merevlemezzel bőven megfelel. Vagy még talán sok is :?
A gond az, hogy vhogy kalkulálnom kellene, mennyi és milyen vas kell majd az éles rendszer alá! Ezt hogyan becsülhetném, ha egyszer az alkalmazásról még csak azt tudjuk, mit kell csinálni, azt még nem, hogyan fogja csinálni? Ja, és hogy sokan fogják használni a világ különböző pontjain.
Eredetileg úgy gondoltuk, hogy minden szervert megduplázunk, ha az egyik kiesne, egy másik vegye át a helyét. De jobban végig gondolva, lehet érdemes lenne azt csinálni, hogy ha mondjuk van 10 gép a világ különböző pontján, akkor ezek mellé veszünk még 2-3 tartalékot, és azok figyelnék, kiesett-e vmelyik. De akkor ezeknek meg 5-5 adatbázissal kell szinkronban lenniük :-/
A másik, hogy most nem világos, mekkora költséget kell számolnom egy-egy szerver fenntartásához... Van itt áram, meg sávszél, meg hogy most állóházas vagy rack... Van ez ügyben tapasztalata vkinek? 30-40-50 ezer? Egyébként állóházasat vagy rack-et érdemes inkább?
Rengeteg kérdés, és nekem meg mondanom kéne vmit, hogy "blokkonként" 1 millió a szerverek és 100 ezer a fenntartásuk havonta. Kb.
Nem tudod előre
Leteszed BUD Sztakiban a gépedet. Leteszed mondjuk Amerikában a másikat. A Sztakiban betáp-karbantartás van, áramszünet. Az US gép észreveszi, hogy nincs magyar gép. És mit csinál? Az IP-t nem tudja magára húzni, max át tudja tekerni a DNS-t, hogy most ne arra, hanem erre menjetek. Ennek viszont az a hátránya, hogy random szolgáltatók random DNS szerverei pont leszarják a TTL beállításodat, főleg ha alacsony, plusz ha load balanceolni is szeretnél, akkor ugye valami jól kitalált DNS szervert is kell üzemeltetned, persze úgyszintén failoverezve. És ugye ez ellen nem véd az sem, hogy két gépet teszel be egy helyre.
Ez ellen sajnos csak az véd, hogy saját dolgokat építesz ki pl áramforrás terén. Nyilván ez a mostani költségvetésetekbe kissé combos tétel lenne, szóval talán a legértelmesebb megoldás a DNS failover plusz rendszeres és alapos backupok plusz monitorozás (Ha Linux, akkor Nagios, Munin, Monit, SMS értesítés és hasonló finomságok. Rendszeres mentés, stb az már csak természetes ekkora projekthez.
Ha több infót szeretnél, akkor picit le kéne írnod, hogy miféle projektről van szó, mert vakon tervezni elég nehéz. :) A terhelés kérdést meg még inkább.
Szerk: ja és persze ha ilyet szeretnél, akkor a programozóknak nem kicsit érteniük kell az elosztott rendszerekhez, ezen valszeg még webstúdiókban megöregedett veteránok is elgondolkoznak. Bár valszeg erről Felhő lényegesen többet tud mondani, én ugyanis csak egy évet fejlesztettem PHP-ban ilyen környezetre (most meg rendszergazda vagyok egy ilyenben. :) )
amazon ecc
+1
Költség
Én havonta egy nem túl nagy hardverű vas üzemeltetésére kb 50e Ftot számoltam azzal együtt, hogy 2-3 évente cserélni kell a gépet is.
Előzetes tervezés
Hááát...
Ők ismerik a projektet?
Hmmm...
Egyelőre úgy képzelem el, hogy:
1. Fejlesztés ideje:
- 1 fejlesztői szerver (full DB ezen)
- AWS (S3 + EC2)
2. Béta teszt:
- 1 európai DB szerver (Az Amazon adatbázis szolgáltatása egyelőre nem tűnik használhatónak nekünk, bár még az is lehet, hogy jó lesz legalább részben, alább kifejtem...)
- AWS (S3 + EC2)
3. Éles üzem: Béta teszt függvényében talán:
- 2-2 saját DB szerver: EU, Ázsia, USA (1 éles, 1 tartalék)
- AWS (S3 + EC2) + GAE tartalék, ha leállna az Amazon (nem használnánk, csak a tárhely után kellene fizetni havonta)
Egyébként Pythonban fog történni a fejlesztés. Az adatok egy része nagyon gyakran és gyorsan változik. Ezeken bonyolultabb műveleteket is végrehajtunk. A többi adaton valszeg nem, így felmerült, hogy MySQL helyett "SQLite-ba" (gyorsabb, mint a MySQL) vagy Amazon SimpleDB-be kerülnének a "sima" adatok (ezeknek az is jónak tűnik), és a kényesebbekre végszükség esetén C++-ban íratnánk egy saját célszoftvert... Ott ugyanis tényleg gyorsan kell nagy mennyiségű adatot feldolgozni, folyamatosan. Persze lehet, hogy aztán kiderül, már verébre lövök ágyúval :D
A lényeg, hogy a kényes résznek valszeg kell(enek) majd a saját szerver(ek), a többinek viszont jó az AWS. A statikus tartalom szinte tuti, hogy oda fog felkerülni.
A fent vázolt esetben: 1 ("gyengébb fejlesztői") + 6 szerver kell, sok memóriával és gyors CPU-val, "pár" GB-os HDD-vel (akár SATA is jó, RAID-ben)
Ez így szerintetek jó és "reális" elképzelésnek tűnik? Feleslegesen túlbiztosított vagy éppen alul?
Technológia
Nem lehet ugyanis pl azt megmondani, hogy SQLite-al, MySQL-lel vagy egészen mással jársz jobban. A gyorsabb relatív fogalom, kérdés hogy pár millió adatnál is gyorsabb-e, stb. A rövid életű adatokra egyébként sem biztos, hogy a relációs adatbázis a legjobb tárolási forma, stb.
Szerintem, ismerkedj meg (vagy a rendszergazdádat ugraszd rá) a platformodnak megfelelő HA megoldásokra, nézz utána a hosting áraknak, hálózatoknak, stb. Anélkül nem fog menni. Húzzátok föl az egész kiválóságot virtuális gépek halmazában, teszteljetek, csináljatok performance teszteket, stb. aztán agyaljatok azon, hány gép kell.
Jogos minden észrevételed, de ... :)
Szóval ez úgy néz ki, hogy csinálunk egy előzetes kalkulációt, hogy az ötlet megvalósításához kell X összeg. Aztán ha ezt megkaptuk, akkor kezdjük el a projekt megvalósítását, emberek felvételét, és végül sorra kerül majd pár hónap múlva a rendszergazda is, akivel nyilván újra fogjuk gondolni a dolgot, de addigra már lesz béta verzió, lesz tapasztalat, és lehet min mérni.
Az a lényeg, hogy nekem írnom kell vmit az üzleti tervbe, hogy pl 10 millió/év < [szerver költség] < 30 millió/év . Aztán még vhogy indokolnom kell a két végletet, hogy miért gondolom azt, amit...
Ez egy bizonytalan, homályos becslés, de akkor is, kell két szám, már csak a nagyságrend miatt is. Hogy nem évi 20 000 Ft-ról van szó, de nem is 500 milliós tétel.
Eleve, 3 évre tervezni, elég vakmerő dolog. Elméletileg a befektetőnek az alap - kezdeti - rendszer felépítését kéne "fedeznie", a növekvő forgalomból adódó költség növekedést, ha minden jól megy, akkor fedezni fogják már a bevételek.
Nem tudsz
Az is egy koncepció lehet, hogy itthon vesztek sok nemzetközi sávszélt és Európát innen szolgáljátok ki, valahol USA-ban ugyanez oszt csókolom. Igen, aranyáron mérik, de legalább kézben tarthatóak a karbantartási feladatok. Két site-ot még nem olyan életveszélyes szinkronban tartani. Egyébként meg vegyetek CDN-t a statikus tartalmakra, az jó dolog és sok sávszélt megspórol.
Semmiképp ne úgy rakjátok oda a megrendelő / főnök elé, hogy ez az ár, hanem úgy, hogy ha ezt szeretnénk, akkor ennyi, ha ezt, akkor ennyi. Ne Te dönts, amikor igazából közöd se nagyon van a rendszergazdai oldalhoz, hacsak nem szeretnéd utána elvinni a balhét. Vegyetek föl egy elosztott webes rendszerekben jártas rendszergazdát. (Nem lesz olcsó.)
Ja és persze azt is tedd hozzá az árkalkulációdhoz, hogy mondjuk évente kétszer ki kell menni a külföldi clusterekhez és 3 évente cserélni kell a gépet (ld. amortizáció). Ennek fényében számold ki, hány gép bírja el a terhelést, számolj bele egy pár HA megoldást, backupot és mondj egy számot. Lehetőleg valami komolyabb rackes vassal számolva. (8 magos 2005-ös Intelek RMM modullal rulez, valahol 1 misi per darab ha jól tudom.)
Egyébként szigorúan a magánvéleményem, hogy az ilyen jellegű projektek, hogy előbb tudjuk, milyen technológiát és szervert használunk, mint hogy lennének fejlesztőink, bebukás-veszélyesek. Barmi nehéz manapság a szakmájához jól értő, egy ilyen elosztott rendszerrel elbírni képes fejlesztőt találni. Nem elég fölvenni néhány webprogramozót, mert ez egészen új feladatokat hoz.
Off: örülök, hogy nem csak én szenvedek alvászavarban. :D
Miért pont CDN?
Külföldi szerverek:
A jelenlegi koncepció szerint a külföldi szervereket hosting szolgáltatóktól bérelnénk, (fizikai) karbantartással együtt. Ez nem feltétlenül drágább, mint ha nekünk kéne utazgatni és karbantartani őket, a bérlés 3 évre szól általában, stb, stb... Persze lehet, hogy később mégis veszünk sajátot és utazgatni fogunk :)
De jelenleg úgy látom - szóljatok ha rosszul gondolom -, a bérlés bár hosszabb távon lehet, drágább, mégis kényelmesebb megoldás. Van más különbség is?
Egyébként nem csak itt kérdezgetek, folyamatosan olvasok is a technológiákról, még mielőtt vki szóvá tenné, hogy "google" :D
Ezt is lehet
van már SLA
S3 vs CDN
Egy CDN ezzel szemben igyekszik a felhasználhoz közel eső szerverről kiszolgálni a kérést. Vannak origin szerverek, te ide teszed fel a cuccod (vagy épp te vagy az origin), és az edge-ek innen rángatják le kérés esetén a cuccot, és cache-elik a megadott ttlnek megfelelően.
Van az Amazonnak is már CDN-je: CloudFront, az S3-on található cuccaid elérhetővé tudod tenni ezen keresztül, jelenleg USA-ban, Európában és Ázsiában vannak edge-ek.
konkrétum helyett jelleg
Teszt
A teszt alfa verziója
Vannak szobák (~100 000). A szobákban emberek vannak (~200/szoba). A szobában lévő embereknek vannak tulajdonságaik (~20 tulajdonság/ember) és azok hatással vannak egymásra. A szobákban lévő emberek néha átmennek más szobákba, találkoznak a másik emberrel és ettől mindkét félnek változik a tulajdonsága. Egyfajta szimulátorról van szó.
Tehát végső esetben ez egy 20 millió soros tábla (100 ezer szoba x 200 ember/szoba), amit ha nem is tized másodpercenként, de gyakran be kell járni (~10s) és a változásokat végrehajtani. Csak az egymáshoz közel lévő emberek vannak egymásra hatással.
A tesztkörnyezet: WinXP, MySQL 5.0.41, 2.2 GHz-es Intel Core Duo E2200, 2 GB RAM, vmi basic merevlemez...
Namost, a tesztben először generáltam egy 14 000 soros táblát, és ezen futtattam egy egyszerűsített szimulációt (5 UPDATE, ebből az egyikben "join"-oltam önmagával a táblát). 0,86 s. Felduzzasztottam a táblát 115 ezer sorra, a szimuláció ideje felugrott 98,23 s-ra :-/ Tehát több, mint 100-szorosra, ami érthető is. Kisebb optimalizálások után ezt az értéket le tudtam tornászni 55 s-ra. A szűk keresztmetszet egyébként a merevlemez volt, mert a proci "mysql-es" magja kb 60%-on dolgozott.
Ez pedig elég rossz eredmény. Jött olyan ötlet, hogy minden szoba legyen külön tábla, hátha attól gyorsabb lesz, van is benne vmi, mert most valszeg azért nő négyzetesen (10x annyi adat, 100x annyi idő), mert az "egymásra hatásnál" mindenkit összevet mindenkivel. Gondolom én. De a más szobában lévőket nem kell összevetni, így sztem átváltana lineáris növekedésbe, de elég "csúnya" megoldásnak tűnik nekem, hogy lesz egy adatbázis, amiben van 100 000 tábla. Persze ezek szétoszthatók gépenként. Másrészt az se szimpi, hogy kb 6 MB adatról van szó, az innoDB fájlja mégis 120 MB-ra hízott a sok indextől... De ekkor jött megint az az ötletem, hogy ezeket a műveleteket nem adatbázisban végeznénk, hanem C-ben vagy Assembly-ben :D íratnánk rá egy célprogramot. Az a 20 tulajdonság kb 50 byte. Bedobáljuk a memóriába őket, a szobák szerint rendezve és ott bejárjuk őket. Van még egy érdekesség, ami miatt megoldható, hogy mondjuk óránként írjuk csak ki a memória tartalmát, esetleges leállás miatt ugyanis nem fog adatveszteséget okozni (az adatok visszaállíthatók maradnak, ebbe most nem megyek bele miért is). Kb 1 GB adatról van szó így. Ezt szét lehet osztani gépek között, mindegyik kap mondjuk 10 000 szobát (100 MB), nem hiszem, hogy ne végeznének 1 "körrel" tized másodpercek alatt, szóval a 10 s-os határon belül lennénk bőven.
Az Amazon szolgáltatása egyre szimpatikusabbnak tűnik. S3-ban tárolom a "szobákat", mondjuk 10 MB-os "csomagokban", és ahogy nő a rendszer, úgy ezeket küldözgetem ki EC2-es szervereknek, hogy "játszadozzanak" velük.
Vélemény a gondolatmenettel kapcsolatban?
Ez így nem megy
mmorpgés társai
Megnéznék néhány tesztlekérdezésedet, tábládat, hátha az indexekkel van baj (elvileg megfelelő indexekkel megoldható a soksok tábláshoz hasonló sebesség).
Az, hogy leválasztod a szimulációhoz nem szükséges adatokat (azaz egy másik táblába teszed) DB esetén is sebességnövekedést eredményezhet.
A sharding-ot szokták még alkalmazni nagyonnagyon sok adat esetén. Azaz nem minden szoba külön tábla, de egy DB szerveren mondjuk csak 1000 szobát tárolsz (ahol valószínűbb, hogy lesz átjárás).
A hasonlat jó
Cserébe itt azért nem is kell olyan gyorsan számolgatni. Bár igazság szerint nem tudom, hogy ott hogyan kell számolgatni és mit, ezt végig kéne gondolnom :? :D
Köszönöm a tanácsokat, C programozó felírva.
Objektumok
ec2
Mint ilyen az adatbázis szervereid is lehetnek ugyanúgy az ec2-ben erre összeállított rendszerek.
Ha ez így van, akkor összehasonlíthatatlanul jobb megoldás, mint az, hogy több kontinensen cégek tucatjaival legyetek kapcsolatban.