Samouczek: migrowanie serwera Oracle WebLogic Server do usługi Azure Virtual Machines z wysoką dostępnością i odzyskiwaniem po awarii

Artykuł
12/10/2024

W tym samouczku przedstawiono prosty i skuteczny sposób implementowania wysokiej dostępności i odzyskiwania po awarii (HA/DR) dla języka Java przy użyciu serwera Oracle WebLogic Server (WLS) na maszynach wirtualnych platformy Azure. Rozwiązanie ilustruje sposób osiągnięcia niskiego celu czasu odzyskiwania (RTO) i celu punktu odzyskiwania (RPO) przy użyciu prostej aplikacji jakarta EE opartej na bazie danych działającej na poziomie WLS. Wysoka dostępność/odzyskiwanie po awarii to złożony temat z wieloma możliwymi rozwiązaniami. Najlepsze rozwiązanie zależy od unikatowych wymagań. Aby uzyskać inne sposoby implementowania wysokiej dostępności/odzyskiwania po awarii, zobacz zasoby na końcu tego artykułu.

Z tego samouczka dowiesz się, jak wykonywać następujące czynności:

Użyj najlepszych rozwiązań zoptymalizowanych pod kątem platformy Azure, aby uzyskać wysoką dostępność i odzyskiwanie po awarii.
Skonfiguruj grupę trybu failover usługi Microsoft Azure SQL Database w sparowanych regionach.
Skonfiguruj sparowane klastry WLS na maszynach wirtualnych platformy Azure.
Konfigurowanie usługi Azure Traffic Manager.
Skonfiguruj klastry WLS pod kątem wysokiej dostępności i odzyskiwania po awarii.
Przetestuj tryb failover z podstawowego do pomocniczego.

Na poniższym diagramie przedstawiono utworzoną architekturę:

Usługa Azure Traffic Manager sprawdza kondycję regionów i kieruje ruch odpowiednio do warstwy aplikacji. Zarówno region podstawowy, jak i region pomocniczy mają pełne wdrożenie klastra WLS. Jednak tylko region podstawowy aktywnie obsługuje żądania sieciowe od użytkowników. Region pomocniczy jest pasywny i aktywowany w celu odbierania ruchu tylko wtedy, gdy region podstawowy doświadcza przerw w działaniu usługi. Usługa Azure Traffic Manager używa funkcji sprawdzania kondycji bramy aplikacja systemu Azure w celu zaimplementowania tego routingu warunkowego. Podstawowy klaster WLS jest uruchomiony, a klaster pomocniczy jest zamykany. Cel czasu odzyskiwania geograficznie w trybie failover warstwy aplikacji zależy od czasu uruchamiania maszyn wirtualnych i uruchamiania pomocniczego klastra ZABEZPIECZEŃ. Cel punktu odzyskiwania zależy od usługi Azure SQL Database, ponieważ dane są utrwalane i replikowane w grupie trybu failover usługi Azure SQL Database.

Warstwa bazy danych składa się z grupy trybu failover usługi Azure SQL Database z serwerem podstawowym i serwerem pomocniczym. Serwer podstawowy jest w trybie aktywnego odczytu i zapisu i jest połączony z podstawowym klastrem WLS. Serwer pomocniczy jest w trybie tylko do gotowości pasywnej i jest połączony z pomocniczym klastrem WLS. Tryb failover geograficznego przełącza wszystkie pomocnicze bazy danych w grupie na rolę podstawową. Aby uzyskać informacje na temat celu punktu odzyskiwania w trybie failover i celu punktu odzyskiwania usługi Azure SQL Database, zobacz Omówienie ciągłości działania.

Ten artykuł został napisany w usłudze Azure SQL Database, ponieważ artykuł opiera się na funkcjach wysokiej dostępności tej usługi. Inne opcje bazy danych są możliwe, ale należy wziąć pod uwagę funkcje wysokiej dostępności dowolnej wybranej bazy danych. Aby uzyskać więcej informacji, w tym informacje na temat optymalizowania konfiguracji źródeł danych na potrzeby replikacji, zobacz Konfigurowanie źródeł danych dla wdrożenia active-pasywnego oprogramowania Oracle Fusion Middleware.

Wymagania wstępne

Subskrypcja platformy Azure. Jeśli nie masz subskrypcji platformy Azure, przed rozpoczęciem utwórz bezpłatne konto.
Upewnij się, że masz Owner rolę lub Contributor role i User Access Administrator w subskrypcji. Przypisanie można sprawdzić, wykonując kroki opisane w temacie Wyświetlanie listy przypisań ról platformy Azure przy użyciu witryny Azure Portal.
Przygotuj maszynę lokalną z zainstalowanym systemem Windows, Linux lub macOS.
Instalowanie i konfigurowanie usługi Git.
Zainstaluj implementację środowiska Java SE w wersji 17 lub nowszej (na przykład kompilacja Microsoft OpenJDK).
Zainstaluj program Maven w wersji 3.9.3 lub nowszej.

Konfigurowanie grupy trybu failover usługi Azure SQL Database w sparowanych regionach

W tej sekcji utworzysz grupę trybu failover usługi Azure SQL Database w sparowanych regionach do użycia z klastrami i aplikacjami WLS. W późniejszej sekcji skonfigurujesz zabezpieczenia WLS do przechowywania danych sesji i danych dziennika transakcji (TLOG) do tej bazy danych. Ta praktyka jest zgodna z architekturą maksymalnej dostępności (MAA) firmy Oracle. Te wskazówki zawierają adaptację platformy Azure dla usługi MAA. Aby uzyskać więcej informacji na temat programu MAA, zobacz Architektura maksymalnej dostępności oracle.

Najpierw utwórz podstawową bazę danych Azure SQL Database, wykonując kroki w witrynie Azure Portal w przewodniku Szybki start: Tworzenie pojedynczej bazy danych — Azure SQL Database. Wykonaj kroki, które należy wykonać, ale nie uwzględniaj sekcji "Czyszczenie zasobów". Podczas pracy z artykułem skorzystaj z poniższych wskazówek, a następnie wróć do tego artykułu po utworzeniu i skonfigurowaniu bazy danych Azure SQL Database:

Po dotarciu do sekcji Tworzenie pojedynczej bazy danych wykonaj następujące kroki:
1. W kroku 4 tworzenia nowej grupy zasobów zapisz wartość nazwy grupy zasobów — na przykład myResourceGroup.
2. W kroku 5 dla nazwy bazy danych zapisz wartość Nazwa bazy danych — na przykład mySampleDatabase.
3. W kroku 6 tworzenia serwera wykonaj następujące kroki:
  1. Zapisz unikatową nazwę serwera — na przykład sqlserverprimary-ejb120623.
  2. W polu Lokalizacja wybierz pozycję (STANY USA) Wschodnie stany USA.
  3. W polu Metoda uwierzytelniania wybierz pozycję Użyj uwierzytelniania SQL.
  4. Zapisz wartość logowania administratora serwera — na przykład azureuser.
  5. Zapisz wartość Password ( Hasło ).
4. W kroku 8 w polu Środowisko obciążenia wybierz pozycję Programowanie. Przyjrzyj się opisowi i rozważ inne opcje obciążenia.
5. W kroku 11 w polu Nadmiarowość magazynu kopii zapasowych wybierz pozycję Magazyn kopii zapasowych lokalnie nadmiarowy. Rozważ inne opcje tworzenia kopii zapasowych. Aby uzyskać więcej informacji, zobacz sekcję Nadmiarowość magazynu kopii zapasowych w usłudze Azure SQL Database.
6. W kroku 14 w konfiguracji reguł zapory dla pozycji Zezwalaj usługom i zasobom platformy Azure na dostęp do tego serwera wybierz pozycję Tak.
Gdy dotrzesz do sekcji Wykonywanie zapytań dotyczących bazy danych, wykonaj następujące kroki:
1. W kroku 3 wprowadź informacje logowania administratora serwera uwierzytelniania SQL, aby się zalogować.
  
  Uwaga
  
  Jeśli logowanie nie powiedzie się z komunikatem o błędzie podobnym do klienta z adresem IP "xx.xx.xx.xx.xx" nie może uzyskać dostępu do serwera, wybierz pozycję Allowlist IP xx.xx.xx.xx na serwerze <nazwa-serwera-sql na> końcu komunikatu o błędzie. Poczekaj, aż reguły zapory serwera zakończą aktualizowanie, a następnie ponownie wybierz przycisk OK .
2. Po uruchomieniu przykładowego zapytania w kroku 5 wyczyść edytor i utwórz tabele.

Wprowadź następujące zapytanie, aby utworzyć schemat dla TLOG.

create table TLOG_msp1_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table TLOG_msp2_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table TLOG_msp3_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table wl_servlet_sessions (wl_id VARCHAR(100) NOT NULL, wl_context_path VARCHAR(100) NOT NULL, wl_is_new CHAR(1), wl_create_time DECIMAL(20), wl_is_valid CHAR(1), wl_session_values VARBINARY(MAX), wl_access_time DECIMAL(20), wl_max_inactive_interval INTEGER, PRIMARY KEY (wl_id, wl_context_path));

Po pomyślnym uruchomieniu powinien zostać wyświetlony komunikat Zapytanie powiodło się: wiersze, których dotyczy problem: 0.

Te tabele baz danych są używane do przechowywania dzienników transakcji (TLOG) i danych sesji dla klastrów i aplikacji WLS. Aby uzyskać więcej informacji, zobacz Using a JDBC TLOG Store and Using a Database for Persistent Storage (JDBC Persistence) (Używanie magazynu TLOG JDBC i Używanie bazy danych dla magazynu trwałego (trwałość JDBC).

Następnie utwórz grupę trybu failover usługi Azure SQL Database, wykonując kroki opisane w temacie Konfigurowanie grupy trybu failover dla usługi Azure SQL Database. Potrzebne są tylko następujące sekcje: Tworzenie grupy trybu failover i Testowanie planowanego przejścia w tryb failover. Wykonaj następujące kroki, wykonując czynności opisane w artykule, a następnie wróć do tego artykułu po utworzeniu i skonfigurowaniu grupy trybu failover usługi Azure SQL Database:

Po dotarciu do sekcji Tworzenie grupy trybu failover wykonaj następujące kroki:
1. W kroku 5 tworzenia grupy trybu failover wybierz opcję utworzenia nowego serwera pomocniczego, a następnie wykonaj następujące kroki:
  1. Wprowadź i zapisz nazwę grupy trybu failover — na przykład nazwa grupy trybu failover-ejb120623.
  2. Wprowadź i zapisz unikatową nazwę serwera — na przykład sqlserversecondary-ejb120623.
  3. Wprowadź ten sam administrator serwera i hasło co serwer podstawowy.
  4. W polu Lokalizacja wybierz inny region niż region używany dla podstawowej bazy danych.
  5. Upewnij się, że wybrano opcję Zezwalaj usługom platformy Azure na dostęp do serwera .
2. W kroku 5 konfigurowania baz danych w grupie wybierz bazę danych utworzoną na serwerze podstawowym — na przykład mySampleDatabase.
Po wykonaniu wszystkich kroków w sekcji Testowanie planowanego trybu failover pozostaw otwartą stronę grupy trybu failover i użyj jej do testowania trybu failover klastrów WLS później.

Uwaga

Ten artykuł zawiera instrukcje dotyczące tworzenia pojedynczej bazy danych Azure SQL Database z uwierzytelnianiem SQL w celu uproszczenia, ponieważ konfiguracja wysokiej dostępności i odzyskiwania po awarii, na której koncentruje się ten artykuł, jest już bardzo złożona. Bezpieczniejszą praktyką jest użycie uwierzytelniania microsoft Entra dla usługi Azure SQL do uwierzytelniania połączenia serwera bazy danych. Aby uzyskać informacje na temat konfigurowania połączenia bazy danych z uwierzytelnianiem firmy Microsoft Entra, zobacz Konfiguracja połączenia z bazą danych bez hasła dla aplikacji Java na serwerze Oracle WebLogic.

Konfigurowanie sparowanych klastrów ZLS na maszynach wirtualnych platformy Azure

W tej sekcji utworzysz dwa klastry WLS na maszynach wirtualnych platformy Azure przy użyciu oferty Oracle WebLogic Server Server na maszynach wirtualnych platformy Azure. Klaster w regionie Wschodnie stany USA jest podstawowy i jest skonfigurowany jako aktywny klaster później. Klaster w regionie Zachodnie stany USA jest pomocniczy i jest skonfigurowany jako klaster pasywny później.

Konfigurowanie podstawowego klastra WLS

Najpierw otwórz ofertę Oracle WebLogic Server Cluster on Azure VMs (Klaster serwera Oracle WebLogic na maszynach wirtualnych platformy Azure) w przeglądarce i wybierz pozycję Utwórz. Powinno zostać wyświetlone okienko Podstawy oferty.

Aby wypełnić okienko Podstawy , wykonaj następujące kroki:

Upewnij się, że wartość wyświetlana dla subskrypcji jest taka sama, która ma role wymienione w sekcji wymagań wstępnych.
Należy wdrożyć ofertę w pustej grupie zasobów. W polu Grupa zasobów wybierz pozycję Utwórz nową i wypełnij unikatową wartość dla grupy zasobów — na przykład wls-cluster-eastus-ejb120623.
W obszarze Szczegóły wystąpienia w obszarze Region wybierz pozycję Wschodnie stany USA.
W obszarze Poświadczenia dla maszyn wirtualnych i WebLogic podaj hasło dla konta administratora maszyny wirtualnej i administratora serwera WebLogic, odpowiednio. Zapisz nazwę użytkownika i hasło dla administratora serwera WebLogic. Aby uzyskać lepsze zabezpieczenia, rozważ użycie klucza publicznego SSH jako typu uwierzytelniania maszyny wirtualnej.
Pozostaw wartości domyślne dla innych pól.
Wybierz przycisk Dalej , aby przejść do okienka Konfiguracja protokołu TLS/SSL.

Pozostaw wartości domyślne w okienku Konfiguracja protokołu TLS/SSL, wybierz pozycję Dalej, aby przejść do okienka aplikacja systemu Azure Brama, a następnie wykonaj następujące kroki.

W obszarze Połącz z bramą aplikacja systemu Azure? wybierz pozycję Tak.
W obszarze Wybierz odpowiednią opcję certyfikatu TLS/SSL wybierz pozycję Wygeneruj certyfikat z podpisem własnym.
Wybierz przycisk Dalej , aby przejść do okienka Sieć .

Wszystkie pola powinny zostać wstępnie wypełnione wartościami domyślnymi w okienku Sieć . Aby zapisać konfigurację sieci, wykonaj następujące kroki:

Wybierz pozycję Edytuj sieć wirtualną. Zapisz przestrzeń adresową sieci wirtualnej — na przykład 10.1.4.0/23.
Wybierz wls-subnet , aby edytować podsieć. W obszarze Szczegóły podsieci zapisz adres początkowy i rozmiar podsieci — na przykład 10.1.5.0 i /28.
Jeśli wprowadzisz jakiekolwiek modyfikacje, zapisz zmiany.
Wróć do okienka Sieć .
Wybierz przycisk Dalej , aby przejść do okienka Baza danych .

W poniższych krokach pokazano, jak wypełnić okienko Baza danych :

W obszarze Połącz z bazą danych? wybierz pozycję Tak.
W obszarze Wybierz typ bazy danych wybierz pozycję Microsoft SQL Server (Obsługa połączenia bez hasła) .
W polu Nazwa JNDI wprowadź wartość jdbc/WebLogicCafeDB.
W przypadku parametrów połączenia źródła danych zastąp symbole zastępcze wartościami zapisanymi w poprzedniej sekcji podstawowej bazy danych SQL Database — na przykład jdbc:sqlserver://sqlserverprimary-ejb120623.database.windows.net:1433; database=mySampleDatabase.
W polu Globalny protokół transakcji wybierz pozycję Brak.
W polu Nazwa użytkownika bazy danych zastąp symbole zastępcze wartościami zapisanymi w poprzedniej sekcji podstawowej usługi SQL Database — na przykład azureuser@sqlserverprimary-ejb120623.
Wprowadź hasło logowania administratora serwera zapisane wcześniej w polu Hasło bazy danych. Wprowadź tę samą wartość w polu Potwierdź hasło.
Pozostaw wartości domyślne dla innych pól.
Wybierz pozycję Przejrzyj i utwórz.
Poczekaj na pomyślne zakończenie ostatniej weryfikacji, a następnie wybierz pozycję Utwórz.

Uwaga

Ten artykuł zawiera instrukcje dotyczące nawiązywania połączenia z bazą danych Azure SQL Database przy zastosowaniu uwierzytelniania SQL, ponieważ uproszczenie tego aspektu jest korzystne ze względu na to, iż konfiguracja wysokiej dostępności i odzyskiwania po awarii, na której skupia się ten artykuł, jest już bardzo złożona. Bezpieczniejszą praktyką jest użycie uwierzytelniania microsoft Entra dla usługi Azure SQL do uwierzytelniania połączenia serwera bazy danych. Aby uzyskać informacje na temat konfigurowania połączenia z bazą danych za pomocą uwierzytelniania Microsoft Entra, zobacz Konfigurowanie połączeń z bazą danych bez hasła dla aplikacji Java na Oracle WebLogic Server.

Po pewnym czasie powinna zostać wyświetlona strona Wdrażanie , na której jest w toku wdrażanie.

Uwaga

Jeśli podczas ostatecznej weryfikacji wystąpią jakiekolwiek problemy, rozwiąż je i spróbuj ponownie.

W zależności od warunków sieciowych i innych działań w wybranym regionie wdrożenie może potrwać do 50 minut. Następnie powinien zostać wyświetlony tekst Wdrożenie zostało ukończone na stronie wdrożenia.

W międzyczasie można skonfigurować pomocniczy klaster WLS równolegle.

Konfigurowanie pomocniczego klastra WLS

Wykonaj te same kroki, jak w sekcji Konfigurowanie podstawowego klastra WLS w celu skonfigurowania pomocniczego klastra ZLS w regionie Zachodnie stany USA, z wyjątkiem następujących różnic:

W okienku Podstawy wykonaj następujące czynności:
1. W polu Grupa zasobów wybierz pozycję Utwórz nową i wypełnij inną unikatową wartość dla grupy zasobów — na przykład wls-cluster-westtus-ejb120623.
2. W obszarze Szczegóły wystąpienia w polu Region wybierz pozycję Zachodnie stany USA.
W okienku Sieć wykonaj następujące czynności:
1. W polu Edytuj sieć wirtualną wprowadź tę samą przestrzeń adresową sieci wirtualnej co podstawowy klaster WLS — na przykład 10.1.4.0/23.
  
  Uwaga
  
  Powinien zostać wyświetlony komunikat ostrzegawczy podobny do następującego: przestrzeń adresowa "10.1.4.0/23" (10.1.4.0 - 10.1.5.255)" nakłada się z przestrzenią adresową "10.1.4.0/23" (10.1.4.0 - 10.1.5.255)" sieci wirtualnej "wls-vnet". Sieci wirtualne z nakładającymi się przestrzeniami adresowymi nie mogą być równorzędne. Jeśli zamierzasz połączyć te sieci wirtualne, zmień przestrzeń adresową "10.1.4.0/23 (10.1.4.0 – 10.1.5.255)". Ten komunikat można zignorować, ponieważ potrzebne są dwa klastry WLS z tą samą konfiguracją sieci.
2. W polu wls-subnetwprowadź ten sam adres początkowy i rozmiar podsieci co podstawowy klaster WLS — na przykład 10.1.5.0 i /28.
W okienku Baza danych wykonaj następujące czynności:
1. W przypadku parametrów połączenia źródła danych zastąp symbole zastępcze wartościami zapisanymi w poprzedniej sekcji pomocniczej bazy danych SQL Database — na przykład jdbc:sqlserver://sqlserversecondary-ejb120623.database.windows.net:1433; database=mySampleDatabase.
2. W polu Nazwa użytkownika bazy danych zastąp symbole zastępcze wartościami zapisanymi w poprzedniej sekcji pomocniczej usługi SQL Database — na przykład azureuser@sqlserversecondary-ejb120623.

Dublowanie ustawień sieci dla dwóch klastrów

W fazie wznowienia oczekujących transakcji w pomocniczym klastrze WLS po przejściu w tryb failover usługa WLS sprawdza własność magazynu TLOG. Aby pomyślnie przejść sprawdzanie, wszystkie serwery zarządzane w klastrze pomocniczym muszą mieć ten sam prywatny adres IP co klaster podstawowy.

W tej sekcji przedstawiono sposób dublowania ustawień sieci z klastra podstawowego do klastra pomocniczego.

Najpierw wykonaj następujące kroki, aby skonfigurować ustawienia sieciowe klastra podstawowego po zakończeniu wdrażania:

W okienku Przegląd strony Wdrażanie wybierz pozycję Przejdź do grupy zasobów.
Wybierz interfejs adminVM_NIC_with_pub_ipsieciowy .
1. W obszarze Ustawienia wybierz pozycję Konfiguracje adresów IP.
2. Wybierz opcję ipconfig1.
3. W obszarze Ustawienia prywatnego adresu IP wybierz pozycję Statyczny dla pozycji Alokacja. Zapisz na bok prywatny adres IP.
4. Wybierz pozycję Zapisz.
Wróć do grupy zasobów podstawowego klastra WLS, a następnie powtórz krok 3 dla interfejsów sieciowych mspVM1_NIC_with_pub_ip, mspVM2_NIC_with_pub_ipi mspVM3_NIC_with_pub_ip.
Poczekaj na ukończenie wszystkich aktualizacji. Możesz wybrać ikonę powiadomień w witrynie Azure Portal, aby otworzyć okienko Powiadomienia na potrzeby monitorowania stanu.
Wróć do grupy zasobów podstawowego klastra WLS, a następnie skopiuj nazwę zasobu z typem Prywatny punkt końcowy — na przykład 7e8c8bsaep. Użyj tej nazwy, aby znaleźć pozostały interfejs sieciowy — na przykład 7e8c8c8bsaep.nic.c0438c1a-1936-4b62-864c-6792eec3741a. Wybierz go i wykonaj powyższe kroki, aby uzyskać jego prywatny adres IP.

Następnie wykonaj następujące kroki, aby skonfigurować ustawienia sieciowe klastra pomocniczego po zakończeniu wdrażania:

W okienku Przegląd strony Wdrażanie wybierz pozycję Przejdź do grupy zasobów.
W przypadku interfejsów sieciowych adminVM_NIC_with_pub_ip, , mspVM1_NIC_with_pub_ipmspVM2_NIC_with_pub_ipi mspVM3_NIC_with_pub_ipwykonaj powyższe kroki, aby zaktualizować alokację prywatnego adresu IP do statycznej.
Poczekaj na ukończenie wszystkich aktualizacji.
W przypadku interfejsów sieciowych mspVM1_NIC_with_pub_ip, mspVM2_NIC_with_pub_ipi mspVM3_NIC_with_pub_ipwykonaj powyższe kroki, ale zaktualizuj prywatny adres IP do tej samej wartości używanej w klastrze podstawowym. Przed przejściem do następnego zaczekaj na ukończenie bieżącej aktualizacji interfejsu sieciowego.

Uwaga

Nie można zmienić prywatnego adresu IP interfejsu sieciowego będącego częścią prywatnego punktu końcowego. Aby łatwo dublować prywatne adresy IP interfejsów sieciowych dla serwerów zarządzanych, rozważ zaktualizowanie prywatnego adresu IP dla adminVM_NIC_with_pub_ip adresu IP, który nie jest używany. W zależności od alokacji prywatnych adresów IP w dwóch klastrach może być konieczne zaktualizowanie prywatnego adresu IP w klastrze podstawowym.

W poniższej tabeli przedstawiono przykład dublowania ustawień sieci dla dwóch klastrów:

Klaster	Interfejs sieciowy	Prywatny adres IP (przed)	Prywatny adres IP (po)	Sekwencja aktualizacji
Podstawowe	`7e8c8bsaep.nic.c0438c1a-1936-4b62-864c-6792eec3741a`	`10.1.5.4`	`10.1.5.4`
Podstawowe	`adminVM_NIC_with_pub_ip`	`10.1.5.7`	`10.1.5.7`
Podstawowe	`mspVM1_NIC_with_pub_ip`	`10.1.5.5`	`10.1.5.5`
Podstawowe	`mspVM2_NIC_with_pub_ip`	`10.1.5.8`	`10.1.5.9`	1
Podstawowe	`mspVM3_NIC_with_pub_ip`	`10.1.5.6`	`10.1.5.6`
Pomocniczy	`1696b0saep.nic.2e19bf46-9799-4acc-b64b-a2cd2f7a4ee1`	`10.1.5.8`	`10.1.5.8`
Pomocniczy	`adminVM_NIC_with_pub_ip`	`10.1.5.5`	`10.1.5.4`	100
Pomocniczy	`mspVM1_NIC_with_pub_ip`	`10.1.5.7`	`10.1.5.5`	5
Pomocniczy	`mspVM2_NIC_with_pub_ip`	`10.1.5.6`	`10.1.5.9`	2
Pomocniczy	`mspVM3_NIC_with_pub_ip`	`10.1.5.4`	`10.1.5.6`	3

Sprawdź zestaw prywatnych adresów IP dla wszystkich serwerów zarządzanych, który składa się z puli zaplecza aplikacja systemu Azure Gateway wdrożonej w każdym klastrze. Jeśli zostanie zaktualizowana, wykonaj następujące kroki, aby odpowiednio zaktualizować pulę zaplecza usługi aplikacja systemu Azure Gateway:

Otwórz grupę zasobów klastra.
Znajdź zasób myAppGateway z typem Application Gateway. Wybierz go, aby go otworzyć.
W sekcji Ustawienia wybierz pozycję Pule zaplecza, a następnie wybierz pozycję myGatewayBackendPool.
Zmień wartości obiektów docelowych zaplecza na zaktualizowany prywatny adres IP lub adresy, a następnie wybierz pozycję Zapisz. Zaczekaj na jego zakończenie.
W sekcji Ustawienia wybierz pozycję Sondy kondycji, a następnie wybierz pozycję HTTPhealthProbe.
Upewnij się, że chcę przetestować kondycję zaplecza przed dodaniem sondy kondycji, a następnie wybierz pozycję Testuj. Powinna zostać wyświetlona wartość Stan puli zaplecza jest oznaczona jako w dobrej kondycji myGatewayBackendPool . Jeśli tak nie jest, sprawdź, czy prywatne adresy IP są aktualizowane zgodnie z oczekiwaniami, a maszyny wirtualne są uruchomione, a następnie ponownie przetestuj sondę kondycji. Przed kontynuowaniem należy rozwiązać ten problem.

W poniższym przykładzie pula zaplecza usługi aplikacja systemu Azure Gateway dla każdego klastra jest aktualizowana:

Klaster	pula zaplecza bramy aplikacja systemu Azure	Elementy docelowe zaplecza (przed)	Elementy docelowe zaplecza (po)
Podstawowe	`myGatewayBackendPool`	(`10.1.5.5`, `10.1.5.8`, `10.1.5.6`)	(`10.1.5.5`, `10.1.5.9`, `10.1.5.6`)
Pomocniczy	`myGatewayBackendPool`	(`10.1.5.7`, `10.1.5.6`, `10.1.5.4`)	(`10.1.5.5`, `10.1.5.9`, `10.1.5.6`)

Aby zautomatyzować dublowanie ustawień sieciowych, rozważ użycie interfejsu wiersza polecenia platformy Azure. Aby uzyskać więcej informacji, zobacz Wprowadzenie do interfejsu wiersza polecenia platformy Azure.

Weryfikowanie wdrożeń klastrów

W każdym klastrze wdrożono bramę aplikacja systemu Azure i serwer administracyjny usługi WLS. Brama aplikacja systemu Azure działa jako moduł równoważenia obciążenia dla wszystkich serwerów zarządzanych w klastrze. Serwer administracyjny usługi WLS udostępnia konsolę sieci Web na potrzeby konfiguracji klastra.

Wykonaj następujące kroki, aby sprawdzić, czy brama aplikacja systemu Azure i konsola administracyjna usługi WLS w każdym klastrze działają przed przejściem do następnego kroku:

Wróć do strony Wdrożenie , a następnie wybierz pozycję Dane wyjściowe.
Skopiuj wartość właściwości appGatewayURL. Dołącz ciąg weblogic/ready , a następnie otwórz ten adres URL na nowej karcie przeglądarki. Powinna zostać wyświetlona pusta strona bez żadnego komunikatu o błędzie. Jeśli tego nie zrobisz, przed kontynuowaniem musisz rozwiązać problem i rozwiązać go.
Skopiuj i zapisz wartość właściwości adminConsole. Otwórz go na nowej karcie przeglądarki. Powinna zostać wyświetlona strona logowania konsoli administracyjnej serwera WebLogic. Zaloguj się do konsoli przy użyciu nazwy użytkownika i hasła dla administratora webLogic zapisanego wcześniej. Jeśli nie możesz się zalogować, przed kontynuowaniem musisz rozwiązać problem i rozwiązać ten problem.

Wykonaj poniższe kroki, aby uzyskać adres IP bramy aplikacja systemu Azure dla każdego klastra. Te wartości są używane podczas konfigurowania usługi Azure Traffic Manager później.

Otwórz grupę zasobów, w której wdrożono klaster — na przykład wybierz pozycję Przegląd , aby wrócić do okienka Przegląd na stronie wdrożenia. Następnie wybierz pozycję Przejdź do grupy zasobów.
Znajdź zasób gwip o typie Publiczny adres IP, a następnie wybierz go, aby go otworzyć. Wyszukaj pole Adres IP i zapisz jego wartość.

Konfigurowanie usługi Azure Traffic Manager

W tej sekcji utworzysz usługę Azure Traffic Manager do dystrybucji ruchu do publicznych aplikacji w globalnych regionach świadczenia usługi Azure. Podstawowy punkt końcowy wskazuje bramę aplikacja systemu Azure w podstawowym klastrze WLS, a pomocniczy punkt końcowy wskazuje bramę aplikacja systemu Azure w pomocniczym klastrze WLS.

Utwórz profil usługi Azure Traffic Manager, wykonując czynności opisane w przewodniku Szybki start: tworzenie profilu usługi Traffic Manager przy użyciu witryny Azure Portal. Pomiń sekcję Wymagania wstępne . Potrzebujesz tylko następujących sekcji: Tworzenie profilu usługi Traffic Manager, dodawanie punktów końcowych usługi Traffic Manager i testowanie profilu usługi Traffic Manager. Wykonaj poniższe kroki, przechodząc przez te sekcje, a następnie wróć do tego artykułu po utworzeniu i skonfigurowaniu usługi Azure Traffic Manager.

Gdy dotrzesz do sekcji Tworzenie profilu usługi Traffic Manager, w kroku 2 Tworzenie profilu usługi Traffic Managerwykonaj następujące kroki:
1. Zapisz na boku unikatową nazwę profilu Traffic Manager jako dla - na przykład tmprofile-ejb120623.
2. Zapisz nową nazwę grupy zasobów dla grupy zasobów — na przykład .
Po dotarciu do sekcji Dodawanie punktów końcowych usługi Traffic Manager wykonaj następujące kroki:
1. Wykonaj tę dodatkową akcję po kroku Wybierz profil z wyników wyszukiwania.
  1. W obszarze Ustawienia wybierz pozycję Konfiguracja.
  2. W przypadku czasu wygaśnięcia (TTL) dns wprowadź wartość 10.
  3. W obszarze Ustawienia monitora punktu końcowego w polu Ścieżka wprowadź / weblogic/ready.
  4. W sekcji Ustawienia szybkiego przełączania awaryjnego punktu końcowegowykorzystaj następujące wartości:
    - W polu Sondowanie wewnętrzne wprowadź wartość 10.
    - W polu Tolerowana liczba awarii wprowadź wartość 3.
    - W przypadku limitu czasu sondy 5.
  5. Wybierz pozycję Zapisz. Zaczekaj na jego zakończenie.
2. W kroku 4 dodawania podstawowego punktu końcowego myPrimaryEndpointwykonaj następujące kroki:
  1. W polu Typ zasobu docelowego wybierz pozycję Publiczny adres IP.
  2. Wybierz listę rozwijaną Wybierz publiczny adres IP i wprowadź adres IP usługi Application Gateway wdrożonej w klastrze WLS Wschodnie stany USA, który został zapisany wcześniej. Powinien zostać wyświetlony jeden wpis dopasowany. Wybierz go jako publiczny adres IP.
3. W kroku 6 dodawania zapasowego/drugorzędnego punktu końcowego myFailoverEndpointwykonaj następujące kroki:
  1. W polu Typ zasobu docelowego wybierz pozycję Publiczny adres IP.
  2. Wybierz listę rozwijaną Wybierz publiczny adres IP i wprowadź adres IP usługi Application Gateway wdrożonej w klastrze Zachodnie Stany USA 2 WLS, który wcześniej zapisałeś. Powinien zostać wyświetlony jeden wpis dopasowany. Wybierz go jako publiczny adres IP.
4. Poczekaj chwilę. Wybierz pozycję Odśwież, dopóki wartość stanu monitora dla obu punktów końcowych będzie w trybie online.
Po dotarciu do sekcji Testowanie profilu usługi Traffic Manager wykonaj następujące czynności:
1. W sekcji Sprawdź nazwę DNS, w kroku 3 zapisz nazwę DNS profilu usługi Traffic Manager — na przykład http://tmprofile-ejb120623.trafficmanager.net.
2. W sekcji Wyświetl usługę Traffic Manager w akcjiwykonaj następujące kroki:
  1. W kroku 1 i 3 dołącz ciąg /weblogic/ready do nazwy DNS profilu usługi Traffic Manager w przeglądarce internetowej — na przykład http://tmprofile-ejb120623.trafficmanager.net/weblogic/ready. Powinna zostać wyświetlona pusta strona bez żadnego komunikatu o błędzie.
  2. Po wykonaniu wszystkich kroków upewnij się, że włączysz podstawowy punkt końcowy, odwołując się do kroku 2, ale zastąp element Disabled wartością Enabled. Następnie wróć do strony Punkty końcowe .

Teraz masz zarówno punkty końcowe włączone , jak i online w profilu usługi Traffic Manager. Pozostaw otwartą stronę i użyj jej do monitorowania stanu punktu końcowego później.

Konfigurowanie klastrów WLS pod kątem wysokiej dostępności i odzyskiwania po awarii

W tej sekcji skonfigurujesz klastry WLS pod kątem wysokiej dostępności i odzyskiwania po awarii.

Przygotowywanie przykładowej aplikacji

W tej sekcji utworzysz i spakujesz przykładową aplikację CRUD Java/JakartaEE, którą później wdrożysz i uruchomisz w klastrach WLS na potrzeby testowania trybu failover.

Aplikacja używa trwałości sesji JDBC serwera WebLogic do przechowywania danych sesji HTTP. Źródło jdbc/WebLogicCafeDB danych przechowuje dane sesji w celu włączenia trybu failover i równoważenia obciążenia w klastrze serwerów WebLogic. Konfiguruje schemat trwałości w celu utrwalania danych coffee aplikacji w tym samym źródle jdbc/WebLogicCafeDBdanych.

Wykonaj następujące kroki, aby skompilować i spakować przykład:

Użyj następujących poleceń, aby sklonować przykładowe repozytorium i wyewidencjonować tag odpowiadający temu artykułowi:
```
git clone https://github.com/Azure-Samples/azure-cafe.git
cd azure-cafe
git checkout 20231206
```
Jeśli zostanie wyświetlony komunikat o Detached HEADusłudze , można bezpiecznie zignorować.
Użyj następujących poleceń, aby przejść do przykładowego katalogu, a następnie skompilować i spakować przykład:
```
cd weblogic-cafe
mvn clean package
```

Po pomyślnym wygenerowaniu pakietu można go znaleźć w folderze parent-path-to-your-local-clone</azure-café/weblogic-café/target/weblogic-café.war> Jeśli nie widzisz pakietu, przed kontynuowaniem musisz rozwiązać problem i rozwiązać ten problem.

Wdrażanie przykładowej aplikacji

Teraz wykonaj następujące kroki, aby wdrożyć przykładową aplikację w klastrach, począwszy od klastra podstawowego:

Otwórz konto adminConsole klastra na nowej karcie przeglądarki internetowej. Zaloguj się do konsoli administracyjnej serwera WebLogic przy użyciu nazwy użytkownika i hasła zapisanego wcześniej administratora serwera WebLogic.
Znajdź pozycję Wdrożenia wlsd>struktury>domeny w okienku nawigacji. Wybierz pozycję Wdrożenia.
Wybierz pozycję >, wybierz pozycję Wybierz plik. Wybierz wcześniej przygotowany plik weblogic-café.war.
Wybierz przycisk Dalej>Dalej.> Wybierz cluster1 z opcją Wszystkie serwery w klastrze dla celów wdrożenia. Wybierz pozycje Next>Finish (Dalej, Zakończ). Wybierz pozycję Aktywuj zmiany.
Przejdź do karty Kontrolka i wybierz pozycję weblogic-cafe z tabeli wdrożeń. Wybierz pozycję Rozpocznij od opcji > Poczekaj chwilę i odśwież stronę, aż zobaczysz, że stan wdrożenia weblogic-cafe jest aktywny. Przejdź do karty Monitorowanie i sprawdź, czy katalog główny kontekstu wdrożonej aplikacji to /weblogic-café. Pozostaw otwartą konsolę administracyjną usługi WLS, aby później można było jej użyć do dalszej konfiguracji.

Powtórz te same kroki w konsoli administracyjnej serwera WebLogic, ale w przypadku klastra pomocniczego w regionie Zachodnie stany USA.

Aktualizowanie hosta frontonu

Wykonaj poniższe kroki, aby klastry WLS wiedziały o usłudze Azure Traffic Manager. Ponieważ usługa Azure Traffic Manager jest punktem wejścia dla żądań użytkowników, zaktualizuj hosta frontonu klastra serwera WebLogic do nazwy DNS profilu usługi Traffic Manager, począwszy od klastra podstawowego.

Upewnij się, że zalogowano się do konsoli administracyjnej serwera WebLogic.
Przejdź do obszaru Klastry środowiska>wlsd>struktury>domeny w okienku nawigacji. Wybierz pozycję Klastry.
Wybierz cluster1 z tabeli klastrów.
Wybierz pozycję Blokuj i edytuj>protokół HTTP. Usuń bieżącą wartość hosta frontonu i wprowadź nazwę DNS zapisanego wcześniej profilu usługi Traffic Manager bez wiodącego http:// — na przykład tmprofile-ejb120623.trafficmanager.net. Wybierz pozycję Zapisz>aktywuj zmiany.

Powtórz te same kroki w konsoli administracyjnej serwera WebLogic, ale w przypadku klastra pomocniczego w regionie Zachodnie stany USA.

Konfigurowanie magazynu dzienników transakcji

Następnie skonfiguruj magazyn dzienników transakcji JDBC dla wszystkich zarządzanych serwerów klastrów, począwszy od klastra podstawowego. Ta praktyka została opisana w temacie Używanie plików dziennika transakcji do odzyskiwania transakcji.

Wykonaj następujące kroki w podstawowym klastrze WLS w regionie Wschodnie stany USA:

Upewnij się, że zalogowano się do konsoli administracyjnej serwera WebLogic.
Przejdź do obszaru Serwery środowiska> wlsd>struktury>domeny w okienku nawigacji. Wybierz pozycję Serwery.
Powinny zostać wyświetlone serwery msp1, msp2i msp3 wymienione w tabeli serwerów.
Wybierz pozycję msp1>Usługi>Blokuj i edytuj. W obszarze Magazyn dzienników transakcji wybierz pozycję JDBC.
W polu Typ>źródła danych wybierz pozycję .jdbc/WebLogicCafeDB
Upewnij się, że wartość pola Nazwa prefiksu jest TLOG_msp1_, która jest wartością domyślną. Jeśli wartość jest inna, zmień ją na TLOG_msp1_.
Wybierz pozycję Zapisz.
Wybierz pozycję >msp2 i powtórz te same kroki, z tą różnicą, że wartość domyślna w polu Nazwa prefiksu jest TLOG_msp2_.
Wybierz pozycję msp3 i powtórz te same kroki, z tą różnicą, że wartość domyślna nazwy prefiksu to TLOG_msp3_.
Wybierz pozycję Aktywuj zmiany.

Powtórz te same kroki w konsoli administracyjnej serwera WebLogic, ale w przypadku klastra pomocniczego w regionie Zachodnie stany USA.

Uruchom ponownie zarządzane serwery klastra podstawowego

Następnie wykonaj następujące kroki, aby ponownie uruchomić wszystkie serwery zarządzane klastra podstawowego, aby zmiany zaczęły obowiązywać:

Upewnij się, że zalogowano się do konsoli administracyjnej serwera WebLogic.
Przejdź do obszaru Serwery środowiska> wlsd>struktury>domeny w okienku nawigacji. Wybierz pozycję Serwery.
Wybierz kartę Kontrolka. Wybierz pozycję msp1, msp2i msp3. Wybierz pozycję Zamknij z opcją > Wybierz ikonę odświeżania. Zaczekaj, aż wartość Stan ostatniej akcji to ZADANIE UKOŃCZONE. Powinna zostać wyświetlona wartość State (Stan ) dla wybranych serwerów to SHUTDOWN (ZAMKNIJ). Ponownie wybierz ikonę odświeżania, aby zatrzymać monitorowanie stanu.
Wybierz pozycję msp1, msp2i msp3 ponownie. Wybierz pozycję Rozpocznij>tak. Wybierz ikonę odświeżania. Zaczekaj, aż wartość Stan ostatniej akcji to ZADANIE UKOŃCZONE. Powinna zostać wyświetlona wartość Stan dla wybranych serwerów jest uruchomiona. Ponownie wybierz ikonę odświeżania, aby zatrzymać monitorowanie stanu.

Zatrzymywanie maszyn wirtualnych w klastrze pomocniczym

Teraz wykonaj następujące kroki, aby zatrzymać wszystkie maszyny wirtualne w klastrze pomocniczym, aby uczynić je pasywnym:

Otwórz witrynę główną witryny Azure Portal na nowej karcie przeglądarki, a następnie wybierz pozycję Wszystkie zasoby. W polu Filtruj dla dowolnego pola... wprowadź nazwę grupy zasobów, w której wdrożono klaster pomocniczy — na przykład wls-cluster-westus-ejb120623.
Wybierz pozycję Typ równa się wszystkim , aby otworzyć filtr Typ . W polu Wartość wprowadź wartość Maszyna wirtualna. Powinien zostać wyświetlony jeden wpis dopasowany. Wybierz ją dla pozycji Wartość. Wybierz Zastosuj. Powinny zostać wyświetlone 4 maszyny wirtualne, w tym adminVM, mspVM1, mspVM2i mspVM3.
Wybierz, aby otworzyć każdą z maszyn wirtualnych. Wybierz pozycję Zatrzymaj i potwierdź dla każdej maszyny wirtualnej.
Wybierz ikonę powiadomień w witrynie Azure Portal, aby otworzyć okienko Powiadomienia .
Monitoruj zdarzenie Zatrzymywanie maszyny wirtualnej dla każdej maszyny wirtualnej do momentu, aż wartość zostanie pomyślnie zatrzymana maszyna wirtualna. Pozostaw otwartą stronę, aby można było jej użyć do testu trybu failover później.

Teraz przejdź do karty przeglądarki, na której monitorujesz stan punktów końcowych usługi Traffic Manager. Odśwież stronę, aż zobaczysz, że punkt końcowy myFailoverEndpoint ma obniżoną sprawność , a punkt końcowy myPrimaryEndpoint jest w trybie online.

Uwaga

Rozwiązanie wysokiej dostępności/odzyskiwania po awarii gotowe do produkcji prawdopodobnie będzie chciało osiągnąć niższy cel czasu odzyskiwania przez pozostawienie uruchomionych maszyn wirtualnych, ale tylko zatrzymanie oprogramowania ZLS działającego na maszynach wirtualnych. Następnie w przypadku przejścia w tryb failover maszyny wirtualne będą już uruchomione, a uruchomienie oprogramowania WLS zajmie mniej czasu. W tym artykule wybrano zatrzymanie maszyn wirtualnych, ponieważ oprogramowanie wdrożone przez klaster oracle WebLogic Server na maszynach wirtualnych platformy Azure automatycznie uruchamia oprogramowanie ZLS po uruchomieniu maszyn wirtualnych.

Weryfikowanie aplikacji

Ponieważ klaster podstawowy jest uruchomiony i działa, działa jako aktywny klaster i obsługuje wszystkie żądania użytkowników kierowane przez profil usługi Traffic Manager.

Otwórz nazwę DNS profilu usługi Azure Traffic Manager na nowej karcie przeglądarki, dołączając katalog główny kontekstu /weblogic-café wdrożonej aplikacji — na przykład http://tmprofile-ejb120623.trafficmanager.net/weblogic-cafe. Utwórz nową kawę o nazwie i cenie — na przykład Kawa 1 z ceną 10. Ten wpis jest utrwalany zarówno w tabeli danych aplikacji, jak i w tabeli sesji bazy danych. Widoczny interfejs użytkownika powinien być podobny do poniższego zrzutu ekranu:

Jeśli interfejs użytkownika nie wygląda podobnie, przed kontynuowaniem rozwiąż problem i rozwiąż go.

Pozostaw otwartą stronę, aby można było jej użyć do testowania trybu failover później.

Testowanie trybu failover z podstawowego do pomocniczego

Aby przetestować tryb failover, ręcznie przełączysz podstawowy serwer bazy danych i klaster do pomocniczego serwera bazy danych i klastra, a następnie wróć po awarii przy użyciu witryny Azure Portal w tej sekcji.

Przechodzenie w tryb failover do lokacji dodatkowej

Najpierw wykonaj następujące kroki, aby zamknąć maszyny wirtualne w klastrze podstawowym:

Znajdź nazwę grupy zasobów, w której wdrożono podstawowy klaster WLS — na przykład wls-cluster-eastus-ejb120623. Następnie wykonaj kroki opisane w sekcji Zatrzymywanie maszyn wirtualnych w klastrze pomocniczym, ale zmień docelową grupę zasobów na podstawowy klaster ZLS, aby zatrzymać wszystkie maszyny wirtualne w tym klastrze.
Przejdź do karty przeglądarki usługi Traffic Manager, odśwież stronę, aż zobaczysz, że wartość stanu monitora punktu końcowego myPrimaryEndpoint stanie się obniżona.
Przejdź do karty przeglądarki przykładowej aplikacji i odśwież stronę. Powinien zostać wyświetlony limit czasu bramy 504 lub 502 — zła brama , ponieważ żaden z punktów końcowych nie jest dostępny.

Następnie wykonaj następujące kroki, aby przejść w tryb failover usługi Azure SQL Database z serwera podstawowego do serwera pomocniczego:

Przejdź do karty przeglądarki grupy trybu failover usługi Azure SQL Database.
Wybierz pozycję Tryb failover>Tak.
Zaczekaj na jego zakończenie.

Następnie wykonaj następujące kroki, aby uruchomić wszystkie serwery w klastrze pomocniczym:

Przejdź do karty przeglądarki, na której zatrzymano wszystkie maszyny wirtualne w klastrze pomocniczym.
Wybierz maszynę wirtualną adminVM. Wybierz Start.
Monitoruj zdarzenie Uruchamianie maszyny wirtualnej w adminVM okienku Powiadomienia i poczekaj, aż wartość stanie się Uruchomiona maszyna wirtualna.
Przejdź do karty przeglądarki konsoli administracyjnej serwera WebLogic dla klastra pomocniczego, a następnie odśwież stronę do momentu wyświetlenia strony powitalnej na potrzeby logowania.
Wróć do karty przeglądarki, na której są wyświetlane wszystkie maszyny wirtualne w klastrze pomocniczym. Dla maszyn wirtualnych mspVM1, mspVM2i mspVM3wybierz każdy z nich, aby go otworzyć, a następnie wybierz pozycję Uruchom.
W przypadku maszyn wirtualnych mspVM1, mspVM2i mspVM3monitoruj zdarzenie Uruchamianie maszyny wirtualnej w okienku Powiadomienia i poczekaj, aż wartości staną się uruchomioną maszyną wirtualną.

Na koniec wykonaj następujące kroki, aby zweryfikować przykładową aplikację po tym, jak punkt końcowy myFailoverEndpoint znajduje się w stanie Online :

Przejdź do karty przeglądarki usługi Traffic Manager, a następnie odśwież stronę, aż zobaczysz, że wartość Stanu monitora punktu końcowego myFailoverEndpoint przechodzi w stan Online .
Przejdź do karty przeglądarki przykładowej aplikacji i odśwież stronę. Te same dane powinny być widoczne w tabeli danych aplikacji i tabeli sesji wyświetlanej w interfejsie użytkownika, jak pokazano na poniższym zrzucie ekranu:

Jeśli nie obserwujesz tego zachowania, może to być spowodowane tym, że aktualizacja dns przez usługę Traffic Manager zajmuje więcej czasu, aby wskazywała lokację trybu failover. Problem może być również taki, że przeglądarka buforowała wynik rozpoznawania nazw DNS wskazujący witrynę, która zakończyła się niepowodzeniem. Poczekaj chwilę i odśwież stronę ponownie.

Uwaga

Gotowe do produkcji rozwiązanie wysokiej dostępności/odzyskiwania po awarii będzie uwzględniać ciągłe kopiowanie konfiguracji zabezpieczeń na poziomie podstawowym do klastrów pomocniczych zgodnie z regularnym harmonogramem. Aby uzyskać informacje na temat tego, jak to zrobić, zapoznaj się z dokumentacją oracle na końcu tego artykułu.

Aby zautomatyzować tryb failover, rozważ użycie alertów dotyczących metryk usługi Traffic Manager i usługi Azure Automation. Aby uzyskać więcej informacji, zobacz sekcję Alerty dotyczące metryk usługi Traffic Manager metryk i alertów usługi Traffic Manager oraz Używanie alertu do wyzwalania elementu Runbook usługi Azure Automation.

Powrót po awarii do lokacji głównej

Wykonaj te same kroki w sekcji Tryb failover w lokacji dodatkowej, aby powrócić po awarii do lokacji głównej, w tym do serwera bazy danych i klastra, z wyjątkiem następujących różnic:

Najpierw zamknij maszyny wirtualne w klastrze pomocniczym. Powinien zostać wyświetlony komunikat o obniżonej myFailoverEndpoint punktu końcowego.
Następnie przełącz usługę Azure SQL Database w tryb failover z serwera pomocniczego do serwera podstawowego.
Następnie uruchom wszystkie serwery w klastrze podstawowym.
Na koniec sprawdź przykładową aplikację po przejściu do punktu końcowego myPrimaryEndpoint w trybie online.

Czyszczenie zasobów

Jeśli nie zamierzasz nadal korzystać z klastrów WLS i innych składników, wykonaj następujące kroki, aby usunąć grupy zasobów, aby wyczyścić zasoby używane w tym samouczku:

Wprowadź nazwę grupy zasobów serwerów usługi Azure SQL Database (na przykład myResourceGroup) w polu wyszukiwania w górnej części witryny Azure Portal i wybierz dopasowaną grupę zasobów z wyników wyszukiwania.
Wybierz pozycję Usuń grupę zasobów.
W polu Wprowadź nazwę grupy zasobów, aby potwierdzić usunięcie, wprowadź nazwę grupy zasobów.
Wybierz Usuń.
Powtórz kroki 1–4 dla grupy zasobów usługi Traffic Manager — na przykład myResourceGroupTM1.
Powtórz kroki 1–4 dla grupy zasobów podstawowego klastra WLS — na przykład wls-cluster-eastus-ejb120623.
Powtórz kroki 1–4 dla grupy zasobów pomocniczego klastra WLS — na przykład wls-cluster-westus-ejb120623.

Następne kroki

W tym samouczku skonfigurujesz rozwiązanie wysokiej dostępności/odzyskiwania po awarii składające się z warstwy infrastruktury aplikacji aktywne-pasywne z warstwą bazy danych aktywne-pasywne i w którym obie warstwy obejmują dwa geograficznie różne lokacje. W pierwszej lokacji zarówno warstwa infrastruktury aplikacji, jak i warstwa bazy danych są aktywne. W drugiej lokacji domena pomocnicza jest zamknięta, a pomocnicza baza danych jest w stanie wstrzymania.

Zapoznaj się z następującymi odwołaniami, aby uzyskać więcej opcji tworzenia rozwiązań wysokiej dostępności/odzyskiwania po awarii i uruchamiania zabezpieczeń WLS na platformie Azure:

Rozwiązania odzyskiwania po awarii dla produktów Oracle Fusion Middleware

Dokumentacja dotycząca niezawodności platformy Azure

Tworzenie rozwiązań w celu zapewnienia wysokiej dostępności

Automatyczne przechodzenie w tryb failover przy użyciu usługi Azure Traffic Manager

Dowiedz się więcej o programie Oracle WebLogic na maszynach wirtualnych platformy Azure

Dowiedz się więcej o aplikacji Oracle WebLogic w usłudze AKS