sql >> Database teknologi >  >> RDS >> Database

Brydning af Azure-gabet:Administrerede forekomster

Hvis du har overvejet at flytte dit SQL Server-miljø til Azure, har du kun haft et par muligheder. Først kunne du bruge PaaS-løsningen fra Azure SQL Database og flytte en enkelt database eller bruge en elastisk pool. Din anden mulighed har været en IaaS-løsning, der bruger Azure Virtual-maskiner, der kører Microsoft SQL Server. Vi vil snart have en tredje mulighed kaldet en SQL Database Managed Instance.


Administrerede forekomster bygger bro mellem on-prem SQL Server og Azure SQL-database

Managed Instances blev først introduceret på Microsoft Build-konferencen i foråret 2017, og indtil videre har forhåndsvisningen været begrænset til et lille antal kunder og konsulenter. Administrerede forekomster kan betragtes som en hybrid mellem en fuld version af SQL Server og Azure SQL Database. Enkelte og elastiske databaser er bygget på en database-scoped programmeringsmodel, og Managed Instances er bygget på en instans-scoped programmeringsmodel. Dette gør Managed Instances mere kompatible med SQL Server på stedet.

Administrerede forekomster giver meget mere en følelse af en lokal SQL Server, men de er bygget på den samme infrastruktur som Azure SQL Database. Det, der adskiller den fra Azure SQL Database, er, at den præsenterer en hel SQL Server-instans for kunden. I Azure SQL Database konfigurerer du en server, som i virkeligheden er en container, og derefter kan have flere databaser på den server, men de kan ikke nemt tale med hinanden. Med Managed Instances er alle databaser i instansen på den samme faktiske SQL Server, så du har fuld understøttelse af cross-database-forespørgsler. Dette er en enorm funktion for mange applikationer, som ellers ikke passede godt til Azure SQL Database, og jeg tror, ​​det vil give mange flere SQL Server-applikationer mulighed for at flytte ind i skyen.

Funktionalitet på instansniveau er nu understøttet. Dette inkluderer ting som globale midlertidige tabeller, SQL Server Agent, Service Broker, replikering, SQL Audit og Common Language Runtime (CLR). Administrerede forekomster kan også understøtte databaser på op til 35 TB i størrelse. I øjeblikket er den største kapacitet for en Azure SQL-database 4 TB i det øverste niveau. Jeg formoder, at dette snart kan ændre sig, og igen vil det åbne skyen for flere applikationer.

Managed Instances får også mulighed for at drage fordel af alle funktionerne i PaaS-platformen, til at inkludere automatiske sikkerhedskopier, trusselsdetektion, sårbarhedsvurderinger, høj tilgængelighed, geo-replikering, databaserådgiver og meget mere. Jeg har set en præsentation, der diskuterede, hvordan den automatiske failover-proces fungerer, og lærte, at objekter på serverniveau replikeres til failover-instansen. Det betyder, at ting som logins og job – smertepunkter for mange af vores miljøer i dag – håndteres for dig.

I løbet af det seneste år har jeg hjulpet adskillige kunder med at migrere til Azure SQL Database, og en af ​​de primære udfordringer er at migrere dataene. Du kan ikke bare udføre en SQL Server-sikkerhedskopi og gendanne til Azure SQL Database. Jeg var meget glad for at høre, at vi med SQL Database Managed Instances kan bruge native SQL Server backups og gendanne til Managed Instances, dog skal du bruge backup to URL mekanismen. Dette vil gøre migreringer til Managed Instances meget nemmere, men da Managed Instances er bygget på Azure SQL Database, er dette en envejsbillet:Du kan ikke sikkerhedskopiere dine Managed Instance-databaser og gendanne tilbage til det lokale. Hvis du nogensinde har besluttet dig for at bringe din database tilbage til stedet eller ud af administrerede forekomster, bliver du nødt til at eksportere dine data.


Databaser på administrerede forekomster er meget mere klar til at migrere til Azure SQL Database

På den anden side, da de er bygget på Azure SQL Database-platformen, kan de individuelle databaser, du lægger i en Managed Instance, migreres til deres egne individuelle Azure SQL-databaser. Dette gør en Managed Instance til et perfekt springbræt, hvor du kan finde ud af de isolationskomplikationer, der forhindrer dig i at migrere direkte til PaaS.

Jeg er nysgerrig efter, om replikering bliver understøttet. Jeg har endnu ikke været i stand til at finde ud af, om en Managed Instance-database kan være en udgiver, eller om den kun kan være en abonnent, som en Azure SQL-database. Hvis det kan være en udgiver, så kunne det være en effektiv måde at migrere tilbage til det lokale. Jeg håber virkelig, at vi i den nærmeste fremtid vil have mulighed for også at gendanne native SQL Server-sikkerhedskopier til singleton Azure SQL-databaser. Det ser ud til, at teknologien er der, den skal blot udvides til det eksisterende PaaS-miljø.

En anden interessant observation om Managed Instances er, at da teknologien er bygget på Azure SQL Database-modellen, vil SQL Server-versionen følge Azure SQL Database. Dette kan komplicere tingene med leverandørsupport. Mange leverandører vil oplyse, at de certificerer deres produkt på SQL Server version X. Selvom Managed Instances vil understøtte næsten alle funktionerne i SQL Server 2017, vil den ikke bruge den samme build-version, så programmæssig versionskontrol vil være kompliceret. Din bedste fremgangsmåde her er at skubbe leverandøren tilbage, da Microsoft sandsynligvis ikke vil vakle over denne holdning, og jeg er ikke i tvivl om, at nogle af disse samtaler vil være udfordrende.

Vil leverandører gå igennem bestræbelserne på at certificere deres produkter på Managed Instances, eller vil dette blive et problem, som vi oplevede med virtualisering? I de tidlige dage af virtualisering erklærede mange leverandører, at de ikke understøttede deres produkter, der kører virtualiseret, men Microsoft understøttede fuldt ud, at Windows X og SQL Server X blev virtualiseret. Forhåbentlig vil vi se leverandører komme ombord og certificere deres produkter på Managed Instances. Jeg ser bestemt nogle SQL Server-pionerer derude, som vil flytte til Managed Instances efter deres egen testning.

Hver gang en kunde ønsker at migrere til skyen, er sikkerhed et stort problem. Administrerede forekomster tilbyder VNET-understøttelse med private IP-adresser og VPN til lokale netværk. Dette kan give en klient mulighed for at beskytte deres miljø mod det offentlige internet og have fuld isolation.

Jeg er begejstret for Managed Instances og kan virkelig ikke vente, indtil det er mere bredt tilgængeligt. For klienter, der gerne vil have et administreret miljø, men har brug for en mere funktionsrig løsning end en singleton eller elastisk Azure SQL-database, føler jeg, at Managed Instances ville passe perfekt. Der har været et hul mellem Azure SQL Database og SQL Server på en Azure VM, da mange kunder har brug for mere end Azure SQL Database tilbyder, men SQL Server på en Azure VM er stadig mere vedligeholdelse og ansvar, end de ønskede. Administrerede forekomster slår virkelig bro over dette hul. De understøtter meget større databaser, giver mulighed for lettere datamigreringer, giver mulighed for forespørgsler på tværs af databaser og burde ikke kræve nogen kodeændringer, da platformen er så yderst kompatibel med SQL Server på stedet.

Sammenfattende, hvis din organisation overvejer at flytte til et hostet miljø inden for Azure SQL Database-platformen, vil du være i stand til at vælge mellem individuelle Azure SQL-databaser, elastiske puljer eller Managed Instances. Afhængigt af dine applikationsbehov bør en af ​​disse løsninger passe godt. Ellers har du også mulighed for at køre en traditionel SQL Server-instans på en virtuel Azure-maskine, som tilbyder gode funktioner som administrerede sikkerhedskopier, geo-replikering, Azure Site Recovery og meget mere. Microsoft fortsætter med at investere i Azure-platformen ved at levere nye produkter og funktioner, som deres kunder har brug for, og den kommende udgivelse af Managed Instances er et fortsat bevis på dette fokus. Hold dig opdateret, da vi er blevet lovet en offentlig forhåndsvisning i den nærmeste fremtid.


  1. Sådan ekskluderer du poster med bestemte værdier i sql select

  2. ORA-38868

  3. Hvordan konverterer man en streng til hex og omvendt?

  4. Hvordan CHARSET() virker i MariaDB