Projektowanie rozproszonej geograficznie architektury danych
Ostatnią częścią projektu architektury naszej aplikacji, którą musimy wziąć pod uwagę, jest warstwa magazynowania danych. Chcemy mieć pewność, że po wystąpieniu awarii całego regionu dane będzie można zarówno odczytywać, jak i zapisywać z pełną funkcjonalnością.
W portalu śledzenia przesyłek wybraliśmy opcję wysyłania wszystkich żądań do usługi App Services w regionie Wschodnie stany USA za pomocą usługi Azure Front Door. Jeśli region Wschodnie stany USA zakończy się niepowodzeniem, usługa Front Door wykryje błąd i wysyła żądania do zduplikowanych składników usługi App Services w regionie Zachodnie stany USA. W naszej oryginalnej architekturze korzystającej z jednego regionu dane relacyjne były przechowywane w usłudze Azure SQL Database, a dane częściowo ustrukturyzowane w usłudze Cosmos DB. Teraz chcemy zrozumieć, w jaki sposób możemy zapewnić, że obie bazy danych pozostaną dostępne, jeśli region Wschodnie stany USA ulegnie awarii.
W tym miejscu dowiesz się, jak replikować dane między regionami i jak zapewnić szybkie przejście w tryb failover w razie potrzeby.
Azure SQL Database
Aby utworzyć implementację usługi Azure SQL Database z obsługą wielu regionów do przechowywania danych relacyjnych, można użyć dowolnej z tych opcji:
- Aktywna replikacja geograficzna
- Grupy automatycznego trybu failover
Aktywna replikacja geograficzna
Dzięki funkcji aktywnej replikacji geograficznej usługa Azure SQL Database może automatycznie replikować bazę danych i wszystkie dokonywane w niej zmiany do innej bazy danych. Zapisywalną kopię bazy danych hostuje tylko podstawowy serwer logiczny. Istnieje możliwość utworzenia maksymalnie czterech innych serwerów logicznych, które będą hostowały kopie bazy danych tylko do odczytu.
W portalu śledzenia przesyłek utwórz pomocniczą bazę danych w regionie Zachodnie stany USA i skonfiguruj replikację geograficzną z regionu Wschodnie stany USA. Gdy wystąpi awaria regionalna, usługa Front Door przekierowuje żądania użytkowników do usług App Services w regionie Zachodnie stany USA. Usługi App Services i Azure Functions mogą uzyskać dostęp do danych relacyjnych, ponieważ kopia została już zreplikowana do regionu Zachodnie stany USA.
Ta zmiana następuje automatycznie, ale należy pamiętać, że pomocnicza baza danych w regionie Zachodnie stany USA jest tylko do odczytu. Jeśli użytkownik spróbuje zmodyfikować dane, na przykład przez utworzenie nowej przesyłki, mogą wystąpić błędy. Możemy ręcznie zainicjować tryb failover w regionie Zachodnie stany USA, gdy tylko zauważymy problem w witrynie Azure Portal. Jeśli chcemy zautomatyzować ten proces, nasi deweloperzy mogą napisać kod wywołujący metodę failover w interfejsie API REST usługi Azure SQL Database.
Uwaga
Wystąpienia zarządzane usługi Azure SQL Database nie obsługują aktywnej replikacji geograficznej. Zostały one zaprojektowane w taki sposób, aby ułatwić bezpieczną migrację danych z lokalnego programu SQL Server. Jeśli używasz wystąpienia zarządzanego, rozważ użycie grup trybu failover.
Grupy automatycznego trybu failover
Grupa automatycznego trybu failover to grupa baz danych, w których dane są replikowane automatycznie z serwera podstawowego na jeden lub większą liczbę serwerów pomocniczych. Ten projekt jest podobny do aktywnej replikacji geograficznej i używa tej samej metody replikacji danych. Zachowanie w przypadku awarii można jednak zautomatyzować przez zdefiniowanie zasad.
W portalu wysyłkowym utworzymy pomocniczą bazę danych w regionie Zachodnie stany USA. Następnie dodamy zasady, które przejdą w tryb failover replikę podstawową bazy danych do regionu Zachodnie stany USA, jeśli w regionie Wschodnie stany USA wystąpi awaria katastrofalna. W takim scenariuszu replika z regionu Zachodnie stany USA automatycznie staje się zapisywalną podstawową bazą danych, dzięki czemu zachowywana jest pełna funkcjonalność.
Rozważ użycie grupy automatycznego trybu failover, jeśli chcesz zautomatyzować przełączenie w tryb failover zapisywalnej bazy danych bez konieczności pisania niestandardowego kodu w celu jego wyzwolenia. Ponadto użyj grup automatycznego trybu failover, jeśli baza danych działa w wystąpieniu zarządzanym usługi Azure SQL Database.
Ważne
Replikacja, która zastępuje zarówno aktywną replikację geograficzną, jak i grupy automatycznego trybu failover, są asynchroniczne. Potwierdzenie jest wysyłane do klienta po zastosowaniu zmiany w replice podstawowej. W tym momencie transakcja jest uznawana za ukończoną i następuje replikacja. Jeśli wystąpi awaria, ostatnie zmiany wprowadzone w podstawowej bazie danych mogą nie zostać zreplikowane do pomocniczej bazy danych. Należy pamiętać, że jeśli wystąpi awaria, ostatnie zmiany bazy danych mogą zostać utracone.
Azure Cosmos DB
Nasza konfiguracja jest mniej skomplikowana w przypadku usługi Azure Cosmos DB, ponieważ jest ona zaprojektowana jako system bazy danych w chmurze z wieloma regionami. Cosmos DB to wielomodelowa baza danych, w której można przechowywać dane relacyjne, dane częściowo ustrukturyzowane i inne formy danych. Nawet jeśli usługa Cosmos DB zostanie uruchomiona w jednym regionie, dane są replikowane do wielu wystąpień w różnych domenach błędów w celu zapewnienia jak największej dostępności.
Podczas tworzenia konta usługi Cosmos DB z obsługą wielu regionów można wybrać jeden z następujących trybów:
Konta z obsługą wielu regionów z wieloma regionami zapisu.
W tym trybie wszystkie kopie bazy danych są zawsze zapisywalne. W przypadku wystąpienia awarii regionu nie jest wymagane przełączenie w tryb failover.
Konta z obsługą wielu regionów z jednym regionem zapisu.
W tym trybie tylko region podstawowy zawiera zapisywalne bazy danych. Dane zreplikowane do regionów pomocniczych są tylko do odczytu. Aktualizacje są domyślnie wyłączone, jeśli region podstawowy ulegnie awarii. Można jednak wybrać opcję Włącz automatyczne przejście w tryb failover, dzięki czemu usługa Cosmos DB będzie automatycznie przechodzić z podstawowej zapisywalnej kopii bazy danych do pracy awaryjnej w innym regionie.
Ważne
W usłudze Cosmos DB replikacja danych zachodzi w sposób synchroniczny. Po zastosowaniu zmiany transakcja nie jest uważana za zakończoną, dopóki nie zostanie zreplikowana do kworum replik. Dopiero wtedy potwierdzenie jest wysyłane do klienta. Jeśli wystąpi awaria, nie zostaną utracone żadne ostatnie zmiany, ponieważ replikacja została zakończona już wcześniej.