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

Приложения, перенесенные из локальной среды, могут использовать преимущества безопасной и экономичной инфраструктуры 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, а также для предотвращения проблем, связанных с созданием всех компонентов по отдельности в концентраторе пиринга между виртуальными сетями. В некоторых случаях ваши требования могут диктовать структуру концентратора пиринга между виртуальными сетями, например определять потребность в сетевых виртуальных модулях в концентраторе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Компоненты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

, определяемые пользователем маршруты и группы безопасности сети. и брандмауэр веб-приложения (WAF) с брандмауэром веб-приложения (WAF) и Диспетчер брандмауэра Azure

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

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

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

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

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

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

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

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

Различные сферы деятельности обычно используют множество веб-приложений, которые, как правило, являются уязвимыми. Брандмауэры веб-приложений — это особый тип продукта, который используется для обнаружения атак на веб-приложения и 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 на уровне клиента (например, Azure Active Directory).
Пользовательские источники. Также можно включить журналы, отправляемые из локальных источников. В качестве примера можно привести события локального сервера или выходные данные системного журнала для сетевых устройств.

Данные мониторинга полезны, только если они могут сделать работу вычислительной среды более открытой. 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, обсуждаемых в этом документе.

📎📎📎📎📎📎📎📎📎📎

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

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

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

Рекомендации по реализации виртуального центра обработки данных

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

Ссылки