Слайд 2
Кратко о главном
Что?
1. Распределенная компьютерная система - отказоустойчивая
виртуально единая система компьютерных ресурсов, для которой характерна прозрачная
для пользователей интеллектуальная агрегация ресурсов.
2. Консолидация компьютерных ресурсов - объединение аппаратного обеспечения в компьютерную систему
3. Виртуализация компьютерных ресурсов – изолированное использование «части» компьютерных ресурсов
Слайд 3
Кратко о главном
Зачем?
Увеличение скорости вычислений
Балансировка нагрузки
Обеспечение надежности
Как?
Volunteer Computing
(Grid)
GNU/Linux (MOSIX, Linux-HA), Windows (CCS)
Supercomputer
Слайд 4
Grid & Supercomputer
Grid:
Узлы разнородны (Win, UNIX) подключены к
сети (локальной или глобальной) при помощи обычных протоколов (Ethernet)
Узел
ненадежен и может отсоединиться в любой момент
Такая нестабильность компенсируется большим количеством узлов
Supercomputer:
Узлы однородны, подключены к высокоскоростной коммутируемой компьютерной сети (InfiniBand, FC)
Слайд 5
Grid & Supercomputer
Пример Grid:
Моделирование свертывания белка в
Стэнфорде
FOLDING@HOME
222 000 CPU & 23 000 GPU
Intel, AMD, Cell,
AMD/NVIDIA GPU
7 PetaFLOPS (2011)
Архитектура «клиент-сервер»
Слайд 6
Grid & Supercomputer
Пример Supercomputer:
Оборонный научно-технический университет НОАК
天河二號,
Tiānhé-2
33,86 PetaFLOPS
состоит из
16 тысяч узлов
(2 процессора Intel Xeon
E5-2692
на архитектуре
Ivy Bridge с 12 ядрами
(частота 2,2 ГГц)
и 3 сопроцессора IntelXeon Phi 31S1P
СХД 12,4 ПБ
Слайд 7
Аппаратная архитектура. Supercomputer
Node
Node
Node
Node
FC Switch
FC Switch
SP A
C1
SP B
RAID group
1
Logical Disk 1 (LUN)
C2
Слайд 8
Computational clusters
Использование: ресурсоемкие вычисления
MPI (MPICH, Open MPI)
Hadoop
Слайд 9
LB & HA clusters
Задача кластеров высокой доступности
High-availability
clusters / failover clusters - организовать надежный доступ к
сервисам путем обеспечения отказоустойчивости.
Задача кластеров балансировки
Load balancing clusters –
распределение нагрузки между нодами (вершинами) кластера для повышения производительности.
Слайд 10
LB & HA clusters. Example (Normal)
Frontend1
Frontend2
HA Proxy
Virtual IP
Virtual
IP
Pacemaker + Corosync
192.168.72.222
HA Proxy
Слайд 11
LB & HA clusters. Example (Fail)
frontend1
Frontend2
Pacemaker + Corosync
192.168.72.222
HA
Proxy
Virtual IP
Слайд 12
Принцип работы HA. Ресурсы
Все, что может быть заскриптовано,
то может быть ресурсом. Все, что требуется от скрипта,
это выполнять 3 действия: start, stop и monitor. Скрипты должны соответствовать LSB (Linux Standard Base) или OCF (Open Cluster Framework).
Ресурс может представлять из себя:
ip-адрес, демон с определенной конфигурацией, блочное устройство, файловую систему и т.д.
Ресурс соответственно должен уметь хранить свое состояние таким образом, чтобы его можно было с минимальными потерями перенести на другую ноду
Слайд 14
Split-Brain
Кластер: 3 ноды A, B, C. Ресурс R
находится на ноде A
Теряется связь между А и остальными.
B
и С не знают, работает ли А (мертвый\живой).
Поэтому они хотят перехватить управление ресурсом, чтобы пользователь не заметил возможной смерти А.
Однако А жив (просто у него нет связи с остальными) и продолжает управлять ресурсом R.
Две изолированных группы нод управляют одним ресурсом R одновременно, что может привести к повреждению ресурса.
Возникает ситуация Split-Brain (“помутнение разума”).
Слайд 15
R
Split-Brain
Node A
Node B
Node C
R
Иллюстрация сломанного ресурса
Слайд 16
Fencing
Решение проблемы со Split-Brain: отрезать «выпавшей» ноде доступ
к ресурсу и самим управлять им
Два типа fencing:
Resource-fencing
Node-fencing
Слайд 17
Fencing
Node fencing:
Киллер на службе у кластера
(тупо гасит «плохую» ноду)
stonithd daemon
STONITH plugin
STONITH devices:
UPS
PDU
Blade power control
device
Lights-out devices
Testing devices
Слайд 18
Resource fencing
Resource fencing:
Кластер может иметь возможность контролировать определенные
устройства (например, дисковые массивы, свитчи и т. д.) для
того, чтобы запретить к ним доступ для «плохих» нод.
Слайд 19
Quorum
При Split-Brain каждая независимая группа нод будет пытаться
сделать STONITH другой группе нод.
Т. о. ничего работать
не будет (все умрут).
Поэтому нужен некий механизм арбитража, для выяснения, кого именно «грохнуть».
Логика кворума проста: если я могу
достучаться до более, чем N/2 нод,
то нужно убить другую группу нод.
Поэтому: выключайте кворум и
STONITH на 2-node-cluster, иначе
все повиснет.
Слайд 20
Архитектура HA-Cluster
Node
Node
Node
Node
Коммуникация между нодами
Управление ресурсами
Ресурс
Ресурс
Слайд 21
ПО HA-Cluster. Heartbeat
Node
Node
Node
Node
Heartbeat + Cluster Resource Manager
Управление ресурсами
Ресурс
Ресурс
Слайд 22
ПО HA-Cluster. Heartbeat + Pacemaker
Node
Node
Node
Node
Heartbeat
Pacemaker (CRM)
Ресурс
Ресурс
Слайд 23
ПО HA-Cluster. Corosync + Pacemaker
Node
Node
Node
Node
Corosync/OpenAIS
Pacemaker (CRM)
Ресурс
Ресурс
Слайд 24
ПО HA-Cluster. Corosync + RGManager
Node
Node
Node
Node
Corosync/OpenAIS
RGManager
Ресурс
Ресурс
CMAN
(RedHat Cluster Stack)
Слайд 30
Задание для получения 5 на экзамене
Сделать кластер с
балансировкой нагрузки, похожий на тот, который демонстрировался на лекции
Рекомендуемый
кластерный стек: Pacemaker + Corosync или Heartbeat
Рекомендуемый балансер: HAProxy
Рекомендуемая ОС - Debian
Виртуальные машины помогут вам (VmWare, VirtualPC, Xen, etc)
В конце семестра нужно будет продемонстрировать работу кластера и объяснить шаги его настройки