Serververhuizing Tweakers.net 30 juni 2007

Inleiding

Zoals jullie hoogstwaarschijnlijk weten, doen wij ons uiterste best om ons serverpark in tip-top conditie te houden; zo is het op dit moment tijd om Artemis definitief te vervangen door iets nieuws en hips, ook de loadbalancers trekken het allemaal niet meer en bovendien zitten onze masterswitches tot de nok vol. Doordat we graag eens ons rack opnieuw zouden willen opzetten kregen we het plan om eens met onze vrienden van True te overleggen om te zien of er misschien een mogelijkheid was om meer ruimte in een rack te krijgen.

Na jaren gebruik te hebben gemaakt van het huidige rack is het helaas een beetje een rommeltje geworden en de mogelijkheid om ons rack opnieuw in te delen zou welkom zijn. We zien af en toe een type rack op Redbus staan wat dieper is dan ons huidige rack en dat leek ons ook wel wat .

Tijdens een van de eerste gesprekken kwam ons totale stroomverbruik naar voren: er werd ons verteld dat wij iets meer dan de toegestane 8 Ampère per footprint gebruikten.
Volgens onze masterswitches trokken we in totaal bijna 21 Ampère .

Oftewel: er moet iets veranderd worden. In Redbus zouden we zelfs naar drie racks toe moeten gaan om er zeker van te zijn dat de koeling van de ruimte onze setup aankan. 'Helaas' hebben wij alle servers keihard nodig, dus iets uitzetten is ook geen optie.

Een andere optie is, je raadt het al aan de titel van dit artikel, verhuizen naar een andere locatie en van daar uit onze sites naar jullie te versturen. We zijn met True overeengekomen dat we gaan verhuizen naar EUNetworks waardoor we per rack 14 Ampère uit de voedingskabel mogen trekken. Dit is echter nog steeds niet voldoende om ons rack te voeden dus gaan we twee racks in gebruik nemen. Dit levert weer nieuwe problemen op: wat zijn we van plan met de kvm, de switches etc. In deze review geven we jullie een blik achter de schermen en proberen we een en ander te verduidelijken.

Onze tijd in Redbus

Onze servers hangen inmiddels al bijna drie jaar in Redbus, en hebben daar veel meegemaakt. Alles wat je kan verzinnen is wel eens stuk geweest, een kleine bloemlezing:

Treurige kijk op de huidige status van de kabelboom.

• Servers met brakke sata-drivers
• Stroomuitval vanwege een brakke masterswitch
• Dataverlies vanwege een stomme kabel
• Gedeeltelijke stroomuitval in Redbus
• Netwerkstoringen
• Kortsluiting in server
• Verdwijnende data
• Volle mailschijven
• Ruzies met Force10-hardware

Uiteraard is er ook genoeg leuks gebeurd in de jaren in Redbus; zo hebben we zonder uitzondering elke machine wel onder handen genomen waardoor configuraties zijn vervangen, aangepast, verbouwd of veranderd zijn van functie. Door dit alles is er van ons originele plan om een mooi strak ingedeeld rack te onderhouden weinig terechtgekomen. Onze plannen zijn ondergesneeuwd onder een veelvoud van kabels en goede bedoelingen. Zo heeft op dit moment elke machine tenminste 4 kabels lopen naar verschillende plekken in ons rack:

• tenminste 2 voedingskabels.
• utp kabel naar een van de switches.
• keyboard, video & muis kabel naar de kvm.

Ons serverpark bevat op dit moment 16 machines waardoor er op een kleine oppervlakte ruim 64 kabels lopen waarbij we nog niet eens kijken naar de overige verbindingen, zoals de voedingskabels van de vier masterswitches, twee netwerkswitches, een kvm en een kvm-over-ip en de drive enclosures. Oftewel: ons rack is vol, heel erg vol, en we kunnen de kabels niet meer kwijt in de toch ruim bemeten kabelgoten, zoals de nevenstaande foto goed illustreert.

Nieuwe hardware

Masterswitches

We grijpen dus deze verhuizing aan om ons originele plan, het beter opzetten van het rack, mogelijk te maken. Zo gaan we deze keer niet weer alle powercables naar de nok van het rack trekken, maar hangen we de hiernaast getoonde masterswitches aan de zijkanten van de racks, zodat we de kabels zo kort mogelijk kunnen houden. Het mag overkill lijken om vier van deze skilatten te plaatsen, maar we willen uiteraard wel beide stroomfeeds gebruiken in elk rack, waardoor we dus in de luxepositie van maar liefst 90 beschikbare stroomtappunten uitkomen. Op dit moment hebben we voor een deel daarvan nog geen functie bedacht, maar dat komt vanzelf. Wie had tenslotte ooit bedacht dat we naar twee racks zouden moeten overstappen?

Netjes opruimen als je klaar bent

Aangezien de kans dat we een compleet rack weer helemaal tot de nok gaan vullen definitief achter ons lijkt te liggen, kunnen we in de nieuwe situatie ook meer ruimte voorzien voor het netjes houden van onze werkplek. Daarvoor hebben we een 3U-lade op de kop getikt waarin we in het vervolg al onze troep kunnen bewaren, zodat we niet (weer) kooimoeren of andere onderdelen onder andere racks laten vallen en rare toeren uit moeten halen om deze terug te krijgen.

Lade om random dingetjes in te bewaren.

Nieuwe connectivity

Per rack komt er verder een nieuwe 24 poorts HP Procurve 2900-24 switch, voorzien van een viertal 10GigE-poortjes waarmee die met behulp van twee cx4-kabels beide racks aan elkaar worden geknoopt. Deze nieuwe switches kunnen een 20Gbit-verbinding met elkaar opzetten.

De oude HP 2824-switches hadden 'slechts' de mogelijkheid tot het trunken van 4Gbit, waarvan wij in Redbus slechts 1Gbit gebruikten. Wij verwachten echter dat, zelfs met maximaal 4Gbit, ons netwerk langzamer zal reageren bij servers die niet aan dezelfde switch hangen. Aangezien we altijd erop vooruit willen gaan, en niet achteruit, gaan deze vervangen door veel hippere Procurves. Een bijkomend voordeel van de nieuwe switches is dat er slechts een tweetal cx4-kabels tussen de racks getrokken hoeven te worden. In de oude situatie zouden we 4 utp-kabels moeten trekken, en we blijven ict'ers, dus minder kabels == beter.

Aangezien availability bij ons hoog in het vaandel staat gaan we dat deze keer weer een stapje verder doorvoeren. Zo gaan we in de weken na deze verhuizing de oude switches klaarmaken en testen voor een positie als fallback-switches zodat we in theorie de nieuwe switches uit kunnen zetten en naadloos over kunnen stappen naar de oude switches waardoor downtime hopelijk nog minder zal voorkomen.

Nieuwe servers

Last but not least: we gaan Artemis weer upgraden. Waar we de vorige keer een tijdelijke upgrade naar de oude Apollo hebben uitgevoerd, zal er dit keer een compleet nieuwe PowerEdge 1950 en MD1000 klaarstaan om de vernieuwde frontpage nog sneller op je beeldscherm te toveren.

Specificaties nieuwe Artemis
Kasttype	PowerEdge 1950
Processor	2x Intel Quad-Core Xeon X5355 2.66GHz/2x4MB 1333FSB
Geheugen	16GB FB 667MHz Memory (8x2GB dual rank DIMMs)
Raid-kaarten	Dell Perc 5/i & Dell Perc 5/E
Remote bediening	Dell Drac 5

En uiteraard hangt daar weer een Dell MD1000 aan geheel gevuld met crispy, nieuwe, 73GB grote, op 15K toeren draaiende 3.5inch-schijven .

Ook gaan we gelijk de oude, brakke, doorhangende loadbalancers vervangen, waardoor we problemen zoals bij de ingebruikname van onze nieuwe frontpage hopelijk niet meer zullen tegenkomen:

Specificaties nieuwe loadbalancers
Kasttype	Dell PowerEdge 860
Processor	Intel Xeon x3220 (quad core, 4x 2.4Ghz, 1066Mhz bus)
Geheugen	2x 1GB 667Mhz
Network	onboard & Intel dual port Gbit-nic

Samenvatting

We gaan onze huidige setup dus serieus upgraden, T.net Style . Een korte samenvatting van onze upgrades is in onderstaande tabel te vinden:

Oude situatie	Nieuwe situatie
1 rack	2 racks
1x 8 Ampère	2x 14 Ampère = 28 Ampère
Artemis Appro	Artemis Dell PE1950 + MD1000
HP Procurve 2824	HP Procurve 2900-24
4 masterswitches type AP7921 à 4U	4 Masterswitches, type AP7951
2x Celeron loadbalancer	2x Dell PowerEdge 860
Betaalde koffie	Gratis koffie

Al met al is de kogel dus door kerk: we gaan verhuizen op 30 juni 2007. Op die dag zullen om 9:00 een aantal met de hand geselecteerde dapperen bij Redbus verschijnen om al onze servers uit Redbus te halen en deze met liefde en toewijding in auto's te laden, waarna ze in EUNetworks kunnen worden opgehangen en weer in gebruik worden genomen. Uiteraard nemen we een camera mee om alles vast te leggen voor het nageslacht.

Aangezien we veel nieuwe hardware in gebruik gaan nemen, kunnen we veel voorbereidend werk alvast uitvoeren. De masterswitches zijn al geconfigureerd en worden binnenkort bij EUNetworks afgeleverd om alvast in de racks te worden geschroefd. Ook zullen de switches, de nieuwe Artemis en loadbalancers al enkele dagen voor de daadwerkelijke verhuizing worden opgehangen.

Uiteraard willen we onze breedbandsponsor True hartelijk bedanken voor deze nieuwe mogelijkheden .

Buitenkant EUNetworks

Reacties (231)

[Redlum]

Hebben jullie wel met True overlegd over die AP7951 masterswitches? Deze hebben namelijk een speciale stekker die wij ongeveer een jaar terug niet konden aansluiten op euNetworks (omdat ze dan het stroomverbruik niet kunnen inzien). Misschien is het onderhand al veranderd maar het vermelden waard voordat jullie voor een verassing komen te staan .

Wij hebben uiteindelijk de 8 ampere versie moeten nemen die wel een normale stekker heeft. De nadeel daar weer van is dat je 'm nooit helemaal vol krijgt als je er een paar dikke servers aanhangt dus ben je beter af met de versie die jullie nu ook al hebben (8 port, 16A).

[Kees]

Jah, wij hebben hier speciaal contact over opgenomen met True, en die heeft ons naar deze verwezen. Er zit inderdaad een 'caravan stekker' op, maar daar zijn gewoon verloopstekkers voor beschikbaar bij de betere electronicahandels.

Het verschil tussen 2x 8 amp of 1x 16 amp op een powerfeed aansluiten lijkt mij ook minimaal

[hommer]

Er zitten natuurlijk niet voor niets van die 'carvan stekkers' aan. Het idee is dat die wat meer stroom kunnen voeren dan een 'gewone' stekker. Dus zo'n verloopje gebruiken is niet helemaal de bedoeling....

[moto-moi]

Valt mee, de gewone 230 stekker zelf is sterk genoeg om wel wat meer dan 16A door zich heen te krijgen, hetgeen waar je op moet letten is de dikte van de kabels en die zijn bij zo'n caravan-verloop wel redelijk op orde.
Verder hebben we al een rondleiding gehad @ EUNetworks en daar hebben we meer racks gezien die exact dezelfde setup gebruikten. Bang voor smelten van kabels zijn we dus niet echt

[Jasper Janssen]

Die blauwe kampeerstekkers (CEE stekkers) zijn onderdeel van de serie geel/blauw/rode stekkers, voor respectievelijk 110V enkelfasig[1], 230V enkelfasig, en 230V driefasig. Het voornaamste voordeel dat ze hebben is dat ze ontzettend robuust zijn en goed kunnen tegen oa weersinvloeden, mechanische belasting (ie, eroverheen lopen/rijden), en vooral ook herhaaldelijk aansluiten en loshalen.

Op zich is een normale nederlandse (Duitse, eigenlijk) schuko stekker met pennen van 4.8 mm meer dan genoeg voor 16A -- heel veel (inbouw-)ovens, en zelfs wasmachines en drogers buiten natte ruimtes, zitten met zo'n ding vast, en dat levert zelden of nooit een probleem op. Als er al eens iets doorfikt zijn het juist de stopcontacten, omdat die plaatjes niet goed contact meer maken (Na te vaak/niet recht genoeg lostrekken), of de aansluiting van de pennen naar de kabel of van het stopcontact naar de installatiedraad. Maar het stopcontact is in dit geval de verantwoordelijkheid van de colo-provider, en dat je daar met een schuko-stekker in moet pluggen is dus ook hun verantwoordelijkheid.

[1] In Nederland nog soms op bouwterreinen te vinden, maar populairder in amerika/japan/etc.

[Reactie gewijzigd door Jasper Janssen op 23 juli 2024 03:43]

[FireDrunk]

een beetje tweaker plakt er toch gewoon een temperatuur sensor in, en in het geval van tweakers.net maken ze er ook nog een mooi statistieken-grafiekje van...

[Noxious]

@thijs:
Ik stem voor!

[burne]

IEC 60309 geeft als maximale stroom voor de stekker op de foto 16A. Daar hoef je het niet om te doen, dus. De voordelen van 'CEE-stekkers' zit 'm in de ingebouwde vergrendeling, de waterdichtheid en de polariteit van de steker. Er ligt vast wat nul en fase is, en omdraaien kan niet. Dat kan soms van belang zijn.

[Jasper Janssen]

Mits de stekkers goed bedraad zijn, natuurlijk, en dat is iets waar je niet honderd procent van kan uitgaan, vooral omdat het iets is dat je pas merkt als er iets anders al stuk is. In landen waar de standaard stopcontacten directioneel zijn, zoals frankrijk en amerika, is vaak 10, 20 procent van de stopcontacten verkeerd om bedraad.

Bij het huurhuis van mijn oma, hier in Nederland, heeft tot voor kort (toen aardleks geinstalleerd werden en opeens alles niet meer werkte) het stopcontact waar de koelkast en -- in voorkomende gevallen -- de oven op zaten, bedraad gezeten met een verwisselde *nul* en *aarde*. Dat is pas kut. De electricien zei dat hij het bij meer huizen in die wijk tegen was gekomen -- blijkbaar een incompetente electricien bezig geweest ooit.

[buzzin]

Je kunt ook even kijken bij campeer winkel....laatst ook eentje gehaald....ook omdat ik hier ineens rack aan moest sluiten op mooie blauw aansluitpunt...
Natuurlijk veranderd dat in de toekomst....maar het rack hier is nog niet zo imposant als dat van tweakers

[MikeN]

Die stekker valt er overigens ook prima af te schroeven waarna je een goede normale stekker kan plaatsen (wel beetje op kwaliteit letten natuurlijk).

Ik vind die AP7951 dingen overigens maar ondingen, ze zitten continu in de weg in je rack en zijn eigenlijk alleen mooi weggewerkt als je ook een APC rack gebruikt. Anders moet je ze aan je staanders hangen en loop je maar te kloten met het plaatsen van rails.

[Redlum]

Op euNetworks valt dit erg mee door de extra diepe kasten. Je hebt ruim genoeg ruimte en kan overal goed bij. Is ook veel beter voor je kabel management.

Het plaatsen is inderdaad wel een beetje brak, gaat opzich goed maar je hebt niet echt het idee dat het nou super stabiel vast zit.

[MikeN]

Tja, ze passen wel, maar iedere keer dat je een server bij wilt plaatsen kun je hem weer een stuk losschroeven omdat je anders je rails er niet tussenkrijgt (tenzij je natuurlijk rapidrails oid gebruikt).

Zo'n gigantische kabelmanagementverbetering zie ik niet echt, kabels zijn bij normale APC's ook wel fatsoenlijk weg te werken, je moet ze alleen niet allemaal op dezelfde plek in je rack hangen, dan krijg je gigantische kabelbomen.

[Jasper Janssen]

Stekkertje wisselen lijkt mij makkelijker dan een verloopje, ook omdat je dan een stekker/contrastekker van blauwe CEE bespaart aan loshangende troep. Je bespaart bovendien een extrra verbinding die dan geen problemen kan leveren.

[bazkar]

De eerste keer dat ik de term 'masterswitch' hoorde keek ik al raar op. (Netwerkboer he, ga je automatisch een andere kant op denken).
Maar ook in de link hierboven wordt gesproken over PDU's (eventueel metered en/of managed PDU's, dus met display en/of IP connectivity). Is er een verschil tussen een 'gewone' PDU en een masterswitch of is het een gewoon een andere naam voor het ander?

Ik vind het wel typisch als ik google op masterswitch dat tweakers als 2e hit voorbij komt....

[froggie]

Ze bedoelen hier gewoon PDU Ik krijg het idee dat MasterSwitch een serie PDU's is (geweest) van APC. Iemand die het zeker weet?

[Redlum]

Masterswitch is een achterhaalde term, dat was inderdaad een serie PDU's van APC die iedereen gebruikte. Tegenwoordig gebruiken ze die term ook niet meer. Old habits .

[Reactie gewijzigd door Redlum op 23 juli 2024 03:43]

[Prulleman]

Ik vind het wel typisch als ik google op masterswitch dat tweakers als 2e hit voorbij komt....

google weet dat jij vaak op tweakers zit en gooit daarom die results omhoog.
(geen grapje btw)

[Reactie gewijzigd door Prulleman op 23 juli 2024 03:43]

[jmwiersma]

PDU is een Power distribution unit; dus een unit voor stroom distributie. Sommige leveranciers zien dit dus als de verdeelkast.

Power strip is soms een betere term. Die heb je in managend en unmanagend versies.

De termen worden nogal door elkaar gebruikt in datacenterland.

[Verwijderd]

Ik zie dat jullie zo'n mooi ouderwetse KVM oplossing met dikke en veel kabels gebruiken.
Waarom niet een Avocent of soortgelijk systeem? daarmee hang je aan je server een heel klein blokje (IQ) waaruit hele korte kabels voor KVM komen. In het blokje steek je een CAT5 kabel met standaard RJ45 stekker die naar de KVM switch gaat. die KVM switch kan je vervolgens volledig via IP bedienen. Inclusief authenticatie via AD of iets anders leuks.

Verder is zo'n oplossing te integreren met de bijbehorende master switches.
Het hele beheer loopt dan netjes vanuit een web interface. Je klikt de juiste server aan en je kan de kvm openen of de power er af halen etc....

nog een ander puntje. Is het kwa storage niet veel eenvoudiger om een SAN te gebruiken. Gooi een CX3-10 onderin dat rack en je kan in de toekomst uitbreiden tot ettelijke terrabytes aan opslag. En dat helemaal on the fly. Dus als de performance te weinig wordt en je hebt meer disks in een array nodig of je hebt te weinig capaciteit: gewoon disken erin gooien, array groter maken, op de server dmv lvm enzo de partities groter maken en klaar. 0,0% downtime. en de performance is nog veel beter dan zo'n disk cabinet ook. Er zit nl een enorme cache in zo'n bak.
Daarnaast zou je zelfs je servers kunnen booten van het SAN. Als er een machine dood gaat knoop je gewoon een nieuwe aan je fabric en vlammen weer. Niks opnieuw installeren enzo.......


maarja..... kost natuurlijk wel iets meer. maar tegenwoordig valt het ook best wel weer mee (20.000 Eur voor compleet SAN: switches, storage doos, kabels)

[Reactie gewijzigd door Verwijderd op 23 juli 2024 03:43]

[ACM]

Die "ouderwetse kvm" hebben we al, een andere oplossing kost ons weer extra investeringen, terwijl de voordelen nou ook weer niet zo groot zijn. Om nou meer dan 3000 euro uit te geven voor een 24-poorts kvm-switch met als belangrijkste verantwoording dat we (per rack een stuk of 10) dunnere kabels overhouden en voor de sporadische keer dat we hem nodig hebben ietsje makkelijker ermee kunnen werken... Dat gaat wat ver

Voor SAN's geldt iets vergelijkbaars. Voor die 20k euro die je noemt gok ik dat je niet een array met 30 disks hebt, terwijl we voor een stuk minder dan dat wel zowel onze forumdatabase, Apollo, en onze nieuwe frontpagedatabase, Artemis, hebben voorzien van een 15-diskarray en met ieder een eigen raid-controller. De grootte van de disks is daar overigens niet relevant bij, enkel de randomaccess-performance (meer diskheads is meestal beter).

Uiteraard zou een SAN-opstelling met 30 disks sneller kunnen zijn dan twee losse met ieder 15, maar hoewel we tegenwoordig niet heel erg op de centen hoeven te letten, moeten investeringen wel verantwoord zijn
Voor webservers gok ik dat een of twee 80BG sata-schijfjes goedkoper zijn dan zo'n fibre-channel HBA+switchpoort (stom dat Dell daar geen prijzen van online heeft), bovendien is er volgens mij de afgelopen twee jaar maar een webserver stuk gegaan.

Dus SAN is mooi, maar ik denk niet dat wij er snel op over zullen stappen.

[XBL]

Sorry om te zeiken, maar waarom alweer verhuizen? Nog niet zo lang geleden (anderhalf jaar ofzo?) zijn jullie ookal verkast. Kon er toen niet geanticipeerd worden op de dreigende problemen (ook toen was al bekend dat stroomgebruik problematisch geworden met slurpende servers overal).

Daarnaast: extra switches is niet perse nodig, voor redundancy, tuurlijk, maar voor de rest trek je toch kabels onder de vloer door? Zeker met KVM, als daar genoeg poorten op zitten, trek je die kabels onder de vloer.

En die troep in jullie rack met kabels: beetje dom om alles aan de achterkant van de server te laten lopen. Je kan power direct rechts sturen en netwerk direct links (bijvoorbeeld). Dan heb je de hele diepte van je rack om de kabels met goten en/of tierips te bevestigen.

Wel mooi om die 0u APC's te gebruiken, die zijn echt heel prettig (korte stroomkabels zoals je zelf al zei, en ook stuk overzichtelijker omdat de server direct naast z'n poort hangt).

En last but not least: gratis koffie is goddelijk. Zelf doe ik nachtdiensten in een datacentrum en ben blij dat ik geen duppie kwijt ben aan die koffie, lekker zuipen .

[jep]

Toen True naar RedBus ging had True nog geen ruimte op EuNetworks. Op dat moment was RedBus tamelijk state of the art, maar de ontwikkelingen gaan nu eenmaal heel erg snel.

Kabels vanaf je KVM en switch (M.u.v. een enkel uplinkje) onder de vloer doortrekken is natuurlijk een poor-mans oplossing. Daar hang je in een professionele omgeving gewoon wat extra apparatuur voor op. Bovendien wil je het onder de vloer ook strak houden (Er staan een paar honderd racks in die ruimte) en is het einde zoek als iedereen zijn bekabeling onder de vloeren door gaat trekken.

Wat betreft die kabels is mijn ervaring dat dit (Zeker in de racks op RB) door veel wijzigingen in servers (met name diepe en ondiepe servers) zo groeit. Vooral omdat de T.net servers continu beschikbaar moeten blijven is het niet altijd mogelijk om cablemanagement helemaal 100% te houden.

Op EuNetworks zijn de racks een stuk dieper en is er veel meer ruimte voor perfect kabelmanagement.

[Reactie gewijzigd door jep op 23 juli 2024 03:43]

[Verwijderd]

De racks in euNetworks staan niet direct op de grond, maar je kunt tussen de grond en de kast makkelijk wat kabels trekken, zodat je niet eens onder de vloer hoeft

Ik heb zelf naar al m'n racks patch-kabels lopen (2 per rack) voor ethernet.. Ideaal

[jep]

Dat heb ik ook op al mijn racks op EU, maar niet voor alle servers en alle KVM kabels.

[ACM]

De vorige verhuizing was zo te zien op 26 oktober 2004, dus ruim twee en een half jaar geleden. We hebben wel daarna nog een keer een deel van de servers verbouwd en ze allemaal opnieuw in het rack gehangen op Red Bus. Toen was het nog bepaald geen hot-issue dat de stroomvoorziening het niet aan zou kunnen (vziw was die zaal waar wij in gingen toen half leeg) en was het bovendien ook nog niet heel erg duidelijk dat wij ondanks de verbeterde stand van techniek (onze servers zijn relatief zuiniger geworden) toch zoveel meer stroom zijn gaan verbruiken. Zie verder de uitleg van jep over True, veel keus voor iets beters was er ook gewoon niet

Het lcd-deel van de KVM die we gebruiken heeft 'maar' 16 poorten en daarmee precies genoeg (en dus te weinig) poorten voor onze servers, de 16-poorts uitbreiding hadden we echter tegelijk gekocht (met het oog op uitbreidingen en af en toe de noodzaak om een sever die vervangen gaat worden wat langer te laten hangen) en wordt dus vanaf nu eindelijk nuttig gebruikt, ipv met maximaal 1 a 2 poorten Dus dat zou zelfs onzin zijn om al die kvm-kabels te vervangen door langere en met een grote berg onder of over het rack te laten lopen, terwijl we de extender toch al hebben. Nu hoeven we er alleen maar een kabel tussen te leggen voor het kvm-gebeuren die we toch al hadden.

Voor de switches geldt hetzelfde, 2 CX4 en 2 UTP kabels voor de redundantie en dat is alles kwa bekabeling. Op zich had het ook wel met een enkele 48p-switch gekund en dan een patchpanel aan de andere kant installeren, maar dit leek ons vanuit redundantie gezien een net iets betere oplossing. Kwa pure switchingtijden zal het iets slechter zijn, maar doordat de switches intern sneller zijn dan de oude verwacht ik niet dat we er heel erg veel van merken.
Als we maar 1 of 2Gbit aan bandbreedte zouden hebben voor de koppeling zouden we tijdens netwerkpiekuren (backups e.d.) wel lichte vertragingen kunnen merken.

[Gwaihir]

Die maximale amperages verbazen me. Elk rack met enigszins actieve apparatuur erin gaat toch ruim boven de 8 ampere? Da's (8 x 230 V) nog geen 2000 Watt ! Ook bij 14 ampere per rack (3220W) is, zoals jullie al constateren, het stroomverbruik nu al ruimschoots de bepalende factorvoor wat er in een rack 'past'. Oftewel: wanneer gaat Redbus op de schop?

Computable heeft het ondertussen over racks met blades die tot 25.000W gebruiken (en sommige rekken van de nieuwe supercomputer van SARA trekken 33.000W per stuk). Die blades leken ooit een goed idee omdat ze zo lekker compact zijn, maar ondertussen is dat kennelijk totaal onbelangrijk?

[CyBeR]

Yep. Blades zijn handig voor als je een eigen DC hebt en je hebt daar niet meer genoeg ruimte in, maar wel de mogelijkheid om in enorme koeling te voorzien. D'r zijn namelijk twee grote problemen in zo ongeveer alle DC's op dit moment:

a) aanvoer van stroom (met UPS, diesel backup, etc.)
b) de koeling van al dat geweld

Dat maakt stroom op dit moment het meest hekele punt zo'n beetje: bandbreedte is tot in tientallen gbits te krijgen, ruimte is met 1U dozen en blades ook niet echt een groot probleem meer. Maar stroom...

[Olaf van der Spek]

Neem even contact op met Google en Intel, voor 30 euro per server kunnen ze het verhelpen (schijnt): nieuws: Intel en Google op de bres voor het milieu

[fre0n]

Het probleem is niet zozeer dat ze niet meer Amps kunnen leveren, maar er moet wel voldoende koelcapaciteit zijn om al die Watts het hoofd te bieden. Koeling is de beperkende factor in RB

[Jasper Janssen]

Hoewel de capaciteit van de koeling en de capaciteit van de UPS/generator backup over het algemeen zeer nauw gerelateerd is -- alle energie die erin gaat via de UPS moet er door de koeling uitgehaald worden, en het hebben van een significante imbalans tussen de twee heb je dus niks aan.

[DSmarty]

Wat zijn die energie-opname limieten ontzettend beperkt en gedateerd....

Bij het bedrijf waar ik werk hebben alle 19" kasten standaard 32A ter beschikking met een optie 64A.

Wat heb je aan 46u racks als je slechts 20U kan vullen (daarmee zit je al boven de 8A)....

[burne]

In tegendeel. Het 'enforcen' van die limieten is nieuw, omdat pas de laatste twee jaar ofzo centers zo vol zitten dat de limieten een probleem beginnen te worden. En kankeren op redbus lijkt leuk, maar andere centers zitten met dezelfde 'problemen'. KPN heeft een 'stop' tot het einde van het jaar, er mag geen machine meer bij, omdat de stroom op is, en Nuon een paar jaar nodig heeft om meer stroom te leveren. Dat was geplannend, alleen is het stroomverbruik sneller gegroeit dan 3 jaar terug geplanned, en nu is het op, en moeten de klanten maar even 10 maanden wachten.

[DarkHelmet]

Vallen mij paar zaken op:

Er wordt gesproken van 4 kabels per server
maar mij lijkt, zeker met colocatie dat je nu naar 5 kabels gaat (DRAC in geval van deze Dell servers).
Geen DRAC zou naar mijn idee simpelweg stom zijn.


En waarom geen VMWare gaan gebruiken?

Scheelt hoop in rack ruimte en in energieverbruik.

OK, je hebt wel een flinke aanschaf aan servers of beter zelfs: blades. Maar het schaalt wel veel beter en je downtime kun je ook meer beperken

Nu heeft het nogsteeds veel weg van een hobby omgeving, terwijl Tweakers dit stadium toch al een tijdje geleden ontgroeit is

[moto-moi]

Er wordt gesproken van 4 kabels per server
maar mij lijkt, zeker met colocatie dat je nu naar 5 kabels gaat (DRAC in geval van deze Dell servers).

Er staat Zo heeft op dit moment elke machine tenminste 4 kabels

En waarom geen VMWare gaan gebruiken?

Waarom wel? Onze belangrijkste machines hebben het dusdanig druk dat we elke cpu cycle keihard nodig hebben en andere taken aan zo'n machine toewijzen is dus geen optie, dus VMWare zal ook geen winst geven.

Blades waren geen optie vanwege de hugeass enclosures (wat nu al geen probleem meer zou zijn), en het feit dat zo'n bladeenclosure geen winst oplevert kwa vermogenafname. Verder betekend een bladeenclosure volgens mij niet direct dat je opeens beter schaalt, de lijnen tussen je machines worden alleen extreem kort. (Waarbij ik wel wil opmerken dat we ons niet vreselijk in blades hebben verdiept en ik dus wel ergens een kleine fout in dit verhaal kan hebben gemaakt )

[siepeltjuh]

ESX met vmotion werkt echt zo uber.

Je zet een paar uber rekenapparaten neer, je koppelt de md1000 apparaten tot een vette SAN en downtime is voorbij.

Servertje stuk, je 'dragged' zo je draaiende os naar een andere fysieke host, zonder hickup.

Goed jullie hebben al aardig wat hardware, en voor een dergelijke setup moet je wel flink investeren in nieuwe hardware, maar ik kan me voorstellen dat dat echt uber zou werken.
Extra cpu-cycles ben je niet meer kwijt, omdat ESX direct als host OS wordt geladen.

http://www.youtube.com/watch?v=E_TtHAgRy_s
http://www.youtube.com/watch?v=ZUtmogrGnTQ

[burne]

ESX met vmotion werkt echt zo uber.

Voor iemand die veel dingen doet, en waarvan elk van die dingen te weinig belasting vormen om een volledige eigen machine te rechtvaardigen. 'Consolidatie' is voor tweakers.net geen overweging. Ze hebben moeite genoeg om de load te verdelen over meer dan 1 machine, simpelweg omdat 1 machine het niet trekt.

VMWare lost problemen op die tweakers.net niet heeft. Leuk voor je dat jij er heel blij mee bent, maar probeer je enthousiasme een beetje in de hand te houden. Het is geen universeel wondermiddel en je kunt er niet alles mee oplossen.

[skinnieh]

ESX3.0 heeft een hele lage footprint, het is niet zo dat je 50% van je resources kwijt bent oid. Er zullen heus wel wat krachtpatsers in het rack van T.net zitten, maar alle servers die 100% zitten te pompen continu, dat kan je me ook niet wijs maken.

[ACM]

Bij gebrek aan ervaring met VMware en vergelijkbare omgevingen moet ik het uiteraard wel met mijn inschatting doen.

Maar zelf zie ik liever geen vmware om diverse redenen voor deze machines:
2 loadbalancers
lowlevel networkingperformance, fysieke uitrusting systemen, betrouwbaarheid, etc

5 webservers
performance

2 databaseservers
performance

1 forum-searchserver
i/o

1 fileserver
i/o, grote hoeveelheid data om te beheren

1 backup/loggingserver
i/o-pieken, grote hoeveelheid data om te beheren

De servers die dan eventueel gevirtualiseerd zouden kunnen worden, mijns inziens, zijn de mailserver, de ontwikkelserver en de ircd/overige taken-server... Uiteraard kunnen we ook een SAN aanleggen en de taken voor de forum-searchserver, fileserver en backup/loggingserver samenvoegen, maar daar zal een en ander niet goedkoper van worden. En met de uptimes die wij tegenwoordig halen zie ik eerlijk gezegd ook geen goede reden om er vanuit dat oogpunt meer geld en complexiteit tegenaan te gooien.

Voorlopig is mijn indruk dat we met onze 16 servers met bovenstaande specialisaties er niet zonder (relatief) veel kosten een paar samengevoegd kunnen worden tot minder fysieke systemen.... En uiteraard zijn bovenstaande servers niet continu volluit aan het rekenen, we hebben juist heel bewust overcapaciteit, bijvoorbeeld voor als er weer eens een /.-posting oid komt en we stellen gewoon veel prijs op snel reagerende webpagina's.

Mocht ik het verkeerd hebben, dan hoor ik natuurlijk graag hoe wij een en ander zouden kunnen verbeteren met de toepassing van een omgeving als ESX3.0

[Reactie gewijzigd door ACM op 23 juli 2024 03:43]

[TheBrain]

Als je servertje stuk is dan stoppen ook echt wel alle lopende VM's op die bak

Is voor deze toepassing dus niet echt geschikt aangezien deze servers heel CPU intensief worden gebruikt.

[siepeltjuh]

Die VM`s die stoppen inderdaad, maar worden binnen 10 seconden (via heartbeat) weer opgestart op een andere fysieke server.

In de huidige situatie, moet een admin naar het DC toe om de server te inspecteren te fixxen, of te vervangen, dat duurt uren.

Downtime heb je nihil met ESX, maar t.net doet het voor de performance, ook dit is wel te realiseren, maar wat ik al zei dan moet je dusdanig veel investeren dat het weinig zin meer heeft.

Als het van de grond af aan werd opgebouwd, had ik het wel via ESX gedaan, maar goed de ervaring met dat spul moet er dan ook zijn.

[Robkazoe]

Gaan jullie ook meteen de oude Tweakers.net case badges vervangen met nieuwe of blijft Henk nog even stralen op de (nieuwe) hardware?

[moto-moi]

Zolang die nog niet zijn gemaakt houden we het bij de huidige

[Leftblank]

Wat ik me nu afvraag mbt de stukjes over de kabels is; waarom moet je in godsnaam een kvm hebben bij dit soort servers? Voldoet een SSH verbinding niet, het lijkt mij ersoonlijk dat er op 'n server toch geen GUI zal worden gezet, wat het effect van een muis eraan niet erg veel zinvoller zal maken, me dunkt

[moto-moi]

ssh werkt prima zolang je bak een verbinding heeft en helemaal gestart is. Wat voor kees en mij vaak interessanter is, is het bootproces te zien terwijl het gebeurt. Ook kun je kernelpanics nog vaak op het console zien terwijl de machine al gestopt is met reageren op het netwerk.

[GrooV]

Dit maakt onderhoud plegen veel makkelijker, en productie systemen onderhoud je liever niet vanaf afstand. Tevens als er dan iets gebeurd heb je meteen een console ter beschikking en hoef je niet te gaan prutsen met een monitor karretje

[Bierkameel]

We gaan onze huidige setup dus serieus upgraden, T.net Style

Nou wat een T.net style, vroege werd er zelf nog een server in elkaar geschroeft, tegenwoordig klikken jullie even naar de Dell site om iets te bestellen...

[ACM]

Dat vroeger is wel heel lang geleden hoor... want de nu bijna 4 jaar oude Artemis (eerst 3 oid jaar als apollo) die vervangen wordt was ook al geen zelfbouw meer. Weliswaar niet bij Dell besteld, maar toch echt niet door onszelf in elkaar geschroefd.
Het is nou eenmaal nauwelijks goedkoper, veel lastiger en kwa garantie helemaal een gedoe om zelfbouw te doen. Die tijd kunnen we dan beter besteden aan het fatsoenlijk onderhouden van de systemen, ipv het uberhaupt in elkaar zetten, draaiend krijgen, etc.

[drZymo]

Wow weer een verhuizing. Ben benieuwd of het allemaal vlekkeloos zal gaan.

In ieder geval een leuk servertje die nieuwe Artemis. Als ik zo op Dell.com kijk:
PE1950: 7.500,- euro
MD1000: 8.000,- euro.
Totaal 15.500,- euro .

Vraag me af of dit mede mogelijk gemaakt wordt door VNU .

[ACM]

Wij betalen wel wat minder dan de prijs die je op de website ziet staan hoor Maar op zich zou VNU hier niet voor nodig geweest zijn. Vergeet niet dat VNU dat soort bedragen alleen maar toestaat als er voldoende inkomsten uit Tweakers.net komen om dat soort kosten weer te dekken. Het is natuurlijk niet en nooit hun bedoeling geweest om het als een groot zwart gat te beschouwen waar ze alleen maar geld in kieperen en daar nooit meer wat van terug zien.