NLEN
Direct technisch advies?
Home > Blog

Azure SQL-database. Lekker simpel en snel... of toch niet?

Mark van der Haar 16-2-2023 10:32
Catégories: BLOG, Cloud, Review

We hebben weleens een demo bijgewoond waar een clouddatabase werd neergezet. Vijf minuten en hij stond er. Daar zakt je mond van open. Toch? Of geeft dit een iets té simplistisch beeld van wat er allemaal komt kijken bij het – goed en veilig – neerzetten van een clouddatabase? In deze blog deelt Mark van der Haar een aantal aandachtspunten die je niet uit het oog mag verliezen bij een Azure SQL-deployment.

1. Database

Het begint al bij de keuze. Ga je voor een Azure SQL-database, een Managed Instance of SQL Server op Azure VM? Als je kiest voor een SQL Server op een VM is de migratie relatief eenvoudig, maar dan heb je niet de voordelen van de cloud. Een Azure SQL-database biedt die voordelen wel. Zo profiteer je van automatische patching en ben je minder geld kwijt aan je dataservices. Maar een applicatie kan niet zonder meer overweg met een Azure SQL-database ter vervanging van een on-premises SQL-database. Dat vraagt om de nodige – grondige – aanpassingen. Misschien wil je je applicatie ook niet zomaar overzetten naar een Azure VM en wil je hier ook meer cloudmogelijkheden gebruiken. Daarmee haal je je een fors migratietraject op de hals. Azure SQL-databases kennen een aantal beperkingen. Denk aan het gemis van een SQL-agent, CLR of de mogelijkheid om een copy-only back-up te maken. De Managed Instance van Microsoft is een tussenvorm, die het beste van de twee werelden combineert, maar die oplossing is vrij kostbaar.

2. Tier

Goed. De keuze is gemaakt, je gaat voor de Azure SQL-database. Maar dan. In een demo-omgeving kies je ‘even snel’ een service-tier, meestal de provisioned single database. In het echte leven is die keuze iets complexer. Natuurlijk kun je achteraf veel dingen aanpassen, maar afstappen van hyperscale – de tier voor hele zware databases – dát kan bijvoorbeeld niet. Je moet dus echt wel serieus weten waar je voor kiest. Zo kleven er bijvoorbeeld ook nadelen aan een serverless tier. Serverless heeft een auto-pause functionaliteit, wat in de kosten kan schelen, maar serverless kan alleen met het vCore purchasingmodel en niet met het DTU purchasingmodel. Bovendien kan serverless voor kleinere databases toch een duurdere oplossing zijn. Kortom, veel keuzes die van invloed zijn op de kosten en daar is niet 123 een eenvoudig advies over te geven. 

3. Netwerk

Een database moet natuurlijk bereikbaar zijn op een veilige manier. Bouw je de applicatie in Microsoft Azure, dan kan je in je Azure SQL-database de optie ‘Allow access to Azure services’ aanzetten. Dat betekent echter dat alle Azure-services bij jouw database kunnen, ook Azure-services van andere bedrijven. Om dat te voorkomen moet je je database beschermen met een firewall. Het bijhouden van alle wijzigingen van IP-adressen, vraagt om stevig onderhoud van die firewall. Dat verhoogt de foutkans. Dat voorkom je door te werken met virtual networks (VNET) en network security groups (NSG). Dan staan de applicatieservices in een apart VNET en kan je met VNET-peering het VNET van de databases beschikbaar maken. Connectie vanuit on-premises-omgevingen regel je via een NSG. Tot slot moet je de connectie maken met een eindpunt. Om dat veilig te doen, moet je een express-route of VPN-tunnel gebruiken.

4. Toegang

Ook identity-access-management werkt bij een Azure SQL-database nét iets anders dan anders. De manier om een login te creëren vanuit Azure Active Directory heeft een wat andere syntax. Bij Azure SQL-databases wordt veel meer gebruik gemaakt van contained users, ofwel users zonder login. Zo verhoog je de portabiliteit van een database. Dit vraagt om een wat andere benadering van de authenticatie. Bij Azure is het wel weer gemakkelijker om MFA te gebruiken.

5. Beperkingen

Bij een Azure SQL-database kan je geen gebruik maken van ‘USE database’. Omdat je een tabel niet kan benaderen met een four-part name, kan je ook geen join maken tussen verschillende databases. Dat maakt het voor ontwikkelaars anders om een connectie te maken met een Azure SQL-database dan met SQL Server op Azure VM. Je kunt met een query maar data uit één database tegelijk halen en de join van die data gebeurt op de client. Of je moet gebruikmaken van de elastic query feature, die wel mogelijkheden biedt om te joinen. Dit is wel een feature die opgezet moet worden en het vraagt om aanpassingen aan de applicatiekant.

6. Auditing

Ook voor auditing moet je iets regelen. Bij Azure SQL-database zijn er meerdere mogelijkheden om de auditgegevens op te slaan. Naast de ‘normale’ storage kan je in Azure ook kiezen voor de destinations: log-analytics of event-hub. Waar je bij on-premises-oplossingen van third-party-software gebruik moest maken om automatisch de uitvoer te doorzoeken op issues (b.v. ArcSight), kan je nu door de audit te sturen naar log-analytics ook al automatisch logs doorzoeken. Een veel voorkomend probleem bij audit-logs is de grote hoeveelheid gegevens die je verzamelt. In combinatie met Azure Defender for SQL – voorheen Advanced Data Security, dus de afkorting blijft ADS – kun je met behulp van classificatie de output beperken. Dit classificeren van velden binnen de database geeft de mogelijkheid om alleen te auditen bij gevoelige data. Dit classificeren is tegenwoordig ook mogelijk bij on-premises databases, maar dat wordt nog niet veel gebruikt.

7. Monitoring

Monitoring van SQL Server is on-premises onderdeel van een algemene monitoringtool, zoals SCOM of HPOM, of er wordt een SQL-specifieke monitoringtool gebruikt, zoals Redgate, SQL Sentry of Idera. Deze laatstgenoemde tools kunnen ook een Azure SQL-database monitoren. Maar voor een Azure SQL-database kun je ook gebruikmaken van een specifiek Azure-tool, Azure Monitor SQL Insights. Die kun je op zijn beurt weer integreren in Azure-dashboards. Bedenk wel dat een nieuwe monitoringtool vaak om veel finetuning vraagt. Zo'n tool genereert initieel veel false positives. De weg naar een situatie waarin je alleen meldingen krijgt die er echt toe doen, is vaak lang. 

8. Migratie

De manieren om je data te migreren naar Azure zijn divers. Denk aan Data Migration Assistant (DMA), SQL Server Migration Assitant (SSMA), Azure Data Migration Service (DMS), Replicatie, BACPAC, Bulk Copy Program (BCP), SQL Data Sync en Azure Data Factory (ADF). Dit is nog niet eens een uitputtende lijst. Bepaalde opties kunnen wel overweg met andere DBMS'sen zoals Oracle, andere niet. Ze zijn allemaal verschillend voor wat betreft downtime en alleen SQL Data Sync geeft de mogelijkheid om de databases naast elkaar te blijven bewerken. De opties zijn ook verschillend qua prijs. DMA kan als enige gebruikt worden voor een pre-assessment. Zo zijn er nog veel meer verschillen. De vergelijking levert genoeg stof op om nog een vervolgblog over te schrijven.

Meer weten?

Zo’n demo van vijf minuten geeft dus echt een iets té simplistisch beeld van het opzetten van een Azure SQL-database, met alle keuzes en instellingen waar je over na moet denken. Zeker als je een on-premises SQL Server-database overzet naar een Azure SQL-database komt daar heel wat bij kijken. De experts van OptimaData kunnen hierbij helpen. Neem gerust contact met ons op.

Andere interessante blogs:

Database-as-a-Service onder de loep genomen

Geboren en getogen in de cloud

Databases in de cloud, zonder nadelen

Voor en nadelen van Database-as-a-Service

Terug naar blogoverzicht
 

Répondre