Сетевые технологии Распределенные компьютерные системы Консолидации аппаратного обеспечения

Сетевые технологии Распределенные компьютерные системы: Консолидации аппаратного обеспечения Ковалев Данила Олегович

Кратко о главном Что? 1. Распределенная компьютерная система отказоустойчивая виртуально единая система компьютерных ресурсов, для которой характерна прозрачная для пользователей интеллектуальная агрегация ресурсов. 2. Консолидация компьютерных ресурсов объединение аппаратного обеспечения в компьютерную систему 3. Виртуализация компьютерных ресурсов независимое параллельное использование аппаратного обеспечения

Кратко о главном Зачем? Как? • Увеличение скорости вычислений • Обеспечение надежности • Балансировка нагрузки • Grid • Cluster

Grid vs Cluster Grid: • Узлы разнородны (Win, UNIX, PC, PS 3) • Узел ненадежен и может отсоединиться в любой момент • Такая нестабильность компенсируется большим количеством узлов • Обычно узлы разнесены достаточно далеко друг от друга Cluster: • Узлы однородны

Grid vs Cluster Пример Grid: FOLDING@HOME • • • Моделирование свертывания белка 222 000 CPU & 23 000 GPU Intel, AMD, Cell, AMD/NVIDIA GPU 7 Peta. FLOPS (2011) Архитектура «клиент-сервер»

Grid vs Cluster Пример Cluster: Milky-Way 2 • • Распределенные вычисления 3, 120, 000 cores Intel Xeon + Xeon Phi 34, 8 Peta. FLOPS

Computational clusters Использование: ресурсоемкие вычисления Технологии: параллелизм и еще много чего Пример кластера: Milky-Way 2 (MPICH) MPI Open. MP Hadoop

LB & HA clusters. Задача кластеров высокой доступности – обеспечивать надежный и постоянный доступ к сервисам путем введения отказоустойчивости. Задача кластеров балансировки – распределение нагрузки между нодами кластера для повышения производительности. Реализации HA&LB: есть программные, есть аппаратные.

LB & HA clusters. Example (Normal) 192. 168. 72. 222 Virtual IP HA Proxy Pacemaker Corosync frontend 2 frontend 1 backend 2 backend 3

LB & HA clusters. Example (Fail) 192. 168. 72. 222 Virtual IP HA Proxy Pacemaker Corosync frontend 2 frontend 1 backend 2 backend 3

Принцип работы HA. Ресурсы • Все, что может быть заскриптовано – ресурс (HAProxy, IP-address, Apache, etc) • Скрипт умеет start, stop, monitor. Следовательно, сервис-ресурс должен как-то предоставлять данные о состоянии • Типы скриптов Pacemaker: OCF и LSB • Можно сделать свой скрипт или найти подходящий на просторах сети • Ресурс соответственно должен уметь хранить свое состояние таким образом, чтобы его можно было с минимальными потерями перенести на другую ноду

Принцип работы HA. Split-Brain Кластер: 3 ноды A, B, C. Ресурс R находится на ноде A Теряется связь между А и остальными. B и С не знают, работает ли А (мертвыйживой). Поэтому они хотят перехватить управление ресурсом, чтобы пользователь не заметил возможной смерти А. • Однако А жив (просто у него нет связи с остальными) и продолжает управлять ресурсом R. • Две изолированных группы нод управляют одним ресурсом R одновременно, что может привести к повреждению ресурса. • Возникает ситуация Split-Brain (“помутнение разума”). • •

Принцип работы HA. Split-Brain Иллюстрация сломанного ресурса Node A Node B Node C R R

Принцип работы HA. Fencing Решение проблемы со Split-Brain: отрезать «выпавшей» ноде доступ к ресурсу и самим управлять им (поставить заборчик). Два типа fencing: • Resource-fencing • Node-fencing

Принцип работы HA. STONITH Node fencing: STONITH • Киллер на службе у кластера (тупо гасит «плохую» ноду) • stonithd daemon • STONITH plugin STONITH devices categories: • UPS • PDU • Blade power control device • Lights-out devices • Testing devices

Принцип работы HA. Resource fencing: Кластер может иметь возможность контролировать определенные устройства (например, дисковые массивы, свитчи и т. д. ) для того, чтобы запретить к ним доступ для «плохих» нод.

Принцип работы HA. Quorum При Split-Brain каждая независимая группа нод будет пытаться сделать STONITH другой группе нод. Т. о. ничего работать не будет (все умрут). Поэтому нужен некий механизм арбитража, для выяснения, кого именно грохнуть (кворум). Логика кворума проста: если я могу достучаться до N/2 нод (есть кворум), то надо убить «плохие» ноды. Поэтому: выключайте кворум и STONITH на 2 -node-cluster, иначе все повиснет.

Архитектура HA-Cluster Node FC Switch SP A SP B Logical Disk RAID

Архитектура HA-Cluster Ресурс Управление ресурсами Коммуникация между нодами Node

Архитектура HA-Cluster. Heartbeat Ресурс Управление ресурсами Heartbeat + Cluster Resource Manager Node

Архитектура HA-Cluster. Heartbeat + Pacemaker Ресурс Pacemaker (CRM) Heartbeat Node

Архитектура HA-Cluster. Corosync + Pacemaker Ресурс Pacemaker (CRM) Corosync/Open. AIS Node

Архитектура HA-Cluster. Corosync + RGManager Ресурс RGManager Corosync/Open. AIS Node CMAN Node Любителям Red. Hat посвящается =) (Red. Hat Cluster Stack)

Архитектура HA-Cluster. Все вместе Ресурс Pacemaker (CRM) Heartbeat Node Ресурс Pacemaker (CRM) RGManager Corosync/Open. AIS Node Node CMAN Node

Что умеет Pacemaker

Задание для получения 5 на экзамене • Сделать кластер с балансировкой нагрузки, похожий на тот, который демонстрировался на лекции • Рекомендуемый кластерный стек: Pacemaker + Corosync или Heartbeat • Рекомендуемый балансер: HAProxy • Рекомендуемая ОС - Debian • Виртуальные машины помогут вам (Vm. Ware, Virtual. PC, Xen, etc) • В конце семестра нужно будет продемонстрировать работу кластера и объяснить шаги его настройки

Полезные ссылки • Clusterlabs. org • Linux-ha. com Что почитать: • Cluster from scratch • Pacemaker explained

Спасибо за внимание!