Клонирование 50Gb базы из Prod в Dev за 1 секунду без потери целостности

в 5:43, , рубрики: lxc, mongodb, proxmox, zfs, виртуализация, контейнерная виртуализация, управление разработкой

Клонирование 50Gb базы из Prod в Dev за 1 секунду без потери целостности - 1

Список инструментов

  • Proxmox
  • ZFS
  • LXC
  • MongoDB в качестве подопытной базы

Предисловие

Меня зовут Евгений Савёлов, я занимаюсь сетями, виртуализацией, Windows и Linux серверами, координирую работу программистов и заказчиков в небольшой компании.
Я вижу, что многие используют системы виртуализации, такие как Proxmox, но не знают как использовать преимущества LXC и ZFS. Многие просто используют классические файловые системы, такие, как Ext4, и классические методы клонирования и резервного копирования контейнеров. Это приводит к простоям во время клонирования больших контейнеров и к высокой нагрузке на сервер.

Так же я подготовил материал в виде 6 минутного скринкаста. Голосового сопровождения нет, поэтому наушники можете не искать :). Зато есть аннотации снизу.

Открыть видео

Исходные настройки

Proxmox
Установлен сразу на ZFS
ZFS
Поддержка включена по умолчанию для Proxmox. Настройки по-умолчанию неплохие. Сомнения вызывают: swap раздел на ZFS и размер блока zvol для KVM виртуальных машин.
LXC
Поддержка включена по умолчанию для Proxmox. Настройки по-умолчанию отличные.
MongoDB
Тестовая база на 50Gb внутри LXC контейнера, созданного с помощью Web консоли Proxmox

Клонирование и тестирование

1. Познакомимся с исходным контейнером

Root файловая система контейнера занимает 56.5GiB на диске с учетом снимков и 30Gib на диске без учета снимков.

zfs list rpool/data/containers/subvol-105-disk-1
NAME                                      USED  AVAIL  REFER  MOUNTPOINT
rpool/data/containers/subvol-105-disk-1  56.5G  98.3G  30.0G  /rpool/data/containers/subvol-105-disk-1

Ниже видно, что наш контейнер занимает 44.4GiB места логически (без учета снимков и сжатия LZ4).

zfs get logicalreferenced rpool/data/containers/subvol-105-disk-1
NAME                                     PROPERTY           VALUE   SOURCE
rpool/data/containers/subvol-105-disk-1  logicalreferenced  44.4G   -

Внутри контейнера Ubuntu 14.04 с базой данных MongoDB 3.4

2. Создадим новый контейнер в Proxmox, в качестве основы для клона.

Во время создания нового контейнера будьте внимательны, в качестве шаблона вы должны обязательно указать шаблон, используемый в основном контейнере.
То есть, если основной контейнер — Ubuntu 14.04, то новый контейнер тоже должен быть Ubuntu 14.04.
Если этого не сделать, то вероятно после клонирования файловой системы из исходного контейнера, новый контейнер не запустится. Дело в том, что кроме файловой системы контейнеры обладают некими атрибутами запуска, зависящими от ОС внутри контейнера.

3. Уничтожим файловую систему нового контейнера.

Номер, внутри квадратных скобок замените на номер нового контейнера. Внимание: эта операция необратима!

zfs destroy rpool/data/images/vm-[111]-disk-1

4. Сделаем моментальный снимок исходного контейнера

Снимок — это одна атомарная операция.
ZFS гарантирует, что снимок будет сделан мгновенно, независимо от размера файловой системы. Так же мы можем быть уверенны, «внутри» операции получения снимка не будут изменены никакие данные файловой системы (консистентность).

zfs snapshot rpool/data/images/vm-[105]-disk-1@demo
#demo - имя снимка

5. Сделаем клон файловой системы исходного контейнера.

Клонирование файловой системы всегда выполняется с указанием снимка другой файловой системы. Имя клона нужно указывать с учетом имени нового контейнера, тогда после создания файловой системы не нужно будет менять точки монтирования, что бы запустить контейнер.

zfs clone rpool/data/images/vm-[105]-disk-1@demo rpool/data/images/vm-[111]-disk-1 

6. Запустим вывод zfs list и продемонстрируем, что клон не расходует дополнительного места.

Ниже видно, что наш контейнер занимает 112KiB на диске и ссылается на 30,0Gib

 zfs list rpool/data/containers/subvol-111-disk-1
NAME                                      USED  AVAIL  REFER  MOUNTPOINT
rpool/data/containers/subvol-111-disk-1   112K  98.2G  30.0G  /rpool/data/containers/subvol-111-disk-1

7. Запустим контейнер-клон и продемонстрируем, что все работает. Поменяем часть базы данных.

Запустить контейнер можно из Web интерфейса Proxmox или используя следующую команду:

 pct start 111

Что бы узнать IP адрес нового контейнера можно зайти в него.

lxc-attach -n 111
ifconfig
exit

Нам остается подключаться к клонированной базе данных, например используя MongoBooster и поменять часть данных. Я наложу сложный индекс.

Скриншот

Клонирование 50Gb базы из Prod в Dev за 1 секунду без потери целостности - 2

8. Запустим вывод zfs list и продемонстрируем, что клон расходует место, которое требовалось для изменения части базы данных.

Место расходуется только на измененные блоки.
Обычно чем больше размер блока, тем больше места будет израсходовано, но в zfs используется прозрачное lz4 сжатие, которое снижает накладные расходы на использование эффективных 128KiB блоков.
Ниже видно, что наш контейнер занимает 144MiB на диске и ссылается на 30,1Gib

 zfs list rpool/data/containers/subvol-111-disk-1
NAME                                      USED  AVAIL  REFER  MOUNTPOINT
rpool/data/containers/subvol-111-disk-1   144M  98.2G  30.1G  /rpool/data/containers/subvol-111-disk-1

9. Результаты

В дальнейшем нам не потребуется удалять или создавать контейнеры в Proxmox. Мы просто уничтожаем файловую систему клона и снова снимаем клон с Production базы.
Это выполняется моментально. Сетевые настройки клона не будут меняться, так как у него не будет меняться Mac адрес.

Вместо заключения

Полагаюсь на ваши комментарии. Постараюсь ответить на все интересные вопросы и дополнить статью этими вопросами и ответами на них, приятного просмотра.

Автор: Савёлов Евгений

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js