Disaster Recovery met klein hardware verschil

[michelc85]

Zit hier met het volgende vraagstuk:

Wij hebben hier een windows 2003 domain controller staan van IBM ( X226 Type nummer 8648 2DG).
Nu willen wij graag een disaster recovery doen op een nieuwe IBM server die wij nog moeten bestellen.(server wordt niet alleen daarvoor gebruikt dus wees gerust)

Nu blijkt echter dat de 8648 2DG niet meer leverbaar is en deze is vervangen door een ander type van IBM de 8648 EFG.

Na navraag bij onze leverancier en IBM blijkt dat het grootste verschil tussen beide modellen de processor is, het 'oude model had een Intel Xeon ('Nocana') DP processor met 1MB level 2 cache, het nieuwe model heeft een Intel Xeon ('Irwindale') DP processor met 2MB level2 cache.
(8648EFG)

Nu is mijn vraag of dit voor de disaster recovery nog enig verschil maakt, omdat je dit alleen maar op dezelfde machine kan uitvoeren.

[Abom]

Dat ligt natuurlijk helemaal aan je manier van disaster recovery.

Toch wil ik even opmerken dat ik betwijfel dat de CPU het grootste verschil is tussen de machines. Een nieuwe revisie van bijvoorbeeld de northbridge of NIC's is al veel groter vergeleken met een ander type CPU (vanuit disaster recovery perspectief that is).

Wanneer je een image van een 2k3 installatie (van de nieuwe machine) op de plak hebt liggen, waar je later je active directory op restored (vanaf tape), denk ik dat het redelijk soepel zal verlopen.

Wanneer je denk dat je simpelweg een harddisk uit de ene server kunt trekken en in de nieuwe kunt steken, denk ik dat je de nodige issues kunt verwachten.

[ Voor 13% gewijzigd door Abom op 20-06-2006 15:42 ]

[empheron]

Waarom doe je dit niet op de normale manier :
- Server installeren
- In hetzelfde domein hangen
- AD erop zetten, laten syncen met je oude 'PDC'.. en die uitzetten.

Ik ben bang dat je met disaster recovery trucjes toch in de knoei komt. Diverse hardware onderdelen van je systeem zullen toch anders zijn (al is het maar serienummers, bios-versies, firmware etc). Grote kans dat het daardoor niet gaat werken.

Als je al disaster recovery gaat doen, doen het dan bij voorkeur niet vanaf een backup medium via Veritas ofzo. Veritas en ArcServe hebben echt problemen met het goed restoren van PDC's. Ghost kan in bepaalde situaties lastig worden (bijv. bij RAID opstellingen).

[ Voor 26% gewijzigd door empheron op 20-06-2006 15:49 ]

[Verwijderd]

Waarom maak je geen gebruik van vmware?
Dit lost het hele probleem van disaster recovery en hardware verschillen op.
En geloof de performancy verliezen zijn minimaal.

[michelc85]

Verwijderd schreef op dinsdag 20 juni 2006 @ 19:10:
Waarom maak je geen gebruik van vmware?
Dit lost het hele probleem van disaster recovery en hardware verschillen op.
En geloof de performancy verliezen zijn minimaal.

Bedoel je VMware op de nieuw server zetten en dan proberen de disaster recovery terugzetten.

[Puch-Maxi]

michelc85 schreef op donderdag 22 juni 2006 @ 12:07:
[...]


Bedoel je VMware op de nieuw server zetten en dan proberen de disaster recovery terugzetten.

Ik denk dat hij meer iets bedoelt als:
VMware ESX Server, je instaleert je server erop en dan is het altijd uitwisselbaar met iedere andere machine's die VMware ESX Server draaien
correct me if I'm wrong

[Rolfie]

Verwijderd schreef op dinsdag 20 juni 2006 @ 19:10:
Waarom maak je geen gebruik van vmware?
Dit lost het hele probleem van disaster recovery en hardware verschillen op.
En geloof de performancy verliezen zijn minimaal.

Je creëert alleen wel een extra laag tussen al je applicaties. Deze moet je ook onderhouden en kennis in opdoen.
Wat als vmware crashed? Hoe los je dat dan op?

[Asteroid9]

Rolfie schreef op donderdag 22 juni 2006 @ 13:29:
[...]
Je creëert alleen wel een extra laag tussen al je applicaties. Deze moet je ook onderhouden en kennis in opdoen.
Wat als vmware crashed? Hoe los je dat dan op?

VMware ESX farm opzetten in combinatie met VirtualCenter / Vmotion
Daarmee kun je virtual machines al draaiende overzetten naar een andere ESX host.
Zo kun je een ESX host probleemloos down brengen voor hardware of software maintenance.

Mocht er dan een ESX host crashen (nog nooit gezien trouwens) start je deze zo weer op vanaf een andere host (SAN is wel benodigd)
Zelfs al zou je de ESX host volledig opnieuw moeten installeren is dat binnen 20 minuten gedaan, er staat namelijk praktisch geen configuratiedata op.
De VM zelf kun je als platte file backup-en, waarna je die op willekeurige hardware onder ESX kan booten.

Een fysieke server die down gaat en die je niet zo maar kan restoren op een andere server levert je stukken meer downtime op.

Misschien overkill voor de situatie van de TS, maar het bied leuke voordelen...

[Powermage]

En met de tootltjes van vmware (p2v) kun je een draaiende machine zonder al te veel moeilijkheden omzetten naar een VM.

[Verwijderd]

Verwijderd schreef op dinsdag 20 juni 2006 @ 19:10:
Waarom maak je geen gebruik van vmware?
Dit lost het hele probleem van disaster recovery en hardware verschillen op.
En geloof de performancy verliezen zijn minimaal.

Alleen ben je een totale randdebiel imho als je zonder enige reden een extra spof gaat introduceren.

Zelfs vmware zelf raad alleen om alleen de esx versie te gebruiken voor productie oplossing. maar vmware draaien op 1 machine om 1 machine te laten draaien is gewoonweg zeer stom.

[Verwijderd]

Asteroid9 schreef op donderdag 22 juni 2006 @ 15:50:
[...]


VMware ESX farm opzetten in combinatie met VirtualCenter / Vmotion
Daarmee kun je virtual machines al draaiende overzetten naar een andere ESX host.
Zo kun je een ESX host probleemloos down brengen voor hardware of software maintenance.


Mocht er dan een ESX host crashen (nog nooit gezien trouwens) start je deze zo weer op vanaf een andere host (SAN is wel benodigd)
Zelfs al zou je de ESX host volledig opnieuw moeten installeren is dat binnen 20 minuten gedaan, er staat namelijk praktisch geen configuratiedata op.
De VM zelf kun je als platte file backup-en, waarna je die op willekeurige hardware onder ESX kan booten.

Een fysieke server die down gaat en die je niet zo maar kan restoren op een andere server levert je stukken meer downtime op.

je biedt niet echt veel voordelen. Als je toch al op een san vertrouwd, zorg je gewoon dat de machines booten van san en dan heb je je machines ook zo weer in de lucht. Idd zorgen voor identieke hardware en een spare klaar hebben staan, maar da's peanuts als je zo'n omgeving kan betalen.

(vmotion is leuk voor als je geplande downtime hebt, maar je hebt er geen ruk aan als de spanning van een host wegvalt. ga je toch alles cluster zeg je dan, tuurlijk kan, maar dan gaat het hele idee van hardware besparing en beheerskosten besparing helemaal naar de knoppen )

De voordelen die vmware opleveren wegen naar mijn idee niet op tegen de nadelen. VMware crash en je bent niet 1 server kwijt maar alle servers. Dan ben je misschien wel sneller in de lucht (wat twijfelachtig is aangezien er veel meer weer online gebracht moet worden), maar werknemers kunnen ook werkelijk niets meer gedurende die tijd

[ Voor 11% gewijzigd door Verwijderd op 23-06-2006 13:58 ]

[Verwijderd]

Nu on topic

@TS: mij niet helemaal duidelijk wat je wilt. Wil je disastery recovery testen of wil je de nieuwe machine de taken overlaten nemen?

disastery recovery vraagt per definitie om dezelfde hardware, maar het betekent niet dat het op andere hardware niet kan. Je zal dan echter wel een aantal problemen moeten oplossen als het lukt. Testen laat je zien of het kan en ten tweede geeft je meer handigheid in het oplossen van problemen als je dat een paar keer gedaan hebt.

wil je de taken overlaten nemen, dan zou ik ook de machine opnieuw inrichten. Ben je gelijk alle crap van de oude machine kwijt en kan je het netjes naast je oude machine opbouwen, zodat je geen big bang nodig hebt.

[Diabolical]

Verwijderd schreef op vrijdag 23 juni 2006 @ 14:03:
disastery recovery vraagt per definitie om dezelfde hardware.

Denk dat je bedoelt dat BareBone recovery per definitie vraagt om dezelfde hardware. Voor disaster recovery is het in het geheel niet nodig dat je dezelfde hardware hebt. Time to run wordt er wel korter door en het is dan ook gewenst maar noodzakelijk niet hoor.

Voor de TS: Verifieer dat de rest (chipset etc.) van de hardware dan wel hetzelfde is. Processor zal niet veel uitmaken maar meestal wordt de northbridge daarmee ook vernieuwd en dat kan dus wel issues opleveren. Daarnaast wil het voorkomen dat on-board options als SCSI controller etc. ook wel eens willen wijzigen.

[Verwijderd]

Diabolical schreef op vrijdag 23 juni 2006 @ 15:20:
[...]


Denk dat je bedoelt dat BareBone recovery per definitie vraagt om dezelfde hardware. Voor disaster recovery is het in het geheel niet nodig dat je dezelfde hardware hebt. Time to run wordt er wel korter door en het is dan ook gewenst maar noodzakelijk niet hoor.

je hebt gelijk. Echter veel backuppakketten die een backup recovery optie aanbieden, maken een server specifieke flop of cd waardoor het restoren naar identieke hardware snel gaat. maar dit is meer een tool dan een disastery recovery procedure. Toch denk ik dat de TS zoiets bedoelt

[PolarWolf]

"Disaster Recovery" is heel iets anders dan het clonen wat je nu wilt gaan doen. Backup pakketten met een disaster recovery optie zijn *niet* bedoeld om servers mee te clonen. Dat dit in sommige gevallen wel kan is mazzel, maar erop vertrouwen is een tweede.

Wat betreft wijzigingen in de hardware: Er zijn maar twee punten waar het echt fout op kan gaan: 1) HAL en 2) Storage controller. Zijn ze in het geval van de nieuwe doos allebei gelijk aan de oude (en dan met name de storage controller), dan kun je in elk geval de machine geboot krijgen om de rest van de eventueel gewijzigde hardware aan de gang te helpen. Netjes is anders, maar het wekt in elk geval in theorie.

Dat gezegd hebbende, zou ik ofwel de procedure aanhouden zoals al is beschreven (clean install, AD laten repliceren), of met een authoritive restore de AD op de nieuw ingerichte DC zetten.

[Verwijderd]

Verwijderd schreef op vrijdag 23 juni 2006 @ 14:03:
disastery recovery vraagt per definitie om dezelfde hardware

Niet altijd Zo is het met bv Livestate Recovery mogelijk naar alternatieve hardware te restoren. Dus de functionaliteit hangt sterk af van je tools.