In de nacht van woensdag 11 op donderdag 12 april heeft hostingprovider Amsio een inbraak gedetecteerd op haar netwerk waarbij de hacker specifiek en gericht een server van een klant is binnengedrongen en hierbij verschillende bestanden heeft buitgemaakt.

Direct na het signaleren van een indringer in het netwerk heeft Amsio vanuit protocol een aantal maatregelen genomen. Van een aantal klanten zijn uit voorzorg wachtwoorden gewijzigd. Met het grootste gedeelte van deze klanten is inmiddels al persoonlijk contact geweest. Alle maatregelen die nodig zijn geweest om de hacker buiten te houden zijn inmiddels gedaan en per direct is een grootschalig onderzoek gestart.

Een team van experts van de gerenommeerde securityorganisatie FOX-IT zijn donderdagmorgen direct op locatie bij Amsio aangekomen om te onderzoeken wat er precies is gebeurd en welke gegevens precies zijn buitgemaakt. Zolang het onderzoek loopt kunnen wij helaas geen verdere informatie verstrekken. Wel kan FOX-IT bevestigen dat het er nu uitziet dat er geen andere klanten binnen het netwerk van Amsio doelgericht zijn aangevallen.

Een van de belangrijkste klanten van Amsio is webhostingprovider en zusterbedrijf Argeweb. Deze provider zal vandaag ook haar klanten vragen hun wachtwoord te wijzigen.

Het merendeel van de benaderde klanten heeft zeer positief gereageerd op de proactieve houding van Amsio en de manier hoe uit voorzorg wordt gehandeld.

Argeweb Managed Services, dat vanaf 1 januari 2011 al gesplitst was van Argeweb Online Services, gaat per 1 maart verder onder de naam Amsio. Het bedrijf levert managed hosting oplossingen voor applicaties, outsourcing en infrastructuur.

Continue reading →

We gebruiken Veeam al enige tijd voor het maken van backups van VMware machines. Voor Windows guests is het handig dat het ook de VSS writer een signaal kan geven waardoor bijvoorbeeld transactie logs van SQL server of Log files van Exchange opgeschoond kunnen worden. Voor Hyper-V gebruiken we Microsoft DPM Server 2010 in combinatie met een hardware VSS provider op de Hyper-V hosts, de ervaringen (in combinatie met onze EMC storage) zijn echter wisselend. Hoog tijd om naar Veeam te kijken (wat ook op VSS leunt heb ik op voorhand begrepen) en zien of dat wat stabiliteit- en snapshot issues oplost.

De installatie van versie 6 verloopt vlot, een SQL Express Edition wordt mee-geinstalleerd. Eenmaal gestart kies ik voor de optie add servers:

Interessant, de onderste twee opties kom ik nog wel een keer aan toe, ik kies nu voor Hyper-V en moet daarna de server selecteren. Ik kan daarna kiezen voor VMM (alleen 2008 heb ik begrepen, deze demo omgeving draait 2012), Hyper-V cluster of een standalone Hyper-V machine. Ik kies voor het cluster:

Ik vul credentials in en na eventjes wachten kan het deployen van de clienst beginnen. Nadat de agent is deployed worden de disks en volumes geinventariseerd. Dit duurt wel een paar minuten, maar de snelheid van deze testomgeving is niet helemaal representatief. “Server has been added successfully” lees ik dus ik beginnen met backuppen. Eerste bugje al gevonden, de cluster naam van Hyper-V wordt niet overgenomen, maar de naam van de eerste node.

Ik wil eerst nog wat extra storage toevoegen, en zie een gave feature waar ik nog wel mee aan de slag wil:

Dit maakt het mogelijk (ik denk wanneer je VMware draait, want Hyper-V doet weinig met NFS) om de backup-VPS-en direct vanaf de backup server te draaien.

Ik kan een VM selecteren en de nodige opslag wordt keurig berekend:

Ook in deze versie zit application-aware image processing en guest file indexing:

Na het aanmaken klik ik op start job en ik wacht. Ik zie in mijn hardware VSS provider log dat deze geladen wordt en dat er een snapshot wordt gemaakt voor de physical drive waar de VM op draait. De HW VSS provider doet er akltijd even over om de snapshot te maken en via PowerPath aan de host te geven.

Deze omgeving is met recht een testomgeving, het cluster presteert door een wat aparte netwerk setup niet helemaal goed meer, maar voor deze functionele test is het prima. Na ruim een uur is er 55,8GB over de lijn gegaan, een gemiddelde snelheid van 18MB/sec. Wel leuk om te zien dat dit de eerste full backup is, maar dat deduplicatie er al voor zorgt dat er 1,3 minder data (het gebruik op de schijf was bijna 74GB) over de lijn hoeft te gaan.

Ik start de backup job nog een keer en test het incrementele gedeelte. Dat gaat aanzienlijk sneller, de inline deduplicatie doet zijn werk goed. Snelheden schieten uiteraard omhoog, dit is waarom ik zo van Veeam backup and recovery houdt: het ontlast veel delen van je netwerk, als er eenmaal een full backup is. Infinite incrementals klinkt erg goed

Tot zover stelt het dus niet teleur. Ook voor Veeam heb je dus een degelijk hardware VSS provider nodig. Totdat Windows Server 8 er is hebben we eigenlijk geen keus. Je wilt voorkomen dat tijdens een backup de CVS’s in redirected mode blijven, dat is een aanzienlijke performance degradatie op een drukke omgeving. Iets waar we op het moment veel last van hebben.

Voor de test heb ik nog een enkele Hyper-V server getest op snelheid, waarbij ik snel zag dat “source” de bottle neck is. Veeam doet compressie en deduplicatie, wat erg CPU intensief is. Nu zit er een functie in Veeam dat “backup proxies” heet. Hiermee kun je de verwerking van de data offloaden naar een andere machine. De backup machine in kwestie heeft Xeon X5650 processoren, dus dat lijkt me juist een perfecte kandidaat om de processing te doen. Het nadeel is echter, dat de storage op de proxy ook aanwezig moet zijn. Single node Hyper-V servers worden dus lastig, in een cluster zou je een extra node kunnen inzetten die toegang heeft tot de CSV’s, maar geen VM’s heeft draaien.

Al met al is de eerste indruk goed, ik wil nog met de replication mogelijkheden aan de gang, maar dat wordt een nieuwe blog.

Ik kwam een interessante blog tegen van ICT jurist Arnoud Engelfriet over de verantwoordelijkheid die je hebt als gebruiker van licenties. Voordat ik het effect ervan duidelijk maak eerst een klein stukje voorgeschiedenis over waarom ik deze blog schrijf.

Als managed service provider zijn wij, net als iedere managed service provider of hostingprovider ter wereld verplicht om het SPLA programma van Microsoft te gebruiken. Dat houdt in dat we onze Microsoft licenties niet kopen bij Microsoft, maar per maand huren. Dat geeft ons een grote mate van flexibiliteit en in sommige gevallen kunnen we daardoor een bijzonder scherp aanbod doen aan onze klanten in vergelijk met gekochte licenties. Het gaat te ver om de regels van het SPLA programma volledig toe te lichten, maar het komt er op neer dat wanneer je hardware voor meer dan 1 klant inzet, je verplicht bent te licenseren via SPLA. Nogmaals, dat is iedere hostingprovider ter wereld.

Helaas zijn er veel (kleinere) hostingproviders die zich hier niet aan houden. Wat wij vaak tegenkomen zijn hostingproviders die het SPLA programma niet goed interpreteren of hostingproviders die helemaal niet meedoen met het SPLA programma. Beide zijn niet compliant, maar vooral de laatste groep neemt een groot risico. Nu maak ik me in de meeste gevallen niet druk om wat andere hostingproviders verkeerd doen, maar wat we steeds vaker tegenkomen is dat ze hiermee een vals concurrentievoordeel hebben. Bij serieuze managed hosting oplossingen is het licenseren van de omgeving soms meer dan 50% van de totale som van de offerte. Als een andere hostingprovider hier dus niet eerlijk mee omgaat kan de prijs daar veel lager liggen. Iets wat ons vaak steekt. Het gaat soms zelfs zo ver dat we er deals op dreigen te verliezen. Gelukkig kunnen we het klanten vaak uitleggen en beseffen zij ook dat het veiliger is om te kiezen voor de eerlijke weg. Want wat als het misbruik ineens grote consequenties heeft voor de andere partij en de bereikbaarheid het platform hiermee in het geding komt?

En nu kom ik op het punt dat ik bovenin wilde maken: de klant zegt vervolgens “dat is niet mijn probleem, ik wijs naar mijn hostingprovider, zij hebben het me aangeboden.” Iets wat wij soms als antwoord krijgen wanneer we het prijsverschil proberen toe te lichten. Zo werkt het dus blijkbaar niet. Ik moest bij de blog van Arnoud Engelfriet denken aan de uitdrukking “onwetendheid is geen verdediging”, want daar lijkt het wel op. Als eindgebruiker ben je zelf juridisch aansprakelijk voor het verkeerde gebruik van de licenties. Dat de hostingprovider ook aansprakelijk is lijkt me voor zich spreken, zij breken immers met de overeenkomst die ze hebben getekend met Microsoft.

Zoals Arnoud zegt: “Je kunt niet als inbreukmaker volstaan met verwijzen naar die onterechte licentiegever. Het mag wel, en als de rechthebbende liever hem aanpakt dan kom je goed weg, maar juridisch heb je geen verweer als de rechthebbende erop staat bij jou de claim neer te leggen.”

Het is dus wel degelijk handig om je als klant goed te laten informeren over het correcte gebruik van bijvoorbeeld SPLA licenties. Het programma is gelukkig sinds 1 juli een stuk transparanter geworden, maar het vergt nog steeds veel tijd om er goed in thuis te raken. Ik vind dat het de verantwoordelijkheid is van iedere hostingprovider om iemand te hebben die het programma goed kent, helaas is dat nog vaak niet zo.

Zie deze link voor de volledige blog van Arnoud Engelfriet: http://blog.iusmentis.com/2011/11/28/mogen-ze-bij-mij-aankloppen-als-mijn-licentie-niet-klopt/

Snelle websites zijn hot. Waar het vroeger om functionaliteit ging en iedereen gewend was dat een site even moest laden is het anno 2011 niet meer ok als een site traag laadt. Nu consumentenverbindingen veelal tientallen Mbits aan downloadsnelheden hebben, verwacht een bezoeker dat een site snel laadt. Nu zijn er genoeg open deuren die je kunt intrappen als het gaat om het bouwen van vlotte websites: Degelijk geoptimaliseerde code, valide HTML en CSS maken, plaatjes klein houden als het niet nodig is de grote versie te tonen, etc. Iets verder gaat het als we het hebben over de juiste headers meegeven voor statische content zodat bestanden gecached kunnen worden. De eventuele database achter de website moet logisch zijn, indexen moeten gelegd worden en er moet goed worden nagedacht over wanneer welke data wordt opgehaald. Het probleem is vaak dat de mensen die de website maken, niet altijd over de juiste kennis beschikken om de site optimaal te laten draaien. Dat is helemaal niet erg; het zweet breekt mij ook uit als ik Photoshop moet opstarten, snap er weinig van en heb er het geduld niet voor. Ik snap meer van de infrastructuur, de architectuur en het netwerk waar die website op draait. En gelukkig maar, want dat is mijn vakgebied.

Er is dus een gat. Een gat dat ligt tussen aan de ene kant de designers of developers die mooie internet applicaties maken met hippe functionaliteit, streaming content en dynamische ajax-elementen, en aan de andere kant de beheerders en architecten die zorgen dat de internetapplicaties blijven werken. Ook als de site plotseling veel drukker wordt bezocht door succes of bijvoorbeeld nieuwswaardigheid.

Gelukkig zijn er technieken voorhanden die ingezet kunnen worden om de beleving van die website flink op te krikken. Door ons veelgebruikte en de laatste tijd steeds populairder wordende producten zijn Varnish in combinatie met Nginx. Varnish is een zogenaamde reverse proxy, of zoals ze zelf zeggen: “Varnish is an open source, state of the art web application accelerator”. Nginx is een lichtgewicht webserver en reverse proxy (ook ja). Door deze twee serverapplicaties achter elkaar in te zetten kan een bijzonder snelle en goed schaalbare webomgeving worden gecreeerd.

Varnish en Nginx kun je installeren op de webserver, maar vaak wordt het “voor” de webserver(s) geplaatst, op de loadbalancers of tussen de loadbalancers en de webservers.

Zoals iedere proxy wordt het http request onderbroken en afgehandeld door Nginx, en daarna nog een keer, door Varnish. Varnish wordt veelal ingezet om te cachen, terwijl Nginx aan de voorkant – de internetkant – wordt gezet om technieken als compressie, SSL offloading en loadbalancing te implementeren.

Als we kijken naar Varnish, dan werkt het grofweg als volgt. Varnish vraagt zelf de content op aan de achterliggende webserver(s) (backend servers) en stuurt dit naar de browser. De kracht zit hem in het feit dat Varnish een stuk geheugen alloceert en de content hierin opslaat. De volgende bezoeker die komt krijgt de content geserveerd uit het geheugen, in plaats van bijvoorbeeld Apache met een PHP applicatie en een MySQL database. Dat is dus sneller, veel sneller. Het gaat te ver om hier uit te leggen hoe Varnish precies werkt, maar het zit erg slim in elkaar. Door slim om te gaan met hoe een kernel werkt en hoe CPU’s werken worden het aantal benodigde system calls verder geminimaliseerd.

Er zijn wel regels. Varnish moet weten dat een pagina gecached mag worden. Een pagina met cookies bijvoorbeeld, die kan niet gecached worden; deze pagina is immers altijd dynamisch. Dus goede headers weergeven is belangrijk. Op die manier kunnen html, css, js, png, jpg en andere statische files goed gecached worden. Hierdoor kan de minder schalende back-end webserver (Apache, Tomcat, IIS) met rust gelaten worden. Regels zijn er om gebroken te worden, dat is een andere kracht van Varnish. Alles is instelbaar. Je kunt alles naar je hand zetten, je kunt alle cookies van de requests afslopen, je kunt bepaalde filetypes altijd cachen, ongeacht de headers.

Onze klanten zeggen vaak dat hun sites dynamisch zijn. Maar als je vervolgens inzoomt, dan zijn er vaak maar heel specifieke delen van de pagina’s dynamisch. Hier heeft Varnish ook een oplossing voor: ESI. Deze taal maakt het mogelijk om binnen een pagina bepaalde gedeeltes niet te cachen. Dit is erg handig voor bijvoorbeeld shopping carts, inlognamen, etc. De content binnen deze ESI tags kunnen dan minder lang, of helemaal niet gecached worden. De beste resultaten worden natuurlijk gehaald als hele pagina’s gecached kunnen worden. Ook al is een site dynamisch, een cache implenteren die “pas” na 1 seconde verloopt  is vaak toch een optie. Als de Apache/IIS/Tomcat backend normaliter 500 requests per seconde te verduren krijgen, blijft er nu nog maar 1 request over. Dat scheelt nogal…

Ik ben erg enthousiast over Varnish. In combinatie met Nginx kan een goed lopende website gaan vliegen. Helemaal afhankelijk worden van Varnish is nooit slim, want het blijft een caching systeem. Maar wanneer het in de juiste situaties slim toegepast wordt levert het dus erg veel op.

Als professionele hoster en leverancier van managed ICT services zijn wij constant bezig te onderzoeken hoe we efficiënter, sneller en betere diensten kunnen leveren. Opslag van data, storage is een vitaal onderdeel van de infrastructuur stack. Wij hebben begin 2007 een keuze gemaakt om bedrijfskritische storage te centraliseren. Wij hebben toen gekozen voor EMC. EMC is de wereldmarktleider op het gebied van storage en hun visie sloot goed aan bij onze wensen. Inmiddels zijn we een aantal EMC modellen verder en ik merk dat ik weer na begin te denken over onze strategie op het gebied van storage voor de komende jaren.

Traditionele storage apparaten zoals de EMC’s die wij hebben, maar ook een HP EVA, een NetApp, Hitachi, etc. werken met een vast aantal controllers en een vast aantal disken dat het array kan aansturen. Ik weet dat fabrikanten met allerlei oplossingen komen die hier omheen werken, maar er blijft een relatie tussen controller en disk.

Als we naar de NAS wereld kijken, dan is de term scale-out inmiddels veel meer gemeengoed. Systemen die worden opgebouwd uit zogenaamde bricks, of storage devices (eigenlijk servers met een flink aantal disken) zorgen voor een lineaire groei in performance en capaciteit. Immers, met het toevoegen van een node wordt niet alleen diskcapaciteit, maar ook performance toegevoegd (netwerkkaarten, CPU’s, geheugen). Dit heeft als voordeel dat de limieten van dit soort systemen veel en veel verder liggen. EMC heeft een oplossing als Isilon (gekocht) en HP heeft Ibrix (ook gekocht). Beide met limieten ver boven de 10PB. Dat klinkt erg 2011! Data groeit parabolisch, de groei groeit, dus daar moet een antwoord op komen. Alle ramingen die we hebben gedaan naar de toekomst toe baseren we op het verleden, maar als de groei groeit, kom je zelden goed uit.

Ik vraag me dus af wanneer deze scale-out architectuur ook in de meer traditionele SAN komt. Ik zie de problemen wel voor me: een SAN levert een block device, hoe biedt je dit aan over 32 netwerkpoorten over 16 nodes zonder binnen 1 seconde allemaal corrupte data te hebben? Dat is waar storage vendoren zich over mogen buigen. Misschien moet het wel een combinatie worden.  Wellicht zit het antwoord wel in de scale out mogelijkheden van een NAS gebruiken om een SAN te maken. De storage puristen onder ons zullen zeggen dat het dan geen traditioneel SAN meer is, maar wat dan nog? Kan dat niet ruimschoots gecompenseerd worden met de performance en schaalvoordelen die de scale out architecturen met zich meebrengen? Is dat niet de manier waarop NetApp al jaren succesvol is met hun FAS oplossingen? Ik ben geen storage expert. Ik heb het vooral nodig voor onze dienstverlening. Betrouwbare, snelle, schaalbare storage. En als ik performance mis wil ik machines toevoegen en een hotspot minder hebben. Herverdeel die data maar. En dan wil ik Fibre Channel kunnen praten, iSCSI, CIFS, NFS, HTTP, WebDav, SSH, S3 en FTP. Unified klinkt mooi, maar als ik kijk naar de Unified oplossingen in de markt, dan doen ze geen van allen alles.

Net als de server- en netwerkmarkt, is ook de storagemarkt op het moment flink in beweging. Het houdt het erg interessant, al is het best lastig om de goede keuze te maken voor de komende jaren. Storage koop je immers niet voor 6 maanden, of een jaar. Het is een lange termijn commitment. Hoe weet ik zeker dat ik goed zit?