Анализ предметной области. Аппаратные решения для обеспечения высокой доступности. Использование сетей хранения данных. Избыточные сетевые соединения. Технология адаптивной декомпозиции. Защитное зануление системы. Надежность программного обеспечения.
При низкой оригинальности работы "Построение кластера высокой доступности на основе ОСРВ QNX Neutrino", Вы можете повысить уникальность этой работы до 80-100%
Квалификационная работа на тему «Построение кластера высокой доступности на основе ОСРВ QNX Neutrino» содержит 90 листов пояснительной записки, 18 рисунков, 12 слайдов графического материала. Теоретическая часть состоит из исследования существующих систем высокой доступности, исследования возможностей ОСРВ QNX Neutrino и интерфейсов взаимодействия между компонентами систем высокой доступности.Реализация вычислений в режиме непрерывной готовности затрагивает практически все аспекты разработки системы - в ней не должно быть ни одного функционального узла, отказ которого может вывести из строя систему в целом. 2) в части доступности устройств ввода-вывода и, прежде всего дисков, возможны следующие конфигурации: а) кластер с разделяемыми дисками (shared disk) подразумевает, что любой узел имеет прозрачный доступ к любой файловой системе общего дискового пространства. Такая схема применяется для того, чтобы в случае отказа одного узла ресурс мог быть передан другому узлу. с) в соответствии с еще одной схемой локальные диски узлов кластера зеркалируются (дублируются). Весьма важной особенностью кластера является так называемый единый образ системы (Single System Image, SSI), благодаря которому пользователи могут видеть серверы в кластере как единое целое. Решает, в том числе такую проблему как Split-Brain - ситуация, когда связь между узлами теряется, но оба они живы, каждый из них думает, что другой умер и пытается забрать все ресурсы себе, это может привести к повреждению данных, поэтому своевременный вывод одного из узлов из кластера решит эту проблему.Нулевой защитный проводник(в системе TN - S - PE - проводник) - проводник, соединяющий открытые проводящие части с глухозаземленной нейтральной точкой источника питания трехфазного тока или с заземленным выводом источника питания однофазного тока. Нулевым рабочим проводником (в системе TN - S - N - проводник) называют проводник, предназначенный для питания электроприемников, соединенный с глухозаземленной нейтральной точкой генератора или трансформатора в сетях трехфазного тока, с глухозаземленным выводом источника однофазного тока, с глухозаземленной точкой источника в сетях постоянного тока, в установках с напряжением до 1 КВ. Совмещенный (в системе TN-C - PEN - проводник) нулевой защитный и нулевой рабочий проводник - проводник в электроустановках напряжением до 1 КВ, совмещающий функции нулевого защитного и нулевого рабочего проводника. Исходя из вышеописанного зануление обеспечивает защиту от поражения током при замыкании на корпус поскольку ограниченивается время прохождения тока через тело человека и снижается напряжение прикосновения. В качестве токовой защиты, обеспечивающей быстрое отключение установки в случае аварии используются плавкие предохранители и автоматические выключатели, которые устанавливаются для защиты от токов короткого замыкания, магнитные пускатели со встроенной тепловой защитой, контакторы в сочетании с тепловыми реле, осуществляющие защиту от перегрузки, автоматы с комбинированными расцепителями, осуществляющие защиту одновременно от токов короткого замыкания и перегрузки и др.
Введение
Современные объекты управления требуют безотказной работы от управляющей системы. Будь то медицинские системы, контролирующие жизненные показатели пациента, системы управления опасным производством, биллинговые системы, системы бронирования билетов, системы для электронной коммерции, автомобильная электроника везде требуется высокая надежность и безотказность обслуживающей системы.
Если какой-то компонент системы выходит из строя, вся система должна продолжать работать и заменить вышедший из строя компонент так, чтобы это было незаметно для пользователя. Или, по крайней мере, система должна иметь предсказуемое время реакции.
Одним из наиболее эффективных способов построения безотказных, надежных систем являются кластеры. Кластер объединяет в себе несколько компьютеров и предоставляет их как единую, целостную систему.
Существующие готовые кластерные решения зачастую имеют очень высокую цену и, далеко не каждое учреждение может себе позволить такую систему.
Возникает задача построения относительно дешевого варианта кластерной системы, которая легко масштабируется, не имеет единой точки отказа и обеспечивает предсказуемое время реакции на сбой.
Актуальность темы.
Современные программные и аппаратные средства становятся все более сложными, в связи с этим растет риск поломки или отказа одного из компонентов системы или всей системы целиком. В современном мире зачастую просто неприемлемо тратить время на поиск и устранение неисправности. Это должно происходить автоматически и с минимальными последствиями для пользователя.
Неважно сервис ли это, обслуживающий миллионы людей или система управления автомобильной электроникой время реакции и устранения неисправности должно быть минимальным.
Идеальная система высокой доступности простаивает примерно 5 минут за год. То есть система работает и доступна 99,999% времени.
Многие современные системы высокой доступности предоставляют аппаратные решения, такие как: - избыточные компоненты или системы
- компоненты, поддерживающие горячую замену
- кластеры
Но частой причиной отказа системы являются отказы программного обеспечения, поэтому идеальной была бы система, единый компонент которой сам по себе являлся бы системой высокой доступности. надежность данные хранение доступность
Анализ предметной области
Для начала разберемся зачем нужны кластеры и что это вообще такое.
Разберем основные термины.
Имеется четыре категории ошибок в компьютерной системе: программные ошибки, аппаратные ошибки, ошибки состояния и временные ошибки.
Программные ошибки - ошибки проектирования или реализации ПО. Деление на ноль, попытка доступа к элементу массива по индексу, который слишком большой или слишком маленький, или некорректная реализация математического уравнения - примеры программных ошибок.
Аппаратные ошибки вызываются отказами лежащей в основе аппаратуры. Примерами являются остановки процессора в мультипроцессорной системе и неспособность сенсора посылать данные.
Ошибки состояния являются результатом различия между системным восприятием внешней среды и действительной средой.
Временные ошибки происходят, когда операции не удовлетворяют временным ограничениям.
Имеется несколько способов для улучшения или поддержки нормальной производительности в среде, в которой происходит неисправность.
Предотвращение неисправности представляет собой способ, используемый при попытке предотвратить возникновение неисправностей.
Маскирование неисправности представляет собой метод, который предотвращает ситуацию, когда неисправность вводит ошибки в систему.
Обнаружение неисправности представляет собой способность обнаруживать неисправности в системе. Могут быть обнаружены только последствия неисправности или ошибки. Причина, по которой происходит неисправность, должна быть выведена из результата.
Отказоустойчивость представляет собой способность системы продолжать выполнять свою задачу после возникновения неисправностей. Она может быть достигнута с использованием многих способов. Маскирование неисправностей - один подход, другой - обнаружение и обработка ошибки, чтобы либо сохранить, либо восстановить функционирование системы.
При введении термина «отказоустойчивость» предполагается, что система устойчива к отказам своих компонент, рассматриваемых в этом смысле как «неделимые блоки».
Структура унифицированного отказоустойчивого вычислителя определяется его назначением и должна обеспечивать сохранение работоспособности в условиях одиночных сбоев и отказов.
Функционирование аппаратуры в условиях обратимых дефектов требует таких решений, которые в течение активного рабочего цикла выполняемой задачи либо обеспечивают парирование сбоев, либо их маскирование и восстановление процесса управления. Полное тестирование и реконфигурация аппаратной части может происходить только в течение пассивного цикла выполняемой задачи. Повышение надежности основано на принципе предотвращения неисправностей путем снижения интенсивности отказов и сбоев за счет применения электронных схем и компонентов с высокой и сверхвысокой степенью интеграции, снижения уровня помех, облегченных режимов работы схем, обеспечения тепловых режимов их работы, а также за счет совершенствования методов сборки аппаратуры. Единицей измерения надежности является среднее время наработки на отказ (MTBF - Mean Time Between Failure).
Принципы, лежащие в основе методов достижения отказоустойчивости, и оказывающие решающее влияние на его конфигурацию: 1) Избыточность ресурса (аппаратного, временного, программного);
2) Наличие дополнительных аппаратных и программных средств, управляющих восстановлением вычислительного процесса после отказов;
3) Достоверность выходных сигналов каждого неделимого блока;
4) Удаление из рабочей конфигурации только неисправных неделимых блоков;
5) Функциональная и системная однородность групп неделимых блоков;
6) Само - контролируемость узлов, вырабатывающих специфические сигналы, не удовлетворяющие свойству однородности (например, схем контроля);
7) Однородность архитектуры управления функционированием и управления отказоустойчивостью.
Лучшими среди отказоустойчивых систем являются системы, обеспечивающие непрерывную готовность. Разработка подобной системы охватывает как аппаратные средства, так и программное обеспечение. Очень важным дополнительным требованием к таким системам является сохранение уровня производительности в случае отказа какого-либо компонента. Время восстановления после отказа не превышает одной секунды.
Реализация вычислений в режиме непрерывной готовности затрагивает практически все аспекты разработки системы - в ней не должно быть ни одного функционального узла, отказ которого может вывести из строя систему в целом.
Во множестве систем высокой готовности используется ПО обработки аппаратных и программных отказов, быстро переключающее работу с одного компьютера на резервный в рамках той же системы. Имеется возможность спроектировать систему, не просто защищенную от сбоев, а гарантирующую полную передачу рабочих функций.
Для обеспечения отказоустойчивости при разработке ПО необходимо реализовать: - модульность;
- резервирование;
- контроль;
- реконфигурацию;
- восстановление.
Для обеспечения отказоустойчивости используются два подхода - кластерный и мажоритарный. В первом случае на каждом из узлов отказоустойчивого вычислителя выполняются разные приложения, но при отказе одного из узлов приложения этого узла мигрируют на работоспособный узел. Во втором случае все три узла работают синхронно на одних и тех же данных, проводят взаимное сравнение своих результатов и отключают неисправный процессор. Если процессоры не само - тестируемые, то минимальная конфигурация должна содержать 3 процессора, и с ростом их числа отказоустойчивость повышается.
Кластер - это разновидность параллельной или распределенной системы, которая: - состоит из нескольких связанных между собой компьютеров;
- используется как единый, унифицированный компьютерный ресурс.
Кластер функционирует как единая система, то есть для пользователя или прикладной задачи вся совокупность вычислительной техники выглядит как один компьютер. Именно это и является самым важным при построении кластерной системы.
Основное назначение кластера состоит в обеспечении: 1) высокого уровня доступности (High Availability), иначе называемого уровнем готовности;
2) высокой степени масштабируемости;
3) удобства администрирования по сравнению с разрозненным набором компьютеров или серверов.
Иными словами, кластеры позволяют значительно повысить отказоустойчивость сетевых служб и увеличить их производительность с сохранением простоты администрирования и использования.
К общим требованиям, предъявляемым к кластерным системам, относятся: - Высокая готовность
-Высокое быстродействие
-Масштабирование
-Общий доступ к ресурсам
-Удобство обслуживания
Программное обеспечение унифицированного отказоустойчивого вычислителя реализует кластерную систему высокой готовности (high availability), поэтому первое требование ставится во главу угла.
Сегодня в мире распространены несколько типов систем высокой готовности. Среди них кластерная система является воплощением технологий, которые обеспечивают высокий уровень отказоустойчивости при самой низкой стоимости. Отказоустойчивость кластера обеспечивается дублированием всех жизненно важных компонент. Максимально отказоустойчивая система должна не иметь ни единой точки, то есть активного элемента, отказ которого может привести к потере функциональности системы. Такую характеристику как правило называют - NSPF (No Single Point of Failure, - англ., отсутствие единой точки отказа).
При построении систем высокой готовности, главная цель - обеспечить минимальное время простоя.
Для того чтобы система обладала высокими показателями готовности, необходимо: 1) чтобы ее компоненты были максимально надежными;
2) чтобы она была отказоустойчивая, желательно, чтобы не имела точек отказов;
3) а также важно, чтобы она была удобна в обслуживании и разрешала проводить замену компонент без останова.
Пренебрежение любым из указанных параметров, может привести к потере функциональности системы.
Что касается обеспечения максимальной надежности, то она осуществляется путем использования электронных компонент высокой и сверхвысокой интеграции, поддержания нормальных режимов работы, в том числе тепловых.
Отказоустойчивость обеспечивается путем использования специализированных компонент (ECC, Chip Kill модули памяти, отказоустойчивые блоки питания, и т.п.), а также с помощью технологий кластеризации. Благодаря кластеризации достигается такая схема функционирования, когда при отказе одного из компьютеров задачи перераспределяются между другими узлами кластера, которые функционируют исправно.
Кластерная архитектура рассчитана на следующую конфигурацию: 1) все узлы кластера имеют независимую оперативную память;
2) в части доступности устройств ввода-вывода и, прежде всего дисков, возможны следующие конфигурации: а) кластер с разделяемыми дисками (shared disk) подразумевает, что любой узел имеет прозрачный доступ к любой файловой системе общего дискового пространства. Помимо разделяемой дисковой подсистемы на узлах кластера могут иметься локальные диски, но в этом случае они используются, главным образом, для загрузки ОС на узле. Такой кластер должен иметь специальную подсистему, называемую «распределенный менеджер блокировок» (Distributed Lock Manager, DLM), для устранения конфликтов при одновременной записи в файлы с разных узлов кластера;
б) Кластер без разделения ресурсов (shared nothing), как и следует из названия, не имеет общих устройств ввода/вывода . Правда, здесь есть одна тонкость: речь идет об отсутствии общих дисков на логическом, а не на физическом уровне. Это означает, что на самом деле дисковая подсистема может быть подключена сразу ко всем узлам. Если на дисковой подсистеме имеется несколько файловых систем (или логических/физических дисков), то в любой конкретный момент времени доступ к определенной файловой системе предоставляется только одному узлу. К другой файловой системе доступ может иметь (т. е. владеть ресурсом) совсем другой узел. Такая схема применяется для того, чтобы в случае отказа одного узла ресурс мог быть передан другому узлу. с) в соответствии с еще одной схемой локальные диски узлов кластера зеркалируются (дублируются). Очевидно, что такой подход годится только для задач, решение которых не возлагает значительной нагрузки на дисковые подсистемы.
Как уже было сказано выше, основными характеристиками кластера являются высокий уровень готовности, масштабируемость и представление кластера как единого целого с точки зрения внешней среды.
Уровень готовности характеризует готовность системы к функционированию в течение длительного времени без остановки и измеряется в процентном отношении времени нахождения системы в работоспособном состоянии к общему времени. Иногда он характеризуется временем простоя системы за год.
Высоким уровнем готовности считается обычно уровень 99, 9 % и выше, хотя такая градация носит достаточно условный характер. С уровнем готовности связано понятие отказоустойчивости. Обычно под отказоустойчивой понимают систему с уровнем готовности 99, 999 % и выше. Используемый иногда термин «истинная отказоустойчивость» подразумевает практически безостановочную работу системы (99, 9999 % и выше).
Важно понимать, что заявляемый производителями уровень готовности относится лишь к аппаратной части кластера и операционной системе и обычно не учитывает надежность ПО, особенно сторонних разработчиков. Более того, чтобы обеспечить высокий уровень производительности, каналы подключения к дисковым массивам, сетевой среде и между узлами должны быть отказоустойчивыми и дублированными. Вдобавок дублировать следует также сами дисковые массивы, маршрутизаторы и коммутаторы сети, источники бесперебойного питания и т. д. Особенно важное значение имеет использование в качестве дисковых подсистем массивов RAID, причем для повышения отказоустойчивости и производительности специалисты советуют применять RAID - 10. Разумеется, чем больше компьютеров в кластере, тем теоретически выше уровень доступности.
Обращаясь к теме масштабирования кластеров, следует отметить, что грамотное размещение на узлах кластера даже обычных (не кластерных) приложений позволяет не только существенно повысить запас прочности, но и увеличить общую производительность по сравнению с одним сервером.
Количество узлов в кластере зависит от конкретной реализации, оно колеблется от двух до нескольких десятков, и, как уже было сказано, каждый узел может быть многопроцессорным. Добавление нового узла в кластер обычно проходит безболезненно и не требует перегрузки других узлов. Таким образом, при нехватке вычислительных ресурсов кластер можно на ходу увеличить «в размерах».
Весьма важной особенностью кластера является так называемый единый образ системы (Single System Image, SSI), благодаря которому пользователи могут видеть серверы в кластере как единое целое. Для пользователя кластер - это большой сервер, на котором работает множество приложений, хотя в действительности они функционируют на различных узлах.
Единый образ системы исключительно важен и для администратора, так как позволяет управлять кластером как одной системой. Разумеется, с помощью соответствующих утилит администратор может управлять и отдельными узлами.
Особый интерес представляет доступ клиентов к кластеру в момент отказа узла.
Кластеру назначается один или несколько общих виртуальных IP - адресов. Эти виртуальные IP - адреса используются для доступа к кластеру как единому целому. Кроме того, каждому узлу назначается свой индивидуальный IP - адрес.
Помимо общих виртуальных IP - адресов каждому сетевому ресурсу кластера (это может быть система для файлового сервиса или приложение с соответствующим ему дисковым пространством) назначается свой виртуальный IP - адрес. В нормально работающем кластере такие виртуальные IP - адреса принадлежат узлам, на которых выполняется приложение или сетевая служба, т. е. при обращении к виртуальному IP - адресу откликается определенный узел. При отказе того или иного узла кластерные ресурсы вместе с соответствующими виртуальными IP - адресами переходят к другим узлам.
Что же происходит при отказе узла или отдельной сетевой службы, с точки зрения клиента? Все зависит от того, какими протоколами и приложениями пользуется клиент в данный момент. Если они относятся к категории сервисов, не отслеживающих состояние соединения, то клиент попросту не заметит ничего, вернее, он может столкнуться с некоторой задержкой в выполнении запросов, вследствие того, что на миграцию служб требуется определенное время.
Если же сервисы отслеживают состояние соединения, то их работа зависит от конкретной реализации. В общем случае от клиента может потребоваться заново установить соединение. Однако в ряде случаев повторного открытия соединений может и не потребоваться, поскольку клиентское ПО само автоматически переустановит соединение.
Программное обеспечение унифицированного отказоустойчивого вычислителя в сочетании с предлагаемыми аппаратными средствами должно обеспечить надежность 99,999% , в этом случае приложение должно иметь непроизводительные потери времени не более чем 5,25 минуты в год, независимо от количества программных сбоев, отключений электропитания, отказов оборудования, ошибок оператора и других неожиданных неприятностей. Даже если приложение останавливается только на один час в год (например, для модернизации), это значит, что степень его готовности составляет всего "четыре девятки" - 99,99%.
Судя по этим цифрам, очевидно, что высокая готовность является системной проблемой. Таким образом, для получения системы высокой готовности все ее компоненты, включая операционную систему, аппаратную платформу и код приложений, должны разрабатываться с учетом требований высокой готовности. Например, это относится к следующим вопросам. Как операционная система обрабатывает ошибки драйвера (которые часто приводят к полному отказу системы)? Может ли ОС немедленно перезапустить драйвер без сброса системы? Или в этом случае вся система должна быть перезагружена?
Исследования показывают, что вопросы, связанные с программным обеспечением, включая программные ошибки и необходимость обновления, являются причиной большинства простоев в предоставлении сервиса. Поэтому достижение высокой готовности должно начинаться с базового программного обеспечения, на котором строятся все приложения высокой готовности - с операционной системы.
Обзор альтернатив
Рассмотрим существующие программные решения для построения кластерных систем.
Linux-HA Project / Pacemaker Project
Linux-HA - проект, предоставляющий возможности построения кластеров высокой доступности на основе операционных систем Linux, FREEBSD, OPENBSD, Solarisи MACOSX. Основой проекта является демон Heartbeat.
Heartbeat - демон управляющий кластером. Из его основных функций можно отметить следующие: - Heartbeat отслеживает состояние ресурсов, при возникновении неполадки демон может перезапустить отказавший процесс или переместить его на другой узел кластера
- удаление отказавших узлов из кластера
- графический интерфейс для конфигурации и мониторинга ресурсов и узлов кластера
Сам по себе демон Heartbeat управляет инфраструктурой кластера, взаимодействием узлов между собой, включением узлов в кластер и удалением их из него. Менеджер ресурсов кластера в Heartbeat имеет ограниченный функционал и может следить одновременно лишь за двумя узлами кластера. Для построения более функционального и надежного кластера существует отдельный менеджер ресурсов кластера - Pacemaker.
Pacemaker существенно расширяет функционал Heartbeat. Основные функции Pacemaker: - Обнаружение и восстановление неисправностей на уровне сервисов и узлов кластера
- Не зависит от подсистемы хранения данных, не требуется общий диск
- Ресурсом кластера может быть все, что можно заскриптовать
- Поддержка STONITH (Shoot-The-Other-Node-In-The-Head) - средство для вывода "умершего" узла из кластера. Решает, в том числе такую проблему как Split-Brain - ситуация, когда связь между узлами теряется, но оба они живы, каждый из них думает, что другой умер и пытается забрать все ресурсы себе, это может привести к повреждению данных, поэтому своевременный вывод одного из узлов из кластера решит эту проблему.
- Поддержка любого количества узлов в кластере
- Поддержка ресурсозависимых и кворумных кластеров
Pacemakerподдерживает практически любую избыточную конфигурацию: Активный/Пассивный, Активный/Активный, N 1, N M, N-to-1, N-to-N.
В этом случае Pacemaker использует DRDB для хранения данных.
В некоторых типах кластера необходим доступ к одним и тем же данным с разных машин, но организовывать распределенное общее хранилище зачастую очень дорого. В таком случае в качестве альтернативы используют DRDB. DRDB представляет из себя программный RAID-1, то есть зеркалирует файлы между машинами.
DRBD работает с блочными устройствами, используемыми в качестве строительных блоков для формирования кластеров высокой надежности. Он зеркалирует все блочное устройство, используя сетевой интерфейс. DRBD зеркалирует каждый блок данных, который записывается на диск, в равноправный узел.
Стрелки с точками показывают поток данных, который реализуется, когда DRBD зеркалирует данные сервиса высокой доступности (high availably service) от активного узла кластера к резервному узлу кластера.
Shared Failover конфигурация - несколько кластеров типа Активный/Пассивный объединяются в один
Конфигурация Активный/Активный
Здесь используется общее хранилище, и каждый узел кластера может замещать другой. Нагрузка распределяется равномерно между всеми машинами в кластере. В случае отказа одной из машин нагрузка перерспределяется между остальными узлами.
Архитектурно кластерный софт можно разделить на три части: - Управление взаимодействием узлов в кластере и добавление/удаление узлов (на схеме изображено красным)
- Компоненты, относящиеся к определенному узлу в кластере (на схеме зеленые). Это такие компоненты как управление и мониторинг за локальными ресурсами.
- Основной компонент - менеджер ресурсов кластера (изображен синим). Этот компонент реагирует на события кластера (присоединение или удаление узла) и события ресурсов кластера и обрабатывает их. Также компонент реагирует на изменение конфигурации кластера со стороны администратора.
Изза ограниченной функциональности демон Heartbeat постепенно замещается связкой Pacemaker COROSYNC.
COROSYNC - проект, который вырос из OPENAIS. OPENAIS - открытая реализация проекта AIS (Application Interface Specification).
AIS - это набор спецификаций, которые описывают интерфейс программирования приложений для реализации приложений высокой доступности. Основной целью проекта AIS является упрощение написания приложений высокой доступности и обеспечение переносимости этих приложений.
COROSYNC предоставляет следующий функционал: - Процессы объединяются в группы процессов для виртуальной синхронизации, это обеспечивает репликацию состояния разных машин.
- Простой менеджер высокой доступности, который перезапускает процессы в случае сбоя.
- Базу данных конфигураций и статистики по узлам кластера и кластеру в целом
- Кворумную систему, уведомляющую приложения, когда кворум достигнут.
Реализация Pacemaker совместно с COROSYNC имеет следующий вид:
Сам Pacemaker состоит из четырех основных частей, к которым можно подключать дополнительные модули (в том числе из LINUXHAPROJECT)
- CIB (Cluster Information Base)
- CRMD (Cluster Resource Manager daemon)
- PENGINE (Policy Engine)
- STONITHD
CIB - использует XMLДЛЯ описания конфигурации кластера и состояния всех его ресурсов. Содержимое CIB реплицируется между всеми компонентами кластера и используется PENGINE для вычисления идеального состояния кластера и путей достижения этого состояния.
Один из демонов CRMD выбирается мастером и, если мастер выйдет из строя другой демон станет мастером.
Инструкции из PENGINE направляются в LRMD (демон локального менеджера ресурсов). В свою очередь локальный демон отвечает о результате выполнения операций. На основе этого ответа PENGINEПЕРЕСЧИТЫВАЕТ идеальное состояние кластера и перестраивает инструкции на основе результатов этого вычисления.
Keepalived (LVS)
Проект для инфраструктур, основанных на Linux. Основная цель обеспечить балансировку нагрузки между узлами кластера и обеспечить высокую доступность. В основном используется для обеспечения безотказной работы сетевых сервисов.
Балансировка нагрузки основана на LVS (LINUXVIRTUALSERVER)
LVS - кластер состоит из одного или двух узлов маршрутизатора и переменного числа серверов. Реальные сервера объединяются частной сетью. LVS маршрутизаторы подсоединяются к этой частной сети, а также к общедоступной сети.
Адаптеры, присоединяющие LVS маршрутизаторы к частной и общедоступной сетям,могут быть любыми устройствами, однако должны быть теми же самыми на каждом маршрутизаторе.
В каждый момент времени активен только один LVS маршрутизатор. Роль активного маршрутизатора состоит в перенаправлении запросов на обслуживание с адресов виртуальных серверов на реальные серверы.
Перенаправление основывается на одном из четырех поддерживаемых алгоритмов балансировки нагрузки: - ROUNDROBIN - распределяет работу равномерно между всеми реальными серверами
- Least - connections - распределяет больше работ реальным серверам с меньшим количеством активных связей (таблица IPVS хранит активные связи)
- Weighted round robin - распределяет больше работ серверам со значительно большей емкостью. Емкость определяется присвоенным пользователем весом, который уменьшается или увеличивается в соответствии с динамической информацией о нагрузке
- Weighted least connections - распределяет больше работ реальным серверам с меньшим количеством активных связей относительно их емкости. Емкость определяется присвоенным пользователем весом, который уменьшается или увеличивается в соответствии с динамической информацией о нагрузке
Активный маршрутизатор динамически отслеживает состояние реальных серверов и выполняемую каждым работу одним из трех способов. Если работа с конкретным реальным сервером запрещается, активный маршрутизатор прекращает посылку работ на сервер до того, как он вернется к нормальному состоянию.
Периодически LVS маршрутизаторы обмениваются сообщениями, подтверждающими их исправность "Я жив", посредством имеющегося между ними общедоступного соединения. Если резервный узел не получает сообщение, подтверждающее исправность, в течение ранее установленного временного интервала, он инициирует операцию по сбойной ситуации для того, чтобы взять на себя роль активного маршрутизатора. В процессе выполнения операции по сбойной ситуации резервный маршрутизатор присваивает себе плавающие IP - адреса неисправного маршрутизатора (как это описано в файле конфигурации кластера) и, используя метод, называемый ARP "подслушиванием", запускает действия по своему объявлению пунктом назначения для IP - пакетов, адресованных на неисправный узел. Когда неисправный узел становится готовым к обслуживанию запросов, он начинает функционировать в режиме горячего резерва.
В каждый момент времени LVS - кластер поддерживает только один метод маршрутизации. Трансляция сетевых адресов (NAT), предполагается добавить туннелирование и прямую маршрутизацию.
Запросы клиента к сервису прибывают на IP адрес виртуального сервера. Это публично известный адрес, которому администратор сайта установил соответствие с полностью определенным доменным именем. Уникальный виртуальный адрес сервера есть сочетание трех величин протокол (TCP или UDP), IP адрес и номер порта.
Компонентами LVS кластера являются: pulse
Это управляющий процесс, который запускает все другие требуемые демоны. Он запускается на LVS маршрутизаторе командным файлом /etc/rc.d/init.d/pulse, как правило, во время начальной загрузки. Посредством pulse, которая реализована как простая программа определения исправности, неактивный LVS маршрутизатор определяет, исправен ли активный маршрутизатор и в какой момент времени требуется инициировать процедуру обработки сбойной ситуации.
Lvs
Демон lvs выполняется на LVS маршрутизаторе. Он считывает файл конфигурации и вызывает ipvsadm для обеспечения работы с таблицей маршрутизации IPVS.
Nanny
Демон слежения nanny выполняется на активном LVS маршрутизаторе. С помощью этого демона активный маршрутизатор определяет состояние каждого из реального сервера и получает информацию об их загруженности. На каждом реальном сервере выполняется отдельный процесс, используемый каждым виртуальным сервером.
/etc/lvs.cf
Это файл конфигурации LVS кластера. Непосредственно или нет все демоны получают информацию о конфигурации из этого файла.
Piranha
Средство для отслеживания, конфигурирования и администрирования LVS кластера.
Ipsvadm
Это средство вносит изменения в таблицу маршрутизации IPVS в ядре. Демон lvs настраивает и администрирует LVS кластер посредством вызова ipsvadm для добавления, замены или удаления строк в таблице маршрутизации IPVS.
Высокая доступность достигается засчет протокола VRRP.
Протокол VRRP объединяет несколько маршрутизаторов в один виртуальный и назначает им один общий IP адрес.
Общая архитектура Keepalived:
Keepalived представляет из себя три процесса. Родительский процесс мониторинга и два процесса - потомка: VRRP и healthcheck. VRRP отвечает за обеспечение высокой доступности, healthcheck проверяет состояние служб кластера.
Keepalived конфигурируется с помощью файла keepalived.conf, затем конфигурация парсится и применяется.
Keepalived предоставляет некоторые функции управления памятью, такие как выделение памяти, перераспределение и освобождение памяти. Демон может работать в нормально режиме и в отладочном режиме. В отладочном режиме демон может отслеживать утечки памяти и следить за общим распределением памяти.
WATCHDOG - компонент отслеживающий состояние дочерних ПРОЦЕССОВVRRPИ healthcheck.
Netlinkreflector - собственное представление сетевого интерфейса в keepalived. Мониторинг осуществляется через Netlinkканал ядра.
Checkers - одинизглавныхкомпонентовkeepalived. Тут проверяется «жив» ли сервер, тут же на основе полученной информации решается вопрос о присоединении/отсоединении сервера от кластера.
WINDOWSFAILOVERCLUSTERING
Рассмотрим также возможности построения кластерных систем, которые предоставляет Windows.
WSFC - Windows Server Failover Clustering предоставляет инфраструктуру для поддержки высокой доступности серверных приложений (например SQLSERVER).Если узел кластера выходит из строя, сервис может быть автоматически или вручную перенесен на другой доступный узел кластера.
WSFCПРЕДОСТАВЛЯЕТ следующий функционал: - Распределенная конфигурация и уведомления. Сам WSFC сервис и метаданные, связанные с критичным приложением, хранятся на каждом узле кластера. Эти метаданные содержат настройки WSFCИ статус приложения, а также дополнительные настройки критичного приложения. Изменения в статусе или в метаданных автоматически распространяются на все узлы кластера.
- Управление ресурсами. Каждый узел кластера может содержать свои собственные физические ресурсы (диски, сетевые интерфейсы и т.д.). Можно настроить зависимость приложений от этих ресурсов.
- Мониторинг «здоровья» кластера. Мониторинг осуществляется с помощью сетевых коммуникаций и мониторинга отдельных ресурсов на каждом узле кластера. Общее «здоровье» кластера определяется кворумом.
- Failover - каждый дополнительный узел может стать основным и наоборот. Базируясь на состоянии кластера, владение ресурсами и их обработкой может быть перемещено с одного узла на другой.
Windows также предоставляет API как для Failover кластеров высокой доступности, так и для балансировки нагрузки.
Вот так выглядят компоненты Failover кластера для Windows систем:
Эти компоненты включают в себя: - Сервис кластера (Cluster service) - контролирует кластерную активность на отдельном узле системы
- Cluster Disk Driver - обеспечивает эксклюзивный доступ к кластерным дисковым ресурсам, во избежание повреждения данных
- Resource Monitors-сервисы для общения между ресурсами кластера и сервисом кластера (Cluster service). Через этот компонент сервис кластера может отслеживать состояние ресурсов отдельных узлов и всего кластера.
- Resource DLLS - обрабатывают практически все операции над ресурсами кластера.
- Cluster Database - хранит информацию о конфигурации кластера
- Административный интерфейс предоставляет возможность администрирования кластера.
Рассмотрим существующие аппаратные решения для обеспечения высокой доступности.
Аппаратные решения для обеспечения высокой доступности
Зеркалирование дисков или RAID 1
Полное копирование данных на двух и более дисках. В случае выхода из строя одного из дисков работоспособность системы не изменится. RAID 1 надежен, т.к. работает, если функционирует хотя бы один диск в массиве. Сразу несколько дисков могут выйти из строя с гораздо меньшей вероятностью, чем один, так как вероятность отказа нескольких дисков равна произведению вероятностей отказа каждого из них.
Еще и плюсов стоит отметить, что зеркалирование иногда позволяет ускорить процесс чтения информации с дисков. Каждый диск может быть доступен отдельно и запросы на чтение можно направлять на различные диски. Это особенно ощутимо когда несколько процессов одновременно хотя считать данные с диска. Направив разные процессы на разные диски получается выигрыш в производительности.
У этого способа есть и минусы. При наличии двух дисков мы получаем фактический полезный объем лишь одного.
Рекомендуется создавать RAID массивы типа 10, в этом случае несколько массивов типа 0 (поочередная запись) объединяются в массив типа 1, то есть зеркалируются.
Избыточные сетевые соединения, несколько сетевых интерфейсов на одной машине. Объединение маршрутизаторов в один виртуальный. Рассмотренный выше протокол VRRP пример реализации сетевой избыточности.
Использование сетей хранения данных (SAN)
SAN - сеть, которая предоставляет сетевые блочные устройства. SAN позволяет воспринимать удаленное устройство хранения как локально подключенное. Сетевые блочные устройства представляют собой устройства хранения соединенные с помощью определенных протоколов и интерфейсов (ISCSI, FIBRECHANNEL, AOE).
Достаточно долгое время на рынке SAN доминировал протокол FIBRECHANNEL. FIBRECHANNEL - транспортный протокол передачи SCSI команд через сети FIBRECHANNEL. У FIBRECHANNEL практически не было альтернатив, однако недостатки у протокола существовали. Основные недостатки - это цена и проблемы с доступом к географически распределенным устройствам.
В последние годы FIBRECHANNEL используется в основном в высокопроизводительных системах. В более бюджетном сегменте его замещает протокол ISCSI.
Протокол ISCSIОПИСЫВАЕТ механизм инкапсуляции SCSIКОМАНД в ІРПАКЕТЫ и передаче их поверх TCP. Благодаря такой реализации возможен удаленный доступ к любому хранилищу через интернет. Для этого не нужно дополнительно инфраструктуры, SAN на основе ISCSI может быть построен на любой физической основе, поддерживающей IP, например Ethernet, GIGABITETHERNET и 10G Ethernet. Однако и тут существуют проблемы, SCSI как интерфейс канального уровня предполагает последовательную и надежную передачу пакетов. В ІРЖЕ пакеты передаются без соблюдения строгой последовательности. Это может привести к потере данных, особенно в глобальных сетях, где вероятность потерь ip пакетов больше чем где бы то ни было. В связи с этим протокол предусматривает обработку ошибок. SCSI команды буферизируются до момента их подтверждения. Если что-то пошло не так и повредился пакет или разорвалась ТСРСЕССИЯ, предпринимается попытка восстановления сессии и повторения передачи поврежденных пакетов.
ISCSI работает на основе клиент - серверной архитектуры. Клиент, который представляет из себя сервер, рабочую машину или, как в нашем случае кластер (то есть набор серверов) инициирует запросы на чтение данных. Сервер - система хранения данных обрабатывает запросы и отвечает на них.
Сессия ISCSI состоит из двух этапов - аутентификации и обмена. Аутентификация позволяет осуществлять контроль доступ
Вы можете ЗАГРУЗИТЬ и ПОВЫСИТЬ уникальность своей работы