Planification du haut niveau de disponibilité
La haute disponibilité pour BizTalk Server se concentre sur la récupération des composants fonctionnels susceptibles de perturber la disponibilité dans un déploiement BizTalk Server.
Pour démontrer la haute disponibilité dans BizTalk Server, vous devez provoquer un échec et mesurer l’efficacité du produit dans la récupération. Un déploiement BizTalk Server hautement disponible rend les erreurs et les défaillances transparentes pour les applications et les systèmes externes, et garantit que tous les services continuent de fonctionner correctement avec une interruption minimale.
La conception d’un déploiement BizTalk Server qui fournit une haute disponibilité implique l’implémentation de la redondance pour chaque composant fonctionnel impliqué dans un scénario d’intégration d’application ou d’intégration de processus métier. BizTalk Server simplifie l’implémentation de ces scénarios en séparant conceptuellement les données des hôtes qui traitent les données. Un hôte est un conteneur logique d’éléments BizTalk, tels que les orchestrations, les gestionnaires d’envoi et les gestionnaires de réception. Vous créez des instances d’hôte et vous les affectez à l’hôte. Une instance d'hôte est la représentation physique d'un hôte sur un serveur particulier. Il s’agit du processus de service BizTalk Server appelé BTSNTSvc.exe ou d’un autre processus, par exemple, le processus IIS. Par conséquent, fournir une haute disponibilité pour BizTalk Server implique l’exécution de plusieurs instances d’hôte et clustering les bases de données BizTalk Server, comme suit :
Architecture pour les hôtes BizTalk. BizTalk Server vous permet de séparer les hôtes et d’exécuter plusieurs instances d’hôte afin de fournir une haute disponibilité pour les fonctions clés telles que la réception de messages, le traitement des orchestrations et l’envoi de messages. Ces hôtes n’ont pas besoin de clustering ou de mécanisme d’équilibrage de charge supplémentaire, car BizTalk Server distribue automatiquement la charge de travail sur plusieurs ordinateurs via des instances d’hôte. Toutefois, les hôtes exécutant les gestionnaires de réception pour les adaptateurs HTTP et SOAP nécessitent un mécanisme d’équilibrage de charge tel que l’équilibrage de charge réseau (NLB) pour fournir une haute disponibilité, et les hôtes exécutant les gestionnaires de réception pour FTP, MSMQ, POP3, SQL et SAP nécessitent un mécanisme de clustering pour fournir une haute disponibilité.
Notes
Vous devez toujours mettre en cluster l’adaptateur de réception SAP pour prendre en charge un scénario de validation en deux phases.
Architecture des bases de données BizTalk Server. La configuration de la haute disponibilité pour les bases de données BizTalk Server se compose généralement de deux ou plusieurs ordinateurs de base de données SQL Server configurés dans une configuration de cluster de serveurs actif/passif. Ces ordinateurs partagent une ressource de disque commune (telle qu’un disque RAID 1+0 SCSI ou un réseau de zone de stockage) et utilisent le clustering de basculement Windows pour fournir une redondance de sauvegarde et une tolérance de panne.
Un autre composant fonctionnel BizTalk critique pour la haute disponibilité est le serveur secret master. BizTalk Server s’appuie sur ce service pour obtenir la clé de chiffrement.
Cette section fournit des informations sur la façon de traiter la haute disponibilité dans chacune de ces catégories. Étant donné qu’une solution de haute disponibilité BizTalk Server repose sur Windows et SQL Server, veillez à déployer ces produits avec une haute disponibilité avant de configurer des hôtes pour BizTalk Server. Les liens suivants comportent des informations sur la façon d'assurer la haute disponibilité pour ces produits sous-jacents :
Solutions à haute disponibilité (SQL Server)](/sql/sql-server/failover-clusters/high-availability-solutions-sql-server)
Présentation de l’impact d’une défaillance d’un composant
Le tableau suivant répertorie les composants et les dépendances d’un environnement BizTalk Server et l’impact sur l’environnement BizTalk Server en cas d’échec du composant ou de la dépendance. Vous devez prendre en compte l’étendue d’un échec potentiel lors de la décision de cluster d’un composant ou d’une dépendance.
| Composant ou dépendance | Étendue de la défaillance |
|---|---|
| SQL Server | À l’échelle du système. Si SQL Server échoue, BizTalk Server ne pourrez pas traiter les documents. |
| Serveur de secret principal | À l’échelle du système. Si le serveur secret master échoue, BizTalk Server ne pourront pas traiter les documents. Note: Si le serveur secret master échoue, chaque serveur BizTalk du groupe BizTalk continuera à utiliser une copie en mémoire mise en cache du secret master jusqu’à ce que le service Enterprise SSO sur ce serveur BizTalk soit redémarré. Si le service Enterprise SSO est redémarré sur les serveurs BizTalk, la copie mise en cache du secret master est libérée de la mémoire et les serveurs BizTalk doivent être en mesure de contacter le serveur secret master pour obtenir une autre copie du secret master. Ne redémarrez pas le service Enterprise SSO sur le ou les serveurs BizTalk d’un groupe si le serveur secret master échoue et que vous souhaitez que le serveur BizTalk continue à traiter les documents. |
| MSDTC | Serveur. Si MSDTC échoue, tout composant sur le serveur qui nécessite la prise en charge des transactions échoue. Note: Étant donné que SQL Server et le serveur secret master dépendent de MSDTC pour la prise en charge des transactions, l’étendue de l’échec devient à l’échelle du système si le MSDTC sur le serveur SQL ou master serveur secret échoue. BizTalk Server nécessite la prise en charge des transactions lors de la communication avec SQL Server et le serveur secret master pendant les opérations d’exécution. |
| Instance de l'hôte BizTalk | Serveur. Tous les composants hébergés dans un instance hôte BizTalk ne pourront pas participer au traitement des documents si le instance hôte échoue. |
| Microsoft Message Queuing (MSMQ) | Serveur. Si MSMQ échoue, tout traitement de document dépendant du service MSMQ, tel que l’adaptateur MSMQ, est arrêté sur le serveur. |
| Système de fichiers | Serveur. Si le système de fichiers échoue, tout traitement de document dépendant du système de fichiers, tel que l’adaptateur de fichiers, est arrêté sur le serveur. |
Pour mieux gérer un système BizTalk Server hautement disponible, vous devez avoir une bonne compréhension de la pile BizTalk : Windows Server, DC (DNS, DHCP), BizTalk Server, SQL Server, serveur IIS, serveur de fichiers, serveur MSMQ, applications externes. Cette section se concentre sur la haute disponibilité des BizTalk Server et de l’ordinateur SQL Server dépendant.
exemples BizTalk Server High-Availability
Pour obtenir des exemples de scénarios dans Microsoft BizTalk Server qui fournissent une haute disponibilité via des niveaux d’hôtes avec montée en puissance parallèle, consultez Exemples BizTalk Server scénarios de haute disponibilité.
Voir aussi
Haute disponibilité pour les hôtes BizTalk
Haute disponibilité pour les bases de données
Haute disponibilité pour le serveur de secret principal
Liste de vérification : accroissement de la disponibilité avec la récupération d’urgence