Библиотека сайта rus-linux.net
Riak и Erlang/OTP
Глава 15 из книги "Архитектура приложений с открытым исходным кодом", том 1.
Оригинал: "Riak and Erlang/OTP", глава из книги "The Architecture of Open Source Applications"
Авторы: Francesco Cesarini, Andy Gross and Justin Sheehy
Перевод: Н.Ромоданов
Creative Commons: Перевод был сделан в соответствие с лицензией Creative Commons. С русским вариантом лицензии можно ознакомиться здесь.
15.6. Репликация и коммуникация в Riak
Riak был разработан для обеспечения высокой надежности и доступности при массовых нагрузках, причем на его разработку оказала влияние система хранения данных Dynamo компании Amazon [DHJ +07]. В архитектуре систем Dynamo and Riak объединены вместе особенности как распределенных хэш-таблиц DHT (Distributed Hash Tables), так и традиционных баз данных. Двумя ключевыми технологиями, которые используются в Riak и Dynamo, являются последовательное хеширование (consistent hashing), применяемое для размещения реплики, и протокол сплетен (gossip protocol), используемое для совместного доступа к общему состоянию.
Последовательное хеширование требует, чтобы все узлы системы знали друг о друге, и знали, каким разделом системы владеет каждый узел. Такие данные о назначениях можно хранить в централизованно управляемом конфигурационном файле, но для больших конфигураций это делать становится чрезвычайно трудно. Другой альтернативой является использование центрального конфигурационного сервера, но в результате в системе появляется место, из-за проблем в котором может произойти выход из строя всей системы. Вместо этого в Riak используется протокол сплетен, с помощью которого данные о вхождении узлов в кластер и принадлежности разделов системы распространяются по всей системе.
Протоколы сплетен, которые также называются протоколами эпидемий (epidemic protocols), работают именно так, как они называются. Когда узел в системе желает изменить часть совместно используемых данных, он делает изменения в своей локальной копии данных и сообщает об этом (сплетничает) другому узлу — своему случайному собеседнику. После получения обновления, узел объединяет полученные изменения со своим собственным локальным состоянием и еще раз сплетничает с другим случайным собеседником.
Когда кластер Riak запускается, все узлы должны быть сконфигурированы так, что в каждом из них находится одинаковое количество разделов. Затем кольцо последовательного хеширования делится на количество разделов, и каждый интервал запоминается в виде пары {HashRange, Owner} (хэш-кольцо, владелец). Первый узел в кластере просто объявляет об этом всем разделам. Когда в кластер добавляется новый узел, он в существующем узле добавляется в список пар {HashRange, Owner} этого узла. Затем объявляется о парах (количество разделов)/(число узлов), обновляется локальное состояние, которое будет отражать новое распределение разделов. Затем информация о распределении разделов будет с помощью протокола сплетен передана другому узлу. А затем это обновленное состояние будет с помощью описанного ранее алгоритма распространено по всему кластеру.
При использовании протокола сплетен в Riak не появляется единое место отказа в виде централизованного конфигурационного сервера, что избавляет системных операторов от необходимости хранить критически важные конфигурационные данные о кластере. В этом случае любой узел может в системе маршрутизации запросов использовать данные о назначении разделов, полученные с помощью протокола сплетен. Совместное использование протокола сплетен и последовательного хэширования позволяет системе Riak действительно функционировать как децентрализованная система, что очень важно при развертывании и эксплуатации крупномасштабных систем.
Продолжение статьи: Заключение и усвоенные уроки.