Всем согревающий весенний привет от Лорда Огня!

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

Итак — всех, кто хочет провести процесс демистификации в области возможностей Microsoft Azure в области сетевого взаимодействия — прошу под кат.

Какие бывают сети и что в них есть?

Сети нужны для коммуникации — это ясно и очевидно, Америки я этим не открыл. В нашем случае сети — виртуальные. И используются они, как правило, для коммуникации виртуальных машин между собой, которые размещены в Microsoft Azure.
Если же смотреть на это с точки зрения приложений, то они бывают распределенными и могут включать в себя различные компоненты, которые правильней размещать на отдельных виртуальных машинах или сервисах, предоставляемых Microsoft Azure: это могут быть веб-сервера, это могут быть СУБД SQL и сами сервера приложений. И сам сервис, представленный таким набором виртуальных машин должен быть масштабируемым — мы же про облако говорим с Вами. И описанная выше сеть представляет собой внутреннюю сеть, так как она используется только для внутренних коммуникаций между ВМ внутри Azure. Единственное, что нужно сделать для надежной и привычной коммуникации — это разместить DNS-сервер в Azure. Это можно сдлеать старым-добрым способом — развернуть ВМ и поднять соответствующую роль внутри нее, а можно и проще и надежнее — создав этот сервис на уровне инфраструктурного компонента Microsoft Azure.

Бывают и ситуации, когда сервис должен быть гибридным, то есть взаимодействовать с локальной сетевой инфраструктурой — либо Вашей организации целиком, либо непосредственно с определенного устройства. Обычно для таких соединений используются VPN-тунелли — и в нашем случае они же и используются — в первом случае это S2S-VPN (Site-to-site VPN) , а во втором это P2S-VPN (Point-to-site VPN) .

Что касается VPN-соединения класса «сеть-сеть», то тут также доступна опция ExpressRoute — это гарантированный прямой канал доступа непосредственно в Microsoft Azure, предоставляемый операторами связи, эта услуга доступна и на территории Российской Федерации.

В реальных компьютерных сетях уровня предприятия VPN-устройства бывают не только софтверные на базе Windows Server 2012R2 (ну а как же без него), но и на базе специальных аппаратных решений от таких вендоров, как Cisco или Juniper, — и Microsoft Azure предоставляет возможность загрузки специальных скриптов с параметрами Вашей сети для настройки таких девайсов.

Так же конфигурация сети может быть описана в XML-файле — и такой файл конфигурации можно импортировать в Microsoft Azure для создания сети.

Ну и последний компонент сетевого стека Microsoft Azure — это менеджер трафика (traffic manager). Этот компонент применяется для оптимизации сетевой нагрузки от пользователя к сервисам, расположенным в Microsoft Azure. Варианта оптимизации есть 3: производительность, циклический перебор (он же round robin) и отработка отказа (failover).

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

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

С Уважением,

Человек-огонь
Георгий А. Гаджиев

ссылка на оригинал статьи http://habrahabr.ru/post/252931/