Déployez SQL Server sur Azure Local

S'applique à :SQL Server

Cet article décrit comment déployer SQL Server sur Azure Local en mode connecté. SQL Server fonctionne sur Windows Server ou des machines virtuelles Linux (VM) dans un cluster Azure Local qui maintient la connectivité à Azure. Cette configuration combine exécution locale et résidence des données avec la gestion, la surveillance, la facturation et les services hybrides basés sur Azure.

Pour les environnements sans connectivité continue à Azure, voir Déployer SQL Server sur Azure Local avec opérations déconnectées.

Prerequisites

Avant de commencer, assurez-vous que vous avez :

Le flux de travail suivant couvre le déploiement d’Azure Local et la création des machines virtuelles SQL Server.

Planifiez la charge de travail de SQL Server

Avant de dimensionner les VM, capturez les exigences de la charge de travail :

  • Sélectionnez la version et l’édition de SQL Server en fonction de la taille de la base de données, des fonctionnalités de disponibilité, des opérations en ligne, des droits de virtualisation et du cycle de vie du support.
  • Enregistrer l’utilisation maximale du processeur, la mémoire de l’ensemble de travail, les opérations d’entrée/sortie par seconde (IOPS), le débit, la latence, la croissance de la base de données, la tempdb demande, le taux de génération de logarismes et la concurrence.
  • Définir les objectifs de points de récupération (RPO) et les objectifs de temps de récupération (RTO).
  • Identifier les dépendances applicatives, les méthodes d’authentification, les exigences de sécurité de la couche de transport (TLS), les ports, les comptes de service, les fenêtres de maintenance, la rétention de sauvegarde et les dépendances logicielles hors ligne.

Concevoir les machines virtuelles SQL Server

Utilisez les considérations suivantes lors de la conception de chaque VM :

Zone de conception Conseils sur SQL Server
Compute Dimensionnez les CPU virtuels pour une utilisation durable et une efficacité de licence. Évitez la surabonnement qui crée une latence de requête imprévisible.
Memory Réservez la mémoire pour le système d’exploitation, les agents, les pilotes et l’activité de basculement. Configurez max server memory pour que SQL Server ne consomme pas la mémoire nécessaire aux autres processus.
Storage Utilisez des volumes séparés pour le système d’exploitation, les données, les journaux tempdbde transactions et les sauvegardes. Validez la latence, le débit, la profondeur de file d’attente, la capacité, la résilience et les seuils d’espace libre.
Network Fournir des chemins clients stables, de gestion, de sauvegarde et de réplication selon les besoins. Validez le DNS, l’unité de transmission maximale (MTU), les règles du pare-feu, la confiance TLS et la connectivité de l’auditeur.
Sélection élective Placez des répliques à haute disponibilité sur différents nœuds Azure Local ou domaines de défaillance. Utilisez l’anti-affinité quand c’est possible.

Workflow du déploiement

Les étapes suivantes vous mènent du déploiement de l’infrastructure à la gestion connectée de SQL Server.

Stage Résultat
Acquérir du matériel et déployer Azure Local Un environnement Azure Local pris en charge.
Créer des machines virtuelles et installer SQL Server SQL Server fonctionnant sur Windows Server ou Linux.
Surveillez et réglez SQL Server Une référence pour la performance et la santé de SQL Server.
Configurez la haute disponibilité Une architecture de disponibilité spécifique à la charge de travail, comme les groupes de disponibilité ou les instances de cluster de basculement.
Connecter SQL Server à Azure Arc Inventaire, gouvernance, sécurité et licences centralisés.

Déployer Azure Local

Déployez Azure Local en suivant la vue d’ensemble de déploiement Azure Local. Remplissez les prérequis de déploiement et le processus de déploiement applicables avant de créer des machines virtuelles pour vos charges de travail SQL Server.

Créer des machines virtuelles et installer SQL Server

  1. Créez des machines virtuelles Windows Server ou Linux sur Azure Local pour vos charges de travail SQL Server.

  2. Installez SQL Server en suivant les instructions de votre système d’exploitation :

  3. Examinez les exigences de licence et de facturation de SQL Server et configurez le modèle de licence approprié.

Surveillez et réglez SQL Server

Surveillez SQL Server avec des vues de gestion dynamique, des événements étendus, des journaux d’erreur et une solution de surveillance prise en charge par le système d’exploitation invité. Sous Windows, vous pouvez également utiliser les alertes SQL Server Agent et les compteurs de performance Windows. Les alertes SQL Server Agent ne sont pas prises en charge sur Linux ; examinez la prise en charge des fonctionnalités SQL Server sur Linux pour votre version.

Établissez une base de référence pour l’utilisation du processeur, la pression mémoire, la latence de stockage, le blocage, la croissance de la base de données et la santé des sauvegardes avant d’ajuster la charge de travail. Après avoir connecté SQL Server à Azure Arc, vous pouvez également effectuer une évaluation des bonnes pratiques, sous réserve de ses prérequis.

Configurer la haute disponibilité

Azure Local offre une résilience au niveau de l’hôte pour les machines virtuelles. Configurez séparément la haute disponibilité de SQL Server pour répondre aux exigences de disponibilité de votre base de données ou de votre instance :

Pour Linux, un groupe de disponibilité sans gestionnaire de cluster fournit des réplicas avec échelle lecture, pas une haute disponibilité. Les déploiements à haute disponibilité nécessitent un gestionnaire de cluster supporté, comme Pacemaker, et les déploiements en production nécessitent un encadrement. Voir Configurer les groupes de disponibilité sous Linux. Validez la distribution Linux, le gestionnaire de cluster, le mécanisme de clôture et le support du stockage pour votre configuration Azure Local ; les procédures Windows ne s'appliquent pas inchangées à Linux.

Planifiez la protection de la charge de travail séparément de la résilience des infrastructures. Pour les options Sauvegarde Azure et Azure Site Recovery, examinez la résilience des charges de travail Azure Local et la reprise après sinistre ainsi que les exigences de support pour votre charge de travail.

Connecter SQL Server à Azure Arc

Connecter les instances de SQL Server fonctionnant sur Azure Local à Azure Arc pour créer des ressources Azure pour une gestion centralisée.

  1. Validez les prérequis Azure Arc.
  2. Suivez Connect SQL Server vers Azure Arc pour générer et exécuter le script d’intégration.
  3. Confirmez que les ressources SQL Server apparaissent dans le portail Azure.

Après l’intégration, vous pouvez utiliser les fonctionnalités suivantes, selon leurs exigences de version et de configuration :

Capability Conseils
Inventaire et création de rapports Consultez les instances, bases de données, versions, éditions et systèmes d’exploitation hôtes. Utilisez Azure Resource Graph pour interroger à travers votre domaine SQL Server. Voir SQL Server activé par Azure Arc.
Évaluation des meilleures pratiques Recevez des recommandations pour la performance et la sécurité. Voir évaluation des meilleures pratiques.
Identity Utilisez l’authentification Microsoft Entra, sous réserve de sa version et des exigences du système d’exploitation. La configuration de l'identité gérée pour l'authentification Microsoft Entra nécessite SQL Server 2025 compatible Arc sur Windows Server et utilise l'identité assignée au système du serveur compatible Arc. L'authentification Microsoft Entra n'est pas prise en charge avec les instances de cluster de basculement.
sécurité et gouvernance Configurez Microsoft Defender for Cloud, ou enregistrez-vous et scannez SQL Server avec Microsoft Purview.
Operations Gérer la configuration et exécuter les scripts approuvés sur les serveurs embarqués. Voir SQL Server activé par Azure Arc et Gérer la configuration.

Configurez la licence via Azure Arc

Utilisez SQL Server activé par Azure Arc pour déclarer et gérer le modèle de licence et de facturation pour vos instances SQL Server :

  • Pay-as-you-go : Abonnez-vous via Azure et payez pour les cœurs sous licence rapportés par Azure Arc. Ce modèle peut s’adapter à des charges de travail variables, temporaires ou incrémentales.
  • Licence avec Software Assurance ou abonnement : Déclarez une licence SQL Server existante couverte par un logiciel Assurance actif ou un abonnement SQL Server. Azure Arc enregistre le type de licence et permet les avantages de gestion applicables.
  • Étendue du cœur : évaluez les licences virtuelles pour les VM individuelles et les licences physiques d’entreprise éligibles avec virtualisation illimitée. Validez l’éligibilité avant de choisir un modèle de licence.
  • Configuration : Définissez et examinez le type de licence via le portail Azure, Azure PowerShell ou Azure CLI. Appliquer des modifications à grande échelle lorsque cela est nécessaire.
  • Reporting : Gardez l’agent Azure Connected Machine et l’extension SQL Server en bonne santé afin que l’inventaire, les rapports d’utilisation et la facturation restent exacts.

Sous Linux, la facturation pay-as-you-go ne détecte pas automatiquement les répliques passives des groupes de disponibilité ni les instances de cluster de basculement. Toutes les instances de SQL Server sont annoncées comme actives, quel que soit leur rôle de haute disponibilité ou de reprise après sinistre. Tenez compte de cette différence lors de la planification des déploiements Linux. Voir les considérations du paiement au fur et à mesure.

Pour les exigences et procédures, voir Gérer la licence et la facturation, Gérer la configuration et Gérer la transition vers le paiement à l’usage.

Développer des applications d’IA locales

SQL Server 2025 peut utiliser sp_invoke_external_rest_endpoint pour appeler un point de terminaison HTTPS de complétion de chat compatible. Les applications peuvent combiner des données SQL avec des modèles hébergés localement tout en conservant l’inférence dans votre environnement.

Avant d’appeler un point de terminaison local :

  • Activez l’option de configuration du external rest endpoint enabled serveur. La procédure est désactivée par défaut dans SQL Server 2025.
  • Accordez l’autorisation au principal de base de données appelant EXECUTE ANY EXTERNAL ENDPOINT, puis configurez l’authentification et les informations d’identification requises par le point de terminaison.
  • Déploie le modèle et rends son point de terminaison HTTPS accessible depuis la VM SQL Server. Configurez les certificats TLS et la confiance des certificats pour une utilisation en production ; un test qui contourne la validation des certificats ne prouve pas que SQL Server peut se connecter en toute sécurité.

Pour plus de détails, voir les permissions et prérequis du point de terminaison REST ainsi que les directives d’inférence locale Foundry.

  • Intégration SQL Server : Envoyez des requêtes REST autorisées depuis SQL Server 2025 vers un point de terminaison de complétion de chat compatible et traitez la réponse dans votre flux de travail applicatif.
  • Inférence locale des modèles : Foundry Local sur Azure Local est en aperçu. Utilisez des modèles de catalogue compatibles avec la conversation ou des modèles à apporter votre propre modèle, et remplissez les prérequis de déploiement et d’accès de l’offre.
  • Outils de développement : Consultez GitHub Copilot et apportez votre propre clé pour les points de terminaison des modèles pris en charge et les exigences du client avant de connecter Visual Studio Code à un point de terminaison local.

Pour plus d’informations, consultez la documentation locale de Foundry et les exigences de terminaison dans sp_invoke_external_rest_endpoint.

Utilisez des VM de lancement de confiance

Le lancement de confiance pour les VM Azure Local prend en compte le Secure Boot et un module de plateforme de confiance virtuel (vTPM). Si vos VM SQL Server utilisent une protection soutenue par TPM, examinez le transfert automatique d’état pour comprendre comment l’état vTPM est géré lors de la migration ou du basculement entre les VM.

SQL Server ne nécessite pas de vTPM. Si vous utilisez un vTPM pour la protection du système d’exploitation invité ou le chiffrement, validez ces exigences séparément de la conception de votre disponibilité SQL Server.

Pour les exigences et limitations, voir Lancement de confiance pour les machines virtuelles Azure Local.

Contenu connexe

  • Dernière mise à jour :