Onderwerp: Blade server info

Beste wht-ers,

Stel je hebt vmware esx op een server staan en je wil HA hebben, dan kan je dat dus doen met 2 gelijke servers toch?
Als je een blade server koopt dan heb je die HA toch "eigenlijk" niet meer nodig of zie ik het nu verkeerd?
Bij een bladeserver is alles redundant opgezet en verlies je eventueel alleen capaciteit....

Klopt het wat ik nu zeg of is dit complete bullshit?

Volgens mij zijn blade-servers gewoon losse servers met een bepaalde formfactor. Niets redundant, behalve de voeding.

HA is het niet inderdaad. Al is een beetje blade enclosure wel uitgevoerd met dubbele voedingen en weet ik wat al niet meer. Maar effectief is elke blade een losse server met eigen mobo, processor, geheugen, schijven en dergelijke.

HP Blade servers hebben die oplossing. Daar kan je blades redundant zetten en in failover.

Oorspronkelijk geplaatst door GlobalServe

HP Blade servers hebben die oplossing. Daar kan je blades redundant zetten en in failover.

Alle blades, of bepaalde types? Linkje toevallig? Vind ik wel erg interessant op dit moment!

Ik heb toch het vermoeden dat je dat gebruikt met extra tools zoals VMWare HA oid. Ik heb nog niet eerder gehoord van oplossingen waarbij de load volautomatisch door de CPU's verdeeld wordt over blades.

http://h71028.www7.hp.com/enterprise...-0-22-472.html

Veel lees en kijkwerk

Oorspronkelijk geplaatst door DiedX

Ik heb toch het vermoeden dat je dat gebruikt met extra tools zoals VMWare HA oid. Ik heb nog niet eerder gehoord van oplossingen waarbij de load volautomatisch door de CPU's verdeeld wordt over blades.

Load verdelen over meerdere CPU's heeft ook niets te maken met HA. Dus wat dat er mee te maken heeft weet ik niet.

Zo uit mijn hoofd kan de C serie van HP dat (de B serie weet ik niet). Daar kan een standby blade een blade met problemen overnemen. Hiervoor is ook wel weer de eis dat de blade boot vanaf shared storage. De blade zal dan doen alsof die de andere blade is bij het booten.

Oorspronkelijk geplaatst door bakkerl

Load verdelen over meerdere CPU's heeft ook niets te maken met HA. Dus wat dat er mee te maken heeft weet ik niet.

Zo uit mijn hoofd kan de C serie van HP dat (de B serie weet ik niet). Daar kan een standby blade een blade met problemen overnemen. Hiervoor is ook wel weer de eis dat de blade boot vanaf shared storage. De blade zal dan doen alsof die de andere blade is bij het booten.

Zonder verder in te gaan op LB en HA (hier kunnen we nog wel eens een pilsje op drinken) ziet de rest er veelbelovend uit. Zelf zou ik dan toch (afhankelijk van de applicatie natuurlijk) eerder gaan naar HA door LB (meerdere machines inzetten die elkaars "backup" zijn) in plaats van rekenkracht down-the-drain the smijten.

Maar goed, de vraag van TS is beantwoord denk ik?

Globalserve: ja, maar die booten gewoon een standby server als de hoofdserver faalt nee?

Je hebt altijd een standby blade, dus je moet storage appart hebben van een SAN, je kan bepaalde types wel redundant zetten, maar dan draaien deze niet in standby, we hebben zo een oplossing draaien bij VPK Packaging.

Dat ook met een vmware is HA mode.

Ik heb gekeken op de hp site maar of ik nou gelijk zie welke bladeserver failover kan doen...
Wat ik dus eigenlijk zoek is een manier om de standaard esx te kunnen gebruiken met een bladeserver waarmee ik dus een goede failover oplossing kan krijgen.

Misschien toevallig een type nummer voor me?
Wil namelijk even kijken hoe hoog te kosten ongeveer zullen zijn.

Waarom wil je per-se blade hebben?

Door middel van VMotion en storage op een
SAN bijvoorbeeld, kan je een virtuele server
héél snel verhuizen van één blade naar een
andere. Enkel de pointer verhuist van blade,
de virtuele machine blijft gewoon op de SAN.
Dit kan zelf geautomatiseerd worden denk ik.

HA zelf is eigenlijk iets heel anders, de service
draait simultaan op twee servers, de pointer
(IP adres) verhuist van de ene naar de andere
server.

HA zou ik persoonlijk niet op blades draaien.
Mijn persoonlijke ervaring met HA was enkel
met firewalls (pf onder OpenBSD met CARP).