Виртуальный центр обработки данных с точки зрения сети

Статья
07/11/2023

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

Microsoft Azure предоставляет гипермасштабируемые службы и инфраструктуру, а также надежность и возможности корпоративного класса. Эти службы и инфраструктура предлагают множество вариантов гибридного подключения, что позволяет клиентам получать доступ к ним через Интернет или через частную сеть. Кроме того, партнеры Майкрософт предоставляют расширенные возможности, предлагая службы безопасности и виртуальные устройства, оптимизированные для работы в Azure.

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

Что такое виртуальный центр обработки данных?

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

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

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

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

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

Реализация виртуального центра обработки данных предполагает нечто большее, чем рабочие нагрузки приложений в облаке. При этом также предполагаются службы сети, безопасности, управления, DNS и Active Directory. Так как предприятия переносят дополнительные рабочие нагрузки в Azure, рассмотрим инфраструктуру и объекты, которые поддерживают эти рабочие нагрузки. Качественное управление ресурсами помогает избежать увеличения числа управляемых по отдельности «изолированных рабочих нагрузок» с независимыми потоками данных, моделями безопасности и задачами соответствия требованиям.

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

Примечание.

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

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

размещение нескольких связанных рабочих нагрузок;
перенос рабочих нагрузок из локальной среды в Azure;
обеспечение общей или централизованной защиты и доступности рабочих нагрузок;
соответствующего объединения DevOps и централизованной ИТ-инфраструктуры для большого предприятия.

Кто отвечает за реализацию ВЦОД?

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

В некоторых организациях есть централизованные ИТ-команды или отделы, сеть, система безопасности или комплаенса. Реализация VDC может помочь применить точки политики, отдельные обязанности и обеспечить согласованность базовых общих компонентов. У специалистов по разработке приложений остается определенная свобода и возможность контроля, что полностью соответствует их требованиям.

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

Общие сведения о ВЦОД

Топологии

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

В плоской топологии все ресурсы развертываются в одной виртуальной сети. Подсети позволяют управлять потоками и разделять их.

В топологии одноранговой сети пиринг между виртуальными сетями напрямую соединяет все виртуальные сети друг с другом.

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

Топология виртуальной глобальной сети Azure поддерживает сети крупномасштабных филиалов и глобальные службы WAN.

Звездообразная топология пиринга и топология виртуальной глобальной сети Azure используют звездообразную модель, которая является оптимальной для обмена данными, общих ресурсов и централизованной политики безопасности. Концентраторы создаются с использованием концентратора пиринга между виртуальными сетями (помеченного как Hub Virtual Network на схеме) или виртуального концентратора глобальной сети (помеченного как Azure Virtual WAN на схеме). Виртуальная глобальная сеть Azure предназначена для масштабного обмена данными между сетями филиалов и между сетями филиалов и Azure, а также для предотвращения проблем, связанных с созданием всех компонентов по отдельности в концентраторе пиринга между виртуальными сетями. В некоторых случаях ваши требования могут диктовать структуру концентратора пиринга между виртуальными сетями, например определять потребность в сетевых виртуальных модулях в концентраторе.

В концентраторах и периферийных топологиях концентратор — это центральная сетевая зона, которая контролирует и проверяет весь трафик между различными зонами, такими как Интернет, локальные и периферийные устройства. Звездообразная топология помогает ИТ-отделу централизованно применять политики безопасности. одновременно минимизируя уязвимости и ошибки в конфигурации.

Концентратор часто содержит общие компоненты службы, потребляемые периферийными устройствами. Их примеры представлены ниже.

Инфраструктура Windows Active Directory необходима для проверки подлинности пользователей сторонних производителей, которые обращаются из ненадежных сетей, прежде чем получить доступ к рабочим нагрузкам в периферийной сети. Он включает связанные службы федерации Active Directory (AD FS) (AD FS)
Служба распределенной системы имен (DNS) используется для разрешения именования рабочей нагрузки в периферийных устройствах и доступа к ресурсам в локальной среде и в Интернете, если Azure DNS не используется
Инфраструктура открытых ключей (PKI) используется для реализации рабочих нагрузок единого входа
Управление потоком трафика TCP и UDP между периферийными зонами сети и Интернетом
Управление потоком между периферийными и локальными
При необходимости управление потоком между одной периферийной и другой

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

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

Ограничения подписки и несколько центральных зон

Внимание

В зависимости от размера развертываний Azure может потребоваться несколько центральных стратегий. При разработке стратегии концентратора и периферийной стратегии попросите "Можно ли масштабировать проект для использования другой виртуальной сети концентратора в этом регионе?" и "Может ли этот масштаб проектирования соответствовать нескольким регионам?" Гораздо лучше планировать дизайн, который масштабируется и не нуждается в нем, чем не планировать и нуждаться в нем.

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

В Azure каждый компонент (независимо от типа) развертывается в подписке Azure. Изоляция компонентов Azure в разных подписках Azure позволяет выполнять требования различных бизнес-приложений, например настройку дифференцированных уровней доступа и авторизации.

Одна реализация VDC может увеличить большое количество периферийных компонентов. Хотя, как и в каждой ИТ-системе, существуют ограничения платформы. Развертывание концентратора привязано к определенной подписке Azure, которая имеет ограничения и ограничения (например, максимальное количество пирингов виртуальной сети. Дополнительные сведения см. в разделе об ограничениях подписки и службы Azure, квотах и ограничениях. В случаях, когда ограничения могут быть проблемой, архитектура может увеличить масштаб, расширив модель из одного концентратора в кластер концентраторов и периферийных компонентов. Связать несколько концентраторов в одном или нескольких регионах Azure можно с помощью пиринга между виртуальными сетями, подключения ExpressRoute, Виртуальной глобальной сети или VPN типа "сайт— сайт".

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

Взаимодействие между периферийными зонами

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

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

Периферийные устройства также могут взаимодействовать с периферийной связью, которая выступает в качестве концентратора. Этот подход создает двухуровневую иерархию. Периферийный элемент на более высоком уровне (уровень 0) становится центром нижней периферии (уровень 1) иерархии. Периферийные компоненты для реализации VDC необходимы для пересылки трафика в центральный концентратор. Затем трафик может перенаправиться в место назначения в локальной сети или в общедоступном Интернете. Такая архитектура концентратора представляет сложную маршрутизацию, что сводит на нет преимущества отдельной звездообразной связи.

Несмотря на то что Azure допускает сложные топологии, одним из основных принципов концепции VDC является повторяемость и простота. Чтобы свести к минимуму действия по управлению системой, в качестве эталонной архитектуры ВЦОД рекомендуется использовать простую топологию тира "звезда".

Компоненты

Виртуальный центр обработки данных состоит из четырех базовых типов компонентов: инфраструктуры, сетей периметра, рабочих нагрузок и мониторинга.

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

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

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

Каждая группа ролей может иметь уникальный префикс в именах. Этот префикс упрощает определение рабочей нагрузки, с которой связана группа. Например, рабочая нагрузка, размещающая службы проверки подлинности, должна содержать группы с именами AuthServiceNetOps, AuthServiceSecOps, AuthServiceDevOps и AuthServiceInfraOps. Для централизованных ролей или ролей, не связанных с определенной службой, должен использоваться префикс Corp. В качестве примера можно привести CorpNetOps.

Многие организации используют разновидность следующих групп для предоставления основной декомпозиции ролей:

Центральная ИТ-отдел Corp, имеет права владения для управления компонентами инфраструктуры. Примерами являются сетевые компоненты и система безопасности. Группе должна быть назначена роль участника в подписке, а также предоставлены права управления концентратором и права участника сети в периферийных зонах. Крупные организации часто разделяют эти функции между несколькими командами. Примеры — команда, отвечающая за сетевые операции (CorpNetOps), которая фокусируется на сетевых компонентах, а также команда, отвечающая за операции системы безопасности (CorpSecOps), которая фокусируется на политиках безопасности и брандмауэра. В этом конкретном случае требуется создание двух разных групп для назначения этих пользовательских ролей.
Группа разработки и тестирования AppDevOps отвечает за развертывание рабочих нагрузок (приложений или служб). Эта группа выполняет роль участника виртуальной машины для развертываний IaaS, а также одну или несколько ролей участника PaaS. Дополнительные сведения см. в статье Встроенные роли Azure. При необходимости группе разработки и тестирования может потребоваться право на просмотр политик безопасности, групп безопасности сети и политик маршрутизации в пределах концентратора или определенной периферийной зоны. Кроме ролей участника для рабочих нагрузок этой группе также потребуется роль читателя сетей.
Группа операций и обслуживания (CorpInfraOps или AppInfraOps) отвечает за управление рабочими нагрузками в рабочей среде. Эта группа должна быть участником подписки для рабочих нагрузок в любой рабочей подписке. Некоторые организации также могут оценить, требуется ли группа поддержки эскалации с ролью участника подписки в рабочей среде и централизованной подписке. Другая группа устраняет потенциальные проблемы конфигурации в рабочей среде.

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

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

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

Обычно в сфере ИТ среда (или уровень) представляет систему, в которой развертываются и выполняются несколько приложений. Крупные предприятия используют среду разработки (в которой формируются и тестируются изменения) и рабочую среду (которую используют пользователи). Эти среды отделяются, часто с несколькими промежуточными средами между ними, чтобы разрешить поэтапное развертывание (развертывание), тестирование и откат при возникновении проблем. Архитектуры развертывания сильно различаются, но обычно соблюдается основной процесс начала развертывания (разработка) и окончания развертывания (рабочая среда).

Общая архитектура для этих типов многоуровневых сред включает DevOps для разработки и тестирования, UAT для промежуточной и рабочей среды. Организации могут использовать один или несколько клиентов Microsoft Entra для определения доступа и прав в этих средах. На предыдущей схеме показано, что используются два разных клиента Microsoft Entra: один для DevOps и UAT, а другой — исключительно для рабочей среды.

Наличие различных клиентов Microsoft Entra обеспечивает разделение между средами. Та же группа пользователей, например центральная ИТ-группа, должна пройти проверку подлинности с помощью другого URI для доступа к другому клиенту Microsoft Entra. Это позволяет команде изменять роли или разрешения среды DevOps или рабочей среды проекта. Выполнение проверки подлинности другого пользователя для доступа к другим средам минимизирует возможные простои и предотвращает появление других проблем, вызванных человеческим фактором.

Тип компонента: инфраструктура

В этом типе компонента размещается большая часть вспомогательной инфраструктуры. С этим компонентом большую часть времени работает централизованная ИТ-команда и команда по обеспечению соответствия и безопасности.

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

Одна из основных задач группы ИТ-инфраструктуры — обеспечение согласованности схем IP-адреса на предприятии. Диапазон частных IP-адресов, назначенный виртуальным центром обработки данных, должен быть согласован и не должен перекрываться с IP-адресами, назначенными локальным сетям.

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

Инфраструктура включает следующие компоненты:

Службы удостоверений и каталогов. Доступ к каждому типу ресурсов в Azure управляется удостоверением, хранящимся в службе каталогов. В службе каталогов хранится не только список пользователей, но также права доступа к ресурсам в определенной подписке Azure. Эти службы могут существовать в облаке или их можно синхронизировать с локальным удостоверением, хранящимся в Active Directory.
Виртуальные сети: виртуальные сети являются одним из основных компонентов VDC и позволяют создать границу изоляции трафика на платформе Azure. Виртуальная сеть состоит из одного или нескольких сегментов виртуальной сети, каждый из которых содержит определенный сетевой префикс IP-адреса (подсеть, либо IPv4 или двойной стек IPv4/IPv6). Виртуальная сеть определяет внутреннюю область периметра, где виртуальные машины IaaS и службы PaaS могут осуществлять закрытый обмен данными. Виртуальные машины (и службы PaaS) в одной виртуальной сети не могут напрямую взаимодействовать с виртуальными машинами (и службами PaaS) в другой виртуальной сети. Это верно, даже если обе виртуальные сети создаются одинаковым клиентом в одной подписке. Это критически важное свойство, которое гарантирует, что виртуальные машины и все коммуникации клиента останутся закрытыми в пределах виртуальной сети. Где необходимо выполнить подключение между сетями, в следующих функциях описано, как это можно сделать.
Пиринг между виртуальными сетями: основная функция, используемая для создания инфраструктуры VDC, — это пиринг между виртуальными сетями, который подключает две виртуальные сети в одном регионе. Это подключение происходит через сеть центра обработки данных Azure или с помощью глобальной магистрали Azure в разных регионах.
виртуальная сеть конечные точки службы: конечные точки службы расширяют адресное пространство виртуальной сети, чтобы включить пространство PaaS. Конечные точки также распространяют идентификатор вашей виртуальной сети до служб Azure посредством прямого подключения. Конечные точки позволяют защищать критически важные ресурсы служб Azure в пределах виртуальных сетей.
Приватный канал: Приватный канал Azure позволяет получать доступ к службам Azure PaaS (например, служба хранилища Azure, Azure Cosmos DB и База данных SQL Azure) и размещенным клиентам и партнерам Azure через частную конечную точку в виртуальная сеть. Трафик между виртуальной сетью и службой проходит через магистральную сеть Майкрософт. Это позволяет избежать рисков общедоступного Интернета. Кроме того, вы можете создать в своей виртуальной сети собственную службу "Приватный канал" и предоставлять ее клиентам в частном порядке. Настройка и потребление с использованием Приватного канала Azure согласованы между службами Azure PaaS, владельцами и общими партнерскими службами.
Определяемые пользователем маршруты: трафик в виртуальной сети направляется по умолчанию на основе таблицы маршрутизации системы. Определяемый пользователем маршрут — это настраиваемая таблица маршрутизации, которую администраторы сети могут связать с одной или несколькими подсетями, чтобы переопределить поведение таблицы маршрутизации системы и определить путь связи в виртуальной сети. Наличие определяемых пользователем маршрутов гарантирует трафик из периферийного транзита через определенные пользовательские виртуальные машины или сетевые виртуальные устройства и подсистемы балансировки нагрузки, присутствующих как в концентраторе, так и в периферийных устройствах.
Группы безопасности сети: группа безопасности сети — это список правил безопасности, которые выполняют фильтрацию трафика в источниках IP- адресов, назначениях IP-адресов, протоколах, ip-портах и портах назначения IP-адресов (также называемых пятью кортежами уровня 4). Эти группы можно применить к подсети, виртуальной плате сетевого адаптера, связанной с виртуальной машиной Azure или и к тому, и к другому. Группы безопасности сети необходимы для реализации правильного управления потоком в концентраторе и периферийных зонах. Уровень безопасности, обеспечиваемый группой безопасности сети, зависит от того, какие порты вы открываете и с какой целью. Клиенты могут применять дополнительные фильтры для каждой виртуальной машины с брандмауэрами на основе узлов, такими как iptables или брандмауэр Windows.
DNS: DNS предоставляет разрешение имен для ресурсов в виртуальном центре обработки данных. Azure предоставляет службы DNS как для общедоступного, так и для частного разрешения имен. Частные зоны предоставляют разрешение имен в виртуальной сети и между виртуальными сетями. Частные зоны могут охватывать виртуальные сети в одном регионе, а также между регионами и подписками. Для общедоступного разрешения Azure DNS предоставляет службу размещения для доменов DNS, которая в свою очередь предоставляет разрешение имен с помощью инфраструктуры Microsoft Azure. Размещая домены в Azure, вы можете управлять своими записями DNS с помощью тех же учетных данных, API и инструментов и оплачивать использование, как и другие службы Azure.
Группа управления, подписка и управление группой ресурсов. Подписка определяет естественную границу, чтобы создать несколько групп ресурсов в Azure. Это разделение может быть реализовано для функции, разделения ролей или выставления счетов. Ресурсы в подписке собраны вместе в логические контейнеры, которые называются группами ресурсов. Группа ресурсов представляет собой логическую группу для организации ресурсов реализации виртуального центра обработки данных. Если в организации много подписок, для эффективного управления доступом к ним, их политиками и соответствием требуется особый подход. Группы управления Azure представляют область действия уровнем выше, чем подписки. Подписки упорядочиваются в контейнеры, которые называются группами управления. К ним применяются условия системы управления. Все подписки в группе управления автоматически наследуют условия, применяемые к группе управления. Сведения о том, как можно просмотреть эти три функции в иерархическом представлении, см. в разделе Организация ресурсов в Cloud Adoption Framework.
Управление доступом на основе ролей Azure (Azure RBAC) — Azure RBAC может сопоставить роли организации и права для доступа к определенным ресурсам Azure. Это позволяет ограничить пользователей только определенным подмножеством действий. Если вы синхронизируете идентификатор Microsoft Entra с локальная служба Active Directory, можно использовать те же группы Active Directory в Azure, которые используются локально. С помощью Azure RBAC доступ предоставляется путем назначения соответствующей роли пользователям, группам и приложениям в определенной области. Областью назначения роли может быть подписка Azure, группа ресурсов или отдельный ресурс. Azure RBAC разрешает наследование разрешений. Роли, назначенной в родительской области, предоставляется доступ также к содержащимся в ней дочерним элементам. С помощью Azure RBAC можно разделить обязанности и предоставить пользователям доступ только к пользователям, которым они должны выполнять свои задания. Например, можно разрешить одному сотруднику управлять виртуальными машинами в подписке, а другому — управлять в ней базами данных SQL Server.

Тип компонента: сети периметра

Компоненты сети периметра (иногда называемой сетью DMZ) соединяют локальные или физические центры обработки данных и обеспечивают подключение к Интернету. Сеть периметра обычно требует значительных затрат времени специалистов по сети и безопасности.

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

Ниже перечислены компоненты сети периметра.

Как правило, центральная ИТ-команда и команда по обеспечению безопасности отвечают за определение требований и операций в сетях периметра.

На предыдущей схеме показано применение двух периметров с доступом в Интернет и локальную сеть. Оба периметра располагаются в концентраторе DMZ. В концентраторе сети периметра сеть с доступом в Интернет можно масштабировать для поддержки большого количества сфер деятельности с помощью нескольких ферм брандмауэров веб-приложения (WAF) или брандмауэров Azure. Концентратор также обеспечивает локальное подключение через VPN или ExpressRoute при необходимости.

Примечание.

На приведенной выше схеме DMZ Hubмногие из следующих функций можно объединить в центр Azure Виртуальная глобальная сеть (например, виртуальные сети, определяемые пользователем маршруты, группы безопасности сети, VPN-шлюзы, шлюзы ExpressRoute, Azure Load Balancers, Брандмауэр Azure, диспетчер брандмауэра и DDOS). Использование центров azure Виртуальная глобальная сеть может упростить создание концентратора виртуальной сети и VDC, так как большая часть инженерной сложности обрабатывается Azure при развертывании центра Виртуальная глобальная сеть Azure.

Виртуальные сети. Концентратор обычно основан на виртуальной сети с несколькими подсетями, в которых размещаются различные типы служб. Эти службы фильтруют и проверяют трафик из Интернета через Брандмауэр Azure, NVAs, WAF и Шлюз приложений Azure экземпляры.

Пользовательские маршруты. С помощью определяемых пользователем маршрутов клиенты могут развертывать брандмауэры, IDS или IPS и другие виртуальные устройства, а также направлять сетевой трафик через эти устройства безопасности. Это позволяет применять, контролировать и проверять политики границ безопасности. Пользовательские маршруты можно создать в концентраторе и периферийных зонах для обеспечения передачи трафика через определенные пользовательские виртуальные машины, виртуальные сетевые устройства и подсистемы балансировки нагрузки, используемые виртуальным центром обработки данных. Чтобы гарантировать, что трафик, созданный из виртуальных машин в периферийных устройствах, передается на правильные виртуальные устройства, необходимо задать определяемый пользователем маршрут в подсетях периферийных устройств. Это делается путем задания внешнего IP-адреса внутренней подсистемы балансировки нагрузки в качестве следующего прыжка. Внутренняя подсистема балансировки нагрузки распределяет внутренний трафик на виртуальные устройства (внутренний пул подсистемы балансировки нагрузки).

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

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

Виртуальные сетевые модули. В концентраторе сеть периметра с доступом в Интернет обычно управляется с помощью экземпляра Брандмауэра Azure, фермы брандмауэров или брандмауэров веб-приложений (WAF).

Различные сферы деятельности обычно используют множество веб-приложений, которые, как правило, являются уязвимыми. Брандмауэры веб-приложений — это специальный тип продукта, используемый для обнаружения атак на веб-приложения и HTTP/HTTPS более эффективно, чем универсальный брандмауэр. По сравнению с традиционными брандмауэрами WAF содержит набор специальных функций для защиты внутренних веб-серверов от угроз.

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

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

Azure Load Balancer обеспечивает высокий уровень доступности (уровень 4) (TCP, UDP), который может распределять входящий трафик между экземплярами службы, определенными в наборе балансировки нагрузки. Трафик, отправляемый в подсистему балансировки нагрузки из интерфейсных конечных точек (конечных точек общедоступных IP-адресов или частных КОНЕЧНЫх точек IP-адресов) можно распространить с помощью или без преобразования адресов в набор пулов ВНУТРЕННИх IP-адресов (например, сетевых виртуальных устройств или виртуальных машин).

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

Azure Front Door (AFD) — это высокодоступная и масштабируемая платформа ускорения веб-приложений Майкрософт, глобальная подсистема балансировки нагрузки HTTP, защита приложений и сеть доставки содержимого. Служба AFD, работающая в более чем 100 расположениях на границе глобальной сети корпорации Майкрософт, позволяет создавать, управлять и горизонтально увеличивать масштаб динамического веб-приложения и статического содержимого. Служба AFD предоставляет вашему приложению производительность конечного пользователя мирового класса, единую автоматизацию регионального/маркированного обслуживания, автоматизацию BCDR, унифицированную клиентскую/пользовательскую информацию, кэширование и полезные сведения об услугах.

Платформа предлагает:

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

Брандмауэр веб-приложений (WAF) также доступен в Azure Front Door, позволяя устранить уязвимости веб-приложений и защитить их от эксплойтов.

Шлюз приложений Azure является выделенным виртуальным устройством, которое предоставляет управляемый контроллер доставки приложений. Он предлагает различные возможности подсистемы балансировки нагрузки уровня 7 для вашего приложения. Таким образом, вы можете оптимизировать производительность веб-фермы за счет выполнения операции завершения SSL-запросов, требующей интенсивного использования ЦП, на шлюзе приложений. Кроме того, пользователи получают другие возможности маршрутизации уровня 7, включая распределение входящего трафика методом циклического перебора, соответствие сеансу на основе файлов cookie, маршрутизацию на основе URL-путей и возможность размещения нескольких веб-сайтов за одним шлюзом приложений. Брандмауэр веб-приложений (WAF) также предоставляется как часть SKU WAF шлюза приложений. Этот SKU обеспечивает защиту веб-приложений от распространенных веб-уязвимостей и эксплойтов. Шлюз приложений можно настроить как шлюз, подключенный к Интернету, внутренний шлюз или сочетание обоих.

Общедоступные IP-адреса. Некоторые функции Azure позволяют связывать конечные точки службы с общедоступным IP-адресом для получения доступа к ресурсам из Интернета. Эта конечная точка использует преобразование сетевых адресов (NAT) для маршрутизации трафика на внутренний адрес и порт в виртуальной сети в Azure. Это основной путь передачи внешнего трафика в виртуальную сеть. Общедоступные IP-адреса можно настроить, чтобы определить, какой трафик следует пропускать в виртуальную сеть, а также как и где его следует пропускать.

Защита от атак DDoS Azure предоставляет больше возможностей по устранению рисков на базовом уровне служб , настроенных специально для ресурсов виртуальной сети Azure. Защита от атак DDoS проста для включения и не требует изменений приложения. Политики защиты корректируются на основе мониторинга выделенного трафика и алгоритмов машинного обучения. Они применяются к общедоступным IP-адресам, связанным с ресурсами, развернутыми в виртуальных сетях, Примерами являются подсистема балансировки нагрузки Azure, шлюз приложений Azure и экземпляры Azure Service Fabric. Журналы, созданные системой, практически в режиме реального времени доступны через представления Azure Monitor во время атаки и журнала. Защиту уровня приложений можно добавить с помощью брандмауэра веб-приложения шлюза приложений Azure. Защита обеспечивается для общедоступных IP-адресов Azure IPv4 и IPv6.

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

На схеме пользовательский маршрут обеспечивает передачу потоков трафика с периферийного компьютера в брандмауэр перед передачей в локальную среду через шлюз ExpressRoute (если политика брандмауэра разрешает такую передачу).

Тип компонента: мониторинг

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

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

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

В Azure Monitor есть два основных типа журналов:

Метрики — это числовые значения, описывающие конкретный аспект системы в определенный момент времени. Они облегчаются и способны поддерживать сценарии практически в режиме реального времени. Для многих ресурсов Azure данные, собранные службой Azure Monitor, отображаются непосредственно на странице "Обзор" портала Azure. Обратите внимание, например, на любую виртуальную машину, и вы увидите несколько диаграмм с метриками производительности. Выберите любой график, чтобы открыть данные в обозревателе метрик на портале Azure, где вы можете отмечать значения нескольких метрик с течением времени. Эти диаграммы можно просмотреть в интерактивном режиме, также их можно закрепить на панели мониторинга, чтобы просматривать с помощью других средств визуализации.
Журналы содержат данные различных типов, упорядоченные по записям с разными наборами свойств для каждого типа. События и трассировки хранятся в виде журналов вместе с данными о производительности, которые можно объединить для анализа. Данные журналов, собранные службой Azure Monitor, можно проанализировать с помощью запросов, которые быстро получают, консолидируют и анализируют собранные данные. Журналы хранятся и запрашиваются из log analytics. Вы можете создавать и тестировать запросы с помощью log analytics в портал Azure, а также напрямую анализировать данные с помощью этих средств или сохранять запросы для использования с визуализациями или правилами оповещений.

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

Данные мониторинга приложений: данные о производительности и функциональности написанного кода независимо от его платформы.
Данные мониторинга ОС на виртуальной машине. Данные об операционной системе, в которой выполняется ваше приложение. Эта ОС может выполняться в Azure, другом облаке или локальной среде.
Данные мониторинга ресурсов Azure. Данные о работе ресурса Azure.
Данные мониторинга подписки Azure: данные об операциях и управлении подпиской Azure, а также о работоспособности и работе самой Azure.
Данные мониторинга клиентов Azure: данные об операциях служб Azure уровня клиента, таких как идентификатор Microsoft Entra.
Пользовательские источники. Также можно включить журналы, отправляемые из локальных источников. В качестве примера можно привести события локального сервера или выходные данные системного журнала для сетевых устройств.

Данные мониторинга полезны, только если они могут сделать работу вычислительной среды более открытой. Azure Monitor включает несколько функций и инструментов, которые предоставляют ценные сведения о приложениях и других ресурсах, от них зависят. Решения и функции мониторинга, такие как application insights и Azure Monitor для контейнеров, предоставляют подробные сведения о различных аспектах приложения и конкретных службах Azure.

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

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

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

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

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

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

Тип компонента: рабочие нагрузки

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

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

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

Интерактивность: вводятся данные, и возвращаются результаты или отчеты
Зависимость от данных: активное использование данных — данные интенсивно используются с частым доступом к базам данных или другому хранилищу.
Интеграция: интеграция с другими системами в пределах и за пределами организации.

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

Аналитика больших данных: если данные должны масштабироваться до больших томов, реляционные базы данных могут не работать в условиях крайней нагрузки или неструктурированной природы данных. Azure HDInsight — это управляемая комплексная облачная служба аналитики с открытым кодом, предназначенная для предприятий. Платформы с открытым кодом, такие как Hadoop, Apache Spark, Apache Hive, LLAP, Apache Kafka, Apache Storm и R. HDInsight. Это поддерживает развертывание в виртуальной сети на основе расположения, которая может быть развернута в кластере в периферийных виртуальных центрах обработки данных.

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

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

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

Высокая доступность: несколько виртуальных центров обработки данных

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

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

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

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

Региональное и глобальное присутствие

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

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

Аварийное восстановление

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

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

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

Обычно концентраторы виртуальных глобальных сетей, пиринг между виртуальными сетями или подключения ExpressRoute – предпочтительные типы подключений из-за более высокой пропускной способности и последовательных уровней задержки при передаче через магистраль Майкрософт.

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

Аварийное восстановление: перенаправление трафика из одного региона в другой

Как Диспетчер трафика Azure, так и Azure Front Door периодически проверяют работоспособность служб прослушивания конечных точек в разных реализациях VDC. Если эти конечные точки завершаются ошибкой, Диспетчер трафика Azure и Azure Front Door автоматически направляются к следующему ближайшему виртуальному центру данных. Диспетчер трафика использует измерение пользователей в режиме реального времени и DNS для маршрутизации пользователей в ближайший ВЦОД (или второй ближайший, в случае сбоя). Azure Front Door — это обратный прокси-сервер с более чем 100 пограничными сайтами в магистральной сети Майкрософт, который использует произвольную передачу для маршрутизацию пользователей на ближайшую конечную точку прослушивания.

Итоги

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

Ссылки

Дополнительные сведения о возможностях Azure, обсуждаемых в этом документе.

Сетевые функции
Виртуальные сети Azure
Группы безопасности сети
Конечные точки службы
Приватный канал
Определяемые пользователем маршруты
Виртуальные сетевые модули
Общедоступные IP-адреса
Azure DNS

Балансировка нагрузки
Azure Front Door
Подсистема балансировки нагрузки Azure (уровень 4)
Шлюз приложений (уровень 7)
Диспетчер трафика Azure

Подключение
Пиринг между виртуальными сетями
Виртуальная частная сеть
Виртуальная глобальная сеть
ExpressRoute
ExpressRoute Direct

Identity
Microsoft Entra ID
Многофакторная проверка подлинности Microsoft Entra
Управление доступом на основе ролей в Azure
Встроенные роли Azure

Мониторинг
Наблюдатель за сетями
Azure Monitor
Служба Log Analytics

Безопасность
Брандмауэр Azure
Диспетчер брандмауэра
Шлюз приложений — WAF
Front Door WAF
Azure DDoS

Другие службы Azure
Хранилище Azure
Azure SQL
Веб-приложения Azure
Azure Cosmos DB
HDInsight
Центры событий
Служебная шина
Azure IoT
Машинное обучение Azure

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

Узнайте больше о пиринге между виртуальными сетями, основной технологии, лежащей в основе звездообразных топологий.
Реализуйте идентификатор Microsoft Entra для использования управления доступом на основе ролей Azure.
Создайте модели подписки и управления ресурсами, используя управление доступом на основе ролей Azure в соответствии со структурой, требованиями и политиками вашей организации. Планирование является самым важным действием: Проанализируйте влияние реорганизаций, слияний, новых линеек продуктов и других рекомендаций на исходные модели, чтобы обеспечить возможность масштабирования в соответствии с будущими потребностями и дальнейшим ростом.

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