Dependencias entre componentes administrados por diferentes escritores

Hay situaciones en las que los datos de un escritor dependen de los datos administrados por otro escritor. En estos casos, debe realizar una copia de seguridad o restaurar datos de ambos escritores.

VSS controla este problema mediante la noción de una dependencia explícita de componente de escritura y la interfaz IVssWMDependency .

Un escritor agrega una o más dependencias al crear el documento de metadatos del escritor mediante el método IVssCreateWriterMetadata::AddComponentDependency . El escritor pasa el método el nombre y la ruta de acceso lógica del componente dependiente (que administra), así como el nombre y la ruta de acceso lógica y el identificador de clase de escritor (el GUID que identifica la clase) del componente en el que depende.

Una vez establecida, esta dependencia informa al solicitante de que, durante cualquier operación de copia de seguridad o restauración, tanto el componente dependiente como los destinos de sus dependencias deben participar.

Un componente determinado puede tener varias dependencias, lo que requiere que y todos sus destinos dependientes participen en la copia de seguridad y restauración conjuntamente.

El componente dependiente o los destinos de sus dependencias se pueden incluir explícita o implícitamente en operaciones de copia de seguridad o restauración.

El mecanismo de dependencia de componente de escritura explícito no se debe usar para crear una dependencia entre dos componentes en el mismo escritor. Las reglas de selección pueden proporcionar la misma funcionalidad de forma más eficaz sin riesgo de dependencias circulares.

Por ejemplo, IVssCreateWriterMetadata::AddComponentDependency podría usarse para definir la dependencia del componente writerData (con la ruta lógica "") del escritor MyWriter en el componente InternetData (con una ruta lógica de "Conexiones") de un escritor denominado InternetConnector con un identificador de clase X de escritor (aunque es posible que varios escritores con el mismo identificador de clase estén en el sistema simultáneamente, se evitará la confusión porque la combinación de ruta de acceso lógica y nombre de componente es única en el sistema en VSS).

Un escritor agrega varias dependencias a un componente determinado simplemente mediante una llamada a IVssCreateWriterMetadata::AddComponentDependency repetida con distintos componentes de diferentes escritores. El número de otros componentes de los que depende un componente determinado se puede encontrar examinando el miembro cDependencies de la estructura VSS_COMPONENTINFO .

Un escritor o solicitante recupera instancias de la interfaz IVssWMDependency con IVssWMComponent::GetDependency. IVssWMDependency devuelve el nombre del componente, la ruta lógica y el identificador de clase del escritor que administra el componente que es el destino de la dependencia.

El mecanismo de dependencia no prescribe ningún orden de preferencia determinado entre el componente dependiente y los destinos de sus dependencias. Como se indicó anteriormente, toda una dependencia indica que cada vez que se realiza una copia de seguridad o se restaura un componente determinado, el componente o los componentes de los que depende también se deben realizar copias de seguridad o restaurarse. La implementación exacta de la dependencia es a discreción de la aplicación de copia de seguridad.

Por ejemplo, en el caso anterior, el componente writerData (ruta lógica "") depende del componente InternetConnector (ruta de acceso lógica "Conexiones"). Un solicitante es libre de interpretar esto de cualquiera de las siguientes maneras:

• Si el componente dependiente, writerData, está seleccionado (implícita o explícitamente) para la copia de seguridad o restauración, el solicitante debe seleccionar (implícita o explícitamente) el destino de su dependencia, InternetData
• Si el destino de su dependencia, InternetData, no está seleccionado para la copia de seguridad, no se debe seleccionar el componente dependiente writerData.

Sin embargo, al desarrollar compatibilidad con dependencias, los desarrolladores de solicitantes deben tener en cuenta que no hay ninguna manera de que un escritor pueda determinar si uno de sus componentes es un destino de una dependencia.

Declaración de dependencias remotas

Una aplicación distribuida es una aplicación que se puede configurar para usar uno o varios equipos a la vez. Normalmente, la aplicación se ejecuta en uno o varios equipos del servidor de aplicaciones y se comunica con (pero puede o no ejecutarse realmente) uno o varios equipos del servidor de bases de datos. Esta configuración se conoce a veces como una implementación de varios sistemas. A menudo, la misma aplicación también se puede configurar para ejecutarse en un único equipo que ejecuta un servidor de aplicaciones y un servidor de bases de datos. Esta configuración se denomina implementación de un solo sistema. En ambas configuraciones, el servidor de aplicaciones y el servidor de bases de datos tienen cada uno sus propios escritores vsS independientes.

En una implementación de varios sistemas, si un componente administrado por el escritor de la aplicación depende de un componente remoto administrado por el escritor del servidor de base de datos, se denomina dependencia remota. (En cambio, una implementación de un solo sistema tiene solo dependencias locales).

Como ejemplo de una implementación de varios sistemas, considere un servidor de aplicaciones que usa un servidor de bases de datos SQL Server como almacén de datos. Los datos específicos de la aplicación, que incluyen los elementos web, los archivos de contenido web y la metabase de IIS, residen en uno o varios equipos, denominados servidores web front-end. El almacén de datos SQL real, que incluye la base de datos config y varias bases de datos de contenido, reside en uno o varios equipos, denominados servidores de bases de datos back-end. Cada uno de los servidores front-end web contiene el mismo contenido y configuración específicos de la aplicación. Cada uno de los servidores de bases de datos back-end puede hospedar cualquiera de las bases de datos de contenido o la base de datos config. El software de aplicación solo se ejecuta en los servidores front-end web, no en los servidores de base de datos. En esta configuración, el escritor de VSS de la aplicación tiene dependencias remotas en los componentes administrados por el escritor de SQL.

Un escritor puede declarar una dependencia remota llamando al método AddComponentDependency , prepending "\\RemoteComputerName\", donde RemoteComputerName es el nombre del equipo donde reside el componente remoto, a la ruta de acceso lógica en el parámetro wszOnLogicalPath . El valor de RemoteComputerName puede ser una dirección IP o un nombre de equipo devuelto por la función GetComputerNameEx .

Windows Server 2003: Un escritor no puede declarar dependencias remotas hasta Windows Server 2003 con Service Pack 1 (SP1).

Para identificar una dependencia, un solicitante llama a los métodos GetWriterId, GetLogicalPath y GetComponentName de la interfaz IVssWMDependency . El solicitante debe examinar el nombre del componente que GetComponentName devuelve en el parámetro pbstrComponentName . Si el nombre del componente comienza por "\\", el solicitante debe suponer que especifica una dependencia remota y que el primer componente que sigue a "\\" es remoteComputerName que se especificó cuando el escritor llamó a AddComponentDependency. Si el nombre del componente no comienza por "\\", el solicitante debe suponer que especifica una dependencia local.

Si hay una dependencia remota, el solicitante debe realizar una copia de seguridad del componente remoto cuando realiza una copia de seguridad del componente local. Para realizar una copia de seguridad del componente remoto, el solicitante debe tener un agente en el equipo remoto y debe iniciar la copia de seguridad en el equipo remoto.

Estructuración de dependencias remotas

Es importante comprender que una dependencia no es un componente en sí mismo. Un componente es necesario para contener la dependencia.

En los ejemplos siguientes se muestran dos maneras de estructurar un conjunto de dependencias.

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, "\")

En el ejemplo 1, el componente A mantiene las dependencias. Dado que solo se pueden seleccionar componentes, no archivos individuales, estructurar las dependencias del componente A de esta manera requeriría que todo el componente, tanto los archivos como las dependencias, siempre se deban realizar copias de seguridad y restaurarse juntos. No se pueden realizar copias de seguridad ni restaurarse individualmente.

En el ejemplo 2, los componentes independientes (componentes A y B) contienen cada una de las dependencias. En este caso, los dos componentes se pueden seleccionar de forma independiente y, por tanto, se pueden realizar copias de seguridad y restaurarse de forma independiente. Estructurar las dependencias de esta manera proporciona a una aplicación distribuida mucha más flexibilidad para administrar sus dependencias remotas.

Compatibilidad con dependencias remotas

Un solicitante puede proporcionar compatibilidad completa o parcial con dependencias remotas.

Para proporcionar soporte técnico completo, el solicitante debe hacer lo siguiente en tiempo de copia de seguridad y restauración.

En el momento de la copia de seguridad, el solicitante debe iniciar la copia de seguridad en el equipo front-end (local), determinar las dependencias que existen y poner en cola trabajos de copia de seguridad adicionales para capturar las bases de datos back-end. El solicitante debe esperar hasta que se hayan completado los trabajos de copia de seguridad de back-end en el equipo remoto antes de llamar a los métodos IVssBackupComponents::SetBackupSucceeded eIVssBackupComponents::BackupComplete . Si el solicitante espera hasta que se complete la copia de seguridad de los componentes de back-end antes de llamar a BackupComplete, esto generará una copia de seguridad más fácil de recuperar para un escritor que implemente mejoras adicionales, como el bloqueo de topología, por ejemplo, durante la copia de seguridad. En el procedimiento siguiente se describe lo que debe hacer el solicitante:

1. En el equipo local, el solicitante llama a los métodos IVssBackupComponents::InitializeForBackup, IVssBackupComponents::GatherWriterMetadata, IVssBackupComponents::P repareForBackup y IVssBackupComponents::D oSnapshotSet .
2. Una vez completada la instantánea local, pero antes de que se complete la copia de seguridad, el solicitante agrupa trabajos de copia de seguridad adicionales mediante el envío de una solicitud a su agente en el equipo remoto.
3. En el equipo remoto, el agente del solicitante realiza la secuencia de copia de seguridad en cola llamando a InitializeForBackup, GatherWriterMetadata, PrepareForBackup, DoSnapshotSet, SetBackupSucceeded y BackupComplete.
4. Cuando el agente del solicitante haya completado los trabajos en cola en el equipo remoto, el solicitante completa la secuencia de copia de seguridad llamando a SetBackupSucceeded yBackupComplete.

En el momento de la restauración, el solicitante debe iniciar la restauración que implica el equipo front-end (local), seleccionar los componentes y sus dependencias que se van a restaurar y, a continuación, enviar el evento PreRestore mediante una llamada al método IVssBackupComponents::P reRestore . A continuación, el solicitante debe poner en cola los trabajos de restauración de back-end en el equipo remoto y llamar al método IVssBackupComponents::P ostRestore cuando se completan las restauraciones de back-end. Este requisito proporciona al escritor de front-end más control sobre la experiencia de restauración y una mejor experiencia de usuario de administrador en general. Dado que las copias de seguridad en cada uno de los sistemas no se producen en el mismo momento, el escritor de front-end tendrá que realizar alguna limpieza de los datos de back-end. En la aplicación de ejemplo descrita en el anterior "Declarar dependencias remotas", el escritor debe iniciar una reasignación o reindexación del sitio después de que se haya completado una restauración de una de las bases de datos de back-end. Para ello, el escritor debe recibir eventos en el servidor front-end. En el procedimiento siguiente se describe lo que debe hacer el solicitante:

1. En el equipo local, el solicitante llama a IVssBackupComponents::InitializeForRestore, GatherWriterMetadata, IVssBackupComponents::SetSelectedForRestore (o IVssBackupComponentsEx::SetSelectedForRestoreEx) y PreRestore.
2. Una vez completada la fase PreRestore , pero antes de que comience la fase PostRestore , el solicitante agrupa trabajos de restauración adicionales mediante el envío de una solicitud a su agente en el equipo remoto.
3. En el equipo remoto, el agente del solicitante realiza los trabajos de restauración en cola llamando a InitializeForRestore, GatherWriterMetadata, SetSelectedForRestore, PreRestore, SetFileRestoreStatus (o SetSelectedForRestoreEx) y PostRestore.
4. Cuando el agente del solicitante ha completado los trabajos en cola en el equipo remoto, el solicitante completa la secuencia de restauración llamando a IVssBackupComponents::SetFileRestoreStatus y PostRestore.

Para proporcionar compatibilidad parcial con las dependencias remotas, el solicitante debe seguir las dependencias remotas e incluirlas como parte de la copia de seguridad, pero no sería necesaria la ordenación de eventos en sistemas front-end y back-end, tal como se detalla en los dos procedimientos anteriores. Para un solicitante que implementa solo compatibilidad parcial, el solicitante debe consultar la documentación de copia de seguridad y restauración de la aplicación de escritor para comprender qué escenarios se pueden admitir.