Translate

Показ дописів із міткою nosql. Показати всі дописи
Показ дописів із міткою nosql. Показати всі дописи

четвер, 25 серпня 2016 р.

Redis Sentinel

У цій статті піде мова про Sentinel - один із способів забезпечення високої доступності Redis. Забігаючи наперед, скажу, що Redis Sentinel не надає можливостей шардингу (sharding), тобто для збільшення простору збереження даних необхідно збільшувати кількість оперативної пам’яті сервера.

Дуже раджу попередньо ознайомитись з простою реплікацією Redis, про яку я писав дещо раніше. У двох словах, Redis Sentinel - це звичайна реплікація Redis, але з можливістю автоматичного міграції майстра на інший працюючий вузол, що був у реплікації. Після такої міграції майстра, попередній майстер, завдяки додатковому демону Sentinel, автоматично переконфігуровується в слейв, який може використовуватись лише для читання.

Для налаштування Redis Sentinel використаємо такі адреси:

192.168.1.39
192.168.1.42
192.168.1.43

Установимо пакети redis-server та redis-sentinel на кожен із серверів. У якості дистрибутиву я обрав останню LTS Ubuntu - 16.04. Зі стандартного репозиторію встановимо Redis та Sentinel:

# apt install redis-server
# apt install redis-sentinel

Зрештою, сервер Redis займе звичний порт 6379, а sentinel - 26379. Ясна річ, що ці порти мають бути відкритими в фаєрволі, якщо такий є.

Перезавантажимо Redis та перевіримо його роботу:

# redis-cli ping
PONG

Конфігурація кластера Sentinel не має викликати особливих труднощів. Перше, що необхідно перевірити - це те чи відкритий порт Redis для віддаленої роботи:

# vim /etc/redis/redis.conf
...
bind 0.0.0.0
...

Порт 6379 має працювати на нелокальному інтерфейсі для взаємодії Redis-процесу з іншими вузлами. Ця опція має приймати аналогічне значення і для Sentinel сервісу в /etc/redis/sentinel.conf.

Налаштовуємо Sentinel-процес:

# vim /etc/redis/sentinel.conf
...
sentinel monitor mymaster 192.168.1.39 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
...

неділя, 14 серпня 2016 р.

Redis Replication: Master-Slave

Декілька тижнів тому, я писав базові можливості Redis та як з ним працювати. Також я обіцяв продовжити цикл статей про Редіс і розповісти про високу доступність, кластеризацію та реплікацію цього сервісу. Отже цього разу мова піде про вбудовану в Redis асинхронну реплікацію Master-Slave.

Redis має вбудовану Master-Slave реплікацію і особливості її наступні:
  • Асинхронність, що на практиці означає, що дані лише з часом потрапляють на слейв. З версії 2.8 слейв періодично надсилає майстру підтвердження щодо того, скільки даних було cкопійовано.
  • Майстер може мати декілька слейвів одночасно
  • Слейви можуть бути підключені каскадно один до одного. Тобто для кожного наступного слейву, попередній слейв виступатиме джерелом даних для реплікації.
  • Процес реплікації є неблокуючим для майстра. Це значить, що майстер продовжує відповідати на всі запити, навіть якщо слейв запитав початкову синхронізацію
  • Процес реплікації також не є блокуючим і для слейвів, у разі, якщо в конфігураційних файлах дозволено використання старого набору даних для відповіді на запити. Інакше, є можливість заборонити такі дії і слати помилки клієнтам, якщо процес реплікації зупинений. 
  • Реплікація може використовуватись для масштабування операцій читання: чим більше слейвів - тим швидше відбуваються операції читання, і тим більшу кількість запитів мають можливість обробити сервера. У разі падіння діючого майстра - слейв можна зробити новим майстром. Тобто слейви можуть використовуватись лише для читання, зі зрозумілих причин операції запису на них заблоковані.
Більш того, опціонально можна вимкнути механізм(и) збереження даних на диск на майстрі, задля підвищення швидкості його роботи. Так як слейви все реплікують - вони і будуть джерелом наповнення даних у разі падіння останнього. Але є одне але: у такому разі автозапуск Redis-процесу необхідно заборонити, адже інакше відсутні дані майстра (дивно звучить), після його можливого падіння, скопіюються і на слейви, що призведе до повного видалення баз. Але навіть так це достатньо ризиковано.

неділя, 24 липня 2016 р.

Redis Basics

Redis (REmote DIctionary Server) - високопродуктивна нереляційна база даних типу ключ-значення, розробку якої наразі фінансує Redis Labs, а раніше - Pivotal Software та VMware. Це програмне забезпечення з відкритим сирцевим кодом написане на мові C. Redis досить зрілий проект і має набір готових біндингів до різноманітних мов програмування.

Redis дуже часто розглядають як заміну Memcached, адже доступ до значень також відбувається по ключу. Проте він, на відміну від останнього, володіє купою переваг, серед яких:
  • Можливість з певною частотою зберігати дані з оперативної в постійну пам'ять. Тож у разі падіння демона дані будуть наявні після рестарту. У останніх версіях Redis є можливість вести лог операцій запису. Щось на зразок бінлогу в MySQL.
  • Більше можливих типів даних, котрі можуть зберігатись. Redis, окрім рядків (strings), підтримує збереження масивів (lists), хеш-таблиць (hash tables), множин (sets), сортованих множин (sorted sets), масиви біт (bitmaps) та HyperLogLog. Останні по-суті базуються на рядках (strings), які мають свою власну семантику. Детальніше про них далі.
  • Реплікація (built-in), кластеризація (Redis Sentinel, Redis Cluster), шардинг (Redis Cluster), висока доступність (Redis Sentinel, Redis Cluster). Цього всього немає в ванільному Memcached, але воно так необхідне при створенні інфраструктур високої доступності.
  • Підтримка транзакцій. Команди можуть бути виконані групою, і у разі невиконання однієї із них - відбудеться повернення на попередній стан. Також команди можна виконувати пакетами (виконуємо пачку команд, потім отримуємо пачку результатів).
  • Підтримка механізму publish/subscribe. Програми, що використовують Redis, можуть створювати іменовані канали і додавати в них повідомлення, а інші програми, відповідно, можуть забирати дані з таких каналів. У моєму розумінні, це щось схоже на черги в RabbitMQ.

субота, 9 липня 2016 р.

Marvel. Monitoring Plugin for Elasticsearch

Півроку тому я писав статтю про Elasticsearch, його кластеризацію, основи роботи. Сьогодні ж поговоримо про способи його моніторингу, а саме установку Marvel. Одразу скажу, що він коштує достатньо космічних сум (проте безкоштовний для використання в DEV-середовищах) і не кожен бізнес може його дозволити собі.

Враховуючи ці ціни, можливо, краще спробувати відкриті альтернативи на кшталт Kopf чи Elasticsearch-head, про котрі я також згадував у власній статті. Проте, ймовірно, вони менш функціональні і призначені скоріше для моніторингу кластерних ресурсів: шардів, реплік, стану кластеру.

Опишу трохи майбутню тестову архітектуру. Розробники з Elastic рекомендують для Prod-середовищ виділяти окремий сервер для Marvel, адже останній логує свої сервісні дані та проводить певні розрахунки, котрі можуть впливати на завантаження самого Elasticsearch. Тому наша інсталяція складатиметься з вузлу Elasticsearch + Marvel-agent, котрий надсилатиме необхідні сервісні дані до іншого вузлу Elasticsearch, котрий буде зберігати їх локально, а Kibana та Marvel plugin, що будуть встановлені тут же, відображатимуть це все.


Установимо oracle-java8-jdk на обидва вузла кластера:

# add-apt-repository ppa:webupd8team/java
# aptitude update
# aptitude install oracle-java8-installer
# update-java-alternatives -s java-8-oracle

# java -version
java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)

вівторок, 19 січня 2016 р.

Elasticsearch Cluster: Overview And Setup

Elasticsearch - це пошукова платформа майже реального часу (near real time, NRT). На практиці це означає, що існує лише мінімальна затримка (зазвичай біля секунди) між часом додавання документу до індексу і часом, коли він стає доступним для пошуку.

Elasticsearch, як і його основний конкурент Solr, базується на бібліотеці Lucene. Сам по собі Apache Lucene не являється повноцінним сервісом: це просто бібліотека для побудови пошукових систем, вона займається лише індексом та пошуком. А, власне, за введення даних, налаштування сервісу, кластеризацію, маршрутизацію пошукових запитів та ін. відповідає Elasticsearch чи інша "обгортка".

Використання та налаштування (переважно) здійснюється за допомогою RESTful API запитів. У випадку з unix-подібною OC з цим може допомогти curl. Але про це дещо далі.

Спочатку почнемо з базової термінології Elasticsearch.

Кластер (Cluster)

Сервери, що обслуговують один набір даних та забезпечують індексацію та їх пошук по всіх серверах. Кластер також може складатись лише з єдиного сервера, проте в цьому випадку не може йти мова про високу доступність.

Про те як створити кластер я напишу нижче.

неділя, 18 жовтня 2015 р.

Cassandra. Part II: Cluster

Тиждень тому я опублікував першу статтю про базу даних Cassandra. Це була теоретична стаття, у якій переважно було про те як влаштована Cassandra та її особливості. Цього разу я розповім як налаштувати власний кластер Cassandra.

Для побудови кластера будемо використовувати 4 віртуальні машини з такими адресами і хостнеймами:

10.131.75.141  cs-1
10.131.75.142  cs-2
10.131.75.143  cs-3
10.131.75.144  cs-4

Із них і буде складатись кільце кластеру (Token Ring). Отже, створимо ці віртуальні машини та додамо цей список адрес до кожної із них в /etc/hosts. У якості ОС я обрав Ubuntu 14.04. Кількість оперативної пам'яті для кожної віртуальної машини рівна 1 ГБ, що звісно достатньо лише для тестових цілей.

Установлюємо Java:

# add-apt-repository ppa:webupd8team/java
# apt-get update
# apt-get install oracle-java8-installer

# apt-get install oracle-java8-set-default

Та останню версію Cassandra з репозиторіїв DataStax:

# echo "deb http://debian.datastax.com/community stable main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list
# curl -L http://debian.datastax.com/debian/repo_key | sudo apt-key add -

# apt-get update
# aptitude install cassandra
The following NEW packages will be installed:
  cassandra libopts25{a} ntp{a} python-support{a} 
0 packages upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 24.9 MB of archives. After unpacking 34.0 MB will be used.
Do you want to continue? [Y/n/?]

Java та Cassandra, очевидно, необхідні на всіх нодах кластеру. Після установки перевіримо роботу бази, підключившись до неї через CQLSH:

# cqlsh
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 2.2.1 | CQL spec 3.3.0 | Native protocol v4]
Use HELP for help.
cqlsh> 

пʼятниця, 9 жовтня 2015 р.

Cassandra. Part I: Overview

Apache Cassandra — розподілена система керування базами даних, що відноситься до класу noSQL-систем і розрахована на створення високомасштабованих і надійних сховищ величезних масивів даних, представлених у вигляді хеша.

Проект стартував у надрах компанії Facebook і в 2009 році був переданий фонду Apache. В основу Cassandra лягли 2 архітектурні ідеї: Amazon Dynamo та Google Big Table, опис яких був опублікований в 2007 та 2006 роках відповідно.

Цю базу данних використовують такі компанії як IBM, Apple, Netflix, Twitter, Yandex, CERN, Reddit, SoundCloud, Rackspace та інші.

Cassandra проектувалась для великих географічно розподілених систем, тому на відміну від традиційних баз не має багатьох недоліків: масштабування, висока доступність і т.п. тут реалізовано простіше ніж, скажімо, в MySQL. Звісно Cassandra не срібна куля, і при проектуванні інфраструктури треба добре розуміти як архітектору так і розробнику, які запити буде обслуговувати база та інші особливості.

Що ж таке Cassandra? Cassandra - це гібрид key-value и column-oriented баз даних. Термінологія структури данних дещо інша ніж в реліційній моделі, проте не варто на цьому особливо зациклюватись адже це не так важливо.


Тож в Cassandra є бази (keyspace), в котрих знаходяться сімейства колонок (аналог таблиць у реляційній системі), а в самому сімействі, вже майже як і у звичайній таблиці, колонки і рядки. Майже, тому що для кожного рядка може бути визначений свій набір колонок (розріджені таблиці). Як це виглядає в реальному житті? Ну щось схоже на це:


До кожного запису в сімействі колонок також привязане значення timestamp, але воно приховане від очей і використовується для реплікацій та вирішення можливих конфліктів: найбільш актуальні дані - дані з найостаннішим timestamp.