Test-Omgeving

Als je in aanraking komt met een nieuw product, software- of hardwarematig, dan is het in feite van cruciaal belang dat je ettelijke uren “hands-on” ervaring opdoet. Een cursus of een techboek leggen wel veel uit en overladen je soms zelfs met informatie, maar de échte know-how komt er in feite vooral door met het product bezig te zijn.
Aangezien je dat niet in een productieomgeving kan doen, is het aangewezen om een test-omgeving te hebben, een sandbox zeg maar, waarin je onbezorgd kan spelen, testen, proberen, van crash & burn doen, herinstalls lanceren, upgrades doen, unsupported configs testen,… en ga zo maar door. Het liefst van al wil je daarbij ook een manier om snel terug te kunnen keren naar de voorgaande (werkende ;-)) situatie, zonder telkens een halve dag kwijt te spelen met je omgeving terug op te bouwen.
En dat is nu net waar virtualisatie om de hoek komt kijken. Er zijn twee grote bekenden, namelijk VMWare van EMC² en Hyper-V van Microsoft. De eerste staat op dit moment nog op voorsprong, wegens de simpele reden dat zij al veel langer in de virtualisatiewereld ronddwalen, maar hou Microsoft ook maar in de gaten, want die gasten zijn serieus aan het inhalen geslagen.
Op dit moment is het echter zo dat de meeste productieomgevingen op VMWare draaien (als ze gevirtualiseerd zijn welteverstaan) en daarom doe ik meestal mijn testen ook in die omgeving. Thuis is dat op VMWare Workstation en op het werk maak ik gebruik van VMWare ESX, wat in sé dezelfde functionaliteit heeft als de Workstation, maar ipv lokaal op je eigen machine te draaien – binnen Windows – is ESX een operation system op zichzelf en draait het op een standalone server (of een cluster van servers, bijvoorbeeld een Bladebox). Vanzelfsprekend biedt ESX ten opzichte van Workstation nog tal van andere extra mogelijkheden, die vooral gericht zijn op productieomgevingen in de lucht houden: zoals bijvoorbeeld vMotion waarmee je je virtuele machines van de ene fysische host naar de andere kan verhuizen (bijvoorbeeld bij een hardware falen, overbelasting van een node,…).
De voorbije dagen heb ik mij bezig gehouden met het “bouwen” van zulke test-omgeving, op een VMWare ESX server met daarin 8 Intel Xeon CPU’s op 1.6GHz en 6GB RAM geheugen. Niet spectaculair, maar zeker krachtig genoeg (en vooral, veel krachtiger dan mijn Thinkpad) om  te doen wat ik in gedachten heb: een Active Directory opzetten met voorlopig één domain controller. Deze zal tegelijkertijd ook dienst doen als file-server, DHCP-server, DNS-server en WSUS-server. De tweede machine is een SQL-server geworden die zoals de naam al aangeeft, SQL draait maar later ook andere rollen kan vervullen (backup DNS, backup DHCP, file-server 2,…). De laatste machine is een application server die ik op dit moment gebruik om Northern Storage Suite op de draaien, de software waarvoor ik vorige week in Zweden opleiding gaan volgen ben. Vanzelfsprekend kan die server ook andere redenen van bestaan toebedeeld krijgen (bv. secondary domain controller worden), maar voorlopig is daar nog geen nood aan.
Elke virtuele machine heeft tussen de 1 en 2GB geheugen gekregen en elke machine beschikt over twee CPU’s. In de Active Directory heb ik enkele test-OU’s gemaakt met daarin tevens ook enkele test-users omdat ik met NSS wil gaan testen op quota-management, rapportering van storage-use per gebruiker en per afdeling en zo voorts.
Een tip die ik steevast zelf toepas voor zulke omgevingen, is het gebruiken van een WSUS-server. WSUS staat voor Windows Server Update Services – wat concreet betekent dat de server die deze rol vervult, de Windows Update server binnen je domein wordt. Het voordeel is niet alleen de centrale beheerbaarheid, maar ook dat al de security updates, hot fixes, service packs en wat nog allemaal, slecht één keer gedownload worden van het internet – namelijk door de WSUS-server. Al de andere servers (en indien gewenst ook clients) gaan bij de WSUS-server hun updates halen, wat dus sneller gaat (lokaal LAN gaat voorlopig nog altijd sneller dan downloaden van internet) en minder bandbreedte en volume kost. En WSUS is nog is gratis ook! What more do you need? De configuratie van WSUS zelf gebeurt via een MMC snap-in, terwijl de verwijzing en schedules naar deze server vanop de andere servers, via een group policy op de AD geconfigureerd wordt.
Nog een laatste tip rond test-omgevingen bouwen: maak op regelmatige basis een snapshot van je machines. Als je wil terugkeren naar een vorige “state” van je server, is dit je reddende engel.
Als er iemand nog andere tips & tricks heeft, laat ze maar achter in de comments!