Partager via

Configurer un runtime d’intégration Azure-SSIS pour la continuité d’activité et reprise d’activité (BCDR)

  • Article

S’APPLIQUE À : Azure Data Factory Azure Synapse Analytics

Conseil

Essayez Data Factory dans Microsoft Fabric, une solution d’analyse tout-en-un pour les entreprises. Microsoft Fabric couvre tous les aspects, du déplacement des données à la science des données, en passant par l’analyse en temps réel, l’aide à la décision et la création de rapports. Découvrez comment démarrer un nouvel essai gratuitement !

Vous pouvez combiner Azure SQL Database/Managed Instance et SQL Server Integration Services (SSIS) dans Azure Data Factory (ADF) ou Synapse Pipelines en tant que solution PaaS recommandée pour une migration SQL Server. Vous pouvez déployer vos projets SSIS dans une base de données de catalogues SSIS (SSISDB) hébergée par Azure SQL Database/Managed Instance, et exécuter vos packages SSIS sur le runtime d’intégration (IR) Azure SSIS dans ADF ou Synapse Pipelines.

Pour la continuité d’activité et reprise d’activité (BCDR), vous pouvez configurer Azure SQL Database/Managed Instance avec un groupe de géo-réplication/basculement, où la SSISDB dans une région Azure primaire avec accès en lecture-écriture (rôle principal) sera répliquée en continu vers une région secondaire avec accès en lecture seule (rôle secondaire). Quand un incident se produit dans la région primaire, un basculement est déclenché, de sorte que les SSISDB primaire et secondaire échangent leur rôles.

Pour BCDR, vous pouvez également configurer une paire de runtimes d’intégration Azure-SSIS de secours, qui fonctionne en synchronisation avec le groupe de basculement Azure SQL Database/Managed Instance. Cela vous permet d’avoir une paire de runtimes d’intégration Azure-SSIS opérationnels. À tout moment, un seul runtime peut accéder à la SSISDB primaire pour extraire et exécuter des packages, ainsi qu’écrire des journaux d’exécution de package (rôle principal), tandis que l’autre ne peut faire de même que pour des packages déployés ailleurs, par exemple dans Azure Files (rôle secondaire). Lors du basculement de SSISDB, les runtimes d’intégration Azure-SSIS primaire et secondaire échangent également leurs rôles et, si les deux sont en cours d’exécution, le temps d’arrêt est presque nul.

Cet article explique comment configurer un runtime d’intégration Azure-SSIS avec un groupe de basculement Azure SQL Database/Managed Instance pour BCDR.

Configurer une paire de runtimes d’intégration Azure-SSIS de secours avec un groupe de basculement Azure SQL Database

Pour configurer une paire de runtimes d’intégration Azure-SSIS de secours qui fonctionne en synchronisation avec un groupe de basculement Azure SQL Database, procédez comme suit.

  1. À l’aide de l’interface utilisateur du portail Azure ou d’ADF, vous pouvez créer un runtime d’intégration Azure-SSIS (Azure-SSIS IR) avec votre serveur Azure SQL Database principal pour héberger la SSISDB dans la région primaire. Si vous disposez déjà d’un Azure-SSIS IR attaché à la SSIDB hébergée par votre serveur Azure SQL Database principal, et qu’il est toujours en cours d’exécution, vous devez l’arrêter avant de le reconfigurer. Ce sera votre Azure-SSIS IR principal.

    Quand vous choisissez d’utiliser une SSISDB dans la page Paramètres de déploiement du volet Installation du runtime d’intégration, activez également la case à cocher Utiliser la paire de runtimes d’intégration Azure-SSIS de secours avec le basculement de SSISDB. Pour Nom de la paire de secours, entrez un nom pour identifier votre paire de runtimes d’intégration Azure-SSIS primaire et secondaire. Lorsque vous terminez la création de votre Azure-SSIS IR principal, celui-ci est démarré et attaché à une SSISDB principale qui sera créée pour vous avec un accès en lecture-écriture. Si vous venez de le reconfigurer, vous devez le redémarrer.

  2. Le portail Azure vous permet de vérifier si la SSISDB principale a été créée dans la page Vue d’ensemble de votre serveur Azure SQL Database principal. Une fois la base de données créée, vous pouvez créer un groupe de basculement pour vos serveurs Azure SQL Database principal et secondaire et y ajouter la SSISDB sur la page Groupes de basculement. Une fois votre groupe de basculement créé, vous pouvez vérifier si la SSISDB principale a été répliquée sur un groupe de basculement secondaire avec un accès en lecture seule sur la page Vue d’ensemble de votre serveur Azure SQL Database secondaire.

  3. L’interface utilisateur du portail Azure ou d’ADF vous permet de créer un autre Azure-SSIS IR avec votre serveur Azure SQL Database secondaire pour héberger la SSISDB dans la région secondaire. Ce sera votre Azure-SSIS IR secondaire. Pour une BCDR complète, assurez-vous que toutes les ressources dont elle dépend sont également créées dans la région secondaire, par exemple, Stockage Azure pour le stockage des scripts/fichiers de configuration personnalisés, ADF pour l’orchestration/planification des exécutions de package, etc.

    Quand vous choisissez d’utiliser une SSISDB dans la page Paramètres de déploiement du volet Installation du runtime d’intégration, activez également la case à cocher Utiliser la paire de runtimes d’intégration Azure-SSIS de secours avec le basculement de SSISDB. Pour le Nom de la paire de secours, entrez le même nom pour identifier votre paire de runtimes d’intégration Azure-SSIS primaire et secondaire. Lorsque vous terminez la création de votre Azure-SSIS IR secondaire, celui-ci est démarré et attaché à la SSISDB secondaire.

  4. Si vous souhaitez que le temps d’arrêt occasionné par le basculement de la SSISDB soit proche de zéro, assurez-vous que les deux runtimes d’intégration Azure-SSIS sont en cours d’exécution. Seul votre Azure-SSIS IR principal peut accéder à la SSISDB principale pour extraire et exécuter des packages, ainsi que pour écrire des journaux d’exécution de package, tandis que votre Azure-SSIS IR secondaire ne peut le faire que pour des packages déployés ailleurs, par exemple, dans Azure Files.

    Si vous souhaitez réduire le coût d’exécution, vous pouvez arrêter votre Azure-SSIS IR secondaire après sa création. Quand le basculement de SSISDB se produit, vos runtimes d’exécution Azure-SSIS principal et secondaire échangent leurs rôles. Si votre Azure-SSIS IR principal est arrêté, vous devez le redémarrer. Selon qu’il est injecté dans un réseau virtuel et la méthode d’injection utilisée, son exécution prend entre 5 minutes ou de 20 à 30 minutes.

  5. Si vous utilisez ADF pour l’orchestration et la planification d’exécutions de package, assurez-vous que tous les pipelines ADF appropriés, avec les activités Exécuter le Package SSIS et les déclencheurs associés, sont copiés vers votre ADF secondaire avec les déclencheurs initialement désactivés. Lorsque le basculement de SSISDB se produit, vous devez les activer.

  6. Vous pouvez tester votre groupe de basculement Azure SQL Database et vérifier sur la page de surveillance de l’Azure-SSIS IR dans le portail ADF si vos runtimes d’intégration Azure-SSIS principal et secondaire ont échangé leurs rôles.

Configurer une paire de runtimes d’intégration Azure-SSIS IR de secours avec un groupe de basculement Azure SQL Managed Instance

Pour configurer une paire de runtimes d’intégration Azure-SSIS IR de secours qui fonctionne en synchronisation avec un groupe de basculement Azure SQL Managed Instance, procédez comme suit.

  1. La portail Azure vous permet de créer un groupe de basculement pour vos instances managées Azure SQL principale et secondaire sur la page Groupes de basculement de votre Azure SQL Managed Instance principale.

  2. L’interface utilisateur du portail Azure ou d’ADF vous permet de créer un Azure-SSIS IR avec votre Azure SQL Managed Instance principale pour héberger la SSISDB dans la région primaire. Si vous disposez déjà d’un Azure-SSIS IR attaché à la SSIDB hébergée par votre Azure SQL Managed Instance principale, et qu’il est toujours en cours d’exécution, vous devez l’arrêter avant de le reconfigurer. Ce sera votre Azure-SSIS IR principal.

    Quand vous choisissez d’utiliser une SSISDB dans la page Paramètres de déploiement du volet Installation du runtime d’intégration, activez également la case à cocher Utiliser la paire de runtimes d’intégration Azure-SSIS de secours avec le basculement de SSISDB. Pour Nom de la paire de secours, entrez un nom pour identifier votre paire de runtimes d’intégration Azure-SSIS primaire et secondaire. Lorsque vous terminez la création de votre Azure-SSIS IR principal, celui-ci est démarré et attaché à une SSISDB principale qui sera créée pour vous avec un accès en lecture-écriture. Si vous venez de le reconfigurer, vous devez le redémarrer. Vous pouvez également vérifier si la SSISDB principale a été répliquée sur un groupe de basculement secondaire avec un accès en lecture seule sur la page Vue d’ensemble de votre Azure SQL Managed Instance.

  3. L’interface utilisateur du portail Azure ou d’ADF vous permet de créer un autre Azure-SSIS IR avec votre Azure SQL Managed Instance secondaire pour héberger la SSISDB dans la région secondaire. Ce sera votre Azure-SSIS IR secondaire. Pour une BCDR complète, assurez-vous que toutes les ressources dont elle dépend sont également créées dans la région secondaire, par exemple, Stockage Azure pour le stockage des scripts/fichiers de configuration personnalisés, ADF pour l’orchestration/planification des exécutions de package, etc.

    Quand vous choisissez d’utiliser une SSISDB dans la page Paramètres de déploiement du volet Installation du runtime d’intégration, activez également la case à cocher Utiliser la paire de runtimes d’intégration Azure-SSIS de secours avec le basculement de SSISDB. Pour le Nom de la paire de secours, entrez le même nom pour identifier votre paire de runtimes d’intégration Azure-SSIS primaire et secondaire. Lorsque vous terminez la création de votre Azure-SSIS IR secondaire, celui-ci est démarré et attaché à la SSISDB secondaire.

  4. Azure SQL Managed Instance peut sécuriser des données sensibles dans des bases de données, telles que SSISDB, en les chiffrant à l’aide de la clé principale de base de données (DMK). Celle-ci est à son tour chiffrée à l’aide de la clé principale du service (SMK) par défaut. Depuis septembre 2021, SMK est répliqué à partir de votre Azure SQL Managed Instance principale vers votre instance secondaire lors de la création d'un groupe de basculement. Si votre groupe de basculement a été créé avant, supprimez toutes les bases de données utilisateur, y compris SSISDB, de votre Azure SQL Managed Instance secondaire, puis recréez votre groupe de basculement.

  5. Si vous souhaitez que le temps d’arrêt occasionné par le basculement de la SSISDB soit proche de zéro, assurez-vous que les deux runtimes d’intégration Azure-SSIS sont en cours d’exécution. Seul votre Azure-SSIS IR principal peut accéder à la SSISDB principale pour extraire et exécuter des packages, ainsi que pour écrire des journaux d’exécution de package, tandis que votre Azure-SSIS IR secondaire ne peut le faire que pour des packages déployés ailleurs, par exemple, dans Azure Files.

    Si vous souhaitez réduire le coût d’exécution, vous pouvez arrêter votre Azure-SSIS IR secondaire après sa création. Quand le basculement de SSISDB se produit, vos runtimes d’exécution Azure-SSIS principal et secondaire échangent leurs rôles. Si votre Azure-SSIS IR principal est arrêté, vous devez le redémarrer. Selon qu’il est injecté dans un réseau virtuel et la méthode d’injection utilisée, son exécution prend entre 5 minutes ou de 20 à 30 minutes.

  6. Si vous utilisez un agent Azure SQL Managed Instance pour l’orchestration et la planification des exécutions de package, assurez-vous que tous les travaux SSIS pertinents, avec leurs étapes et les planifications associées, sont copiés dans votre Azure SQL Managed Instance secondaire avec les planifications initialement désactivées. Dans SSMS, procédez comme suit.

    1. Pour chaque travail SSIS, cliquez avec le bouton droit, puis sélectionnez dans le menu déroulant les éléments Générer un script du travail en tant que, CREATE To et Nouvelle fenêtre de l’’éditeur de requête pour générer son script.

      Générer un script de travail SSIS

    2. Pour chaque script de travail SSIS généré, recherchez la commande pour exécuter la procédure stockée sp_add_job et modifier/supprimer l’attribution de valeur à l’argument @owner_login_name si nécessaire.

    3. Pour chaque script de travail SSIS mis à jour, exécutez-le sur votre Azure SQL Managed Instance secondaire pour copier le travail avec ses étapes et les planifications associées.

    4. À l’aide du script suivant, créez un travail T-SQL pour activer ou désactiver les planifications de travaux SSIS en fonction du rôle de SSISDB principale/secondaire, respectivement dans vos instances managées Azure SQL primaire et secondaire, et exécutez-le régulièrement. Lors du basculement de SSISDB, les planifications de travaux SSIS désactivées sont activées, et vice versa.

      IF (SELECT Top 1 role_desc FROM SSISDB.sys.dm_geo_replication_link_status WHERE partner_database = 'SSISDB') = 'PRIMARY'
   BEGIN
      IF (SELECT enabled FROM msdb.dbo.sysschedules WHERE schedule_id = <ScheduleID>) = 0
         EXEC msdb.dbo.sp_update_schedule @schedule_id = <ScheduleID >, @enabled = 1
   END
ELSE
   BEGIN
      IF (SELECT enabled FROM msdb.dbo.sysschedules WHERE schedule_id = <ScheduleID>) = 1
         EXEC msdb.dbo.sp_update_schedule @schedule_id = <ScheduleID >, @enabled = 0
   END

  7. Si vous utilisez ADF pour l’orchestration et la planification d’exécutions de package, assurez-vous que tous les pipelines ADF appropriés, avec les activités Exécuter le Package SSIS et les déclencheurs associés, sont copiés vers votre ADF secondaire avec les déclencheurs initialement désactivés. Lorsque le basculement de SSISDB se produit, vous devez les activer.

  8. Vous pouvez tester votre groupe de basculement Azure SQL Managed Instance et vérifier sur la page de surveillance de l’Azure-SSIS IR dans le portail ADF si vos runtimes d’intégration Azure-SSIS principal et secondaire ont échangé leurs rôles.

Attacher un nouvel Azure-SSIS IR à une SSISDB existante hébergée par Azure SQL Database/Managed Instance

Si un incident se produit, qui a un impact sur votre Azure-SSIS IR mais pas sur Azure SQL Database/Managed Instance dans la même région, vous pouvez remplacer l’Azure-SSIS IR par un nouveau dans une autre région. Pour attacher votre SSISDB hébergée par Azure SQL Database/Managed Instance à un nouvel Azure-SSIS IR, procédez comme suit.

  1. Si votre Azure-SSIS IR est toujours en cours d’exécution, vous devez commencer par l’arrêter à l’aide de l’interface utilisateur du portail Azure ou d’ADF, ou d’Azure PowerShell. Si l’incident affecte également ADF dans la même région, vous pouvez ignorer cette étape.

  2. À l’aide de SSMS, exécutez la commande suivante pour la SSISDB dans votre Azure SQL Database/Managed Instance pour mettre à jour les métadonnées qui autorisent les connexions à partir de votre nouvel ADF/Azure-SSIS IR.

    EXEC [catalog].[failover_integration_runtime] @data_factory_name = 'YourNewADF', @integration_runtime_name = 'YourNewAzureSSISIR'

  3. À l’aide de l’interface utilisateur du portail Azure ou d’ADF, ou d’Azure PowerShell, créez votre nouvel ADF/Azure-SSIS IR nommé YourNewADF/YourNewAzureSSISIR dans une autre région. Si vous utilisez l’interface utilisateur du portail Azure ou d’ADF, vous pouvez ignorer l’erreur de test de connexion dans la page Paramètres de déploiement du volet Configuration du runtime d’intégration.

Contenu connexe

Vous pouvez envisager ces autres options de configuration pour votre Azure-SSIS IR :