Подключение к целевой зоне данных в одном регионе

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

Рис. 1. Однорегионная Подключение тивность.

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

• Концентратор Подключение и зона Управление данными
• Концентратор Подключение тивности и каждая целевая зона данных
• Зона Управление данными и каждая целевая зона данных
• Каждая целевая зона данных

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

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

Каждый шаблон конструктора оценивается с помощью следующих критериев:

• Себестоимость
• Управление доступом пользователей
• Управление сервисным обслуживанием
• Пропускная способность
• Задержка

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

Примечание.

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

Внимание

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

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

Архитектура одноранговой сети (рекомендуется)

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

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

В нашем примере данные, загруженные из служба хранилища Account A, передает подключение пиринга виртуальной сети (2) между двумя виртуальными сетями целевой зоны данных. Он загружается и обрабатывается виртуальной машиной B ((3) и (4)), а затем отправляется через локальную частную конечную точку (5) для хранения в служба хранилища account B.

В этом сценарии данные не передают центр Подключение ivity Hub. Он остается в пределах платформы данных, которая состоит из целевой зоны управления данными и одной или нескольких целевых зон данных.

Рис. 2. Архитектура сетки сети.

Управление доступом пользователей в сетке сетевой архитектуры

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

• Запись доступа к выделенной группе ресурсов в целевой зоне данных
• Присоединение доступа к назначенной подсети

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

Сводка:

Управление службами в сетке сетевой архитектуры

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

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

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

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

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

Сводка:

Стоимость архитектуры одноранговой сети

Примечание.

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

В этой структуре сети вы платите только за следующее:

• Частные конечные точки (в час)
• Входящий и исходящий трафик, отправленный через частные конечные точки для загрузки необработанного набора данных (1) и хранения обработанного набора данных (6)

Пиринг виртуальных сетей не будет взиматься (2), поэтому этот вариант имеет минимальную стоимость.

Сводка:

Пропускная способность и задержка в сетевой архитектуре

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

Сводка:

Сводная информация об архитектуре одноранговой сети

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

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

Традиционная архитектура концентратора и периферийной архитектуры (не рекомендуется)

Проектирование сетевой архитектуры концентратора и периферийной сети является наиболее очевидным вариантом, который был принят многими предприятиями. В нем транзитивность сети настраивается в центре Подключение ivity Hub для доступа к данным в служба хранилища account A из виртуальной машины B. Данные проходят через два пиринга виртуальных сетей ((2) и (5)) и виртуальную (модуль) сети, размещенную в центре Подключение ivity Hub ((3) и (4)). Затем данные загружаются виртуальной машиной (6) и хранятся обратно в учетную запись служба хранилища B (8).

Рис. 3. Архитектура концентратора и периферийной архитектуры.

Управление доступом пользователей в традиционной архитектуре концентратора и периферийной архитектуры

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

• Запись доступа к группе ресурсов в целевой зоне данных
• Присоединение доступа к назначенной подсети

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

Сводка:

Управление службами в традиционной архитектуре концентратора и периферийной архитектуры

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

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

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

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

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

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

Сводка:

Стоимость традиционной архитектуры концентратора и периферийной архитектуры

Примечание.

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

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

Клиент взимается за входящий трафик и исходящий трафик одного пиринга виртуальной сети (5). Как ранее упоминание, первый пиринг виртуальной сети не взимается (2).

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

Сводка:

Пропускная способность и задержка в традиционной архитектуре концентратора и периферийной архитектуры

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

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

Сводка:

Сводка по традиционной архитектуре концентратора и периферийной архитектуры

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

Архитектура проекции частной конечной точки (не рекомендуется)

Другой вариант проектирования — проекция частных конечных точек в каждой и каждой целевой зоне. В этой структуре частная конечная точка для служба хранилища Account A создается в каждой целевой зоне. Это приводит к первой частной конечной точке в целевой зоне данных A, подключенной к виртуальной сети в целевой зоне данных A, второй частной конечной точке, подключенной к виртуальной сети в целевой зоне данных B и т. д.

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

Рис. 4. Архитектура проекции частной конечной точки.

Так как все частные конечные точки определенной службы (например, служба хранилища Account A) имеют одинаковые полные доменные имена (напримерstorageaccounta.privatelink.blob.core.windows.net), это решение создает проблемы на уровне DNS, который не может быть решен с помощью зон Частная зона DNS. Вместо этого вам потребуется пользовательское решение DNS, позволяющее разрешать DNS-имена на основе источника или IP-адреса запрашивающего объекта. Это позволяет подключить виртуальную машину к частным конечным точкам, подключенным к виртуальной сети в целевой зоне данных A, и подключить виртуальную машину B к частным конечным точкам, подключенным к виртуальной сети в целевой зоне данных B. Это можно сделать с помощью установки на основе Windows Server, в то время как вы можете автоматизировать жизненный цикл записей DNS A с помощью сочетания журналов действий и Функции Azure.

В этой настройке можно загрузить необработанный набор данных в служба хранилища Account A в виртуальную машину B путем доступа к набору данных через локальную частную конечную точку (1). После загрузки и обработки набора данных ((2) и (3)) его можно сохранить в учетной записи B служба хранилища, напрямую получив доступ к локальной частной конечной точке (4). В этом сценарии данные не должны проходить через пиринги виртуальной сети.

Управление доступом пользователей в архитектуре проекции частной конечной точки

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

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

• Запись доступа к группе ресурсов в указанной целевой зоне данных
• Присоединение доступа к назначенной подсети
• Доступ к группе ресурсов и подсети во всех остальных целевых зонах данных для создания соответствующих локальных частных конечных точек

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

Если команды целевой зоны данных и команды приложений данных не имеют необходимых прав доступа, проблемы, описанные в традиционной архитектуре концентратора и периферийной архитектуры (не рекомендуется).

Сводка:

Управление службами в архитектуре проекции частной конечной точки

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

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

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

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

Сводка:

Стоимость архитектуры проекции частной конечной точки

Примечание.

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

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

Сводка:

Пропускная способность и задержка в архитектуре проекции частной конечной точки

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

Сводка:

Сводка по архитектуре проекции частной конечной точки

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

Частные конечные точки в архитектуре центра Подключение ivity Hub (не рекомендуется)

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

Данные проходят по одному пирингу виртуальной сети между концентратором Подключение и целевой зоной данных, чтобы загрузить набор данных, хранящийся в служба хранилища account A в виртуальной машине B. После загрузки и обработки набора данных ((3) и (4)) он проходит через один и тот же пиринг виртуальной сети в секунду (5), прежде чем, наконец, храниться в служба хранилища Account B через частную конечную точку, подключенную к виртуальной сети Концентратора (6).

Рис. 5. Частные конечные точки в архитектуре центра Подключение тивности.

Управление доступом пользователей в архитектуре центра Подключение ivity Hub

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

• Разрешение на запись в группу ресурсов в подписке Подключение ivity Hub
• Присоединение разрешений к виртуальной сети Концентратора

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

Сводка:

Управление службами в архитектуре центра Подключение ivity Hub

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

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

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

Сводка:

затраты на архитектуру центра Подключение

Примечание.

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

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

Сводка:

Пропускная способность и задержка в архитектуре центра Подключение ivity Hub

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

Сводка:

Общие сведения об архитектуре частных конечных точек в Подключение концентраторе

Хотя эта архитектура сети имеет несколько преимуществ, ее ранее упоминание несоответствия управления доступом делают его вложенным. Поэтому мы не можем рекомендовать этот подход к проектированию.

Вывод подключения к целевой зоне данных в одном регионе

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

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

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

• Подключение тивность целевой зоны данных между регионами