Oude Red Hat server virtualiseren onder VM

[demichel]

Ik heb een oude HP server draaien met een oude versie van Red Hat (versie 3 of zoiets ouds). Hierop draait een Oracle 9i database.

Nu is het de bedoeling deze straks te gaan vervangen door een gevirtualiseerde versie onder OracleVM, op 2 aparte servers in 2 aparte server-ruimtes. Helaas, tot mid volgend jaar het klassieke verhaal: geen tijd, geen budget. Dus blijft deze oude server een serieus risico, een doorn in mijn oog eigenlijk.

Ik wil deze preventief gaan virtualiseren, niet in de productie-omgeving, maar wel "voor het geval dat". Als de server crasht, kunnen we wel een dagje of twee zonder terwijl ik de virtualisatie in orde breng, maar ik wil het nu wel al even "oefenen" e.d.

Betreft een vrij oude single core HP server met 4 GIG RAM, dus qua performantie moet dat zeker gevirtualiseerd kunnen draaien op een Quadcore met 8 GIG RAM (kan eventueel meer RAM insteken indien nodig).

Ik heb volledige admin rechten over de machine en er uiteraard ook fysieke toegang toe. Iemand die me kan wijzen naar wat meer info hoe ik te werk ga om dat ding te gaan virtualiseren? Ik heb ooit wel eens een HD uit een WinXP PC gehaald en deze in een VM omgezet, maar een Linux server virutaliseren lijkt me nét iets ingewikkelder.

Ik gebruik VMWare Workstation 6.5, niet de meest recente versie, maar de enige waarvoor ik licenties heb.

[ Voor 3% gewijzigd door demichel op 06-09-2012 11:40 ]

[Bigs]

Misschien handig om te vermelden welk virtualisatieplatform je gebruikt. Als je zoekt op '<virtualisatietool> P2V red hat 3' vind je snel genoeg wat de mogelijkheden zijn.

[Verwijderd]

Makkelijkst zal waarschijnlijk zijn via een tool zoals VMware Converter. Die kan gewoon de draaiende machine virtualiseren. Even uit mijn hoofd zijn de enige vereisten root-toegang via SSH.

[demichel]

Verwijderd schreef op donderdag 06 september 2012 @ 11:49:
Makkelijkst zal waarschijnlijk zijn via een tool zoals VMware Converter. Die kan gewoon de draaiende machine virtualiseren. Even uit mijn hoofd zijn de enige vereisten root-toegang via SSH.

Aha, dan begin ik daar deze namiddag eens serieus op te googlen dank!

[DJSmiley]

demichel schreef op donderdag 06 september 2012 @ 11:52:
[...]


Aha, dan begin ik daar deze namiddag eens serieus op te googlen dank!

Alternatief is om een diskimage te trekken (norton ghost, trueimage oid) en die te importeren via vmware converter. Voordeel is dat je dan geen tools op die bak hoeft te installeren. Ik heb wel eens een Win2k bak gehad die op die manier geconverteerd is, omdat vmware converter hogere eisen stelde kwa frameworks/servicepacks dan die bak door omstandigheden had/kon

[Verwijderd]

DJSmiley schreef op donderdag 06 september 2012 @ 19:34:
[...]


Alternatief is om een diskimage te trekken (norton ghost, trueimage oid) en die te importeren via vmware converter. Voordeel is dat je dan geen tools op die bak hoeft te installeren. Ik heb wel eens een Win2k bak gehad die op die manier geconverteerd is, omdat vmware converter hogere eisen stelde kwa frameworks/servicepacks dan die bak door omstandigheden had/kon

Klopt, dat kan ook. Alleen in het geval een Linux-server installeert VMware Converter volgens mij geen software. (Maar het is alweer even geleden, dus ik kan me vergissen.) En voor het maken van een image met zulke tools, zonder software te installeren, moet je server down en dat kan tot protest leiden in het geval van een productiesysteem.

Wat ik nog wel weet: Linux P2V kan een stuk lastiger zijn dan Windows. Maar het is mij met een SLES10 gelukt vanaf een desktop-PCtje (testservertje) naar VMware ESX. Tegenwoordig doe ik eigenlijk nooit meer P2V: alles wat virtueel kan, wordt meteen virtueel geïnstalleerd.

Binnenkort ga ik misschien eens met de volgende uitdaging aan de slag: Een VM uit VMware ESX (vSphere 4.1) migreren naar KVM. Laatst 2 dagen training gehad in KVM en zo'n migratie bleek toch wat ingewikkelder te zijn dan het importeren van een vmdk in KVM. Heeft te maken met device-mappings van bijv. de harddisks.

[Foeijonghaai]

De echte uitdaging is natuurlijk:
* kun je deze server (al dan niet gevirtualiseerd) opnieuw optuigen?

Een machine met RH3 is plm 6 jaar oud:
* is de documentatie nog aanwezig? Weet iemand nog hoe hij ingericht is? Installatieverslag etc.
* zijn er nog updates beschikbaar?
* kan hij meedraaien in je configuratiebeheer?

Kennelijk al 6 jaar in productie zonder noemenswaardige problemen.

Maar kun je hem nog herstellen als je installatiemedia niet meer hebt? Kun je hem nog herstellen als je volume op het SAN verdwijnt? Heb je een backupplan voor de installatiemedia? de configs? etc.

Ik wil alleen maar zeggen: oude hardware is niet het enige waar je druk over zou moeten maken.

Up to date zijn (met je packages, kernel, documentatie) etc is geen must, maar zo oud en kennelijk niet bijgehouden is ook een risico.

[demichel]

Foeijonghaai schreef op vrijdag 07 september 2012 @ 08:50:
De echte uitdaging is natuurlijk:
* kun je deze server (al dan niet gevirtualiseerd) opnieuw optuigen?

Een machine met RH3 is plm 6 jaar oud:
* is de documentatie nog aanwezig? Weet iemand nog hoe hij ingericht is? Installatieverslag etc.
* zijn er nog updates beschikbaar?
* kan hij meedraaien in je configuratiebeheer?

Kennelijk al 6 jaar in productie zonder noemenswaardige problemen.

Maar kun je hem nog herstellen als je installatiemedia niet meer hebt? Kun je hem nog herstellen als je volume op het SAN verdwijnt? Heb je een backupplan voor de installatiemedia? de configs? etc.

Ik wil alleen maar zeggen: oude hardware is niet het enige waar je druk over zou moeten maken.

Up to date zijn (met je packages, kernel, documentatie) etc is geen must, maar zo oud en kennelijk niet bijgehouden is ook een risico.

Geen documentatie, geen updates, niks van dat alles (ik heb de boel hier ook maar geërfd).

Ik begrijp wel niet zo goed wat je bedoelt. Bedoeling is om dat ding, zoals het nu draait, met alle software, alles wat erop staat, er af te plukken en dat te virtualiseren. Er zou dus helemaal geen herinstallatie e.d. nodig hoeven te zijn, want da's nu net wat ik wil vermijden...

Volgend jaar, als er eens tijd & budget is, de hele boel herinstalleren, dan welliswaar onder een recentere Linux, meteen gevirtualiseerd onder OracleVM, in 2 server ruimtes,... dat wordt inderdaad een interessante uitdaging.

[Foeijonghaai]

demichel schreef op vrijdag 07 september 2012 @ 08:55:
[...]


Geen documentatie, geen updates, niks van dat alles (ik heb de boel hier ook maar geërfd).

Ik begrijp wel niet zo goed wat je bedoelt. Bedoeling is om dat ding, zoals het nu draait, met alle software, alles wat erop staat, er af te plukken en dat te virtualiseren. Er zou dus helemaal geen herinstallatie e.d. nodig hoeven te zijn, want da's nu net wat ik wil vermijden...

Volgend jaar, als er eens tijd & budget is, de hele boel herinstalleren, dan welliswaar onder een recentere Linux, meteen gevirtualiseerd onder OracleVM, in 2 server ruimtes,... dat wordt inderdaad een interessante uitdaging.

Je hebt 1 installatie, waarvan je niet precies van de hoed en rand weet, en die bescherm je nu tegen hardwarefalen.

Hardwarefalen is niet je grootste probleem: er komt echt wel een nieuwe (virtuele?) machine als deze op is. Maar als je niet meer bij de disk, de software, de config (en de keuzes in die config) of de data kan. Hoe los je dat op?

[demichel]

Foeijonghaai schreef op vrijdag 07 september 2012 @ 09:17:
[...]

Je hebt 1 installatie, waarvan je niet precies van de hoed en rand weet, en die bescherm je nu tegen hardwarefalen.

Hardwarefalen is niet je grootste probleem: er komt echt wel een nieuwe (virtuele?) machine als deze op is. Maar als je niet meer bij de disk, de software, de config (en de keuzes in die config) of de data kan. Hoe los je dat op?

Ik maak NU (= dus zo snel mogelijk, als ik er achter kom hoe dat precies moet) een virtuele versie van die server. Database wordt iedere nacht gebackupped. Gaat het fout met de hardware dan start ik "gewoon" de virtuele server op, restore de database (dat kan ik nu weer wél ) op dat ding en we zijn terug vertrokken. Of zo zou het toch moeten...

Wat betreft de nieuwe servers die er volgend jaar hopelijk komen, dat wordt inderdaad een compleet nieuwe installatie, nieuwe Linux, ook Oracle 10g ipv 9i, enz enz... Maar dat wordt dan wel een grondig voorbereide operatie, die naast de bestaande ouwe bak komt te draaien tot acceptatie rond is en alles vlotjes draait.

[ Voor 16% gewijzigd door demichel op 07-09-2012 09:22 ]

[terror538]

een image trekken kan je natuurlijk gewoon doen met dd zonder dat de bak down hoeft te gaan.

Maar ik kan me erg vinden in bovenstaande, waarom niet gewoon de database exporteren en deze importeren op een verse machine ?

[Koffie]

Move PNS >NOS

[Hero of Time]

En anders een nieuwe installatie van RH3 maken in de VM en via Rsync alle bestanden behalve /dev, /proc en /sys overzetten. Daarna nagaan wat nog aangepast moet worden voor de virtuele omgeving, zoals MAC adres referenties en fstab.

Zorg wel dat als je bestanden overneemt, je DB UIT is, anders krijg je een inconsistente DB als resultaat op de VM.

[JaQ]

TS zegt Oracle VM, dan heb je volgens mij niet zo veel aan al die vmware p2v tooling.. Omzetten van vmware naar ovs is niet zo eenvoudig. Als je applicatie het toestaat: databse upgraden! En anders op zijn minst naar een recent os (een goede dba krijgt oracle 9 makkelijk aan de praat op rhel5, data overzetten en klaar).

Daarnaast: die Oracle 9 database is niet meer gesupport. Als je problemen krijgt door het overzetten kan je hulp (in de vorm van patches) vergeten. Als je de HA functionaliteit van Oracle VM wilt inzetten, zal je net zoals bij vmware al je cores in je server pool moeten licenseren voor je database (van je hosts dus, niet van je guest). Pinnen op CPU kan wel (en dan heb je geen extra database licenties nodig), maar dat kan niet via de OVS manager (enkel op commandline). Je verliest daarmee de HA functie, maar hebt geen extra database licenties nodig. Het licentiemodel van Oracle is bijzonder virtualisatie-onvriendelijk.

Overigens wil ik TS ook aanraden om even contact op te nemen met een dba. In 2012 ben ik al een aantal malen door verschillende bedrijven gebeld waar os / VM mannen omgevingen virtualiseren zonder een dba te consulteren. Dat is goed voor mijn business, maar zorgt voor serieuze kosten (en downtime) voor deze klanten.

[ Voor 24% gewijzigd door JaQ op 08-09-2012 20:39 ]

[demichel]

Dank voor alle racties tot dusver!

JaQ schreef op zaterdag 08 september 2012 @ 20:33:
TS zegt Oracle VM, dan heb je volgens mij niet zo veel aan al die vmware p2v tooling.. Omzetten van vmware naar ovs is niet zo eenvoudig. Als je applicatie het toestaat: databse upgraden! En anders op zijn minst naar een recent os (een goede dba krijgt oracle 9 makkelijk aan de praat op rhel5, data overzetten en klaar).

Wellicht was ik niet duidelijk genoeg in mijn OP. We moeten twee fases onderscheiden:

-van nu tot ruwweg "najaar 2013": oude Red Hat blijft (hoop ik) draaien en als noodmaatregel wil ik op voorhand een VM image maken om in noodgevallen, na het restoren van de Oracle DB (backup iedere nacht) "voorlopig" gevirtualiseerd verder te draaien.

-"najaar 2013": volledig nieuwe install van de DB, onder RHEL, gevirtualiseerd onder VM-ware op 2 servers in 2 server-ruimtes. Dit is een geplande re-install, met acceptatie-fase e.d. Wordt dan uiteraard ook Oracle 10g want 9i idd niet meer gesupporteerd (ik wil niet naar dan eventueel reeds beschikbare versie 11 want bij Oracle is dat nooit een goed idee, kinderziektes e.d.)

JaQ schreef op zaterdag 08 september 2012 @ 20:33:
Daarnaast: die Oracle 9 database is niet meer gesupport. Als je problemen krijgt door het overzetten kan je hulp (in de vorm van patches) vergeten. Als je de HA functionaliteit van Oracle VM wilt inzetten, zal je net zoals bij vmware al je cores in je server pool moeten licenseren voor je database (van je hosts dus, niet van je guest). Pinnen op CPU kan wel (en dan heb je geen extra database licenties nodig), maar dat kan niet via de OVS manager (enkel op commandline). Je verliest daarmee de HA functie, maar hebt geen extra database licenties nodig. Het licentiemodel van Oracle is bijzonder virtualisatie-onvriendelijk.

Licentiemodel van Oracle is inderdaad bijzonder ingewikkeld en niet virtualisatie-vriendelijk (al zijn de "perpetual licenses" wel bijzonder interessant op langere termijn). Licensies voor de gevirtusliseerde servers zijn ondertussen geregeld en betaald en zullen dus helaas tot najaar 2013 niet ten volle benut worden met dat ouwe single core servertje (ah, het is niet anders).

[JaQ]

demichel schreef op zondag 09 september 2012 @ 10:13:
Wordt dan uiteraard ook Oracle 10g want 9i idd niet meer gesupporteerd (ik wil niet naar dan eventueel reeds beschikbare versie 11 want bij Oracle is dat nooit een goed idee, kinderziektes e.d.)

Are you serious? 10.1 is ook al out of support. 10.2 geen error correcting support meer. 11.2.0.2 heeft in jan 2013 zijn laatste security patches, je zou al over 11.2.0.3 moeten gaan nadenken. 12 is reeds dik in beta (ik verwacht een release zo rond 1 oktober 2012, ten tijde van OOW).

Je maakt je backups wel met rman inclusief archive logs, of vertrouw je ook op exp?

[Hero of Time]

Wij draaien 2 databases, een oracle 10g en een 11. Beide geen problemen. Als je de keus hebt, neem dan 11.

[The Eagle]

Even over die Oracle VM: Van wat ik begreep is dat op twee druppels water na CentOS. Ik weet van een collega van me dat ie de Oracle VM template op CentOs / XEN aan de praat heeft gekregen iig, zonder veel problemen.
Oracle VM is leuk, maar de VM manager schijnt een draak van een product te zijn. Bovendien zoals gezegd een spinoff van Xen, dus ik zie eigenlijk niet in waarom ej Oracle VM zou wilen gaan draaien - tenzij je makkelijk templates uit wilt rollen. Maar zoveel werk is de install van RHEL 5.5 + Oracle nou ook weer niet

Qua licenties: ik heb dat laatst uitgezocht hoe dat zit met licenties voor Oracle DB en virtuele machines. Conclusie: je betaalt per fysieke core van de machine waarop de VM draait. Dus als jij 64 core cluster hebt met tig DB's, mag je per DB voor 64 cores gaan betalen. Da's nie leuk nie

[Hero of Time]

De enige, echte reden waarom je ook maar zou overwegen om OracleVM te gaan gebruiken, is support van Oracle. Net als OEL een aftreksel is van RHEL, is OVM een aftreksel van XenServer. Dat laatste draait op CentOS.

Overigens heb ik van onze DBA begrepen dat als je een licentie hebt voor een CPU, bijvoorbeeld een dual socket quad core Xeon server, dan mag je met een virtuele machine daar op draaien. Je mag er zelfs 2 DBs op hebben, of meer. Zolang alle DBs op die fysieke machine draaien waar je een licentie voor hebt, is er geen probleem. Mocht je server uitvallen en je zet alle VMs op een andere, identieke server, ook geen probleem. Draai je de VMs op 2 servers, dan heb je wel een issue. En met een cluster is er geen onderscheid tussen fysieke servers, dus ben je zoals The Eagle zegt flink duur uit. Dan kan je beter licenseren op aantal gebruikers, dan heb je weer geen beperking op aantal CPUs.

Dit is wat ik van onze DBA heb begrepen. Het kan in praktijk anders zijn. Als je echt vragen hebt, kan je het beste bij Oracle wezen.

[The Eagle]

Dat laatste hoeft niet eens: http://www.orafaq.com/wiki/Oracle_licensing

Maar wat Hero Of Time zegt is exact wat ik zeg: je mag best een VM met Oracle op je fysieke machine draaien, zolang je je fysieke cores maar telt voor de licentie. De crux zit hem echter in de partitioning: Oracle staat hard partitioning wel toe, maar geen soft partitioning. Zie ook http://www.oracle.com/us/...g/partitioning-070609.pdf EN helaas is VMware soft-partitioning...

Overigens is Oracle's support instelling mbt VM's anders: ze maken qua OS / support geen onderscheid tussen een virtuele en fysieke machine. Of je RHEL machien dus fysiek of virtueel is uitgevoerd maakt voor je support niet uit. OS is OS

Enige manier waarop je je licentiekosten kunt drukken bij gebruik van VM's is het gebruik maken named user plus licenses. Dan kun je de kosten vaak nog een beetje drukken.

E.e.a. is overigens ook de reden waarom je Oracle (DB) producten nog maar zo weinig in de cloud ziet. Want hoe weet je in een cloud in 's hemelsnaam hoeveel CPU's / cores een onderliggende fysieke server heeft? Valt niet hard te maken en valt altijd te duur uit
Enige manier van Oracle cloud computing is om dat via Amazon te doen - want daar heeft Oracle een overeenkomst mee dat de Amazon cloud de Oracle VM templates ondersteunt. En dan mag het uiteraard ineens wel

---

Maar back ontopic: een Oracle 9i DB zou zoals al aangegeven prima op een nieuwe OS moeten kunnen draaien. Of het ooit supported is of was is vraag twee, maar dat was het toch al niet meer dus dat boeit niet. Als het werkt werkt het 9i is voor zover ik weet altijd 32 bits geweest, dus dat moet vrijwel overal op te draaien zijn.

Afhankelijk van je eigen voorkeur: kies een OS voor je VM, installeer 9i en zorg dat het draait. DB onder linux simpelweg klonen vanuit een backup van je originele machine, en onder windows gaat het zeker lukken met een import / export. ter indicatie: wij hebben op de zaak een 500+GB 9i DB draaien die vanaf 9i AIX naar 9i Windows 2003 32bit gemigreerd is. Archiefomgeving van een grote beursgenoteerde klant. Works like a dream

[demichel]

JaQ schreef op zondag 09 september 2012 @ 21:51:
[...]

Are you serious? 10.1 is ook al out of support. 10.2 geen error correcting support meer. 11.2.0.2 heeft in jan 2013 zijn laatste security patches, je zou al over 11.2.0.3 moeten gaan nadenken. 12 is reeds dik in beta (ik verwacht een release zo rond 1 oktober 2012, ten tijde van OOW).

Je maakt je backups wel met rman inclusief archive logs, of vertrouw je ook op exp?

Whoops, toen ik dit tikte had ik dus al mijn zonneslagje (+ bijhorende streekbieren-in-de-tuin-kater) gisterenavond. Bedoel natuurlijk upgrade van 9i naar 11g, niet 10g !!

[JaQ]

The Eagle schreef op maandag 10 september 2012 @ 00:32:
Maar back ontopic: een Oracle 9i DB zou zoals al aangegeven prima op een nieuwe OS moeten kunnen draaien. Of het ooit supported is of was is vraag twee, maar dat was het toch al niet meer dus dat boeit niet. Als het werkt werkt het 9i is voor zover ik weet altijd 32 bits geweest, dus dat moet vrijwel overal op te draaien zijn.

Afhankelijk van je eigen voorkeur: kies een OS voor je VM, installeer 9i en zorg dat het draait. DB onder linux simpelweg klonen vanuit een backup van je originele machine, en onder windows gaat het zeker lukken met een import / export. ter indicatie: wij hebben op de zaak een 500+GB 9i DB draaien die vanaf 9i AIX naar 9i Windows 2003 32bit gemigreerd is. Archiefomgeving van een grote beursgenoteerde klant. Works like a dream

Even uit nieuwsgierigheid: waarom haal je 32bits er bij? Dat maakt voor je datafiles toch helemaal niets uit? Bij een platform-migratie is toch enkel het endian format relevant? (of vergis ik mij hier?)

Om te miereneuken 64bit Oracle 9 bestond in ieder geval op Open VMS, HP-UX, AIX, Solaris en Windows. Volgens mij is er nooit een 32bit versie van Oracle 9 op VMS, HP-UX, AIX en Solaris geweest?

demichel schreef op maandag 10 september 2012 @ 14:14:
Whoops, toen ik dit tikte had ik dus al mijn zonneslagje (+ bijhorende streekbieren-in-de-tuin-kater) gisterenavond. Bedoel natuurlijk upgrade van 9i naar 11g, niet 10g !!

DBA's en alcohol innemen is ook een typische combi

[ Voor 11% gewijzigd door JaQ op 12-09-2012 16:51 ]

[The Eagle]

Ik had de versies niet specifiek gecheckt, maar mijn opmerking was specifiek voor TS' context. Hij gebruikt linux (of windows). Inderdaad, er heeft een 64bits 9i voor windows bestaan. Maar aangezien 9i gemaakt was op windows 2000, dat alleen in 64 bits beschikbaar was voor een Itanium architectuur, was dat wel een longshot geweest. Dus de kans dat TS die had achtte ik vrij klein, anders had ie dat wel gemeld

Vandaar dus de melding dat 9i voor zijn OS'en altijd 32 bits geweest is Dat er voor andere OS'en een 64bit versie was ben ik voor het gemak even aan voorbij gegaan

[igmar]

Ik heb live machines overgezet, gewoon draaiende. Je *moet* dan alleen achteraf een fsck check draaien, waarbij drukke machines een (hoger) risico geven op corruptie.

[CAPSLOCK2000]

Hoe ik het doe:

1. VM aanmaken met de juiste specs
2. Start de VM met een live CD. Partitiioneer de schijf en configureer het netwerk met een tijdelijk ip-adres.
3. rsync de (draaiende) fysieke machine naar de VM toe
== downtime begint hier ===
4. sluit Oracle en andere applicaties af en ga naar runlevel 1
5. herhaal de rsync
6. zet fysieke machine uit
7. installeer vmware-tools op de vm
8. (her)installeer de bootloader van de vm en pas het IP-adres aan
9. reboot de vm

Als het goed is heb je nu een werkende VM. Als het niet goed is kun je je oude server weer aanzetten.

Ik doe de rsync in twee keer om de downtime kort te houden. De eerste keer wordt de bulk van de data overgezet maar loop je het risico op corrupte bestanden omdat je een draaiende database kopieert. De tweede rsync corrigeert dat.
Om de bootloader geinstalleerd te krijgen moet je een beetje handig zijn met chroot. Als je dat te ingewikkeld vindt kun je ook VMWare Converter proberen dat ongeveer hetzelfde doet. Ik doe het zelf liever met de hand zodat ik meer controle heb.

[The Eagle]

@CAPSLOCK: Oracle (zeker 9i) gaat het niet heel erg leuk vinden als ie draaiend over wordt gezet en al helemaal niet met rsync Maar gelukkig weet TS dat wel, dus die zal voorafgaand aan de rsync zn DB even down brengen zodat ie inconsitentie voorkomt

Rule 1: Als je een draaiende Oracle DB simpelweg kopieert heb je onbruikbare bestanden

Overigens zou ik persoonlijk gewoon met RMAN aan de slag gaan (9i snapt dat ook al), dan heb je die rsync niet eens nodig en kan de DB wel open blijven

[CAPSLOCK2000]

Daarom doen we een tweede rsync nadat oracle gestopt is, ik noem het expliciet.

[The Eagle]

Hm, was gisteren tijd voor me om naar bed te gaan geloof ik

Magoed, we zitten iig op 1 lijn, dus da's goed

[ Voor 29% gewijzigd door The Eagle op 14-09-2012 16:29 ]