Поделиться через

Географическое распределенное масштабирование с помощью сред службы приложений

  • Статья

Обзор

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

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

Например, предположим, что приложение, работающее в конфигурации среды службы приложений, было проверено для обработки запросов 20K в секунду (RPS). Если требуемая пиковая нагрузка составляет 100K RPS, можно создать пять (5) сред службы приложений и настроить их, чтобы приложение может обрабатывать максимальную прогнозированную нагрузку.

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

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

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

Схема концептуальной архитектуры геораспределаемой службы приложений с помощью диспетчера трафика.

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

Планирование топологии

Прежде чем создавать распределенное приложение, полезно заранее получить немного информации.

  • Личный домен для приложения: Что такое имя личного домена, которое клиенты будут использовать для доступа к приложению? Для образца приложения используется пользовательское доменное имя www.asabuludemo.com.
  • Домен диспетчера трафика: При создании профиля диспетчера трафика Azure выберите доменное имя. Это имя будет объединено с суффиксом trafficmanager.net для регистрации записи домена, управляемой диспетчером трафика. Для примера приложения выбрано имя scalable-ase-demo. Полное доменное имя, управляемое диспетчером трафика, — это scalable-ase-demo.trafficmanager.net.
  • Стратегия масштабирования объема приложения: Будет ли приложение распределено между несколькими средами службы приложений в одном регионе? Несколько регионов? Комбинация обоих подходов? Основываясь на ожиданиях того, откуда будет поступать трафик клиентов, и насколько хорошо остальная часть поддерживающей инфраструктуры приложения может масштабироваться. Например, с приложением без состояния 100% можно добиться масштабирования с помощью сочетания множества сред службы приложений в каждом регионе Azure, умноженных на среды службы приложений, развернутые во многих регионах Azure. С более чем 15 доступных для выбора глобальных регионов Azure клиенты могут действительно создавать мировую гипермасштабируемую инфраструктуру приложений. Для примера приложения, используемого для этой статьи, в одном регионе Azure (южная часть США) были созданы три среды службы приложений.
  • Соглашение об именовании для сред службы приложений: Для каждой среды службы приложений требуется уникальное имя. Помимо одной или двух сред службы приложений, полезно иметь соглашение об именовании, чтобы помочь определить каждую среду службы приложений. Для примера приложения использовалось простое соглашение об именовании. Имена трех сред службы приложений : fe1ase, fe2ase и fe3ase.
  • Соглашение об именовании для приложений: Так как будет развернуто несколько экземпляров приложения, для каждого экземпляра развернутого приложения требуется имя. Одна малоизвестная, но удобная функция сред службы приложений заключается в том, что одно и то же имя приложения можно использовать в нескольких средах службы приложений. Так как каждая среда службы приложений имеет уникальный суффикс домена, разработчики могут повторно использовать то же имя приложения в каждой среде. Например, разработчик может иметь следующие приложения: myapp.foo1.p.azurewebsites.net, myapp.foo2.p.azurewebsites.net, myapp.foo3.p.azurewebsites.net и т. д. Однако для примера приложения каждый экземпляр приложения также имеет уникальное имя. Используемые имена экземпляров приложения: webfrontend1, webfrontend2 и webfrontend3.

Настройка профиля диспетчера трафика

После развертывания нескольких экземпляров приложения в нескольких средах службы приложений отдельные экземпляры приложений можно зарегистрировать в диспетчере трафика. Для тестового приложения требуется профиль диспетчера трафика для scalable-ase-demo.trafficmanager.net, который может направлять клиентов в любой из следующих развернутых экземпляров приложений.

  • webfrontend1.fe1ase.p.azurewebsites.net: Экземпляр примера приложения, развернутого в первой среде службы приложений.
  • webfrontend2.fe2ase.p.azurewebsites.net: Экземпляр примера приложения, развернутого во второй среде службы приложений.
  • webfrontend3.fe3ase.p.azurewebsites.net: Экземпляр примера приложения, развернутого в третьей среде службы приложений.

Самый простой способ зарегистрировать несколько конечных точек Службы приложений Azure, работающих в одном регионе Azure, — с поддержкой PowerShell Azure Resource Manager Traffic Manager.

Первым шагом является создание профиля диспетчера трафика Azure. В приведенном ниже коде показано, как создан профиль для примера приложения:

$profile = New-AzTrafficManagerProfile –Name scalableasedemo -ResourceGroupName yourRGNameHere -TrafficRoutingMethod Weighted -RelativeDnsName scalable-ase-demo -Ttl 30 -MonitorProtocol HTTP -MonitorPort 80 -MonitorPath "/"

Обратите внимание, что параметру RelativeDnsName было задано значение scalable-ase-demo. Этот параметр приводит к созданию и сопоставлению доменного имени scalable-ase-demo.trafficmanager.net с профилем диспетчера трафика.

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

При создании профиля каждое приложение добавляется в профиль в качестве родной конечной точки Azure. Следующий код получает ссылку на каждое интерфейсное веб-приложение. Затем он добавляет каждое приложение в качестве конечной точки диспетчера трафика через параметр TargetResourceId .

$webapp1 = Get-AzWebApp -Name webfrontend1
Add-AzTrafficManagerEndpointConfig –EndpointName webfrontend1 –TrafficManagerProfile $profile –Type AzureEndpoints -TargetResourceId $webapp1.Id –EndpointStatus Enabled –Weight 10

$webapp2 = Get-AzWebApp -Name webfrontend2
Add-AzTrafficManagerEndpointConfig –EndpointName webfrontend2 –TrafficManagerProfile $profile –Type AzureEndpoints -TargetResourceId $webapp2.Id –EndpointStatus Enabled –Weight 10

$webapp3 = Get-AzWebApp -Name webfrontend3
Add-AzTrafficManagerEndpointConfig –EndpointName webfrontend3 –TrafficManagerProfile $profile –Type AzureEndpoints -TargetResourceId $webapp3.Id –EndpointStatus Enabled –Weight 10

Set-AzTrafficManagerProfile –TrafficManagerProfile $profile

Обратите внимание, что существует один вызов Add-AzureTrafficManagerEndpointConfig для каждого отдельного экземпляра приложения. Параметр TargetResourceId в каждой команде PowerShell ссылается на один из трех развернутых экземпляров приложения. Профиль диспетчера трафика распределяет нагрузку по всем трем конечным точкам, зарегистрированным в профиле.

Все три конечные точки используют одно и то же значение (10) для параметра Weight . Эта ситуация приводит к тому, что диспетчер трафика распределяет запросы клиентов по всем трем экземплярам приложения относительно равномерно.

Указание личного домена приложения на домен диспетчера трафика

Последним шагом необходимо указать пользовательский домен приложения на домен диспетчера трафика. Для приложения-образца наведите указатель на www.asabuludemo.comscalable-ase-demo.trafficmanager.net. Выполните этот шаг с регистратором доменов, который управляет личным доменом.

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

Снимок экрана: настройка записи CNAME в DNS.

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

В этом примере используется www.asabuludemo.comличный домен, и каждый экземпляр приложения имеет личный домен, связанный с ним.

Снимок экрана: настройка личного домена службы приложений.

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

Пробная попытка распределенной топологии

Конечным результатом конфигурации диспетчера трафика и DNS является то, что запросы для www.asabuludemo.com будут проходить через следующую последовательность:

  1. Браузер или устройство осуществит запрос DNS для www.asabuludemo.com
  2. Запись CNAME в регистраторе домена приводит к тому, что запрос DNS перенаправляется в Azure Traffic Manager.
  3. Запрос DNS выполняется для scalable-ase-demo.trafficmanager.net на одном из DNS-серверов диспетчера трафика Azure.
  4. На основе политики балансировки нагрузки, указанной ранее в параметре TrafficRoutingMethod , диспетчер трафика выбирает одну из настроенных конечных точек. Затем он возвращает полное доменное имя этой конечной точки браузеру или устройству.
  5. Так как полное доменное имя конечной точки является URL-адресом экземпляра приложения, работающего в среде службы приложений, браузер или устройство попросит DNS-сервер Microsoft Azure разрешить полное доменное имя в IP-адрес.
  6. Браузер или устройство отправит запрос HTTP/S на IP-адрес.
  7. Запрос будет поступать в один из экземпляров приложения, работающих в одной из сред службы приложений.

На рисунке консоли ниже показан поиск DNS для пользовательского домена приложения-примера. Он успешно указывает на экземпляр приложения, который работает в одной из трех образцов сред службы приложений (в данном случае это вторая из трех сред службы приложений):

Снимок экрана: результат поиска DNS.

Документация по поддержке Диспетчера трафика Azure Resource Manager в PowerShell.

Примечание.

Если вы хотите приступить к работе со службой приложений Azure перед регистрацией в учетной записи Azure, перейдите в раздел "Пробная служба приложений", где можно сразу же создать кратковременное начальное веб-приложение в службе приложений. Не требуются кредитные карты; никаких обязательств.