Программа для кластеризации компьютеров

Обновлено: 07.07.2024

Всем привет! Представляю вашему вниманию новую версию программы KeyClusterer, предназначенной для группировки семантического ядра методами Hard и Soft.

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

Основные изменения

1. Оптимизирована скорость импорта и кластеризации запросов.

Скорость импорта запросов из CSV-файлов на некоторых проектах выросла до 20 раз. Даже для 100 000 запросов импорт теперь занимает менее 3-х минут.

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

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

Для метода Soft (порог 4):

Для метода Hard (порог 3):

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

2. Добавлено диалоговое окно импорта данных из CSV.

По вашим просьбам мы добавили форму для облегчения импорта проектов из CSV-файлов, в том числе из программы Key Collector.

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

3. Добавлена возможность отмены последних действий при работе с семантическим ядром.

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

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

4. Добавлена возможность вырезки и вставки групп и ключевых запросов.

Теперь, помимо переноса групп и запросов методом Drag & Drop, можно вырезать и вставлять запросы и группы при помощи контекстного меню и комбинаций клавиш Ctrl-X и Ctrl-V. Это является более удобным способом манипуляции группами и запросами на больших семантических ядрах.

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

5. Добавлена возможность использования списка стоп-слов для манипуляции ключевыми запросами.

Было добавлено отдельное окно для хранения стоп-слов и манипуляций ими.

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

Параметры действий при поиске запросов:

Полное вхождение (ищем "я пил молоко", находим "молоко я пил вчера").
Частичное соответствие (ищем "ил моло", находим "я пил молоко").
Точное соответствие (ищем "я пил молоко", находим "я пил молоко").

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

6. Добавлена подсветка найденных слов и частей слова при фильтрации данных.

При фильтрации данных, найденные части слова из первого фильтра теперь выделяются желтым цветом, а из второго – зеленым.

7. Добавлена возможность работы со списком прокси.

Была добавлена поддержка работы программы через прокси с возможностью проверки списка прокси-серверов на работоспособность.

8. Оптимизирована работа с сайтами-исключениями в интерфейсе основных настроек программы.

Список сайтов исключений теперь редактируется в отдельном окне основных настроек программы.

Прочие изменения

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

Я недавно проводил исследование, в рамках которого было необходимо обработать несколько сотен тысяч наборов входных данных. Для каждого набора — провести некоторые расчеты, результаты всех расчетов собрать вместе и выбрать "лучший" по некоторым критериям. По сути это bruteforce перебор. Тоже самое происходит при подборе параметров ML моделей с помощью GridSearch .

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

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

Для построения "домашнего кластера" прекрасно подойдет библиотека Dask (https://dask.org/). Она проста в установке и не требовательна к узлам, что серьезно понижает "уровень входа" в кластерные вычисления.

Для настройки своего кластера нужно на всех компьютерах:

установить интерпретатор python
установить пакеты dask и прикладные пакеты вашего распределенного приложения
сконфигурировать запуск планировщика (scheduler) на одном из компьютеров и работников (worker) на всех доступных

Версии python

Поскольку Dask в своих операциях зависит от pickle, на клиенте, шедулере и рабочих узлах необходимо держать версии одинаковые или очень близкие версии python.
Версии 3.6 и 3.7 вместе работают, хотя и выдается предупреждение о различии версий. Узлы с 3.8 вместе с предыдущими работать не будут из-за новой версии pickle.

Если все ставится "с нуля", то, очевидно, лучше ставить везде одну версию.

Пакеты Dask

Dask и необходимые зависимости устанавливается как стандартные пакеты с помощью pip или conda

В документации под dask, последний пакет bokeh упоминается как опциональный, но не говориться, что без него "по-тихому" не будет работать прекрасная функция dask dashboard.
Без нее проводить мониторинг кластера и наблюдать как задачки разбегаются по узлам будет невозможно. А это очень поможет при оптимизации приложения для работы в распределенной среде.

Для сборки необходим gcc, потому:

на MacOS должен быть установлен xcode
если собираете docker image для запуска docker-worker, то начать с "тонкого" имиджа, типа python:3.6-slim-buster может не получиться. Прийдется либо доставлять необходимые пакеты, либо взять полноразмерный исходный имидж python:3.6 .

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

Процесс-планировщик создается один на кластер. Запускать его можно на любой машине. Единственная очевидная рекомендация — машина должна быть максимально доступна.

Процессы-работники запускаются на всех компьютерах, ресусами которых вы планируете пользоваться.

nprocs / nthreads — количество процессов, которые будут запущены, и количество потоков в каждом из них. Поскольку GIL присутствует и на стороне процессов-работников, запускать обработку на многих потоках имеет смысл только если распределенный процесс реализован на чем-то низкоуровневом, как numpy. В противном случае нужно масштабироваться за счет количества процессов.
memory-limit — объем памяти, доступный каждому процессу. Ограничивать доступную память процесам нужно очень аккуратно — при достижении предела по памяти процесс-работник перестартовывает, что может вызвать остановку процесса обработки. Я сначала ставил ограничение, но потом убрал.
death-timeout — время в секундах, в течении которого процессы-работники будут ждать, пока планировщик перезапустится. Это время нужно подбирать в соответствии с ожидаемым временем перезагрузки компьютера-планировщика. Как ни странно, похоже, этот параметр не всегда учитывается.
name — префикс имени процесса-работника, как он будет отображаться в отчетах планировщика. Это удобно, чтобы видеть "человеческие" имена сервисов-работников.
local-directory — директория, которая будет использоваться для создания временных файлов

Запуск процессов-работников на Windows в виде сервиса

Понятно, что запуск dask-worker со всему параметрами делается в виде пакетного файла. Также, чтобы кластер поднимался сам, dask-worker должен запускаться как только компьютер стартовал.

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

Проверка Firewall

Также необходимо проверить правила firewall: планировщик должен иметь возможность достучаться до процесса-работника.

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

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

Подключение к кластеру

Подключение к распределенному кластеру происходит очень просто:

Если не указать расположение планировщика — запустится "локальный" кластер в пределах одной машины, но это не то что нужно.

Общие прикладные пакеты

Важно иметь ввиду, что все пакеты, которые необходимы для работы распределенного приложения должны быть установлены и на рабочих узлах кластера. Это касается pandas, numpy, scikit-learn, tensorflow.
Особо критично совпадение версий пакетов на всех узлах кластера для объектов, которые сериализуются.

Что делать, если на узлах кластера отсутствует необходимый пакет? Можно воспользоваться стандартной функцией удаленного запуска функций — и запустить pip

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

Пакеты и модули приложения

Если в состав приложения входят разработанные пакеты или модули, и вы хотите, чтобы программный код из них выполнялся распределенно — то эти пакеты и модули также должны быть распространены на все узлы кластера перед запуском приложения.
Это довольно серьезное неудобство, если вы все еще дорабатываете приложение и пытаетесь его структурировать, и попутно запуская его в распределенной среде Dask кластера.

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

Файл-модуль можно передать непосредственно, а пакет прийдется предварительно запаковать в zip.

Масштабирование joblib

Я использую библиотеку joblib для удобного параллельного выполнения операций в рамках одного компьютера. Поскольку joblib позволяет подменить движок — модификация кода получается довольно простой:

Версия с joblib

Версия с joblib + dask

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

Работают только два из доступных 16 работников, огромные промежутки между интервалами загрузки.

Время на выполнение одного батча — 10-20 мс, а интервалы между работами может достигать 200мс.

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

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

На картинке отмечены области, где процесс вычисления все еще неоптимален.

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

Теперь время выполнения вычислений для пакета работы занимает 3.5-4 сек, а время на простой измеряется десятками милисекунд. Стало гораздо лучше: видно, что увеличение размера батча и количества пред-запланированных задач увеличили время, выделенное на выполнение, и не добавили много оверхеда.

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

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

Масштабирование GridSearchCV

Поскольку scikit-learn также использует joblib для реализации параллельной работы, масштабирование обучения моделей достигается ровно также — подменой движка на dask

В результате выполнения:

Каждый перебираемый вариант преобразуется в отдельную задачу для dask. Таким образом все варианты распределяется случайным образом по всем доступным процессам-работникам.
При наличии достаточного количества работников в кластере — все работы начинают выполняться параллельно.

К сожалению, в случае если модель с разными значениями гиперпараметров сходится за разное время (как в данном случае) — параллелизм не приводит к сокращению времени пропорционально количеству узлов кластера. Но длительность всего процесса подбора становится сравнима с самым долгим вариантом — уже очень неплохо.

Библиотека Dask — прекрасный инструмент для масштабирования для определенного класса задач. Даже если использовать только базовый dask.distributed и оставить в стороне специализированные расширения dask.dataframe, dask.array, dask.ml — можно существенно ускорить эксперименты. В некоторых случаях можно добиться почти линейного ускорения рассчетов.

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

Если у вас есть 32 старых однопроцессорных компьютера, нужно лишь найти способ, как заставить их работать сообща. Другими словами — собрать из них кластер. Да, у них всего по одному процессорному ядру, но все вместе они смогут сделать больше, чем одна двухъядерная машина. Как это сделать, рассказано в статье Т. Лемана (Tom Lehmann) «Как создать высокопроизводительный вычислительный кластер на Linux». В статье приведен обзор пакета Rocks — Linux-дистрибутива для развертывания, управления и поддержки высокопроизводительного вычислительного кластера.

> но все вместе они смогут сделать больше, чем одна двухъядерная машина

проще сдать весь этот хлам на металлолом и купить четырехъядерную машину

>Если у вас есть 32 старых однопроцессорных компьютера

А я-то думал куда мне деть мои 32 старых компа.

Т.е. 32 компа немногим лучше, чем одна двухядерная машина?

> Т.е. 32 компа немногим лучше, чем одна двухядерная машина?

Скорее хуже, если нет своей АЭС.

/me пошел делать кластер из 133 и 166 машинок

у нас в европе элекричество дорогое. так что лесом эту хрень

лучше купить один мощный комп.

А счет за киловатт-часы кто будет оплачивать?

Это развёртывать можно разве что в университетах, где тачки одинаковые.

> Если у вас есть 32 старых однопроцессорных компьютера

Возможно Вы серьезно больны.

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

> лучше купить один мощный комп.

А лучше 32 мощных компа :)

> Боюсь серверные двухканальные сетевухи будут стоить дороже этого хлама, а на обычных делать смысла нет -- пересылки всё сожрут.

Именно поэтому по ссылке упоминается InfiniBand.

Вот тут тоже про кластеры.

Это главная? Или толксы?

>Если у вас есть 32 старых однопроцессорных компьютера

Поменяйте их на один новый

>Да, у них всего по одному ядру, но все вместе они смогут сделать больше, чем одна двухъядерная машина.

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

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

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

А о том, как приготовить офигический ужин на двоих из 7 протухших сарделек там не пишут?

а почему вы интересуетесь?

Пишут как сделать ужин, а протухшие или свежие сардельки туда резать - Вам решать :D

А по делу мне кажется что статья вполне ничего. Как ознакомительная по кластерным дистрам. Кстати, Beowulf-подобные решения вполне могут быть востребованы в тех же универах для обучения. У нас было такое дело что пришел новый класс, старый так тоже вполне себе ничего был. Там оптероны 4-процовые стояли. И их "утилизировали" подобным способом.

> чОрт, у меня есть только всего один старый комп. Я смогу сделать из него кластер, который обделает все 10-ядерные ксеноны.

и питцот галагенок

всё, бегу докупать ещё 31 однопроцессорный комп, и я буду круче чем сосед со своим 2 ядерным ноутбуком. вот я его натяну! ( а электричество.. это уже мелочи.. главное куда деть эти 32 компа?)

только сегодня думал что надо почитать про кластеры линуксовые ^_^

>Если у вас есть 32 старых однопроцессорных компьютер

Слово "старых" явно лишнее в названии статьи.

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

О! У меня! У меня есть!!1111111 Вся кладовка в офисе ими завалена (на полном серьёзе, раньше юзались как ТК, потом перешли на ТК от HP) - выбросить жалко, применить некуда.

Интересно, если их все в кластер собрать - на них tomboy пойдёт?

>Если у вас есть 32 старых однопроцессорных компьютера

Самая идея совершенно бредовая, но очень типичная для нищебродского отечественного IT. Дело-то ведь не в том, чтобы сэкономить за счёт использования кластера - да Боже упаси, эксплуатация скоренько сожрёт денег больше, чем любой Гаргантюа с Пантагрюэлем вместе взятые, - НЕТ, дело в том, чтобы уложиться в текущий бюджет, чтобы, например, обучение начальника каким-нибудь основам CRM/BPM не пошло прахом из-за покупки нового дорогого мощного сервера. Народ в организациях просто боиться тратиться единовременно на крупные суммы. Лучше вот 10 раз по 30 рублей, чем один раз аж 100 капиталовыложить! И все прекрасно понимают, что кластер из хлама - это бесполезно и бесцельно, впустую потраченное время специалистов (которое тоже чего-то ПО ИДЕЕ должно бы стоить), это неоправданно высокие затраты электроэнергии, это на порядки более геморройные и менее диагностируемые проблемы с железом, это место в серверной в конце-концов (и оно тоже денег стоит), но ё-моё, вы ж посмотрите, господин гавнюк, то мы бы купили IBM P-серии (кошмарно дорогой, аж два ваших отпуска в Европе!), а так - мы такие умные, погладщьте нас по головке и увеличьте фонд на обучение, уйму денег вам сэкономим, старую серверную рухлядь соберём в ультрамодное словечко - HA-кластер (НА - это, правда, не высокодоступный значит, это просто наше русское классическое НА ) и будем круче яиц, сваренных в крутую на процессорах этих 32-х машинок. УРА! Все счастливы, углекислый газ выделяется, парниковый эффект усиливается, скоро все будем жить на Канарах или хотя бы просто на острове посреди Мирового Океана - все вместе, начальнека, все вместе, в тесноте, да не в обиде.

как пел Евгений Гудзь, "серебряные зайцы водят хоровод". теперь я знаю, он про гленду ;)

Нифигасе высер. А если я четыре сервака на кореквадах в кластер хочу, чтоб аппсервер мог не 3000 а 10000 соединений одновременных обслуживать? А тестироваться/практиковаться на чём?

Спасибо, Виктор Алексеевич. Хорошая, годная статья.

Я бы переименовал в "Как собрать обогреватель".
В принципе лето заканчивается, скоро будет актуально.

Виндовый ботнет и то выглядит перспективнее для всяких расчетов, чем старая рухлядь (еще и 32 шутки). И тише будет.

Чтобы аппсервер мог больше соединений обслуживать, прежде всего замените аппсервер на бэкенды, написанные на C и веб-фронтенды на Perl! Java-сервера приложений 80% времени своей работы тупо жрут процессорное время и память. Дай какой-нибудь веб-сфере сказать "Hello, world!", она и на это потратит столько же тактов, сколько в каком-нибудь 1970-ом году тртилось на расчёт полёта космической ракеты. У меня как у ASM-програмиста подобные вещи ничего, кроме отвращения, не вызывают. Ну и собственно очень редко узким местом является именно процессор, гораздо чаще это всё-таки ввод-вывод, ну а коли у вас все ноды кластера наверняка будут подключены к одной полке и делить одно на всех внешнее ethernet-подключение, то о каком трёхкратном росте производительности может идти речь?

>Чтобы аппсервер мог больше соединений обслуживать, прежде всего замените аппсервер на бэкенды, написанные на C и веб-фронтенды на Perl!

А потом выйдите на улицу на перекур и узнайте, что Землю сто лет назад захватили серо-зеленые жабокрылы.

32 * 300 Watt одной машины

9kWat хорошенький обогреватель, всё равно аля <Как из 32 студентов инженеров первоеурсников сделать 1 крутого админа>

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

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

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

Кластеры высокой готовности или отказоустойчивые кластеры (high-availability clusters или failover clusters) используют избыточные узлы для обеспечения работы в случае отказа одного из узлов.
Кластеры балансировки нагрузки (load-balancing clusters) служат для распределения запросов от клиентов по нескольким серверам, образующим кластер.
Вычислительные кластеры (compute clusters), как следует из названия, используются в вычислительных целях, когда задачу можно разделить на несколько подзадач, каждая из которых может выполняться на отдельном узле. Отдельно выделяют высокопроизводительные кластеры (HPC — high performance computing clusters), которые составляют около 82% систем в рейтинге суперкомпьютеров Top500.

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

Такую систему можно рассматривать как обобщение понятия «кластер». ластеры могут быть сконфигурированы в режиме работы active/active, в этом случае все узлы обрабатывают запросы пользователей и ни один из них не простаивает в режиме ожидания, как это происходит в варианте active/passive.

Oracle RAC и Network Load Balancing являются примерами active/ active кластера. Failover Cluster в Windows Server служит примером active/passive кластера. Для организации active/active кластера требуются более изощренные механизмы, которые позволяют нескольким узлам обращаться к одному ресурсу и синхронизовать изменения между всеми узлами. Для организации кластера требуется, чтобы узлы были объединены в сеть, для чего наиболее часто используется либо традиционный Ethernet, либо InfiniBand.

Программные решения могут быть довольно чувствительны к задержкам — так, например, для Oracle RAC задержки не должны превышать 15 мс. В качестве технологий хранения могут выступать Fibre Channel, iSCSI или NFS файловые сервера. Однако оставим аппаратные технологии за рамками статьи и перейдем к рассмотрению решений на уровне операционной системы (на примере Windows Server 2008 R2) и технологиям, которые позволяют организовать кластер для конкретной базы данных (OracleDatabase 11g), но на любой поддерживаемой ОС.

Windows Clustering

У Microsoft существуют решения для реализации каждого из трех типов кластеров. В состав Windows Server 2008 R2 входят две технологии: Network Load Balancing (NLB) Cluster и Failover Cluster. Существует отдельная редакция Windows Server 2008 HPC Edition для организации высокопроизводительных вычислительных сред. Эта редакция лицензируется только для запуска HPC-приложений, то есть на таком сервере нельзя запускать базы данных, web- или почтовые сервера.

NLB-кластер используется для фильтрации и распределения TCP/IPтрафика между узлами. Такой тип кластера предназначен для работы с сетевыми приложениями — например, IIS, VPN или межсетевым экраном.

Могут возникать сложности с приложениями, которые полага ются на сессионные данные, при перенаправлении клиента на другой узел, на котором этих данных нет. В NLB-кластер можно включать до тридцати двух узлов на x64-редакциях, и до шестнадцати — на x86.

Failoverclustering — это кластеризации с переходом по отказу, хотя довольно часто термин переводят как «отказоустойчивые кластеры».

Узлы кластера объединены программно и физически с помощью LAN- или WAN-сети, для multi-site кластера в Windows Server 2008 убрано требование к общей задержке 500 мс, и добавлена возможность гибко настраивать heartbeat. В случае сбоя или планового отключения сервера кластеризованные ресурсы переносятся на другой узел. В Enterprise edition в кластер можно объединять до шестнадцати узлов, при этом пятнадцать из них будут простаивать до тех пор, пока не произойдет сбой. Приложения без поддержки кластеров (cluster-unaware) не взаимодействуют со службами кластера и могут быть переключены на другой узел только в случае аппаратного сбоя.

Приложения с поддержкой кластеров (cluster-aware), разработанные с использованием ClusterAPI, могут быть защищены от программных и аппаратных сбоев.

Развертывание failover-кластера

Процедуру установки кластера можно разделить на четыре этапа. На первом этапе необходимо сконфигурировать аппаратную часть, которая должна соответствовать The Microsoft Support Policy for Windows Server 2008 Failover Clusters. Все узлы кластера должны состоять из одинаковых или сходных компонентов. Все узлы кластера должны иметь доступ к хранилищу, созданному с использованием FibreChannel, iSCSI или Serial Attached SCSI. От хранилищ, работающих с Windows Server 2008, требуется поддержка persistent reservations.

На втором этапе на каждый узел требуется добавить компонент Failover Clustering — например, через Server Manager. Эту задачу можно выполнять с использованием учетной записи, обладающей административными правами на каждом узле. Серверы должны принадлежать к одному домену. Желательно, чтобы все узлы кластера были с одинаковой ролью, причем лучше использовать роль member server, так как роль domain controller чревата возможными проблемами с DNS и Exchange.

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

На четвертом этапе создается кластер. Для этого из Failover Cluster Management запускается мастер Create Cluster, в котором указываются серверы, включаемые в кластер, имя кластера и дополнительные настройки IP-адреса. Если серверы подключены к сетям, которые не будут использоваться для общения в рамках кластера (например, подключение только для обмена данными с хранилищем), то в свойствах этой сети в Failover Cluster Management необходимо установить параметр «Do not allow the cluster to use this network».

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

Для этого необходимо запустить High Availability Wizard, который можно найти в Services and Applications оснастки Failover Cluster Management.

Cluster Shared Volumes

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

Еще одна проблема, возникающая из-за того, что LUN является минимальной единицей обхода отказа, заключается в том, что при сбое одного приложения, находящегося на LUN, приходится переключать все приложения, которые хранятся на этом LUN, на другой сервер. Во всех приложениях (включая Hyper-V до второго релиза Server 2008) это удавалось обходить за счет многочисленных LUN, на каждом из которых хранились данные только одного приложения. В Server 2008 R2 появилось решение для этих проблем, но предназначенное для работы только с Hyper-V и CSV (Cluster Shared Volumes).

CSV позволяет размещать на общем хранилище виртуальные машины, запускаемые на разных узлах кластера — тем самым разбивается зависимость между ресурсами приложения (в данном случае виртуальными машинами) и дисковыми ресурсами. В качестве файловой системы CSV использует обычную NTFS. Для включения CSV необходимо в Failover Cluster Manage выполнить команду Enable Cluster Shared Volumes. Отключить поддержку CSV можно только через консоль:

Для использования этой команды должен быть загружен Failover Clusters, модуль PowerShell. Использование CSV совместно с live migration позволяет перемещать виртуальные машины между физическими серверами в считанные миллисекунды, без обрыва сетевых соединений и совершенно прозрачно для пользователей. Стоит отметить, что копировать любые данные (например, готовые виртуальные машины) на общие диски, использующие CSV, следует через узел-координатор.

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

Oracle RAC

Oracle Real Application Clusters (RAC) — это дополнительная опция Oracle Database, которая впервые появилась в Oracle Database 9i под названием OPS (Oracle Parallel Server). Опция предоставляет возможность нескольким экземплярам совместно обращаться к одной базе данных. Базой данных в Oracle Database называет ся совокупность файлов данных, журнальных файлов, файлов параметров и некоторых других типов файлов. Для того, чтобы пользовательские процессы могли получить доступ к этим данным, должен быть запущен экземпляр. Экземпляр (instance) в свою очередь состоит из структур памяти (SGA) и фоновых процессов. В отсутствии RAC получить доступ к базе данных может строго один экземпляр.

Опция RAC не поставляется с Enterprise Edition и приобретается отдельно. Стоит отметить, что при этом RAC идет в составе Standard Edition, но данная редакция обладает большим количеством ограничений по сравнению с Enterprise Edition, что ставит под сомнение целесообразность ее использования.

Oracle Grid Infrastructure

Для работы Oracle RAC требуется Oracle Clusterware (или стороннее ПО) для объединения серверов в кластер. Для более гибкого управления ресурсами узлы такого кластера могут быть организованы в пулы (с версии 11g R2 поддерживается два варианта управления — на основании политик для пулов или, в случае их отсутствия, администратором).

Во втором релизе 11g Oracle Clusterware был объединен с ASM под общим названием Oracle Grid Infrastructure, хотя оба компонента и продолжают устанавливаться по различным путям.

Automatic Storage Management (ASM) — менеджер томов и файловая система, которые могут работать как в кластере, так и с singleinstance базой данных. ASM разбивает файлы на ASM Allocation Unit.

Размер Allocation Unit определяется параметром AU_SIZE, который задается на уровне дисковой группы и составляет 1, 2, 4, 8, 16, 32 или 64 MB. Далее Allocation Units распределяются по ASM-дискам для балансировки нагрузки или зеркалирования. Избыточность может быть реализована, как средствами ASM, так и аппаратно.

ASM-диски могут быть объединены в Failure Group (то есть группу дисков, которые могут выйти из строя одновременно — например, диски, подсоединенные к одному контролеру), при этом зеркалирование осуществляется на диски, принадлежащие разным Failure Group. При добавлении или удалении дисков ASM автоматически осуществляет разбалансировку, скорость которой задается администратором.

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

Oracle рекомендует использовать ASM в качестве решения для управления хранением данных вместо традиционных менеджеров томов, файловых систем или RAW-устройств.

Развертывание Oracle RAC

Рассмотрим этапы установки различных компонентов, необходимых для функционирования Oracle RAC в режиме active/active кластера с двумя узлами. В качестве дистрибутива будем рассматривать последнюю на момент написания статьи версию Oracle Database 11g Release 2. В качестве операционной системы возьмем Oracle Enterprise Linux 5. Oracle Enterprise Linux — операционная система, базирующаяся на RedHat Enterprise Linux. Ее основные отличия — цена лицензии, техническая поддержка от Oracle и дополнительные пакеты, которые могут использоваться приложениями Oracle.

Подготовка ОС к установке Oracle стандартна и заключается в создании пользователей и групп, задании переменных окружения и параметров ядра. Параметры для конкретной версии ОС и БД можно найти в Installation Guide, который поставляется вместе с дистрибутивом.

На узлах должен быть настроен доступ к внешним общим дискам, на которых будут храниться файлы базы данных и файлы Oracle Clusterware. К последним относятся votingdisk (файл, определяющий участников кластера) и Oracle Cluster Registry (содержит конфигурационную информацию — например, какие экземпляры и сервисы запущены на конкретном узле). Рекомендуется создавать нечетное количество votingdisk. Для создания и настройки ASMдисков желательно использовать ASMLib, которую надо установить на всех узлах:

Кроме интерфейса для взаимодействия с хранилищем на узлах желательно настроить три сети — Interconnect, External и Backup.
Необходимо настроить IP-адресацию (вручную или с использованием Oracl e GNS) и DNS для разрешения всех имен (или только GNS).

Вначале осуществляется установка Grid Infrastructure. Для этого загружаем и распаковываем дистрибутив, затем запускаем установщик. В процессе установки необходимо указать имя кластера; указать узлы, которые будут входить в кластер; указать назначение сетевых интерфейсов; настроить хранилище.

В конце нужно выполнить с правами root скрипты orainstRoot.sh и root.sh. Первым на всех узлах выполняется скрипт orainstRoot.sh, причем запуск на следующем узле осуществляется только после завершения работы скрипта на предыдущем. После выполнения orainstRoot.sh последовательно на каждом узле выполняется root.sh. Проверить успешность установки можно с помощью команды:

/u01/grid/bin/crsctl check cluster –all

Выполнив проверку, можно приступать к установке базы данных. Для этого запускаем Oracle Universal installer, который используется и для обычной установки базы.

Кроме active/active-кластера в версии 11g R2 существуют две возможности для создания active/passive-кластера. Одна из них — Oracle RACOneNode. Другой вариант не требует лицензии для RAC и реализуется средствами Oracle Clusterware. В этом случае вначале создается общее хранилище; затем устанавливается Grid Infrastructure, с использованием ASM_CRS и SCAN; а после этого на узлы устанавливается база данных в варианте Standalone. Далее создаются ресурсы и скрипты, которые позволяют запускать экземпляр на другом узле в случае недоступности первого.

Заключение

Oracle RAC совместно с Oracle Grid Infrastructure позволяют реализовать разнообразные сценарии построения кластеров. Гибкость настройки и широта возможностей компенсируются ценой такого решения.

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

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