СТРАТЕГИИ КОНФИГУРИРОВАНИЯ ВЫЧИСЛИТЕЛЬНОГО КЛАСТЕРА

Костюков Антон Александрович

аспирант кафедры МОиПЭВМ Пензенский Государственный Университет,

РФ, г. Пенза

Email: antononrails@gmail.com

STRATEGY COMPUTING CLUSTER CONFIGURATION

Anton Kostiukov

graduate student at department of computer application and software

Penza State University,

Russia, Penza

АННОТАЦИЯ

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

ABSTRACT

The article describes the nuances and variations of configuring computing cluster (distributed computing system). The detailed review of the conditions of execution, as well as maintenance and support of cluster-configured systems.

Ключевые слова: Распределённые вычислительные системы; стратегии конфигурирования; кластерные системы; вертикальное масштабирование.

Keywords: Distributed computing systems; strategy configuration; cluster systems; vertical scaling.

Вычислительный кластер (также нужно иметь ввиду, понятие – распределенная вычислительная система, РВС) является одной из самых необходимых абстракций при решении задач обслуживания пользователей. В современном мире, каждый раз, когда пользователь обращается к высоконагруженному[1] ресурсу, можно считать, что его запрос попадает не напрямую к целевому серверу, который имеет доступ к необходимой информации, а в некий пул серверов, которым управляет распределитель нагрузки. Распределитель (балансировщик) нагрузки в свою очередь принимает решение о направлении запроса тому или иному узлу на обработку, после чего может быть два варианта развития событий: либо узел сам направляет запрашиваемый ресурс (решение задачи) клиенту, либо запрос опять возвращается в распределитель, и оттуда уже направляется по адресу. Принятие решения на стороне балансировщика – сама по себе отдельная математическая задача, решающаяся как эвристическим, так и теоретическим методами. С примерами решения, можно ознакомиться в работе Безяева В.С и Макарычева П.П. [2].

Выделяют несколько основных направлений конфигурирования РВС: High Availability Cluster (высокодоступная РВС) – кластер, ориентированный на обеспечение максимальной доступности ресурсов. РВС включает в себя большое количество узлов (больше минимально необходимого на несколько порядков), что приводит к масштабному повышению доступности системы в целом. В общем случае минимальное количество узлов для обеспечения высокой доступности – это пара. Load Balancing Cluster (балансировочный РВС) – базируется на принципе балансировки нагрузки на сервер при помощи одного или нескольких входных узлов. Данные узлы распределяют трафик направляющийся на сервер по определенному алгоритму между узлами РВС. Такой подход изначально ориентирован на производительность, но иногда в таких системах применяются так же методики для повышения надежности. Такие архитектуры называются фермами. High Performance Cluster (высокопроизводительная РВС или Beowulf cluster) – применяется для обеспечения наивысшей производительности. Такая система применяется для научных вычислений. Они выполняют огромный объем работы путем распараллеливания задач на несколько задач исполняемых на разных узлах сети. Связь между узлами строится как можно эффективней, что позволяет осуществлять оперативный обмен данными, поэтому такие кластеры довольно хорошо подходят для распараллеливания вычислительных задач и использования общих подсистем. MapReduce Grid Cluster (РВС для распределенных вычислений или grid-система. Система построенная на подобной архитектуре является низкодоступной (невозможно гарантировать корректную работу узла в каждый момент времени), так как узлы могут выполнять горячее подключение и отключение от системы. Такие системы обычно используют для параллельных вычислений не требующих обращения с РВС как с единым компьютером.

На данный момент существует огромное количество конфигураций для РВС. Основными являются две: Shared Nothing Model (SNM) – модель РВС, которая не разделяет доступа к подсистемам, или не имеет таковых вообще. Данный вид РВС обычно используется в связке с внешними источниками данных и удаленными вычислительными узлами. Так РВС построенная по технологии Network Load Balancing (NLB) не имеет общих ресурсов. NLB спроектирована как простое объединение узлов РВС в локальную сеть. Чтобы реализовать архитектуру подобного вида необходимо лишь соединение между узлами сети посредством сетевых карт устройств. Назначение Network Load Balancing состоит в балансировке трафика на сетевом уровне. Данный подход позволяет увеличить уровень отказоустойчивости сервера. Запросы клиентов перенаправляются самими узлами наименее занятому узлу для дальнейшей обработки, что уменьшает время отклика сервера в целом и скорость обработки запроса в частности. Ввиду того, что в системе так же происходит автоматическое обнаружение неработоспособных узлов и перераспределение задач между работоспособными узлами повышается уровень надежности сервера (отказоустойчивость). Для реализации данного поведения на каждой машине, представляющей собой узел РВС должно быть установлено соответствующее программное обеспечение (ПО), работающее на сетевом уровне модели OSI. Со стороны клиента существует пул адресов для доступа к РВС и посредством запроса к кластеру как к единому целому, сеанс связи пользователя с сервером представляется как отправка запросов и принятие ответов от единого сервера. Достоинства данного подхода к организации РВС – это высокая скорость обработки запросов, устойчивость к сбоям. Недостатки: высокая фрагментированность системы по части целостности данных на разных узлах, проблемы репликации данных, снижение скорости работы системы в целом при значительном расширении парка устройств, сложность в поддержке и поиске неисправностей. Shared Device Model (SDM) – модель РВС с разделяемым доступом к общим подсистемам данных. При проектировании кластеров с общей подсистемой данных (хранения информации) нет необходимости заботиться о целостности данных, так как все данные хранятся в одной подсистеме и не зависят от систем репликации. При поломке одно узла, остальные машины не теряют возможность получать доступ к данным на подсистеме. Управление подсистемой хранения данных происходит на узлах совместно и может возникнуть ситуация иного рода при записи данных в подсистему, что может привести к «загрязнению» данных или вообще их полной потери. Обычно узлы такой РВС объединяются между собой при помощи сетевых карт и пропускная способность системы в целом зависит от суммарной пропускной способности сетевых интерфейсов всех узлов системы. Машин в подобной РВС может быть от двух, до нескольких сотен. Все узлы могут быть сконфигурированы различными способами, иметь различные операционные системы (ОС) и различное аппаратное обеспечение, что делает подобный подход очень привлекательным для высоконагруженных систем, где используется большое число узлов и следует стремиться к более низкой стоимости замены оборудования или горизонтального расширения РВС.

Исследуя все аспекты интернет ориентированных систем, включая их технологии, стратегии построения и управления нельзя не брать во внимание CAP теорему [5] Эрика Брюера[2], которая в общем виде гласит: «В распределенной системе невозможно обеспечить одновременное выполнение всех трех условий: целостность, доступность, надежность». Необходимо пояснить суть каждого из этих свойств: Целостность (Consistency) – система выдает только логически непротиворечивые ответы. Доступность (Availiability) – система отвечает на запросы перманентно. Устойчивость к сбоям сети (Partition tolerance) – распределенная по кластеру система работает в расчете на случаи произвольной потери пакетов внутри сети.

По теореме CAP, кластерные конфигурации, распадаются на три класса в зависимости от пары свойств, которыми они обладают: CA – кластер, в каждом из узлов которого, все данные согласованы с остальными узлами, а также обеспечена доступность – жертвует возможностью распада на секции. Данный подход может быть осуществлен на основе ПО поддерживающего сеансы транзакций (ACID). Можно привести пример таких систем – кластерная СУБД или LDAP. CP – система распределенная по узлам кластера, которая в каждый момент времени обеспечивает целостный результат, также способная к распаду на секции, жертвует доступностью, рискуя не откликаться на запрос пользователя. Устойчивость к распаду может быть осуществлена только при условии мгновенного распространения изменений в узлах кластера. В таких случаях используют пессимистические блокировки транзакций для обеспечения данного условия. AP – система, в которой целостностью результата отодвигается на задний план. Пример таких систем: DNS, Web-Cache, NoSQL. При построении AP-системы главным приоритетом является обеспечение минимального уровня целостности данных. Такие системы еще называются «приходящие к целостному состоянию». (англ. eventually consistent) или как о «слабо целостных» (англ. weak consistent).

Стратегии конфигурирования вычислительного кластера имеют под собой обширный пул задач, и довольно массивную теоретическую поддержку. Решая задачи в кластерной среде – невозможно не столкнуться с трудностями понимания функционирования распределенных сред. В данной статье были изложены вводные абстракции вышеозначенной теории и основные принципы стратегий. Ближе познакомиться с обсуждаемой темой можно в работах Таненбаума Э. [3], Брюера Э. [5], и других ученых работающих в данной области.

Список литературы:
1. Айвалиотис Д.А. Администрирование сервера NGINX / Москва: Москнига, 2011 – 300 с.
2. Безяев В.С., Макарычев П.П., Решение задачи о назначениях в автоматизированных системах оперативного управления на основе тензорного исчисления // Известия высших учебных заведений. Поволжский регион. Технические науки. 2015. № 3 (35). С. 78–86.
3. Таненбаум Э. Распределённые системы. Принципы и парадигмы. – СПб.: Питер, 2003. – ISBN: 5-272-00053-6.
4. Юревич Ю.Г. WSGI, Введение WSGI – стандарт обмена данными между веб-сервером и веб-приложением / Юревич Ю.Г. – Санкт-Петербург: ДМК Питер, 2010 – 200 с.
5. Brewer E., // Proceedings of the XIX annual ACM symposium on Principles of distributed computing. Portland, 2000.