Unexpected.be

Telling stories for a living

Tag: Omgeving

Mijn ThinkPad volgt mij professioneel gewijs altijd en overal en aangezien ik vaak dingen moet kunnen testen, draait er op mijn laptop VMWare Workstation 7 – gratis gekregen door toe te treden tot de VCP4 kudde – met daarin een mobiel labo. Op dat mobiel testlabo draait een serieuze waslijst aan servers:

  • VMWare ESX 3.5 Server
  • VMWare ESX 3.5 Server (kwestie van VMotion te kunnen doen met de eerste)
  • VMWare VCenter Server voor bovenstaande ESX servers
  • VMWare vSphere 4 Server
  • VMWare vSphere 4i Server
  • VMWare vSphere 4i Server (kwestie van VMotion te kunnen doen met de eerste)
  • VMWare VCenter vSphere Server voor bovenstaande vSphere ESX servers
  • Openfiler iSCSI SAN emulatie server
  • Wiki Server waarin ik veel documentatie en info dump
  • Drie W2K3 SP2 servers die dienst doen als Active Directory, DHCP en DNS servers (twee van de drie) en als test server
  • Windows XP Pro test machine
  • VCB Server zodat ik VMWare Consolidated Backup kan testen in bovenstaande omgeving
  • Networker Server met zoals de naam al doet vermoeden EMC Networker Backup Server

Alle servers tegelijkertijd laten draaien is geen optie omdat er niet genoeg geheugen / CPU rekenkracht in mijn ThinkPad (of eender welke andere laptop for that matter) zit om dat mogelijk te maken zonder dat alles aan een slakkegangetje vooruit gaat. Gelukkig heb ik ook nooit alle servers tegelijkertijd nodig, maar het gebeurt wel eens dat er twee ESX servers + een VCenter + VCB + een Networker server tegelijkertijd draaien, wat als geheel toch een serieuze impact heeft op de beschikbare resources.
Mijn laptop beschikt over 4GB RAM en een dual-core Intel Centrino 2 processor op 2.0GHz wat net genoeg is om een deftige testomgeving werkbaar te maken. VMWare Workstation levert goed werk door de beschikbare resources deftig te managen waardoor alles werkt zoals ik verwacht. Er is echter één bottleneck waar geen enkele software iets aan kan doen: de harde schijf.
Hoe je het ook draait of keert, het geheel loopt op één enkele “spindle” oftewel harde schijf, wat nefast is voor de performantie. Zowel de virtuele machines als het host-besturingssysteem – mijn Windows 7 dus – gebruiken dezelfde harde schijf en allemaal op verschillende momenten – problematisch!
Om dit te counteren zit er in een van de PC-Card sloten een SSD-disk van 48GB waarop naast een “ReadyBoost” partitie (extra swapfile waardoor Windows iets pittiger zou moeten zijn), de “zwaardere” virtuele machines draaien. Meestal zijn dit de ESX servers, maar het gebeurt al eens dat ik er SQL servers op draai (veel I/O).
Maar daarmee is mijn probleem nog niet volledig opgelost! 48GB is leuk, maar eigenlijk veel te weinig. Een SSD van 128GB of 256GB zou al beter zijn, maar ik heb niet direct zin om meer dan 500€ uit te geven. Ik zocht een goedkope oplossing die mobiel is en toch extra performantie met zich meebrengt. U raadt het al, ik heb een externe harde schijf ter hulp geroepen.
Mijn keuze is gevallen op de iOmega Select Mobile Hard Disk van 500GB. Het “Select” gedeelte wijst er in feite op dat het over een budget harde schijf gaat, maar de term budget is nogal slecht gekozen. De duurdere broertjes hebben meestal een mooiere shell (al vind ik de mijne ook wel netjes), krijgen er “gratis” backup software bij (die ik toch niet gebruik) en beschikken soms naast USB2.0 ook over FireWire / eSata aansluitingen. Die laatste had ik eventueel wel zien zitten, maar ik had geen zin om daarvoor twee keer zoveel geld uit te geven. En dus was de keuze snel gemaakt – 69€ voor een mobiele schijf van 500GB. Let op: het gaat hier over een 2.5″ exemplaar dat stroom via de USB-poort krijgt, niet over een “gewone” 3.5″ externe schijf met aparte voeding. Ik ben me bewust dat je daar meer opslag / snelheid voor je geld krijgt, maar de focus lag op mobiel.

Waar vroeger een waslijst aan virtuele machines op mijn laptop disk stonden te pruttelen, is de impact vanaf nu verdeelt over mijn externe mobiele schijf en mijn interne SSD van 48GB. Deze combinatie houdt mijn laptop snel zodat ik naast mijn testlabo ook nog andere dingen kan doen, iets wat vroeger meestal onmogelijk was.

De enige bottleneck die ik nu nog heb is het RAM geheugen en de CPU, en dan vooral dat eerste. Mijn laptop kan met 4GB uitgebreid worden tot een totaal van 8GB intern geheugen, maar de kostprijs van 400€ vind ik er een beetje over… dus voorlopig doen we het zo, tot de prijzen van het RAM geheugen weer eens in elkaar zakken ;-).

Nu mijn VCP-examen met succes achter de rug is, had ik me voorgenomen om mijn VMWare test-omgeving te scratchen en van nul terug op te bouwen. Oefening baart kunst zeggen ze, maar doorheen het studeerwerk heb ik ook enkele best-practises ontdekt die ik graag zou toepassen.
De oorspronkelijke configuratie zag er zo uit:
Server 1

  • Functie: dit was de eerste ESX-server in mijn setup
  • OS: VMWare ESX 3.5

Server 2

  • Functie: dit was de tweede ESX-server in mijn setup
  • OS: VMWare ESX 3.5

Server 3

  • Functie: deze server stond in voor de iSCSI storage emulatie met behulp van Openfiler, alsmede voor de Virtual Center omgeving. Zowel de Openfiler als de Virtual Center draaiden elk op hun eigen virtuele machine die binnen een VMWare Server 2.0 omgeving werden gehost.
  • OS: Het basis OS voor de server zelf was Windows 2003 SP2.

De Openfiler VM zorgde voor “Shared Storage” die aan beide ESX servers werd aangeboden om zo o.a. VMotion te kunnen gebruiken. De Virtual Center VM was een simpele W2K3SP2 machine met daarop de Virtual Center software (en een bijhorende database) die gebruikt werd om de volledige omgeving te beheren. Deze machine speelde ook DNS server voor de volledige omgeving.
– OS: Windows 2003 SP2
Van Server 1 en Server 2 was ik erg tevreden, al wil ik nu de partities die VMWare ESX nodig heeft customizen en niet de “defaults” volgen. Je kan dit achteraf wijzigen, maar het is veel simpeler en sneller om ESX te herinstalleren met de correcte waarden.
Het schoentje wrong echter bij Server 3: alles werkte wel zoals gepland, maar ik vond de installatie en het gebruik te ingewikkeld en met teveel overhead. Hier zou dus een mouw moeten aangepast worden bij het redesign van mijn test-omgeving.
Het “Redesign” plan:
– Server 1 & Server 2: geen veranderingen.
– Server 3: ter vervanging van W2K3SP2 met daarop een VMWare Server 2.0, heb ik gekozen om VMWare ESXi te installeren als basis OS. Resultaat: sneller en minder overhead.
Op deze ESXi omgeving zou ik dan opnieuw twee virtuele machines aanmaken:

  • Openfiler VM: net zoals voordien, moet deze machine de iSCSI shared storage leverancier worden.
  • W2K3SP2 VM: in tegenstelling tot voordien, zal op deze machine géén Virtual Center worden geïnstalleerd. Deze VM zal de rollen van Domain Controller, DNS, DHCP, WINS en WSUS op zich nemen in mijn nieuw op te richten Active Directory domein. In de vorige test-omgeving maakte ik gebruik van lokaal gedefinieerde users op de VMWare servers om alles in kannen en kruiken te leiden, maar deze keer wil ik via LDAP werken en aangezien ik Windows-omgevingen het best ken, lag Active Directory voor de hand. DNS, DHCP en WINS liggen voor de hand in een Active Directory omgeving, maar WSUS – oftewel Windows Server Update Service – misschien iets minder.

Telkens ik nieuwe (test) machines aanmaak in de virtuele omgeving, moet je deze machines net als een “echte” PC uitrusten met de nieuwste patches en updates. Je kan dit gedeeltelijk oplossen met templates te gebruiken die je dan op hun beurt up to date houdt, maar voor bestaande VM’s is dit geen oplossing. Deze machines draaien elk apart Windows Update en moeten dus elk apart alle patches en updates downloaden. Niet zo ideaal dus. Een WSUS server download al deze (voorafgedefinieerde) updates en via group policies kan je dan instellen dat je andere machines hun updates van deze server downloaden. Resultaat: sneller en minder bandbreedte / volume verspilling.
Het enige dat nog ontbreekt, is een Virtual Center installatie. Zoals ik al zei, zal deze niet op een VM draaien (nochtans wel gesupporteerd door VMWare), maar wou ik deze graag op een fysiek gescheiden machine draaien (sneller, al zou dat niet veel mogen uitmaken binnen mijn kleine test-omgeving). Aangezien ik nog een Sony VAIO laptop ongebruikt naast mij had liggen, was de keuze snel gemaakt. De VAIO beschikt over een Intel Centrino dual-core 1,66GHz CPU en 2GB RAM geheugen – ruimschoots krachtig genoeg om als Virtual Center server dienst te doen. Het basis OS is Windows XPSP3 geworden (supported OS voor Virtual Center) omdat dat toch iets sneller zal lopen als W2K3SP2 én omdat ik daar alle drivers voor bij de hand had.
En dan zijn we rond. Het moeilijkste gedeelte is alles uitdenken en uittekenen, daarna is het noeste “handenarbeid” om alles te installeren en te configureren. Gisteren heb ik alvast Server 3 zijn basis OS meegegeven en de VM’s aangemaakt (ze moeten nog geconfigureerd worden).
De VAIO heeft ook zijn OS meegekregen en Virtual Center 2.5 is ook al geïnstalleerd. Vandaag waag ik me aan de herinstallatie van Server 1 en Server 2 en als het allemaal een beetje vordert, heb ik tegen zondag een volledig werkende VMWare ESX 3.5 test-omgeving zoals ik ze wil.
By the way: de reden waarom ik voor Server 3 voor ESXi gekozen heb en niet voor ESX is simpel: beide broertjes gelijken erg op elkaar, maar er zijn toch verschillen. En niets is zo goed om een product te leren, als ermee werken. Hence the reason why…
Wordt ongetwijfeld vervolgd…

Daarnet stond UPS aan de deur met de “backend” server, voor zover de rest geen backend servers zijn natuurlijk. Zoals ik in mijn eerste blogbericht schreef, gaat het hier over een Dell Poweredge 2850 die dienst zal doen als iSCSI software emulator / storage systeem, als VMWare Virtual Center server, als DNS server en als beheermachine voor al dat lekkers.  Voor het host OS heb ik niet gekozen voor Redhat zelf voor de simpele reden dat dat OS niet gratis is, maar in plaats daarvan heb ik voor CentOS (Community ENTerprise OS) 5.3 gekozen. CentOS is gebaseerd op Redhat en dus in feite identiek, maar in plaats van dat je voor support terugvalt op de mannen van Redhat, is het hier de community zelf.
Aangezien ik in CentOS zo goed als nooit zal werken, maakt het mij allemaal niet uit. Zolang ik maar VMWare Server kan draaien op deze Linux distributie om bovenstaande machines te huisvesten.
Ondertussen is de installatie van CentOS al afgerond en is de Package Updates (Windows Update in de Linux wereld zeg maar) bezig met het systeem up to date te brengen. Eens dat klaar is, ga ik VMWare erop installeren en dan zijn we klaar voor het zwaardere werk ;-).
Morgen komt trouwens de derde en laatste server toe, een Dell Poweredge 2650 die als ESX host zal draaien naast de reeds geinstalleerde 2650. Het labo is hardwarematig dus bijna compleet en de configuratie van al die geektoys kan beginnen! Nog veel werk voor de boeg, maar oh zo plezant dat dat is!

Zoals jullie in mijn vorige blogpost konden lezen, ben ik volop bezig met me voor te bereiden op het behalen van het VMWare Certified Professional statuut. Vorige week had ik een 4-daagse opleiding, maar vanzelfsprekend verlies je al die kennis vliegensvlug als je daar niet mee bezig blijft. Alleen in boeken neuzen is interessant, maar daarmee doe je geen hands-on ervaring op en laat net dat van vitaal belang zijn om iets goed onder de knie te krijgen.
Op het werk hebben we wel enkele VMWare machines, maar ofwel draait daar productie op en daar blijf je af, ofwel is het een testmachine waarop ook andere collega’s met testen bezig zijn en dus kan ik die machine(s) niet zomaar rebooten, herinstalleren, verknoeien,… wanneer het mij uitkomt. Mijn eerste oplossing was op mijn laptop VMWare Workstation gebruiken om een testomgeving in op te zetten (daarover zal ik in de nabije toekomst eens een blogpost schrijven, misschien dat het toch wel interessant is voor sommigen onder jullie?), maar nadat ik die theorie in de praktijk had omgezet, bleek mijn ThinkPad te kreunen onder al dat virtueel geweld. Wat had je anders gedacht met volgende setup:

  • 2 x ESX server met 2GB RAM.
  • 1 x ISCSI software emulatieserver die als SAN zal dienen voor de ESX servers.
  • 1 x Windows 2003 Server (gestript met nLite) die dienst doet als Routing & Remote Access machine, maar ook als DNS server (VMWare staat of valt bij een goede DNS werking).
  • 1 x Windows XP Professional die in eerste instantie VMWare Virtual Center draait (van waaruit je de ESX servers aanstuurt voor o.a. VMotion), maar daarnaast ook dient als “management console” voor de SAN-server en alle andere testen die moeten gebeuren.
  • Binnen de gevirtualiseerde ESX servers draaien ook nog eens twee virtuele machines: eentje met een gestripte W2K3 en eentje met een Linux distro (DSL).

Mijn laptop heeft 4GB geheugen, wat genoeg blijkt voor al dit moois, onder voorbehoud dat ik het niet te bont maak. De dual-core Centrino 2 2GHz CPU houdt het ook goed vol en gaat zelden boven de 50% lopen (natuurlijk afhankelijk van wat ik doe binnen de testomgeving). Het enige probleem, dat tegelijkertijd ook verantwoordelijk is voor de “übertraagheid” van mijn virtueel testlabo, is de harde schijf.
Al dat virtueel geweld draait uiteindelijk op één enkele harde schijf, dat dan nog een laptopmodel is en op 5400 toeren per minuut loopt. En dan hebben we het nog maar alleen over VMWare Workstation en het testlabo dat daarin draait, maar we mogen niet vergeten dat mijn operating systeem zelf (Windows 7), mijn browser, mijn e-mail client,… ook nog actief zijn én eveneens op diezelfde hardeschijf losbeuken. Het resultaat is dat de schijf totaal niet kan volgen met de gevraagde commando’s en dus aan multitasking gaat doen – met een traag systeem tot gevolg. VMotion lukt trouwens niet, want de ESX komt me vertellen dat er niet genoeg resources vrij zijn om de operatie succesvol uit te voeren.
De “virtuale” testomgeving is dus ok voor kleine dingen, om een setting na te kijken bijvoorbeeld. Maar voor het serieuzere testwerk volstaat het niet en moest er een andere oplossing gezocht worden. Eerst dacht ik er aan om mijn volledige testomgeving na te bouwen / te kopiëren naar mijn vast werkstation, dat met zijn quadcore 3,4GHz, 8GB geheugen én snellere harde schijven een pak performanter is dan mijn laptop. Maar dan bleef ik met de beperkingen van de virtualisatie  binnen een virtueel platform zitten en eigenlijk wou ik toch graag een deftige testsetup opzetten om mij zo goed mogelijk te kunnen voorbereiden op mijn examens.
Tijd om nieuwe hardware te kopen dus. Maar, VMWare ESX is niet de meest gemakkelijke klant op gebied van acceptatie van hardware. De harde schijven moeten SCSI modellen zijn (sommige SATA disks werken omdat de SATA controllers soms dezelfde chipset hebben als de SCSI controllers – maar officieel is het niet gesupporteerd), de netwerkkaarten moeten ook van bepaalde types zijn (lees: Intel), de CPU’s tussen de ESX servers onderling moeten van dezelfde familie zijn,… kortom veel prerequisites dus! Je kan altijd eens piepen op Ultimate WhiteBox, een website van VMWare addepts waar je een lijst kan vinden van geteste en gevalideerde (en soms ook officieel niet ondersteunde) hardware.
Voor mezelf had ik besloten dat ik drie servers wou hebben, allemaal met officieël ondersteunde hardware. Niet omdat dat sneller zou werken of zo, maar gewoon omdat ik me moet voorbereiden op de examens en ik geen zin heb om te tweaken en te tunen om iets ongesupporteerd toch te laten werken. Nieuwe servers waren out of the question wegens veel te duur voor mijn behoeftes. Tweedehands dan maar, en wat is er dan beter dan eBay?
Na een paar uurtjes browsen, afchecken van hardware, nog wat google’en en een schematekening om te bepalen wat ik allemaal nodig heb, was de kogel door de kerk en heb ik mij hetvolgende gekocht:

  • 2 x Dell Poweredge 2650: 2 x Intel Xeon 3,06GHz CPU – 2GB RAM – 73GB Ultra320 SCSI HDD @ 10K RPM
  • 1 x Dell Poweredge 2850: 2 x Intel Xeon 3,2GHz CPU – 4GB RAM – 2x36GB Ultra320 SCSI HDD @ 15K RPM

Dell Poweredge

De 2850 krijgt een Redhat OS mee met daarop een VMWare Server installatie. Binnen deze VMWare komen er drie virtuele machines:

  • een iSCSI software emulator die de shared storage zal emuleren, nodig voor VMotion en HA testen.
  • een Windows 2003 Server die Virtual Center, RRAS en DNS voor zijn rekening zal nemen.
  • een Windows XP Professional die zal gebruik zal worden voor het beheer van bovengenoemde configuraties.

De twee 2650 machines gaan op hun beurt dienst doen als VMWare ESX servers met VMWare Infrastructure 3.5 als operating systeem. Al de servers beschikken over een dual gigabit netwerk interface en dus zullen de ESX machines één connectie naar “het netwerk” krijgen en één connectie voor “IP Storage – iSCSI dus”. Idealiter heb je drie netwerk interfaces en kan je die derde dan gebruiken voor de service console, maar ik ga die samen met de IP Storage connectie op een NIC definiëren. Als de nood hoog is, kan ik nog altijd een extra NIC bijplaatsen, maar voorlopig ga ik het zo doen.
Al de servers zijn trouwens rack-mountable modellen, “pizzaboxes” zoals wij ze wel eens noemen, beschikken over redundante power supplies, hebben cd-rom (2650) of dvd-rom (2850), VGA, PS2 en USB2.0 aansluitingen aan voor- en achterkant en maken gigantisch veel lawaai wegens extreme fans die ervoor moeten zorgen dat die dingen in alle omstandigheden up & running blijven. Je kan er dus van op aan dat die dingen enkel online gaan zijn wanneer ik er effectief testen op wil doen, tenzij ik ergens een kleine rack op de kop kan tikken en dat ding in de garage of zo kan opstellen… ;-).
Gisterenavond heb ik de eerste ESX server al geïnstalleerd, weliswaar zonder shared storage en dus met een virtuele testmachine op de local storage, en dat ging zeer vlotjes. Meer dan genoeg resources available. Vandaag verwacht ik de levering van de 2850 server en dan kan ik al beginnen met de setup van de backend voor mijn ESX omgeving. En tegen dat die goed en wel opgezet is, is het weekend alweer voorbij en staan ze met de derde en laatste server aan de deur.
Wordt zonder twijfel spoedig vervolgd…

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!

© 2018 Unexpected.be

Theme by Anders NorenUp ↑