+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

ZFS - постоянная репликация виртуальных машин с базами данных, Proxmox Виртуальная Среда

rholighaus

Guest

11.02.2018 10:00:00

Я хочу мигрировать существующие ВМ на Windows Server 2012R2 с Hyper-V на Proxmox. Эти ВМ либо основаны на Oracle, либо на базах данных MS SQL, работающих в ВМ. В настоящее время они резервируются с помощью коммерческого решения, которое создает резервные копии дисков ВМ на хосте Hyper-V. Поскольку эти ВМ критически важны для работы, я не могу позволить себе рисковать несоответствием в резервных копиях. Я также запускаю контейнеры с MySQL и задаюсь вопросом, будет ли репликация pve ZFS согласованной, так как я вижу только заморозку и оттаивание файловой системы, но никакого взаимодействия с MySQL. Мне нравится, как снимки ZFS можно использовать для инкрементных резервных копий на уровне файловой системы, но я не нашел ничего о согласованности репликации pve ZFS с ВМ (или контейнерами). У кого-то есть опыт, чтобы поделиться?

rholighaus

Guest

27.02.2018 12:53:00

Привет, guletz, спасибо за рекомендацию. Мне нравится идея urbackup, и я собираюсь изучить её поближе. Но моя основная проблема в следующем: обеспечивает ли Proxmox, что снимки, созданные для новой функции репликации, будут последовательными? Если взглянуть, например, на znapzend (https://github.com/oetiker/znapzend), они предлагают хуки для скриптов, которые могут быть вызваны до и после снимка, что позволяет, например, выполнить "FLUSH TABLES WITH READ LOCK" в MySQL внутри контейнера/ВМ. Все, что я вижу в логах PVE, это то, что PVE замораживает и размораживает файловые системы, что может или не может вызвать сброс базы данных, скажем, в Windows ВМ — я недостаточно знаю о том, что команда guest-fsfreeze-freeze / guest-fsfreeze-thaw делает с базой данных, работающей, например, на Oracle внутри Windows Server VM.

LnxBil

Guest

27.02.2018 14:13:00

Заморозка и оттаивание вызывает vss в Windows, так что если Oracle подключается к этому, все в порядке. Просто проверьте журнал оповещений, если в момент создания снимка произошла смена журнала. Для базы данных Oracle обычно лучше использовать Oracle Linux, который имеет наилучшее покрытие тестами, так как это основная платформа разработки. В Linux вы можете просто вызывать сценарии при заморозке или оттаивании.

rholighaus Guest	#4 0 27.02.2018 14:37:00 Спасибо, LnxBil - очень полезно! Есть ли шанс, что что-то вроде hook скриптов есть и внутри контейнеров LXC?

LnxBil Guest	#5 0 27.02.2018 16:17:00 Насколько я знаю, ты можешь просто выполнять команды внутри через pct: Код: root@proxmox ~ > pct exec 14000 id uid=0(root) gid=0(root) Gruppen=0(root)

rholighaus

Guest

27.02.2018 16:32:00

Я знаю, как выполнять команды внутри контейнеров и использую это, когда делаю снимки самостоятельно, но PVE делает снимки автоматически перед началом репликации, и у меня (пока что) нет контроля над тем, как обеспечить согласованные снимки для моих LXC-контейнеров с работающими базами данных... Хук был бы отличным решением...

LnxBil

Guest

27.02.2018 16:37:00

Два решения, если вы используете pve-zsync: a) просто напишите обертку для него, которая будет выполнять ваш хук непосредственно перед вашей оригинальной командой; b) подайте запрос на добавление функции в pve-zsync для реализации механизма хуков. Я быстро просмотреть исходный код и ничего подобного не нашел.

rholighaus Guest	#8 0 27.02.2018 16:42:00 Я не использую pvezsync, а использую Репликацию Хранилища (новая функция PVE 5.x): https://pve.proxmox.com/wiki/Storage_Replication

LnxBil Guest	#9 0 27.02.2018 16:45:00 Тогда b) все еще применимо (не для pve-zsync, но для pvesr)

denos

Guest

#10

27.02.2018 17:21:00

Снимки ZFS всегда консистентны в случае сбоя. Любое приложение, которое не может восстановиться из консистентного снимка после сбоя, будет не в состоянии восстановиться от чего-либо, что вызвало неожиданный останов сервера (например, сбой питания, паника ядра, аппаратная неисправность и т.д.). Базы данных используют операции sync, fsync и т.д., чтобы гарантировать, что данные находятся на диске до завершения транзакции. Если вы не нарушили гарантии синхронизации на аппаратном уровне (например, буфер записи без резервного питания) или на программном уровне (например, установив sync=disabled в ZFS, отключив sync/fsync в конфигурации базы данных и т.д.), то зафиксированные данные будут присутствовать в снимке. Транзакции, которые выполнялись в момент создания снимка, будут откатаны при восстановлении базы данных из состояния консистентного сбоя. Операции "ализирование" полезны для инструментов резервного копирования, которые не могут зафиксировать файловую систему в состоянии консистентного сбоя, когда вы хотите, чтобы все текущие транзакции завершились, когда вы немного поиграли с целостностью синхронизации, когда вы хотите минимизировать операции восстановления и т.д.

guletz Guest	#11 0 27.02.2018 18:45:00 Привет, @denos, объясню снова почти тот же процесс, который происходит с zfs snapshot. Если тебе не жалко, ты можешь использовать хук, как в этой ссылке: https://github.com/proxmox/qemu/blob/master/scripts/qemu-guest-agent/fsfreeze-hook, и вставить свой sql flush или что угодно... Но в итоге ты получишь ту же согласованную БД, как без любого хука, только с одной разницей: процесс создания полного снимка займет больше времени. А теперь подумай о катастрофических сценариях. Ты заканчиваешь свой zfs snapshot, и через 5 минут твоя БД VM терпит крах (до твоего следующего запланированного снимка, скажем, через 10 минут). Так что без какого-либо DB хука ты потеряешь 100 sql транзакций. Возможно, с sql хуком ты потеряешь только 50. Проблема в том, что в любом случае ты что-то потеряешь, больше или меньше. В обоих случаях тебе нужно будет выяснить, что было потеряно. Если эта операция обязательна, то тебе нужно будет пересмотреть любые варианты асинхронной репликации. Например, если ты запускаешь веб-почту (которая использует sql движок), никому не важно, если ты потеряешь некоторые sql вставки (кеш заголовков писем, какие пользователи вошли и так далее). Как я уже писал, если ты не хочешь потерять ни одной успешно выполненной sql транзакции, то лучшее решение — использовать SQL кластер. В заключение, тебе следует задать себе вопрос, что для тебя приемлемо: потерять что-то или не потерять ничего? После этого ответа ты поймешь, что тебе нужно. Удачи!

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры