Modèles d’application et stratégies de développement pour SQL Server sur machines virtuelles Azure

S’applique à : SQL Server sur machine virtuelle Azure

Notes

Azure a deux modèles de déploiement différents pour créer et utiliser des ressources : Resource Manager et classique. Cet article traite des deux modèles, mais Microsoft recommande d’utiliser le modèle Resource Manager dans la plupart des nouveaux déploiements.

Vue d’ensemble

La détermination du ou des modèles d’application à utiliser pour vos applications SQL Server dans un environnement Azure est une décision de conception importante. Elle exige une bonne compréhension de l’interopérabilité de SQL Server et de chaque composant d’infrastructure d’Azure. Avec SQL Server sur les services d’infrastructure Azure, vous pouvez aisément migrer, gérer et superviser vos applications SQL Server existantes créées sur Windows Server sur des machines virtuelles dans Azure.

Cet article vise à fournir aux architectes de solutions et aux développeurs une base pour une architecture et une conception de qualité, qu’ils peuvent appliquer lors de la migration d’applications existantes vers Azure ainsi que dans le cadre du développement de nouvelles applications dans Azure.

Pour chaque modèle d’application, vous trouverez un scénario local, la solution cloud correspondante et les recommandations techniques connexes. En outre, l’article aborde des stratégies de développement propres à Azure afin de vous permettre de concevoir correctement vos applications. Compte tenu des nombreux modèles d’application possibles, il est recommandé aux architectes et aux développeurs d’opter pour celui qui convient le mieux à leurs applications et à leurs utilisateurs.

Contributeurs techniques : Luis Carlos Vargas Herring et Madhan Arumugam Ramakrishnan

Réviseurs techniques : Corey Sanders, Drew McDaniel, Narayan Annamalai, Nir Mashkowski, Sanjay Mishra, Silvano Coriani, Stefan Schackow, Tim Hickey, Tim Wieman et Xin Jin

Introduction

Vous pouvez développer de nombreux types d’applications multiniveaux en répartissant les composants des niveaux d’application sur différents ordinateurs ainsi que dans différents composants. Par exemple, vous pouvez placer l’application cliente et les composants de règles métier sur un ordinateur, les composants de niveau web frontal et d’accès aux données sur un deuxième ordinateur et un niveau de base de données principale sur un troisième ordinateur. Ce type de structure permet d’isoler les niveaux les uns des autres. Si vous modifiez la provenance des données, vous n’avez pas besoin de modifier l’application cliente ou web, mais seulement les composants de niveau d’accès aux données.

Une application multiniveau type inclut la couche Présentation, la couche Métier et la couche Données :

Niveau	Description
Présentation	La couche Présentation (niveau web, niveau frontal) correspond à la couche dans laquelle les utilisateurs interagissent avec une application.
Métier	La couche Métier (niveau intermédiaire) correspond à la couche utilisée par la couche Présentation et la couche Données pour communiquer l’une avec l’autre. Elle inclut la fonctionnalité principale du système.
Données	La couche Données correspond au serveur stockant les données d’une application (par exemple, dans le cas d’un serveur exécutant SQL Server).

Les couches d’application décrivent les regroupements logiques des fonctionnalités et des composants d’une application, tandis que les niveaux décrivent la distribution physique des composants et fonctionnalités sur des serveurs physiques, des ordinateurs, des réseaux ou des emplacements distants distincts. Les couches d’une application peuvent résider sur le même ordinateur physique (même niveau) ou être réparties sur des ordinateurs distincts (multiniveau), tandis que les composants de chaque couche communiquent avec les composants des autres couches via des interfaces bien définies. Vous pouvez considérer que le terme « niveau » fait référence aux modèles de distribution physiques comme des structures à deux niveaux, trois niveaux et multiniveaux. Un modèle d’application à deux niveaux contient deux couches Application : un serveur d’application et un serveur de base de données. La communication directe se produit entre le serveur d’application et le serveur de base de données. Le serveur d’application contient des composants de niveau web et de niveau métier. Dans un modèle d’application à trois niveaux, il existe trois couches Application : un serveur web, un serveur d’application (qui contient la couche Logique métier et/ou les composants d’accès aux données de la couche Métier) et le serveur de base de données. La communication entre le serveur web et le serveur de base de données a lieu sur le serveur d’application. Pour plus d’informations sur les couches Application, consultez la page Guide d’architecture d’application Microsoft.

Avant de lire cet article, vous devez connaître les concepts fondamentaux de SQL Server et Azure. Pour plus d’informations, consultez les pages Documentation en ligne de SQL Server, SQL Server sur des machines virtuelles Azure et Azure.com.

Cet article décrit plusieurs modèles d’application qui peuvent convenir à de simples applications, ainsi qu’à des applications métier très complexes. Avant de détailler chaque modèle, nous vous recommandons de vous familiariser avec les services de stockage de données disponibles dans Azure, tels que Stockage Azure, Azure SQL Database et SQL Server dans une machine virtuelle Azure. Pour prendre les meilleures décisions de conception de vos applications, apprenez comment utiliser au mieux chaque service de stockage de données.

Choisissez SQL Server sur des machines virtuelles Azure quand :

• Vous avez besoin de contrôler SQL Server et Windows. Par exemple, cela peut inclure la version de SQL Server, des correctifs spéciaux, une configuration des performances, etc.

• Vous avez besoin d’une compatibilité complète avec SQL Server et souhaitez déplacer des applications existantes vers Azure en l’état.

• Vous souhaitez exploiter les fonctionnalités de l’environnement Azure mais Azure SQL Database ne prend pas en charge les fonctionnalités requises par votre application. Cela peut inclure les éléments suivants :

  • Taille de la base de données : Au moment de la mise à jour de cet article, le service SQL Database prend en charge une base de données pouvant contenir jusqu’à 1 To de données. Si votre application nécessite plus de 1 To de données et que vous ne souhaitez pas implémenter de solutions de partitionnement personnalisées, il est recommandé d’utiliser SQL Server sur une machine virtuelle Azure. Pour plus d’informations, consultez Scale-out Azure SQL Database, Modèle d’achat DTU et Modèle d’achat vCore(préversion).
  • Conformité HIPAA : Les clients du secteur de la santé et les fournisseurs de logiciels indépendants (ISV) peuvent choisir le service SQL Server sur des machines virtuelles Azure au lieu du service Azure SQL Database, car le service SQL Server sur des machines virtuelles Azure est couvert par le contrat HIPAA Business Associate Agreement (BAA). Pour plus d’informations sur la conformité, consultez le Centre de confidentialité Microsoft Azure : Conformité.
  • Fonctionnalités au niveau de l’instance : SQL Database ne prend pas en charge actuellement les fonctionnalités qui résident en dehors de la base de données (comme les serveurs liés, les travaux de l’Agent, Flux de fichier, Service Broker, etc.). Pour plus d’informations, consultez la section Instructions et limitations Azure SQL Database.

1 niveau (simple) : une seule machine virtuelle

Dans ce modèle d’application, vous déployez votre application et votre base de données SQL Server sur une machine virtuelle autonome dans Azure. La même machine virtuelle contient votre application cliente/web, les composants métier, la couche d’accès aux données et le serveur de base de données. Les niveaux de présentation, de métier et de code d’accès aux données sont séparés de manière logique, mais situés physiquement sur un serveur unique. La plupart des clients démarrent avec ce modèle d’application, puis ils effectuent un scale-out en ajoutant plusieurs rôles web ou des machines virtuelles à leur système.

Ce modèle d’application est utile dans les cas suivants :

• Vous souhaitez effectuer une migration simple vers la plateforme Azure pour déterminer si cette dernière répond aux exigences de votre application.
• Vous souhaitez conserver tous les niveaux d’application hébergés dans la même machine virtuelle dans le même centre de données Azure pour réduire la latence entre les niveaux.
• Vous voulez rapidement approvisionner des environnements de développement et de test pour de courtes périodes.
• Vous souhaitez effectuer un test de contrainte sur différents niveaux de charge de travail, mais en même temps, vous ne souhaitez pas posséder et gérer plusieurs machines physiques tout le temps.

Le schéma suivant illustre un scénario local simple et explique comment déployer sa solution de cloud dans une seule machine virtuelle dans Azure.

Le déploiement de la couche métier (composants de logique métier et d’accès aux données) sur le même niveau physique que la couche de présentation peut optimiser les performances de l’application, sauf si vous devez utiliser un niveau distinct en raison de problèmes de sécurité et d’extensibilité.

Dans la mesure où il s’agit d’un modèle de démarrage courant, l’article suivant, qui traite de la migration, peut vous être utile pour déplacer vos données vers votre machine virtuelle SQL Server : Guide de migration : SQL Server vers SQL Server sur les machines virtuelles Azure.

3 niveaux (simple) : plusieurs machines virtuelles

Dans ce modèle d’application, vous déployez une application à 3 niveaux dans Azure en plaçant chaque niveau d’application dans une machine virtuelle différente. Cela fournit un environnement flexible pour des scénarios de mise à l’échelle simples. Lorsqu’une machine virtuelle contient votre application cliente/web, la deuxième héberge vos composants métier et la troisième le serveur de base de données.

Ce modèle d’application est utile dans les cas suivants :

• Vous souhaitez faire migrer des applications de base de données complexes vers des machines virtuelles Azure.
• Vous souhaitez que différents niveaux d’application soient hébergés dans différentes régions. Par exemple, vous avez peut-être partagé des bases de données qui sont déployées sur plusieurs régions à des fins de création de rapports.
• Vous souhaitez déplacer des applications métier à partir de plateformes virtualisées locales vers des machines virtuelles Azure. Pour obtenir une présentation détaillée des applications métier, consultez la section Qu’est-ce qu’une application d’entreprise ?.
• Vous voulez rapidement approvisionner des environnements de développement et de test pour de courtes périodes.
• Vous souhaitez effectuer un test de contrainte sur différents niveaux de charge de travail, mais en même temps, vous ne souhaitez pas posséder et gérer plusieurs machines physiques tout le temps.

Le schéma suivant explique comment placer une simple application à 3 niveaux dans Azure en plaçant chaque niveau d’application dans une machine virtuelle distincte.

Dans ce modèle d’application, il n’y a qu’une seule machine virtuelle dans chaque niveau. Si vous avez plusieurs machines virtuelles dans Azure, nous vous recommandons de configurer un réseau virtuel. Azure Virtual Network crée une limite de sécurité approuvée et permet aux machines virtuelles de communiquer entre elles via l’adresse IP privée. De plus, assurez-vous toujours que toutes les connexions Internet vont uniquement vers le niveau de présentation. Lorsque vous suivez ce modèle d’application, gérez les règles du groupe de sécurité réseau pour contrôler l’accès. Pour plus d’informations, voir Autoriser l’accès externe à votre machine virtuelle à l’aide du portail Azure.

Dans le schéma, les protocoles Internet peuvent être TCP, UDP, HTTP ou HTTPS.

Notes

La configuration d’un réseau virtuel dans Azure est gratuite. Toutefois, vous êtes facturé pour la passerelle VPN qui se connecte en local. Ces frais sont basés sur la durée d’approvisionnement et de disponibilité de la connexion.

2 et 3 niveaux avec montée en puissance de niveau de présentation

Dans ce modèle d’application, vous déployez une application de base de données à 2 ou 3 niveaux vers Azure Virtual Machines en plaçant chaque niveau d’application dans une machine virtuelle distincte. De plus, vous effectuez un scale-out du niveau de présentation pour faire face à l’augmentation du volume de demandes clientes entrantes.

Ce modèle d’application est utile dans les cas suivants :

• Vous souhaitez déplacer des applications métier à partir de plateformes virtualisées locales vers des machines virtuelles Azure.
• Vous voulez effectuer un scale-out du niveau de présentation pour faire face à l’augmentation du volume de demandes clientes entrantes.
• Vous voulez rapidement approvisionner des environnements de développement et de test pour de courtes périodes.
• Vous souhaitez effectuer un test de contrainte sur différents niveaux de charge de travail, mais en même temps, vous ne souhaitez pas posséder et gérer plusieurs machines physiques tout le temps.
• Vous voulez posséder un environnement d’infrastructure pouvant être mis à l’échelle à la demande.

Le schéma suivant explique comment placer les niveaux d’application dans plusieurs machines virtuelles dans Azure en montant en puissance le niveau de présentation pour faire face à l’augmentation du volume de demandes clientes entrantes. Comme indiqué dans le schéma, l’équilibreur de charge Azure est responsable de la distribution du trafic sur plusieurs machines virtuelles et de la détermination du serveur web auquel se connecter. La présence de plusieurs instances des serveurs web derrière un équilibreur de charge garantit la haute disponibilité du niveau de présentation.

Meilleures pratiques pour les modèles à 2 et 3 niveaux ou multiniveaux ayant plusieurs machines virtuelles dans un même niveau

Il est recommandé de placer les machines virtuelles appartenant au même niveau dans le même service cloud et dans le même groupe à haute disponibilité. Par exemple, placez un ensemble de serveurs web dans Service_Cloud_1 et Groupe_haute_disponibilité_1 et un ensemble de serveurs de base de données dans Service_cloud_2 et Groupe_haute_disponibilité_2. Un groupe à haute disponibilité dans Azure vous permet de placer les nœuds de haute disponibilité dans des domaines d’erreur et des domaines de mise à niveau distincts.

Pour tirer parti de plusieurs instances de machine virtuelle d’un niveau, vous devez configurer l’équilibreur de charge Azure entre les niveaux d’application. Pour configurer Load Balancer dans chaque niveau, créez un point de terminaison avec équilibrage de charge séparément sur les machines virtuelles de chaque niveau. Pour un niveau spécifique, commencez par créer des machines virtuelles dans le même service cloud. Cela garantit qu’elles ont la même adresse IP virtuelle publique. Puis créez un point de terminaison sur l’une des machines virtuelles de ce niveau. Ensuite, affectez le même point de terminaison aux autres machines virtuelles de ce niveau pour l’équilibrage de charge. En créant un jeu d’équilibrage de la charge, vous répartissez le trafic entre plusieurs machines virtuelles et permettez également à l’équilibreur de charge de déterminer le nœud auquel se connecter lorsqu’un nœud de machine virtuelle principal échoue. Par exemple, la présence de plusieurs instances des serveurs web derrière un équilibreur de charge garantit la haute disponibilité du niveau de présentation.

Nous vous recommandons de toujours vous assurer que toutes les connexions Internet vont d’abord vers le niveau de présentation. La couche de présentation accède au niveau métier, puis le niveau métier accède au niveau de données. Pour plus d’informations sur la façon d’autoriser l’accès à la couche de présentation, voir Autoriser l’accès externe à votre machine virtuelle à l’aide du portail Azure.

Notez que l’équilibreur de charge dans Azure fonctionne de la même manière que les équilibreurs de charge dans un environnement local. Pour plus d’informations, consultez la page Équilibrage de charge pour les services d’infrastructure Azure.

De plus, nous vous recommandons de configurer un réseau privé pour vos machines virtuelles en utilisant Azure Virtual Network. Cela leur permet de communiquer entre elles via l’adresse IP privée. Pour plus d’informations, consultez Azure Virtual Network.

2 et 3 niveaux avec montée en puissance de niveau métier

Dans ce modèle d’application, vous déployez une application de base de données à 2 ou 3 niveaux vers Azure Virtual Machines en plaçant chaque niveau d’application dans une machine virtuelle distincte. De plus, vous pouvez distribuer les composants de serveur d’applications sur plusieurs machines virtuelles en raison de la complexité de votre application.

Ce modèle d’application est utile dans les cas suivants :

• Vous souhaitez déplacer des applications métier à partir de plateformes virtualisées locales vers des machines virtuelles Azure.
• Vous voulez distribuer les composants de serveur d’applications sur plusieurs machines virtuelles en raison de la complexité de votre application.
• Vous voulez déplacer des applications métier volumineuses de logique métier vers Azure Virtual Machines. Les applications métier sont un ensemble d’applications critiques qui sont essentielles au fonctionnement d’une entreprise, telles que les applications de comptabilité, de ressources humaines (RH), de paie, de gestion de la chaîne logistique et de planification des ressources.
• Vous voulez rapidement approvisionner des environnements de développement et de test pour de courtes périodes.
• Vous souhaitez effectuer un test de contrainte sur différents niveaux de charge de travail, mais en même temps, vous ne souhaitez pas posséder et gérer plusieurs machines physiques tout le temps.
• Vous voulez posséder un environnement d’infrastructure pouvant être mis à l’échelle à la demande.

Le schéma suivant illustre un scénario local et sa solution cloud. Dans ce scénario, vous placez les niveaux d’application dans plusieurs machines virtuelles dans Azure par montée en puissance parallèle du niveau métier, qui contient la couche de logique métier et les composants d’accès aux données. Comme indiqué dans le schéma, l’équilibreur de charge Azure est responsable de la distribution du trafic sur plusieurs machines virtuelles et de la détermination du serveur web auquel se connecter. La présence de plusieurs instances des serveurs d’application derrière un équilibreur de charge garantit la haute disponibilité du niveau métier. Pour plus d’informations, consultez la section Meilleures pratiques pour les modèles d’application à 2 niveaux, 3 niveaux ou multiniveau ayant plusieurs machines virtuelles dans un niveau.

2 et 3 niveaux avec une montée en puissance et un HADR des niveaux de présentation et métier

Dans ce modèle d’application, vous déployez une application de base de données à 2 ou 3 niveaux vers Azure Virtual Machines en distribuant les composants du niveau de présentation (serveur web) et du niveau métier (serveur d’application) vers plusieurs machines virtuelles. Vous implémentez également des solutions de haute disponibilité et de reprise d’activité (HADR) pour vos bases de données sur des machines virtuelles Azure.

Ce modèle d’application est utile dans les cas suivants :

• Vous souhaitez déplacer des applications métier à partir de plateformes virtualisées locales vers Azure en implémentant les capacités de haute disponibilité et de récupération d’urgence de SQL Server.
• Vous souhaitez effectuer un scale-out du niveau de présentation et le niveau métier pour faire face à l’augmentation du volume de demandes clientes entrantes et à la complexité de votre application.
• Vous voulez rapidement approvisionner des environnements de développement et de test pour de courtes périodes.
• Vous souhaitez effectuer un test de contrainte sur différents niveaux de charge de travail, mais en même temps, vous ne souhaitez pas posséder et gérer plusieurs machines physiques tout le temps.
• Vous voulez posséder un environnement d’infrastructure pouvant être mis à l’échelle à la demande.

Le schéma suivant illustre un scénario local et sa solution cloud. Dans ce scénario, vous effectuez un scale-out du niveau de présentation et du niveau métier dans plusieurs machines virtuelles dans Azure. De plus, vous implémentez des techniques de haute disponibilité et de récupération d’urgence (HADR) pour les bases de données SQL Server dans Azure.

L’exécution de plusieurs copies d’une application dans différentes machines virtuelles garantit l’équilibrage de la charge des demandes entre ces dernières. Lorsque vous avez plusieurs machines virtuelles, vous devez vous assurer qu’elles sont accessibles et en cours d’exécution à un moment donné. Si vous configurez l’équilibrage de charge, Azure Load Balancer surveille l’intégrité des machines virtuelles et dirige les appels entrants vers les nœuds de machines virtuelles fonctionnant correctement. Pour plus d’informations sur la méthode de configuration de l’équilibrage de charge des machines virtuelles, consultez la page Équilibrage de charge pour les services d’infrastructure Azure. La présence de plusieurs instances des serveurs web et d’application derrière un équilibreur de charge garantit la haute disponibilité des niveaux de présentation et métier.

Meilleures pratiques pour les modèles d’application nécessitant des techniques de haute disponibilité et de récupération d’urgence (HADR) SQL

Lorsque vous configurez des solutions de haute disponibilité et de récupération d’urgence SQL Server dans Azure Virtual Machines, la configuration d’un réseau virtuel pour vos machines virtuelles à l’aide d’Azure Virtual Network est obligatoire. Les machines virtuelles d’un réseau virtuel ont une adresse IP privée stable, même après une interruption de service. Cela vous évite de perdre du temps à mettre à jour la résolution du nom DNS. De plus, le réseau virtuel vous permet d’étendre votre réseau local vers Azure et crée une limite de sécurité approuvée. Par exemple, si votre application a des restrictions de domaine d’entreprise (par exemple, l’authentification Windows, Active Directory), la configuration d’Azure Virtual Network est nécessaire.

La plupart des clients, qui exécutent un code de production sur Azure, conservent les réplicas principaux et secondaires dans Azure.

Pour obtenir des informations complètes et des tutoriels sur les techniques de haute disponibilité et de reprise d’activité, consultez la page Haute disponibilité et reprise d’activité pour SQL Server sur des machines virtuelles Azure.

2 et 3 niveaux à l’aide de machines virtuelles Azure et de Cloud Services

Dans ce modèle d’application, vous déployez des applications à 2 ou 3 niveaux vers Azure en utilisant Azure Cloud Services (rôles web et de travail - plateforme en tant que Service (PaaS)) et Azure Virtual Machines (infrastructure en tant que service (IaaS)). L’utilisation d’Azure Cloud Services pour le niveau de présentation et/ou métier et SQL Server dans Azure Virtual Machines pour le niveau de données est bénéfique pour la plupart des applications s’exécutant sur Azure. En effet, le fait d’avoir une instance de calcul en cours d’exécution sur Cloud Services facilite la gestion, le déploiement, la surveillance et la montée en puissance.

Avec Cloud Services, Azure assure l’entretien de l’infrastructure : maintenance de routine, application des correctifs sur les systèmes d’exploitation et tentatives de récupération après échec matériel ou de service. Lorsque votre application a besoin d’une montée en puissance, des options de montée en puissance automatique et manuelle sont disponibles pour votre projet de service cloud en augmentant ou diminuant le nombre d’instances ou de machines virtuelles que votre application utilise. De plus, vous pouvez utiliser une version locale de Visual Studio pour déployer votre application dans un projet de service cloud dans Azure.

En résumé, si vous souhaitez éviter les tâches d’administration importantes pour le niveau de présentation et/ou métier, et que votre application ne nécessite aucune configuration complexe des logiciels ou du système d’exploitation, utilisez Azure Cloud Services. Si Azure SQL Database ne prend pas en charge toutes les fonctionnalités que vous recherchez, utilisez SQL Server sur une machine virtuelle Azure pour le niveau de données. L’exécution d’une application dans Azure Cloud Services et le stockage de données dans Azure Virtual Machines combine les avantages des deux services. Pour une comparaison détaillée, voir la section Comparaison des stratégies de développement dans Azure.

Dans ce modèle d’application, le niveau de présentation inclut un rôle web, qui est un composant de Cloud Services en cours d’exécution dans l’environnement d’exécution d’Azure et personnalisé pour la programmation d’applications web prises en charge par IIS et ASP.NET. Le niveau métier ou principal inclut un rôle de travail, qui est un composant Services Cloud en cours d’exécution dans l’environnement d’exécution d’Azure et est utile pour le développement généralisé, tout en pouvant effectuer des opérations de traitement en arrière-plan pour un rôle web. Le niveau de base de données réside sur une machine virtuelle SQL Server dans Azure. La communication entre le niveau de présentation et le niveau de base de données a lieu directement ou via les composants de rôle de travail du niveau métier.

Ce modèle d’application est utile dans les cas suivants :

• Vous souhaitez déplacer des applications métier à partir de plateformes virtualisées locales vers Azure en implémentant les capacités de haute disponibilité et de récupération d’urgence de SQL Server.
• Vous voulez posséder un environnement d’infrastructure pouvant être mis à l’échelle à la demande.
• Azure SQL Database ne prend pas en charge toutes les fonctionnalités dont votre application ou votre base de données a besoin.
• Vous souhaitez effectuer un test de contrainte sur différents niveaux de charge de travail, mais en même temps, vous ne souhaitez pas posséder et gérer plusieurs machines physiques tout le temps.

Le schéma suivant illustre un scénario local et sa solution cloud. Dans ce scénario, vous placez le niveau de présentation dans des rôles web, le niveau métier dans des rôles de travail et le niveau de données dans des machines virtuelles dans Azure. L’exécution de plusieurs copies du niveau de présentation dans différents rôles web garantit le chargement des demandes d’équilibrage entre eux. Lorsque vous combinez Azure Cloud Services avec Azure Virtual Machines, nous vous recommandons de configurer également Azure Virtual Network . Azure Virtual Networkpermet d’obtenir des adresses IP privées stables et persistantes dans le même service cloud dans le cloud. Lorsque vous avez défini un réseau virtuel pour vos machines virtuelles et vos services cloud, ils peuvent commencer à communiquer entre eux via l’adresse IP privée. De plus, le fait d’avoir des machines virtuelles et des rôles web et/ou de travail Azure dans le même réseau virtuel Azure fournit une latence faible et une connectivité plus sécurisée. Pour plus d’informations, consultez la section Qu’est-ce qu’un service cloud ?

Comme indiqué dans le schéma, l’équilibreur de charge Azure distribue le trafic sur plusieurs machines virtuelles et détermine le serveur web ou d’application auquel se connecter. La présence de plusieurs instances des serveurs web et d’application derrière un équilibreur de charge garantit la haute disponibilité des niveaux de présentation et métier. Pour plus d’informations, consultez la section Meilleures pratiques pour les modèles d’application nécessitant des techniques de haute disponibilité et de récupération d’urgence (HADR) SQL.

Une autre approche d’implémentation de ce modèle d’application consiste à utiliser un rôle web consolidé contenant les composants des niveaux de présentation et métier comme indiqué dans le schéma suivant. Ce modèle d’application est utile pour les applications qui requièrent une conception avec état. Comme Azure fournit des nœuds de calcul sans état sur les rôles web et de travail, nous vous recommandons d’implémenter une logique pour stocker l’état de session à l’aide de l’une des technologies suivantes : mise en cache Azure, Stockage Table Azure ou Azure SQL Database.

Modèle avec des machines virtuelles Azure, Azure SQL Database et Azure App Service (Web Apps)

Le principal objectif de ce modèle d’application consiste à vous montrer comment combiner des composants d’infrastructure en tant que service (IaaS) Azure avec des composants de plateforme en tant que service (PaaS) Azure dans votre solution. Ce modèle est axé sur Azure SQL Database pour le stockage des données relationnelles. Il n’inclut pas SQL Server dans une machine virtuelle Azure, qui fait partie de l’offre Infrastructure en tant que service (IaaS) Azure.

Dans ce modèle d’application, vous déployez une application de base de données vers Azure en plaçant les niveaux métier et de présentation dans la même machine virtuelle et en accédant à une base de données dans des serveurs Azure SQL Database (SQL Database). Vous pouvez implémenter le niveau de présentation en utilisant les solutions web IIS classiques. Sinon, vous pouvez implémenter une combinaison des couches Présentation et Métier en utilisant Azure App Service.

Ce modèle d’application est utile dans les cas suivants :

• Vous avez déjà un serveur SQL Database existant configuré dans Azure et vous souhaitez tester votre application rapidement.
• Vous souhaitez tester les fonctionnalités de l’environnement Azure.
• Vous voulez rapidement approvisionner des environnements de développement et de test pour de courtes périodes.
• Vos composants de logique métier et d’accès aux données peuvent être autonomes dans une application web.

Le schéma suivant illustre un scénario local et sa solution cloud. Dans ce scénario, vous placez les niveaux d’application dans une seule machine virtuelle dans Azure et accédez aux données dans Azure SQL Database.

Si vous choisissez d’implémenter une combinaison des niveaux web et d’application utilisant Azure Web Apps, nous vous recommandons de conserver le niveau intermédiaire ou d’application en tant que bibliothèques de liens dynamiques (DLL) dans le contexte d’une application web.

En outre, passez en revue les recommandations de la section Comparaison des stratégies de développement web dans Azure à la fin de cet article pour en savoir plus sur les techniques de programmation.

Modèle d’application hybride multiniveau

Dans le modèle d’application hybride multiniveau, vous implémentez votre application dans plusieurs niveaux distribués entre Azure et les emplacements locaux. Par conséquent, vous créez un système hybride réutilisable et flexible, que vous pouvez modifier ou doter d’un niveau spécifique sans changer les autres niveaux. Pour étendre votre réseau d’entreprise vers le cloud, utilisez le service Azure Virtual Network .

Ce modèle d’application hybride est utile dans les cas suivants :

• Vous voulez développer des applications qui s’exécutent en partie dans le cloud et en partie localement.
• Vous souhaitez migrer une partie ou la totalité des éléments d’une application locale existante vers le cloud.
• Vous souhaitez déplacer des applications métier à partir de plateformes virtualisées locales vers Azure.
• Vous voulez posséder un environnement d’infrastructure pouvant être mis à l’échelle à la demande.
• Vous voulez rapidement approvisionner des environnements de développement et de test pour de courtes périodes.
• Vous voulez une méthode de sauvegarde économique pour vos applications de base de données métier.

Le schéma suivant illustre un modèle d’application hybride multiniveau qui s’étend en local et sur Azure. Comme indiqué dans ce schéma, l’infrastructure locale inclut un contrôleur de domaine pour les services de domaine Active Directory afin de prendre en charge l’authentification et l’autorisation des utilisateurs. Notez que le schéma illustre un scénario dans lequel certaines parties du niveau de données résident dans un centre de données local tandis que d’autres sont hébergées dans Azure. Selon les besoins de votre application, vous pouvez implémenter plusieurs autres scénarios hybrides. Par exemple, vous pouvez conserver le niveau de présentation et le niveau métier dans un environnement local, et le niveau de données dans Azure.

Dans Azure, vous pouvez utiliser l’ID Microsoft Entra (anciennement Azure Active Directory) pour la gestion des identités et des accès, ou intégrer un Active Directory local existant à l’ID Microsoft Entra. Comme indiqué dans le diagramme, les composants de la couche métier peuvent s’authentifier auprès de plusieurs sources de données, telles que SQL Server sur les machines virtuelles Azure (via une adresse IP privée interne), une version locale de SQL Server (via Azure Virtual Network) ou le service Base de données Azure SQL (en utilisant les technologies du fournisseur de données .NET Framework). Dans ce schéma, Azure SQL Database est un service de stockage de données en option.

Dans le modèle d’application hybride multiniveau, vous pouvez implémenter le flux de travail suivant dans l’ordre spécifié :

1. Identifiez les applications de base de données métier qui doivent être déplacées dans le cloud à l’aide de Microsoft Assessment and Planning (MAP) Toolkit. Microsoft Assessment and Planning (MAP) Toolkit regroupe les données d’inventaire et de performances des ordinateurs que vous envisagez de virtualiser et fournit des recommandations sur la capacité et la planification de l’évaluation.

2. Planifiez les ressources et la configuration requise dans la plateforme Azure, telles que les comptes de stockage et les machines virtuelles.

3. Configurez la connectivité réseau entre les réseaux d’entreprise locaux et Azure Virtual Network. Pour configurer la connexion entre le réseau d’entreprise local et une machine virtuelle dans Azure, utilisez une des deux méthodes suivantes :

   1. Établissez une connexion entre l’environnement local et Azure via des points de terminaison publics sur une machine virtuelle dans Azure. Cette méthode simplifie la configuration et vous permet d’utiliser l’authentification SQL Server dans votre machine virtuelle. En outre, configurez vos règles de groupe de sécurité réseau pour contrôler le trafic public vers la machine virtuelle. Pour plus d’informations, voir Autoriser l’accès externe à votre machine virtuelle à l’aide du portail Azure.

   2. Établissez une connexion entre un environnement local et Azure via le tunnel du réseau privé virtuel (VPN) d’Azure. Cette méthode vous permet d’étendre les stratégies de domaine vers une machine virtuelle dans Azure. Vous pouvez également définir des règles de pare-feu et utiliser l’authentification Windows dans votre machine virtuelle. Actuellement, Azure prend en charge les connexions VPN sécurisées de site à site et de point à site :

      • La connexion de site à site sécurisée permet d’établir une connectivité réseau entre votre réseau local et votre réseau virtuel dans Azure. Nous vous recommandons de connecter votre environnement de centre de données local à Azure.
      • Une connexion de point à site sécurisée permet d’établir une connectivité réseau entre votre réseau virtuel dans Azure et vos machines individuelles exécutées. Cette connexion est généralement recommandée pour le développement et les tests.

      Pour plus d’informations sur la façon de se connecter à SQL Server dans Azure, consultez la page Connexion à une machine virtuelle SQL Server sur Azure.

4. Configurez les tâches planifiées et les alertes qui sauvegardent les données locales sur un disque de machine virtuelle dans Azure. Pour plus d’informations, consultez les pages Sauvegarde et restauration SQL Server avec le Stockage Blob Azure et Sauvegarde et restauration pour SQL Server sur des machines virtuelles Azure.

5. Selon les besoins de votre application, vous pouvez implémenter l’un des trois scénarios courants suivants :

   1. Vous pouvez conserver votre serveur web, votre serveur d’applications et vos données non sensibles dans un serveur de base de données dans Azure, tout en conservant vos données sensibles en local.
   2. Vous pouvez conserver votre serveur web et votre serveur d’applications en local, tout en conservant le serveur de base de données dans une machine virtuelle dans Azure.
   3. Vous pouvez conserver votre serveur de base de données, votre serveur web et votre serveur d’applications en local, tout en conservant les réplicas de base de données dans des machines virtuelles dans Azure. Cette configuration permet aux applications de création de rapports et aux serveurs web locaux d’accéder aux réplicas de base de données dans Azure. Ceci permet de réduire la charge de travail d’une base de données locale. Nous vous recommandons d’implémenter ce scénario pour les charges de travail de lecture volumineuses et pour le développement. Pour plus d’informations sur la création de réplicas de base de données dans Azure, consultez Groupes de disponibilité Always On dans Haute disponibilité et reprise d’activité pour SQL Server sur des machines virtuelles Azure.

Comparaison des stratégies de développement web dans Azure

Pour implémenter et déployer une application multiniveau basée sur SQL Server dans Azure, vous pouvez utiliser une des deux méthodes de programmation suivantes :

• Configurez un serveur web classique (IIS - Internet Information Services) dans Azure et accédez aux bases de données dans SQL Server sur machines virtuelles Azure.
• Implémentez et déployez un service cloud dans Azure. Puis, assurez-vous que ce service cloud peut accéder aux bases de données dans SQL Server sur machines virtuelles Azure. Un service cloud peut inclure plusieurs rôles web et de travail.

Le tableau suivant présente une comparaison entre le développement web traditionnel avec Azure Cloud Services et Azure Web Apps par rapport à SQL Server sur machines virtuelles Azure. Ce tableau inclut Azure Web Apps, car vous pouvez utiliser SQL Server dans une machine virtuelle Azure en tant que source de données pour Azure Web Apps via son adresse IP virtuelle publique ou son nom DNS.

	Développement web classique dans Azure Virtual Machines	Services cloud dans Azure	Hébergement web avec Azure Web Apps
Migration d’applications au niveau local	Applications existantes telles quelles.	Les applications ont besoin de rôles web et de travail.	Les applications existantes telles quelles, mais convient pour les applications web autonomes et les services web qui nécessitent une extensibilité rapide.
Déploiement et développement	Visual Studio, WebMatrix, Visual Web Developer, WebDeploy, FTP, TFS, Gestionnaire des services Internet, PowerShell.	Visual Studio, Kit de développement logiciel (SDK) Azure, TFS, PowerShell. Chaque service cloud comporte deux environnements dans lesquels vous pouvez déployer vos packages de service et votre configuration : un environnement intermédiaire et un environnement de production. Vous pouvez déployer un service cloud dans l'environnement intermédiaire afin d'effectuer des tests avant de le passer en production.	Visual Studio, WebMatrix, Visual Web Developer, FTP, GIT, BitBucket, CodePlex, DropBox, GitHub, Mercurial, TFS, WebDeploy, PowerShell.
Administration et paramétrage	Vous êtes responsable des tâches administratives sur les applications, les données, les règles de pare-feu, le réseau virtuel et le système d’exploitation.	Vous êtes responsable des tâches administratives sur les applications, les données, les règles de pare-feu et le réseau virtuel.	Vous êtes responsable des tâches administratives sur l’application et les données uniquement.
Haute disponibilité et reprise d’activité (HADR)	Nous vous recommandons de placer les machines virtuelles dans le même groupe à haute disponibilité et dans le même service cloud. Le fait de garder vos machines virtuelles dans le même groupe à haute disponibilité permet à Azure de placer les nœuds de haute disponibilité dans des domaines d’erreur et des domaines de mise à niveau distincts. De même, le fait de garder vos machines virtuelles dans le même service cloud permet l’équilibrage de charge et la communication directe entre vos machines virtuelles via le réseau local dans le centre de données Azure. Vous êtes responsable de l’implémentation d’une solution de haute disponibilité et de reprise d’activité pour SQL Server sur machines virtuelles Azure afin d’éviter tout temps d’arrêt. Pour connaître les technologies HADR prises en charge, consultez la page Haute disponibilité et reprise d’activité pour SQL Server sur des machines virtuelles Azure. Vous êtes chargé de sauvegarder votre application et vos données. Azure peut déplacer vos machines virtuelles si l’ordinateur hôte du centre de données tombe en panne en raison de problèmes matériels. De plus, il est possible que des temps d’arrêt planifiés soient appliqués à vos machines virtuelles lorsque les machines hôtes sont mises à jour pour des raisons de sécurité ou de mises à jour logicielles. Par conséquent, nous vous conseillons de tenir à jour au moins deux machines virtuelles dans chaque niveau d’application pour garantir une disponibilité continue. Azure ne fournit pas de contrat SLA pour une seule machine virtuelle.	Azure gère les défaillances résultant du logiciel de système d’exploitation ou du matériel sous-jacent. Nous vous recommandons d’implémenter plusieurs instances d’un rôle web ou de travail pour garantir la haute disponibilité de votre application. Pour plus d’informations, consultez Contrats de niveau de service pour les services cloud, machines virtuelles et réseaux virtuels. Vous êtes chargé de sauvegarder votre application et vos données. Vous êtes responsable de l’implémentation d’une solution de récupération d’urgence pour éviter tout temps d’arrêt dans les bases de données résidant dans une base de données SQL Server dans une machine virtuelle Azure. Pour connaître les technologies HADR prises en charge, consultez la page Haute disponibilité et reprise d’activité pour SQL Server sur des machines virtuelles Azure. Mise en miroir de base de données SQL Server : Utilisation avec Azure Cloud Services (rôles web/de travail). Les machines virtuelles SQL Server et un projet de service cloud peuvent être situés dans le même réseau virtuel Azure. Si votre machine virtuelle SQL Server n’est pas dans le même réseau virtuel, vous devez créer un alias SQL Server pour acheminer la communication vers l’instance de SQL Server. De plus, le nom de l’alias doit correspondre à celui de l’instance de SQL Server.	La haute disponibilité est obtenue à partir des rôles de travail Azure, du Stockage Blob Azure et d’Azure SQL Database. Par exemple, Azure Storage conserve trois réplicas de l’ensemble des données d’objets blob, de tables et de files d’attente. À tout moment, Azure SQL Database conserve trois réplicas des données en cours d’exécution : un réplica principal et deux réplicas secondaires. Pour en savoir plus, consultez Stockage Azure et Azure SQL Database. Quand vous utilisez SQL Server dans une machine virtuelle Azure comme source de données pour Azure Web Apps, n’oubliez pas qu’Azure Web Apps ne prend pas en charge Azure Virtual Network. En d’autres termes, toutes les connexions à partir d’Azure Web Apps vers les machines virtuelles SQL Server dans Azure doivent passer par des points de terminaison publics de machines virtuelles. Cela peut entraîner des limitations pour les scénarios de haute disponibilité et de récupération d’urgence. Par exemple, l’application cliente sur Azure Web Apps qui se connecte à une machine virtuelle SQL Server avec une mise en miroir de base de données ne peut pas se connecter au nouveau serveur principal, car la mise en miroir de base de données nécessite une configuration du service Azure Virtual Network entre les machines virtuelles hébergeant SQL Server dans Azure. Par conséquent, l’utilisation de la mise en miroir de bases de données SQL Server avec Azure Web Apps n’est pas prise en charge pour le moment. Groupes de disponibilité SQL Server Always On : vous pouvez configurer des groupes de disponibilité Always On lors de l’utilisation d’Azure Web Apps avec des machines virtuelles SQL Server dans Azure. Toutefois, vous devez configurer l’écouteur de groupe de disponibilité Always On pour acheminer la communication vers le réplica principal par le biais de points de terminaison publics avec équilibrage de charge.
Connectivité intersite	Vous pouvez utiliser Azure Virtual Network pour vous connecter à des infrastructures locales.	Vous pouvez utiliser Azure Virtual Network pour vous connecter à des infrastructures locales.	Azure Virtual Network est pris en charge.
Extensibilité	La montée en puissance peut être appliquée en augmentant les tailles des machines virtuelles ou en ajoutant des disques. Pour plus d’informations sur les tailles de machines virtuelles, voir Tailles de machines virtuelles pour Azure. Pour le serveur de base de données : la montée en charge est disponible via l’utilisation de techniques de partitionnement de base de données et de groupes de disponibilité SQL Server Always On. Pour les charges de travail en lecture volumineuses, vous pouvez utiliser des groupes de disponibilité Always On sur plusieurs nœuds secondaires ainsi que la réplication SQL Server. Pour les charges de travail en écriture volumineuses, vous pouvez implémenter le partitionnement horizontal des données sur plusieurs serveurs physiques pour fournir une montée en charge des applications. En outre, vous pouvez implémenter une montée en charge à l’aide de SQL Server avec le routage dépendant des données. Avec le routage dépendant des données (DDR), vous devez implémenter un mécanisme de partitionnement dans l’application cliente, généralement dans la couche de niveau métier, pour acheminer les demandes de base de données vers plusieurs nœuds SQL Server. Le niveau métier contient des mappages permettant de définir la méthode de partitionnement des données et le nœud qui contient les données. Vous pouvez faire évoluer les applications qui exécutent des machines virtuelles. Pour plus d’informations, consultez Mise à l’échelle automatique d’une application. Remarque importante : La fonctionnalité de mise à l’échelle automatique d’Azure permet d’augmenter ou de diminuer automatiquement le nombre de machines virtuelles utilisées par votre application. Cette fonctionnalité garantit que l’utilisateur final n’est pas affecté par les périodes de pointe et que des machines virtuelles sont arrêtées lorsque la demande est faible. Il est déconseillé de configurer l’option de mise à l’échelle automatique pour votre service cloud s’il comprend des machines virtuelles SQL Server. En effet, la fonctionnalité de mise à l’échelle automatique permet à Azure d’activer une machine virtuelle lorsque l’utilisation du processeur d’une machine virtuelle est supérieure à un certain seuil, et de désactiver une machine virtuelle lorsque l’utilisation du processeur est inférieure à ce seuil. La fonctionnalité de mise à l’échelle automatique est utile pour les applications sans état, comme les serveurs web, où aucune machine virtuelle ne peut gérer la charge de travail sans aucune référence à un état antérieur. Cependant, la fonctionnalité de mise à l’échelle automatique n’est pas utile pour les applications avec état, comme SQL Server, où une seule instance autorise l’écriture dans la base de données.	La montée en puissance peut être appliquée en utilisant plusieurs rôles web et de travail. Pour plus d’informations sur les tailles de machines virtuelles pour les rôles web et worker, voir Configurer les tailles des services cloud. Lorsque vous utilisez Azure Cloud Services, vous pouvez définir plusieurs rôles pour distribuer le traitement et bénéficier d’une mise à l’échelle flexible de votre application. Chaque service cloud se compose d’un ou plusieurs rôles web et/ou de travail, chacun comportant ses propres fichiers d’application et sa configuration. Vous pouvez monter en puissance un service cloud en augmentant le nombre d’instances de rôle (machines virtuelles) déployées pour un rôle et réduire la puissance d’un service cloud en diminuant le nombre d’instances de rôle. Pour plus d’informations, voir Modèles d’exécution Azure. La montée en charge est disponible via la prise en charge de la haute disponibilité Azure intégrée via le contrat de niveau de service pour Services cloud, Machines Virtuelles et Réseau virtuel et l’équilibrage de charge. Pour une application multiniveau, nous vous recommandons de connecter l’application des rôles web/de travail aux machines virtuelles du serveur de base de données via Azure Virtual Network. De plus, Azure fournit l’équilibrage de la charge pour les machines virtuelles appartenant à un même service cloud, en répartissant entre elles les requêtes utilisateur. Les machines virtuelles ainsi connectées peuvent communiquer directement entre elles sur le réseau local dans un centre de données Azure. Vous pouvez configurer la mise à l’échelle automatique sur le portail Azure, ainsi que les heures de planification. Pour plus d’informations, consultez Configuration de la mise à l’échelle automatique d’un service cloud dans le portail.	Scale up/Scale down – Évolution : Vous pouvez augmenter ou diminuer la taille de l’instance (machine virtuelle) réservée pour votre site web. Effectuer un scale-out : Vous pouvez ajouter davantage d’instances réservées (machines virtuelles) pour votre site web. Vous pouvez configurer la mise à l’échelle automatique sur le portail, ainsi que les heures de planification. Pour plus d’informations, consultez Mise à l’échelle des applications web.

Pour plus d’informations sur le choix entre ces méthodes, consultez la page Applications web, services cloud et machines virtuelles Azure : quand les utiliser ?

Étape suivante

Pour plus d’informations sur l’exécution de SQL Server sur les machines virtuelles Azure, consultez la page Vue d’ensemble de SQL Server sur les machines virtuelles Azure.