Scenario 1-lösning – Utforma global skalning och säker åtkomst
I föregående lektion arbetade vi med ett scenario med global skalning i ett nätverk för innehållsleverans. I den här lektionen granskar du en potentiell lösning och några element att överväga.
Under granskningen bör du jämföra den lösning som tillhandahålls med den som du utvecklade i föregående lektion. Det finns vanligtvis mer än en korrekt lösning på problemen och det krävs nästan alltid kompromisser. Vilka element i din lösning skiljer sig från det föreslagna? Finns det något i din lösning som du kan tänka annorlunda kring? Finns det något i den tillhandahållna lösningen som du tycker är mer noggrant utformat i din lösning?
Distributionsalternativ och konfiguration
Det första du bör fundera på är vilket distributionsalternativ för Azure SQL som ska väljas. Även om SQL Server i en virtuell Azure-dator kan fungera, kan en plattform som en tjänst (PaaS) vara ett bättre alternativ med lägre hanteringskostnader.
Kunden använder CLR (Common Language Runtime), som är en funktion med en instans. Azure SQL Managed Instance är det enda PaaS-distributionsalternativ som har stöd för funktioner som är begränsade till instanser som CLR, Service Broker och Database Mail. Därför ger Azure SQL Managed Instance kunden möjlighet att gå över till ett PaaS-erbjudande utan att behöva skriva om CLR-programmen till en lösning som är kompatibel med Azure SQL Database (t.ex. elastiska databasjobb).
Nästa beslut handlar om tjänstnivån. Eftersom kunden vill isolera sina läs- och skrivarbetsbelastningar, är det enklast att använda den affärskritiska tjänstnivån för att uppnå det. Den affärskritiska servicenivån har en AlwaysOn-tillgänglighetsgrupp som körs i bakgrunden. En av dessa sekundära repliker kan användas för skrivskyddade arbetsbelastningar.
Den affärskritiska nivån är bara den ena hälften av konfigurationen när läs- och skrivarbetsbelastningar ska separeras. Scenariot visar att kunden måste kunna skala över flera regioner med flera frågor åt gången, samtidigt som läs- och skrivarbetsbelastningar isoleras.
De två alternativ som skulle kunna klara den här utmaningen är geo-replikering och automatiska redundansgrupper. Det finns dock för närvarande inte stöd för geo-replikering i Azure SQL Managed Instance. Att använda en grupp för automatisk redundans är därför det enda alternativet som kan göra så att det här scenariot kan skalas för global läsning.
Eftersom kunden använder automatiska redundansgrupper, är den affärskritiska tjänstnivån beroende av hur många skrivskyddade slutpunkter analysarbetsbelastningen kräver. Med en automatisk redundansgrupp i den affärskritiska tjänstnivån får kunden tre läsbara slutpunkter:
- En sekundär replik från den primära regionens tillgänglighetsgrupp
- Sekundärservern för redundansgruppen (som är den primära repliken av databasen i den sekundära regionen)
- Den sekundära repliken från den sekundära regionens tillgänglighetsgrupp
Om analysarbetsbelastningen inte behöver alla dessa läsbara repliker, kan generell användning vara en mer kostnadseffektiv lösning.
Välja de lämpligaste autentiseringsmetoderna
Den andra delen av scenariot är att avgöra hur varje program eller person ska anslutas till lösningen på bästa sätt, med tanke på behovet av att skapa och använda de säkraste teknikerna. Om du delar upp scenariot finns det fyra separata klienter som behöver ha åtkomst till Azure SQL Managed Instance:
- Program som körs på en virtuell Azure-dator
- Ett program som körs på en dator som inte är en Azure-dator som är domänansluten
- DBA:er eller andra användare av SQL-administrationsverktyg (SQL Server Management Studio, Azure Data Studio, PowerShell) på datorer som inte är Azure-datorer som inte är domänanslutna
- Äldre program som körs på en dator som inte är en Azure-dator, där du inte kan ändra drivrutins- eller anslutningssträngen
Låt oss titta på dessa klienter och se hur du kan välja autentiseringsmetod, samt några ytterligare överväganden och begränsningar.
Program som körs på en virtuell Azure-dator
Hanterade identiteter för Azure-resurser är i allmänhet den rekommenderade typen av lösenordsfri autentisering för program som körs på virtuella Azure-datorer.
Ett program som körs på en dator som inte är en Azure-dator som är domänansluten
För datorer som inte är Azure-datorer är hanterade identiteter inte ett alternativ. Integrerad autentisering via Microsoft Entra-ID är den rekommenderade autentiseringsmetoden för appar som körs på domänanslutna datorer utanför Azure, förutsatt att domänen har federerats med Microsoft Entra-ID.
Om datorn som inte är en Azure-dator inte är domänansluten, kan du:
- Skapa en programidentitet för ditt program i Microsoft Entra-ID.
- Associera ett certifikat med programidentiteten.
- Ändra ditt program och hämta en token för Azure SQL Database, genom att ange ett klient-ID och ett certifikat.
Även om certifikatet måste innehålla en privat nyckel och distribueras på den dator som är värd för ditt program, undviker du åtminstone hårdkodning av en programhemlighet i programkoden eller konfigurationen. (Du måste konfigurera appen med tumavtrycket för certifikatet.)
DBA:er eller andra användare av SQL-administrationsverktyg från en dator som inte är en Azure-dator som inte är domänansluten
För användare utanför Azure rekommenderar vi att användningen av lösenord elimineras så långt det är möjligt. Du kan eliminera användningslösenord med SQL-verktyg med hjälp av Microsoft Entra-integrerad autentisering. Verktygen måste dock köras på en domänansluten dator och domänen måste ha federerats med Microsoft Entra-ID, vilket inte är fallet för det här scenariot.
Eftersom miljön inte uppfyller kraven för integrerad autentisering rekommenderar vi att du använder interaktiv Microsoft Entra-autentisering med multifaktorautentisering, vilket de flesta SQL-verktyg stöder.
Äldre program som körs på en dator som inte är en Azure-dator, där du inte kan ändra drivrutins- eller anslutningssträngen
I scenarier där drivrutins- eller anslutningssträngen inte kan ändras, finns det i dag inget alternativ för att eliminera lösenord. Dessa äldre program måste fortsätta att använda SQL-autentisering. Du kan fördjupa dig i begränsningarna och se hur du kan få en säkrare autentiseringsmetod för programmen, om du vill.