Share via

Зависимости между компонентами, управляемыми разными модулями записи

  • Статья

Бывают ситуации, когда данные из одного модуля записи зависят от данных, управляемых другим модулем записи. В таких случаях следует выполнить резервное копирование или восстановление данных из обоих модулей записи.

VsS решает эту проблему с помощью понятия явной зависимости компонента записи и интерфейса IVssWMDependency .

Модуль записи добавляет одну или несколько зависимостей при создании документа метаданных модуля записи с помощью метода IVssCreateWriterMetadata::AddComponentDependency . Модуль записи передает методу имя и логический путь зависимого компонента (которым он управляет), а также имя и логический путь и идентификатор класса модуля записи (GUID, определяющий класс) компонента, от которого он зависит.

После установки эта зависимость информирует инициатора запроса о том, что во время любой операции резервного копирования или восстановления должен участвовать как зависимый компонент, так и целевые объекты его зависимостей.

Данный компонент может иметь несколько зависимостей, что требует, чтобы он и все его зависимые целевые объекты участвовали в резервном копировании и восстановлении вместе.

Зависимый компонент и(или) целевые объекты его зависимостей могут быть включены явным илинеявным образом в операции резервного копирования или восстановления.

Явный механизм зависимости компонентов модуля записи не следует использовать для создания зависимости между двумя компонентами одного модуля записи. Правила выбора могут предоставлять те же функции более эффективно без риска циклических зависимостей.

Например, IVssCreateWriterMetadata::AddComponentDependency можно использовать для определения зависимости компонента writerData (с логическим путем "") модуля записи MyWriter в компоненте internetData (с логическим путем "Подключения") модуля записи с именем InternetConnector с идентификатором класса модуля записи X. (Хотя несколько модулей записи с одинаковым идентификатором класса могут находиться в системе одновременно, путаницы можно избежать, так как сочетание логического пути и имени компонента является уникальным в системе в VSS.)

Модуль записи добавляет несколько зависимостей к данному компоненту, просто вызывая метод IVssCreateWriterMetadata::AddComponentDependency , повторяющийся с разными компонентами из разных модулей записи. Количество других компонентов, от которых зависит данный компонент, можно найти, изучив элемент cDependenciesструктуры VSS_COMPONENTINFO .

Модуль записи или инициатор запроса получает экземпляры интерфейса IVssWMDependency с помощью IVssWMComponent::GetDependency. IVssWMDependency возвращает имя компонента, логический путь и идентификатор класса модуля записи, управляющего компонентом, который является целевым объектом зависимости.

Механизм зависимостей не предписывает какой-либо особый порядок предпочтений между зависимым компонентом и целевыми объектами его зависимостей. Как отмечалось выше, все зависимости указывают на то, что каждый раз, когда выполняется резервное копирование или восстановление определенного компонента, необходимо также создать резервную копию или восстановить компонент или компоненты, от которые он зависит. Точная реализация зависимости зависит от решения приложения резервного копирования.

Например, в приведенном выше случае компонент writerData (логический путь "") зависит от компонента InternetConnector (логический путь "Подключения"). Инициатор запроса может интерпретировать это в любом из следующих способов:

  • Если зависимый компонент writerData выбран (неявно или явно) для резервного копирования или восстановления, инициатор запроса должен выбрать (неявно или явно) целевой объект своей зависимости internetData.
  • Если для резервного копирования не выбран целевой объект его зависимости internetData, то не следует выбирать зависимый компонент writerData.

Однако при разработке поддержки зависимостей разработчики, запрашивающие запросы, должны знать, что средство записи не может определить, является ли один из его компонентов целевым объектом зависимости.

Объявление удаленных зависимостей

Распределенное приложение — это приложение, которое можно настроить для использования одного или нескольких компьютеров одновременно. Как правило, приложение выполняется на одном или нескольких компьютерах сервера приложений и взаимодействует с одним или несколькими компьютерами сервера баз данных (но может не работать на самом деле). Эту конфигурацию иногда называют развертыванием с несколькими системами. Часто одно и то же приложение также можно настроить для запуска на одном компьютере, на котором работают как сервер приложений, так и сервер базы данных. Такая конфигурация называется развертыванием с одной системой. В обеих конфигурациях сервер приложений и сервер базы данных имеют собственные независимые модули записи VSS.

В развертывании с несколькими системами, если компонент, управляемый модулем записи приложения, зависит от удаленного компонента, управляемого модулем записи сервера базы данных, это называется удаленной зависимостью. (Развертывание с одной системой, напротив, имеет только локальные зависимости.)

В качестве примера развертывания с несколькими системами рассмотрим сервер приложений, который использует сервер базы данных SQL Server в качестве хранилища данных. Данные конкретного приложения, которые включают веб-части, файлы веб-содержимого и метабазу IIS, находятся на одном или нескольких компьютерах, называемых интерфейсными веб-серверами. Фактическое хранилище данных SQL, включающее базу данных Config и несколько баз данных контента, находится на одном или нескольких других компьютерах, называемых внутренними серверами баз данных. Каждый интерфейсный веб-сервер содержит одинаковое содержимое и конфигурацию для конкретного приложения. На каждом серверном сервере базы данных может размещаться любая база данных контента или база данных конфигурации. Программное обеспечение приложения выполняется только на интерфейсных веб-серверах, но не на серверах баз данных. В этой конфигурации модуль записи VSS приложения имеет удаленные зависимости от компонентов, управляемых модулем записи SQL.

Модуль записи может объявить удаленную зависимость, вызвав метод AddComponentDependency , добавив в начало "\\RemoteComputerName\", где RemoteComputerName — имя компьютера, на котором находится удаленный компонент, к логическому пути в параметре wszOnLogicalPath . Значением RemoteComputerName может быть IP-адрес или имя компьютера, возвращаемое функцией GetComputerNameEx.

Windows Server 2003: Модуль записи не может объявлять удаленные зависимости до Windows Server 2003 с пакетом обновления 1 (SP1).

Чтобы определить зависимость, инициатор запроса вызывает методы GetWriterId, GetLogicalPath и GetComponentName интерфейса IVssWMDependency . Инициатор запроса должен проверить имя компонента, возвращаемое GetComponentName в параметре pbstrComponentName . Если имя компонента начинается с "\\", инициатор запроса должен предположить, что он указывает удаленную зависимость и что первым компонентом после "\\" является RemoteComputerName , которое было указано при вызове модуля записи AddComponentDependency. Если имя компонента не начинается с "\\", инициатор запроса должен предположить, что он указывает локальную зависимость.

При наличии удаленной зависимости инициатор запроса должен создать резервную копию удаленного компонента при резервном копировании локального компонента. Для резервного копирования удаленного компонента инициатор запроса должен иметь агент на удаленном компьютере и инициировать резервное копирование на удаленном компьютере.

Структурирование удаленных зависимостей

Важно понимать, что зависимость сама по себе не является компонентом. Компонент необходим для хранения зависимости.

В следующих примерах показаны два способа структурирования набора зависимостей.

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

В примере 1 зависимости удерживаются компонентом A. Так как можно выбирать только компоненты, а не отдельные файлы, структурирование зависимостей компонента А таким образом потребует, чтобы весь компонент, как файлы, так и зависимости, всегда были резервное копирование и восстановление вместе. Их невозможно создать или восстановить по отдельности.

В примере 2 отдельные компоненты (компоненты A и B) содержат каждую из зависимостей. В этом случае эти два компонента можно выбирать независимо и, следовательно, создавать резервные копии и восстанавливать их независимо. Структурирование зависимостей таким образом дает распределенному приложению гораздо большую гибкость в управлении удаленными зависимостями.

Поддержка удаленных зависимостей

Инициатор запроса может обеспечить полную или частичную поддержку удаленных зависимостей.

Чтобы обеспечить полную поддержку, инициатор запроса должен выполнить следующие действия во время резервного копирования и восстановления.

Во время резервного копирования инициатор запроса должен запустить резервное копирование на интерфейсном (локальном) компьютере, определить существующие зависимости и запустить дополнительные задания резервного копирования для записи серверных баз данных. Инициатор запроса должен дождаться завершения заданий резервного копирования серверной части на удаленном компьютере перед вызовом методов IVssBackupComponents::SetBackupSucceeded и IVssBackupComponents::BackupComplete . Если инициатор запроса ожидает завершения резервного копирования внутренних компонентов перед вызовом BackupComplete, это позволит создать более легко восстанавливаемую резервную копию для модуля записи, который реализует дополнительные улучшения, например блокировку топологии, во время резервного копирования. В следующей процедуре описывается, что должен делать инициатор запроса.

  1. На локальном компьютере инициатор запроса вызывает методы IVssBackupComponents::InitializeForBackup, IVssBackupComponents::GatherWriterMetadata, IVssBackupComponents::P repareForBackup и IVssBackupComponents::D oSnapshotSet .
  2. После завершения локального теневого копирования, но до завершения резервного копирования инициатор запроса выполняет дополнительные задания резервного копирования, отправляя запрос агенту на удаленном компьютере.
  3. На удаленном компьютере агент инициатора запроса выполняет хранимую последовательность резервного копирования, вызывая InitializeForBackup, GatherWriterMetadata, PrepareForBackup, DoSnapshotSet, SetBackupSucceeded и BackupComplete.
  4. После того как агент инициатора запроса завершил хранимые задания на удаленном компьютере, инициатор запроса завершает последовательность резервного копирования, вызывая Методы SetBackupSucceeded и BackupComplete.

Во время восстановления инициатор запроса должен запустить восстановление с использованием внешнего (локального) компьютера, выбрать компоненты и их зависимости для восстановления, а затем отправить событие PreRestore , вызвав метод IVssBackupComponents::P restore . После завершения восстановления серверной части инициатор запроса должен подложить задания восстановления серверной части на удаленном компьютере и вызвать метод IVssBackupComponents::P ostRestore . Это требование дает интерфейсной записи больший контроль над процессом восстановления и лучшее взаимодействие с администратором в целом. Так как резервные копии в каждой из систем не выполняются в один и тот же момент времени, интерфейсному средству записи потребуется выполнить некоторую очистку данных серверной части. В примере приложения, описанном в предыдущем разделе "Объявление удаленных зависимостей", модуль записи должен инициировать повторное сопоставление или повторное индексирование сайта после завершения восстановления одной из серверных баз данных. Для этого модуль записи должен получать события на интерфейсном сервере. В следующей процедуре описывается, что должен делать инициатор запроса.

  1. На локальном компьютере инициатор запроса вызывает IVssBackupComponents::InitializeForRestore, GatherWriterMetadata, IVssBackupComponents::SetSelectedForRestore (или IVssBackupComponentsEx::SetSelectedForRestoreEx) и PreRestore.
  2. После завершения этапа PreRestore , но до начала этапа PostRestore инициатор запроса выполняет дополнительные задания восстановления, отправляя запрос своему агенту на удаленном компьютере.
  3. На удаленном компьютере агент инициатора запроса выполняет хранимые задания восстановления, вызывая InitializeForRestore, GatherWriterMetadata, SetSelectedForRestore, PreRestore, SetFileRestoreStatus (или SetSelectedForRestoreEx) и PostRestore.
  4. Когда агент инициатора запроса завершил хранимые задания на удаленном компьютере, инициатор запроса завершает последовательность восстановления, вызывая IVssBackupComponents::SetFileRestoreStatus и PostRestore.

Чтобы обеспечить частичную поддержку удаленных зависимостей, инициатор запроса должен следовать удаленным зависимостям и включать их в состав резервного копирования, но порядок событий в интерфейсных и внутренних системах, как описано в предыдущих двух процедурах, не требуется. Для инициатора запроса, который реализует только частичную поддержку, запрашивающий должен обратиться к документации по резервному копированию и восстановлению приложения записи, чтобы понять, какие сценарии могут поддерживаться.