Как организовать резервное копирование виртуальных машин с общими дисками?

Question

[t_q_l]

Вводные данные:

Есть ESXi сервера, есть VCenter (v5.1), на них крутятся виртуальные машины. К ESXi подключено несколько СХД, на которых нарезаны LUN и отданы виртуальным машинам. Внутри виртуальных машин подключено дисков от разных СХД. В качестве системы резервного копирования используется Acronis Backup & Recovery 11.5, агенты которого установлены внутри всех VM. Время начала резервного копирования виртуальных машин привязано к сервисам, которые на них расположены. Резервное копирование каждой машины выполняется 7 раз в неделю (1 полная копия и 6 дифференциальных). Работа виртуальных машин вне времени резервного копирования оптимальна, и диски не являются узким местом. Выделить каждой VM свой LUN целиком нельзя, т.к. на всех места не хватит.

Проблема:

Резервное копирование более двух VM одновременно с общими дисками чревато провалом производительности обеих машин и сервисов, на них находящихся.

Вот схема для наглядности :



На схеме изображено 4 VM и 3 LUN, но на деле виртуальных машин около 100, а LUN около 15. LUN разного размера и производительности.

Со стороны гипервизора диски подключены так:

• VM1 -> DS1, DS2
• VM2 -> DS1, DS2
• VM3 -> DS1, DS2, DS3
• VM4 -> DS2, DS3

Со стороны СХД виртуальные машины подключены так:

• DS1 -> VM1, VM2, VM3
• DS2 -> VM1, VM2, VM3
• DS3 -> VM3, VM4

Чего хочется:

1. Составить план резервного копирования, который бы учитывал нагрузку на диски, время запуска каждой машины.
2. Найти инструмент для документирования процедуры резервного копирования. Эдакий timeline, открыв который можно определить в какое время, как долго и какая машина будет бэкапиться, где есть окно, чтобы вставить другое задание.

Поделитесь опытом, кто и как решает подобные задачи? Сейчас это почти хаотичное передвижение планов копирования и гадание на кофейной гуще.

UPD: Уточнил версию Acronis Backup & Recovery (ABR) - используется версия 11.5, а не 10.

Comments

[Владимир Пилипчук]

А чем сейчас пользуетесь для резервирования?

[t_q_l]

Владимир Пилипчук: Я в вопросе написал, что используется Acronis Backup & Recovery 10

Answer 1

[Владимир Пилипчук]

t_q_l: Простите, не увидел сразу.

ABR не очень хорошо работает с виртуальными машинами. Он работает с ними на уровне файлов, поэтому ему присущи все недостатки такого подхода. Я сам пользовался ABR 10 на Standalone ESXi c внутренним хранилищем - был доволен. Но после перехода на полноценные кластерные решения и общие хранилища - был очень расстроен. В итоге выбрал Veeam, так как он использует другой подход - вытягивание снапшотов на уровне блоков. Плюс такого подхода особенно заметен, когда одновременно резервируются несколько машин. Если данные этих машин расположены рядом, то система просто производит чуть-ли не линейное чтение со стораджа. Плюс ко всему при этом доступна дедубликация на уровне блоков, что еще больше сказывается на занимаемом пространстве, снижая стоимость хранения.
Вообще, если Вы используете общие хранилища, то первым делом должны были задуматься об архитектуре SAN, и как следствие, реализация такого подхода открывает вам дверь в мир продуктов, осуществляющих резервирование на уровне SAN, а это совершенно другой подход, и как следствие, совершенно другие возможности и эффективность.
Я рекомендую попробовать триальную версию Veeam - это решение хорошо умеет работать в гибридных средах, так называемых paraSAN, что позволит вам оценить новые подходы к резервированию и оценить их эффективность именно для Ваших задач. А потом уже выбрать то что подходит больше.

К сожелению я не знаком с Вашей топологией и потребностями, по этой причине не буду ничего советовать, а лишь рекомендую ознакомиться, в качестве отправной точки, с другими методами и технологиями реализации и резервирования виртуальных сред

Comments

[t_q_l]

Владимир Пилипчук, вы не правы. ABR не работает на уровне файлов.
Агенты, установленные на VM, делают снимки дисков на уровне блоков (попутно сбрасывая кэш ОС и приложений, чтобы данные были консистентны).

Не вижу плюсов в использовании Veeam - cнапшоты тоже будут нагружать диски VM, которые расположены на общем хранилище, и получим тот же эффект при одновременной пиковой нагрузке на хранилище.

[Владимир Пилипчук]

t_q_l: Возможно я ошибаюсь, но на сколько помню ABR работает с данными на уровне VMDK (агент для этого и ставится), а не на уровне LUN c VMFS. А это принципиально разный подход к работе с данными. Да, у Veeam есть отдельные инструменты для правильной работы с СУБД, Active Directory, Exchange и т.д., но это необходимо для сохранения целостности этих данных и гранулярного восстановления ввиду архитектурных особенностей этих продуктов, но это только косвенно связано с тем КАК ИМЕННО бэкапятся виртуальные машины.
Могу сказать лишь, что скорость резервирования и удобство управления планами резервирования и восстановления значительно выше по сравнению с ABR 10.
Сейчас VMware, например, обновила список своих продуктов значительно расширив инструментарий для нативного резервирования, в том числе и vSphere SRM, который я на данный момент тестирую для реализации катастрофо-устойчивого ЦОД. Тоже вариант. Все упирается в адекватность стоимости того или иного решения целям проекта.
Почитал сейчас про ABR 10 - как и говорил, поддержка vStorage появилась тольок в 11 версии и доработалась до вменяемого состояния в новой Acronis Backup 11.5 d в которой есть нормальный CBR. Но это из маркетинговых статей, сам я ни 11 ни 11,5 не использовал. В десятой версии максимальная интеграция была на уровне VMFS через API, а это не уровень LUN, это уровень FS. И о работе с блоками тут не может быть и речи.
Я не спорю с Вами, я лишь пытаюсь сказать, что реализация резервирования на уровнях FS и выше крайне не производительна при большом количестве виртуальных машин, особенно с разделяемыми образами виртуальных дисков (а именно это вы заявили в вопросе и заголовке, но в иллюстрации картинка несколько иная, описывающая обшие распределенные хранилища для VM). Обобшая эти два кейса я делаю вывод о том, что деградация производительности процесса резервирования связана именно с поддержкой акронисом VMFS. Возможно в новых версиях ABR функционал расширили, но и тут работа с храниличем заявлена через SAN, а не через гипервизор, который является довольно узким местом при вашей топологии (на сколько я могу ее "телепатировать")

[t_q_l]

Владимир Пилипчук: Владимир, спасибо за развёрнутый ответ.

Я извиняюсь - уточнил версию Acronis Backup & Recovery (ABR) - используется версия 11.5, а не 10.

Попытаюсь вернуть вопрос в нужное русло. Я готов изменить и методы резервного копирования, возможно даже и продукт (хотя на него потрачены деньги, и не хочется их терять). Но я пока не вижу ответа на свой вопрос - как оптимально построить план резервного копирования на общих дисках? Хоть на уровне LUN, хоть на уровне FS проблема никуда не исчезает - снэпшоты и их копирование влияет на производительность диска, на котором несколько машин.

[Владимир Пилипчук]

t_q_l: Можете описать топологию более детально, для понимания как у вас организована виртуализация и резервирование? Попытаюсь проанализировать и дать ответ.

[t_q_l]

Владимир Пилипчук, уточнил схему (см. мой ответ ниже)

Answer 2

[t_q_l]

По просьбам трудящихся уточняю схему виртуализации и резервного копирования.

Диски виртуальных машин (от 2 и более) расположены на разных LUN'ах разной производительности и размера:



Резервное копирование с помощью Acronis Backup & Recovery v.11.5 подразумевает создание снимков всех дисков и копирование их на отдельных NAS.

Проблема: pезервное копирование более двух VM одновременно с общими дисками чревато провалом производительности обеих машин и сервисов, на них находящихся.

Бэкапить машины по одной - не укладываемся в допустимое "окно". Если запускаем резервное копирование нескольких VM одновременно, то сложно угадать, чтобы не было затыка. Пример на картинке - VM1 VM2 вместе нельзя бэкапить, но на картинке всего 4 машины, а на деле 100 VM и 15 LUN'ов.

1. Как правильно построить схему резервного копирования?
2. Как / в чём вести документирование, чтобы правильно распределить время старта, окончания и свободные окна для других машин?

Comments

[Владимир Пилипчук]

Я правильно понимаю, что вы "шарите" один и тот-же VMDK между разными VM?

[t_q_l]

Владимир Пилипчук: Нет.
На каждом LUN несколько vmdk-файлов, которые являются дисками разных виртуальных машин.

[Владимир Пилипчук]

t_q_l: еще несколько уточняющих вопросов:
1 - на чем построена SAN? iSCSI/FC/FCoE/SAS (ну и про JumboFrame спрошу, если вдруг FCoE или iSCSI)
2 - Вы используете кластерное решение vmware c HA, или несколько Standalone ESXi с подключением каждого гипервизора к каждому хранилищу?
3 - Уточните редакцию ABR 11.5 (в связи с этим https://forum.acronis.com/forum/68696)
4 - Хранилища, на которые бэкапите подключениы к SAN как блочные устройства или выступают в роли SMB/FTP ресурсов, подключениых к ABR (которая так-же развернута как VM) в качестве централизованных хранилищ (опубликованных через собственный Samba/FTP-server или на одной из VM)?

[t_q_l]

Владимир Пилипчук:
1. FC.
2. Лезвия в вlade-шасси с двумя FC-cвитчами, к которым подключены СХД.
3. ABR 11.5 39029. Shared vmdk не используются. RDM диски не используются.
4. ABR-крутится на standalone сервере, к которому по iSCSI подключены диски с СХД (не задействованные в виртуалзации).

[Владимир Пилипчук]

t_q_l: Вы не ответили - у вас HA-кластер с vCenter или нет? Хранилища подключены в vStorage или нет?

[t_q_l]

Владимир Пилипчук: HA-кластеров нет. Не знаю, что значит подключены в vStorage (не хватает компетенций ответить)

[Владимир Пилипчук]

Если я все правильно понял отностительно вашей топологии, то...
Видите-ли, vStorage - это набор нативных технологий vmware, появившихся в vSphere 5 для работы с VMFS томами и данными на них, в частности это VMware vStorage API for Data Protection (VADP) и vStorage API for Array Integration (VAAI), а так же другие "плюшки", не интересные нам в разрезе вопроса.
Эти API используются, в основном, сторонними продуктами, обеспечивающими резервирование виртуальных машин. Эти технологии позволяют производить манипуляции с данными на уровне SAN без загрузки сети передачи данных LAN, что повышает производиельность, снижает влияние процессов резервирования и т.п.
Ну а теперь позволю себе предположить следующее:
Упомятый нами ABR 11.5 поддерживает все эти API ТОЛЬКО ПРИ РАБОТЕ с Высокодоступными (HA - high availability) кластерами под упрвлением vCenter Server 5.1 и выше, в иных конфигурациях ни Сервер ни Агенты Acronis Backup не используют эти API, и работают не на уровне SAN, а на уровне VMFS и выше, а так-же используют LAN для передачи данных в Хранилище резервных копий (это из документации к Acronis и vSphere).
В итоге, при бэкапе Акронисом, мы упираемся в пропускную способность Ethernet интерфейса конкретного ESXi сервера c MTU 1500 и блокировками данных внутри VMFS.

При вашей ситуации и топологии я бы попробовал, для начала, включить, выключенный по умолчанию VAAI в настройках гипервизора (Configuration -> Advanced Settings -> DataMover и установить DataMover.HardwareAccelerationMove = 1). Однако проверьте совместимость вашего хранилища с vSphere. В противном случае вы можете получить еще большую деградацию производительности, а то и вовсе потерять хранилища в гипервизорах.
Если все нормально, то вы получите прирост скорости при работе гипервизовров с томами и данными, такими как создание, копирование, перемещение и резайзинг VMDK, создание и консолидация снапшотов и т.п.
Вторым этапом я бы всетаки собрал гипервизоры под управление vCenter Server. Это даст возможность централизовать управление хранилищами, что в свою очередь позволить использовать VADP. Возможно этого будет достаточно для ABR и у вас заработает блочная передача на уровне SAN.
Ну и третий этап - это на выбор, или меняйте топологию, или собирайте кластер, или меняйте ПО.

[Владимир Пилипчук]

t_q_l: И еще забыл сказать важную веСЧ - если я прав, то для сохранения консистентности данных скорость передачи будет выравнена по самому медленному потоку (то есть цепочки - самый медленный сторадж+самый медленный LAN-порт), во избежание переполнения и сброса буферов, при многопоточной передаче.