Часто задаваемые вопросы (FAQ)#

Что должно быть установлено у клиента, чтобы начать репликацию инфраструктуры?

Установите и запустите агенты репликации на каждом из хостов ESXi в вашей VMware vSphere или внутренние агенты в случае операционных систем Windows и Linux. Каждый агент VMware будет отвечать за репликацию машин на своем хосте, что оптимизирует поток и сделает процесс репликации более надёжным. Агент VMware загружается с помощью мастера репликации нового хоста, где агент передаётся группе в качестве параметра. Машины, реплицируемые агентом, автоматически войдут в эту группу, поскольку параметры доступа к VMware vSphere также являются общими. Для получения подробной информации, пожалуйста, обратитесь к разделу ACP - Защита машин.

Как часто вы должны обновлять свои планы планы аварийного восстановления?

Чем чаще вы обновляете планы аварийного восстановления, тем лучше, когда сталкиваетесь с аварией, и тем меньше времени потребуется для обновления когда сбой уже произошел. Рекомендуемая частота - каждые 2 или 3 недели. Для получения подробной информации, пожалуйста, обратитесь к разделу ACP - Планы аварийного восстановления.

Как правильно группировать машины и почему я должен создавать группы?

Группы необходимы для логической разбивки машин. Ассоциативные принципы могут быть разными: общее назначение машин, географическое местоположение, общие правила хранения снапшотов и расписание репликации. Особенно важной и удобной функцией для групп является возможность одновременного управления общими параметрами расписания репликации и правилами хранения снапшотов, что значительно упрощает гибкую настройку репликации бизнес-приложения.

Сколько данных может быть потеряно в случае сбоя?

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

Как проверить реплицируемое бизнес-приложение в случае сбоя?

Для проверки правильности репликации и восстановления бизнес-приложения в случае сбоя, необходимо периодически тестировать планы аварийного восстановления и восстанавливать инфраструктуру. С определённой периодичностью запускайте cloud sites с последних точек восстановления на основе обновлённых планов аварийного восстановления и выполняйте набор тестов на восстановленном приложении (аналогично проверке корректности работы в производстве), убедитесь, что тесты успешно пройдены и приложение работает так, как ожидалось на cloud site. В случае возникновения проблем обратитесь в службу поддержки для скорейшего решения.

Некоторые машины изменили свои статусы на Error, в чем причина и как это исправить?

Убедитесь, что агенты репликации запущены, в их консоли нет ошибок и нет проблем с подключением к Интернету между рабочей средой и сайтом DR.

Как настроить расписание репликации для критически важных частей бизнес-приложения и правила хранения снапшотов?

Параметры расписаний и политик хранения снапшотов можно изменять как для всех машин, так и для отдельных групп и отдельных машин. Подробный обзор функциональности можно найти в разделах ACP Изменение параметров и расписания репликации и параметров хранения репликаций.

Как правильно спланировать failback в продуктив и какие простои ожидаются во время процедуры?

Failback может быть инициирован после устранения соответствующей аварии на производственной платформе и готовности основного сайта к failback бизнес-приложения. Загрузите failback-агента приложения, завершите процесс загрузки данных с сайта аварийного восстановления, протестируйте продуктив, остановите машины на cloud site и загрузите с него все изменения, запустите продуктив и снова проведите окончательное тестирование, наконец, перенаправьте трафик на продуктив. Ожидаемое время простоя зависит от размера бизнес-приложения и количества изменений, накопленных на cloud site с момента последней синхронизации между сайтами. В среднем это длится от 1 часа до 1-2 дней. Для получения подробного описания процесса, пожалуйста, обратитесь к разделу ACP -- Failback в продуктив.

Пользователь удалил некоторые ресурсы (cloud site, план аварийного восстановления

и т.д.). Как получить журнал аудита последних действий пользователя?

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

Как создать системного пользователя с ограниченными правами на просмотр и редактирование ресурсов?

Система поддерживает гибкое управление ролями, включая различные действия внутри ролей. Обратитесь к администратору решения, чтобы создать роль с необходимыми параметрами доступа и назначить ей пользователей. Подробный обзор функциональности можно найти в разделе ACP - Управление ролями.

Одна из виртуальных машин переходит в состояние "приостановлен" с причиной: "The machine will be parked: Create snapshots failed because of expected provider error. Check the event log for details". Не могли бы вы дать мне инструкцию для решения этой проблемы?

Как правило, достаточно убрать причину, указанную в логах журналов Windows. В первую очередь это логи сервиса VSS в журнале Application в Event Viewer-е, а также логи сервиса Volsnap в журнале System. Также можно выполнить следующие действия:

Перезапустить сервис VSS;
Перезагрузить сервер;
Проверить диски на ошибки;
Проверить настройки VSS (достаточно ли места выделено под Shadow Storage).

Есть ли поддержка режима транспортировки HotAdd в VMware?

Хайстекс Акура поддерживает режим транспортировки HotAdd в VMware. Этот режим обеспечивает эффективную передачу данных, позволяя устройству резервного копирования получать прямой доступ к дискам виртуальных машин через хост ESXi. Это снижает нагрузку на сеть и повышает общую производительность резервного копирования. HotAdd особенно полезен в средах с крупными виртуальными машинами или при необходимости минимизировать время простоя. Наше решение полностью совместимо с требованиями и настройками VMware для режима HotAdd. Чтобы воспользоваться этой функцией, выберите значение "HotAdd" в поле "Режим передачи VDDK" на третьем шаге конфигурации агента VMware.