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