Gathering of Tweakers

clusteren dus, wat zijn de optie's om clusteren met virtuale machines te combineren?

aangezien clusteren alleen kan met server 2003, kan je op die geclusterde machine dan ook weer een virtule machine zetten?

DNS en DHCP zijn geen services die je gaat clusteren; dit zijn namelijk services die je gewoon dubbel in je netwerk kunt plaatsen. Wanneer één DNS of DHCP uitvalt, krijgt de andere server automagisch alle verzoeken te verwerken.

Dit zijn overigens wel servers die zich uitstekend laten virtualiseren. Maar niet met het idee wat jij in je eerste post aangeeft: maintenance zonder down-time. Wanneer je beide virtuele servers op één machine wilt zetten, zullen ze beide down moeten wanneer je onderhoud wilt plegen op de host server. Je zou dan een virtuele infrastructuur moeten hebben met minimaal 2 VMware servers, maar dan is het weer overbodig om te virtualiseren, tenzij je buiten deze 2 servers nog andere servers wilt virtualiseren.

Zaken die geclustered worden zijn: Exchange, SQL, IIS. Dat heb je in jouw opdracht waarschijnlijk niet nodig.
Een cluster bouwen om daar weer VMware op te draaien is geen goed idee. Ik denk dat het zelfs niet mogelijk is, sowieso niet met MS-Clustering.

Abom wijzigde dit bericht 18-09-2006 11:08 (17%)

quote:

Abom schreef op maandag 18 september 2006 @ 11:01:
DNS en DHCP zijn geen services die je gaat clusteren; dit zijn namelijk services die je gewoon dubbel in je netwerk kunt plaatsen. Wanneer één DNS of DHCP uitvalt, krijgt de andere server automagisch alle verzoeken te verwerken.

Dit zijn overigens wel servers die zich uitstekend laten virtualiseren. Maar niet met het idee wat jij in je eerste post aangeeft: maintenance zonder down-time. Wanneer je beide virtuele servers op één machine wilt zetten, zullen ze beide down moeten wanneer je onderhoud wilt plegen op de host server. Je zou dan een virtuele infrastructuur moeten hebben met minimaal 2 VMware servers, maar dan is het weer overbodig om te virtualiseren, tenzij je buiten deze 2 servers nog andere servers wilt virtualiseren.

Zaken die geclustered worden zijn: Exchange, SQL, IIS. Dat heb je in jouw opdracht waarschijnlijk niet nodig.
Een cluster bouwen om daar weer VMware op te draaien is geen goed idee. Ik denk dat het zelfs niet mogelijk is, sowieso niet met MS-Clustering.

dat waren ook voorbeelden, het maakt niet uit wat voor server er draait.(nouja het blijkt dat het dus wel uitmaakt, alleen dat is niet van belang voor mij)
Dan zal ik even overleggen dat hetgeen wat men wil dus niet kan.
iig bedankt allemaal voor jullie reactie's

1) Nou ik laat het voorlopig maar even bij een winxp pc met een virtuele vista
van daaruit ga ik wel verder kijken wat nog meer mogenlijk is.
Ik heb hier een VMware workstation tot mijn beschikking dus daar ga ik eerst wel even mee aan de gang.
2) Als 2e opdracht wil ik iets gaat maken met Windows server 2003 met 2 pc's/servers dat als er dus één uitvalt de andere het overneemt, en dat één van de twee dus als backup gaat functioneren. (of iets in deze richting)

Hoe ik dat ga realiseren weet ik nog niet precies, ik wil het hier opzich wel vragen, maar ik krijg een beetje het gevoel dat jullie de helpdesk zijn, en dat is natuurlijk niet de bedoeling.

dus ik probeer het zelf wel een beetje uit te vogelen, als jullie mij een beetje in de goede richting drukken gaat het wel lukken.

koekoek2003nl wijzigde dit bericht 18-09-2006 14:11 (24%)

quote:

iis5_rulez schreef op vrijdag 18 augustus 2006 @ 17:02:
mkb server die 3 servers gaat draaien. buiten het reeds genoemde licentie probleem, zal je ook een flink stevigere bak moeten aanschaffen >> weer meer kosten.[/b]

Tot zover heb je gelijk.

quote:

De voordelen zijn minimaal:
- beheer kosten gaan niet omlaag, je beheert nog net zoveel servers. het stukje winst wat je pakt met bijv. backup verlies je weer met onderhoud van je vm software

Je beheert echter nog maar 1 hardware platform. Alle VM's hebben dezelfde hardware. Onderstaande replies gaan trouwens uit van een middelgrote tot grote omgeving met shared storage (FC of IP)

quote:

- hardware kosten gaan wel omlaag. Maar als je het goed wilt opzetten, dan is dat ook weer niet zo veel dat je daar echt veel mee terug verdient (vette bakken en meerdere systemen zodat vm's verplaatst kunnen worden).

Op dit moment schaf ik voor vervanging DNS & Mail-passthrough een nieuwe server aan.
Laten we een middensysteem nemen; HP DL380/G4 met 1GB geheugen. 2GB is standaard bij ons bij Linux en Windows, 4GB voor Netware. 2x 36GB schijf, aangezien kleiner niet meer is aan te schaffen. Liever schaffen we normaliter 72GB aan, omdat dit standaard is, en dan heb je geen tig soorten reserveschijven nodig.
Dan ben ik rond om de 3000E kwijt.

Stel ik wil een extra processor en 8GB geheugen, dan kost met dat 1000 tot 1600 euro meer.

Op een Dual Xeon 3.2GHz (Woodcrest) met 8GB geheugen kan ik ongeveer 10 virtual machines draaien. Een DNS en sendmail server heeft niet meer dan 512MB geheugen en 512MB schijfruimte nodig. Ik heb het dan over een kale Debian installatie.

Als je een routering en firewall server wil hebben, dan is het met VMWare heel makkelijk om een extra interface toe te voegen in plaats van dat je met VLAN drivers aan de slag wilt. Geheugen:1GB, schijfruimte; 512MB tot 1GB. Normaliter schaffen we hier ook een server aan van 3000E.

En ga zo maar door. Wij hebben twee windows CRON werkstations. Die zijn beiden gevirtualiseerd. Uitsparing; 1000 Euro.

quote:

- Heb je het goed geschaald, dan kan je alle vm's overswitchen en (hardware) werkzaamheden verrichten op de virtualisatieserver op normale werkuren. Maar dit houdt tevens in dat je dus een grote overcapaciteit moet hebben, wat weer het doel van virtualisatie voorbij schiet.

Hoezo grote overcapaciteit? Je kan een kleine migratieserver erbij nemen. Dat kan zelfs met reeds afgeschreven server, zolang de HBA's er maar in passen. Onze HBA's kunnen in praktisch alle vormen van PCI-X gestoken worden, en zeker die van 1 generatie eerder.
Stel dat je 5 tot 8 guests hebt per host en een farmpje van 4VMWare servers(en dan de ene backup), dan migreer je ze met Virtual Center naadloos naar de andere VMWare servers. De impact op de performance is minimaal.

quote:

De naar mijn idee zwaarder wegende nadelen:
- Je introduceert extra spofs (single point of failures). Bij vmware gsx versie zijn dat er 2, base os en vmware zelf. Als 1 van die 2 ermee kapt, ben je niet 1 servertjes kwijt, maar alle machines die op die host draaide. Dit is 1 van de redenen dat vmware alleen de ESX versie aanraadt voor virtualisatie.

Het OS mag je niet onder SPOFs gerekend worden. Iedereen die denkt dat 1 DNS server genoeg is, is niet goed wijs. Natuurlijk kan het zijn dat je omgeving zo klein is dat het geen nut heeft er twee neer te zetten, maar ik heb tegen de 1500 werkstations in beheer. Dan moet je er gewoon twee hebben. VMWare raadt natuurlijk ESX aan, want ESX kost meer en ze verdienen er meer geld aan. Daarnaast is het probleem van een host OS dat er vaker security patches op geapplied moeten worden en dat het meer onderhoud kost.

quote:

- hardware probleem (vnl. server in 1 keer down) >> ben je dus gelijk meerdere servers kwijt. Tuurlijk kan je alles redundant maken, maar het zal niet de eerste keer zijn dat het toch niet zo redundant was als gedacht of dat het niet zo werkt als het zou moeten. De kans is klein, maar de shit is groot als het wel gebeurt.

Met VMWare Virtual Center kan je een DivX/XVid/H.264 Film afspelen, de stekker van de hardware eruit trekken, de Virtual Machines worden naadloos omgegooid naar een andere server, en het filmpje schokt niet eens! Dit heb ik niet alleen in een demo gezien, maar ook zelf geprobeerd. Om dit met H.264 te proberen is het wel aan te raden om een werkstation met een Gbit verbinding te hebben btw .

quote:

(issue als je slecht geschaald hebt: Stel je hebt alles mooi op een raid-5 draaien. 5 vm's draaien erop. Wat denk je dat er gebeurt met je rebuild times van je raid 5 als er een 1 schijf klapt?)

De rebuild tijden blijven hetzelfde. Daar wordt in de bouw van de controllers wel rekening mee gehouden. Een goede SCSI controller merkt er niets van, of redirect processorkracht naar rebuilden en geeft gewone schrijfacties minder voorrang. Daarnaast zou dit probleem dan moeten spelen op iedere drukke fileserver.

[quote]Waarvoor ik virtualisatie wel zou gebruiken:
- testomgevingen. Fantastisch dat je alles snel en makkelijk kan opzetten.
- als passive node van een active-passive cluster. 10 echte servers die active draaien en een vmserver, die geschaald is om 2-3 servers tegelijkertijd over te nemen. Hier heb je echte winst. Spaart je veel hardware uit, voor machines die eigenlijk niets doen.[/quote]
Voor testdoeleinden pak ik liever VMWare Workstation of GSX.
2 of 3 machines per host? Dat vind ik vrij weinig. Wij draaien er gemakkelijk 10 tot 15. Dit hangt uiteraard van de hardware af, maar over het algemeen is processorcapaciteit het probleem niet bij de servers, maar geheugen. Zolang je maar genoeg geheugen hebt, kan je heel veel door blijven schalen.
Als voorbeeld een screenshot van een van onze ESX servers.


Dit is er maar een van de drie. Onze eerste. Morgen ga ik het geheugen uitbreiden naar 16GB

quote:

Met VMWare Virtual Center kan je een DivX/XVid/H.264 Film afspelen, de stekker van de hardware eruit trekken, de Virtual Machines worden naadloos omgegooid naar een andere server, en het filmpje schokt niet eens!

Hoe stel je je dit voor? Je host gaan spontaan dood en andere hosts houden de VM gewoon online?
VMotion kan dit alleen wanneer je zelf die move uitvoerd en dan pas de host uit zet. ESX3 heeft load balance meuk aanboord wat dit automatisch doet volgens mij, maar dan nog...wanneer je host onderuit gaat, liggen alle guests ook op hun gat.

Dan zou het toch eigenlijk in moeten houden dat er continu een synchronisatie van de virtuele servers plaats moet vinden?

quote:

Abom schreef op maandag 18 september 2006 @ 11:01:
DNS en DHCP zijn geen services die je gaat clusteren; dit zijn namelijk services die je gewoon dubbel in je netwerk kunt plaatsen. Wanneer één DNS of DHCP uitvalt, krijgt de andere server automagisch alle verzoeken te verwerken..

ummm dhcp is juist een voorbeeld van een service die je wel zou kunnen clusteren. Dit is namelijk helemaal niet zo makkelijk 2 maal op 1 subnet neer te zetten.

Stel je gebruikt 2 dhcp servers met alle bij 50% van de adressen (c klasse). nu heb je 150 hosts en 1 dhcp server gaat down, wat dan? 25 nodes, dus zonder ip adres. Met clustering heb je dus wel je hele reeks beschikbaar als er 1 node uitvalt...

dns is idd onzin, zeker wanneer de zone ad integrated is.

quote:

iis5_rulez schreef op woensdag 20 september 2006 @ 16:36:
[...]


ummm dhcp is juist een voorbeeld van een service die je wel zou kunnen clusteren. Dit is namelijk helemaal niet zo makkelijk 2 maal op 1 subnet neer te zetten.

Stel je gebruikt 2 dhcp servers met alle bij 50% van de adressen (c klasse). nu heb je 150 hosts en 1 dhcp server gaat down, wat dan? 25 nodes, dus zonder ip adres. Met clustering heb je dus wel je hele reeks beschikbaar als er 1 node uitvalt...

dns is idd onzin, zeker wanneer de zone ad integrated is.

Huh? Als 1 dhcp host down is verliezen toch niet ineens alle nodes hun connectie?
Ze gaan halverwege hun leasetime proberen te renewen en als dat niet lukt houden ze hun IP tot het einde van de lease.
Een gangbare leasetime is 3 dagen, dus als je tweede DHCP server in dat geval niet langer dan 3 dagen down gaat is er niks aan het handje!

DHCP clusteren vind ik persoonlijk absolute onzin, een beetje slim je scopes, reservations, en lease time instellen is voldoende!

quote:

Asteroid9 schreef op woensdag 20 september 2006 @ 16:53:
[...]


Huh? Als 1 dhcp host down is verliezen toch niet ineens alle nodes hun connectie?
Ze gaan halverwege hun leasetime proberen te renewen en als dat niet lukt houden ze hun IP tot het einde van de lease.
Een gangbare leasetime is 3 dagen, dus als je tweede DHCP server in dat geval niet langer dan 3 dagen down gaat is er niks aan het handje!

DHCP clusteren vind ik persoonlijk absolute onzin, een beetje slim je scopes, reservations, en lease time instellen is voldoende!

machines die aanstaan idd, die zullen het niet direct merken. Machines die net aangezet worden, die zijn het haasje... (je server gaat niet plat om 5 uur 's avonds, maar 's ochtend vlak voordat de mensen beginnen... murphy's law )

in ideale situaties zorg je dat je genoeg ruimte hebt. Echter ik ben het vaak genoeg tegengekomen dat scopes nokkie vol zaten en ook niet een twee drie een extra of ander subnet gecreeert of het bestaande subnet vergroot kan worden.

dhcp clusteren garandeert simpelweg een grotere beschikbaarheid dan je scopes verdelen over 2 servers, maar het is zeker niet altijd noodzakelijk om toch een goede beschikbaarheid te halen.

iis5_rulez wijzigde dit bericht 20-09-2006 17:11 (4%)

quote:

iis5_rulez schreef op woensdag 20 september 2006 @ 17:09:
[...]


machines die aanstaan idd, die zullen het niet direct merken. Machines die net aangezet worden, die zijn het haasje...
in ideale situaties zorg je dat je genoeg ruimte hebt. Echter ik ben het vaak genoeg tegengekomen dat scopes nokkie vol zaten en ook niet een twee drie een extra of ander subnet gecreeert is of het bestaande subnet vergroot kan worden.

dhcp clusteren garandeert simpelweg een grotere beschikbaarheid dan je scopes verdelen over 2 servers, maar het is zeker niet altijd noodzakelijk om toch een goede beschikbaarheid te halen.

Als ze uit staan is dat normaliter nog geen probleem, tenzij ze echt een week of meer uit gestaan hebben (afhankelijk van je leasetime)
Printers en andere devices zijn wel eens wat kritischer, dat klopt.

Downtime van je DHCP server moet je toch zien te voorkomen, maar bij calamiteiten heb ik zonder meer zo'n machine binnen 4 uur weer in de lucht.
In die periode hoef je geen noemenswaardige problemen bij je dhcp clients te verwachten, en alleen daarvoor ga ik niet aan de hele rompslomp van een DHCP cluster beginnen.
En dan nog beschermt dat cluster je enkel tegen hardware uitval, en dat is op eenvoudiger manieren op te lossen...
In mijn geval is dat ESX, enkel als het SAN doodgaat heb ik een probleem, maar dat lijkt me duidelijk...

quote:

In mijn geval is dat ESX, enkel als het SAN doodgaat heb ik een probleem, maar dat lijkt me duidelijk...

Is dat een geaccepteerd risico?

quote:

Asteroid9 schreef op woensdag 20 september 2006 @ 17:16:
[...]


Als ze uit staan is dat normaliter nog geen probleem, tenzij ze echt een week of meer uit gestaan hebben (afhankelijk van je leasetime)
Printers en andere devices zijn wel eens wat kritischer, dat klopt.

hier maak je toch echt een grote vergissing.
Bij het aanzetten van een client zal die aan de dhcp server om een ipnummer vragen en als de lease nog niet verstreken is, zal dit zijn oude ip nummer zijn. Maar bij geen response van de server neemt de client niet zomaar het oude ip nummer over. Geen ip of een ipipa adres is het gevolg...

quote:

Downtime van je DHCP server moet je toch zien te voorkomen, maar bij calamiteiten heb ik zonder meer zo'n machine binnen 4 uur weer in de lucht.
In die periode hoef je geen noemenswaardige problemen bij je dhcp clients te verwachten, en alleen daarvoor ga ik niet aan de hele rompslomp van een DHCP cluster beginnen.
En dan nog beschermt dat cluster je enkel tegen hardware uitval, en dat is op eenvoudiger manieren op te lossen...

nah er zijn wel meer oorzaken te bedenken. 4 uur niet werken voor 50 man... wordt je baas niet blij van kan ik je verzekeren . Ik ben het wel met je eens dat het een afweging is van risico's of je dit doet of niet.

quote:

In mijn geval is dat ESX, enkel als het SAN doodgaat heb ik een probleem, maar dat lijkt me duidelijk...

ook hier weer het ongelovelijk grote vertrouwen in vmware zelf, maar ik zal er verder niet op in gaan

quote:

iis5_rulez schreef op woensdag 20 september 2006 @ 17:28:
[...]


hier maak je toch echt een grote vergissing.
Bij het aanzetten van een client zal die aan de dhcp server om een ipnummer vragen en als de lease nog niet verstreken is, zal dit zijn oude ip nummer zijn. Maar bij geen response van de server neemt de client niet zomaar het oude ip nummer over. Geen ip of een ipipa adres is het gevolg...

Zou je nog wel eens gelijk in kunnen hebben, op zich wel de moeite om nog eens in te duiken.
Maar daar hadden we dus de 2-server (non-cluster) setup voor, tenzij de tweede scope vol is levert dat dus weinig problemen op.

quote:

nah er zijn wel meer oorzaken te bedenken. 4 uur niet werken voor 50 man... wordt je baas niet blij van kan ik je verzekeren . Ik ben het wel met je eens dat het een afweging is van risico's of je dit doet of niet.

Dat is een correcte berekening, maar 4 uur gaat het nooit worden. Zie ook mij bovenstaande opmerking over de tweede server, enkel bij een volle scope moeten we actie ondernemen.
(Hier in het bedrijf geen issue trouwens, maar dat terzijde)
Een DHCP service kunnen we letterlijk in 10 minuten up and running hebben, creer bijvoorbeeld alvast een tweede service die je bij calamiteiten direct kunt authoriseren.

quote:

ook hier weer het ongelovelijk grote vertrouwen in vmware zelf, maar ik zal er verder niet op in gaan

Dit is het virtualisatie topic, dus een respons lijkt me nog wel op z'n plaats.
Ook al storten al onze ESX hosts gelijktijdig in: een install from scratch kost 10 minuten, we gebruiken een PXE boot met config file, eventueel is reserve hardware altijd aanwezig.
Filesystem (VMFS) corruptie zou theoretisch ook voor kunnen komen, indien niet te herstellen dan moeten we dat volume restoren van tape, inderdaad uiterst vervelend.

Dat zijn 2 serieuze grote risico's, maar op fysieke hardware zijn de risico's net zo groot, zo niet nog groter.
VMware levert slechts 1 extra pof op, en dat is met VMotion + reserve capaciteit voor 99% te ondervangen.
Alle overige risico's zijn er met fysieke hardware net zo goed.

Om er even op door te gaan:
We zijn nu bezig met een disaster recovery scenario, en dan wordt het leuk:

Fysieke servers, benodigde uitwijk hardware:
10* server A, merk HP, type XX, met specificaties aaaa, bbbb, cccc
20* server B, merk IBM, type SS, specificaties bbbb, cccc
25* server C, merk Dell, type AA, met specificaties aaaa, bbbb, cccc
(plus de nodige SAN handel)

Virtuele servers, benodigde uitwijk hardware:
20* ESX certified hardware, met wat minimum specificaties (merk & type onbelangrijk, alle grote merken zijn ondersteund)
(plus de nodige SAN handel)

Verschil in kostenplaatje met je uitwijkpartner: factor 3 of meer.
Wellicht gaan we de uitwijk hardware zelfs gewoon aanschaffen en deze in een ander kantoor of in een datacenter optuigen.

Ook hoef je je uitwijkcontract niet continu aan te passen, na verloop van tijd laat je een paar extra servers opnemen, dat is alles.
Servers kaal installeren gaan we dan ook niet doen, VM diskfiles van backup terugzetten, booten en we zijn in de lucht.
Als fallback hebben we een scenario om met een kale OS installatie en traditionele backups te restoren, maar dat gaat een veelvoud aan tijd kosten.

Ja, ik ben behoorlijk VMware minded, maar dat komt omdat ik het hier live gebruik en ik er dagelijks massale voordelen mee tegenkom.
Oudere hardware uitfaseren? Nieuwe server plaatsen, VM's overpompen en klaar!

Iedereen heeft uiteraard zijn eigen mening, maar virtualisatie is niet voor niks zo enorm in opmars, en tot dusver heb ik nog niemand serieuze nadelen horen noemen, in elk geval niet voor de wat grotere omgevingen...

quote:

djluc schreef op woensdag 20 september 2006 @ 17:24:
[...]
Is dat een geaccepteerd risico?

Ja en nee, op dit moment is het SAN niet dubbel uitgevoerd. Uiteraard wel een dik supportcontract maar nog geen redundancy behalve in het apparaat zelf (IBM ESS)
Binnen 4 uur hebben we een gerepareerd of vervangend SAN, maar de restore zal wel aardig tijd gaan kosten (ondanks een zeer zwaar tapesysteem)
Dat zou je momenteel een geaccepteerd risico kunnen noemen, maar happy zijn we er niet mee.
Het SAN zal komend jaar vervangen moeten worden en dan moeten we hier keuzes over gaan maken.

In principe willen we naar een extra off-site SAN toe met replicatie over een WAN link.
We hebben een 1Gb internet connectie met een upgrade mogelijkheid naar 10Gb, dus het behoort tot de mogelijkheden, maar eenvoudig is het niet.
Dan heb je nog steeds het risico van datacorruptie, maar de traditionele tape backups houden we er ook zeker gewoon naast.

Inderdaad, dat je SAN weer werkt binnen 4 uur maar je tijd tot de mensen weer kunnen werken ligt een stuk hoger. Als het op een ochtend gebeurt kan je in principe gewoon de werkdag compleet niet meer werken.

quote:

Filesystem (VMFS) corruptie zou theoretisch ook voor kunnen komen,

Is geen theorie hoor. We hebben er al 2 gehad bij ESX 3.

quote:

Rolfie schreef op woensdag 20 september 2006 @ 22:06:
[...]


Is geen theorie hoor. We hebben er al 2 gehad bij ESX 3.

En kon je ze herstellen? Ik ben de upgrade naar ESX 3 momenteel aan het voorbereiden, met 2.5 heb ik het nog nooit gehad.

quote:

DeaDLocK2K schreef op woensdag 20 september 2006 @ 14:54:
[...]
Met VMWare Virtual Center kan je een DivX/XVid/H.264 Film afspelen, de stekker van de hardware eruit trekken, de Virtual Machines worden naadloos omgegooid naar een andere server, en het filmpje schokt niet eens! Dit heb ik niet alleen in een demo gezien, maar ook zelf geprobeerd. Om dit met H.264 te proberen is het wel aan te raden om een werkstation met een Gbit verbinding te hebben btw .

Als je ESX host down gaat, dan gaat je virtuele server ook echt down. Daar is niets aan te doen. Echter hij kan wel weer automatisch opgestart worden op een andere ESX server. Echter net zoals bij "gewone" machines, niet weg geschreven data is dan meestal verloren.
Wat jij waarschijnlijk gezien hebt is dat de machine geswitched wordt van de ene ESX server naar de andere ESX server (vmotion) . Dit kan wel zonder downtime.

quote:

Je beheert echter nog maar 1 hardware platform. Alle VM's hebben dezelfde hardware. Onderstaande replies gaan trouwens uit van een middelgrote tot grote omgeving met shared storage (FC of IP)

Das niet waar. Je beheerd nog maar 1 hardware platform voor je virtuele omgevingen. Je ESX server hardware moet je ook nog ondersteunen. En dit is Linux, dus daar moet je ook de benodigde patches op installeren, eventuele monitoring tools installeren, hardware fabrikant monitoring software installeren en onderhouden. beheer technisch dus niet minder werk.Daarbij moet de hardware wel de zelfde processor generatie zijn. (AMD Intel, P3 P4 enz enz)

quote:

Als je een routering en firewall server wil hebben

Firewalls wil je juist liever niet virualiseren. Aangezien de filters juist vaak in ring 0 werken. Dit kan nog wel eens rare dingen geven als vmware er tussen wil komen. Het kan wel hoor, maar performance technisch is dit niet gewenst.

quote:

Hoezo grote overcapaciteit? Je kan een kleine migratieserver erbij nemen. Dat kan zelfs met reeds afgeschreven server,

Hou wel rekening er mee dat het de zelfde processor generatie moet zijn. Hier heb je dus een probleem als dit niet het geval is.

quote:

Het OS mag je niet onder SPOFs gerekend worden

Ja en Nee, je draaid nu 2 keer een OS. Dus je creerd een extra SPOF. immers je ESX server kan ook crashen. Eingenlijk creer je 2 * een SPOF met ESX, je hebt 2 kernels draaien. een Linux Redhat kernel voor de console en je vmware kernel. Beide kunnen niet zonder elkaar. Als de 1 onder uitgaat gaat de andere ook onderuit. Maar dit is over het algemeen wel vele vele malen stabieler. ESX werkt ook gegarandeerd op de supporte hardware. Je kan ook garantie geven op de CPU/memory. Dat gaat je niet lukken met vmware server. Daarom adviseerd vmware ESX server.

quote:

Asteroid9 schreef op woensdag 20 september 2006 @ 22:10:
[...]


En kon je ze herstellen? Ik ben de upgrade naar ESX 3 momenteel aan het voorbereiden, met 2.5 heb ik het nog nooit gehad.

Een collega had de problem er mee. Test was toen nog geen live, dus we zijn niet gaan troubleshooten. gewoon SAN schijfje formatern.

Hou er rekening mee dat ESX 3 zeer mooi is, maar GUI technisch is het bagger. De ESX kernel is zeer goed, maar de GUI die er momenteel omheen zit werkt niet zo goed. We hebben de raarste dingen er mee gemaakt. Als je twijfled, waarom de settings nog niet actief is, laat de GUI dan eerst een refresh geven. Heeft de GUI het nog niet goed weer, kijk dan eventueel naar de Website van ESX. Ik had bv een server die volgens de GUI uit stond stond, maar dat was niet het geval. De Stop knop kon je niet selecteren. Je had alleen maar de AAN knop beschikbaar. En als je daar op klikte, dan vertelde ESX netjes dat dit niet kon, omdat de server al aanstond.
Via de web interface heb ik toen een geforceerde shutdown kunnen geven. Dat loste alles op.

quote:

Rolfie schreef op donderdag 21 september 2006 @ 10:51:
Das niet waar. Je beheerd nog maar 1 hardware platform voor je virtuele omgevingen. Je ESX server hardware moet je ook nog ondersteunen. En dit is Linux, dus daar moet je ook de benodigde patches op installeren, eventuele monitoring tools installeren, hardware fabrikant monitoring software installeren en onderhouden. beheer technisch dus niet minder werk.Daarbij moet de hardware wel de zelfde processor generatie zijn. (AMD Intel, P3 P4 enz enz)

ESX server patches krijg je van VMware zelf. Je hoeft eigenlijk niets van Linux af te weten, en je hoeft zeker niet (mag ook niet) het Linux OS zelf aanpassen/patchen/etc.

quote:

Hou wel rekening er mee dat het de zelfde processor generatie moet zijn. Hier heb je dus een probleem als dit niet het geval is.

Nee hoor. Die check kun je uitzetten in VirtualCenter (dmv. een .ini file dacht ik), en ik heb er nog nooit problemen mee gehad.

quote:

djluc schreef op woensdag 20 september 2006 @ 15:34:
Dan zou het toch eigenlijk in moeten houden dat er continu een synchronisatie van de virtuele servers plaats moet vinden?

Nee, want je guests draaien vanaf shared storage, disaster recovery nog nooit getest trouwens. Ik zou de powerkabels er eens uit kunnen trekken.

Verder loop je nog wat te "zeiken" over SANs en dergelijke. Een SAN is een stuk betrouwbaarder dan een gemiddelde server met een RAID-5 en sneller ook nog. De meeste nieuwere SAN's ondersteunen namelijk ook RAID6(dubbele pariteit). Daarnaast is dit natuurlijk geen reden om niet te gaan virtualiseren, aangezien dezelfde problemen ook kunnen voorkomen bij losse servers met veel schijfcapaciteit.
Volgend jaar gaan we onze Clariion CX300 denk ik redundant maken. Alleen in het onderwijs is relatief weinig geld voor ICT. Software kost geen drol, maar hardware is tres beaucoup de duur... Laat staan de bijbehorende onderhoudscontracten.

quote:

Asteroid9 schreef:
DHCP clusteren vind ik persoonlijk absolute onzin, een beetje slim je scopes, reservations, en lease time instellen is voldoende!

Als DHCP uitvalt kan er bij ons geen PC meer booten (alles gaat via PXE).
De dhcpd.conf wordt naar twee DHCP servers weggeschreven vanuit de PC database. We hebben een semi-vast systeem. Het MAC-adres moet in de hardware database staan en dan wordt automatisch een dhcptab gegenereerd en getransferred naar twee linux servers. Daarna wordt dhcpd gerestart.

@Rolfie; Ik schreef ook VM's, niet VMWare Hosts. De guests/VM's hebben dezelfde hardware. En je gaat toch zeker geen ESX gebruiken op een server die daar niet certified voor is. Lijkt mij tenminste.

Monitoring gaat bij ons vanuit twee oude werkstations met Nagios. Parallel aan elkaar. En ik krijg een mailtje als er een non-critical system of service uitflikkert en een SMS als het critical is.

Deadlock, dat je VHD's op shared storage staan, wil nog niet zeggen dat een crash van een ESX bak opgevangen kan worden zonder downtime (zo beschrijf je het immers, het afspelen van media wordt volgens jou niet onderbroken).
De guest moet weer normaal geboot worden op de nieuwe ESX machine die de guest gaat hosten...

Zoals ik al zei, alleen bij een geplande actie kan, dankzij VMotion en shared storage, een guest online verplaatst worden naar een andere ESX host.

Abom wijzigde dit bericht 21-09-2006 16:41 (19%)

quote:

DeaDLocK2K schreef op donderdag 21 september 2006 @ 16:26:
[...]

Als DHCP uitvalt kan er bij ons geen PC meer booten (alles gaat via PXE).
De dhcpd.conf wordt naar twee DHCP servers weggeschreven vanuit de PC database. We hebben een semi-vast systeem. Het MAC-adres moet in de hardware database staan en dan wordt automatisch een dhcptab gegenereerd en getransferred naar twee linux servers. Daarna wordt dhcpd gerestart.

Wij doen ook steeds meer met PXE, dus DHCP is zeker wel belangrijk, maar ik heb gewoon weinig vertrouwen in een cluster oplossing.
In eerste instantie reageerde ik op de opmerking dat 2 DHCP servers in 1 subnet moeilijk is, en daar ben ik het absoluut mee oneens.

Voor DHCP redundancy moet je kijken naar meerdere DHCP services, al dan niet gelijktijdig geauthoriseerd en/of draaiend.
Daarmee heb je DHCP gegarandeerd binnen zeer korte tijd weer operationeel, vertrouwen op 1 enkel MS cluster voor DHCP is imho niet slim.

als je DHCP gaat clusteren dan snap je het idd niet.
Als de active node in je cluster eruit klapt duurt het zowiezo enkele seconden voordat hij overschakeld en dat is best lang in een wereld van milliseconden.

gewoon 2 dhcp servers installeren en beide authorizeren.
Stel dat je 192.168.1.x/24 uitgeeft.

1 server maak je scope 192.168.1.1 t/m 192.168.1.254 en je exlude de range 1.128 t/m 1.254
andere server scope 192.168.1.1 t/m 192.168.1.254 en je exclude de range 1.1 t/m 1.127

1 client vraagt om IP adres,
Beide server reageren,
1 van de servers was als eerste en client bevestigd tegen die server dat hij het aanbod accepteerd.
Andere server hoort er niets meer van en na een paar seconden is het aanbod afgelopen en kan hij het aan een ander geven.

Als nu je eerste server plat gaat en een client met 192.168.1.25 wil zijn lease verlengen dan krijgt hij geen antwoordt op zijn aanvraag voor verlenging.
Vervolgens vraagt hij om een nieuw IP adres en zegt daarbij: als het ff kan wil ik 192.168.1.25 gewoon blijven gebruiken. De 2de server zal dan die aanvraag gewoon verlengen.

Doe ik ook zo hier (met andere en grotere ranges) en het werkt perfect.
Het enige waar je op moet letten is dat je die exlude ranges goed insteld.
Als beide servers hetzelfde IP adres kunnen uitgeven gaat het natuurlijk een keertje fout.

DNS clusteren is al net zoiets lomps. Het is van nature gebouwd als een decentrale service met backup / failover faciliteiten genoeg. net als DHCP

idd, ik draai windows
Maar met linux/unix werkt het verhaal van exlusion ranges precies hetzelfde.

Allemaal erg leuk die clusterdiscussies, maar het gaat hier over virtualiseren. Discussieren over (het al dan niet onnodig) clusteren van bepaalde services kan IMHO beter in een ander topic gedaan worden (centraal clustertopic of iets dergelijks).