Теорема CAP является краеугольным камнем теории распределенных систем.
Конечно, споры вокруг нее не утихают: определения в ней не каноничны, а строгого доказательства нет. Тем не менее, твердо стоя на позициях житейского здравого смысла™, мы интуитивно понимаем, что теорема верна.
Единственное, что не очевидно, так это значение буквы «П».
Когда кластер разделен, он решает, не отвечать ли ему до тех пор, пока не будет достигнут кворум, или вернуть доступные данные.
В зависимости от результатов такого выбора система классифицируется либо как КП, либо как АП.
Кассандра, например, может вести себя как угодно, в зависимости даже не от настроек кластера, а от параметров каждого конкретного запроса.
А если система не «П» и она распадается, то что? Ответ на этот вопрос несколько неожиданный: кластер CA не может расщепляться.
Что это за кластер, который не может расщепиться? Непременный атрибут такого кластера — общая система хранения данных.
В подавляющем большинстве случаев это означает подключение через SAN, что ограничивает использование решений CA только крупными предприятиями, способными поддерживать инфраструктуру SAN. Чтобы несколько серверов могли работать с одними и теми же данными, необходима кластерная файловая система.
Такие файловые системы доступны в портфолио HPE (CFS), Veritas (VxCFS) и IBM (GPFS).
Oracle RAC
Опция Real Application Cluster впервые появилась в 2001 году с выпуском Oracle 9i. В таком кластере с одной базой данных работают несколько экземпляров сервера.Oracle может работать как с кластерной файловой системой, так и с собственным решением — ASM, Automatic Storage Management. Каждый экземпляр ведет свой собственный журнал.
Транзакция выполняется и фиксируется одним экземпляром.
В случае сбоя экземпляра один из выживших узлов кластера (экземпляров) читает его журнал и восстанавливает утерянные данные — тем самым обеспечивая доступность.
Все инстансы поддерживают свой собственный кеш, и одни и те же страницы (блоки) могут одновременно находиться в кешах нескольких инстансов.
Более того, если одному экземпляру нужна страница и она находится в кеше другого экземпляра, он может получить ее от соседа, используя механизм слияния кеша вместо чтения с диска.
Но что произойдет, если одному из экземпляров потребуется изменить данные?
Особенность Oracle в том, что у него нет выделенного сервиса блокировки: если сервер хочет заблокировать строку, то запись блокировки помещается непосредственно на страницу памяти, где находится заблокированная строка.
Благодаря такому подходу Oracle является лидером по производительности среди монолитных баз данных: служба блокировки никогда не становится узким местом.
Но в конфигурации кластера такая архитектура может привести к интенсивному сетевому трафику и взаимоблокировкам.
Как только запись заблокирована, экземпляр уведомляет все остальные экземпляры о том, что страница, на которой хранится эта запись, имеет эксклюзивное удержание.
Если другому экземпляру необходимо изменить запись на той же странице, он должен дождаться, пока изменения на странице будут зафиксированы, т. е.
информация об изменении запишется в журнал на диске (и транзакция может продолжиться).
Также может случиться так, что страница будет изменена последовательно несколькими копиями, и тогда при записи страницы на диск вам придется узнать, кто хранит текущую версию этой страницы.
Случайное обновление одних и тех же страниц на разных узлах RAC приводит к резкому падению производительности базы данных до такой степени, что производительность кластера может оказаться ниже, чем у одного экземпляра.
Правильное использование Oracle RAC заключается в физическом секционировании данных (например, с использованием механизма секционированных таблиц) и доступе к каждому набору секций через выделенный узел.
Основной целью RAC было не горизонтальное масштабирование, а обеспечение отказоустойчивости.
Если узел перестает отвечать на тактовый сигнал, то узел, обнаруживший его первым, запускает процедуру голосования на диске.
Если здесь не указан недостающий узел, то ответственность за восстановление данных берет на себя один из узлов:
- «замораживает» все страницы, которые находились в кеше отсутствующего узла;
- читает логи (redo) отсутствующего узла и повторно применяет записанные в этих журналах изменения, попутно проверяя, есть ли на других узлах более свежие версии изменяемых страниц;
- откатывает ожидающие транзакции.
Экземпляр может обслуживать несколько сервисов, а сервис может перемещаться между узлами.
Экземпляр приложения, обслуживающий определенную часть базы данных (например, группу клиентов), работает с одним сервисом, а сервис, отвечающий за эту часть базы данных, при выходе узла из строя перемещается на другой узел.
IBM Pure Data Systems для транзакций
Кластерное решение для СУБД появилось в портфолио Blue Giant в 2009 году.Идеологически оно является преемником кластера Parallel Sysplex, построенного на «обычном» оборудовании.
В 2009 году был выпущен пакет программного обеспечения DB2 pureScale, а в 2012 году IBM предложила устройство под названием Pure Data Systems for Transactions. Не следует путать ее с Pure Data Systems for Analytics, которая представляет собой не что иное, как переименованную Netezza. На первый взгляд архитектура pureScale похожа на Oracle RAC: точно так же несколько узлов подключены к общей системе хранения данных, и на каждом узле работает свой экземпляр СУБД со своими областями памяти и журналами транзакций.
Но, в отличие от Oracle, DB2 имеет специальную службу блокировки, представленную набором процессов db2LLM*.
В кластерной конфигурации эта служба размещается на отдельном узле, который в Parallel Sysplex называется соединительным средством (CF), а в Pure Data — PowerHA. PowerHA предоставляет следующие услуги:
- менеджер блокировок;
- глобальный буферный кеш;
- область межпроцессных коммуникаций.
Если узлу нужна страница, а этой страницы нет в кеше, то узел запрашивает страницу в глобальном кеше и только если ее там нет, считывает ее с диска.
В отличие от Oracle, запрос идет только к PowerHA, а не к соседним узлам.
Если экземпляр собирается изменить строку, он блокирует ее в монопольном режиме, а страницу, на которой находится строка, в совместно используемом режиме.
Все блокировки регистрируются в глобальном менеджере блокировок.
Когда транзакция завершается, узел отправляет сообщение менеджеру блокировок, который копирует измененную страницу в глобальный кэш, снимает блокировки и делает измененную страницу недействительной в кэшах других узлов.
Если страница, на которой находится измененная строка, уже заблокирована, то менеджер блокировок прочитает измененную страницу из памяти узла, внесшего изменение, снимет блокировку, сделает измененную страницу недействительной в кэшах других узлов и передать блокировку страницы узлу, который ее запросил.
«Грязные», то есть измененные, страницы могут быть записаны на диск как с обычной ноды, так и с PowerHA (castout).
В случае сбоя одного из узлов pureScale восстановление ограничивается только теми транзакциями, которые еще не были завершены на момент сбоя: страницы, измененные этим узлом в завершенных транзакциях, находятся в глобальном кэше PowerHA. Узел перезапускается в сокращенной конфигурации на одном из серверов кластера, откатывает ожидающие транзакции и снимает блокировки.
PowerHA работает на двух серверах, и главный узел синхронно реплицирует свое состояние.
В случае сбоя основного узла PowerHA кластер продолжает работать с резервным узлом.
Конечно, если вы получаете доступ к набору данных через один узел, общая производительность кластера будет выше.
PureScale может даже заметить, что определенная область данных обрабатывается одним узлом, и тогда все блокировки, относящиеся к этой области, будут обрабатываться локально узлом без связи с PowerHA. Но как только приложение попытается получить доступ к этим данным через другой узел, централизованная обработка блокировки возобновится.
Внутренние тесты IBM при рабочей нагрузке 90% чтения и 10% записи, что очень похоже на реальные производственные рабочие нагрузки, показывают почти линейное масштабирование до 128 узлов.
Условия испытаний, к сожалению, не разглашаются.
HPE NonStop SQL
В портфолио Hewlett-Packard Enterprise также имеется собственная платформа высокой доступности.Это платформа NonStop, выпущенная на рынок в 1976 году компанией Tandem Computers. В 1997 году компания была приобретена Compaq, которая, в свою очередь, в 2002 году объединилась с Hewlett-Packard. NonStop используется для построения критически важных приложений — например, HLR или процессинга банковских карт. Платформа поставляется в виде программно-аппаратного комплекса (устройства), включающего в себя вычислительные узлы, систему хранения данных и оборудование связи.
Сеть ServerNet (в современных системах — Infiniband) служит как для обмена между узлами, так и для доступа к системе хранения данных.
В ранних версиях системы использовались фирменные процессоры, синхронизированные между собой: все операции выполнялись синхронно несколькими процессорами, и как только один из процессоров допускал ошибку, он отключался, а второй продолжал работать.
Позже система перешла на обычные процессоры (сначала MIPS, затем Itanium и, наконец, x86), а для синхронизации стали использоваться другие механизмы:
- сообщения: у каждого системного процесса есть «теневой» двойник, которому активный процесс периодически отправляет сообщения о своем статусе; при сбое основного процесса теневой процесс начинает работать с момента, определенного последним сообщением;
- голосование: в системе хранения имеется специальный аппаратный компонент, который принимает множественные одинаковые доступы и выполняет их только в случае совпадения доступов; Вместо физической синхронизации процессоры работают асинхронно, и результаты их работы сравниваются только в моменты ввода-вывода.
Он обеспечивает механизмы записи, кэширования и блокировки данных.
Обработка данных осуществляется серверными процессами-исполнителями, работающими на тех же узлах, что и соответствующие менеджеры данных.
Планировщик SQL/MX распределяет задачи между исполнителями и агрегирует результаты.
Когда необходимо внести согласованные изменения, используется протокол двухфазной фиксации, предоставляемый библиотекой TMF (Transaction Management Facility).
NonStop SQL может определять приоритеты процессов, чтобы длинные аналитические запросы не мешали выполнению транзакций.
Однако его целью является именно обработка коротких транзакций, а не аналитика.
Разработчик гарантирует доступность кластера NonStop на уровне пяти «девяток», то есть время простоя составляет всего 5 минут в год.
SAP Хана
Первый стабильный выпуск СУБД HANA (1.0) состоялся в ноябре 2010 года, а пакет SAP ERP перешёл на HANA в мае 2013 года.Платформа основана на закупленных технологиях: TREX Search Engine (поиск в колоночном хранилище), P* СУБД ВРЕМЕНИ и МАКС БД.
Само слово «HANA» является аббревиатурой «Высокопроизводительное аналитическое устройство».
Данная СУБД поставляется в виде кода, который может работать на любых x86-серверах, но промышленная установка допускается только на сертифицированном оборудовании.
Доступны решения HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Некоторые конфигурации Lenovo допускают работу даже без SAN — роль общей системы хранения играет GPFS-кластер на локальных дисках.
В отличие от платформ, перечисленных выше, HANA представляет собой in-memory СУБД, т.е.
основной образ данных хранится в оперативной памяти, а на диск записываются только логи и периодические снимки для восстановления в случае сбоя.
Каждый узел кластера HANA отвечает за свою часть данных, а карта данных хранится в специальном компоненте — Name Server, расположенном на узле-координаторе.
Данные не дублируются между узлами.
Информация о блокировке также хранится на каждом узле, но в системе имеется глобальный детектор взаимоблокировок.
Когда клиент HANA подключается к кластеру, он загружает его топологию и затем может напрямую получить доступ к любому узлу, в зависимости от того, какие данные ему нужны.
Если транзакция затрагивает данные одного узла, то она может быть выполнена локально этим узлом, но если данные нескольких узлов изменяются, узел-инициатор связывается с узлом-координатором, который открывает и координирует распределенную транзакцию, фиксируя ее с помощью оптимизированный протокол двухфазной фиксации.
Узел-координатор дублируется, поэтому в случае выхода из строя координатора его немедленно берет на себя резервный узел.
Но если узел с данными выйдет из строя, то единственный способ получить доступ к его данным — перезапустить узел.
Как правило, кластеры HANA содержат запасной сервер, чтобы как можно быстрее перезапустить на нем потерянный узел.
Теги: #Хранение данных #Высокая производительность #Распределенные системы #oracle #HP #rac #db2 #hana #pure data #NonStop #cap-теорема
-
Ипотека
19 Oct, 24 -
Супер-Пупер Безопасный Режим
19 Oct, 24 -
Какие Цветовые Схемы Вы Используете В Ide?
19 Oct, 24 -
Филологи И Компьютеры (Нервные)
19 Oct, 24 -
Google Leanback — Забота Старшего Брата
19 Oct, 24
