DR dla usług PaaS
Proszę zaprojektować odzyskiwanie po awarii dla Azure SQL Database z użyciem replikacji geograficznej i grup automatycznego przełączania awaryjnego oraz porównać je z replikacją na poziomie maszyn wirtualnych dla obciążeń stanowych.
DR dla usług PaaS to bezpłatna lekcja Azure Fundamentals na CoddyKit. To lekcja 4 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Azure Fundamentals, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Azure Fundamentals zawiera 4 lekcji w sumie.
DR dla usług PaaS i IaaS
Odzyskiwanie po awarii w przypadku usług IaaS (maszyn wirtualnych) zazwyczaj obejmuje użycie Azure Site Recovery do replikowania całego systemu operacyjnego i dysków danych do regionu pomocniczego. Usługi PaaS mają inne modele DR, ponieważ podstawową infrastrukturą zarządza firma Microsoft. W przypadku PaaS konfiguracja DR zwykle odbywa się na warstwie danych — dane są replikowane do regionu pomocniczego, a sama platforma jest uruchamiana automatycznie.
Azure SQL Database: wbudowana redundancja
Azure SQL Database zapewnia wbudowaną wysoką dostępność na poziomie stref w obrębie jednego regionu. W przypadku DR między regionami oferuje dwie kluczowe funkcje: aktywną replikację geograficzną (dodatkowe bazy danych tylko do odczytu w maksymalnie czterech innych regionach) oraz grupy automatycznego przełączania awaryjnego (automatyczne przełączanie awaryjne z jednym punktem końcowym odbiornika). Funkcje te konfiguruje się na poziomie bazy danych lub serwera, bez konieczności używania Azure Site Recovery.
# Create a geo-replication link:
az sql db replica create \
--resource-group myRG \
--server primarySqlServer \
--name myDatabase \
--partner-server secondarySqlServer \
--partner-resource-group secondaryRGGrupy automatycznego przełączania awaryjnego
Grupy automatycznego przełączania awaryjnego zapewniają automatyzację i jeden punkt końcowy połączenia w oparciu o replikację geograficzną. Należy skonfigurować grupę na serwerze podstawowym, dodać serwer pomocniczy i określić okres karencji — czas, przez który Azure czeka na odzyskanie serwera podstawowego przed uruchomieniem automatycznego przełączenia awaryjnego. Aplikacje łączą się z punktem końcowym odbiornika (np. mygroup.database.windows.net) i po przełączeniu awaryjnym są automatycznie przekierowywane bez zmiany parametrów połączenia.
# Create an auto-failover group:
az sql failover-group create \
--resource-group myRG \
--server primarySqlServer \
--name myFailoverGroup \
--partner-server secondarySqlServer \
--partner-resource-group secondaryRG \
--failover-policy Automatic \
--grace-period 60RPO dla usługi Azure SQL z replikacją geograficzną
Replikacja geograficzna usługi Azure SQL Database jest asynchroniczna — transakcje są zatwierdzane na serwerze podstawowym, a następnie replikowane do serwera pomocniczego. Oznacza to niewielkie opóźnienie replikacji, zwykle mniejsze niż 5 sekund w normalnych warunkach. RPO dla replikacji geograficznej SQL wynosi zatem w większości scenariuszy około 5 sekund, dzięki czemu rozwiązanie nadaje się do obciążeń Tier 1 i Tier 2 wymagających bardzo małej utraty danych.
Przywracanie SQL do punktu w czasie
Wszystkie warstwy usługi Azure SQL Database obejmują automatyczne kopie zapasowe: pełne kopie zapasowe co tydzień, różnicowe kopie zapasowe co 12 godzin oraz kopie zapasowe dziennika transakcji co 5–12 minut. Umożliwia to przywracanie do punktu w czasie (PITR) — przywrócenie bazy danych do dowolnej sekundy w okresie przechowywania (7–35 dni w warstwach Standard/General Purpose, maksymalnie 35 dni w warstwie Business Critical). PITR jest przydatne do odzyskiwania danych po przypadkowym usunięciu lub uszkodzeniu.
# Restore a database to a specific point in time:
az sql db restore \
--resource-group myRG \
--server mySqlServer \
--name myDatabase-restored \
--source-database-name myDatabase \
--time '2026-06-20T14:30:00Z'Cosmos DB: zapis w wielu regionach na potrzeby DR
Azure Cosmos DB z zapisem w wielu regionach zapewnia aplikacjom globalnym niemal zerowy RPO. Wszystkie skonfigurowane regiony mogą jednocześnie przyjmować operacje zapisu, a Cosmos DB automatycznie synchronizuje dane za pomocą własnego protokołu replikacji. W przypadku awarii regionu ruch jest automatycznie kierowany do pozostałych sprawnych regionów, bez konieczności ręcznego przełączania awaryjnego — co pozwala osiągnąć wartości RTO i RPO bliskie zeru.
# Add a secondary region to Cosmos DB:
az cosmosdb update \
--resource-group myRG \
--name myCosmosAccount \
--locations regionName=eastus failoverPriority=0 isZoneRedundant=true \
regionName=westus failoverPriority=1 isZoneRedundant=trueZagadnienia DR dotyczące Azure App Service
Sama usługa Azure App Service jest bezstanowa (kod aplikacji jest wdrażany z systemu kontroli wersji lub pliku ZIP). W kontekście DR należy skupić się na warstwie danych (bazie danych i magazynie obiektów blob). App Service można szybko ponownie wdrożyć w regionie pomocniczym za pomocą potoku CI/CD. Należy jednak zadbać o replikację lub oskryptowanie niestandardowej domeny, certyfikatów TLS i ustawień aplikacji, aby można je było szybko odtworzyć w regionie pomocniczym.
# Export App Service configuration (app settings + connection strings):
az webapp config appsettings list \
--name myWebApp \
--resource-group myRG \
--output json > appsettings-backup.json
# Apply to secondary region App Service:
az webapp config appsettings set \
--name myWebApp-secondary \
--resource-group secondaryRG \
--settings @appsettings-backup.jsonAzure Storage: GRS i RA-GRS
Azure Blob Storage z funkcją magazynu geograficznie nadmiarowego (GRS) automatycznie replikuje dane do regionu pomocniczego oddalonego o setki kilometrów. Dane są replikowane asynchronicznie (RPO zazwyczaj wynosi mniej niż 15 minut). Funkcja GRS z dostępem do odczytu (RA-GRS) umożliwia odczyt z pomocniczego punktu końcowego jeszcze przed uruchomieniem przełączenia awaryjnego, co jest przydatne w przypadku obciążeń analitycznych i raportowych podczas awarii regionu podstawowego.
# Create a storage account with RA-GRS:
az storage account create \
--resource-group myRG \
--name mystorageaccount \
--sku Standard_RAGRS \
--kind StorageV2
# Secondary endpoint: mystorageaccount-secondary.blob.core.windows.netDR dla Azure Functions i Logic Apps
Azure Functions są z założenia bezstanowe, dzięki czemu można je łatwo ponownie wdrożyć. W ramach DR należy wdrożyć tę samą aplikację funkcji w regionie pomocniczym i użyć Traffic Manager do kierowania wyzwalaczy HTTP między regionami. W przypadku wyzwalaczy innych niż HTTP (Service Bus, Event Grid) należy skonfigurować źródło komunikatów tak, aby rozsyłało je do obu regionów, albo skonfigurować region pomocniczy tak, aby odpytywał to samo źródło. Stan funkcji w usłudze Durable Functions jest przechowywany w Azure Storage — należy upewnić się, że ten magazyn korzysta z GRS.
Wybór między aktywną replikacją geograficzną a grupami automatycznego przełączania awaryjnego
Aktywnej replikacji geograficznej należy używać, gdy potrzebują Państwo szczegółowej kontroli — na przykład kierowania ruchu odczytu do repliki pomocniczej w celu zwiększenia wydajności lub niezależnego zarządzania wieloma replikami pomocniczymi w różnych regionach. Grupy automatycznego przełączania awaryjnego warto wybrać, gdy najważniejsza jest prostota: pojedynczy punkt końcowy nasłuchujący, automatyczne przełączanie awaryjne zgodnie z harmonogramem oraz wbudowana orkiestracja procesu przełączania bez konieczności ręcznej interwencji.
Porównanie kosztów odzyskiwania po awarii w usługach PaaS i na maszynach wirtualnych
Odzyskiwanie po awarii w modelu PaaS jest często tańsze niż odzyskiwanie oparte na maszynach wirtualnych z kilku powodów. Replikacja geograficzna SQL Database obejmuje opłatą tylko magazyn i moc obliczeniową repliki pomocniczej — nie płacą Państwo za pełną licencję systemu operacyjnego maszyny wirtualnej. Azure Cosmos DB pobiera opłaty za aprowizowane jednostki RU w każdym regionie. Azure Storage GRS zwiększa koszt magazynu około dwukrotnie. Z kolei maszyny wirtualne replikowane za pomocą ASR wymagają poniesienia pełnych kosztów mocy obliczeniowej, magazynu i licencjonowania w regionie pomocniczym.
Szybki test
Sprawdź swoją wiedzę na temat zagadnień Microsoft Azure Fundamentals (AZ-900) z tej lekcji.
Podsumowanie lekcji
W tej lekcji poznali Państwo następujące zagadnienia: odzyskiwanie po awarii w modelu PaaS koncentruje się na warstwie danych, a nie na replikacji maszyn wirtualnych; grupy automatycznego przełączania awaryjnego usługi Azure SQL zapewniają pojedynczy punkt końcowy nasłuchujący i automatyczne przełączanie awaryjne; a zapisy w wielu regionach usługi Cosmos DB zapewniają niemal zerowe wartości RTO i RPO dla aplikacji globalnych. Następnie omówimy struktury zgodności platformy Azure oraz model współdzielonej odpowiedzialności.
Często zadawane pytania
Czy lekcja „DR dla usług PaaS” jest bezpłatna?
Tak — pełny tekst „DR dla usług PaaS” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Azure Fundamentals, przejdź na CoddyKit PRO. Kurs Azure Fundamentals zawiera 4 lekcji w sumie.
Co nauczysz się w „DR dla usług PaaS”?
Proszę zaprojektować odzyskiwanie po awarii dla Azure SQL Database z użyciem replikacji geograficznej i grup automatycznego przełączania awaryjnego oraz porównać je z replikacją na poziomie maszyn wi… Ćwiczysz Azure Fundamentals z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.
Czy potrzebuję doświadczenia, aby zacząć Azure Fundamentals?
Nie wymagamy żadnego doświadczenia. Azure Fundamentals w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 4 z 4.
Ile czasu zajmuje lekcja „DR dla usług PaaS”?
Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.
Czy mogę pisać i uruchamiać kod w tej lekcji Azure Fundamentals?
Tak. Każda lekcja Azure Fundamentals zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.
Wszystkie lekcje w tym kursie
- Definiowanie RTO, RPO i poziomów odtwarzania
- Plany odtwarzania i automatyczne przełączanie awaryjne
- Testowanie DR bez wpływu na środowisko
- DR dla usług PaaS