Comprendre les scénarios hybrides

Effectué

Supposons que votre organisation ait beaucoup investi dans une infrastructure SQL Server locale et des centres de données locaux. Dans ce cas, il est essentiel de savoir que l’utilisation du cloud n’est pas une proposition du tout ou rien. Il existe des moyens d’utiliser une infrastructure locale existante dans une capacité hybride avec Azure pour améliorer la résilience opérationnelle et réduire les coûts.

L’implémentation d’une infrastructure hybride est également une excellente étape dans l’évaluation du cloud computing pour les organisations qui sont restées locales et sceptiques vis-à-vis du cloud. Dans les organisations d’aujourd’hui, il est courant d’avoir un mélange de déploiements physiques et virtualisés de SQL Server en local, qui peuvent tous s’étendre au cloud dans le cadre d’une solution hybride. La plateforme SQL Server hybride offre les avantages des services locaux et cloud. Il s’agit d’un juste milieu entre les deux. Le composant cloud utilise généralement des services IaaS tels que le stockage ou les machines virtuelles SQL Server, comme indiqué ci-dessous.

Diagramme illustrant l’infrastructure locale et l’infrastructure cloud pontées par une solution hybride.

En plus d’étendre des solutions locales, les mêmes schémas peuvent être appliqués à d’autres solutions cloud existantes, ce qui permet d’avoir des implémentations hybrides cloud à cloud. Examinons quelques-uns des scénarios hybrides les plus courants pour SQL Server.

Scénarios hybrides pour SQL Server

Examinons quelques stratégies pour le déploiement d’une solution hybride pour SQL Server.

Récupération d’urgence

La reprise d’activité après sinistre est le scénario le plus courant pour un déploiement hybride de SQL Server. La reprise d’activité signifie que les organisations garantissent la continuité de l’activité en fonction d’événements catastrophiques. Les organisations peuvent distribuer des déploiements sur plusieurs centres de données pour le basculement dans une approche locale. Ces centres de données résident généralement dans la même région géographique que l’organisation, donc il sont sujets à des catastrophes régionales plus importantes. Les centres de données physiques coûtent également cher à déployer, surveiller et gérer. Il est possible que le coût pour faire fonctionner des machines virtuelles Azure SQL Server dans différentes régions géographiques soit beaucoup moins élevé que pour installer un nouveau centre de données physique dans une autre région.

Diagramme illustrant le basculement local du siège social vers le centre de données physique et un basculement hybride vers Azure à partir du réseau local.

Dans cette approche hybride, Azure est utilisé pour le basculement DR (vers une ou plusieurs régions) tandis que le traitement normal quotidien continue d’utiliser des serveurs locaux pour la haute disponibilité locale.

Sauvegardes SQL Server

Les sauvegardes SQL Server constituent un autre scénario hybride courant. Les sauvegardes peuvent être effectuées directement dans le Stockage Azure via l’URL ou le partage de fichiers Azure (SMB). Ce scénario protège contre la perte de données lorsque le stockage de sauvegarde sur site échoue. De plus, ces sauvegardes peuvent également être restaurées sur des machines virtuelles dans Azure et testées dans le cadre des procédures de reprise d’activité.

Un autre scénario utilise le Stockage Azure afin de stocker des fichiers de données SQL Server locaux pour les bases de données utilisateur. Notez qu’il s’agit de fichiers utilisateur et non de bases de données système. En cas d’échec du stockage local, les fichiers utilisateur sont stockés en toute sécurité dans le cloud, ce qui empêche la perte de données. De plus, en utilisant le Stockage Azure, il existe des garanties de fiabilité intégrées afin que le stockage de ces fichiers dans le cloud soit plus résilient. Pour ce scénario hybride, il est essentiel de garder une communication réseau sécurisée, d’évaluer la latence réseau de la solution et de vérifier que le compte de stockage est verrouillé avec des listes de contrôle d’accès et Microsoft Entra ID.

Serveurs SQL avec Azure Arc

Le fait d’avoir des Serveurs SQL avec Azure Arc étend et centralise les services de gestion Azure aux instances SQL Server hébergées en local, dans vos centres de données, en périphérie et dans des environnements multicloud. Dans ce scénario hybride, Azure Arc permet d’avoir un inventaire de tous les déploiements de SQL Server inscrits et évalue leurs configurations, leurs modèles d’utilisation et leur sécurité pour fournir des actions et des recommandations basées sur des bonnes pratiques. Avec les Serveurs SQL avec Azure Arc, vous bénéficiez des avantages de la gestion centralisée des serveurs. Vous profitez également d’alertes de sécurité en temps réel Azure Defender et de rapports de vulnérabilités sur les serveurs SQL locaux et leurs systèmes d’exploitation hôtes. De plus, Azure Sentinel peut fournir une plus grande introspection des menaces de sécurité si nécessaire.

Diagramme illustrant un exemple d’architecture SQL Server avec Azure Arc.

Considérations relatives à la sécurité

Lors du déploiement d’une solution SQL hybride, toutes les infrastructures principales, telles qu’Active Directory et DNS, doivent exister en local et dans Azure. Une communication bidirectionnelle sécurisée doit aussi exister entre le réseau local et Azure. Cette communication sécurisée peut prendre la forme d’un VPN de site à site (S2S) ou d’un tunnel ExpressRoute dédié. Lors de l’évaluation de différentes méthodes de connectivité, il est essentiel de déterminer la quantité de latence acceptable pour votre organisation. Quelle que soit la solution choisie, la sécurité réseau doit également être au premier rang dans l’implémentation.

Diagramme de connexion illustrant un passerelle VPN de site à site vers Azure.

L’image ci-dessus montre l’avantage d’une solution VPN S2S : elle a tendance à coûter moins cher et son implémentation est une tâche courante des ingénieurs réseau. Toutefois, avec cette solution, toutes les communications se produisent sur l’Internet public et sont limitées par les vitesses Internet de l’organisation.

Diagramme de connexion illustrant une connexion ExpressRoute à Azure.

Comme nous pouvons le voir ci-dessus, la solution ExpressRoute tend à être plus chère, mais elle offre la meilleure sécurité et la latence la plus faible, car toutes les communications passent par un canal sécurisé direct indépendant de l’Internet public. Toutefois, les détracteurs de cette solution dénoncent son coût global et son incapacité à appliquer ExpressRoute entre les fournisseurs cloud dans une solution multicloud.