Managed hosting door True
Onderstaande bijdrage is van een externe partij. De redactie is niet verantwoordelijk voor de geboden informatie.

Cloud Disaster Recovery met Computication

Een uitwijklocatie in verband met disaster recovery is tegenwoordig veilig in de cloud te realiseren. Dit is veelal goedkoper dan een uitwijkcomputerruimte, omdat geen investering nodig is in servers, extra beheer en communicatie. Computication, aanbieder van it-beheerdiensten en specialist in cloud computing, biedt een dergelijke oplossing aan als dienst: Cloud Disaster Recovery, onderdeel van het ict-assurance pakket.

De ict-assurance dienst van Computication bestaat uit het regelmatig maken van een snapshot van de gegevens en datastructuren op de hoofdlocatie die vervolgens naar het datacenter van Computication gaan. Aangezien het repliceren van de snapshot-data naar de cloud-omgeving veel tijd kost, is de informatie soms één of meerdere dagen oud. Maar dat vangt de cloud-specialist op met de dagelijkse back-up, zodat in geval van een ‘ramp’ vrij snel over het complete it-landschap is te beschikken. De medewerkers kunnen binnen 24 uur weer aan het werk in hun eigen it-omgeving met bijbehorende rechten en plichten.

Omdat Computication werkt met een datacenter dat de hoogste veiligheidsgaranties afgeeft, is de uitwijk in de cloud een goed beveiligde oplossing. De kosten van de cloud-omgeving worden gedeeld door meerdere klanten. Deze schaalgrootte zorgt voor een betaalbaar alternatief. De kosten van de Cloud Disaster Recovery-dienst zijn volgens Computication een fractie van het bedrag dat je kwijt bent als je het zelf via bijvoorbeeld een mirror site wilt regelen.

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Reacties

Klinkt best leuk. 1x per dag een back-up en tussentijds wat snaps vult niet bij iedereen de RPO en RTO in. En mogelijk zal beperkte bandbreedte hier een spelbreker zijn.

DR is natuurlijk veel meer dan alleen wat servertjes + een copie van de data aanbieden. Logistiek en organisatorisch moet er natuurlijk ook flink wat in geregeld worden.

Ik ben benieuwd naar meer details.

Wat een slechte marketing!
Tegenwoordig lees je overal dat cloud voordeliger is omdat er geen investering nodig is in de benodigde hardware etc etc!
Onderbouw eerst de voordelen van je product met een berekening en een overzicht van zaken die je in een traditionele uitwijk vs cloud nodig hebt. Laat pas zien dat je met deze oplossing voordeliger uit bent dan met traditionele backup/uitwijk.

Bovendien ik kan ook met een product zoals Evault, Back-up-as-a-Service aanbieden. Wat is er nieuw aan Computication?

@Ruud: Kom uit dat on-premises hol :-) Bandbreedte tussen datacenters is tegenwoordig behoorlijk! 30 Gb verplaatsen tussen AWS en Windows Azure is minuten werk en dan gebruik ik geen premiums.

Verder eens dat er geen details geboden word (marketing?)

@Reza: Het is geen opinie, maar productnieuws.

Het "wat is nieuw" deel: Het is voor hun nieuw om het aan te bieden. Dus niet globaal een nieuwe dienst, maar een dienst die zij sinds kort aanbieden.

De enige reden dat ik dit artikel las was omdat er reacties waren :-)

Henri,

Je leeft nog teveel met je hoofd in de wolken en dan wordt de realiteit ietwat wazig :-)

Dus ik zal je even helpen om weer met beide benen op de grond te komen.

Ik deel je mening dat de bandbreedte tussen de grote DC's goed ingeregeld is. Echter is dit vanuit de eindklant ( en daar praten we hier over ) niet altijd het geval. En dat is waar ik op doelde.

Bandbreedte kan je natuurlijk minimaliseren door WAN-optimalisatie, deduplicatie en snapshots. Zo kan je slim, snel en met zo min mogelijk bandbreedte je data ergens in een DC neer zetten.

Maar alleen dat is natuurlijk niet DR. Bij DR komt veel meer kijken en dat mis ik een beetje in dit stuk.

Ook zal ik je even een leuk rekenvoorbeeldje bandbreedte uit de praktijk geven. En dan gebruik ik in tegenstelling tot velen alleen praktijk waardes en geen marketing getallen. Dus ze zijn ietwat conservatief.

2 Mb = 0.72 GB per uur
10 Mb = 3.6 GB per uur
50 Mb = 18 GB per uur
100 Mb = 36 GB per uur
1000 Mb = 360 GB per uur


Als een klant 15 TB bedrijfskritische data heeft dan ben je toch echt wel even bezig om het terug te halen. En dan is 24 uur niet haalbaar. Hier is dus van belang dat je goed je data en de daarbij behorende applicaties kwalificeert.

@Ruud: Point taken!

En DR is idd meer dan data verplaatsen. Als je twee databases hebt die en groot zijn en data uitwisselen is het terugzetten van een backup zeker niet voldoende.

"Cloud Disaster Recovery" is in deze dus een "cloud washing" term. Verkoopt leuk maar is geen kant en klaar product welke met een druk op de knop alles oplost.

@ Henri,

Yep. U snapt mijn punt. DR wordt nog te vaak onderschat. Met alleen het veiligstellen van de data ben je er nog niet.

Buiten de technische kant komt er natuurlijk ook op logistiek en procedureel gebied veel meer bij kijken.

Henri,
Ik heb al eerder opgemerkt dat het bekijken van de zaken rondom ict-infrastructuur andere kennis nodig heeft. Het is ook heel anders dan de kennis en ervaring die een ontwikkelaar heeft. Jij bekijkt de zaak als ontwikkelaar heel anders dan een infrastractuur-integrators zoals Ruud.

Ik vind de zaken die Ruud benoemd heeft zeer terecht.

Als 'Independent' professional met o.m. expertise gebied DRS en audits, haal ik ook even mijn schouders op bij een summier stukje als deze.

In de eerste plaats is cloud een aardige oplossing voor tal van diensten. Zeker niet voor alle typen en soorten diensten zou ik cloud adviseren. Dat je dan in de zin van continuity management iets aan cloud zou hebben, kan ik me wel iets bij voorstellen.

Dat er vanuit het DC beredeneerd bandbreedte geen enkele issue is, ongetwijfeld. Maar de eerstvolgende bottleneck, welke en waar die moge zijn, zou dat wel eens kunnen zijn en die bottleneck is nu eenmaal niet altijd in regie van dat DC.

Ik wil niet al te negatief klinken maar wanneer je DSR roept, dan heb je het over een expertisegebied en niet 'iets' dat je er even bij doet. Er komen namelijk nogal wat zaken bij kijken. En om met mijn 'mede professionals' te spreken, dat kom ik hier dan weer even niet tegen.

wordt vervolgd?

Helemaals eens NumoQuest. Dit heb ik in meerdere opiniestukjes al beschreven. DRS is niet alleen ijzer maar ook mensen.

@Reza, zaken van Ruud zijn ook zeer terecht.

En hoewel ik (cloud) software ontwikkel heb ik meer ervaring met disaster recovery dan je zult denken.

Als je heel erg op cloud focussed zul je ook merken dat een DR in de cloud een stuk simpeler is als je software al vanaf de grond toe opgebouwd is voor dit soort scenario's. Dit houdt o.a. in dat je interdependency van databases vermijdt of transactioneel afghandeld. (roll back en roll forward) en bepaalde zaken zoals queues a-synchroon laat lopen met een hoge mate van fout tolerantie.

Traditionele DR kan best (zeer) pittig zijn. Moderne op cloud gebaseerde software gaat het er echt heel anders aan toe.

Ook hier gaat de pets vs cattle analoog heel erg op. Als je een band hebt met jouw servers die ook echt een naam hebben... zit je niet op het juiste spoor.

Dus goede architecturen zijn vanaf de grond opgebouwd voor falen....

DR is dus niet altijd complex en moeilijk...




@Ruud


transport in netwerken gaat in (M)bit/s
opslag in bytes

dan is 1000Mb/s niet gelijk aan 360 GB/uur......

Henri,
Zoals altijd merk ik een verschil tussen hoe en de plek waaruit we naar hetzelfde vraagstuk kijken!
Ik bekijk naar DR vanuit de huidige situatie en IT-landschap (lees traditionele wijze)en jij (als ik me niet vergis) vanuit je cloudvisie!

Ik spreek je niet tegen als je het over DR en vooral jouw vakgebied " database" in de cloud hebt. Maar hoeveel % van bedrijven met hun "totale ict-landschap" zitten nu echt in de cloud? Hoeveel organisaties hebben zich los getrokken van de afhankelijkheden van hun servernamen? Wat heb je aan een (cloud)oplossing die niet zijn doelstellingen kan behalen zolang de ict-omgeving traditioneel ingericht is?

Ik had vorige week te maken met een uitwijktest en wat was de uitdaging in die test? Ja, de servernamen!

De voordelenn van de cloud zullen we nog zien en meemaken (of het waar is of niet), misschien is het handiger dat je je (in je reacties) tot die tijd inleeft/indenkt in de huidige situatie van de klant, dus met de beide benen op de grond.

Vanuit deze positie kun je beter de stappen naar cloud zetten en je klant meenemen dan in de cloud staan en naar je klant kijken, ben ik van mening!

Misschien

@ Maarten,

I know.

Ik reken eerst Mb naar MB om en dan naar GB's. En dan pak ik nog eens 80% van de max. Dat zijn namelijk de meest reeele cijfers en geen marketing prietpraat ( dus overhead filesystem/protocol )

Ik ben erg benieuwd naar de eventuele fouten die je ziet in mijn berekening.

Dank voor de reacties op het artikel Cloud Disaster Recovery. Het bericht is een eerste introductie van deze nieuwe dienst, zonder uitgebreid uit te wijden over de ins en outs hiervan. Maar gezien de reacties geef ik hierbij een toelichting.

De bedoeling is om ondernemingen eenvoudig en laagdrempelig toegang te geven tot een fallback scenario in het geval van een ernstige outage. Het is niet de bedoeling om een dienst te introduceren die een real-time failover verzorgd. Want een real-time replicatie met failover functionaliteit vergt middelen die voor veel bedrijven en organisaties niet binnen bereik liggen; de risico’s wegen vaak niet op tegen de kosten.

Wat wij zien is dat bij een calamiteit veel tijd verloren gaat aan het weer beschikbaar krijgen van de infrastructuur die nodig is om de IT diensten te leveren. Als het serverpark onbruikbaar is geworden, met welk (tape) systeem ga je dan je backup herstellen? En waar haal je op korte termijn nieuwe servers vandaan om de data op te slaan en beschikbaar te maken voor gebruikers? Die apparatuur kan je natuurlijk huren en ergens co-locaten maar dat kost tijd. Vervolgens moet het herstel dan nog beginnen.
De nieuwe dienst voorziet in een snelle beschikbaarheid van draaiende kopieën van de originele serverinfrastructuur plus remote desktop faciliteit. Wat we doen is snapshots maken van het serverpark naar een lokaal opslagmedium. Die bestanden repliceren we naar ons cloud platform. Op dat cloud platform is capaciteit gereserveerd die pas wordt gebruikt als het fallback scenario in gang word gezet. Op die manier zijn de kosten voor het beschikbaar houden van voldoende capaciteit vele malen lager dan wanneer een onderneming eigen capaciteit moet kopen en beheren.

De op het Cloud platform opgestarte servers kunnen, door de terecht genoemde bandbreedtebeperkingen, een iets verouderde dataset hebben. Die servers worden snel up-to-date gemaakt met de data uit de dagelijkse backup. Dit proces kan direct starten aangezien de tijdrovende eerste stap van herstel van de infrastructuur kan worden overgeslagen.

Het voordeel van deze werkwijze is dat een onderneming in korte tijd weer beschikt over de vertrouwde infrastructuur inclusief alle functionaliteit, rollen, rechten, applicaties etc die nodig zijn om de bedrijfsvoering te continueren. De IT diensten zijn dan beschikbaar middels een remote desktop faciliteit die vanaf bijv. een tijdelijke kantooromgeving kan worden gebruikt, of door medewerkers vanuit huis.

Er is voor disaster recovery inderdaad geen kant-en-klaar product dat alles oplost. Verstandig is het opstellen van een degelijk disaster recovery plan zodat de factoren mens en organisatie ook de benodigde aandacht krijgen. Want alleen dan zal de uitvoering van een disaster recovery scenario succesvol zijn.

Hoor graag weer, Martijn van der Schaaf.

Reza, dit artikel krijgt meer reacties dan het verdiend, maar had een relatie naar cloud :-) Ja we hebben vaak een andere invalshoek maar mijn insteek is echt niet onrealistisch of futuristisch hoor.

Maar ik doe meer dan een database in de cloud en vele bedrijven met mij. Veel klanten doen al behoorlijk wat met "private" cloud computing. Ofwel ze virtualiseren wat servers en data bij een 3e partij en kunnen die uitbereiden, daarbij merk ik inderdaad op dat er maar weinig bedrijven hun architectuur zodanig opzetten dat deze niet vasthangen aan server namen. Desalniettemin is disaster recovery heel breed hoor. Je biedt een dienst aan, maar de dienst wordt onderbroken omdat 1 van je servers omvalt. Ik vind het dan zeer primitief dat het omvallen van 1 server leidt tot een dag uit de lucht zijn.

Maar het is ook DR als je provider failliet gaat of je toegang ontzegt.

Daarnaast denk ik dat je vooral in een ander eco-systeem opereert. Jij zit misschien veel bij bedrijven die vooral diensten afnemen, mijn klanten zijn vaak bedrijven die (online) diensten aanbieden. Beide kunnen profiteren van cloud computing en beide hebben te maken met DR. en DR speelt zich op veel niveaus af. Een authenticatie service die omvalt kan een hele grote impact hebben, maar een mailserver die omvalt wellicht een stuk minder, maar zelfs dat is een gevaarlijke aanname. Niettemin heeft heeft cloud computing (of dit nu on-premises is, of extern) zeer veel mogelijkheden om enerzijds DR te voorkomen, anderzijds om hier sneller van te herstellen. Dit is echt geen toekomst muziek en gewoon realiteit. Dat veel bedrijven daar nog niet aan toe zijn gekomen is een heel ander verhaal.

Ik ga echt niet in elke reactie een context geven. Die geef ik wel als mensen ernaar vragen of als er een context hiaat is gevallen :-) Daarnaast herkennen veel mensen mijn perspectief al, en dat is niet per ongeluk.

Juist omdat ik me in klanten inleef kan ik ze helpen, alleen hebben we blijkbaar andere klanten, andere uitdagingen en zijn de klantwensen ook nog eens anders. Ik wordt niet gevonden voor het opzetten van bijvoorbeeld een Citrix omgeving. Dat is niet mijn ding, of het soort oplossingen wat ik bied. Ook niet voor een grote migratie van Windows X naar Windows Y.

Maar ik zeg het nogmaals, ik ben geen filosoof die toekomst muziek levert en fietsverhalen ophangt. Echte oplossingen voor een echte wereld , voor echte bedrijven.

@ Martijn,

Thanks voor je feedback. Altijd goed om te zien dat een leverancier "durft" te reageren.

Is er trouwens ergens nog meer informatie omtrent de techniek achter deze oplossing te vinden ? Ik ben erg benieuwd hoe jullie dit doen. Op jullie website kan ik dit namelijk nog niet vinden.

@ Henri/Reza,

Zullen jullie het ooit met elkaar eens worden? :-)

@Ruud

Ik las het als berekening. Daardoor miste ik wat, de protocoloverhead 20%, op zich dus nu correct!

@ Maarten,

Gelukkig anders deed ik het al jaren chronisch fout :-)

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.