Udostępnij za pośrednictwem

Architektury bazy danych Oracle na maszynach wirtualnych platformy Azure

  • Artykuł

Dotyczy: ✔️ maszyny wirtualne z systemem Linux

Ten artykuł zawiera informacje dotyczące wdrażania bazy danych Oracle o wysokiej dostępności na platformie Azure. Ponadto ten przewodnik zawiera szczegółowe informacje na temat zagadnień związanych z odzyskiwaniem po awarii. Te architektury zostały utworzone na podstawie wdrożeń klientów. Ten przewodnik dotyczy tylko wersji Oracle Database Enterprise Edition.

Jeśli chcesz dowiedzieć się więcej na temat maksymalizacji wydajności bazy danych Oracle, zobacz Projektowanie i implementowanie bazy danych Oracle na platformie Azure.

Wymagania wstępne

  • Zrozumienie różnych pojęć dotyczących platformy Azure, takich jak strefy dostępności
  • Oracle Database Enterprise Edition 12c lub nowszy
  • Świadomość skutków licencjonowania podczas korzystania z rozwiązań w tym artykule
  • Zdefiniowane wymagania dotyczące celu punktu odzyskiwania i celu odzyskiwania

Wysoka dostępność baz danych Oracle

Osiągnięcie wysokiej dostępności w chmurze jest ważną częścią planowania i projektowania każdej organizacji. Platforma Azure oferuje strefy dostępności i zestawy dostępności do użycia w regionach, w których strefy dostępności są niedostępne. Aby uzyskać więcej informacji na temat projektowania chmury, zobacz Opcje dostępności dla usługi Azure Virtual Machines.

Oprócz narzędzi i ofert natywnych dla chmury firma Oracle udostępnia rozwiązania zapewniające wysoką dostępność, które można skonfigurować na platformie Azure:

W tym przewodniku opisano architektury referencyjne dla każdego z tych rozwiązań.

Podczas migracji lub tworzenia aplikacji dla chmury zalecamy używanie wzorców natywnych dla chmury, takich jak wzorzec ponawiania prób i wzorzec wyłącznika. Aby zapoznać się z innymi wzorcami, które mogą pomóc zwiększyć odporność aplikacji, zobacz Przewodnik po wzorcach projektowania chmury.

Oracle RAC w chmurze

Oracle Real Application Cluster (RAC) to rozwiązanie firmy Oracle, które ułatwia klientom osiągnięcie wysokiej przepływności przez uzyskanie dostępu do jednego magazynu bazy danych przez wiele wystąpień. Ten wzorzec jest architekturą współdzieloną. Chociaż rozwiązanie Oracle RAC może służyć do zapewnienia wysokiej dostępności w środowisku lokalnym, sam model Oracle RAC nie może być używany do wysokiej dostępności w chmurze. Rozwiązanie Oracle RAC chroni tylko przed awariami na poziomie wystąpienia, a nie przed awariami na poziomie stojaka lub centrum danych. Z tego powodu firma Oracle zaleca używanie funkcji Oracle Data Guard z bazą danych, niezależnie od tego, czy jest to pojedyncze wystąpienie, czy RAC, w celu zapewnienia wysokiej dostępności.

Klienci zazwyczaj wymagają wysokiej umowy SLA do uruchamiania aplikacji o znaczeniu krytycznym. Firma Oracle obecnie nie certyfikowa ani nie obsługuje usługi Oracle RAC na platformie Azure. Jednak platforma Azure oferuje funkcje, takie jak strefy dostępności i okna planowanej konserwacji, które ułatwiają ochronę przed awariami na poziomie wystąpienia. Oprócz tych ofert można używać funkcji Oracle Data Guard, Oracle GoldenGate i Oracle Sharding w celu zapewnienia wysokiej wydajności i odporności. Te technologie mogą pomóc chronić bazy danych przed awariami na poziomie stojaka, centrum danych i geopolitycznymi.

W przypadku uruchamiania baz danych Oracle Database w wielu strefach dostępności za pomocą programu Oracle Data Guard lub GoldenGate można uzyskać umowę SLA dotyczącą czasu pracy na poziomie 99,99%. W regionach świadczenia usługi Azure, w których strefy dostępności nie są jeszcze obecne, można użyć zestawów dostępności i uzyskać umowę SLA czasu pracy na 99,95%.

Uwaga

Możesz mieć docelowy czas pracy, który jest znacznie wyższy niż umowa SLA czasu pracy zapewniana przez firmę Microsoft.

Odzyskiwanie po awarii dla baz danych Oracle

Podczas hostowania aplikacji o krytycznym znaczeniu w chmurze ważne jest zaprojektowanie pod kątem wysokiej dostępności i odzyskiwania po awarii.

W przypadku programu Oracle Database Enterprise Edition funkcja Oracle Data Guard jest przydatną funkcją odzyskiwania po awarii. Wystąpienie bazy danych rezerwowej można skonfigurować w sparowanym regionie platformy Azure i skonfigurować tryb failover funkcji Data Guard na potrzeby odzyskiwania po awarii. W przypadku zerowej utraty danych zalecamy wdrożenie wystąpienia programu Oracle Data Guard Far Sync oprócz funkcji Active Data Guard.

W przypadku replikacji danych o długiej odległości zaleca się korzystanie z usługi Far Sync. Far Sync to funkcja Oracle Active Data Guard.

Uwaga

Jeśli włączysz usługę Far Sync, wymagana jest licencja usługi Active Data Guard. Skontaktuj się z przedstawicielem Oracle, aby omówić implikacje dotyczące licencjonowania.

Usługa Oracle Far Sync zajmuje długą odległość między podstawową bazą danych a pomocniczą bazą danych, wprowadzając pośredni serwer znany jako wystąpienie usługi Far Sync. Ten serwer odbiera ponownie dane z podstawowej bazy danych, a następnie przekazuje je do bazy danych rezerwowej. Dzięki temu wystąpienie usługi Far Sync znajduje się bliżej podstawowego, aby skrócić czas komunikacji. Następnie serwer usługi Far Sync przesyła ponownie dane asynchronicznie do pomocniczej bazy danych.

Uwaga

W przypadku korzystania z baz danych Oracle Standard Edition istnieją rozwiązania niezależnego dostawcy oprogramowania, które umożliwiają skonfigurowanie wysokiej dostępności i odzyskiwania po awarii, takich jak DBVisit Standby lub Tessell.

Architektury odwołań

Oracle Data Guard

Funkcja Oracle Data Guard zapewnia wysoką dostępność, ochronę danych i odzyskiwanie po awarii dla danych przedsiębiorstwa. Funkcja Data Guard obsługuje bazy danych rezerwowych jako transakcyjnie spójne kopie podstawowej bazy danych. W zależności od odległości między podstawowymi i pomocniczymi bazami danych a tolerancją aplikacji dla opóźnienia można skonfigurować replikację synchroniczną lub asynchroniczną.

Oracle Data Guard z trybem failover szybkiego uruchamiania

Funkcja Data Guard można wdrożyć przy użyciu trybu failover szybkiego startu (FSFO). Tryb szybki start-failover to funkcja udostępniona w konfiguracji brokera funkcji Data Guard. Ta funkcja umożliwia automatyczne przejście w tryb failover w przypadku awarii. Domyślny czas użycia przez klientów to 30 sekund, ale można go dostosować w zależności od wymagań. Ten tzw. OperationTimeout jest częścią właściwości funkcji Data Guard zdefiniowanych podczas wdrażania.

Jak działa funkcja Data Guard z tą właściwością

Zadaniem funkcji Data Guards jest ciągłe monitorowanie kondycji i stanu podstawowej i pomocniczej bazy danych. Po włączeniu trybu failover szybkiego uruchamiania (FSFO) proces obserwatora jest wyzwalany i przegląda stan kondycji w regularnych odstępach czasu, aby zapewnić wysoką dostępność w danym momencie.

Jeśli podstawowa baza danych stanie się niedostępna, obserwator i broker usługi Data Guard wykryją tę przerwę. W ten sposób parametr OperationTimeout 30 sekund określa, jak długo broker powinien czekać na odpowiedź z podstawowej bazy danych przed podjęciem dalszych działań.

Co powoduje, że w tym 30-sekundowym oknie element podstawowy nie odpowiada, obserwator zakłada, że podstawowy jest niedostępny i rozpoczyna proces pracy w trybie failover.

Broker natychmiast promuje bazę danych rezerwowej do stanu podstawowego, przełączając role i zapewniając, że aplikacja może szybko wznowić działanie z trybu wstrzymania.

W tym czasie broker zapewnia również, że transakcje są aktualne w stanie gotowości. W przypadku skonfigurowanego trybu, który może być maksymalną dostępnością lub maksymalną ochroną, replikacja synchroniczna zapewni minimalną do zerowej utraty danych. Bazy danych Oracle są umieszczane w wielu strefach dostępności w celu zapewnienia wysokiej dostępności. Każda strefa składa się z co najmniej jednego centrum danych wyposażonego w niezależne zasilanie, chłodzenie i sieć. Aby zapewnić odporność, w wszystkich regionach z włączoną obsługą skonfigurowano co najmniej trzy oddzielne strefy. Fizyczne rozdzielenie stref dostępności w regionie chroni dane przed awariami centrum danych. Ponadto dwa obserwatory FSFO są konfigurowane w dwóch strefach dostępności w celu zainicjowania trybu failover w pomocniczej bazie danych w przypadku awarii. Po przejściu w tryb failover i ponownym udostępnieniu poprzedniej podstawowej bazy danych można ją przywrócić. Broker usługi Data Guard ułatwia ten proces.

Ostatecznie, jeśli podstawowa baza danych jest niedostępna z powodu planowanej lub nieplanowanej awarii, funkcja Data Guard przełącza się lub przechodzi w tryb failover do bazy danych rezerwowej.

Ta funkcja może zapewnić dodatkową odporność, konfigurując obserwatora na oddzielnej maszynie wirtualnej. W ten sposób obserwator jest wdrażany na lekkiej maszynie wirtualnej. Takie podejście umożliwia wysoką dostępność i odporność.

W przypadku bazy danych Oracle Database w wersji 12.2 lub nowszej można również skonfigurować wiele obserwatorów przy użyciu jednej konfiguracji brokera oracle Data Guard. Zapewnia dodatkową dostępność w przypadku przestoju jednego obserwatora i pomocniczej bazy danych. Aby uzyskać więcej informacji na temat brokera usługi Data Guard i jego zalet, zobacz Oracle Data Guard Broker Concepts (Pojęcia dotyczące brokera usługi Oracle Data Guard).

Na poniższym diagramie przedstawiono instalację programu Oracle Data Guard bez funkcji Far Sync z czasem odzyskiwania krótszym niż 5 minut.

Diagram przedstawiający architekturę oracle Data Guard.

Bazy danych Oracle są umieszczane w wielu strefach dostępności w celu zapewnienia wysokiej dostępności. Każda strefa składa się z co najmniej jednego centrum danych wyposażonego w niezależne zasilanie, chłodzenie i sieć. Aby zapewnić odporność, w wszystkich regionach z włączoną obsługą skonfigurowano co najmniej trzy oddzielne strefy. Fizyczne rozdzielenie stref dostępności w regionie chroni dane przed awariami centrum danych. Ponadto dwa obserwatory FSFO są konfigurowane w dwóch strefach dostępności w celu zainicjowania trybu failover w pomocniczej bazie danych w przypadku awarii.

Uwaga

Podczas planowania wdrożenia symetrycznej funkcji Data Guard należy pamiętać, że w strefie dostępności będzie potrzebny jeszcze jeden obserwator w strefie dostępności trzy.

Ponadto zdecydowanie zalecamy wdrożenie programu Oracle Enterprise Manager w celu zachowania przeglądu warstwy bazy danych. Zaleca się wdrożenie usługi Azure Monitor przy użyciu następujących metryk: Monitorowanie dysków:

  • Procent użycia operacji we/wy na sekundę dysku systemu operacyjnego
  • Procent użycia operacji we/wy na sekundę dysku danych
  • Bajty odczytu dysku danych/s
  • Liczba bajtów zapisu na dysku danych na sekundę
  • Głębokość kolejki dysku
  • Przepustowość dysku w % na jednostkę LUN

Oprócz powyższych zdecydowanie zalecamy również włączenie szczegółowych informacji o maszynie wirtualnej.

Maszyna wirtualna jest wybierana na podstawie oceny AWR. Aby uzyskać więcej informacji, zapoznaj się z tematem Oracle Capacity Planning (Planowanie pojemności Oracle). Zdecydowanie zalecamy korzystanie z ograniczonych procesorów wirtualnych rdzeni, aby zaoszczędzić na kosztach licencjonowania i zmaksymalizować wydajność.

Wybór typu dysku zależy od danych wyjściowych oceny AWR.

Jak wspomniano powyżej, usługa Far Sync jest funkcją używaną głównie w scenariuszach, w których replikujesz między regionami pokonując długie odległości. Odnosząc się do tego scenariusza, usługa Oracle Active Data Guard Far Sync zapewnia zerową możliwość ochrony przed utratą danych dla baz danych Oracle Database. Wystąpienie programu Oracle Far Sync musi być zainstalowane na oddzielnej maszynie wirtualnej.

Dyski SSD w warstwie Premium w wersji 2 nie są obsługiwane w przypadku plików odwołująjących się do systemu operacyjnego. Aby uzyskać więcej informacji, odwiedź stronę Deploy Premium SSD v2 (Wdrażanie dysków SSD w warstwie Premium w wersji 2).

Jako używana jest docelowa kopia zapasowa usługi Azure Premium Files. To rozwiązanie jest najbardziej wydajne. Możesz również użyć usługi Azure Blob Storage jako miejsca docelowego kopii zapasowej. Zawsze upewnij się, że sprawdzasz, która opcja jest najlepsza. Odwiedź również stronę Oracle Database Backup Strategies (Strategie tworzenia kopii zapasowych bazy danych Oracle).

Oracle Data Guard Far Sync

Jak wspomniano powyżej, usługa Far Sync jest funkcją używaną głównie w scenariuszach, w których replikujesz między regionami pokonując długie odległości. Odnosząc się do tego scenariusza, usługa Oracle Far Sync zapewnia zerową możliwość ochrony przed utratą danych dla baz danych Oracle Database. Wystąpienie programu Oracle Far Sync musi być zainstalowane na oddzielnej maszynie wirtualnej.

W przypadku ochrony przed utratą danych należy przeprowadzić synchroniczną komunikację między podstawową bazą danych a wystąpieniem usługi Far Sync. Wystąpienie usługi Far Sync odbiera ponownie z bazy podstawowej w sposób synchroniczny i przekazuje je natychmiast do wszystkich baz danych rezerwowych w sposób asynchroniczny. Ta konfiguracja zmniejsza również obciążenie podstawowej bazy danych, ponieważ musi wysłać ponownie do wystąpienia usługi Far Sync, a nie wszystkich baz danych rezerwowych. Jeśli wystąpienie usługi Far Sync zakończy się niepowodzeniem, funkcja Active Data Guard automatycznie używa asynchronicznego transportu do pomocniczej bazy danych z podstawowej bazy danych w celu zachowania ochrony przed utratą danych niemal zerową. W przypadku dodatkowej odporności klienci mogą wdrażać wiele wystąpień usługi Far Sync na każde wystąpienie bazy danych, w tym podstawowe i pomocnicze.

Na poniższym diagramie przedstawiono architekturę korzystającą z programu Oracle Active Data Guard FSFO i Far Sync w celu osiągnięcia wysokiej dostępności i odzyskiwania po awarii:

Diagram przedstawiający usługę Oracle Database using Far Sync w konfiguracji usługi Active Data Guard w różnych regionach.

Uwaga

Podczas planowania wdrożenia symetrycznej usługi Far Sync należy pamiętać, że w drugim regionie będzie potrzebne jeszcze jedno wystąpienie usługi Far Sync.

Oracle GoldenGate

GoldenGate umożliwia wymianę i manipulowanie danymi na poziomie transakcji na wielu platformach heterogenicznych w przedsiębiorstwie. Przenosi zatwierdzone transakcje z integralnością transakcji i minimalnym obciążeniem w istniejącej infrastrukturze. Jego modularna architektura zapewnia elastyczność wyodrębniania i replikowania wybranych rekordów danych, zmian transakcyjnych i zmian języka definicji danych (DDL) w różnych topologiach.

Rozwiązanie Oracle GoldenGate umożliwia skonfigurowanie bazy danych pod kątem wysokiej dostępności przez zapewnienie replikacji dwukierunkowej. Takie podejście umożliwia skonfigurowanie konfiguracji wielowzorcowej lub aktywnej-aktywnej, która wymaga rozpoznawania na poziomie aplikacji. Na poniższym diagramie zalecana jest architektura konfiguracji Oracle GoldenGate active-active-active na platformie Azure. W poniższej architekturze baza danych Oracle została skonfigurowana przy użyciu maszyny wirtualnej zoptymalizowanej pod kątem hiperwątków pamięci z ograniczonymi rdzeniami wirtualnymi, aby zaoszczędzić na kosztach licencjonowania i zmaksymalizować wydajność. Architektura używa wielu dysków w warstwie Premium lub Ultra (dysków zarządzanych) w celu zapewnienia wydajności i dostępności.

Diagram przedstawiający bazę danych Oracle Database używającą stref dostępności z brokerem usługi Data Guard — FSFO.

Uwaga

Podobną architekturę można skonfigurować przy użyciu zestawów dostępności w regionach, w których strefy dostępności nie są obecnie dostępne.

Rozwiązanie Oracle GoldenGate zawiera procesy, takie jak Wyodrębnianie, Pompa i Replicat , które ułatwiają asynchroniczne replikowanie danych z jednego serwera bazy danych Oracle do innego. Te procesy umożliwiają skonfigurowanie replikacji dwukierunkowej w celu zapewnienia wysokiej dostępności bazy danych, jeśli wystąpi przestój na poziomie strefy dostępności.

Na powyższym diagramie proces wyodrębniania jest uruchamiany na tym samym serwerze co baza danych Oracle. Procesy pompy danych i repliki są uruchamiane na osobnym serwerze w tej samej strefie dostępności. Proces replicat służy do odbierania danych z bazy danych w innej strefie dostępności i zatwierdzania danych do bazy danych Oracle w strefie dostępności. Podobnie proces Pompa danych wysyła dane wyodrębnione przez proces wyodrębniania do procesu Replicat w inną strefę dostępności.

Na powyższym diagramie architektury przedstawiono procesy pompy danych i repliki skonfigurowane na osobnym serwerze, ale można skonfigurować wszystkie procesy Oracle GoldenGate na tym samym serwerze na podstawie pojemności i użycia serwera. Zawsze skonsultuj się z raportem AWR i metrykami na platformie Azure, aby zrozumieć wzorzec użycia serwera.

Podczas konfigurowania replikacji dwukierunkowej Oracle GoldenGate w różnych strefach dostępności lub w różnych regionach należy upewnić się, że opóźnienie między różnymi składnikami jest akceptowalne dla aplikacji. Opóźnienie między strefami dostępności i regionami może się różnić. Opóźnienie zależy od wielu czynników. Zalecamy skonfigurowanie testów wydajnościowych między warstwą aplikacji a warstwą bazy danych w różnych strefach dostępności lub regionach. Testy mogą potwierdzić, że konfiguracja spełnia wymagania dotyczące wydajności aplikacji.

Warstwę aplikacji można skonfigurować we własnej podsieci, a warstwa bazy danych może zostać podzielona na własną podsieć. Jeśli to możliwe, rozważ użycie bramy aplikacja systemu Azure do równoważenia obciążenia ruchu między serwerami aplikacji. Usługa Application Gateway to niezawodny moduł równoważenia obciążenia ruchu internetowego. Zapewnia koligację sesji opartą na plikach cookie, która utrzymuje sesję użytkownika na tym samym serwerze, minimalizując konflikty w bazie danych. Alternatywą dla usługi Application Gateway są usługi Azure Load Balancer i Azure Traffic Manager.

Fragmentowanie Oracle

Fragmentowanie to wzorzec warstwy danych wprowadzony w programie Oracle 12.2. Umożliwia ona partycjonowanie w poziomie i skalowanie danych w niezależnych bazach danych. Jest to architektura bez udziału, w której każda baza danych jest hostowana na dedykowanej maszynie wirtualnej. Ten wzorzec umożliwia wysoką przepływność odczytu i zapisu oprócz odporności i zwiększonej dostępności.

Ten wzorzec eliminuje pojedyncze punkty awarii, zapewnia izolację błędów i umożliwia uaktualnianie stopniowe bez przestojów. Przestój jednego fragmentu lub awarii na poziomie centrum danych nie ma wpływu na wydajność ani dostępność innych fragmentów w innych centrach danych.

Fragmentowanie jest odpowiednie dla aplikacji OLTP o wysokiej przepływności, które nie mogą sobie pozwolić na przestoje. Wszystkie wiersze z tym samym kluczem fragmentowania są zawsze gwarantowane dla tego samego fragmentu. Ten fakt zwiększa wydajność, zapewniając wysoką spójność. Aplikacje korzystające z fragmentowania muszą mieć dobrze zdefiniowany model danych i strategię dystrybucji danych, taką jak spójny skrót, zakres, lista lub złożony. Strategia uzyskuje przede wszystkim dostęp do danych przy użyciu klucza fragmentowania, na przykład customerId lub accountNum. Fragmentowanie umożliwia również przechowywanie określonych zestawów danych bliżej klientów końcowych, co pomaga spełnić wymagania dotyczące wydajności i zgodności.

Zalecamy replikowanie fragmentów w celu zapewnienia wysokiej dostępności i odzyskiwania po awarii. Tę konfigurację można skonfigurować przy użyciu technologii Oracle, takich jak Oracle Data Guard lub Oracle GoldenGate. Jednostka replikacji może być fragmentem, częścią fragmentu lub grupą fragmentów. Awaria lub spowolnienie jednego lub większej liczby fragmentów nie wpływa na dostępność podzielonej bazy danych.

W celu zapewnienia wysokiej dostępności fragmenty rezerwowe można umieścić w tej samej strefie dostępności, w której znajdują się podstawowe fragmenty. W przypadku odzyskiwania po awarii fragmenty rezerwowe mogą znajdować się w innym regionie. Fragmenty można również wdrożyć w wielu regionach, aby obsługiwać ruch w tych regionach. Aby dowiedzieć się więcej na temat konfigurowania wysokiej dostępności i replikacji podzielonej na fragmenty bazy danych, zobacz Wysoka dostępność na poziomie fragmentów.

Fragmentowanie oracle składa się głównie z następujących składników. Aby uzyskać więcej informacji, zobacz Oracle Sharding Overview (Omówienie fragmentowania Oracle):

  • Wykaz fragmentów. Baza danych Oracle specjalnego przeznaczenia, która jest magazynem trwałym dla wszystkich danych konfiguracji bazy danych fragmentów. Wszystkie zmiany konfiguracji, takie jak dodawanie lub usuwanie fragmentów, mapowanie danych i listy DDLs w bazie danych fragmentów są inicjowane w wykazie fragmentów. Wykaz fragmentów zawiera również kopię główną wszystkich zduplikowanych tabel w bazie danych SDB.

    Wykaz fragmentów używa zmaterializowanych widoków do automatycznego replikowania zmian do zduplikowanych tabel we wszystkich fragmentach. Baza danych wykazu fragmentów działa również jako koordynator zapytań używany do przetwarzania zapytań wieloczęściowych i zapytań, które nie określają klucza fragmentowania.

    Zalecamy używanie funkcji Oracle Data Guard ze strefami dostępności lub zestawami dostępności dla wysokiej dostępności wykazu fragmentów jako najlepsze rozwiązanie. Dostępność wykazu fragmentów nie ma wpływu na dostępność podzielonej bazy danych na fragmenty. Przestój w wykazie fragmentów ma wpływ tylko na operacje konserwacji i zapytania wieloczęściowe w krótkim okresie ukończenia pracy w trybie failover funkcji Data Guard. Baza danych SDB kontynuuje kierowanie i uruchamianie transakcji online. Awaria katalogu nie ma na nie wpływu.

  • Dyrektorzy fragmentów. Uproszczone usługi, które należy wdrożyć w każdym regionie/strefie dostępności, w których znajdują się fragmenty. Dyrektorzy fragmentów są menedżerami usług globalnych wdrożonych w kontekście fragmentowania Oracle. W celu zapewnienia wysokiej dostępności zalecamy wdrożenie co najmniej jednego dyrektora fragmentów w każdej strefie dostępności, w której istnieją fragmenty.

    Podczas początkowego nawiązywania połączenia z bazą danych dyrektor fragmentów konfiguruje informacje o routingu i buforuje informacje dotyczące kolejnych żądań, które pomijają dyrektora fragmentów. Po ustanowieniu sesji przy użyciu fragmentu wszystkie zapytania SQL i listy DML są obsługiwane i wykonywane w zakresie danego fragmentu. Ten routing jest szybki i jest używany dla wszystkich obciążeń OLTP, które wykonują transakcje wewnątrz fragmentów. Zalecamy używanie routingu bezpośredniego dla wszystkich obciążeń OLTP, które wymagają najwyższej wydajności i dostępności. Pamięć podręczna routingu jest automatycznie odświeżana, gdy fragment stanie się niedostępny lub nastąpią zmiany topologii fragmentowania.

    W przypadku routingu zależnego od danych o wysokiej wydajności firma Oracle zaleca używanie puli połączeń podczas uzyskiwania dostępu do danych w bazie danych podzielonych na fragmenty. Pule połączeń Oracle, biblioteki specyficzne dla języka i sterowniki obsługują fragmentowanie Oracle. Aby uzyskać więcej informacji, zobacz Oracle Sharding Overview (Omówienie fragmentowania Oracle).

  • Usługa globalna. Usługa globalna jest podobna do zwykłej usługi bazy danych. Oprócz wszystkich właściwości usługi bazy danych usługa globalna ma właściwości dla baz danych podzielonych na fragmenty. Te właściwości obejmują koligację regionów między klientami a fragmentami i tolerancją opóźnienia replikacji. Aby odczytywać/zapisywać dane do i z bazy danych podzielonych na fragmenty, należy utworzyć tylko jedną usługę globalną. W przypadku korzystania z funkcji Active Data Guard i konfigurowania replik tylko do odczytu fragmentów można utworzyć kolejną globalną usługę dla obciążeń tylko do odczytu. Klient może używać tych usług globalnych do nawiązywania połączenia z bazą danych.

  • Bazy danych fragmentów. Bazy danych fragmentów to bazy danych Oracle. Każda baza danych jest replikowana przy użyciu funkcji Oracle Data Guard w konfiguracji brokera z włączoną funkcją FSFO. Nie trzeba konfigurować trybu failover i replikacji funkcji Data Guard na każdym fragmentie. Ten aspekt jest automatycznie konfigurowany i wdrażany podczas tworzenia udostępnionej bazy danych. Jeśli określony fragment zakończy się niepowodzeniem, udostępnianie bazy danych Oracle przechodzi w tryb failover z podstawowego do rezerwowego.

Bazy danych z podziałem na fragmenty można wdrażać i zarządzać nimi za pomocą dwóch interfejsów: graficzny interfejs użytkownika kontroli chmury programu Oracle Enterprise Manager i GDSCTL narzędzia wiersza polecenia. Możesz nawet monitorować różne fragmenty pod kątem dostępności i wydajności przy użyciu kontroli chmury. Polecenie GDSCTL DEPLOY automatycznie tworzy fragmenty i ich odbiorniki. Ponadto to polecenie automatycznie wdraża konfigurację replikacji używaną do wysokiej dostępności na poziomie fragmentu określonym przez administratora.

Istnieją różne sposoby fragmentowania bazy danych:

  • Dzielenie na fragmenty zarządzane przez system: automatyczne dystrybuowanie między fragmentami przy użyciu partycjonowania
  • Fragmentowanie zdefiniowane przez użytkownika: umożliwia określenie mapowania danych na fragmenty, które dobrze sprawdza się, gdy istnieją wymagania prawne lub dotyczące lokalizacji danych
  • Fragmentowanie złożone: kombinacja fragmentowania zarządzanego przez system i zdefiniowanego przez użytkownika dla różnych przestrzeni fragmentów
  • Części tabeli: podobne do regularnej tabeli partycjonowanej

Aby uzyskać więcej informacji, zobacz Metody fragmentowania.

Baza danych podzielonych na fragmenty wygląda jak pojedyncza baza danych dla aplikacji i deweloperów. Podczas migracji do podzielonej na fragmenty bazy danych należy dokładnie zaplanować, aby zrozumieć, które tabele są zduplikowane i podzielone na fragmenty.

Zduplikowane tabele są przechowywane we wszystkich fragmentach, podczas gdy tabele podzielone na fragmenty są dystrybuowane między różne fragmenty. Zalecamy duplikowanie małych i wymiarowych tabel oraz dystrybuowanie/fragmentowanie tabel faktów. Dane można załadować do bazy danych podzielonej na fragmenty przy użyciu wykazu fragmentów jako centralnego koordynatora lub przez uruchomienie funkcji Data Pump na każdym fragmentie. Aby uzyskać więcej informacji, zobacz Migrowanie danych do bazy danych podzielonej na fragmenty.

Fragmentowanie oracle za pomocą funkcji Data Guard

Funkcja Oracle Data Guard może służyć do fragmentowania za pomocą metod fragmentowania zarządzanych przez system, zdefiniowanych przez użytkownika i złożonych metod fragmentowania.

Na poniższym diagramie przedstawiono architekturę referencyjną dla fragmentowania Oracle z funkcją Oracle Data Guard używaną do wysokiej dostępności każdego fragmentu. Diagram architektury przedstawia złożoną metodę fragmentowania. Diagram architektury prawdopodobnie różni się w przypadku aplikacji o różnych wymaganiach dotyczących lokalizacji danych, równoważenia obciążenia, wysokiej dostępności i odzyskiwania po awarii. Aplikacje mogą używać innej metody do fragmentowania. Fragmentowanie Oracle pozwala spełnić te wymagania i skalować je w poziomie i wydajnie, zapewniając te opcje. Podobną architekturę można nawet wdrożyć przy użyciu rozwiązania Oracle GoldenGate.

Diagram przedstawiający fragmentowanie bazy danych Oracle przy użyciu stref dostępności z brokerem usługi Data Guard — FSFO.

Fragmentowanie zarządzane przez system jest najłatwiejsze do skonfigurowania i zarządzania. Fragmentowanie zdefiniowane przez użytkownika lub złożone fragmentowanie jest odpowiednie w scenariuszach, w których dane i aplikacja są rozproszone geograficznie lub w scenariuszach, w których musisz mieć kontrolę nad replikacją każdego fragmentu.

W poprzedniej architekturze fragmentowanie złożone służy do geodystrybucjonowania danych i skalowania w poziomie warstw aplikacji. Fragmentowanie złożone jest kombinacją fragmentowania zarządzanego przez system i zdefiniowanego przez użytkownika, a tym samym zapewnia korzyści obu metod. W poprzednim scenariuszu dane są najpierw podzielone na fragmenty w wielu przestrzeniach fragmentów oddzielonych regionami. Następnie dane są dalej partycjonowane przy użyciu spójnego skrótu w wielu fragmentach w przestrzeni fragmentów.

Każda przestrzeń fragmentów zawiera wiele grup fragmentów. Każda grupa fragmentów ma wiele fragmentów i jest jednostką replikacji. Każda grupa fragmentów zawiera wszystkie dane w przestrzeni fragmentów. Grupy fragmentów A1 i B1 są podstawowymi grupami fragmentów, natomiast grupy fragmentów A2 i B2 są w stanie wstrzymania. Możesz zdecydować, że poszczególne fragmenty są jednostką replikacji, a nie grupą fragmentów.

W poprzedniej architekturze dyrektor globalny menedżera usług (GSM)/fragmentów jest wdrażany w każdej strefie dostępności w celu zapewnienia wysokiej dostępności. Zalecamy wdrożenie co najmniej jednego dyrektora GSM/fragmentu na centrum danych/regionie. Ponadto wystąpienie serwera aplikacji jest wdrażane w każdej strefie dostępności zawierającej grupę fragmentów. Ta konfiguracja umożliwia aplikacji zachowanie opóźnienia między serwerem aplikacji a bazą danych/grupą fragmentów. Jeśli baza danych ulegnie awarii, serwer aplikacji w tej samej strefie co baza danych rezerwowej może obsłużyć żądania po przejściu roli bazy danych. aplikacja systemu Azure Gateway i dyrektor fragmentu śledzą odpowiednio opóźnienia żądań i odpowiedzi oraz kierują żądania.

Z punktu widzenia aplikacji system kliencki wysyła żądanie do aplikacja systemu Azure Gateway lub innych technologii równoważenia obciążenia na platformie Azure, które przekierowuje żądanie do regionu znajdującego się najbliżej klienta. aplikacja systemu Azure Gateway obsługuje również sesje sticky, więc wszystkie żądania pochodzące z tego samego klienta są kierowane do tego samego serwera aplikacji. Serwer aplikacji używa buforowania połączeń w sterownikach dostępu do danych. Ta funkcja jest dostępna w sterownikach, takich jak JDBC, ODP.NET i OCI. Sterowniki mogą rozpoznawać klucze fragmentowania określone w ramach żądania. Klienci JDBC firmy Oracle mogą włączyć klientów aplikacji innych niż Oracle, takich jak Apache Tomcat i IIS, do pracy z fragmentowaniem Oracle. Aby uzyskać więcej informacji, zobacz Omówienie udostępnionej puli UCP na potrzeby fragmentowania bazy danych.

Podczas początkowego żądania serwer aplikacji łączy się z dyrektorem fragmentu w swoim regionie, aby uzyskać informacje dotyczące routingu dla fragmentu, do którego należy kierować żądanie. Na podstawie przekazanego klucza fragmentowania dyrektor kieruje serwer aplikacji do odpowiedniego fragmentu. Serwer aplikacji buforuje te informacje, tworząc mapę, a w przypadku kolejnych żądań pomija katalog fragmentów i kieruje żądania bezpośrednio do fragmentu.

Fragmentowanie Oracle za pomocą rozwiązania GoldenGate

Na poniższym diagramie przedstawiono architekturę referencyjną dla fragmentowania Oracle z rozwiązaniem Oracle GoldenGate w celu zapewnienia wysokiej dostępności każdego fragmentu w regionie. W przeciwieństwie do poprzedniej architektury ta architektura przedstawia wysoką dostępność tylko w jednym regionie świadczenia usługi Azure z wieloma strefami dostępności. Bazę danych o wysokiej dostępności z wieloma regionami można wdrożyć, podobnie jak w poprzednim przykładzie, przy użyciu rozwiązania Oracle GoldenGate.

Diagram przedstawiający fragmentowanie bazy danych Oracle przy użyciu stref dostępności z rozwiązaniem GoldenGate.

Poprzednia architektura referencyjna używa metody fragmentowania zarządzanego przez system do fragmentowania danych. Ponieważ replikacja Oracle GoldenGate jest wykonywana na poziomie fragmentu, połowa danych replikowanych do jednego fragmentu może być replikowana do innego fragmentu. Druga połowa może być replikowana do innego fragmentu.

Sposób replikacji danych zależy od współczynnika replikacji. Przy użyciu współczynnika replikacji dwóch elementów masz dwie kopie każdego fragmentu danych w trzech fragmentach w grupie fragmentów. Podobnie dzięki współczynnikowi replikacji trzech i trzech fragmentów w grupie fragmentów wszystkie dane w poszczególnych fragmentach są replikowane do każdego innego fragmentu w grupie fragmentów. Każdy fragment w grupie fragmentów może mieć inny współczynnik replikacji. Ta konfiguracja ułatwia efektywne definiowanie projektu wysokiej dostępności i odzyskiwania po awarii w grupie fragmentów i w wielu grupach fragmentów.

W poprzedniej architekturze grupa fragmentów A i grupa fragmentów B zawierają te same dane, ale znajdują się w różnych strefach dostępności. Jeśli obie grupy fragmentów A i Shardgroup B mają ten sam współczynnik replikacji trzech, każdy wiersz/fragment tabeli podzielonej na fragmenty jest replikowany sześć razy w dwóch grupach fragmentów. Jeśli grupa fragmentów A ma współczynnik replikacji trzech, a grupa fragmentów B ma współczynnik replikacji dwóch, każdy wiersz/fragment jest replikowany pięć razy w dwóch grupach fragmentów.

Ta konfiguracja uniemożliwia utratę danych, jeśli wystąpi awaria na poziomie wystąpienia lub na poziomie strefy dostępności. Warstwa aplikacji jest w stanie odczytywać dane i zapisywać je w poszczególnych fragmentach. Aby zminimalizować konflikty, fragmentowanie Oracle wyznacza fragment wzorca dla każdego zakresu wartości skrótu. Ta funkcja zapewnia, że żądania zapisu dla określonego fragmentu są kierowane do odpowiedniego fragmentu. Ponadto rozwiązanie Oracle GoldenGate zapewnia automatyczne wykrywanie konfliktów i rozwiązywanie problemów w celu obsługi wszelkich konfliktów, które mogą wystąpić. Aby uzyskać więcej informacji i ograniczeń dotyczących implementowania elementu GoldenGate z fragmentowaniem Oracle, zobacz Using Oracle GoldenGate with a Sharded Database (Używanie bazy danych Oracle GoldenGate z fragmentowaną bazą danych).

W poprzedniej architekturze dyrektor GSM/shard jest wdrażany w każdej strefie dostępności w celu zapewnienia wysokiej dostępności. Zalecamy wdrożenie co najmniej jednego dyrektora GSM/fragmentu dla każdego centrum danych lub regionu. Wystąpienie serwera aplikacji jest wdrażane w każdej strefie dostępności zawierającej grupę fragmentów. Ta konfiguracja umożliwia aplikacji zachowanie opóźnienia między serwerem aplikacji a bazą danych/grupą fragmentów. Jeśli baza danych ulegnie awarii, serwer aplikacji w tej samej strefie co baza danych rezerwowej może obsługiwać żądania po przejściu roli bazy danych. aplikacja systemu Azure Gateway i dyrektor fragmentu śledzą odpowiednio opóźnienia żądań i odpowiedzi oraz kierują żądania.

Z punktu widzenia aplikacji system kliencki wysyła żądanie do aplikacja systemu Azure Gateway lub innych technologii równoważenia obciążenia na platformie Azure, które przekierowuje żądanie do regionu znajdującego się najbliżej klienta. aplikacja systemu Azure Gateway obsługuje również sesje sticky, więc wszystkie żądania pochodzące z tego samego klienta są kierowane do tego samego serwera aplikacji. Serwer aplikacji używa buforowania połączeń w sterownikach dostępu do danych. Ta funkcja jest dostępna w sterownikach, takich jak JDBC, ODP.NET i OCI. Sterowniki mogą rozpoznawać klucze fragmentowania określone w ramach żądania. Klienci JDBC firmy Oracle mogą włączyć klientów aplikacji innych niż Oracle, takich jak Apache Tomcat i IIS, do pracy z fragmentowaniem Oracle.

Podczas początkowego żądania serwer aplikacji łączy się z dyrektorem fragmentu w swoim regionie, aby uzyskać informacje dotyczące routingu dla fragmentu, do którego należy kierować żądanie. Na podstawie przekazanego klucza fragmentowania dyrektor kieruje serwer aplikacji do odpowiedniego fragmentu. Serwer aplikacji buforuje te informacje, tworząc mapę, a w przypadku kolejnych żądań pomija katalog fragmentów i kieruje żądania bezpośrednio do fragmentu.

Stosowanie poprawek i konserwacja

Podczas wdrażania obciążeń Oracle na platformie Azure firma Microsoft zajmuje się wszystkimi poprawkami na poziomie systemu operacyjnego hosta. Firma Microsoft komunikuje wszelkie planowane konserwacje na poziomie systemu operacyjnego klientom z wyprzedzeniem. Dwa serwery z dwóch różnych stref dostępności nigdy nie są poprawiane jednocześnie. Aby uzyskać więcej informacji na temat konserwacji i stosowania poprawek maszyn wirtualnych, zobacz Opcje dostępności dla usługi Azure Virtual Machines.

Stosowanie poprawek systemu operacyjnego maszyny wirtualnej można zautomatyzować przy użyciu usługi Azure Automation Update Management. Stosowanie poprawek i utrzymywanie bazy danych Oracle można zautomatyzować i zaplanować przy użyciu usługi Azure Pipelines lub Azure Automation Update Management , aby zminimalizować przestoje. Aby uzyskać więcej informacji na temat ciągłego dostarczania i wdrożeń niebieski/zielony, zobacz Progresywne techniki ekspozycji.

Zagadnienia dotyczące architektury i projektowania

  • Rozważ użycie maszyny wirtualnej zoptymalizowanej pod kątem hiperwątków pamięci z ograniczonymi rdzeniami wirtualnymi dla maszyny wirtualnej bazy danych Oracle Database, aby zaoszczędzić na kosztach licencjonowania i zmaksymalizować wydajność. Aby uzyskać wydajność i dostępność, użyj wielu dysków w warstwie Premium lub Ultra (dysków zarządzanych).
  • W przypadku korzystania z dysków zarządzanych nazwa dysku/urządzenia może ulec zmianie po ponownym uruchomieniu. Zalecamy użycie identyfikatora UUID urządzenia zamiast nazwy, aby upewnić się, że instalacja będzie utrzymywana w sprite ponownego uruchamiania. Aby uzyskać więcej informacji, zobacz Dodawanie nowego systemu plików do /etc/fstab.
  • Strefy dostępności umożliwiają osiągnięcie wysokiej dostępności w regionie.
  • Rozważ użycie dysków w warstwie Ultra, jeśli są dostępne lub dyski w warstwie Premium dla bazy danych Oracle.
  • Rozważ skonfigurowanie rezerwowej bazy danych Oracle w innym regionie świadczenia usługi Azure przy użyciu funkcji Oracle Data Guard.
  • Rozważ użycie grup umieszczania w pobliżu, aby zmniejszyć opóźnienie między aplikacją a warstwą bazy danych.
  • Maksymalna przepustowość sieci maszyn wirtualnych platformy Azure jest (zwykle) wyższa niż maksymalna przepływność dysku w tej samej jednostce SKU. Możesz uzyskać większą przepływność na tej samej jednostce SKU maszyny wirtualnej lub użyć mniejszej jednostki SKU maszyny wirtualnej przy użyciu magazynu sieciowego o wysokiej wydajności, małych opóźnieniach, takich jak usługa Azure NetApp Files. dla bazy danych.
  • Skonfiguruj program Oracle Enterprise Manager na potrzeby zarządzania, monitorowania i rejestrowania.
  • Rozważ użycie automatycznego zarządzania magazynem Oracle w celu usprawnienia zarządzania magazynem dla bazy danych.
  • Wprowadzenie do funkcji Oracle Data Guard
  • Dostosuj kod aplikacji, aby dodać wzorce natywne dla chmury, które mogą pomóc aplikacji w bardziej odpornej kondycji. Rozważ wzorce, takie jak wzorzec ponawiania prób, wzorzec wyłącznika i inne zdefiniowane w przewodniku Wzorce projektowania chmury.

Następne kroki

Zapoznaj się z następującymi artykułami referencyjnymi oracle, które mają zastosowanie do danego scenariusza.