Планирование инфраструктуры для мгновенного восстановления виртуальных машин Instant VM Recovery

в 10:36, , рубрики: veeam backup and replication, Блог компании «Veeam Software», виртуализация, Восстановление данных, резервное копирование, системное администрирование, системы хранения данных

Всем известно, что резервное копирование затевается для того, чтобы можно было восстановить работу системы после сбоя или повреждения данных. Конечно, здесь важна скорость — ведь чем быстрее происходит восстановление, тем меньше простои и убытки для бизнеса. Для ситуаций, когда необходимо максимально быстро возобновить работу виртуальной машины, инженеры Veeam и разработали функциональность мгновенного восстановления Instant VM Recovery. Она весьма популярна среди пользователей, и сегодня мы предлагаем вашему вниманию несколько полезных советов для планирования соответствующей инфраструктуры.

Итак, добро пожаловать под кат.

Планирование инфраструктуры для мгновенного восстановления виртуальных машин Instant VM Recovery - 1

Для тех, кто еще не знаком с возможностями Instant VM Recovery, есть довольно подробное описание в документации на русском языке, в частности, вот такое определение:
Технология мгновенного восстановления виртуальных машин (Instant VM Recovery) позволяет за несколько секунд запустить виртуальную машину прямо из сжатой и дедуплицированной резервной копии, которая хранится в репозитории.

Далее в руководстве описан базовый сценарий использования.

Зачем это планировать и оптимизировать?

Если ваша инфраструктура не очень велика, и вы планируете восстанавливать небольшое число ВМ в случае необходимости, то знания базового сценария вполне достаточно.

Однако среди реальных сценариев использования Instant VM Recovery встречаются и весьма крупные инфраструктуры, в которых нужно было восстановить работу критичных сервисов после повреждения СХД, а в каких-то — после вирусной атаки. Даже если резервные копии не повреждены (благодаря хранению на отдельной системе, как велит правило «3-2-1»), восстановление может идти довольно долго. Поэтому при планировании таких сценариев IT-специалисты ставят целью обеспечить высокую скорость за счет параллельного восстановления нескольких ВМ, а также соблюдение установленнной последовательности восстановления.
Причем все это должно работать быстрее и обходиться дешевле, чем плата за ключ дешифрования по итогу атаки вируса-шифровальщика. (Да-да, всё упирается во «время-деньги».) Естественно, нужно защитить от возможных атак резервные копии, хранящиеся на диске. Специалисты рекомендуют применять многофакторную аутентификацию для доступа к репозиториям.

Или, допустим, вы являетесь провайдером услуг, предоставляя в пользование потребителям сотни, а то и тысячи ВМ. Тут счет машинам, которые может понадобиться восстановить в мгновение ока, пойдет уже как минимум на десятки. И здесь, конечно, не обойтись без планирования и подготовки. Ведь необходимо будет не просто быстро поднять все необходимые машины из бэкапа, но и обеспечить достаточную производительность этих машин, и при этом постараться свести к минимуму влияние на ресурсы производственной инфраструктуры. Так, высокую скорость можно обеспечить при восстановлении с аппаратных снимков SAN Snapshots, созданных с учетом работы приложений и реплицируемых между массивами или сохраняемых на другие носители (например, на магнитную ленту).

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

Во первых строках — производительность

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

  • Быстро выполнять операцию чтения с СХД резервных копий. Чем быстрее СХД, с которой делается восстановление, тем лучше производительность восстанавливаемой ВМ.
  • Иметь хороший скоростной канал передачи данных. Пропускная способность — рекомендуется 10 Гбит/c или выше.
  • Иметь достаточно быструю целевую систему для восстановления (это может быть та, с которой делались бэкапы). Целевая СХД должна иметь такую производительность, чтобы поддерживать все операции чтения-записи у восстановленной ВМ на то время, пока вы не финализировали процесс (читаем про заключительные шаги в документации).

Подбираем СХД резервных копий с учетом планируемого восстановления Instant VM Recovery

Конечно, в идеале для мгновенного восстановления нужно держать резервные копии на скоростной СХД, с хорошим каналом передачи данных. Но это недешевое удовольствие, поэтому обычно более старые бэкпы хранят на СХД попроще и подешевле. Можно использовать SAN попроще, S2D. Главное – хранить на СХД с достаточно высокой производительностью самые свежие бэкапы. Это могут быть четыре последних бэкапа за прошедшие сутки, и т.п. – все зависит от требований и политик организации. Если есть необходимость, то можно использовать и SSD, и даже NVMe.

Нужно понимать, что пока вы «поднимаете» машину, с этой СХД не только будут читаться данные восстанавливаемой ВМ, но работающие задания будут продолжать записывать бэкапы на эту же СХД. Вот почему так важна ее производительность.

Пример 1

В компании среднего размера используется бюджетный вариант СХД, организовано несколько уровней хранения:

  • на уровне 1 (небольшой емкости) хранятся самые свежие бэкапы – это т.н. «highly available repository», то есть репозиторий, обеспечивающий высокую доступность.
  • более старые бэкапы перемещаются на уровень 2 (емкостью побольше) – это т.н. «non-highly available repository», то есть обеспечивающий доступность не очень высокую, а просто удовлетворительную.

Если скорость чтения-записи и величина задержки (latency) СХД при этих операциях вас устраивают, можно добавить репозитории к SAN. Если нет, то можно наращивать количество репозиториев по мере необходимости, т.е. выполнять горизонтальное масштабирование.
Примечание: Старайтесь не использовать один и тот же массив СХД для продакшена и бэкапов, дабы минимизировать риск потери данных из-за ошибок во встроенном ПО.

Пример 2

Используется Storage Spaces Direct, обеспечивающий высокую доступность, а также несколько целевых систем с ReFS Multi-Resilient Volumes, обеспечивающих защиту данных и чётность с зеркальным ускорением (mirror-accelerated parity). Можно выполнить настройку таким образом, чтобы «горячие» (самые свежие) данные зеркалировались на SSD перед тем, как стать «холодными», т.е. данными, которые долежали нетронутыми до часа Х и перешли во «вторую категорию свежести». «Холодные» данные переезжают на уровень хранения попроще (подешевле). В таком варианте заложены возможности как для горизонтального, так и для вертикального масштабирования.

Планирование инфраструктуры для мгновенного восстановления виртуальных машин Instant VM Recovery - 2

Пример 3

Строим инфраструктуру резервного копирования, исходя из того, что нам нужен 2-й уровень хранения только для тех ВМ, которые требуют максимально быстрого бэкапа и восстановления.
Для этого можно задействовать пару дисковых СХД на 2TB SSD/NVMe, куда будут вести запись задания бэкапа с достаточно малым количеством хранимых точек восстановления. Затем эти бэкапы будут уезжать на СХД попроще и подешевле – для длительного хранения.

Можно использовать разные либо одни и те же репозитории. В любом случае удобно будет задействовать задания переноса резервных копий Veeam Backup Copy.

Планирование инфраструктуры для мгновенного восстановления виртуальных машин Instant VM Recovery - 3

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

Так, если у вас имеется СХД типа AFA с 60 SDD для производственных ВМ, то для них вы можете использовать MLC, поскольку операции чтения-записи будут распределены по всем дискам. Но если ее планируется использовать как первый уровень хранения бэкапов и, соответственно, для восстановления Instant VM Recovery, то имейте в виду, что нагрузка будет постоянно приходиться на малое число дисков, и ресурс может исчерпаться довольно быстро.

В следующий раз мы рассмотрим, что следует учесть при планировании сетевых подключений и целевой системы – той, на которую будет выполняться восстановление.

Что еще почитать и посмотреть

Автор: polarowl

Источник

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


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