Freigeben über

Hochverfügbarkeit mit SQL Server Always On Verfügbarkeitsgruppen – BizTalk Server

  • Artikel

Konfigurieren Sie Hochverfügbarkeit mit SQL Server AlwaysOn-Verfügbarkeitsgruppen.

Tipp

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

Wichtig

  • BizTalk Server unterstützen Always On 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 den Modus für synchrone Commits. Der Modus für asynchrone Commits wird nicht unterstützt. Für die Notfallwiederherstellung wird empfohlen, den Auftrag Backup BizTalk Server zu konfigurieren und den Protokollversand zu verwenden. Weitere Informationen finden Sie unter Sichern und Wiederherstellen BizTalk Server Datenbanken.

Verfügbarkeitsmodi enthält details zu den Commitoptionen mit Always On Verfügbarkeitsgruppen.

Hintergrund und Verlauf

BizTalk Server hängt stark von SQL Server für die Datenpersistenz ab. Andere Komponenten und Hosts in BizTalk Server haben bestimmte Rollen bei der Integration 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 Hochverfügbarkeit, Sicherung und Wiederherstellung sowie Notfallwiederherstellung für seine Datenbanken bereitzustellen. In Azure IaaS (Virtuelle Azure-Computer) unterstützte BizTalk (Windows und SQL) bisher keine Failoverclusterinstanzen, da keine unterstützten freigegebenen Datenträger vorhanden waren, was für das Clustering von SQL und MSDTC erforderlich ist. Daher verfügte BizTalk bei der Verwendung von Azure-VMs nicht über eine Hochverfügbarkeitslösung. Da Azure Shared Disk jetzt verfügbar ist, ist es möglich, sowohl SQL als auch MSDTC in Azure-VMs zu clustern. Die SQL-Failoverclusterinstanz mit freigegebenen Azure-Datenträgern ist die hoch verfügbare Lösung.

Ab SQL Server 2016 unterstützt SQL Server AlwaysOn-Verfügbarkeitsgruppen MSDTC für lokale und azure-VMs. Daher wird das AlwaysOn-Feature SQL Server 2016 (oder höher) für lokale BizTalk-Datenbanken oder in Azure IaaS-Szenarien unterstützt. Da bei der synchronen Datenträgersynchronisierung bei verwendung von Direkte Speicherplätze (S2D) und zusätzlicher Zeit bei Failovern zusätzlicher Aufwand entsteht, ist dies im Vergleich zur SQL-Failoverclusterinstanz weniger hoch verfügbar.

AlwaysOn-Verfügbarkeitsgruppen SQL Server 2016

Für die Bereitstellung von AlwaysOn-Verfügbarkeitsgruppen ist ein WSFC-Cluster (Windows Server Failover Clustering) erforderlich. Jedes Verfügbarkeitsreplikat einer bestimmten Verfügbarkeitsgruppe muss sich in 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 Zustand 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 der 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 an eine bestimmte Verfügbarkeitsgruppe angefügt sind, um Clientverbindungen mit dem entsprechenden Verfügbarkeitsreplikat zu leiten.

Wichtig

SQL Server 2016 unterstützt MSDTC mit AlwaysOn-Verfügbarkeitsgruppen (AG) auf Windows Server 2016 und Windows Server 2012 R2. Windows Server 2012 R2 muss der 3090973 Windows-Hotfix installiert sein. Windows Server 2016 erfordert, dass der Registrierungsschlüssel RemoteAccessEnabled aktiviert ist.

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

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

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

Vor SQL Server 2016 SP2 unterstützten Verfügbarkeitsgruppen MSDTC zwischen Datenbanken auf demselben SQL-instance daher mussten BizTalk-Datenbanken auf mindestens 4 SQL-Instanzen verteilt werden. 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 instance verwenden können. Sie können aus Leistungsgründen dennoch mehrere SQL-instance verwenden (z. B. messageBox auf einem anderen SQL-instance).

In einem hochskalierten MessageBox-Szenario (eine Konfiguration mit mehreren MessageBox-Dateien) 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 die 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 weitere eigenständige SQL Server instance für die Datenbanken BAMArchive und BAMAnalysis Analysis Services zu verwenden. Für lokale 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 vier SQL-Instanzen nicht mehr erforderlich):

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

Ab BizTalk Server 2020 wird mithilfe von SSIS Catalog eine hohe Verfügbarkeit für BAM DTS-Pakete 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 vier SQL-Instanzen nicht mehr erforderlich):

Empfohlene SQL Server Always On-Konfiguration unter 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. Auf 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. Wenn ja, müssen Sie sie auf jeder instance von SQL Server replizieren, die ein Replikat von BizTalk-Datenbanken hosten.

  1. BizTalk-Anwendungsbenutzer (ein oder mehrere, die jedem in-proc-Host entsprechen)
  2. BizTalk Isolated Host Users (ein oder mehrere, die jedem isolierten Host entsprechen)
  3. BizTalk Server-Administratoren
  4. BizTalk Server-B2B-Operatoren
  5. BizTalk Server-Operatoren
  6. SSO-Administratoren
  7. BAM-Warnungsbenutzer
  8. Benutzer des BAM-Verwaltungswebdiensts
  9. Updatedienstkonto der Regel-Engine

Wenn Sie zusätzliche Hosts erstellt haben oder später weitere Hosts erstellen, werden im Rahmen dieses Prozesses neue SQL-Anmeldungen erstellt. Sie müssen sicherstellen, dass Sie diese SQL-Anmeldungen manuell auf den entsprechenden Replikaten erstellen.

Die folgenden Aufträge des SQL Server-Agents stehen mit BizTalk Server in Zusammenhang. Die auf den einzelnen Servern installierten Aufträge unterscheiden sich je nachdem, welche Features installiert und konfiguriert sind. Die meisten dieser Aufträge werden während BizTalk Server Konfiguration erstellt. Einige werden beim Konfigurieren des Protokollversands erstellt. Diese Aufträge müssen auf jedem instance SQL Server Replikats repliziert werden, das die entsprechende BizTalk-Datenbank hostet. Dies muss manuell ausgeführt werden.

  • BizTalkMgmtDb-Aufträge:
    • BizTalk Server (BizTalkMgmtDb) sichern
    • CleanupBTFExpiredEntriesJob_BizTalkMgmtDb
    • Überwachen von BizTalk Server (BizTalkMgmtDb)
  • BizTalkMsgBoxDb-Aufträge:
    • 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
  • Aufträge auf zusätzlichen msgboxes
  • BizTalkDTADb-Auftrag:
    • DTA-Lösch- und -Archivierungsauftrag (BizTalkDTADb)
  • BizTalkRulesEngineDb-Auftrag:
    • Rules_Database_Cleanup_BizTalkRuleEngineDb
  • BAMAlertsAnwendungsauftrag:
    • 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 ein Failover auf jedem 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 auf dem aktuellen primären Replikat ausgeführt werden, muss jeder Schritt in jedem Auftrag wie folgt in einen IF-Block eingeschlossen werden:

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 Sie den Namen 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 DTC-Unterstützung pro Datenbank 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, Anmeldungen und SQL-Agent-Aufträge auf dem aktuellen primären Replikat erstellt.
  4. Beenden Sie die BizTalk-Verarbeitung (Hostinstanzen, SSO-Dienst, IIS, Regel-Engine-Updatedienst, BAMAlerts-Dienst usw.), und beenden Sie die SQL-Agent-Aufträge.
  5. Fügen Sie nun den jeweiligen Verfügbarkeitsgruppen BizTalk-Datenbanken hinzu.
  6. Schließen Sie den Text der SQL-Agent-Auftragsschritte in IF den Block (oben erwähnt) ein, um sicherzustellen, dass sie nur ausgeführt werden, wenn das Ziel das primäre Replikat ist.
  7. Skriptanmeldungen und SQL-Agent-Aufträge, um sie auf dem entsprechenden Replikat zu replizieren.
  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 Meldungsfelddatenbank hinzufügen oder später eine neue BAM-Aktivität/Sicht bereitstellen, werden neue SQL-Aufträge für neue Nachrichtenfelddatenbanken oder BAM-Warnungsdatenbanken auf dem aktuellen primären Replikat erstellt. Stellen Sie sicher, dass Sie es auf dem primären Replikat bearbeiten, und erstellen Sie sie dann manuell auf den entsprechenden sekundären Replikaten.
  10. Ab BizTalk Server 2020 und höher 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 unter AlwaysON für SSIS Catalog.

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 Skripts und UpdateRegistry.vbs nach den UpdateDatabase.vbs oben genannten Schritten auf den BizTalk-Computern 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ügbarkeitsgruppe mit der Option DTC-Unterstützung pro Datenbank erstellt wurde.

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

  4. Führen Sie eine vollständige Sicherung aller BizTalk-Datenbanken durch.

  5. Stellen Sie BizTalk-Datenbanken auf den SQL-Instanzen wieder her, die sich derzeit in der primären Rolle in der Verfügbarkeitsgruppe befinden.

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

  7. Führen Sie die UpdateDatabase.vbs Skripts und UpdateRegistry.vbs auf den BizTalk-Computern mithilfe der folgenden Schritte aus. Geben Sie den Verfügbarkeitsgruppenlistener als neuen Servernamen in der Xml-Datei für Eingabeupdateinformationen 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 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 Namen des Quellservers (alte SQL Server, die alte Datenbanken hosten).
      2. Ersetzen Sie "DestinationServer" durch den Namen des Zielservers, der dem Namen des Verfügbarkeitsgruppenlisteners entsprechen sollte.
      3. Wenn Sie über BAMAnalysis, BAM-Datenbanken oder RuleEngineDB verfügen, heben Sie die Auskommentierung der entsprechenden Abschnitte auf.

    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 auf jedem BizTalk Server Computer in dieser BizTalk-Gruppe in den 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

    5. Öffnen Sie auf jedem Computer in der Gruppe BizTalk Server 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 nun die Datenbanken in ihre jeweiligen Verfügbarkeitsgruppen.

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

  10. Schließen Sie den Text der SQL-Agent-Auftragsschritte in einen IF-Block ein, um sicherzustellen, dass sie nur ausgeführt werden, wenn das Ziel das primäre Ist.

  11. Skriptanmeldungen und SQL-Agentaufträge, um sie auf dem entsprechenden Replikat zu replizieren. Das Skript UpdateDatabase aktualisiert auch den Servernamen in den aufträgen Operations_OperateOnInstances_OnMaster_BizTalkMsgBoxDb und TrackedMessages_Copy_BizTalkMsgBoxDb. Führen Sie daher ein Skript für die SQL-Agent-Aufträge erst nach dem Ausführen des Skripts UpdateDatabase aus.

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 unter Bekannte Einschränkungen in diesem Artikel.

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

Verfügbarkeitsgruppenlistener, der mit einem nicht standardmäßigen Port konfiguriert ist (1433)

Verwenden Sie den SQL-Alias auf BizTalk Server Computern.

Verfügbarkeitsgruppen mit mehreren Subnetzen

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

Weitere Informationen zu Problemen, die auftreten können, wenn ein SQL-Client, der diese Option nicht unterstützt, mit einer SQL-Verfügbarkeitsgruppe mit mehreren Subnetzen verbunden wird, finden Sie in der SQL-Dokumentation. Einige dieser Probleme werden in den folgenden Links erläutert:

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 Read-Only Routing für keine der Verbindungen mit seinen Datenbanken. Dies bedeutet, dass die Option "Lesbar sekundär" für Verfügbarkeitsreplikate in der Verfügbarkeitsgruppe keine Auswirkungen auf BizTalk-Datenbankverbindungen hat.

Verhalten von BizTalk-Hostinstanzen während SQL Server Failovers

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

Verhalten der Hostinstanzen vom Typ „In-Process“ beim SQL Server-Failover

Wenn die BizTalk Server Datenbanken nicht verfügbar sind, wird eine prozessinterne instance eines BizTalk Server-Hosts wiederverwendet, bis die Verbindung mit dem SQL Server wiederhergestellt wird. Nachdem die Verbindung mit der SQL Server Datenbanken wiederhergestellt wurde, wird die Dokumentverarbeitung normal fortgesetzt.

Verhalten isolierter Hostinstanzen beim SQL Server-Failover

Wenn die BizTalk Server Datenbanken nicht verfügbar sind, wird eine isolierte instance eines BizTalk Server-Hosts angehalten, und im Protokoll der BizTalk Server-Anwendung wird ein Fehler ähnlich dem folgenden 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.

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

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

Protokollversand für die Notfallwiederherstellung

BizTalk Server implementiert Datenbank-Standbyfunktionen mithilfe des Datenbankprotokollversands. BizTalk Server Protokollversand automatisiert die Sicherung und Wiederherstellung von Datenbanken und deren Transaktionsprotokolldateien, sodass ein Standbyserver die Datenbankverarbeitung im Falle eines Ausfalls des Produktionsdatenbankservers fortsetzen kann.

Sekundäre Datenbanken in Verfügbarkeitsgruppen sind keine Sicherungen. Fahren Sie mit der Sicherung von BizTalk-Datenbanken und deren Transaktionsprotokollprotokollen fort, indem Sie BizTalk Server Protokollversandaufträge verwenden. Durch die Implementierung des BizTalk-Protokollversands wird sichergestellt, dass Sicherungen immer für das aktuelle primäre Replikat jeder Datenbank ausgeführt werden. Die Sicherungseinstellung für die Verfügbarkeitsgruppe wird von den BizTalk Server Protokollversandaufträgen nicht berücksichtigt.

Wenn Sie dem BizTalk-Datenbanksicherungsauftrag andere BizTalk-Datenbanken hinzufügen, müssen Sie beim Einrichten der Sicherung den Namen des Verfügbarkeitsgruppenlisteners als Datenbankserver verwenden.

Referenzen

Bekannte Einschränkungen

Diese Einschränkungen gelten für BizTalk Server, SQL Server AlwaysOn-Verfügbarkeitsgruppe und Azure Virtual Machines. Diese Einschränkungen werden möglicherweise in Zukunft behoben.

  • Anmeldungen, SQL-Agent-Aufträge, das SQL DB-E-Mail-Profil und Konten werden nicht in Verfügbarkeitsgruppen verwaltet. Dies erfordert eine manuelle Änderung 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 Hochverfügbarkeitslösung für diese in Azure Virtual Machines. die BAM-Funktionen von BizTalk Server sind von diesen Diensten abhängig.

  • Vor SQL Server 2016 SP2 unterstützen Verfügbarkeitsgruppen MSDTC zwischen Datenbanken auf demselben SQL-instance nicht.

    Ab SQL Server 2016 SP2 und BizTalk Server 2016 CU5 können die BizTalk-Datenbanken dieselbe SQL Server instance 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-Verfügbarkeitsgruppe. Da BizTalk viele Datenbanken verwendet, wird in der Regel SQL Server Enterprise Edition empfohlen.

  • Wenn Sie Azure-VMs verwenden, wird empfohlen, einen dedizierten festen TCP/IP-Port für MSDTC zu verwenden. Wenn Sie einen festen TCP/IP-Port verwenden, schränken Sie ihren RPC-Portbereich nicht ein, der normalerweise mit älteren Betriebssystemen verwendet wird. 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-Unterstützung für einzelne Ports wird der ServerTcpPort Registrierungsschlüssel beschrieben. Neben dem festen Port für MSDTC wird auch der Standard RPC-Port 135 verwendet.

Nächste Schritte

Planen der Fehlertoleranz