We zijn enkele jaren geleden begonnen met virtualisatie op basis van Xen. Uiteraard hebben wij dit uitvoerig getest en we hebben de clusters op basis van Xen dan ook al een flinke tijd stabiel draaien. Waar klanten (gelukkig) niks van merken, is de beheerkant. Voor dit beheer zijn we momenteel deels afhankelijk van third-party tools. Na een tijdje kom je dan toch altijd kleine dingen tegen. Het betreft open source software, dus het is zelf aan te passen. Maar dat is weer lastiger met updates van de ontwikkelaars van de software. Je kunt ook losse dingen eromheen schrijven, maar dat komt het functioneren vaak ook niet ten goede.

Eind vorig jaar besloten we dat het tijd werd om alles opnieuw te bekijken. Na veel testen, is de keus gevallen op de virtualisatietechniek KVM en het ontwikkelen van eigen clustersoftware. Eigen software is makkelijker te combineren met bijvoorbeeld onze eigen beheer- & administratie-software en krijgen we daarnaast nog meer diepgaande invloed op onze clusters, wat weer handig is bij eventuele storingen.

Maar waarom geen Xen meer? Hiervoor waren eigenlijk meerdere redenen. Belangrijk was vooral dat Xen voornamelijk voor de, inmiddels verouderde, 2.6.18 kernel wordt ontwikkeld. Hierdoor missen vaak kernel modules voor de wat nieuwere hardware. De ontwikkeling van KVM lijkt wat actiever te zijn en meerdere Linux distributies hebben Xen ook de deur uitgedaan en vervangen door KVM. In Linux Debian Lenny zit wel een Xen kernel op basis van 2.6.26, maar we hebben tijdens onze testen deze niet volledig stabiel gekregen.

Verder hebben we met Xen ook andere kleine probleempjes. Zo gaat bijvoorbeeld een live migration (dus zonder downtime een virtueel systeem naar een ander fysiek systeem verplaatsen) niet altijd helemaal goed. KVM is op dit punt toch wel heel wat beter. Ook blijkt KVM iets betere performance te leveren dan onze huidige Xen opstelling.

Het grootste deel van deze ‘problemen’ is overigens niet aanwezig bij Citrix XenServer. Hierbij hebben we bijvoorbeeld zeer positieve ervaringen met live migration, op voorwaarde dat de software voor gastsystemen van Citrix geïnstalleerd is. Citrix XenServer heeft alleen weer als nadeel dat het wat minder open is en hierdoor veel meer afhankelijk bent van Citrix. Als oplossing voor onze klanten die zelf virtualisatie willen, is dat vaak geen probleem.

Het ontwikkelen van ons nieuwe cluster en bijbehorende clustersoftware heel wat manuren gekost.  Zo zijn onder andere het beheer van instellingen, toevoegen van virtuele systemen, ervoor zorgen dat er geen dubbele MAC adressen ontstaan in het netwerk, virtuele servers live migreren, de harddisks van een systeem kunnen vergroten en regelmatige automatische controles of alles nog wel correct draait,  enkele van de vele belangrijke beheer functies die onze clustersoftware moesten komen.  Ook klanten moesten meer controle krijgen over hun virtuele server, waaronder bijvoorbeeld het zelfstandig kunnen herstarten of via de console overnemen van een virtuele server zijn onderdelen die binnen ons klantensysteem ‘my.shockmedia.nl’ beschikbaar moesten komen.

Na veel ontwikkeling en testen is dan inmiddels ons nieuwe cluster, op basis van KVM en onze eigen clustersoftware, live gegaan. Nieuwe Virtuele Servers leveren wij dan ook per direct op vanuit ons nieuwe cluster.

iSCSI failover: uitval van een SAN is geen uitval van de storage
Een van de interessantere mogelijkheden van Open-E is wel iSCSI failover, waardoor uitval van een van de SANs niet een uitval van de storage betekent. Open-E weet binnen een seconde over te schakelen op het andere systeem, waardoor een hapering eigenlijk niet eens merkbaar is. Alle virtuele instances die op de storage hun data opslaan, blijven dus gewoon zonder problemen werken.

Betaalbaarder, maar ook beter
Een Open-E oplossing is een zeer goed betaalbare oplossing. Zo betaalbaar zelfs, dat licenties en hardware meegerekend, je in plaats van (de gebruikelijke oplossing) één enkele prijzige SAN, twee op Open-E gebaseerde SANs neer kunt zetten. Alle hardware kan altijd kapot, welk merk dan ook, maar het belangrijkst is om bij uitval toch zo min mogelijk problemen te hebben. Daarvoor kan wel een SLA worden afgesloten waarbij binnen 4 uur de SAN weer gerepareerd is door de leverancier, maar dan liggen wel alle servers er 4 uur lang uit. En een dergelijke SLA is vaak ook nog eens een behoorlijke periodieke kostenpost, naast dat 4 uur downtime natuurlijk niet is te verkopen aan klanten.

Ook de door Open-E geleverde performance is zeer goed. Door gebruik te maken van meerdere gigabit uplinks, is een zeer hoge data throughput haalbaar. In de server zelf wordt dan een goede hardware RAID controller geplaatst met zeer snelle schijven. Zo is met een SATA RAID 5 bestaande uit 4 schijven een snelheid van boven de 300 megabyte per seconde prima haalbaar. En voor de I/O intensieve applicaties is een SAS RAID 5 tegenwoordig ook goed betaalbaar.

Onze oplossing: high availability op maar 4 servers
Wij kunnen klanten dankzij Open-E en VMware of Citrix XenServer al een high availability oplossing bieden vanaf 4 ‘gewone’ dedicated servers. Op 2 servers draait de SAN met iSCSI failover en op 2 andere servers draait VMware of Citrix XenServer met automatische failover. Naast dat we hiermee een zeer stabiele oplossing bieden, is uitbreiding in de toekomst ook eenvoudig mogelijk, door bijvoorbeeld een extra fysieke server te plaatsen waar weer VMware of Xen instances op komen te draaien. En het mooie is, deze clusters ondersteunen zonder problemen zowel Windows als Linux. Of zelfs een combinatie van deze twee!

Twee dedicated servers inclusief Open-E met iSCSI failover, is al leverbaar vanaf 300 euro per maand.

Omdat wij alle systemen waarvan wij het beheer onder onze hoede nemen, proactief monitoren, trendgrafieken maken en regelmatig onderwerpen aan een grondige ‘checkup’, detecteren en verhelpen we vrijwel alle potentiële problemen voordat het problemen worden. Toch zullen er altijd problemen blijven ontstaan, die niet vooraf te voorkomen waren. Enkele voorbeelden van problemen die niet vaak proactief op te lossen zijn:

• Spontane filesystem corruption (door software of hardware) waardoor data in extreme gevallen corrupt kan raken.
• Zero-day exploits in gebruikte software waardoor hackers in extreme gevallen data zouden kunnen verwijderen.
• Mensenlijke fouten waardoor data perongeluk word verwijderd.
• Rampen en terrorisme.

De vraag die wij onszelf daarom regelmatig stellen is niet of een incident gaat plaatsvinden, maar altijd wanneer en hoe we op dat moment zo’n incident kunnen ondervangen. Deze conclusie heeft er tot geleid dat wij bijna paranoïde zijn geworden op het maken van goede backups en het redundant opslaan van data. Er zijn nooit teveel backups!

Backups en dataopslag bij Shock Media B.V.

Hiernaast staat een illustratie over hoe wij data in ons Xen-cluster opslaan en hier backups van maken. Om het voor minder technisch onderlegde mensen begrijpbaar te houden, zijn een aantal zaken versimpeld weergegeven. Data van onze klanten wordt op de fysieke server redundant opgeslagen d.m.v. hardware RAID, hiernaast word ook alle data realtime gerepliceerd naar een andere fysieke server, die als secundairy dient en eveneens met hardware RAID is uitgerust. Wanneer een fysieke server uitvalt, kunnen de virtuele systemen (die de data bevatten) eenvoudig op een ander fysiek systeem weer gestart worden. Hierdoor is de data van bijvoorbeeld een website, e-mail, database of applicatie al op 4 verschillende mediadragers realtime opgeslagen in het cluster.

Deze data staat allemaal nog wel in hetzelfde datacentrum. Hoewel dit datacentrum zwaar beveiligd is tegen brand, braak, water en andere soorten rampen, is wanneer bijvoorbeeld een vliegtuig land op het datacentrum een potentieel probleem voor verlies van data. Hierom maken wij ook offsite backups naar een backup-server in een fysiek ander – geografisch gescheiden – datacentrum. Wederom is deze server uitgevoerd met hardware RAID.

Als laatste maken wij periodiek complete backups naar backuptapes die weer op een geografisch gescheiden locatie worden opgeslagen. Deze data is niet via een netwerk verbonden maar is volledig offline. Dit zorgt ervoor dat de data extreem veilig staat, echter niet makkelijk toegankelijk om te gebruiken voor recovery van data. Dit is dan ook alleen in extreme situaties een extra uitwijk mogelijkheid.

Alle data van onder andere onze shared hosting, virtuele servers maar ook diverse dedicated servers en dedicated clusters worden door het gebruik van hardware RAID, netwerk-replicate, onsite backups, offsite backups en offline backups in totaal 9 keer opgeslagen.