Архитектура без разделения ресурсов

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 19:43, 21 января 2019.
Версия от 19:43, 21 января 2019; nickolay altukhov (обсуждение | вклад)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)

Архитектура без разделения ресурсов (англ. shared-nothing architecture) - архитектура, в которой выполнение приложения возлагается на один из физических серверов, в то время как другие серверы (узлы) ждут в резерве, пока не произойдет отказ первого физического сервера, чтобы начать действовать, взяв на себя выполнение этого приложения. В каждый момент времени это приложение выполняется только каким-либо одним сервером. (Эта архитектура известна также под названием "active/passive" - с одним активным и несколькими пассивными компонентами).[Источник 1]

Преимущества архитектуры SN (shared-nothing) по сравнению с центральным объектом, который управляет сетью (архитектура на основе контроллера), включают в себя устранение любой отдельной точки отказа, возможность самовосстановления и предоставление преимущества, предлагая обновление без прерывания работы.

История

Хотя SN лучше всего известна в контексте веб-разработки, эта концепция предшествует сети: Майкл Стоунбрейкер из Университета Калифорнии, Беркли, использовал этот термин в статье 1986 года. В нем он упоминает о существующих коммерческих реализациях архитектуры (хотя ни одна не названа явно). Teradata, которая поставила свою первую систему в 1983 году, была, вероятно, одной из тех коммерческих реализаций. Tandem Computers официально выпустила NonStop SQL, базу данных без общего доступа, в 1984 году.

Особенности

Рисунок 1 - Концепция shared-nothing architecture

Как и в архитектуре с общими дисками, в этой архитектуре поддерживается единый образ базы данных при работе с несколькими компьютерами, работающими под управлением своих копий операционных систем. Однако в этой архитектуре каждый узел системы имеет собственную ОЗУ и собственные диски, которые не разделяются между отдельными узлами системы. Практически в таких системах разделяется только общий коммуникационный канал между узлами системы. Производительность таких систем может увеличиваться путем добавления процессоров, объемов оперативной и внешней (дисковой) памяти в каждом узле, а также путем наращивания количества таких узлов.

SN популярна для веб-разработки из-за своей масштабируемости. Как продемонстрировала Google, "чистая" система SN может масштабироваться просто путем добавления узлов в виде недорогих компьютеров, поскольку нет единого узкого места для замедления работы системы. Google называет это шардингом. Система SN обычно распределяет свои данные между многими узлами в разных базах данных (назначая разные компьютеры для работы с разными пользователями или запросами), или может потребовать, чтобы каждый узел сохранял свою собственную копию данных приложения, используя некоторый протокол согласования.

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

Архитектура без разделения ресурсов стала преобладающим в пространстве хранилищ данных. SN, безусловно, требует больше времени для ответа на запросы, которые включают в себя объединения больших наборов данных из разных разделов (машин). Тем не менее, потенциал для масштабирования огромен.

Хотя в программных / аппаратных компонентах систем SN нет единой точки отказа, в какой-то момент может потребоваться реинтеграция информации от разрозненных узлов. Такие точки возникают везде, где информационная система, находящаяся за пределами архитектуры SN, запрашивает информацию из разных узлов в архитектуре SN с единственной целью. Примерами таких внешних узлов могут быть:

  • субъекты которые смотрят на два узла SN и решают, что они хранят или обрабатывают данные об одном и том же (достаточно просто признать, что два узла принадлежат одной и той же системе SN)
  • любая программно-аппаратная система, которая написана для запроса различных узлов в архитектуре SN

Сравнение

В таблице 1 приведено сравнение 3-х различных архитектур. Каждая архитектура оценивается цифрами 1, 2 или 3. Градация сложности, качества и возможностей начинается с цифры "1" и заканчивается цифрой "3", от меньшего к большему, соответственно.

Таблица 1. Сравнение архитектур
Системная особенность Shared-nothing Shared memory Shared disk
сложность управления параллелизмом 2 2 3
сложность восстановления после сбоя 2 1 3
сложность проектирования базы данных 3 2 2
сложность балансировки нагрузки 3 1 2
сложность высокой доступности 1 3 2
количество сообщений 3 1 2
необходимая пропускная способность 1 3 2
возможность масштабирования на большое количество машин 1 3 2
способность иметь большие расстояния между машинами 1 3 2
восприимчивость к критическим участкам 1 3 2
количество системных образов 3 1 3
восприимчивость к горячим точкам 3 3 3

Исходя из таблицы, можно сделать вывод, что SN предлагает наиболее жизнеспособную и экономически эффективную архитектуру. Количество сообщений не должно быть проблемой для общего случая, горячие точки должны быть разрешимы с использованием традиционных методов, более крупные транзакционные системы в лучшем случае не представляют дополнительных трудностей, а в худшем случае усугубляют проблему горячей точки.[Источник 2]

Проблемы с Shared Nothing

Уравновешивание нагрузки базы данных SN путем перераспределения является естественным расширением такого вспомогательного средства проектирования. Более того, приложения, которые имеют стабильный или медленно меняющийся шаблон доступа, будут успешно реагировать на такое обращение и будут называться настраиваемыми. Только базы данных с периодическими или непредсказуемыми схемами доступа будут неуправляемыми, и я ожидаю, что такие базы данных будут относительно необычными. Следовательно, балансировка нагрузки и проектирование базы данных не должны быть серьезными проблемами в типичных средах. Горячие точки являются проблемой во всех архитектурах, и для их решения существует как минимум три метода.

  • избавиться от них
  • разделить запись горячей точки на N подзаписей
  • использовать некоторую реализацию системы бронирования.

Источники

  1. НОУ ИНТУИТ. [2003-2019]. Дата обновления: 01.02.2012. URL: https://www.intuit.ru/studies/courses/1114/301/lecture/7503?page=3/ (дата обращения 23.12.2018)
  2. The Case for Shared Nothing Architecture by Michael Stonebraker. [Originally published in Database Engineering, Volume 9, Number 1 (1986). [1986]. Дата обновления: 1986. URL: http://db.cs.berkeley.edu/papers/hpts85-nothing.pdf/ (дата обращения 23.12.2018)