TL;DR; В этой статье мы расскажем о том, какие типы снимков поддерживаются в Cloud2, почему мы не поддерживаем периодические снимки и о том, что снимки не являются заменой резервному копированию VM.
В Cloud2 поддерживаются снимки всей виртуальной машины и снимки томов виртуальной машины. Первые позволяют создать слепок всей VM и откатить его, вернув тома VM и RAM в состояние на момент создания снимка. Вторые позволяют содать копию диска на некоторый момент времени, а при необходимости вернуть диск в предыдущее состояние.
Пользователи, в основном, используют снимки для решения нескольких задач:
- фиксация состояния виртуальной машины перед изменениями с возможностью отката;
- создание шаблона из тома виртуальной машины;
- создание резервных копий виртуальной машины (периодические снимки по расписанию).
Мы искренне считаем использование снимков для резервного копирования VM великим злом и не поддерживаем периодические снимки по расписанию. Далее, объясним почему так.
Сложности использования снимков в публичном облаке
Когда снимки остаются в основном хранилище томов. Если снимки не перемещаются в холодное хранилище, значит при утрате основного хранилища они пропадут, тем самым они не обеспечивают требование надежности резервного копирования.
Когда снимки перемещаются в холодное хранилище. Производительность холодного хранилища должна быть очень высокой, например, легко посчитать, что для перемещения снимка размером 100 ГБ за 10 минут требуется пропускная способность хранилища равная 160 МБ/сек, а ведь одновременно может выполняться перемещение десятков или даже сотен снимков. Таким образом холодное хранилище становится чрезмерно дорогим, что негативно влияет на стоимость услуги для пользователей.
Шанс повреждения файловой системы VM. Для того, чтобы с томов VM снять снимок без повреждения файловой системы, требуется наличие внутри VM специального агента (qemu guest agent для KVM), который «заморозит» файловые системы на момент создания снимка и «разморозит» их после его создания. Для наших шаблонов мы добавляем в VM qemu guest agent, однако пользователи могут удалить это ПО или отключить его.
Шанс повреждения данных приложений. Приложения внутри VM не знают о том, что требуется синхронизировать данные с файловой системой на момент создания снимка, если только такая интеграция не настроена администратором системы в qemu guest agent. В связи с этим, приложения, выполняющие для операций записи периодическую синхронизацию с файловой системой, вполне могут столкнуться с потерей или повреждением данных.
Продолжительная блокировка файловой системы на запись. Если хранилище нагружено или система управления гипервизором занята, файловая система может быть «заморожена» на достаточно продолжительное время. Это может привести к сбою приложений в виртуальной машине.
Продолжительная блокировка виртуальной машины. При создании снимка VM с памятью требуется выполнить сброс этой памяти на диск. Для машины с 16 GB RAM, при использовании массива с доступной квотой по записи 500 MB/s, сброс памяти займет минимум 32 секунды. Таким образом, пользователи VM могут столкнуться с проблемой доступности служб.
Трехкратный и более рост IO. Поскольку снимки реализуются с помощью CoW механизма, во время создания снимка каждая операция записи внутри VM генерирует x3 операции записи в хранилище.
Шанс перегрузки IO дисковой подсистемы узла. Для всех типов VPS, кроме DataBox, каждые сутки (для Ultra 3 раза в сутки) мы выполняем резервное копирование всех томов узла. Это позволяет нам получать точку восстановления при критическом отказе дисковой подсистемы узлов. Это довольно продолжительная и ресурсозатратная операция, которая производится под контролем нагрузки (throttling), что позволяет выполнять резервное копирование без перегрузки IO узла. Если на фоне этой операции будет выполняться множество других заданий создания снимков VM по расписанию, может возникнуть ситуация, когда дисковая подсистема окажется перегружена по IO, соответственно часть пользователей столкнется со снижением производительности виртуальных машин.
К сожалению, мы не можем обязать всех пользователей самостоятельно заботиться о резервном копировании томов VPS, поэтому отказ от централизованного резервного копирования всех данных узла невозможен.
Самым большим недостатком использования снимков для осуществления задач резервного копирования мы считаем иллюзию пользователя в том, что все всегда будет замечательно.
Даже успешное тестирование восстановления из снимка, проведенное без нагрузки будет радикально отличаться от ситуации, когда снимок создавался в условиях высоконагруженной виртуальной машины, интенсивного IO и прочих условий.
Особенно расстроит данная информация пользователей приватных облаков под управлением VmWare ESXi или Proxmox, которые привыкли к монопольному использованию облачной инфраструктуры и контролю как за виртуализированными слоями, так и аппаратурой.
К сожалению, в публичных облаках, которые являются системами массового обслуживания, существует лишь две опции — либо закладывать существенный резерв производительности, что отрицательно повлияет на цену услуги, либо ограничивать пользователей в использовании операций, которые могут привести к деградации производительности облачной среды.
Настаиваете на снимках по расписанию? Можем развернуть для Вас приватное облако на выделенных серверах в контуре инфраструктуры Cloud2. Предоставим отдельный домен, пользовательский интерфейс, создадим тарифные планы. Администрирование и настройку берем на себя.
Тем не менее, в облаке Cloud2 поддерживаются снимки по запросу, которые успешно используются нашими клиентами для решения принципиально важных задач.
Снимок полного состояния виртуальной машины
На момент публикации статьи каждая виртуальная машина в Cloud2 в один момент времени может иметь только один снимок полного состояния. Это позволяет решить задачу отката при возникновении проблемы или задачу создания шаблона/образа. Для создания снимка состояния не требуется наличие пространства в дополнительном хранилище.
Снимки состояния имеют ряд ограничений — до тех пор, пока у VPS есть снимок, вы не можете масштабировать VPS (увеличивать или уменьшать параметры CPU/RAM), не можете изменять размер дисков.
Вариант использования 1. Создание точки восстановления.
- перед выполнением работ создаем снимок состояния VM;
- выполняем работы;
- проверяем, что все корректно работает;
- удаляем снимок VM.
ВИ 2. Синхронные снимки нескольких томов VM. Используется для создания снимков томов, если у VM несколько томов данных. Этот вариант использования должен применяться только для машин, у которых несколько дисков, поскольку он позволяет получить синхронную копию всех томов.
- создаем снимок состояния VM;
- для каждого тома VM из снимка состояния VM создаем снимок тома VM;
- удаляем снимок VM.
В этом варианте использования требуется наличие пространства в дополнительном хранилище. Доступный объем этого хранилища должен быть равен суммарному размеру томов VM.
Снимок состояния тома VM
Второй тип снимков состояния — снимок тома VM. В этом случае снимок выполняется для некоторого тома, при этом виртуальная машина блокируется на короткий момент для синхронизации файловой системы. Для надежной работы данного механизма (файловые системы внутри VM без повреждения) требуется, чтобы в виртуальной машине был запущен и настроен qemu guest agent, который выполнит «заморозку» и «разморозку» файловых систем.
Этот тип снимка может успешно использоваться для виртуальных машин с одним томом.
ВИ 3. Создание точки восстановления.
- перед выполнением работ создаем снимок состояния тома VM;
- выполняем работы;
- проверяем, что все корректно работает;
- удаляем снимок (или не удаляем) .
В этом варианте использования требуется наличие пространства в дополнительном хранилище. Доступный объем этого хранилища должен быть размеру тома VM.
ВИ 4. Клонирование VPS.
- создаем снимок тома VM;
- создаем шаблон из снимка тома VM;
- удаляем снимок;
- развертываем новые машины из шаблона.
В этом варианте использования требуется наличие пространства в дополнительном хранилище. Доступный объем этого хранилища должен быть размеру тома VM.
Как жить без периодических снимков?
Используйте специализированные средства резервного копирования, работающие внутри VM. Средства резервного копирования, которые вы настраиваете внутри VM не только лучше работают для ваших приложений, но и обеспечивают существенную экономию.
Все равно хочу делать снимки всего дискового пространства, пусть даже из VM! Что делать?
Легко. Установите VM на ZFS, BTRFS или LVM2 и вам станут доступны снимки, которые вы можете отправлять в удаленное хранилище.
Я все понял, какие у меня варианты?
Вариантом много — все зависит от ваших приложений, которые выполняются на VPS.
Статические файлы. Самый простой и удобный способ для резервного копирования файлов — использование Duplicity, Restic или Rdiff Backup.
Файлы СУБД. Каждый поставщик СУБД предоставляет свои инструменты, которые позволяют выполнять как копирование без прерывания обслуживания, так и с краткосрочной блокировкой операций.
Комбинированные варианты. Создание снимка файловой системы с помощью LVM2 или ZFS и выполнение резервной копии файлов из снимка, а не из исходной файловой системы.
Мы советуем провести анализ ваших приложений для того, чтобы разработать сценарий резервного копирования, который будет оптимален для сервисов, выполняющихся на VPS, и обеспечивать требуемое время восстановления данных в случае аварийных ситуаций.
Для пользователей Cloud2 мы рекомендуем осуществлять резервное копирование на отдельное файловое хранилище, которое вы можете заказать в биллинге. Стоимость хранения 1 GB данных составляет 1 рубль в месяц. Большинство средств резервного копирования обеспечивают шифрование данных — не пренебрегайте данным механизмом. Это позволяет обеспечить большую безопасность хранения резервных копий.
Хотите узнать больше технической информации? Читайте статью на Habr-е.