failover plan veeam что это
Настройка Failover Plan (Плана аварийного переключения на реплику виртуальной машины)
Используя Veeam Backup & Replication возможно переключиться на любую точку восстановления реплики.
Операции переключения на реплику и обратного переключения на исходную VM можно выполнить как для одной машины, так и для группы машин. Например, если произошел сбой в работе хоста ESX(i), есть возможность моментально переключиться на резервный хост и гарантировать минимальный простой служб.
Чтобы создать план переключения при отказе, выполните одно из следующих действий:
В данном случае VM будут автоматически добавлены в план отработки отказа. Добавить в план другие VM станет возможно после прохождения всех разделов настройки.
В данном случае выбранные VM будут автоматически добавлены в план отработки отказа. Добавить в план другие VM станет возможно после прохождения всех разделов настройки.
General
Укажите название и описание плана аварийного переключения:
Virtual Machines
Выберите VM, которые необходимо добавить в план отработки отказа
Возможно добавлять отдельные VM и целые vApp (хосты, кластеры, папки, пулы ресурсов, виртуальные приложения, хранилища данных или теги).
Установите порядок запуска VM:
Установите временную задержку для VM. Время задержки определяет, как долго Veeam Backup & Replication должен ждать перед запуском операции аварийного переключения для следующей VM в списке. Возможно использовать временные задержки, чтобы убедиться, что некоторые VM уже работают в момент запуска зависимых виртуальных машин. Для последней в списке VM невозможно указать задержку. Если ременные задержки не указаны, VM будут запускаться одновременно.
Пример: в план отработки отказа добавлено 2 VM и установлена временная задержка 60 секунд для первой VM в списке. Veeam Backup & Replication выполнит аварийное переключение следующим образом: запустит аварийное переключение для первой VM в списке, подождет 60 секунд и запустит аварийное переключение для второй VM в списке.
Чтобы установить время задержки для виртуальной машины:
Summary
Завершите процедуру настройки плана переключения при отказе:
Чтобы добавить VM к существующему плану отработки отказа:
Failover Plan
Virtual Machines
Summary
Для выполнения плана аварийного переключения возможно:
Чтобы переключиться на последнюю точку восстановления реплик VM:
Чтобы переключиться на определенную точку восстановления реплик VM:
Возможно отменить переключение сразу для всех VM, добавленных в план аварийного переключения. При отмене отработки отказа рабочая нагрузка переключается обратно на исходные VM и отменяются все изменения, внесенные в реплики VM во время отработки отказа.
Чтобы отменить аварийное переключение с помощью плана аварийного переключения:
Операцию переключения на реплику VM можно выполнить, если реплика была создана корректно:
Чтобы переключиться на реплику VM:
Failover Plans
A failover plan helps you perform failover for dependent VMs one by one, as a group. To do this automatically, you can prepare a failover plan.
In the failover plan, you define the order in which VMs must be processed and an interval of time for which Veeam Backup & Replication must wait before starting the failover operation for the next VM in the list. The failover plan helps ensure that some VMs, such as a DNS server, are already running at the time the dependent VMs start.
The failover plan must be created in advance.
In case the primary VM group goes offline, you can start the failover plan manually. When you start the plan, you can choose to fail over to the latest state or select the point in time to which VM replicas must be started. Veeam Backup & Replication will look for the closest restore points to this point in time and use them to start VM replicas. The source VMs will not be powered off.
The failover process is performed in the following way:
Limitations for Failover Plans
The maximum number of VMs that can be started simultaneously when you run a failover plan is 10. If you have added more VMs to the failover plan and scheduled them to start simultaneously, Veeam Backup & Replication will wait for the first VMs in the list to fail over and then start the failover operation for subsequent VMs. This limitation helps reduce the workload on the production infrastructure and backup server.
For example, if you have added 14 VMs to the failover plan and scheduled them to start at the same time, Veeam Backup & Replication will start the failover operation for the first 10 VMs in the list. After the 1 st VM is processed, Veeam Backup & Replication will start the failover operation for the 11 th VM in the list, then for the 12 th VM and so on.
Finalizing Failover Plans
Failover is a temporary intermediate step that needs to be finalized. You can finalize group failover in the same ways as regular failover: undo failover, perform permanent failover or failback.
Veeam Backup
Портал Veeam Cloud Connect Portal предназначен для аварийного переключения на реплики, когда управляющий клиентский сервер Veeam и оригиналы виртуальных машин находятся в нерабочем состоянии.
Для аварийного переключения на реплики через Cloud Connect Portal требуется наличие созданных заранее Failover Plans. Без них переключение на реплики из веб-портала невозможно.
Начало работы с Veeam Cloud Connect Portal
Для доступа к Cloud Connect Portal откройте в веб-браузере сайт https://veeamccp.slcloud.ru/
Введите учетные данные, которые были предоставлены вам в письме-приглашении. Это те же самые учетные данные, которые вы вводили при настройке подключения к сервис-провайдеру в консоли Veeam Backup&Replication.
Работа с Failover Plan
На главной странице будет отображаться все созданные вами в данной подписке Failover Plans
Для запуска плана выберите его в списке и нажмите «Start»
После этого выберите один из двух вариантов:
После этого начнет выполняться Failover Plan и реплики запустятся в порядке, который вы определили для них при его создании.
Внимание! При выполнении Failover Plan не происходит никаких операций с оригинальной площадкой, так как считается, что она недоступна.
Сайт переключится на вкладку «Session History», где будет отображаться статус выполнения плана целиком и отдельно для каждой виртуальной машины.
Так выглядит Failover Plan, который успешно выполнился.
Для отмены Failover Plan переключитесь на основную страницу, выберите запущенный Failover Plan и нажмите «Undo».
Внимание! Операция Undo отменяет все изменения, произошедшие на реплике за время ее работы. Для сохранения изменений требуется после восстановления работоспособности основной площадки выполнить обратное переключение с реплик на оригиналы через консоль Veeam Backup&Replication.
Сайт переключится на вкладку «Session History» и отобразится процесс остановки Failover Plan
Planned Failover
Planned failover is smooth manual switching from a primary VM to its replica with minimum interrupting in operation. Planned failover is helpful when you know that your primary VMs are about to go offline and you need to proactively switch the workload from original VMs to their replicas. You can use the planned failover, for example, if you plan to perform datacenter migration, maintenance or software upgrade of the primary VMs. You can also perform planned failover if you have noticed some signs of the approaching disaster.
As the procedure is designed to transfer the current workload to the replica, it does not suggest selecting a restore point to switch.
When you start the planned failover, Veeam Backup & Replication performs the following operations:
If VMware Tools are installed on the VM, Veeam Backup & Replication tries to shut down the VM guest OS. If nothing happens after 15 minutes, Veeam Backup & Replication powers off the VM. If VMware Tools are not installed on the VM or the VM is suspended, Veeam Backup & Replication powers off the VM.
During the planned failover, Veeam Backup & Replication creates two helper restore points (steps 1 and 3) that are not deleted afterwards. You can see these restore points in the list of restore points for the VM. You can use the restore points later to roll back to the necessary VM replica state.
During planned failover, Veeam Backup & Replication always retrieves VM data from the production infrastructure, even if the replication job uses the backup as a data source. This approach helps Veeam Backup & Replication synchronize the VM replica to the latest state of the production VM.
Finalizing Planned Failover
When your primary host is online again, you can switch back to it. You can finalize planned failover in the same ways as regular failover: undo failover, perform permanent failover or failback.
Limitations for Planned Failover
Planned failover has the following limitations:
Как правильно бекапить SQL Failover кластер
Не люблю, когда в сети нет простых пошаговых инструкций без умных слов, показывающих, как делать не самые очевидные вещи. Поэтому без лишних вступлений сегодня расскажу, как правильно бекапить отказоустойчивый (Failover) кластер SQL. Да-да, именно кластер, а не отдельно стоящий SQL сервер. Как раз про них написано много, а кластера почему-то избегают.
И без долгих предисловий рассмотрим нашу лабу:
Теперь — до того как мы приступим — давайте договоримся про две важные вещи:
Поехали!
Итак, как уже ясно, бекапить мы будем ноды целиком. Сразу возникает первый вопрос: зачем, если Microsoft SQL кластер из коробки даёт нам очень и очень приличный уровень защиты от падения? Всегда, например, можно увести роль SQL и ресурсы на другую ноду.
Это рассуждение верно, но упускается тот вариант, что ноды сами по себе уязвимы. Если кратко: кластер на уровне ОС закрывает риски, связанные с функционированием ОС конкретной машины, а SQL кластер закрывает риски, связанные конкретно с базами данных. Да и бекапить такую конфигурацию интересней.
Давайте представим, что к нам придёт зловред шифровальщик и начнёт одну за одной класть ноды кластера. Тут у нас уже не получится быстренько восстановить только файлы БД. А ещё бывают неудачные обновления ОС, умирающее железо и т.д.
Поэтому предлагаю считать, что о необходимости бекапа всего сервера мы договорились, и теперь переходим к инструментарию. Я напишу, как достичь поставленных целей и быть восхитительным с помощью Veeam Backup & Replication 9.5 Ещё версию назад Veeam умел централизованно бекапить только виртуальные машины, но теперь он получил полноценную поддержку бекапов физических серверов, и грех будет в этом не разобраться.
Protection Groups
Для бекапа мы будем использовать Protection Group. Это простая логическая сущность, по сути — контейнер, где группируются машины, которые надо забекапить. Например, в нём можно сгруппировать несколько объектов из AD и не беспокоиться, что новые машины не попадут в бекап. Protection Group автоматически сканирует изменения и выполняет остальные необходимые действия по заданному расписанию. Одним словом, очень удобная штука, особенно в больших смешанных инфраструктурах.
Но переходим от слов к делу: запускаем Veeam Backup & Replication, идём на вкладку Inventory и запускаем визард создания Protection Group
На первом шаге надо задать имя группы и какое-то описание по необходимости, тут всё ясно.
А вот на следующем шаге надо уже выбирать, откуда Protection Group будет получать информацию о защищаемых машинах. Можно добавить их по старинке вручную по DNS именам или IP, можно предоставить список в виде CSV файла, как делают настоящие джедаи, но мы люди попроще и будем использовать объекты Active Directory. В нашем случае это так же значит, что все ноды кластера будут обнаруживаться автоматически, в том числе и новые.
На следующем шаге вас первым делом попросят указать адрес контроллера домена, порт и данные пользователя для подключения.
Если всё хорошо, нажимаете Add и выбираете нужные OU.
Важный момент: добавлять нужно только кластер! Отдельные ноды добавлять не надо.
Мой кластер называется WINCLU, его и добавлю.
На следующем шаге задаются правила для исключения машин из сканирования. В современном мире OU зачастую содержат как виртуальные, так и физические машины, и в ряде случаев их бэкапят по разным сценариям. На самом деле бывают даже смешанные кластера, где использованы как физические, так и виртуальные машины. Этакий третий уровень защиты.
По умолчанию, первые две галочки выбраны, и вам их снимать, может быть, не обязательно, но моя лаба полностью виртуальная, а мы в начале договорились посмотреть на функционал бекапа физических машин.
Теперь надо указать, какого пользователя мы будем использовать. В неком идеальном случае у нас создан специальный пользователь в AD, имеющий права локального админа на всех машинах. Но если это не так, то Veeam позволяет назначить на каждый объект отдельного юзера.
Зачем нужен локальный админ?
Отдельно надо заострить ваше внимание на кнопке Test Now. Отличная вещь, позволяющая быстро проверить, что все учётки введены правильно, а в случае кластера быть досрочно уверенным, что все ноды видны и доступны.
Потом надо задать интервал и время сканирования участников PG. Можно хоть раз в неделю, а можно и непрерывное обновление настроить. Тут решать вам, но обычно отличный вариант — это повторить частоту бекапа, дабы все новые участники смогли попасть в ближайшую точку восстановления.
Ниже находятся уже менее очевидные, но важные опции.
Distribution server — это машина, с которой будут устанавливаться Veeam Agents. В общем случае достаточно использовать Veeam Backup сервер, но в географически распределённых инфраструктурах с плохой связью имеет смысл указать вариант поближе. Во всех остальных случаях менять не имеет смысла.
Дальше. Причин, почему не следует устанавливать и не обновлять агентов в автоматическом режиме, я не знаю, но если не доверяете автоматике, можете смело отказываться. Но учтите, что из-за разницы версий вы можете остаться без очередной точки бекапа.
Также можно согласиться на установку нашего CBT драйвера, который будет отслеживать изменение дисков на уровне файловой системы. Это позволит отдавать в бекап только фактически изменившиеся сектора, а значит, точка восстановления меньше, бекап быстрее, нагрузка на сервер меньше. Но если не доверяете, трафик вам не важен, диски у вас большие и связь отличная, то можно и не ставить.
С автоматической перезагрузкой есть нюанс: она применяется не только при первой установке, но и при обновлениях. Так что не забудьте снять галочку, если вы не можете позволить себе такой роскоши.
На следующем шаге нас проинформируют о необходимости доустановки компонентов на Distribution сервер. Даже если их не окажется, через минуту они там будут по нажатию кнопки Apply.
На последнем шаге нас проинформируют, что Protection Group (PG) создана успешно, и предложат запустить discovery, т.е. группа по заданным условиям составит список машин и согласно настройкам запустит установку агентов. Пока будут происходить все необходимые операции, можно сходить налить себе кофе.
По опустошении чашки кофе можно обнаружить, что на одну из нод не удалось установить агента из-за ошибки доступа по сети. Если с вами приключилось подобное горе, то просто отключите от этой ноды диск с кворумом. Не часто, но бывает. А может, это и вовсе особенность именно моей лабы. Так и не хватило усидчивости разобраться с этой проблемой до конца.
Создаём бекап
Итак, если на предыдущем этапе всё закончилось успешно, то в вашей Protection Group теперь есть кластер и список его нод с успешно установленными агентами. Поэтому переходим к самому интересному: создаём бекап в режиме Failover Cluster, чтобы в него попали все ноды и все приатаченные диски.
В чём главное отличие и почему нельзя их просто забекапить как отдельные машины? Технически, можно так поступить со всеми нодами, кроме одной — текущего держателя роли кластера. Если её начать бекапить прямо в лоб, остальные ноды могут потерять с ней связь и начнут перетягивать одеяло на себя, что в итоге приведёт к развалу и остановке всего кластера. Это случается очень часто у загруженных систем.
С помощью правой кнопки мыши (ПКМ), кликнув на PG, запускаем мастер создания бекапной джобы и сразу выбираем режим Failover Cluster. Такие задания могут быть созданы только на центральном Backup Server, в отличие от локальных агентских бекапов. Но это и логично: как вы помните, мы хотели заодно по полной бекапить SQL, а значит, будут регулярно транкейтиться логи – для чего в любом случае понадобится связь между серверами.
Затем выбираем имя джобы и список участников бекапа. По умолчанию тут будет только выбранная PG, но сюда также можно добавить что-то дополнительно.
На следующем шаге надо выбрать между бекапом отдельных дисков или всей машины целиком. В общем случае если можно бекапить всю машину, то нужно бекапить всю машину. В нашем случае это верно, т.к. мы должны забекапить все диски кластера, которые могут оказаться на любой ноде нашего кластера.
Потом выбираем репозиторий для бекапов и указываем, сколько точек восстановления у нас будет. По кнопке Advanced можно вызвать меню тонкой настройки, где можно выбрать, каким способом создавать цепочку бекапов, включить дополнительные проверки целостности файлов и многое другое, на что сейчас мы не будет тратить время, потому что впереди самое интересное — раздел Guest Processing.
Именно от настроек на этой вкладке зависит, получится ли у нас так называемый application consistent бекап (что переводят иногда как целостная резервная копия или как резервная копия с учётом состояния приложений, либо ещё не пойми как и, главное, зачем). Поэтому заходим в Applications, выбираем нашу PG и жмём Edit.
Убеждаемся, что на первой вкладке включен Application-Aware Processing. В этом случае будет задействована подсистема VSS, работа которой должна пройти без ошибок. Вернее, она может отработать с ошибками, но в этом случае бекап не будет создан и понадобится разобраться в причинах сбоя. Также здесь надо определить судьбу транзакционных логов: Veeam может игнорировать их, просто копировать в бекап или обрезать.
Теперь переходим к вкладке SQL. Первое, что надо сделать, это задать учётку пользователя для взаимодействия с SQL сервером и его базами. В идеальном мире она совпадает с локальным администратором, которого мы указывали при создании PG. В противном случае главное, что у этого пользователя должны быть Databases Owner права.
Затем выбираем, как мы будем взаимодействовать с логами. Например, если у вас база в режиме Full Recovery, очень удобно логи транкейтить. Или можно бекапть логи транзакций по отдельному расписанию, чтобы можно было быстрее откатить базу на нужный момент времени, а не терять всё, что было между бекапами. Конечно, можно ничего с логами и не делать вовсе.
Переходим к предпоследнему пункту Schedule, где устанавливаем расписание согласно вашим требованиям. Кому-то достаточно раз в день, кому-то раз в час, это только вам решать.
Завершаем создание задания, пару раз нажав Apply, и наслаждаемся результатом.
В идеальном мире, если у вас не приключится никаких фокусов с установкой агентов, которые работают связующим звеном между кластером и Veeam Server, или вы вдруг забыли подгрузить необходимую для агентов лицензию, джоба отработает на отлично, и вы увидите примерно следующую картину.
Вот и всё. Оказывается, бекапить кластеры не так уж и страшно, как об этом принято думать. Даже если это кластер внутри другого кластера.
Если интересно узнать о другом сценарии бекапа/рестора, то напишите в комментариях об этом, и мы всё расскажем в лучшем виде.