Отличные новости для тех, кто уже использует Microsoft Azure и тех, кто только планирует это делать. В июле вышло большое обновление платформы Azure. Уверен, в обширном списке нововведений каждый найдёт для себя что-то особенно важное. Для меня это, без сомнения VNET Peering.
Наконец-то, появилась возможность связывать VNET непосредственно между собой. Это открывает новые возможности для построения виртуальной инфраструктуры на базе облака Microsoft. Подробности под катом.
В чём собственно проблема и почему это обновление так важно? VNET- виртуальная сеть в облаке Azure, набор подсетей с некоторыми общими характеристиками и возможностью внутренней маршрутизации без дополнительных устройств. Для того чтобы получить маршрутизацию траффика между VNET и другими сетями (другими вашими VNET, вашей on-premises сетью, VNET в других подписках Azure) вам нужно добавить Virtual Gateway, который позволит вам настраивать VPN соединения. Именно так раньше нам предлагал поступать Microsoft.
Особенно неприятно всё становилось, если вы использовали ExpressRoute. Дело в том, что вы могли создать только один Virtual Gateway в VNET, а тип gateway для VPN и ExpressRoute был разный. В итоге, приходилось создавать ExpressRoute Virtual Gateway в каждом вашем VNET и связать их все с ExpressRoute соединением. А что если вам хочется добиться маршрутизации в VNET в другой подписке? А если вы хотите изолировать какой-то VNET от ExpressRoute, но сохранить его связность с другими VNET? Приходилось искать нетривиальные решения.
Теперь всё меняется. Одно из нововведений в анонсе выше, это выход VNET Peering в public preview. Очень приятно, что, согласно заявлению Microsoft, мы получаем возможность связывать VNET не только внутри подписки и между подписками, но и Azure Service Manager VNET и Azure Resource Manager VNET. В качестве бонуса, траффик VNET Peering идет внутри инфраструктуры Azure, не проходя через дополнительное виртуальное устройство, что повышает надежность такого соединения и увеличивает его скорость.
К сожалению, мне пока не удалось найти технических деталей по использованию этого функционала. Как только я их найду они обязательно появятся на Habrahabr.
Наконец-то, появилась возможность связывать VNET непосредственно между собой. Это открывает новые возможности для построения виртуальной инфраструктуры на базе облака Microsoft. Подробности под катом.
В чём собственно проблема и почему это обновление так важно? VNET- виртуальная сеть в облаке Azure, набор подсетей с некоторыми общими характеристиками и возможностью внутренней маршрутизации без дополнительных устройств. Для того чтобы получить маршрутизацию траффика между VNET и другими сетями (другими вашими VNET, вашей on-premises сетью, VNET в других подписках Azure) вам нужно добавить Virtual Gateway, который позволит вам настраивать VPN соединения. Именно так раньше нам предлагал поступать Microsoft.
Особенно неприятно всё становилось, если вы использовали ExpressRoute. Дело в том, что вы могли создать только один Virtual Gateway в VNET, а тип gateway для VPN и ExpressRoute был разный. В итоге, приходилось создавать ExpressRoute Virtual Gateway в каждом вашем VNET и связать их все с ExpressRoute соединением. А что если вам хочется добиться маршрутизации в VNET в другой подписке? А если вы хотите изолировать какой-то VNET от ExpressRoute, но сохранить его связность с другими VNET? Приходилось искать нетривиальные решения.
Теперь всё меняется. Одно из нововведений в анонсе выше, это выход VNET Peering в public preview. Очень приятно, что, согласно заявлению Microsoft, мы получаем возможность связывать VNET не только внутри подписки и между подписками, но и Azure Service Manager VNET и Azure Resource Manager VNET. В качестве бонуса, траффик VNET Peering идет внутри инфраструктуры Azure, не проходя через дополнительное виртуальное устройство, что повышает надежность такого соединения и увеличивает его скорость.
К сожалению, мне пока не удалось найти технических деталей по использованию этого функционала. Как только я их найду они обязательно появятся на Habrahabr.
Поделиться с друзьями