Реферат
Введение 6
1. Постановка задачи и функциональные требования к разрабатываемому ПО 9
2. Нефункциональные требования к разрабатываемому ПО 10
3. Анализ базовых решений 12
3.1 Pecrona Xtra Backup 12
3.2 InnoDB Hot Backup 13
4. Варианты использования 14
5. Аппаратная виртуализация и виртуализация на уровне ядра ОС 18
5.1 Аппаратная виртуализация (виртуальные машины) 19
5.2 Виртуализация на уровне ядра ОС (контейнеры) 21
6. Взаимосвязи между программными и аппаратными компонентами веб-сервиса 23
7. Архитектура веб-сервиса 27
7.1 Logging 27
7.2 Scheduler 28
7.3 Tornado 28
7.4 MySQLdb 28
7.5 Config 28
7.6 EmailNotificator 30
7.7 Gateway 32
7.8 Backup 34
7.9 Restore 36
7.10 Controllers 39
8. Руководство пользователя 42
9. Руководство администратора 47
Заключение 50
Список литературы 51
Приложение А 52
Система управления базой данных (далее СУБД) является неотъемлемым и важнейшим компонентом любой информационной системы (далее ИС), с помощью которого производятся основные операции управления данными. Данные, хранящиеся в базе данных (далее БД), изменяются наиболее часто и отражают динамику транзакций клиентов сервиса пользователя во времени.
Риск потери БД является наиболее критическим для пользователя, поскольку это означает, что потеряны все взаимосвязи между объектами ИС, что ведет, в свою очередь, к повышенному вниманию к сохранности данных в БД. Для выполнения данных условий требуется обеспечить высокое качество управления данными, что отражается в нескольких направлениях:
1. Аппаратные средства повышенной надежности (резервирование
источника бесперебойного питания (ИБП), избыточный массив
независимых дисков (RAID), память с коррекцией ошибок (ECC RAM), оборудование известных производителей).
2. Программная платформа с прогнозируемой производительностью, которая будет обеспечивать требуемые уровни производительности БД.
3. Комплекс административных процессов и политик обеспечения
надежности и безопасности, которые обеспечат контроль за
сохранностью данных и позволят выполнить восстановление обслуживания в случае сбоя в минимальные сроки.
Зачастую, полноценное выполнение вышеуказанных факторов пользователем невозможно в силу экономических, операционных или квалификационных факторов. Кроме того, зачастую ITSP (Internet Telephony Service Provider) пользователя не обеспечивает необходимого уровня сервиса в силу причин, которые пользователь не может контролировать (введение в заблуждение, дезинформация).
Необходимо так же заметить, что размещение БД на одном физическом сервере с приложениями также имеет некоторые недостатки, которые могут быть выражены в следующих пунктах:
1. Доступ приложений к файловой системе сервера БД, что может привести к несанкционированному доступу или изменению данных, разрушению данных в обход стандартных интерфейсов доступа к БД;
2. Конкуренция за ресурсы между БД и приложениями, в рамках которой может происходить деградация производительности за счет перерасхода ресурсов приложениями в ущерб БД (утечки памяти в приложениях, зацикливание с чрезмерной утилизацией центрального процессора (CPU), критические ошибки в системных приложениях);
3. Обычно, сервер приложений является точкой входа в систему, что является привлекательным для злоумышленников, которые будут подвергать пристальному вниманию сервер. В случае взлома, если БД находится на том же сервере, то злоумышленник автоматически получает доступ к данным на сервере.
Таким образом, данные факторы могут вести к снижению безопасности хранения данных и снижению качества сервиса БД для приложений.
Кроме того, если рассматривать аспекты управления данными, связанные с эксплуатацией систем, генерирующими прибыль продажей товаров и услуг клиентам, то для данных систем могут предъявляться дополнительные требования, которые зачастую сложно обеспечить IT службам клиента:
1. Шифрование данных, что обеспечивает безопасность данных после их изъятия;
2. Резервное копирование данных, выполняемое так часто, чтобы обеспечить необходимые уровни контроля изменений, запрашиваемые клиентом. К примеру, для online-магазина с большим количеством транзакций необходимо выполнять резервное копирование данных с высокой частотой (например, 1 раз в 10 минут) для того, чтобы обеспечить возврат к недавнему состоянию после восстановления БД; в то же время, для каких-либо других сервисов достаточно ежедневного копирования, однако требуется хранить резервные копии за последние 2-3 месяца;
3. Независимое хранение резервных копий данных на независимой площадке;
4. One-click восстановление БД непрофессионалом с помощью простой инструкции восстановления;
5. Минимальный downtime и доступность 24x7.
В данный момент на рынке программного обеспечения (далее ПО) не существует комплексного решения для описанных выше проблем. Поэтому актуальной является задача разработки веб-сервиса, в рамках которого будут решены задачи, описанные выше.
В результате проделанной работы были проанализированы требования к ПО, изучены теоретические основы и необходимое для реализации ПО. Был спроектирован и реализован веб-сервис резервного копирования и восстановления БД MySQL в среде UNIX, который решает поставленную задачу. В частности, веб-сервис имеет следующий функционал:
1. Резервное копирование выполняется с заданным пользователем промежутком времени, с помощью компонента Scheduler.
2. Восстановление в 1 нажатие. Просто и удобно.
3. Уведомление пользователя о событиях, происходящих с его БД.
4. Изменение настроек для каждой БД пользователя.
5. Если у пользователя несколько контейнеров с БД, то можно легко между ними переключаться для осуществления манипуляций.
Данный продукт решает проблему резервного копирования и восстановления БД MySQL в среде UNIX, используя контейнерную технологию LXC и систему управления контейнерами Docker.
