Share via

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

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.

Jeśli aplikacja zezwala na opóźnienie, rozważ skonfigurowanie wystąpienia usługi Data Guard Far Sync w innej strefie dostępności niż podstawowa baza danych Oracle. Dokładnie przetestuj konfigurację. Użyj trybu maksymalnej dostępności , aby skonfigurować synchroniczny transport plików ponownie do wystąpienia usługi Far Sync. Te pliki są następnie przenoszone asynchronicznie do bazy danych rezerwowej.

Aplikacja może nie zezwalać na utratę wydajności podczas konfigurowania wystąpienia usługi Far Sync w innej strefie dostępności w trybie maksymalnej dostępności (synchroniczny). Jeśli nie, możesz skonfigurować wystąpienie usługi Far Sync w tej samej strefie dostępności co podstawowa baza danych. Aby uzyskać dodatkową dostępność, rozważ skonfigurowanie wielu wystąpień usługi Far Sync w pobliżu podstawowej bazy danych i co najmniej jednego wystąpienia w pobliżu bazy danych rezerwowej, jeśli rola zostanie przeniesiona.

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.

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ą. Jeśli podstawowa baza danych jest niedostępna z powodu planowanej lub nieplanowanej awarii, funkcja Data Guard może przełączyć dowolną rezerwową bazę danych na rolę podstawową, minimalizując przestój.

W przypadku korzystania z funkcji Oracle Data Guard możesz również otworzyć pomocniczą bazę danych do celów tylko do odczytu. Ta konfiguracja nosi nazwę Active Data Guard. Oracle Database 12c wprowadziła funkcję o nazwie Wystąpienie usługi Data Guard Far Sync. To wystąpienie umożliwia skonfigurowanie konfiguracji zerowej utraty danych bazy danych Oracle bez konieczności naruszenia wydajności.

Uwaga

Funkcja Active Data Guard wymaga dodatkowego licencjonowania. Ta licencja jest również wymagana do korzystania z funkcji Far Sync. Skontaktuj się z przedstawicielem Oracle, aby omówić implikacje dotyczące licencjonowania.

Oracle Data Guard z trybem failover szybkiego uruchamiania

Funkcja Oracle Data Guard z trybem failover szybkiego uruchamiania (FSFO) może zapewnić większą odporność, konfigurując brokera na oddzielnej maszynie. Broker usługi Data Guard i pomocnicza baza danych uruchamiają obserwatora i obserwują podstawową bazę danych pod kątem przestojów. Takie podejście umożliwia również nadmiarowość w konfiguracji obserwatora usługi Data Guard.

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. Ta konfiguracja zapewnia dodatkową dostępność, jeśli jeden obserwator i dodatkowe środowisko bazy danych przestój. Broker usługi Data Guard jest lekki i może być hostowany na stosunkowo małej maszynie wirtualnej. 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).

Poniższy diagram jest zalecaną architekturą do korzystania z funkcji Oracle Data Guard na platformie Azure ze strefami dostępności. Ta architektura umożliwia uzyskanie umowy SLA dotyczącej czasu działania maszyny wirtualnej w wysokości 99,99%.

Diagram przedstawiający zalecaną architekturę do korzystania z funkcji Oracle Data Guard na platformie Azure ze strefami dostępności.

Na powyższym diagramie system klienta uzyskuje dostęp do aplikacji niestandardowej za pomocą zaplecza Oracle przy użyciu internetu. Fronton internetowy jest skonfigurowany w module równoważenia obciążenia. Fronton internetowy wywołuje odpowiedni serwer aplikacji w celu obsługi pracy. Serwer aplikacji wysyła zapytanie do podstawowej bazy danych Oracle. Baza danych Oracle została skonfigurowana przy użyciu maszyny wirtualnej zoptymalizowanej pod kątem pamięci hiperwątku z ograniczonymi rdzeniami wirtualnymi, aby zaoszczędzić na kosztach licencjonowania i zmaksymalizować wydajność. Wiele dysków w warstwie Premium lub Ultra (Dyski zarządzane) jest używanych do zapewnienia wydajności i wysokiej dostępności.

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 obserwatorzy FSFO są skonfigurowani w dwóch strefach dostępności w celu zainicjowania i przełączenie bazy danych w tryb failover do pomocniczej, gdy wystąpi awaria.

W tym przypadku można skonfigurować innych obserwatorów lub bazy danych rezerwowych w innej strefie dostępności, az 1, niż strefa pokazana w poprzedniej architekturze. Na koniec oracle Enterprise Manager (OEM) monitoruje bazy danych Oracle pod kątem czasu pracy i wydajności. Narzędzie OEM umożliwia również generowanie różnych raportów dotyczących wydajności i użycia.

W regionach, w których strefy dostępności nie są obsługiwane, możesz użyć zestawów dostępności do wdrożenia bazy danych Oracle Database w sposób wysoce dostępny. Zestawy dostępności umożliwiają osiągnięcie czasu pracy maszyny wirtualnej w wysokości 99,95%. Na poniższym diagramie przedstawiono architekturę referencyjną tego użycia:

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

Uwaga

  • Ponieważ wdrażane jest tylko jedno wystąpienie producenta OEM, nie trzeba umieszczać maszyny wirtualnej oracle Enterprise Manager w zestawie dostępności.
  • Dyski w warstwie Ultra nie są obecnie obsługiwane w konfiguracji zestawu dostępności.

Oracle Data Guard Far Sync

Usługa Oracle Data Guard Far Sync zapewnia możliwość ochrony przed utratą danych dla baz danych Oracle Database. Ta funkcja umożliwia ochronę przed utratą danych, jeśli maszyna bazy danych ulegnie awarii. Program Oracle Data Guard Far Sync musi być zainstalowany na oddzielnej maszynie wirtualnej. Far Sync to lekkie wystąpienie Oracle, które ma tylko plik kontrolny, plik haseł, plik spfile i dzienniki wstrzymania. Brak plików danych ani plików dziennika ponownego tworzenia.

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 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ę wysokiej dostępności korzystającą z funkcji Oracle Data Guard Far Sync:

Diagram przedstawiający bazę danych Oracle korzystającą ze stref dostępności z usługą Data Guard Far Sync & Broker — FSFO.

W poprzedniej architekturze istnieje wystąpienie usługi Far Sync wdrożone w tej samej strefie dostępności co wystąpienie bazy danych, aby zmniejszyć opóźnienie między tymi dwoma wystąpieniami. W przypadkach, gdy aplikacja jest wrażliwa na opóźnienia, rozważ wdrożenie bazy danych i wystąpienia usługi Far Sync w grupie umieszczania w pobliżu.

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

Diagram przedstawiający bazę danych Oracle Database korzystającą ze stref dostępności na potrzeby odzyskiwania po awarii za pomocą funkcji Data Guard Far Sync i Broker — FSFO.

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. 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. Platforma Oracle Universal Połączenie ion Pool (UCP) dla klientów JDBC może umożliwić klientom aplikacji innych niż Oracle, takim jak Apache Tomcat i IIS, pracować 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. Platforma Oracle Universal Połączenie ion Pool (UCP) dla klientów JDBC może umożliwić klientom aplikacji innych niż Oracle, takim jak Apache Tomcat i IIS, pracować 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.
  • Usługa Azure Pipelines umożliwia zarządzanie poprawkami i aktualizacjami bazy danych bez żadnych przestojów.
  • 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.