что такое сетевая связанность
Организация сети в облаке и сетевая связность с облаком
Здравствуйте, дорогие любители cloud computing.
Сегодня меня заставили написать пост о сетях – о тех сетях, что используются в нашем облаке. Я изо всех сил постараюсь объяснить, как тут все организовано, а также расскажу о том, как можно подключиться к нашему облаку.
Случай 1 (легкий):
Вы приобретаете услугу по размещению в облаке своей виртуальной машины. Мы создаем пул ресурсов и выделяем вам сеть с 5 адресами. Вы настраиваете виртуальную машину в соответствии с полученными инструкциями и (ТАДАМ!) она работает (кто бы сомневался?).
Вам захотелось сэкономить и вы вместо того, чтобы взять еще одну машину для нового сайта, просто повесили алиасом еще один адрес. И (ТАДАМ!) – он тоже работает.
Случай 2 (еще проще, потому как мне еще не встречался):
Вы – разработчик. Причем такой разработчик, которому удобно работать в консоли VMware. Вам нужно организовать тестовый стенд, чтобы проверить очередной HelloWorld-проект. Отлично! Загружаем свои машины в облако (которое уже арендовано), подключаем их к выделенной внутренней сети, включаем и проверяем все, что хотим. Бонус: можно использовать любую адресацию внутри такого VLANа.
Случай 3 (запарный, но не сильно, т.к. требует примерно на 5 кликов мышкой больше, чем в 1 случае):
Вы пошли на поводу у «системы» и решили не выбиваться из общей массы тех, кто пользуется frontend/backend топологией. Например, у вас есть web-сервер с каким-то важным контентом и база данных, к которой этот самый сервер обращается. База данных должна быть недоступна со стороны интернета, потому как он наводнен всякими маргиналами, пытающимися эту самую базу украсть / взломать / допишите сами. Самый простой вариант защиты – оградить ее (базу, сервер баз данных) от общения с беснующимся Интернетом на 2 уровне сетевой модели OSI. И это тоже по силам нам. Мы выдаем 2 сети: богатую (целых 5 IP адресов) внешнюю сеть и безразмерную внутреннюю. WEB-сервер мы подключаем к этим двум сетям разными адаптерами (ДА, ТАКОЕ ТОЖЕ ВОЗМОЖНО!), сервер баз данных подключаем только ко внутренней сети. Получится примерно такая топология:
После этих манипуляций мы отделили север баз данных от интернета и различные зловреды до него не доберутся (но мы-то знаем, что эта проблема лишь вершина айсберга, т.к. нужно допиливать frontend, потому как через него зловреды-таки смогут попасть на наш беззащитный сервер с базой данных).
Случай 4:
Есть у VMware продукт под названием vShield manager. Вкратце: это обычный firewall / router, реализованный в виде виртуальной машины. Помимо всего этого – его интерфейс интегрируется с vCloud и управлять настройками (правилами, маршрутизацией, IPSec и т.п. вещами) можно прямо из облака. Чем-то напоминает случай 3. Однако теперь вы сможете добавлять правила NAT и настраивать политики firewall под себя из графического интерфейса:
Случай 4a:
Этот случай очень напоминает предыдущий вариант, но в отличие от него в качестве маршрутизатора / брандмауэра используется не vShield, а другое решение (например MS TMG, Vyatta, либо специальным образом настроенный дистрибутив с opensource системой). Т.е. мы так же выделяем организации в облаке 2 сети: внутреннюю и внешнюю, и подключаем их к этому маршрутизатору.
Теперь я расскажу немного о том, как можно настроить безопасные подключения к своим облакам. Как вы уже догадались – существует 2 варианта подключения: на уровне 2 модели OSI и на уровне 3 той же модели.
Подключение на 2 уровне: вы либо тянете провод в наш ЦОД, либо арендуете VLAN у своего провайдера, который представлен в нашем ЦОДе. Мы пробрасываем этот линк в ваше облако и вуаля.
Подключение на 3 уровне осуществляется через общедоступную сеть Интернет при помощи туннелирования. Это самый простой способ. Реализуется он также на базе vShield, либо любого другого специализированного дистрибутива. vShiled предоставляет только IPSec туннели. Ниже пример действующего туннеля одного из наших клиентов:
Теперь вы знаете, как работают сети в облаке ИТ-ГРАД; как подключиться к своему облаку и что для этого нужно. Если вы реально заинтересованы – задавайте свои вопросы, я постараюсь помочь.
Что такое сетевая связанность
Понятие связности имеет для сети фундаментальное значение. Высокая связность сети предполагает, что такая сеть надежна. Высокая связность, достигаемая при минимальной стоимости сети делает сеть оптимальной.
Существуют детерминированные и вероятностные оценки связности сети.
Детерминированные оценки связности сети
Удаление узлов 1 и 4 разрывает граф. Вершинная связность k = 2. Удаление ребер, входящих в узел 3 делает граф несвязным Реберная связность графа равна l = 3.
Реберная связность рассматривается как мера защищенности графа сети от распада при удалении из него вершин или ребер. На предыдущем рисунке удаление ребер входящих в узел 3 делает граф несвязным.
Множество узлов, удаление которых делает сеть не связной, также называется узловым сечением. Аналогично, множество ребер, удаление которых делает сеть не связной, называется реберным сечением. Поэтому узловая связность соответствует минимальному узловому сечению, а реберная связность – минимальному реберному сечению. Для проверки связности сети используются матрицы смежности, алгоритмы Форда и Фалкерсона и др.
Вероятностные оценки связности сети
В условиях нарушения работоспособности компонентов сети за счет агрессивных или агрессивных воздействий вероятность связности соответствует живучести сети и используется как мера надежности в сетях военного назначения. Иногда вводят понятие структурной надежности сети, которое эквивалентно понятию надежности.
Наиболее простая характеристика живучести сети – вероятность связности всех вершин графа сети. Состояние сети при удалении части вершин или ребер графа могут быть благоприятными и неблагоприятными. Неблагоприятным состоянием будем считать распад графа на не связанные части с учетом технической надежности и внешних условий работы. Живучесть сети определяется суммой вероятностей всех возможных состояний, в которых вершины графа связаны.
где i = 1, 2,3,…,l
P – вероятность связности всех вершин графа,
Аi – благоприятные состояния, в которых граф оказывается связанным,
P(Ai) – вероятность благоприятного состояния,
l – число благоприятных состояний.
Вероятность связанности сети может быть определена либо методом статистического моделирования сети, либо по формуле:
Другой характеристикой надежности сети является вероятность связности 2-х вершин. Две вершины будут связаны тогда, когда в графе существует хотя бы один путь Mi (где i=1…k), связывающий рассматриваемые вершины.
Если Bi – событие, состоящее в том, что хотя бы один такой путь существует, а P(Bi) – вероятность такого события, то вероятность связности 2-хвершин:
где k- количество цепей или благоприятных случаев).
Для приближенной оценки связности пар узлов используют метод простых сечений. Пару вершин можно рассматривать как фрагмент сети. В некоторых практических случаях требуется определять связность фрагмента сети, включающего от 3 и более узлов в сети. Такой показатель называют фрагментной связностью.
Метод простых сечений удобно рассмотреть на примере:
Рис.1
На приведенном рисунке требуется определить связность вершин s и t. Для этого надо определить сечения из 2, 3, 4 и более ребер сети, удаление которых разрывает связь между вершинами s и t. Количество сечений по 2, 3, 4 и т.д. ребер подставляется в формулу:
В нашем примере разъединение сети произойдет, если выйдет из строя не менее 2-х ребер, таких сечений 6 и 5 сечений по 3 ребра.
Инфраструктура в разных концах города: как не проворонить сетевую связность
Обеспечить георезервирование можно, если разместить оборудование в удаленных дата-центрах или взять ресурсы в разных облачных зонах доступности. Но важно не забыть про сетевую связность и на берегу выяснить несколько вопросов у телеком-провайдера. Иначе сбой сети сведет на нет все плюсы распределенной архитектуры.
В октябре по просьбе наших подписчиков мы обсудили тему сетевой связности на эфире в Салатовой телеге. Здесь решили продолжить обсуждение в двух частях:
в первой части покажем сценарии георезервирования и варианты связности в рамках одной сети дата-центров в одном городе;
в следующий раз поговорим, как обеспечить связность, если нужно держать резерв в другом городе и у другого сервис-провайдера.
Кому и какое георезервирование нужно
В идеальном сценарии георезервирование обеспечивает скорость восстановления. Что бы ни произошло на основной площадке, сначала переключимся на резервную, а потом разберемся в проблеме и устраним аварию. Реализовать эту идею можно разными способами: единой для всех таблетки “георезервирование” не существует.
С точки зрения сети важно продумать нужное качество соединения, резервирование каналов на всех уровнях и информационную безопасность. Для этого комплексно анализируем, какую систему, как и для чего резервируем. Например, у нас к проекту обычно подключаются не только сетевые инженеры, но и группы виртуализации, резервного копирования, архитекторы, специалисты центра киберзащиты.
На какие вопросы нужно ответить перед разработкой решения:
Какие площадки связываем: ЦОДы или собственные площадки клиента?
Между крупными дата-центрами уже проложены каналы и есть телеком-операторы на выбор. На базе этих каналов можно выбрать разные услуги. А вот для связи с клиентской серверной, возможно, потребуется достроить канал от ближайшей точки присутствия провайдера.
Какое расстояние между площадками?
Даже если резерв находится в пределах одного города, важно выяснить расстояние. От этого зависит задержка сети и скорость.
Средневзвешенная задержка в пределах одного города будет меньше 10 миллисекунд — этот показатель растет при расстояниях в тысячу и более километров. Но для предсказания фактической задержки важно знать топологию сети и маршрут между узлами присутствия.
А в случае со скоростью многое зависит и от оборудования. Например: дальнобойные трансиверы дают максимальную скорость на расстоянии до 40—50 км.
Какие нужны показатели допустимого времени восстановления (RTO) и допустимой потери данных (RPO) исходя из задачи?
Резервная площадка может понадобиться для хранения бэкапов, когда важно сохранить максимум информации, а скорость развертывания вторична. Тогда мы задаем строгий RPO и не так требовательны к RTO.Или, наоборот, клиент может держать площадку в другом ЦОДе, чтобы максимально быстро поднять свой сервис при аварии. Тогда выбираем решение с предсказуемым RTO: отказоустойчивый кластер между двумя дата-центрами, послеаварийное восстановление как сервис (DRaaS) или катастрофоустойчивое облако.
С точки зрения сети нам важно, как будет происходить репликация на стороннюю площадку. Когда речь идет про репликацию в реальном времени или кластер Active-Active с высокой нагрузкой, то важно обеспечить широкий канал с минимальными задержками. Например, мы уже рассказывали, как это устроено в нашем катастрофоустойчивом облаке.
Если же репликация происходит сессионно раз в несколько минут, то требования к каналу снижаются. В этом случае уже можно использовать межрегиональное резервирование.
Дальше мы уточняем детали и предлагаем решения по ситуации.
Покажем на конкретных примерах, какие удачные решения и ошибки могут возникнуть в таких проектах.
Резервируем ресурсы и трассы внутри Москвы
Мы уже рассказывали про варианты подключения к нашим облакам здесь: 5+ способов подключиться к облаку. Дополним список с точки зрения георезервирования, когда нужно организовать подключение к разным дата-центрам одной сети.
Вот какие способы организации сети и резервирования тут есть.
Публичный интернет. Вариант, если нужно дешево и сердито. Есть очевидные минусы: негарантированная полоса пропускания, негарантированная задержка, ограничения по объему трафика и риск кибератак.
Кажется, что для георезервирования даже в пределах города не подходит. Но есть сценарии, когда требования к RTO и RPO не такие высокие, а риски этого варианта компенсируются дополнительными инструментами:
Например, сеть магазинов нужно подключить к облаку с внутренними системами. В этом случае главный узел в облаке собирает информацию от торговых точек, которые работают как второстепенные узлы.
Тянуть каналы L2 в каждую точку нет смысла: так магазин никогда не окупится. Компания готова мириться с небольшой временной деградацией трафика — главное, чтобы связь с магазинами была.
Чтобы застраховаться от сбоев интернет-соединения, каждую точку ритейлер подключает к двум разным интернет-провайдерам. Неплохо, если ритейлер узнает больше про их сети и убедится, что при аварии не откажут сразу оба провайдера.
А для защиты от угроз ИБ затем можно использовать фаерволы и подключение по шифрованному каналу: классический IPsec site-to-site, IPsec с GRE и так далее. Подробнее об их настройке мы рассказывали здесь:
Как ритейлер в этом примере может проверить телеком-операторов? Во-первых, запросить карту сети и убедиться, что маршруты выбранных провайдеров не пересекаются. Еще лучше, если удастся изучить схему прокладки оптического кабеля в офисном здании. Так можно проверить, насколько кабельные вводы далеко друг от друга и застрахованы от “шального экскаватора”.
Пример схемы прокладки оптики в здании.
Такая проверка не будет лишней даже в Москве. К сожалению, единственный кабельный ввод без резерва встречается и в крупных московских дата-центрах: Воздушки, релейки, кабель в окно: как не напороться на провайдера-монополиста в бизнес-центре.
Во-вторых, у провайдера важно выяснить количество апстримов — стыков с вышестоящими операторами связи. Так можно обезопасить себя от ситуаций, когда интернет пропадет из-за сбоя вышестоящего оператора, а у вашего поставщика интернета нет резерва.
Для проверки можно использовать сервисы Looking Glass, они есть даже у небольших телеком-провайдеров. По названию провайдера можно проверить, в каком состоянии находится пиринг — обмен трафиком между операторами. Для примера поищем по названию DataLine в сервисе от Hurricane Electrics:
На графе видим кликабельные обозначения провайдеров, с которыми настроен обмен.
Более интересный кейс: можно выходить в интернет с помощью протокола маршрутизации BGP. Для этого у клиента должна быть своя автономная система (АС) — система IP-сетей и маршрутизаторов, которыми управляют операторы связи. При наличии у клиента АС и независимых адресов сервис-провайдер может поднять BGP-пиринг, то есть организовать обмен маршрутами с клиентом и отдавать их в сторону собственных апстримов. При этом для резервирования можно поднять второй пиринг с другим телеком-провайдером.
Возможен и более экзотический кейс георезервирования. Клиент может поднять BGP-сессии на серых АС с IP-адресами, которые выделяет сервис-провайдер. В этом случае организовать пиринг с другим провайдером уже не получится.
Вот как мы реализуем эту схему. Вы анонсируете эти адреса нам из двух ЦОДов. Если что-то случилось в одном из ЦОДов, то другой берет на себя эти адреса, и даунтайм минимален.
В целом, наш опыт подсказывает, что вполне можно использовать интернет в связке с VPN для доступа к легкому статичному контенту. А вот нагруженные решения уже стоит связывать по-взрослому.
Использование каналов сервис-провайдера между площадками. Когда две площадки для резервирования расположены в одной сети дата-центров, можно воспользоваться готовой связностью между ними. Например, первые проекты с резервированием внутри Москвы мы начинали на базе двух площадок: NORD и OST. Для обеспечения связности между ними была построена наша собственная оптоволоконная сеть.
Какие есть варианты связывания площадок с использованием такой сети:
Если обе площадки облачные, можно растянуть между ними канал L2 на уровне виртуализации. Для этого часто применяют технологию VxLAN, которая использует готовую сеть между зонами доступности облака. Это как раз тот случай, когда к проекту подключается группа виртуализации.
Если клиент подключает площадку в дата-центре со своим физическим оборудованием, то можно взять канал L2 Ethernet в аренду. Тогда в конечных точках сразу будет установлен коммутатор. Чаще всего этот вариант берут компании с объемом трафика до 1 гигабита между площадками с “физикой” — так получается выгоднее всего. На самом деле, в таком сценарии мы можем предоставить порт и на 10 гигабит. А вот все, что больше, нужно прорабатывать отдельно. Не всегда IP-транспорт способен обеспечить передачу такого объема трафика без потерь.
Поэтому, если трафика много, есть DWDM — спектральное уплотнение канала. Простыми словами: DWDM позволяет отправлять больше информации по одному волокну. Для этого используется оптоволокно с дальномерными трансиверами на концах каждой связки. Такое оборудование стоит довольно дорого, зато за счет уплотнения можно сильно сэкономить на оптике.
Облачные сервис-провайдеры строят DWDM-системы между своими площадками, чтобы с запасом обеспечить транспорт для всех “растянутых” облачных сервисов. Но и некоторые крупные клиенты могут создать DWDM-решение для собственных нужд.
Внутри DWDM уже заложена отказоустойчивость. Каждый трансивер подключен сразу к двум непересекающимся трассам. Для переключения между ними используется коммутатор L1, в котором установлен датчик света. Если датчик “не видит” света в волокне, то переводит трафик на резервный канал (на самом деле все чуть сложнее, но об этом как-нибудь в следующий раз).
Можно предоставить клиенту темную оптику — свободные волокна, к которым не подключено активное оборудование. Это уже для тех, кто хочет организовать все сам и поставить свое железо. Но тогда клиенту придется самостоятельно позаботиться и о сценариях резервирования сети: не забыть про резервный канал и настроить аварийные переключения на собственном оборудовании.
Поверх транспортной сети также возможны дополнительные услуги: VPN, Anti-DDoS и так далее.
Все эти сценарии помогут за счет ресурсов провайдера обеспечить нужное RTO c практически мгновенным переключением на резерв. Вот по каким признакам можно убедиться, что у сервис-провайдера хорошо организовано резервирование сети между площадками:
На уровне опорной сети связь идет по нескольким трассам непересекающимися маршрутами.
На уровне каждой площадки есть резервирование трасс и оборудования. Например, у нас на OST есть 3 независимых узла связи: по одному кластеру в каждом энергоцентре. На второй площадке NORD независимых кластеров еще больше, все они соединены друг с другом и с узлами дата-центра OST. При падении целого сетевого сегмента нагрузка перераспределяется на другие узлы.
На уровне самих каналов достаточная пропускная способность обеспечивается за счет оборудования Enterprise-уровня. Например, у нас на этом уровне предусмотрено двойное резервирование сети. Что это значит: мы наблюдаем за утилизацией сети на мониторинге и следим, чтобы ее загруженность не превышала 50%. При такой загрузке даже падение половины линков нам не страшно. Как только загрузка начинает регулярно превышать 50%, пора модернизировать сеть. Где-то наращивать линки, где-то менять оборудование на более мощное.
Если нужно соединить с облаком собственную площадку клиента, вопрос стоимости резерва может встать чуть острее. Достраивать оптику до клиента бывает недешево само по себе, а нам вдобавок нужно продумать резервирование этого канала. Здесь уже есть варианты: достроить второй канал, арендовать второй канал у подрядчиков на площадке клиента или обойтись резервом через интернет с учетом его издержек.
Посмотрим, как можно применить сразу несколько вариантов в конкретном проекте.
У одного из крупных клиентов на территории Москвы было 2 офиса с собственными серверными. Изначально инфраструктура не предполагала других площадок.
Но затем произошла авария и компания задумалась о послеаварийном восстановлении за пределами офиса. Резервную инфраструктуру решили разместить в защищенном облаке DataLine Cloud-152. В случае падения виртуальной машины на одной из клиентских площадок резервная ВМ должна мгновенно подниматься в Cloud-152.
До этого проекта реплицировать машины куда-то еще не планировали, поэтому сетевую часть нужно было переделать. При этом из-за финансовых ограничений клиент не мог полностью перестроить всю инфраструктуру. В этих условиях инженеры продумывали резерв на разные случаи отказа: если будет сбой у одного из операторов связи, либо если отключится питание в серверной.
В итоге к офисам компании подключились через 2 канала: один канал арендовали у DataLine, а второй у другого оператора связи. Получилось резервирование сети за счет двух независимых телеком-операторов.
Из-за особенностей клиентской инфраструктуры нужно было минимизировать возможные проблемы единого растянутого L2-домена. Мы посоветовали клиенту разделить домен на два сегмента с его стороны. К нам на площадку NORD приходят оба VLAN’а, и, в случае падения ВМ на одной из основных площадок заказчика, на нашей они поднимутся сразу в нужном IP-сегменте.
В данной схеме есть свои узкие места, но в кейсе клиента она решила задачи с учетом ограниченного бюджета на переделку инфраструктуры.
В следующий раз поговорим, какие риски и особенности могут возникнуть у межпровайдерского георезервирования:
какие есть варианты для связи независимых дата-центров по России;
какие трудности появляются на больших расстояниях и как их преодолеть;
где между телеком-операторами возникают серые зоны, за которые никто не отвечает.
Как устроено облако VMware внутри. Сети и сетевая связанность
Как устроено облако VMware внутри. Сети и сетевая связанность
Предлагаем рассмотреть важные детали, вынеся на повестку дня следующие вопросы:
Для построения полноценного сервис-ориентированного и адаптивного под задачи любой сложности облака VMware используется набор продуктов VMware vCloud Suite, или сокращенно vCS. Из всего набора продуктов VMware vCloud Suite рассмотрим ключевые, с помощью которых можно построить облако, организовать внутри него сети, гарантировать должный уровень безопасности и обеспечить эффективное управление облачной площадкой.
Поскольку речь идет об облаке на базе VMware, предлагаем вспомнить особенности платформы виртуализации VMware vSphere 5.5, которая обеспечивает следующую функциональность:
Таким образом, vSphere можно назвать фундаментом облака, без которого, как и в строительстве, нельзя возвести здание.
А для обеспечения безопасности и устойчивости к различным внутренним и внешним угрозам необходим набор продуктов vCloud Networking and Security, который аналогично можно сопоставить с перекрытиями и стенами здания.
vCloud Director, входящий в состав vCloud Suite, представляет собой главный компонент, являющийся мощным инструментом управления облаком.
Для самостоятельного управления виртуальной инфраструктурой клиенту предоставляется доступ к персональному порталу самообслуживания. В облаке VMware такой портал, как правило, реализуется на основе vCloud Director и с помощью веб-интерфейса позволяет управлять следующими компонентами:
Сочетание vSphere с набором продуктов vCloud Networking and Security дает возможность сформировать так называемую облачную ячейку. Облачная ячейка представляет собой базовый набор ресурсов, который может быть «разрезан» на более мелкие составляющие. На их основе в дальнейшем и создаются различные по масштабу независимые друг от друга облака. Количество облаков при этом зависит от реально доступных вычислительных ресурсов.
Как организовать сеть внутри облака VMware?
Виртуальная сеть в облаке мало чем отличается от физической сети: она может быть как изолированной, так и нет, с внешней маршрутизацией или с внутренней, на базе протокола IPv4 или IPv6. С точки зрения надежности и возможностей виртуальные сети, в отличие от физических, обладают следующими преимуществами:
Сеть внутри облака VMware может быть организована с использованием различных сценариев. Остановимся подробно на каждом из них.
Построение внешней маршрутизируемой подсети с количеством IPv4/IPv6-адресов согласно требованиям клиента.
Такие типы внешних маршрутизируемых сетей часто именуют External networks, которые представляют собой, по сути, вход и выход во внешний мир. Например, выход в Интернет или доступ к этой сети извне посредством технологий организации удаленного доступа.
Рисунок 1. Пример фрагмента внешней маршрутизируемой сети компании «ИТ-ГРАД»
Для создания внешней сети в облаке администратор vSphere создает отдельную группу портов с необходимыми параметрами. При формировании сетевого сегмента важно корректно указать шлюз, параметры одного или нескольких DNS-серверов (о DNS более подробно будет рассказано ниже), а также определить диапазон IP-адресов с соответствующей маской подсети. Каждая сеть должна иметь свое наименование, поэтому при настройке задается ее имя и описание. Если в сегменте планируется выдача публичных (белых) адресов, то для этого создаются соответствующие правила в таблице маршрутизации на маршрутизаторе.
Давайте рассмотрим пример внешней маршрутизируемой сети в облаке на примере компании «ИТ-ГРАД», обратившись к рисунку 1. Здесь мы видим наличие так называемых публичных хостов, доступ к которым извне должен быть организован на постоянной основе с доступностью 24/7.
К сайту компании www.it-grad.ru могут обращаться любые пользователи из любой точки мира. В том числе сотрудники самой компании могут работать удаленно, подключаясь к терминальным серверам, где установлены необходимые для работы приложения, а также использовать Outlook Web Access для доступа к почте через web. Как правило, публичные серверы, доступ к которым организуется извне, отделяют от внутренних ресурсов.
Для реализации рассматриваемого сценария может потребоваться выделение четырех белых IP-адресов под каждую виртуальную машину для доступа к ней из внешних сетей через Интернет. Однако возможен и другой вариант, когда для текущего сценария будет достаточно наличия одного белого IP-адреса, в таком случае потребуется конфигурация брандмауэра и настройка правил публикации каждого из серверов, расположенных в этой внешней сети.
Построение изолированной подсети для связи между виртуальными машинами
Помимо внешних маршрутизируемых сетей в облаке могут присутствовать изолированные подсети для связи межу виртуальными машинами. Необходимость таких сетей может быть обусловлена определенными задачами. Давайте рассмотрим пример на рисунке 2. Согласно рисунку 2, в компании ИТ-ГРАД есть два контроллера домена (VM1 и VM2), которые должны выполнять репликацию баз данных активного каталога. Это необходимо для поддержания баз в актуальном состоянии. Кроме того, дополнительно развернут DNS-сервер (VM3), который хранит вторичную зону it-grad.ru. Серверы VM2 и VM3 должны взаимодействовать друг с другом для выполнения трансфера зоны. Если на машине VM2 меняется содержимое основной зоны it-grad.ru, все изменения, связанные с зоной, должны быть переданы на машину VM3. Доступ к сети internal network 1 ограничен извне. В терминологии VMware такой тип сети именуется как сеть организации или Organizations Network, внутри которой ходит ее внутренний трафик.
Построение изолированной подсети для связи между виртуальными машинами
Рисунок 2. Фрагмент изолированной подсети в облаке
Помимо внешних маршрутизируемых сетей в облаке могут присутствовать изолированные подсети для связи межу виртуальными машинами. Необходимость таких сетей может быть обусловлена определенными задачами. Давайте рассмотрим пример на рисунке 2.
Согласно рисунку 2, в компании ИТ-ГРАД есть два контроллера домена (VM1 и VM2), которые должны выполнять репликацию баз данных активного каталога. Это необходимо для поддержания баз в актуальном состоянии. Кроме того, дополнительно развернут DNS-сервер (VM3), который хранит вторичную зону it-grad.ru. Серверы VM2 и VM3 должны взаимодействовать друг с другом для выполнения трансфера зоны.
Если на машине VM2 меняется содержимое основной зоны it-grad.ru, все изменения, связанные с зоной, должны быть переданы на машину VM3. Доступ к сети internal network 1 ограничен извне. В терминологии VMware такой тип сети именуется как сеть организации или Organizations Network, внутри которой ходит ее внутренний трафик.
Организация подсетей с использованием комбинированного подхода: построение одновременно внутренних и внешних подсетей, либо выдача двух и более внешних или внутренних сетей.
Данный тип организации подсетей является наиболее распространенным и часто встречающимся на практике. Как правило, в большинстве компаний, которые переносят свою ИТ-инфраструктуру в облако, имеются ресурсы, доступ к которым необходим извне. А также имеется набор критичных сервисов и приложений, которые должны быть изолированы и защищены от внешнего доступа. Именно они помещаются в изолированный сегмент. Также бывают сценарии, когда таких изолированных сетей должно быть несколько. При этом подключать виртуальные приложения можно напрямую как часть сегмента организации или через виртуальный шлюз Edge Gateway с возможностью использования NAT.
Рисунок 3. Фрагмент облака с двумя изолированными сетями и сетью публичного доступа
На рисунке 3 мы видим фрагмент облака, в котором представлены две внутренние подсети и одна публичная, каждая из которых отделена друг от друга. В этом сценарии реализован комбинированный подход.
Изолированная сеть Internal Network 1 рассматривалась ранее более подробно. Напомним, что в ней находятся контроллеры домена, выполняющие репликацию баз активного каталога, а также реализован трансфер зоны с сервером DNS и одним из контроллеров домена. В изолированной сети Internal network 2 находятся две виртуальные машины, выполняющие роль распределенной файловой системы. Между данными серверами выполняется репликация изменений файлов в каталогах Marketing и HR. Доступ к двум рассмотренным подсетям извне ограничен. Подсеть Public network 1, в свою очередь, является публичной, доступной из Интернета.
DMZ в виртуальной среде
При построении сети внутри облака может возникнуть вопрос организации демилитаризованной зоны (DMZ), достаточно часто используемой в физических сетях.
Отличается ли DMZ в физической реализации от реализации ее в виртуальной среде публичного облака в модели IaaS?
Разберем все по порядку и начнем, пожалуй, с определения, важного для понимания сути вопроса.
На рисунке 3 сеть Public network 1, по сути, можно назвать демилитаризованной зоной.
В физической реализации демилитаризованная зона находится между локальной сетью компании и публичной сетью Интернет, располагаясь в сетевом пространстве брандмауэра. В DMZ разрешен предопределенный тип трафика, а необходимость ее построения заключается в требованиях предоставления доступа к публичным сервисам компании, таким как почта, терминальные серверы, веб-серверы и прочее.
Априори такой тип организации сети, по сравнению с внутренними изолированными сетями, считается более уязвимым в плане безопасности. Поскольку обращение к сегменту DMZ происходит из незащищенной сети Интернет, возможны попытки организации различных видов атак.
При организации DMZ в физической среде, как и в среде виртуальной, существуют различные сценарии. По сути, создается выделенная логическая подсеть, на границах которой должны размещаться средства безопасности, такие как брандмауэр.
Возможен сценарий использования Front End / Back End брандмауэра. Пример такой схемы представлен на рисунке 4.
Рисунок 4. DMZ в сценарии Front End / Back End брандмауэра
В таком сценарии мы видим наличие двух фаерволов на границе каждой сети. При попытке атаки зоны DMZ из публичной, небезопасной сети Интернет, злоумышленник на своем пути встречает «защиту» в виде пограничного фаервола.
Внутренняя сеть компании отделена от DMZ дополнительной «подушкой безопасности» в виде пограничного внутреннего фаервола. Такой сценарий считается не очень бюджетным, поскольку подразумевает наличие минимум двух брандмауэров, что влечет за собой дополнительные расходы. Зато в плане безопасности такой сценарий является рекомендуемым.
Более простым сценарием с DMZ является наличие одного брандмауэра, как продемонстрировано на рисунке 5. Такая модель носит название трехногой топологии и очень часто встречается на практике в силу своей бюджетности. Такая топология считается менее безопасной.
Рисунок 5. DMZ в сценарии «трехногой» конфигурации
А как дело обстоит в облаке?
Виртуализированная DMZ, должным образом сконфигурированная, так же надежна в плане безопасности, как и DMZ в физической реализации. В последнее время перенос DMZ в облако набирает все больше оборотов.
Рисунок 6. Пример DMZ в облаке
Возможные сценарии организации DMZ в облаке:
Итак, мы рассмотрели первый пункт, касающийся построения сетей в облаке. Теперь необходимо понять, какие сетевые сервисы должны быть у провайдера IaaS, ведь многие из них выполняют очень важные функции.
Сетевые сервисы IaaS-провайдеров
На сегодняшний день существует огромное количество различных сервисов, без которых трудно представить полноценную ИТ-инфраструктуру. Зачастую конечному пользователю виден только результат, но как же выглядит «закулисная жизнь» особо важных сервисов, какие функции они выполняют и что обычно предлагает облачный IaaS-провайдер?
Одним из важных аспектов в облачной сетевой инфраструктуре, как и в физической, является наличие сервисов, отвечающих за так называемый процесс разрешения имен.
В чем же разница? Ответ на поставленный вопрос следует начать с особенностей типов имен, поскольку в этом пункте чаще всего возникает путаница. Имена делятся на две категории: HOSTS-имена и NETBIOS-имена, характеристики которых представлены в таблице 1.
Типы имен
