В прошлый раз мы обсудили, как обеспечить георезервирование и грамотно разместить инфраструктуру в разных концах города у одного провайдера. При этом есть немало случаев, когда резервирования такого уровня клиенту недостаточно. Поэтому сегодня разовьем тему и поговорим:
какие есть варианты для связи независимых дата-центров по России;
какие трудности появляются на больших расстояниях и как их преодолеть;
где между телеком-операторами возникают серые зоны, за которые никто не отвечает.
Когда нужно резервирование ресурсов между городами и провайдерами
Клиент хочет избежать катастрофы локального масштаба и держит резерв подальше, в другом городе. Как правило, это крупные компании с DR-планом, которые страхуются от масштабных стихийных бедствий и знают о рисках влияния стихии даже на дата-центры.
У компании несколько офисов или представительств по России, и узлы инфраструктуры создаются в городах присутствия.
Сторонняя площадка в другом городе также может использоваться как арбитр — так называют узел, который решает задачи доступа к распределенным ресурсам. Арбитр следит за двумя другими удаленными площадками и разрешает конфликтующие запросы в случае сбоев.
Часто мы используем такую схему для почтовых серверов. Например, ресурсы для почтового сервиса распределены между двумя московскими дата-центрами и общаются по выделенному каналу связи. А арбитр наблюдает из Санкт-Петербурга или Удомли.
Какие дополнительные проблемы возникают при межпровайдерском и межрегиональном резервировании:
построить свою оптику с нуля чаще всего не вариант — влетит в копеечку;
увеличивается задержка: 10 миллисекунд на каждую тысячу километров;
появляется больше посредников на всех уровнях, усложняется коммуникация.
Если клиент решает организовать связность сам, то ему часто приходится собирать конструктор и договариваться сразу с несколькими компаниями.
Резервируем ресурсы и трассы между городами
Посмотрим на прежние варианты организации сети и добавим несколько новых нюансов.
Подключение через интернет. В регионах среди интернет-провайдеров появляется больше компаний, которые полностью берут каналы у операторов уровнем выше. В этом случае у локального провайдера есть несколько апстримов, на уровне которых возможны неприятные сюрпризы. Даже крупные городские провайдеры не всегда рассказывают потребителям о толщине своего канала с апстримами.
Были случаи, когда клиенты в регионе подключались к небольшому интернет-провайдеру и выясняли, что наверх идет всего один порт в 100 Мбит/с. При всем желании такой оператор не мог отдать наверх больше 100 Мбит, а у клиентов начинались потери пакетов.
Поэтому мы предостерегаем клиентов ни в коем случае не использовать подключение через публичный интернет для связи резервных площадок в разных городах. Особенно если связь нужна между узлами высоконагруженного кластера. Даже если провайдер гарантирует какую-то полосу пропускания, эта гарантия действует только в рамках его автономной системы.
Например, у нас есть пара виртуальных машин на московской площадке и основной узел в Новосибирске, где развернута ВМ с терминалом и ведутся журналы всех подключений. В этом случае мы можем подключаться к панели управления через VPN, анализировать журналы и удаленно администрировать виртуальные машины в других облачных зонах.
При этом связь самих узлов между городами все равно строится по каналам L2.В междугороднем сценарии подключение через публичный интернет подходит только для доступа к интерфейсу управления.
Подключение по арендованным выделенным каналам связи. Если в регионе можно взять каналы L2 напрямую от оператора, то клиент уже может рассчитывать на какие-то гарантии. На этом уровне провайдер может обещать конкретные показатели: уровень задержек, пропускную способность. Но важно убедиться, что вы действительно арендуете каналы у того, кто несет ответственность за результат.
Был клиент с крупным офисом в Новосибирске и ресурсами в Москве. Он решил организовать связность новосибирского офиса с облаком самостоятельно. Для этого купил гигабитный канал у какого-то провайдера. Но при запуске трафика скорость не поднималась выше 100 Мбит.
Нам пришлось общаться с провайдером около месяца, чтобы наконец вскрыть правду: провайдер сам берет канал у субподрядчика, а тот — у еще одного субподрядчика. То есть за одной услугой клиенту скрывалось четыре разных провайдера. Найти ответственного за сбои в этой цепочке было крайне трудно.
Поэтому договор все равно стоит читать внимательно: где начинается и заканчивается ответственность провайдера за сервис, какие санкции последуют за невыполнение. Иначе можно пропустить неприятные подробности мелким шрифтом: “Прием обращений в рабочее время, гарантированный срок решения проблемы — месяц”.
Еще один антипример. Для клиента с площадкой во Владивостоке мы предоставляли подключение через субподрядчика. Все проблемы решались через нашу техподдержку. Однажды этот канал упал, и клиент создал тикет на нас. Наши специалисты отправились звонить субподрядчику: обращения он принимал только по единому телефону горячей линии.
Звоним на горячую линию, называем номер договора, описываем проблему. Оператор отвечает: “Вы позвонили в московский офис, перевожу вас на звонок по России”. Слушаем музыку. После соединения с новым оператором опять озвучиваем номер договора и проблему. Оператор: “Ой, а это не к нам. Перевожу вас на региональное подразделение на Дальнем Востоке”.
Снова музыка. Тем временем на Дальнем Востоке уже стемнело, трубку долго никто не берет. Отвечают. И снова мы о проблеме и номере договора. “Ой, а вам нужно в подразделение во Владивостоке”.
Такими темпами только на создание тикета у субподрядчика нам потребовался час висения на телефоне. Формально с топологией сети у него все было ок, а вот с сервисом — не очень.
Аренда каналов в сети обмена трафиком. Для нас это предпочтительный вариант, если соединяются разные облака или разные дата-центры.
Такие проекты стали обычным делом, когда команды DataLine и “Ростелеком-ЦОД” объединились и география дата-центров расширилась. В качестве транспорта в совместных проектах мы используем сеть MSK-IX. Это первая сеть обмена интернет-трафиком в РФ, которая насчитывает:
17 узлов присутствия в Москве,
7 площадок в Санкт-Петербурге,
по 4 узла в Екатеринбурге и Новосибирске,
а также точки присутствия в других городах: Ростове-на-Дону, Ставрополе, Самаре, Казани, Владивостоке, Риге.
Для проектов внутри нашей сети дата-центров мы используем каналы от Питера до Удомли, от Удомли до Москвы, от Москвы до Екатеринбурга, от Екатеринбурга до Новосибирска и сквозное соединение всех этих точек.
Какие возможности дает оператор точек обмена трафиком:
Возможность пиринга — обмена маршрутами с другими участниками сети без необходимости прокладывать дополнительные кроссировки. Это то, ради чего создавались точки обмена трафиком: клиенту хватает одной кроссировки, чтобы получить доступ к серверам со всеми маршрутами участников обмена трафиком. Проще говоря, точка обмена помогает быть ближе к потребителям и при этом снизить затраты на трафик. Это важно для контент-генераторов и крупных контент-потребителей, например: стриминговых сервисов с одной стороны и провайдеров интернета для физлиц с другой.
Для пиринга была построена развитая сеть каналов c георазнесенными маршрутами. Например, сеть MSK-IX в Москве построена по топологии “двойное ядро”: в двух точках есть ядра, которые соединяются между собой тремя непересекающимися георазнесенными трассами. К каждому из этих ядер по оптике подключены московские дата-центры. При такой топологии определенное резервирование уже заложено в самой архитектуре:
Упрощенная схема подключения дата-центров к сети MSK-IX. Большинство каналов по России у сети обмена трафиком построены кратчайшими маршрутами. Например, у MSK-IX основной канал связи от Москвы до Екатеринбурга идет по железной дороге. Эта железнодорожная магистраль Москва — Свердловск была спроектирована по линейке на карте, кратчайшим путем:
Помимо этого, между городами есть и альтернативные маршруты для резерва, так как от аварий на магистрали никто не застрахован. Но в итоге клиенту гарантируется средневзвешенная задержка между этими маршрутами, а приоритет все равно отдается кратчайшему пути.
На основе сети организована платформа для подключения к облакам через канал связи L2 или L3. Через одно физическое подключение к оператору обмена трафиком клиент получает доступ сразу к нескольким облакам за счет отдельных VLAN.
Клиенту это гарантирует выделенную полосу пропускания и отсутствие перегрузок на сети. Например, если “кто-то из соседей решил что-то скачать”, это никак не повлияет на арендатора выделенного канала. Вдобавок, внутри платформы уже есть решения для защиты от DDoS-атак.
У подключения через точки обмена трафиком тоже возможны перерывы, например, когда на физическом оборудовании идет плановое обслуживание. Зарезервировать подключение можно разными способами. Например, на уровне сети MSK-IX уже есть резервные маршруты, но нужно не забыть подключиться к ним.
Пример письма техподдержки MSK-IX о плановом обслуживании устройств. Нередко клиенты также используют для резервирования подключение через интернет или другой арендованный канал.
Связь через сеть обмена трафиком особенно полезна в проектах георезервирования с участием нескольких сервис-провайдеров.
Например, клиент не хочет зависеть от одного поставщика облачных сервисов. Он использует для георезервирования площадку в Москве от одной компании и площадку в Санкт-Петербурге — от другой (а иногда и еще одну площадку в США или Европе от третьего сервис-провайдера). Связать площадки в России через сеть обмена трафиком часто быстрее и дешевле, так как каналы между крупными дата-центрами уже построены. При этом взаимодействовать с оператором сети обмена можно через своего облачного сервис-провайдера и получать сразу комплексный сервис.
Для связи с зарубежным дата-центром можно использовать стык облачного сервис-провайдера с магистральным оператором международного уровня. Например, московские площадки DataLine подключены к оператору Level 3, чтобы обеспечить минимальные задержки до Европы и США. Подобные стыки с международными сетями есть у всех сервис-провайдеров.
Что учесть при выборе телеком-оператора для резервирования
Проекты георезервирования — конструктор, который можно собирать из разных элементов. Как показывают наши примеры, часто проблемы возникают даже не с технической частью, а с сервисом и коммуникацией на стыке разных элементов конструктора. Поэтому общие рекомендации при выборе поставщиков будут такие:
изучить карту сети у провайдера и расположение кабельных вводов в зданиях;
выяснить количество апстримов и их ограничения по полосе пропускания;
изучить детальный SLA;
уточнить наличие выделенного менеджера и единой точки входа в техподдержку;
не стесняться делиться информацией о своих инфраструктурных проблемах. Без знания общей картины почти нереально подобрать необходимый набор сервисов и проработать стоящее техническое решение.
