Версия 8.3.1 VMware Site Recovery Manager активна еще с 15 сентября 2020 года, а совсем недавно, 13 ноября, вендор опубликовал результаты проделанной над ошибками работы, с установкой и использованием этого продукта проблем наблюдается все еще немало. Тем не менее, без его такого полезнейшего и удобнейшего функционала аварийного восстановления жить в средах VMware непросто, следовательно, врага, что называется, надо знать в лицо. Причем, в первую очередь, с его не лучшей стороны.
Как шутят виртуализаторы, Site Recovery Manager имеет только две стадии: либо он работает, либо нет. И сегодня мы как раз попробуем разобраться, в каких именно случаях второе случается.
- Issue: При попытке изменения размера столбца сетки (браузер Chromium-семейства) пользовательский интерфейс Site Recovery зависает. В Chromium LayoutNG имеет ошибку, являющуюся причиной проблем с производительностью. Посмотреть перечень багов можно здесь и здесь.
Resolve: Проделать следующее:
-
- Закрыть все окна Chrome
- Отредактировать ссылку ярлыка Chrome и обновить ее до
C:\Program Files (x86)\Google\Chrome\Application\chrome.exe” –disable-blink-features=LayoutNG
-
- Открыть Chrome снова.
Второй вариант: Обновить браузер Chrome до версии 85.0.4183.83 или более свежей.
- Issue: Reprotect выдает ошибку вида:
VR synchronization failed for VRM group “VM_Name”. A replication error occurred at the vSphere Replication Server for replication ‘VM_Name’. Details: ‘Instance was aborted; Stale file update (wrong seq) on group GID-
на этапе синхронизации и виртуальная машина уходит в состояние «ОК».
Resolve: нет. В принципе, ожидаемо, не критично, и можно продолжать дальше работу Site Recovery Manager.
- Issue: Site Recovery Manager не инсталлируется или не конфигурируется корректно, если в имени пользователя vCenter Sigle Sign-On есть символы, отличные от ascii. Выдает ошибку:
Error 25239. Failed to configure Site Recovery Manager. Details: Provided credentials are not valid.
Resolve: В имени пользователя vCenter Single Sign-On применять только символы ascii.
- Issue: Часть восстановленных виртуальных машин выдают такое предупреждение:
vSphere HA virtual machine failover failed
С точки же зрения Site Recovery Manager не произошло никакого функционального сбоя, так как все виртуальные машины восстанавливаются успешно.
Resolve: нет. Просто подтвердить выскочившее предупреждение.
- Issue: VMware vCenter Server 7.0/7.0.0b показывают ошибку, что vSphere Replication 8.3 и Site Recovery Manager 8.3 несовместимы.
Resolve: нет. На самом деле они совместимы. Не обращать внимания на сообщение.
- Issue: Site Recovery Manager Configuration Import/Export Tool не импортирует все Network Mapping, если названия сетей совпадают. Импортируются данные взятые только из одной сети с неуникальным именем.
Resolve: Переименовать сети, чтобы не было дубликатов имен, и снова запустить процесс экспортирования и импортирования данных конфигурации.
- Issue: Плагин Site Recovery Manager 8.3 не появляется в веб-клиенте vCenter Server 6.5.х/6.7.х на Windows Server или в HTML5-клиенте.
Resolve: Создан подробный гайд.
- Issue: После изменения сертификатов vCenter Server, для виртуального устройства Site Recovery Manager нельзя отменить регистрацию. Ошибка будет выглядеть так:
A specified parameter was not correct: connection.thumbprint.
Resolve: Перезагрузить службу конфигурации. Подключиться по SSH к виртуальному хосту Site Recovery Manager и запустить «sudo systemctl restart dr-configurator».
- Issue: При тестировании, созданные в процессе восстановления виртуальные машины автоматически не защищены по его окончанию. Речь о создании ВМ на защищенном хранилище данных в группе защиты на основе массива. Тогда автоматическая защита машины не происходит, если тестовый процесс не очищен в течении первых 15 минут после создания.
Resolve: Есть два пути решения задачи:
-
- Перезапустить сервер Site Recovery Manager на защищенном сайте. Защита запустится автоматически.
- Назначить вручную защиту ВМ состояния «Not configured state» после тестового восстановления.
- Issue: Даже если выбран статический DNS без DNS-серверов в конфигурации сети, DNS-сервера все равно доступны в интерфейсе Recovery Manager Appliance Management.
Resolve: Использовать 127.0.0.1 или ::1 в списке статических DNS-серверов, исходя из выбранного IP-протокола.
- Issue: После успешного логгирования в Single Sign-On, невозможно войти в пользовательский интерфейс Site Recovery. Выдается ошибка вида:
Certificate for <host> doesn’t match any of the subject alternative names: <subjectaltlist>
Если попытаться войти через удаленку в Site Recovery, выскочит аналогичная ошибка.
Пользовательский интерфейс Site Recovery может не быть в состоянии подключиться к хостам Platform Services Controller, потому что в сертификате хоста:
-
- не назначен адрес хоста (IP или FQDN) как альтернативное имя;
- вообще отсутствуют альтернативные имена, и имя хоста не совпадает в CN-полях сертификата.
Resolve: Перенастроить the Platform Services Controller с сертификатом с SAN (Subject Alternative Name Field), в котором будет содержаться вход для адреса Platform Services Controller. Если с сертификатом все в порядке, но адрес пользовательского интерфейса не используется, следует перенастроить интерфейс и соответствующий ему Site Recovery Manager, а также vSphere Replication Appliances с корректным адресом Platform Services Controller. Все проделать для пар.
- Issue: Reprotect завершается ошибкой при использовании растянутого хранилища в ряде массивов хранения. Происходит намеренный пропуск команды отмены репликации, когда уже в наличии статус «expected». В результате массив хранилища не получает требуемое уведомление, и операция повторной защиты сбоит.
Resolve: Проделать следующее:
-
- Найти файл «vmware-dr.xml» и открыть его на редактирование.
- Установить маркер конфигурации «storage.forcePrepareAndReverseReplicationForNoopDevices» в позицию «true».
<storage >
<forcePrepareAndReverseReplicationForNoopDevices>true</forcePrepareAndReverseReplicationForNoopDevices>
</storage>
-
- Сохранить файл и перезапустить службу сервера Site Recovery Manager.
- Issue: В процессе настройки IPv6 через интерфейс Site Recovery Manager Appliance Management путем выбора «Obtain IPv6 settings automatically through router advertisement» при автоназначении DNS получаем ошибку:
invalid property – dns.
Resolve: Подключиться по SSH к хосту Site Recovery Manager Appliance и запустить:
$netmgr ip6_address –set –interface –dhcp 0 –autoconf 1 .
Чтобы получить IP-адрес через DHCP, запустить вместо этого:
$netmgr ip6_address –set –interface –dhcp 1 –autoconf 1.
- Issue: При тестовом восстановлении один из хостов ESXi дает сбой с PSOD:
Assert bora/vmkernel/main/bh.c:981.
Resolve: Перезапустить ESXi-хост.
- Issue: При попытке связать инстанс Site Recovery Manager 8.3 с инстансом Site Recovery Manager 8.2, в пользовательском интерфейсе первого вылетает предупреждение:
SRM Server cannot connect to SSO Server.
Resolve: Перезапустить сервер Site Recovery Manager 8.3.
- Issue: После запуска виртуального устройства Site Recovery Manager, VMware Console не отображается в пользовательском интерфейсе vSphere (отсутствует синий экран с информацией об устройстве). При этом все службы VMware запущены и работают.
Resolve: Перезапустить устройство Site Recovery Manager.
- Issue: Устройства vSphere Replication некорректно работают после конвергенции инстансов vCenter Server в Enhanced Linked Mode с внешними Platform Services Controller .
Resolve: Повторно зарегистрировать пользователя решения или вручную добавить его в требуемые группы.
- Issue: Экспорт сеток не работает в браузере Microsoft Edge. В представлении сетки при выборе в «Export» – «All rows/Selected rows» не загружается никаких файлов. При попытке загрузить или экспортировать историю плана восстановления выдает ошибку в консоли и файлы загрузки оказываются поврежденными.
Resolve: Обновить браузер Microsoft Edge до актуальной версии на базе Chromium.
- Issue: Невозможно удалить или принудительно остановить репликацию, если вход был осуществлен на целевом сайте, а не на исходном.
Resolve: Использовать vSphere Replication Management Server Managed Object Browser, открыв «https://vrms_address:8043/mob/?vmodl=1». Далее:
-
- Для входящих репликаций пройти по пути «content > replica-manager > getIncomingReplications». Для исходящих – по «content > replication-manager > getOutgoingReplications».
- Поменять параметры следующим образом:
start: 0
count: 2000.
Почистить сортировку и фильтры и оставить их пустыми, а затем нажать «Invoke Method».
-
- Найти репликацию, которую нужно удалить, по имени ВМ и скопировать ее ID (GID-<uuid> value).
- Зайти в репликации в « ID value > destroy > Invoke method».
- Зайти в «val > info» и убедиться, что значение статуса – «Success», а ошибки – «Unset».
Если задача все еще в процессе выполнения, обновить окно и подождать до его окончания.
- Issue: Site Recovery Manager не заполняет все реплицированные виртуальные машины в группе защиты vSphere Replication при ее редактировании и добавлении новых реплицированных ВМ. Заполняются только выбранные.
Resolve: Использовать параметр фильтра в списке, чтобы найти требуемые реплицированные виртуальные машины. Когда фильтр будет очищен, все виртуалки появятся в группе защиты.
- Issue: В базирующемся на HTML5 клиенте vSphere, когда используется vCenter Server 6.5U2 или более ранние версии, нельзя создать оповещения для Site Recovery Manager.
Resolve: Использовать клиент на Flex или vCenter Server 6.7U1 и более поздние.
- Issue: Команде PowerCLI «Connect-SrmServer» не удается подключиться к устройству Site Recovery Manager по дефолтному порту. Ошибка:
Unable to connect to the remote server .
В Windows-версии Site Recovery Manager этой проблемы нет.
Resolve: Указать порт 443 для устройства Site Recovery Manager следующей командой:
Connect-SrmServer -Port 443 .
Полный список сетевых портов Site Recovery Manager можно посмотреть здесь. Также проверить можно на ports.vmware.com.
- Issue: При восстановлении группы защиты политики хранения план восстановления может завершиться ошибкой:
Cannot fetch hosts associated with placeholder VMs. Mapping for resourcePool ‘XXXXXX’ missing in resource mappings.
где «resourcePool ‘XXXXXX’» – это вычислительный узел или кластер, не содержащий защищенных группой защиты политики хранения ВМ. Ошибка появляется при отсутствии отображения инвентаря ресурса, но некоторые хосты, принадлежащие к тому же вычислительному ресурсу, смонтировали ряд хранилищ данных, защищенных группой защиты политик хранения.
Resolve: Не удалять вычислительный ресурс из инвентаря vSphere, создать его отображение для упомянутых вычислительных ресурсов и повторно запустить восстановление. Если же он был удален, проделать следующее:
-
- Остановить сервер Site Recovery Manager, чтобы отображения появились в пользовательском интерфейсе, создать отображения для таких же вычислительных ресурсов.
- Повторно запустить восстановление.
- Когда оно закончится успешно, инициация повторной защиты все равно может генерировать ошибки. В этом случае нужно удалить затронутую группу защиты политики хранения из Site Recovery Manager. Если и это не помогло, и повторная защита Site Recovery Manager не отменила репликацию хранилища, отменить ее для вовлеченных LUN, используя инструменты администрирования хранилища. Затем следует запустить Discover Devices на проблемной паре массивов и убедиться, что направление репликации определяется правильно. И, наконец, нужно пересоздать группу защиты политики хранения в обратном направлении, после чего снова добавить ее в текущий план восстановления.
- Issue: После миграции сервера Windows Site Recovery Manager на Site Recovery Manager Virtual Appliance служба srm-server не запускается.
Resolve: Перенастроить Site Recovery Manager Virtual Appliance через интерфейс Site Recovery Manager Appliance Management.
- Issue: Назначение пары инстансам Site Recovery Manager завершается ошибкой после установки нового сертификата в Site Recovery Manager Appliance. Когда меняется сертификат одного из устройств SRM в паре сайтов, соединение между ними теряется, и операция назначения пары не выполняется.
Resolve: Можно либо повторно подключить эту пару сайтов к такому, где сертификат изменен не был, либо перезапустить службу srm-server на устройстве с измененным сертификатом и повторно подключить пару.
- Issue: Когда запускается Test Recovery плана восстановления, содержащего группы защиты политики хранения в растянутом кластере хранения, вылетает предупреждение:
The name <Datastore_name> already exists.
Resolve: Игнорировать предупреждение. На успешность завершения операций SRM это не влияет.
- Issue: Запланированная миграция группы защиты политики хранения постоянно фейлится с ошибкой:
ProtectionGroupNotSynced fault: “The peer site has not finished synchronizing changes to protection group ‘SP_protection_group_name’. If this is a planned migration, wait for the peer site to synchronize and then retry the workflow.
При отключении проверки, процесс миграции успешно завершается.
Resolve: Сделать следующее:
-
- Отредактировать файл «vmware-dr.xml» для серверов Site Recovery Manager, дописав следующую дополнительную конфигурацию:
<replication>
<failPlannedMigrationIfSitesNotSynced>false</failPlannedMigrationIfSitesNotSynced>
</replication>
-
- Перезапустить оба сервера Site Recovery Manager.
- Опять инициировать запланированную миграцию групп защиты политики хранения.
- Issue: vCenter Server выдает предупреждение об истечении срока evaluation-лицензии на локальный инстанс Site Recovery Manager, даже когда парой назначен инстанс Site Recovery Manager в VMware Cloud on AWS.
Resolve: Можно игнорировать без ущерба.
- Issue: При запуске Test Recovery в группе защиты политики хранения с растянутым хранилищем, выдается предупреждение о возможных сбоях динамической миграции. Перезапускается служба vpxd и создается дамп ядра.
Resolve: Игнорировать.
- Issue: Выполнение плана восстановления могло не повлечь за собой включение виртуальной машины с ошибкой:
vmodl.fault.InvalidArgument:path.
В этом случае в логах сайта сервера отобразится:
YYYY-MM-DDT20:24:35.996-08:00 error vmware-dr[02448] [SRM@6876 sub=Recovery …] Plan execution (test workflow) failed;
plan id: 34f86036-3bc7-4c2d-a841-e15c5d781532, plan name: HBRRP_LIMITS, error: (vmodl.fault.InvalidArgument) {
–> faultCause = (vmodl.MethodFault) null,
–> faultMessage = <unset>,
–> invalidProperty = “path”
–> msg = “A specified parameter was not correct: path”
–> }
–>
Ошибка является результатом сбоя операции «Relocating VM before powered on» на целевом для восстановления ESXi-хосте. В логах службы vpxa появится:
YYYY-MM-DDT03:56:48.255Z error vpxa[2099931] [Originator@6876 sub=vpxaVmprov opID=failedOpId] Failed to canonicalize vm register path; /vmfs/volumes/…/recoveredVm.vmx, err: 16(Device or resource busy)…YYYY-MM-DDT03:56:48.256Z info vpxa[2099931] [Originator@6876 sub=Default opID=failedOpId] [VpxLRO] — ERROR task-1824 — vpxa — vpxapi.VpxaService.registerVm: vmodl.fault.InvalidArgument:–> Result:–> (vmodl.fault.InvalidArgument) {–> faultCause = (vmodl.MethodFault) null,–> faultMessage = <unset>,–> invalidProperty = “path“
Resolve: перезапустить невыполненный план восстановления.
- Issue: Информация об устройствах и хранилищах теряется в процессе переключения плана восстановления на базирующуюся на массивах репликацию групп защиты. При запуске отказоустойчивого плана восстановления, исходя из конкретного типа SAN и того, используется ли отсоединение хранилища данных от хоста во время восстановления, информация на вкладках «Devices» и «Datastores» может пропадать.
Resolve: После успешной повторной защиты она появится снова.
- Issue: Повторная защита сбоит с ошибкой:
Internal error: Received unexpected exception during prepare phase. The session is not authenticated.
Resolve: Перезапустить операцию повторной защиты.
- Issue: Для первичной виртуальной машины на ESXi 6.7 синхронизация репликации выполняется, однако инстанс репликации никогда не завершается успешно. В ESXi 6.7 часто для параллельного трансфера планируется больше блоков журнала, чем по факту может передаться. Если реплицируется машина на таком хосте, а целевой хост слишком медленный или же постоянно возникают ошибки сети, может вылететь предупреждение:
DiskQueue is full.
Resolve: Сделать следующее:
-
- Перенести все виртуальные машины на другой хост ESXi.
- Изменить значение параметра DemandlogTransferMaxNetwork с базового 64 на 63 в «Advanced setting» ESXi.
- Поставить ESXi-хост в «maintenance mode».
- Отправить хост в перезагрузку.
- Issue: Инициация полной синхронизации может остановиться до завершения, если исходная ВМ для репликации на ESXi 6.7 или ESXi 6.7U1. Синхронизация репликации все еще в прогрессе, а контрольная сумма в деталях информации о репликации не растет. Операции выключения питания, снятия снэпшота, возврата к снэпшоту и миграция для виртуалки завершаются ошибкой с таймаутом или ошибками прогресса задачи.
Resolve: Сделать пошагово:
-
- В «Advanced settings» ESXi отключить контрольную сумму для vSphere Replication, установив «HBR.ChecksumUseChecksumInfo = 0».
- Перенести все виртуальные машины и отключить те, которые нельзя перенести на ESXi-хост.
- Перевести хост в maintenance mode.
- Перезагрузить хост.
Важно! Это решение отключает контрольную часть процесса синхронизации, в результате чего все выделенные блоки будут отправлены на удаленный сайт, неважно, разные они или нет.
- Issue: Во время evaluation-режима Site Recovery Manager отображается неправильное количество подлежащих защите виртуальных машин в vSphere Client. Во вкладке «The Administration > Licensing > Assets» указано, что Site Recovery Manager в evaluation-режиме может защитить до сотни ВМ на каждом сайте. Правильное число – 75.
Resolve: Пока пользуйтесь 75-ю.
- Issue: Если имена сетей отличаются от тех, которые восстанавливаются, Site Recovery Manager может создавать фиктивные сети от защищаемого vCenter Server на vCenter Server восстановления. Такие пустые сети создаются лишь единожды, а не при каждой инициации Test \ Recovery \ Reprotect.
Resolve: Выходов может быть два:
-
- Отключить сохранение снэпшотов путем изменения значения «preserveMpitImagesAsSnapshots» в улучшенных настройках Site Recovery Manager.
- Уничтожить фиктивную сеть и продолжить работу с SRM.
- Issue: Site Recovery Manager 8.3 Configuration Import/Export Tool выдает ошибку в процессе импорта конфигурации с защищаемой виртуальной машины при отсутствии плана восстановления. Когда защищаемые ВМ ставятся в план восстановления, удаляются все планы восстановления с этими машинами и экспортируется конфигурация при помощи VMware Site Recovery Manager 8.2 Configuration Import/Export Tool, настройки восстановления машины из этого пула экспортируются, но импортировать их позднее становится невозможным. При попытке импорта выдает следующую ошибку:
Error while importing VM settings for server with guid ‘6f81a31e-32e0-4d35-b329-783933b50868’
Все остальное импортируется нормально.
Resolve: Заново создать план восстановления, перенастроить нужные параметры и снова экспортировать конфигурацию. Не удалять планы восстановления, если нужен последующий импорт и экспорт.
- Issue: Виртуальные машины, защищенные в Storage Profile Protection Groups не показываются в создаваемом при работе DR IP Customizer tool CSV-файле. Если используется DR IP Customizer tool на множественном окружении vCenter Server, например, при настройке с объединенными PSC, где на каждом сайте доступно более одного инстанса vCenter Server, нужно указывать параметр «–vcid UUID» для сбора сетевой информации о виртуальных машинах, защищенных Site Recovery Manager. При предоставлении вторичному сайту идентификатора «vcid» происходит подключение к неправильному серверу vCenter и в созданном файле CSV нужные ВМ не значатся.
Resolve: Когда используется DR-инструмент настройки IP-адресов, указывать только «vcid» и «uri» первичного vCenter Server.
- Issue: Если в Enhanced Linked Mode развернуты Site Recovery Manager и vCenter Server, после запуска инсталлятора SRM в «modify mode», сервера Site Recovery Manager не подключены.
Resolve: Перенастроить соединение серверов SRM.
- Issue: Настройка подсети путем отображения IP не полностью поддерживается для использующих несколько сетевых адаптеров виртуальных машин на Linux со смешанной конфигурацией DHCP и статического IP. Site Recovery Manager занимается настройкой сетевых адаптеров с исключительно статическими IP-адресами. Именно для них у него есть соответствующее правило сопоставления IP подсети. Он может очищать некоторые параметры конфигурации для сетевых адаптеров, настроенных с DHCP. Эта проблема хорошо известна для Red Hat Enterprise Linux 6.x / 7.x и CentOS 6.x / 7.x: там наблюдается удаление «/etc/sysconfig/network-scripts/ifcfg-ethX»-файлов, если сетевые карты настроены с помощью DHCP.
Resolve: Настраивать IP-адресацию для смешанных типов конфигураций исключительно вручную (опция SRM: «Manual IP Customization»).
- Issue: Настройка IP не удается, если используются спецсимволы в имени плана восстановления.
Resolve: Удалить все спецсимволы из имени плана восстановления.
- Issue: При выключении защищаемого vCenter Server может наблюдаться снижение производительности на восстанавливаемом сайте при использовании пользовательского HTML5-интерфейса. Особенно в диалоговом окне «Configure Recovery Settings».
Resolve: Обновить пользовательский интерфейс и повторить операцию.
- Issue: Удаленный сервер vCenter не отображается на вкладке «Summary» после апгрейда Site Recovery Manager. Эта проблема известна для обновления до версии 8.2 из ранних.
Resolve: Восстановить соответствующую пару вручную.
- Issue: Привилегии Site Recovery Manager не локализированы в клиенте vSphere 6.7.
Resolve: Обновиться до vSphere 6.7U1 или выше.
- Issue: В пользовательском интерфейсе зациклен поток сообщений об ошибке 403, из-за чего невозможно работать.
Resolve: Выйти из пользовательского интерфейса SRM и зайти снова, снять галочку в браузере на «Restore last session». Для Chrome выключить опцию «Continue where you left off».
- Issue: Имена папок хранилищ данных VSAN в диалоговом окне свойств защиты виртуальной машины показываются с UUID вместо привычных имен.
Resolve: нет.
- Issue: Кластер хранилищ данных, состоящий из видимых для Site Recovery Manager нереплицируемых хранилищ или принадлежащих к разным логическим группам, не получает SRM-предупреждения.
Resolve: нет.
- Issue: После выполнения аварийного отключения, сетевые адаптеры виртуальных машин на сайте аварийного восстановления могут оставаться отключенными. При повторном запуске происходит сбой настройки IP сетевых адаптеров.
Resolve: Вручную подключать соответствующие сетевые карты, перенастроив устройства ВМ.
- Issue: Экспорт отчета из «Recovery Plan History» или из экранов Recovery Steps не работает в браузере Microsoft Edge. Ошибка:
ERROR XML5610: Quote character expected.
ERROR Error: Invalid argument.
Resolve: Использовать Chrome, Microsoft Internet Explorer или Firefox.
- Issue: Если в пользовательском интерфейсе vSphere кликнуть правой кнопкой мыши на реплицируемую виртуальную машину и выбрать «Reconfigure Replication», всплывающее окно блокируется в браузере Mozilla Firefox.
Resolve: В меню «Options» Mozilla Firefox выбрать вкладку «Content» и добавить URL vCenter Server в список исключений для всплывающих окон.
- Issue: Site Recovery Manager Server может аварийно завершить работу при попытке повторного включения восстановления виртуальной машины.
Resolve: Запустить сервер SRM и отключить восстановление виртуальной машины.
- Issue: Операции тестирования и восстановления фейлятся, если в растянутом кластере vSAN есть один недоступный домен сбоя. vSAN Default Storage Policy не удовлетворяется и подготовить виртуальную машину с помощью Site Recovery Manager на хранилище не удается.
Resolve: Зарегистрировать восстановленную виртуальную машину в растянутом кластере vSAN вручную.
- Issue: После повторной защиты хранилище данных в инвентаре первичного защищаемого сайта может отображаться как неактивное. Часто случается при использовании расширенного хранилища. Ошибка вида:
The requested object was not found or has already been deleted.
Resolve: Обновить или повторно просканировать адаптеры хранилища. Для этого зайти на вкладку «Configure» и там выбрать «Storage Adapters». Кликнуть по иконке «Refresh» или «Rescan».
- Issue: Даже если значение параметра «remoteSiteStatus.drPanicDelay» или «remoteSiteStatus.drPingFailedDelay» было изменено, Site Recovery Manager использует назначенное по умолчанию. SRM игнорирует пользовательское значение для задержки между событиями «отсутствие ответа» и «сбой» и значение «remoteSiteStatus.drPingFailedDelay».
Resolve: Временно поможет изменение соответствующего параметра и перезапуск Site Recovery Manager Server.
- Issue: Виртуальная машина и логическая группа, назначенная в удаленной политике хранения, появляется во вкладках «Virtual Machines» и «Consistency Groups» для групп SPPG.
Resolve: Пересоздать политику хранения группы защиты. После этого проблемные машины и логические группы пропадут из соответствующих вкладок.
- Issue: Восстановление зашифрованной виртуальной машины может завершиться ошибкой на этапе «Power On», если ключ шифрования недоступен на сайте восстановления.
Resolve: Выполнить следующее:
-
- Удалить зашифрованную ВМ из инвентаря сайта восстановления.
- Проверить, что на сайте восстановления доступен Key Management Server, и что соответствующий ключ там в наличии.
- Зарегистрировать зашифрованную машину в инвентаре на сайте восстановления.
- В пользовательском интерфейсе Site Recovery Manager открыть настройки восстановления зашифрованной ВМ и отключить питание при восстановлении.
- Повторить восстановление.
- Issue: Test Recovery сбоит с ошибкой:
Cannot create a test bubble image for group.
Если ВМ имеет несколько реплицируемых с помощью vSphere Replication в разные хранилища данных vSphere Virtual Volumes дисков, тестовое восстановление завершится неудачей. Это происходит потому, что vSphere Replication пытается создать связанные клоны для дисков реплик, однако связанные клоны в разных хранилищах данных не поддерживаются. Интересно, что такая проблема наблюдается только в тестовом режиме – запланированное восстановление, незапланированное и повторная защита завершаются успешно.
Resolve: На вторичном сайте для тестового восстановления надо выбирать репликацию дисков только в одно и то же хранилище данных.
- Issue: Первая попытка восстановления виртуальных машин из vSphere Virtual Volumes может завершиться ошибкой на этапе настройки. Site Recovery Manager не может распознать старые версии VMware Tools, установленные на размещенных в хранилище vSphere Virtual Volumes виртуальных машинах во время первой попытки восстановления. Ошибка может вылетать в таком виде:
Vim::Fault::OperationNotSupportedByGuest : “The guest operating system does not support the operation.” Vim::Fault::InvalidGuestLogin : “Failed to authenticate with the guest operating system using the supplied credentials.
Resolve: Очистить план тестирования и повторно запустить тестовое восстановление. Обновить VMware Tools до последней актуальной версии для всех ВМ на vSphere Virtual Volumes.
- Issue: Запланированная миграция может завершиться для защищенных в хранилище данных vSphere Virtual Volumes виртуальных машин ошибкой вида:
Error – Storage policy change failure: The vSphere Virtual Volumes target encountered a vendor specific error. Invalid virtual machine configuration. A specified parameter was not correct: path.
Resolve: Повторить план восстановления.
- Issue: Операции настройки IP или вызова в гостевой системе могут завершиться с ошибкой:
Error – Failed to authenticate with the guest operating system using the supplied credentials
Resolve: Если в «Advanced Settings» опции «recovery.autoDeployGuestAlias» назначено значение TRUE (по дефолту) и время ESX-хоста, где восстанавливается и работает ВМ, не синхронизировано с серверами vCenter Single Sign-On восстанавливаемого сайта, а кроме того гостевая операционка восстанавливаемой машины – Linux и время опережает хост ESX восстановленной виртуальной машины, следует, в первую очередь, проапдейтить параметры настройки ВМ следующей процедурой и затем повторить зафейленный план восстановления:
-
- Кликнуть правой кнопкой на восстанавливаемую машину;
- Выбрать «EditSettings».
- Во вкладке «Options» выбрать «General».
- Выбрать «Configuration» для обновления параметров конфигурации.
- Нажать «Add Row» и ввести: «synchronize.tools.startup.backward» в текстовое поле «Name», а также выбрать «TRUE» в текстовом поле «Value».
- Подтвердить все действия «ОК».
Если в «Advanced Settings» значение «recovery.autoDeployGuestAlias» – «FALSE», следует убедиться, что:
-
- На гостевой ОС защищаемой машины и на серверах vCenter Single Sign-On сайта восстановления время правильно засинхронизировано.
- На защищенных виртуальных машинах настроены правильные гостевые псевдонимы для пользователя решения на сервере SRM сайта восстановления. Подсказки по правильным настройкам параметра «autoDeployGuestAlias» находятся в опции «Change Recovery Settings».
Больше информации по устранению неполадок этого вида можно узнать здесь.
- Issue: Валидные адреса vCenter Server могут не отображаться как возможные цели при инсталляции Site Recovery Manager. Если в среде есть повторяющиеся адреса vCenter Server (множественная регистрация службы одного vCenter Server на разных версиях), действительный адрес не отображается в списке. Ошибка дублированного ключа записывается в файл логов установки и выглядит она так:
VMware: Srm::Installation::XmlFileHandler::GetElementMap: INFORMATION: Inserted key ‘xxxxxx’ and value ’76B00E54-9A6F-4C13-8DD9-5C5A4E6101E3′
VMware: Srm::Installation::XmlFileHandler::GetElementMap: INFORMATION: Inserted key ‘xxxxxx’ and value ‘default-first-site:b84bcef3-85fb-4d92-8204-2392acf0088d’
VMware: Srm::Installation::XmlFileHandler::GetElementMap: ERROR: Duplicate key ‘xxxxxx’ exists
Resolve: Исчерпывающий гайд по исправлению.
- Issue: Замена SSL-сертификата vCenter Server приводит к ошибке проверки сертификата в Site Recovery Manager.
Resolve: Обновить сертификаты vCenter Server и следовать указаниям гайда.
- Issue: Аварийное восстановление для виртуальной машины, привязанной к VSS-сети демонстрирует защищенную сеть сайта в пользовательском интерфейсе для временного размещения отображений сети. Это происходит в сетях VSS с ненастроенным регулярным размещением отображений сети. Когда временное размещение завершается, сеть может появиться на вторичном сайте и у нее будет такое же имя, как у той, что на первичном. Если эта сеть не создавалась специально, то она явно не подлинная. Ее, конечно, можно выбрать как цель для временного размещения отображения, и в таком случае восстановление пройдет успешно. Однако после она будет недоступна, даже если видно, что восстановленные ВМ к ней подключены.
Resolve: Вручную подключить виртуальные машины к другой сети после восстановления и проверить, что она является подлинной.
- Issue: Тестовые отображения сети не убираются при удалении соответствующего отображения сети. Например:
- Конфигурируется отображение сети из Protected_Network_Main защищаемого сайта на Recovery_Network_Main сайта восстановления.
- Конфигурируется тестовое отображение сети из Recovery_Network_Main в Recovery_Network_Test для использования сети в тестовых планах восстановления.
- Recovery_Network_Main на сайте восстановления не используется в качестве цели для любых других отображений сети.
- Удаляется отображение сети из Protected_Network_Main в Recovery_Network_Main, но оно используется для полных восстановлений.
- Тестовое отображение сети из Recovery_Network_Main в Recovery_Network_Test не удалено.
Resolve: Удалить вручную тестовое отображение сети.
- Issue: Зависимость между двумя виртуальными машинами (один vMotion включен, а другой – выключен) на растянутом хранилище не работает при миграции.
Resolve: Удалить зависимость между виртуальными машинами и повторно запустить запланированную миграцию с помощью vMotion. Вручную снова включить зависимость для последующих рабочих процессов восстановления. Если зависимость между машинами ни на каком этапе нельзя терять, можно запустить плановую миграцию без vMotion – перенести их как обычные, исходя из порядка зависимости.
- Issue: Не способность Site Recovery Manager отслеживать удаление некритичных виртуальных машин из инвентаря vCenter Server. В результате получаем ошибки MONF в восстановлении, тестовом восстановлении и тестовой чистке workflow. Теряется соединение с серверами vCenter.
Resolve: Перезапустить сервер Site Recovery Manager.
- Issue: Когда редактируется временное отображение расположения, появляется ошибка:
The specified key, name, or identifier ‘6458aed1-6c80-4565-907f-189e6a102046’ already exists.
Resolve: Проследить, чтобы регулярного отображения для инвентарей одинаковых защищаемых сайтов не существовало.
- Issue: Переименование связанного с защищенной виртуальной машиной хранилища данных может привести к потере настроек защиты и восстановления.
Resolve: Перезапустить сервер Site Recovery Manager на защищенном сайте, либо же удалить затронутое хранилище данных из группы защиты, а затем вернуть его обратно. После повторно настроить параметры восстановления.
- Issue: Site Recovery Manager некорректно показывает имена некоторых защищенных объектов сайта в отображениях размещения. Дата-центры демонстрируют имя «vm» вместо пользовательского. Ресурс-пулы – имя «Resources» вместо определенного пользователем и т. д.
Resolve: Проверить отчет о неудачном тестировании или рабочем процессе восстановления, где произошли неудачные сопоставления, и исправить причину ошибки. Затем провести тест или регулярное восстановление согласно протоколу.
- Issue: По окончанию работы плана восстановления, последние этапы показываются, как все еще незавершенные.
Resolve: Дело во временном неправильном отображении статуса в пользовательском интерфейсе. Можно кликнуть на иконку глобального обновления.
- Issue: Подсказки и команды пропадают из списка этапов в отображении восстановления.
Resolve: Еще одно временное неудобство пользовательского интерфейса. Site Recovery Manager все этапы проходит верно, даже если этого не видно на экране.
- Issue: При выходе из строя массива хранения на защищаемом сайте Site Recovery Manager не восстанавливает виртуальные машины в группах защиты профиля хранения. ВМ – не защищены, но данные – защищены.
Resolve: Вручную восстановить хранилища данных и виртуалки на сайте восстановления.
- Issue: Если истек срок сертификата Platform Services Controller, установка Site Recovery Manager завершается ошибкой на этапе выбора инстанса vCenter Server для подключения, и выглядит она так:
Failed to validate vCenter Server. Details: Internal error: unexpected error code: -1.
Аналогичное оповещение вылетает уже после успешной инсталляции SRM и в процессе его работы, когда действие сертификата Platform Services Controller заканчивается.
Resolve: Заменить сертификат Platform Services Controller и повторить попытку установки.
- Issue: Местоположение виртуальной машины на сайте восстановления все еще существует, даже когда группа защиты уже удалена, как и план восстановления. Соответственно, если попытаться создать новую группу защиты с именем, как у удаленной, выдается ошибка. Если же попробовать вручную удалить местоположение ВМ из инвентаря vCenter Server, процесс тоже сфейлится, а Site Recovery Manager пометит машину как осиротевшую.
Resolve: Удалить расположение виртуальной машины и саму осиротевшую ВМ, затем создать группу защиты с ней.
- Issue: Процесс очистки завершается ошибкой, если он инициирован в течении 10 минут после перезапуска ESXi-хостов сайта восстановления из maintenance mode.
Resolve: Подождать 10 минут и попробовать снова.
- Issue: Повторный запуск защиты сбоит с ошибкой:
Protection Group ‘{protectionGroupName}’ has protected VMs with placeholders which need to be repaired
В результате статус имеющихся виртуальных машин помечается как «repairNeeded». Это случается, когда происходит сбой на операции «ReloadFromPath» при первой попытке повторной защиты машины.
Resolve: Повторно запустить защиту, включив функцию принудительной очистки. Таким образом операция повторной защиты завершится, и параметр «Recreate placeholder» станет активным. Затем надо кликнуть на этот параметр для восстановления виртуальных машин.
- Issue: Не выполняется восстановление после сбоя подключения к защищенному сайту. Если во время операции деактивации, RemoteOnlineSync или RemotePostReprotectCleanup (последние два – при повторной защите), план восстановления может не выполнится. Система будет ждать, пока группы или ВМ не завершат свои прерванные задачи.
Resolve: Если проблема возникла при повторной защите, следует еще раз подключить оригинальный защищаемый сайт, после чего отменить и снова запустить план восстановления. Если проблема появилась в процессе восстановления, нужно просто отменить все и опять запустить.
- Issue: Восстановленный том VMFS не получается смонтировать. Ошибка:
Failed to recover datastore.
Причина – в задержках пакетов между vCenter, ESXi и Site Recovery Manager Server.
Resolve: Повторно запустить план восстановления.
- Issue: Временно утраченное подключение к vCenter Server приводит к проблемам восстановления виртуальных машин с необработанными сопоставлениями дисков.
Resolve: Если vCenter Server с течением времени сам не включается, надо повторно установить с ним соединение, после чего запустить восстановление. Если же он после перерыва снова стал доступным, виртуальная машина восстанавливается, но имеет необработанные сопоставления дисков, и они могут отображаться неправильно. Это вызывает целый спектр ошибок: от невозможности включить ВМ, до проблем с приложениями, гостевой операционкой и т.п. В случае тестового восстановления тут не обойтись без операции очистки, после которой можно запускать тест повторно. При реальном восстановлении придется вручную подключать правильные RDM к восстановленной машине.
- Issue: Отмена плана восстановления не завершается. Это происходит из-за того, что даже если отменить план восстановления, процесс этот не закончится, пока не завершится синхронизация или ее срок не выйдет. По умолчанию это – 60 минут.
Resolve: Для экстренной остановки лучше приостановить репликацию vSphere – получим сбой синхронизации. Восстановление выдаст ошибку и тогда через vSphere Client надо просто перезапустить vSphere Replication на соответствующей вкладке. После перезапуска репликации, если в плане восстановления еще есть нужда, активировать его снова. Или просто подождать час.
- Issue: Ошибка в плане восстановления, когда выключаются виртуальные машины:
Error – Operation timed out: 900 seconds during Shutdown VMs at Protected Site step.
Обычно она возникает в случае поддержки массивами динамической подкачки (к примеру, Clariion), когда определенные массивы определяют защищаемые LUN как «read-only», вследствие чего ESXi не в состоянии завершить I/O для питания на защищаемых виртуальных машинах.
Resolve: Перезагрузить помеченные как «только для чтения» ESXi-хосты на защищаемом сайте.
- Issue: Запланированная миграция завершилась ошибкой:
Error: Unable to copy the configuration file…
Если в кластере пара хостов ESXi, и один теряет связь с хранилищем, обычно, второй может восстановить реплицируемые виртуальные машины. Однако в некоторых случаях файл конфигурации оказывается некопируемым.
Resolve: Перезапустить восстановление.
- Issue: Сбой очистки теста из-за ошибки размонтирования хранилища данных:
Error – Cannot unmount datastore ‘datastore_name’ from host ‘hostname’. The operation is not allowed in the current state.
Это значит, что не получилось отключить хранилище данных от хоста. Возможно, по причине того, что хост уже успел отключить хранилище данных еще до запуска операции очистки.
Resolve: Перезапустить операцию очистки.
- Issue: Выполнение запланированной планом восстановления миграции с незащищенными виртуальными машинами оставляет среду в непригодном для использования состоянии. Если в группе защиты нет ВМ, и запускается план восстановления этой группы в режиме запланированной миграции с удаленного сервера Site Recovery Manager, вылетит ошибка, и план перейдет в состояние «Incomplete Recovery». Причем не сможет быть удален, а LUN отключается и от узлов защиты, и от узлов восстановления.
Resolve: Удалить группу защиты и план восстановления, вручную перенастроить LUN, пользуясь интерфейсом управления SAN. Тогда среда восстановится.
- Issue: Когда пользователь осуществил вход, а с него в это время снимают разрешения на вход, появится ошибка:
Unable to retrieve Permissions data. The session is already logged in.
Такая же ошибка будет на вкладке «Advanced Settings».
Resolve: Выйти и зайти после получения разрешения.
- Issue: План восстановления не выполняется из-за ошибки ВМ на этапе настройки хранилища. Далее все запуски плана восстановления аналогично будут завершаться неудачей для этой машины и на том же этапе. Ошибка будет выглядеть так:
The specified key, name, or identifier already exists.
При этом в инвентаре vCenter Server показаны две виртуалки с одинаковыми именами, обозначенными как «failed». И одна из них будет в папке «Discovered Virtual Machines». Корни этой проблемы – в известных недостатках связи между vCenter Server и инстансом ESXi Server.
Resolve: Отменить регистрацию продублированной виртуальной машины в папке «Discovered Virtual Machines» vCenter Server. После этого все затронутые ВМ смогут запустить для себя план восстановления повторно.
Если найдутся еще какие-нибудь интересные и важные проблемы с VMware Site Recovery Manager 8.3.1, этот материал будет дополнен. И, конечно, как только появятся пути решения задач, для которых на данный момент нет ответа, он обязательно обновится.