Георепликация в Azure SignalR

Компании ищут локальное присутствие или требуют надежной системы отработки отказа часто выбирают развертывание служб в нескольких регионах Azure. Благодаря интеграции георепликации в Azure SignalR управление сценариями с несколькими регионами значительно упрощается.

Преимущества использования георепликации

  • Более устойчивый к региональному сбою: если происходит региональный сбой, DNS Azure SignalR будет разрешен для работоспособных реплик в других регионах.
  • Обмен данными между регионами. Разные реплики могут взаимодействовать друг с другом, как если бы они были одинаковыми экземплярами.
  • Улучшенная скорость сети: географически распределенные клиенты подключаются к ближайшей реплике. Эти реплики взаимодействуют через глобальную сеть Azure, обеспечивая быструю и стабильную сеть.
  • Общие конфигурации. Все реплики сохраняют конфигурацию основного ресурса службы Служба Azure SignalR.

Предварительные требования

Примеры использования

Contoso — это компания социальных сетей с базой клиентов, распространяемой по всей территории США и Канады. Чтобы обслуживать этих клиентов и разрешать им взаимодействовать друг с другом, Contoso выполняет свои службы в центральной части США. Служба Azure SignalR используется для обработки подключений пользователей и упрощения взаимодействия между пользователями. Конечные пользователи Компании Contoso в основном являются пользователями телефонов. Из-за длинных географических расстояний конечные пользователи в Канаде могут столкнуться с высокой задержкой и плохим качеством сети.

Схема использования одного экземпляра Azure SignalR для обработки трафика из двух стран.

До появления возможности георепликации Contoso могла развернуть ещё одну службу Azure SignalR в регионе Canada Central, чтобы обслуживать канадских пользователей. Развернув Служба Azure SignalR в географически более близком регионе, теперь можно обеспечить конечным пользователям более качественное сетевое подключение и меньшую задержку.

Однако управление несколькими службами Azure SignalR сопряжено с определёнными трудностями:

  1. Для включения общения между Канадой и пользователями США потребуется механизм обмена данными между регионами.
  2. Команде разработчиков потребуется управлять двумя отдельными службами Azure SignalR, каждая со своим доменом и строкой подключения.
  3. В случае регионального сбоя трафик необходимо переключить в другой регион.

Схема использования двух экземпляров Azure SignalR для обработки трафика из двух стран.

Использование георепликации

Благодаря новой функции георепликации Contoso теперь может установить реплику в Центральной Канаде, эффективно преодолевая описанные выше препятствия.

Схема использования одного экземпляра Azure SignalR с репликой для обработки трафика из двух стран или регионов.

Создание реплики SignalR

Чтобы создать реплику, перейдите на панель SignalR Реплики на портале Azure и нажмите Добавить, чтобы создать реплику. Он будет автоматически включен при создании.

Снимок экрана: создание реплики для Azure SignalR на портале.

После создания вы сможете просмотреть или изменить реплику на портале, щелкнув имя реплики.

Снимок экрана панели обзора ресурса реплики Azure SignalR.

Примечание.

  • Число реплик в настоящее время ограничено не более 8 на основной ресурс.

Цены и единица ресурсов

Каждая реплика имеет собственныйunit и autoscale settings.

Replica — это функция уровня Премиум службы Azure SignalR. Каждая реплика тарифицируется отдельно в зависимости от собственной единицы тарификации и исходящего трафика. Квота бесплатного сообщения также вычисляется отдельно.

В предыдущем примере Contoso добавила одну реплику в регионе "Центральная Канада". Компания Contoso будет платить за реплику в Центральной Канаде в соответствии с его единицей и сообщением в ценовой категории "Премиум".

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

Удаление реплики

После того как вы создали реплику для службы Azure SignalR, вы можете удалить её в любое время, если она вам больше не нужна.

Чтобы удалить реплику на портале Azure, сделайте следующее:

  1. Перейдите к службе Azure SignalR и выберите раздел Replicas. Щелкните реплику, которую вы хотите удалить.
  2. Нажмите кнопку "Удалить" на панели обзора реплики.

Общие сведения о работе реплики SignalR

На следующей схеме представлена краткая иллюстрация функциональных возможностей реплик SignalR:

Схема арки реплики Azure SignalR.

  1. Клиент ведет переговоры с сервером приложений и получает перенаправление в службу Azure SignalR. Затем она определяет полное доменное имя службы SignalR (FQDN) — contoso.service.signalr.net. Это полное доменное имя указывает на Traffic Manager, который возвращает каноническое имя (CNAME) ближайшего регионального экземпляра SignalR.
  2. С помощью этого CNAME клиент устанавливает подключение к региональному экземпляру (реплике).
  3. Две реплики синхронизируют данные друг с другом. При необходимости сообщения, отправленные на одну реплику, будут передаваться другим репликам.
  4. Если реплика не проходит проверку работоспособности, проводимую Диспетчером трафика (TM), TM исключает конечную точку сбойного экземпляра из процесса разрешения доменных имен. Дополнительные сведения см. в разделе " Устойчивость и аварийное восстановление"

Примечание.

  • В плоскости данных основная функция ресурса Azure SignalR идентична ее репликам.

Устойчивость и аварийное восстановление

Служба Azure SignalR использует диспетчер трафика для проверок работоспособности и разрешения DNS в отношении реплик. При нормальных обстоятельствах, когда все реплики работают правильно, клиенты будут направляться к ближайшей реплике. Например:

  • Клиенты, находящиеся рядом с eastus, будут перенаправлены на реплику, расположенную в eastus.
  • Аналогичным образом клиенты, находящиеся рядом с westus, будут направлены к реплике в westus.

В случае регионального сбоя в eastus (как показано ниже) диспетчер трафика обнаружит сбой проверки работоспособности в этом регионе. Затем DNS этой неисправной реплики будет исключена из результатов разрешения DNS диспетчера трафика. По истечении времени жизни записи DNS (TTL), составляющего 90 секунд, клиенты в eastus будут перенаправлены на подключение к реплике в westus.

Схема переключения при отказе реплики Azure SignalR.

После устранения проблемы eastus и подключения региона к сети проверка работоспособности завершится успешно. Клиенты в eastus затем снова будут перенаправлены на реплику в их регионе. Этот переход является гладким, так как подключенные клиенты не будут затронуты до тех пор, пока существующие подключения не будут закрыты.

Схема восстановления после аварийного переключения реплики Azure SignalR.

Этот процесс переключения при отказе и восстановления выполняется автоматически и не требует ручного вмешательства.

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

Примечание.

  • Этот механизм аварийного переключения предназначен для службы Azure SignalR. Региональные сбои сервера приложений выходят за рамки этого документа.

Отключить или включить конечную точку реплики

При настройке реплики можно включить или отключить её конечную точку. Если этот параметр отключён, при DNS-разрешении основного FQDN реплика не будет учитываться, и поэтому трафик не будет направляться к ней.

Схема настройки конечной точки реплики Azure SignalR.

Вы также можете включить или отключить конечную точку после ее создания. На вкладке реплик основного ресурса нажмите кнопку с многоточием справа от реплики и выберите Включить конечную точку или Отключить конечную точку:

Схема изменения конечной точки реплики Azure SignalR.

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

Эта функция также полезна для устранения региональных проблем.

Примечание.

  • Из-за кэша DNS может пройти несколько минут, прежде чем обновление DNS вступит в силу.
  • Существующие подключения остаются не затронутыми до тех пор, пока они не будут отключены.

Влияние добавления реплик на производительность

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

В частности, если ваше приложение обычно передает данные большим группам (размером >10) или одному соединению, влияние синхронизации на производительность едва заметно. Если вы обменяе сообщениями с небольшими группами (размером < 10) или отдельными пользователями, вы можете заметить немного больше затрат на синхронизацию.

Чтобы обеспечить эффективное переключение при отказе, рекомендуется настроить размер каждого модуля реплики так, чтобы он мог обрабатывать весь трафик. Кроме того, можно включить автоматическое масштабирование для управления этим.

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

Ненаследуемые и наследуемые конфигурации

Реплики наследуют большинство конфигураций из основного ресурса; однако некоторые параметры необходимо настроить непосредственно на репликах. Ниже приведен список этих конфигураций:

  1. SKU: каждая реплика имеет собственное имя SKU и размер единицы. Правила автомасштабирования для реплик должны быть настроены отдельно на основе отдельных метрик.
  2. Общие частные конечные точки доступа: хотя общие частные конечные точки доступа автоматически реплицируются на реплики, для целевых ресурсов Private Link требуются отдельные согласования. Чтобы добавить или удалить общие частные конечные точки, управляйте ими в основном ресурсе. Не включите реплику до утверждения общей частной конечной точки.
  3. Параметры назначения журнала. Если на репликах это не настроено, будут передаваться только журналы основного ресурса.
  4. Оповещения.

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