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.

‘Het voelt als de laatste stap tot volledige zelfstandigheid’, zegt CTO Ruben van der Zwan. ‘We waren als broer van Argeweb al helemaal zelfstandig, maar zo zagen klanten dat niet altijd en daar zal nu verandering in komen. Het is natuurlijk fijn om enerzijds mee te liften op de betrouwbare naam die Argeweb de afgelopen jaren op het gebied van hosting heeft opgebouwd, maar het moet in de markt ook duidelijk zijn dat het hier om een compleet andere organisatie gaat. Wij doen grote projecten en zijn vooral een technische club die bedrijven compleet ontzorgt, terwijl Argeweb haar focus voornamelijk op marketing legt en ondernemingen helpt met hoogwaardige producten op abonnementsniveau.’

Internationale naam
Met Amsio heeft het bedrijf gekozen voor een korte, internationale naam, die officieel staat voor: Argeweb Managed Services Infrastructure & Outsourcing. Op 1 maart is de website www.amsio.com live gegaan. Een versie gebaseerd op de voormalige website. Op 1 mei zal een compleet nieuwe website voor Amsio worden gelanceerd.

Bedrijfsstructuur
Wat betreft directie en personeel verandert er niets. De holding waar zowel Argeweb als Amsio onder vallen blijft bestaan en zal verder gaan als ‘Argeweb Amsio Holding’. Argeweb zal de toevoeging ‘Online Services’ minder gaan gebruiken, aangezien er ook geen ‘managed services’ meer op de markt is.

CO2 neutraal
Uiteraard waren de datacenters van Amsio al CO2 neutraal, maar tegelijk met deze naamswijziging is per 1 maart de complete holding groen. Dat betekent dat zowel Argeweb als Amsio per vandaag het CO2-neutraal keurmerk mogen voeren. Ook de complete kantooromgeving, het vervoer en al het drukwerk wordt gecompenseerd.

Over Amsio
Amsio is ontstaan uit het in 2000 opgerichte Argeweb en is met drie netwerk locaties in Amsterdam en Schiphol, grote EMC storage oplossingen en duizenden servers een van de grotere managed hostingproviders van Nederland. Amsio levert oplossingen op het gebied van applicatiehosting en netwerkbeheer, maar regelt ook de outsourcing van werkplekken van middelgrote organisaties. Amsio werkt voor bekende websites en overheden en beheert het complete netwerk en de infrastructuur van webhostingprovider Argeweb. Amsio is lid van de DHPA en is Microsoft Gold partner op het gebied van hosting.

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.

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/

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.

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?