На примере этой эталонной архитектуры показано, как развернуть виртуальные машины и виртуальную сеть, настроенные для N-уровневого приложения с помощью Apache Cassandra на платформе Linux для уровня данных.
Архитектура
Скачайте файл Visio для этой архитектуры.
Рабочий процесс
Архитектура состоит из следующих компонентов.
Общие
Группа ресурсов. Группы ресурсов используются для группирования ресурсов Azure по времени существования, владельцу и другим критериям для управления.
Зоны доступности Зоны доступности — это физические расположения в регионе Azure. Каждая зона состоит из одного или нескольких центров обработки данных с независимым питанием, охлаждением и сетью. Разместив виртуальные машины в зонах, приложение становится устойчивым к сбоям в пределах зоны.
Сети и балансировка нагрузки
Виртуальные сети и подсети. Каждая виртуальная машина Azure развертывается в виртуальной сети, которую можно разделить на подсети. Создайте отдельные подсети для каждого уровня.
Шлюз приложений. Шлюз приложений — это балансировщик нагрузки уровня 7. В этой архитектуре шлюз перенаправляет HTTP-запросы к внешнему веб-интерфейсу. Шлюз приложений также предоставляет брандмауэр веб-приложения (WAF), который защищает приложения от распространенных эксплойтов и уязвимостей.
Подсистемы балансировки нагрузки. Используйте Azure Load Balancer (цен. категория для распределения сетевого трафика с веб-уровня на бизнес-уровень.
Группы безопасности сети (NSG). Используйте группы безопасности сети для ограничения сетевого трафика в виртуальной сети. Например, в приведенной здесь трехуровневой архитектуре уровень базы данных не принимает трафик из веб-интерфейса, а только с бизнес-уровня и из подсети управления.
Защита от атак DDoS. Хотя платформа Azure обеспечивает базовую защиту от распределенных атак типа "отказ в обслуживании" (DDoS), рекомендуется использовать защиту сети DDoS Azure, которая обеспечивает расширенные функции защиты от атак DDoS. Ознакомьтесь с рекомендациями по обеспечению безопасности .
Azure DNS. Azure DNS — это служба размещения для доменов DNS. Она осуществляет разрешение имен на базе инфраструктуры Microsoft Azure. Размещая домены в Azure, вы можете управлять своими записями DNS с помощью тех же учетных данных, API и инструментов и оплачивать использование, как и другие службы Azure.
Виртуальные машины
База данных Apache Cassandra. Обеспечивает высокий уровень доступности на уровне данных, включив репликацию и отработку отказа.
OpsCenter. Разверните решение мониторинга, например DataStax OpsCenter , для мониторинга кластера Cassandra.
Jumpbox. Он также называется узлом-бастионом. Безопасная виртуальная машина в сети, которую администраторы используют для подключения к другим виртуальным машинам. В jumpbox есть группа безопасности сети, обеспечивающая удаленный трафик только из общедоступных IP-адресов из списка надежных отправителей. NSG должна пропускать трафик с удаленного рабочего стола (RDP).
Рекомендации
Описанная здесь архитектура может не соответствовать вашим требованиям. Воспользуйтесь этими рекомендациями в качестве отправной точки.
Виртуальные машины
Рекомендации по настройке виртуальных машин см. в статье "Запуск виртуальной машины Linux в Azure".
Виртуальная сеть
При создании виртуальной сети определите, сколько IP-адресов требуется для ресурсов в каждой подсети. Укажите маску подсети и достаточно большой диапазон адресов сети для требуемых IP-адресов с помощью нотации CIDR. Используйте адресное пространство, которое входит в диапазон стандартных блоков частных IP-адресов, например 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16.
Выберите диапазон адресов, который не перекрывается с локальной сетью, если вам потребуется настроить шлюз между виртуальной сетью и локальной сетью позже. Создав виртуальную сеть, изменить диапазон адресов нельзя.
Проектируйте подсети с учетом требований к функциональности и безопасности. Все виртуальные машины в пределах одного уровня или одной роли должны входить в одну и ту же подсеть, которая может быть надежным периметром безопасности. Дополнительные сведения о проектировании виртуальных сетей и подсетей см. в статье Планирование и проектирование виртуальных сетей Azure.
Шлюз приложений
Сведения о настройке Шлюз приложений см. в Шлюз приложений обзоре конфигурации.
Подсистемы балансировки нагрузки
Не предоставляйте виртуальным машинам непосредственный доступ в Интернет. Вместо этого назначьте каждой виртуальной машине частный IP-адрес. Клиенты подключаются с помощью IP-адреса, связанного с Шлюз приложений.
Определите правила подсистемы балансировки нагрузки для направления трафика к виртуальным машинам. Например, чтобы включить трафик HTTP, создайте правило, которое сопоставляет порт 80 интерфейсной конфигурации с портом 80 серверного пула адресов. Когда клиент отправляет HTTP-запрос на порт 80, подсистема балансировки нагрузки выбирает IP-адрес серверной части с помощью хэш-алгоритма, который содержит исходный IP-адрес. Клиентские запросы распределяются между всеми виртуальными машинами.
Группы безопасности сети
С помощью правил NSG можно ограничить трафик между уровнями. Например, в показанной выше трехуровневой архитектуре веб-уровень не взаимодействует напрямую с уровнем базы данных. Чтобы обеспечить эту возможность, уровень базы данных должен блокировать входящий трафик из подсети веб-уровня.
- Запретите весь входящий трафик от виртуальной сети. (В правиле используйте тег
VIRTUAL_NETWORK.) - Разрешите входящий трафик из подсети бизнес-уровня.
- Разрешите входящий трафик из самой подсети уровня базы данных. Это правило обеспечивает взаимодействие между виртуальными машинами баз данных, которое необходимо для репликации и отработки отказа базы данных.
- Разрешите трафик SSH (порт 22) из подсети jumpbox. Это правило позволяет администраторам подключаться к уровню базы данных из jumpbox.
Создайте правила 2–4 с более высоким приоритетом, чем у правила 1, чтобы они переопределяли его.
Cassandra
Для производственных целей мы рекомендуем использовать DataStax Enterprise. Эти рекомендации применимы для каждого выпуска Cassandra. Дополнительные сведения о запуске DataStax в Azure см. в руководстве по развертыванию DataStax Enterprise для Azure.
Настройте узлы в режиме с поддержкой стоек. Сопоставьте домены сбоя со стойками в файле cassandra-rackdc.properties.
Вам не потребуется подсистема балансировки нагрузки для кластера. Клиент подключается напрямую к узлу в кластере.
Скрипты развертывания для этой архитектуры используют разрешение имен для инициализации начального узла для обмена данными внутри кластера (gossip). Чтобы включить разрешение имен, развертывание создает зону azure Частная зона DNS с записями A для узлов Cassandra. В зависимости от сценариев инициализации вместо этого можно использовать статический IP-адрес.
Примечание.
Частная зона DNS в настоящее время находится на этапе общедоступной предварительной версии.
Jumpbox
Запретите доступ по протоколу SSH из общедоступного Интернета к виртуальным машинам, которые выполняют рабочую нагрузку приложения. Вместо этого все доступы по протоколу SSH к этим виртуальным машинам должны проходить через jumpbox. Администратор выполняет вход в jumpbox, а затем вход в другую виртуальную машину из jumpbox. Jumpbox разрешает трафик SSH из Интернета, но только из известных и безопасных IP-адресов.
Jumpbox имеет минимальные требования к производительности, поэтому выберите небольшой размер виртуальной машины. Создайте общедоступный IP-адрес для jumpbox. Поместите jumpbox в виртуальную сеть вместе с другими виртуальными машинами, однако в отдельную подсеть управления.
Чтобы защитить jumpbox, добавьте правило NSG, разрешающее подключения по протоколу SSH только из безопасного набора общедоступных IP-адресов. Настройте NSG для других подсетей, чтобы разрешить трафик SSH из подсети управления.
Рекомендации
Масштабируемость
Масштабируемые наборы
Для веб-уровней и бизнес-уровней рекомендуется использовать Масштабируемые наборы виртуальных машин вместо развертывания отдельных виртуальных машин в группе доступности. Масштабируемый набор упрощает процессы развертывания и администрирования набора идентичных виртуальных машин, а также автоматического масштабирования виртуальных машин на основе метрик производительности. По мере увеличения нагрузки на виртуальные машины в подсистему балансировки нагрузки автоматически добавляются дополнительные виртуальные машины.
Настройку виртуальных машин, развернутых в масштабируемый набор, можно выполнить двумя основными способами:
Используйте расширения для настройки виртуальной машины после ее развертывания. В этом случае новые экземпляры виртуальной машины могут дольше запускаться, чем виртуальные машины без расширений.
Развернуть управляемый диск с помощью пользовательского образа диска. При этом развертывание выполняется быстрее. Но образ необходимо обновлять.
Дополнительные сведения см. в статье Рекомендации по проектированию масштабируемых наборов.
Совет
При использовании любого решения автоматического масштабирования заблаговременно протестируйте его с рабочими нагрузками производственного уровня.
Ограничения подписки
В каждой подписке Azure настроены ограничения по умолчанию, включая максимальное количество виртуальных машин в каждом регионе. Их лимит можно увеличить, создав запрос на поддержку. Дополнительные сведения см. в статье Подписка Azure, границы, квоты и ограничения службы.
Шлюз приложений
Шлюз приложений поддерживает режим фиксированной емкости или режим автомасштабирования. Режим фиксированной емкости подходит для сценариев с постоянной, предсказуемой рабочей нагрузкой. Рекомендуется использовать режим автомасштабирования для рабочих нагрузок с переменным трафиком. Дополнительные сведения см. в статье Автоматическое масштабирование и Шлюз приложений, избыточный между зонами, версии 2.
Оптимизация производительности
Чтобы получить лучшую производительность из Cassandra на виртуальных машинах Azure, ознакомьтесь с рекомендациями по запуску Apache Cassandra на виртуальных машинах Azure.
Доступность
Зоны доступности обеспечивают лучшую устойчивость в одном регионе. Если вам нужна еще более высокая доступность, рассмотрите возможность реплика приложения в двух регионах.
Не все регионы поддерживают зоны доступности, а не все размеры виртуальных машин поддерживаются во всех зонах. Выполните следующую команду Azure CLI, чтобы найти поддерживаемые зоны для каждого размера виртуальной машины в пределах региона:
az vm list-skus --resource-type virtualMachines --zone false --location <location> \
--query "[].{Name:name, Zones:locationInfo[].zones[] | join(','@)}" -o table
При развертывании этой архитектуры в регионе, который не поддерживает зоны доступности, поместите виртуальные машины для каждого уровня в группу доступности. Виртуальные машины в одной доступности развертываются на нескольких физических серверах, вычислительных стойках, единицах хранения и сетевых коммутаторах для избыточности. Масштабируемые наборы автоматически используют группы размещения, которые функционируют как неявная группа доступности.
При развертывании в зонах доступности используйте стандартный номер SKU Azure Load Balancer и номер SKU версии 2 Шлюз приложений. Эти номера SKU поддерживают избыточность между зонами. Дополнительные сведения см. в разделе:
- Load Balancer (цен. категория "Стандартный") и Зоны доступности
- Автоматическое масштабирование и Шлюз приложений, избыточный между зонами, версии 2
- Как Шлюз приложений поддерживает высокую доступность и масштабируемость?
Одно Шлюз приложений развертывание может выполнять несколько экземпляров шлюза. Для рабочих нагрузок выполните по крайней мере два экземпляра.
Кластер Cassandra
Для кластера Cassandra сценарии отработки отказа зависят от уровней согласованности, используемых приложением, а также от количества используемых реплик. Сведения о уровнях согласованности и использовании в Cassandra см. в разделе "Настройка согласованности данных" и Cassandra: Сколько узлов разговаривают с Кворумом? Доступность данных в Cassandra определяется уровнем согласованности, используемым приложением и механизмом реплика. Сведения о репликации в Cassandra см. в статье Data Replication in NoSQL Databases Explained (Описание репликации данных в базах данных NoSQL).
Зонды работоспособности
Шлюз приложений и Load Balancer используют пробы работоспособности для мониторинга доступности экземпляров виртуальных машин.
- Шлюз приложений всегда использует пробу HTTP.
- Load Balancer может протестировать ПРОТОКОЛ HTTP или TCP. Как правило, если виртуальная машина запускает HTTP-сервер, используйте пробу HTTP. В противном случае используйте TCP.
Если проба не может достичь экземпляра в течение периода ожидания, шлюз или подсистема балансировки нагрузки останавливает отправку трафика на этой виртуальной машине. Проба продолжает проверка и вернет виртуальную машину в внутренний пул, если виртуальная машина снова станет доступной.
Пробы HTTP отправляют HTTP-запрос GET в указанный путь и прослушивают ответ HTTP 200. Этим путем может быть путь к корневому каталогу (/) или конечная точка мониторинга работоспособности, которая реализует определенную пользовательскую логику для проверки работоспособности приложения. Конечная точка должна разрешать анонимные HTTP-запросы.
Дополнительные сведения о пробах работоспособности см. в следующем разделе:
Рекомендации по проектированию конечной точки пробы работоспособности см . в шаблоне мониторинга конечных точек работоспособности.
Оптимизация затрат
Используйте калькулятор цен Azure для оценки затрат. Ниже приведены некоторые другие соображения.
Масштабируемые наборы виртуальных машин
Масштабируемые наборы виртуальных машин доступны во всех размерах виртуальных машин Linux. Плата взимается только за развертываемые виртуальные машины Azure, а также за любые дополнительные потребляемые ресурсы базовой инфраструктуры, например ресурсы хранения данных и сетевые ресурсы. За саму службу наборов для масштабирования виртуальных машин дополнительная оплата не начисляется.
Сведения о ценах на отдельные виртуальные машины см . в разделе цен на виртуальные машины Linux.
Подсистемы балансировки нагрузки
Плата взимается только за количество настроенных правил балансировки нагрузки и исходящего трафика. За правила преобразования сетевых адресов (NAT) плата не взимается. Если правила не настроены, для Load Balancer (цен. категория "Стандартный") почасовая оплата не применяется.
См. сведения о затратах на платформу Microsoft Azure с продуманной архитектурой.
Безопасность
Виртуальные сети являются границей, изолирующей трафик в Azure. Виртуальные машины из разных виртуальных сетей не могут напрямую обмениваться данными. Виртуальные машины в одной виртуальной сети могут обмениваться данными, если только не созданы группы безопасности сети, ограничивающие этот трафик. Дополнительные сведения см. в статье Virtual datacenters: A network perspective (Виртуальные центры обработки данных: перспектива сети).
Для входящего интернет-трафика правила подсистемы балансировки нагрузки определяют, какой трафик может достичь серверной части. Однако правила подсистемы балансировки нагрузки не поддерживают списки безопасных IP-адресов, поэтому если вы хотите добавить некоторые общедоступные IP-адреса в список надежных, добавьте группу безопасности сети в подсеть.
DMZ. Попробуйте добавить сетевой виртуальный модуль (NVA), чтобы создать сеть периметра между Интернетом и виртуальною сетью Azure. Сетевой виртуальный модуль — это универсальный термин для виртуального модуля, который может выполнять сетевые задачи, например брандмауэра, проверки пакетов, аудита и пользовательской маршрутизации. Дополнительные сведения см. в статье Сеть периметра между Azure и Интернетом.
Шифрование. Выполните шифрование конфиденциальных неактивных данных и используйте Azure Key Vault для управления ключами шифрования базы данных. Key Vault может хранить ключи шифрования в аппаратных модулях безопасности. В Key Vault также рекомендуется хранить секреты приложения, например строки подключения к базе данных.
Защита от атак DDoS. Платформа Azure по умолчанию предоставляет основные средства защиты от атак DDoS. Эти основные средства защиты предназначены для защиты всей инфраструктуры Azure. Хотя базовая защита от атак DDoS включена автоматически, рекомендуется использовать защиту сети DDoS Azure. Защита сети использует адаптивную настройку на основе шаблонов сетевого трафика приложения для обнаружения угроз. Это позволяет устранять риски атак DDoS, которые могут остаться незамеченными для соответствующих политик уровня инфраструктуры. Защита сети также предоставляет оповещения, телеметрию и аналитику с помощью Azure Monitor. Дополнительные сведения см. в статье Защита от атак DDoS Azure. Рекомендации и эталонные образцы архитектуры.
Эффективность работы
Так как все основные ресурсы и их зависимости находятся в одной виртуальной сети в этой архитектуре, они изолированы в одной базовой рабочей нагрузке. Этот факт упрощает связывание конкретных ресурсов рабочей нагрузки с командой DevOps, чтобы команда могли самостоятельно управлять всеми аспектами этих ресурсов. Эта изоляция позволяет DevOps Teams и Services выполнять непрерывную интеграцию и непрерывную доставку (CI/CD).
Кроме того, можно использовать различные шаблоны развертывания и интегрировать их с Azure DevOps Services для подготовки различных сред в минутах, например для реплика рабочей среды, например сценариев или сред нагрузочного тестирования, только если это необходимо, экономия затрат.
В этом сценарии виртуальные машины настраиваются с помощью расширений виртуальных машин, так как они предлагают возможность установки определенного дополнительного программного обеспечения, например Apache Cassandra. В частности, расширение пользовательского скрипта позволяет скачивать и выполнять произвольный код на виртуальной машине, что позволяет неограниченно настраивать операционную систему виртуальной машины Azure. Расширения виртуальных машин устанавливаются и выполняются только во время создания виртуальной машины. Это означает, что если операционная система настроена неправильно на более позднем этапе, потребуется вмешательство вручную, чтобы переместить его обратно в правильное состояние. Средства управления конфигурацией можно использовать для решения этой проблемы.
Мы рекомендуем использовать Azure Monitor для анализа и оптимизации производительности инфраструктуры, отслеживания и диагностики проблем с сетью без входа на виртуальные машины. Фактически Application Insights — это один из компонентов платформы Azure Monitor, которая предоставляет разнообразные метрики и журналы, отображающие состояние всего ландшафта Azure. Azure Monitor поможет вам следовать состоянию инфраструктуры.
Не только отслеживайте вычислительные элементы, поддерживающие код приложения, но и платформу данных, в частности базы данных, так как низкая производительность уровня данных приложения может иметь серьезные последствия.
Чтобы протестировать среду Azure, в которой выполняются приложения, она должна управлять версиями и развертываться с помощью тех же механизмов, что и код приложения, а затем его можно протестировать и проверить с помощью парадигм тестирования DevOps.
Дополнительные сведения см. в разделе "Эффективность работы" в Microsoft Azure Well-Architecture Framework.