Общие вопросы о мониторинге Site Recovery

В этой статье содержатся ответы на распространенные вопросы о мониторинге Azure Site Recovery, использовании встроенного мониторинга Site Recovery и Azure Monitor (Анализ журналов).

Общие

Чем записанная целевая точка восстановления (RPO) отличается от последней доступной точки восстановления?

Служба Site Recovery использует многоэтапный асинхронный процесс репликации компьютеров в Azure.

• На предпоследнем этапе репликации последние изменения на компьютере и метаданные копируются в учетную запись хранения журналов или кэша.
• Эти изменения, а также тег, определяющий точку восстановления, записывается в учетную запись хранения или управляемый диск в целевом регионе.
• Теперь Site Recovery может создать восстанавливаемую точку для виртуальной машины.
• На этом этапе RPO соответствует изменениям, переданным на данный момент в учетную запись хранения. Другими словами, на данном этапе значение RPO виртуальной машины равно времени, прошедшему с момента создания метки времени, соответствующей восстанавливаемой точке.
• После этого служба Site Recovery получает данные, переданные из учетной записи хранения, и применяет их к дискам реплик, созданных для компьютера.
• Затем Site Recovery создает точку восстановления и делает ее доступной для восстановления при отработке отказа.
• Последняя доступная точка восстановления указывает метку времени, соответствующую последней точке восстановления, которая уже была обработана и применена к дискам реплик.

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

Встроенное ведение журнала Site Recovery

Почему количество виртуальных машин в представлении инфраструктуры хранилища отличается от общего количества, показанного в реплицированных элементах?

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

Почему число реплицированных элементов, которое отображается в Essentials, отличается от общего числа реплицированных элементов на панели мониторинга?

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

ведение журналов Azure Monitor;

Как часто Site Recovery отправляет журналы ресурсов в журнал Azure Monitor?

• AzureSiteRecoveryReplicationStats и AzureSiteRecoveryRecoveryPoints отправляются каждые 15 минут.
• AzureSiteRecoveryReplicationDataUploadRate и AzureSiteRecoveryProtectedDiskDataChurn отправляются каждые пять минут.
• AzureSiteRecoveryJobs отправляются при триггере и завершении задания.
• AzureSiteRecoveryEvents отправляется при каждом создании события.
• AzureSiteRecoveryReplicatedItems отправляется при любом изменении среды. Как правило время обновления данных составляет 15 минут после изменения.

Как долго данные хранятся в журналах Azure Monitor?

Сведения о хранении данных см. в разделе "Хранение данных" и архивирование в журналах Azure Monitor.

Вы можете изменить период хранения по умолчанию в разделе "Использование и предполагаемые затраты" в рабочей области Log Analytics. Щелкните Срок хранения данных и выберите диапазон.

Каков объем данных журналов ресурсов?

Обычно размер журнала составляет 15–20 КБ.

Встроенные оповещения Azure Monitor для Azure Site Recovery

Есть ли затраты на использование встроенных оповещений Azure Monitor для Azure Site Recovery?

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

Будет ли текущее решение для уведомлений по электронной почте для Azure Site Recovery в хранилище служб восстановления продолжать работать?

По состоянию на сегодняшний день текущее решение для уведомлений по электронной почте параллельно с новым встроенным решением для оповещений Azure Monitor. Мы рекомендуем попробовать оповещение на основе Azure Monitor, чтобы ознакомиться с новым интерфейсом и использовать его возможности.

Какова разница между правилом генерации оповещений, правилом обработки оповещений и группой действий?

• Правило генерации оповещений: относится к правилу, созданному пользователем и определяющему условие, при котором должно активироваться оповещение.
• Правило обработки оповещений (прежнее название — правило действия): относится к правилу, созданному пользователем и определяющему каналы уведомлений, в которые должно быть направлено конкретное активированное оповещение. Вы также можете использовать правила обработки оповещений для подавления уведомлений в течение времени.
• Группа действий: относится к каналу уведомлений (например, к электронной почте, конечной точке ITSM, приложению логики, веб-перехватчику и т. д.), в который может быть направлено активированное оповещение.

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

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

Сведения о мониторинге с помощью встроенного мониторинга Site Recovery или Azure Monitor.