Comments 16
Говоря о миграции Cassandra в Kubernetes, мы надеемся, что с переездом управлять ей станет удобнее.
Можно поподробнее, в чем улучшилось удобство управления после миграции?
Конкретно в нашем случае — удобнее готовить новый узел. Инфраструктура в наших kubernetes кластерах выстроена так, что при добавлении ноды мы автоматически получаем всё необходимое: настройку системных параметров, мониторинг и т. д.
Чтобы на этом (уже готовом для работы) узле оказалась Cassandra, зачастую нужно сделать только две вещи:
1. Определиться, где будут лежать данные.
2. Увеличить количество нод в statefulset’е (или другой абстракции оператора) на 1.
Чтобы на этом (уже готовом для работы) узле оказалась Cassandra, зачастую нужно сделать только две вещи:
1. Определиться, где будут лежать данные.
2. Увеличить количество нод в statefulset’е (или другой абстракции оператора) на 1.
Чтобы «однообразно» ставить Кассандру «с нуля» на сервер нужен маленький скрипт. А если запускать ее в обычном docker (или podman) — этот скрипт будет еще меньше. При этом не нужно искать решения для проблем типа таких:
Впрочем, зависит от сценария использования. Если нужно часто развертывать тестовые конфигурации для разработчиков, то такая автоматизация может быть оправдана.
Но для production, получается, сыровата технология?
Пунктом выше мы согласились, что один узел Cassandra будет равняться одному pod’у в Kubernetes. Но IP-адреса у pod’ов каждый раз будут разными. А идентификация узла в Cassandra происходит именно на основе IP-адреса… Получается, что после каждого удаления pod’а кластер Cassandra будет добавлять в себя новый узел.
Выход есть, и даже не один
…
…
На данном этапе пробовать что-то из вышеописанного можно на свой страх и риск: ни один из разработчиков не гарантирует 100%-ую работу своего решения в production-среде.
Впрочем, зависит от сценария использования. Если нужно часто развертывать тестовые конфигурации для разработчиков, то такая автоматизация может быть оправдана.
Но для production, получается, сыровата технология?
multiDC можно достичь заведением нод kubernetes кластера в нескольких DC. Повесить на ноды специфичные для DC label’ы/taint’ы. Указать для cassandra toleration и affinity. Для этого, как указано в статье, нам придется использовать более чем один statefulset. Практически все операторы это вопрос решают.
Возникает вопрос по поводу того, как гарантировать доступность master нод, но это уже другая история :)
Возникает вопрос по поводу того, как гарантировать доступность master нод, но это уже другая история :)
Больше похоже про сову на глобус. Какая цель всего этого? Такого удобства управления явно не достаточно для перехода с 100+ железных нод.
Чтобы осуществлять переезд с одной инфраструктуры на другую, нужно четко понимать зачем.
Если есть понимание, что переезд будет натягиванием совы на глобус — лучше оставить птичку в покое.
Суть статьи — помочь с пониманием нюансов, если кто-то захочет перевезти свою Cassandra в Kubernetes.
P.s.: В ходе написания статьи ни одна сова не пострадала.
Если есть понимание, что переезд будет натягиванием совы на глобус — лучше оставить птичку в покое.
Суть статьи — помочь с пониманием нюансов, если кто-то захочет перевезти свою Cassandra в Kubernetes.
P.s.: В ходе написания статьи ни одна сова не пострадала.
«Чтобы осуществлять переезд с одной инфраструктуры на другую, нужно четко понимать зачем.» — вот это и хочется понять, зачем?
Или Вы это делаете, без цели, просто для общего развития…
Или Вы это делаете, без цели, просто для общего развития…
Если вопрос конкретно про нас, то мы обслуживаем большое число Kubernetes-кластеров, где Cassandra, например, используется для инсталляций Jaeger, поэтому удобно (эффективно для управления), чтобы всё было сделано унифицировано. Другой кейс — уже упомянут выше, когда регулярно (и автоматически) нужно выкатывать однотипные окружения (для целей разработки), имеющие в своём составе Cassandra. Какие потребности у других — может быть, они расскажут об этом сами. Статья написана не для ответа на вопрос, «зачем», а о том, «как» это можно делать на сегодняшний день (и для тех, кому это нужно уже сейчас или в скором времени).
Призывов проводить миграцию (тем более — как самоцель) здесь нет.
Призывов проводить миграцию (тем более — как самоцель) здесь нет.
Напомню, что часть данных Cassandra хранит в памяти. Чтобы сделать полный бэкап, нужно данные из памяти (Memtables) перенести на диск (SSTables). В этот момент узел Cassandra перестает принимать соединения, полностью выключаясь из работы кластера.
это не так, возможно вы делаете что то не то. ни nodetool flush ( сброс memtables на диск ) ни nodetool snapshot (что есть сброс на диск + создание хардлинков на текущее состоянии данных на диске ) не вызывают остановку ноды кассандры.
возможно, вы пытаетесь сделать nodetool drain, что есть flush + остановка сетевых сервисов ноды кассандры. но для целей бакапа это бессмысленно.
обычно nodetool snapshot и перемещение получившихся хардлинков из поддиректорий snapshots должно быть достаточно для бакапа и последующего восстановления ( если нода в которую идет восстановление имеет тот же ip ).
Также, всевозможные варианты бакапов и восстановлений хорошо описаны тут: thelastpickle.com/blog/2019/11/05/cassandra-medusa-backup-tool-is-open-source.html
Sign up to leave a comment.
Миграция Cassandra в Kubernetes: особенности и решения