Подключение к целевой зоне данных между регионами
Если у вас есть присутствие в нескольких регионах Azure и требуется разместить платформу данных и приложения данных в нескольких географических регионах, подключение становится немного сложнее.
Развертывания в нескольких регионах обычно имеют подписку узла подключения в каждом отдельном регионе Azure. Например, если у вас есть службы, работающие как в восточной части США, так и в Западной Европе, вы настроили подписку концентратора подключения с общими сетевыми ресурсами в каждом регионе. Общие сетевые ресурсы включают:
- Сетевые виртуальные устройства (например, брандмауэр Azure)
- Шлюзы ExpressRoute
- VPN-шлюзы
- Виртуальные сети концентратора (в центральной и периферийной архитектуре) или концентраторы vWAN (в настройке виртуальной глобальной сети)
рис. 1. Подключение между регионами.
В архитектуре центральной узловой сети виртуальные сети соединительных узлов часто подключаются с помощью глобального пиринга виртуальных сетей. Для более крупных сред распространенная альтернатива — использовать ExpressRoute Global Reach. Независимо от выбранного варианта подключения можно достичь глобальной маршрутизации и подключения между периферийными сетями в нескольких географических регионах. Это означает, что данные можно перемещать по регионам с помощью сетевых виртуальных устройств, групп безопасности сети и таблиц маршрутов, учитывая, что трафик не блокируется в любой подписке на подключение.
Важный
Эта статья и другие статьи в разделе сетей освещают взаимодействие между бизнес-подразделениями, которые совместно используют данные. Однако это может не быть вашей первоначальной стратегией и что вам нужно начать на базовом уровне сначала.
Спроектируйте вашу сеть так, чтобы можно было реализовать рекомендуемую нами настройку между зонами выгрузки данных. Убедитесь, что зоны приземления для управления данными подключены непосредственно к зонам приземления для руководства.
Пиринг глобальной виртуальной сети (рекомендуется)
Зоны приземления данных можно подключать между регионами с помощью непосредственного глобального пиринга виртуальных сетей. В этой конфигурации, если мы продолжим предыдущую ситуацию, виртуальная машина в Западной Европе обращается к частной конечной точке учетной записи хранения в Восточных США напрямую, без использования каких-либо сетевых архитектур типа hub-and-spoke или виртуальной WAN. Данные загружаются непосредственно виртуальной машиной через частную конечную точку, обрабатываются, а затем хранятся обратно в учетной записи хранения в Западной Европе.
Управление доступом пользователей в пиринге глобальной виртуальной сети
Ни для одного из предложенных вариантов подключения между регионами к зоне приземления данных нет особых плюсов или минусов.
Сводка: 
/
Управление сервисами в пиринге глобальной виртуальной сети
Пиринг глобальной виртуальной сети не имеет сетевого виртуального устройства, которое выступает в роли единственной точки сбоя или ограничивает пропускную способность. Данные не отправляются через центры подключения, поэтому вам не нужно масштабировать виртуальные устройства и шлюзы в центрах подключения. Это отсутствие масштабирования снижает затраты на управление для основной группы платформы Azure. Кроме того, вам не нужно разрешать отдельные подключения между регионами. Группы данных могут получать доступ к данным из целевых зон данных в других регионах, не ожидая изменений таблицы маршрутов.
В этой сетевой структуре центральная группа платформы Azure больше не может проверять и регистрировать весь трафик с помощью брандмауэра уровня 7. Однако сценарий облачной аналитики — это согласованная платформа, охватывающая несколько подписок, которая позволяет масштабировать и преодолевать ограничения на уровне платформы, поэтому это не является недостатком. Вы можете собирать сетевые логи с помощью журналов потоков группы безопасности сети. Вы можете консолидировать и хранить другие журналы приложений и уровней обслуживания с помощью параметров диагностики для конкретной службы.
Все эти журналы можно записать в большом масштабе с помощью определений политики Azure для параметров диагностики.
В некоторых сценариях необходимо ограничиться из-за нормативных или юридических последствий. Например, у вас может быть локальное регулирование, которое требует, чтобы определенные наборы данных оставались в центре обработки данных, поэтому их нельзя передавать по регионам. Вы можете полагаться на группы безопасности сети, чтобы помочь вам соответствовать этому типу правила, только позволяя трафику перемещаться в одном направлении из Восточной ЧАСТИ США в Западную Европу, а не наоборот. В группах безопасности сети можно убедиться, что трафик, исходящий из Восточной части США, запрещен, а трафик, исходящий из Западной Европы, разрешен.
Этот подход решения не влияет на пропускную способность и задержку, и позволяет клиентам оставаться совместимыми, сохраняя при этом объединение наборов данных из нескольких регионов. Этот параметр также не влияет на архитектуру DNS и позволяет использовать собственное решение Azure на основе частных зон DNS Azure.
Сводка:
Стоимость пиринга глобальной виртуальной сети
Заметка
При доступе к частной конечной точке через сеть, связанную через пиринг, вы будете платить только за частную конечную точку, а не за пиринг виртуальной сети. Вы можете прочитать официальное заявление в вопросы и ответы: как будет работать выставление счетов при доступе к частной конечной точке из одноранговой сети?.
С помощью этой структуры сети плата взимается за частные конечные точки (в час) и весь входящий и исходящий трафик, отправленный через них. Кроме того, необходимо платить стоимость передачи данных для трафика между регионами. Тем не менее, с вас не будет взиматься плата за затраты на пиринг глобальной виртуальной сети на входящий и исходящий трафик, и это имеет заметные преимущества по сравнению с традиционным вариантом концентратор-шина-шина-концентратор.
Сводка:
Пропускная способность и задержка в пиринге глобальной виртуальной сети
Влияние на пропускную способность и задержку ниже в глобальной виртуальной сети с пирингом, чем в традиционной схеме "спица-хаб-хаб-спица". Пиринг глобальной виртуальной сети обеспечивает меньшее количество переходов при обмене данными между зонами приземления данных в разных регионах и не требует сетевых виртуальных приложений, ограничивающих пропускную способность. Единственное, что диктует пропускную способность и задержку, которые можно достичь для трафика между регионами, это физические ограничения наших центров обработки данных (скорость волоконно-оптических кабелей, шлюзов и маршрутизаторов).
Сводка:
Сводка по пирингу глобальной виртуальной сети
Пиринг глобальной виртуальной сети между зонами приземления данных в разных регионах обеспечивает огромные преимущества, особенно по мере того, как трафик данных между регионами увеличивается в пределах вашей платформы данных. Это упрощает управление службами для команды основной платформы Azure и особенно помогает в сценариях использования, требующих низкой задержки и высокой пропускной способности. Он также предлагает значительные выгодные изменения стоимости по сравнению с традиционным вариантом проектирования сети по принципу спица-узел-узел-спица.
Традиционная архитектура топологии спица-концентратор-концентратор-спица (не рекомендуется)
Другой вариант передачи данных между регионами — это традиционная архитектура "спица-колесный центр". В нашем примере, если виртуальная машина в зоне приема данных A, размещенной в Западной Европе, загружает набор данных, хранящийся в учетной записи хранения из зоны приема данных B, размещенной в Восточной части США, данные проходят два пиринга локальной виртуальной сети (подключение между центральными и периферийными узлами), один глобальный пиринг виртуальной сети (подключение между центральными узлами) и два шлюза или сетевых виртуальных устройства, прежде чем они загружаются виртуальной машиной, а затем перемещаются обратно в локальную учетную запись хранения.
Управление доступом пользователей в традиционном дизайне spoke-hub-hub-spoke
Для любого из предлагаемых вариантов подключения к целевой зоне данных между регионами нет конкретных плюсов или минусов.
Сводка:
/
Управление службами в традиционной схеме "спица-втулка-втулка-спица"
Этот подход решения хорошо известен и согласуется с другими шаблонами подключения между регионами, что упрощает внедрение и реализацию. Он также не влияет на архитектуру DNS и позволяет использовать собственное решение Azure на основе частных зон DNS Azure.
Хотя этот параметр подключения работает без проблем при правильной настройке, он имеет недостатки. Трафик между регионами часто блокируется по умолчанию и должен быть включен в каждом отдельном случае. Запрос должен быть отправлен в основную команду платформы Azure для каждого отдельного требования к доступу данных между регионами, чтобы ваша команда могла разрешить каждое конкретное подключение между виртуальной машиной и учетной записью хранения в другом регионе. Этот процесс значительно увеличивает затраты на управление. Он также замедляет работу команд проектов данных, так как они не могут получить доступ к нужным данным.
Кроме того, следует отметить, что в этом параметре центры подключения выполняют роль отдельных точек сбоя. При простое сетевого виртуального устройства или шлюза связь и соответствующие платформы данных выходят из строя. Кроме того, в центрах подключения есть высокий риск неправильной настройки маршрутов. Такая неправильное настройка может привести к более серьезному простою на платформе данных и привести к ряду зависимых рабочих процессов и сбоев продуктов данных.
При использовании этого подхода следует отслеживать объем данных, необходимых для передачи по регионам. Со временем этот мониторинг может охватывать гигабайты или терабайты данных, передаваемых через центральные узлы. Так как пропускная способность виртуальных сетевых устройств часто ограничена пропускной способностью одного или двухзначного гигабайта, устройства могут выступать в качестве критического узких мест, ограничивающих поток трафика между регионами и возможность совместного использования ресурсов данных. Из-за этого узкого места ресурсы вашей общей сети могут требовать внедрения механизмов масштабирования, что часто занимает много времени и требует значительных затрат, и могут повлиять на другие рабочие нагрузки в вашем тенанте.
Сводка:
Традиционные затраты на проектирования модели "Спица-хаб-Hub-Spoke"
Заметка
При доступе к частной конечной точке через одноранговую сеть, вам будет начислена плата только за саму частную конечную точку, а не за сам пиринг виртуальной сети. Вы можете прочитать официальное заявление в разделе часто задаваемых вопросов : как будет работать биллинг при доступе к частной конечной точке из одноранговой сети?.
В традиционном радиально-концентрическом дизайне с вас взымается плата за ваши две конечные точки для частного доступа учетных записей хранения (в час) и за весь входящий и исходящий трафик, отправленный через них. Кроме того, взимается плата за входящий и исходящий трафик в случае одного пиринга локальной виртуальной сети и пиринга глобальной виртуальной сети между центрaми подключения. Однако вы не взимаете плату за первый пиринг виртуальных сетей, как описано в предыдущем примечание.
Ваши центральные сетевые виртуальные устройства также несут значительные затраты, если вы выберете эту структуру сети. Эта стоимость обусловлена тем, что вам придется приобрести дополнительные лицензии для масштабирования устройств на основе спроса или оплаты за обработанный гигабайт, как и в брандмауэре Azure.
Сводка:
Пропускная способность и задержка в традиционном дизайне «спица-узел-узел-спица».
Эта сетевая конструкция имеет серьезные ограничения пропускной способности. Ваши центральные сетевые виртуальные устройства становятся критически узкими местами по мере роста платформы, что ограничивает варианты использования целевой зоны данных между регионами и совместное использование наборов данных. Кроме того, с течением времени создается несколько копий наборов данных. Эта конструкция также сильно влияет на задержку, которая особенно важна для сценариев аналитики в режиме реального времени, так как данные проходят много прыжков.
Сводка:
Проектирование традиционного периферийного концентратора-концентратора
Проектирование по схеме спица-колесо-колесо-спица хорошо известно и введено во многих организациях, что упрощает внедрение в существующей среде. Однако она имеет значительные недостатки для управления службами, затрат, пропускной способности и задержки. Эти проблемы особенно заметны по мере роста числа вариантов использования между регионами.
Заключение
Глобальный пиринг виртуальных сетей имеет множество преимуществ по сравнению с традиционными шина-звезда-шина, так как он экономичен, легко управляем и обеспечивает надежное подключение между регионами. Хотя традиционный спицеобразный концентратор-концентратор может быть жизнеспособным вариантом, пока объем данных и необходимость обмена данными между регионами невелика, мы рекомендуем использовать подход пиринга глобальной виртуальной сети, когда объем данных, которые необходимо обменивать между регионами, увеличивается.