что такое отказоустойчивость сети
Как мы обеспечиваем отказоустойчивость работы инфраструктуры наших клиентов
Добрый день, уважаемые Хабраюзеры.
В данном посте я хотел бы рассказать подробнее о том, как мы обеспечиваем отказоустойчивость работы инфраструктуры наших клиентов.
Для примера взят стандартный офис (ПК, IP-телефония, WiFi) с разбивкой на подсистемы: ClientCloud, ClientLan, ClientPhone, ClientWiFi
Подсистема ClientLan предназначена для организации доступа ПК к другим подсистемам.
Подсистема ClientPhone предназначена для организации доступа IP-телефонов к подсистеме ClientCloud (IP-АТС).
Подсистема ClientWiFi предназначена для организации гостевого доступа мобильного оборудования (ноутбуки, коммуникаторы, планшетные компьютеры) к сети Интернет.
Доступ с подсистемы ClientWiFi ко всем подсистемам (ClientCloud, ClientLan, ClientPhone) запрещен настройками коммутатора.
В целях отказоустойчивости связи оборудования с подсистемой облака клиента предусматриваются две линии связи – основная (канал L2) и резервная (VPN через Интернет). Оборудование, расположенное на узле ЛВС в целях обеспечения бесперебойной работы сети подключается к источнику бесперебойного питания. Для создания отказоустойчивой системы коммутаторы объединяются в стек – Stacking Switch.
Узел ЛВС на Объекте включает в себя:
-активное оборудование уровня коммутации ЛВС;
-пассивное оборудование кроссирования портов;
-пассивное оборудование для организации размещения патч-кордов;
-пассивное оборудование для монтажа
Подключение объекта к сети производится при помощи двух независимых каналов связи – L2 (основной канал) и VPN через интернет (резервный). Логическая схема представлена на рисунке. Для обеспечения наибольшей отказоустойчивости операторы L2 и оператор сети интернет различны, либо используется независимое (различное) активное оборудование оператора. Доступ к сети интернет для ПК, принтеров, IP-телефонов, сети устройств Wi-Fi и других устройств происходит посредством данного подключения к сети интернет.
При пропадании основного канала L2 происходит переключение таблицы маршрутизации на коммутаторе третьего уровня, и трафик начинает проходить через резервный канал – VPN-канал. Данное переключение происходит посредством динамического протокола маршрутизации RIP версии 2.
При потере канала с доступом в интернет, основной канал остается в работе. Пропадает возможность поднятия резервного VPN-канала, а так же доступ в сеть интернет для пользователей ПК и устройств Wi-Fi сети.
Организация VPN канала происходит посредством существующего подключения к сети интернет через оператора связи. Защищенный VPN организуется посредством аппаратной реализации, используя оборудование Cisco ASA5505, задействовав технологии Site-to-site, IPsec.
Схема отказоустойчивости коммутаторов
Коммутаторы, расположенные в серверной стойке, для обеспечения отказоустойчивости объединяются в стек StackingSwitch. Это достигается перекрестным соединением портов стекирования таким образом, что при выходе из строя любого коммутатора, оставшиеся будут друг для друга доступны по альтернативному пути. Соединения внешней сети L2 и канала VPN подключаются в разные коммутаторы, для сохранения подключения к сети при выходе из строя коммутатора. Переключение прохождения трафика происходит полностью в автоматическом режиме.
Коммутаторы доступа обслуживают следующие подсистемы: ClientLan, ClientPhone и ClientWiFi. Подключение персональных компьютеров осуществляется на коммутаторы Switch1 (Extreme Summit X440-48t) и Switch2 (Extreme Summit X440-48t). IP-телефоны, используя технологию PoE, коммутируются на Switch3 и Switch4 (Extreme Summit X440-48p). Подсистема ClientWiFi на данных коммутаторах присутствует логически и подключается через контроллер Wi-Fi на порт коммутатора Switch3.
Для каждой подсистемы выделен свой VLAN и своя подсеть. Каждая подсистема имеет свой список доступа к другим подсетям (подсистемам).
При отказе одного из коммутаторов произойдет потеря связи только у ПК, непосредственно подключенных к данному коммутатору, не повлияв на работоспособность остальных. При выходе из строя коммутатора Switch1 (или канала L2) связь с подсистемой ClientCloud останется по каналу VPN. При отказе коммутатора Switch2 будет использоваться основной канал L2. При выходе из строя коммутатора Switch3 часть телефонов отключится, однако, кроссировкой предусмотрено, что в одном кабинете телефоны кроссируются на разные коммутаторы Switch3 и Switch4, и поэтому кабинет без связи не останется, т.е. часть телефонов будут работать.
После замены вышедшего коммутатора и ввода его в стек, к нему применяется единая стековая конфигурация. На случай выхода из строя коммутаторов или портов, к которым подключены магистрали, в стеке предусмотрены порты-партнеры, которые позволят, вручную переключив магистральный кабель, возобновить работу именно через необходимый канал.
Схема подключения подсистем к коммутаторам
Таким образом схема подключения клиента строиться так, что каждая подсистема выделена в свой VLAN и свою подсеть, что гарантирует защиту от негативного влияния одной сети на другую (вирус, большая нагрузка) и обеспечивает контроль доступа по сетям.
Видение отказоустойчивой, надежной, масштабируемой сети передачи данных
Воодушевленный философией сетевых технологий, технологиями передачи данных, да и вообще всем тем, что объясняет, как все работает, решаюсь написать ряд статей о том, что является эталоном сетевых решений, качественной реализацией или настройкой, или что подобным не является, но в современности присутствует, и жутко раздражает.
Что же в этот раз.
В видении построения сетей компании Cisco существует понятие трехуровневая модель.
Трехуровневая модель сети представляет собой некую иерархическую структуру передачи данных не в терминах протоколов или моделей (типа модели OSI или TCP/IP), а в терминах функционирования абстрактных элементов сети.
Из названия очевидно, что все элементы сети делятся на три так называемых уровня. Это деление позволяет строить отказоустойчивые, надежные, масштабируемые сети передачи данных. Роль уровней скорее логическая, и не обязательно существует физическая привязка к конкретному оборудованию. 
Базовый уровень (Core Layer)
Является ядром сети. Единственное, что он должен выполнять — молниеносно перенаправлять пакеты из одного сегмента в другой. Базовый уровень отвечает только за скоростную коммутацию трафика, он не отвечает за маршрутизацию. Исходя из этого, базовый уровень нужно обеспечить высокой степенью отказоустойчивости и надежности. Обычно дублируют устройства, работающие на базовом уровне. Рассмотрим, к примеру Cisco WS-C6503-E.
Уровень распределения (Distribution Layer)
Представляет собой «прослойку» между уровнем доступа и уровнем ядра (базовым уровнем). Именно на этом уровне осуществляется контроль над сетевой передачей данных. Также можно создавать широковещательные домены, создавать VLAN’ы, если необходимо, а так же внедрять различные политики (безопасности и управления). На уровне распределения может осуществляться правило обращения к уровню ядра. Приведу некоторые особенности и рекомендации при проектировании уровня распределения, которые выделяют ведущие производители сетевого оборудования.
Уровень доступа (Access Layer)
Важно!
Необходимо при построении сети придерживаться правила, чтобы функции одного уровня не выполнял другой и наоборот.
Естественно, что такая модель приемлема для сети крупного предприятия, в интересах которого функционирование ее должным образом. Немало нужно затратить сил и, времени и средств, чтобы выработать проект, внедрить и обслуживать такую сеть. Но зато это стоит того!
Обзор вариантов реализации отказоустойчивых кластеров: Stratus, VMware, VMmanager Cloud
Есть разновидности бизнеса, где перерывы в предоставлении сервиса недопустимы. Например, если у сотового оператора из-за поломки сервера остановится биллинговая система, абоненты останутся без связи. От осознания возможных последствий этого события возникает резонное желание подстраховаться.
Мы расскажем какие есть способы защиты от сбоев серверов и какие архитектуры используют при внедрении VMmanager Cloud: продукта, который предназначен для создания кластера высокой доступности.
Предисловие
В области защиты от сбоев на кластерах терминология в Интернете различается от сайта к сайту. Для того чтобы избежать путаницы, мы обозначим термины и определения, которые будут использоваться в этой статье.
На первый взгляд самый привлекательный вариант для бизнеса тот, когда в случае сбоя обслуживание пользователей не прерывается, то есть кластер непрерывной доступности. Без КНД никак не обойтись как минимум в задачах уже упомянутого биллинга абонентов и при автоматизации непрерывных производственных процессов. Однако наряду с положительными чертами такого подхода есть и “подводные камни”. О них следующий раздел статьи.
Continuous availability / непрерывная доступность
Бесперебойное обслуживание клиента возможно только в случае наличия в любой момент времени точной копии сервера (физического или виртуального), на котором запущен сервис. Если создавать копию уже после отказа оборудования, то на это потребуется время, а значит, будет перебой в предоставлении услуги. Кроме этого, после поломки невозможно будет получить содержимое оперативной памяти с проблемной машины, а значит находившаяся там информация будет потеряна.
Для реализации CA существует два способа: аппаратный и программный. Расскажем о каждом из них чуть подробнее.
Программный способ.
На момент написания статьи самый популярный инструмент для развёртывания кластера непрерывной доступности — vSphere от VMware. Технология обеспечения Continuous Availability в этом продукте имеет название “Fault Tolerance”.
В отличие от аппаратного способа данный вариант имеет ограничения в использовании. Перечислим основные:
Мы не стали расписывать конкретные конфигурации нод: состав комплектующих в серверах всегда зависит от задач кластера. Сетевое оборудование описывать также смысла не имеет: во всех случаях набор будет одинаковым. Поэтому в данной статье мы решили считать только то, что точно будет различаться: стоимость лицензий.
Стоит упомянуть и о тех продуктах, разработка которых остановилась.
Есть Remus на базе Xen, бесплатное решение с открытым исходным кодом. Проект использует технологию микроснэпшотов. К сожалению, документация давно не обновлялась; например, установка описана для Ubuntu 12.10, поддержка которой прекращена в 2014 году. И как ни странно, даже Гугл не нашёл ни одной компании, применившей Remus в своей деятельности.
Предпринимались попытки доработки QEMU с целью добавить возможность создания continuous availability кластера. На момент написания статьи существует два таких проекта.
Первый — Kemari, продукт с открытым исходным кодом, которым руководит Yoshiaki Tamura. Предполагается использовать механизмы живой миграции QEMU. Однако тот факт, что последний коммит был сделан в феврале 2011 года говорит о том, что скорее всего разработка зашла в тупик и не возобновится.
Второй — Micro Checkpointing, основанный Michael Hines, тоже open source. К сожалению, уже год в репозитории нет никакой активности. Похоже, что ситуация сложилась аналогично проекту Kemari.
Таким образом, реализации continuous availability на базе виртуализации KVM в данный момент нет.
Итак, практика показывает, что несмотря на преимущества систем непрерывной доступности, есть немало трудностей при внедрении и эксплуатации таких решений. Однако существуют ситуации, когда отказоустойчивость требуется, но нет жёстких требований к непрерывности сервиса. В таких случаях можно применить кластеры высокой доступности, КВД.
High availability / высокая доступность
В контексте КВД отказоустойчивость обеспечивается за счёт автоматического определения отказа оборудования и последующего запуска сервиса на исправном узле кластера.
В КВД не выполняется синхронизация запущенных на нодах процессов и не всегда выполняется синхронизация локальных дисков машин. Стало быть, использующиеся узлами носители должны быть на отдельном независимом хранилище, например, на сетевом хранилище данных. Причина очевидна: в случае отказа ноды пропадёт связь с ней, а значит, не будет возможности получить доступ к информации на её накопителе. Естественно, что СХД тоже должно быть отказоустойчивым, иначе КВД не получится по определению.
Таким образом, кластер высокой доступности делится на два подкластера:
VMmanager Cloud
Наше решение VMmanager Cloud использует виртуализацию QEMU-KVM. Мы сделали выбор в пользу этой технологии, поскольку она активно разрабатывается и поддерживается, а также позволяет установить любую операционную систему на виртуальную машину. В качестве инструмента для выявления отказов в кластере используется Corosync. Если выходит из строя один из серверов, VMmanager поочерёдно распределяет работавшие на нём виртуальные машины по оставшимся нодам.
В упрощённой форме алгоритм такой:
Практика показывает, что лучше выделить одну или несколько нод под аварийные ситуации и не развёртывать на них ВМ в период штатной работы. Такой подход исключает ситуацию, когда на “живых” нодах в кластере не хватает ресурсов, чтобы разместить все виртуальные машины с “умершей”. В случае с одним запасным сервером схема резервирования носит название “N+1”.
Рассмотрим по каким схемам пользователи VMmanager Cloud реализовывали кластеры высокой доступности.
FirstByte
Компания FirstByte начала предоставлять облачный хостинг в феврале 2016 года. Изначально кластер работал под управлением OpenStack. Однако отсутствие доступных специалистов по этой системе (как по наличию так и по цене) побудило к поиску другого решения. К новому инструменту для управления КВД предъявлялись следующие требования:
Отличительные черты кластера:
Данная конфигурация подходит для хостинга сайтов с высокой посещаемостью, для размещения игровых серверов и баз данных с нагрузкой от средней до высокой.
FirstVDS
Компания FirstVDS предоставляет услуги отказоустойчивого хостинга, запуск продукта состоялся в сентябре 2015 года.
К использованию VMmanager Cloud компания пришла из следующих соображений:
В случае общего отказа Infiniband-сети связь между хранилищем дисков ВМ и вычислительными серверами выполняется через Ethernet-сеть, которая развёрнута на оборудовании Juniper. “Подхват” происходит автоматически.
Благодаря высокой скорости взаимодействия с хранилищем такой кластер подходит для размещения сайтов со сверхвысокой посещаемостью, видеохостинга с потоковым воспроизведением контента, а также для выполнения операций с большими объёмами данных.
Эпилог
Подведём итог статьи. Если каждая секунда простоя сервиса приносит значительные убытки — не обойтись без кластера непрерывной доступности.
Однако если обстоятельства позволяют подождать 5 минут пока виртуальные машины разворачиваются на резервной ноде, можно взглянуть в сторону КВД. Это даст экономию в стоимости лицензий и оборудования.
Кроме этого не можем не напомнить, что единственное средство повышения отказоустойчивости — избыточность. Обеспечив резервирование серверов, не забудьте зарезервировать линии и оборудование передачи данных, каналы доступа в Интернет, электропитание. Всё что только можно зарезервировать — резервируйте. Такие меры исключают единую точку отказа, тонкое место, из-за неисправности в котором прекращает работать вся система. Приняв все вышеописанные меры, вы получите отказоустойчивый кластер, который действительно трудно вывести из строя.
Если вы решили, что для ваших задач больше подходит схема высокой доступности и выбрали VMmanager Cloud как инструмент для её реализации, к вашим услугам инструкция по установке и документация, которая поможет подробно ознакомиться с системой. Желаем вам бесперебойной работы!
P. S. Если у вас в организации есть аппаратные CA-серверы — напишите, пожалуйста, в комментариях кто вы и для чего вы их используете. Нам действительно интересно услышать для каких проектов использование такого оборудование экономически целесообразно 🙂
Вопросы построения сети. Проприетарное рабство, отказоустойчивость и модульность (часть 1)
Введение
Сегодня расскажем как построить максимально отказоустойчивую сетевую инфраструктуру предприятия, с минимальной привязкой к конкретному вендору, преимущественно на открытых протоколах и стандартах.
Условно говоря, сетевую инфраструктуру можно разделить на ряд компонентов:
ЛВС (локальная вычислительная сеть) — IT-инфраструктура на основе группы стандартов IEEE 802.3.
БЛВС (беспроводная локальная вычислительная сеть) — IT-инфраструктура на основе группы стандартов IEEE 802.11, так или иначе интегрированная с ЛВС.
Вспомогательные системы (система управления IP пространством, инвентарная система, система описания сетевых сервисов, системы мониторинга).
Сегодня начнем с ЛВС.
Долой проприетарное рабство!
Каждый производитель активного сетевого оборудования предлагает свои проприетарные решения для упрощения настройки администрирования сети, для построения высоко надежных и отказоустойчивых систем. И эти решения могут быть вполне себе эффективными и полезными. Но у проприетарных решений есть недостатки:
Появляется зависимость от конкретного производителя, в случае необходимости замены оборудования или масштабирования сети не так просто перейти на другого производителя;
Повышаются и сужаются требования к персоналу (инженер должен знать конкретные решения конкретного производителя);
Усложняется процесс поиска и устранения неисправностей и усиливается необходимость контракта на техническую поддержку производителя.
Поэтому мы строим вендор-независимую отказоустойчивую сеть, для этого необходимо минимизировать использование проприетарных протоколов — отдаем предпочтение открытым стандартам. Плюсы отказа от объединения физических коммутаторов в кластер или стек:
Минимизация масштабов простоя сервиса в случае сбоя в ПО на одном из физических коммутаторов — это не приведет к сбою всего виртуального коммутатора или стека, и, как следствие, простою сервиса;
Унификация настроек коммутаторов (первый порт это всегда Gi1/0/1, а не Gi3/0/1);
Минимизация использования проприетарных технологий и минимизации зависимости от вендора;
Минимизация масштабов простоя сервиса в случае обновления ПО и перезагрузки. Несомненно, производители предлагают механизмы обновления ПО без простоя, но это на данный момент не все производители умеют, и не все инженеры будут изучать мануал, а если и будут, то все равно попросят maintenance window у бизнеса для перестраховки;
Минимизация простоя сервиса в случае ошибки по причине человеческого фактора. Например, если администратор случайно перезагрузит коммутатор доступа, то перезагрузится только 1 устройство, а не стек из Х коммутаторов. А если инженер случайно перезагрузит коммутатор распределения или ядра, то простой сервисов ограничится только временем сходимости сети;
Простота замены оборудования: достаточно скопировать бэкапный конфиг и подключить устройство в сеть, без сложных и рискованных процедур по объединению оборудования в стек или кластер; никогда не знаешь наверняка, все ли пройдет без сбоев и перезагрузок.
Минусы отказа от объединения физических коммутаторов в кластер или стек:
Потребуется увеличение количества физических линков (удорожание СКС). Отказоустойчивость или дешевизна, нужно выбрать одно;
Усложнится (сделается не loop free) L2 домен (этим пугают производители, предлагая проприетарные решения). Решается грамотной настройкой выбранного протокола группы STP;
Усложнится процесс администрирования, так как будет больше логических устройств. Решается применением автоматизации, которая не предусматривает подключение к оборудованию инженерами “руками” для решения рутинных задач;
Замедлится сходимость сети — это явный минус. Если стоит задача максимально ускорить сходимость сети и если сходимость сети в 1 минуту уже очень долго для бизнеса, лучше присмотреться к проприетарным решениям, так как любой протокол группы STP в этом случае будет проигрывать.
Отказоустойчивость (больше линков, больше железа, меньше технологий)
Active-passive vs active-active
Выбор схемы active-active не является оптимальным из-за того, что данные мониторинга загрузки оборудования в режиме active-active не будут достаточно информативными, чтобы гарантировать работу сети в случае выхода из строя одного из компонентов.
Пример построения сети на L2:
Три кита отказоустойчивости:
Резервирование линков. Каждый логический канал между активным сетевым оборудованием должен состоять как минимум из двух физических каналов;
Резервирование оборудования. Каждый логический модуль уровня ядра и распределения должен состоять из двух физических устройств;
Грамотная настройка оборудования.
Резервирование линков и оборудования
Потребуются две серверные для построения территориально-распределенных компонентов ЛВС, чтобы минимизировать влияние аварии в одной из серверных на работу всей сети. Под авариями подразумеваются такие события, как продолжительное отключение электропитания, физическое повреждение каналов связи, пожар, поломки оборудования и пр;
Потребуется два провайдера Интернета (или других сервисов) до каждой серверной (оптика). Оптические трассы могут быть перекопаны техникой, поэтому важно еще иметь дополнительный линк провайдера по радио.
Три источника проблем
Неправильная настройка оборудования. Все может отлично работать, и даже продолжительное время, но какой-то внешний фактор может нарушить работу сети;
Человеческий фактор. Настройка и администрирование оборудования человеком рано или поздно приведет к ошибкам. Человек не может выдавать одинаковый результат втечение продолжительного времени. Например, если администратор вот уже Х лет не делал ни одной ошибки, не факт что завтра он не спутает консоль коммутатора доступа с консолью коммутатора ядра;
Модульность (занудно, но важно)
Модульность — это свойство системы, связанное с возможностью ее декомпозиции на ряд внутренне связанных между собой модулей (Wi-Ki).
В зависимости от требований бизнеса, сетевую инфраструктуру удобно разделить на несколько логических компонентов (модулей), например:
Модуль ядра сети (коммутаторы ядра сети) предназначен для быстрой коммутации и маршрутизации, объединения других модулей в единую систему. Чаще всего это будут два коммутатора, которые производители позиционируют как “Core Switch”. Лучше территориально разнести по разным серверным;
Модуль кампусной сети (коммутаторы уровней распределения и доступа). Каждый логический коммутатор уровня распределения должен состоять из двух физических коммутаторов, лучше территориально разнести по разным серверным. Коммутаторы уровня доступа должны состоять из одного физического коммутатора. В случае надобности подключения оконечных сетевых устройств, требующих питание по active PoE, необходимо предусмотреть коммутаторы доступа с поддержкой active PoE. При этом должен быть отражен расчет бюджета PoE;
Модуль подключения серверного оборудования. Как правило, модуль представляет собой набор из межсетевых экранов, высокопроизводительных коммутаторов и модулей расширения фабрики с поддержкой IEEE 802.1BR, предназначенных для центров обработки данных. Тут все сильно зависит от масштабов бизнеса;
Модуль подключения к сети Интернет. Представляет собой набор коммутаторов, межсетевых экранов, с поддержкой подключения к удаленным объектам (IPSec VPN) и подключения удаленных рабочих мест (SSL/IPsec VPN) в случае надобности;
Модуль вспомогательных систем управления может включать в себя следующие компоненты: система управления IP-пространством IPAM (IP Address Management), инвентарная система, система описания сетевых сервисов или управления конфигурацией, системы мониторинга, система контроля доступа NAC (Network Admission Control), NTP, FTP, TFTP и пр.
Любой выбор — это всегда баланс между плюсами и минусами того или иного решения. Предлагаемый вариант подхода к построению сети призван удовлетворить трем главным для нас критериям: отказоустойчивость, простота, независимость от модели и производителя.