Zoals gewoonlijk had ik dit laatste pas gezien nadat ik een support request geopend had, maar ik heb dus zoals in dit KB document: http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&externalId=2010589 gehandeld en de zaak is ‘opgelost’.

Wat ik niet goed begrijp is waarom ik in de eerste plaats een VM gemaakt had met “maar” 2GB RAM. Waarschijnlijk omdat de documentatie daarom vroeg. Dan kan je je afvragen of VMware zijn documentatie moet aanpassen, of zijn software moet repareren, want is 4GB voor een backup pakket niet heel erg veel?

Naar aanleiding van die cursus zal ik hier af en toe vragen van collega’s beantwoorden op een manier die voor anderen misschien ook nuttig kan zijn. Graag hoor ik van jullie, lezers, of dit leuk is om te lezen of niet.

En dan volgt nu de reclame, inschrijven voor mijn cursus kan hier.

Dan zou je  eens moeten kijken of de gebruiker die de thinapp start leesrechten heeft op alle bovenliggende mappen, dus deze:

\\server_1\

\\server_1\dfs

\\server_1\dfs\thinapp

\\server_1\dfs\thinapp\apps

Als je gebruiker geen leesrechten heeft op bijv. \\server_1\dfs\thinapp dan zal het verbinden met internet op een of andere mysterieuze wijze niet werken. Waarom is een raadsel, dat het mij enkele dagen gekost heeft om dit te debuggen is een zekerheid.

- Software View client gebruikt om te verbinden naar een persistent desktop met een extra 4GB disk, aangemaakt op de SAN.
- IOmeter geïnstalleerd
- IOmeter 512 bytes en 32 KB profielen aangepast naar 100% random writes en 100% random reads (dus 4 profielen), elk profiel 6 keer uitgevoerd met telkens 2^n outstanding ios (1,2,4,8,16,32).

Dit alles op een MD3220i backend met 8 SAS disks in RAID 10, die normaal een RAID penalty van 2 zou moeten hebben.

Met deze grafieken als resultaat:

Beide pieken komen voor 99% uit de read cache van de RAID controller, resulterend in zeer goede leesprestaties, maar deze zijn voor mij niet zo interessant.

Deze grafiek boeit mij meer:

Hier zie je heel goed hoe het aantal write IOPS blijft steken rond de 2400, er zijn uitspattingen naar boven, maar ik neem het voorzichtig op. Met 8 SAS disks die deze datastore ondersteunen, kom ik uit op ongeveer 300IOPS per disk, zelfs iets meer. Dit ligt tver boven het algemeen aangenomen aantal van 175/200 IOPS voor een 15K rpm SAS disk.

Moeten we nieuwe normen opstellen, of niet meer blindelings die cijfers overnemen van de andere bloggers? Mijn tip, doe je eigen meet en rekenwerk vooraleer je aan het plannen gaat! Leveranciers kunnen ook deze metingen doen en zo een advies formuleren.

Misschien maak ikzelf hier een denkfout, als je denkt dat het zo is, of je hebt andere feedback, dan kan je die onderaan achterlaten.

De afloop evenwel was minder goed. Doordat we spam stuurden, is het ip adres van onze mailserver op een DNSBL geraakt. Veel van deze lists hebben ons op korte tijd verwijderd, maar gmail weigerde tot vandaag nog steeds mail vanaf ons ip adres. Daarom deze post om kort uit te leggen hoe ik dat probleem omzeild heb.

Ik heb op onze mailserver (Postfix) in master.cf deze transport toegevoegd:

togmail   unix  −       −       n       −       −       smtp −o smtp_bind_address=62.213.199.201

en een alias gemaakt op een van de netwerkinterfaces in /etc/network/interfaces:

auto eth1:0
iface eth1:0 inet static
address 62.213.199.201
netmask 255.255.255.240
network 62.213.199.192
broadcast 62.213.199.207
gateway 62.213.199.195
metric 1

Op dit moment moet ik enkel nog postfix vertellen dat hij mail voor gmail.com speciaal moet behandelen en het via dat togmail transport moet sturen. Daarvoor voeg ik een rijtje toe in onze transport tabel met als destination gmail.com en transport togmail:

Voila, nu hopen dat ik binnen enkele weken dit terug kan uitschakelen, maar voorlopig kan iedereen terug naar iedereen mailen!

Onze school beschikt vandaag de dag over ongeveer een 200-tal computers. Om al deze computers bruikbaar te maken en te houden, gebruikt het ICT-team een hele batterij aan technische snufjes, zodat we tijd kunnen maken om de mensen echt te ondersteunen in plaats van de hele tijd ‘brandjes’ te blussen.
Een nieuwe technologie die wij dit schooljaar beginnen toe te passen is het virtualiseren van onze desktop computers. Dit betekent dat de gebruikers zelf geen actieve pc meer ontvangen, maar een ‘domme’ thin client. Dit toestel maakt verbinding met een server op school, die dan op zijn beurt zorgt dat de gebruikers een werkbare computer voorgeschoteld krijgen. Deze manier van werken zorgt voor een consistente gebruikerservaring: waar de mensen ook gaan op school, ze krijgen altijd dezelfde werkomgeving met dezelfde programma’s die op dezelfde plaats staan en op dezelfde manier werken. Het ICT-team heeft als groot voordeel dat alle computers op dezelfde manier te beheren zijn, omdat ze allemaal op een beperkt aantal servers staan. Dit laat ons toe om zeer snel te reageren op vragen om nieuwe software te installeren of aanpassingen te doen aan mensen hun computeromgeving. De toestellen op zich leveren ook een aantal voordelen. Zo verbruikt een thin client met bijhorende servers ongeveer 3 keer minder dan een traditionele computeropstelling. Dit heeft ook als gevolg dat er geen lawaai meer moet zijn in de buurt van computers en de warmteontwikkeling blijft ook binnen de perken. De bekende verzameling van kabels rond een computer is in ons geval ook beperkt, scherm en thin client zijn in elkaar verweven en er moeten dus maar 4 draden naar dit toestel lopen (elektriciteit, netwerk, toetsenbord en muis). Een rust voor het oor, lust voor het oog en spaart de stembanden van onze collega’s. Tegelijk met de verandering van traditionele computers naar een server gebaseerde oplossing zullen wij ook overstappen naar Windows 7, het nieuwste besturingssysteem van Microsoft. Zo kunnen de leerlingen en leerkrachten ook gebruik maken van deze nieuwe technologie zonder dat we onze computers moeten upgraden. Wij zorgen voor meer servers en de mensen kunnen dan, zelfs vanop oude computers, verbinden met een virtuele computer die daarop draait. De volgende fase van ons project zal plaatsvinden in de nieuwbouw, waar we alle lokalen zullen uitrusten met dezelfde comfortabele infrastructuur. Op deze manier kunnen de leerkrachten en leerlingen in een rustige klas werken en les volgen en breiden we ons computerpark met ongeveer 150 toestellen uit.

Met mooie opmaak ziet het geheel er dan zo uit:

Dat ziet er dan zo uit:

Nu heb ik per LUN altijd mooie stats over het aantal IOPS ze leveren (of niet…), iets waar Dell mij niet kan in voorzien, wat eigenlijk wel vreemd is want ik gebruik hier enkel open source tools en de linux MDSM client van Dell zelf.

View 4.6 brengt de mogelijkheid om zonder VPN, veilig en eenvoudig van eender waar te verbinden naar je View omgeving. De mogelijkheden die je hiermee krijgt zijn volgens mij een van de echte redenen om voor VDI of SBC te kiezen. Nogmaals, zonder VPN appliance of andere software TCP vpn stack die latency en overhead met zich meebrengt.

Ik zal deze versie misschien volgende week al installeren en hier berichten over eventuele succesverhalen of #fail verhalen.

Tegelijkertijd werd ook Thinapp 4.6.1 uitgebracht en daar hoop ik ene fix te vinden voor mijn problemen om iumi deftig te thinappen. Meer hierover ook in een latere post.