Freigeben über

Hohe Verfügbarkeit mit SQL Server AlwaysOn-Verfügbarkeitsgruppen – BizTalk Server

Konfigurieren Sie hohe Verfügbarkeit mithilfe von SQL Server AlwaysOn-Verfügbarkeitsgruppen.

Tipp

Das Einrichten von BizTalk Server 2016 mithilfe von Verfügbarkeitsgruppen LAB bietet eine schrittweise Anleitung, die von einem Microsoft-Feldtechniker geschrieben wurde. Sie basiert auf einer Laborumgebung und enthält einige Beobachtungen. Schauen Sie es sich an.

Von Bedeutung

  • BizTalk Server unterstützt AlwaysOn-Verfügbarkeitsgruppen ab SQL Server 2016 und höher. Wenn Sie eine frühere SQL Server-Version verwenden, gilt dieser Artikel nicht für Sie.
  • BizTalk Server unterstützt synchronen Commit-Modus; Der asynchrone Commit-Modus wird nicht unterstützt. Für die Notfallwiederherstellung wird empfohlen, den Sicherungs-BizTalk Server-Auftrag zu konfigurieren und den Protokollversand zu verwenden. Spezifische Details finden Sie unter Sichern und Wiederherstellen von BizTalk Server-Datenbanken .

Verfügbarkeitsmodi zeigen die Commitoptionen mit AlwaysOn-Verfügbarkeitsgruppen an.

Hintergrund und Verlauf

BizTalk Server basiert stark auf SQL Server für die Datenpersistenz. Andere Komponenten und Hosts in BizTalk Server verfügen über bestimmte Rollen beim Integrieren unterschiedlicher Geschäftsanwendungen, z. B. Empfangen, Verarbeiten oder Weiterleiten von Nachrichten. Der Datenbankcomputer erfasst diese Arbeit und speichert sie auf dem Datenträger.

BizTalk verwendet SQL Server-Failoverclustering und Protokollversand, um hohe Verfügbarkeit, Sicherung und Wiederherstellung sowie Notfallwiederherstellung für seine Datenbanken bereitzustellen. In Azure IaaS (virtuelle Azure-Computer) unterstützte BizTalk (Windows und SQL) früher keine Failover-Cluster-Instanzen, da es keine unterstützten freigegebenen Datenträger gab, die für das Clustering von SQL und MSDTC erforderlich sind. Daher hat BizTalk keine HA-Lösung bei verwendung von Azure-VMs. Da Azure Shared Disk jetzt verfügbar ist, ist es möglich, SQL und MSDTC in Azure-VMs zu clustern. SQL-Failoverclusterinstanz mit Azure Shared Disks ist die höchst verfügbare Lösung.

Ab SQL Server 2016 unterstützen SQL Server AlwaysOn-Verfügbarkeitsgruppen MSDTC für lokale Bereitstellung und die Verwendung von Azure-VMs. Das SQL Server 2016-Feature (oder höher) AlwaysOn wird daher für lokale BizTalk-Datenbanken oder in Azure IaaS-Szenarien unterstützt. Da bei der Verwendung von Storage Spaces Direct (S2D) ein zusätzlicher Aufwand durch synchrone Festplattensynchronisation und zusätzliche Zeit bei Failovers entsteht, ist es im Vergleich zur SQL-Failoverclusterinstanz weniger hochverfügbar.

SQL Server 2016 AlwaysOn-Verfügbarkeitsgruppen

Für die Bereitstellung von AlwaysOn-Verfügbarkeitsgruppen ist ein Windows Server-Failoverclustering (WSFC)-Cluster erforderlich. Jedes Verfügbarkeitsreplikat einer bestimmten Verfügbarkeitsgruppe muss sich auf einem anderen Knoten desselben WSFC-Clusters befinden. Für jede erstellte Verfügbarkeitsgruppe wird eine WSFC-Ressourcengruppe erstellt. Der WSFC-Cluster überwacht diese Ressourcengruppe, um den Status des primären Replikats auszuwerten.

In der folgenden Abbildung ist eine Verfügbarkeitsgruppe dargestellt, die ein primäres Replikat und vier sekundäre Replikate enthält.

Primäres Replikat in SQL AlwaysOn-Verfügbarkeitsgruppe mit BizTalk Server

Clients können mithilfe eines Verfügbarkeitsgruppenlisteners eine Verbindung mit dem primären Replikat einer bestimmten Verfügbarkeitsgruppe herstellen. Ein Verfügbarkeitsgruppenlistener stellt eine Reihe von Ressourcen bereit, die einer bestimmten Verfügbarkeitsgruppe zugeordnet sind, um Clientverbindungen zum entsprechenden Verfügbarkeitsreplikat zu leiten.

Von Bedeutung

SQL Server 2016 unterstützt MSDTC mit AlwaysOn Availability Groups (AG) unter Windows Server 2016 und Windows Server 2012 R2. Windows Server 2012 R2 erfordert die Installation des 3090973 Windows-Hotfixes. Windows Server 2016 erfordert, dass der RemoteAccessEnabled-Registrierungsschlüssel aktiviert ist.

SQL Server unterstützt MSDTC mit AlwaysOn AG für alle Versionen vor 2016 nicht. SQL Server 2016 SP2 verbesserte MSDTC-Transaktionsbehandlung, sodass SP2 oder höher empfohlen wird.

Bereitstellen einer hohen Verfügbarkeit für BizTalk-Datenbanken mithilfe von AlwaysOn-Verfügbarkeitsgruppen

In der Grundlegenden Konfiguration von BizTalk Server werden mindestens 9 Datenbanken erstellt, einschließlich Rules- und BAM-Datenbanken.

Vor SQL Server 2016 SP2 haben Verfügbarkeitsgruppen MSDTC zwischen Datenbanken derselben SQL-Instanz nicht unterstützt, sodass BizTalk-Datenbanken mindestens über 4 SQL-Instanzen verteilt werden mussten. Aufgrund dieser Einschränkung wird empfohlen, SQL Server 2016 SP2 (oder höher) und BizTalk Server 2016 CU5 (oder höher) zu verwenden, damit alle BizTalk-Datenbanken dieselbe SQL Server-Instanz verwenden können. Möglicherweise können Sie aus Leistungsgründen immer noch mehrere SQL-Instanzen verwenden (z. B. das MessageBox-Element in einer anderen SQL-Instanz).

In einem skalierten MessageBox-Szenario, einer Konfiguration mit mehr als einer MessageBox, gibt es mehr als eine MessageBox-Datenbank, und jede MessageBox-Datenbank muss der Verfügbarkeitsgruppe hinzugefügt werden.

BizTalk Server hängt auch von SQL Server Analysis Services und SQL Server Integration Services für BAM-Analyse und -Archivierung ab. SQL Server bietet keine Hochverfügbarkeitslösung für Integration Services oder Analysis Services in Azure IaaS. Daher wird empfohlen, eine andere eigenständige SQL Server-Instanz für die DATENBANKEN BAMArchive und BAMAnalysis Analysis Services zu verwenden. Bei lokalen Installationen kann die SQL-Failoverclusteringinstanz zum Einrichten einer Hochverfügbarkeitskonfiguration verwendet werden.

Für BizTalk Server 2016 wird diese Konfiguration in der folgenden Abbildung dargestellt und für BizTalk-Datenbanken in Verfügbarkeitsgruppen empfohlen (wie oben erwähnt, ab SQL 2016 SP2 und BizTalk 2016 CU5 sind 4 SQL-Instanzen nicht mehr erforderlich):

Empfohlene Always On SQL Server-Konfiguration in BizTalk Server 2016 und älteren Versionen

Ab BizTalk Server 2020 wird hohe Verfügbarkeit für BAM DTS-Pakete mithilfe des SSIS-Katalogs unterstützt. Fügen Sie die SSISDB-Datenbank derselben Verfügbarkeitsgruppe wie die BizTalk Server-Datenbanken hinzu. Diese Konfiguration wird in der folgenden Abbildung dargestellt und für BizTalk-Datenbanken in Verfügbarkeitsgruppen empfohlen (wie oben erwähnt, sind 4 SQL-Instanzen nicht mehr erforderlich):

Empfohlene Always On-Konfiguration für SQL Server auf BizTalk Server 2020 und neueren Versionen

Zusätzlich zu den SQL Server-Datenbanken erstellt die BizTalk Server-Konfiguration auch SQL Server-Sicherheitsanmeldungen und SQL-Agent-Aufträge. AlwaysOn-Verfügbarkeitsgruppen bieten nur die Möglichkeit, Datenbanken innerhalb einer Verfügbarkeitsgruppe zu verwalten. Bei allen Verfügbarkeitsreplikaten müssen die BizTalk Server-Anmeldungen und SQL-Agent-Aufträge manuell erstellt und aktualisiert werden.

Die folgende Liste der SQL Server-Sicherheitsanmeldungen ist BizTalk Server zugeordnet. Möglicherweise haben Sie zusätzliche Anmeldungen für Ihre BizTalk Server-Anwendungen erstellt. In diesem Fall müssen Sie sie auf jeder Instanz von SQL Server replizieren, die ein Replikat von BizTalk-Datenbanken hosten.

  1. BizTalk-Anwendungsbenutzer (mindestens einer, der jedem In-Proc-Host entspricht)
  2. BizTalk-isolierte Hostbenutzer (einer oder mehrere, entsprechend jedem isolierten Host)
  3. BizTalk Server-Administratoren
  4. BizTalk Server B2B-Operatoren
  5. BizTalk Server-Operatoren
  6. SSO-Administratoren
  7. BAM-Benachrichtigungsbenutzer
  8. BAM-Verwaltungswebdienstbenutzer
  9. Updatedienstkonto des Regelmoduls

Wenn Sie zusätzliche Hosts erstellt haben oder später zusätzliche Hosts erstellen, werden im Rahmen dieses Prozesses neue SQL-Anmeldungen erstellt. Sie müssen sicherstellen, dass Sie diese SQL-Anmeldungen manuell für die entsprechenden Replikate erstellen.

Die folgenden SQL Server-Agent-Aufträge sind BizTalk Server zugeordnet. Die auf jedem Server installierten Aufträge unterscheiden sich je nachdem, welche Features installiert und konfiguriert sind. Die meisten dieser Aufträge werden während der BizTalk Server-Konfiguration erstellt. Beim Konfigurieren des Protokollversands werden mehrere erstellt. Diese Aufträge müssen auf jeder Instanz des SQL Server-Hostingreplikats ihrer entsprechenden BizTalk-Datenbank repliziert werden. Dies muss manuell ausgeführt werden.

  • BizTalkMgmtDb-Aufträge:
    • BizTalk Server sichern (BizTalkMgmtDb)
    • CleanupBTFExpiredEntriesJob_BizTalkMgmtDb
    • Überwachen von BizTalk Server (BizTalkMgmtDb)
  • BizTalkMsgBoxDb-Aufträge:
    • MessageBox_AbgestorbeneProzesse_Cleanup_BizTalkMsgBoxDb
    • MessageBox_Message_Cleanup_BizTalkMsgBoxDb
    • MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb
    • Bereinigung von Teilen in der BizTalk-Nachrichtendatenbank (MessageBox_Parts_Cleanup_BizTalkMsgBoxDb)
    • MessageBox_UpdateStats_BizTalkMsgBoxDb
    • Operations_OperateOnInstances_OnMaster_BizTalkMsgBoxDb
    • PurgeSubscriptionsJob_BizTalkMsgBoxDb
    • TrackedMessages_Copy_BizTalkMsgBoxDb
  • Aufträge für zusätzliche Nachrichtenboxen
  • BizTalkDTADb-Auftrag:
    • DTA-Bereinigung und Archiv (BizTalkDTADb)
  • BizTalkRulesEngineDb-Auftrag:
    • Rules_Database_Cleanup_BizTalkRuleEngineDb
  • BAMAlertsApplication-Auftrag:
    • 0 oder mehr DelAlertHistJob

Im Gegensatz zu SQL-Failoverclusteringinstanzen sind in Verfügbarkeitsgruppen alle Replikate aktiv, ausgeführt und verfügbar. Wenn SQL-Agent-Aufträge für das Failover für jedes Replikat dupliziert werden, werden sie für das entsprechende Replikat ausgeführt, unabhängig davon, ob es sich derzeit in der primären oder sekundären Rolle befindet. Um sicherzustellen, dass diese Aufträge nur für das aktuelle primäre Replikat ausgeführt werden, muss jeder Schritt in jedem Auftrag in einen WENN-Block eingeschlossen werden, wie gezeigt:

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

Ersetzen Sie durch ‘dbname’ den entsprechenden Datenbanknamen, für den der Auftrag für die Ausführung konfiguriert ist. Das folgende Beispiel zeigt diese Änderung für TrackedMessages_Copy_BizTalkMsgBoxDb in BizTalkMsgBoxDb:

Ändern des Namens des SQL-Agent-Auftrags in der AlwaysOn-Verfügbarkeitsgruppe mit BizTalk Server

Konfigurieren von BizTalk, wenn Verfügbarkeitsgruppen bereits eingerichtet sind

  1. Überprüfen Sie Ihre Betriebssystemanforderungen:
  2. Erstellen Sie die erforderlichen Verfügbarkeitsgruppen. Stellen Sie sicher, dass die Verfügbarkeitsgruppen mit der Option "Pro Datenbank DTC-Unterstützung" erstellt werden.
  3. Wenn Sie BizTalk Server konfigurieren und den SQL Server-Namen angeben, verwenden Sie den Listenernamen der Verfügbarkeitsgruppe anstelle des tatsächlichen Computernamens. Dadurch werden die BizTalk-Datenbanken, Anmelde- und SQL-Agent-Aufträge für das aktuelle primäre Replikat erstellt.
  4. Beenden Sie die BizTalk-Verarbeitung (Hostinstanzen, SSO-Dienst, IIS, Updatedienst des Regelmoduls, BAMAlerts-Dienst usw.), und beenden Sie die SQL-Agent-Aufträge.
  5. Fügen Sie nun BizTalk-Datenbanken zu den jeweiligen Verfügbarkeitsgruppen hinzu.
  6. Schließen Sie den Inhalt der SQL-Agent-Auftragsschritte innerhalb des IF-Blocks ein, wie oben erwähnt, um sicherzustellen, dass sie nur ausgeführt werden, wenn das Ziel die primäre Replik ist.
  7. Skripts für Anmeldungen und SQL-Agent-Aufträge zum Replizieren auf den jeweiligen Replikaten.
  8. Replizieren Sie SQL DBMail-Profil und Konto für BAM-Warnungen auf entsprechenden SQL-Instanzen, die das sekundäre Replikat hosten.
  9. Wenn Sie eine zusätzliche Nachrichtenfelddatenbank hinzufügen oder später eine neue BAM-Aktivität/Ansicht bereitstellen, werden neue SQL-Aufträge für neue Nachrichtenfelddatenbanken oder BAM-Warnungsdatenbanken im aktuellen primären Replikat erstellt. Stellen Sie sicher, dass Sie es im primären Replikat bearbeiten und dann manuell für die entsprechenden sekundären Replikate erstellen.
  10. Ab BizTalk Server 2020 und neuer werden BAM DTS-Pakete im SSIS-Katalog bereitgestellt. Fügen Sie die SSISDB-Datenbank derselben Verfügbarkeitsgruppe wie die BizTalk-Datenbanken hinzu. Weitere Informationen finden Sie im AlwaysON für SSIS-Katalog.

Diese Konfiguration kann auch mithilfe der SQL-Instanzen erfolgen, die das primäre Replikat hosten. Führen Sie in diesem Fall nach der BizTalk-Konfiguration die UpdateDatabase.vbs Und UpdateRegistry.vbs Skripts auf den BizTalk-Computern nach den obigen Schritten aus. Dies wird im nächsten Abschnitt ausführlicher erläutert.

Verschieben vorhandener BizTalk-Datenbanken in Verfügbarkeitsgruppen

  1. Überprüfen Sie Ihre Betriebssystemanforderungen:

  2. Erstellen Sie die erforderlichen Verfügbarkeitsgruppen. Stellen Sie sicher, dass die Verfügbarkeitsgruppen mit der Option Pro Datenbank DTC Unterstützung erstellt werden.

  3. Beenden Sie die BizTalk-Verarbeitung und die SQL-Agent-Aufträge.

  4. Führen Sie die vollständige Sicherung aller BizTalk-Datenbanken aus.

  5. Stellen Sie BizTalk-Datenbanken auf den SQL-Instanzen wieder her, die momentan die primäre Rolle in der Verfügbarkeitsgruppe innehaben.

  6. Skriptanmeldungen und SQL-Agent-Aufträge für entsprechende SQL-Instanzen, die sich derzeit in der primären Rolle in der Verfügbarkeitsgruppe befinden.

  7. Führen Sie die Skripte UpdateDatabase.vbs und UpdateRegistry.vbs auf den BizTalk-Computern mit den folgenden Schritten aus. Geben Sie den Verfügbarkeitsgruppenlistener als neuen Servernamen in der Updateinformationen-XML-Eingabe ein.

    1. Beenden Sie alle BizTalk-Dienste und Enterprise-SSO-Dienste auf BizTalk Server. Beenden Sie den SQL-Agent-Dienst auf SQL Server.

    2. Bearbeiten Sie auf BizTalk Server SampleUpdateInfo.xml im folgenden Ordner:

      32-Bit-Computer: %SystemRoot%\Program Files\Microsoft BizTalk Server 20xx\Schema\Restore

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

      1. Ersetzen Sie "SourceServer" durch den Quellservernamen (alte SQL Server-Hostingdatenbanken).
      2. Ersetzen Sie "DestinationServer" durch den Namen des Zielservers, bei dem es sich um den Listenernamen der Verfügbarkeitsgruppe handeln soll.
      3. Wenn Sie über die BAMAnalysis-, BAM-Datenbanken oder RuleEngineDB verfügen, entfernen Sie die Kommentare zu den entsprechenden Abschnitten.

    3. Öffnen Sie eine Eingabeaufforderung, und wechseln Sie zu:

      32-Bit-Computer: %SystemRoot%\Program Files\Microsoft BizTalk Server 20xx\Schema\Restore

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

      Führen Sie an der Eingabeaufforderung Folgendes aus:
      cscript UpdateDatabase.vbs SampleUpdateInfo.xml

      Führen Sie UpdateDatabase.vbs nur auf einem Server in der BizTalk-Gruppe aus.

    4. Kopieren Sie die bearbeitete SampleUpdateInfo.xml Datei in den folgenden Ordner auf jedem BizTalk Server-Computer in dieser BizTalk-Gruppe:

      32-Bit-Computer: %SystemRoot%\Program Files\Microsoft BizTalk Server 20xx\Schema\Restore

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

    5. Öffnen Sie auf jedem Computer in der BizTalk Server-Gruppe eine Eingabeaufforderung, und wechseln Sie zu:

      32-Bit-Computer: %SystemRoot%\Program Files\Microsoft BizTalk Server 20xx\Schema\Restore

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

      Führen Sie an der Eingabeaufforderung Folgendes aus:
      cscript UpdateRegistry.vbs SampleUpdateInfo.xml

      Führen Sie UpdateRegistry.vbs auf jedem Server in der BizTalk-Gruppe aus.

  8. Verschieben Sie die Datenbanken nun in ihre jeweiligen Verfügbarkeitsgruppen.

  9. Replizieren Sie das SQL-DBMail-Profil und -Konto für BAM Alerts auf den SQL-Instanzen, die das Replikat der BAMAlerts-Datenbank hosten.

  10. Schließen Sie den Textkörper von SQL-Agent-Auftragsschritten in eine IF-Bedingung ein, um sicherzustellen, dass sie nur ausgeführt werden, wenn das Ziel der Primärserver ist.

  11. Skriptanmeldungen und SQL-Agent-Aufträge, um sie im entsprechenden Replikat zu replizieren. Das UpdateDatabase-Skript aktualisiert auch den Servernamen in den Operations_OperateOnInstances_OnMaster_BizTalkMsgBoxDb und TrackedMessages_Copy_BizTalkMsgBoxDb Aufträgen. SQL-Agent-Aufträge nur skripten, nachdem das UpdateDatabase-Skript ausgeführt wurde.

Anforderungen

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

    • SQL Server 2019 Enterprise oder Standard

    • SQL Server 2017 Enterprise oder Standard

    • SQL Server 2016 Enterprise oder Standard.

      Informationen zur Einschränkung der SQL Server Standard Edition finden Sie in diesem Artikel zu bekannten Einschränkungen .

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

Listener für Verfügbarkeitsgruppen, konfiguriert mit einem nicht standardmäßigen Port (1433)

Verwenden Sie SQL-Alias auf BizTalk Server-Computern.

Verfügbarkeitsgruppen für mehrere Subnetze

BizTalk Server unterstützt die MultiSubnetFailover(=TRUE)-Verbindungsoption nicht.

Weitere Informationen zu Problemen, die auftreten können, wenn Sie einen SQL-Client, der diese Option nicht unterstützt, mit einer Multi-Subnet-SQL-Verfügbarkeitsgruppe verbinden, finden Sie in der SQL-Dokumentation. Einige dieser Probleme werden in den folgenden Links behandelt:

Schreibgeschütztes Routing

Schreibgeschütztes Routing bezieht sich auf die Fähigkeit von SQL Server, eingehende Verbindungen für einen Verfügbarkeitsgruppenlistener an ein sekundäres Replikat weiterzuleiten, das für schreibgeschützte Workloads konfiguriert ist.

BizTalk verwendet nicht Read-Only Routing für verbindungen mit seinen Datenbanken. Dies bedeutet, dass die Option „Readable Secondary“ bei Verfügbarkeitsreplikaten in der Verfügbarkeitsgruppe keine Auswirkungen auf BizTalk-Datenbankverbindungen hat.

Verhalten von BizTalk-Hostinstanzen während des SQL Server-Failovers

Wenn die SQL Server-Verfügbarkeitsgruppe ein Failover erlebt, sind die BizTalk Server-Datenbanken in der Verfügbarkeitsgruppe vorübergehend nicht verfügbar.

Verhalten von In-Process Hostinstanzen während des SQL Server-Failovers

Wenn die BizTalk Server-Datenbanken nicht verfügbar sind, wird eine prozessinterne Instanz eines BizTalk Server-Hosts wiederverwendet, bis die Verbindung mit sql Server wiederhergestellt wird. Sobald die Verbindung mit den SQL Server-Datenbanken wiederhergestellt wurde, wird die Dokumentverarbeitung normal fortgesetzt.

Verhalten von isolierten Hostinstanzen während des SQL Server-Failovers

Wenn die BizTalk Server-Datenbanken nicht verfügbar sind, wird eine isolierte Instanz eines BizTalk Server-Hosts angehalten, und im BizTalk Server-Anwendungsprotokoll wird ein Fehler wie folgt generiert:

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.

Sobald die Verbindung mit den SQL Server-Datenbanken wiederhergestellt wurde, wird eine Informationsmeldung ähnlich dem folgenden in das BizTalk Server-Anwendungsprotokoll geschrieben, und die Dokumentverarbeitung wird normal fortgesetzt:

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

Logversand für Notfall-Wiederherstellung

BizTalk Server implementiert Die Datenbank-Standbyfunktionen mithilfe des Datenbankprotokollversands. Der BizTalk Server-Protokollversand automatisiert die Sicherung und Wiederherstellung von Datenbanken und deren Transaktionsprotokolldateien, sodass ein Standbyserver die Datenbankverarbeitung fortsetzen kann, wenn der Produktionsdatenbankserver fehlschlägt.

Sekundäre Datenbanken in der Verfügbarkeitsgruppe sind keine Sicherungen. Setzen Sie die Sicherung von BizTalk-Datenbanken und deren Transaktionsprotokollen mithilfe von BizTalk Server Log Shipping-Aufträgen fort. Die Art und Weise, wie bizTalk Log Shipping implementiert wird, stellt sicher, dass Sicherungen immer mit dem aktuellen primären Replikat jeder Datenbank ausgeführt werden. Die Sicherungseinstellung der Verfügbarkeitsgruppe wird von den BizTalk Server Log Shipping-Jobs nicht berücksichtigt.

Wenn Sie dem Sicherungsauftrag für BizTalk-Datenbanken weitere BizTalk-Datenbanken hinzufügen, stellen Sie sicher, dass Sie beim Einrichten der Sicherung den Namen des Verfügbarkeitsgruppen-Listeners als Datenbankserver verwenden.

References

Bekannte Einschränkungen

Diese Einschränkungen gelten für BizTalk Server, SQL Server AlwaysOn-Verfügbarkeitsgruppe und virtuelle Azure-Computer. Diese Einschränkungen können in Zukunft behoben werden oder nicht.

  • Anmeldungen, SQL-Agent-Aufträge, das SQL DB-E-Mail-Profil und Konten werden nicht in Verfügbarkeitsgruppen verwaltet. Dies erfordert manuelle Änderungen in Aufträgen, um sicherzustellen, dass sie für das primäre Replikat ausgeführt werden.

  • SQL Server Analysis Services und SQL Server Integration Services sind nicht an Verfügbarkeitsgruppen beteiligt. Ohne diese Unterstützung von SQL Server gibt es keine HA-Lösung für diese in virtuellen Azure-Computern. Die BAM-Funktionen von BizTalk Server sind von diesen Diensten abhängig.

  • Vor SQL Server 2016 SP2 unterstützen Verfügbarkeitsgruppen MSDTC nicht zwischen Datenbanken in derselben SQL-Instanz.

    Ab SQL Server 2016 SP2 und BizTalk Server 2016 CU5 können die BizTalk-Datenbanken dieselbe SQL Server-Instanz verwenden.

  • BizTalk Server kann Read-Only Routing nicht verwenden.

  • BizTalk Server legt die MultiSubnetFailover Verbindungseigenschaft nicht fest.

  • BizTalk-Sicherungsaufträge mit Protokollversand zielen immer auf das primäre Replikat ab, unabhängig von der Sicherungseinstellung, die für die Verfügbarkeitsgruppe festgelegt ist.

  • SQL Server 2016 Standard unterstützt nur eine einzelne Datenbank in jeder SQL AlwaysOn AG. Da BizTalk viele Datenbanken verwendet, wird sql Server Enterprise Edition in der Regel empfohlen.

  • Wenn Sie Azure-VMs verwenden, empfiehlt es sich, einen dedizierten festen TCP/IP-Port für MSDTC zu verwenden. Wenn Sie einen festen TCP/IP-Port verwenden, beschränken Sie ihren RPC-Portbereich, der in der Regel bei älteren Betriebssystemen verwendet wird, nicht. und es hilft, Ihre Firewall- und Lastenausgleichsregeln zu vereinfachen. Um Konflikte mit bekannten niedrigeren Ports zu vermeiden, sollten Sie einen höheren festen Port (z >. B. 20000) verwenden. Beim Konfigurieren der DTC Single Port Support wird der ServerTcpPort Registrierungsschlüssel beschrieben. Zusätzlich zum festen Port für MSDTC wird auch der Haupt-RPC-Port 135 verwendet.

Nächste Schritte

Planen der Fehlertoleranz.

  • Last updated on