Läs på engelska

Dela via

Självstudie: Migrera Oracle WebLogic Server till Azure Kubernetes Service (AKS) med geo-redundans

  • Artikel

Den här självstudien visar ett enkelt och effektivt sätt att implementera en strategi för affärskontinuitet och haveriberedskap (DR) för Java med hjälp av Oracle WebLogic Server (WLS) i Azure Kubernetes Service (AKS). Lösningen visar hur du säkerhetskopierar och återställer en WLS-arbetsbelastning med hjälp av ett enkelt databasdrivet Jakarta EE-program som körs på AKS. Geo-redundans ä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 geo-redundans finns i resurserna i slutet av den här artikeln.

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

  • Använd Azure-optimerade metodtips för att uppnå hög tillgänglighet och haveriberedskap (HA/DR).
  • Konfigurera en Redundansgrupp för Microsoft Azure SQL Database i parkopplade regioner.
  • Konfigurera primära WLS-kluster på AKS.
  • Konfigurera geo-redundans med Azure Backup.
  • Återställa ett WLS-kluster i en sekundär region.
  • Konfigurera en Azure Traffic Manager.
  • Testa redundans.

Följande diagram illustrerar arkitekturen som du skapar:

Diagram över lösningsarkitekturen för WLS på virtuella Azure-datorer med hög tillgänglighet och haveriberedskap.

Azure Traffic Manager kontrollerar hälsotillståndet för dina regioner och dirigerar trafiken enligt programnivån. Den primära regionen har en fullständig distribution av WLS-klustret. Endast den primära regionen underhåller aktivt nätverksbegäranden från användarna. Den sekundära regionen återställer WLS-klustret från säkerhetskopior av den primära regionen om det uppstår en katastrof eller en deklarerad DR-händelse. Den sekundära regionen aktiveras för att endast ta emot trafik när den primära regionen drabbas av en tjänststörning.

Azure Traffic Manager använder hälsokontrollfunktionen i Azure Application Gateway och WebLogic Kubernetes Operator (WKO) för att implementera den här villkorliga routningen. WKO integreras djupt med AKS-hälsokontroller, vilket gör det möjligt för Azure Traffic Manager att ha en hög nivå av medvetenhet om hälsotillståndet för din Java-arbetsbelastning. Det primära WLS-klustret körs och det sekundära klustret stängs av.

Mål för återställningstid för geo-redundans (RTO) på programnivån beror på tiden för att starta AKS och köra det sekundära WLS-klustret, vilket vanligtvis är mindre än en timme. Programdata sparas och replikeras i Azure SQL Database-redundansgruppen, med en RTO på minuter eller timmar och ett mål för återställningspunkt (RPO) på minuter eller timmar. I den här arkitekturen har Azure Backup bara en säkerhetskopia av valvstandard för WLS-konfigurationen varje dag. Mer information finns i Vad är säkerhetskopiering av Azure Kubernetes Service (AKS)?

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.

Den här artikeln använder Azure Backup för att skydda AKS. Information om regiontillgänglighet, scenarier som stöds och begränsningar finns i Supportmatris för Azure Kubernetes Service-säkerhetskopiering. För närvarande har Azure Backup stöd för säkerhetskopieringar på valvnivå och återställning mellan regioner, som är tillgängliga i offentlig förhandsversion. Mer information finns i Aktivera säkerhetskopieringar på valvnivå för AKS och återställning mellan regioner med hjälp av Azure Backup.

Anteckning

I den här artikeln måste du ofta skapa unika identifierare för olika resurser. Den här artikeln använder konventionen om <initials><sequence-number> som ett prefix. Om ditt namn till exempel är Emily Juanita Bernal är ejb01en unik identifierare . För ytterligare tvetydighet kan du lägga till dagens datum i MMDD format, till exempel ejb010307.

Förutsättningar

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 de Azure Portal stegen 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äkerhetskopieringslagringsredundansi 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.

      Anteckning

      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.

  1. Om du vill skapa schemat anger du följande frågor:

    1. Om du vill skapa schemat för TLOG anger du följande fråga:

      SQL 
      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 TLOG_msp4_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_msp5_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 Query succeeded: Affected rows: 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).

    2. Om du vill skapa schemat för exempelprogrammet anger du följande fråga:

      SQL 
      CREATE TABLE COFFEE (ID NUMERIC(19) NOT NULL, NAME VARCHAR(255) NULL, PRICE FLOAT(32) NULL, PRIMARY KEY (ID));
CREATE TABLE SEQUENCE (SEQ_NAME VARCHAR(50) NOT NULL, SEQ_COUNT NUMERIC(28) NULL, PRIMARY KEY (SEQ_NAME));

      Efter en lyckad körning bör du se meddelandet Query succeeded: Affected rows: 0.

Nu är du klar med artikeln "Snabbstart: Skapa en enkel databas – Azure SQL Database".

Skapa sedan en Azure SQL Database-redundansgrupp genom att följa de Azure Portal stegen 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.

Hämta JDBC-anslutningssträng och användarnamnet för databasadministratören för redundansgruppen

Följande steg instruerar dig att hämta JDBC-anslutningssträng och databasanvändarnamnet för databasen i redundansgruppen. Dessa värden skiljer sig från motsvarande värden för den primära databasen.

  1. I Azure Portal letar du reda på resursgruppen som du distribuerade den primära databasen till.

  2. I listan över resurser väljer du den primära databasen med typen SQL-databas.

  3. Under Inställningar väljer du Anslutningssträngar.

  4. Välj JDBC.

  5. I textområdet under JDBC (SQL-autentisering) väljer du kopieringsikonen för att placera värdet för JDBC-anslutningssträng i Urklipp.

  6. Klistra in värdet i en textredigerare. Du redigerar den i ett annat steg.

  7. Gå tillbaka till resursgruppen.

  8. Välj den resurs av typen SQL Server som innehåller databasen som du just tittade på i föregående steg.

  9. Under Datahantering väljer du Redundansgrupper.

  10. I tabellen mitt på sidan väljer du redundansgruppen.

  11. I textområdet under Läs/skriv-lyssnarens slutpunkt väljer du kopieringsikonen för att placera värdet för JDBC-anslutningssträng i Urklipp.

  12. Klistra in värdet på en ny rad i textredigeraren. Textredigeraren bör nu ha rader som liknar följande exempel:

    jdbc:sqlserver://ejb010307db.database.windows.net:1433;database=ejb010307db;user=azureuser@ejb010307db;password={your_password_here};encrypt=true;trustServerCertificate=false;hostNameInCertificate=*.database.windows.net;loginTimeout=30;
ejb010307failover.database.windows.net

  13. Skapa en ny rad med hjälp av följande ändringar:

    1. Kopiera hela den första raden.

    2. Ändra värdnamnsdelen av URL:en så att värdnamnet används från slutpunktsraden läs-/skrivlyssnare.

    3. Ta bort allt efter paret name=value för database. Ta med andra ord bort allt inklusive och efter ; omedelbart efter database=ejb010307db.

      När du är klar bör strängen se ut ungefär som i följande exempel:

      jdbc:sqlserver://ejb010307failover.database.windows.net:1433;database=ejb010307db

      Det här värdet är JDBC-anslutningssträng.

  14. I samma textredigerare härleder du databasanvändarnamnet genom att hämta värdet för parametern user från den ursprungliga JDBC-anslutningssträng och ersätta databasnamnet med den första delen av slutpunktsraden läs-/skrivlyssnare. Om du fortsätter med föregående exempel skulle värdet vara azureuser@ejb010307failover. Det här värdet är användarnamnet för databasadministratören.

Konfigurera de primära WLS-klustren på AKS

I det här avsnittet skapar du ett WLS-kluster på AKS med hjälp av Oracle WebLogic Server i AKS-erbjudandet . Klustret i USA, östra är det primära och konfigureras som det aktiva klustret.

Anteckning

Mer information om Oracle WebLogic Server i AKS-erbjudandet finns i följande artiklar:

Förbereda en exempelapp

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:

    Bash 
    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:

    Bash 
    cd weblogic-cafe
mvn clean package

När paketet har genererats hittar du det på <.> Om du inte ser paketet måste du felsöka och lösa problemet innan du fortsätter.

Skapa ett lagringskonto och en lagringscontainer för att lagra exempelprogrammet

Använd följande steg för att skapa ett lagringskonto och en container. Vissa av de här stegen leder dig till andra guider. När du har slutfört stegen kan du ladda upp ett exempelprogram för distribution på WLS.

  1. Logga in på Azure-portalen.

  2. Skapa ett lagringskonto genom att följa stegen i Skapa ett lagringskonto. Använd följande specialiseringar för värdena i artikeln:

    • Skapa en ny resursgrupp för lagringskontot.
    • För Region väljer du USA, östra.
    • För Lagringskontonamn använder du samma värde som resursgruppens namn.
    • För Prestanda väljer du Standard.
    • För Redundans väljer du Lokalt redundant lagring (LRS).
    • De återstående flikarna behöver inga specialiseringar.

  3. Fortsätt att verifiera och skapa kontot och gå sedan tillbaka till den här artikeln.

  4. Skapa en lagringscontainer i kontot genom att följa stegen i avsnittet Skapa en container i Snabbstart: Ladda upp, ladda ned och lista blobar med Azure Portal.

  5. Med samma artikel laddar du upp paketet azure-café/weblogic-café/target/weblogic-café.war som du skapade tidigare genom att följa stegen i avsnittet Ladda upp en blockblob . Gå sedan tillbaka till den här artikeln.

Distribuera WLS på AKS

Använd följande steg för att distribuera WLS på AKS:

  1. Öppna Oracle WebLogic Server på AKS-erbjudandet i webbläsaren och välj Skapa. Du bör se fönstret Grundläggande i erbjudandet.

    Skärmbild av Azure Portal som visar Oracle WebLogic Server i fönstret Grundläggande AKS.

  2. 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. I fältet Resursgrupp väljer du Skapa ny och fyller i ett unikt värde för resursgruppen , till exempel wlsaks-eastus-20240109.

    3. Under Instansinformation väljer du USA, östra för Region.

    4. Under Autentiseringsuppgifter WebLogic anger du ett lösenord för WebLogic-administratör respektive WebLogic-modellkryptering. Spara användarnamnet och lösenordet för WebLogic-administratören åt sidan.

    5. Under Valfri grundläggande konfiguration, för Acceptera standardvärden för valfri konfiguration?, väljer du Nej. Den valfria konfigurationen visas.

      Skärmbild av Azure Portal som visar Oracle WebLogic Server i aks-fönstret Grundläggande alternativ konfiguration.

    6. Fyll i mspför namnprefix för Managed Server. Du konfigurerar WLS TLOG-tabellen med prefix senare TLOG_${serverName}_ . Den här artikeln skapar TLOG-tabellen med namnet TLOG_msp${index}_WLStore. Om du vill ha ett annat prefix för hanterat servernamn kontrollerar du att värdet matchar namngivningskonventionerna för Microsoft SQL Server-tabeller och de riktiga tabellnamnen.

    7. Lämna standardvärdena för de andra fälten.

  3. Välj Nästa för att gå till AKS-fönstret.

  4. Under Bildval anger du följande information:

    • För Användarnamn för Oracle-autentisering med enkel inloggning fyller du i ditt Oracle SSO-användarnamn från förhandsvillkoren.
    • För Lösenord för Oracle-autentisering med enkel inloggning fyller du i dina Oracle SSO-autentiseringsuppgifter från förhandsvillkoren.

    Skärmbild av Azure Portal som visar Oracle WebLogic Server i AKS-fönstret – Bildval.

  5. Under Program använder du följande steg:

    1. I avsnittet Program bredvid Distribuera ett program?, väljer du Ja.
    2. Bredvid Programpaket (.war,.ear,.jar)väljer du Bläddra.
    3. Börja skriva namnet på lagringskontot från föregående avsnitt. När det önskade lagringskontot visas väljer du det.
    4. Välj lagringscontainern från föregående avsnitt.
    5. Markera kryssrutan bredvid weblogic-café.war, som du laddade upp i föregående avsnitt. Välj Välj.
    6. Lämna standardvärdena för de andra fälten.

    Skärmbild av Azure Portal som visar Oracle WebLogic Server i AKS-fönstret – Val av app.

  6. Välj Nästa.

  7. Lämna standardvärdena i fönstret TLS/SSL-konfiguration och välj sedan Nästa för att gå till fönstret Belastningsutjämning .

    Skärmbild av Azure Portal som visar Oracle WebLogic Server-klustret i aks-fönstret belastningsutjämning.

  8. I fönstret Belastningsutjämning bredvid Skapa ingress för administrationskonsolen. Kontrollera att inget program med sökvägen /console*, det kommer att orsaka konflikt med administrationskonsolsökvägen och välj Ja.

  9. Lämna standardvärdena för de andra fälten och välj Nästa

  10. Lämna standardvärdena i DNS-fönstret och välj Nästa för att gå till fönstret Databas .

    Skärmbild av Azure Portal som visar Oracle WebLogic Server-klustret i aks-databasfönstret.

  11. Ange följande värden i fönstret Databas :

  12. Välj Granska + skapa.

  13. 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.

Anteckning

Om du ser några problem när du kör den slutliga valideringen... kan du åtgärda dem och försöka igen.

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

Konfigurera lagring av TLOG-data

I det här avsnittet konfigurerar du lagringen av TLOG-data genom att åsidosätta WLS-avbildningsmodellen med en ConfigMap. Mer information om finns i ConfigMapWebLogic Deploy Tooling Model ConfigMap.

Det här avsnittet kräver en Bash-terminal med Azure CLI och kubectl installerat. Använd följande steg för att härleda nödvändig YAML till och konfigurera lagring av TLOG-data:

  1. Använd följande steg för att ansluta till ditt AKS-kluster:

    1. Öppna Azure Portal och gå till resursgruppen som du etablerade i avsnittet Distribuera WLS på AKS.
    2. Välj AKS-klustret i resurslistan och välj sedan Anslut för att ansluta till AKS-klustret.
    3. Välj Azure CLI och följ stegen för att ansluta till AKS-klustret i din lokala terminal.

  2. Använd följande steg för att hämta topology: posten från WLS-avbildningsmodellen YAML:

    1. Öppna Azure Portal och gå till resursgruppen som du etablerade i avsnittet Distribuera WLS på AKS.
    2. Välj Inställningar>Distributioner. Välj den första distributionen vars namn börjar med oracle.20210620-wls-on-aks.
    3. Välj Utdata. Kopiera shellCmdtoOutputWlsImageModelYaml-värdet till Urklipp. Värdet är ett gränssnittskommando som avkodar modellfilens base64-sträng och sparar innehållet i en fil med namnet model.yaml.
    4. Klistra in värdet i Bash-terminalen och kör kommandot för att skapa filen model.yaml .
    5. Redigera filen för att ta bort allt innehåll förutom posten på den översta nivån topology: . Det bör inte finnas några poster på den översta nivån i filen förutom topology:.
    6. Spara filen.

  3. Använd följande steg för att hämta ConfigMap namn och namnområdesnamn från WLS-domänmodellen YAML:

    1. Öppna Azure Portal och gå till resursgruppen som etablerades i avsnittet Distribuera WLS på AKS.

    2. Välj Inställningar>Distributioner. Välj den första distributionen vars namn börjar med oracle.20210620-wls-on-aks.

    3. Välj Utdata. Kopiera värdet för shellCmdtoOutputWlsDomainYaml till Urklipp. Värdet är ett gränssnittskommando för att avkoda base64-strängen med modellfilen och spara innehåll i model.yaml.

    4. Klistra in värdet i terminalen så får du en fil med namnet domain.yaml.

    5. Leta efter följande värden i domain.yaml-.

      • spec.configuration.model.configMap. Om du accepterade standardvärdena är sample-domain1-wdt-config-mapdet här värdet .
      • metadata.namespace. Om du accepterade standardvärdena är sample-domain1-nsdet här värdet .

      För enkelhetens skull kan du använda följande kommando för att spara dessa värden som gränssnittsvariabler:

      Bash 
      export CONFIG_MAP_NAME=sample-domain1-wdt-config-map
export WLS_NS=sample-domain1-ns

  4. Använd följande kommando för att hämta ConfigMap YAML:

    Bash 
    kubectl get configmap ${CONFIG_MAP_NAME} -n ${WLS_NS} -o yaml > configMap.yaml

  5. Använd följande steg för att skapa filen tlog-db-model.yaml :

    1. Skapa en tom fil med namnet tlog-db-model.yaml i en textredigerare.

    2. Infoga innehållet i din model.yaml, lägg till en tom rad och infoga sedan innehållet i filen configMap.yaml .

  6. . Lägg till den här texten på följande rad, var mycket försiktig TransactionLogJDBCStoreListenPort och de återstående raderna i följande kodfragment är indragna med två, som du ser i följande exempel:

    YAML 
    TransactionLogJDBCStore:
  Enabled: true
  DataSource: jdbc/WebLogicCafeDB
  PrefixName: TLOG_${serverName}_

    Den slutförda tlog-db-model.yaml bör se mycket nära följande exempel:

    YAML 
    topology:
  Name: "@@ENV:CUSTOM_DOMAIN_NAME@@"
  ProductionModeEnabled: true
  AdminServerName: "admin-server"
  Cluster:
    "cluster-1":
      DynamicServers:
        ServerTemplate: "cluster-1-template"
        ServerNamePrefix: "@@ENV:MANAGED_SERVER_PREFIX@@"
        DynamicClusterSize: "@@PROP:CLUSTER_SIZE@@"
        MaxDynamicClusterSize: "@@PROP:CLUSTER_SIZE@@"
        MinDynamicClusterSize: "0"
        CalculatedListenPorts: false
  Server:
    "admin-server":
      ListenPort: 7001
  ServerTemplate:
    "cluster-1-template":
      Cluster: "cluster-1"
      ListenPort: 8001
      TransactionLogJDBCStore:
        Enabled: true
        DataSource: jdbc/WebLogicCafeDB
        PrefixName: TLOG_${serverName}_
  SecurityConfiguration:
    NodeManagerUsername: "@@SECRET:__weblogic-credentials__:username@@"
    NodeManagerPasswordEncrypted: "@@SECRET:__weblogic-credentials__:password@@"

resources:
  JDBCSystemResource:
    jdbc/WebLogicCafeDB:
      Target: 'cluster-1'
      JdbcResource:
        JDBCDataSourceParams:
          JNDIName: [
            jdbc/WebLogicCafeDB
          ]
          GlobalTransactionsProtocol: None
        JDBCDriverParams:
          DriverName: com.microsoft.sqlserver.jdbc.SQLServerDriver
          URL: '@@SECRET:ds-secret-sqlserver-1709938597:url@@'
          PasswordEncrypted: '@@SECRET:ds-secret-sqlserver-1709938597:password@@'
          Properties:
            user:
              Value: '@@SECRET:ds-secret-sqlserver-1709938597:user@@'
        JDBCConnectionPoolParams:
            TestTableName: SQL SELECT 1
            TestConnectionsOnReserve: true

  7. Åsidosätt WLS-modellen med ConfigMap. Om du vill åsidosätta WLS-modellen ersätter du den befintliga ConfigMap med den nya modellen. Mer information finns i Uppdatera en befintlig modell i Oracle-dokumentationen. Kör följande kommandon för att återskapa ConfigMap:

    Bash 
    export CM_NAME_FOR_MODEL=sample-domain1-wdt-config-map
kubectl -n sample-domain1-ns delete configmap ${CM_NAME_FOR_MODEL}

# replace path of tlog-db-model.yaml
kubectl -n sample-domain1-ns create configmap ${CM_NAME_FOR_MODEL} \
  --from-file=tlog-db-model.yaml
kubectl -n sample-domain1-ns label configmap ${CM_NAME_FOR_MODEL} \
  weblogic.domainUID=sample-domain1

  8. Starta om WLS-klustret med hjälp av följande kommandon. Du måste orsaka en löpande uppdatering för att den nya modellen ska fungera.

    Bash 
    export RESTART_VERSION=$(kubectl -n sample-domain1-ns get domain sample-domain1 '-o=jsonpath={.spec.restartVersion}')
# increase restart version
export RESTART_VERSION=$((RESTART_VERSION + 1))

kubectl -n sample-domain1-ns patch domain sample-domain1 \
    --type=json \
    '-p=[{"op": "replace", "path": "/spec/restartVersion", "value": "'${RESTART_VERSION}'" }]'

Kontrollera att WLS-poddarna körs innan du går vidare. Du kan använda följande kommando för att titta på status för poddarna:

Bash 
kubectl get pod -n sample-domain1-ns -w

Anteckning

I den här artikeln ingår WLS-modeller i programcontaineravbildningen, som skapades av WLS i AKS-erbjudandet. TLOG konfigureras genom att åsidosätta den befintliga modellen med den WDT ConfigMap som innehåller modellfilen och använder domänens CRD-fält configuration.model.configMap för att referera till kartan. I produktionsscenarier är extrabilder den rekommenderade bästa metoden för att inkludera modell i bildmodellfiler, programarkivfiler och installation av WebLogic Deploy Tooling i dina poddar. Den här funktionen eliminerar behovet av att ange dessa filer i avbildningen som anges i domain.spec.image.

Konfigurera geo-redundans med Azure Backup

I det här avsnittet använder du Azure Backup för att säkerhetskopiera AKS-kluster med hjälp av tillägget Säkerhetskopiering, som måste installeras i klustret.

Använd följande steg för att konfigurera geo-redundans:

  1. Skapa en ny lagringscontainer för AKS-säkerhetskopieringstillägget i lagringskontot som du skapade i avsnittet Skapa ett lagringskonto och en lagringscontainer för att lagra exempelprogrammet .

  2. Använd följande kommandon för att installera AKS-säkerhetskopieringstillägget och aktivera CSI-drivrutiner och ögonblicksbilder för klustret:

    Azure CLI 
    #replace with your resource group name.
export RG_NAME=wlsaks-eastus-20240109
export AKS_NAME=$(az aks list \
    --resource-group ${RG_NAME} \
    --query "[0].name" \
    --output tsv)

az aks update \
    --resource-group ${RG_NAME} \
    --name ${AKS_NAME} \
    --enable-disk-driver \
    --enable-file-driver \
    --enable-blob-driver \
    --enable-snapshot-controller --yes

    Det tar cirka 5 minuter att aktivera drivrutinerna. Kontrollera att kommandona har slutförts utan fel innan du går vidare.

  1. Öppna den resursgrupp som har AKS distribuerat. Välj AKS-klustret i resurslistan.

  2. På AKS-landningssidan väljer du >

  3. På sidan Installera AKS Backup-tillägget väljer du Nästa. Välj lagringskontot och blobcontainern som skapades i föregående steg. Välj Nästa och sedan Skapa. Det tar ungefär fem minuter att slutföra det här steget.

  1. Öppna Azure Portal genom att söka efter Säkerhetskopieringsvalv i sökfältet längst upp. Du bör se den i listan under Tjänster. Välj den.

  2. Om du vill aktivera AKS Backup följer du stegen i Säkerhetskopiera Azure Kubernetes Service med hjälp av Azure Backup upp till, men inte inklusive, avsnittet "Använd krokar under AKS-säkerhetskopiering". Gör de justeringar som anges i följande steg.

  3. När du når avsnittet "Skapa ett säkerhetskopieringsvalv" gör du följande justeringar:

    • För steg 1 går du till Regioner och väljer USA, östra. Under Redundans för säkerhetskopieringslagring använder du Globalt redundant.

      Skärmbild av Azure Portal som visar fönstret Basic för Backup Vault.

    • För steg 2 aktiverar du Återställning mellan regioner.

  4. När du når avsnittet "Skapa en säkerhetskopieringsprincip" gör du följande justeringar när du uppmanas att skapa en kvarhållningsprincip:

    1. Lägg till en kvarhållningsregel där Vault-standard har valts.

      Skärmbild av Azure Portal som visar valet av valvstandardalternativet.

    2. Markera Lägga till.

  5. När du når avsnittet "Konfigurera säkerhetskopior" gör du följande justeringar. Steg 1–5 gäller installation av AKS-tillägg. Hoppa över steg 1–5 och börja från steg 6.

    • För steg 7 får du behörighetsfel. Välj Bevilja behörighet för att gå vidare. När behörighetsdistributionen har slutförts väljer du Omvalidera för att uppdatera rolltilldelningarna om felet fortfarande visas.

      Skärmbild av Azure Portal som visar behörigheten för AKS Configure Backup Grant.

    • För steg 10 letar du reda på Välj resurser till Säkerhetskopiering och gör följande justeringar:

      • För Namnet på säkerhetskopieringsinstansen fyller du i ett unikt namn.
      • För Namnområden väljer du namnområden för WebLogic Operator och WebLogic Server. I den här artikeln väljer du weblogic-operator-ns och sample-domain1-ns.
      • För Andra alternativ väljer du alla alternativ. Kontrollera att Inkludera hemligheter är markerat.

      Skärmbild av Azure Portal som visar AKS Konfigurera säkerhetskopiering Välj resurser.

    • För steg 11 får du ett rolltilldelningsfel. Välj din datakälla i listan och välj Tilldela saknade roller för att åtgärda felet.

      Skärmbild av Azure Portal som visar AKS Configure Backup Validation (Konfigurera säkerhetskopieringsverifiering).

Förbered för att återställa WLS-klustret i en sekundär region

I det här avsnittet förbereder du dig för att återställa WLS-klustret i den sekundära regionen. Här är den sekundära regionen West US 2. Innan du återställer måste du ha ett AKS-kluster med AKS Backup Extension installerat i Västra USA 2-regionen.

Konfigurera Azure Container Registry för geo-replikering

Använd följande steg för att konfigurera Azure Container Registry (ACR) för geo-replikering, som innehåller den WLS-avbildning som du skapade i avsnittet Distribuera WLS på AKS . Om du vill aktivera ACR-replikering måste du uppgradera den till premiumprisplanen. Mer information finns i Geo-replikering i Azure Container Registry.

  1. Öppna resursgruppen som du etablerade i avsnittet Distribuera WLS på AKS . I resurslistan väljer du den ACR vars namn börjar med wlsaksacr.
  2. På landningssidan för ACR väljer du . För Prisplan väljer du Premium och sedan Spara.
  3. I navigeringsfönstret väljer du Tjänster>Geo-replikering. Välj Lägg till för att lägga till replikeringsregionen på sidan.
  4. På sidan Skapa replikering väljer du Plats, väljer Västra USA 2och väljer sedan Skapa.

När distributionen är klar aktiveras ACR för geo-replikering.

Skapa ett lagringskonto i en sekundär region

Om du vill aktivera AKS Backup-tillägget måste du ange ett lagringskonto med en tom container i samma region.

Om du vill återställa säkerhetskopiering mellan regioner måste du ange en mellanlagringsplats där säkerhetskopieringsdata är hydratiserade. Den här mellanlagringsplatsen innehåller en resursgrupp och ett lagringskonto i den inom samma region och prenumeration som målklustret för återställning.

Använd följande steg för att skapa ett lagringskonto och en container. Vissa av de här stegen leder dig till andra guider.

  1. Logga in på Azure-portalen.
  2. Skapa ett lagringskonto genom att följa stegen i Skapa ett lagringskonto. Du behöver inte utföra alla steg i artikeln. Fyll i fälten som visas i fönstret Grundläggande . För Regionväljer du USA, västra 2och väljer sedan Granska + skapa för att acceptera standardalternativen. Fortsätt att verifiera och skapa kontot och gå sedan tillbaka till den här artikeln.
  3. Skapa en lagringscontainer för AKS Backup-tillägget genom att följa stegen i avsnittet Skapa en container i Snabbstart: Ladda upp, ladda ned och lista blobar med Azure Portal.
  4. Skapa en lagringscontainer som en mellanlagringsplats för användning under återställningen.

Förbereda ett AKS-kluster i en sekundär region

Följande avsnitt visar hur du skapar ett AKS-kluster i en sekundär region.

Skapa ett nytt AKS-kluster

Den här artikeln visar ett WLS-program med application gateway-ingresskontrollant. I det här avsnittet skapar du ett nytt AKS-kluster i regionen West US 2. Sedan aktiverar du ingresskontrollanttillägget med en ny application gateway-instans. Mer information finns i Aktivera ingresskontrollanttillägget för ett nytt AKS-kluster med en ny programgatewayinstans.

Använd följande steg för att skapa AKS-klustret:

  1. Använd följande kommandon för att skapa en resursgrupp i den sekundära regionen:

    Azure CLI 
    export RG_NAME_WESTUS=wlsaks-westus-20240109

az group create --name ${RG_NAME_WESTUS} --location westus

  2. Använd följande kommandon för att distribuera ett AKS-kluster med tillägget aktiverat:

    Azure CLI 
    export AKS_NAME_WESTUS=${RG_NAME_WESTUS}aks
export GATEWAY_NAME_WESTUS=${RG_NAME_WESTUS}gw

az aks create \
    --resource-group ${RG_NAME_WESTUS} \
    --name ${AKS_NAME_WESTUS} \
    --network-plugin azure \
    --enable-managed-identity \
    --enable-addons ingress-appgw \
    --appgw-name ${GATEWAY_NAME_WESTUS} \
    --appgw-subnet-cidr "10.225.0.0/16" \
    --generate-ssh-keys

    Det här kommandot skapar automatiskt en Standard_v2 SKU programgatewayinstans med namnet ${RG_NAME_WESTUS}gw i resursgruppen AKS-nod. Nodresursgruppen namnges MC_resource-group-name_cluster-name_location som standard.

    Anteckning

    AKS-klustret som du etablerade i avsnittet Distribuera WLS på AKS körs i tre tillgänglighetszoner i regionen USA, östra. Tillgänglighetszoner stöds inte i regionen West US 2. AKS-klustret i västra USA 2 är inte zonredundant. Om produktionsmiljön kräver zonredundans kontrollerar du att den kopplade regionen stöder tillgänglighetszoner. Mer information finns i avsnittet Översikt över tillgänglighetszoner för AKS-kluster i Skapa ett AKS-kluster (Azure Kubernetes Service) som använder tillgänglighetszoner.

  3. Använd följande kommandon för att hämta den offentliga IP-adressen för programgatewayinstansen. Spara ip-adressen, som du använder senare i den här artikeln.

    Azure CLI 
    export APPGW_ID=$(az aks show \
    --resource-group ${RG_NAME_WESTUS} \
    --name ${AKS_NAME_WESTUS} \
    --query 'addonProfiles.ingressApplicationGateway.config.effectiveApplicationGatewayId' \
    --output tsv)
echo ${APPGW_ID}
export APPGW_IP_ID=$(az network application-gateway show \
    --id ${APPGW_ID} \
    --query frontendIPConfigurations\[0\].publicIPAddress.id \
    --output tsv)
echo ${APPGW_IP_ID}
export APPGW_IP_ADDRESS=$(az network public-ip show \
    --id ${APPGW_IP_ID} \
    --query ipAddress \
    --output tsv)
echo "App Gateway public IP address: ${APPGW_IP_ADDRESS}"

  4. Använd följande kommando för att koppla en DNS-namnetikett (domain name service) till den offentliga IP-adressresursen. Ersätt <your-chosen-DNS-name> med ett lämpligt värde , till exempel ejb010316.

    Azure CLI 
    az network public-ip update --ids ${APPGW_IP_ID} --dns-name <your-chosen-DNS-name>

  5. Du kan kontrollera det fullständigt kvalificerade domännamnet (FQDN) för den offentliga IP-adressen med az network public-ip show. I följande exempel visas ett FQDN med DNS-etikett ejb010316:

    Bash 
    az network public-ip show \
    --id ${APPGW_IP_ID} \
    --query dnsSettings.fqdn \
    --output tsv

    Det här kommandot genererar utdata som liknar följande exempel:

    Output 
    ejb010316.westus.cloudapp.azure.com

Anteckning

Om du arbetar med ett befintligt AKS-kluster slutför du följande två åtgärder innan du går vidare:

  • Aktivera ingresskontrollanttillägget genom att följa stegen i Aktivera tillägg för ingresskontrollant för programgateway för ett befintligt AKS-kluster.
  • Om du har WLS som körs i målnamnområdet rensar du WLS-resurser i WebLogic-operatorns namnområde och WebLogic Server-namnområdet för att undvika konflikter. I den här artikeln etablerade WLS på AKS-erbjudandet WebLogic-operatorn i namnområdet weblogic-operator-ns och WebLogic-servern i namnområdet sample-domain1-ns. Kör kubectl delete namespace weblogic-operator-ns sample-domain1-ns för att ta bort de två namnrymderna.

Aktivera AKS-säkerhetskopieringstillägget

Innan du fortsätter använder du följande steg för att installera AKS Backup-tillägget i klustret i den sekundära regionen:

  1. Använd följande kommando för att ansluta till AKS-klustret i region Västra USA 2:

    Azure CLI 
    az aks get-credentials \
    --resource-group ${RG_NAME_WESTUS} \
    --name ${AKS_NAME_WESTUS}

  2. Använd följande kommando för att aktivera CSI-drivrutiner och ögonblicksbilder för klustret:

    Azure CLI 
    az aks update \
    --resource-group ${RG_NAME_WESTUS} \
    --name ${AKS_NAME_WESTUS} \
    --enable-disk-driver \
    --enable-file-driver \
    --enable-blob-driver \
    --enable-snapshot-controller --yes

  1. Öppna den resursgrupp som har AKS distribuerat. Välj AKS-klustret i resurslistan.

  2. På AKS-landningssidan väljer du >

  3. På sidan Installera AKS Backup-tillägget väljer du Nästa. Välj lagringskontot och blobcontainern som skapades i föregående steg. Välj Nästa och sedan Skapa. Det tar ungefär fem minuter att slutföra det här steget.

Anteckning

För att spara kostnader kan du stoppa AKS-klustret i den sekundära regionen genom att följa stegen i Stoppa och starta ett AkS-kluster (Azure Kubernetes Service). Starta det innan du återställer WLS-klustret.

Vänta tills en säkerhetskopia av valvstandard inträffar

I AKS är valvstandardnivån den enda nivån som stöder geo-redundans och återställning mellan regioner. Som anges i Vilken lagringsnivå för säkerhetskopiering stöder AKS-säkerhetskopiering?, "Endast en schemalagd återställningspunkt per dag flyttas till valvnivå." Du måste vänta tills en säkerhetskopia av valvstandard inträffar. En bra nedre gräns är att vänta 24 timmar efter att du har slutfört föregående steg innan du fortsätter.

Stoppa det primära klustret

Det primära WLS-klustret och det sekundära WLS-klustret konfigureras med samma TLOG-databas. Endast ett kluster kan äga databasen samtidigt. Stoppa det primära WLS-klustret för att säkerställa att det sekundära klustret fungerar korrekt. I den här artikeln stoppar du AKS-klustret för att inaktivera WLS-klustret med hjälp av följande steg:

  1. Öppna Azure Portal och gå till resursgruppen som du etablerade i avsnittet Distribuera WLS på AKS.
  2. Öppna AKS-klustret som visas i resursgruppen.
  3. Välj Stoppa för att stoppa AKS-klustret. Kontrollera att distributionen är klar innan du går vidare.

Återställa WLS-klustret

AKS-säkerhetskopiering stöder säkerhetskopiering på både driftnivå och valvnivå. Endast säkerhetskopior som lagras på valvnivå kan användas för att återställa till ett kluster i en annan region (Azure Paired Region). Enligt de kvarhållningsregler som anges i säkerhetskopieringsprincipen flyttas den första lyckade säkerhetskopieringen av en dag till blobcontainern mellan regioner. Mer information finns i avsnittet Vilken lagringsnivå för säkerhetskopiering stöder AKS-säkerhetskopiering? i Vad är Säkerhetskopiering av Azure Kubernetes Service?

När du har konfigurerat geo-redundans i avsnittet Konfigurera geo-redundans med Azure Backup tar det minst en dag innan säkerhetskopior på valvnivå blir tillgängliga för återställning.

Använd följande steg för att återställa WLS-klustret:

  1. Öppna Azure Portal och sök efter Backup Center. Välj Säkerhetskopieringscenter under Tjänster.

  2. Under Hantera väljer du Säkerhetskopieringsinstanser. Filtrera på datakällans typ Kubernetes Services för att hitta den säkerhetskopieringsinstans som du skapade i föregående avsnitt.

  3. Välj säkerhetskopieringsinstansen för att se listan med återställningspunkter. I den här artikeln är instansnamnet en sträng som liknar wlsonaks*\wlsaksinstance20240109.

    Skärmbild av Azure Portal som visar återställningspunkterna för säkerhetskopieringsinstansen.

  4. Välj den senaste säkerhetskopian av drifts- och valvstandard och välj sedan Fler alternativ. Välj Återställ för att starta återställningsprocessen.

  5. På sidan Återställ är standardfönstret Återställningspunkt. Välj Föregående för att ändra till fönstret Grundläggande . För Återställ region väljer du Sekundär region och sedan Nästa: Återställningspunkt.

    Skärmbild av Azure Portal som visar fönstret Återställ grunderna.

  6. I fönstret Återställningspunkt för Välj den nivå som ska återställas väljer du Arkivarkiv och sedan Nästa:Återställ parametrar.

    Skärmbild av Azure Portal som visar fönstret Återställningspunkt.

  7. Använd följande steg i fönstret Återställningsparametrar :

    1. För Välj målklusterska du välja det AKS-kluster som du skapade i regionen Västra USA 2. Du stöter på ett behörighetsproblem som visas på följande skärmbild. Välj Bevilja behörighet för att åtgärda felen.

    2. Välj för mellanlagringsplats för säkerhetskopieringdet lagringskonto som du skapade i Västra USA 2. Du stöter på ett behörighetsproblem som visas på följande skärmbild. Välj Tilldela saknade roller för att åtgärda felen.

    3. Om felen fortfarande inträffar när rolltilldelningarna har slutförts väljer du Förnya för att uppdatera behörigheterna.

      Skärmbild av Azure Portal som visar parameterfönstret Återställ.

    4. När du beviljar saknade behörigheter godkänner du standardvärdet om du uppmanas att ange ett omfång.

    5. Välj validera. Du bör se meddelandet Validering har slutförts. Annars kan du felsöka och lösa problemet innan du fortsätter.

  8. Välj Nästa:Granska + återställa och välj sedan Återställ. Det tar cirka 10 minuter att återställa WLS-klustret.

  9. Du kan övervaka återställningsprocessen från Säkerhetskopieringscenter>Övervakning + rapportering>Säkerhetskopieringsjobb, enligt följande skärmbild:

    Skärmbild av Azure Portal som visar en CrossRegionRestore som pågår.

  10. Välj Uppdatera för att se den senaste förloppet.

  11. När processen har slutförts utan fel stoppar du AKS-säkerhetskopieringsklustret. Om du inte gör det uppstår ägarkonflikter när du kommer åt TLOG-databasen i senare steg.

  12. Starta det primära klustret.

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 stegen i Snabbstart: Skapa en Traffic Manager-profil med hjälp av Azure Portal. 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 i steg 2 Skapa Traffic Manager-profil:

    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. Efter steget Välj profil från sökresultatet använder du följande steg:
      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 övervakningsstatusen når följande tillstånd:
      • Den primära slutpunkten är Online.
      • Redundansslutpunkten är Degraderad.

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

    1. I underavsnittet Kontrollera DNS-namnet sparar du i steg 3 DNS-namnet för din Traffic Manager-profil , 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. I steg 4 kan du inte komma åt /weblogic/ready, vilket förväntas eftersom det sekundära klustret har stoppats.
      3. Återaktivera den primära slutpunkten.

Nu har den primära slutpunkten tillstånden Aktiverad och Online och redundansslutpunkten har tillstånden Aktiverad och Degraderad i Traffic Manager-profilen. Håll sidan öppen för att övervaka slutpunktsstatusen senare.

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

För att testa redundansväxlingen redundansväxlar du manuellt den primära databasservern och WLS-klustret till den sekundära databasservern och WLS-klustret i det här avsnittet.

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:

Skärmbild av exempelprogrammets användargränssnitt.

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.

Redundansväxling till den sekundära platsen

Använd följande steg för att redundansväxla från primär till sekundär.

Använd först följande steg för att stoppa det primära AKS-klustret:

  1. Öppna Azure Portal och gå till resursgruppen som etablerades i avsnittet Distribuera WLS på AKS.
  2. Öppna AKS-klustret som visas i resursgruppen.
  3. Välj Stoppa för att stoppa AKS-klustret. Kontrollera att distributionen är klar innan du går vidare.

Använd sedan följande steg för att redundansväxla 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 det sekundära klustret.

  1. Öppna Azure Portal och gå till resursgruppen som har AKS-kluster i den sekundära regionen.
  2. Öppna AKS-klustret som visas i resursgruppen.
  3. Välj Starta för att starta AKS-klustret. Kontrollera att distributionen är klar innan du går vidare.

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:

    Skärmbild av exempelprogrammets användargränssnitt efter redundansväxlingen.

    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.

Anteckning

En produktionsklar HA/DR-lösning skulle kunna hantera kontinuerlig kopiering av WLS-konfigurationen från det primära till det sekundära klustret enligt ett regelbundet schema. Information om hur du gör detta finns i referenserna till Oracle-dokumentationen i slutet av den här artikeln.

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

Om du vill återställa till den primära platsen måste du se till att de två klustren har en speglingssäkerhetskonfiguration. Du kan uppnå det här tillståndet med hjälp av följande steg:

  1. Aktivera säkerhetskopieringar av AKS-kluster i regionen USA, västra 2 genom att följa stegen i avsnittet Konfigurera geo-redundans med Azure Backup från och med steg 4.
  2. Återställ den senaste säkerhetskopieringen på valvnivå till klustret i regionen USA, östra genom att följa stegen i avsnittet Förbered för att återställa WLS-klustret i en sekundär region . Hoppa över de steg som du redan har slutfört.
  3. Använd liknande steg i avsnittet Redundansväxling till den sekundära platsen för att återställa till den primära platsen, inklusive databasserver och kluster.

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. I sökrutan överst i Azure Portal anger du Säkerhetskopieringsvalv och väljer säkerhetskopieringsvalv från sökresultaten.
  2. Välj Hantera>egenskaper>Mjuk borttagningsuppdatering.> Avmarkera kryssrutan bredvid Aktivera mjuk borttagning.
  3. Välj Hantera>säkerhetskopieringsinstanser. Välj den instans som du skapade och ta bort den.
  4. 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.
  5. Välj Ta bort resursgrupp.
  6. I Ange resursgruppens namn för att bekräfta borttagningen anger du resursgruppens namn.
  7. Välj Ta bort.
  8. Upprepa steg 4–7 för resursgruppen i Traffic Manager – till exempel myResourceGroupTM1.
  9. Upprepa steg 4–7 för resursgruppen i det primära WLS-klustret – till exempel wls-aks-eastus-20240109.
  10. Upprepa steg 4–7 för resursgruppen för det sekundära WLS-klustret – till exempel wls-aks-westus-20240109.

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:

Haveriberedskapslösningar för Oracle Fusion Middleware-produkter

Dokumentation om Azure-tillförlitlighet

Skapa lösningar för hög tillgänglighet

Automatisk redundans med Azure Traffic Manager

Läs mer om Oracle WebLogic på virtuella Azure-datorer

Läs mer om Oracle WebLogic på AKS