Présentation de l'architecture

Cette section fournit une vue d'ensemble de l'architecture de Service Bus pour Windows Server, y compris la pile de plateformes, le système de processus d'exécution, les solutions de batterie de serveurs, la montée en charge et la haute disponibilité.

Vue d'ensemble de Service Bus pour Windows Server

Service Bus pour Windows Server est un ensemble de composants installables pour Windows qui fournit des fonctionnalités de messagerie Service Bus (semblables à celles fournies dans Service Bus). Service Bus pour Windows Server permet de générer, de tester et d'exécuter des applications à couplage souple et pilotées par des messages dans des environnements auto-gérés et sur des ordinateurs de développement. Les files d'attente Service Bus offrent un stockage et une récupération des messages fiables avec un large choix de protocoles et d'API. À l'instar des files d'attente, les rubriques Service Bus fournissent des fonctionnalités de publication et d'abonnement qui autorisent plusieurs abonnés simultanés à récupérer des vues filtrées ou non filtrées du flux de message publié.

Pile de plateformes Service Bus pour Windows Server

Service Bus pour Windows Server est basé sur Microsoft .NET Framework 4,0 PU3, Windows Server 2008 R2, SQL Server 2008 R2, Base de données SQL et Windows PowerShell 3.0. Toutes ces plateformes doivent être exécutées sur des systèmes d'exploitation 64 bits. La couche de stockage du système (SQL) peut être située sur un serveur distant dédié ou sur l'un des nœuds de calcul, ou dans Base de données SQL Windows Azure. Les nœuds de calcul utilisés dans cette pile peuvent être hébergés localement ou sous Windows Azure IAAS.

La figure suivante présente la pile de plateformes de Service Bus pour Windows Server.

Processus et modèle d'exécution

La figure suivante montre le modèle logique qui présente le fonctionnement du serveur Service Bus pour Windows Server. Chaque serveur Service Bus pour Windows Server inclut trois processus principaux : la passerelle Service Bus, le courtier de messages Service Bus et Windows Fabric. Tous les processus du serveur sont hébergés en tant que services Windows NT.

Vous pouvez connecter un ensemble de serveurs les uns aux autres dans une « batterie de serveurs » à haut niveau de disponibilité.

Modèles de communication à l'intérieur des batteries de serveurs

Comme la batterie de serveurs du serveur Service Bus pour Windows Server est « hautement disponible »”, il existe une communication inter-processus qui s'étend sur les ordinateurs locaux et distants.

• Le processus de passerelle Service Bus est un service sans état qui peut communiquer avec le courtier de messages sur les ordinateurs locaux et distants au sein de la batterie de serveurs.

• Le processus de courtier de messages Service Bus sur chaque ordinateur s'enregistre auprès du service Windows Fabric (sur le même ordinateur). Cet enregistrement indique la disponibilité afin d'héberger des services Windows Fabric.

• Les services Windows Fabric de chaque ordinateur communiquent les uns avec les autres pour établir un « anneau de haute disponibilité ».

Passerelle Service Bus

Toutes les demandes entrantes provenant des clients sont d'abord reçues et traitées par la passerelle Service Bus. Les en-têtes de protocole traitent les demandes et exécutent les opérations nécessaires (authentification, autorisation et résolution d'adresse). La demande est ensuite transférée au courtier de messages approprié. Dans certains cas, le client communique ensuite directement avec le courtier de messages pour les demandes suivantes. Le schéma suivant présente le flux de communication qui implique la passerelle Service Bus :

Les clients peuvent utiliser Net.TCP ou REST sur HTTP en tant que protocole pour la communication avec le serveur Service Bus pour Windows Server.

Interaction Net.TCP

Lorsqu'une demande du client Net.TCP est reçue au niveau de la passerelle, celle-ci identifie l'hôte (conteneur de messages) pour l'entité de messagerie (file d'attente, rubrique ou abonnement). Le service transfère ensuite les demandes vers le courtier de messages Service Bus approprié (local ou distant) dans lequel le conteneur de messages est exécuté.

Le mode de redirection de la messagerie est pris en charge uniquement pour les demandes Net.TCP. Dans ce mode, une fois l'authentification effectuée et l'autorisation obtenue, le client peut demander à la passerelle de répondre avec l'adresse du courtier de messages Service Bus. Le client peut ensuite se connecter directement au courtier de messages Service Bus pour les demandes suivantes. Cette fonctionnalité réduit le traitement induit par l'acheminement de toutes les demandes via la passerelle pour chaque message envoyé sur le réseau.

Interaction REST

Lorsqu'un client demande le protocole REST sur HTTP, le service NT de passerelle identifie l'hôte (conteneur de messages) pour l'entité de messagerie (file d'attente, rubrique ou abonnement). Le service transfère ensuite les demandes vers le courtier de messages Service Bus approprié (local ou distant) dans lequel le conteneur de messages est exécuté. Le modèle d'interaction REST ne prend pas en charge la fonctionnalité de redirection de la messagerie.

Courtier de messages Service Bus

Le courtier de messages est un service NT qui héberge les en-têtes de protocole, ainsi qu'un ou plusieurs conteneurs de messages. Le service s'enregistre lui-même auprès de Windows Fabric et agit comme hôte pour le service du conteneur de messages.

Le schéma suivant affiche une représentation logique du service NT de courtier de messages Service Bus.

Le cycle de vie du service NT est la base de la détection de basculement et de la haute disponibilité.

Conteneur de messages

Vous pouvez considérer le conteneur de messages comme une collection logique de logiques d'exécution (de calcul) soutenue par un magasin persistant (base de données SQL). En cas de basculement ou d'équilibrage de la charge, le conteneur de messages est un service modulaire qui se déplace. Chaque conteneur de messages est soutenu par un magasin (base de données SQL) et héberge un ensemble de files d'attente, de rubriques et d'abonnements, tel que déterminé par un algorithme de gestion de capacité de tourniquet (round-robin) simple. Les entités (files d'attente, rubriques et abonnements) placées dans un conteneur ne peuvent pas être déplacées et elles sont conservées dans le conteneur et la base de données associée. Tous les états associés au conteneur de messages sont persistants dans la base de données.

Windows Fabric

Ce processus contient la logique principale nécessaire à la haute disponibilité, à la formation de clusters et de batteries de serveurs, ainsi qu'à l'équilibrage de la charge sur tous les ordinateurs de la batterie de serveurs. Le service de courtier de messages sur chaque ordinateur s'enregistre auprès du processus Windows Fabric sur les ordinateurs respectifs. Windows Fabric détermine le nombre d'instances enregistrées du service de conteneur de messages et les place sur différents ordinateurs de la batterie de serveurs en fonction d'un algorithme simple d'équilibrage de la charge.

Haute disponibilité

Service Bus pour Windows Server prend en charge la haute disponibilité. Il existe deux aspects dans la haute disponibilité :

• Calcul

• Stockage

Couche de calcul

Service Bus pour Windows Server est un serveur à haut niveau de disponibilité. Le serveur est dépendant de Windows Fabric pour bénéficier d'une haute disponibilité. Afin d'obtenir une haute disponibilité, Service Bus pour Windows Server requiert trois ordinateurs. Toutes les topologies incluant moins de trois ordinateurs ne peuvent pas prendre en charge la haute disponibilité.

Le schéma suivant présente la condition d'état stable d'une batterie de serveurs incluant trois ordinateurs et trois conteneurs de messages.

Si un service NT de courtier de messages tombe en panne ou est recyclé, ou en cas de recyclage ou d'arrêt complet du nœud, les conteneurs de messages associés qui ont été placés dans cette instance de courtier avant la panne sont automatiquement déplacés vers d'autres ordinateurs de la batterie de serveurs. Les conteneurs de messages continuent à traiter les demandes avec une courte interruption en cas de basculement.

Si le serveur inclut plusieurs conteneurs, l'équilibrage de la charge constitue un autre aspect de la haute disponibilité. À mesure que de nouveaux ordinateurs sont ajoutés à la batterie de serveurs, la capacité de calcul est optimisée par le rééquilibrage de la liste des conteneurs attribués à un service NT de courtier de messages spécifique. L'algorithme d'équilibrage de la charge est également déclenché lorsque les administrateurs du serveur créent ou suppriment des conteneurs de messages.

Service Bus pour Windows Server automatise l'ajout de nouveaux ordinateurs à la batterie de serveurs, ainsi que la reconfiguration de la batterie de serveurs afin de prendre en charge la haute disponibilité. Pour obtenir cette automatisation, le serveur active automatiquement l'impression à distance et le partage de fichiers.

Niveau de stockage

Service Bus pour Windows Server ne fournit pas de prise en charge native de la haute disponibilité au niveau de la couche de stockage. Vous pouvez utiliser votre propre solution, telle que la mise en miroir SQL.

Date de génération :

2013-07-25