Pull to refresh

Comments 16

Говоря о миграции Cassandra в Kubernetes, мы надеемся, что с переездом управлять ей станет удобнее.


Можно поподробнее, в чем улучшилось удобство управления после миграции?
Конкретно в нашем случае — удобнее готовить новый узел. Инфраструктура в наших kubernetes кластерах выстроена так, что при добавлении ноды мы автоматически получаем всё необходимое: настройку системных параметров, мониторинг и т. д.
Чтобы на этом (уже готовом для работы) узле оказалась Cassandra, зачастую нужно сделать только две вещи:
1. Определиться, где будут лежать данные.
2. Увеличить количество нод в statefulset’е (или другой абстракции оператора) на 1.
Чтобы «однообразно» ставить Кассандру «с нуля» на сервер нужен маленький скрипт. А если запускать ее в обычном docker (или podman) — этот скрипт будет еще меньше. При этом не нужно искать решения для проблем типа таких:

Пунктом выше мы согласились, что один узел Cassandra будет равняться одному pod’у в Kubernetes. Но IP-адреса у pod’ов каждый раз будут разными. А идентификация узла в Cassandra происходит именно на основе IP-адреса… Получается, что после каждого удаления pod’а кластер Cassandra будет добавлять в себя новый узел.

Выход есть, и даже не один


На данном этапе пробовать что-то из вышеописанного можно на свой страх и риск: ни один из разработчиков не гарантирует 100%-ую работу своего решения в production-среде.


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

Но для production, получается, сыровата технология?
Не достаточно отточена для production, я бы сказал.
UFO just landed and posted this here
multiDC можно достичь заведением нод kubernetes кластера в нескольких DC. Повесить на ноды специфичные для DC label’ы/taint’ы. Указать для cassandra toleration и affinity. Для этого, как указано в статье, нам придется использовать более чем один statefulset. Практически все операторы это вопрос решают.

Возникает вопрос по поводу того, как гарантировать доступность master нод, но это уже другая история :)

Доступность master нод? До сих пор был уверен, что у Кассандры все ноды равноправные.

Имелась ввиду доступность master нод kubernetes кластера. Если master нода только в одном dc, могут возникнуть проблемы.
Больше похоже про сову на глобус. Какая цель всего этого? Такого удобства управления явно не достаточно для перехода с 100+ железных нод.
Чтобы осуществлять переезд с одной инфраструктуры на другую, нужно четко понимать зачем.
Если есть понимание, что переезд будет натягиванием совы на глобус — лучше оставить птичку в покое.
Суть статьи — помочь с пониманием нюансов, если кто-то захочет перевезти свою Cassandra в Kubernetes.

P.s.: В ходе написания статьи ни одна сова не пострадала.
«Чтобы осуществлять переезд с одной инфраструктуры на другую, нужно четко понимать зачем.» — вот это и хочется понять, зачем?
Или Вы это делаете, без цели, просто для общего развития…
Если вопрос конкретно про нас, то мы обслуживаем большое число Kubernetes-кластеров, где Cassandra, например, используется для инсталляций Jaeger, поэтому удобно (эффективно для управления), чтобы всё было сделано унифицировано. Другой кейс — уже упомянут выше, когда регулярно (и автоматически) нужно выкатывать однотипные окружения (для целей разработки), имеющие в своём составе Cassandra. Какие потребности у других — может быть, они расскажут об этом сами. Статья написана не для ответа на вопрос, «зачем», а о том, «как» это можно делать на сегодняшний день (и для тех, кому это нужно уже сейчас или в скором времени).

Призывов проводить миграцию (тем более — как самоцель) здесь нет.
Напомню, что часть данных Cassandra хранит в памяти. Чтобы сделать полный бэкап, нужно данные из памяти (Memtables) перенести на диск (SSTables). В этот момент узел Cassandra перестает принимать соединения, полностью выключаясь из работы кластера.

это не так, возможно вы делаете что то не то. ни nodetool flush ( сброс memtables на диск ) ни nodetool snapshot (что есть сброс на диск + создание хардлинков на текущее состоянии данных на диске ) не вызывают остановку ноды кассандры.
возможно, вы пытаетесь сделать nodetool drain, что есть flush + остановка сетевых сервисов ноды кассандры. но для целей бакапа это бессмысленно.
обычно nodetool snapshot и перемещение получившихся хардлинков из поддиректорий snapshots должно быть достаточно для бакапа и последующего восстановления ( если нода в которую идет восстановление имеет тот же ip ).
Да, всё верно, тут хорошее замечание. В статье есть скрипт с примером бекапов. Он делает как раз то, что вы описали. Если не делать nodetool drain, все должно пройти гладко.
Спасибо! Упустил из виду. Вышла уже после того, как я закончил основную часть статьи. Ознакомлюсь.
Sign up to leave a comment.