Устранение неполадок с сервером обработки

  • Статья

Сервер обработки Site Recovery используется при настройке аварийного восстановления в Azure для локальных виртуальных машин VMware и физических серверов. В этой статье описывается, как устранять неполадки с сервером обработки, в том числе с репликацией и подключением.

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

Перед началом работы

Прежде, чем приступить к устранению неполадок, сделайте следующее:

  1. Убедитесь, что вы понимаете принципы мониторинга серверов обработки.
  2. Изучите предложенные ниже рекомендации.
  3. Убедитесь, что вы соблюдаете рекомендации по производительности, а также рекомендации из руководства по выбору размеров для сервера конфигурации и изолированных серверов обработки.

Рекомендации по развертыванию сервера обработки

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

Рекомендация Сведения
Использование Убедитесь, что сервер конфигурации или изолированный сервер обработки используются строго по назначению. Не выполняйте на них никаких других задач.
IP-адрес Убедитесь, что сервер обработки имеет статический IPv4-адрес и не использует NAT.
Контроль использования памяти и ЦП Следите за тем, чтобы уровень потребления ЦП и памяти не превышал 70 %.
Обеспечение свободного места Свободным местом здесь называется дисковое пространство кэша на сервере обработки. Данные репликации сохраняются в кэше перед отправкой в Azure.

Следите за тем, чтобы свободными оставались не менее 25 % емкости. Если этот показатель падает ниже 20 %, применятся регулирование к реплицируемым компьютерам, связанным с сервером обработки.

Проверка работоспособности серверов обработки

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

Troubleshoot process server health

Шаг 1. Устранение неполадок по оповещениям о состоянии работоспособности сервера обработки

Сервер обработки создает ряд оповещений о состоянии работоспособности. Эти оповещения и рекомендуемые действия приведены в следующей таблице.

Тип оповещения Ошибка Устранение неполадок
Healthy нет Сервер обработки подключен и является работоспособным.
Warning Указанные службы не работают. 1. Убедитесь, что все службы запущены.
2. Если службы работают нормально, переходите к инструкциям по проверке проблем с подключением и репликацией.
Warning Загрузка ЦП > 80 % последние 15 минут. 1. Не добавляйте новые компьютеры.
2. Убедитесь, что количество виртуальных машин, использующих этот сервер обработки, соответствует определенным ограничениям, и обдумайте возможность настроить еще один сервер обработки.
3. Переходите к инструкциям по устранению неполадок с подключением и репликацией.
Critical Загрузка ЦП > 95 % последние 15 минут. 1. Не добавляйте новые компьютеры.
2. Убедитесь, что количество виртуальных машин, использующих этот сервер обработки, соответствует определенным ограничениям, и обдумайте возможность настроить еще один сервер обработки.
3. Переходите к инструкциям по устранению неполадок с подключением и репликацией.
4. Если проблема сохранится, запустите Планировщик развертывания для репликации VMware или физического сервера.
Warning Потребление памяти > 80 % последние 15 минут. 1. Не добавляйте новые компьютеры.
2. Убедитесь, что количество виртуальных машин, использующих этот сервер обработки, соответствует определенным ограничениям, и обдумайте возможность настроить еще один сервер обработки.
3. Выполните все инструкции, указанные для этого предупреждения.
4. Если проблема сохранится, переходите к инструкциям по устранению неполадок с подключением и репликацией.
Critical Потребление памяти > 95 % последние 15 минут. 1. Не добавляйте новые компьютеры и обдумайте возможность настроить еще один сервер обработки.
2. Выполните все инструкции, указанные для этого предупреждения.
3. 4. Если проблема сохранится, переходите к инструкциям по устранению неполадок с подключением и репликацией.
4. Если проблема сохранится, запустите Планировщик развертывания для проблем с репликацией VMware или физического сервера.
Warning Свободное место в папке кэша < 30 % последние 15 минут. 1. Не добавляйте новые компьютеры и обдумайте возможность настроить еще один сервер обработки.
2. Убедитесь, что число виртуальных машин, использующих этот сервер обработки, соответствует рекомендациям.
3. Переходите к инструкциям по устранению неполадок с подключением и репликацией.
Critical Свободное место < 25 % в течение последних 15 минут 1. Следуйте инструкциям, указанным для предупреждения об этой проблеме.
2. 3. Переходите к инструкциям по устранению неполадок с подключением и репликацией.
3. Если проблема сохранится, запустите Планировщик развертывания для репликации VMware или физического сервера.
Critical Нет пульса от сервера обработки в течение 15 минут или более. Служба tmansvs не может связаться с сервером конфигурации. 1) Убедитесь, что сервер обработки включен и работает.
2. Убедитесь, что tmansvc запущен на сервере обработки.
3. Переходите к инструкциям по устранению неполадок с подключением и репликацией.

Table key

Шаг 2. Проверка служб на сервере обработки

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

Для всех служб, кроме агента Служб восстановления Microsoft Azure (obengine), тип запуска должен иметь значение Автоматически или Автоматически (отложенный запуск).

Развертывание Запущенные службы
Сервер обработки на сервере конфигурации ProcessServer, ProcessServerMonitor, cxprocessserver, InMage PushInstall, служба отправки журналов (LogUpload), служба приложения InMage Scout, агент Служб восстановления Microsoft Azure (obengine), InMage Scout VX Agent-Sentinel/Outpost (svagents), tmansvc, служба веб-публикаций (W3SVC), MySQL, служба Microsoft Azure Site Recovery (dra).
Сервер обработки как автономный сервер ProcessServer, ProcessServerMonitor, cxprocessserver, InMage PushInstall, служба отправки журналов (LogUpload), служба приложения InMage Scout, агент Служб восстановления Microsoft Azure (obengine), InMage Scout VX Agent-Sentinel/Outpost (svagents), tmansvc.
Сервер обработки, развернутый в Azure для восстановления размещения ProcessServer, ProcessServerMonitor, cxprocessserver, InMage PushInstall, служба отправки журналов (LogUpload).

Шаг 3. Проверка пакетов пульса от сервера обработки

Если от сервера обработки не поступают пакеты пульса (код ошибки 806), выполните следующие действия:

  1. Убедитесь, что виртуальная машина сервера обработки включена и работает.

  2. Проверьте отсутствие ошибок в следующих журналах.

    C:\ProgramData\ASR\home\svsystems\eventmanager*.log C\ProgramData\ASR\home\svsystems\monitor_protection*.log

Проверка возможности подключения и репликации

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

Flowchart showing steps to troubleshoot connectivity and replication.

Шаг 4.Проверка синхронизации времени на исходном компьютере

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

Шаг. 5. Проверка антивирусного ПО на исходном компьютере

Убедитесь, что антивирусное ПО на реплицируемом компьютере не мешает работе Site Recovery. Если вам потребуется внести Site Recovery в списки исключений антивирусных программ, воспользуйтесь этой статьей.

Шаг 6. Проверка возможности подключения с исходного компьютера

  1. Установите клиент Telnet на исходный компьютер, если его там нет. Не используйте проверку связи командой Ping.

  2. С исходного компьютера с помощью Telnet выполните проверку связи с сервером обработки по порту HTTPS. По умолчанию для трафика репликации используется порт HTTP 9443.

    telnet <process server IP address> <port>

  3. Убедитесь, что подключение выполняется успешно.

Подключение Сведения Действие
Успешно Telnet отображает пустой экран и сервер процессов доступен. Никаких дополнительных действий не требуется.
Неудачно Не удается подключиться. Проверьте, что для сервера обработки открыт входящий порт 9443. Возможно, у вас присутствует сеть периметра или промежуточная подсеть. Снова проверьте возможность подключения.
Частично успешно Удается подключиться, но исходный компьютер сообщает о невозможности связаться с сервером обработки. Переходите к следующей процедуре устранения неполадок.

Шаг 7. Устранение неполадок, связанных с не отвечающим сервером процессов

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

Для устранения неполадок проверьте, может ли исходный компьютер подключиться к IP-адресу сервера обработки, а затем выполните на исходном компьютере средство cxpsclient, чтобы полностью проверить возможность подключения.

Проверка подключения к IP-адресу сервера обработки

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

  1. Перейдите в веб-браузере по такому адресу: https://<IP_сервера_обработки>:<Порт_на_сервере_обработки>/.
  2. Если при этой проверке отображается ошибка сертификата HTTPS, это считается нормальным. Пропустив эту ошибку, вы увидите страницу с кодом 400 Bad Request (Неверный запрос). Это означает, что сервер не может обработать запрос от браузера, а стандартные механизмы подключения по протоколу HTTPS работают нормально.
  3. Если не удается выполнить такую проверку, обратите внимание на код ошибки, возвращаемый в браузере. Например, ошибка 407 означает проблему с проверкой подлинности на прокси-сервере.

Проверка подключения с помощью cxpsclient

Кроме того, вы можете запустить средство cxpsclient для полной проверки подключения.

  1. Запустите средство следующим образом.

    <install folder>\cxpsclient.exe -i <PS_IP> -l <PS_Data_Port> -y <timeout_in_secs:recommended 300>

  2. На сервере процессов проверьте полученные журналы в следующих папках:

    C:\ProgramData\ASR\home\svsystems\transport\log\cxps.err C:\ProgramData\ASR\home\svsystems\transport\log\cxps.xfer

Проверка журналов на исходной виртуальной машине на предмет сбоев отправки данных (ошибка 78028)

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

  1. Чтобы устранить неполадки, связанные со сбоем отправки данных по сети, проверьте наличие ошибок в следующем журнале:

    C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\svagents*.log

  2. Примените остальные процедуры из этой статьи, которые помогут вам устранить неполадки, связанные с отправкой данных.

Шаг 8. Проверка отправки данных с сервера обработки

Проверьте, отправляет ли сервер обработки данные в Azure.

  1. Откройте диспетчер задач на сервере обработки (нажмите клавиши CTRL+SHIFT+ESC).

  2. На вкладке Производительность щелкните >Открыть монитор ресурсов.

  3. На странице Монитор ресурсов выберите вкладку Сеть. На вкладке Процессы с сетевой активностью проверьте, передает ли cbengine.exe большие объемы данных.

    Screenshot showing a large number for volumes under processes with network activity.

Если файл cbengine.exe не отправляет большие объемы данных, выполните действия, указанные в следующих разделах.

Шаг 9. Проверка подключения сервера обработки к хранилищу BLOB-объектов Azure

  1. В мониторе ресурсов выберите cbengine.exe.
  2. В разделе TCP-подключения проверьте, подключен ли сервер обработки к хранилищу Azure.

Screenshot showing connectivity between cbengine.exe and the Azure Blob storage URL.

Проверка служб

Если сервер обработки не подключен к URL-адресу хранилища BLOB-объектов Azure, проверьте выполнение служб.

  1. На панели управления выберите Службы.

  2. Проверьте, работают ли следующие службы:

    • cxprocessserver;
    • InMage Scout VX Agent – Sentinel/Outpost;
    • агент служб восстановления Microsoft Azure.
    • служба Microsoft Azure Site Recovery;
    • tmansvc.

  3. Запустите или перезапустите службы, которые не запущены.

  4. Убедитесь, что сервер процессов подключен к сети и отвечает на запросы.

Шаг 10. Проверка подключения сервера обработки к общедоступному IP-адресу Azure

  1. На сервере обработки перейдите в папку %programfiles%\Microsoft Azure Recovery Services Agent\Temp и откройте файл CBEngineCurr.errlog с последней датой.
  2. В этом файле найдите строку 443 или строку connection attempt failed (не удалось подключиться).

Error logs in the Temp folder

  1. Если здесь вы увидите ошибки, найдите значение общедоступного IP-адреса Azure в файле CBEngineCurr.currLog, используя поиск по порту 443.

telnet <your Azure Public IP address as seen in CBEngineCurr.errlog> 443

  1. В командной строке на сервере обработки вызовите Telnet для проверки связи с общедоступным IP-адресом Azure.
  2. Если подключиться не удается, выполните следующую процедуру.

Шаг 11. Проверка параметров брандмауэра на сервере обработки.

Проверьте, блокирует ли доступ правило брандмауэра на основе IP-адресов на сервере обработки.

  1. Для правил брандмауэра на основе IP-адресов сделайте следующее:

    1) Скачайте полный список на странице Диапазоны IP-адресов центра обработки данных Microsoft Azure.

    2) Добавьте эти диапазоны IP-адресов в конфигурацию брандмауэра, чтобы он разрешал обмен данными с Azure (и на порт HTTPS, по умолчанию это 443).

    3) Разрешите доступ для диапазонов IP-адресов региона Azure, в котором располагается ваша подписка, и региона Azure "Западная часть США" (используется для контроля доступа и управления удостоверениями).

  2. В конфигурации брандмауэра на основе URL-адресов разрешите URL-адреса, перечисленные в следующей таблице.

    Имя. Коммерческий URL-адрес Государственный URL-адрес Description
    Microsoft Entra ID login.microsoftonline.com login.microsoftonline.us Используется для управления доступом и идентификаторами.
    Резервное копирование *.backup.windowsazure.com *.backup.windowsazure.us Используется для передачи данных репликации и координации.
    Репликация *.hypervrecoverymanager.windowsazure.com *.hypervrecoverymanager.windowsazure.us Используется для операций управления репликацией и координации.
    Хранилище *.blob.core.windows.net *.blob.core.usgovcloudapi.net Используется для доступа к учетной записи хранения, в которой хранятся реплицируемые данные.
    Телеметрия (необязательно) dc.services.visualstudio.com dc.services.visualstudio.com Используется для телеметрии.
    Синхронизация времени time.windows.com time.nist.gov Используется для проверки синхронизации времени системы с глобальным временем во всех развертываниях.

Шаг 12. Проверка параметров прокси-сервера на сервере обработки

  1. Если вы используете прокси-сервер, убедитесь, что его имя разрешается DNS-сервером. Проверьте значение, которое вы указали при настройке сервера конфигурации в разделе реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Azure Site Recovery\ProxySettings.

  2. Теперь убедитесь, что те же параметры используются агентом Azure Site Recovery для отправки данных.

    1) Найдите службу Microsoft Azure Backup.

    2) Откройте Microsoft Azure Backup, а затем выберите Действие>Изменить свойства.

    3) Адрес, указанный на вкладке Конфигурация прокси, должен совпадать с адресом прокси-сервера, который отображается в параметрах реестра. В противном случае измените его на тот адрес.

Шаг 13. Проверка пропускной способности

Увеличьте пропускную способность сети между сервером обработки и Azure и проверьте, возникают ли проблемы.

Следующие шаги

Если вам потребуется дополнительная помощь, опубликуйте свой вопрос на странице вопросов и ответов по Azure Site Recovery на сайте Майкрософт.