Zřejmě jste se již někdy setkali s pojmem Azure Recovery Services a asi víte, že pod ně spadají služby Azure Backup a Azure Site Recovery, které vám umožní v Azure jednoduše zprovoznit Backup-as-a-Service a Disaster Recovery-as-a-Service. Pojďme si podívat, o co se vlastně jedná, pro koho je služba vhodná a také se zaměříme na novinky, které se objevily na přelomu tohoto roku.
Azure Backup
Pojďme se nejprve podívat na Azure Backup a jeho možnosti zálohovat systémy on-premise, tak i virtuální stroje, běžící v cloudu Azure. Azure Backup je v podstatě odlehčená varianta DPM (Data Protection Manager, který je součástí System Center suity) a který je určen především pro scénář zálohování lokálních dat do cloudu pro SMB zákazníky, nemající licenci na DPM či System Center. Druhý scénář je určen spíše pro Enterprise zákazníky, kteří se chtějí zbavit zálohování na pásky a zálohy si chtějí odkládat do cloudu nebo kteří si potřebují ochránit virtuální stroje, které provozují v Azure.
Pokud si nainstalujeme agenta Azure Backupu přímo na server, který chceme zálohovat, jedná se o scénář zálohování souborového serveru, kdy se záloha ukládá nejprve na disk tohoto serveru a poté jeho kopie do cloudu. Druhá (nová) možnost je, že se agent Azure Backupu nainstaluje na samostatný server (tzv. Azure Backup server), který potom svým prostřednictvím komunikuje s ostatními chráněnými servery, na kterých je instalován agent Backupu (je to v podstatě agent DPM). V tomto scénáři lze zálohovat z disku na disk (v on-premise), nebo z disku na disk a poté jde další záloha do cloudu (D-D-C). Lze zálohovat jak fyzické tak i virtuální servery (a to jak Hyper-V, tak i VMware) a workloady pro Exchange, SQL Server či SharePoint. Mohou být chráněny všechny podporované virtuální stroje na daném virtualizačním serveru, tj. i linuxové VM. Pod Windows lze zajistit konzistenci dat na aplikační úrovni, pod Linuxem na úrovni souborové konzistence dat.
Alternativně lze (po instalaci agenta Azure Backupu na DPM server) ukládat kopie záloh do Azure pro zákazníky, používající System Center Data Protection Manager.
Obr.1: Zálohování on-premise serverů pomocí Azure Backupu.
Podrobnější seznámení a postupy pro nasazení najdete na Get started with Azure Backup (https://azure.microsoft.com/en-us/trial/get-started-backup/) nebo Preparing to back up workloads using Azure Backup Server (https://azure.microsoft.com/en-us/documentation/articles/backup-azure-microsoft-azure-backup/)
Pokud provozujete hybridní infrastrukturu a potřebujete chránit i své virtuální stroje běžící v prostředí Azure, lze i je jednoduše a efektivně chránit pomocí Azure Backupu. Tím své prostředí zabezpečíte před ztrátou či poničením dat, ochráníte před náhodným smazáním VM (i administrátor je jen člověk a může se utnout J) resp. lze takto jednoduše vyřešit kopírování VM. Azure Backup musí (logicky) ukládat zálohy do stejného regionu, kde běží vlastní VM. Jsou podporovány VM až se 16 datovými disky (plus disk pro OS), lze zálohovat běžící VM stejně tak jako v off-line módu.
Obr.2: Zálohování virtuálních strojů v Azure
Pozn.: Zatím není možné zálohovat stroje, běžící na tzv. premium storage (=SSD), ani šifrované VM (ale pracuje se na tom).
Pro sizing můžete použít kalkulačku Storage capacity planner (https://gallery.technet.microsoft.com/Azure-Backup-Storage-a46d7e33).
Vše lze pochopitelně automatizovat pomocí PowerShellu. Více viz Back up Azure virtual machines (https://azure.microsoft.com/cs-cz/documentation/articles/backup-azure-vms/) nebo Deploy and manage backup to Azure for Windows Server/Windows Client using PowerShell (https://azure.microsoft.com/en-us/documentation/articles/backup-client-automation/).
Zálohy jsou zabezpečeny (po předchozí komprimaci, která dokáže snížit objem dat o 50-70 procent) šifrováním AES 256. Šifrovací klíč se vygeneruje na lokálním stroji a je chráněn tzv. PassPhrase (PEK) o délce 16-1024 znaků. Klíče si musí správce pečlivě uschovávat (u sebe nebo v Azure Key Vault – viz např. Get started with Azure Key Vault - https://azure.microsoft.com/en-us/documentation/articles/key-vault-get-started/). Takto zašifrovaná data jsou poté přenesena pomocí protokolu HTTPS do cloudového úložiště a zde zůstávají vložena v nezměněné (zašifrované) podobě. Azure Backup vyhovuje normě ISO 27001 (Information Security Management) a také řadě dalších jako je HIPAA aj., více viz. Azure Trust Center.
Zbývá odpovědět, jak že se vlastně Azure Backup licencuje. I zde nastala menší změna – poplatky se skládají ze dvou částí, jednak je potřeba mít licencovány všechny chráněné instance pomocí licence na Azure Backup, a jednak se platí standardní poplatek za využité místo na Azure Storage. Licenční poplatek se liší podle velikosti instance (do 50 GB je to 5 USD/měsíc, 50-500 GB za 10 USD/měsíc, pro instance větší než 500 GB navíc inkrement po 500 GB opět za 10 USD). A co se počítá do oné velikosti instance? Je to buď celková velikost souborů a složek (pro Windows klienta či server), nebo celková velikost instance, databáze a obsahové (content) farmy pro aplikační servery, případně celková velikost VHD disků pro virtuální stroj. Cena za Azure Storage se samozřejmě liší podle toho, zda jsme si vybrali pro ukládání dat do LRS (3 kopie dat) nebo GRS (3+3 kopií dat ve dvou regionech). Pozor, tuto volbu nelze později změnit, je nutno si předem vybrat konkrétní typ již při vytváření úložiště. Příjemné je, že za Azure Backup již dále neplatíte žádné další poplatky za obnovování dat, transakce či přenosy dat.
Azure Site Recovery
Druhou službou v rámci Azure Recovery Services je služba Azure Site Recovery (ASR). Ta umožňuje zajistit automatizované přepnutí (failover) na záložní datové centrum resp. po odstranění původní závady automatizovat návrat zpět do primárního datového centra (failback). Takovéto přepnutí je možné docílit v řádu minut a tím radikálně snížit RTO (Recovery Time Objective), neboli dobu, za kterou lze po výpadku pokračovat v práci a rovněž snížit RPO (Recovery Point Objective), tj. o kolik dat přijdeme.
Azure Site Recovery umí pracovat ve dvou režimech – jako koordinační jednotka mezi dvěma zákaznickými datovými centry nebo (pokud zákazník nemá k dispozici záložní datové centrum) Azure může být tímto záložním datovým centrem, do kterého se systémy po výpadku přepnou. Takto lze ochránit virtuální servery s Hyper-V, VMware či fyzické servery.
Dvě datová centra a ASR
Pojďme si nejprve projít první variantu se dvěma DC:
V případě Hyper-V serveru musí být obě datová centra (primární i záložní) vybavena System Center Virtual Machine Managerem, který komunikuje se službou Site Recovery. Datová centra jsou spolu propojena (LAN či VPN) a tímto kanálem probíhá vlastní replikování dat na úrovni hostů.
Obr.3: Azure Site Recovery pro dvě datová centra s Hyper-V
Replikace dokonce může být realizována na úrovni SAN storage, která zabezpečí takřka nulové RPO (NetApp, HP 3PAR, EMC VMAX – viz. [
http://social.technet.microsoft.com/wiki/contents/articles/28317.deploying-azure-site-recovery-with-vmm-and-san-supported-storage-arrays.aspx](http://social.technet.microsoft.com/wiki/contents/articles/28317.deploying-azure-site-recovery-with-vmm-and-san-supported-storage-arrays.aspx)
). ASR potom orchestruje vlastní přepínání (failover/failback) pomocí protokolu HTTPS.
Obr.4: Dvě DC s Hyper-V a replikací na úrovni storage
Poněkud jiná situace je v případě, kdy v obou datových centrech je virtualizaci řešena pomocí VMware. V tomto případě je replikace mezi datovými centry realizována technologií Scout, která díky pomocným serverům zajišťuje komunikaci mezi primárním datovým centrem (s VMware a/nebo fyzickými servery) a záložním datovým centrem (s VMware). Tato replikace zajišťuje takřka nulové RPO. Kanál mezi Azure a datovými centry slouží pouze ke stažení agenta a zajišťování stavu licencí.
Obr.5: ASR a dvě datová centra s VMware
Jedno datové centrum a Azure
Druhý typ scénáře pokrývá situaci, kdy zákazník disponuje pouze jedním datovým centrem, ale přesto potřebuje zajistit nízké hodnoty RTO/RPO. Zde Azure zároveň poskytuje i službu záložního datového centra, do kterého při failoveru překlápějí zákaznické aplikace.
První varianta je pro Hyper-V virtualizaci (ať již s nebo bez VMM), kdy se změny VM replikují pomocí protokolu HTTPS do příslušných Azure Storage kontejnerů, které v případě výpadku slouží jako virtuální disky pro VM, které se rozběhnou v prostředí Azure. Teprve po failoveru se v Azure nastartují virtuální stroje a řídící logika na ně přesměruje klienty. Varianta bez VMM je určena buď pro SMB zákazníky nebo pro pobočková řešení větších zákazníků (mající VMM v centru).
Obr.6: ASR a replikace Hyper-V do Azure
Novější varianta ASR pro VMware (nebo fyzický server) s jedním datovým centrem se proti původní zjednodušila tím, že v Azure je již připravena kompletní infrastruktura a na straně on-premise lze použít jediný pomocný server, který zajistí veškerou komunikaci pro replikování dat i řízení přepínací logiky.
Obr.7: Vylepšené ASR pro replikaci VMware do Azure
ASR umí zajistit i aplikační konzistenci dat (AD, IIS, RDS, VDI, FS, SQL, SharePoint, Exchange, Oracle, SAP). SQL Sever a jeho technologie HA/DR se skvěle doplňují s ASR, SQL AlwaysOn Availability Groups jsou synchronizovány s recovery plány ASR (viz Protect SQL Server with SQL Server disaster recovery and Azure Site Recovery - [
https://azure.microsoft.com/en-us/documentation/articles/site-recovery-sql/#integration-with-sql-alwayson-to-azure](https://azure.microsoft.com/en-us/documentation/articles/site-recovery-sql/#integration-with-sql-alwayson-to-azure)
resp. Configure AlwaysOn Availability Groups in Azure VM (GUI) - [
https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-sql-server-alwayson-availability-groups-gui/](https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-sql-server-alwayson-availability-groups-gui/)
). Oracle je na tom podobně díky využití jeho technologie Oracle Data Guard, která si rozumí i s ASR (viz Configuring Oracle Data Guard for Azure - [
https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-configuring-oracle-data-guard/](https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-configuring-oracle-data-guard/)
). Exchange Server je již sám o sobě připraven na vysokou dostupnost, jeho DAG je možné snadno integrovat s ASR. Více informací najdete např. v článku What workloads can you protect with Azure Site Recovery? ([
https://azure.microsoft.com/en-us/documentation/articles/site-recovery-workload/](https://azure.microsoft.com/en-us/documentation/articles/site-recovery-workload/)
).
Obr.8: ASR a SQL – replikace do Azure
Pro správný chod ASR je zapotřebí zajistit dostatečnou kapacitu připojení k Internetu (VPN) nebo přímého připojení pomocí zařízení ExpressRoute. Kapacitu lze určit pomocí Azure Site Recovery Capacity Planner ([
https://gallery.technet.microsoft.com/Azure-Recovery-Capacity-d01dc40e](https://gallery.technet.microsoft.com/Azure-Recovery-Capacity-d01dc40e)
). Informace o integraci s ExpressRoute lze najít na odkazu ExpressRoute + ASR = Efficient DR solution ([
https://blogs.technet.microsoft.com/virtualization/2014/07/20/expressroute-asr-efficient-dr-solution/](https://blogs.technet.microsoft.com/virtualization/2014/07/20/expressroute-asr-efficient-dr-solution/)
). Objem přenosu dat lze podstatně snížit (až o 3/4) použitím vhodného WAN traffic shaperu, např. SteelHead: Optimizing Azure Site Recovery (ASR) with Riverbed® SteelHead™ WAN Optimizers (https://www.microsoft.com/en-us/download/details.aspx?id=44571).
Licencování ASR se samozřejmě liší podle toho, zda funguje ve scénáři s jedním nebo dvěma datovými centry. Pro dvě DC je cena licence samozřejmě nižší než v případě jednoho centra, kdy ještě navíc musíme počítat s cenou za spotřebovaný storage a cenu za běh VM v případě failoveru. Je příjemné, že prvních 31 dnů máte ASR k dispozici zdarma.
Při vyžívání služeb Azure Recovery Services musí mít zákazník k dispozici buď vlastní předplatné na Azure nebo využívá služeb Azure od partnera, který má uzavřenu s Microsoftem smlouvu v rámci tzv. Cloud Solution Programu (a má tím možnost přeprodávat služby Azure třetí straně). První varianta bude asi častější pro větší zákazníky nebo firmy, které již do cloudu investovali. Druhá bude asi zajímavější pro menší firmy, pro které není výhodné uzavírat předplatné s variantou Pay-as-you-go či se vázat k odběru služeb v určité hodnotě. Při využívání partnerského modelu totiž zákazník platí měsíčně jen za to, co využívá a nemusí se nijak zavazovat k určité velikosti odběru.
#### Závěr
Jak je vidět, služby Backup-as-a-Service a/nebo DR-as-a-Service se dají poměrně jednoduše a relativně levně nasadit i u zákazníků, kteří předtím o takovémto řešení ani neuvažovali. Výhodou je především široká škála scénářů, které pokrývají a rychlost a snadnost nasazení. Důležitým aspektem je i podpora většiny důležitých aplikací. Pro řadu zákazníků též může být značným pozitivem průběžné placení za užívání služby bez potřeby velké počáteční investice.
Slovníček pojmů
Disaster Recovery
Pojem Disaster Recovery znamená obnovu po havárii. Přesněji řečeno, jedná se o předem připravený scénář, který vede k obnově infrastruktury po nastalé (někdy jen simulované) havárii – ať již fatální havárii hardware nebo software, problému způsobeného lidským faktorem, živelnou katastrofou případně jiným selháním.
Příprava správného scénáře Disaster Recovery není triviální, protože by mělo dojít i k ověření jeho správnosti obnovou celé infrastruktury v jiné lokalitě. Vysoká náročnost takovéto (byť zkušební) obnovy (zejména z pohledu finančních i lidských prostředků) často vede k podcenění významu nebo dokonce k absenci takového scénáře.
Business Continuity
Sada aplikovaných procesů v organizaci, které vedou ke snížení nebo eliminaci následků havárie jednotlivých komponent IT infrastruktury či infrastruktury jako celku na fungování organizace.
V posledních letech se zejména díky možnostem virtualizace stala v podnicích fenoménem a díky cenové dostupnosti jejích výhod již dnes dokážou využívat i podniky z oblasti malého a středního podnikání.
Na druhé straně se však s rostoucím počtem pořizovaných dat objevuje jiné riziko v oblasti business continuity, kterým je doba trvání zálohovacích procedur a v návaznosti na to i doba obnovy zálohovaných dat (tzv. RTO). Stále větší důraz je kladen na jiné geografické umístění záloh (tj. mimo hlavní lokalitu) a následnou možnost rychlého zprovoznění infrastruktury i v případě havárie hlavní lokality.
Retenční politika
Nastavením správné retenční politiky chráníte vaši organizaci před ztrátou dat, která by konvenční záloha dávno nenávratně přepsala.
Retenční politika se objevila společně s příchodem snapshotů a deduplikačních metod do oblasti zálohování. „Retenční politikou“ nebo též „politikou rentence dat“ stanovujeme počet záloh daného stáří, které se v zálohovacích archivech udržují.
Retenční politika chrání organizaci před ztrátou dat, u kterých se tato ztráta nebo poškození projeví až poté, co proběhne standardní zálohovací procedura (např. full-backup) a v konvenčním zálohovacím režimu by byly nenávratně ztraceny přepsáním staré zálohy novou, která již tato data neobsahuje.
Můžete takto stanovit například politiku zachovávat 24 hodinových záloh, dále 7 denních, 52 týdenních, 2 roční. Díky tomu jste schopni obnovit data z předchozích 24 hodin s přesností jedné hodiny, data až 7 předchozích dnů s granularitou den atd.
Politiku retence dat by měla definovat organizace nebo by o ní měl mít povědomí management, aby byl zaručen soulad s právními požadavky a potřebami.
RPO – Recovery Point Objective
RPO popisuje stáří dat, která mám k dispozici v pravidelné záloze. Havárie v průběhu dne může znamenat nutnost obnovy z noční zálohy. Např. pravidelné noční zálohování znamená RPO v řádu hodin. Pokud nastane v průběhu dne havárie, kvůli níž je nutná kompletní obnova dat z noční zálohy, dojde ke ztrátě dat pořízených v průběhu celého dne.
Moderní trendy zálohování v IT proto zkracují RPO až do řádu několika minut. Pracují na principu snapshotů, tedy rozdílových změn od poslední zálohy. Tím zkracují dobu nutnou pro zálohování (přenáší se jen změněné datové bloky) a mohou si proto dovolit spouštění zálohy několikrát za den nebo dokonce i několikrát za hodinu.
RTO – Recovery Time Objective
RTO popisuje dobu nutnou k obnovení dat ze zálohy. Nevhodně nastavené procesy mohou znamenat délku obnovy několik hodin i dnů.
RTO vyjadřuje dobu obnovení dat nebo systémů ze zálohy. V oblasti zálohování se jedná o zásadní kritérium, které je společně s RPO směrodatným ukazatelem, jak jsou nastaveny procesy Disaster Recovery a jaké mohou mít dopady na fungování organizace v případě výpadku.
Standardní obnova dat ze zálohy může trvat několik hodin i dnů – administrátor musí najít správný zdroj zálohy (např. pásku) a data ze zdroje načíst a rozbalit do požadovaného umístění. Moderní trendy zálohování a přípravy na obnovu (snapshoty, virtual stand-by) zkracují RTO téměř na nulu, tj. v případě havárie lze spustit systémy okamžitě na jiném HW, případně lze připojit sdílený nebo virtuální disk s předchozí zálohou téměř okamžitě.