Az 1. forgatókönyv megoldása – globális méretezés és biztonságos hozzáférés kialakítása
Az előző leckében egy olyan forgatókönyvvel dolgozott, amely egy tartalomkézbesítési hálózat globális méretezésével foglalkozott. Ebben a leckében át fogunk tekinteni egy lehetséges megoldást és néhány megfontolandó tényezőt.
Az áttekintés során hasonlítsa össze az itt megadott megoldást azzal, amelyet Ön dolgozott ki az előző leckében. Gyakran több megfelelő megoldás is létezik egy problémára, de mindegyik kompromisszumokkal jár. Az Ön megoldásának mely elemei különböznek a javasolttól? Van valami a megoldásában, amit szeretne újragondolni? Van valami az itt megadott megoldásban, amellyel az Ön megoldása alaposabban foglalkozik?
Üzembehelyezési lehetőség és konfigurálás
Az első döntés, amelyet meg kell hoznia, az Azure SQL üzembe helyezési megoldásának kiválasztása. Bár az SQL Server működhet egy Azure-beli virtuális gépen (virtual machine, VM), egy szolgáltatásként nyújtott platform (platform as a service, PaaS) megfelelőbb megoldás lehet, mert kevesebb felügyeleti tevékenységet követel meg.
Az ügyfél közös nyelvi futtatókörnyezetet (CLR) használ, amely egy példányra irányuló funkció. Ne feledje, hogy az Azure SQL Managed Instance az egyetlen olyan PaaS-telepítési lehetőség, amely támogatja a példányra irányuló funkciókat, például a CLR-t, a Service Brokert vagy a Database Mailt. Az Azure SQL Managed Instance lehetővé teszi, hogy az ügyfél anélkül váltson PaaS-ajánlatra, hogy átírná a CLR-alkalmazásait egy Azure SQL Database-szel kompatibilis megoldássá (például rugalmas feladatokká).
A következő döntés a szolgáltatási szintre vonatkozik. Mivel az ügyfél el szeretné különíteni az olvasási és írási számítási feladatokat, erre az üzletileg kritikus szolgáltatási szint a legegyszerűbb megoldás. Az üzletileg kritikus szolgáltatási szinten elérhető az AlwaysOn rendelkezésre állási csoport a háttérben. Az egyik másodlagos replika felhasználható a csak olvasható számítási feladatokhoz.
Az olvasási és írási számítási feladatok elkülönítéséhez az üzletileg kritikus szint a konfigurációnak csak egy egyik fele. A forgatókönyvben az ügyfélnek az olvasási és írási feladatok elkülönítése mellett több, egyszerre több lekérdezést futtató régió méretezésére is szüksége van.
Erre megoldás lehet a georeplikáció és az automatikus feladatátvételi csoportok. A georeplikáció azonban a felügyelt Azure SQL-példányban jelenleg nem érhető el. Ezért az automatikus feladatátvételi csoport használata az egyetlen olyan lehetőség, amely segíthet ebben a forgatókönyvben a globális olvasásra méretezés kialakításában.
Mivel az ügyfél automatikus feladatátvételi csoportokat használ, attól függ, hogy szükség van-e az üzletileg kritikus szolgáltatási szintre, hogy hány írásvédett végpontot igényelnek az elemzési számítási feladatai. Egy automatikus feladatátvételi csoport használatával az üzletileg kritikus szolgáltatási szinten az ügyfél három olvasható végponthoz fér hozzá:
- Egy másodlagos replika az elsődleges régió rendelkezésre állási csoportjából
- A feladatátviteli csoport másodlagos replikája (amely a másodlagos régió adatbázisának elsődleges replikája)
- A másodlagos régió rendelkezésre állási csoportjának másodlagos replikája
Ha az elemzési számítási feladatnak nincs szüksége ezekre az olvasható replikára, az általános célú szolgáltatási szint használata költséghatékonyabb lehet.
A megfelelő hitelesítési módszerek kiválasztása
A forgatókönyv másik eleme azzal foglalkozott, hogyan lehet a legjobban hozzákapcsolni az egyes alkalmazásokat vagy személyeket a megoldáshoz, tekintettel a lehető legbiztonságosabb technológiák létrehozásának és kihasználásának az igényére. Ha lebontja a forgatókönyvet, négy különböző ügyfélnek van szüksége hozzáférésre az Azure SQL Managed Instance-hez:
- Azure-beli virtuális gépen futó alkalmazás
- Azure-on kívüli, tartományhoz csatlakoztatott gépen futó alkalmazás
- Adatbázisgazdák vagy egyéb felhasználók, akik jelentéseket futtatnak SQL rendszergazdai eszközökről (SQL Server Management Studio, Azure Data Studio, PowerShell) nem Azure-beli gépeken, amelyek nincsenek tartományhoz csatlakoztatva
- Nem Azure-beli gépen futó régebbi alkalmazások, amelyeken nem módosítható az illesztőprogram vagy a kapcsolati sztring
Nézzük meg ezeket az ügyfeleket részletesen, hogy megállapíthassuk, hogyan választhatja ki a hitelesítési módszert, és hogyan vehet figyelembe néhány további szempontot és korlátozást.
Azure-beli virtuális gépen futó alkalmazás
Az Azure-beli virtuális gépeken futó alkalmazásokhoz általában Azure-erőforrások felügyelt identitásait érdemes használni a jelszó nélküli hitelesítéshez.
Azure-on kívüli, tartományhoz csatlakoztatott gépen futó alkalmazás
Nem Azure-beli gépeken felügyelt identitásokat nem lehet használni. Az Azure-on kívüli, tartományhoz csatlakoztatott gépeken futó alkalmazások ajánlott hitelesítési módszere a Microsoft Entra-azonosítón keresztüli integrált hitelesítés, feltéve, hogy a tartomány össze lett építve a Microsoft Entra-azonosítóval.
Ha az Azure-on kívüli gép nincs tartományhoz csatlakoztatva, a következőket teheti:
- Hozzon létre egy alkalmazásidentitást az alkalmazáshoz a Microsoft Entra-azonosítóban.
- Társíthat egy tanúsítványt az alkalmazásidentitással.
- Módosíthatja az alkalmazást úgy, hogy jogkivonatot kérjen az Azure SQL Database számára egy ügyfél-azonosító és egy tanúsítvány megadásával.
Bár a tanúsítványnak tartalmaznia kell egy titkos kulcsot és az alkalmazást üzemeltető gépen kell telepíteni, legalább elkerülheti, hogy rögzíteni kelljen az alkalmazáskulcsot az alkalmazás kódjában vagy konfigurációjában. (az alkalmazást a tanúsítvány ujjlenyomatával kell konfigurálnia.)
Adatbázisgazdák vagy más felhasználók, akik nem Azure-beli, tartományhoz nem csatlakoztatott gépről használják az SQL rendszergazdai eszközöket
Az Azure-on kívüli felhasználók számára érdemes kiküszöbölni a jelszavak használatát, amennyire csak lehetséges. Az SQL-eszközökkel a jelszóhasználatot a Microsoft Entra integrált hitelesítésével szüntetheti meg. Az eszközöknek azonban tartományhoz csatlakoztatott gépen kell futniuk, és a tartományt Microsoft Entra-azonosítóval kell összevonni, ami ebben a forgatókönyvben nem így van.
Mivel a környezet nem felel meg az integrált hitelesítés előfeltételeinek, javasoljuk, hogy többtényezős hitelesítéssel használja a Microsoft Entra interaktív hitelesítést, amelyet a legtöbb SQL-eszköz támogat.
Nem Azure-beli gépen futó régebbi alkalmazások, amelyeken nem módosítható az illesztőprogram vagy a kapcsolati sztring
Olyan forgatókönyvekben, ahol az illesztőprogram vagy a kapcsolati sztring nem módosítható, jelenleg nincs lehetőség a jelszavak kiküszöbölésére. Ezeknek a régebbi alkalmazásoknak továbbra is SQL-hitelesítést kell használniuk. Érdemes lehet alaposan áttanulmányozni a korlátozásokat és azt, hogyan lehet feloldani őket annak érdekében, hogy egy biztonságosabb hitelesítési módszert lehessen használni az alkalmazásokhoz.