Why Blade Servers are the Wrong Choice

http://www.petri.com/blade-servers-are-the-wrong-c...

Hvad siger i?

Personligt er jeg ikke så begejstret for blade servere.. Det ekstra lag af administration er overflødigt imo.
Mit udgangspunkt er virtualisering med Hyper-V... Jeg er ikke sikker på hvordan VMware eller andre gør det, men i Windows Server 2012 R2 kan jeg lave converged networking direkte i OS'et i stedet for at bruge HP Virtual Connect og hvad de ellers kaldes.

#1

Jeg synes ikke at der er helt belæg for konklusionen.

Det starter ganske fornuftigt med en konstatering af at blades giver mere power per rack men at man med rack servere har mere frihed til at blande hardware fra forskellige leverandører.

Det er jo rigtigt. For rigtigt mange firmaer er det entydigt et plus da de ikke er interesseret i at blande hardware fra forskellige leverandører af support hensyn.

Men resten er mest Windows/Hyper-V specifikt. Der er tilsyneladende nogle problemer med driverne til Emulex NICs. Og der mangler support for hardware converged networking.

Det er vel mere et Windows/Hyper-V problem end det er et blade problem. VMWare har så ikke disse problemer (men sikkert nogle andre problemer).

#2

Nå du nåede at kommenterer på det inden jeg.

Der er også mindst en fejl i hans nedsabling af blades.
På hp blades centre kan man bruge cisco switches, hvis man den slags lyster. Man er ikke som han påstår nødsaget til at køre hp switches på hp blades.

Sidst jeg havde fingerne i et IBM bladecenter var det med nortel switches.

Når jeg ser på den side er jeg ikke overrasket over at de anbefaler hyper-v. Der er nogle få VMware artikler men ellers er resten MS specifikt. Hvilket vel også forklarer hvorfor en MS konsulent læser siden. Det lader til at der er en helt enorm mængde MS specifik viden på det site.

arne_v (2) skrev:

Det er jo rigtigt. For rigtigt mange firmaer er det entydigt et plus da de ikke er interesseret i at blande hardware fra forskellige leverandører af support hensyn.

Det er selvfølgelig et klart plus at der kun er 1 leverandør. Jeg mener så ikke det opvejer de begrænsninger det sætter og det ekstra lag af administration det giver i converged networking og ikke mindst ved opdateringer (meget specifikt HP).

arne_v (2) skrev:

Men resten er mest Windows/Hyper-V specifikt. Der er tilsyneladende nogle problemer med driverne til Emulex NICs. Og der mangler support for hardware converged networking.

Det er vel mere et Windows/Hyper-V problem end det er et blade problem. VMWare har så ikke disse problemer (men sikkert nogle andre problemer).

Der har været nogle tegn på at VMware også er lidt ramt af de samme problemer med VMQ på Emulex, dog ikke i samme størrelsesorden som Hyper-V.

Hubert (3) skrev:

Der er også mindst en fejl i hans nedsabling af blades.
På hp blades centre kan man bruge cisco switches, hvis man den slags lyster. Man er ikke som han påstår nødsaget til at køre hp switches på hp blades.

Sidst jeg havde fingerne i et IBM bladecenter var det med nortel switches.

Korrekt, den undrede jeg mig også over.

Hubert (3) skrev:

Når jeg ser på den side er jeg ikke overrasket over at de anbefaler hyper-v. Der er nogle få VMware artikler men ellers er resten MS specifikt. Hvilket vel også forklarer hvorfor en MS konsulent læser siden. Det lader til at der er en helt enorm mængde MS specifik viden på det site.

Der er nu ikke rigtig nogen anbefalinger så vidt jeg lige har set? Petri har mange Microsoft relaterede emner, men der huserer nu også VMware og Citrix folk, omend de ikke er lige så aktive som den kære Aidan Finn :)

Det var nu heller ikke så meget en diskussion om VMware vs Microsoft, men blade servere vs rack servere. Linket var bare inspiration ;)

Magten (4) skrev:

Det er selvfølgelig et klart plus at der kun er 1 leverandør. Jeg mener så ikke det opvejer de begrænsninger det sætter og det ekstra lag af administration det giver i converged networking og ikke mindst ved opdateringer (meget specifikt HP).

Nu har jeg ikke rodet med blades i en 3-4 år. Men er der virkelig mere bøvl i at opdate mgmt på et bladecenter end der er på alt det ilo mgmt sjov der findes på en server nu om dage?

Der har været nogle tegn på at VMware også er lidt ramt af de samme problemer med VMQ på Emulex, dog ikke i samme størrelsesorden som Hyper-V.

Da jeg i "gamle dage" var netværksadministrator hos et hosting selskab her i landet havde vi 5-6 vmware klustre bestådende af både IBM og HP blades. Dem var der så vidt jeg ved ikke problemer med. VI brugte så også altid cisco switches på både hp og ibm blades

Der er nu ikke rigtig nogen anbefalinger så vidt jeg lige har set? Petri har mange Microsoft relaterede emner, men der huserer nu også VMware og Citrix folk, omend de ikke er lige så aktive som den kære Aidan Finn :)

Artiklen kan nærmest beskrives som en reklame for hyper-v.

Det var nu heller ikke så meget en diskussion om VMware vs Microsoft, men blade servere vs rack servere. Linket var bare inspiration ;)

Det ville også blive en kort diskution. De folk jeg kender der arbejder med virtualisering i MS huse siger at hyper-v stadig ikke er noget de bruger tid på. En af dem er endda gået så langt som til at sige at han mener det er decideret ringe i forhold til vmware. Jeg selv har kun brugt hyper-v playeren eller hvad den nu hedder en enkelt gang. Når jeg kommer ud i min nuværende rolle som konsulent er det også 9½ gange ud af 10 vmare selvom man har en såkaldt ms strategi.

Om man skal vælge blades eller rack server afhænger vel som alt andet af hvad man skal bruge. Skulle jeg i dag bygge et hw setup til virtualisering, ville jeg bruge blades.

Skulle jeg derimod bygge et fw cluster ville jeg vælge rack server løsningen.

Hubert (5) skrev:

Nu har jeg ikke rodet med blades i en 3-4 år. Men er der virkelig mere bøvl i at opdate mgmt på et bladecenter end der er på alt det ilo mgmt sjov der findes på en server nu om dage?

Nu har jeg kun haft fingrene i HP bladecentre, men de har godt nok været bøvlet at opdatere firmware osv på.

Hubert (5) skrev:

Da jeg i "gamle dage" var netværksadministrator hos et hosting selskab her i landet havde vi 5-6 vmware klustre bestådende af både IBM og HP blades. Dem var der så vidt jeg ved ikke problemer med. VI brugte så også altid cisco switches på både hp og ibm blades

Jeg har også set massere af VMware clustre på blade servere, jeg har dog ikke prøvet at sætte dem op så jeg kender ikke rigtig til den del :)
Vi havde dog heller ikke de store problemer med de clustre vi havde kørene på mit gamle job. Det var også med Cisco switche.

Hubert (5) skrev:

Om man skal vælge blades eller rack server afhænger vel som alt andet af hvad man skal bruge. Skulle jeg i dag bygge et hw setup til virtualisering, ville jeg bruge blades.

Skulle jeg derimod bygge et fw cluster ville jeg vælge rack server løsningen.

Hvordan ville du lave netværket til virtualisering så? Jeg har ikke rigtig styr på hvad den bedste løsning er til VMware m.fl. men jeg har på fornemmelsen det er her forskellen ligger.

De Hyper-V clustre jeg har lavet på bladecentre har serverne fået 2 NIC's hver som så bliver teamet i OS'et. Derefter laver jeg virtuelle NIC's til management(/VM's), cluster heartbeat og live migration, og tildeler BW til hver enkelt.

Fordi jeg laver teams mv. i OS'et bliver det smarte ved blades (muligheden for at splitte netværk op og tildele BW til hver enkelt adapter) ret overflødigt og kun et ekstra lag af administration.

Magten (6) skrev:

Hvordan ville du lave netværket til virtualisering så? Jeg har ikke rigtig styr på hvad den bedste løsning er til VMware m.fl. men jeg har på fornemmelsen det er her forskellen ligger.

De Hyper-V clustre jeg har lavet på bladecentre har serverne fået 2 NIC's hver som så bliver teamet i OS'et. Derefter laver jeg virtuelle NIC's til management(/VM's), cluster heartbeat og live migration, og tildeler BW til hver enkelt.

Fordi jeg laver teams mv. i OS'et bliver det smarte ved blades (muligheden for at splitte netværk op og tildele BW til hver enkelt adapter) ret overflødigt og kun et ekstra lag af administration.

Ohh det er sgu så længe siden at jeg dårligt kan huske hvordan man gør. Umidlbart ser jeg ikke den store forskel på den måde du beskriver og den måde jeg husker at man laver det på i vmware.

Jeg kan ikke umidlbart se at det skulle være smartere at oprette virtuelle nics på serveren istedet for på det "virtuelle" lag eller hypervisor laget om man vil.

På vmware kan jeg oprette virtuelle switches og tilknytte de virtuelle servere jeg har brug for til en given virtuel switch. Hvis jeg ikke tager helt fejl så er dette også muligt på hyper-v. Jeg mener da ihvertfald det var det jeg kom frem til da jeg havde en kunde der havde en forespørgsel omkring et produkt jeg arbejder med på hyper-v. ESX er desværre ikke en mulighed, men klart at foretrække i det her tilfældet grundet de problemer Debian har haft med hyper-v.

#7
Hmm, det lyder lidt som om det er samme vej frem, bortset fra det med de virtuelle NIC's.
Reelt laver jeg en switch i SCVMM med de virtuelle NIC's, og tilknytter så den til fysiske NIC's (og teamer dem) på mine hosts. Fordelen er at jeg kan administrere mine hosts og deres netværk udelukkende fra SCVMM i stedet for at skulle have fat i bladecenteret også.

Men det er nok deri forskellen ligger, og uden at kunne overskue det helt vil jeg tro det også giver en fordel at bruge blade servere til VMware.

Edit: Det er jo selvfølgelig stadig bare min mening - jeg ved at der er massere af Hyper-V folk der foretrækker blade servere, så det afhænger ikke af hypervisor. Det var bare et lille sidespor jeg kom ud på :)

#8

Alt mgmt foregår i vmware software. Vcenter hedder det vist i dag. Bladecenteret skal blot præsentere nics til ESXi ganske som på en rack server gør. Ud fra hvad du har skrevet så vil der ikke være nogen særlig forskel på et bladecenter og en rackserver

#9
Nu har jeg som sagt kun rodet med HP blades, men der skal jeg altså på bladecenteret og konfigurere NIC's (antal, hastighed, vlan's osv) til hver enkelt blade inden jeg kan tage serveren i brug.

Magten (10) skrev:

#9
Nu har jeg som sagt kun rodet med HP blades, men der skal jeg altså på bladecenteret og konfigurere NIC's (antal, hastighed, vlan's osv) til hver enkelt blade inden jeg kan tage serveren i brug.

Det du taler om her er switchkonfigurationen på blade centeret. Det er jo ikke noget du kommer uden om bare fordi du kører med x antal rack server i et cluster.

#11
Men ikke desto mindre må VLANs mm. da skulle konfigureres i både bladecenter switche og på LAN switche.

Men det kan da godt ske det bare er fordi opgaven flyttes fra netværksfolk over til mig at jeg synes det er mere besværligt ;)

Magten (12) skrev:

#11
Men ikke desto mindre må VLANs mm. da skulle konfigureres i både bladecenter switche og på LAN switche.

Men det kan da godt ske det bare er fordi opgaven flyttes fra netværksfolk over til mig at jeg synes det er mere besværligt ;)

Vlans er højst sansynligt allerede på de næste switche i rækken. De skal selvfølgelig defineres på blade switchene også. Men er bliver det typisk gjort engang for alle porte på hver switch.
Altså ikke noget der er det store arbejde i. For mig at se er der mindre arbejde i at konfigurere alle porte på en enkelt switch engang kontra at skulle gøre det hvergang man opretter en ny virtuel server.

Her ud over kan du så tage performance med i ligningen og så står du altså endnu dårligere på din rent virtuelle platform.

Magten (4) skrev:

Det er selvfølgelig et klart plus at der kun er 1 leverandør.

Lad mig lige bidrage med en historie fra min egen fortid, der illustrerer at det kan være et klart minus, at der kun er en enkelt leverandør. Den handler ikke om blade servere, men lignende problematikker kan opstå i alle situationer, hvor der kun er en enkelt leverandør.

Vi havde et problem med et system, der ikke leverer den ydelse det burde. Vi havde et meget klart billede af, hvorfor vi ikke har den ønskede ydelse. Et antal drev er ude af drift, og mange af de drev der er i drift kører kun med 73% af den specificerende hastighed.

Der er en ganske klar aftale med leverandøren om, at vi blot skal oprette RMA sager på de defekte drev.

Men leverandøren leverer ikke erstatninger for de defekte drev så hurtigt som aftalt. Så vi har stakkevis af drev ude af drift og endnu flere med dårlig ydelse som venter på at blive taget ud af drift så snart producenten har leveret nye drev til erstatning for de første.

Det bliver ikke bedre af, at vi også oplever at de nye drev vi modtager når vi har sendt et defekt retur er DOA. På et tidspunkt bliver jeg bedt om at undersøge et af de tilfælde nærmere, det viser sig at det er tredje gang vi har lavet en RMA sag på det pågældende serienummer.

Vi er nødt til at finde ud af hvad vi kan gøre ved situationen for at levere den lovede ydelse til vores kunder. En manager påpeger at når den reelle udnyttelse per drev er lavere end forventet, så er det ikke andet for end at vi må købe mere hardware.

Vi er på det tidspunkt i en situation, hvor vi kun har en enkelt leverandør.

Hvad ovennævnte leverandør har præsteret vil jeg betragte som uacceptabelt ringe. Det må have en konsekvens for leverandøren. Hvad var konsekvensen i den konkrete situation? Mersalg!

Havde man i det mindste haft et setup med et mix af hardware fra to leverandører, så var den næste ordre åbenlyst være blevet placeret hos en anden leverandør.

Der er også fordele ved at holde sig til en enkelt leverandør, man må opveje fordele og ulemper imod hinanden.