Шаблоны приложений и стратегии разработки для SQL Server на виртуальных машинах Azure

Применимо к:SQL Server на виртуальной машине Azure

Примечание.

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

Обзор

Выбор моделей приложений, которые вы будете использовать для ваших приложений на основе SQL Server в среде Azure, — это важное решение на этапе проектирования. Чтобы принять его, необходимо хорошо понимать, как SQL Server и все компоненты инфраструктуры Azure работают друг с другом. С помощью SQL Server в службах инфраструктуры Azure можно легко переносить существующие приложения SQL Server, созданные в Windows Server, в виртуальные машины в Azure, а также обслуживать и отслеживать их.

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

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

Технические соавторы: Луис Карлос Варгас Херринг (Luis Carlos Vargas Herring), Мадхан Арумугам Рамакришнан (Madhan Arumugam Ramakrishnan)

Технические рецензенты: Кори Сэндерс (Corey Sanders), Дрю МакДэниэл (Drew McDaniel), Нараян Аннамалай (Narayan Annamalai), Нир Машковски (Nir Mashkowski), Санджей Мишра (Sanjay Mishra), Сильвано Кориани (Silvano Coriani), Стефан Шакоу (Stefan Schackow), Тим Хики (Tim Hickey), Тим Виман (Tim Wieman), Синь Цзинь (Xin Jin).

Введение

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

Типичное n-уровневое приложение включает в себя уровень представления, бизнес-уровень и уровень данных.

Уровень	Description
Уровень представления	Уровень представления (веб-уровень, интерфейсный уровень) — это слой, на котором пользователи взаимодействуют с приложением.
Рабочий	Бизнес-уровень (средний уровень) — это слой, который уровни представления и данных используют для связи друг с другом. На этом слое реализована основная функциональность системы.
Данные	По существу, уровень данных представляет собой сервер, на котором хранятся данные приложения (например, сервер под управлением SQL Server).

Под слоями приложений подразумеваются логические группы функций и компонентов в приложении. Уровни же определяют физическое распределение функций и компонентов на отдельных физических серверах, компьютерах, в сетях или удаленных расположениях. Слои приложения могут быть размещены на одном физическом компьютере (на одном уровне), а могут быть распределены по разным компьютерам (n-уровневое размещение). Компоненты в каждом слое взаимодействуют с компонентами в других слоях с помощью четко определенных интерфейсов. В данной статье термин "уровень" относится к моделям физического распределения(пример: модели двухуровневого, трехуровневого и n-уровневого приложений). Модель двухуровневого приложения содержит два уровня приложений: сервер приложений и сервер базы данных. Между сервером приложений и сервером базы данных происходит прямой обмен данными. Сервер приложений содержит компоненты веб уровня и бизнес уровня. Модель трехуровневого приложения включает три уровня приложений: веб-сервер, сервер приложений (содержит уровень бизнес-логики и компоненты доступа к данным бизнес-уровня) и сервер базы данных. Обмен данными между веб-сервером и сервером базы данных происходит через сервер приложений. Подробные сведения о слоях и уровнях приложений см. в статье Microsoft Application Architecture Guide (Руководство по архитектуре приложений Майкрософт).

Прежде чем читать данную статью, изучите фундаментальные понятия SQL Server и Azure. Дополнительные сведения см. в статьях Электронная документация на Microsoft SQL Server и Приступая к работе с SQL Server на виртуальных машинах Azure, а также на веб-сайте Azure.com.

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

Выберите SQL Server на виртуальных машинах Azure в таких случаях:

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

• Требуется полная совместимость с SQL Server, так как необходимо переместить существующие приложения в Azure "как есть".

• Вам необходимо использовать возможности среды Azure, но База данных SQL Azure не поддерживает все функции, которые требуются приложению. Это могут быть указанные ниже возможности.

  • Размер базы данных: на момент обновления данной статьи, База данных SQL поддерживает базы данных размером до 1 ТБ. Если приложению требуется более 1 ТБ данных и вы не хотите реализовывать пользовательские решения сегментирования, рекомендуется использовать SQL Server в виртуальной машине Azure. Последние сведения см. в разделах Масштабирование баз данных SQL Azure, Модель приобретения на основе единиц DTU и Модель приобретения на основе виртуальных ядер (предварительная версия).
  • Соответствие требованиям HIPAA. Клиенты из сферы здравоохранения и независимые поставщики программного обеспечения могут предпочесть SQL Server на виртуальных машинах Azure вместо Базы данных SQL Azure, так как вариант с SQL Server на виртуальной машине Azure оговорен в соглашении с бизнес-партнерами HIPAA. Сведения о соответствии требованиям см. в центре управления безопасностью Microsoft Azure — раздел "Compliance" (Соответствие требованиям).
  • Функции уровня экземпляра. В настоящее время База данных SQL не поддерживает функции, которые находятся вне базы данных (например, связанные серверы, задания агента, FileStream, Service Broker и т. д.). Дополнительные сведения см. в статье Общие ограничения и рекомендации для Базы данных SQL Azure.

Модель простого одноуровневого приложения: одна виртуальная машина

При использовании этой модели приложения выполняется развертывание приложения SQL Server и базы данных на автономной виртуальной машине в Azure. Эта же виртуальная машина содержит клиентское или веб-приложение, бизнес-компоненты, слой доступа к данным и сервер базы данных. Код уровня представления, бизнес-уровня и уровня доступа к данным логически разделен, но физически размещен на одном и том же компьютере сервера. Большинство клиентов начинает работу с этой модели приложения, а затем выполняет горизонтальное увеличение масштаба, добавляя дополнительные веб-роли или виртуальные машины в систему.

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

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

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

Развертывая бизнес-слой (бизнес-логику и компоненты доступа к данным) на одном физическом уровне со слоем представления, можно добиться максимальной производительности приложений, если только не требуется использовать отдельный уровень из соображений масштабирования или безопасности.

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

Модель простого трехуровневого приложения: несколько виртуальных машин

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

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

• Необходимо выполнить миграцию сложных приложений базы данных на виртуальные машины Azure.
• Необходимо, чтобы разные уровни приложения были размещены в разных регионах. Например, у вас могут быть общие базы данных, развернутые в нескольких регионах с целью составления отчетов.
• Необходимо переместить корпоративные приложения из локальных виртуализированных платформ на виртуальные машины Azure. Подробные сведения о корпоративных приложениях см. в статье What is an Enterprise Application? (Основные сведения о корпоративных приложениях).
• Необходимо за небольшое время подготовить к работе среду разработки и тестовую среду.
• Необходимо выполнить нагрузочное тестирование для изменяющихся уровней рабочих нагрузок, но при этом вы не хотите постоянно владеть большим количеством компьютеров и обслуживать их.

На схеме ниже показано, как разместить простое трехуровневое приложение в Azure, помещая каждый уровень приложения в отдельную виртуальную машину.

В этой модели приложения на каждом уровне используется только одна виртуальная машина. Если у вас есть несколько виртуальных машин в Azure, мы рекомендуем настроить виртуальную сеть. Виртуальная сеть Azure создает надежный периметр безопасности и позволяет виртуальным машинам взаимодействовать друг с другом через частный IP-адрес. Кроме того, необходимо всегда проверять, что все подключения к Интернету ведут только на уровень представления. При использовании данной модели приложения для контроля доступа управляйте правилами группы безопасности сети. Дополнительные сведения см. в статье Открытие портов для виртуальной машины в Azure с помощью портала Azure.

На схеме протоколы IP — это протоколы TCP, UDP, HTTP или HTTPS.

Примечание.

Настройка виртуальной сети в Azure выполняется бесплатно. Тем не менее с вас будет взиматься плата за VPN-шлюз, подключаемый к локальной среде. Размер платы зависят от количества времени, на которое это соединение предоставлено и в течение которого оно доступно.

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

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

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

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

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

Рекомендации для моделей двух-, трех- и n-уровневых приложений с несколькими виртуальными машинами на одном уровне

Рекомендуется разместить виртуальные машины, принадлежащие одному и тому же уровню, в той же облачной службе и в той же группе доступности. Например, вы можете поместить набор веб-серверов в облачную службу CloudService1 и группу доступности AvailabilitySet1, а набор серверов баз данных — в облачную службу CloudService2 и группу доступности AvailabilitySet2. Группа доступности в Azure позволяет помещать узлы с высоким уровнем доступности в отдельные домены сбоя и обновления.

Чтобы использовать несколько экземпляров виртуальных машин какого-либо уровня, необходимо настроить балансировщик нагрузки Azure между уровнями приложения. Чтобы настроить Load Balancer на каждом уровне, создайте конечную точку с балансировкой нагрузки на виртуальных машинах каждого уровня отдельно. Для конкретного уровня сначала создайте виртуальные машины в той же облачной службе. В результате они гарантированно будут иметь одинаковый общедоступный виртуальный IP-адрес. Затем создайте конечную точку на одной из виртуальных машин на этом уровне. Далее для балансировки нагрузки назначьте эту конечную точку другим виртуальным машинам на этом уровне. После создания набора с балансировкой нагрузки трафик будет распределяться по нескольким виртуальным машинам, а балансировщик нагрузки сможет определять, какой узел подключать при сбое внутреннего узла виртуальных машин. Например, наличие нескольких экземпляров веб-серверов за балансировщиком нагрузки обеспечивает высокий уровень доступности уровня представления.

Рекомендуется всегда проверять, что все подключения к Интернету сначала ведут на уровень представления. Уровень представления получает доступ к бизнес-уровню, а затем бизнес-уровень получает доступ к уровню данных. Дополнительные сведения о том, как разрешить доступ к уровню представления данных см. в статье Открытие портов для виртуальной машины в Azure с помощью портала Azure.

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

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

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

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

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

• Необходимо переместить корпоративные приложения из локальных виртуализированных платформ на виртуальные машины Azure.
• Из-за сложности приложения необходимо распределить компоненты сервера приложений по нескольким виртуальным машинам.
• Необходимо переместить локальные бизнес-приложения с серьезной нагрузкой бизнес-логики на виртуальные машины Azure. Бизнес-приложения — это набор критически важных компьютерных приложений, необходимых для работы предприятия. Например, это могут быть приложения для учета, отдела кадров, расчета заработной платы, управления логистическими цепочками и планирования ресурсов.
• Необходимо за небольшое время подготовить к работе среду разработки и тестовую среду.
• Необходимо выполнить нагрузочное тестирование для изменяющихся уровней рабочих нагрузок, но при этом вы не хотите постоянно владеть большим количеством компьютеров и обслуживать их.
• Необходимо владеть инфраструктурой, масштаб которой можно увеличивать или уменьшать по требованию.

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

Модель двух- и трехуровневых приложений с горизонтальным масштабированием уровня представления и бизнес-уровня и HADR

В этой модели приложения выполняется развертывание двух- или трехуровневого приложение баз данных на виртуальных машинах Azure. При этом компоненты уровня представления (веб-сервер) и бизнес-уровня (сервер приложений) распределяются по нескольким виртуальным машинам. Кроме того, вы можете реализовать решения для обеспечения высокой доступности и аварийного восстановления (HADR) баз данных на виртуальных машинах Azure.

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

• Необходимо переместить корпоративные приложения с локальных виртуализированных платформ в Azure путем реализации возможностей обеспечения высокого уровня доступности SQL Server и аварийного восстановления.
• Необходимо выполнять горизонтальное увеличение масштаба уровня представления и бизнес-уровня из-за увеличения объема входящих клиентских запросов и сложности приложения.
• Необходимо за небольшое время подготовить к работе среду разработки и тестовую среду.
• Необходимо выполнить нагрузочное тестирование для изменяющихся уровней рабочих нагрузок, но при этом вы не хотите постоянно владеть большим количеством компьютеров и обслуживать их.
• Необходимо владеть инфраструктурой, масштаб которой можно увеличивать или уменьшать по требованию.

На схеме ниже показан локальный сценарий и облачное решение для него. В этом сценарии выполняется горизонтальное увеличение масштаба компонентов уровня представления и бизнес-уровня на нескольких виртуальных машинах в Azure. Кроме того, вы можете реализовать методы высокого уровня доступности и аварийного восстановления (HADR) для баз данных SQL Server в Azure.

Если несколько копий приложения работают на разных виртуальных машинах, то для них выполняется балансировка нагрузки по обработке запросов. При наличии нескольких виртуальных машин необходимо обеспечить доступность всех виртуальных машин и их одновременную работу. Если вы настроите функцию балансировки нагрузки, то Azure Load Balancer будет отслеживать работоспособность виртуальных машин и соответствующим образом направлять входящие вызовы в полноценно функционирующие узлы виртуальных машин. Сведения о настройке балансировки нагрузки виртуальных машин см. в статье Балансировка нагрузки для служб инфраструктуры Azure. При наличии нескольких экземпляров веб-серверов и серверов приложений за балансировщиком нагрузки обеспечивает высокий уровень доступности уровня представления и бизнес-уровня.

Рекомендации для моделей приложений, требующих HADR SQL

Если вы устанавливаете решения по обеспечению высокого уровня доступности и аварийного восстановления SQL Server на виртуальных машинах Azure, то вам также необходимо настроить виртуальную сеть для ваших виртуальных машин с помощью виртуальной сети Azure. Виртуальные машины в виртуальной сети будут иметь постоянный частный IP-адрес даже после простоя службы. Таким образом, можно избежать времени обновления, необходимого для разрешения имен DNS. Кроме того, виртуальная сеть позволяет расширить локальную сеть в Azure и создает надежный периметр безопасности. Например, если для приложения действуют ограничения корпоративного домена (такие как аутентификация Windows или Active Directory), то необходимо настроить виртуальную сеть Azure.

Большинство клиентов, выполняющих рабочий код в Azure, хранят и основную, и дополнительную реплики в Azure.

Подробные сведения и учебники по обеспечению высокой доступности и аварийного восстановления см. в статье Высокая доступность и аварийное восстановление для SQL Server на виртуальных машинах Azure.

Модель 2- и 3-уровневых приложений, использующих виртуальные машины и облачные службы Azure

В этой модели приложения выполняется развертывание двух- или трехуровневого приложения в Azure с помощью облачных служб Azure (веб и рабочая роли — платформа как услуга (PaaS)) и виртуальных машин Azure (инфраструктура как услуга (IaaS)). Вариант, когда облачные службы Azure используются для уровня представления или бизнес-уровня, а SQL Server на виртуальных машинах Azure — для уровня данных, хорошо подходит для большинства приложений, работающих в Azure. Причина состоит в том, что наличие вычислительной операции, работающей в облачных службах, упрощает управление, развертывание, отслеживание и горизонтальное масштабирование.

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

В итоге, если вы не хотите владеть обширными административными задачами для уровня презентации или бизнеса, а ваше приложение не требует сложной настройки программного обеспечения или операционной системы, используйте Azure Облачные службы. Если База данных SQL Azure не поддерживает все необходимые функции, то для уровня данных используйте SQL Server на виртуальной машине Azure. Выполняя приложения в облачных службах Azure и храня данных на виртуальных машинах Azure, можно сочетать преимущества обеих служб. Подробное сравнение см. в разделе Сравнение стратегий веб-разработки в Azure данной статьи.

В этой модели приложения уровень представления включает веб-роль, представляющую собой компонент облачных служб, который работает в среде выполнения Azure. Этот компонент настроен для программирования веб-приложений с поддержкой IIS и ASP.NET. Бизнес-уровень или внутренний уровень включает рабочую роль,представляющую собой компонент облачных служб, который работает в среде выполнения Azure. Этот компонент удобно использовать для общей разработки. Кроме того, он может выполнять фоновую обработку для веб-роли. Уровень базы данных находится на виртуальной машине SQL Server в Azure. Обмен данными между уровнем представления и уровнем базы данных происходит напрямую или через бизнес-уровень, представляющий собой компоненты рабочей роли.

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

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

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

Как показано на схеме, балансировщик нагрузки Azure распределяет трафик по нескольким виртуальным машинам, а также определяет, к какому веб-серверу или серверу приложений необходимо подключиться. Наличие нескольких экземпляров веб-серверов и серверов приложений за балансировщиком нагрузки обеспечивает высокий уровень доступности уровня представления и бизнес-уровня. Дополнительные сведения см. в разделе Рекомендации для моделей приложений, требующих HADR SQL.

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

Модель с виртуальными машинами Azure, Базой данных SQL Azure и Службой приложений Azure (веб-приложениями)

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

В этой модели приложения выполняется развертывание приложения базы данных в Azure путем размещения уровня представления и бизнес-уровня в одной виртуальной машине и получения доступа к базе данных на серверах Базы данных SQL Azure. Уровень представления можно реализовать с помощью традиционных веб-решений на основе IIS. Кроме того, вы можете объединить уровень представления и бизнес-уровень, используя службу приложений Azure.

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

• У вас уже есть сервер Базы данных SQL, настроенный в Azure, и необходимо быстро протестировать приложение.
• Необходимо протестировать возможности среды Azure.
• Необходимо за небольшое время подготовить к работе среду разработки и тестовую среду.
• Компоненты бизнес-логики и доступа к данным могут быть автономными и размещаться в веб-приложении.

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

Если вы решили объединить веб-уровень и уровень приложений с помощью веб-приложений Azure, мы рекомендуем сохранить средний уровень или уровень приложения в виде библиотеки динамической компоновки (DLL) в контексте веб-приложения.

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

Модель n-уровневого гибридного приложения

В модели n-уровневого гибридного приложения выполняется реализация приложения на нескольких уровнях, распределенных между локальной средой и Azure. Таким образом, вы создаете гибкую и многократно используемую гибридную систему, которую можно изменить и в которую можно добавить определенный уровень без изменения остальных уровней. Для расширения корпоративной сети в облако используйте службу виртуальной сети Azure .

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

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

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

В Azure можно использовать идентификатор Microsoft Entra (ранее Azure Active Directory) для управления удостоверениями и доступом или интегрировать существующую локальная служба Active Directory с идентификатором Microsoft Entra. Как показано на схеме, компоненты бизнес-уровня могут проходить проверку подлинности в нескольких источниках данных, включая SQL Server на виртуальных машинах Azure через частный внутренний IP-адрес, локальный СЕРВЕР SQL Server через Azure виртуальная сеть или База данных SQL Azure с помощью поставщика данных платформа .NET Framework Технологии. На этой схеме База данных SQL Azure представляет собой дополнительную службу хранилища данных.

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

1. Определите корпоративные приложения базы данных, которые необходимо переместить в облако, с помощью Microsoft Assessment and Planning (MAP) Toolkit. MAP Toolkit собирает данные инвентаризации и производительности с компьютеров, которые планируется виртуализировать, и предоставляет рекомендации по планированию емкости и оценки.

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

3. Настройте сетевое соединение между корпоративной локальной сетью и виртуальной сетью Azure. Чтобы настроить соединение между корпоративной локальной сетью и виртуальной машиной в Azure, воспользуйтесь одним из двух указанных ниже методов.

   1. Установите соединение между локальной сетью и Azure посредством общедоступных конечных точек на виртуальной машине в Azure. Этот метод обеспечивает простую настройку и позволяет использовать проверку подлинности SQL Server на виртуальной машине. Кроме того, настройте правила групп безопасности сети для контроля общего трафика на виртуальной машине. Дополнительные сведения см. в статье Открытие портов для виртуальной машины в Azure с помощью портала Azure.

   2. Установите соединение между локальной сетью и Azure с помощью туннеля виртуальной частной сети (VPN). Этот метод позволяет распространить политики домена на виртуальную машину в Azure. Кроме того, можно настроить правила брандмауэра и использовать проверку подлинности Windows на виртуальной машине. Сейчас Azure поддерживает безопасные подключения VPN типа "сеть-сеть" и VPN типа "точка-сеть".

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

      Сведения о том, как подключиться к серверу SQL Server в Azure, см. в статье Подключение к виртуальной машине SQL Server в Azure.

4. Настройте запланированные задания и предупреждения, которые создают резервные копии локальных данных на диске виртуальной машины в Azure. Дополнительные сведения см. в статьях Резервное копирование и восстановление SQL Server с помощью хранилища BLOB-объектов Azure и Резервное копирование и восстановление SQL Server на виртуальных машинах Azure.

5. В зависимости от потребностей приложения можно реализовать один из следующих трех распространенных сценариев:

   1. Вы можете разместить веб-сервер, сервер приложений и неконфиденциальные данные на сервере базы данных в Azure, а конфиденциальные данные — в локальной сети.
   2. Вы можете разместить веб-сервер и сервер приложений в локальной сети, а сервер базы данных — на виртуальной машине в Azure.
   3. Вы можете разместить сервер базы данных, веб-сервер и сервер приложений в локальной сети, а реплики базы данных — на виртуальных машинах в Azure. Этот параметр позволяет локальным веб-серверам или приложениям отчетности получать доступ к репликам базы данных в Azure. Таким образом, можно добиться снижения рабочей нагрузки в локальной базе данных. Мы рекомендуем использовать этот сценарий для серьезных рабочих нагрузок и целей разработки. Сведения о создании реплика базы данных в Azure см. в разделе "Группы доступности AlwaysOn" в группах доступности и аварийном восстановлении для SQL Server в Azure Виртуальные машины.

Сравнение стратегий веб-разработки в Azure

Для реализации и развертывания многоуровневого приложения на основе SQL Server в Azure можно использовать один из указанных ниже двух методов программирования.

• Настройте традиционный веб-сервер (IIS) в Azure и доступ к базам данных в SQL Server на виртуальных машинах Azure.
• Реализуйте и разверните облачную службу в Azure. Затем убедитесь, что эта облачная служба имеет доступ к базам данных в SQL Server на виртуальных машинах Azure. Облачная служба может включать несколько веб- и рабочих ролей.

В таблице ниже представлено сравнение традиционной веб-разработки (с облачными службами Azure и веб-приложениями Azure) с SQL Server на виртуальных машинах Azure. В таблице имеются сведения о веб-приложениях Azure, так как SQL Server можно использовать на виртуальной машине Azure в качестве источника данных для веб-приложений Azure через его общедоступный виртуальный IP-адрес или DNS-имя.

	Традиционная веб-разработка в виртуальных машинах Azure	Облачные службы в Azure	Размещение в Интернете с помощью веб-приложений Azure
Миграция приложений из локальных систем	Существующие приложения как есть.	Приложениям необходимы веб-роли и рабочие роли.	Вариант "Существующие приложения как есть" подходит для независимых веб-приложений и веб-служб, которым требуется быстрая масштабируемость.
Разработка и развертывание	Visual Studio, WebMatrix, Visual Web Developer, WebDeploy, FTP, TFS, диспетчер IIS, PowerShell.	Visual Studio Azure SDK, TFS, PowerShell. Каждая облачная служба имеет две среды, в которых можно развернуть пакет и конфигурацию службы: промежуточную и рабочую. Можно развернуть облачную службу в промежуточной среде, чтобы проверить ее работу перед переносом в производственную среду.	Visual Studio, WebMatrix, Visual Web Developer, FTP, GIT, BitBucket, CodePlex, DropBox, GitHub, Mercurial, TFS, веб-развертывание, PowerShell.
Администрирование и настройка	Вы несете ответственность за выполнение административных задач для приложений, данных, правил брандмауэра, виртуальной сети и операционной системы.	Вы несете ответственность за выполнение административных задач для приложений, данных, правил брандмауэра и виртуальной сети.	Вы несете ответственность за выполнение административных задач только для приложений и данных.
Высокая доступность и аварийное восстановление (HADR)	Мы рекомендуем размещать виртуальные машины в одной группе доступности и в одной облачной службе. Благодаря размещению виртуальных машин в одной группе доступности можно помещать узлы с высоким уровнем доступности в отдельные домены сбоя и обновления. Аналогично, размещение виртуальных машин в одной и той же облачной службе позволяет выполнять балансировку нагрузки, при этом виртуальные машины могут обмениваться данными непосредственно друг с другом по локальной сети в рамках центра обработки данных Azure. Чтобы избежать простоев, вам нужно реализовать решения по обеспечению высокого уровня доступности и аварийного восстановления SQL Server на виртуальных машинах Azure. Сведения о поддерживаемых технологиях HADR см. в статье Высокая доступность и аварийное восстановление для SQL Server на виртуальных машинах Azure. Вы отвечаете за архивацию своих данных и приложения. Azure может перемещать ваши виртуальные машины в случае сбоя хост-компьютера в центре обработки данных из-за проблем с оборудованием. Кроме того, возможны запланированные простои ваших виртуальных машин при установке обновлений для системы безопасности и обновлений программного обеспечения на хост-компьютер. Поэтому для обеспечения постоянной доступности мы рекомендуем поддерживать по крайней мере две виртуальные машины на каждом уровне приложения. Azure не обеспечивает выполнение соглашений об уровне обслуживания при использовании одной виртуальной машины.	Azure управляет сбоями, вызванными используемым оборудованием или операционной системой. Для обеспечения высокого уровня доступности вашего приложения мы рекомендуем реализовать несколько экземпляров веб- и рабочих ролей. Чтобы получить дополнительные сведения, ознакомьтесь с соглашением об уровне обслуживания для облачных служб, виртуальных машин и виртуальной сети. Вы отвечаете за архивацию своих данных и приложения. При использовании баз данных, находящихся в базе данных SQL Server на виртуальной машине Azure, вы отвечаете за реализацию решения, которое обеспечивает высокую доступность и аварийное восстановление во избежание простоев. Сведения о поддерживаемых технологиях HADR см. в статье "Высокая доступность и аварийное восстановление для SQL Server на виртуальных машинах Azure". Зеркальное отображение базы данных SQL Server: используйте с облачными службами Azure (веб-роли и рабочие роли). Виртуальные машины SQL Server и проект облачной службы могут находиться в одной и той же виртуальной сети Azure. Если виртуальная машина SQL Server не находится в той же виртуальной сети, необходимо создать псевдоним SQL Server для маршрутизации данных к экземпляру SQL Server. Кроме того, имя псевдонима должно соответствовать имени SQL Server.	Высокий уровень доступности наследуется от рабочих ролей Azure, Хранилище BLOB-объектов Azure и База данных SQL Azure. Например, служба хранилища Azure поддерживает три реплики для всех данных больших двоичных объектов, таблиц и очереди. В любой момент времени База данных SQL Azure хранит три реплики рабочих данных: одну основную и две дополнительных. Дополнительные сведения см. в статьях Документация по хранилищу и Что такое База данных SQL Azure. При использовании SQL Server на виртуальной машине Azure в качестве источника данных для веб-приложений Azure следует иметь в виду, что веб-приложения Azure не поддерживают виртуальную сеть Azure. Другими словами, все соединения веб-приложений Azure с виртуальными машинами SQL Server в Azure должны проходить через общедоступные конечные точки виртуальных машин. Это может привести к некоторым ограничениям для сценариев обеспечения высокого уровня доступности и аварийного восстановления. Например, клиентское приложение в веб-приложениях Azure, подключающееся к виртуальной машине SQL Server с зеркальным отображением базы данных, не сможет подключиться к новому основному серверу, так как для зеркального отображения базы данных требуется настроить виртуальную сеть Azure между виртуальными машинами SQL Server в Azure. Таким образом, использование зеркального отображения базы данных SQL Server совместно с веб-приложениями Azure не поддерживается. Группы доступности Sql Server AlwaysOn. Вы можете настроить группы доступности AlwaysOn при использовании Azure веб-приложения с виртуальными машинами SQL Server в Azure. Но необходимо настроить прослушиватель группы доступности AlwaysOn для маршрутизации связи в основной реплика через общедоступные конечные точки с балансировкой нагрузки.
Возможность распределенного подключения	Виртуальную сеть Azure можно использовать для локального подключения.	Виртуальную сеть Azure можно использовать для локального подключения.	Виртуальная сеть Azure поддерживается.
Масштабируемость	Разворачивание доступно путем увеличения размера виртуальных машин или добавления дополнительных дисков. Дополнительные сведения о размерах виртуальных машин см. в разделе Размеры виртуальных машин в Azure. Для сервера базы данных: горизонтальное масштабирование доступно с помощью методов секционирования баз данных и групп доступности AlwaysOn SQL Server. Для тяжелых рабочих нагрузок чтения можно использовать группы доступности AlwaysOn на нескольких дополнительных узлах, а также Репликация SQL Server. Для серьезных рабочих нагрузок записи можно реализовать горизонтальное секционирование данных на нескольких физических серверах для обеспечения горизонтального масштабирования приложений. Кроме того, можно реализовать горизонтальное масштабирование, используя SQL Server с маршрутизацией, зависящей от данных. При использовании технологии маршрутизации, зависящей от данных, необходимо реализовать механизм секционирования в клиентском приложении (обычно в слое бизнес-уровня) для маршрутизации запросов к базе данных на несколько узлов SQL Server. Бизнес-уровень содержит сопоставления, определяющие порядок секционирования данных и то, какой узел содержит данные. Вы можете масштабировать приложения, запускающие виртуальные машины. Дополнительные сведения см. в статье Автомасштабирование облачной службы. Важное примечание. Благодаря функции автомасштабирования в Azure можно автоматически увеличивать или уменьшать размер виртуальных машин, используемых приложением. Эта функция гарантирует, что во время периодов пика активности на работу конечных пользователей не будет оказано отрицательного влияния, а в периоды низкого спроса работа виртуальных машин будет завершена. Рекомендуется не задать параметр Автомасштабирования для облачной службы, если он включает виртуальные машины SQL Server. Причина в том, что функция Автомасштабирования позволяет Azure включить виртуальную машину, если использование ЦП в этой виртуальной машине выше порогового значения, и отключить виртуальную машину, когда загрузка ЦП снижается, чем она. Функция автомасштабирования подходит для приложений без учета состояния, например для веб-серверов, где все виртуальные машины могут управлять рабочей нагрузкой без учета предыдущего состояния. Тем не менее, функция автомасштабирования не подходит для приложений с отслеживанием состояния, например для SQL Server, когда только один экземпляр разрешает запись в базу данных.	Разворачивание можно выполнять с помощью нескольких веб-ролей и рабочих ролей. Дополнительные сведения о размерах виртуальных машин для веб-ролей и рабочих ролей см. в статье Размеры для облачных служб. При использовании облачных служб можно определить несколько ролей для распределения обработки и гибкого масштабирования приложения. Все облачные службы включают одну или несколько веб-ролей или рабочих ролей, каждая из которых имеет собственные файлы и конфигурацию приложения. Вы можете увеличивать масштаб облачной службы за счет увеличения количества экземпляров роли (виртуальных машин), развернутых для роли, или уменьшать его за счет уменьшения количества экземпляров роли. Дополнительные сведения см. в статье Стоит ли сделать выбор в пользу облачных служб или чего-то другого? Вы можете выполнять горизонтальное масштабирование благодаря встроенной поддержке высокого уровня доступности Azure в соответствии с соглашением об уровне обслуживания для облачных служб, виртуальных машин и виртуальной сети и балансировщика нагрузки. Для многоуровневого приложения мы рекомендуем подключить приложение веб-ролей и рабочих ролей к виртуальным машинам сервера базы данных через виртуальную сеть Azure. Кроме того, Azure обеспечивает балансировку нагрузки для виртуальных машин в рамках одной облачной службы, распределяя запросы пользователей между ними. Виртуальные машины, подключенные таким образом, могут обмениваться данными напрямую друг с другом по локальной сети в центре обработки данных Azure. На портале Azure можно настроить автомасштабирование, а также запланировать время масштабирования. Дополнительные сведения см. в разделе Как настроить автомасштабирование для облачной службы на портале.	Увеличение и уменьшение масштаба: вы можете увеличивать или уменьшать размер экземпляра (виртуальной машины), зарезервированный для веб-сайта. Горизонтальное увеличение масштаба: вы можете добавить дополнительные зарезервированные экземпляры (виртуальные машины) для своего веб-сайта. На портале можно настроить автомасштабирование, а также запланировать время масштабирования. Дополнительные сведения см. в статье Увеличение масштаба приложения в Azure.

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

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

Дополнительные сведения о работе SQL Server на виртуальных машинах Azure см. в статье Обзор SQL Server на виртуальных машинах Azure.