Beschikbaarheid. Iedereen praat erover alsof iedereen hierin kan voorzien, op de een of andere manier. Helaas, als je een beetje graaft en goed kijkt dan blijkt dat er bijna net zoveel definities van beschikbaarheid zijn als dat er aanbieders zijn die zeggen het te kunnen bieden. Sommigen bedoelen de beschikbaarheid van de data en anderen bedoelen het systeem of de opslag. Een ding hebben ze allemaal gemeen ze gebruiken allemaal dezelfde mode woorden zoals: “ disaster recovery”,”real-time”, “bedrijfscontinuïteit” of “ hoge beschikbaarheid”, dit heeft tot heel veel verwarring en verkeerde opvattingen geleid over wat deze zaken nu echt in houden. Velen proberen het bedrijfsleven zelfs te beweren dat een paar uur uitval van een applicatie heel acceptabel is. Het woud aan oplossingen en de hype eromheen heeft het voor het bedrijfsleven heel moeilijk gemaakt om te zoeken naar een betere manier om zichzelf en de applicaties te beveiligen tegen uitval veroorzaakt door fouten en storingen.
De kern van de zaak, beschikbaarheid moet worden gedefinieerd als “ aanwezig en klaar voor gebruik, bij de hand en toegankelijk”. Het grijze gebied wat wordt uitgebuit door leveranciers van bepaalde oplossingen ligt in de mate waarin de tijdseenheid en welke systemen “ klaar voor gebruik moeten zijn”. Binnen de meeste organisaties liggen de beschikbaarheids eisen en behoeftes per applicatie en ysteem op een ander niveau. Enkele applicaties moeten continue beschikbaar zijn en mogen geen moment uitvallen, terwijl het merendeel wel een kleine onderbreking mag hebben. Beschikbaarheid is zeker geen “ een maat past alles” oplossing. Om de echte behoefte hiervan te begrijpen moet een bedrijf een risico analyse en impact onderzoek uitvoeren om te bepalen welk service niveau noodzakelijk is. Als een bedrijf de precieze behoefte van beschikbaarheid heeft vastgesteld dan kunnen afdoende oplossingen worden bekeken en onderzocht.
Er zijn letterlijk dozijnen producten te verkrijgen die een bepaald niveau van applicatie beveiliging bieden. Als u de marketing literatuur leest dan klinken de meesten ongeveer hetzelfde. Om eenvoudig de enorme hoeveelheid aan producten te begrijpen, zijn deze in 3 hoofdgroepen uit te splitsen:
- Fault-tolerante servers
- Shared disk clusters
- Replicatie en Failover
Wat hiermee bedoeld wordt en dat het ook anders kan kunt u in mijn volgende column lezen
Kom met uw praktijkervaringen op het terrein van managen en organiseren
Deel uw kennis, schrijf 3 columns of artikelen en ontvang een gratis pro-abonnement (twv €200)
Word een pro!
SCHRIJF MEE >>
Omdat ik werkzaam ben in de branche die oplossingen levert waarmee de beschikbaarheid van applicaties een niveautje hoger getild kan worden, voel ik me aangesproken door het generaliserende en ongenuanceerde begin van je column. Maar dat zal wel een doel dienen...
Het gaat inderdaad niet om het leveren van beschikbaarheid, maar om het beveiligen tegen uitval en storingen. Storingen doen zich voor:
a) binnen applicaties
b) binnen besturingssystemen
c) binnen serverhardware
d) in het (storage)netwerk
e) in de opslag
Deze storingen kun je terugbrengen door fout-tolerantie/redundantie in diezelfde onderdelen te verzorgen. Elk onderdeel van deze keten kent eigen zwakke punten, gevolgen van failure, en mogelijkheden ter voorkoming. Mocht dit alsnog misgaan, dan kun je met technieken als backup-restore, applicatie/serverfailover en storagefailover (en failback) de boel weer in de lucht brengen. De 'beschikbaarheid' van de applicatie is uiteindelijk afhankelijk van de snelheid waarmee je het herstel kunt realiseren. Er zijn vele technieken te gebruiken om deze oplossingen te realiseren, elk met voor- en nadelen en kosten. Complexiteit leidt daarbij vaak tot hogere kosten. In kleinere omgevingen moet je deze vermijden en kun je dus 1 maat aanmeten, in grotere omgevingen kan een complexere omgeving met meer maten kostenefficienter zijn.
Het klinkt alsof jij de losse schakeltjes in de keten kunt vervangen door een enkele (of dubbele) staalkabel. Ben benieuwd, onder voorbehoud...
Heel apart dat je leest dat het niet gaat om beschikbaarheid, maar om het beveiligen tegen uitval en storingen.
Ik lees juist dat het WEL gaat om applicatiebeschikbaarheid.
Het komt namelijk voor dat bepaalde applicaties NIET uit mogen vallen, omdat anders de schade erg groot is. Dit komt vaak voor bij productielijnen. Dan heb je niets aan DATA beschikbaarheid, die je inderdaad kunt realiseren met oplossingen die beveiligen tegen uitval en storingen.
Je vermeldt overigens ook storingen binnen applicaties - mocht dit voorkomen, dan zullen deze applicaties nooit in een bedrijfskritische omgeving worden gebruikt.
Stel je eens voor:
Een applicatie voor het snijden van vlees, wegen, verpakken en stickeren (soort vlees, gewicht, prijs, houdbaarheid etc). Als deze applicatie ook maar een seconde uit de lucht is, dan kun je een hele productierun vlees weggooien. Geldt ook voor chocoladepasta, auto's enz..
Dit probleem los je niet op met een oplossing die gebaseerd is op virtual machines en een cluster. Je hebt er niets aan als de data beschikbaar blijft.
Hiervoor heb je een Fault tolerant omgeving nodig, waar geen sprake is van failover/herstart bij disaster, maar waarbij de applicatie ondanks de disaster gewoon doordraait. Geloof me, deze oplossingen bestaan en ze kosten slechts een fractie van de schade die ze helpen voorkomen.