георезервирование что это такое
Инфраструктура в разных концах города: как не проворонить сетевую связность
Сценарии георезервирования и варианты связности в рамках одной сети дата-центров в одном городе.
Размещение ИТ-инфраструктуры на двух и более площадках решает разные задачи: помогает быстро расширить ресурсы или стать ближе к конечному потребителю в случае размещения контента в разных CDN-зонах. Но особенно часто такое распределение систем используется для георезервирования: когда при выходе из строя одной площадки вторая находится вне зоны аварии и берет на себя критически важные нагрузки.
Обеспечить георезервирование можно, если разместить оборудование в удаленных дата-центрах или взять ресурсы в разных облачных зонах доступности. Но важно не забыть про сетевую связность и на берегу выяснить несколько вопросов у телеком-провайдера. Иначе сбой сети сведет на нет все плюсы распределенной архитектуры.
В октябре по просьбе наших подписчиков мы обсудили тему сетевой связности на эфире в Салатовой телеге. Здесь решили продолжить это обсуждение в двух частях:
Кому и какое георезервирование нужно
В идеальном сценарии георезервирование обеспечивает скорость восстановления. Что бы ни произошло на основной площадке, сначала переключимся на резервную, а потом разберемся в проблеме и устраним аварию. Реализовать эту идею можно разными способами: единой для всех таблетки “георезервирование” не существует.
С точки зрения сети важно продумать нужное качество соединения, резервирование каналов на всех уровнях и информационную безопасность. Для этого комплексно анализируем, какую систему, как и для чего резервируем. Например, у нас к проекту обычно подключаются не только сетевые инженеры, но и группы виртуализации, резервного копирования, архитекторы, специалисты центра киберзащиты.
На какие вопросы нужно ответить перед разработкой решения:
Какие площадки связываем: ЦОДы или собственные площадки клиента?
Между крупными дата-центрами уже проложены каналы и есть телеком-операторы на выбор. На базе этих каналов можно выбрать разные услуги. А вот для связи с клиентской серверной, возможно, потребуется достроить канал от ближайшей точки присутствия провайдера.
Какое расстояние между площадками?
Даже если резерв находится в пределах одного города, важно выяснить расстояние. От этого зависит задержка сети и скорость.
Какие нужны показатели допустимого времени восстановления (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 Ethernet в аренду. Тогда в конечных точках сразу будет установлен коммутатор.
Чаще всего этот вариант берут компании с объемом трафика до 1 гигабита между площадками с “физикой” — так получается выгоднее всего. На самом деле, в таком сценарии мы можем предоставить порт и на 10 гигабит.
А вот все, что больше, нужно прорабатывать отдельно. Не всегда IP-транспорт способен обеспечить передачу такого объема трафика без потерь.
Поэтому, если трафика много, есть DWDM — спектральное уплотнение канала. Простыми словами: DWDM позволяет отправлять больше информации по одному волокну. Для этого используется оптоволокно с дальномерными трансиверами на концах каждой связки. Такое оборудование стоит довольно дорого, зато за счет уплотнения можно сильно сэкономить на оптике.
Облачные сервис-провайдеры строят DWDM-системы между своими площадками, чтобы с запасом обеспечить транспорт для всех “растянутых” облачных сервисов. Но и некоторые крупные клиенты могут создать DWDM-решение для собственных нужд.
Внутри DWDM уже заложена отказоустойчивость. Каждый трансивер подключен сразу к двум непересекающимся трассам. Для переключения между ними используется коммутатор L1, в котором установлен датчик света. Если датчик “не видит” света в волокне, то переводит трафик на резервный канал (на самом деле все чуть сложнее, но об этом как-нибудь в следующий раз).
Все эти сценарии помогут за счет ресурсов провайдера обеспечить нужное RTO c практически мгновенным переключением на резерв. Вот по каким признакам можно убедиться, что у сервис-провайдера хорошо организовано резервирование сети между площадками:
На уровне самих каналов достаточная пропускная способность обеспечивается за счет оборудования Enterprise-уровня.
Например, у нас на этом уровне предусмотрено двойное резервирование сети. Что это значит: мы наблюдаем за утилизацией сети на мониторинге и следим, чтобы ее загруженность не превышала 50%. При такой загрузке даже падение половины линков нам не страшно. Как только загрузка начинает регулярно превышать 50%, пора модернизировать сеть. Где-то наращивать линки, где-то менять оборудование на более мощное.
Если нужно соединить с облаком собственную площадку клиента, вопрос стоимости резерва может встать чуть острее. Достраивать оптику до клиента бывает недешево само по себе, а нам вдобавок нужно продумать резервирование этого канала. Здесь уже есть варианты: достроить второй канал, арендовать второй канал у подрядчиков на площадке клиента или обойтись резервом через интернет с учетом его издержек.
Посмотрим, как можно применить сразу несколько вариантов в конкретном проекте.
У одного из крупных клиентов на территории Москвы было 2 офиса с собственными серверными. Изначально инфраструктура не предполагала других площадок.
Но затем произошла авария и компания задумалась о послеаварийном восстановлении за пределами офиса. Резервную инфраструктуру решили разместить в защищенном облаке DataLine Cloud-152. В случае падения виртуальной машины на одной из клиентских площадок резервная ВМ должна мгновенно подниматься в Cloud-152.
До этого проекта реплицировать машины куда-то еще не планировали, поэтому сетевую часть нужно было переделать. При этом из-за финансовых ограничений клиент не мог полностью перестроить всю инфраструктуру. В этих условиях инженеры продумывали резерв на разные случаи отказа: если будет сбой у одного из операторов связи, либо если отключится питание в серверной.
В итоге к офисам компании подключились через 2 канала: один канал арендовали у DataLine, а второй у другого оператора связи. Получилось резервирование сети за счет двух независимых телеком-операторов.
Из-за особенностей клиентской инфраструктуры нужно было минимизировать возможные проблемы единого растянутого L2-домена. Мы посоветовали клиенту разделить домен на два сегмента с его стороны. К нам на площадку NORD приходят оба VLAN’а, и, в случае падения ВМ на одной из основных площадок заказчика, на нашей они поднимутся сразу в нужном IP-сегменте.
В данной схеме есть свои узкие места, но в кейсе клиента она решила задачи с учетом ограниченного бюджета на переделку инфраструктуры.
В следующий раз поговорим, какие риски и особенности могут возникнуть у межпровайдерского георезервирования:
Верите ли вы в бога надежности?
В этой статье я хотел бы рассказать о некоторых мерах, которые мы применяем (ну, или почти применяем) в ДомКлик для обеспечения надежности работы наших сервисов. Честно говоря, возможно, какие-то из этих процедур избыточны, но ежегодный аудит и постоянные проверки заставляют нас дуть на воду и готовиться к худшему.
Также я постараюсь подробно отразить свою субъективную оценку по каждому из перечисленных мероприятий, на предмет сложности реализации и эффективности.
Аварийный план восстановления работы сервиса
Логически рассуждая, если вам понадобился такого рода план, то явно надежность вашего сервиса хотя бы раз дала серьезный сбой. По сути, аварийный план — это схема процесса, по которому должна действовать организация в случае критического сбоя или катастрофы, приведших к длительной (более 4 часов) недоступности сервисов или систем. Навскидку могу привести такие примеры подобного рода катастроф:
Поставщика необходимой смежной услуги лишили лицензии:
Для чего это надо?
В первую очередь, чтобы не допустить панику и придумать хотя бы какие-то меры выживания организации в случае такого форс-мажора. Подобного рода катастрофы очень редки, и зачастую никто в компании не понимает, что делать при возникновении такой ситуации. А нужно понимать и отреагировать так, чтобы снизить ущерб до минимального уровня. Правда, паника, вероятно, всё равно будет. В нужный момент о плане могут не вспомнить, либо он окажется неактуальным.
Эффективность: 3/10
Сложность реализации: 2/10
Георезервирование критичных сервисов и систем
Эта мера как раз и должна помочь справиться с катастрофой. Суть её (как понятно из названия) состоит в организации второго/третьего ЦОД, в котором дублировались бы все критичные системы и сервисы. Решение безумно дорогое и технологически сложное (поскольку возникают вопросы с параллельной выкаткой релизов в несколько production-окружений, вопросы синхронизации баз данных и т.д.).
Для чего это надо?
Если знать, как это блюдо готовить, и научиться быстро переключать трафик с одного ЦОД на другой (в случае горячего резерва) или распределять трафик между ЦОД, автоматически балансируя его в зависимости от доступности сервисов, то эта мера защищает от большинства проблем и катастроф. По сути, многие внутренние проблемы сервисов не коснутся клиентов, и это замечательно!
Эффективность: 8/10
Сложность реализации: 10/10
Аварийные учения
Это эмуляция возникновения проблемы (точки отказа оборудования или приложения). Такое мероприятие правильно проводить в production-среде. Для минимизации негативного эффекта для пользователей обычно мы проводим учения ночью, а также во время новогодних и майских праздников.
Что именно проверяем:
Отказ элементов сетевой инфраструктуры (коммутаторов, каналов связи и т.д.) для проверки переключения на дублирующие системы.
Выход из строя отдельных физических серверов БД для проверки переключения приложений с master-баз данных на реплики.
Выход из строя серверов кластера Kubernetes для проверки балансировки трафика и перезапуска подов приложений на других серверах кластера.
Отказ отдельных микросервисов для проверки отсутствия негативного эффекта на смежные сервисы (если сломался один конкретный микросервис, то остальные должны уметь с этим работать).
Эмулируем DDoS-атаки на публичные веб-ресурсы для проверки механизмов защиты от DDoS и проверки логики работы WAF.
Эмулируем повышенную легитимную нагрузку для проверки готовности сервисов к пикам клиентского трафика.
Эмулируем отказ брокеров сообщений (RabbitMQ и Kafka) для проверки работоспособности автоматической балансировки сообщений и отсутствия потерь отдельных сообщений.
Эмулируем отказ отдельных потребителей для проверки работы микросервисов в таких ситуациях.
В каждом случае проверяем механизмы уведомления и мониторингов, а также время их срабатывания.
Для чего это надо?
Убедиться в том, что ваш сервис готов к отказам и корректно обработает точечный выход из строя элементов программно-аппаратного комплекса. К тому же лишний раз можно убедиться в корректной работе инструментов мониторинга и уведомления, полноте логов и сервисных сообщений для разбора возможных проблем.
Стоит понимать, что проведение таких учений требует значительных трудозатрат в нерабочее время. Да и в рабочее тоже, поскольку при неожиданном поведении сервисов проблемы нужно будет устранить в рамках тех долга.
Эффективность: 7/10
Сложность реализации: 6/10
Дежурная смена разработчиков
Никто не знает все нюансы работы сервиса лучше, чем тот, кто его разрабатывает! И даже если проблема не в самом сервисе, а лишь проявляется в его работе, разработчик гораздо быстрее чем кто бы то ни было сможет диагностировать причину или сервис, ставший источником проблемы.
Поэтому для каждого крупного продукта мы ввели функциональность «Дежурного разработчика». По сути, это человек, который занимается разработкой группы сервисов крупного продукта. «Дежурный разработчик» обязан:
Быть на связи круглосуточно. Отвечать на звонки с номеров службы поддержки в любое время.
Постоянно иметь доступ к средствам разработки и диагностики (носить с собой ноутбук).
В случае возникновения проблемы в течение 10 минут приступить к её разбору (даже если проблема случилась ночью).
Не отключать каналы мониторинга (не отключать звук оповещений в соответствующих каналах в мессенджерах) и реагировать на возникновение проблем высокой важности.
Дежурство длится одну неделю. Сами дежурные назначаются по желанию, с условием того, что один разработчик не может дежурить две недели подряд. Дежурство оплачивается дополнительно.
Для чего это надо?
Помимо сугубо утилитарного эффекта (разработчик гораздо быстрее разберется в проблеме своего сервиса, чем кто бы то ни было), есть и психологический: если сервис будет написан качественно, то дежурного разработчика никто дергать не будет. Легкие деньги 😉
Эффективность: 7/10
Сложность реализации: 5/10
Управление инцидентами
В рамках статьи я буду считать инцидентом сбой в работе сервиса. Даже если эта проблема не повлияла на конечных пользователей, всё равно это инцидент.
Суть процедуры управления инцидентами состоит в том, чтобы периодически (у нас это происходит один раз в неделю) публичный разбирать сбои и разрабатывать меры по их недопущению в будущем. А также отслеживать реализацию таких мер, злостно карая за рецидивы.
При этом необходимо придерживаться здравого смысла: некоторые инциденты не удается разобрать до конца (они не повторяются и корневая причина их возникновения может остаться неизвестной). В таком случае после мониторинга их можно просто закрыть. Важен сам факт периодического публичного разбора.
Для чего это надо
Одна голова хорошо, а две — лучше. Разбор инцидентов может помочь выдвинуть новые гипотезы о причинах, либо коллеги могут предложить новые способы недопущения таких инцидентов. К тому же публичный стыд — это мотиватор побыстрее сделать так, чтобы в сервисах твоей зоны ответственности никаких инцидентов не было.
Эффективность: 5/10
Сложность реализации: 4/10
Координатор рисков
Хорошо иметь отлаженные механизмы и процедуры по работе с инцидентами. Но еще лучше — даже не допускать возникновения такого рода проблем. Поэтому в качестве одной из мер по повышению надежности работы сервисов может быть найм специального человека, который изучал бы текущие схемы работы инфраструктуры и приложений и заранее формулировал «риски» — проблемы в работе сервисов и систем, которые, ВОЗМОЖНО, могут произойти. Этот же человек может ставить задачи командам разработки в качестве тех. долга и контролировать их выполнение.
Для чего это надо?
Человек, не загруженный рутиной и постоянной работой, может действительно накопать «пробелы» в исторически сложившейся модели работы компании. Может даже не технического плана. Проблема в том, что иногда для оправдания своего существования такие люди могут высасывать «риски» из пальца. Нужен строгий контроль задач координатором рисков.
Эффективность: 1/10
Сложность реализации: 4/10
Контроль bus-фактора
Этот способ повышения надежности применим только в средних и крупных компаниях. Иногда возникают ситуации, когда внутреннюю логику работы сервиса знает только один разработчик. Да, можно попытаться смягчить эту проблему, организовав документирование сервиса и кода (и убиваться, поддерживая актуальность документации), однако это всё равно зачастую не заменяет практическое знание работы сервиса. В идеале, логику работы каждого сервиса и его специфику должны знать как минимум два разработчика.
В ДомКлик мы отслеживаем такие ситуации (используем для этого Skilltracker) и в рамках работы над техническим долгом организуем обмен знаний между разработчиками.
Для чего это надо?
Для снижения зависимости работы сервисов от одного человека. В каждый момент времени нужно иметь как минимум двоих, кто может оперативно разобраться в проблеме и/или доработать сервис.
Эффективность: 4/10
Сложность реализации: 4/10
Тест на проникновение
Сложные веб-порталы, особенно построенные на основе микросервисной архитектуры, используют огромное количество API endpoints. Каждый день создаются новые взаимодействия между сервисами, новые экранные формы и интерфейсы, для наполнения которых разрабатываются новые обработчики.
Иногда API разрабатываются не совсем удачно. Сама структура передаваемых данных или URLа может быть плохой, либо возможен перебор идентификаторов — за всеми такими ситуациями разработчик не уследит, и их могут просмотреть на code review.
Для чего это надо
Человек, профессионально занимающийся взломом сайтов, достаточно легко и быстро находит все дыры и несостыковки (даже напрямую не влияющие на безопасность) в разработанных API. Всегда полезно иметь посторонний взгляд дружественного хакера. Проблема возникает, когда нужно «срочно-пресрочно» выкатить фичу, а пентестер нашел в API этой фичи уязвимость, да такую, которую не исправить за час.
Эффективность: 6/10
Сложность реализации: 7/10
Защита от DDoS/WAF
Если пользователи работают с вашим сервисом через публичный интернет и ваш ресурс достаточно популярен, то рано или поздно вы столкнётесь с проблемой DDoS-атак. Обычно это коварные китайские боты, которые, словно свора гончих, накинутся на ваш сайт и попытаются достучаться до всех уголков неавторизованной зоны. Для борьбы с этим явлением повсеместно используют различные продукты и сервисы защиты от DDoS-атак.
Для чего это надо
Отсекать китайских ботов и недружелюбных хакеров. Причем зачастую атаки не совсем «тупые» и выполняются с распределенных IP-адресов. Поэтому простой защиты от DDoS иногда недостаточно и применяют Web Application Firewall. На базе продуктов этого типа можно настраивать более тонкую логику отсечения трафика. Только главное не переусердствовать и не порезать легитимных пользователей.
Эффективность: 6/10
Сложность реализации: 4/10
Контроль трафика между сервисами
Зачастую возникает ситуация, когда сервис, взаимодействующий с кучей смежных сервисов по событиям, долгое время был недоступен (ну или была какая-то сетевая проблема и были недоступны смежные сервисы). И вот, когда работа системы восстанавливается, этот сервис начинает отрабатывать накопленные сообщения и с максимальной скоростью дергать смежные сервисы. А те не готовы к такой нагрузке.
Для чего это надо
Чтобы исключить такой легитимный DDoS, который может повлиять на доступность смежных сервисов, нужно контролировать межсервисный трафик и не допускать его драматического увеличения, растягивая по времени. Сделать это можно разными механизмами (например, на основе Service Discovery).
Эффективность: 4/10
Сложность реализации: 5/10
Мониторинг ресурсов
Компании и сервисы растут из года в год и начинают потреблять всё больше и больше ресурсов. Это происходит постепенно, изо дня в день. Рано или поздно наступает момент, когда срабатывают мониторинги и вы понимаете, что места на сервере БД осталось на пару дней. Необходимо заранее и периодически проверять и прогнозировать достаточность ресурсов инфраструктуры.
Для чего это надо
Добавить объем жесткого диска может оказаться не так просто. Например, потребуется остановка сервера, либо вообще закупка более мощной инфраструктуры. Такое за пару дней не сделать. Если же спрогнозировать необходимость усиления ресурсов за полгода, то можно заранее закупить и установить необходимое оборудование.
Эффективность: 3/10
Сложность реализации: 2/10
Мониторинг сертификатов
Доступ к большинству порталов, требующих авторизации или регистрации пользователей, защищается SSL-сертификатами для предотвращения подмены ответа сервера. При этом сертификаты на серверной части имеют определенный период действия (обычно длительный). Проблема в том, что каждый раз срок действия сертификата истекает неожиданно. И вот — опять зима неожиданно наступила.
Для чего это надо
Окончание срока действия сертификата может в мгновение ока сделать портал недоступным для пользователей. Иногда бывает сложно быстро выпустить новый сертификат, и период недоступности может составить несколько часов. Лучше не допускать такого и настроить мониторинг срока действия всех сертификатов, чтобы иметь в запасе несколько недель до момента его истечения.
Эффективность: 3/10
Сложность реализации: 1/10
В заключение
Надеюсь, хотя бы часть из перечисленных мер может оказаться полезными для вас и ваших сервисов. Хочу поблагодарить Александра Молчанова за помощь в подготовке статьи. Для удобства я свел все предлагаемые меры в единую таблицу: