Гибридная сетевая инфраструктура в Microsoft Azure (часть 10)

• Гибридная сетевая инфраструктура в Microsoft Azure (часть 1)
• Гибридная сетевая инфраструктура в Microsoft Azure (часть 2)
• Гибридная сетевая инфраструктура в Microsoft Azure (часть 3)
• Гибридная сетевая инфраструктура в Microsoft Azure (часть 4)
• Гибридная сетевая инфраструктура в Microsoft Azure (часть 5)
• Гибридная сетевая инфраструктура в Microsoft Azure (часть 6)
• Гибридная сетевая инфраструктура в Microsoft Azure (часть 8)
• Гибридная сетевая инфраструктура в Microsoft Azure (часть 9)
• Гибридная сетевая инфраструктура в Microsoft Azure (часть 11)

Введение

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

Затем в части 4 мы потратили большую часть нашего времени на обсуждение того, что такое виртуальные сети Azure и как они сравниваются с виртуальными сетями, которые мы используем в традиционных локальных установках Hyper-V. В части 5 были более подробно описаны виртуальные сети Azure и некоторые особенности, которые необходимо учитывать. В части 6 мы обсудили виртуальные сети Azure и внешние балансировщики нагрузки. В части 7 мы начали обсуждение внутренней балансировки нагрузки и того, как использовать PowerShell для настройки ILB для виртуальных машин, содержащихся в виртуальной сети Azure. В части 8 мы перешли к настройке ILB для облачных служб, отредактировав файл.cscfg, а затем рассказали о группах безопасности сети.

В части 9 мы говорили о списках ACL для виртуальных машин, которые можно использовать для предоставления выборочного удаленного доступа к виртуальным машинам, которые вы размещаете в виртуальных сетях Azure. Мы также говорили о некоторых альтернативах использованию списков ACL для виртуальных машин, которые во многих отношениях могут быть более безопасными, чем настройка списков ACL. Кроме того, списки ACL виртуальных машин нельзя использовать на виртуальных машинах на базе управления службами Azure (ARM).

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

√ Виртуальные частные сети между сайтами

√ Виртуальные частные сети типа «укажи на сайт»

√ Выделенные каналы WAN

√ Виртуальные сетевые шлюзы

√ Виртуальные сети Azure

√ Возможность подключения к виртуальной сети

√ Внешние балансировщики нагрузки

√ Внутренние балансировщики нагрузки

√ Группы безопасности сети

√ ACL виртуальной машины

> Двойной дом

> Сторонние брандмауэры

• Выделенные общедоступные IP-адреса
• Статические IP-адреса на виртуальных машинах
• Публичные адреса на виртуальных машинах
• DNS

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

Виртуальные машины с несколькими сетевыми картами

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

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

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

В дополнение к группам безопасности сети у нас также были «брандмауэры» веб-приложений на основе прокси. Я взял слово «брандмауэры» в кавычки, потому что, несмотря на название, они не были похожи на наши современные надежные сетевые брандмауэры. Эти так называемые «брандмауэры» были просто устройствами с одной сетевой картой, которые на самом деле являются прокси-устройствами, а не брандмауэрами. Устройства веб-прокси, как правило, представляют собой машины с одной сетевой картой, и если вы помните, как Том говорил о брандмауэрах ISA с «режимом работы», вы поймете, что я имею в виду. Конечно, у прокси и брандмауэров некоторые общие черты, и мы знаем, что на самом деле брандмауэр ISA был прямым потомком Microsoft Proxy Server. Однако мы также знаем, что одно из важных различий между прокси-серверами и брандмауэрами заключается в том, что первые легко обойти, поскольку они не обеспечивают сегментацию и изоляцию сети.

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

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

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

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

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

Независимо от модели развертывания (ASM или ARM) все компьютеры, находящиеся в одной облачной службе (ASM) или группе ресурсов (ARM), должны иметь один или несколько сетевых адаптеров.

Примечание:
Возможно, вы помните, что ASM относится к Azure Service Management, а ARM — к Azure Resource Manager, которые представляют собой два разных REST API, которые можно использовать для предоставления доступа к службам Azure и функциям платформы, включая виртуальные машины Azure и виртуальные сети Azure. У каждого есть свои преимущества и недостатки, но ARM — более новая модель, которая более или менее заменила ASM. Вы также можете услышать/прочитать, что ASM называют «классической» моделью развертывания. Microsoft рекомендует использовать ARM для большинства новых развертываний.

Все виртуальные машины с несколькими сетевыми картами должны находиться в виртуальной сети Azure.

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

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

Резюме

В этой 10-й части нашей серии статей о создании и управлении гибридной сетевой инфраструктурой в Microsoft Azure мы погрузились в удивительный мир поддержки нескольких сетевых карт, которая была добавлена в Azure в 2014 году, и начали обсуждать некоторые рекомендации, предостережения и «подводные камни», которые относятся к использованию этой функции. В Части 11 мы продолжим и завершим это обсуждение, так что обязательно присоединяйтесь к нам.

• Гибридная сетевая инфраструктура в Microsoft Azure (часть 1)
• Гибридная сетевая инфраструктура в Microsoft Azure (часть 2)
• Гибридная сетевая инфраструктура в Microsoft Azure (часть 3)
• Гибридная сетевая инфраструктура в Microsoft Azure (часть 4)
• Гибридная сетевая инфраструктура в Microsoft Azure (часть 5)
• Гибридная сетевая инфраструктура в Microsoft Azure (часть 6)
• Гибридная сетевая инфраструктура в Microsoft Azure (часть 8)
• Гибридная сетевая инфраструктура в Microsoft Azure (часть 9)