Как быть с сетью, если резервируешь инфраструктуру между городами и провайдерами

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!

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

  • какие есть варианты для связи независимых дата-центров по России;

  • какие трудности появляются на больших расстояниях и как их преодолеть;

  • где между телеком-операторами возникают серые зоны, за которые никто не отвечает.

Когда нужно резервирование ресурсов между городами и провайдерами

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

  2. У компании несколько офисов или представительств по России, и узлы инфраструктуры создаются в городах присутствия.

  3. Сторонняя площадка в другом городе также может использоваться как арбитр — так называют узел, который решает задачи доступа к распределенным ресурсам. Арбитр следит за двумя другими удаленными площадками и разрешает конфликтующие запросы в случае сбоев. 

Часто мы используем такую схему для почтовых серверов. Например, ресурсы для почтового сервиса распределены между двумя московскими дата-центрами и общаются по выделенному каналу связи. А арбитр наблюдает из Санкт-Петербурга или Удомли.

Какие дополнительные проблемы возникают при межпровайдерском и межрегиональном резервировании: 

  • построить свою оптику с нуля чаще всего не вариант — влетит в копеечку;

  • увеличивается задержка: 10 миллисекунд на каждую тысячу километров; 

  • появляется больше посредников на всех уровнях, усложняется коммуникация.

Если клиент решает организовать связность сам, то ему часто приходится собирать конструктор и договариваться сразу с несколькими компаниями.

Резервируем ресурсы и трассы между городами

Посмотрим на прежние варианты организации сети и добавим несколько новых нюансов. 

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

    Были случаи, когда клиенты в регионе подключались к небольшому интернет-провайдеру и выясняли, что наверх идет всего один порт в 100 Мбит/с. При всем желании такой оператор не мог отдать наверх больше 100 Мбит, а у клиентов начинались потери пакетов.

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

    Например, у нас есть пара виртуальных машин на московской площадке и основной узел в Новосибирске, где развернута ВМ с терминалом и ведутся журналы всех подключений. В этом случае мы можем подключаться к панели управления через VPN, анализировать журналы и удаленно администрировать виртуальные машины в других облачных зонах. 
    При этом связь самих узлов между городами все равно строится по каналам L2.

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

  2. Подключение по арендованным выделенным каналам связи. Если в регионе можно взять каналы L2 напрямую от оператора, то клиент уже может рассчитывать на какие-то гарантии. На этом уровне провайдер может обещать конкретные показатели: уровень задержек, пропускную способность. Но важно убедиться, что вы действительно арендуете каналы у того, кто несет ответственность за результат. 

    Был клиент с крупным офисом в Новосибирске и ресурсами в Москве. Он решил организовать связность новосибирского офиса с облаком самостоятельно. Для этого купил гигабитный канал у какого-то провайдера. Но при запуске трафика скорость не поднималась выше 100 Мбит. 

    Нам пришлось общаться с провайдером около месяца, чтобы наконец вскрыть правду: провайдер сам берет канал у субподрядчика, а тот — у еще одного субподрядчика. То есть за одной услугой клиенту скрывалось четыре разных провайдера. Найти ответственного за сбои в этой цепочке было крайне трудно.

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

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

    Звоним на горячую линию, называем номер договора, описываем проблему. Оператор отвечает: “Вы позвонили в московский офис, перевожу вас на звонок по России”. Слушаем музыку. После соединения с новым оператором опять озвучиваем номер договора и проблему. Оператор: “Ой, а это не к нам. Перевожу вас на региональное подразделение на Дальнем Востоке”.

    Снова музыка. Тем временем на Дальнем Востоке уже стемнело, трубку долго никто не берет. Отвечают. И снова мы о проблеме и номере договора. “Ой, а вам нужно в подразделение во Владивостоке”. 

    Такими темпами только на создание тикета у субподрядчика нам потребовался час висения на телефоне. Формально с топологией сети у него все было ок, а вот с сервисом — не очень.

  3. Аренда каналов в сети обмена трафиком. Для нас это предпочтительный вариант, если соединяются разные облака или разные дата-центры. 

    Такие проекты стали обычным делом, когда команды DataLine и “Ростелеком-ЦОД” объединились и география дата-центров расширилась. В качестве транспорта в совместных проектах мы используем сеть MSK-IX. Это первая сеть обмена интернет-трафиком в РФ, которая насчитывает: 

    • 17 узлов присутствия в Москве, 

    • 7 площадок в Санкт-Петербурге, 

    • по 4 узла в Екатеринбурге и Новосибирске, 

    • а также точки присутствия в других городах: Ростове-на-Дону, Ставрополе, Самаре, Казани, Владивостоке, Риге.

    Для проектов внутри нашей сети дата-центров мы используем каналы от Питера до Удомли, от Удомли до Москвы, от Москвы до Екатеринбурга, от Екатеринбурга до Новосибирска и сквозное соединение всех этих точек. 

    Какие возможности дает оператор точек обмена трафиком: 

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

    • Для пиринга была построена развитая сеть каналов c георазнесенными маршрутами. Например, сеть MSK-IX в Москве построена по топологии “двойное ядро”: в двух точках есть ядра, которые соединяются между собой тремя непересекающимися георазнесенными трассами. К каждому из этих ядер по оптике подключены московские дата-центры. При такой топологии определенное резервирование уже заложено в самой архитектуре:

      Упрощенная схема подключения дата-центров к сети MSK-IX.
      Упрощенная схема подключения дата-центров к сети MSK-IX.

      Большинство каналов по России у сети обмена трафиком построены кратчайшими маршрутами. Например, у MSK-IX основной канал связи от Москвы до Екатеринбурга идет по железной дороге. Эта железнодорожная магистраль Москва — Свердловск была спроектирована по линейке на карте, кратчайшим путем: 

      Помимо этого, между городами есть и альтернативные маршруты для резерва, так как от аварий на магистрали никто не застрахован. Но в итоге клиенту гарантируется средневзвешенная задержка между этими маршрутами, а приоритет все равно отдается кратчайшему пути.  

    • На основе сети организована платформа для подключения к облакам через канал связи L2 или L3. Через одно физическое подключение к оператору обмена трафиком клиент получает доступ сразу к нескольким облакам за счет отдельных VLAN.

      Клиенту это гарантирует выделенную полосу пропускания и отсутствие перегрузок на сети. Например, если “кто-то из соседей решил что-то скачать”, это никак не повлияет на арендатора выделенного канала.  Вдобавок, внутри платформы уже есть решения для защиты от DDoS-атак.

    У подключения через точки обмена трафиком тоже возможны перерывы, например, когда на физическом оборудовании идет плановое обслуживание. Зарезервировать подключение можно разными способами. Например, на уровне сети MSK-IX уже есть резервные маршруты, но нужно не забыть подключиться к ним.

    Пример письма техподдержки MSK-IX о плановом обслуживании устройств.
    Пример письма техподдержки MSK-IX о плановом обслуживании устройств.

    Нередко клиенты также используют для резервирования подключение через интернет или другой арендованный канал. 

Связь через сеть обмена трафиком особенно полезна в проектах георезервирования с участием нескольких сервис-провайдеров. 

Например, клиент не хочет зависеть от одного поставщика облачных сервисов. Он использует для георезервирования площадку в Москве от одной компании и площадку в Санкт-Петербурге — от другой (а иногда и еще одну площадку в США или Европе от третьего сервис-провайдера). Связать площадки в России через сеть обмена трафиком часто быстрее и дешевле, так как каналы между крупными дата-центрами уже построены. При этом взаимодействовать с оператором сети обмена можно через своего облачного сервис-провайдера и получать сразу комплексный сервис.

Для связи с зарубежным дата-центром можно использовать стык облачного сервис-провайдера с магистральным оператором международного уровня. Например, московские площадки DataLine подключены к оператору Level 3, чтобы обеспечить минимальные задержки до Европы и США. Подобные стыки с международными сетями есть у всех сервис-провайдеров.

Что учесть при выборе телеком-оператора для резервирования

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

  • изучить карту сети у провайдера и расположение кабельных вводов в зданиях;

  • выяснить количество апстримов и их ограничения по полосе пропускания; 

  • изучить детальный SLA;

  • уточнить наличие выделенного менеджера и единой точки входа в техподдержку;

  • не стесняться делиться информацией о своих инфраструктурных проблемах. Без знания общей картины почти нереально подобрать необходимый набор сервисов и проработать стоящее техническое решение. 

Источник: https://habr.com/ru/company/dataline/blog/589937/


Интересные статьи

Интересные статьи

Высокотехнологический бизнес не может являться таковым, если в нем нет научной составляющей, благодаря которой инновационные достижения ставятся на экономические рельсы и приносят доход. Однако успешн...
Представьте: вы долго работали сисадмином, обросли навыками DevOps и DevSecOps, стали профи и решили открыть свою аутсорсинговую компанию. В штате несколько сисадминов и ...
Данный пост является продолжением идей высказанных мной в предыдущем посте, если какая либо часть рассуждений кажется Вам недостаточно раскрытой возможно вы сможете найти...
Перевод статьи подготовлен в преддверии старта курса «Team Lead 2.0». Выгорание сотрудников в IT–сфере — это не шутка. Всякий, кто только входит в IT, полагает, что вопрос выгора...
В первой части статьи тема превосходства VB.NET над C# по рейтингу TIOBE нашла живой отклик в комментариях. Поэтому по совету AngReload посмотрим на тренды StackOverflow. C# все еще силен! Рев...