Кассандраның Кубернетеске көшуі: ерекшеліктері мен шешімдері

Біз үнемі Apache Cassandra дерекқорына және оны Кубернетес негізіндегі инфрақұрылымда пайдалану қажеттілігіне тап боламыз. Бұл материалда біз Кассандраны K8-ге көшіру үшін қажетті қадамдар, критерийлер және бар шешімдер (операторларға шолуды қоса) туралы өз көзқарасымызды бөлісеміз.

«Әйелді билеген адам мемлекетті де билей алады»

Кассандра деген кім? Бұл бір сәтсіздік нүктесінсіз жоғары қолжетімділікті қамтамасыз ете отырып, деректердің үлкен көлемін басқаруға арналған бөлінген сақтау жүйесі. Жобаға ұзақ кіріспе қажет емес, сондықтан мен Кассандраның белгілі бір мақаланың контекстінде маңызды болатын негізгі ерекшеліктерін ғана беремін:

• Кассандра Java тілінде жазылған.
• Кассандра топологиясы бірнеше деңгейлерді қамтиды:
  • Түйін - бір орналастырылған Cassandra данасы;
  • Rack - бір деректер орталығында орналасқан кейбір сипаттамалары бойынша біріктірілген Cassandra даналарының тобы;
  • Datacenter – бір деректер орталығында орналасқан Кассандра даналарының барлық топтарының жинағы;
  • Кластер - бұл барлық деректер орталықтарының жиынтығы.
• Кассандра түйінді анықтау үшін IP мекенжайын пайдаланады.
• Жазу және оқу әрекеттерін жылдамдату үшін Кассандра кейбір деректерді жедел жадта сақтайды.

Енді - Кубернетеске нақты ықтимал көшу.

Аударуды тексеру парағы

Кассандраның Кубернетеске көші-қоны туралы айтатын болсақ, көшу арқылы оны басқару ыңғайлы болады деп үміттенеміз. Бұл үшін не қажет болады, бұған не көмектеседі?

1. Мәліметтерді сақтау

Түсіндірілгендей, Cassanda деректердің бір бөлігін жедел жадта сақтайды Memtable. Бірақ дискіде сақталған деректердің тағы бір бөлігі бар - пішінде SSTable. Бұл деректерге нысан қосылады Тапсырма журналы — барлық транзакциялардың жазбалары, олар да дискіде сақталады.

Кассандрада транзакция диаграммасын жазыңыз

Kubernetes-те біз деректерді сақтау үшін PersistentVolume пайдалана аламыз. Тексерілген тетіктердің арқасында Kubernetes-те деректермен жұмыс істеу жыл сайын жеңілдеуде.

Біз әрбір Cassandra подводына өзіміздің тұрақты көлемді бөлеміз

Айта кету керек, Кассандраның өзі бұл үшін кірістірілген механизмдерді ұсына отырып, деректерді репликациялауды білдіреді. Сондықтан, егер сіз көптеген түйіндерден Cassandra кластерін құрастырсаңыз, деректерді сақтау үшін Ceph немесе GlusterFS сияқты бөлінген жүйелерді пайдаланудың қажеті жоқ. Бұл жағдайда деректерді хост дискісінде сақтау қисынды болады жергілікті тұрақты дискілер немесе монтаждау hostPath.

Тағы бір сұрақ: әрбір мүмкіндік тармағы үшін әзірлеушілер үшін бөлек ортаны жасау керек пе. Бұл жағдайда дұрыс тәсіл бір Кассандра түйінін көтеру және деректерді таратылған қоймада сақтау болады, яғни. аталған Ceph және GlusterFS сіздің опцияларыңыз болады. Содан кейін әзірлеуші ​​Kuberntes кластер түйіндерінің бірі жоғалса да сынақ деректерін жоғалтпайтынына сенімді болады.

2. Бақылау

Kubernetes-те мониторингті жүзеге асыру үшін іс жүзінде даусыз таңдау Прометей болып табылады (біз бұл туралы егжей-тегжейлі айттық қатысты есеп). Кассандра Prometheus үшін метрика экспорттаушылармен қалай жұмыс істейді? Grafana үшін сәйкес бақылау тақталары бар, одан да маңыздысы не?

Кассандра үшін Графанадағы графиктердің пайда болуының мысалы

Тек екі экспорттаушы бар: jmx_exporter и cassandra_exporter.

Біз өзіміз үшін біріншісін таңдадық, себебі:

1. JMX Exporter өсіп және дамып келеді, ал Cassandra Exporter қауымдастықтың жеткілікті қолдауын ала алмады. Cassandra Exporter әлі де Cassandra нұсқасының көпшілігін қолдамайды.
2. Жалаушаны қосу арқылы оны javaagent ретінде іске қосуға болады -javaagent:<plugin-dir-name>/cassandra-exporter.jar=--listen=:9180.
3. Оның біреуі бар барабар бақылау тақтасы, ол Cassandra Exporter бағдарламасымен үйлеспейді.

3. Kubernetes примитивтерін таңдау

Кассандра кластерінің жоғарыдағы құрылымына сәйкес, онда сипатталғанның барлығын Кубернетес терминологиясына аударуға тырысайық:

• Кассандра түйіні → Pod
• Cassandra Rack → StatefulSet
• Cassandra Datacenter → StatefulSets пулы
• Кассандра кластері → ???

Бүкіл Кассандра кластерін бірден басқару үшін кейбір қосымша нысан жетіспейтіні белгілі болды. Бірақ егер бірдеңе жоқ болса, біз оны жасай аламыз! Кубернетестің осы мақсат үшін өз ресурстарын анықтау механизмі бар - Пайдаланушы ресурс анықтамалары.

Журналдар мен ескертулер үшін қосымша ресурстарды жариялау

Бірақ пайдаланушы ресурсының өзі ештеңені білдірмейді: ақыр соңында, ол талап етеді контроллер. Сізге көмек сұрау қажет болуы мүмкін Kubernetes операторы...

4. Бұршақтарды анықтау

Жоғарыдағы абзацта біз бір Кассандра түйіні Кубернетестегі бір түйінге тең болады деп келістік. Бірақ подкасттардың IP мекенжайлары әр уақытта әртүрлі болады. Ал Кассандрадағы түйіннің идентификациясы IP-адреске негізделген... Подкастты әр алып тастағаннан кейін Кассандра кластері жаңа түйін қосады екен.

Бір ғана емес, шығу жолы бар:

1. Біз жазбаларды хост идентификаторлары (Cassandra даналарын бірегей түрде анықтайтын UUID) немесе IP мекенжайлары бойынша сақтай аламыз және олардың барлығын кейбір құрылымдарда/кестелерде сақтай аламыз. Әдістің екі негізгі кемшілігі бар:
   • Екі түйін бірден құлап кетсе, жарыс жағдайының пайда болу қаупі. Көтерілгеннен кейін Кассандра түйіндері бір уақытта кестеден IP мекенжайын сұрайды және сол ресурс үшін бәсекелеседі.
   • Егер Кассандра түйіні деректерін жоғалтса, біз оны бұдан былай анықтай алмаймыз.
2. Екінші шешім кішкентай бұзу сияқты көрінеді, бірақ соған қарамастан: біз әрбір Cassandra түйіні үшін ClusterIP арқылы қызметті жасай аламыз. Бұл іске асыру проблемалары:
   • Кассандра кластерінде түйіндер көп болса, бізге көптеген қызметтерді жасауға тура келеді.
   • ClusterIP мүмкіндігі iptables арқылы жүзеге асырылады. Кассандра кластерінде көптеген (1000... немесе тіпті 100?) түйін болса, бұл мәселе болуы мүмкін. Дегенмен IPVS негізінде теңдестіру бұл мәселені шеше алады.
3. Үшінші шешім - бұл параметрді қосу арқылы бөлінген қосқыштар желісінің орнына Кассандра түйіндері үшін түйіндер желісін пайдалану hostNetwork: true. Бұл әдіс белгілі бір шектеулер қояды:
   • Бірліктерді ауыстыру үшін. Жаңа түйіннің бұрынғымен бірдей IP мекенжайы болуы қажет (AWS, GCP сияқты бұлттарда мұны істеу мүмкін емес);
   • Кластер түйіндерінің желісін пайдалана отырып, біз желілік ресурстар үшін бәсекеге түсеміз. Сондықтан, бір кластерлік түйінге Кассандрамен бірге бірнеше қосқышты орналастыру қиын болады.

5. Сақтық көшірмелер

Біз кесте бойынша бір Кассандра түйінінің деректерінің толық нұсқасын сақтағымыз келеді. Kubernetes ыңғайлы мүмкіндікті пайдаланады CronJob, бірақ бұл жерде Кассандраның өзі біздің дөңгелектерге спиц қояды.

Еске сала кетейін, Кассандра кейбір мәліметтерді жадта сақтайды. Толық сақтық көшірме жасау үшін жадтағы деректер қажет (Memtables) дискіге жылжыту (SSTables). Осы кезде Кассандра түйіні кластерден толығымен өшіп, қосылымдарды қабылдауды тоқтатады.

Осыдан кейін сақтық көшірме жойылады (суретті) және схема сақталады (пернелер кеңістігі). Содан кейін ғана сақтық көшірме бізге ештеңе бермейтіні белгілі болды: біз Кассандра түйіні жауапты болған деректер идентификаторларын сақтауымыз керек - бұл арнайы белгілер.

Кассандра түйіндерінің қандай деректерге жауап беретінін анықтау үшін таңбалауыштарды тарату

Кубернетесте 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}"

Бір Кассандра түйінінен сақтық көшірме алуға арналған bash сценарийінің мысалы

Кубернетестегі Кассандраға арналған дайын шешімдер

Қазіргі уақытта Кассандраны Kubernetes-те орналастыру үшін не қолданылады және олардың қайсысы берілген талаптарға сәйкес келеді?

1. StatefulSet немесе Helm диаграммаларына негізделген шешімдер

Cassandra кластерін іске қосу үшін негізгі StatefulSets функцияларын пайдалану жақсы нұсқа болып табылады. Helm диаграммасын және Go үлгілерін пайдалану арқылы пайдаланушыға Кассандраны орналастыру үшін икемді интерфейсті қамтамасыз ете аласыз.

Бұл әдетте жақсы жұмыс істейді... түйін сәтсіздігі сияқты күтпеген нәрсе болғанша. Стандартты Kubernetes құралдары жоғарыда сипатталған барлық мүмкіндіктерді ескере алмайды. Бұған қоса, бұл тәсіл оны неғұрлым күрделі қолданулар үшін кеңейтуге болатындығымен шектелген: түйінді ауыстыру, сақтық көшірме жасау, қалпына келтіру, бақылау және т.б.

Өкілдер:

• Негізгі Helm репозиторийіндегі диаграмма;
• Битнамиден алынған диаграмма.

Екі диаграмма да бірдей жақсы, бірақ жоғарыда сипатталған мәселелерге бағынады.

2. Kubernetes Operator негізіндегі шешімдер

Мұндай опциялар қызықтырақ, өйткені олар кластерді басқаруға кең мүмкіндіктер береді. Cassandra операторын жобалау үшін, кез келген басқа дерекқор сияқты, жақсы үлгі Sidecar <-> Controller <-> CRD сияқты көрінеді:

Жақсы жобаланған Кассандра операторындағы түйіндерді басқару схемасы

Қолданыстағы операторларды қарастырайық.

1. Cassandra-оператор instaclustr

• GitHub
• Дайындық: Альфа
• Лицензия: Apache 2.0
• Іске асырылған: Java

Бұл шынымен де Кассандраның басқарылатын орналастыруларын ұсынатын компанияның өте перспективалы және белсенді дамып келе жатқан жобасы. Ол, жоғарыда сипатталғандай, HTTP арқылы пәрмендерді қабылдайтын бүйірлік контейнерді пайдаланады. Java тілінде жазылған, кейде клиент-go кітапханасының жетілдірілген функционалдығы жетіспейді. Сондай-ақ, оператор бір Datacenter үшін әртүрлі сөрелерді қолдамайды.

Бірақ оператордың мониторингті қолдау, CRD көмегімен жоғары деңгейлі кластерді басқару, тіпті сақтық көшірме жасау үшін құжаттама сияқты артықшылықтары бар.

2. Jetstack-тен навигатор

• GitHub
• Дайындық: Альфа
• Лицензия: Apache 2.0
• Орындалған: Голанг

МҚ-ны қызмет ретінде орналастыруға арналған мәлімдеме. Қазіргі уақытта екі дерекқорды қолдайды: Elasticsearch және Cassandra. Оның RBAC арқылы дерекқорға қол жеткізуді басқару сияқты қызықты шешімдері бар (бұл үшін оның жеке навигатор-аписервері бар). Қызықты жоба, ол мұқият қарап шығуға тұрарлық, бірақ соңғы міндеттеме бір жарым жыл бұрын жасалды, бұл оның әлеуетін анық төмендетеді.

3. Вгковскийдің Кассандра-операторы

• GitHub
• Дайындық: Альфа
• Лицензия: Apache 2.0
• Орындалған: Голанг

Олар мұны «байыпты» деп есептемеді, өйткені репозиторийге соңғы міндеттеме бір жылдан астам уақыт бұрын болған. Операторды әзірлеу тоқтатылды: қолдау көрсетілетіні хабарланған Kubernetes бағдарламасының соңғы нұсқасы 1.9.

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

• GitHub
• Дайындық: Альфа
• Лицензия: Apache 2.0
• Орындалған: Голанг

Дамуы біз қалағандай жылдам дамымайтын оператор. Оның кластерді басқаруға арналған жақсы ойластырылған CRD құрылымы бар, ClusterIP қызметі арқылы түйіндерді анықтау мәселесін шешеді (сол «бұзу»)... бірақ бұл әзірше. Қазіргі уақытта қораптан тыс мониторинг немесе сақтық көшірмелер жоқ (айтпақшы, біз бақылау үшін өзіміз алып кеттік). Бір қызығы, сіз ScyllaDB бағдарламасын осы операторды қолдана отырып қолдана аласыз.

Ескертпе: Біз бұл операторды жобаларымыздың бірінде шамалы өзгертулермен қолдандық. Оператор жұмысында барлық жұмыс кезеңінде (~4 ай жұмыс) ешқандай ақаулар байқалмады.

5. Апельсиннен алынған CassKop

• GitHub
• Дайындық: Альфа
• Лицензия: Apache 2.0
• Орындалған: Голанг

Тізімдегі ең жас оператор: бірінші міндеттеме 23 жылдың 2019 мамырында жасалған. Қазірдің өзінде оның арсеналында біздің тізімнен көптеген мүмкіндіктер бар, олардың толығырақ мәліметтерін жоба репозиторийінен табуға болады. Оператор танымал оператор-sdk негізінде құрастырылған. Қораптан тыс бақылауды қолдайды. Басқа операторлардан басты айырмашылығы – пайдалану CassKop плагині, Python-да енгізілген және Кассандра түйіндері арасындағы байланыс үшін пайдаланылады.

қорытындылар

Кассандраны Кубернетеске көшірудің тәсілдер саны мен ықтимал нұсқалары өзі туралы айтады: тақырып сұранысқа ие.

Бұл кезеңде сіз жоғарыда аталғандардың кез келгенін өзіңіздің қауіп-қатеріңізге және тәуекеліңізге байланысты қолданып көруге болады: әзірлеушілердің ешқайсысы өндірістік ортада өз шешімдерінің 100% жұмыс істеуіне кепілдік бермейді. Бірақ қазірдің өзінде көптеген өнімдер әзірлеу орындықтарында қолданып көруге перспективалы болып көрінеді.

Менің ойымша, болашақта кемедегі бұл әйел пайдалы болады!

PS

Біздің блогта да оқыңыз:

• «MongoDB-тің Kubernetes-ке үздіксіз көшуі«;
• «RabbitMQ-ны Kubernetes-ке үздіксіз көшіру«;
• «Деректер базалары және Кубернеталар (шолу және бейне есеп)«;
• «K8s кеңестері мен амалдары: үлкен дерекқорлар үшін жүктеуді жылдамдату«.

Ақпарат көзі: www.habr.com