Linux cluster какие бывают

Обновлено: 01.07.2024

Из-за требований современного онлайн-бизнеса один сервер больше не может соответствовать потребностям бизнеса, и бизнес-сервер должен передавать больше запросов доступа. Либо отказ одного сервера (SPOF, единственная точка отказа) приведет к тому, что все службы быть недоступным. В этом случае необходимо объединить все одни и те же бизнес-серверы для предоставления услуг для одного и того же бизнеса. Для достижения высокого уровня параллелизма и быстрого реагирования. Кластерная технология и операционная система Linux обеспечивают высокую производительность и доступность сервера с очень хорошая масштабируемость, хорошая надежность и хорошая управляемость.

Тип кластера

LB: балансировка нагрузки

Компоненты:

Балансировщик нагрузки

планировщик
Распределитель

"Реальный сервер" бэкэнда

HA: высокая доступность

Активный сервер (активный)
Резервный сервер (пассивный)

HP: высокопроизводительный вычислительный кластер (высокая производительность)

Подключите несколько ЦП через шину для совместного выполнения вычислений и повышения эффективности вычислений

DS: Распределенная система

Распределенная система хранения является наиболее распространенной, например hadoop

Вопросы, которые необходимо учитывать при построении балансировки нагрузки

Сохранение сеанса , Следующие сценарии применения

1 Session sticky : Отслеживайте запросы пользователей через балансировщик нагрузки и всегда отправляйте сеансы с одним и тем же IP-адресом на один и тот же реальный сервер.

Недостатки: если вы обращались к реальному файлу сервера, это заставит некоторых пользователей проверить, сколько обычного доступа

Недостатки: в случае большого сеанса сервер будет синхронизировать большое количество сеансов, что приведет к потере большого количества ресурсов и подходит только для относительно небольшого сеанса.

Недостатки: служба сеанса сетевого хранилища будет иметь узкое место в сети или файловую машину хранилища сеанса.

Файловое хранилище : Использовать распределенную систему хранения

Общее хранилище

NAS: сетевое хранилище (сервер хранения файлов)
SAN: Storage Area Network (хранилище на уровне блоков)
DS: Distributed Storage (распределенное хранилище файлового уровня)

Rsync

Внедрение кластерного подразделения LB

аппаратное обеспечение:

F5 : BIG-IP
Citrx : Netscaler
A10 : A10
Array
Redward

программного обеспечения

LVS(linux virtual server)
HAPorxy
Nginx
Ats(apache traffice server)
Perlbal

Разделение уровня протокола LB-кластера

Транспортный уровень:

LVS
HAPorxy (аналоговый транспортный уровень, режим TCP)

Уровень приложения

Внедрение HA-кластера

Программный способ реализации

KeepAlived: Реализуйте дрейф адресов за счет реализации протокола vrrp

AIS

hearbeat
cman + rgmanager (реализация Red Hat, RHCS)
corosync + pacemaker

Идеи построения бизнес-системы

Стратификация

Уровень доступа
Слой кеширования
Бизнес-уровень
Уровень данных

распределен

заявление
данные
место хранения
Расчет

Введение в LVS

Как работает LVS

Терминология LVS-кластера

VS: виртуальный сервер, называемый Директором
RS: реальный сервер, сервер, который предоставляет реальные услуги на бэкэнде
CIP: IP-адрес клиента
DIP: IP-адрес директора, внутренний IP-адрес LVS
VIP: IP-директор, интерфейсный IP-адрес LVS
RIP: IP-адрес сервера, который фактически предоставляет услугу на бэкэнде.

Типы LVS

lvs-nat(MASQUERADE)

Преимущества: физические серверы в кластере могут использовать любую операционную систему, поддерживающую TCP / IP, и только подсистеме балансировки нагрузки требуется юридический IP-адрес.

Недостатки: ограниченная масштабируемость. Когда серверный узел (обычный ПК-сервер) слишком сильно разрастается, балансировщик нагрузки становится узким местом всей системы, поскольку все пакеты запросов и ответные пакеты проходят через балансировщик нагрузки. Когда серверных узлов слишком много, в балансировщике нагрузки объединяется большое количество пакетов данных, и скорость замедляется!

lvs-dr(GATAWAY)

Ответ на трансляцию

Когда есть запрос трансляции VIP, RS будет транслировать все IP-адреса в системе.

Преимущества: Как и TUN (туннельный режим), балансировщик нагрузки только распределяет запросы, а ответный пакет возвращается клиенту через отдельный метод маршрутизации. По сравнению с VS-TUN, VS-DR не требует туннельной структуры, поэтому большинство операционных систем можно использовать в качестве физических серверов.

Недостатки: (нельзя назвать недостатками, можно только сказать, что недостаточно). Сетевая карта балансировщика нагрузки должна находиться в том же физическом сегменте, что и физическая сетевая карта.

lvs-tun(IPIP)

Преимущества: балансировщик нагрузки отвечает только за распространение пакета запроса на сервер внутреннего узла, в то время как RS отправляет ответный пакет непосредственно пользователю. Следовательно, большой поток данных балансировщика нагрузки сокращается. Балансировщик нагрузки больше не является узким местом системы и может обрабатывать огромное количество запросов. Таким образом, один балансировщик нагрузки может распределять нагрузку для многих RS. И его можно распространять в разных регионах, работая в сети общего пользования.

Недостатки: узел RS в туннельном режиме требует легального IP. Этот метод требует, чтобы все серверы поддерживали протокол «IP-туннелирование» (IP-инкапсуляция). Серверы могут быть ограничены только некоторыми системами Linux. Инкапсуляция двух заголовков IP-пакетов вызовет проблемы: размер MTU составляет 1500, а добавление другого заголовка IP-пакета превысит размер MTU, в результате чего маршрутизатор отклонит его (поскольку размер, нарезанный перед передачей, составляет 1500 байт)

lvs-fullnat

Как lvs вычисляет активные и неактивные соединения:

Метод планирования LVS

Статический метод (публикация планируется согласно самому алгоритму, независимо от состояния работы внутреннего сервера, влияние нагрузки ограничено)

rr : круговой алгоритм, круговой алгоритм, опрос, круговой алгоритм

Недостатки: серверы с хорошей производительностью будут простаивать, а серверы с низкой производительностью будут заняты.

wrr : взвешенный rr, взвешенный опрос, тяжелые нагрузки

Недостатки: в некоторых случаях, когда сервер с хорошей производительностью выделяет более длинные соединения, а большинство распределений с низкой производительностью - это короткие соединения, это заставляет сервер с хорошей производительностью обрабатывать множество соединений, и нагрузка возрастает. сервер с низкой производительностью все еще находится в пространстве, что вызывает ложную загрузку

sh : исходный IP-адрес, хэш исходного адреса, всегда может вести один и тот же IP-адрес к одному и тому же серверу RS (поддерживать хеш-таблицу на сервере Director, которая имеет формат KV, ключ - это исходный IP-адрес, а значение - это Адрес RS. Хеш-таблица будет просматриваться каждый раз. Если можно запросить предыдущую запись соединения, она будет отправлена непосредственно на сервер RS. Если нет, алгоритм будет использоваться для планирования)

Недостатки: со временем будет много старых IP-адресов, что окажет сильное давление на фиксированный сервер RS.

dh : IP-адрес назначения, хэш адреса назначения (используется для внутренней загрузки, прямого прокси), запрос клиента, если это тот же адрес назначения, всегда будет отправляться через один и тот же шлюз.

Недостаток: если другой клиент также запрашивает тот же целевой адрес, он также будет использовать тот же шлюз для отправки этого запроса. Если запрос на тот же целевой адрес относительно велик, это вызовет нагрузку на тот же шлюз и повредит эффект нагрузка.

Динамический метод (оценка на основе алгоритма и текущего состояния нагрузки каждого RS. Если нагрузка мала, будет загружен следующий запрос. overhead Значение для назначения запроса)

LC : наименьшее соединение (наименьшее соединение), если количество соединений RS одинаково, будет выполняться циклический перебор, и следующий запрос будет получен, если значение накладных расходов мало

Формула расчета накладных расходов: `активные (количество активных подключений) * 256 + неактивные (количество неактивных подключений)

Недостатки: невозможно распределять запросы в зависимости от производительности сервера.

WLC : взвешенный LC, следующий запрос получит меньшие накладные расходы

Формула расчета накладных расходов: `активные * 256 + неактивные / вес

Недостатки: когда два активных соединения равны 0, будет выполняться циклический перебор. Если циклический перебор происходит с ответом с небольшим весом, это не идеально. Алгоритм SED решает эту проблему.

SED : самая короткая задержка expction, самая короткая ожидаемая задержка, является улучшением алгоритма WLC

Формула расчета накладных расходов: (актив + 1) * 256 / вес

Недостатки: если веса сильно различаются, меньшие веса будут бездействовать.

NQ : Nerver Queue
Это усовершенствование алгоритма SED. Когда поступает запрос пользователя, сервер заранее выделяет в соответствии с запросом пользователя в соответствии с весом, а затем выделяет в соответствии с алгоритмом SED

LBLC : Locality-based LC
Это динамический алгоритм DH. Когда клиент запрашивает целевой адрес, когда нет записи соединения целевого адреса, он выберет шлюз с небольшой нагрузкой для отправки, которая также используется, когда это прямой прокси. Алгоритм

LBLCR : LBLCR с репликацией, LBLC с репликацией
Когда целевой адрес сильно кэшируется кеш-сервером, и пользователь снова запрашивает этот целевой адрес, другой кэш-сервер в это время слишком простаивает, и алгоритм LBLCR пройдет. Скопируйте содержимое напряженного кеш-сервера на бездействующий кеш-сервер

ipvsadm/ipvs

ipvsadm

Инструмент командной строки, который работает в пользовательском пространстве, пространстве пользователя, используется для управления службами кластера и RS в службах кластера, это инструмент CLI.

Программный код, который работает в пространстве ядра и работает с перехватчиком INPUT netfilter. Его кластерная функция зависит от правил определения инструмента Ipvsadm. Хост ipvs должен иметь по крайней мере один RS, и он также может определять несколько кластерных служб одновременно

Поговорим о горизонтальном масштабировании. Допустим, ваш проект вырос до размеров, когда один сервер не справляется с нагрузкой, а возможностей для вертикального роста ресурсов уже нет.

В этом случае дальнейшее развитие инфраструктуры проекта обычно происходит за счет увеличения числа однотипных серверов с распределением нагрузки между ними. Такой подход не только позволяет решить проблему с ресурсами, но и добавляет надежности проекту — при выходе из строя одного или нескольких компонентов его работоспособность в целом не будет нарушена.

Большую роль в этой схеме играет балансировщик — система, которая занимается распределением запросов/трафика. На этапе ее проектирования важно предусмотреть следующие ключевые требования:

Отказоустойчивость. Нужно как минимум два сервера, которые одновременно занимаются задачей распределения запросов/трафика. Без явного разделения ролей на ведущего и резервного.
Масштабирование. Добавление новых серверов в систему должно давать пропорциональную прибавку в ресурсах.

Фактически, это описание кластера, узлами которого являются серверы-балансеры.

В этой статье мы хотим поделиться рецептом подобного кластера, простого и неприхотливого к ресурсам, концепцию которого успешно применяем в собственной инфраструктуре для балансировки запросов к серверам нашей панели управления, внутреннему DNS серверу, кластеру Galera и разнообразными микросервисам.

Договоримся о терминах:

— Серверы, входящие в состав кластера, будем называть узлами или балансерами.
— Конечными серверами будем называть хосты, на которые проксируется трафик через кластер.
— Виртуальным IP будем называть адрес, “плавающий” между всеми узлами, и на который должны указывать имена сервисов в DNS.

Что потребуется:

— Для настройки кластера потребуется как минимум два сервера (или вирт.машины) с двумя сетевыми интерфейсами на каждом.
— Первый интерфейс будет использоваться для связи с внешним миром. Здесь будут настроены реальный и виртуальный IP адреса.
— Второй интерфейс будет использоваться под служебный трафик, для общения узлов друг с другом. Здесь будет настроен адрес из приватной (“серой”) сети 172.16.0.0/24.
Вторые интерфейсы каждого из узлов должны находиться в одном сегменте сети.

Используемые технологии:

LVS, Linux Virtual Server — механизм балансировки на транспортном/сеансовом уровне, встроенный в ядро Linux в виде модуля IPVS. Хорошее описание возможностей LVS можно найти здесь и здесь.
Суть работы сводится к указанию того, что есть определенная пара “IP + порт” и она является виртуальным сервером. Для этой пары назначаются адреса реальных серверов, ответственных за обработку запросов, задается алгоритм балансировки, а также режим перенаправления запросов.

В нашей системе мы будем использовать Nginx как промежуточное звено между LVS и конечными серверами, на которые нужно проксировать трафик. Nginx будет присутствовать на каждом узле.

Для настроек VRRP и взаимодействия с IPVS будем использовать демон Keepalived, написанный в рамках проекта Linux Virtual Server.

КОНЦЕПЦИЯ

Система будет представлять собой связку из двух независимых друг от друга равнозначных узлов-балансеров, объединенных в кластер средствами технологии LVS и протокола VRRP.

Точкой входа для трафика будет являться виртуальный IP адрес, поднятый либо на одном, либо на втором узле.

Поступающие запросы LVS перенаправляет к одному из запущенных экземпляров Nginx — локальному или на соседнем узле. Такой подход позволяет равномерно размазывать запросы между всеми узлами кластера, т.е. более оптимально использовать ресурсы каждого балансера.

Работа Nginx заключается в проксировании запросов на конечные сервера. Начиная с версии 1.9.13 доступны функции проксирования на уровне транспортных протоколов tcp и udp.

Каждый vhost/stream будет настроен принимать запросы как через служебный интерфейс с соседнего балансера так и поступающие на виртуальный IP. Причем даже в том случае, если виртуальный IP адрес физически не поднят на данном балансере (Keepalived назначил серверу роль BACKUP).

Таким образом, схема хождения трафика в зависимости от состояния балансера (MASTER или BACKUP) выглядит так:

запрос приходит на виртуальный IP. IPVS маршрутизирует пакет на локальный сервер;
поскольку локальный Nginx слушает в том числе виртуальный IP, он получает запрос;
согласно настройкам проксирования для данного виртуального IP Nginx отправляет запрос одному из перечисленных апстримов;
полученный ответ отправляется клиенту.

запрос приходит на виртуальный IP. IPVS маршрутизирует пакет на соседний сервер;
на соседнем балансере этот виртуальный IP не поднят. Поэтому dst_ip в пакете нужно заменить на соответствующий серый IP из сети текущего балансера. Для этого используется DNAT;
после этого локальный Nginx получает запрос на серый IP адрес;
согласно настройкам проксирования для данного виртуального IP Nginx отправляет запрос одному из перечисленных апстримов;
полученный ответ отправляется клиенту напрямую с src_ip равным виртуальному IP (при участии conntrack)

РЕАЛИЗАЦИЯ:

В качестве операционной системы будем использовать Debian Jessie с подключенными backports репозиториями.

Установим на каждый узел-балансер пакеты с необходимым для работы кластера ПО и сделаем несколько общесистемных настроек:

На интерфейсе eth1 настроим адреса из серой сети 172.16.0.0/24 :

Виртуальный IP адрес прописывать на интерфейсе eth0 не нужно. Это сделает Keepalived.

В файл /etc/sysctl.d/local.conf добавим следующие директивы:

Первая включает возможность слушать IP, которые не подняты локально (это нужно для работы Nginx). Вторая включает автоматическую защиту от DDoS на уровне балансировщика IPVS (при нехватке памяти под таблицу сессий начнётся автоматическое вычищение некоторых записей). Третья увеличивает размер conntrack таблицы.

В /etc/modules включаем загрузку модуля IPVS при старте системы:

Параметр conn_tab_bits определяет размер таблицы с соединениями. Его значение является степенью двойки. Максимально допустимое значение — 20.

Кстати, если модуль не будет загружен до старта Keepalived, последний начинает сегфолтиться.

Теперь перезагрузим оба узла-балансера. Так мы убедимся, что при старте вся конфигурация корректно поднимется.

Общие настройки выполнены. Дальнейшие действия будем выполнять в контексте двух задач:

Вводные данные:

В качестве виртуального IP адреса будем использовать 192.168.0.100 ;
У веб-серверов будут адреса 192.168.0.101 , 192.168.0.102 и 192.168.0.103 соответственно их порядковым номерам;
У DNS серверов 192.168.0.201 и 192.168.0.202 .

Начнем с конфигурации Nginx.

Добавим описание секции stream в /etc/nginx/nginx.conf :

И создадим соответствующий каталог:

Настройки для веб-серверов добавим в файл /etc/nginx/sites-enabled/web_servers.conf

Настройки для DNS-серверов добавим в файл /etc/nginx/stream-enabled/dns_servers.conf

Далее остается сконфигурировать Keepalived (VRRP + LVS). Это немного сложнее, поскольку нам потребуется написать специальный скрипт, который будет запускаться при переходе узла-балансера между состояниями MASTER/BACKUP.

Все настройки Keepalived должны находиться в одном файле — /etc/keepalived/keepalived.conf . Поэтому все нижеследующие блоки с конфигурациями VRRP и LVS нужно последовательно сохранить в этом файле.

Скрипт, который упоминался выше — /usr/local/bin/nat-switch . Он запускается каждый раз, когда у текущего VRRP инстанса меняется состояние. Его задача заключается в том, чтобы балансер, находящийся в состоянии BACKUP, умел корректно обработать пакеты, адресованные на виртуальный IP. Для решения этой ситуации используются возможности DNAT. А именно, правило вида:

При переходе в состояние MASTER, скрипт удаляет это правило.

Здесь можно найти вариант скрипта nat-switch , написанный для данного примера.

Настройки LVS для группы веб-серверов:

Настройки LVS для группы DNS-серверов:

В завершении перезагрузим конфигурацию Nginx и Keepalived:

ТЕСТИРОВАНИЕ:

Посмотрим как балансировщик распределяет запросы к конечным серверам. Для этого на каждом из веб-серверов создадим index.php с каким-нибудь простым содержимым:

Если в процессе выполнения этого цикла посмотреть на статистику работы LVS (на MASTER узле), то мы можем увидеть следующую картину:

Здесь видно как происходит распределение запросов между узлами кластера: есть два активных соединения, которые обрабатываются в данный момент и 6 уже обработанных соединений.

Статистику по все соединениям, проходящим через LVS, можно посмотреть так:

Здесь, соответственно, видим то же самое: 2 активных и 6 неактивный соединений.

ПОСЛЕСЛОВИЕ:

Предложенная нами конфигурация может послужить отправным пунктом для проектирования частного решения под конкретный проект со своими требованиями и особенностями.

Если у вас возникли вопросы по статье или что-то показалось спорным — пожалуйста, оставляйте свои комментарии, будем рады обсудить.

Обзор многопроцессорных вычислительных систем. Появление кластерных систем и их преимущества перед традиционными архитектурами вычислительных сетей. Linux как ОС для кластерных систем. Построение простого кластера на примере linux-проекта Beowulf.

Рубрика	Программирование, компьютеры и кибернетика
Вид	курсовая работа
Язык	русский
Дата добавления	13.01.2012
Размер файла	716,3 K

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Введение

Кластерные системы различных классов, работающие на Linux, используются в различных образовательных и научных учреждениях, проводящих сложные вычисления, а также в коммерческих компаниях для выполнения ресурсоемких задач. К примеру, кластеры на Linux есть в Центре суперкомпьютерных вычислений Российской академии наук, Московском физико-техническом институте, ведущих научно-исследовательских институтах России и мира.

В проводимых в последнее время исследованиях Linux показывает высочайшие результаты горизонтальной масштабируемости, т.е. в увеличении вычислительной мощности за счет кластеризации серверов. Кроме того, Linux постоянно совершенствуется в области вертикальной масштабируемости (увеличения мощности отдельного сервера) и в настоящее время поддерживает 32-процессорные системы. IBM использует и расширяет возможности Linux и в своих проектах по построению суперкомпьютеров.

Подразделение IBM Research недавно закончила работу над своим суперкластером RoadRunner. Его производительность превысила 1 петафлоп и был преодолен барьер в 1 квадрилион операций в секунду! Благодаря таким высоким возможностям Linux обеспечивает тот уровень гибкости, который необходим компаниям для удовлетворения своих растущих требований сегодня и в перспективе.

Кластерные системы получили высокую степень развития, это демонстрирует тот факт, что на сегодняшний день в списке 500 самых мощных компьютеров мира из 20 первых мест 11 занимают кластерные системы. Министерство обороны США использует кластер из 256 серверов IBM x330 для повышения точности прогнозов погоды. Энергетическая компания Royal Dutch Shell добилась производительности, измеряемой в терафлопах, объединив в кластер с помощью Linux свыше одной тысячи серверов xSeries™. Как отметил эксперт по суперкомпьютерам Фрэнк Джилфивер (Frank Gilfeather) из университета Нью-Мексико: «Кластеры Linux будут определять будущее суперкомпьютеров, и компании должны понять, каким образом эта технология может им помочь».

1. Параллельные вычисления, как предпосылки создания вычислительных систем

Многие задачи требуют вычислений с большим количеством операций, которые занимают значительные ресурсы даже современной технике, более того, можно с уверенностью считать, что каких бы скоростей ни достигла вычислительная техника всегда найдутся задачи, на решение которых потребовалось значительное время. Многие из таких сложных задач требуют, чтобы результат был получен за как можно меньшее время или даже строго ограниченное. К таким задачам, например, относится прогнозирование погоды, обработка изображений и распознание образов при управлении техникой. С другой стороны представляет большую техническую проблему уменьшение времени исполнения каждой операции в микропроцессоре.

В наше время круг задач, требующих для своего решения применения мощных вычислительных ресурсов, постоянно расширяется. Это связано с тем, что произошли фундаментальные изменения в самой организации научных исследований. Вследствие широкого внедрения вычислительной техники, значительно усилилось направление численного моделирования и численного эксперимента. Численное моделирование, заполняя промежуток между физическими экспериментами и аналитическими подходами, позволило изучать явления, которые являются либо слишком сложными для исследования аналитическими методами, либо слишком дорогостоящими или опасными для экспериментального изучения. При этом численный эксперимент позволил значительно удешевить процесс научного и технологического поиска. Стало возможным моделировать в реальном времени процессы интенсивных физико-химических и ядерных реакций, глобальные атмосферные процессы, процессы экономического и промышленного развития регионов и т.д. Очевидно, что решение таких масштабных задач требует значительных вычислительных ресурсов.

Мощности современных процессоров вполне достаточно для решения элементарных шагов большинства задач, а объединение нескольких десятков таких процессоров позволяет быстро и эффективно решать многие поставленные задачи, не прибегая к помощи мэйнфреймов и суперкомпьютеров.

Такой подход носит название параллельных вычислений. Несмотря на кажущуюся простоту решения оно является подчас весьма нетривиальной задачей по проектированию вычислительной техники и разработки алгоритмов. Первая проблема кроется в том, что для того, чтобы задачу можно было решить с помощью параллельных вычислений алгоритм её решения должен допускать распараллеливание, мало того, далеко не каждая задача может быть решена параллельным алгоритмом. Другой же, не менее важной проблемой является построение системы, на которой бы возможна была реализация параллельных вычислений.

2. Обзор основных многопроцессорных вычислительных систем

2.1 Архитектура SMP

Первыми архитектурами построения вычислительных систем являются симметричные мультипроцессорные системы (SMP) и массивно-параллельные системы (MPP).

SMP (symmetric multiprocessing) - симметричная многопроцессорная архитектура. Особенность таких систем является то, что она состоит из массива общей памяти и нескольких однородных процессоров.

Рисунок 1 - Схематический вид SMP-архитектуры

Для формирования общедоступной, масштабируемой, системы памяти в SMP системах, чаще всего используется способ, который заключается в организации доступа к памяти с помощью специального масштабируемого канала процессоры-память. Каждая из операций доступа к памяти интерпретируется как группа последовательных операций по шине процессоры-память. Каждый из процессоров имеет одну или несколько собственных кэш-памятей.

SMP архитектуру можно представить в виде одного компьютера с несколькими равноправными процессорами, одной памятью, одной подсистемой ввода/вывода и одной операционной системой. Каждый из процессоров может делать все, что и другие процессоры смежные с ними. Все процессоры имеют доступ ко всему адресному пространству памяти, могут выполнять любые операции ввода/вывода, а также могут прерывать работу других процессоров .

Главные недостатками SMP-систем:

· необходимость организации канала память-процессоры, который требует высокую пропускную способность;

· низкая масштабируемость систем с общей памятью;

Из преимуществ SMP-систем можно назвать:

· простота и универсальность для программирования, так как SMP не накладывает ограничений на модель программирования, следствием этого стало существование эффективных средств автоматического распараллеливания;

· SMP-системы просты в эксплуатации.

2.2 Архитектура MPP

MPP(massive parallel processing) - массивно-параллельная архитектура с разделенной памятью. MMP строится из однородных вычислительных узлов, т.к. память физически разделена, при этом система состоит из отдельных модулей, которые содержат один или несколько процессоров, локальную операционную память (ОП), коммуникационные процессоры (рутеры) или сетевые адаптеры, жесткие диски и/или другие устройства I/O.

Рисунок 2 - Схематический вид MPP-архитектуры

К системе возможно добавление специальных устройства I/O и управляющих узлов. Все узлы связаны коммуникационной средой, построенной, например, на основе коммутатора или высокоскоростной сети.

Главное преимущество MPP это - хорошая масштабируемость, т.к. каждый процессор в данной архитектуре работает только в пространстве своей локальной памяти. Это приводит тому, что пропадает необходимость в пошаговой (тактовой) синхронизации процессоров.

Из недостатков MPP можно выделить:

· процессоры используют ограниченный объем локальной памяти;

· вследствие этих недостатков возникает потребность использования системных ресурсов, что приводит к высокой стоимости программного обеспечения для массивно-параллельных систем.

2.3 Появление кластерных систем и их преимущества перед традиционными архитектурами вычислительных сетей

Традиционные архитектуры SMP, MPP, а также векторные параллельные системы развиваются достаточно быстрыми темпами. Растет производительность, повышается отказоустойчивость и надежность. Но у всех этих перечисленных архитектур есть один существенный недостаток - цена на созданные системы, часто высокая и недоступная для широкого круга пользователей таких систем - научно-исследовательских, военных и образовательных организаций. Усложнения программных и аппаратных составляющих системы, которые требуются для обеспечения роста темпов производительности, и привели к их высокой стоимости. Кроме того постоянно возрастает потребность в вычислительных ресурсах во многих отраслях практической деятельности, для ее обеспечения не хватает производительности и ресурсов суперкомпьютерных систем, построенных на традиционных архитектурах .

Создание вычислительных систем на основе кластеров задумывалось с целью понижения стоимости программных и аппаратных средств за счет использования в своей архитектуре относительно дешевых технологий, таких как Linux, Ethernet, персональных компьютеров (PC), которые к тому времени стали широко распространятся. Более того решились проблемы нехватки вычислительных ресурсов .

Использование дешевых, массовых технологий стало возможно благодаря прогрессу в области развития компонентов простых вычислительных систем, таких как, центральные микропроцессоры, оперативная память, каналы связи, коммуникационных среды, операционные системы.

Если рассматривать кластерные системы с архитектурной точки зрения, то они являются развитием базовых составляющих технологий систем с массовым параллелизмом. Поэтому прослеживалась связь с прогрессом в области сетевых и кластерных технологий, что способствовало созданию эффективных и дешевых коммуникационных решений. Это все в целом и предопределило быстрое внедрение и развитие кластерных вычислительных систем. Также развитию кластерных систем способствовали и другие факторы.

Благодаря высокой степени резервирования и возможности географического разнесения вычислительных мощностей, входящих в состав одной системы, кластеры обладают повышенной отказоустойчивостью, и могут быть устойчивы к локальным природным бедствиям, а также катастрофам другого рода

Преимущества кластера наряду с обычными компьютерами, работающими независимо, очевидны. Благодаря специально разработанным диспетчерским системам пакетной обработки данных, можно распределять задачу на все узлы кластера и использовать для решения задачи ресурсы всей системы. От правильного выбора системного программного обеспечения, его установки и конфигурации зависит как общая производительность кластерной системы, так и её надёжность, удобство пользовательского интерфейса, который также в немалой степени косвенно определяет эффективность выполнения вычислений. Отдельные вычислительные узлы кластера работают под собственной локальной копией операционной системы, в качестве которой в большинстве случаев выбирают один из дистрибутивов ОС Linux, Windows, NetWare, Solaris или UNIX. Для централизованного управления кластерными системами как единым вычислительным массивом, в данный момент используются специализированные системы управления кластерами. Такая система позволяет осуществлять централизованное управление и мониторинг кластера, осуществлять перераспределение потоков задач, выделение под них ресурсов.

кластер архитектура linux

3. Основы кластерных систем

Кластер -- это модульная многопроцессорная система, созданная на базе стандартных вычислительных узлов, соединенных высокоскоростной коммуникационной средой.

Кластерные системы имеют ряд преимуществ перед набором независимых компьютеров. Во-первых, разработано множество диспетчерских систем пакетной обработки заданий, позволяющих послать задание на обработку кластеру в целом, а не какому-то отдельному компьютеру. Эти диспетчерские системы автоматически распределяют задания по свободным вычислительным узлам или буферизуют их при отсутствии таковых, что позволяет обеспечить более равномерную и эффективную загрузку компьютеров. Во-вторых, появляется возможность совместного использования вычислительных ресурсов нескольких компьютеров для решения одной задачи.

3.1 Виды кластеров

Существуют три основных вида кластеров: Fail-over (отказоустойчивые), Load-balancing (балансировочные, распределяющие нагрузку) и High Performance Computing (высокопроизводительные вычислительные).

Отказоустойчивые кластеры представляют собой два или более связанных по сети компьютера с дополнительным выделенным контрольным (heartbeat) соединением между ними. Это выделенное соединение между машинами используется для мониторинга состояния сервисов: как только заданный сервис на одной машине выходит из строя, то другая начинает выполнять её функции.

Концепция балансировочных кластеров заключается в том, что если, допустим, приходит запрос к веб-серверу, то кластер сначала определяет наименее загруженную машину, а затем направляет к ней запрос. Довольно часто балансировочный кластер выполняет и функции отказоустойчивого кластера, хотя для этого и требуется большее количество узлов.

Последний вид - вычислительный кластер, используется специально для центров обработки информации, которым необходима максимально возможная производительность. К подобным системам относится система Beowulf, разработанная именно для исследовательских центров, нуждающихся в большой скорости вычислений. В таких системах также присутствует некоторая функция балансировочных кластеров: для повышения производительности они стараются распределить процессы на большее количество машин. Только в данном случае процесс распараллеливается на части, которые выполняются на многих машинах одновременно, вместо того чтобы выполняться друг за другом по очереди.

3.2 Модели кластеров

Существует несколько технологий реализации параллельных вычислений: (N)UMA, DSM, PVM и MPI - всё это различные схемы параллельных вычислений. Некоторые из них уже реализованы аппаратно, другие только в программном, а некоторые - и в том, и в другом виде.

(N)UMA: здесь машины пользуются разделяемым доступом к памяти, в которой они могут выполнять свои программы. В ядре Linux реализована поддержка NUMA, позволяющая получать доступ к разным областям памяти. При этом задача ядра использовать ту память, которая находится ближе к процессору, работающему с ней.

DSM уже реализована не только в программном виде, но и в аппаратном. Основная концепция DSM в организации абстрактного слоя для физически распределённой памяти.

Технологии PVM и MPI наиболее часто упоминаются, когда речь заходит о GNU/Linux Beowulf кластерах.

PVM - ещё один родственник MPI, широко используемый при создании Beowulf. PVM работает как пользовательская программа, поэтому никаких изменений в ядро системы вносить не нужно - выходит, что любой пользователь с минимальными правами может запустить PVM.

3.3 Концепция кластерных систем

Рисунок 1 - Кластерная система

Кластер функционирует как единая система, то есть для пользователя или прикладной задачи вся совокупность вычислительной техники выглядит как один компьютер. Именно это и является самым важным при построении кластерной системы.

Первые кластеры компании Digital были построены на машинах VAX. Эти машины уже не производятся, но все еще работают на площадках, где были установлены много лет назад. И наверное самое важное то, что общие принципы, заложенные при их проектировании, остаются основой при построении кластерных систем и сегодня.

К общим требованиям, предъявляемым к кластерным системам, относятся:

1) Высокая готовность

2) Высокое быстродействие

4) Общий доступ к ресурса

5) Удобство обслуживания

Естественно, что при частных реализациях одни из требований ставятся во главу угла, а другие отходят на второй план. Так, например, при реализации кластера, для которого самым важным является быстродействие, для экономии ресурсов меньше внимания придают высокой готовности.

3.3.1 Разделения кластеров по распределению программно-аппаратных ресурсов

В общем случае кластер функционирует как мультипроцессорная система, поэтому, важно понимать классификацию таких систем в рамках распределения программно-аппаратных ресурсов. Рассмотрим её на примере рисунков

Рисунок 2 - Тесно связанная мультипроцессорная система

Рисунок 3 - Умеренно связанная мультипроцессорная система

Рисунок 4. Слабо связанная мультипроцессорная система

3.3.2 Разделение на High Avalibility и High Performance системы

В функциональной классификации кластеры можно разделить на "Высокоскоростные" (High Performance, HP), "Системы Высокой Готовности" (High Availability, HA), а также "Смешанные Системы".

Высокоскоростные кластеры используются для задач, которые требуют значительной вычислительной мощности. Классическими областями, в которых используются подобные системы, являются:

1) обработка изображений: рендеринг, распознавание образов

2) научные исследования: физика, биоинформатика, биохимия, биофизика

3) промышленность (геоинформационные задачи, математическое моделирование)

Рисунок 5 - Высокоскоростной кластер

Кластеры, которые относятся к системам высокой готовности, используются везде, где стоимость возможного простоя превышает стоимость затрат, необходимых для построения кластерной системы, например:

1) биллинговые системы

2) банковские операции

3) электронная коммерция

4) управление предприятием, и т.п.

Сегодня в мире распространены несколько типов систем высокой готовности. Среди них кластерная система является воплощением технологий, которые обеспечивают высокий уровень отказоустойчивости при самой низкой стоимости. Отказоустойчивость кластера обеспечивается дублированием всех жизненно важных компонент. Максимально отказоустойчивая система должна не иметь ни единой точки, то есть активного элемента, отказ которого может привести к потере функциональности системы. Такую характеристику как правило называют - NSPF (No Single Point of Failure, - англ., отсутствие единой точки отказа).

Рисунок 6. Кластерная система высокой готовности с отсутствием точек отказов

Смешанные системы объединяют в себе особенности как первых, так и вторых. Позиционируя их, следует отметить, что кластер, который обладает параметрами как High Performance, так и High Availability, обязательно проиграет в быстродействии системе, ориентированной на высокоскоростные вычисления, и в возможном времени простоя системе, ориентированной на работу в режиме высокой готовности.

В этой статье мы соберем кластер на дистрибутиве Centos 7 с использованием пакета Pacemaker. Сборка из исходников DRBD описывается в этой статье. Настройка реплицируемого блочного устройства описывается в статье по этой ссылке. Для полноценной работы кластера одного DRBD не достаточно, должен быть механизм мониторинга состояния блочных устройств, процессов, сервисов, состояние работы самой операционной системы, сети […]

В этой статье мы соберем кластер на дистрибутиве Centos 7 с использованием пакета Pacemaker.

Дстрибутив будем использовать CentOS-7-x86_64-Minimal-1908 и DRBD версии 9.

Для полноценной работы кластера одного DRBD не достаточно, должен быть механизм мониторинга состояния блочных устройств, процессов, сервисов, состояние работы самой операционной системы, сети ит.д. Также должен быть механизм репликации диска на другую ноду в случае отказа первой. Также в некоторых случаях используется один общий виртуальный ip адрес на нодах для возможности функционирования кластера как единая система. Этими функциями DRBD не занимается.

Нода это единица кластера. Простыми словами это один из серверов входящий в кластерную систему. Их может быть произвольное количество

Вышеописанными задачами занимается Pacemaker – менеджер ресурсов кластера.

Pacemaker состоит из 5 ключевых компонентов:

CIB – Cluster Information Base это база данных которая содержит конфигурацию кластера и состояние ресурсов кластера. Сама база данных храниться в файле в формате XML

Отдельно редактировать файл ни в коем случае нельзя, редактирование происходит с помощью самого pacemaker. Иначе вы рискуете остаться без рабочего кастера.

2. Stonithd – это механизм, который позволяет кластеру выключать, перезагружать, включать узлы кластера сети если узел не отвечает, то его ресурсы передаются другой ноде, или если ресурс дал сбой он отключается от общего кластера для предотвращения сбоя всего кластера.

3. PEngine – механизм политики. Он рассчитывает идеальное состояние кластера. Если какой либоо механизм дал сбой, PEngine сделает перерасчет механизма работы всего кластера и передаст его в CRMd

4. CRMd – демон управления ресурсами кластера. PEngine выбирает CRMd на какой-то одной ноде. В случае сбоя забочей ноды с CRMd быстро назначается новая нода как главная. Главная CRMd получает инструкции от PEngine и передает их в требуемом порядке или LRMd (демон локального управления) или одноранговым CRMd на других нодах, а те в свою очередь LRMd своего локального процесса.

5. LRMd – демон управления локальными ресурсами который исполняет полученные инструкции от CRMd на локальной машине, а также передает обратно результат их выполнения.

Главный CRMd называется DC (Designated Controller) – назначенный контроллер

Ключевые компоненты из которых состоит Pacemaker

Для правильной работы кластера нам необходимо иметь по 2 сетевых интерфейса в каждой ноде. По первому интерфейсу будет связь с общей сетью, а через второй интерфейс ноды будут обмениваться служебной информацией.

Также нужно настроить имя хостовой машины и DNS для общения серверов по имени

Построить кластер можно только с использованием имен. По ip адресам настроить не получится.

Исходные параметры первой ноды

Первый интерфейс 192.168.32.20 (доступ в локальную сеть)

Второй интерфейс 10.10.10.1 (интерфейс для общения нод)

Исходные данные второй ноды:

Первый интерфейс 192.168.32.19 (доступ в локальную сеть)

Второй интерфейс 10.10.10.2 (интерфейс для общения нод)

Для изменения имени хоста без перезагрузки сервера воспользуемся утилитой hostnamctl

После указания имени хоста необходимо в файле /etc/hosts прописать Ip адрес и hostname противоположных атс.

На первой ноде добавляем

На второй ноде добавляем

Пример файла /etc/hosts со второй ноды.

Далее необходимо проверить корректность введенных данных пропинговав друг друга по имени хоста.

Результат должен быть как на скриншоте (пример с одной ноды):

пинг со второй ноды.

Перед наxалом установки убедитесь, что отключен SELINUX

Проверка статуса Selinux

Включенный Selinux

Для выключения Selinux необходимо в конфигурационном файле /etc/selinux/config прописать SELINUX=disabled

Отключение Selinux

Далее приступим к установке необходимых пакетов для сборки кластера:

Где pacemaker описан выше, менеджер ресурсов кластера. Он позволяет использовать службы и объекты в рамках одного кластера из двух или более нод.

Resource-agent – этот пакет содержит агенты ресурсов(набор скриптов) кластера (RA), соответствующие спецификации Open Cluster Framework (OCF), используемые для взаимодействия с различными службами в среде высокой доступности, управляемой менеджером ресурсов Pacemaker.

Corosync – информационный уровень. программный продукт, который позволяет создавать единый кластер из нескольких аппаратных или виртуальных серверов. Corosync отслеживает и передает состояние всех участников (нод) в кластере.

Этот продукт позволяет:

Pcs – pacemaker/corosync configuration system. Утилита для управления, настройки и мониторинга кластера. Управляется как через командную строку, так и через веб интерфейс.

Также кластер можно настроить без pcs. Но тут будет немного сложнее, т.к. все остальные утилиты придется настраивать вручную. Pcs берет все на себя

На следующем этапе необходимо отключить фаервол на время, после сборки кластера в фаевол надо обязательно включить и прописать необходимые порты.

Отключение и остановка фаервола

На следующем этапе запустим на обеих нодах pcs демон:

После установки pcs на обоих нодах будут созданы пользователи «hacluster»

С помощью этих учеток ноды будут «общаться между собой». Зададим для них новые сложные пароли:

создание пароля для учетной записи hacluster

Далее с помощью pcs авторизуемся на обоих нодах:

Авторизация на всех нодах с помощью pcs

На следующем шаге создаем кластер:

Эта команда создаст кластер, автоматически сгенерирует конфигурационный файл corosync.

После успешного создания кластера его необходимо запустить следующей командой:

Запуск кластера.

Как видно из скриншота, запускается corosync и pacemaker.

На этом установка и первоначальная настройка кластера завершена. В следующей статье мы поговорим про управление, мониторинг кластера.

Читайте также: