saját felhő jellegű irodai szerverpark

Közösségi kerekasztal

Ötletelni kezdtem, hogyan lehetne olyan kicsi szerverparkot építeni, ami jó egyensúly a viszonylag olcsó, megbízható és gyors között, és elmegy egy irodának, ahol elég a 99%-os rendelkezésre állás. Sokszor fogom használni a viszonylag szót, mert én is tudom, hogy határ a csillagos ég.

Az alapfelállás legyen mondjuk 15 "szerver" (ne menjünk bele, hogy ki mit hív annak, vannak szintek), szerintem elég sok helyen jellemzőek az ilyesmi számok. Az a bajom, hogy nagyon heterogén szerverek szoktak összejönni, és a redundanciára csak nagyon speciális, leginkább alkalmazás szintű módszerek a jellemzőek. Pl. az X gép az apache webszerver, az Y gép az Exchange szerver, tök más a hardver kiépítésük, az X gép redundanciája valami Z load balancer szerverrel van elintézve, az Exchange-hez egy DAG van, csak egy darab virtuális hoszt szerver van, amin fut néhány developer szerver, stb. Ilyen kis számosságú szerverpark esetén túl nagy kiadás lenne mindenből rendesen kettőt beállítani, egyszerre gyorsat is meg még inkább. Marad az, hogy vegyes lesz a rendszer, sok az SPOF, és ha valami elromlik, akkor van vele egy kis szívás, nehezen átpakolható egyik szolgáltatás a másik gépre. De a kis számosság miatt ez ritkán fordul elő, tehát még mindig jobban megéri így. A heterogén elrendezés miatt a terhelés is nagyon egyenetlen, sok gép nincs kihasználva, mások meg nagyon is.

Az jutott eszembe, hogy felhő jellegű megoldást egész olcsón meg lehetne építeni egész jóra. Mellőzzük a drága és jó enterprise megoldásokat, meg az automatikus failovert, meg minden ilyesmit. Nem kell kinevetni, egyszerűen nem mindenki engedheti meg, hogy N darab milliós szervert bepakol, enterprise support, mittudomén, és no para, atomháborút is túlélünk. Ez most az összes többi embernek szól. Összesen az a minimum elvárás, hogy a kieső elemeket minimális szívással lehessen helyettesíteni, de még manuálisan, és teljes halál helyett inkább a teljesítmény degradálódásával még maradjon életben a rendszer. Talán viszonylag szemét alapanyagból is lehet viszonylag jó rendszert összerakni, ha okosan csináljuk, volt már rá példa a történelem során.

Elsőként meg kell oldani a storage-ot. 15 oprendszer elfér 500 GB-on, és mondjuk 3 TB nagyon kritikus adattal számolva 4 TB az adat, RAID1-ben még a leggagyibb 100 ezer forintos PC is simán elviszi 4x2 TB SATA diszkkel. Ebből a storage gépből vegyünk két egyformát, és csináljunk egy blokk szintű szinkront. Ez eddig olcsó. Ha egyik elromlik, átállunk a másikra, pár klikk, ez már viszonylag megbízhatónak is elmegy. Mitől lesz viszonylag gyors? Van olyan szoftveres megoldás, amivel a két storage gép párhuzamosan elosztja a terhelést? Vessünk be RAID0-t és/vagy több kisebb diszket? Dobjunk be 1-2 SSD-t cache-nek? Sok olcsó RAM? Ja és persze a storage jellegű gépből kell egy 3. is, kicsit nagyobb tárhellyel, viszont kisebb redundanciával, pl. RAID5, backupnak. Ahogy halad előre az idő, jelennek meg a 3, 4, X TB-os diszkek, tehát ha nincsenek extra igények, akkor a mindenkor aktuális desktop hardverrel bővíthető még sokáig.

Aztán vegyünk 3 db PC-t, viszonylag jobb számítási teljesítménnyel és RAM-mal. Nem kell ma már hozzá óriási befektetés, hogy egyszerűbb alaplapba sokmagos processzort meg 32 GB RAM-ot belepakoljunk. Darabonként 200 ezer forint, és már lehet sokat mondtam. Mind a hármon virtualizálunk. Manuálisan elosztjuk, hogy az elsőn fut 5 gép, a másodikon is 5, a harmadikon is 5. Megvan mind a 15 "szerver", több gép nem lesz, tehát eddig ez is olcsó. Ha az egyik megdöglik, akkor a futó gépeket elosztjuk a másik kettőn, csak 50-50% extra terhelés, és másnapra veszünk egy újat. A kis számosság és viszonylag alacsony elvárt rendelkezésre állás miatt ez kivárható időtartam. A storage ugyanaz a gépek alatt, tehát semmiből se tart átmigrálni egy virtuális gépet. Kicsit lassabban, de el fog döcögni a rendszer, esetleg 1-2 kevésbé használt gépet leállítunk. Ha tud ilyet mondjuk az OpenStack vagy a VMWare vagy bármi, akkor felőlem automatikus is lehet a failover, de bőven elég a manuális is. Ez lefedi a megbízhatóságot. A gyorsaság meg itt kevésbé problémás, hacsak nem csillagászati kutatásokat végzünk, a processzorok sokat fognak unatkozni, és a RAM-ok is inkább cache-elt adatokkal lesznek tele.

Túl sok tapasztalatom ilyen téren nincs, de nekem érzésre úgy tűnik, hogy ez nem kerül sokkal többe, mint az eredeti szerverpark, viszont sokkal homogénebb, a döglött hardverek kiváltása sokkal egyszerűbb, és a teljesítmény is sokkal jobban el van osztva. Szerintetek működhet egy ilyen? További ötletek?

( psc | 2013. 03. 30., szo – 00:18 )

vegyel egy entry-level server-t storage-nek, bele sas hba-t, tomd meg sas lemezzel, vegyel bele 10ge ethernet kartyat (lemezek nelkul tartasz kb. 300-400k -nal), vegyel egy erosebb server-t virtualizacios host-nak, bele 10ge ethernet (kb. szinten 300-400k), osszekotod, iscsi, vigan elfut 15 virtualizalt server, s tudsz snapshotolni, stb.
ha ketto storage-t akarsz, akkor veszel megegy gepet, abba is 10ge kartya, es osszedugod a storage-vel.

Ez így összesen két (vagy három) gép nem? Ő pedig kapásból ötöt tudna venni közel ennyiért. Bár az ő megoldása hardver szinten kevésbé megbízható, de több vasra van szétosztva, és könnyen pótolható, míg a te megoldásodnál ha valamilyen okból kifolyólag meghal a hardver, akkor a csere nehezebb is, drágább is, és nincsen addig semmi, ami helyettesítse.

Minőségi PC alkatrészekből is lehet összerakni ilyet, ha kicsi a rászánható összeg, de kell az auto/manual fail-over, akkor szerintem jó lehet az OP megközelítése.

Szerintem meg nem ilyen fekete-fehér a dolog. Google is sokáig eljutott olcsó diszkekkel, persze nem akarom a kis irodákat hozzájuk hasonlítani. Habár ők is nagyon lentről indultak. Sok lúd disznót győz. Ha sok olcsó diszked van, és egy okos rendszert építesz rá, akkor kellő megbízhatóságot és teljesítményt tudsz elérni, csak a rendszer és a számok kérdése.

--

Attol ,hogy valami a Googlenek jo neked nem biztos ,hogy megfelelo lesz egyreszt nekik mondjuk van 10k+ szerveruk neked meg mondjuk harom, ha kiesik par szaz hardver hiba miatt nem veszik eszre. Egy elosztott infrastrukturan mas keppen kell kezelni a dolgokat.Az ,hogy ok SATA diskeket hasznalnak az Te szempontbol lenyegtelen mert naluk nem egy gepen fog jelentkezni az I/O mondjuk nalad nagyvaloszinuseggel igen.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

Így van! A medve nem játék a sata nem merevlemez. :) ...legalábbis szerver esetén. ;)

Annó mikor a főnök marha drága HP szervere feldobta a talpát és 24 óra volt bele az új alaplap, nos mikor lejárt a gar ismét és az idő is eljárt felette, javasoltam, hogy a helyett hogy ismét 1 misiért vesz valami brand szervert, 600-ért vegyünk inkább kettőt amit összerakok. ...és ha beszarik, akkor csak áttolom a diszkeket a másikba és megyünk tovább. Annyi leállás belefér, de 24 óra nem... ...legalábbis hétköznap. (ebbe az árba már egy tartalék DISK-is volt)
Mondjuk ez azóta is megy, tovább bírja mint annó a Proliant de nem akarok most bullshitelni mert ennyiből nem vonnék le következtetést, annál is inkább mert van ahol még egy 350 G3 is hibamenetesen megy.

Rózsár Gábor (muszashi)

Ne dőlj be a GOOG propaganda meséinek. BS.

Marketing 101, hogy kell egy alázatos, megható kedves sztori a kezdetekről amivel könnyű azonosulni (lásd garázsmítoszok: hp, aapl, ebay stb.). Amikor ezek nem színtiszta hazugságok, akkor is legfeljebb csak részigazságokat tartalmaznak.

egyébként: már mondták itt, hogy az ECC lényegében desktop árban van és nem érdemes kihagyni; ahogyan az amd opteron is egy költséghatékony platform.

Nekem mindegy, ki mit csinál. De 10ge nélkül nélkül lassú lesz a storage, egy 10ge kártya pedig 135-150k HUFba kerül.
Ezen kívül érdemes xeon processzorokat használni, azért nagyon nem mindegy.
A sata meg nem merevlemez. Storage gépet, amit 15 vm fog használni, meg ki tudja hány user, illene azért sas lemezekre tenni. Nagyon nem mindegy.

( Elbandi v | 2013. 03. 30., szo – 01:55 )

ha a lowcost a cel akkor:
2 gep sok diskel, drbd, felette iscsi/aoe.
3 gep vpsnek proxmox-al clusterbe kotve.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

hat hogy a xenvm mit csinal a drbd-vel azt nemtudom, de itten fut egy ketnode-os proxmox, 1.5 ev alatt semmi gond nemvolt (kop-kop). hat megis szetesne a drbd, hat b*sszasas: mivel nem automatan vandorolnak a gepek es a pve gondoskodik arrol hogy adott lv csak egyik oldalon legyen aktiv, igy eleg csak a lv-ket atsyncelni egyhelyre, utana drbd fejbeverheti a masik node-ot...

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( bognarattila | 2013. 03. 30., szo – 22:49 )

Konkrétum nélkül nehéz konkrétat javasolni. Kb mennyi a költségvetés? 500e? 1m? 3m? ...
Normális tervezéshez ismerni kellene a szolgáltatásokat tételesen SLA és erőforrás igénnyel stb.

Az is simán járható, hogy veszel egy darab szervert, mellé mindenből egy csere alkatrészt (ami nem redundáns, lemezből akár többet is). Ha elromlik valami és leáll, azt az egyet (például alaplap) kicseréled. Ugyanez működhet 2 vagy 3 szerverrel, akár valamilyen replikációval közöttük kritikusabb alkalmazások esetén.
SATA lemez (pláne csak 4 darab) biztosan kevés lesz.
Ennél egyszerűbb nem nagyon van, de ez esetben is át kell részletesen gondolni.

Ha tároló megoldást is szeretnél (ami redundáns és több szerver által elérhető), akkor vegyél erre a célra készült eszközt. Ha magad szeretnél ilyet csinálni, szerintem inkább szívás lesz belőle + esetleg feleslegesen megvett hardver, én nem tölteném erre az időmet.

Biztonsági mentésről (független tárhelyre) mindenképpen kell gondoskodni. Erre alkalmas lehet SATA lemez, mennyisége leginkább attól függ, hogy milyen jellegűek az adatok (mennyire tömöríthető/deduplikálható), illetve milyen visszatartás szükséges.

( HKaresz | 2013. 03. 30., szo – 23:35 )

A Hyper-V nem tud automatikus loadbalance-ot? (+sub)

( mrmartin v | 2013. 03. 31., v – 11:15 )

OpenStack esetleg? Ha már felhő...

( hackac | 2013. 03. 31., v – 11:55 )

2-3 host, vsphere essentials plus. Local diszkekből lesz redundáns storage (virtuális storage appliance van ebben a verzióban mar), HA is megoldott. Menteshez VMDR.
Ha komolyabb virtuális storage appliance kellene, akkor meg HP Storevirtual (leánykori néven LeftHand).
Erre van támogatások, redundáns, nem osszegányolt.

( wpeople v | 2013. 03. 31., v – 17:44 )

vannak már nagyon jópofa "miniblade" rendszerek, ahol egy (redundáns tápot adó) házba 4-8-több
gépet teszel. Megoldástól függően lehet a gépeknek saját (1-2-3) HDDje amiről futhat az alaprendszer, de természetesen bootolhat netről is.
Ha jól láttam, talán Asus kínálja a legolcsóbb (nem full kiépítésű) megoldást, azaz indulhatsz mondjuk a 4ből 2 géppel egész emberi áron. Emlékeim szerint SuperMicro megoldása akkor jóáras, ha indulásból megveszed az összes blade-t bele.

közös storage: ha nem ipariból veszed, hanem összerakod, akkor a titka a dolognak a sok jó lemez, (SAS v legalább midline), és jó raid vezérlő sok cache-el (1G). iSCSI-n kiadod az imageket, itt sajnos RAM-ot cache-re nem nagyon tudod használni.

Azt neked kell tudnod, hogy mekkora sebességet szeretnél elérni háttértárhoz a virtualizációt biztosító gépeknél. Ha 1G elég (~100mbyte/s - viszont a beépített vinyóknál esélyesen jóval több IO), akkor OK, ha nem, akkor drága lesz (főleg a 10G switch...)

ps: Mikrotik jön ki új CCR(/CCS) eszközzel, ami már tud 2db SFP+ -t, így egész olcsón megoldható lesz a 10G uplink, 1G downlink.

ugyan így vagyok, a sebesseg mondjuk nalam nem is igen akart noni, csak picit, 50-60 Mb/sec-rol felment 70-80 Mb/sec-re, s egyelnetesen volt elosztva a ket kartya kozott. de mar ehhez is az esxi-t parancssorbol kellett utasitani, hogy 4 IOPS-onkent round-robinolja a kartyat kozott a forgalmat.
inkabb vettunk ketto 10ge kartyat meg koze optikai kabelt, azota nincs gond :)

(mondjuk nalunk nem bondingolva volt, hanem iscsi multipath volt ket path-on.)

En kiserleteztem sokat iscsi-vel, 1G-n meg 10ge-n.
1G-n nem igazán ment valójában 50-60 MB/sec fölé...
10ge-nél meg a merevlemeztömb a szűk keresztmetszet. :) (4x15k rpm SAS, raidz)
A 10ge nagyon sokkal-sokkal-sokkal jobb, mint 1G-n. A latency is alacsony, IOPS probléma sincs, távolról se.
Viszont a 10ge átvitelhez kell processzor is. Egy kozepes Xeon 20%-át képes megenni.

( kisg v | 2013. 03. 31., v – 23:44 )

Volt nem olyan rég NagyZ storage építős topicja, onnan pár idevágó adalék:

- Xeon E3 desktop árban van, és támogat ECC RAM-ot, ami szintén nem sokkal drágább mint a nem-ECC. Meg lehet nézni, pl. cpuboss.com-on ár/teljesítményben ugyanott van az E3-1240v2 mint egy i7-3770k. Ezt belerakod egy jobb PC házba, és kész is a költséghatékony szerver. Ez alá a jelenlegi árak mellett nem érdemes menni.

- az E3 hátránya, hogy max. 32GB RAM-ot támogat, kérdés, hogy ez korlát-e.

- az E5-16xx már 375GB RAM-ot támogat, de itt már drágább a lap és a CPU is. Még mindig 1 CPUs világ, de ha jól rémlik van több mint 4 magos változata.

- 10Gb ethernet helyett az InfiniBand-ot is érdemes megfontolni, mert olcsóbbra kijöhet, Linux, Vmware, sőt Windows is támogatja.

- Storagenél érdemes megfontolni a drága RAID kontroller helyett ZFS + tükrözött SSD felállást cache-nek (ZIL + L2ARC). ZFS-t támogat 3 OS is: Solaris származékok, FreeBSD, Linux. A Linux port (zfsonlinux.org) elvileg a legkevésbé kiforrott, a gyakorlatban nálunk már egy ideje gond nélkül megy, és most már a fejlesztők is "használatra kész"-nek nyilvánították.

"- 10Gb ethernet helyett az InfiniBand-ot is érdemes megfontolni, mert olcsóbbra kijöhet, Linux, Vmware, sőt Windows is támogatja.

- Storagenél érdemes megfontolni a drága RAID kontroller helyett ZFS + tükrözött SSD felállást cache-nek (ZIL + L2ARC). ZFS-t támogat 3 OS is: Solaris származékok, FreeBSD, Linux. A Linux port (zfsonlinux.org) elvileg a legkevésbé kiforrott, a gyakorlatban nálunk már egy ideje gond nélkül megy, és most már a fejlesztők is "használatra kész"-nek nyilvánították."

e ketto uti egymast....
ha zfs-t hasznalsz, hogyan fogod az infinibandot rendes infinibandkent hasznalni (nem pedig ipoverinfiniband vagy hasnolokkal)?

Amikor "cloud"-ról van szó, akkor implicite ott kéne legyen az is, hogy olcsó.
Namost a 10GBit meg a SAS az nem olcsó.
Inkább vennék 4 db Dell T110-II-t mondjuk össz 1M-ért, és akkor darabján elfut a 3-4 vm, local storage-el, mint akármiből egyet-kettőt ugyanennyiért. Horizontal vs vertical scaling.

--
Gábriel Ákos
http://i-logic.hu

Akkor már csak azt kéne megindokolni, hogy a google és az amazon vajon miért teljesen kommersz cuccokból építi a felhőjét? Hülyék mind?
Persze lehet brand, drága vasakból is venni egy bizonyos gépparkot, és azon felhőszoftvert futtatni, és még működni is fog, csak akkor valahol az eredeti célt hibázzuk el.
A cloudban a szoftveresen megoldott redundancia pont azért van benne, hogy az olcsó hardveren is lehetővé tegye azt a működész amit a drága vas hardverből old meg. Három gépre tervezni cloudot az marhaság, az nem cloud. Oké, hárommal lehet indulni, mert onnantól értelmezhető a redundancia, de alapvetően nem erről szól ez a technológia.

Kicsit olyan ez, mint Toyota Priust tuningolni gyorsulásira, vagy Ferrarira vonóhorgot tenni, hogy el tudd húzni utánfutón a csomagot.

--
Gábriel Ákos
http://i-logic.hu

Szűklátókörűség azt gondolni, hogy csak a Google és az Amazon testesíti meg a felhő definícióját. Más igények merülhetnek fel egy private cloudban(de akár publicban is), ahol esetleg nem kommersz cuccokra akarnak építkezni, igényük van beszállítói támogatásra, egyéb olyan szolgáltatásokra amiket a kommersz cuccokra építkezők nem adnak meg. Ilyen alap dolgok is felmerülhetnek egy felhőnél, nem csak az árcédula. A felhő hol szólt csak arról, hogy olcsó gépekre olcsó szoftvert tegyünk?

Miert gondolod, h kommersz cuccokbol epitik fel? Ott a google meg az amazon a brand. Ha nalad (nalatok) is meglenne az a tudas, hazon belul, mint ami megvan naluk, akkor te is megteheted, h a piacrol egyenkent osszevalogatod az elemeket, sot fejleszted, ill. egyedileg neked gyartjak.

Nalam nincs, igy nem hiszem magamrol, h szervert tudok epiteni.

tompos

Én csak a másik topicban összegyűlt infókból válogattam ki néhányat, amik szerintem hasznosak. Sajnos még nincs InfiniBand nálunk (ZFS van), csak tervezés alatt, és ezért az alábbiak csak olvasmányélményekre támaszkodnak:

- SRP-t mindegyik felsorolt OS támogatja, ZVolokat ki lehet ajánlani azon keresztül a VM-eknek
- Ha Linux a VM host (KVM vagy Xen), akkor játszik még NFS over RDMA is, sajnos tudtommal se VMware, se Windows nem támogatja.

ha jól látom, akkor 4X dualport infiniband kártya ~200EUR és ~100EUR a kábel.
tehát 2 gép összekötése (1 porton) ~500EUR - ez kb annyi, mint 1db 10G kártya. (persze előbbi használt utóbbi új)

gyanítom megoldható egy olyan konfig is, hogy 2 db storage DRBD-vel (S1 és S2) valamint 2db virtualizációt végző gép (V1 és V2) van összekötve kvázi gyűrűbe.
Azt nem tudom, h IPoInfiniband támogat-e több fizikai kártyát egy gépben.

ps: használ(t) valaki ilyet? (úgyértem IPoverInfiniband)

( kisg v | 2013. 04. 02., k – 15:47 )

Opteron vs Xeon alkérdés

Mivel a legutóbbi Opteronos gép, ami megfordult a környéken még egy Sun Fire X2100 M2 volt, érdekelne, hogy a mostani felhozatalból ki mit javasol a következő kategóriákban:

1. Intel S1200BTL + Xeon E3-1240v2 -vel ekvivalens rendszer - ilyenből több is ketyeg nálunk, alapvetően elégedettek vagyunk.

2. Xeon E5-16xx-szel ekvivalens rendszer (itt Intel alaplap javaslat is érdekel, eddig nem találtam olyan igazán szimpatikusat).

Mindegyik esetben fontos, hogy dedikált menedzsment port IP-KVM-mel legyen rajta (vagy olcsón elérhető legyen upgrade kártya, mint az S1200BTL-nél).

A Supermicronál mindig elbizonytalanít az 1 év garancia.

Tud valaki jó AMD vs Intel benchmark siteot? A szokásos szintetikus benchmarkok nem izgatnak különösebben, ami érdekel:
- virtualizálás overheadje vSphere, Xen és KVM-en az Intelekkel összevetve
- milyen gyorsan fordít (Linux kernel, Android ... stb.)

nyilván azonos storage backend és memória konfiguráció mellett.

Nos mi egy elég komoly WP alapú blog oldalcsomagot hajtunk egy kétprocis 16G memóval szerelt 42xx-es (2x8 szál) Supermicro-s gépen és remekül megy már 1 éve. Load az simán 2-3 körüli és csúcsidőben bőven 200Mbit főlé megy a kimenő forgalom. A webszerver az lighttpd+php-fpm+xcache és nyilván a WP-re is odafigyeltek, mert ekkora forgalommal és egy rosszul belőtt site-al tetszőleges gép fektethető. :) A masina jóval olcsóbb volt, mint egy inteles csodagép és egyáltalán nem csalódtunk, sőt...

Azt is hozzá kell tegyem, hogy nekünk az Opteronos szerverekkel általában jó a tapasztalatunk. Ment SUN Fire X2100-as, X2200M2-es és DL385G1-es gépünk is hiba nélkül. Az X2200M2 és egy DL385G1 még mindíg megy, a DL385G1-es párját pedig eltettük tartaléknak, mert egyébként nincs baja.

A gari kérdésre csak azt tudom mondani, hogy olcsóbb plusz egy lapot eltenni, mint a jódrága brand supportért fizetni, ha a pénz számít.

Nagyon meglépődnék, hogy ha egy kisebb hazai vállalkozás (mondjuk SBS, Samba fileszerver vagy akár közepes virtualizációs) igényeit nem tudná lefedni egy vagy néhány single vagy dual socketes 42xx/43xx-es Opteron szerver. Az külön az Opteron mellett szól, hogy már single socketben is simán 64GB memóriát eszik, míg az E3-as szériánál 32GB a maximum.

A fejlesztok szerint nalunk a memoria savszelesseggel van a problema, a toredeket nem nyujtja, mint amit egy Intel proci. Ilyen formaban meg egy i7-es laptop is lefozi. Hiaba a sok mag es memoria, nem tudja kiszolgalni.

Az is igaz, h egy nem igazan jol megirt java alkalmazasrol van szo, de java temaban mas alkalmazasok eseten is bejott ez a szamitas kesobb.

tompos

Gondolom ezt nem nekem akartad válaszolni, de ha már így történt: vannak cégek, ahol a gyári támogatás fontos különféle okokból kifolyólag (nem is feltétlenül kizárólag műszaki/anyagi jellegű, egyébként a garancia kérdése nemcsak annyiból áll, hogy vesz az ember +1 alkatrészt vagy sem, cége válogatja, kinek mi a célszerűbb).

> A Supermicronál mindig elbizonytalanít az 1 év garancia.

Az ne tegye, mivel vasarolhatsz hozza +10%-ert +2 evet. Bar nekem az a tapasztalatom, hogy igazabol nem eri meg.
Sokkal nagyobb problema, h nincs helyi szerviz Magyarorszagon tudtommal, igy ha gondod van, fujhatod az eszkozt akar hetekre vagy honapokra. Cserebe viszont nem szokott vele olyan sok problema lenni (kopp...), ill. a support viszonylag valaszekony.

Ha koztes megoldast keresel, javaslom az Intel szervereket, pl. az Asbis certified partner es ha jol emlekszem, 3-4 napon belul javitjak, ha baj van (azaz az Asbis jogosult megallapitani a hibat es igy javitani, cserelni).

De az Intel azert olyan, hogy van itt-ott nehol egy csavar.

tompos

> itt Intel alaplap javaslat is érdekel

Gondolom nem az opteronhoz:)

Nalunk vannak Intel es Supermicro serverek is, alapvetoen mindegyik rendben van. A supermicro-t talan egy picit jobban kedvelem, jobban szerelheto, flexibilisebb vmivel.

> Opteron vs Xeon

Az utolso es jo ideje egyetlen opteron rendszer a kezem kozott egy 4 processzoros hulladek. Akkor megfogadtam, h meg a kozelebe sem fogok menni. Annyira silany a teljesitmenye, h leginkabb a kitalalojanak a fejehez vagdosnam, mert vas mondjuk van benne...

tompos