disponibilitate ridicată utilizarea SQL Server întotdeauna pe grupuri de disponibilitate-BizTalk Server

• 01/14/2020
• 13 minute de citit
• • M
  • m
  • p
  • n
  • w
  • +8

configurați disponibilitatea ridicată utilizând SQL Server AlwaysOn grupuri de disponibilitate.

fundal și istorie

BizTalk Server se bazează foarte mult pe SQL Server pentru persistența datelor. Alte componente și gazde din BizTalk Server au roluri specifice atunci când integrează aplicații de afaceri disparate, cum ar fi primirea, procesarea sau rutarea mesajelor. Computerul bazei de date captează această lucrare și o persistă pe disc.

BizTalk utilizează SQL Server Failover Clustering și log Shipping pentru a oferi disponibilitate ridicată, backup și restaurare și recuperare în caz de dezastru pentru bazele sale de date locale. În Azure IaaS (Azure virtual machines), versiunile anterioare ale SQL Server nu acceptă instanțe de cluster Failover (fără suport MSDTC). Drept urmare, BizTalk nu a avut o soluție HA atunci când a utilizat Azure VMs.

începând cu SQL Server 2016, SQL Server AlwaysOn disponibilitate grupuri acceptă MSDTC pentru local și folosind Azure VMs. Ca rezultat, caracteristica SQL Server 2016 AlwaysOn este acceptată pentru bazele de date BizTalk on-premises sau în scenariile Azure IaaS.

SQL Server 2016 grupuri de disponibilitate AlwaysOn

implementarea grupurilor de disponibilitate AlwaysOn necesită un cluster Windows Server Failover Clustering (WSFC). Fiecare replică de disponibilitate a unui grup de disponibilitate dat trebuie să se afle pe un nod diferit al aceluiași cluster WSFC. Un grup de resurse WSFC este creat pentru fiecare grup de disponibilitate pe care îl creați. Clusterul WSFC monitorizează acest grup de resurse pentru a evalua starea de sănătate a replicii primare.

următoarea ilustrație prezintă un grup de disponibilitate care conține o replică primară și patru replici secundare.

clienții se pot conecta la replica primară a unui grup de disponibilitate dat folosind un ascultător de grup de disponibilitate. Un ascultător de grup de disponibilitate oferă un set de resurse care sunt atașate unui grup de disponibilitate dat pentru a direcționa conexiunile Clientului către replica de disponibilitate corespunzătoare.

SQL Server nu acceptă MSDTC cu AlwaysOn AG pentru nicio versiune anterioară anului 2016.

oferiți disponibilitate ridicată pentru bazele de date BizTalk utilizând grupurile de disponibilitate AlwaysOn

în configurația de bază a BizTalk Server, sunt create minimum 9 baze de date, inclusiv reguli și baze de date BAM.

într-un scenariu MessageBox scalat (o configurație cu mai multe MessageBox), există mai multe baze de date MessageBox și fiecare bază de date MessageBox trebuie adăugată la grupul de disponibilitate.

BizTalk Server depinde, de asemenea, de SQL Server Analysis Services și SQL Server Integration Services pentru analiza BAM și arhivare. SQL Server nu oferă o soluție de înaltă disponibilitate pentru Servicii de integrare sau servicii de analiză în Azure IaaS. Prin urmare, este recomandat să utilizați o altă instanță SQL Server independent pentru bazele de date Bamarchive și Bamanalysis Analysis Services. Pentru instalările locale, instanța de Clustering SQL Failover poate fi utilizată pentru configurarea unei configurații de disponibilitate ridicată.

pentru BizTalk Server 2016 și mai vechi, această configurație este prezentată în următoarea imagine și recomandată pentru bazele de date BizTalk în grupurile de disponibilitate:

începând cu BizTalk Server 2020 și mai nou, disponibilitatea ridicată pentru pachetele BAM DTS este acceptată folosind catalogul SSIS. Adăugați baza de date SSISDB la același grup de disponibilitate ca bazele de date BizTalk Server. Această configurație este prezentată în următoarea imagine și recomandată pentru bazele de date BizTalk din grupurile de disponibilitate:

în plus față de bazele de date SQL Server, configurația BizTalk Server creează, de asemenea, login-uri de securitate SQL Server și locuri de muncă SQL Agent. Grupurile de disponibilitate AlwaysOn oferă doar posibilitatea de a gestiona bazele de date în interiorul unui grup de disponibilitate. Pe toate replicile disponibilitate, BizTalk Server logins și SQL Agent de locuri de muncă trebuie să fie create și actualizate manual.

următoarea listă de login-uri de securitate SQL Server sunt asociate cu BizTalk Server. Este posibil să aveți autentificări suplimentare create pentru aplicațiile BizTalk Server. Dacă da, trebuie să le reproduceți pe fiecare instanță a SQL Server care găzduiește o replică a bazelor de date BizTalk.

1. utilizatorii aplicației BizTalk (unul sau mai mulți corespunzători fiecărei gazde in-proc)
2. BizTalk utilizatori gazdă izolați (unul sau mai mulți corespunzători fiecărei gazde izolate)
3. administratorii serverului BizTalk
4. operatorii B2B ai serverului BizTalk
5. operatorii serverului BizTalk
6. SSO administratori
7. Bam alerte utilizator
8. Bam Management Web Service utilizator
9. regula motor actualizare serviciu cont

dacă ați creat gazde suplimentare sau va crea gazde suplimentare mai târziu, vor exista noi login SQL create ca parte a acest proces. Trebuie să vă asigurați că creați manual aceste Conectări SQL pe replicile corespunzătoare.

următoarele locuri de muncă SQL Server Agent sunt asociate cu BizTalk Server. Lucrările instalate pe fiecare server sunt diferite în funcție de caracteristicile instalate și configurate. Cele mai multe dintre aceste locuri de muncă sunt create în timpul configurației BizTalk Server. Mai multe sunt create la configurarea log shipping. Aceste locuri de muncă trebuie să fie reproduse pe fiecare instanță de SQL Server hosting replica bazei lor de date BizTalk corespunzătoare. Acest lucru trebuie efectuat manual.

• BizTalkMgmtDb jobs:
  • Backup BizTalk Server (BizTalkMgmtDb)
  • CleanupBTFExpiredEntriesJob_BizTalkMgmtDb
  • Monitor BizTalk Server (BizTalkMgmtDb)
• BizTalkMsgBoxDb jobs:
  • MessageBox_DeadProcesses_Cleanup_BizTalkMsgBoxDb
  • MessageBox_Message_Cleanup_BizTalkMsgBoxDb
  • MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb
  • MessageBox_Parts_Cleanup_BizTalkMsgBoxDb
  • MessageBox_UpdateStats_BizTalkMsgBoxDb
  • Operations_OperateOnInstances_OnMaster_BizTalkMsgBoxDb
  • PurgeSubscriptionsJob_BizTalkMsgBoxDb
  • TrackedMessages_Copy_BizTalkMsgBoxDb
• Jobs on additional msgboxes
• BizTalkDTADb job:
  • epurare și arhivare DTA (BizTalkDTADb)
• BizTalkRulesEngineDb de locuri de muncă:
  • Rules_Database_Cleanup_BizTalkRuleenginedb
• BAMAlertsApplication job:
  • 0 sau mai multe DelAlertHistJob

spre deosebire de instanțele de grupare SQL Failover, în grupurile de disponibilitate toate replicile sunt active, rulate și disponibile. Când joburile SQL Agent sunt duplicate pe fiecare replică pentru failover, acestea rulează împotriva replicii corespunzătoare, indiferent dacă este în prezent în rol primar sau rol secundar. Pentru a vă asigura că aceste lucrări sunt executate numai pe replica primară curentă, fiecare pas din fiecare lucrare trebuie să fie închis într-un bloc IF, așa cum se arată:

IF (sys.fn_hadr_is_primary_replica('dbname') = 1) BEGIN … END

înlocuiți 'dbname' cu numele bazei de date corespunzătoare față de care jobul este configurat să ruleze. Următorul exemplu arată această modificare Pentru TrackedMessages_Copy_BizTalkMsgBoxdb pe BizTalkMsgBoxDb:

configurați BizTalk când grupurile de disponibilitate sunt deja configurate

1. verificați cerințele sistemului de operare:
   • pe toate computerele Windows Server 2012 R2, instalați remedierea rapidă 3090973 MSDTC (deschide un articol KB).
   • pe toate computerele Windows Server 2016, activați cheia de registry RemoteAccessEnabled (deschide un articol KB).
2. creați grupurile de disponibilitate necesare. Asigurați-vă că grupurile de disponibilitate sunt create cu opțiunea Suport DTC per bază de date.
3. când configurați BizTalk Server și specificarea SQL server name, utilizați numele ascultător disponibilitatea grupului în loc de numele mașinii reale. Acest lucru creează bazele de date BizTalk, datele de conectare, și SQL Agent de locuri de muncă pe replica primar curent.
4. opriți procesarea BizTalk (instanțe gazdă, serviciul SSO, IIS, serviciul de actualizare a motorului regulilor, serviciul BAMAlerts și așa mai departe) și opriți lucrările SQL Agent.
5. Acum adăugați bazele de date BizTalk la grupurile de disponibilitate respective.
6. includeți corp de SQL Agent pașii de locuri de muncă în IF bloc (menționat anterior) pentru a vă asigura că acestea se execută numai dacă ținta este replica primar.
7. login Script și SQL Agent de locuri de muncă pentru a le reproduce pe replica corespunzătoare.
8. replicați profilul SQL DBMAIL și contul pentru alertele BAM pe instanțele SQL corespunzătoare care găzduiesc replica secundară.
9. dacă adăugați o bază de date casetă de mesaje suplimentară sau implementați o nouă activitate/vizualizare BAM mai târziu, atunci sunt create noi lucrări SQL pentru baze de date casetă de mesaje noi sau baza de date alerte BAM pe replica principală curentă. Asigurați-vă că pentru a edita pe replica primar, și apoi creați-le manual pe replici secundare corespunzătoare.
10. începând cu BizTalk Server 2020 și mai noi, pachetele BAM DTS sunt implementate în catalogul SSIS. Adăugați baza de date SSISDB la același grup de disponibilitate ca bazele de date BizTalk. Pentru mai multe informații, consultați catalogul AlwaysOn pentru SSIS.

această configurație se poate face și folosind instanțele SQL care găzduiesc replica primară. În acest caz, după configurația BizTalk, executați scripturile UpdateDatabase.vbs și UpdateRegistry.vbs pe mașinile BizTalk după pașii de mai sus. Acest lucru este discutat mai detaliat în secțiunea următoare.

mutați bazele de date BizTalk existente în grupuri de disponibilitate

1. verificați cerințele sistemului de operare:

   • pe toate computerele Windows Server 2012 R2, instalați remedierea rapidă 3090973 MSDTC (deschide un articol KB)
   • pe toate computerele Windows Server 2016, activați cheia de registry RemoteAccessEnabled (deschide un articol KB)

2. creați grupurile de disponibilitate necesare. Asigurați-vă că grupul de disponibilitate este creat cu opțiunea de asistență pentru DTC Per Database.

3. opri procesarea BizTalk și SQL Agent de locuri de muncă.

4. efectuați o copie de rezervă completă a tuturor bazelor de date BizTalk.

5. restaurați bazele de date BizTalk pe instanțele SQL aflate în prezent în rolul principal în grupul de disponibilitate.

6. login-uri Script și SQL Agent de locuri de muncă pe instanțe SQL corespunzătoare în prezent în rolul principal în grupul de disponibilitate.

7. rulați scripturile UpdateDatabase.vbs și UpdateRegistry.vbs pe mașinile BizTalk utilizând pașii următori. Introduceți ascultătorul grupului de disponibilitate ca nume de server nou în xml informații actualizare intrare.

   1. Opriți toate serviciile BizTalk și serviciile SSO Enterprise pe BizTalk Server. Opriți serviciul SQL Agent pe SQL Server.

   2. pe BizTalk Server, edita SampleUpdateInfo.xml în următorul folder:

      computer pe 32 de biți: %SystemRoot%\Program Files\Microsoft BizTalk Server 20xx\Schema\Restore

      64-bit computer: %SystemRoot%\Program Files (x86)\Microsoft BizTalk Server 20xx\Bins32\Schema\Restore

      1. înlocuiți „SourceServer” cu numele serverului sursă (SQL Server vechi care găzduiește baze de date vechi).
      2. înlocuiți „DestinationServer” cu numele serverului de destinație, care ar trebui să fie numele ascultătorului grupului de disponibilitate.
      3. dacă aveți bamanalysis, baze de date BAM sau RuleEngineDB, decomentați secțiunile corespunzătoare.

   3. deschideți un prompt de comandă și accesați:

      computer pe 32 de biți: %SystemRoot%\Program Files\Microsoft BizTalk Server 20xx\Schema\Restore

      64-bit computer: %SystemRoot%\Program Files (x86)\Microsoft BizTalk Server 20xx\Bins32\Schema\Restore

      la promptul de comandă, executați:
      cscript UpdateDatabase.vbs SampleUpdateInfo.xml

      rulați UpdateDatabase.vbs pe un singur server din grupul BizTalk.

   4. copiați eșantionul editatupdateinfo.fișier xml în următorul folder de pe fiecare computer BizTalk Server din acest grup BizTalk:

      computer pe 32 de biți: %SystemRoot%\Program Files\Microsoft BizTalk Server 20xx\Schema\Restore

      64-bit computer: %SystemRoot%\Program Files (x86)\Microsoft BizTalk Server 20xx\Bins32\Schema\Restore

   5. pe fiecare computer din grupul BizTalk Server, deschideți un prompt de comandă și accesați:

      computer pe 32 de biți: %SystemRoot%\Program Files\Microsoft BizTalk Server 20xx\Schema\Restore

      64-bit computer: %SystemRoot%\Program Files (x86)\Microsoft BizTalk Server 20xx\Bins32\Schema\Restore

      la promptul de comandă, executați:
      cscript UpdateRegistry.vbs SampleUpdateInfo.xml

      rulați UpdateRegistry.vbs pe fiecare server din grupul BizTalk.

8. acum mutați bazele de date în grupurile de disponibilitate respective.

9. replicați profilul SQL DBMAIL și contul pentru alertele BAM pe instanțele SQL care găzduiesc replica bazei de date BAMAlerts.

10. includeți corpul pașilor de lucru SQL Agent într-un bloc IF pentru a vă asigura că se execută numai dacă ținta este primară.

11. login Script și SQL Agent de locuri de muncă pentru a le reproduce pe replica corespunzătoare. Scriptul UpdateDatabase actualizează, de asemenea, numele serverului în lucrările Operations_OperateOnInstances_Onmaster_biztalkmsgboxdb și TrackedMessages_Copy_BizTalkMsgBoxdb. Deci script agentul SQL funcționează numai după rularea scriptului UpdateDatabase.

cerințe

• BizTalk Server:
  • BizTalk Server 2020 Enterprise
  • BizTalk Server 2016 Enterprise CU5
• SQL Server:

  • SQL Server 2019 Enterprise sau Standard

  • SQL Server 2017 Enterprise sau Standard

  • SQL Server 2016 Enterprise sau Standard.

    consultați limitările cunoscute din acest articol pentru limitarea SQL Server Standard Edition.

• Windows Server
  • Windows Server 2019
  • Windows Server 2016
  • Windows Server 2012 R2

disponibilitate grup ascultător configurat cu port non-implicit (1433)

utilizați alias SQL pe BizTalk mașini Server.

support Availability Group Multi-Subnet Failovers

BizTalk Server utilizează Microsoft OLE DB pentru conexiuni de baze de date, care nu acceptă opțiunea de conectare MultiSubnetFailover. BizTalk Server nu acceptă opțiunea de conectare MultiSubnetFailover (=TRUE), iar acest lucru poate cauza timp de recuperare mai mare în timpul failover multi-subrețea.

rutare numai în citire

rutare numai în citire se referă la capacitatea SQL Server de a ruta conexiunile primite pentru un ascultător de grup de disponibilitate la o replică secundară care este configurată pentru a permite sarcini de lucru numai în citire.

BizTalk nu utilizează rutare numai în citire pentru oricare dintre conexiunile la bazele sale de date. Aceasta înseamnă că opțiunea „secundar lizibil” privind replicile de disponibilitate din grupul de disponibilitate nu are niciun impact asupra conexiunilor bazei de date BizTalk.

comportamentul BizTalk instanțe gazdă în timpul SQL Server Failover

în cazul în care grupul de disponibilitate SQL Server experiențe un failover, bazele de date BizTalk Server pe grupul de disponibilitate sunt temporar indisponibile.

comportamentul instanțelor gazdă în proces în timpul SQL Server Failover

dacă bazele de date BizTalk Server nu sunt disponibile, apoi o instanță în proces de o gazdă BizTalk Server este reciclat până când conexiunea la SQL Server este restabilită. Odată ce conexiunea la bazele de date SQL Server este restabilită, procesarea documentelor se reia în mod normal.

comportamentul de instanțe gazdă izolate în timpul SQL Server Failover

dacă bazele de date BizTalk Server nu sunt disponibile, apoi o instanță izolată de o gazdă BizTalk Server pauze, și o eroare similară cu următoarele este generat în Jurnalul de aplicații BizTalk Server:

All receive locations are being temporarily disabled because either the MessageBox or Configuration database is not available. When these databases become available, the receive locations will be automatically enabled.

odată ce conexiunea la bazele de date SQL Server este restabilită, un mesaj Informațional similar cu următorul text este scris în Jurnalul de aplicații BizTalk Server și apoi procesarea documentelor se reia în mod normal:

All receive locations are being enabled because both the MessageBox and Configuration databases are back online.

jurnal de transport maritim pentru recuperare în caz de dezastru

BizTalk Server implementează capabilități de standby de baze de date prin utilizarea de transport maritim jurnal de baze de date. BizTalk Server log shipping automatizează backup și restaurare a bazelor de date și a fișierelor jurnal de tranzacții, permițând unui server standby să reia procesarea bazei de date în cazul în care serverul bazei de date de producție eșuează.

bazele de date secundare din grupul de disponibilitate nu sunt copii de rezervă. Continuați să faceți backup bazelor de date BizTalk și jurnalele lor de tranzacții utilizând joburile de expediere BizTalk Server log. Modul în care BizTalk log Shipping este implementat asigură că copiile de rezervă sunt întotdeauna efectuate împotriva replica primară curentă a fiecărei baze de date. Setarea preferințelor de rezervă din grupul de disponibilitate nu este onorată de lucrările de expediere a Jurnalului BizTalk Server.

dacă adăugați alte baze de date BizTalk la lucrarea de backup a bazelor de date BizTalk, asigurați-vă că utilizați numele ascultătorului grupului de disponibilitate ca server de baze de date pentru acestea atunci când configurați copia de rezervă.

• furnizarea de disponibilitate ridicată pentru BizTalk baze de date Server
• suport software Microsoft server pentru Microsoft Azure mașini virtuale
• SQL Server baza de date mirroring, Volume Shadow Copy service și AlwaysOn
• Prezentare generală a grupurilor de disponibilitate AlwaysOn (SQL Server)
• tranzacții Cross-Database suport pentru (SQL Server)
• reenlist nu poate fi apelat atunci când SQL Server primește rezultatul tranzacției de la MSDTC în Windows Server 2012 R2
• backup și restaurarea BizTalk Server Baze de date
• cum să mutați bazele de date BizTalk Server
• cum să restaurați bazele de date
• timeout-uri de conectare în grupul de disponibilitate Multi-subrețea

limitări cunoscute

aceste limitări sunt pentru BizTalk Server, SQL Server AlwaysOn Availability Group și Azure Virtual Machines. Aceste limitări pot sau nu pot fi abordate în viitor.

• conectările, lucrările SQL Agent, profilul SQL DB Mail și conturile nu sunt gestionate în cadrul grupurilor de disponibilitate. Acest lucru necesită modificarea manuală în locuri de muncă pentru a vă asigura că se execută împotriva replica primar.

• SQL Server Analysis Services și SQL Server Integration Services nu participă la grupurile de disponibilitate. Fără acest suport de la SQL Server, nu există nici o soluție HA pentru acestea în mașinile virtuale Azure. Capabilitățile bam ale BizTalk Server depind de aceste servicii.

• înainte de SQL Server 2016 SP2, grupurile de disponibilitate nu acceptă MSDTC între bazele de date pe aceeași instanță SQL.

  începând cu SQL Server 2016 SP2 și BizTalk Server 2016 CU5, bazele de date BizTalk pot utiliza aceeași instanță SQL Server.

• BizTalk Server nu poate utiliza rutare numai în citire.

• BizTalk Server nu stabilește MultiSubnetFailover proprietate conexiune.

• BizTalk Backup Jobs folosind log Shipping va viza întotdeauna replica primară, indiferent de preferința de rezervă setată pe grupul de disponibilitate.

• SQL Server 2016 Standard acceptă doar o singură bază de date în fiecare SQL AlwaysOn AG. Deoarece BizTalk utilizează mai multe baze de date, SQL Server Enterprise edition este de obicei recomandat.

• dacă utilizați Azure VMs, este recomandat să utilizați un port dedicat TCP/IP fix pentru MSDTC. Când utilizați un port TCP/IP fix, nu vă limitați gama de porturi RPC utilizate în mod obișnuit cu sistemele de operare mai vechi; și vă ajută să simplificați regulile firewall și load balancer. Pentru a evita conflictele cu porturile inferioare cunoscute, luați în considerare utilizarea unui port fix mai mare (cum ar fi >20000). Configurarea suportului pentru un singur Port DTC descrie cheia de registry ServerTcpPort. În plus față de portul fix pentru MSDTC, se utilizează și portul principal RPC 135.

planul de toleranță la erori.