Миграција на Касандра во Кубернетес: карактеристики и решенија

Редовно се среќаваме со базата на податоци на Apache Cassandra и потребата да се работи со неа во рамките на инфраструктурата базирана на Кубернетес. Во овој материјал, ќе ја споделиме нашата визија за неопходните чекори, критериуми и постоечки решенија (вклучувајќи преглед на операторите) за мигрирање на Касандра на K8.

„Кој може да владее со жена, може да владее и со државата“

Која е Касандра? Тоа е дистрибуиран систем за складирање дизајниран да управува со големи количини на податоци додека обезбедува висока достапност без ниту една точка на дефект. На проектот едвај му треба долг вовед, па ќе ги дадам само главните карактеристики на Касандра кои ќе бидат релевантни во контекст на одредена статија:

• Касандра е напишана на Јава.
• Топологијата Касандра вклучува неколку нивоа:
  • Јазол - еден распореден примерок на Касандра;
  • Rack е група на примери на Касандра, обединети со некоја карактеристика, лоцирана во истиот центар за податоци;
  • Центар за податоци - збирка од сите групи на примероци на Касандра лоцирани во еден центар за податоци;
  • Кластерот е збирка од сите центри за податоци.
• Касандра користи IP адреса за да идентификува јазол.
• За да ги забрза операциите за пишување и читање, Касандра складира дел од податоците во RAM меморијата.

Сега - до вистинскиот потенцијал преселба во Кубернетес.

Список за проверка за трансфер

Зборувајќи за миграцијата на Касандра во Кубернетес, се надеваме дека со овој потег ќе стане попогодно за управување. Што ќе биде потребно за ова, што ќе помогне со ова?

1. Складирање податоци

Како што веќе беше појаснето, Cassanda складира дел од податоците во RAM - во Мемтабл. Но, постои уште еден дел од податоците што се зачувуваат на дискот - во форма SSTable. На овие податоци се додава ентитет Обврски Дневник — записи за сите трансакции, кои исто така се зачувани на дискот.

Напишете дијаграм на трансакција во Касандра

Во Kubernetes, можеме да користиме PersistentVolume за складирање податоци. Благодарение на докажаните механизми, работата со податоци во Kubernetes станува полесна секоја година.

Ќе го доделиме секој под со Касандра свој постојан волумен

Важно е да се напомене дека самата Касандра подразбира репликација на податоци, нудејќи вградени механизми за ова. Затоа, ако градите кластер Касандра од голем број јазли, тогаш нема потреба да користите дистрибуирани системи како Ceph или GlusterFS за складирање податоци. Во овој случај, би било логично да се складираат податоци на дискот домаќин користејќи локални постојани дискови или монтирање hostPath.

Друго прашање е дали сакате да создадете посебна средина за програмери за секоја гранка на функции. Во овој случај, правилниот пристап би бил да се подигне еден јазол Касандра и да се складираат податоците во дистрибуирано складирање, т.е. споменатите Ceph и GlusterFS ќе бидат ваши опции. Тогаш развивачот ќе биде сигурен дека нема да ги изгуби податоците од тестот дури и ако се изгуби еден од јазлите на кластерот Кубернтес.

2. Следење

Практично неспорниот избор за спроведување на мониторинг во Кубернетес е Прометеј (за ова детално разговаравме во поврзан извештај). Како работи Касандра со извозниците на метрика за Прометеј? И, што е уште поважно, со соодветните контролни табли за Grafana?

Пример за појава на графикони во Графана за Касандра

Има само два извозници: jmx_exporter и касандра_извозник.

Првото го избравме за себе затоа што:

1. JMX Exporter расте и се развива, додека Cassandra Exporter не може да добие доволно поддршка од заедницата. Cassandra Exporter сè уште не ги поддржува повеќето верзии на Cassandra.
2. Можете да го извршите како javaagent со додавање на знаменце -javaagent:<plugin-dir-name>/cassandra-exporter.jar=--listen=:9180.
3. Има еден за него соодветна контролна табла, што е некомпатибилно со Cassandra Exporter.

3. Избор на примитиви на Кубернет

Според горната структура на кластерот Касандра, ајде да се обидеме да го преведеме сето она што е опишано таму во терминологијата на Кубернет:

• Касандра Јазол → Под
• Касандра Rack → StatefulSet
• Касандра податочен центар → базен од StatefulSets
• Кластерот Касандра → ???

Излегува дека недостига некој дополнителен ентитет за да управува со целиот кластер Касандра одеднаш. Но, ако нешто не постои, можеме да го создадеме! Kubernetes има механизам за дефинирање на сопствени ресурси за оваа намена - Прилагодени дефиниции за ресурси.

Декларирање дополнителни ресурси за дневници и предупредувања

Но, самиот прилагоден ресурс не значи ништо: на крајот на краиштата, тоа бара контролер. Можеби ќе треба да побарате помош Оператор Kubernetes...

4. Идентификација на мешунки

Во параграфот погоре, се согласивме дека еден јазол Касандра ќе биде еднаков на еден под во Кубернет. Но, IP адресите на мешунките ќе бидат различни секој пат. И идентификацијата на јазол во Касандра се заснова на IP адресата... Излегува дека по секое отстранување на под, кластерот Касандра ќе додаде нов јазол.

Има излез, а не само еден:

1. Можеме да водиме евиденција по идентификатори на домаќини (UUID кои единствено ги идентификуваат примерите на Касандра) или по IP адреси и сето тоа да го складираме во некои структури/табели. Методот има два главни недостатоци:
   • Ризикот од појава на состојба на трка ако паднат два јазли одеднаш. По подемот, јазлите на Касандра истовремено ќе побараат IP адреса од табелата и ќе се натпреваруваат за истиот ресурс.
   • Ако јазолот Касандра ги изгубил своите податоци, веќе нема да можеме да го идентификуваме.
2. Второто решение изгледа како мал хак, но сепак: можеме да создадеме услуга со ClusterIP за секој јазол Касандра. Проблеми со оваа имплементација:
   • Ако има многу јазли во кластерот Касандра, ќе мора да создадеме многу Услуги.
   • Функцијата ClusterIP се имплементира преку iptables. Ова може да стане проблем ако кластерот Касандра има многу (1000... или дури 100?) јазли. Иако балансирање врз основа на IPVS може да го реши овој проблем.
3. Третото решение е да се користи мрежа од јазли за јазлите на Касандра наместо посветена мрежа на мешунки со овозможување на поставката hostNetwork: true. Овој метод наметнува одредени ограничувања:
   • За замена на единици. Неопходно е новиот јазол да ја има истата IP адреса како и претходната (во облаците како AWS, GCP тоа е речиси невозможно да се направи);
   • Користејќи мрежа од кластерски јазли, почнуваме да се натпреваруваме за мрежни ресурси. Затоа, поставувањето на повеќе од еден под со Касандра на еден кластер јазол ќе биде проблематично.

5. Бекап

Сакаме да зачуваме целосна верзија на податоци од еден јазол Касандра на распоред. Kubernetes обезбедува удобна функција со користење CronJob, но овде самата Касандра ни става говор во тркалата.

Да ве потсетам дека Касандра чува дел од податоците во меморијата. За да направите целосна резервна копија, потребни ви се податоци од меморијата (Memtables) премести на диск (SST-табели). Во овој момент, јазолот Касандра престанува да прифаќа врски, целосно исклучувајќи се од кластерот.

После ова, резервната копија се отстранува (слика) и шемата е зачувана (клучен простор). И тогаш излегува дека само резервната копија не ни дава ништо: треба да ги зачуваме идентификаторите на податоци за кои беше одговорен јазолот Касандра - ова се специјални токени.

Дистрибуција на токени за да се идентификува за какви податоци се одговорни јазлите на Касандра

Пример скрипта за преземање резервна копија на Касандра од Google во Кубернетес може да се најде на овој линк. Единствената точка што скриптата не ја зема предвид е ресетирање на податоците во јазолот пред да се направи снимката. Односно, резервната копија се врши не за моменталната состојба, туку за состојба малку порано. Но, ова помага да не се извади јазолот од работа, што изгледа многу логично.

set -eu

if [[ -z "$1" ]]; then
  info "Please provide a keyspace"
  exit 1
fi

KEYSPACE="$1"

result=$(nodetool snapshot "${KEYSPACE}")

if [[ $? -ne 0 ]]; then
  echo "Error while making snapshot"
  exit 1
fi

timestamp=$(echo "$result" | awk '/Snapshot directory: / { print $3 }')

mkdir -p /tmp/backup

for path in $(find "/var/lib/cassandra/data/${KEYSPACE}" -name $timestamp); do
  table=$(echo "${path}" | awk -F "[/-]" '{print $7}')
  mkdir /tmp/backup/$table
  mv $path /tmp/backup/$table
done


tar -zcf /tmp/backup.tar.gz -C /tmp/backup .

nodetool clearsnapshot "${KEYSPACE}"

Пример за баш скрипта за преземање резервна копија од еден јазол Касандра

Подготвени решенија за Касандра во Кубернетес

Што се користи моментално за распоредување на Касандра во Кубернетес и кое од овие најдобро одговара на дадените барања?

1. Решенија засновани на табели на StatefulSet или Helm

Користењето на основните функции на StatefulSets за извршување на кластерот Касандра е добра опција. Користејќи ги шаблоните Helm chart и Go, можете да му обезбедите на корисникот флексибилен интерфејс за распоредување на Cassandra.

Ова обично функционира добро... додека не се случи нешто неочекувано, како што е дефект на јазолот. Стандардните алатки на Kubernetes едноставно не можат да ги земат предвид сите карактеристики опишани погоре. Дополнително, овој пристап е многу ограничен во тоа колку може да се прошири за посложени намени: замена на јазли, резервна копија, обновување, следење итн.

Претставници:

• Графикон од главното складиште на Helm;
• Графикон од битнами.

Двата графикони се подеднакво добри, но се предмет на проблемите опишани погоре.

2. Решенија базирани на Kubernetes Operator

Ваквите опции се поинтересни бидејќи даваат многу можности за управување со кластерот. За дизајнирање на оператор Касандра, како и секоја друга база на податоци, добра шема изгледа како Sidecar контролер CRD:

Шема за управување со јазли во добро дизајниран оператор Касандра

Да ги погледнеме постоечките оператори.

1. Касандра-оператор од instaclustr

• GitHub
• Подготвеност: Алфа
• Лиценца: Apache 2.0
• Имплементиран во: Јава

Ова е навистина многу ветувачки и активно развивачки проект од компанија која нуди управувани распоредувања на Касандра. Тој, како што е опишано погоре, користи контејнер за странична кола што прифаќа команди преку HTTP. Напишано во Јава, понекогаш му недостасува понапредната функционалност на библиотеката за клиент-оди. Исто така, операторот не поддржува различни Racks за еден Datacenter.

Но, операторот има такви предности како поддршка за мониторинг, управување со кластери на високо ниво со користење на CRD, па дури и документација за правење резервни копии.

2. Навигатор од Jetstack

• GitHub
• Подготвеност: Алфа
• Лиценца: Apache 2.0
• Имплементиран во: Голанг

Изјава дизајнирана за распоредување на DB-as-a-Service. Во моментов поддржува две бази на податоци: Elasticsearch и Cassandra. Има толку интересни решенија како контрола на пристап до базата на податоци преку RBAC (за ова има свој посебен навигатор-аписервер). Интересен проект кој би вредел да се погледне подетално, но последното залагање е направено пред година и пол, што очигледно го намалува неговиот потенцијал.

3. Касандра-оператор од вгковски

• GitHub
• Подготвеност: Алфа
• Лиценца: Apache 2.0
• Имплементиран во: Голанг

Тие не го сметаа тоа „сериозно“, бидејќи последното обврзување на складиштето беше пред повеќе од една година. Развојот на операторот е напуштен: најновата верзија на Kubernetes пријавена како поддржана е 1.9.

4. Касандра-оператор од Рук

• GitHub
• Подготвеност: Алфа
• Лиценца: Apache 2.0
• Имплементиран во: Голанг

Оператор чиј развој не напредува толку брзо како што би сакале. Има добро осмислена CRD структура за управување со кластери, го решава проблемот со идентификација на јазли со помош на Service with ClusterIP (истиот „хак“)... но тоа е сè за сега. Во моментов нема мониторинг или резервни копии надвор од кутијата (патем, ние сме за следење самите го земавме). Интересен момент е тоа што можете да го распоредите и ScyllaDB користејќи го овој оператор.

Забелешка: Го користевме овој оператор со мали измени во еден од нашите проекти. Во текот на целиот период на работа (~4 месеци од работењето) не беа забележани никакви проблеми во работата на операторот.

5. CassKop од Orange

• GitHub
• Подготвеност: Алфа
• Лиценца: Apache 2.0
• Имплементиран во: Голанг

Најмладиот оператор на листата: првото обврзување беше направено на 23 мај 2019 година. Веќе сега има во својот арсенал голем број функции од нашата листа, за кои повеќе детали може да се најдат во складиштето на проектот. Операторот е изграден врз основа на популарниот оператор-sdk. Поддржува следење надвор од кутијата. Главната разлика од другите оператори е употребата Приклучок CassKop, имплементиран во Python и се користи за комуникација помеѓу јазлите Касандра.

Наоди

Бројот на пристапи и можните опции за пренесување на Касандра во Кубернетес зборува сам за себе: темата е на побарувачката.

Во оваа фаза, можете да пробате кое било од горенаведените на ваш сопствен ризик и ризик: ниту еден од програмерите не гарантира 100% работа на нивното решение во производствена средина. Но, веќе, многу производи изгледаат ветувачки за користење во развојни клупи.

Мислам дека во иднина оваа жена на бродот ќе ни се најде!

PS

Прочитајте и на нашиот блог:

• «Беспрекорна миграција на MongoDB во Kubernetes";
• «Беспрекорна миграција на RabbitMQ во Kubernetes";
• «Бази на податоци и Kubernetes (преглед и видео извештај)";
• «Совети и трикови за K8s: Забрзување на подигањето за големи бази на податоци".

Извор: www.habr.com