DoclerWeb: van, hogy van jobb a felhőnél (x)

Hirdetés

A nagy terhelésű, folyamatosan nagy látogatottságot generáló weboldalak üzemeltetői számára már megérheti saját infrastruktúrát építeni. Számukra ideális megoldást jelenthetnek a mikroszerverek.

A mikroszerverek tipikusan az I/O korlátos, kis processzorteljesítményt igénylő, jól párhuzamosítható feladatok alatt mutatják meg az oroszlánkörmeiket, ezek közé tartozik a webkiszolgálás is. A webhoszting-szolgáltatók nem ritkán több ezer vagy több tízezer gépet üzemeltetnek, számukra a legnagyobb kiadás a gépek bekerülési és üzemeltetési költsége, utóbbiban pedig jelentős tétel az energiafogyasztás.

A mikroszerverek ezen a téren jelentenek nagy előrelépést a hagyományos rackes vagy blade formátumú kiszolgálókhoz képest, amelyhez alacsony fogyasztású processzorok és nem ritkán alacsony fogyasztású memóriák jelentik a kulcsot. A gépek emellett fizikailag is kisebbek a rackbe építhető “pizzadoboz” vagy blade kivitelű társaiknál, ami alacsony árat és nagy teljesítménysűrűségű kiépítést tesz lehetővé - egy rackszekrénybe akár több száz szerver is beépíthető, amennyiben a megfelelő hűtési kapacitás rendelkezésre áll. Egy mikroszerverekkel “megtömött” rackszekrény fogyasztása megközelítheti a 10 kilowattot is, ezt azonban kevés adatközpontban tudják kezelni.

A világ 40 leglátogatottabb oldalainak egyikét üzemeltető és a hazai hosztingpiacon is egyre nagyobbá váló DoclerWeb kutatás-fejlesztési osztálya, a DoclerLabs olyan technológiákra koncentrál, amik egyszerre költséghatékony és kellően hibatűrő rendszert eredményeznek a lehető legjobb teljesítmény mellett. A vállalat tapasztalatai szerint a cloudok és a virtualizált rendszerek esetében relatív sok üzemzavart okoznak azok a rétegek, amik a virtualizációért felelősek.

Teljesítmény terén is kompromisszumokat követelnek meg a public cloudok és virtuális szerverek: az elvileg "hasonló" teljesítményű instance-ek és virtuális privát szerverek (VPS) jelentősen gyengébb sebességadatokat produkáltak a mikroszervereknél, elsősorban I/O terén. A VPS ugyanakkor remek eszköznek bizonyult tesztrendszerek vagy kisebb jelentőségű kiszolgálók üzemeltetésére, és a cloudban is van fantázia, amennyiben ideiglenes terhelést kell kiszolgálni vagy kis forgalmú webes tartalomszolgáltatásra van szükség.

A közel egy éves kutatás konklúziója, hogy ár/teljesítmény, megbízhatóság és üzemeltetési költségek terén a mikroszerver a jobb megoldás, amennyiben nagy teljesítményű webes kiszolgálás a cél. A költséghatékonyság elsősorban a rendkívül kedvező árú hardvernek, az extrém alacsony fogyasztású Xeon E3 processzoroknak és a load-balancing kedvező árának köszönhető. Ezeket az előnyöket a DoclerWeb kihasználja, használja, mégpedig úgy, hogy továbbadja ügyfeleinek: így érhető el szerverhoszting áráért egy fizikai szerver és szerverhoszting.

A vállalat az érdeklődők számára egy április 24-én este 6-kor kezdődő rendezvényen számol be szerverterem-építés terén szerzett tapasztalatairól. A Docler Akadémia előadója Angeli János, azaz Angelo, a szakma elismert szerverterem-tervezője és hálózati mérnöke. Angelo 1998 óta dolgozik internetszolgáltatóknál, részt vett 7 szerverterem tervezésében és építésében, műszaki vezetőként az Interware szervertermeinek építését és üzemeltetését is irányította, a cég ez idő alatt vált a hazai hosztingpiac vezetőjévé. A DoclerWeb hálózat és infrastruktúra osztályvezetőjeként szerverterem, valamint IP-gerinchálózat építése és üzemeletetése a feladata. Az eseményre ezen az oldalon lehet regisztrálni.

(A DoclerWeb Informatikai Kft. megbízásából készített anyag.)

( sj | 2012. 04. 16., h – 09:17 )

az elvileg "hasonló" teljesítményű instance-ek és virtuális privát szerverek (VPS) jelentősen gyengébb sebességadatokat produkáltak a mikroszervereknél, elsősorban I/O terén.

Errol jo lenne valami konkretat latni (mondjuk a meresek jegyzokonyvet), hogy egyaltalan az kideruljon, hogy mit mivel es hogyan hasonlitottak ossze...

Hajra, elnok ur! A Heti Valasz cenzuraja

Sziasztok!

Csak a további OFFolások elkerülése végett:

Igen, a www.livejasmin.com a DoclerWeb egyik nagy ügyfelének a tulajdonában van, és Igen, a DoclerWeb üzemelteti ennek az Alexa top50-es site-nak a szervereit.

Remélem ezt a szálat ezennel le is tudjuk zárni. :)

Üdv:
Angeli János
DoclerWeb

top65, mester :)

http://www.alexa.com/siteinfo/livejasmin.com

--------------------------
The OOM killer is like a surgeon that amputates the limb of a man to save his life: losing a limb is not a nice thing, but sometimes there is nothing better to do.

"Understanding the Linux Kernel" on page frame reclaiming

( KoGa v | 2012. 04. 16., h – 18:03 )

Na ez erdekelne, kar hogy nem tudok elmenni. Lesz valami letoltheto prezi, felvetel, ilyesmi?

ez 8 node/3U, vagyis 2.66 node/U.

Mi itt 2node/U sűrűségű rendszert használunk, nincs teli a rack, 45 node van csak. Igen komoly feladat volt a 45 node bekábelezése, a 19'' rack nincs erre méretezve. Talán egy 21'' rackbe be lehet kábelezni 84 node-t is.

Az a gyanum, hogy nálatok sincs a 42U rackben 112 node, mind klímatechnikai mind pedig szervizelési okokból értelmesebb 'hagyni helyet' a rackben.

Az entry-level storage fajlagosan olcsóbb, mint egy telivér midrange, kisebb switch fajlagosan olcsóbb, mint egy 48 port feletti switch, a tartalomkiszolgálásnál a storage áteresztőképessége fontosabb, mint a cpu száma. Innen gondolom - ha valóban több racknyi infrastruktúrátok van- hogy mondjuk 24 node, 2 swtitch és egy entry-level storage (3-4 shelffel) tartozik egy rackbe.

A blade-ek esetén szerintem a tápegység hatásfoka is jobb

Az összes blade-rendszer prospektusában szerepel ez az állítás. Ahol mérés is van mellette, ott mindig a mai blade rendszert hasonlítják össze a 4-5 évvel ezelötti standalone szerverrel.

Történt a blade szerverek elterjedésének idejében egy tápegység-fejlődés, amikor is a tápegységek hatásfoka lényegesen javult. (80%-ról 95%-ra ?). Nagyjából ez idő tájt terjedt el a változtatható fordulatszámú ventillátor a szerverekben, a blade rendszerekben is.

Aztán ez az állítás az összes mai szerver prospektusában szerepel.

Az egyik storage-hez kaptam egy matricát, ami azt bizonygatja, hogy ez a storage az üzemeltetése alatt nem foszilis-áramot, hanem szélenergia-áramot fog fogyasztani. Ezek nagyon fontos dolgok.

Itt a 45 darab gép 9.5 kW -ot eszik teljes terhelésnél. Ez 90 darab Xeon E5520 cpu és 282 darab ddr3 modul, 179 ventillátor, 12 tápegység.

A számok teljesen korrektek. Egy mai 1/2U-os duál Xeon szerver kb 210-225W-ot fogyaszt, és jó minőségű tápegység van bennük. (0,9 - 0,95-ös cosfi + 90% körüli hatásfok)

Egy blade chassis-ban kb 6 vagy 8 tápegység van, és kb 16 szerver. Ez szerverenként akkor 0,5 tápegység, de jelentősen nagyobb tápok. Jó esetben a tápegységek vesztesége fele akkora lehet egy blade-ben mint 16db különálló szerverben, de sűrű felépítés miatti nagyobb ventilátorok ezt a nyereséget szerintem elfogyasztják.

Viszont a kérdés remek, megmérjük, semmi akadálya. :) Ezzel mi eddig nem nagyon foglalkoztunk, mert a blade megoldások más műszaki paraméterek miatt kiestek a versenyből a sima szerverekhez képest. :) Ezt lentebb már írtam.

Angelo

Egy közepesen pakolt IBM X3550M3-as 180-190W-ot mér magáról nagyjából alapjáraton. Ebből 2 CPU, 5 diszk és 6x4GB memória van. Ez szerintem bőven lejebb hozható, ha csak egyszerű felhasználás kell. Ugyanakkor X56xx-es cpukkal és totál tökig rakva memóval és 15k-s diszkekkel simán duplázható is. :)

(Alapjárat: a gép körberöhögi azt a terhelést/forgalmat, amit egy sokéves 2 procis 2,8GHz-es Netburst Xeon és egy másik hasonló de csak 2,4GHz-es gép már elég nehezen viselt.)

A táp kérdést minden matrica nélkül gondoltam, a brossúrákat ritkán olvasom vagy veszem komolyan. Ez a szélenergiás különösen aranyos, lehet arra gondoltak hogy a gépben a ventik által keltett szelet lehet visszatáplálásra használni. :)

A kérdés jogos! Valóban nem triviális feladat.
Nálunk 19"-os 46 U-s rackek vannak, és 96 node-ot teszünk egy rackbe.
Ez ugye 12*3 Unit, ami mellé még kell 96 gigabites switch port,
amit két 48 portos menedzselhető switch szolgáltat.

Emellett minden géphez külön fixen bekötött IPMI port is jár,
ami újabb 96 portot jelent, egy VPNen elérhető VLANban.
Ez még négy 24 portos switch.

Így összesen 42 Unit van használatban.
A fennmaradó 4 Unit a switchek körül van elosztva a kábelezés rendezésére.
Valójában mind a klíma rendszer, mind a rackenkénti betáp elbírna többet is,
a 10 kW/rack hűtési teljesítmény ilyenkor jön jól. :)

A storage megoldásokat productionra nem preferáljuk, a gépek lokális diszkjeit használjuk alapvetően.
Akinek mégis kell storage, a blade-ek rendelkeznek iSCSI vezérlővel.
Mivel az iSCSI ethernet felett megy, a storage bárhol lehet, jellemzően egy másik rackben.

Angelo ígért képeket a kábelezésről, ezt ilyen sűrűség mellett is meg lehet oldani kulturáltan.

Üdv,

-logor-

Ez egy 'marketing' adat, amire ráadásul olyan kérdést tettél fel, aminek szintén kevés a gyakorlati értelme. 100db normál hoszting szerver (nem warez, ftp...) nem feltétlenül közelíti meg az 1G belföldet, külföld irányba néhány 10M-t csúcsidőben. A fontos kérés az, hogy a szolgáltatónak van-e biztonságos plusz tartalék sávszéllel annyija, ami bőven elég az ügyfeleinek, illetve ha szükséges, tudja-e és milyen gyorsan bőviteni a kapacitásait, ha a gyakorlatban több kell. Doclernél szerintem az utóbbiak közül egyik sem gond. Ha megnézed az oldalukat, az össz külföldre 80G kapcsolattal hirdetik magukat..., valószínű tudnak annyit kiszorítani belőle, amennyi kell ezeknek a bérszervereknek.

Skuzzy már leírta a lényeget. :)

Minden hoszting linerate 1G-át kap. (Linerate: Nem korlátozunk semmit sem, de a technológia - ethernet + TCP/IP - miatt 80% forgalomnál már lehet packet loss. Azaz 1G port esetén ez 800Mbit/sec Full Duplex kapcsolatot jelent packet loss nélkül.) A 10G uplink azért fontos a Layer2 aggregation switchekből a core felé, mert manapság egy DOS attack simán lehet 2-3G is. Azaz egy gépet ért támadás nem üti ki az összes ügyfelet (48) aki ugyanazon a Layer2 switchen van.

Minden hosztingnak műszakilag garantáljuk a linerate 1G-át belföld és külföld felé is. Az már más kérdés, hogy azok a felhasználók akik _folyamatosan_ _jelentősen_ kilógnak az árazási modellből, azokkal 1-2 hónapon belül leülünk beszélgetni hogy mit szeretnének... Azok a felhasználók akik időnként elrángatják 1G-ig a szerverüket simán beleférnek az árazási modellbe. :)

Műszakilag tudjuk mérni és korlátozni is a hoszting nemzetközi és belföldi forgalmát is. Jelenleg viszont nincs egyetlen ügyfelünk sem akinél limitet kellett volna felrakni. Sőt nem is lesz senkin limit addig amíg az előbb említett megbeszélés le nem zajlott vele. :)

Üdv:
Angelo

:) Nekem van olyan projektem (nem előjázmin konkurens), ami a mérés szerint csúcsidőben 950-980Mbitet présel ki üzemszerűen (~98-99%-ban belföld) 1-1 switchportból és perpill 3 van. :) Az ilyenhez hogyan viszonyultok műszaki főleg szempontból? (Hogy mennyire van csomagvesztés a linkeken azt nem mértük, de szerintem elenyésző.)

amikor kezdődött ez a sűrűség-kergetés, akkor elöbb kijöttek a 2U, majd az 1U szerverek.
Utána már látszott, hogy a kábelezéstechnikai, felügyeleti probélmák durván nőnek a szerverszámtól, emiatt kezdett elterjedni a blade technológia, ahol is a kábelezést, felügyeletet adja a doboz. befér 8/14/16 node egy dobozba.

Csakhogy a blade túl nagy siker (buzzword) lett, a gyártók rendszerei páronként inkompatibilisek egymással, így történt, hogy a balade rendszer ára szinte mindíg több, mint egy vele szoftveresen ekvivalens standalone konfig ára (szerverek, switchek, felügyelet).

Van a vásárlóknak egy része, akiket nem lehetett beetetni a blade technológiával, akiknek megéri 50e forintot kifizetni a kábelezésre (mérnök) mintsem 1M forintot a blade árába. (ahol a mérnök rendkívül szűk erőforrás, ott megéri a blade).

Ilyen helyeken alkalmaznak a standalone server és a blade rendszer közötti átmenetet, ahol is a tápegység és a doboz közös, de más (felügyelet, switch, kábelezés) nem. Nálunk ezeket 'thin server' -nek nevezik, itt most microserver-nek.

Pontosan erről van szó!

Mi sem használunk klasszikus blade rendszereket, mert semmivel sem olcsóbb az 1/2U-os szervereknél. A kábelezést sem egyszerűsíti csak akkor ha belerakjuk a blade chassis-ba az ethernet switchet, így viszont túl sok hálózati eszközt kellene üzemeltetni. (És nem is olcsó megoldás :)

A nagy sűrűség elérésének a titka az egyedi méretű kábelek és egy igényes technikus kolléga.

A Mikroszerver márkanév ;) pedig egy belső fejlesztési projektből jött ami arról szól hogy kb 144 alaplap + CPU-t rakjunk egy rack szekrénybe. De ezen még dolgozunk egy kicsit. :)

Üdv:
Angelo

Az egyedi hosszúságú kábel nem feltétlenül helyszínen gyártott. Mi konkrétan gyári 0,3 0,5 1 1,5 2 és 2,5m-es kábeleket használunk a rack szekrényekben különböző színekkel kombinálva. Tápkábelekből is egyedi gyártású gyári 65 és 85cm-es kivitelt.

És valóban nem kevés raktárkészletet kell fenntartani ahhoz, hogy minden színből és hosszból legyen kb. 100db raktáron. :)

Üdv:
Angelo

Ahogyan ígértem, íme egy fotó a MikroSzerver rack (46U, 600mm széles, 1200mm mély) kábelezéséről:

CablingWorks by Yotzo :)

A szürke kábelek a production GE, a kék kábelek a 100M-ás IPMI kábelek, a fekete pedig a tápkábelek (balra az "A" jobbra a "B" UPS tápelosztója).
A production switch egy CISCO 4948E back-to-front légáramlással 48x10/100/1000M + 4x1/10G SFP+, az IPMI switchek nem managelhető Planet 24x10/100M + 2x10/100/1000M.
A képen jól látszik hogy szinte felesleges is a kihagyott 1-1 Unit a switchek és a szerverek között. :) Azaz egy 42U-os rack be is be lehetne rakni a 96 szervert. :)

Üdv:
Angelo

IPMI/KVM switchnek valszin több mint kiváló. Ha minden porton egyszerre KVM-eznek is, akkor sem több mint 20Mbit a szumma forgalom, annyit meg remélhetőleg kibír. :)

Egyszer egy komoly helyen meglepődtem, hogy miért csak két "sima" switchet használnak. Aszondták azért mert "hát nekünk két vlan kell és így még a szeparáció is tuti".

a specifikációnak megfelelő legolcsóbb switch kell, minden más hiba.

- 3 év gari (niif esetén 5)
- wirespeed gigabit
- jumbo frame
- értelmes légáramlási megoldás
- 10G uplink

nem olyan hosszú a specifikációs lista nemde?

más kérdés a production-HPC, mondjuk a meteorológusoknál, hiszen az erősen ciki, hogy "nincs előrejelzés holnapra, javitják a switchet" Ennek megfelelően az omsz 2 darab egyforma HPC-t vett.

Nyilván az érintett gépnél sem az interconnect megy a Planet switchen keresztül (az Numalink5), csak érdekes volt látni, hogy egy sokmilliós beruházásnál ezen spóroltak pár tízezer forintot (majd gondosan leragasztották a Planet feliratot a switchen, hogy úgy hátha nem szúrja ki az ember elsőre... :)

Pedig ez nem ciki szerintem. Sőt, meg lehet mutatni, hogy nézzétek a pénz nem baromságra költöttük, hanem inkább erősebb CPU, több RAM stb. került a rendszerbe a ahelyett hogy Full layer 3+ managed BGP mittomilyen csodaswitchen mennek az IPMI-s vagy ahhoz hasonló dolgok. :)

Ehhez persze tudni kell, hogy általában sok remek EU-s projektnél X forintot (EUR árfolyamtól függően...) nyernek meg és be kell tuszkolni egy minnél jobb rendszert. Természetesen azzal az optimista feltételezzésel élek, hogy rendesen állnak hozzá a projekthez. Ez egyébként igaz lehet akkor is, ha egy normál céges projektben szűkre szabják a költségvetést vagy a tervezéskori árakhoz képest elszállnak a beszerzéskoriak.

Igen, Planet switch. :)

A kérdéses switchnek jelenleg alábbi a specifikációja, bármit használunk szívesen ami működik és ennek megfelel:
- back to front airflow vagy passzív légáramlás nélküli hűtés
- nem managelhető
- min. 2db GE uplink port
- 24 vagy 48 10/100 vagy 10/100/1000 port

Régebben 3com-ot használtunk, a rack-ek feléban az van, de megszüntették a gyártását. :)

Üdv:
Angelo

Elrettentésképpen ide most linkelhetnék egy hazai hostingban készült képet, amit az egyik olvasó juttatott el hozzám azután, miután a fórumban a hosting embere levetetett egy kommentet, mert azt állította, hogy az illető nem állított valóst, amikor az ottani helyzetről képet festett. Szép lenne a kontraszt :D

--
trey @ gépház

( egeresz | 2012. 04. 18., sze – 14:45 )

meg kell mondjam, egy kicsit elfogott az irigység, én itt terelgetem a 63 node-os HPC-t és a 22 node-os cloudot, azt meg másutt mekkora rendszereket építgetnek, és nem is a no such agency, meg lawrence livermore, hanem a szomszéd.

( uid_228 | 2012. 04. 20., p – 11:15 )

Több napja jelentkeztem, eddig semmi visszajelzést nem kaptam. Ez bug, vagy feature? :)

--
Java apps are nothing more than sophisticated XML-to-exception converters.

Igazán nincs mit!
Aki az előadás után szeretné a szervertermet is megnézni,
az mihamarabb válaszoljon, mert biztonsági okokból limitált számú embert tudunk bevinni.
Nem biztos, hogy mindenki sorra kerül aznap este.
Természetesen más időpontokban is lehet jönni,
csak egy egyeztetés kérdése.

Aki nagyon szeretne aznap este menni, az a válaszlevélbe írja be a hup.hu varázsszót:)

Üdv,

-logor-

( siposf | 2012. 04. 25., sze – 10:10 )

Az előadáson leadott slide-ot meglehetne kapni? :)