Базы данных, совместно использующие диски в SMP-системах

Оценить
(0 голоса)

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

Базы данных, совместно использующие диски, запускают отдельный экземпляр базы данных в каждой SMP-системе кластера, однако от моделей, не предусматривающих совместное использование, они отличаются тем, что все данные на дисках доступны из каждого SMP-сервера. Более того, все экземпляры обладают одновременным доступом ко всему набору данных базы. Другими словами, несколько экземпляров совместно используют одну базу данных. Поскольку база данных используется ими совместно, то DLM (Distributed Lock Manager - менеджер распределенных блокировок) выполняет координирование доступа к данным для надежного обслуживания когерентности кэша и сохранения целостности данных при совместном доступе.

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

В системах OLTP оптимальная производительность баз данных, совместно использующих диски, может быть достигнута путем обращения к подмножествам данных в первую очередь (или даже исключительно) через один узел кластера. Предположим, например, что доступ к данным базы страхования обычно концентрируется вокруг шестизначного страхового идентификатора. Для кластера, состоящего из двух узлов, все транзакции, относящиеся к значениям идентификатора от 0 до 499999, могут быть направлены в первую систему, в то время как транзакции, относящиеся к значениям идентификатора от 500000 до 999999, направляются во вторую систему. Несмотря на то, что обе системы способны обращаться ко всем данным, однако строки, связанные с определенным идентификатором, могут быть доступны и кэшированы только в одной системе, исключая совместно используемые данные и, естественно, трафик данных между системами для синхронизации каждого кэша. Но если в узле происходит сбой, другой узел может принять на себя доступ ко всему набору данных. Важно отметить, что разделяются не данные, а только доступ к ним.

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

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

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

Базы данных в SMP, не предусматривающие совместное использование
Характеристики логических узлов
Масштабируемость очереди
Делить на разделы или нет?
Архитектура аппаратных средств и базы данных

Добавить комментарий


Защитный код
Обновить