Déploiement de SQL Server sur Azure Local avec des opérations déconnectées

S'applique à :SQL Server

Cet article décrit comment planifier, déployer, sécuriser et exploiter SQL Server sur Windows Server ou sur des machines virtuelles Linux (VM) prises en charge dans Azure Local avec des opérations déconnectées.

Avant de commencer :

  • Obtenez l’approbation de votre organisation.
  • Obtenez la plateforme d’opérations hors ligne.
  • Déployez la plateforme à l’intérieur des limites de sécurité de votre organisation.

Les charges de travail de SQL Server, le plan de contrôle local, les données de gestion, l’intégration des identités et la gouvernance restent sur site. L'environnement ne nécessite pas une connectivité continue à Azure ou à Internet. Utilisez des flux de transfert approuvés en étapes ou hors ligne pour les mises à jour, les packs de support, les données d’enregistrement et d’autres artefacts nécessaires.

Pour les déploiements qui maintiennent la connectivité à Azure, voir Deploy SQL Server on Azure Local.

Quand utiliser des opérations déconnectées

Prenez en compte les opérations hors connexion pour :

  • Des environnements souverains, réglementés ou isolés où la connectivité du cloud public est interdite ou peu fiable.
  • Des sites nécessitant une exécution locale, une administration locale et un contrôle des données et de la télémétrie opérationnelle.
  • Des charges de travail SQL Server qui nécessitent la virtualisation et le stockage Azure Local sans dépendre du plan de contrôle public Azure.

Vous pouvez exécuter localement des charges de travail transactionnelles, analytiques, d’intelligence économique et d’entrepôts de données. Intégrez les VM SQL Server avec vos systèmes d’identité sur site, de surveillance, de sauvegarde, de sécurité, de patching et de distribution logicielle approuvés.

Important

L'extension SQL Server pour Azure Arc n'est pas prise en charge pour les opérations déconnectées. Les capacités d’inventaire d’Azure Arc SQL Server, d’évaluation des meilleures pratiques et de gestion de SQL Server basées sur Azure ne sont pas disponibles via cette extension. Utilisez les outils locaux pris en charge pour gérer et surveiller SQL Server dans chaque VM.

Prerequisites

Avant de déployer SQL Server, confirmez que vous avez :

  • Ces prérequis ne nécessitent pas une connectivité continue à Azure ou à Internet.
  • Un environnement d'opérations déconnectées Azure Local approuvé, déployé sur du matériel supporté à l'intérieur des limites de sécurité de votre organisation. Examinez les services pris en charge et terminez le déploiement de la plateforme avant de continuer.
  • Des images Windows Server ou Linux prises en charge et une capacité de calcul et de stockage suffisante pour créer des machines virtuelles de charge de travail.
  • Réseau local, identité, certificats et synchronisation temporelle qui répondent aux exigences réseau et d’identité de la plateforme.
  • Licences appropriées pour SQL Server et licences distinctes pour la plateforme Azure Local pour les opérations déconnectées. Examinez les limites de licences et de support ainsi que la facturation des opérations déconnectées.
  • Supports d’installation SQL Server approuvés, mises à jour cumulatives, pilotes, outils de gestion et paquets préalables, avec un processus hors ligne contrôlé pour transférer et vérifier ces artefacts.
  • Surveillance locale et cibles de sauvegarde protégées pour les charges de travail SQL Server, distinctes des sauvegardes sur plan de contrôle.
  • Un processus de maintenance hors ligne approuvé pour SQL Server et les mises à jour invitées du système d’exploitation.

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 conseils suivants pour concevoir vos machines virtuelles SQL Server :

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.

Installer et configurer SQL Server

  1. Créez des machines virtuelles Windows Server ou Linux prises en charge en suivant le guide des machines virtuelles pour les opérations déconnectées.
  2. Transférez les supports d’installation approuvés, les mises à jour cumulatives, les pilotes, les outils de gestion et les packages préalables via votre processus hors ligne contrôlé.
  3. Installez SQL Server en suivant les instructions pour Windows ou Linux. Installez uniquement les fonctionnalités dont vous avez besoin. Utilisez des fichiers de configuration reproductibles ou de l’automatisation, protégez les clés de produit et les identifiants, et documentez la base de la compilation.
  4. Applique la mise à jour cumulative approuvée. Configurez les comptes de service, l’authentification, les certificats TLS, les règles de pare-feu, la compilation, max server memoryla tempdbcroissance des fichiers de base de données et la compression de sauvegarde.
  5. Valider la latence de stockage, la pression du processeur et de la mémoire, la connectivité, l’intégrité de la base de données, les sauvegardes, les opérations de restauration et le comportement des applications avant l’utilisation en production.

Configurer la haute disponibilité et la récupération d’urgence

Concevoir la disponibilité et la récupération pour la charge de travail de SQL Server séparément du plan de contrôle Azure Local.

Options de disponibilité de SQL Server

  • Groupes de disponibilité toujours activés : Utilisez des machines virtuelles SQL Server séparées et placez des répliques entre les domaines de défaillance physiques. Pour les déploiements Windows, configurez le cluster de basculement Windows Server, un témoin local et un quorum, des auditeurs et un comportement de réessayage d’application sans dépendre d’Azure Cloud Witness. Consultez l’aperçu des groupes de disponibilité et les conseils pour débuter.
  • Instances de cluster de basculement sous Windows : Utilisez un stockage partagé pris en charge et une configuration SQL Server en cluster prise en charge lorsque vous avez besoin d’une protection au niveau des instances. Voir Instances de cluster de basculement Always On et Installation d’un cluster de basculement SQL Server.
  • Résilience de l'hôte : Utilisez un placement conscient du cluster et une anti-affinité afin que les répliques SQL Server ne partagent pas le même nœud physique ou le même domaine de défaillance.

Pour connaître la configuration requise pour le clustering Windows, consultez Windows Server Failover Clustering with SQL Server.

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. Vérifiez que votre distribution Linux, votre gestionnaire de cluster, votre mécanisme de clôture et votre configuration de stockage sont pris en charge dans votre environnement Azure Local déconnecté avant de déployer. Les procédures Windows mentionnées ici n'établissent pas de prise en charge d'une topologie Linux.

Conception de récupération

Définissez les objectifs de récupération pour chaque base de données. Séparez les sauvegardes SQL Server cohérentes avec l’application des sauvegardes du plan de contrôle. Répliquez ou exportez les sauvegardes vers une zone ou un site de sécurité secondaire approuvé, protégez les clés de chiffrement de manière indépendante et effectuez des tests de restauration programmés.

Pour plus d’informations, consultez la vue d’ensemble de la restauration et de la récupération de SQL Server.

Sécuriser SQL Server

Appliquez une base de sécurité SQL Server qui fonctionne sans services de cloud public :

  • Sous Windows, utilisez des comptes de domaine à privilège minimum ou de service géré lorsque cela est supporté. Utilisez la configuration d’identité de service prise en charge par votre système d’exploitation, et restreignez les autorisations de sauvegarde, de surveillance et d’identité d’applications.
  • Privilégiez l’authentification intégrée lorsque cela est supporté. Sous Linux, l’authentification Active Directory utilise Kerberos et nécessite une configuration du nom de principal de service (SPN) et du fichier keytab propres à SQL Server. L'intégration de l'identité de plateforme ne configure pas l'authentification SQL Server. Restreignez sysadmin l’adhésion, supprimez les connexions et fonctionnalités inutilisées, désactivez les protocoles faibles et réexaminez régulièrement les permissions.
  • Exigez TLS pour les connexions clients. Pour le trafic des réplicas du groupe de disponibilité, configurez l’authentification et le chiffrement sur les points de terminaison de mise en miroir de la base de données. Gérez les certificats via votre infrastructure locale de clé publique (PKI), et surveillez l’état d’expiration et de la chaîne de confiance.
  • Protéger les données avec un chiffrement transparent des données (TDE) ou un chiffrement de volumes selon le cas. Chiffrer les sauvegardes, stocker les clés séparément, et tester la récupération des clés.
  • Activez SQL Server Audit ou des contrôles équivalents pour les activités privilégiées, les échecs de connexion, les modifications des permissions, l’accès à des objets sensibles et les modifications de configuration.

Considérations de sécurité hors connexion

  • Maintenir un dépôt hors ligne approuvé pour les mises à jour, pilotes, outils, définitions de sécurité et dépendances de SQL Server. Vérifiez les signatures et scannez les artefacts importés.
  • Pour les appels REST externes, n’autorisez que les terminaux HTTPS locaux approuvés. Utilisez des informations d’identification limitées à la base de données, restreignez EXECUTE ANY EXTERNAL ENDPOINT et auditez les requêtes. Examinez les autorisations et les exigences de terminaison pour sp_invoke_external_rest_endpoint.
  • Documentez l’accès d’urgence, la rotation des identifiants, le renouvellement des certificats, la désinfection des packs de support et les procédures de récupération qui ne dépendent pas des services du cloud public.

Surveillance de SQL Server

Vous pouvez surveiller l’infrastructure Azure Local, les services de contrôle et la santé des machines virtuelles via des solutions de surveillance externes configurées. Installez et configurez les agents et packs de gestion nécessaires pour votre solution de surveillance. Disconnected Operations ne propose pas de service dédié de surveillance SQL Server.

Surveillez SQL Server à l’intérieur de chaque VM avec des fonctionnalités natives, telles que des vues de gestion dynamique, des événements étendus et des journaux d’erreurs, ou une plateforme de surveillance sur site approuvée. 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.

Recueillez les signaux suivants, selon votre charge de travail :

  • Disponibilité de SQL Server, statut de base de données, âge de sauvegarde et échecs de tâches.
  • Blocages, blocages, attentes, utilisation du processeur et pression mémoire.
  • Latence de stockage, augmentation de la taille des bases de données et des journaux, et intégrité de tempdb.
  • Synchronisation des répliques à haute disponibilité.

Conservez la télémétrie dans les dépôts locaux approuvés. Définissez des seuils d’action et des procédures d’escalade. Pour la surveillance de la plateforme, voir Surveiller les opérations déconnectées.

Sauvegardez et récupérez SQL Server

Important

La capacité de sauvegarde des opérations déconnectées protège uniquement les données des machines virtuelles du plan de contrôle. Il ne sauvegarde pas les charges de travail SQL Server ni les clusters de charges de travail configurés. Configurez les sauvegardes SQL Server séparément.

  1. Sélectionnez les modèles de récupération en fonction de vos RPO. Planifiez des sauvegardes complètes et, si besoin, des sauvegardes différentielles vers un stockage local protégé. Pour les bases de données utilisant le modèle de récupération complète ou en bloc, planifiez également des sauvegardes dans les journaux de transaction. Le modèle de récupération simple ne supporte pas les sauvegardes de journaux de transactions ni la récupération à un moment donné. Utilisez la compression, les sommes de contrôle et le chiffrement lorsque cela est approprié.
  2. Conservez des copies dans un domaine ou site de défaillance séparé. Protégez indépendamment les clés de sauvegarde et de chiffrement, et surveillez la capacité et l’ancienneté des sauvegardes.
  3. Testez les restaurations d'hôte complètes et alternatives. Lorsque la récupération à un instant donné est requise, utilisez le modèle de récupération complet, maintenez la chaîne des sauvegardes du journal des transactions et testez les restaurations à un instant donné. Avec le mode de récupération utilisant la journalisation en mode bloc, vous ne pouvez pas effectuer une restauration jusqu’à un instant précis à l’intérieur d’une sauvegarde du journal contenant des modifications journalisées en mode bloc. Consignez les RPO et RTO atteints, et remédiez aux lacunes.

Pour les procédures, voir Sauvegarder et restaurer les bases de données SQL Server, Créer une sauvegarde complète de la base de données, ainsi que la vue d’ensemble de restauration et de récupération.

Service SQL Server hors ligne

Maintenir les bases de référence approuvées pour les mises à jour cumulatives de SQL Server, les correctifs invités du système d’exploitation, les pilotes, les outils de gestion et les logiciels de sécurité :

  • Mises à jour des tests dans un environnement représentatif déconnecté.
  • Sauvegardez les charges de travail avant d’appliquer les mises à jour.
  • Patcher les répliques à haute disponibilité dans une séquence contrôlée.
  • Validez le basculement, la connectivité des applications et les performances après la mise à jour.
  • Microsoft publie la mise à jour cumulative (CU), la version générale de distribution (GDR) ou la mise à jour de sécurité applicables de SQL Server via les canaux de mise à jour standard de service SQL Server ainsi que les dernières mises à jour et historiques des versions de SQL Server.

Livrer SQL Server et mises à jour invitées via un mécanisme approuvé pour le système d’exploitation invité :

Suivez les instructions distinctes relatives à la mise à jour des opérations déconnectées pour les mises à jour de la plateforme.

Développer des applications d’IA locales

SQL Server 2025 peut se connecter à des terminaux locaux approuvés pour complétion de chat, tels que les déploiements compatibles de Foundry Local. Les applications peuvent combiner des données SQL avec l’inférence de modèles sur site sans nécessiter de connectivité cloud publique.

Foundry Local sur Azure Local est en aperçu. Complétez ses prérequis de déploiement et d’accès avant d’intégrer un modèle avec SQL Server. 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.
  • Rendez le point de terminaison HTTPS du modèle déployé accessible depuis la VM SQL Server. Configurez les certificats TLS et la confiance des certificats pour une utilisation en production. Ne comptez pas sur des tests d’inférence qui contournent la validation des certificats.

Examinez les points de terminaison pris en charge et les exigences de sécurité avant d’utiliser sp_invoke_external_rest_endpoint. Pour le déploiement et l’inférence de modèles, consultez Foundry Local sur Azure Local, effectuez l’inférence et apportez vos propres modèles.

L’inférence locale des modèles n’établit pas que les outils développeurs peuvent fonctionner sans connectivité cloud. Validez séparément les exigences d’authentification, de client et de connectivité de chaque outil avant de les inclure dans un flux de travail déconnecté.

Limites de licence et de soutien

Choisissez le modèle de licence SQL Server avant de finaliser la taille et la topologie de disponibilité des machines virtuelles. Évaluer les exigences d’édition, les licences de cœur virtuel, les licences éligibles pour cœurs physiques avec virtualisation illimitée, les droits d’assurance logicielle ou d’abonnement, et les droits non liés à la production. La capacité de la plateforme d’opérations déconnectées Azure Local est licenciée séparément.

  • Édition : Valider les exigences en fonctionnalités standard et d’entreprise, y compris la disponibilité, l’échelle, les opérations en ligne et les droits de virtualisation.
  • Portée de la licence : Comparez la licence par VM à cœur virtuel avec les modèles à cœur physique éligibles, en particulier lors de la consolidation des VM SQL Server.
  • Modèle de licence : Valider les exigences d’assurance logicielle SQL Server ou d’abonnement ainsi que l’éligibilité à Azure Hybrid Benefit pour les opérations déconnectées.
  • Dossiers : Tenir des inventaires des hôtes, VM, cœurs assignés, éditions, environnements et preuves de licence.

Consultez la facturation des opérations hors connexion pour connaître les conditions d’utilisation de la plateforme. Le SQL Server activé par la documentation de licence Azure Arc décrit l'expérience de gestion connectée ; ce n'est pas une procédure pour installer l'extension SQL Server non prise en charge dans des opérations déconnectées.

Contenu connexe

  • Dernière mise à jour :