Självstudie: Migrera Oracle WebLogic Server till virtuella Azure-datorer med hög tillgänglighet och haveriberedskap

Den här självstudien visar ett enkelt och effektivt sätt att implementera hög tillgänglighet och haveriberedskap (HA/DR) för Java med hjälp av Oracle WebLogic Server (WLS) på virtuella Azure-datorer (VM). Lösningen visar hur du uppnår ett rto-mål (Low Recovery Time Objective) och Recovery Point Objective (RPO) med hjälp av ett enkelt databasdrivet Jakarta EE-program som körs på WLS. HA/DR är ett komplext ämne med många möjliga lösningar. Den bästa lösningen beror på dina unika krav. Andra sätt att implementera HA/DR finns i resurserna i slutet av den här artikeln.

I den här självstudien lär du dig att:

Följande diagram illustrerar arkitekturen som du skapar:

Azure Traffic Manager kontrollerar hälsotillståndet för dina regioner och dirigerar trafiken enligt programnivån. Både den primära regionen och den sekundära regionen har en fullständig distribution av WLS-klustret. Det är dock bara den primära regionen som aktivt hanterar nätverksbegäranden från användarna. Den sekundära regionen är passiv och aktiverad för att endast ta emot trafik när den primära regionen drabbas av avbrott i tjänsten. Azure Traffic Manager använder hälsokontrollfunktionen i Azure Application Gateway för att implementera den här villkorliga routningen. Det primära WLS-klustret körs och det sekundära klustret stängs av. RTO för geo-redundans på programnivån beror på tiden för att starta virtuella datorer och köra det sekundära WLS-klustret. RPO:et är beroende av Azure SQL Database eftersom data sparas och replikeras i Azure SQL Database-redundansgruppen.

Databasnivån består av en Azure SQL Database-redundansgrupp med en primär server och en sekundär server. Den primära servern är i aktivt läs- och skrivläge och är ansluten till det primära WLS-klustret. Den sekundära servern är i passivt redo läge och ansluten till det sekundära WLS-klustret. En geo-redundansväxlar alla sekundära databaser i gruppen till den primära rollen. Information om RPO för geo-redundans och RTO för Azure SQL Database finns i Översikt över affärskontinuitet.

Den här artikeln skrevs med Azure SQL Database-tjänsten eftersom artikeln förlitar sig på ha-funktionerna (hög tillgänglighet) för tjänsten. Andra databasval är möjliga, men du måste överväga ha-funktionerna i vilken databas du än väljer. Mer information, inklusive information om hur du optimerar konfigurationen av datakällor för replikering, finns i Konfigurera datakällor för Oracle Fusion Middleware Active-Passive Deployment.

Förutsättningar

• En Azure-prenumeration. Om du inte har en Azure-prenumeration kan du skapa ettkostnadsfritt konto innan du börjar.
• Kontrollera att du har rollen Owner eller rollerna Contributor och User Access Administrator i prenumerationen. Du kan verifiera tilldelningen genom att följa stegen i Lista Azure-rolltilldelningar med hjälp av Azure-portalen.
• Förbered en lokal dator med Windows, Linux eller macOS installerat.
• Installera och konfigurera Git.
• Installera en Java SE-implementering, version 17 eller senare (till exempel Microsoft-versionen av OpenJDK).
• Installera Maven, version 3.9.3 eller senare.

Konfigurera en Azure SQL Database-redundansgrupp i parkopplade regioner

I det här avsnittet skapar du en Azure SQL Database-redundansgrupp i parkopplade regioner för användning med dina WLS-kluster och din app. I ett senare avsnitt konfigurerar du WLS för att lagra dess sessionsdata och transaktionsloggdata (TLOG) i den här databasen. Den här metoden överensstämmer med Oracles arkitektur för maximal tillgänglighet (MAA). Den här vägledningen ger en Azure-anpassning för MAA. Mer information om MAA finns i Oracles arkitektur för maximal tillgänglighet.

Skapa först den primära Azure SQL Database genom att följa stegen i Azure-portalen i Snabbstart: Skapa en enkel databas – Azure SQL Database. Följ stegen upp till, men inte inkludera, avsnittet "Rensa resurser". Använd följande anvisningar när du går igenom artikeln och gå sedan tillbaka till den här artikeln när du har skapat och konfigurerat Azure SQL Database:

1. När du kommer till avsnittet Skapa en enkel databas använder du följande steg:

   1. I steg 4 för att skapa en ny resursgrupp sparar du värdet Resursgruppnamn , till exempel myResourceGroup.
   2. I steg 5 för databasnamn sparar du värdet Databasnamn , till exempel mySampleDatabase.
   3. I steg 6 för att skapa servern använder du följande steg:
      1. Spara åt sidan det unika servernamnet – till exempel sqlserverprimary-ejb120623.
      2. För Plats väljer du (USA) USA, östra.
      3. Som Autentiseringsmetod väljer du Använd SQL-autentisering.
      4. Spara åt sidan inloggningsvärdet serveradministratör – till exempel azureuser.
      5. Spara lösenordet åt sidan.
   4. I steg 8 väljer du Utveckling för Arbetsbelastningsmiljö. Titta på beskrivningen och överväg andra alternativ för din arbetsbelastning.
   5. I steg 11 för Redundans för säkerhetskopieringslagring väljer du Lokalt redundant lagring av säkerhetskopiering. Överväg andra alternativ för dina säkerhetskopior. Mer information finns i avsnittet Säkerhetskopieringslagringsredundans i Automatiserade säkerhetskopieringar i Azure SQL Database.
   6. I steg 14 går du till konfigurationen brandväggsregler och väljer Ja för Tillåt Azure-tjänster och resurser att komma åt den här servern.

2. När du kommer till avsnittet Fråga databasen använder du följande steg:

   1. I steg 3 anger du inloggningsinformation för sql-autentiseringsserveradministratören för att logga in.

      Kommentar

      Om inloggningen misslyckas med ett felmeddelande som liknar Klienten med IP-adressen "xx.xx.xx.xx.xx" inte har behörighet att komma åt servern väljer du Tillåtlista IP xx.xx.xx.xx på servern <your-sqlserver-name> i slutet av felmeddelandet. Vänta tills serverns brandväggsregler har uppdaterats och välj sedan OK igen.

   2. När du har kört exempelfrågan i steg 5 rensar du redigeraren och skapar tabeller.

Ange följande fråga för att skapa ett schema för 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));

Efter en lyckad körning bör du se meddelandet Fråga lyckades: Berörda rader: 0.

Dessa databastabeller används för att lagra transaktionsloggar (TLOG) och sessionsdata för dina WLS-kluster och din app. Mer information finns i Using a JDBC TLOG Store and Using a Database for Persistent Storage (JDBC Persistence).

Skapa sedan en Azure SQL Database-redundansgrupp genom att följa stegen i Azure-portalen i Konfigurera en redundansgrupp för Azure SQL Database. Du behöver bara följande avsnitt: Skapa redundansgrupp och Testa planerad redundans. Följ stegen nedan när du går igenom artikeln och gå sedan tillbaka till den här artikeln när du har skapat och konfigurerat redundansgruppen för Azure SQL Database:

1. När du kommer till avsnittet Skapa redundansgrupp använder du följande steg:

   1. I steg 5 för att skapa redundansgruppen väljer du alternativet för att skapa en ny sekundär server och använder sedan följande steg:
      1. Ange och spara namnet på redundansklustergruppen , till exempel failovergroupname-ejb120623.
      2. Ange och spara det unika servernamnet åt sidan – till exempel sqlserversecondary-ejb120623.
      3. Ange samma serveradministratör och lösenord som din primära server.
      4. För Plats väljer du en annan region än den som du använde för den primära databasen.
      5. Kontrollera att Tillåt Azure-tjänster att komma åt servern är valt.
   2. I steg 5 för att konfigurera databaserna i gruppen väljer du den databas som du skapade på den primära servern, till exempel mySampleDatabase.

2. När du har slutfört alla steg i avsnittet Testa planerad redundans håller du sidan redundansgrupp öppen och använder den för redundanstestet för WLS-kluster senare.

Konfigurera parade WLS-kluster på virtuella Azure-datorer

I det här avsnittet skapar du två WLS-kluster på virtuella Azure-datorer med hjälp av Oracle WebLogic Server-klustret på virtuella Azure-datorer . Klustret i USA, östra är primärt och konfigureras som det aktiva klustret senare. Klustret i USA, västra är sekundärt och konfigureras som passivt kluster senare.

Konfigurera det primära WLS-klustret

Öppna först Oracle WebLogic Server-klustret på virtuella Azure-datorer i webbläsaren och välj Skapa. Du bör se fönstret Grundläggande i erbjudandet.

Använd följande steg för att fylla i fönstret Grundläggande :

1. Kontrollera att värdet som visas för Prenumeration är samma som har de roller som anges i avsnittet för förhandskrav.
2. Du måste distribuera erbjudandet i en tom resursgrupp. I fältet Resursgrupp väljer du Skapa ny och fyller i ett unikt värde för resursgruppen , till exempel wls-cluster-eastus-ejb120623.
3. Under Instansinformation väljer du USA, östra för Region.
4. Under Autentiseringsuppgifter för virtuella datorer och WebLogic anger du ett lösenord för administratörskontot för den virtuella datorn respektive WebLogic-administratören. Spara användarnamnet och lösenordet för WebLogic-administratören åt sidan.
5. Lämna standardvärdena för andra fält.
6. Välj Nästa för att gå till fönstret TLS/SSL-konfiguration .

Lämna standardvärdena i fönstret TLS/SSL-konfiguration , välj Nästa för att gå till fönstret Azure Application Gateway och använd sedan följande steg.

1. För Anslut till Azure Application Gateway? väljer du Ja.
2. För Alternativet Välj önskat TLS/SSL-certifikat väljer du Generera ett självsignerat certifikat.
3. Välj Nästa för att gå till fönstret Nätverk .

Du bör se alla fält ifyllda i förväg med standardvärdena i fönstret Nätverk . Använd följande steg för att spara nätverkskonfigurationen:

1. Välj Redigera virtuellt nätverk. Spara adressutrymmet för det virtuella nätverket , till exempel 10.1.4.0/23.

   

2. Välj wls-subnet för att redigera undernätet. Under Undernätsinformation sparar du startadressen och undernätets storlek , till exempel 10.1.5.0 och /28.

   

3. Spara ändringarna om du gör några ändringar.

4. Gå tillbaka till fönstret Nätverk .

5. Välj Nästa för att gå till fönstret Databas .

Följande steg visar hur du fyller i fönstret Databas :

1. Välj Ja för Anslut till databas?.
2. För Välj databastyp väljer du Microsoft SQL Server (Stöd för lösenordslös anslutning) .
3. För JNDI-namn anger du jdbc/WebLogicCafeDB.
4. För DataSource-anslutningssträng ersätter du platshållarna med de värden som du sparade åt sidan i föregående avsnitt för den primära SQL Database – till exempel jdbc:sqlserver://sqlserverprimary-ejb120623.database.windows.net:1433; database=mySampleDatabase.
5. För Globalt transaktionsprotokoll väljer du Ingen.
6. För databasanvändarnamn ersätter du platshållarna med de värden som du sparade åt sidan i föregående avsnitt för den primära SQL Database , till exempel azureuser@sqlserverprimary-ejb120623.
7. Ange inloggningslösenordet för serveradministratören som du sparade tidigare för Databaslösenord. Ange samma värde för Bekräfta lösenord.
8. Lämna standardvärdena för de andra fälten.
9. Välj Granska + skapa.
10. Vänta tills den slutgiltiga verifieringen har körts... har slutförts och välj sedan Skapa.

Efter ett tag bör du se sidan Distribution där distribution pågår visas.

Beroende på nätverksförhållanden och annan aktivitet i den valda regionen kan distributionen ta upp till 50 minuter att slutföra. Därefter bör du se texten Distributionen är klar visas på distributionssidan.

Under tiden kan du konfigurera det sekundära WLS-klustret parallellt.

Konfigurera det sekundära WLS-klustret

Följ samma steg i som i avsnittet Konfigurera det primära WLS-klustret för att konfigurera det sekundära WLS-klustret i regionen USA, västra, förutom följande skillnader:

1. I fönstret Grundläggande använder du följande steg:

   1. I fältet Resursgrupp väljer du Skapa ny och fyller i ett annat unikt värde för resursgruppen – till exempel wls-cluster-westtus-ejb120623.
   2. Under Instansinformation väljer du USA, västra för Region.

2. I fönstret Nätverk använder du följande steg:

   1. För Redigera virtuellt nätverk anger du samma adressutrymme för det virtuella nätverket som ditt primära WLS-kluster, till exempel 10.1.4.0/23.

      Kommentar

      Du bör se ett varningsmeddelande som liknar följande: Adressutrymmet "10.1.4.0/23 (10.1.4.0 – 10.1.5.255)" överlappar med adressutrymmet "10.1.4.0/23 (10.1.4.0– 10.1.5.255)" för det virtuella nätverket "wls-vnet". Virtuella nätverk med överlappande adressutrymme kan inte peer-kopplas. Om du tänker peerkoppla dessa virtuella nätverk ändrar du adressutrymmet "10.1.4.0/23 (10.1.4.0 – 10.1.5.255)". Du kan ignorera det här meddelandet eftersom du behöver två WLS-kluster med samma nätverkskonfiguration.

   2. För wls-subnetanger du samma startadress och undernätsstorlek som ditt primära WLS-kluster, till exempel 10.1.5.0 och /28.

3. I fönstret Databas använder du följande steg:

   1. För DataSource-anslutningssträng ersätter du platshållarna med de värden som du sparade åt sidan i föregående avsnitt för den sekundära SQL Database – till exempel jdbc:sqlserver://sqlserversecondary-ejb120623.database.windows.net:1433; database=mySampleDatabase.
   2. För Databasanvändarnamn ersätter du platshållarna med de värden som du sparade åt sidan i föregående avsnitt för den sekundära SQL Database, till exempel azureuser@sqlserversecondary-ejb120623.

Spegla nätverksinställningarna för de två klustren

Under fasen för att återuppta väntande transaktioner i det sekundära WLS-klustret efter en redundansväxling kontrollerar WLS ägarskapet för TLOG-lagret. Om du vill klara kontrollen måste alla hanterade servrar i det sekundära klustret ha samma privata IP-adress som det primära klustret.

Det här avsnittet visar hur du speglar nätverksinställningarna från det primära klustret till det sekundära klustret.

Använd först följande steg för att konfigurera nätverksinställningar för det primära klustret när distributionen är klar:

1. I fönstret Översikt på sidan Distribution väljer du Gå till resursgrupp.

2. Välj nätverksgränssnittet adminVM_NIC_with_pub_ip.

   1. Under Inställningar väljer du IP-konfigurationer.
   2. Välj ipconfig1.
   3. Under Inställningar för privat IP-adress väljer du Statisk för Allokering. Spara den privata IP-adressen åt sidan.
   4. Välj Spara.

3. Gå tillbaka till resursgruppen för det primära WLS-klustret och upprepa sedan steg 3 för nätverksgränssnitten mspVM1_NIC_with_pub_ip, mspVM2_NIC_with_pub_ipoch mspVM3_NIC_with_pub_ip.

4. Vänta tills alla uppdateringar har slutförts. Du kan välja meddelandeikonen i Azure-portalen för att öppna fönstret Meddelanden för statusövervakning.

   

5. Gå tillbaka till resursgruppen för det primära WLS-klustret och kopiera sedan namnet på resursen med typen Privat slutpunkt – till exempel 7e8c8bsaep. Använd det namnet för att hitta det återstående nätverksgränssnittet , till exempel 7e8c8bsaep.nic.c0438c1a-1936-4b62-864c-6792eec3741a. Välj den och följ föregående steg för att hämta dess privata IP-adress.

Använd sedan följande steg för att konfigurera nätverksinställningarna för det sekundära klustret när distributionen är klar:

1. I fönstret Översikt på sidan Distribution väljer du Gå till resursgrupp.

2. För nätverksgränssnitten adminVM_NIC_with_pub_ipföljer du mspVM1_NIC_with_pub_ipmspVM2_NIC_with_pub_ipmspVM3_NIC_with_pub_ipstegen ovan för att uppdatera den privata IP-adressallokeringen till Static.

3. Vänta tills alla uppdateringar har slutförts.

4. För nätverksgränssnitten mspVM1_NIC_with_pub_ipföljer du mspVM2_NIC_with_pub_ipmspVM3_NIC_with_pub_ipstegen ovan, men uppdaterar den privata IP-adressen till samma värde som används med det primära klustret. Vänta tills den aktuella uppdateringen av nätverksgränssnittet har slutförts innan du fortsätter till nästa.

   Kommentar

   Du kan inte ändra den privata IP-adressen för nätverksgränssnittet som ingår i en privat slutpunkt. Du kan enkelt spegla de privata IP-adresserna för nätverksgränssnitt för hanterade servrar genom att uppdatera den privata IP-adressen för adminVM_NIC_with_pub_ip till en IP-adress som inte används. Beroende på allokeringen av privata IP-adresser i dina två kluster kan du också behöva uppdatera den privata IP-adressen i det primära klustret.

Följande tabell visar ett exempel på spegling av nätverksinställningarna för två kluster:

Kontrollera uppsättningen privata IP-adresser för alla hanterade servrar, som består av serverdelspoolen för Azure Application Gateway som du distribuerade i varje kluster. Om den uppdateras använder du följande steg för att uppdatera Azure Application Gateway-serverdelspoolen i enlighet med detta:

1. Öppna resursgruppen för klustret.
2. Hitta resursen myAppGateway med typen Programgateway. Välj den för att öppna den.
3. I avsnittet Inställningar väljer du Serverdelspooler och sedan myGatewayBackendPool.
4. Ändra värdena för serverdelens mål med den uppdaterade privata IP-adressen eller adresserna och välj sedan Spara. Vänta tills den är klar.
5. I avsnittet Inställningar väljer du Hälsoavsökningar och sedan HTTPhealthProbe.
6. Kontrollera att jag vill testa serverdelshälsan innan du lägger till hälsoavsökningen och välj sedan Testa. Du bör se att statusvärdet för serverdelspoolen myGatewayBackendPool är markerat som felfritt. Om det inte är det kontrollerar du om privata IP-adresser uppdateras som förväntat och de virtuella datorerna körs och testar sedan hälsoavsökningen igen. Du måste felsöka och lösa problemet innan du fortsätter.

I följande exempel uppdateras Azure Application Gateway-serverdelspoolen för varje kluster:

Om du vill automatisera nätverksinställningarnas spegling bör du överväga att använda Azure CLI. Mer information finns i Komma igång med Azure CLI.

Verifiera distributionerna av klustren

Du distribuerade en Azure Application Gateway och en WLS-administratörsserver i varje kluster. Azure Application Gateway fungerar som lastbalanserare för alla hanterade servrar i klustret. WLS-administratörsservern tillhandahåller en webbkonsol för klusterkonfiguration.

Använd följande steg för att kontrollera om Azure Application Gateway och WLS-administratörskonsolen i varje kluster fungerar innan du går vidare till nästa steg:

1. Gå tillbaka till sidan Distribution och välj sedan Utdata.
2. Kopiera värdet för egenskapen appGatewayURL. Lägg till strängen weblogic/ready och öppna sedan url:en på en ny webbläsarflik. Du bör se en tom sida utan felmeddelande. Om du inte gör det måste du felsöka och lösa problemet innan du fortsätter.
3. Kopiera och spara värdet för egenskapen adminConsole. Öppna den på en ny webbläsarflik. Du bör se inloggningssidan för WebLogic Server-administrationskonsolen. Logga in på konsolen med användarnamnet och lösenordet för WebLogic-administratören som du sparade åt sidan tidigare. Om du inte kan logga in måste du felsöka och lösa problemet innan du fortsätter.

Använd följande steg för att hämta IP-adressen för Azure Application Gateway för varje kluster. Du använder dessa värden när du konfigurerar Azure Traffic Manager senare.

1. Öppna resursgruppen där klustret distribueras. Välj till exempel Översikt för att växla tillbaka till fönstret Översikt på distributionssidan. Välj sedan Gå till resursgrupp.
2. Leta reda på resursen gwip med typen Offentlig IP-adress och välj den sedan för att öppna den. Leta efter FÄLTET IP-adress och spara dess värde.

Konfigurera en Azure Traffic Manager

I det här avsnittet skapar du en Azure Traffic Manager för att distribuera trafik till dina offentliga program i de globala Azure-regionerna. Den primära slutpunkten pekar på Azure Application Gateway i det primära WLS-klustret och den sekundära slutpunkten pekar på Azure Application Gateway i det sekundära WLS-klustret.

Skapa en Azure Traffic Manager-profil genom att följa snabbstarten: Skapa en Traffic Manager-profil med hjälp av Azure-portalen. Hoppa över avsnittet Förutsättningar. Du behöver bara följande avsnitt: Skapa en Traffic Manager-profil, Lägg till Traffic Manager-slutpunkter och Testa Traffic Manager-profil. Använd följande steg när du går igenom de här avsnitten och gå sedan tillbaka till den här artikeln när du har skapat och konfigurerat Azure Traffic Manager.

1. När du kommer till avsnittet Skapa en Traffic Manager-profil använder du följande steg:

   1. I steg 2 Skapa Traffic Manager-profil använder du följande steg:
      1. Spara åt sidan det unika Traffic Manager-profilnamnet för Namn – till exempel tmprofile-ejb120623.
      2. Spara åt sidan det nya resursgruppsnamnet för Resursgrupp – till exempel myResourceGroupTM1.

2. När du kommer till avsnittet Lägg till Traffic Manager-slutpunkter använder du följande steg:

   1. Utför den här ytterligare åtgärden efter steget Välj profilen från sökresultaten.
      1. Under Inställningar väljer du Konfiguration.
      2. Ange 10 för TTL (DNS time to live).
      3. Under Inställningar för slutpunktsövervakare anger du /weblogic/ready för Sökväg.
      4. Under Inställningar för snabb slutpunktsredundans använder du följande värden:
         • För avsökning internt anger du 10.
         • För Tolererat antal fel anger du 3.
         • För timeout för avsökning, 5.
      5. Välj Spara. Vänta tills den är klar.
   2. I steg 4 för att lägga till den primära slutpunkten myPrimaryEndpointanvänder du följande steg:
      1. Som Målresurstyp väljer du Offentlig IP-adress.
      2. Välj listrutan Välj offentlig IP-adress och ange IP-adressen för Application Gateway som distribuerades i WLS-klustret usa, östra som du sparade åt sidan tidigare. Du bör se en post matchad. Välj den för offentlig IP-adress.
   3. I steg 6 för att lägga till en redundans/sekundär slutpunkt myFailoverEndpoint använder du följande steg:
      1. Som Målresurstyp väljer du Offentlig IP-adress.
      2. Välj listrutan Välj offentlig IP-adress och ange IP-adressen för Application Gateway som distribuerades i WLS-klustret usa, västra som du sparade åt sidan tidigare. Du bör se en post matchad. Välj den för offentlig IP-adress.
   4. Vänta ett tag. Välj Uppdatera tills statusvärdet Övervaka för båda slutpunkterna är Online.

3. När du når avsnittet Test Traffic Manager-profil använder du följande steg:

   1. I underavsnittet Kontrollera DNS-namnet använder du följande steg:
      1. I steg 3 sparar du DNS-namnet på traffic manager-profilen åt sidan , till exempel http://tmprofile-ejb120623.trafficmanager.net.
   2. I underavsnittet Visa Traffic Manager i praktiken använder du följande steg:
      1. I steg 1 och 3 lägger du till /weblogic/ready till DNS-namnet på traffic manager-profilen i webbläsaren , till exempel http://tmprofile-ejb120623.trafficmanager.net/weblogic/ready. Du bör se en tom sida utan felmeddelande.
      2. När du har slutfört alla steg måste du aktivera den primära slutpunkten genom att referera till steg 2, men ersätt Inaktiverad med Aktiverad. Gå sedan tillbaka till sidan Slutpunkter .

Nu har du båda slutpunkterna Aktiverade och Online i Traffic Manager-profilen. Håll sidan öppen och du använder den för att övervaka slutpunktsstatusen senare.

Konfigurera WLS-kluster för hög tillgänglighet och haveriberedskap

I det här avsnittet konfigurerar du WLS-kluster för hög tillgänglighet och haveriberedskap.

Förbereda exempelappen

I det här avsnittet skapar och paketar du ett CRUD Java/JakartaEE-exempelprogram som du senare distribuerar och kör i WLS-kluster för redundanstestning.

Appen använder WebLogic Server JDBC-sessionspersistence för att lagra HTTP-sessionsdata. Datakällan jdbc/WebLogicCafeDB lagrar sessionsdata för att aktivera redundans och belastningsutjämning över ett kluster med WebLogic-servrar. Det konfigurerar ett beständigt schema för att bevara programdata coffee i samma datakälla jdbc/WebLogicCafeDB.

Använd följande steg för att skapa och paketera exemplet:

1. Använd följande kommandon för att klona exempellagringsplatsen och kolla in taggen som motsvarar den här artikeln:

   git clone https://github.com/Azure-Samples/azure-cafe.git
   cd azure-cafe
   git checkout 20231206
   

   Om du ser ett meddelande om Detached HEADär det säkert att ignorera.

2. Använd följande kommandon för att navigera till exempelkatalogen och kompilera och paketera sedan exemplet:

   cd weblogic-cafe
   mvn clean package
   

När paketet har genererats hittar du det på parent-path-to-your-local-clone>/azure-café/weblogic-café/target/weblogic-café.war.< Om du inte ser paketet måste du felsöka och lösa problemet innan du fortsätter.

Distribuera exempelappen

Använd nu följande steg för att distribuera exempelappen till klustren med början från det primära klustret:

1. Öppna adminConsole för klustret på en ny flik i webbläsaren. Logga in på weblogic-serveradministrationskonsolen med användarnamnet och lösenordet för den WebLogic-administratör som du sparade åt sidan tidigare.
2. Leta upp Domänstruktur>wlsd>Distributioner i navigeringsfönstret. Välj Distributioner.
3. Välj Lås och redigera>Installera>Ladda upp dina filer> Välj fil. Välj filen weblogic-café.war som du förberedde tidigare.
4. Välj Nästa>nästa>nästa. Välj cluster1 med alternativet Alla servrar i klustret för distributionsmålen. Välj Nästa>Slutför. Välj Aktivera ändringar.
5. Växla till fliken Kontroll och välj weblogic-cafe från distributionstabellen. Välj Börja med alternativet Service för alla begäranden>Ja. Vänta ett tag och uppdatera sidan tills du ser att distributionens weblogic-cafe tillstånd är Aktivt. Växla till fliken Övervakning och kontrollera att kontextroten för det distribuerade programmet är /weblogic-café. Håll WLS-administratörskonsolen öppen så att du kan använda den senare för ytterligare konfiguration.

Upprepa samma steg i WebLogic Server Administration Console, men för det sekundära klustret i regionen USA, västra.

Uppdatera klientdelsvärden

Använd följande steg för att göra dina WLS-kluster medvetna om Azure Traffic Manager. Eftersom Azure Traffic Manager är startpunkten för användarbegäranden uppdaterar du Front Host för WebLogic Server-klustret till DNS-namnet på Traffic Manager-profilen, med början från det primära klustret.

1. Kontrollera att du är inloggad på WebLogic Server Administration Console.
2. Gå till Domänstruktur>wlsd>Environment>Clusters i navigeringsfönstret. Välj Kluster.
3. Välj cluster1 från klustertabellen.
4. Välj Lås och redigera>HTTP. Ta bort det aktuella värdet för Klientdelsvärd och ange DNS-namnet på Traffic Manager-profilen som du sparade åt sidan tidigare, utan inledande http:// , till exempel tmprofile-ejb120623.trafficmanager.net. Välj Spara>aktivera ändringar.

Upprepa samma steg i WebLogic Server-administrationskonsolen, men för det sekundära klustret i regionen USA, västra.

Konfigurera transaktionsloggarkivet

Konfigurera sedan JDBC-transaktionsloggarkivet för alla hanterade servrar i kluster, med början från det primära klustret. Den här metoden beskrivs i Använda transaktionsloggfiler för att återställa transaktioner.

Använd följande steg i det primära WLS-klustret i regionen USA, östra:

1. Kontrollera att du är inloggad på WebLogic Server-administrationskonsolen.
2. Gå till Domänstruktur>wlsd>Environment>Servers i navigeringsfönstret. Välj Servrar.
3. Du bör se servrar msp1, msp2och msp3 visas i tabellen servrar.
4. Välj msp1>Tjänstlås>och redigera. Under Transaktionsloggarkiv väljer du JDBC.
5. För Typ>av datakälla väljer du .jdbc/WebLogicCafeDB
6. Bekräfta att värdet för Prefixnamn är TLOG_msp1_, vilket är standardvärdet. Om värdet är annorlunda ändrar du det till TLOG_msp1_.
7. Välj Spara.
8. Välj Servrar>msp2 och upprepa samma steg, förutom att standardvärdet för Prefixnamn är TLOG_msp2_.
9. Välj Servrar>msp3 och upprepa samma steg, förutom att standardvärdet för Prefixnamn är TLOG_msp3_.
10. Välj Aktivera ändringar.

Upprepa samma steg i WebLogic Server Administration Console, men för det sekundära klustret i regionen USA, västra.

Starta om de hanterade servrarna i det primära klustret

Använd sedan följande steg för att starta om alla hanterade servrar i det primära klustret för att ändringarna ska börja gälla:

1. Kontrollera att du är inloggad på WebLogic Server Administration Console.
2. Gå till Domänstruktur>wlsd>Environment>Servers i navigeringsfönstret. Välj Servrar.
3. Välj fliken Kontroll . Välj msp1, msp2och msp3. Välj Stäng med alternativet När arbetet är>klart Ja. Välj uppdateringsikonen. Vänta tills värdet För senaste åtgärd har slutförts. Du bör se att värdet Tillstånd för de valda servrarna är AVSTÄNGNING. Välj uppdateringsikonen igen för att stoppa statusövervakningen.
4. Välj msp1, msp2och msp3 igen. Välj Starta>Ja. Välj uppdateringsikonen. Vänta tills värdet För senaste åtgärd har slutförts. Du bör se att värdet Tillstånd för de valda servrarna körs. Välj uppdateringsikonen igen för att stoppa statusövervakningen.

Stoppa de virtuella datorerna i det sekundära klustret

Använd nu följande steg för att stoppa alla virtuella datorer i det sekundära klustret för att göra det passivt:

1. Öppna Startsidan för Azure-portalen på en ny flik i webbläsaren och välj sedan Alla resurser. I rutan Filtrera för alla fält... anger du resursgruppens namn där det sekundära klustret distribueras , till exempel wls-cluster-westus-ejb120623.
2. Välj Typ är lika med alla för att öppna typfiltret . Som Värde anger du Virtuell dator. Du bör se en post matchad. Välj den som Värde. Välj Använd. Du bör se 4 virtuella datorer i listan, inklusive adminVM, mspVM1, mspVM2och mspVM3.
3. Välj för att öppna var och en av de virtuella datorerna. Välj Stoppa och bekräfta för varje virtuell dator.
4. Välj meddelandeikonen från Azure-portalen för att öppna fönstret Meddelanden .
5. Övervaka händelsen Stoppa den virtuella datorn för varje virtuell dator tills värdet har stoppats av den virtuella datorn. Håll sidan öppen så att du kan använda den för redundanstestet senare.

Växla nu till webbläsarfliken där du övervakar slutpunkternas status för Traffic Manager. Uppdatera sidan tills du ser att slutpunkten myFailoverEndpoint är Degraderad och slutpunkten myPrimaryEndpoint är Online.

Verifiera appen

Eftersom det primära klustret är igång fungerar det som det aktiva klustret och hanterar alla användarbegäranden som dirigeras av traffic manager-profilen.

Öppna DNS-namnet på din Azure Traffic Manager-profil på en ny flik i webbläsaren och lägg till kontextroten /weblogic-café för den distribuerade appen , till exempel http://tmprofile-ejb120623.trafficmanager.net/weblogic-cafe. Skapa en ny kaffe med namn och pris – till exempel Kaffe 1 med pris 10. Den här posten sparas i både programdatatabellen och sessionstabellen i databasen. Användargränssnittet som du ser bör likna följande skärmbild:

Om användargränssnittet inte ser liknande ut kan du felsöka och lösa problemet innan du fortsätter.

Håll sidan öppen så att du kan använda den för redundanstestning senare.

Testa redundans från primär till sekundär

Om du vill testa redundansväxlingen redundansväxlar du manuellt den primära databasservern och klustret till den sekundära databasservern och klustret och redundansväxlar sedan tillbaka med hjälp av Azure-portalen i det här avsnittet.

Redundansväxling till den sekundära platsen

Använd först följande steg för att stänga av de virtuella datorerna i det primära klustret:

1. Leta reda på namnet på resursgruppen där det primära WLS-klustret distribueras, till exempel wls-cluster-eastus-ejb120623. Följ sedan stegen i avsnittet Stoppa virtuella datorer i det sekundära klustret , men ändra målresursgruppen till ditt primära WLS-kluster för att stoppa alla virtuella datorer i klustret.
2. Växla till webbläsarfliken i Traffic Manager och uppdatera sidan tills du ser att värdet Övervaka status för slutpunkten myPrimaryEndpoint blir Degraderad.
3. Växla till webbläsarfliken i exempelappen och uppdatera sidan. Du bör se tidsgränsen för 504 gateway eller 502 felaktig gateway eftersom ingen av slutpunkterna är tillgänglig.

Använd sedan följande steg för att redundansväxlar Azure SQL Database från den primära servern till den sekundära servern:

1. Växla till webbläsarfliken i din Azure SQL Database-redundansgrupp.
2. Välj Redundans>Ja.
3. Vänta tills den är klar.

Använd sedan följande steg för att starta alla servrar i det sekundära klustret:

1. Växla till webbläsarfliken där du stoppade alla virtuella datorer i det sekundära klustret.
2. Välj den virtuella datorn adminVM. Välj start.
3. Övervaka händelsen Starta virtuell dator för adminVM i fönstret Meddelanden och vänta tills värdet blir Startad virtuell dator.
4. Växla till webbläsarfliken i WebLogic Server Administration Console för det sekundära klustret och uppdatera sedan sidan tills du ser välkomstsidan för inloggning.
5. Växla tillbaka till webbläsarfliken där alla virtuella datorer i det sekundära klustret visas. För de virtuella datorerna mspVM1väljer , mspVM2och , var och mspVM3en för att öppna den och väljer sedan Starta.
6. För de virtuella datorerna mspVM1övervakar , mspVM2och mspVM3, händelsen Starta virtuell dator i fönstret Meddelanden och väntar tills värdena blir Startad virtuell dator.

Använd slutligen följande steg för att verifiera exempelappen när slutpunkten myFailoverEndpoint är i onlinetillståndet:

1. Växla till webbläsarfliken i Traffic Manager och uppdatera sedan sidan tills du ser att värdet Övervaka status för slutpunkten myFailoverEndpoint anger onlinetillståndet.

2. Växla till webbläsarfliken i exempelappen och uppdatera sidan. Du bör se samma data som sparas i programdatatabellen och sessionstabellen som visas i användargränssnittet, enligt följande skärmbild:

   

   Om du inte ser det här beteendet kan det bero på att Traffic Manager tar tid att uppdatera DNS för att peka på redundansplatsen. Problemet kan också vara att webbläsaren cachelagrade dns-namnmatchningsresultatet som pekar på den misslyckade webbplatsen. Vänta ett tag och uppdatera sidan igen.

Om du vill automatisera redundansväxlingen bör du överväga att använda aviseringar på Traffic Manager-mått och Azure Automation. Mer information finns i avsnittet Aviseringar om Traffic Manager-mått i Traffic Manager-mått och aviseringar och Använd en avisering för att utlösa en Azure Automation-runbook.

Växla tillbaka till den primära platsen

Använd samma steg i avsnittet Redundans till den sekundära platsen för att återställa till den primära platsen, inklusive databasservern och klustret, förutom följande skillnader:

1. Stäng först av de virtuella datorerna i det sekundära klustret. Du bör se att slutpunkten myFailoverEndpoint blir Degraderad.
2. Redundansväxlar sedan Azure SQL Database från den sekundära servern till den primära servern.
3. Starta sedan alla servrar i det primära klustret.
4. Kontrollera slutligen exempelappen när slutpunkten myPrimaryEndpoint är Online.

Rensa resurser

Om du inte kommer att fortsätta att använda WLS-kluster och andra komponenter använder du följande steg för att ta bort resursgrupperna för att rensa de resurser som används i den här självstudien:

1. Ange resursgruppens namn på Azure SQL Database-servrar (till exempel myResourceGroup) i sökrutan överst i Azure-portalen och välj den matchade resursgruppen i sökresultaten.
2. Välj Ta bort resursgrupp.
3. I Ange resursgruppens namn för att bekräfta borttagningen anger du resursgruppens namn.
4. Välj Ta bort.
5. Upprepa steg 1–4 för resursgruppen i Traffic Manager – till exempel myResourceGroupTM1.
6. Upprepa steg 1–4 för resursgruppen i det primära WLS-klustret , till exempel wls-cluster-eastus-ejb120623.
7. Upprepa steg 1–4 för resursgruppen för det sekundära WLS-klustret , till exempel wls-cluster-westus-ejb120623.

Nästa steg

I den här självstudien konfigurerar du en HA/DR-lösning som består av en aktiv-passiv programinfrastrukturnivå med en aktiv-passiv databasnivå och där båda nivåerna sträcker sig över två geografiskt olika platser. På den första platsen är både programinfrastrukturnivån och databasnivån aktiva. På den andra platsen stängs den sekundära domänen av och den sekundära databasen är i vänteläge.

Fortsätt att utforska följande referenser för fler alternativ för att skapa HA/DR-lösningar och köra WLS på Azure: