Partager via

Dépendances entre les composants gérés par différents enregistreurs

  • Article

Il existe des situations où les données d’un enregistreur dépendent de données gérées par un autre enregistreur. Dans ce cas, vous devez sauvegarder ou restaurer des données à partir des deux enregistreurs.

VSS gère ce problème par le biais de la notion d’une dépendance de composant de rédacteur explicite et de l’interface IVssWMDependency .

Un enregistreur ajoute une ou plusieurs dépendances lors de la création du document de métadonnées writer à l’aide de la méthode IVssCreateWriterMetadata::AddComponentDependency . L’enregistreur transmet à la méthode le nom et le chemin logique du composant dépendant (qu’il gère), ainsi que le nom et le chemin logique et l’ID de classe writer (GUID identifiant la classe) du composant dont il dépend.

Une fois établie, cette dépendance informe le demandeur que, pendant toute opération de sauvegarde ou de restauration, le composant dépendant et les cibles de ses dépendances doivent participer.

Un composant donné peut avoir plusieurs dépendances, ce qui nécessite que lui et toutes ses cibles dépendantes participent ensemble à la sauvegarde et à la restauration.

Le composant dépendant et/ou la ou les cibles de ses dépendances peuvent être inclus explicitement ou implicitement dans une opération de sauvegarde ou de restauration.

Le mécanisme de dépendance de composant d’enregistreur explicite ne doit pas être utilisé pour créer une dépendance entre deux composants sur le même enregistreur. Les règles de sélection peuvent fournir les mêmes fonctionnalités plus efficacement sans risque de dépendances circulaires.

Par exemple, IVssCreateWriterMetadata::AddComponentDependency peut être utilisé pour définir la dépendance du composant writerData (avec le chemin logique « ») de l’enregistreur MyWriter sur le composant internetData (avec un chemin logique « Connexions ») d’un enregistreur nommé InternetConnector avec un enregistreur ID de classe X. (Alors qu’il est possible pour plusieurs enregistreurs avec le même ID de classe d’être simultanément sur le système, la confusion sera évitée, car la combinaison du chemin logique et du nom du composant est unique sur le système sous VSS.)

Un enregistreur ajoute plusieurs dépendances à un composant donné en appelant simplement IVssCreateWriterMetadata::AddComponentDependency répété avec différents composants provenant de différents enregistreurs. Le nombre d’autres composants dont dépend un composant donné peut être trouvé en examinant le membre cDependencies de la structure VSS_COMPONENTINFO .

Un enregistreur ou un demandeur récupère les instances de l’interface IVssWMDependency avec IVssWMComponent::GetDependency. L’IVssWMDependency retourne le nom du composant, le chemin logique et l’ID de classe de l’enregistreur qui gère le composant qui est la cible de la dépendance.

Le mécanisme de dépendance n’impose aucun ordre de préférence particulier entre le composant dépendant et les cibles de ses dépendances. Comme indiqué ci-dessus, une dépendance indique que chaque fois qu’un composant donné est sauvegardé ou restauré, le ou les composants dont il dépend doivent également être sauvegardés ou restaurés. L’implémentation exacte de la dépendance est à la discrétion de l’application de sauvegarde.

Par exemple, dans le cas ci-dessus, le composant writerData (chemin logique « ») dépend du composant InternetConnector (chemin logique « Connexions »). Un demandeur est libre d’interpréter cela de l’une des manières suivantes :

  • Si le composant dépendant, writerData, est sélectionné (implicitement ou explicitement) pour la sauvegarde ou la restauration, le demandeur doit sélectionner (implicitement ou explicitement) la cible de sa dépendance, internetData
  • Si la cible de sa dépendance, internetData, n’est pas sélectionnée pour la sauvegarde, le composant dépendant, writerData, ne doit pas être sélectionné.

Toutefois, lors du développement de la prise en charge des dépendances, les développeurs demandeurs doivent savoir qu’il n’existe aucun moyen pour un enregistreur de déterminer si l’un de ses composants est la cible d’une dépendance.

Déclaration de dépendances distantes

Une application distribuée est une application qui peut être configurée pour utiliser un ou plusieurs ordinateurs à la fois. En règle générale, l’application s’exécute sur un ou plusieurs ordinateurs serveurs d’applications et communique avec (mais peut ne pas s’exécuter sur) un ou plusieurs ordinateurs serveurs de base de données. Cette configuration est parfois appelée déploiement multi-système. Souvent, la même application peut également être configurée pour s’exécuter sur un seul ordinateur qui exécute à la fois un serveur d’applications et un serveur de base de données. Une telle configuration est appelée déploiement à système unique. Dans les deux configurations, le serveur d’applications et le serveur de base de données ont chacun leurs propres enregistreurs VSS indépendants.

Dans un déploiement multi-système, si un composant géré par l’enregistreur de l’application dépend d’un composant distant géré par l’enregistreur du serveur de base de données, cela est appelé dépendance distante. (En revanche, un déploiement à système unique n’a que des dépendances locales.)

À titre d’exemple de déploiement multi-système, considérez un serveur d’applications qui utilise un serveur de base de données SQL Server comme magasin de données. Les données spécifiques à l’application, qui incluent les composants WebPart, les fichiers de contenu web et la métabase IIS, résident sur un ou plusieurs ordinateurs, appelés serveurs web frontaux. Le magasin de données SQL réel, qui comprend la base de données Config et plusieurs bases de données Content, réside sur un ou plusieurs autres ordinateurs, appelés serveurs de base de données principaux. Chacun des serveurs web frontaux contient le même contenu et la même configuration spécifiques à l’application. Chacun des serveurs de base de données back-end peut héberger l’une des bases de données De contenu ou la base de données Config. Le logiciel d’application s’exécute uniquement sur les serveurs web frontaux, pas sur les serveurs de base de données. Dans cette configuration, l’enregistreur VSS de l’application a des dépendances distantes sur les composants gérés par l’enregistreur SQL.

Un enregistreur peut déclarer une dépendance distante en appelant la méthode AddComponentDependency , au lieu de « \\RemoteComputerName\ », où RemoteComputerName est le nom de l’ordinateur où réside le composant distant, au chemin logique dans le paramètre wszOnLogicalPath . La valeur de RemoteComputerName peut être une adresse IP ou un nom d’ordinateur retourné par la fonction GetComputerNameEx .

Windows Server 2003 : Un enregistreur ne peut pas déclarer les dépendances distantes tant que Windows Server 2003 avec Service Pack 1 (SP1).

Pour identifier une dépendance, un demandeur appelle les méthodes GetWriterId, GetLogicalPath et GetComponentName de l’interface IVssWMDependency . Le demandeur doit examiner le nom du composant que GetComponentName retourne dans le paramètre pbstrComponentName . Si le nom du composant commence par « \ », le demandeur doit supposer qu’il spécifie une dépendance distante et que le premier composant suivant « \\ » est le RemoteComputerName qui a été spécifié lorsque l’enregistreur appelé AddComponentDependency. Si le nom du composant ne commence pas par « \\ », le demandeur doit supposer qu’il spécifie une dépendance locale.

S’il existe une dépendance distante, le demandeur doit sauvegarder le composant distant lorsqu’il sauvegarde le composant local. Pour sauvegarder le composant distant, le demandeur doit avoir un agent sur l’ordinateur distant et lancer la sauvegarde sur l’ordinateur distant.

Structuration des dépendances distantes

Il est important de comprendre qu’une dépendance n’est pas un composant en soi. Un composant est nécessaire pour contenir la dépendance.

Les exemples suivants montrent deux façons de structurer un ensemble de dépendances.

Example 1:
    Writer 1
        Component A
            File A
            File B
            Dependency (SQL/MSDE Writer, Component X, "\")
            Dependency (SQL/MSDE Writer, Component Y, "\")

Example 2:
    Writer 2
        Component A
            File A
            File B
        Component B
            Dependency (SQL/MSDE Writer, Component X, "\")
            Dependency (SQL/MSDE Writer, Component Y, "\")

Dans l’exemple 1, les dépendances sont détenues par le composant A. Étant donné que seuls les composants peuvent être sélectionnés, pas des fichiers individuels, la structuration des dépendances du composant A nécessite que l’ensemble du composant, à la fois les fichiers et les dépendances, soit toujours sauvegardé et restauré ensemble. Ils ne peuvent pas être sauvegardés ou restaurés individuellement.

Dans l’exemple 2, des composants distincts (composants A et B) contiennent chacune des dépendances. Dans ce cas, les deux composants peuvent être sélectionnés indépendamment, et donc sauvegardés et restaurés indépendamment. La structuration des dépendances de cette façon donne à une application distribuée beaucoup plus de flexibilité dans la gestion de ses dépendances distantes.

Prise en charge des dépendances distantes

Un demandeur peut fournir une prise en charge complète ou partielle des dépendances distantes.

Pour fournir une prise en charge complète, le demandeur doit effectuer les opérations suivantes au moment de la sauvegarde et de la restauration.

Au moment de la sauvegarde, le demandeur doit démarrer la sauvegarde sur l’ordinateur frontal (local), déterminer les dépendances existantes et mettre en pool des travaux de sauvegarde supplémentaires pour capturer les bases de données principales. Le demandeur doit attendre la fin des travaux de sauvegarde principaux sur l’ordinateur distant avant d’appeler les méthodes IVssBackupComponents::SetBackupSucceeded etIVssBackupComponents::BackupComplete . Si le demandeur attend que la sauvegarde des composants principaux soit terminée avant d’appeler BackupComplete, cela génère une sauvegarde plus facilement récupérable pour un enregistreur qui implémente des améliorations supplémentaires, telles que le verrouillage de la topologie, par exemple, pendant la sauvegarde. La procédure suivante décrit ce que le demandeur doit faire :

  1. Sur l’ordinateur local, le demandeur appelle les méthodes IVssBackupComponents::InitializeForBackup, IVssBackupComponents::GatherWriterMetadata, IVssBackupComponents::P repareForBackup et IVssBackupComponents::D oSnapshotSet .
  2. Une fois le cliché instantané local terminé, mais avant la fin de la sauvegarde, le demandeur enroule des travaux de sauvegarde supplémentaires en envoyant une requête à son agent sur l’ordinateur distant.
  3. Sur l’ordinateur distant, l’agent du demandeur effectue la séquence de sauvegarde en pool en appelant InitializeForBackup, GatherWriterMetadata, PrepareForBackup, DoSnapshotSet, SetBackupSucceeded etBackupComplete.
  4. Une fois que l’agent du demandeur a terminé les travaux mis en pool sur l’ordinateur distant, le demandeur termine la séquence de sauvegarde en appelant SetBackupSucceeded etBackupComplete.

Au moment de la restauration, le demandeur doit démarrer la restauration impliquant l’ordinateur frontal (local), sélectionner les composants et leurs dépendances à restaurer, puis envoyer l’événement PreRestore en appelant la méthode IVssBackupComponents::P reRestore . Le demandeur doit ensuite mettre en pool les travaux de restauration du back-end sur l’ordinateur distant et appeler la méthode IVssBackupComponents::P ostRestore lorsque les restaurations back-end sont terminées. Cette exigence donne au rédacteur frontal davantage de contrôle sur l’expérience de restauration et une meilleure expérience utilisateur de l’administrateur dans l’ensemble. Étant donné que les sauvegardes sur chacun des systèmes ne se produisent pas au même point dans le temps, l’enregistreur frontal doit effectuer un nettoyage des données back-end. Dans l’exemple d’application décrit dans le précédent « Déclaration des dépendances distantes », l’enregistreur doit lancer un remapping ou une réindexation de site une fois la restauration de l’une des bases de données principales terminée. Pour ce faire, l’enregistreur doit recevoir des événements sur le serveur frontal. La procédure suivante décrit ce que le demandeur doit faire :

  1. Sur l’ordinateur local, le demandeur appelle IVssBackupComponents::InitializeForRestore, GatherWriterMetadata, IVssBackupComponents::SetSelectedForRestore (ou IVssBackupComponentsEx::SetSelectedForRestoreEx) et PreRestore.
  2. Une fois la phase De prérestore terminée, mais avant le début de la phase PostRestore , le demandeur effectue un pool de travaux de restauration supplémentaires en envoyant une requête à son agent sur l’ordinateur distant.
  3. Sur l’ordinateur distant, l’agent du demandeur effectue les travaux de restauration en pool en appelant InitializeForRestore, GatherWriterMetadata, SetSelectedForRestore, PreRestore, SetFileRestoreStatus (ou SetSelectedForRestoreEx) et PostRestore.
  4. Lorsque l’agent du demandeur a terminé les travaux mis en pool sur l’ordinateur distant, le demandeur termine la séquence de restauration en appelant IVssBackupComponents::SetFileRestoreStatus et PostRestore.

Pour fournir une prise en charge partielle des dépendances distantes, le demandeur doit suivre les dépendances distantes et les inclure dans le cadre de la sauvegarde, mais l’ordre des événements sur les systèmes front-end et back-end, comme détaillé dans les deux procédures précédentes, n’est pas requis. Pour un demandeur qui implémente uniquement une prise en charge partielle, le demandeur doit se référer à la documentation de sauvegarde/restauration de l’application writer pour comprendre les scénarios qui peuvent être pris en charge.