36. Понятие кластера. Аппаратная и программная реализация кластера.Масштабируемость и отказоустойчивость кластерных решений.
Кластер — группа компьютеров, объединённых высокоскоростными каналами связи, представляющая с точки зрения пользователя единый аппаратный ресурс.
Кластер - слабо связанная совокупность нескольких вычислительных систем, работающих совместно для выполнения общих приложений, и представляющихся пользователю единой системой.
Кластер состоит из двух или более взаимосвязанных машин — узлов кластера.
Узлы кластера «видны» снаружи как единое целое.
Внутренняя структура кластера «скрывается» кластерным ПО — все кластеры «выглядят»
снаружи как обычные серверы БД.
Все диски доступны для чтения и записи всем узлам кластера.
На всех узлах кластера используется одна и та же версия ОС.
Кластер мб либо отказоустойчивым, либо масштабируемым. Упор на что-то одно.
Уровни масштабируемости
Для того, чтобы использование кластера было эффективным, требуется обеспечить масштабируемость на всех уровнях:
Аппаратный — скорость чтения / записи на диски.
Взаимодействие между узлами — пропускная способность сети и время отклика.
Операционная система — возможность работы на многопроцессорных машинах.
СУБД — синхронизация при параллельном доступе к данным.
Приложение — особенности архитектуры.
Два варианта масштабирования: горизонтальное и вертикальное.
Большинство компьютерных систем допускают несколько способов повышения их производительности: добавление памяти, увеличение числа процессоров в многопроцессорных системах или добавление новых адаптеров или дисков. Такое масштабирование называется вертикальным и позволяет временно улучшить производительность системы. Однако в системе будет установлено максимальное поддерживаемое количество памяти, процессоров или дисков, системные ресурсы будут исчерпаны. И пользователь столкнется с той же проблемой улучшения характеристик компьютерной системы, что и ранее.
Горизонтальное масштабирование предоставляет возможность добавлять в систему дополнительные компьютеры и распределять работу между ними. Таким образом, производительность новой системы в целом выходит за пределы предыдущей. Естественным ограничением такой системы будет программное обеспечение, которые вы решите на ней запускать. Самым простым примером использования такой системы является распределение различных приложений между разными компонентами системы. Например, вы можете переместить ваши офисные приложения на один кластерный узел приложения для Web на другой, корпоративные базы данных — на третий. Однако здесь возникает вопрос взаимодействия этих приложений между собой. И в этом случае масштабируемость обычно ограничивается данными, используемыми в приложениях. Различным приложениям, требующим доступ к одним и тем же данным, необходим способ, обеспечивающий доступ к данным с различных узлов такой системы. Решением в этом случае становятся технологии, которые, собственно, и делают кластер кластером, а не системой соединенных вместе машин. При этом, естественно, остается возможность вертикального масштабирования кластерной системы. Таким образом, за счет вертикального и горизонтального масштабирования кластерная модель обеспечивает серьезную защиту инвестиций потребителей.
В качестве варианта горизонтального масштабирования стоит также отметить использование группы компьютеров, соединенных через коммутатор, распределяющий нагрузку (технология Load Balancing).
Отказоустойчивость
Под отказоустойчивостью понимается доступность тех или иных функций в случае сбоя, другими словами, это резервирование функций и распределение нагрузки.
Приведем пример серверного кластера: каждый сервер в кластере остается относительно независимым, то есть его можно остановить и выключить (например, для проведения профилактических работ или установки дополнительного оборудования), не нарушая работоспособность кластера в целом. Тесное взаимодействие серверов, образующих кластер (узлов кластера), гарантирует максимальную производительность и минимальное время простоя приложений за счет того, что:
в случае сбоя программного обеспечения на одном узле приложение продолжает функционировать (либо автоматически перезапускается) на других узлах кластера;
сбой или отказ узла (или узлов) кластера по любой причине (включая ошибки персонала) не означает выхода из строя кластера в целом;
профилактические и ремонтные работы, реконфигурацию и смену версий программного обеспечения в большинстве случаев можно осуществлять на узлах кластера поочередно, не прерывая работу приложений на других узлах кластера.
Возможные простои, которые не в состоянии предотвратить обычные системы, в кластере оборачиваются либо некоторым снижением производительности (если узлы выключаются из работы), либо существенным сокращением (приложения недоступны только на короткий промежуток времени, необходимый для переключения на другой узел), что позволяет обеспечить уровень готовности в 99,99%.
37. Основные принципы построения масштабируемых приложений. Speedup & Scaleup.
ScaleUp - способность сохранять те же самые уровни производительности (время отклика), когда и нагрузка (транзакции) и ресурсы (процессор, память) пропорционально возрастают.
Например, если 50 пользователей потребляют почти 100 процентов ЦП, затем добавить больше пользователей, то система замедлится из-за конкуренции за ограниченные ресурсы ЦП. Однако, за счет добавления новых ЦП, мы можем добавить новых пользователей без снижения производительности.
ScaleUp увеличивает пропускную способность, т.е. количество задач, выполняемых в данный момент времени, увеличивается.
Speedup - эффект применения большого количества ресурсов для фиксированного объема работ для достижения пропорционального снижение времени выполнения:
Speedup достигается за счет наличия ресурсов для других задач. Например, если запросы обрабатываются, как правило, десять минут одним ЦП, то параллельная работа нескольких ЦП сокращает время.
SPEED UP
|
SCALE UP
|
Улучшает время отклика
|
Улучшает пропускную способность
|
As you multiply resources by a certain factor, the time taken to execute a transaction should be reduced by the same factor:
|
As you multiply resources the size of a task that can be executed in a given time should be increased by the same factor.
|
10 seconds to scan a DB of 10,000 records using 1 CPU
1 second to scan a DB of 10,000 records using 10 CPUs
|
1 second to scan a DB of 1,000 records using 1 CPU
1 second to scan a DB of 10,000 records using 10 CPUs
|
Концентрируется на времени, что значит улучшение временем отклика т.е. ускорение.
|
Концентрируется на данных, что значит улучшение масштабируемости.
|
|
|
38. Глобальные ресурсы Oracle RAC, особенности управления ими. Глобальные DPV.
Архитектура Oracle RAC
Зачем нужны глобальные ресурсы?
Управление глобальными ресурсами
Синхронизация глобального кэша
Координация записи на диск
Глобальные DPV
Содержат информацию обо всех запущенных экземплярах в составе кластера. У каждого локального представления (V$) есть соответствующее ему глобальное представление (GV$).
Исполняются параллельно на всех узлах кластера — «ведущий» запрос на узле, к которому осуществляется обращение и «ведомые» запросы к V$ на остальных узлах.
Параллелизмом управляет специальный сервис — координатор параллельного исполнения (Parallel Execution Coordinator, PEC).
39. Архитектура Oracle RAC: процессы, конфигурационные файлы, файлы БД.
Процессы
Конфигурационные файлы
Появляются 2 новых категории файлов
Файлы с результатами мониторинга состояния кластера.
Файлы OCR — Oracle Cluster Registry.
Файлы OCR не могут храниться в ASM, т. к. они должны быть доступны ещё до запуска кластера.
Файлы БД
40. Варианты построения системы хранения в Oracle RAC, их преимущества и недостатки.
Преимущества CFS:
Проще администрировать.
Ставится вместе с Oracle, не нужна дополнительная конфигурация.
Автоматически расширяется по мере возрастания объёма данных.
Можно использовать для хранения файлов архива журнала повторов.
Преимущества raw:
Потенциально быстрее.
Ниже требования к инфраструктуре.
Можно использовать ASM для расширения возможностей.
В разделяемом пространстве можно хранить файлы данных (database files), данные для восстановления (recovery files), исполняемые файлы (binaries), OCR(Oracle Custer Registry) и Voting Files.
RAW devices (сырые устройства) - специальные символьные (character) устройства, предназначенные для организации доступа к блочным устройствам без кэширования.
Гарантирована запись, исключена проблема двойной буферизации (в СУБД и ОС), ниже требования к инфраструктуре, потенциально быстрее всех, можно использовать ASM для расширения.
Для Oracle 1 raw устройство == 1 файлу => нужно много файлов, средствами ОС (df, ls -l) не оценить используемое дисковое пространство и не сделать бэкап/восстановление, можно хранить только файлы БД, не поддерживаются с Oracle 12g
CFS (Clustered File System) - эмулирует традиционную ФС с дополнительными возможностями по управлению разделяемыми данными и метаданными
Просто администрировать, все скрипты работают так же как и локальной ФС, можно хранить не только файлы БД(архив журнала повторов), OCFS ставится вместе с Oracle, автоматически расширяется.
- Сложность начальной конфигурации, возможно уменьшается производительность, в стек БД добавляется новый продукт.
ASM (Automatic Storage Management) рекомендация Oracle для всего, кроме бинарников. ASM - урезанный экземпляр Oracle
нет требования один диск == один файл, добавляет поддержку RAID, кроссплатформенность, благодаря зеркалированию не нужно полностью восстанавливать данные на диске при его падении
- не во всех версиях Oracle можно хранить любые файлы, не относящиеся к БД
NFS (Network File System) + RAC - выглядит как CFS
все компоненты БД можно хранить в NFS (+исполняемые), NFS сервер имеет больше функциональных возможностей, чем raw devices
Часто обходится дороже чем raw, некоторая нагрузка может не масштабироваться, в мире баз данных уже считается устаревшей, медленной и ненадежной технологией.
Все перечисленные технологии могут комбинироваться
|
