|








| |

Описанная функциональность реализована с помощью следующих
технологий. Централизованное хранилище версий ПО представляет собой базу данных
(БД), содержащую всю информацию о каждой версии прикладного ПО.
Эта информация (файлы, записи реестра, и т.д.) содержится в
сжатом (архивированном) виде в БД, которая расположена на корпоративном сервере.
На каждый элемент, представленный в БД, хранится контрольная сумма (хеш-свёртка
информации). Это обеспечивает:
-
Уверенность в том, что вся информация, скопированная на
пользовательский компьютер, соответствует оригиналу. То есть, факт
корректного копирования файла подтверждён не его (файла) наличием и
соответствием даты и размера заданным значениям, а гарантированным
соответствием его содержимого эталонному файлу
-
Механизм поддержания целостности ПО. Периодическая
верификация каждого объекта (файла, записи реестра) позволяет автоматически
восстанавливать разрушенные элементы; причина разрушения (действия
пользователя, сбой системы) не имеет значения: целостность ПО будет
восстановлена в любом случае
На компьютере каждого пользователя устанавливается программа «SoftUpdater.Client»,
которая после запуска автоматически сворачивается в трей (к часам). «SoftUpdater.Client»
подключен к упомянутой БД.
В процессе проверки/обновления ПО «SoftUpdater.Client»
считывает из БД информацию об элементах каждого проекта (приложения), в которых
заинтересован пользователь, проверяет наличие этих объектов на локальном
компьютере и, при необходимости, копирует их на жёсткий диск (в реестр Windows).
По умолчанию на пользовательском компьютере процесс
проверки/обновления запускается:
-
При запуске программы; так как SoftUpdater
запускается в момент загрузки Windows, следовательно, впервые процесс
проверки/обновления стартует сразу после загрузки Windows.
-
Впоследствии – автоматически каждый час; интервал запуска
можно изменить как в сторону увеличения (например, чтобы процесс запускался
через каждые 3 часа), так и в сторону уменьшения. Кроме того, можно вообще
выключить периодическую проверку для любого компьютера.
-
По команде системного администратора. Если сисадмин в «SoftUpdater.Admin»
нажмёт кнопку «Обновить все компьютеры», на всех рабочих станциях стартует
процесс верификации/обновления.
Собственно процесс проверки (верификации) выглядит следующим
образом:
-
Определяется список всех объектов (файлов, ключей реестра,
INI), которые должны присутствовать на компьютере пользователя. Список
объектов определяется множеством проектов (приложений), в которых
«заинтересован» компьютер. Эти вопросы регулируются групповой политикой.
-
Для каждого объекта выполняется проверка наличия
(существует ли файл) и соответствия его контрольной суммы эталонной
хеш-свёртке. По результатам проверки каждому объекту присваивается статус
успешно или неуспешно реплицированного.
Процесс обновления (репликации):
-
«SoftUpdater.Client» по сформированному на
предыдущем этапе списку выбирает из БД все объекты, в которых
«заинтересован» компьютер, имеющие статус неуспешно реплицированных.
-
Выполняется репликация выбранных объектов (копирование их
на пользовательский компьютер) из центральной БД.
Процесс обновления на клиентском компьютере весьма нетребователен
к ресурсам. Потребности SoftUpdater в оперативной памяти скромны – не
более 20 Мб; память не будет «отобрана» у рабочих программ.
Собственно процесс проверки/репликации представляет собою
множественные считывания информации из БД, перемежаемые операциями ввода/вывода
на локальном компьютере. Именно по этой причине процессор пользовательского
компьютера никогда не будет перегружен трудоёмкими вычислениями: после каждого
обработанного объекта следует обращение к серверу за следующей порцией
информации; во время ожидания ответа сервера процессор выполняет прикладные
задачи пользователя.
Кроме того, процессорное время отдаётся в первую очередь рабочим
приложениям благодаря тому, что «SoftUpdater.Client» запускается с
приоритетом ниже нормального. Таким образом, пользователь, работая в любимой
программе (MS Excel, 1С:Бухгалтерия, и т.д.), не ощутит никакого замедления
работы даже в момент выполнения проверки/репликации.
Сервер также не будет перегружен сверх меры, даже если вы
используете многие десятки компьютеров, подключенных к системе SoftUpdater.
Такое положение дел обусловлено продуманным механизмом обновления:
-
Пакет обновления для каждого «проекта» (приложения)
представляет собой совокупность файлов, записей реестра, и т.п. Каждый
объект сжат (упакован) и записан в БД отдельно; на каждый объект подсчитана
контрольная сумма. Такой подход позволил сделать процесс проверки/репликации
дискретным (не непрерывным).
-
Каждый пользовательский компьютер в процессе обновления НЕ
генерирует непрерывный трафик. После считывания из БД информации о каждом
объекте (например, файле) выполняется локальная работа на пользовательском
компьютере: объект сохраняется во временный файл, распаковывается,
проверяется его хеш-свёртка, объект копируется в положенное ему место
(папку), временный файл удаляется.
-
Процесс обработки каждого объекта (дисковый ввод-вывод),
выполняется небыстро, по меркам центрального процессора. Всё это время канал
связи и процессор сервера свободны для запросов других компьютеров.
-
Уже упоминалось, что каждый файл хранится в БД в сжатом
(упакованном) виде. Неплохо сжимаются даже исполняемые файлы (EXE, DLL) – в
2 - 2.5 раза. Это значительно уменьшает объём как БД, так и трафика,
прокачиваемого между сервером и клиентским компьютером. Например, проект
размером в 111 Мб совокупно занимает в БД 26 Мб. То есть, при полном
копировании такого проекта на клиентский компьютер по каналу связи будет
передано не 111, а 26 Мб. А при инкрементальном копировании (например,
восстановлении повреждённого файла) трафик будет и вовсе мизерным.
-
Передача по каналам связи сжатых (компрессированных)
данных ускоряет процесс и позволяет выполнять обновление на рабочих
станциях, подключенных к серверу не только через локальную сеть, но и через
интернет.
-
Наконец, т.к. компьютеры пользователей включаются в разное
время, их процессы репликации будут запущены вразнобой, что также снижает
нагрузку на сеть.
Таким образом, репликация, которая базируется на перечисленных
принципах, позволяет быстро и качественно организовать обновление и поддержку
целостности ПО в организации.

|