Георезервирование что это такое
Как быть с сетью, если резервируешь инфраструктуру между городами и провайдерами
В прошлый раз мы обсудили, как обеспечить георезервирование и грамотно разместить инфраструктуру в разных концах города у одного провайдера. При этом есть немало случаев, когда резервирования такого уровня клиенту недостаточно. Поэтому сегодня разовьем тему и поговорим:
какие есть варианты для связи независимых дата-центров по России;
какие трудности появляются на больших расстояниях и как их преодолеть;
где между телеком-операторами возникают серые зоны, за которые никто не отвечает.
Когда нужно резервирование ресурсов между городами и провайдерами
Клиент хочет избежать катастрофы локального масштаба и держит резерв подальше, в другом городе. Как правило, это крупные компании с 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;
уточнить наличие выделенного менеджера и единой точки входа в техподдержку;
не стесняться делиться информацией о своих инфраструктурных проблемах. Без знания общей картины почти нереально подобрать необходимый набор сервисов и проработать стоящее техническое решение.
Инфраструктура в разных концах города: как не проворонить сетевую связность
Обеспечить георезервирование можно, если разместить оборудование в удаленных дата-центрах или взять ресурсы в разных облачных зонах доступности. Но важно не забыть про сетевую связность и на берегу выяснить несколько вопросов у телеком-провайдера. Иначе сбой сети сведет на нет все плюсы распределенной архитектуры.
В октябре по просьбе наших подписчиков мы обсудили тему сетевой связности на эфире в Салатовой телеге. Здесь решили продолжить обсуждение в двух частях:
в первой части покажем сценарии георезервирования и варианты связности в рамках одной сети дата-центров в одном городе;
в следующий раз поговорим, как обеспечить связность, если нужно держать резерв в другом городе и у другого сервис-провайдера.
Кому и какое георезервирование нужно
В идеальном сценарии георезервирование обеспечивает скорость восстановления. Что бы ни произошло на основной площадке, сначала переключимся на резервную, а потом разберемся в проблеме и устраним аварию. Реализовать эту идею можно разными способами: единой для всех таблетки “георезервирование” не существует.
С точки зрения сети важно продумать нужное качество соединения, резервирование каналов на всех уровнях и информационную безопасность. Для этого комплексно анализируем, какую систему, как и для чего резервируем. Например, у нас к проекту обычно подключаются не только сетевые инженеры, но и группы виртуализации, резервного копирования, архитекторы, специалисты центра киберзащиты.
На какие вопросы нужно ответить перед разработкой решения:
Какие площадки связываем: ЦОДы или собственные площадки клиента?
Между крупными дата-центрами уже проложены каналы и есть телеком-операторы на выбор. На базе этих каналов можно выбрать разные услуги. А вот для связи с клиентской серверной, возможно, потребуется достроить канал от ближайшей точки присутствия провайдера.
Какое расстояние между площадками?
Даже если резерв находится в пределах одного города, важно выяснить расстояние. От этого зависит задержка сети и скорость.
Средневзвешенная задержка в пределах одного города будет меньше 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-сегменте.
В данной схеме есть свои узкие места, но в кейсе клиента она решила задачи с учетом ограниченного бюджета на переделку инфраструктуры.
В следующий раз поговорим, какие риски и особенности могут возникнуть у межпровайдерского георезервирования:
какие есть варианты для связи независимых дата-центров по России;
какие трудности появляются на больших расстояниях и как их преодолеть;
где между телеком-операторами возникают серые зоны, за которые никто не отвечает.