Posts

Een corrigerende trap tegen je ESX-bak en hij draait weer als een zonnetje :)

Tijdens mijn beheer werkzaamheden liep ik tegen het probleem aan dat VirtualCenter op een taak bleef hangen op één taak en alle andere taken, zoals “maintenaince mode”, “power down”, “migrate”, etc. er achter werden ge-queued. Hierdoor kon ik dus eigenlijk niks meer met VirtualCenter. Ook werdt VirtualCenter onwijs traag, en was het dus elke keer hopen dat hij toch nog doorliep.

Ik hoor jullie denken: “Nou dan doe je toch, rechtermuisklik –> cancel”. Dat had ik dus ook al bedacht, maar maakte ook geen verschil. Neutral

Dan komt hier de oplossing:
1. Op de ESX-server waar de niet meer reagerende VM’s op draaien voer je het commando “service mgmt-vmware restart” uit, of je reboot de betreffende esx-server.
2. In de services van windows waar je VirtualCenter op draait, zoek je naar de services van “VMware VirtualCenter” en restart je de service.

En dan kan je nu weer knallen als voorheen Green with Envy

VMware goed voor het milieu?

Is VMware goed voor het milieu?, oordeel zelf

http://www.aint-that-the-truth.com

 Robin Plomp

Beschikbaarheidspercentage

Bij het maken van een technisch ontwerp voor een klant wordt vaak het één en ander geroepen over beschikbaarheidspercentages van een nieuwe infrastructuur of nieuwe systemen. Zware kost?

Ja en nee, beschikbaarheidspercentages hangen samen met veel interne en externe factoren. Zo zal er voor het schrijven van een technisch ontwerp altijd inzicht moeten zijn of de beschikbaarheid geldt voor de keten van componenten tussen een systeem waar een beschikbaarheidspercentage op af wordt gegeven. Vaak zal worden gesteld: “deze applicatie dient 99,8%, 24/7 beschikbaar dienen te zijn”. Leuk, totdat je je PepperByte blocnote erbij pakt en gaat rekenen…. 99,8% op 24/7: hoeveel uur mag de desbetreffende applicatie er dan uitliggen? Een simpele rekensom helpt daarmee: downtime = (total available hours + 0,25) – ((total available hours + 0,25) / availability%). Dus in ons voorbeeld (99,8% op 24/7) is de downtime: (8760 (24 uur * 365 dagen) + 0,25 (overhead voor het schikkeljaar)) – ((8760 + 0,25) / 99,8%) = 17,52 uren.

17,5 uren op een jaar, nou dat is wel te halen op deze applicatie! Maar dan komt de keten van componenten nog. Concreet betekent dit dat alle systemen vanaf de klant tot aan de applicatie dienen te functioneren! Dus dan heb je het over netwerkinfrastructuur (mogelijkheid om vanaf een ander locatie te werken? waar beleg je dit in de SLA – dus houden we het in dit voorbeeld puur op de backend infrastructuur, dus puur de core netwerkfunctionaliteiten van-en-naar de MER), database server, applicatie server, data opslag locatie. En dan heb ik het nu alleen nog over een traditionele server-client infrastructuur. Wanneer je Server Based Computing gebruikt zal dus ook de Farm beschikbaar moeten zijn en wanneer je het zaakje hebt gevirtualiseerd zal je dus (bijvoorbeeld) de ESX omgeving en SAN mee moeten tellen.

Zo worden die 17,52 uur toch echt een hele dure grap; want om deze beschikbaarheid te halen heb je een heel stevig argument voor een twin center omgeving… Mijn advies? Berg je blocnote op en vraag de klant of het beschikbaarheidspercentage voor deze applicatie aangepast dient te worden Wink

Voor nu,

Later…

SQL 2005 – Reporting Services – VMWare ESX

Zo; net thuisgekomen van een avond load testen bij een klant van ons. Wij hebben een implementatie gedaan van SQL 2005 en Reporting Services voor een Management Informatie Systeem. Wij hebben SQL 2005 geïnstalleerd op een virtuele machine binnen VMWare ESX. Doordat SQL 2005 beter kan in zijn jasje zit als 64-bit versie hebben we zowel Windows 2003 als SQL 2005 als 64-bit geïnstalleerd. De machine heeft 2 procs. en 6GB intern geheugen. Vrij ok zou je zeggen….

De laatste paar dagen ben ik bezig geweest met een tool die zeer snel internet acties opneemt. Deze recorder gaat straks deel uitmaken van DUAF. Ik heb dus een flink aantal scripts gemaakt die de gebruikers activiteiten op dit Management Informatie Systeem simuleert. De scripts werkten goed, dus om terug te komen bij de loadtest…. die ging vrij slecht, met 50 gebruikers ging de machine goed onderuit, pagina’s laden via de Reporting Services van SQL duurde zo’n drie tot vier minuten! Dit zijn dus gewoon asp.net webpagina’s.

Na het toevoegen van twee extra procs. en 2GB geheugen ging het een stuk(-je) beter, maar niet denderend veel beter. Ik moet de meetresultaten nog analyseren en dan kom ik hier op terug. Voor nu;

Later….