На кластер: Прием кластер на уроке. Что это такое и как его использовать? Примеры — Критическое мышление — Преподавание — Образование, воспитание и обучение

Кластерные системы / Блог компании Parking.ru / Хабр

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

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

Parking.ru запустил целый ряд кластерных решений построенных на надежной дублированной инфраструктуре и имеющих в основе самые разные решения: от виртуальных машин до группы физических серверов. Отдельного внимания заслуживает предложение по ГЕО кластеризации в двух разных ЦОД, объединенных дублированными каналами связи.

Если рассматривать вкратце, то в рамках предложения существуют следующие типовые схемы кластеров:

Кластеры высокой доступности (High Availability cluster)

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

Обычно High Availability кластер строится для Microsoft SQL server’ов, который поддерживает базы данных интернет проектов. High Availability кластер возможно построить и для Exchange систем.

Существует ещё одна разновидность High Availability SQL кластера — «зеркалирование БД» или database mirroring. Этот вид кластера не требует выделенного дискового хранилища, но для автоматического переключения в случае аварии нужен ещё один SQL сервер — следящий/witness. Такой кластер идеально подходит для WEB приложений и требует меньше затрат на создание.

Балансировка нагрузки (Network Load Balancing, NLB)

Принцип действия NLB-кластеров — распределение приходящих запросов на несколько физических или виртуальных узлов серверов. Первоначальная цель такого кластера — производительность, однако, они используются также для повышения надёжности, поскольку выход из строя одного узла приведет просто к равномерному увеличению загрузки остальных узлов. Совокупность узлов кластера часто называют кластерной фермой. Минимальное количество узлов в ферме — два. Максимальное — 32.

При размещении высоконагруженных web-проектов в режиме NLB строится ферма web-серверов на IIS 7.х

Кластеры на виртуальных машинах

Наиболее доступным и масштабируемым решением является построение кластера на основе виртуальных машин на платформе Hyper-V.

В качестве web-боксов NLB-кластера используются виртуальные машины с установленными на них Windows Web Server 2008 (IIS7.х, пользовательское приложение).

В качестве кластера баз данных используется две виртуальные машины необходимой мощности на Windows Server 2008 Standard Edition и SQL Server 2008 Standard Edition.

Отказоустойчивое единое хранилище данных на основе Storage System от NetApp или HP.

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

Масштабируемость решения достигается путем увеличения мощности используемых виртуальных машин (вплоть до 100% мощности физического сервера), а также за счет добавления новых узлов в NLB-кластер.

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

Данный кластер является лучшим решением в соотношении цена/качество и рекомендуется как для критичных для бизнеса приложений, так и для относительно нагруженных web-проектов (~до 30000-50000 посетителей ежедневно).

Кластеры на физических серверах

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

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

Геокластеры

При построении локальных кластеров единой точкой отказа системы является сама инфраструктура ЦОД. Parking.ru предлагает уникальное решение на российском рынке — построение географически распределенного кластера, узлы которого располагаются в разных ЦОДах Parking.ru.

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

Stratus, VMware, VMmanager Cloud / Блог компании ISPsystem / Хабр

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

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

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

• Отказоустойчивость (Fault Tolerance, FT) — способность системы к дальнейшей работе после выхода из строя какого-либо её элемента.
• Кластер — группа серверов (вычислительных единиц), объединенных каналами связи.
• Отказоустойчивый кластер (Fault Tolerant Cluster, FTC) — кластер, отказ сервера в котором не приводит к полной неработоспособности всего кластера. Задачи вышедшей из строя машины распределяются между одной или несколькими оставшимися нодами в автоматическом режиме.
• Непрерывная доступность (Continuous Availability, CA) — пользователь может в любой момент воспользоваться сервисом, перерывов в предоставлении не происходит. Сколько времени прошло с момента отказа узла не имеет значения.
• Высокая доступность (High Availability, HA) — в случае выхода из строя узла пользователь какое-то время не будет получать услугу, однако восстановление системы произойдёт автоматически; время простоя минимизируется.
• КНД — кластер непрерывной доступности, CA-кластер.
• КВД — кластер высокой доступности, HA-кластер.

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

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

Бесперебойное обслуживание клиента возможно только в случае наличия в любой момент времени точной копии сервера (физического или виртуального), на котором запущен сервис. Если создавать копию уже после отказа оборудования, то на это потребуется время, а значит, будет перебой в предоставлении услуги. Кроме этого, после поломки невозможно будет получить содержимое оперативной памяти с проблемной машины, а значит находившаяся там информация будет потеряна.
Для реализации CA существует два способа: аппаратный и программный. Расскажем о каждом из них чуть подробнее.

Аппаратный способ представляет собой “раздвоенный” сервер: все компоненты дублированы, а вычисления выполняются одновременно и независимо. За синхронность отвечает узел, который в числе прочего сверяет результаты с половинок. В случае несоответствия выполняется поиск причины и попытка коррекции ошибки. Если ошибка не корректируется, то неисправный модуль отключается.

На Хабре недавно была статья на тему аппаратных CA-серверов. Описываемый в материале производитель гарантирует, что годовое время простоя не более 32 секунд. Так вот, для того чтобы добиться таких результатов, надо приобрести оборудование. Российский партнёр компании Stratus сообщил, что стоимость CA-сервера с двумя процессорами на каждый синхронизированный модуль составляет порядка $160 000 в зависимости от комплектации. Итого на кластер потребуется $1 600 000.

Программный способ.

На момент написания статьи самый популярный инструмент для развёртывания кластера непрерывной доступности — vSphere от VMware. Технология обеспечения Continuous Availability в этом продукте имеет название “Fault Tolerance”.

В отличие от аппаратного способа данный вариант имеет ограничения в использовании. Перечислим основные:

• На физическом хосте должен быть процессор:
  • Intel архитектуры Sandy Bridge (или новее). Avoton не поддерживается.
  • AMD Bulldozer (или новее).

• Машины, на которых используется Fault Tolerance, должны быть объединены в 10-гигабитную сеть с низкими задержками. Компания VMware настоятельно рекомендует выделенную сеть.
• Не более 4 виртуальных процессоров на ВМ.
• Не более 8 виртуальных процессоров на физический хост.
• Не более 4 виртуальных машин на физический хост.
• Невозможно использовать снэпшоты виртуальных машин.
• Невозможно использовать Storage vMotion.

Полный список ограничений и несовместимостей есть в официальной документации.
Экспериментально установлено, что технология Fault Tolerance от VMware значительно “тормозит” виртуальную машину. В ходе исследования vmgu.ru после включения FT производительность ВМ при работе с базой данных упала на 47%.

Лицензирование vSphere привязано к физическим процессорам. Цена начинается с $1750 за лицензию + $550 за годовую подписку и техподдержку. Также для автоматизации управления кластером требуется приобрести VMware vCenter Server, который стоит от $8000. Поскольку для обеспечения непрерывной доступности используется схема 2N, для того чтобы работали 10 нод с виртуальными машинами, нужно дополнительно приобрести 10 дублирующих серверов и лицензии к ним. Итого стоимость программной части кластера составит 2*(10+10)*(1750+550)+8000=$100 000.

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

Стоит упомянуть и о тех продуктах, разработка которых остановилась.

Есть Remus на базе Xen, бесплатное решение с открытым исходным кодом. Проект использует технологию микроснэпшотов. К сожалению, документация давно не обновлялась; например, установка описана для Ubuntu 12.10, поддержка которой прекращена в 2014 году. И как ни странно, даже Гугл не нашёл ни одной компании, применившей Remus в своей деятельности.

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

Первый — Kemari, продукт с открытым исходным кодом, которым руководит Yoshiaki Tamura. Предполагается использовать механизмы живой миграции QEMU. Однако тот факт, что последний коммит был сделан в феврале 2011 года говорит о том, что скорее всего разработка зашла в тупик и не возобновится.

Второй — Micro Checkpointing, основанный Michael Hines, тоже open source. К сожалению, уже год в репозитории нет никакой активности. Похоже, что ситуация сложилась аналогично проекту Kemari.

Таким образом, реализации continuous availability на базе виртуализации KVM в данный момент нет.

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

В контексте КВД отказоустойчивость обеспечивается за счёт автоматического определения отказа оборудования и последующего запуска сервиса на исправном узле кластера.

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

Таким образом, кластер высокой доступности делится на два подкластера:

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

На данный момент для реализации КВД с виртуальными машинами на нодах есть следующие инструменты:

• Heartbeat версии 1.х в связке с DRBD;
• Pacemaker;
• VMware vSphere;
• Proxmox VE;
• XenServer;
• Openstack;
• oVirt;
• Red Hat Enterprise Virtualization;
• Windows Server Failover Clustering в связке с серверной ролью “Hyper-V”;
• VMmanager Cloud.

Познакомим вас с особенностями нашего продукта VMmanager Cloud.
Наше решение VMmanager Cloud использует виртуализацию QEMU-KVM. Мы сделали выбор в пользу этой технологии, поскольку она активно разрабатывается и поддерживается, а также позволяет установить любую операционную систему на виртуальную машину. В качестве инструмента для выявления отказов в кластере используется Corosync. Если выходит из строя один из серверов, VMmanager поочерёдно распределяет работавшие на нём виртуальные машины по оставшимся нодам.

В упрощённой форме алгоритм такой:

1. Происходит поиск узла кластера с наименьшим количеством виртуальных машин.
2. Выполняется запрос хватает ли свободной оперативной памяти для размещения текущей ВМ в списке.
3. Если памяти для распределяемой машины достаточно, то VMmanager отдаёт команду на создание виртуальной машины на этом узле.
4. Если памяти не хватает, то выполняется поиск на серверах, которые несут на себе большее количество виртуальных машин.

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

Практика показывает, что лучше выделить одну или несколько нод под аварийные ситуации и не развёртывать на них ВМ в период штатной работы. Такой подход исключает ситуацию, когда на “живых” нодах в кластере не хватает ресурсов, чтобы разместить все виртуальные машины с “умершей”. В случае с одним запасным сервером схема резервирования носит название “N+1”.

VMmanager Cloud поддерживает следующие типы хранилищ: файловая система, LVM, Network LVM, iSCSI и Ceph. В контексте КВД используются последние три.

При использовании вечной лицензии стоимость программной части кластера из десяти “боевых” узлов и одного резервного составит €3520 или $3865 на сегодняшний день (лицензия стоит €320 за ноду независимо от количества процессоров на ней). В лицензию входит год бесплатных обновлений, а со второго года они будут предоставляться в рамках пакета обновлений стоимостью €880 в год за весь кластер.

Рассмотрим по каким схемам пользователи VMmanager Cloud реализовывали кластеры высокой доступности.

Компания FirstByte начала предоставлять облачный хостинг в феврале 2016 года. Изначально кластер работал под управлением OpenStack. Однако отсутствие доступных специалистов по этой системе (как по наличию так и по цене) побудило к поиску другого решения. К новому инструменту для управления КВД предъявлялись следующие требования:

1. Возможность предоставления виртуальных машин на KVM;
2. Наличие интеграции с Ceph;
3. Наличие интеграции с биллингом подходящим для предоставления имеющихся услуг;
4. Доступная стоимость лицензий;
5. Наличие поддержки производителя.

В итоге лучше всего по требованиям подошел VMmanager Cloud.

Отличительные черты кластера:

• Передача данных основана на технологии Ethernet и построена на оборудовании Cisco.
• За маршрутизацию отвечает Cisco ASR9001; в кластере используется порядка 50000 IPv6 адресов.
• Скорость линка между вычислительными нодами и коммутаторами 10 Гбит/с.
• Между коммутаторами и нодами хранилища скорость обмена данными 20 Гбит/с, используется агрегирование двух каналов по 10 Гбит/с.
• Между стойками с нодами хранилища есть отдельный 20-гигабитный линк, используемый для репликации.
• В узлах хранилища установлены SAS-диски в связке с SSD-накопителями.
• Тип хранилища — Ceph.

В общем виде система выглядит так:

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

Компания FirstVDS предоставляет услуги отказоустойчивого хостинга, запуск продукта состоялся в сентябре 2015 года.

К использованию VMmanager Cloud компания пришла из следующих соображений:

1. Большой опыт работы с продуктами ISPsystem.
2. Наличие интеграции с BILLmanager по умолчанию.
3. Отличное качество техподдержки продуктов.
4. Поддержка Ceph.

Кластер имеет следующие особенности:

• Передача данных основана на сети Infiniband со скоростью соединения 56 Гбит/с;
• Infiniband-сеть построена на оборудовании Mellanox;
• В узлах хранилища установлены SSD-носители;
• Используемый тип хранилища — Ceph.

Общая схема выглядит так:

В случае общего отказа Infiniband-сети связь между хранилищем дисков ВМ и вычислительными серверами выполняется через Ethernet-сеть, которая развёрнута на оборудовании Juniper. “Подхват” происходит автоматически.

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

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

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

Кроме этого не можем не напомнить, что единственное средство повышения отказоустойчивости — избыточность. Обеспечив резервирование серверов, не забудьте зарезервировать линии и оборудование передачи данных, каналы доступа в Интернет, электропитание. Всё что только можно зарезервировать — резервируйте. Такие меры исключают единую точку отказа, тонкое место, из-за неисправности в котором прекращает работать вся система. Приняв все вышеописанные меры, вы получите отказоустойчивый кластер, который действительно трудно вывести из строя.

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

P. S. Если у вас в организации есть аппаратные CA-серверы — напишите, пожалуйста, в комментариях кто вы и для чего вы их используете. Нам действительно интересно услышать для каких проектов использование такого оборудование экономически целесообразно 🙂

Эффективные кластерные решения

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

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

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

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

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

• LAN — Local Area Network, локальная сеть
• SAN — Storage Area Network, сеть хранения данных

Впервые в классификации вычислительных систем термин «кластер» определила компания Digital Equipment Corporation (DEC).

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

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

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

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

1. Высокая готовность
2. Высокое быстродействие
3. Масштабирование
4. Общий доступ к ресурсам
5. Удобство обслуживания

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

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

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

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

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

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

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

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

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

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

и много других…

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

• биллинговые системы
• банковские операции
• электронная коммерция
• управление предприятием, и т.п….

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

Проблематика High Performance кластеров

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

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

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

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

Быстродействие интерфейсов характеризуется двумя параметрами: пропускной способностью непрерывного потока даных и максимальным количеством самых маленьких пакетов, которые можно передать за единицу времени. Варианты реализаций коммуникационных интерфейсов мы рассмотрим в разделе «Средства реализации High Performance кластеров».

Проблематика High Availability кластерных систем

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

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

При построении систем высокой готовности, главная цель — обеспечить минимальное время простоя.

Для того, чтобы система обладала высокими показатели готовности, необходимо:

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

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

Давайте коротко пройдемся по всем трём пунктам.

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

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

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

Смешанные архитектуры

Рисунок 7. Высокоскоростной отказоустойчивый кластер

Сегодня часто можно встретить смешанные кластерные архитектуры, которые одновременно являются как системами высокой готовности, так и высокоскоростными кластерными архитектурами, в которых прикладные задачи распределяются по узлам системы. Наличие отказоустойчивого комплекса, увеличение быстродействия которого осуществляется путем добавления нового узла, считается самым оптимальным решением при построении вычислительной системы. Но сама схема построения таких смешанных кластерных архитектур приводит к необходимости объединения большого количества дорогих компонент для обеспечения высокого быстродействия и резервирования одновременно. И так как в High Performance кластерной системе наиболее дорогим компонентом является система высокоскоростных коммуникаций, ее дублирование приведет к значительным финансовым затратам. Следует отметить, что системы высокой готовности часто используются для OLTP задач, которые оптимально функционируют на симметричных мультипроцессорных системах. Реализации таких кластерных систем часто ограничиваются 2-х узловыми вариантами, ориентированными в первую очередь на обеспечение высокой готовности. Но в последнее время использование недорогих систем количеством более двух в качестве компонент для построения смешанных HA/HP кластерных систем становится популярным решением.

Что подтверждает, в частности, информация агентства The Register, опубликованная на его страничке:

«Председатель корпорации Oracle объявил о том, что в ближайшее время три Unіх сервера, на которых работает основная масса бизнес-приложений компании, будут заменены на блок серверов на базе процессоров Іntеl под управлением ОС Lіnuх. Ларри Эллисон настаивает на том, что введение поддержки кластеров при работе с приложениями и базами данных снижает затраты и повышает отказоустойчивость.»

Средства реализации High Performance кластеров

Самыми популярными сегодня коммуникационными технологиями для построения суперкомпьютеров на базе кластерных архитектур являются:

Myrinet, Virtual Interface Architecture (cLAN компании Giganet — одна из первых коммерческих аппаратных реализаций), SCI (Scalable Coherent Interface), QsNet (Quadrics Supercomputers World), Memory Channel (разработка Compaq Computer и Encore Computer Corp), а также хорошо всем известные Fast Ethertnet и Gigabit Ethernet.

Рисунок 8. Скорость передачи непрерывного потока данных

Рисунок 9. Время передачи пакета нулевой длинны

Эти диаграммы (Рис. 8 и 9) дают возможность увидеть быстродействие аппаратных реализаций разных технологий, но следует помнить, что на реальных задачах и при использовании разнообразных аппаратных платформ параметры задержки и скорости передачи данных получаются на 20-40%, а иногда на все 100% хуже, чем максимально возможные.

Например, при использовании библиотек MPI для коммуникационных карточек cLAN и Intel Based серверов с шиной PCI, реальная пропускная способность канала составляет 80-100 MByte/sec, задержка — около 20 мксек.

Одной из проблем, которые возникают при использовании скоростных интерфейсов, например, таких как SCI является то, что архитектура PCI не подходит для работы с высокоскоростными устройствами такого типа. Но если перепроектировать PCI Bridge с ориентацией на одно устройство передачи данных, то эта проблема решается. Такие реализации имеют место в решениях некоторых производителей, например, компании SUN Microsystems.

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

Таблица 1. Сравнение высокоскоростных коммуникационных интерфейсов

^* аппаратура SCI (и программное обеспечение поддержки) допускает построение так называемых MASH топологий без использования коммутаторов

^** нет данных

Рисунок 10. Тесно связанная мультипроцессорная система с несимметричным доступом к памяти

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

Средства распараллеливания

Существует несколько разных подходов к программированию параллельных вычислительных систем:

• на стандартных широко распространенных языках программирования с использованием коммуникационных библиотек и интерфейсов для организации межпроцессорного взаимодействия (PVM, MPI, HPVM, MPL, OpenMP, ShMem)
• использование специализированных языков параллельного программирования и параллельных расширений (параллельные реализации Fortran и C/C++, ADA, Modula-3)
• использование средств автоматического и полуавтоматического распараллеливания последовательных программ (BERT 77, FORGE, KAP, PIPS, VAST)
• программирование на стандартных языках с использованием параллельных процедур из специализированных библиотек, которые ориентированы на решение задач в конкретных областях, например: линейной алгебры, методов Монте-Карло, генетических алгоритмов, обработки изображений, молекулярной химии, и т.п. (ATLAS, DOUG, GALOPPS, NAMD, ScaLAPACK).

Существует также немало инструментальных средств, которые упрощают проектирование параллельных программ. Например:

• CODE — Графическая система для создания параллельных программ. Параллельная программа изображается в виде графа, вершины которого есть последовательные части программы. Для передачи сообщений используются PVM и MPI библиотеки.
• TRAPPER — Коммерческий продукт немецкой компании Genias. Графическая среда программирования, которая содержит компоненты построения параллельного программного обеспечения.

По опыту пользователей высокоскоростных кластерных систем, наиболее эффективно работают программы, специально написанные с учетом необходимости межпроцессорного взаимодействия. И даже несмотря на то, что программировать на пакетах, которые используют shared memory interface или средства автоматического распараллеливания, значительно удобней, больше всего распространены сегодня библиотеки MPI и PVM.

Учитывая массовою популярность MPI (The Message Passing Interface), хочется немного о нём рассказать.

«Интерфейс передачи сообщений» — это стандарт, который используется для построения параллельных программ и использует модель обмена сообщениями. Существуют реализации MPI для языка C/C++ и Fortran как в бесплатных, так и коммерческих вариантах для большинства распространенных суперкомпьютерных платформ, в том числе High Performance кластерных систем, построенных на узлах с ОС Unix, Linux и Windows. За стандартизацию MPI отвечает MPI Forum (http://www.mpi-forum.org). В новой версии стандарта 2.0 описано большое число новых интересных механизмов и процедур для организации функционирования параллельных программ: динамическое управление процессами, односторонние коммуникации (Put/Get), параллельные I/O. Но к сожалению, пока нет полных готовых реализаций этой версии стандарта, хотя часть из нововведений уже активно используется.

Для оценки функциональности MPI, хочу представить вашему вниманию график зависимости времени вычисления задачи решения систем линейных уравнений в зависимости от количества задействованных процессоров в кластере. Кластер построен на процессорах Intel и системе межузловых соединений SCI (Scalable Coherent Interface). Естественно, задача частная, и не надо понимать полученные результаты как общую модель прогнозирования быстродействия желаемой системы.

Рисунок 11. Зависимость времени вычисления задачи решения систем линейных уравнений в зависимости от количества задействованных процессоров в кластере

На графике отображены две кривые, синяя — линейное ускорение и красная — полученное в результате эксперимента. То есть, в результате использования каждой новой ноды мы получаем ускорение выше, чем линейное. Автор эксперимента утверждает, что такие результаты получаются из-за более эффективного использования кэш памяти, что вполне логично и объяснимо. Если у кого возникнут мысли и идеи по этому поводу, буду благодарен, если вы ими поделитесь (мой e-mail: [email protected]).

Средства реализации High Availability кластеров

High Availability кластеры можно распределить на:

• Shared Nothing Architecture (архитектура без разделения ресурсов)
• Shared Disk Architecture (архитектура с общими дисками)

Рисунок 12. Архитектура без разделения ресурсов

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

Рисунок 13. Архитектура с общими дисками

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

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

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

Рисунок 14. Гетерогенная кластерная система

Самыми популярными коммерческими системами сегодня являются двухузловые отказоустойчивые кластеры. Различают Активный-Активный (Active-Active) и Активный-Пассивный (Active-Passive) модели реализации отказоустойчивых кластерных систем в отношении распределения програмных ресурсов.

Рисунок 15. Модель Активный-Активный

В модели Активный-Активный мы практически получаем вместе с отказоустойчивым решением — решение высокоскоростное, так как одна задача работает на нескольких серверах одновременно. Такой вариант реализован, например, в Oracle Prallel Server, MS SQL 2000, IBM DB2. То есть, реализация такой модели возможна лишь в случае написания прикладного программного обеспечения с ориентацией на функционирование в кластерном режиме (исключение составляют кластерные системы с разделением оперативной памяти). В модели Активный-Активный возможно масштабирование скорости работы задачи путем добавления нового узла, если конечно программным обеспечением поддерживается необходимое количество нод. Например, Oracle Parallel Server 8.0.5 поддерживает работу на кластере от 2-х до 6-ти узлов.

Рисунок 16. Активный-Активный кластер на 3-х узлах

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

Рисунок 17. Модель Активный-Пассивный

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

Рисунок 18. Псевдо Активный-Активный кластер на 3-х узлах

Если вам нужно обеспечить отказоустойчивую работу нескольких программных ресурсов, то достаточно добавить в систему новый узел и запустить на кластере нужные вам задачи, которые в случае отказа этого узла перейдут на выполнение на другом узле. Такая модель реализована в программном обеспечении ReliantHA для ОС Caldera OpenUnix и Unixware, которое поддерживает кластеризацию от 2-х к 4-х узлам, в MSCS (Microsoft Cluster Service) и Linux Failover Cluster модели.

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

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

Рисунок 19. Архитектура с общей SCSI шиной

или с помощью автономной дисковой подсистемы со встроенным контролером SCSI to SCSI. В последнем случае диски подключаются ко внутренним независимым каналам дисковой подсистемы.

Рисунок 20. Вариант с использованием SCSI to SCSI дисковой подсистемы

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

В последнее время начинает приобретать популярность новый последовательный интерфейс для протокола SCSI — FC (Fibre Channel). На базе FC строятся так называемые сети хранения данных — SAN (Storage Area Network).

Рисунок 21. Кластерная система с использованием SAN на базе Fibre Channel

К основным преимуществам Fibre Channel можно отнести практически все его особенности.

• Высокие скорости передачи данных
• Протоколо-независимость (0-3 уровни)
• Большие расстояния между точками
• Низкие задержки при передаче коротких пакетов
• Высокая надежность передачи данных
• Практически неограниченное масштабирование
• Многоточечные топологии

Эти замечательные особенности Fibre Channel получил благодоря тому, что в его проектировании принимали участие специалисты в областях как канальных, так и сетевых интерфейсов, причем им удалось объединить в одном FC интерфейсе положительные черты обоих.

Для понимания значимости FC я приведу сравнительную табличку FC и параллельного SCSI интерфейса.

Таблица 2. Таблица сравнительных характеристик FC и параллельного SCSI интерфейса

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

Существует еще один очень интересный вариант реализации кластерной архитектуры — кластерная система с разделяемой памятью (в т.ч. оперативной) Shared Memory Cluster. Фактически этот кластер может функционировать как в модели умеренно связанной многопроцессорной системы, так и тесно связанной. Такая система, как уже говорилось в начале статьи, называется NUMA.

Рисунок 22. Модель кластера с разделяемой памятью

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

В завершение рассказа о кластерных системах высокой готовности, хочу привести статистику по простоям различных систем.

Рисунок 23. Сравнение среднего времени простоя различных систем

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

Как видим, кластерные системы высокой готовности не являются панацеей при минимизации простоев. Если простой системы является чрезвычайно критичным, тогда следует использовать системы класса Fault Tolerant или Continuous Availability, системы такого класса имеют коэффициент готовности на порядок выше, чем системы класса High Availability.

Примеры проверенных решений

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

Сперва о высокоскоростных кластерах.

Одним из наиболее полезных, на мой взгляд, примеров является то, что первые места, да и вообще большинство мест 18-й редакции списка самых мощных суперкомпьютеров мира занимают системы IBM SP2 и Compaq AlphaServer SC. Обе системы являются массивно-параллельными вычислительными системами (MPP), которые структурно аналогичны High Performance кластерным решениям.

В IBM SP2 в качестве узлов используются машины RS/6000, соединенные коммутатором SP Switch3. Пропускная способность коммутатора — 500MB/s в одном направлении, величина задержки — 2.5 мксек.

Compaq AlphaServer SC. Узлы — 4-х процессорные системы типа Compaq AlphaServer ES45, соединенные с помощью коммуникационного интерфейса QsNet, параметры которого упоминались выше.

В том же суперкомпьютерном списке находятся машины, построенные на обычных Intel платформах и коммутаторах SCI и Myrinet и даже обычном Fast и Gigabit Ethernet. Причем как в первых двух вариантах, так и на высокоскоростных кластерных системах, построенных на рядовом оборудовании, для програмирования используются пакеты MPI.

Ну и напоследок хочется привести красивый пример масштабируемой кластерной системы высокой готовности. Аппаратная модель кластерного решения для отказоустойчивой высокоскоростной обработки базы данных IBM DB/2.

Рисунок 24. Кластер IBM DB2

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

Литература

• «Sizing Up Parallel Architectures», — Greg Pfister, старший технический специалист компании IBM.
• «Возможна ли отказоустойчивость для Windows?», — Наталья Пирогова, материалы издательства «Открытые системы».
• «Использование систем распараллеливания задач в слабосвязанном кластере», — М.Н.Иванов.
• «Отказоустойчивые компьютеры компании Stratus», — Виктор Шнитман, материалы издательства «Открытые системы».
• «Современные высокопроизводительные компьютеры», — В. Шнитман, информационно-аналитические материалы Центра Информационных Технологий.
• «Шаг к сетям хранения данных», информационно-аналитические материалы компании ЮСТАР.
• «Эволюция архитектуры виртуального интерфейса», — Торстен фон Айкен, Вернер Фогельс, материалы издательства «Открытые системы».
• Материалы Лаборатории Параллельных Информационных Технологий «НИВЦ МГУ».
• Материалы Cluster Computing Info Centre.
• Материалы SCI Europe.
• Материалы VI Forum (Virtual Architecture Developers Forum).
• Материалы компании Caldera.
• Материалы компании Dolphinics.
• Материалы компании Emulex.
• Материалы компании KAI Software, a Division of Intel Americas, Inc. (KAI).
• Материалы компании Myricom, Inc.
• Материалы компании Oracle.
• Рекомендации технической поддержки корпорации Intel.

Кластер Hyper-v из двух нод, без внешнего хранилища или гиперконвергенция на коленке

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

Однако недавно я наткнулся на статью Romain Serre в которой эта проблема как раз решалась с помощью Windows Server 2016 и новой функции которая присутствует в нем — Storage Spaces Direct (S2D). Картинку я как раз позаимствовал из этой статьи, поскольку она показалась очень уместной.

Технология Storage Spaces Direct уже неоднократно рассматривалась на Хабре. Но как-то прошла мимо меня, и я не думал, что можно её применять в «народном хозяйстве». Однако это именно та технология, которая позволяет собрать кластер из двух нод, создав при этом единое общее хранилище между серверами. Некий единый рейд из дисков, которые находятся на разных серверах. Причем выход одного из дисков или целого сервера не должны привести к потере данных.

Звучит заманчиво и мне было интересно узнать, как это работает. Однако двух серверов для тестов у меня нет, поэтому я решил сделать кластер в виртуальной среде. Благо и вложенная виртуализация в hyper-v недавно появилась.

Для своих экспериментов я создал 3 виртуальные машины. На первой виртуальной машине я установил Server 2016 с GUI, на котором я поднял контроллер AD и установил средства удаленного администрирования сервера RSAT. На виртуальные машины для нод кластера я установил Server 2016 в режиме ядра. В этом месяце загадочный Project Honolulu, превратился в релиз Windows Admin Center и мне также было интересно посмотреть насколько удобно будет администрировать сервера в режиме ядра. Четвертная виртуальная машина должна будет работать внутри кластера hyper-v на втором уровне виртуализации.

Для работы кластера и службы Storage Spaces Direct необходим Windows Server Datacenter 2016. Отдельно стоит обратить внимание на аппаратные требования для Storage Spaces Direct. Сетевые адаптеры между узлами кластера должны быть >10ГБ с поддержкой удаленного прямого доступа к памяти (RDMA). Количество дисков для объединения в пул – минимум 4 (без учета дисков под операционную систему). Поддерживаются NVMe, SATA, SAS. Работа с дисками через RAID контроллеры не поддерживается. Более подробно о требованиях docs.microsoft.com

Если вы, как и я, никогда не работали со вложенной виртуализацией hyper-v, то в ней есть несколько нюансов. Во-первых, по умолчанию на новых виртуальных машинах она отключена. Если вы захотите в виртуальной машине включить роль hyper-v, то получите ошибку, о том, что оборудование не поддерживает данную роль. Во-вторых, у вложенной виртуальной машины (на втором уровне виртуализации) не будет доступа к сети. Для организации доступа необходимо либо настраивать nat, либо включать спуфинг для сетевого адаптера. Третий нюанс, для создания нод кластера, нельзя использовать динамическую память. Подробнее по ссылке.

Поэтому я создал две виртуальные машины – node1, node2 и сразу отключил динамическую память. Затем необходимо включить поддержку вложенной виртуализации:

Set-VMProcessor -VMName node1,node2 -ExposeVirtualizationExtensions $true

Включаем поддержку спуфинга на сетевых адаптерах ВМ:

Get-VMNetworkAdapter -VMName node1,node2 | Set-VMNetworkAdapter -MacAddressSpoofing On

HDD10 и HDD 20 я использовал как системные разделы на нодах. Остальные диски я добавил для общего хранилища и не размечал их.

Сетевой интерфейс Net1 у меня настроен на работу с внешней сетью и подключению к контроллеру домена. Интерфейс Net2 настроен на работу внутренней сети, только между нодами кластера.

Для сокращения изложения, я опущу действия необходимые для того, чтобы добавить ноды к домену и настройку сетевых интерфейсов. С помощью консольной утилиты sconfig это не составит большого труда. Уточню только, что установил Windows Admin Center с помощью скрипта:

msiexec /i "C:\WindowsAdminCenter1804.msi" /qn /L*v log.txt SME_PORT=6515 SSL_CERTIFICATE_OPTION=generate

По сети из расшаренной папки установка Admin Center не прошла. Поэтому пришлось включать службу File Server Role и копировать инсталлятор на каждый сервер, как в мс собственно и рекомендуют.

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

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

$Servers = "node1","node2"
$ServerRoles = "Data-Center-Bridging","Failover-Clustering","Hyper-V","RSAT-Clustering-PowerShell","Hyper-V-PowerShell","FS-FileServer"

foreach ($server in $servers){
    Install-WindowsFeature –Computername $server –Name $ServerRoles} 

И перегружаю сервера после установки.

Запускаем тест для проверки готовности нод:

Test-Cluster –Node "node1","node2" –Include "Storage Spaces Direct", "Inventory", "Network", "System Configuration

Отчёт в фомате html сформировался в папке C:\Users\Administrator\AppData\Local\Temp. Путь к отчету утилита пишет, только если есть ошибки.

Ну и наконец создаем кластер с именем hpvcl и общим IP адресом 192.168.1.100

New-Cluster –Name hpvcl –Node "node1","node2" –NoStorage -StaticAddress 192.168.1.100 

После чего получаем ошибку, что в нашем кластере нет общего хранилища для отказоустойчивости. Запустим Failover cluster manager и проверим что у нас получилось.

Включаем (S2D)

Enable-ClusterStorageSpacesDirect –CimSession hpvcl 

И получаем оповещение, что не найдены диски для кэша. Поскольку тестовая среда у меня на SSD, а не на HDD, не будем переживать по этому поводу.

Затем подключаемся к одной из нод с помощью консоли powershell и создаем новый том. Нужно обратить внимание, что из 4 дисков по 40GB, для создания зеркального тома доступно порядка 74GB.

New-Volume -FriendlyName "Volume1" -FileSystem CSVFS_ReFS -StoragePoolFriendlyName S2D* -Size 74GB -ResiliencySettingName Mirror 

На каждой из нод, у нас появился общий том C:\ClusterStorage\Volume1.

Кластер с общим диском готов. Теперь создадим виртуальную машину VM на одной из нод и разместим её на общее хранилище.

Для настроек сети виртуальной машины, необходимо будет подключиться консолью hyper-v manager и создать виртуальную сеть с внешним доступом на каждой из нод с одинаковым именем. Затем мне пришлось перезапустить службу кластера на одной из нод, чтобы избавиться от ошибки с сетевым интерфейсом в консоли failover cluster manager.

Пока на виртуальную машину устанавливается система, попробуем подключиться к Windows Admin Center. Добавляем в ней наш гиперконвергентный кластер и получаем грустный смайлик

Подключимся к одной из нод и выполним скрипт:

Add-ClusterResourceType -Name "SDDC Management" -dll "$env:SystemRoot\Cluster\sddcres.dll" -DisplayName "SDDC Management"

Проверяем Admin Center и на этот раз получаем красивые графики

После того, как установил ОС на виртуальную машину VM внутри кластера, первым делом я проверил Live migration, переместив её на вторую ноду. Во время миграции я пинговал машину, чтобы проверить насколько быстро происходит миграция. Связь у меня пропала только на 2 запроса, что можно считать весьма неплохим результатом.

И тут стоит добавить несколько ложек дёгтя в эту гиперконвергентную бочку мёда. В тестовой и виртуальной среде все работает неплохо, но как это будет работать на реальном железе вопрос интересный. Тут стоит вернуться к аппаратным требованиям. Сетевые адаптеры 10GB с RDMA стоят порядка 500$, что в сумме с лицензией на Windows Server Datacenter делает решение не таким уж и дешёвым. Безусловно это дешевле чем выделенное хранилище, но ограничение существенное.

Вторая и основная ложка дёгтя, это новость о том, что функцию (S2D) уберут из следующей сборки server 2016 . Надеюсь, сотрудники Microsoft, читающие Хабр, это прокомментируют.

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

Обзор алгоритмов кластеризации данных / Хабр

Приветствую!

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

О том, что такое кластеризация, рассказал sashaeve в статье «Кластеризация: алгоритмы k-means и c-means». Я частично повторю слова Александра, частично дополню. Также в конце этой статьи интересующиеся могут почитать материалы по ссылкам в списке литературы.

Так же я постарался привести сухой «дипломный» стиль изложения к более публицистическому.

Понятие кластеризации

Кластеризация (или кластерный анализ) — это задача разбиения множества объектов на группы, называемые кластерами. Внутри каждой группы должны оказаться «похожие» объекты, а объекты разных группы должны быть как можно более отличны. Главное отличие кластеризации от классификации состоит в том, что перечень групп четко не задан и определяется в процессе работы алгоритма.

Применение кластерного анализа в общем виде сводится к следующим этапам:

1. Отбор выборки объектов для кластеризации.
2. Определение множества переменных, по которым будут оцениваться объекты в выборке. При необходимости – нормализация значений переменных.
3. Вычисление значений меры сходства между объектами.
4. Применение метода кластерного анализа для создания групп сходных объектов (кластеров).
5. Представление результатов анализа.

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

Меры расстояний

Итак, как же определять «похожесть» объектов? Для начала нужно составить вектор характеристик для каждого объекта — как правило, это набор числовых значений, например, рост-вес человека. Однако существуют также алгоритмы, работающие с качественными (т.н. категорийными) характеристиками.

После того, как мы определили вектор характеристик, можно провести нормализацию, чтобы все компоненты давали одинаковый вклад при расчете «расстояния». В процессе нормализации все значения приводятся к некоторому диапазону, например, [-1, -1] или [0, 1].

Наконец, для каждой пары объектов измеряется «расстояние» между ними — степень похожести. Существует множество метрик, вот лишь основные из них:

1. Евклидово расстояние
   
   Наиболее распространенная функция расстояния. Представляет собой геометрическим расстоянием в многомерном пространстве:

2. Квадрат евклидова расстояния
   
   Применяется для придания большего веса более отдаленным друг от друга объектам. Это расстояние вычисляется следующим образом:

3. Расстояние городских кварталов (манхэттенское расстояние)
   
   Это расстояние является средним разностей по координатам. В большинстве случаев эта мера расстояния приводит к таким же результатам, как и для обычного расстояния Евклида. Однако для этой меры влияние отдельных больших разностей (выбросов) уменьшается (т.к. они не возводятся в квадрат). Формула для расчета манхэттенского расстояния:

4. Расстояние Чебышева
   
   Это расстояние может оказаться полезным, когда нужно определить два объекта как «различные», если они различаются по какой-либо одной координате. Расстояние Чебышева вычисляется по формуле:

5. Степенное расстояние
   
   Применяется в случае, когда необходимо увеличить или уменьшить вес, относящийся к размерности, для которой соответствующие объекты сильно отличаются. Степенное расстояние вычисляется по следующей формуле:
   ,
   
   где r и p – параметры, определяемые пользователем. Параметр p ответственен за постепенное взвешивание разностей по отдельным координатам, параметр r ответственен за прогрессивное взвешивание больших расстояний между объектами. Если оба параметра – r и p — равны двум, то это расстояние совпадает с расстоянием Евклида.

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

Классификация алгоритмов

Для себя я выделил две основные классификации алгоритмов кластеризации.

1. Иерархические и плоские.
   
   Иерархические алгоритмы (также называемые алгоритмами таксономии) строят не одно разбиение выборки на непересекающиеся кластеры, а систему вложенных разбиений. Т.о. на выходе мы получаем дерево кластеров, корнем которого является вся выборка, а листьями — наиболее мелкие кластера.
   
   Плоские алгоритмы строят одно разбиение объектов на кластеры.
2. Четкие и нечеткие.
   
   Четкие (или непересекающиеся) алгоритмы каждому объекту выборки ставят в соответствие номер кластера, т.е. каждый объект принадлежит только одному кластеру. Нечеткие (или пересекающиеся) алгоритмы каждому объекту ставят в соответствие набор вещественных значений, показывающих степень отношения объекта к кластерам. Т.е. каждый объект относится к каждому кластеру с некоторой вероятностью.

Объединение кластеров

В случае использования иерархических алгоритмов встает вопрос, как объединять между собой кластера, как вычислять «расстояния» между ними. Существует несколько метрик:

1. Одиночная связь (расстояния ближайшего соседа)
   
   В этом методе расстояние между двумя кластерами определяется расстоянием между двумя наиболее близкими объектами (ближайшими соседями) в различных кластерах. Результирующие кластеры имеют тенденцию объединяться в цепочки.
2. Полная связь (расстояние наиболее удаленных соседей)
   
   В этом методе расстояния между кластерами определяются наибольшим расстоянием между любыми двумя объектами в различных кластерах (т.е. наиболее удаленными соседями). Этот метод обычно работает очень хорошо, когда объекты происходят из отдельных групп. Если же кластеры имеют удлиненную форму или их естественный тип является «цепочечным», то этот метод непригоден.
3. Невзвешенное попарное среднее
   
   В этом методе расстояние между двумя различными кластерами вычисляется как среднее расстояние между всеми парами объектов в них. Метод эффективен, когда объекты формируют различные группы, однако он работает одинаково хорошо и в случаях протяженных («цепочечного» типа) кластеров.
4. Взвешенное попарное среднее
   
   Метод идентичен методу невзвешенного попарного среднего, за исключением того, что при вычислениях размер соответствующих кластеров (т.е. число объектов, содержащихся в них) используется в качестве весового коэффициента. Поэтому данный метод должен быть использован, когда предполагаются неравные размеры кластеров.
5. Невзвешенный центроидный метод
   
   В этом методе расстояние между двумя кластерами определяется как расстояние между их центрами тяжести.
6. Взвешенный центроидный метод (медиана)
   
   Этот метод идентичен предыдущему, за исключением того, что при вычислениях используются веса для учета разницы между размерами кластеров. Поэтому, если имеются или подозреваются значительные отличия в размерах кластеров, этот метод оказывается предпочтительнее предыдущего.

Обзор алгоритмов

Алгоритмы иерархической кластеризации

Среди алгоритмов иерархической кластеризации выделяются два основных типа: восходящие и нисходящие алгоритмы. Нисходящие алгоритмы работают по принципу «сверху-вниз»: в начале все объекты помещаются в один кластер, который затем разбивается на все более мелкие кластеры. Более распространены восходящие алгоритмы, которые в начале работы помещают каждый объект в отдельный кластер, а затем объединяют кластеры во все более крупные, пока все объекты выборки не будут содержаться в одном кластере. Таким образом строится система вложенных разбиений. Результаты таких алгоритмов обычно представляют в виде дерева – дендрограммы. Классический пример такого дерева – классификация животных и растений.

Для вычисления расстояний между кластерами чаще все пользуются двумя расстояниями: одиночной связью или полной связью (см. обзор мер расстояний между кластерами).

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

Алгоритмы квадратичной ошибки

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

где c_j — «центр масс» кластера j (точка со средними значениями характеристик для данного кластера).

Алгоритмы квадратичной ошибки относятся к типу плоских алгоритмов. Самым распространенным алгоритмом этой категории является метод k-средних. Этот алгоритм строит заданное число кластеров, расположенных как можно дальше друг от друга. Работа алгоритма делится на несколько этапов:

1. Случайно выбрать k точек, являющихся начальными «центрами масс» кластеров.
2. Отнести каждый объект к кластеру с ближайшим «центром масс».
3. Пересчитать «центры масс» кластеров согласно их текущему составу.
4. Если критерий остановки алгоритма не удовлетворен, вернуться к п. 2.

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

К недостаткам данного алгоритма можно отнести необходимость задавать количество кластеров для разбиения.

Нечеткие алгоритмы

Наиболее популярным алгоритмом нечеткой кластеризации является алгоритм c-средних (c-means). Он представляет собой модификацию метода k-средних. Шаги работы алгоритма:

1. Выбрать начальное нечеткое разбиение n объектов на k кластеров путем выбора матрицы принадлежности U размера n x k.
2. Используя матрицу U, найти значение критерия нечеткой ошибки:
   ,
   
   где c_k — «центр масс» нечеткого кластера k:
   .
3. Перегруппировать объекты с целью уменьшения этого значения критерия нечеткой ошибки.
4. Возвращаться в п. 2 до тех пор, пока изменения матрицы U не станут незначительными.

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

Алгоритмы, основанные на теории графов

Суть таких алгоритмов заключается в том, что выборка объектов представляется в виде графа G=(V, E), вершинам которого соответствуют объекты, а ребра имеют вес, равный «расстоянию» между объектами. Достоинством графовых алгоритмов кластеризации являются наглядность, относительная простота реализации и возможность вносения различных усовершенствований, основанные на геометрических соображениях. Основными алгоритмам являются алгоритм выделения связных компонент, алгоритм построения минимального покрывающего (остовного) дерева и алгоритм послойной кластеризации.

Алгоритм выделения связных компонент

В алгоритме выделения связных компонент задается входной параметр R и в графе удаляются все ребра, для которых «расстояния» больше R. Соединенными остаются только наиболее близкие пары объектов. Смысл алгоритма заключается в том, чтобы подобрать такое значение R, лежащее в диапазон всех «расстояний», при котором граф «развалится» на несколько связных компонент. Полученные компоненты и есть кластеры.

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

Алгоритм минимального покрывающего дерева

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

Путём удаления связи, помеченной CD, с длиной равной 6 единицам (ребро с максимальным расстоянием), получаем два кластера: {A, B, C} и {D, E, F, G, H, I}. Второй кластер в дальнейшем может быть разделён ещё на два кластера путём удаления ребра EF, которое имеет длину, равную 4,5 единицам.

Послойная кластеризация

Алгоритм послойной кластеризации основан на выделении связных компонент графа на некотором уровне расстояний между объектами (вершинами). Уровень расстояния задается порогом расстояния c. Например, если расстояние между объектами , то .

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

,

где G^t = (V, E^t) — граф на уровне с^t,
,
с^t – t-ый порог расстояния,

m – количество уровней иерархии,
G⁰ = (V, o), o – пустое множество ребер графа, получаемое при t⁰ = 1,
G^m = G, то есть граф объектов без ограничений на расстояние (длину ребер графа), поскольку t^m = 1.

Посредством изменения порогов расстояния {с⁰, …, с^m}, где 0 = с⁰ < с¹ < …< с^m = 1, возможно контролировать глубину иерархии получаемых кластеров. Таким образом, алгоритм послойной кластеризации способен создавать как плоское разбиение данных, так и иерархическое.

Сравнение алгоритмов

Вычислительная сложность алгоритмов

Сравнительная таблица алгоритмов

Немного о применении

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

В отличие от полносвязного графа, в ориентированном дереве не все вершины соединены ребрами, при этом общее количество ребер равно n–1, где n – число вершин. Т.е. применительно к узлам дерева, работа алгоритма выделения связных компонент упростится, поскольку удаление любого количества ребер «развалит» дерево на связные компоненты (отдельные деревья). Алгоритм минимального покрывающего дерева в данном случае будет совпадать с алгоритмом выделения связных компонент – путем удаления самых длинных ребер исходное дерево разбивается на несколько деревьев. При этом очевидно, что фаза построения самого минимального покрывающего дерева пропускается.

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

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

Список литературы

1. Воронцов К.В. Алгоритмы кластеризации и многомерного шкалирования. Курс лекций. МГУ, 2007.
2. Jain A., Murty M., Flynn P. Data Clustering: A Review. // ACM Computing Surveys. 1999. Vol. 31, no. 3.
3. Котов А., Красильников Н. Кластеризация данных. 2006.
3. Мандель И. Д. Кластерный анализ. — М.: Финансы и Статистика, 1988.
4. Прикладная статистика: классификация и снижение размерности. / С.А. Айвазян, В.М. Бухштабер, И.С. Енюков, Л.Д. Мешалкин — М.: Финансы и статистика, 1989.
5. Информационно-аналитический ресурс, посвященный машинному обучению, распознаванию образов и интеллектуальному анализу данных — www.machinelearning.ru
6. Чубукова И.А. Курс лекций «Data Mining», Интернет-университет информационных технологий — www.intuit.ru/department/database/datamining

Создание кластера на уроках русского языка

Муниципальное бюджетное общеобразовательное учреждение –

средняя общеобразовательная школа № 45им. Д. И. Блынского г. Орла

Создание кластера

на уроках русского языка

Учитель начальных классов:

Коряковцева Елена Ивановна

Орёл, 2016г.

Создание кластера на уроках русского языка

1. Прием кластера как способ графической организации материала

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

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

Кластер предполагает:

1. выделение смысловых единиц текста

2. графическое оформление их в виде схемы.

Кластер является отражением нелинейной формы мышления, позволяет показать смысловые поля того или иного понятия. Иногда такой способ называют «наглядным мозговым штурмом».

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

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

Основные принципы составления кластера

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

Правила оформления кластера на уроке

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

Рекомендации по составлению кластера

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

Применение метода кластер

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

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

Применение кластера имеет следующие достоинства:

• он позволяет охватить большой объем информации;

• вовлекает всех участников коллектива в обучающий процесс, им это интересно;

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

В ходе данной работы формируются и развиваются следующие умения:

• умение ставить вопросы;

• выделять главное;

• устанавливать причинно-следственные связи и строить умозаключения;

• переходить от частностей к общему, понимая проблему в целом;

• сравнивать и анализировать;

• проводить аналогии.

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

2. Виды кластеров на уроках русского языка

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

Существуют различные виды кластеров:

• планета и её спутники

• блок-схемы

• бумажный кластер

• кластер с нумерацией слов для составления рассказа

• кластер с использованием отдельных или сюжетных картинок вместо записи слов

• групповые кластеры с использованием в каждой группе разных фрагментов одной темы с целью составления коллективного рассказа

• обратный кластер

• грамматический кластер

На этапе закрепления и систематизации изученного материала самой востребованной и продуктивной моделью кластера является «Планета и ее спутники». Ею удобно воспользоваться также на этапе целеполагания, повторения изученного материала.

Последовательность действий при создании кластера проста и логична:

1) посередине чистого листа (классной доски) фиксируется ключевое слово или предложение, которое является «сердцем» темы;

2) вокруг записываются слова или предложения, выражающие идеи, факты, образы, понятия, подходящие для данной темы;

3) по мере записи появившиеся слова соединяются разного рода символами (прямыми линиями, векторами, арифметическими знаками) с ключевым понятием. У каждого из «спутников» в свою очередь тоже появляются «спутники», устанавливаются новые логические связи.

При коллективном составлении кластера можно воспользоваться приемом «Корзина идей», предложив учащимся назвать факты, сведения самим, не повторяя ранее сказанного.

Систематизировать и представить материал по теме «Звуки речи» можно следующим образом:

Блок-схема

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

Анализ имени существительного

1. Определить часть речи:

2. Нач. ф. – (И. п., ед.ч.)

3. Постоянные признаки:

4. Определи форму слова:

5. Член предложения

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

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

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

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

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

Бумажный кластер

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

Часть речи

Обозначает

Вопросы

Изменяется

Роль в предложении

Кластер с нумерацией слов.

Подобный кластер целесообразно использовать в том случае, когда необходимо определить последовательность событий при составлении рассказа или устном изложении темы. Этот метод хорошо подходит для работы с учениками начальных классов, и теми, кто изучает иностранный язык, поскольку именно для них наибольшую трудность представляет определение очередности предложений в тексте: с чего начать изложение событий, как его развивать и каким образом закончить. Кластер с нумерацией слов составляется коллективно следующим образом: в центре доски записывается тема (ключевое слово), затем ученики называют все слова и словосочетания, которые приходят им на ум в связи с данной темой. Когда вся предлагаемая учениками лексика написана на доске, класс приступает к обсуждению последовательности событий в данном рассказе. Учитель помогает наводящими вопросами и вместе с учащимися проставляет номера очередности возле записанных на доске слов: рядом со словами, которые надо использовать в первом предложении, ставится номер 1, во втором – номер 2 и т. д.

Рекомендация: чтобы ученикам было легче ориентироваться в кластере и не пропускать слова при составлении рассказа, можно писать цифры цветными мелками: все цифры 1 – одним цветом, цифры 2- другим и т. д.

Арт-кластер (кластер с картинками)

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

Предметный Арт-кластер

Например, тема «Написание письма». В середине листа наклеивается конверт. Ученики должны выбрать из предложенных им картинок части и наклеить их вокруг главной темы. Затем ученики по кластеру рассказывают, как оформить (подписать) конверт.

Сюжетный Арт-кластер

Используется на уроках развития речи. Например, составить рассказ по серии картинок.

Групповой кластер

Групповой кластер подразумевает распределение фрагментов одной темы по группам и составление коллективного рассказа. Сочиняется рассказ, например на тему «Имя существительное». Одна группа составляет кластер «Одушевлённые — неодушевлённые», вторая – «Склонение», третья – «Род», четвертая – «Число», пятая – «Падеж», шестая – «Собственное — нарицательное». Готовые кластеры на больших листах приклеиваются вокруг главной темы. Каждая группа рассказывает часть рассказа по своему кластеру (или по чужому кластеру другую часть – на усмотрение учителя), остальные помогают, дополняют.

Обратный кластер

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

Ученики должны сами определить, что темой урока будет «Имя числительное».

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

3. Обучение школьников приему составления кластеров на уроках русского языка

Работу по обучению приему кластера можно «разбить» на несколько этапов:

1) коллективное составление кластера вместе с учителем;

2) коллективное составление кластера учащимися;

3) составление кластера в группе;

4) создание кластера в паре;

5) индивидуальная работа школьника на уроке.

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

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

На втором уроке учащиеся самостоятельно коллективно составляют кластер на этапе закрепления и систематизации пройденного материала. Школьники предлагают свои варианты организации информации и ее содержание устно (прием «Корзина идей»), делают записи, в процессе работы уточняют фактический материал, подмечают недостатки друг друга, стараются найти самый оптимальный вариант. Ребятам нравится возможность творчески проявить себя, в обсуждении участвуют все. По окончании работы учитель просит объяснить ему полученную модель, что ученики и делают с энтузиазмом.

На третьем занятии учитель на этапе объяснения нового материала предлагает учащимся самостоятельно поработать с учебником: внимательно прочитать правило, выделить в нем то, что он уже знал, то, что стало новым и то, что ему показалось сложным (прием «Инсерт»). Учащиеся имеют возможность задать вопросы, на которые получают ответы от одноклассников или, в случае затруднения, от учителя. Затем педагог предлагает ребятам поработать в паре и составить кластер к изучаемому правилу. Школьники советуются, уточняют материал, исправляют ошибки, корректируют недочеты как на уровне теоретического усвоения материала, так и при попытке его систематизации и графической организации. Через 5 минут ученики предлагают свои варианты кластеров (по желанию), зарисовывают их на доске, комментируют, делают выводы.

На уроке повторения изученного учащимся в индивидуальном порядке предлагается на альтернативной основе составить кластер на тему «Однокоренные слова и формы одного слова» или выполнить упражнение из учебник. Поработать над составлением кластера пожелала половина ребят, что я как педагог посчитала хорошим началом на пути дальнейшего совершенствования в этом виде работы: дети не боятся деятельности данного рода, готовы попробовать составить кластер даже индивидуально, а значит, уверены в наличии у них определенных знаний и навыков. По прошествии 5 минут учащиеся сдают свои работы. Подведение итогов проводится в два этапа: вначале просматриваются варианты кластера, которые получились у ребят, выбираются наиболее удачные, затем ребята защищают свои работы у доски. Класс оценивает их, комментирует, исправляет недочеты. Дети работают с интересом. К этому времени они уже достаточно хорошо освоили алгоритм составления кластера, научились работать с текстовой информацией и оформлять ее графически. Далее необходимо прокомментировать, почему не все кластеры были допущены к защите: разъясняются, прорабатываются типичные ошибки.

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

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

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

Заключение

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

Кластер Elasticsearch на 200 ТБ+ / Блог компании Одноклассники / Хабр

С Elasticsearch сталкиваются многие. Но что происходит, когда хочешь с его помощью хранить логи «в особо крупном объёме»? Да ещё и безболезненно переживать отказ любого из нескольких дата-центров? Какой стоит делать архитектуру, и на какие подводные камни наткнёшься?

Мы в Одноклассниках решили при помощи elasticsearch решить вопрос лог-менеджмента, а теперь делимся с Хабром опытом: и про архитектуру, и про подводные камни.

Я — Пётр Зайцев, работаю системным администратором в Одноклассниках. До этого тоже был админом, работал с Manticore Search, Sphinx search, Elasticsearch. Возможно, если появится ещё какой-нибудь …search, вероятно буду работать и с ним. Также участвую в ряде опенсорсных проектов на добровольной основе.

Когда я пришёл в Одноклассники, то опрометчиво сказал на собеседовании, что умею работать с Elasticsearch. После того, как освоился и поделал какие-то простенькие задачи, мне подарили большую задачу по реформированию системы лог-менеджмента, существовавшую на тот момент.

Требования

Требования к системе были сформулированы следующим образом:

• В качестве фронтенда должен был использоваться Graylog. Потому что в компании уже был опыт использования этого продукта, программисты и тестировщики его знали, он им был привычен и удобен.
• Объём данных: в среднем 50-80 тысяч сообщений в секунду, но если что-то ломается, то трафик ничем не ограничен, это может быть 2-3 миллиона строк в секунду
• Обсудив с заказчиками требования по скорости обработки поисковых запросов, мы поняли, что типичный паттерн использования подобной системы такой: люди ищут логи своего приложения за последние два дня и не хотят ждать результата на сформулированный запрос больше секунды.
• Админы настаивали на том, чтобы система при необходимости легко масштабировалась, не требуя от них глубокого вникания в то, как она устроена.
• Чтобы единственная задача по обслуживанию, которая этим системам требовалась периодически — это менять какое-то железо.
• Кроме того, в Одноклассниках есть прекрасная техническая традиция: любой сервис, который мы запускаем, должен переживать отказ дата-центра (внезапный, незапланированный и абсолютно в любое время).

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

Среда

Мы работаем на четырёх дата-центрах, при этом дата-ноды Elasticsearch могут располагаться только в трёх (по ряду нетехнических причин).

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

Важная особенность: запуск кластера происходит в контейнерах Podman не на физических машинах, а на собственном облачном продукте one-cloud. Контейнерам гарантируется 2 ядра, аналогичных 2.0Ghz v4 с возможностью утилизации остальных ядер, в случае их простоя.

Иными словами:

Топология

Общий вид решения мне изначально виделся следующим образом:

• 3-4 VIP стоят за А-рекордом домена Graylog, это адрес, на который отсылаются логи.
• каждый VIP представляет из себя балансировщик LVS.
• После него логи попадают на батарею Graylog, часть данных идёт в формате GELF, часть в формате syslog.
• Дальше всё это большими батчами пишется в батарею из координаторов Elasticsearch.
• А они, в свою очередь, отправляют запросы на запись и чтение на релевантные дата-ноды.

Терминология

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

В Elasticsearch есть несколько типов нод — master, coordinator, data node. Есть ещё два других типа для разных преобразований логов и связи разных кластеров между собой, но мы использовали только перечисленные.

Master

Пингует все присутствующие в кластере ноды, поддерживает актуальную карту кластера и распространяет её между нодами, обрабатывает событийную логику, занимается разного рода cluster wide housekeeping.

Coordinator

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

Data node

Хранит данные, выполняет, прилетающие из вне, поисковые запросы и операции над расположенными на ней шардами.

Graylog

Это что-то вроде сплава Kibana с Logstash в ELK-стэке. Graylog совмещает в себе и UI и конвейер по обработке логов. Под капотом в Graylog работают Kafka и Zookeeper, которые обеспечивают связность Graylog как кластера. Graylog умеет кэшировать логи (Kafka) на случай недоступности Elasticsearch и повторять неудачные запросы на чтение и запись, группировать и маркировать по задаваемым правилам логи. Как и Logstash, Graylog имеет функциональность по модификации строк перед записью в Elasticsearch.

Кроме того, в Graylog есть встроенный service discovery, позволяющий на основе одной доступной ноды Elasticsearch получить всю карту кластера и отфильтровать её по определённому тегу, что даёт возможность направлять запросы на определённые контейнеры.

Визуально это выглядит примерно так:

Это скриншот с конкретного инстанса. Здесь мы по поисковому запросу выстраиваем гистограмму, выводим релевантные строки.

Индексы

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

На приведённой ранее схеме это самый нижний уровень: Elasticsearch data nodes.

Индекс — это большая виртуальная сущность, состоящая из шардов Elasticsearch. Сам по себе каждый из шардов является ни чем иным, как Lucene index. А каждый Lucene index, в свою очередь, состоит и одного или более сегментов.

При проектировании мы прикидывали, что для обеспечения требования по скорости чтения на большом объёме данных нам необходимо равномерно «размазать» эти данные по дата-нодам.

Это вылилось в то, что количество шардов на индекс (с репликами) у нас должно быть строго равно количеству дата-нод. Во-первых, для того, чтобы обеспечить replication factor, равный двум (то есть мы можем потерять половину кластера). А, во-вторых, для того, чтобы запросы на чтение и запись обрабатывать, как минимум, на половине кластера.

Время хранения мы определили сперва как 30 дней.

Распределение шардов можно представить графически следующим образом:

Весь тёмно-серый прямоугольник целиком — это индекс. Левый красный квадрат в нём — это primary-шард, первый в индексе. А голубой квадрат — это replica-шард. Они находятся в разных дата-центрах.

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

Ротацию индексов, т.е. создание нового индекса и удаление наиболее старого, мы сделали равной 48 часов (по паттерну использования индекса: по последним 48 часам ищут чаще всего).

Такой интервал ротации индексов связан со следующими причинами:

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

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

Чтобы обеспечить необходимый latency поиска, мы решили использовать SSD. Для быстрой обработки запросов машины, на которых размещались эти контейнеры, должны были обладать по меньшей мере 56 ядрами. Цифра в 56 выбрана как условно-достаточная величина, определяющая количество тредов, которые будет порождать Elasticsearch в процессе работы. В Elasitcsearch многие параметры thread pool напрямую зависят от количества доступных ядер, что в свою очередь прямо влияет на необходимое кол-во нод в кластере по принципу «меньше ядер — больше нод».

В итоге у нас получилось, что в среднем шард весит где-то 20 гигабайт, и на 1 индекс приходится 360 шардов. Соответственно, если мы их ротируем раз в 48 часов, то у нас их 15 штук. Каждый индекс вмещает в себя данные за 2 дня.

Схемы записи и чтения данных

Давайте разберёмся, как в этой системе записываются данные.

Допустим, у нас из Graylog прилетает в координатор какой-то запрос. Например, мы хотим проиндексировать 2-3 тысячи строк.

Координатор, получив от Graylog запрос, опрашивает мастер: «В запросе на индексацию у нас был конкретно указан индекс, но в который шард это писать — не указано».

Master отвечает: «Запиши эту информацию в шард номер 71», после чего она направляется непосредственно в релевантную дата-ноду, где находится primary-shard номер 71.

После чего лог транзакций реплицируется на replica-shard, который находится уже в другом дата-центре.

Из Graylog в координатор прилетает поисковый запрос. Координатор перенаправляет его по индексу, при этом Elasticsearch по принципу round-robin распределяет запросы между primary-shard и replica-shard.

Ноды в количестве 180 штук отвечают неравномерно, и, пока они отвечают, координатор копит информацию, которую в него уже «выплюнули» более быстрые дата-ноды. После этого, когда либо вся информация пришла, либо по запросу достигнут таймаут, отдаёт всё непосредственно клиенту.

Вся эта система в среднем отрабатывает поисковые запросы по последним 48 часам за 300-400ms, исключая те запросы, которые с leading wildcard.

«Цветочки» с Elasticsearch: настройка Java

Чтобы всё это заработало так, как мы изначально хотели, мы очень долго отлаживали самые разнообразные вещи в кластере.

Первая часть обнаруженных проблем была связана с тем, как в Elasticsearch по дефолту преднастроена Java.

Проблема первая

Мы наблюдали очень большое количество сообщений о том, что у нас на уровне Lucene, когда запущены background job’ы, мерджи сегментов Lucene завершаются с ошибкой. При этом в логах было видно, что это OutOfMemoryError-ошибка. По телеметрии мы видели, что хип свободен, и не было понятно, почему эта операция падает.

Выяснилось, что мерджи Lucene-индексов происходят вне хипа. А контейнеры довольно жёстко ограничены по потребляемым ресурсам. В эти ресурсы влезал только хип (значение heap.size было примерно равно RAM), а какие-то off-heap операции падали с ошибкой аллокации памяти, если по какой-то причине не укладывались в те ~500MB, что оставались до лимита.

Фикс был довольно тривиальным: доступный для контейнера объём RAM увеличили, после чего забыли о том, что такие проблемы у нас вообще были.

Проблема вторая

Дня через 4-5 после запуска кластера мы заметили, что дата-ноды начинают периодически вываливаться из кластера и заходить в него секунд через 10-20.

Когда полезли разбираться, выяснилось, что эта самая off-heap память в Elasticsearch не контролируется практически никак. Когда мы контейнеру отдали больше памяти, мы получили возможность наполнять direct buffer pools различной информацией, и она очищалась только после того, как запускался explicit GC со стороны Elasticsearch.

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

Решение было следующим: мы ограничили Java возможность использовать основную часть памяти вне хипа под эти операции. Мы лимитировали её до 16 гигабайт (-XX:MaxDirectMemorySize=16g), добившись того, что explicit GC вызывался значительно чаще, а отрабатывал значительно быстрее, перестав тем самым дестабилизировать кластер.

Проблема третья

Если вы думаете, что проблемы с «нодами, покидающими кластер в самый непредвиденный момент» на этом кончились, вы ошибаетесь.

Когда мы конфигурировали работу с индексами, мы остановили свой выбор на mmapfs, чтобы сократить время поиска по свежим шардам с большой сегментированностью. Это было довольно грубой ошибкой, потому что при использовании mmapfs файл маппится в оперативную память, а дальше мы работаем уже с mapped-файлом. Из-за этого получается, что при попытке GC остановить треды в приложении мы очень долго идём в safepoint, и по дороге к нему приложение перестает отвечать на запросы мастера о том, живое ли оно. Соответственно, master считает, что нода у нас больше в кластере не присутствует. После этого спустя секунд 5-10 отрабатывает garbage collector, нода оживает, снова заходит в кластер и начинает инициализацию шардов. Всё это сильно напоминало “продакшен, который мы заслужили” и не годилось для чего-либо серьёзного.

Чтобы избавиться от такого поведения, мы сперва перешли на стандартный niofs, а после, когда с пятых версий Elastic отмигрировались на шестые, попробовали hybridfs, где данная проблема не воспроизводилась. Подробней про типы стореджа можно почитать здесь.

Проблема четвёртая

Потом была еще очень занимательная проблема, которую мы лечили рекордно долго. Мы ловили её 2-3 месяца, потому что был абсолютно непонятен её паттерн.

Иногда у нас координаторы уходили в Full GC, обычно где-то после обеда, и оттуда уже не возвращались. При этом при логировании задержки GC это выглядело так: у нас всё идет хорошо, хорошо, хорошо, а потом раз — и всё резко плохо.

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

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

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

Единственный фикс, который мы нашли для того, чтобы изменить поведение кластера в такой ситуации — миграция на JDK13 и использование сборщика мусора Shenandoah. Это решило проблему, координаторы у нас падать перестали.

На этом проблемы с Java закончились и начались проблемы с пропускной способностью.

«Ягодки» с Elasticsearch: пропускная способность

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

Первый встреченный симптом: при каких-то «взрывах» на продакшене, когда резко генерируется очень большое количество логов, в Graylog начинает часто мелькать ошибка индексации es_rejected_execution.

Это происходило из-за того, что thread_pool.write.queue на одной дата-ноде до момента, как Elasticsearch сумеет обработать запрос на индексацию и закинуть информацию в шард на диск, по дефолту умеет кэшировать только 200 запросов. И в документации Elasticsearch об этом параметре говорится крайне мало. Указывается только предельное кол-во тредов и дефолтный размер.

Разумеется, мы пошли крутить это значение и выяснили следующее: конкретно в нашем сетапе довольно хорошо кешируется до 300 запросов, а большее значение чревато тем, что мы снова улетаем в Full GC.

Кроме того, поскольку это пачки сообщений, которые прилетают в рамках одного запроса, то надо было ещё подкрутить Graylog для того, чтобы он писал не часто и мелкими батчами, а огромными батчами или раз в 3 секунды, если батч всё ещё не полон. В таком случае получается, что информация, которую мы в Elasticsearch пишем, становится доступной не через две секунды, а через пять (что нас вполне устраивает), но уменьшается количество ретраев, которые приходится сделать, чтобы пропихнуть большую пачку информации.

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

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

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

Но это можно было частично обойти за счёт того, что в шестых версиях Elasticsearch появился алгоритм, позволяющий распределять запросы между релевантными дата-нодами не по случайному принципу round-robin (контейнер, который занимается индексацией и держит primary-shard, может быть очень занят, там не будет возможности ответить быстро), а направить этот запрос на менее загруженный контейнер с replica-shard, который ответит значительно быстрее. Иными словами, мы пришли к use_adaptive_replica_selection: true.

Картина чтения начинает выглядеть так:

Переход на этот алгоритм позволил заметно улучшить query time в те моменты, когда у нас шёл большой поток логов на запись.

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

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

• Если у нас в отвалившемся дата-центре находится текущий master, то он будет перевыбран и переедет как роль на другую ноду в другом ДЦ.
• Мастер быстро выкинет из кластера все недоступные ноды.
• На основе оставшихся он поймет: в потерявшемся дата-центре у нас были такие-то primary-шарды, быстро запромоутит комплиментарные replica-шарды в оставшихся дата-центрах, и у нас продолжится индексация данных.
• В результате этого у нас будет плавно деградировать пропускная способность кластера на запись и чтение, однако в целом всё будет работать хоть и медленно, но стабильно.

Как выяснилось, хотели мы чего-то вот такого:

А получили следующее:

Как так получилось?

В момент падения дата-центра у нас узким местом стал мастер.

Почему?

Дело в том, что в мастере есть TaskBatcher, отвечающий за распространение в кластере определённых задач, ивентов. Любой выход ноды, любое продвижение шарда из replica в primary, любая задача на создание где-то какого-то шарда — всё это попадает сперва в TaskBatcher, где обрабатывается последовательно и в один поток.

В момент вывода одного дата-центра получалось, что все дата-ноды в выживших дата-центрах считали своим долгом сообщить мастеру «у нас потерялись такие-то шарды и такие-то дата-ноды».

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

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

Мы делали измерения, и до версии 6.4.0, где это было пофикшено, нам было достаточно вывести одновременно вывести всего лишь 10 дата-нод из 360 для того, чтобы полностью положить кластер.

Выглядело это примерно вот так:

После версии 6.4.0, где починили этот стрёмный баг, дата-ноды перестали убивать мастера. Но «умнее» он от этого не стал. А именно: когда мы выводим 2, 3 или 10 (любое количество, отличное от единицы) дата-нод, мастер получает какое-то первое сообщение, которое говорит, что нода А вышла, и пытается рассказать об этом ноде B, ноде C, ноде D.

И на текущий момент с этим можно бороться только установкой тайм-аута на попытки кому-то о чём-то рассказать, равные где-то 20-30 секундам, и таким образом управлять скоростью вывода дата-центра из кластера.

В принципе, это укладывается в те требования, которые изначально были предъявлены к конечному продукту в рамках проекта, но с точки зрения «чистой науки» это баг. Который, кстати, был успешно пофикшен разработчиками в версии 7.2.

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

Поэтому, когда уже всё «отгремело», вышедшие дата-ноды не маркируются как stale немедленно. Соответственно, мы вынуждены ждать, когда оттаймаутятся все пинги до вышедших дата-нод и только после этого наш кластер начинает рассказывать о том, что там-то, там-то и там-то надо продолжить запись информации. Более подробно можно почитать об этом здесь.

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

В итоге мы пришли к следующему решению:

• У нас 360 дата-нод с дисками на 700 гигабайт.
• 60 координаторов для роутинга трафика по этим самым дата-нодам.
• 40 мастеров, которые у нас остались как некое наследие со времён версий до 6.4.0 — чтобы пережить вывод дата-центра, мы морально были готовы потерять несколько машин, чтобы гарантированно даже при худшем сценарии иметь кворум мастеров
• Любые попытки совмещения ролей на одном контейнере у нас упирались в то, что рано или поздно нода ломалось под нагрузкой.
• Во всём кластере используется heap.size, равный 31 гигабайту: все попытки уменьшить размер приводили к тому, что на тяжёлых поисковых запросах с leading wildcard либо убивал какие-то ноды, либо прибивался circuit breaker в самом Elasticsearch.
• Кроме того, для обеспечения производительности поиска мы старались держать количество объектов в кластере минимально возможным, чтобы обрабатывать как можно меньше событий в самом узком месте, которое у нас получилось в мастере.

Напоследок о мониторинге

Чтобы всё это работало так, как задумывалось, мы мониторим следующее:

• Каждая дата-нода сообщает в наше облако, что она есть, и на ней находятся такие-то шарды. Когда мы где-то что-то тушим, кластер через 2-3 секунды рапортует, что в центре А мы потушили ноду 2, 3, и 4 — это означает, что в других дата-центрах мы ни в коем случае не можем тушить те ноды, на которых остались шарды в единственном экземпляре.
• Зная характер поведения мастера, мы очень внимательно смотрим на количество pending-задач. Потому что даже одна зависшая задача, если вовремя не оттаймаутится, теоретически в какой-то экстренной ситуации способна стать той причиной, по которой у нас не отработает, допустим, промоушен replica-шарда в primary, из-за чего встанет индексация.
• Также мы очень пристально смотрим на задержки garbage collector, потому что у нас с этим уже были большие сложности при оптимизации.
• Реджекты по тредам, чтобы понимать заранее, где находится «бутылочное горло».
• Ну и стандартные метрики, типа heap, RAM и I/O.

При построении мониторинга обязательно надо учитывать особенности Thread Pool в Elasticsearch. Документация Elasticsearch описывает возможности настройки и дефолтные значения для поиска, индексации, но полностью умалчивает о thread_pool.management.Эти треды обрабатывают, в частности, запросы типа _cat/shards и другие аналогичные, которые удобно использовать при написании мониторинга. Чем больше кластер, тем больше таких запросов выполняется в единицу времени, а вышеупомянутый thread_pool.management мало того, что не представлен в официальной документации, так ещё и лимитирован по дефолту 5 тредами, что очень быстро утилизируется, после чего мониторинг перестаёт работать корректно.

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

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

sql — Средняя цена за кластер

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

.

Как работает кластеризация на основе плотности — ArcGIS Pro

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

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

Возможные области применения

Вот несколько способов применения этого инструмента:

• Городские водопроводные сети являются важным скрытым подземным активом. Группировка разрывов труб и разрывов может указывать на надвигающиеся проблемы. Используя инструмент кластеризации на основе плотности, инженер может найти, где находятся эти кластеры, и предпринять упреждающие действия в зонах повышенной опасности в сетях водоснабжения.
• Предположим, у вас есть данные о позициях для всех удачных и неудачных бросков для игроков НБА.Кластеризация на основе плотности может показать вам различные модели удачных и неудачных позиций для каждого игрока. Затем эту информацию можно использовать для информирования о стратегии игры.
• Предположим, вы изучаете конкретную болезнь, переносимую вредителями, и имеете набор точечных данных, представляющий домохозяйства в вашем районе исследования, некоторые из которых заражены, а некоторые нет. Используя инструмент кластеризации на основе плотности, вы можете определить самые большие кластеры зараженных домашних хозяйств, чтобы помочь точно определить область, в которой нужно начать обработку и уничтожение вредителей.
• Твиты с геолокацией после стихийных бедствий или террористических атак могут быть сгруппированы, а потребности в спасательных операциях и эвакуации могут быть информированы в зависимости от размера и местоположения идентифицированных кластеров.

Методы кластеризации

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

• Определенное расстояние (DBSCAN) — использует указанное расстояние для разделения
  плотные скопления из более редкого шума.Алгоритм DBSCAN — самый быстрый из методов кластеризации, но
  подходит только в том случае, если существует очень четкое расстояние поиска для использования, и это хорошо работает для всех потенциальных кластеров.
  Для этого необходимо, чтобы все значимые кластеры имели одинаковые
  плотности.
• Самонастраивающийся (HDBSCAN) — использует диапазон расстояний для разделения
  кластеры разной плотности из более редкого шума.

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

• Мультимасштаб (ОПТИКА) — использует расстояние между соседними объектами для создания
  график достижимости, который затем используется для отделения кластеров различной плотности от
  шум. Алгоритм OPTICS предлагает максимальную гибкость
  в точной настройке обнаруженных кластеров, хотя это
  требует больших вычислительных ресурсов, особенно при большом поиске
  Расстояние.

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

Минимальное количество функций на кластер (Требуется для всех методов)

Этот параметр определяет минимальное количество функций, необходимых для рассмотрения группировки точек в кластер. Например, если у вас есть несколько различных кластеров, размер которых варьируется от 10 до 100 точек, и вы выбираете Минимальное количество функций на кластер, равное 20, все кластеры, которые имеют менее 20 точек, будут считаться шумом (поскольку они имеют не образуют группу, достаточно большую, чтобы считаться кластером), или они будут объединены с соседними кластерами, чтобы удовлетворить минимальное количество требуемых функций.Напротив, выбор минимального количества функций на кластер, меньшего, чем то, что вы считаете самым маленьким значимым кластером, может привести к разделению значимых кластеров на более мелкие кластеры. Другими словами, чем меньше минимальное количество функций на кластер, тем больше кластеров будет обнаружено. Чем больше минимальное количество функций на кластер, тем меньше кластеров будет обнаружено.

Совет:

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

Параметр Minimum Features Per Cluster также важен при вычислении расстояния между ядрами, которое является измерением, используемым всеми тремя методами для поиска кластеров. Концептуально расстояние до ядра или каждая точка — это измерение расстояния, которое требуется для прохождения от каждой точки до определенного минимального количества объектов.Таким образом, если выбрано большое минимальное количество функций на кластер, то соответствующее расстояние ядра будет больше. Если выбрано небольшое минимальное количество элементов на кластер, соответствующее расстояние ядра будет меньше. На границах кластеров точки будут иметь большие расстояния до ядра (и, вероятно, не попадут в кластер). Расстояние между ядрами связано с параметром «Расстояние поиска», который используется как в методах «Определенное расстояние» (DBSCAN), так и в методах многомасштабных измерений (OPTICS).

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

Расстояние поиска (DBSCAN и OPTICS)

Для определенного расстояния (DBSCAN), если минимальные объекты на кластер не могут быть найдены в пределах расстояния поиска от определенной точки, эта точка будет отмечена как шум. Другими словами, если расстояние до ядра (расстояние, необходимое для достижения минимального количества объектов) для объекта больше, чем расстояние поиска, точка помечается как шум. Расстояние поиска при использовании «Определенное расстояние» (DBSCAN) рассматривается как ограничение поиска.

Когда расстояние поиска меньше, чем расстояние до ядра (расстояние, необходимое для достижения указанного минимального количества объектов на кластер, которое на этом рисунке равно 4), объект помечается как шум. Когда расстояние поиска больше расстояния до ядра, объект помечается как часть кластера.

Для многомасштабного (OPTICS) расстояние поиска рассматривается как максимальное расстояние, которое будет сравниваться с расстоянием до ядра. Multi-scale (OPTICS) использует концепцию максимального расстояния достижимости, которое представляет собой расстояние от точки до ближайшего соседа, который еще не был посещен поиском (Примечание: OPTICS — это упорядоченный алгоритм, который начинается с объекта в OID 0 и переходит от этой точки к следующей, чтобы создать сюжет.Порядок точек имеет решающее значение для результатов). Multi-scale (OPTICS) будет искать все соседние расстояния в пределах указанного Search Distance, сравнивая каждое из них с базовым расстоянием. Если какое-либо расстояние меньше, чем core-distance, то этой функции назначается это core-distance в качестве расстояния достижимости. Если все расстояния больше, чем расстояние ядра, то наименьшее из этих расстояний назначается расстоянием достижимости. Эти расстояния затем используются для создания графика достижимости, который представляет собой упорядоченный график расстояний достижимости, который используется для обнаружения кластеров.

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

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

График достижимости (ОПТИКА)

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

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

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

Плато могут возникать на графике достижимости, когда расстояние поиска меньше наибольшего расстояния до ядра. Ключевым аспектом использования метода кластеризации OPTICS является определение того, как обнаруживать кластеры на графике достижимости, что выполняется с помощью параметра Cluster Sensitivity.

Cluster Sensitivity (OPTICS)

Параметр Cluster Sensitivity определяет, как форма (оба
наклон и высота) пиков на графике достижимости будет
используется для разделения кластеров.Очень высокая чувствительность кластера (близко
до 100) будет рассматривать даже самый маленький пик как разделение между
кластеры, что приводит к увеличению количества кластеров. Очень низкий
Чувствительность кластера (близкая к 0) относится только к самым крутым,
самые высокие пики как разделение между кластерами, что приводит к
меньшее количество кластеров.

Низкая чувствительность кластера по сравнению с высокой чувствительностью кластера

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

Сравнение методов

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

График концептуальной достижимости с кластерами точек с различной плотностью и расстоянием между ними.

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

Иллюстрация расстояния поиска в алгоритме DBSCAN

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

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

Для многомасштабного (ОПТИКА) работа по обнаружению кластеров основана не на
определенное расстояние, но вместо этого на пиках и долинах в пределах
сюжет.Скажем, каждый пик имеет уровень либо Малый, либо
Средний или Большой.

Иллюстрация интенсивности пиков на графике достижимости

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

Иллюстрация влияния высокой чувствительности кластера, используемого с оптикой и соответствующими кластерами

Выбор
умеренная кластерная чувствительность приведет к как Среднему, так и
Используются большие пики, но не маленькие пики.

Иллюстрация влияния умеренной чувствительности кластера, используемого с оптикой, и соответствующих кластеров

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

Иллюстрация влияния параметра низкой чувствительности кластера, используемого с OPTICS и соответствующими кластерами

Multi-scale (OPTICS) предлагает максимальную гибкость в точной настройке
кластеров, которые обнаруживаются, хотя он также является самым медленным из
три метода кластеризации.

Результаты

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

Если выбран метод кластеризации Самонастраивающийся (HDBSCAN), выходной класс пространственных объектов также будет содержать поля PROB, которые представляют собой вероятность того, что объект принадлежит к
назначенная ему группа, OUTLIER, обозначающая объект, возможно, выброс в пределах
собственный кластер (чем больше значение, тем больше признак
может быть выбросом) и EXEMPLAR, который обозначает функции, которые являются наиболее
прототип или наиболее представительный для каждого кластера.

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

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

В дополнение к графику достижимости, который создается при выборе Multi-scale (OPTICS), все методы кластеризации также создают
Гистограмма, показывающая все уникальные идентификаторы кластера. Этот график можно использовать
чтобы легко выбрать все функции, которые попадают в указанный
кластер и изучить размер каждого из кластеров.

Дополнительные ресурсы

Для получения дополнительной информации о DBSCAN:

• Ester, M., Kriegel, H.P., Sander, J., & Xu, X.(1996, август). Алгоритм на основе плотности для обнаружения кластеров в больших пространственных базах данных с шумом. In Kdd (Том 96, № 34, стр. 226-231).

Для получения дополнительной информации о HDBSCAN:

• Campello, R.J., Moulavi, D., & Sander, J. (2013, апрель). Кластеризация на основе плотности на основе оценок иерархической плотности. В Тихоокеанско-азиатской конференции по открытию знаний и интеллектуальному анализу данных (стр. 160-172). Шпрингер, Берлин, Гейдельберг.

Для получения дополнительной информации об ОПТИКЕ:

• Ankerst, M., Брейниг, М. М., Кригель, Х. П., и Сандер, Дж. (1999, июнь). ОПТИКА: точки упорядочивания для определения структуры кластеризации. В записи ACM Sigmod (Vol. 28, No. 2, pp. 49-60). ACM.

.

на кластер ▷ испанский перевод

por grupos (6)

Por Clúster (6)

пор рацимо (5)

пор группа (3)

.