Met de komst van het Microsoft data-tier application (DAC) framework versie 2.0 wordt het mogelijk om back-ups van een SQL Azure database te maken vergelijkbaar met die in een on-premises omgeving. Het wordt eindelijk mogelijk om “snapshots” van een database te maken en die als bestand te downloaden of direct in blob storage op te slaan. Dit artikel gaat in op de nieuwe functionaliteit die geïntroduceerd is in de CTP van versie 2.0.
Introductie
De requirements omtrent het maken van back-ups van een database op het Windows Azure platform zijn anders dan die in een on-premises omgeving. In een on-premises omgeving moeten we immers rekening houden met systeemfouten, netwerkstoringen en andere hardware gerelateerde fouten. In Windows Azure wordt de grootste kans op dataverlies veroorzaakt door de gebruikers van een systeem. Dit kunnen beheerders, servicemedewerkers danwel eindgebruikers zijn. De kans op hardwarefouten in Windows Azure wordt aanzienlijk verkleind door de 2 replica’s die continu meedraaien. Als een database uitvalt neemt vrijwel direct een andere replica het werk over en wordt gelijktijdig de defecte replica gerepareerd, of wordt er een nieuwe in de lucht gebracht.
Een verschil in requirements houdt echter niet in dat er op een andere manier geback-uped moet worden. Velen hebben de wens uitgesproken om op een vergelijkbare wijze, zoals we die we gewend zijn in een on-premises omgeving, back-ups te maken. Want naast het terugzetten van een database na dataverlies zijn er natuurlijk ook andere redenen waarom het handig is om een back-up te hebben. Denk bijvoorbeeld aan een realistische dataset om bugs mee te op te sporen, testen mee uit te voeren of om statistische gegevens uit te bepalen. Tot voor kort bood SQL Azure hier echter geen oplossing voor. Er bestond geen mogelijkheid om een back-up te maken en vervolgens het .BAK-bestand te downloaden.
Een kort overzicht van de huidige back-upoplossingen:
· Automatische synchronisatie middels het Micrsoft Sync-framework
· Het maken van duplicaten in SQL Azure zelf (as copy of)
· Handmatige data synchronisatie met bestaande oplossingen (bijvoorbeeld Redgate-suite)
· Handmatige data synchronisatie met eigen oplossingen (bijvoorbeeld bulk-transfer)
Deze oplossingen categoriseren zich vooral door onhandig, langzaam of duur. Hier lijkt verandering in te komen door de tweede versie van het DAC-framework.
Microsoft DAC-framework
De functionaliteit omtrent data-tier applicaties (DACs) is geïntroduceerd met de komst van Microsoft SQL Server 2008 R2. Het framework is ontwikkeld om het data gedeelte van een applicatie eenvoudiger te beheren en te deployen. Middels de geïntegreerde functionaliteit in SQL server en Visual Studio is het mogelijk een groot deel van het deploymentproces te automatiseren [1].
Een DAC-pakket is een container die zowel metadata (schema’s, stored procedures, etc.) van een SQL-database bevat als daadwerkelijke data. Als we de inhoud van een DAC-pakket inspecteren zullen we dan ook veel SQL-code tegenkomen. Sinds kort heeft Microsoft een tweede versie ter preview uitgebracht. In deze nieuwe versie wordt ondersteuning gegeven voor SQL Azure en is het eenvoudiger gemaakt om van een bestaande database een DAC-pakket te maken en vice versa.
Belangrijk om op te merken is dat een DAC-pakket, welke voortkomt uit een SQL Azure database, te herstellen zal zijn in een SQL Server 2008 R2 omgeving. Andersom is geen garantie, gezien SQL Azure niet alle functionaliteit aanbiedt die SQL Server 2008 R2 bezit.
We zullen in de rest van het artikel nader ingaan hoe we het DAC-framework kunnen inzetten om een back-upservice op te zetten.
Voorbeeldontwerp
In een typische implementatie willen we een tweetal zaken bereiken: allereerst het maken en herstellen van back-ups en ten tweede het kunnen downloaden van de back-upbestanden. Daarbij is het wenselijk om Windows Azure blob storage als primair opslagmechanisme te gebruiken, gezien de opslagkosten laag zijn en het interne dataverkeer tegenwoordig kosteloos is. Enkel voor de uitzonderlijke situaties willen we een DAC-bestand kunnen downloaden. Dit laatste is geen lastige opgave en laten we in dit artikel buiten beschouwing.
Een grafische weergave van onze oplossing ziet er als volgt uit:
Figuur 1: voorbeeldontwerp
De worker role is verantwoordelijk voor het tot stand brengen van het back-up- of herstelproces. Alle data tussen SQL Azure en blob storage zal tevens via deze rol lopen. Hierdoor hebben we één centraal controle- en beheerpunt . We brengen zaken zoals scheduling, logging en procesmonitoring dan ook hier onder. Daarnaast biedt deze oplossing de optie om dezelfde code-base te gebruiken voor een commandline-programma om back-upbestanden uit de storage te halen en op een lokale SQL Server instantie te herstellen.
Implementatie
Alvorens we starten met de implementatie moeten we de benodigde softwarebibliotheken van het DAC-framework downloaden en installeren. Deze zijn verkrijgbaar via de website van SQL Azure labs [2].
We importen vervolgens de volgende drie softwarebibliotheken in ons Visual Studio Worker role project:
· Microsoft.SqlServer.ConnectionInfo – versie 11.0.0.0
· Microsoft.SqlServer.Management.Dac – versie 11.0.0.0
· Microsoft.SqlServer.Management.Sdk.Sfc – versie 11.0.0.0
Het maken van een back-up (export-functie) en herstellen (import-functie) wordt met behulp van de geïmporteerde softwarebibliotheken kinderlijk eenvoudig:
private void Backup(string databaseConnectionString, string databaseName,
Stream backupDataDestination)
{
using (var sqlConnection = new SqlConnection(databaseConnectionString))
{
var sqlServerConnection = new ServerConnection(sqlConnection);
var dacStore = new DacStore(sqlServerConnection);
dacStore.Export(databaseName, backupDataDestination);
}
}
private void Restore(Stream backupDataSource,
string databaseConnectionString, string databaseName)
{
using (var sqlConnection = new SqlConnection(databaseConnectionString))
{
var sqlServerConnection = new ServerConnection(sqlConnection);
var dacStore = new DacStore(sqlServerConnection);
var deploymentProperties = new DatabaseDeploymentProperties(
sqlServerConnection,
databaseName);
dacStore.Import(backupDataSource, deploymentProperties, false);
}
}
Listing 1: implementatie van back-up en herstel methods
Opmerking: de connectionstring in bovenstaande voorbeelden verwijst naar de MASTER-database.
Uitdagingen en beperkingen
Helaas zijn er een aantal uitdagingen en beperkingen om een correcte en volwaardige service te implementeren. Allereest moeten we een kopie van de database maken om transactioneel consistent te zijn. Dit wordt (nog) niet gegarandeerd door het DAC-framework.
We zullen dus eerst een kopie moeten maken van de database (SQL):
create database [CopyOfProductionDatabase1] as copy of [ProductionDatabase1]
Listing 2: dupliceer database
Vervolgens wachten we totdat deze ‘online’ is:
select lower(state_desc) as state from sys.databases where name = 'BackupOfProduction01'
Listing 3: monitor status van het duplicatieproces
We kunnen op de website van het DAC-framework [2] lezen dat een DAC-pakket geen historische data of transactiedata bevat. Een DAC-pakket (.BACPAC-bestand) is dus niet 100% inhoudelijk equivalent aan een .BAK-bestand.
Het kan daarnaast voorkomen dat het back-uppen of herstellen van een database mislukt. Op de website van SQL Azure labs [2] staan een aantal veelvoorkomende situaties beschreven die (nog) niet ondersteund worden.
Eén van de benodigde softwarebibliotheken is gecompileerd voor een x86-architectuur (32bit). Dit lijkt in eerste instantie iets onschuldigs klein, pas als we de oplossing in een 64bit-omgeving gaan testen merken we dat dit simpelweg niet werkt. Gezien alle rollen binnen het Windows Azure-platform 64bit zijn veroorzaakt dit een struikelblok. Een oplossing is om het back-upproces als los proces te starten:
string backupProgamPath = Path.Combine(AssemblyDirectory, "backup.exe");
var backupProgramProcessInfo = new ProcessStartInfo(backupProgamPath)
{
CreateNoWindow = true,
UseShellExecute = false
};
Process.Start(backupProgramProcessInfo);
Listing 4: start extern back-upproces (zonder console-venster)
De communicatie tussen het workerrole-proces en het back-upproces kan bijvoorbeeld middels WCF named pipes lopen.
Als laatste heb ik zelf enige problemen ervaren om alle benodigde softwarebibliotheken in het Windows Azure deployment-pakket te krijgen. Uiteindelijk heb ik besloten om deze niet aan het deployment-pakket toe te voegen, maar elke keer automatisch te downloaden en te installeren wanneer de back-upservice start.
Conclusie
Het maken van back-ups zoals we gewend zijn in een on-premises omgeving is bijna werkelijkheid. We zullen eerst nog even de CTP moeten afwachten om productie-oplossingen te implementeren. De kleine struikelblokken worden hopelijk in de tussentijd nog opgelost, zoals 64bit-compatibiliteit voor alle softwarebibliotheken. Uiteindelijk zal het DAC-framework ons in staat stellen met enkele regels code back-upbestanden te maken van SQL Azure databases en deze op te slaan in blob storage.
Als laatste: er wordt verwacht dat er in de komende periode vergelijkbare functionaliteit als service zal worden aangeboden, geleverd door derden. Interessant voor wie niet een eigen oplossing wil implementeren op basis van het DAC-framework.
Referenties:
Microsoft SQL Azure labs / DAC-framework:
http://www.sqlazurelabs.com/ImportExport.aspx