Omezení SQL Database
Přesto, že SQL Database vychází z klasického Microsoft SQL Serveru, obsahuje některá omezení funkcionality, která je třeba brát v potaz. Pokud je vaše aplikace závislá na využití vybraných funkcionalit SQL Serveru, které nejsou v SQL Database k dispozici, a přesto chcete databázi migrovat do cloudu, musíte buď aplikaci upravit nebo si vytvořit celý virtuální server v rámci služby Azure Virtual Machines, kde si můžete nainstalovat klasický SQL Server 2012 v požadované edici. První způsob může být velmi nákladný a druhý přístup vás nezbaví povinností spojených s údržbou SQL Serveru a placením licencí (pronájem licence na SQL Server je v tomto případě přičten k ceně Azure Virtual Machine). Pokud budete navíc požadovat vysokou dostupnost, budete muset tyto virtuální servery vytvořit alespoň 2, což bude pro malé množství databází podstatně dražší než služba SQL Database.
Při návrhu databáze je nutné pamatovat na to, že SQL Database vyžaduje, aby každá tabulka měla clustered index. SQL Server umožňuje vytvářet i tabulky bez clustrovaného indexu, kdy jsou řádky organizovány v datové struktuře halda (tento přístup může být výhodný zejména u velmi malých tabulek, kde se procházejí všechny záznamy). SQL Database využívá informací v clustrovaném indexu při replikaci dat mezi jednotlivými replikami kvůli zajištění vysoké dostupnosti. Pokud budete migrovat existující databázi, která porušuje toto pravidlo, stačí pouze dodatečně založit clustrované indexy (SQL Server Management Studio ve výchozím chování clustrovaný index vytváří nad sloupcem, který zvolíte jako primární klíč).
Z pohledu vývojáře SQL Database dále nepodporuje integrované full-textové vyhledávání ani tvorbu uložených procedur a funkcí v C# (SQL CLR).
Rád bych upozornil, že SQL Database je ekvivalentem komponenty SQL Server Database Engine. Ostatní služby SQL Serveru – Analysis Services, Integration Services, Master Data Services, SQL Agent a další, nejsou aktuálně dostupné v jejich hostované variantě. Výjimkou jsou Reporting Services, které jsou nabízeny také jako Windows Azure služba SQL Reporting.
Migrace databáze do cloudu
Pokud používáte SQL Server Management Studio jako hlavní nástroj pro vývoj databází, potom vás určitě nepotěšila omezení představená v minulém dílu tohoto seriálu, která prakticky znemožňují hostovanou databázi vytvářet a upravovat s pomocí vizuálních nástrojů.
Jedna z cest, jak tato omezení obejít, je vyvíjet databázi na klasickém SQL Serveru za pomoci známých nástrojů a následně databázi přesunout z SQL serveru do cloudu.
Pokud tedy máte vytvořenou databázi, začneme s procesem migrace.
První způsob – Konverze databáze na SQL skript
S pomocí SQL Server Management Studia převedeme schéma databáze i data, pokud je třeba, do podoby SQL skriptu, který spustíme proti hostované SQL Database. Zde se následně vytvoří databázové objekty a vloží se data.
Zvolíme operaci Generate Scripts nad databází, kterou budeme chtít publikovat.
Následně si zvolíme, které objekty budeme chtít převést na SQL kód. Buď je možné převést celou databázi, nebo případně jen vybrané objekty.
V dalším kroku si vybíráme, kam chceme uložit vygenerovaný SQL kód. V našem případě jsme zvolili novou záložku v SQL Server Management Studiu, ale pokud budete exportovat rozsáhlou databázi včetně dat, potom doporučuji zvolit soubor na disku, protože Management Studio není příliš stabilní, pokud pracuje se skripty o velikosti několika stovek MB či GB.
Dále otevřeme dialog pokročilých nastavení přes tlačítko Advanced. Zde nejprve zvolíme, že skript se má generovat pro databázový engine SQL Azure Database. Pokud tuto možnost nezvolíte, skript bude bez problémů spustitelný na jiném SQL Serveru, kde vám vznikne kopie databáze, ale v prostředí SQL Database provádění skriptu skončí chybou (např.: Při vytváření tabulek se u SQL Database neuvádí File Group, kde má být tabulka uložena). Ve výchozí konfiguraci se generuje skript pouze pro schéma databáze. Pokud migrujete rozsáhlejší databázi, můžete nejprve nasadit její schéma a potom data, nebo nechat do jednoho skriptu vygenerovat vše.
Po nutných úpravách konfigurace exportu potvrdíme přehled nastavení a systém následně vygeneruje požadovaný SQL skript.
Připojíme se nyní na vytvořenou SQL Database z minulého dílu, vytvoříme prázdný dotaz nad tímto spojením a vložíme vygenerovaný skript. Po jeho provedení máme vytvořenou přesnou kopii databáze z našeho SQL Serveru v hostovaném prostředí.
Pozn.: Pokud je vygenerovaný skript příliš veliký a SQL Server Management Studio jej odmítá spustit, využijte utility sqlcmd a skript spusťte z příkazové řádky.
Druhý způsob – Deploy Database to SQL Azure
Databázi z SQL Serveru lze do Windows Azure publikovat i za pomoci nástroje, který z vaší databáze vytvoří balíček BACPAC, na základě kterého Windows Azure založí novou databázi, vytvoří v ní databázové objekty a nakopíruje data.
V základní podobě je tento nástroj dostupný v SQL Server Management Studiu, ale před jeho použitím doporučuji nainstalovat aktuální verzi nástroje SQL Server Data Tools (SSDT). Při instalaci dojde k aktualizaci Data-Tier Application Frameworku, který má na starost generování BACPAC balíčků (pozn.: Aktualizací SSDT se mi povedlo vyřešit neznámou chybu, která bránila publikaci databáze v rámci následující ukázky). Aktuální verzi nástroje SSDT naleznete na blogu jeho autorů nebo jej můžete nainstalovat přes Web Platform Installer.
Jakmile máte připravenou databázi na SQL Serveru, která splňuje omezení SQL Database, a chcete ji publikovat, připojte se na tento server přes SQL Server Management Studio a nad databází zvolte operaci Deploy Database to SQL Azure.
V kroku nastavení parametrů publikace se nejprve připojíte k databázovému serveru ve Windows Azure účtem správce, který má právo zakládat databáze. Dále nakonfigurujete, jakou edici databáze a s jakým velikostním omezením chcete založit. Pokud již databáze tohoto jména na serveru existuje, průvodce vás na to upozorní a nebude možné pokračovat dále.
Jako další krok následuje přehled konfigurace nasazení a pak samotné nasazení databáze do služby SQL Database. Pokud vše dobře dopadne, výsledkem jen kopie lokální databáze běžící v cloudu.
Pozn.: Data-Tier Application Framework pracuje se 2 formáty souborů – DACPAC a BACPAC. Tyto formáty jsou po technické stránce totožné, ale liší se v účelu použití. DACPAC slouží k definici schématu databáze, jejímu nasazení nebo aktualizaci schématu na novou verzi. BACPAC obsahuje kromě schématu databáze také data za účelem zálohy databáze.
Migrace databáze z cloudu na vlastní server
Doposud jsme si ukazovali, jak migrovat databázi do cloudu, ale mohou nastat i situace, kdy budete chtít produkční databázi z cloudu přesunout na vlastní SQL Server, proto si ukážeme i tento směr migrace.
Když se přihlásíte do Windows Azure portálu a zobrazíte si buď seznam databází, nebo detail databáze, můžete si všimnout, že jedna z dostupných operací ve spodním panelu je Export.
Export databáze probíhá tak, že zvolíte Blob Storage Account včetně kontejneru, kam je uložena kopie exportované databáze ve formátu BACPAC. Následně už jen stačí vytvořený .bacpac soubor stáhnout z Azure Storage a naimportovat jej jako novou databázi do vašeho SQL Serveru přes SQL Server Management Studio.
Pozn.: Při zálohování databáze je kvůli zachování konzistence vytvořena dočasná kopie databáze a ta je teprve exportována do .bacpac souboru. Po dokončení exportu je dočasná databáze automaticky odstraněna, ale protože se databáze účtují po dnech, je vám dočasná databáze v den exportu naúčtována.
Pro stažení vyexportované databáze lze využít Azure portál, který umožňuje procházet obsah Azure Storage a stahovat soubory z Blob Storage.
Po přihlášení k SQL Serveru zvolíme v SQL Server Management Studiu možnost Import Data-tier Application.
Průvodce umožňuje načíst BACPAC soubor buď z disku, kam jsme jej stáhli přes management portál nebo přímo z Azure Storage. Pokud zvolíte druhou možnost, budete potřebovat přístupový klíč ke zvolenému storage účtu, který naleznete na Azure portálu ve vlastnostech storage účtu.
V dalším kroku jsme doplnili název, pod kterým bude databáze importována do SQL Serveru.
Po obrazovce se shrnutím vstupních parametrů následuje samotný import databáze, a pokud vše proběhne v pořádku, máte na lokálním serveru kopii vaší SQL Database.
Automatické zálohy databáze
SQL Database je díky replikaci dat na 3 servery poměrně odolná proti ztrátě dat z důvodu selhání databázového serveru, ale mechanizmus replikace neochrání vaše data před poškozením vlastním zaviněním – třeba chybou v aplikaci. Pro zálohu databáze můžete využít manuálně spouštěný export databáze do Azure Storage. Hlavní problém je ale v tom, že je to manuální proces a zrovna u zálohování platí Murphyho zákony velice důsledně – zrovna ve chvíli, kdy zapomenete za zálohovat, zálohu budete potřebovat.
Tento proces lze nyní automatizovat díky nově představené službě automatických exportů.
Vysoká dostupnost
Výhodou hostované databáze je garance její dostupnosti zakotvená v SLA, která v případě SQL Database činí 99,95%. Můžete si zkusit spočítat, jaké náklady byste měli na provoz vysoce dostupné databáze ve vlastním prostředí. Pokud byste se rozhodli využít v SQL Serveru technologii AlwaysOn, potřebujete nejvyšší edici – Enterprise, případně můžete využít Database mirroring v synchronním režimu, ale stále potřebujete 2 servery a jeden, co bude působit jako svědek a přesměrovávat spojení, která k databázi přicházejí. Zkuste se podívat, který český hosting vám tyto služby nabídne a za kolik.
Vysoké dostupnosti služby SQL Database je dosaženo synchronní replikací vašich databází mezi 3 databázovými servery. Jedna z databází je označena jako primární replika, na tu jsou přesměrovávány všechny příchozí požadavky od klientů. Pokud dojde k provedení transakce, jsou potřebné informace o této transakci distribuovány na zbylé sekundární repliky, a primární replika potvrdí dokončení transakce klientovi, až má jistotu, že je tato transakce provedena i na sekundárních replikách. Tento mechanizmus zajišťuje, že i v případě nečekaného výpadku primární repliky nedojde k žádné ztrátě dat a stačí pouze jednu ze sekundárních replik povýšit na repliku primární a přesměrovat na ni zátěž. Mezi tím infrastruktura datacentra najde nový fyzický server, kde vytvoří novou sekundární repliku.
V případě vysoké dostupnosti se o nic nestaráte, nic nenastavujete, toto je výchozí chování.
Z pohledu vývojáře je třeba si dát pozor na to, že v případě havárie repliky je aktuální spojení ukončeno a dojde k vyvolání výjimky, což je vhodné ošetřit vhodnou retry policy, která zajistí opakování nedokončené operace. Při implementaci této politiky pamatujte i na interval mezi jednotlivými pokusy o znovu provedení operace, protože příliš mnoho neúspěšných pokusů o připojení může vést k následnému automatickému odmítnutí všech spojení.
Škálovatelnost
Protože veškeré požadavky od klientů zpracovává vždy jen jedna z replik a nelze automaticky zátěž rozložit na víc serverů, jsou možnosti škálovatelnosti této relační databáze omezeny.
Přesto, že SQL Database je schopná obsloužit začnou zátěž, je výhodné už v návrhu architektury aplikace počítat s omezením celkové zátěže na databázi pomocí cacheování nebo část zátěže přesměrovat na Windows Azure Storage, o jehož možnostech si povíme v následujících dílech tohoto seriálu.
Pokud nedostačuje výkon jedné databáze, lze databázi rozdělit buď na více izolovaných databází, nebo lze využít SQL Database Federation, což je přístup, kdy se databáze sice tváří jednotně, ale na pozadí jsou data rozdělena do více databází podle předem určeného distribučního klíče. Tento přístup však není zcela transparentní, neboť je nutné do dotazů uvádět, se kterou partition se bude pracovat.
Nedávno představenou novinkou, zatím v testovacím provozu, je SQL Database Premium. Tato edice se snaží řešit jeden z hlavních problémů služby SQL Database, kterým je nepředvídatelný výkon. V současnosti jsou na fyzických databázových serverech umístěny databáze různých zákazníků a infrastruktura datacentra monitoruje vytížení jednotlivých serverů. Pokud je některý server dlouhodobě přetížen, systém přerozdělí zátěž změnou primární repliky nebo migrací databáze na jiný server. U SQL Database Premium je vaší databázi poskytnut garantovaný výpočetní výkon, což ocení zejména majitelé velmi zatížených databází, kde je navíc i požadavek na garantovanou dobu odezvy. U edice Premium současně padá omezení na maximální počet současně zpracovávaných požadavků (ostatní edice jsou omezeny na 180 současných požadavků).
V následujícím dílu tohoto seriálu se zaměříme na datové úložiště Azure Storage.