Seed node cassandra что это
Seed node cassandra что это
Запросы клиента на чтение и запись могут быть отправлены любому узлу в кластере. Когда клиент подключается к узлу с запросом, этот узел служит в качестве координатора для этой конкретной операции клиента. Координатор выступает в роли прокси между приложением клиента и узлами, в которых находятся данные запроса. Координатор определяет, какие узлы в цепи должны получить запрос, в зависимости от настроек кластера.
Основные компоненты
Основные компоненты настройки хранилища
При создании пространства ключей необходимо определить стратегию размещения реплики и необходимое количество копий.
Использующийся по умолчанию SimpleSnitch не распознает дата-центры и стойки информации. Его рекомендуется использовать для развертываний с одним дата-центром или для одиночной зоны в общедоступных облаках. GossipingPropertyFileSnitch рекомендован для промышленной эксплуатации. Он определяет узел дата-центра и стойку, и использует госсипы для распространения данной информации другим узлам.
Настройка и запуск кластера с несколькими узлами (один дата-центр)
Перед началом работы
Каждый узел должен быть правильно настроен перед запуском кластера. Необходимо определить или выполнить следующие действия перед началом работы:
Хорошо понимать, как работает Cassandra. Рекомендуется изучить как минимум следующие статьи:
Установить Cassandra на каждый узел.
Указать имя для кластера.
Получить IP-адрес для каждого узла.
Определить узлы, которые будут раздающими ( seed nodes ). Не нужно делать все узлы раздающими. Рекомендуется изучить протокол взаимодействия узлов (Internode communications (gossip)).
При использовании нескольких дата-центров требуется определить правила именования для каждого дата-центра и стойки (rack), например:
Будьте внимательны при указании имени: переименование дата-центра невозможно.
Другие возможные настройки конфигурации описаны в конфигурационном файле cassandra.yaml и в файле свойств cassandra-rackdc.properties
Установка чистого хранилища
Хранилище Cassandra устанавливается с помощью команды:
# aptitude install arta-synergy-jcr4c
После установки Cassandra проверить ее статус можно командой:
# service cassandra status
Процедура настройки
Предполагается, что Cassandra устанавливается на следующие узлы:
Примечание : рекомендуется делать более одного seed узла для одного дата-центра
Если на кластере запущен брандмауэр, необходимо открыть определенный порт для коммуникации между узлами. Подробнее об этом в статье Configuring firewall port access
Если Cassanra запущена, требуется остановить сервер и очистить данные: Выполните удаление для кластера по умолчанию cluster_name (Test Cluster) для системной таблицы. Все узлы должны использовать одно имя кластера.
Установите свойства в файле cassandra.yaml для каждого узла:
Примечание: после внесения любых изменений в файл cassandra.yaml необходимо перезапускать узел для применения этих изменений.
Параметры для установки:
num_tokens : рекомендуемое значение: 256
auto_bootstrap : false Добавлять этот параметр необходимо только при запуске нового кластера, не содержащего данных.
Примечание : если узлы в кластере идентичны в смысле дискового пространства, распределенных библиотек и т. д., можно использовать одинаковые копии файла cassandra.yaml для всех них.
Пример:
В файле cassandra-rackdc.properties для дата-центра и стоек требуется назначить имена, определенные перед началом работы. Например:
После установки и настройки Cassandra на всех узлах, сначала по одному запустите seed-узлы, потом запустите остальные узлы.
Примечание: если узел перезапустился из-за автоматического перезапуска, то сначала требуется остановить узел и очистить каталоги данных, как описано выше.
Для проверки того, что цепь запущена и работает, выполните:
для пакетной установки:
для установки из tar-архива:
Каждый узел должен быть указан в списке, и его статус должен быть UN (Up Normal): (илл. “ Проверка работы кластера ” ).
Figure 6.32. Проверка работы кластера
Миграция данных в хранилище Cassandra
Synergy поддерживает два типа миграции: стандартную и кастомную.
Стандартная миграция
Стандартная миграция предназначена для миграции всех версий документов и последних версий файлов.
Стандартная миграция может быть “ полной ” или “ ленивой ” :
полная миграция требует выполнения на остановленном jboss, работа пользователей в Synergy в это время невозможна;
ленивая миграция выполняется на запущенном jboss; работа пользователей в Synergy, хоть и замедляется, но может быть в продолжена в штатном режиме.
Процедура выполнения полной миграции :
установить пакет мигратора:
# aptitude install arta-synergy-jcrmigrator
запустить собственно миграцию:
после завершения миграции установить основной пакет Хранилища arta-synergy-jcr4c :
# aptitude install arta-synergy-jcr4c
Выполнение ленивой миграции :
установить пакет мигратора:
# aptitude install arta-synergy-jcrmigrator
запустить миграцию каркаса хранилища:
Выполнение команды занимает примерно 1 минуту на 200 документов.
При старте jboss версии документов начинают в “ ленивом ” режиме мигрировать из одного хранилища в другое. При каждом старте jboss выполняется вычисление количества оставшихся версий документов.
Обратите внимание: до завершения миграции запуск и работа jboss будут выполняться медленнее, чем обычно.
Проверка состояния нового хранилища, подсчет количества оставшихся версий (запускается только на остановленном jboss ):
Когда check сообщит, что все версии успешно мигрированы, можно ставить основной пакет Хранилища arta-synergy-jcr4c :
# aptitude install arta-synergy-jcr4c
Этот пакет установит хранилище на Cassandra, которое уже будет содержать мигрировавшие документы.
Миграция в режиме debug
Если требуется более подробный вывод хода миграции, а именно отображение документов, которые в данный момент в обработке, можно воспользоваться следующими командами:
Кастомная миграция
Кастомная миграция предназначена для миграции последних версий неудаленных документов реестров и личных карточек пользователей.
установить пакет мигратора:
# aptitude install arta-synergy-jcrmigrator
запустить миграцию последних версий всех документов в системе (записей реестров, документов в журналах):
При повторном выполнении команды будет осуществляться домиграция оставшихся документов.
После завершения миграции будет выведено сообщение:
Congratulations! You have fully migrated your documents storage to Cassandra.
При повторном выполнении команды будет осуществляться домиграция оставшихся файлов.
После завершения миграции будет выведено сообщение:
Congratulations! You have fully migrated your files storage to Cassandra.
запустить миграцию последних версий карточек пользователей:
Для карточек пользователей также предусмотрена домиграция при повторном выполнении команды.
После завершения миграции будет выведено сообщение:
Congratulations! You have fully migrated your personal cards storage to Cassandra.
запустить миграцию предыдущих версий документов, которые были мигрированы командой migrate_docs :
Аналогично, предусмотрена домиграция при повторном запуске. После завершения миграции будет выведено сообщение:
Congratulations! You have migrated all version of documents to Cassandra.
когда будет завершена миграция всех необходимых документов, можно установить основной пакет хранилища Cassandra:
Cassandra seed nodes and clients connecting to nodes
I’m a little confused about Cassandra seed nodes and how clients are meant to connect to the cluster. I can’t seem to find this bit of information in the documentation.
Do the clients only contain a list of the seed node and each node delegates a new host for the client to connect to? Are seed nodes only really for node to node discovery, rather than a special node for clients?
Should each client use a small sample of random nodes in the DC to connect to?
Or, should each client use all the nodes in the DC?
3 Answers 3
Answering my own question:
Seeds
Seeds are used during startup to discover the cluster.
The seed node designation has no purpose other than bootstrapping the gossip process for new nodes joining the cluster. Seed nodes are not a single point of failure, nor do they have any other special purpose in cluster operations beyond the bootstrapping of nodes.
From these details it seems that a seed is nothing special to clients.
Clients
From the DataStax documentation on client requests:
All nodes in Cassandra are peers. A client read or write request can go to any node in the cluster. When a client connects to a node and issues a read or write request, that node serves as the coordinator for that particular client operation.
The job of the coordinator is to act as a proxy between the client application and the nodes (or replicas) that own the data being requested. The coordinator determines which nodes in the ring should get the request based on the cluster configured partitioner and replica placement strategy.
I gather that the pool of nodes that a client connects to can just be a handful of (random?) nodes in the DC to allow for potential failures.
seed nodes serve two purposes.
the cassandra client contact points simply provide the cluster topology to the client, after which the client may connect to any node in the cluster. as such, they are similar to seed nodes and it makes sense to use the same nodes for both seeds and client contacts. however, you can safely configure as many cassandra client contact points as you like. the only other consideration is that the first node a client contacts sets its data center affinity, so you may wish to order your contact points to prefer a given data center.
for more details about contact points see this question: Cassandra Java driver: how many contact points is reasonable?
Как устроена apache cassandra
В этом топике я хотел бы рассказать о том, как устроена кассандра (cassandra) — децентрализованная, отказоустойчивая и надёжная база данных “ключ-значение”. Хранилище само позаботится о проблемах наличия единой точки отказа (single point of failure), отказа серверов и о распределении данных между узлами кластера (cluster node). При чем, как в случае размещения серверов в одном центре обработки данных (data center), так и в конфигурации со многими центрами обработки данных, разделенных расстояниями и, соответственно, сетевыми задержками. Под надёжностью понимается итоговая согласованность (eventual consistency) данных с возможностью установки уровня согласования данных (tune consistency) каждого запроса.
NoSQL базы данных требуют в целом большего понимания их внутреннего устройства чем SQL. Эта статья будет описывать базовое строение, а в следующих статьях можно будет рассмотреть: CQL и интерфейс программирования; техники проектирования и оптимизации; особенности кластеров размещённых в многих центрах обработки данных.
Модель данных
В терминологии кассандры приложение работает с пространством ключей (keyspace), что соответствует понятию схемы базы данных (database schema) в реляционной модели. В этом пространстве ключей могут находиться несколько колоночных семейств (column family), что соответствует понятию реляционной таблицы. В свою очередь, колоночные семейства содержат колонки (column), которые объединяются при помощи ключа (row key) в записи (row). Колонка состоит из трех частей: имени (column name), метки времени (timestamp) и значения (value). Колонки в пределах записи упорядочены. В отличие от реляционной БД, никаких ограничений на то, чтобы записи (а в терминах БД это строки) содержали колонки с такими же именами как и в других записях — нет. Колоночные семейства могут быть нескольких видов, но в этой статье мы будем опускать эту детализацию. Также в последних версиях кассандры появилась возможность выполнять запросы определения и изменения данных (DDL, DML) при помощи языка CQL, а также создавать вторичные индексы (secondary indices). 
С каждым значением связана метка времени — задаваемое пользователем число, которое используется для разрешения конфликтов во время записи: чем больше число, тем колонка считается новее, а при сравнении перетирает старые колонки.
По типам данных: пространство ключей и колоночное семейство — это строки (имена); метка времени — это 64-битное число; а ключ, имя колонки и значение колонки — это массив байтов. Также кассандра имеет понятие типов данных (data type). Эти типы могут по желанию разработчика (опционально) задаваться при создании колоночного семейства. Для имён колонок это называется сравнителем (comparator), для значений и ключей — валидатором (validator). Первый определяет какие байтовые значения допустимы для имён колонок и как их упорядочить. Второй — какие байтовые значение допустимы для значений колонок и ключей. Если эти типы данных не заданы, то кассандра хранит значения и сравнивает их как байтовые строки (BytesType) так как, по сути, они сохраняются внутри.
В кассандре все операции записи данных это всегда операции перезаписи, то есть, если в колоночную семью приходит колонка с таким же ключом и именем, которые уже существуют, и метка времени больше, чем та которая сохранена, то значение перезаписывается. Записанные значения никогда не меняются, просто приходят более новые колонки с новыми значениями.
Запись в кассандру работает с большей скоростью, чем чтение. Это меняет подход, который применяется при проектировании. Если рассматривать кассандру с точки зрения проектирования модели данных, то проще представить колоночное семейство не как таблицу, а как материализованное представление (materialized view) — структуру, которая представляет данные некоторого сложного запроса, но хранит их на диске. Вместо того, чтобы пытаться как-либо скомпоновать данные при помощи запросов, лучше постараться сохранить в коночное семейство все, что может понадобиться для этого запроса. То есть, подходить необходимо не со стороны отношений между сущностями или связями между объектами, а со стороны запросов: какие поля требуются выбрать; в каком порядке должны идти записи; какие данные, связанные с основными, должны запрашиваться совместно — всё это должно уже быть сохранено в колоночное семейство. Количество колонок в записи ограничено теоретически 2 миллиардами. Это краткое отступление, а подробней — в статье о техниках проектирования и оптимизации. А теперь давайте углубимся в процесс сохранения данных в кассандру и их чтения.
Распределение данных
Рассмотрим каким образом данные распределяются в зависимости от ключа по узлам кластера (cluster nodes). Кассандра позволяет задавать стратегию распределения данных. Первая такая стратегия распределяет данные в зависимости от md5 значения ключа — случайный разметчик (random partitioner). Вторая учитывает само битовое представление ключа — порядковый разметчик (byte-ordered partitioner). Первая стратегия, в большинстве своем, даёт больше преимуществ, так как вам не нужно заботиться о равномерном распределение данных между серверами и подобных проблемах. Вторую стратегию используют в редких случаях, например если необходимы интервальные запросы (range scan). Важно заметить, что выбор этой стратегии производится перед созданием кластера и фактически не может быть изменён без полной перезагрузки данных.
Для распределения данных кассандра использует технику, известную как согласованное хеширование (consistent hashing). Этот подход позволяет распределить данные между узлами и сделать так, что при добавлении и удалении нового узла количество пересылаемых данных было небольшим. Для этого каждому узлу ставится в соответствие метка (token), которая разбивает на части множество всех md5 значений ключей. Так как в большинстве случаев используется RandomPartitioner, рассмотрим его. Как я уже говорил, RandomPartitioner вычисляет 128-битный md5 для каждого ключа. Для определения в каких узлах будут храниться данные, просто перебираются все метки узлов от меньшего к большему, и, когда значение метки становится больше, чем значение md5 ключа, то этот узел вместе с некоторым количеством последующих узлов (в порядке меток) выбирается для сохранения. Общее число выбранных узлов должно быть равным уровню репликации (replication factor). Уровень репликации задаётся для каждого пространства ключей и позволяет регулировать избыточность данных (data redundancy).
Перед тем, как добавить узел в кластер, необходимо задать ему метку. От того, какой процент ключей покрывает промежуток между этой меткой и следующей, зависит сколько данных будет храниться на узле. Весь набор меток для кластера называется кольцом (ring).
Вот иллюстрация отображающая при помощи встроенной утилиты nodetool кольцо кластера из 6 узлов с равномерно распределенными метками.
Согласованность данных
Узлы кластера кассандры равноценны, и клиенты могут соединятся с любым из них, как для записи, так и для чтения. Запросы проходят стадию координации, во время которой, выяснив при помощи ключа и разметчика на каких узлах должны располагаться данные, сервер посылает запросы к этим узлам. Будем называть узел, который выполняет координацию — координатором (coordinator), а узлы, которые выбраны для сохранения записи с данным ключом — узлами-реплик (replica nodes). Физически координатором может быть один из узлов-реплик — это зависит только от ключа, разметчика и меток.
Для каждого запроса, как на чтение, так и на запись, есть возможность задать уровень согласованности данных.
Таким образом, можно регулировать временные задержки операций чтения, записи и настраивать согласованность (tune consistency), а также доступность (availability) каждой из видов операций. По сути, доступность напрямую зависит от уровня согласованности операций чтения и записи, так как он определяет, сколько узлов-реплик может выйти из строя, и при этом эти операции все ещё будут подтверждены.
Если число узлов, с которых приходит подтверждения о записи, в сумме с числом узлов, с которых происходит чтение, больше, чем уровень репликации, то у нас есть гарантия, что после записи новое значение всегда будет прочитано, и это называется строгой согласованностью (strong consistency). При отсутствии строгой согласованности существует возможность того, что операция чтения возвратит устаревшие данные.
В любом случае, значение в конце концов распространится между репликами, но уже после того, как закончится координационное ожидание. Такое распространение называется итоговой согласованностью (eventual consistency). Если не все узлы-реплики будут доступны во время записи, то рано или поздно будут задействованы средства восстановления, такие как чтение с исправлением и анти-энтропийное восстановление узла (anti-entropy node repair). Об этом чуть позже.
Таким образом, при уровне согласованности QUORUM на чтение и на запись всегда будет поддерживаться строгая согласованность, и это будет некий баланс между задержкой операции чтения и записи. При записи ALL, а чтении ONE будет строгая согласованность, и операции чтения будут выполняться быстрее и будут иметь большую доступность, то есть количество вышедших из строя узлов, при котором чтение все еще будет выполнено, может быть большим, чем при QUORUM. Для операций записи же потребуются все рабочие узлы-реплик. При записи ONE, чтении ALL тоже будет строгая согласованность, и операции записи будут выполняться быстрее и доступность записи будет большой, ведь будет достаточно подтвердить лишь, что операция записи прошла хотя бы на одном из серверов, а чтение — медленней и требовать всех узлов-реплик. Если же к приложению нету требования о строгой согласованности, то появляется возможность ускорить и операции чтения и операции записи, а также улучшить доступность за счет выставления меньших уровней согласованности.
Восстановление данных
Запись на диск
Когда данные приходят после координации на узел непосредственно для записи, то они попадают в две структуры данных: в таблицу в памяти (memtable) и в журнал закрепления (commit log). Таблица в памяти существует для каждого колоночного семейства и позволяет запомнить значение моментально. Технически это хеш-таблица (hashmap) с возможностью одновременного доступа (concurrent access) на основе структуры данных, называемой “списками с пропусками” (skip list). Журнал закрепления один на всё пространство ключей и сохраняется на диске. Журнал представляет собой последовательность операций модификации. Так же он разбивается на части при достижении определённого размера.
Такая организация позволяет сделать скорость записи ограниченной скоростью последовательной записи на жесткий диск и при этом гарантировать долговечность данных (data durability). Журнал закрепления в случае аварийного останова узла читается при старте сервиса кассандры и восстанавливает все таблицы в памяти. Получается, что скорость упирается во время последовательной записи на диск, а у современных жёстких дисков это порядка 100МБ/с. По этой причине журнал закрепления советуют вынести на отдельный дисковый носитель.
Понятно, что рано или поздно память может заполниться. Поэтому таблицу в памяти также необходимо сохранить на диск. Для определения момента сохранения существует ограничение объёма занимаемыми таблицами в памяти (memtable_total_spacein_mb), по умолчанию это ⅓ максимального размера кучи Java (Java heapspace). При заполнении таблицами в памяти объёма больше чем это ограничение, кассандра создает новую таблицу и записывает старую таблицу в памяти на диск в виде сохраненной таблицы (SSTable). Сохранённая таблица после создания больше никогда не модифицируется (is immutable). Когда происходит сохранение на диск, то части журнала закрепления помечаются как свободные, таким образом освобождая занятое журналом место на диске. Нужно учесть, что журнал имеет переплетённую структуру из данных разных колоночных семейств в пространстве ключей, и какие-то части могут быть не освобождены, так как некоторым областям будут соответствовать другие данные, все ещё находящиеся в таблицах в памяти.
Уплотнение
В определенный момент времени данные в колоночном семействе перезапишутся — придут колонки, которые будут иметь те же имя и ключ. То есть, возникнет ситуация, когда в более старой сохранённой таблице и более новой будут содержаться старые и новые данные. Для того, чтобы гарантировать целостность, кассандра обязана читать все эти сохранённые таблицы и выбирать данные с последней меткой времени. Получается, что количество операций позиционирования жёсткого диска при чтении пропорционально количеству сохранённых таблиц. Поэтому для того, чтобы освободить перезаписанные данные и уменьшить количество сохранённых таблиц, существует процесс уплотнения (compaction). Он читает последовательно несколько сохранённых таблиц и записывает новую сохранённую таблицу, в которой объединены данные по меткам времени. Когда таблица полностью записана и введена в использование, кассандра может освободить таблицы-источники(таблицами, которые её образовали). Таким образом, если таблицы содержали перезаписанные данные, то эта избыточность устраняется. Понятно, что во время такой операции объем избыточности увеличивается — новая сохранённая таблица существует на диске вместе с таблицами-источниками, а это значит, что объем места на диске всегда должен быть такой, чтобы можно было произвести уплотнение.
Операции удаления
С точки зрения внутреннего устройства, операции удаление колонок — это операции записи специального значения — затирающего значения (tombstone). Когда такое значение получается в результате чтения, то оно пропускается, словно такого значения никогда и не существовало. В результате же уплотнения, такие значения постепенно вытесняют устаревшие реальные значения и, возможно, исчезают вовсе. Если же появятся колонки с реальными данными с еще более новыми метками времени, то они перетрут, в конце концов, и эти затирающие значения.
Транзакционность
Послесловие
Итак, мы рассмотрели как устроены основные операции — чтение и запись значений в кассандру.
Просьба: замечания по орфографии и идеи по улучшению статьи высказывайте в личном сообщении.