Ширяев А.П., соискатель Национального исследовательского университета «Московский институт электронной техники»
РАЗРАБОТКА ПРОГРАММНОГО КОМПЛЕКСА ДЛЯ РЕПЛИКАЦИИ ДАННЫХ С ИСПОЛЬЗОВАНИЕМ ОБЛАЧНЫХ ТЕХНОЛОГИЙ
Практически каждая компания в России пользуется системой бухгалтерского учета 1С Бухгалтерия, использующей базы данных с весьма непростой конфигурацией. В процессе эксплуатации системы могут возникнуть проблемы, связанные с целостностью и безопасностью данных. Никто не застрахован от потери данных в связи с хакерскими атаками, неисправностью оборудования, программного обеспечения и др. В любом случае потеря данных в системе бухгалтерского учета компании может привести к очень серьезным проблемам, вплоть до выхода из бизнеса. Многих проблем можно избежать, если проводить систематическое резервное копирование данных. Однако проводить ежедневное полное копирование данных 1С невозможно, во-первых, из-за большого объема данных, во-вторых, из-за значительных временных затрат на проведение такой операции.
С развитием интернет-технологий и появлением облачных технологий появилась возможность получить надежный доступ к данным из любой точки планеты при наличии интернет соединения. Применение облачных технологий позволяет получить недорогое и надежное хранилище для резервных копий для малого и среднего бизнеса - именно этот сектор бизнеса не может пофинансовым соображениям содержать собственные высокозащищенные серверы исоответствующий обслуживающий персонал. На сегодняшний день предлагаются следующие программные решения: использование облака по схеме БааБ (программное обеспечение как услуга - аренда платформы 1С, находящейся в облаке) и по схеме БааБ (предоставляется дисковое пространство, на котором специальное ПО сохраняет резервные копии).
Существующие программные решения не обеспечивают все потребности пользователей в полной мере. Например, не все решения поддерживают отслеживание изменений данных внутри системы, для многих из них уровень защиты недостаточно высок, и не обеспечивается мониторинг объемов данных, подвергаемых резервному копированию.
В данной работе предлагается программное решение данной задачи, которое должно обеспечивать следующие возможности:
Отслеживание ежедневных изменений;
• Защиту данных с помощью пароля или шифрования;
• Удобство резервного копирования и восстановления данных;
• Мониторинг объемов данных, подвергающихся резервному копированию, и графика проведения.
Данная концепция позволяет повысить надежность хранения данных и, как результат, увеличить эффективность работы бухгалтерии предприятия.
Алгоритм решения задачи был декомпозирован на следующие этапы: создание «бэкапа» и отслеживание изменений (полная резервная копия и резервная копия журнала транзакций), генерация архивов с пакетом изменений (архив всех изменений за текущее число) и полной резервной копией, размещение в облаке.
Рис. 1. Функциональная схема программного комплекса
Решать задачу первого этапа можно несколькими путями: извлекать базу и помещать в xml-файл (копия в открытом виде), извлекать данные из журнала регистраций и сопутствующих журналов, работать с sql-версией базы данных. Первые два способа на первый взгляд могут показаться очевидными решениями из-за достаточно высокой скорости разбора стандарта XML современными средствами. Но тут возникают следующие проблемы:
- разбор xml-файлов больших размеров может оказаться весьма длительной задачей, особенно, если размеры базы измеряются в Гб;
- из-за необходимости отдельного разбора файлов для извлечения пакетов изменений приложение будет плохо масштабируемым, и изменения в структуре данных производителем приведет к необходимости модернизации программного решения.
Работа с SQL-версией под управлением СУБД обеспечивает высокую скорость обработки данных, поддержку работы с большими объемами данных (при больших объемах данных производительность файловой БД 1С падает). Например, SQL-Server содержит специальные механизмы, обеспечивающие целостность хранимых данных. Отслеживание изменений можно организовать в видеинкрементального резервного копирования. Использование СУБД позволяетреализовать более надежную систему резервного копирования данных.
Таким образом, на первом этапе в соответствии с заданными временными интервалами программно генерируются специальные запросы к базе данных, по которым с помощью специальных механизмов СУБД создаются резервные копии. Информация о ходе выполнения процедуры обрабатывается и отображается пользователю.
На втором этапе полная резервная копия собирается в один архив, а резервные копии журнала транзакций формируют пакет изменений (логи журнала транзакций за текущее число) в виде архива за текущее число. На полученные архивы может устанавливаться пароль, либо перед архивацией происходит многопоточное шифрование резервных копий.
На третьем этапе происходит размещение в облаке. Возможно использование двух вариантов работы - ручная загрузка файлов (выбирается нужный файл и загружается) или синхронизация папок.
I
L
Файл
W.
хХинхр
О Ч
Шифрованна
Синхронизация папок
Облачное хранилище
Прямое размещение
Рис. 2. Схема размещения данных в облачное хранилище
В качестве «стартового» облачного хранилища рассматривается Dropbox. Он предоставляет 2Гб для бесплатного хранения с возможностью бесплатного расширения до 16 Гб. Для всех аккаунтов по умолчанию Dropbox сохраняет удаленные файлы и старые версии измененных файлов 30 дней, и в течение этого периода их можно восстановить.
Процедура восстановления повторяет в обратном порядке описанные выше этапы: загружаются файлы из облака, данные разархивируются и генерируется запрос на восстановление с использованием резервных копий до указанной точки восстановления (заданного числа и времени после создания полной резервной копии).
По данным формируются графики объемов данных, подвергающихся резервному копированию по датам, и графики других зависимостей.
Рассмотрим аспекты многопоточности для реализации данной задачи. Для этого необходимо ввести ряд понятий:
• Критический ресурс - ресурс, который в каждый момент времени используется не более чем одним процессом. В нашем случае критическими ресурсами будут являться создаваемые резервные копии и их зашифрованный вариант.
• Процесс - экземпляр выполняемой программы.
• Поток - некая сущность внутри процесса, получающая процессорное время для вы-
• Многопоточность - свойствоприложения, состоящее в том, что процесс, порожденный в операционной системе, может состоять из нескольких потоков, выполняющихся «параллельно», то есть без предписанного порядка во времени. В нашем случае чтение данных и запись в архив при шифровании должны идти параллельно.
• «Состояние гонок» - ошибка программирования многопоточного приложения, при которой несколько потоков пытаются одновременно получить доступ к данным, причем хотя бы один поток выполняет запись.
полнения.
Практически все приложения с графическим интерфейсом и длительным выполнением операций используют асинхронное выполнение (многопоточность). Рассмотрим, например, выполнение и обработку запроса на создание резервной копии. У нас есть некая форма, которая функционирует в рамках одного основного потока. Выполняем в этом же потоке запрос - в результате наша форма блокируется на срок выполнения запроса, что зачастую бывает крайне нежелательно для пользователя. А если нам необходимо получать в реальном времени информацию о ходе выполнения запроса и каких-либо данных? Из-за блокировки формы эта задача не сможет выполняться в должной мере. Для разрешения данного противоречия необходимы выполнение и обработка запроса в новом потоке. Еще в одном потоке будет обрабатываться информация о завершении нашего запроса.
Рассмотрим различные паттерны для реализации многопоточного шифрования:
1. Планировщик - паттерн параллельного программирования, заключающийся в создании объекта, который явным образом ставит в очередь ожидающие ресурс потоки.
Во многих библиотеках он уже присутствует (например, в библиотеке для C# TPL (Task-ParallelLibrary - пользовательский планировщик или планировщик по умолчанию)), так что не следует «изобретать велосипед». Но даже при этом грамотно реализовать алгоритм работы программы с использованием библиотек или без - задача не тривиальная. К тому же использование большого количества потоков для решения нашей задачи нецелесообразно из-за критических ресурсов, это просто не даст прироста производительности. Родственным данному паттерну является Ведущий-ведомый.
2. Пул потоков - набор определенного количества потоков, которые создаются и уничтожаются динамически, в зависимости от нагрузки на приложение. С этим паттерном также нет необходимости писать свое решение, онреализован в библиотеках. Нашу задачу, конечно, можно решить с помощью пула потоков, но это будет не совсем целесообразно. Один-два потока могут читать данные блоками и заносить их в очередь задач, затем они распределяются между потоками. Но из-за того, что используется критический ресурс, в который все эти потоки должны записывать данные - паттерн не даст прироста производительности, потоки будут простаивать.
3. Модель «поставщик-потребитель» применяется во многих многопоточных приложениях. Ее идея заключается в разбиении проблемы на две подпроблемы: создание поставщиком задачи для выполнения и извлечение задачи потребителем, выполняющим обработку.
Один поток будет читать блоками данные в пакете изменений и помещать их в очередь задач, откуда уже поток-потребитель будет извлекать задачу для записи в архив. Типичной ошибкой при реализации данной модели является проблема ограниченногобуфера. Проблема описывает два потока - поставщика и потребителя, которые используют общий фиксированный буфер как очередь. Производитель генерирует данные, помещает их в буфер и начинает работу сначала. В то же время потребитель извлекает данные в определенные промежутки времени. Производитель не должен добавлять данные, если буфер полон, а потребитель не должен читать данные, если буфер пуст. К тому же на время занесения или чтения
Для дальнейшего прочтения статьи необходимо приобрести полный текст. Статьи высылаются в формате PDF на указанную при оплате почту. Время доставки составляет менее 10 минут. Стоимость одной статьи — 150 рублей.