Подключение зоны передачи данных для одного региона
В конфигурации с единственным регионом зона управления данными, зоны размещения данных и все связанные службы устанавливаются в одном регионе. Все целевые зоны находятся в одной подписке концентратора подключения. Эта подписка содержит общие сетевые ресурсы, которые могут включать сетевое виртуальное устройство (например, брандмауэр Azure), шлюз ExpressRoute, шлюз виртуальной частной сети (VPN), виртуальную сеть концентратора или виртуальную глобальную сеть (концентратор vWAN).
Рис. 1. Подключение к одному региону.
В зависимости от текущих возможностей сетевых служб Azure рекомендуется использовать сетчатую сетевую архитектуру. Вам следует настроить пиринг виртуальных сетей между:
- Концентратор подключения и зона Управление данными
- Концентратор подключения и каждая целевая зона данных
- Зона Управление данными и каждая целевая зона данных
- Каждая целевая зона данных
В этой статье описываются преимущества и минусы каждого варианта сетевой архитектуры, рассмотренного для аналитики в масштабе облака.
Первый раздел этой статьи посвящен шаблону с одним регионом, где Управление данными зона и все целевые зоны данных размещаются в одном регионе.
Каждый шаблон конструктора оценивается с помощью следующих критериев:
- Себестоимость
- Управление доступом пользователей
- Управление сервисным обслуживанием
- Пропускная способность
- Задержка
Мы анализируем каждый вариант проектирования с учетом следующего сценария перекрестного использования зон размещения данных.
Примечание.
виртуальная машина B ( виртуальная машина B), размещенная в целевой зоне данных B, загружает набор данных из учетной записи хранения A, размещенной в целевой зоне данных A. Затем виртуальная машина B обрабатывает этот набор данных и сохраняет его в учетной записи хранения B, размещенной в целевой зоне данных B.
Внимание
Эта статья и другие статьи в разделе сети описывают меж бизнес-подразделения, которые совместно используют данные. Однако это может не быть вашей первоначальной стратегией и что вам нужно начать на базовом уровне сначала.
Создайте сеть, чтобы в конечном итоге реализовать рекомендуемую настройку между целевыми зонами данных. Убедитесь, что целевые зоны управления данными подключены непосредственно к целевым зонам для управления.
Архитектура сети с сеткой (рекомендуется)
При внедрении облачной аналитики рекомендуется использовать архитектуру сетки сети. Помимо существующей сетевой архитектуры концентратора и периферийной сети, настроенной в клиенте, необходимо выполнить два действия, чтобы реализовать архитектуру сетки сети:
- Добавьте пиринги виртуальной сети между всеми виртуальными сетями в зоне приземления данных.
- Добавьте пиринги виртуальной сети между Зоной приземления управления данными и всеми Зонами приземления данных.
В нашем примере данные, загруженные из учетной записи хранения A, проходят через подключение к пирингу виртуальной сети (2), установленное между двумя виртуальными сетями зон приема данных. Он загружается и обрабатывается виртуальной машиной B ((3) и (4)), а затем отправляется через локальную частную конечную точку (5) для хранения в учетной записи хранения B.
В этом сценарии данные не передаются через Центр подключения. Он остается в пределах платформы данных, которая состоит из целевой зоны управления данными и одной или нескольких целевых зон данных.
Рис. 2. Сетчатая архитектура сети.
Управление доступом пользователей в архитектуре сетчатой сети
В структуре сетевой архитектуры команды приложений данных требуют только двух вещей для создания новых служб (включая частные конечные точки):
- Запись доступа к выделенной группе ресурсов в целевой зоне данных
- Присоединение доступа к назначенной подсети
В этой структуре команды приложений данных могут самостоятельно развертывать частные конечные точки. Если у них есть необходимые права доступа для подключения частных конечных точек к подсети в заданной периферийной сети, команды не нуждаются в поддержке при настройке необходимого подключения.
Сводка: 
Управление службами в архитектуре сетки сети
В сетчатой архитектуре сетевой архитектуры виртуальный модуль не выступает в качестве одной точки сбоя или регулирования. Отсутствие наборов данных, отправляемых через Центр подключения, сокращает затраты центральной группы платформы Azure, если не нужно масштабировать это виртуальное устройство.
Это означает, что центральная группа платформы Azure больше не может проверять и регистрировать весь трафик, отправленный между целевыми зонами данных. Однако аналитика в масштабе облака — это последовательная платформа, охватывающая несколько подписок, которая позволяет масштабировать и преодолевать ограничения на уровне платформы, поэтому это не является недостатком.
При использовании всех ресурсов, размещенных в одной подписке, центральная группа платформы Azure больше не проверяет все данные в центре подключения. Журналы сети по-прежнему можно записывать с помощью журналов потока группы безопасности сети. Вы можете консолидировать и хранить другие журналы приложений и уровней обслуживания с помощью параметров диагностики для конкретной службы.
Все эти журналы можно записать в масштабе с помощью Политика Azure определений для параметров диагностики.
Эта конструкция также позволяет создавать собственное решение DNS Azure на основе зон Частная зона DNS. Жизненный цикл записи DNS A можно автоматизировать с помощью определений Политика Azure для частных групп DNS.
Сводка:
Затраты на сетевую архитектуру с сеткой
Примечание.
При доступе к частной конечной точке через пиринговую сеть плата взимается только за частную конечную точку, а не для пиринга виртуальной сети. Вы можете прочитать официальное заявление в разделе часто задаваемых вопросов: как будет выполняться выставление счетов при доступе к частной конечной точке из одноранговой сети?.
В этой структуре сети вы платите только за следующее:
- Частные конечные точки (в час)
- Входящий и исходящий трафик, отправленный через частные конечные точки для загрузки необработанного набора данных (1) и хранения обработанного набора данных (6)
Пиринг между виртуальными сетями не будет взиматься (2), поэтому этот параметр имеет минимальную стоимость.
Сводка:
Пропускная способность и задержка в ячеистой сетевой архитектуре
Эта конструкция не имеет известных ограничений пропускной способности или задержки, так как виртуальные сетевые устройства не ограничивают пропускную способность для обмена данными между зонами размещения данных. Единственным фактором ограничения дизайна является физическое ограничение наших центров обработки данных (скорость волоконно-оптических кабелей).
Сводка:
Сводка по архитектуре сети с сеткой
Если вы планируете внедрить облачную аналитику, рекомендуется использовать сетчатую сетевую структуру. Сеть с сеткой обеспечивает максимальную пропускную способность и низкую задержку с минимальными затратами, но не компрометирует управление доступом пользователей или уровень DNS.
Если необходимо применить другие политики сети на платформе данных, используйте группы безопасности сети, а не центральные сетевые виртуальные устройства.
Традиционная архитектура концентратора и периферийной архитектуры (не рекомендуется)
Проектирование сетевой архитектуры концентратора и периферийной сети является наиболее очевидным вариантом, который был принят многими предприятиями. В нем транзитивность сети настраивается в Центре подключения для доступа к данным в учетной записи хранения A из виртуальной машины B. Данные проходят через два пиринга виртуальных сетей ((2) и (5)) и сетевое виртуальное устройство, размещенное в Центре подключения ((3) и (4)). Затем данные загружаются виртуальной машиной (6) и хранятся обратно в учетную запись хранения B (8).
рис. 3. Архитектура концентратора и периферийной архитектуры.
Управление доступом пользователей в традиционной архитектуре Концентратора и периферийной архитектуры
В традиционной структуре концентратора и периферийной структуры команды приложений данных требуют только двух вещей для создания новых служб (включая частные конечные точки):
- Запись доступа к группе ресурсов в целевой зоне данных
- Присоединение доступа к назначенной подсети
В этой структуре команды приложений данных могут самостоятельно развертывать частные конечные точки. Если у них есть необходимые права доступа для подключения частных конечных точек к подсети в заданной периферийной сети, команды не нуждаются в поддержке при настройке необходимого подключения.
Сводка:
Управление сервисами в традиционной архитектуре центра и периферии
Эта сетевая конструкция хорошо известна и согласуется с существующей настройкой сети большинства организаций. Это упрощает разработку и реализацию. Вы также можете использовать централизованное решение AZURE DNS с зонами Частная зона DNS для предоставления полного доменного имени в клиенте Azure. Использование зон Частная зона DNS позволяет автоматизировать жизненный цикл записи DNS A с помощью политик Azure.
Еще одним преимуществом этой структуры является маршрутизация трафика через центральное сетевое виртуальное устройство, поэтому сетевой трафик, отправляемый из одной периферии в другой, можно регистрировать и проверять.
Одним из недостатков этой структуры является то, что центральная команда платформы Azure должна вручную управлять таблицами маршрутов. Это необходимо для обеспечения транзитивности между спицами, что позволяет совместно использовать данные в нескольких зонах приземления данных. Управление маршрутами может стать сложным и подверженным ошибкам с течением времени и должно быть рассмотрено заранее.
Еще одним недостатком этой настройки сети является способ настройки центрального сетевого виртуального устройства. Сетевое виртуальное устройство работает как единая точка сбоя и может привести к серьезному простою внутри платформы данных, если происходит сбой. Кроме того, по мере увеличения размера набора данных в пределах платформы данных, а число вариантов использования зоны размещения между данными увеличивается, больше трафика отправляется через центральное сетевое виртуальное устройство.
Со временем это может привести к гигабайтам или даже терабайтам данных, отправляемых через центральный экземпляр. Поскольку пропускная способность существующих сетевых виртуальных устройств часто ограничена только однозначной или двухзначной пропускной способностью гигабайта, центральный сетевой виртуальный модуль может стать узким местом, которое критически ограничивает поток трафика между целевыми зонами данных и ограничивает возможность совместного использования ресурсов данных.
Единственный способ избежать этой проблемы заключается в масштабировании центрального сетевого виртуального устройства в нескольких экземплярах, что имеет серьезные последствия для этой структуры.
Сводка: 
Стоимость традиционной архитектуры концентратора и периферийной архитектуры
Примечание.
При доступе к частной конечной точке через пиринговую сеть вы будете взиматься только за частную конечную точку, а не за пиринг виртуальной сети. Вы можете прочитать официальное заявление в разделе часто задаваемых вопросов: как будет выполняться выставление счетов при доступе к частной конечной точке из одноранговой сети?.
Для этой сети плата взимается в час за частные конечные точки учетных записей хранения. Вы также взимаете плату за входящий и исходящий трафик, отправленный через частные конечные точки, чтобы загрузить необработанный набор данных (1) и сохранить обработанный набор данных (8).
Клиенту выставляется плата за входящий и исходящий трафик одного пиринга виртуальной сети (5). Как упоминалось ранее, первый пиринг между виртуальными сетями не взимается (2).
В конечном итоге у вас будет высокая стоимость виртуального сетевого устройства, если используется этот сетевой дизайн ((3) и (4)). Вам нужно приобрести дополнительные лицензии и масштабировать центральное сетевое виртуальное устройство по требованию или оплатить плату за гигабайт, как это сделано с помощью Брандмауэр Azure.
Сводка:
Пропускная способность и задержка в традиционной архитектуре концентратора и периферийной архитектуры
Эта сетевая конструкция имеет серьезные ограничения пропускной способности. Центральное сетевое виртуальное устройство становится критически узким местом по мере роста платформы, что ограничивает варианты использования целевой зоны между данными и общий доступ к набору данных. Он также, скорее всего, создает несколько копий наборов данных с течением времени.
Эта конструкция также сильно влияет на задержку, которая становится особенно важной в сценариях аналитики в режиме реального времени.
Сводка:
Сводка по архитектуре традиционного концентратора и периферийной архитектуры
Этот концентратор и периферийный сетевой дизайн имеют управление доступом и некоторые преимущества управления службами, но из-за критических ограничений управления службами и пропускной способности и задержки мы не можем рекомендовать эту структуру сети для вариантов использования между зонами размещения данных.
Архитектура проецирования частной конечной точки (не рекомендуется)
Другой вариант проектирования — проекция частных конечных точек в каждой и каждой целевой зоне. В этом проекте в каждой целевой зоне создается частная конечная точка для учетной записи хранения A. Это приводит к первой частной конечной точке в целевой зоне данных A, подключенной к виртуальной сети в целевой зоне данных A, второй частной конечной точке, подключенной к виртуальной сети в целевой зоне данных B и т. д.
Это же относится к учетной записи хранения B и потенциально к другим службам в целевых зонах данных. Если определить количество целевых зон данных как n, то мы в конечном итоге будем использовать n частных конечных точек по крайней мере для всех учетных записей хранения и потенциально других служб в целевых зонах данных. Это приводит к экспоненциальному увеличению числа частных конечных точек.
Рис. 4. Архитектура проекции частной конечной точки.
Так как все частные конечные точки определенной службы (например, учетная запись хранения A) имеют то же полное доменное имя (например, напримерstorageaccounta.privatelink.blob.core.windows.net), это решение создает проблемы на уровне DNS, которые не могут быть решены с помощью зон Частная зона DNS. Вместо этого требуется пользовательское решение DNS, позволяющее разрешать DNS-имена на основе источника или IP-адреса запрашивающего. Это позволяет подключить виртуальную машину A к частным конечным точкам, подключенным к виртуальной сети в целевой зоне данных A, и подключить виртуальную машину B к частным конечным точкам, подключенным к виртуальной сети в целевой зоне данных B. Это можно сделать с помощью установки на основе Windows Server, в то время как вы можете автоматизировать жизненный цикл записей DNS A с помощью сочетания журналов действий и функций Azure.
В этой настройке можно загрузить необработанный набор данных в учетной записи хранения A в виртуальную машину B, доступ к набору данных через локальную частную конечную точку (1). После загрузки и обработки набора данных ((2) и (3)) его можно сохранить в учетной записи хранения B, напрямую получив доступ к локальной частной конечной точке (4). В этом сценарии данные не должны проходить через пиринги виртуальных сетей.
Управление доступами пользователей в архитектуре проецирования частной конечной точки
Такой подход к управлению доступом пользователей аналогичен архитектуре сетки сети. Однако в этом проекте можно требовать права доступа для других целевых зон данных, чтобы создавать частные конечные точки не только в указанной целевой зоне данных и виртуальной сети, но и в других целевых зонах данных и их соответствующих виртуальных сетях.
Из-за этого команды приложений данных требуют трех вещей, а не двух, чтобы иметь возможность создавать новые службы самостоятельно:
- Запись доступа к группе ресурсов в указанной целевой зоне данных
- Присоединение доступа к назначенной подсети
- Доступ к группе ресурсов и подсети во всех остальных целевых зонах данных для создания соответствующих локальных частных конечных точек
Эта схема сети повышает сложность уровня управления доступом, так как команды приложений данных требуют разрешений в каждой целевой зоне данных. Проектирование также может быть запутанным и привести к несогласованности RBAC с течением времени.
Если команды целевой зоны данных и команды приложений данных не имеют необходимых прав доступа, проблемы, описанные в традиционной архитектуре концентратора и периферийной архитектуры (не рекомендуется).
Сводка:
Управление службами в архитектуре проекции частной конечной точки
Несмотря на то, что эта сетевая архитектура снова похожа на архитектуру сетки, эта сетевая архитектура имеет преимущество без виртуального сетевого устройства, выступающего в качестве единой точки сбоя или регулирования пропускной способности. Это также снижает затраты на управление для центральной группы платформы Azure, не отправляя наборы данных через Центр подключения, так как не требуется масштабировать виртуальное устройство. Это означает, что центральная группа платформы Azure больше не может проверять и регистрировать весь трафик, отправленный между целевыми зонами данных. Однако аналитика в масштабе облака — это последовательная платформа, охватывающая несколько подписок, которая позволяет масштабировать и преодолевать ограничения на уровне платформы, поэтому это не является недостатком.
При использовании всех ресурсов, размещенных в одной подписке, трафик не проверяется в центре подключения. Вы по-прежнему можете записывать сетевые журналы с помощью журналов потока безопасности сети, а также консолидировать и хранить журналы других приложений и уровней обслуживания с помощью параметров диагностики для конкретной службы. Все эти журналы можно записать в большом масштабе с помощью политик Azure. С другой стороны, сетевое адресное пространство, необходимое для платформы данных, увеличивается из-за экспоненциального увеличения необходимых частных конечных точек, что не является оптимальным.
Основные проблемы, связанные с этой сетевой архитектурой, являются его ранее упомянутыми проблемами DNS. Вы не можете использовать встроенное решение Azure в виде частных DNS-зон, поэтому для этой архитектуры требуется стороннее решение, которое может разрешать полностью определённые доменные имена (FQDN) на основе источника или IP-адреса клиента. Кроме того, необходимо разработать и поддерживать средства и рабочие процессы для автоматизации частных записей DNS A, что значительно увеличивает затраты на управление по сравнению с предлагаемым решением, управляемым политикой Azure,.
Вы можете создать распределенную инфраструктуру DNS с помощью зон Частная зона DNS, но это создает DNS-острова, которые в конечном итоге вызывают проблемы при попытке доступа к службам приватного канала, размещенным в других целевых зонах в вашем клиенте. Поэтому этот дизайн не является жизнеспособным вариантом.
Сводка:
Архитектурные издержки проекции частных конечных точек
Примечание.
При доступе к частной конечной точке через пиринговую сеть вы будете взиматься только за частную конечную точку, а не за пиринг виртуальной сети. Вы можете прочитать официальное заявление в разделе часто задаваемых вопросов: как будет выполняться выставление счетов при доступе к частной конечной точке из одноранговой сети?.
В этой структуре сети взимается плата только за частные конечные точки (в час) и исходящий трафик, отправленный через эти частные конечные точки для загрузки необработанных наборов данных (1) и хранения обработанных наборов данных (4). Однако дополнительные затраты должны ожидаться из-за экспоненциального увеличения числа частных конечных точек платформы данных. Так как плата взимается в час, сумма дополнительных затрат зависит от того, сколько частных конечных точек создаются.
Сводка:
Пропускная способность и задержка в архитектуре проекции частной конечной точки
Эта конструкция не имеет известных ограничений пропускной способности и задержки, так как она не имеет сетевых виртуальных устройств, ограничивающих пропускную способность для обмена данными между целевыми зонами. Единственным фактором ограничения дизайна является физическое ограничение наших центров обработки данных (скорость волоконно-оптических кабелей).
Сводка:
Сводка по архитектуре проекции частной конечной точки
Экспоненциальный рост частных конечных точек в этой сетевой архитектуре может привести к потере отслеживания того, какие частные конечные точки используются для какой цели в каком расположении. Вы также ограничены проблемами управления доступом и сложностями уровня DNS. Из-за этих проблем мы не можем рекомендовать эту структуру сети для вариантов использования между зонами размещения данных.
Частные конечные точки в архитектуре узла подключения (не рекомендуется)
Другой вариант сети — разместить частные конечные точки в Концентраторе подключения и подключить их к виртуальной сети Концентратора. В этом решении размещается одна частная конечная точка для каждой службы в корпоративной виртуальной сети. Из-за существующей сетевой архитектуры концентратора и периферийной сети в большинстве корпораций, и тот факт, что Центр подключения размещает частные конечные точки в этом решении, транзитивность не требуется. Виртуальная сеть пиринга между вашим узлом подключения и зонами приема данных обеспечивает прямой доступ.
Данные проходят по одному пирингу виртуальной сети между Концентратором подключения и целевой зоной данных, чтобы загрузить набор данных, хранящийся в учетной записи хранения A в виртуальной машине B. После загрузки и обработки этого набора данных ((3) и (4)) он проходит через один и тот же пиринг виртуальной сети второй раз (5), прежде чем, наконец, храниться в учетной записи хранения B через частную конечную точку, подключенную к виртуальной сети Концентратора (6).
рис. 5. Частные конечные точки в архитектуре Центра подключения.
Управление доступом пользователей в архитектуре Центра подключения
В этой сетевой структуре команды целевой зоны данных и команды приложений данных должны иметь два способа подключения частных конечных точек к виртуальной сети Концентратора:
- Разрешение на запись в группу ресурсов в подписке Центра подключений
- Присоединение разрешений к виртуальной сети Концентратора
Центр подключения предназначен для группы платформы Azure организации и предназначен для размещения необходимой и общей сетевой инфраструктуры организации (включая брандмауэры, шлюзы и средства управления сетями). Этот сетевой параметр делает этот проект несогласованным, так как он не следует принципам управления доступом из базовых принципов зоны высадки Enterprise-Scale. Поэтому большинство команд платформ Azure не утверждают этот вариант проектирования.
Сводка:
Управление службами в архитектуре Центра подключения
Несмотря на то, что такая архитектура сети похожа на архитектуру сетки, этот проект не имеет виртуального сетевого устройства, выступающего в качестве одной точки сбоя или регулирования пропускной способности. Это также снижает затраты на управление для центральной группы платформы Azure, не отправляя наборы данных через Центр подключения, так как не требуется масштабировать виртуальное устройство. Это означает, что центральная группа платформы Azure больше не может проверять и регистрировать весь трафик, отправленный между целевыми зонами данных. Однако аналитика в масштабе облака — это последовательная платформа, охватывающая несколько подписок, которая позволяет масштабировать и преодолевать ограничения на уровне платформы, поэтому это не является недостатком.
При использовании всех ресурсов, размещенных в одной подписке, трафик не проверяется в центре подключения. Вы по-прежнему можете записывать сетевые журналы с помощью журналов потока безопасности сети, а также консолидировать и хранить журналы других приложений и уровней обслуживания с помощью параметров диагностики для конкретной службы. Все эти журналы можно записать в большом масштабе с помощью политик Azure.
Эта конструкция также позволяет создавать собственное решение DNS Azure на основе зон Частная зона DNS и позволяет автоматизировать жизненный цикл записи DNS С помощью политик Azure.
Сводка:
Затраты на архитектуру концентратора подключения
Примечание.
При доступе к частной конечной точке через пиринговую сеть вы будете взиматься только за частную конечную точку, а не за пиринг виртуальной сети. Вы можете прочитать официальное заявление в разделе часто задаваемых вопросов: как будет выполняться выставление счетов при доступе к частной конечной точке из одноранговой сети?.
В этой структуре сети взимается плата только за частные конечные точки (в час) и входящий и исходящий трафик, отправленный через эти частные конечные точки, чтобы загрузить необработанный набор данных (1) и сохранить обработанный набор данных (6).
Сводка:
Пропускная способность и задержка в архитектуре концентратора подключения
Эта конструкция не имеет известных ограничений пропускной способности и задержки, так как она не имеет сетевых виртуальных устройств, ограничивающих пропускную способность для обмена данными между целевыми зонами. Единственным фактором ограничения дизайна является физическое ограничение наших центров обработки данных (скорость волоконно-оптических кабелей).
Сводка:
Общие сведения о частных конечных точках в обзоре архитектуры Центра подключения
Хотя эта архитектура сети имеет несколько преимуществ, ее ранее упомянутые несоответствия управления доступом делают его вложенным. Поэтому мы не можем рекомендовать этот подход к проектированию.
Заключение о подключении к зоне размещения данных одного региона
Из всех проверенных параметров сетевой архитектуры и их плюсов и минусов , сетка сетевой архитектуры является явным победителем. Это имеет огромные преимущества для пропускной способности и управления, поэтому мы рекомендуем использовать его при развертывании облачной аналитики. Пиринговые периферийные виртуальные сети ранее не были общими, и это привело к проблемам совместного использования наборов данных между доменами и бизнес-подразделениями.
Аналитика в облаке можно просматривать как согласованное решение, охватывающее несколько подписок. В одной настройке подписки поток сетевого трафика равен потоку в сетевой архитектуре. В рамках одной настройки подписки пользователи, скорее всего, ударят по ограничениям и квотам уровня подписки платформы, которые облачная аналитика стремится избежать.