TOC

Comment créer un cluster Sharded RethinkDB sur Ubuntu 14.04

introduction

  • RethinkDB * est une base de données NoSQL. Il dispose d’une API facile à utiliser pour interagir avec la base de données. RethinkDB simplifie également la configuration de clusters de bases de données. c’est-à-dire des groupes de serveurs desservant les mêmes bases de données et tables. Les grappes permettent de mettre facilement à l’échelle vos bases de données sans temps d’arrêt.

Ce didacticiel explique comment configurer un cluster, importer des données et le sécuriser. Si vous êtes nouveau sur RethinkDB, consultez les bases dans https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-rethinkdb-on-an-ubuntu-12-04-vps [ ce tutoriel] avant de plonger dans le processus de configuration de cluster plus complexe.

Conditions préalables

Ce didacticiel nécessite au moins deux Droplets exécutant Ubuntu 14.04 LTS, nommés * rethink1 * & * rethink2 * (ces noms seront utilisés tout au long de ce didacticiel). Vous devez mettre en place un utilisateur sudo non root sur chaque Droplet avant de configurer RethinkDB - cela constitue une bonne pratique de sécurité.

Ce tutoriel fait également référence au pilote client Python, qui est expliqué dans https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-rethinkdb-on-an-ubuntu-12-04-vps [ce tutoriel].

Configurer un nœud

Les clusters dans RethinkDB n’ont pas de nœuds spéciaux; c’est un réseau peer-to-peer pur. Avant de pouvoir configurer le cluster, nous devons installer RethinkDB. Sur chaque serveur, à partir de votre répertoire personnel, ajoutez la clé RethinkDB et le référentiel à apt-get:

source /etc/lsb-release && echo "deb http://download.rethinkdb.com/apt $DISTRIB_CODENAME main" | sudo tee /etc/apt/sources.list.d/rethinkdb.list

wget -qO- http://download.rethinkdb.com/apt/pubkey.gpg | sudo apt-key add -

Puis mettez à jour apt-get et installez RethinkDB:

sudo apt-get update
sudo apt-get install rethinkdb

Ensuite, nous devons configurer RethinkDB pour s’exécuter au démarrage. RethinkDB est livré avec un script à exécuter au démarrage, mais ce script doit être activé:

sudo cp /etc/rethinkdb/default.conf.sample /etc/rethinkdb/instances.d/cluster_instance.conf

Le script de démarrage sert également de fichier de configuration. Ouvrons ce fichier:

sudo nano /etc/rethinkdb/instances.d/cluster_instance.conf

Le nom de l’ordinateur (celui de la console de gestion Web et des fichiers journaux) est défini dans ce fichier. Faisons en sorte que ce nom soit le même que le nom d’hôte de la machine en recherchant la ligne (tout en bas):

# machine-name=server1

Et le changer pour:

machine-name=

(Remarque: si vous ne définissez pas le nom avant de lancer RethinkDB pour la première fois, un nom de thème DOTA sera automatiquement défini.)

Configurez RethinkDB pour qu’il soit accessible à partir de toutes les interfaces réseau en recherchant la ligne:

# bind=127.0.0.1

Et le changer pour:

bind=all

Enregistrez la configuration et fermez nano (en appuyant sur les touches + Ctrl-X +, puis + Y +, puis + Enter +). Nous pouvons maintenant démarrer RethinkDB avec le nouveau fichier de configuration:

sudo service rethinkdb start

Vous devriez voir cette sortie:

rethinkdb: cluster_instance: Starting instance. (logging to `/var/lib/rethinkdb/cluster_instance/data/log_file')

RethinkDB est maintenant opérationnel.

Sécuriser RethinkDB

Nous avons activé l’option + bind = all +, rendant RethinkDB accessible de l’extérieur du serveur. C’est peu sûr. Nous devrons donc bloquer RethinkDB d’Internet. Mais nous devons autoriser l’accès à ses services à partir d’ordinateurs autorisés.

Pour le port du cluster, nous utiliserons un pare-feu pour entourer notre cluster. Pour la console de gestion Web et le port du pilote, nous utiliserons des tunnels SSH pour y accéder depuis l’extérieur du serveur. Les tunnels SSH redirigent les demandes d’un ordinateur client vers un ordinateur distant via SSH, donnant ainsi au client l’accès à tous les services disponibles uniquement dans l’espace de noms localhost du serveur distant.

Répétez ces étapes sur tous vos serveurs RethinkDB.

Tout d’abord, bloquez toutes les connexions extérieures:

# The Web Management Console
sudo iptables -A INPUT -i eth0 -p tcp --dport 8080 -j DROP
sudo iptables -I INPUT -i eth0 -s 127.0.0.1 -p tcp --dport 8080 -j ACCEPT

# The Driver Port
sudo iptables -A INPUT -i eth0 -p tcp --dport 28015 -j DROP
sudo iptables -I INPUT -i eth0 -s 127.0.0.1 -p tcp --dport 28015 -j ACCEPT

# The Cluster Port
sudo iptables -A INPUT -i eth0 -p tcp --dport 29015 -j DROP
sudo iptables -I INPUT -i eth0 -s 127.0.0.1 -p tcp --dport 29015 -j ACCEPT

Pour plus d’informations sur la configuration des tables IPTables, consultez la page https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-using-iptables-on-ubuntu-14-04]. .

Installons «iptables-persistent» pour sauvegarder nos règles:

sudo apt-get update
sudo apt-get install iptables-persistent

Vous verrez un menu comme celui-ci:

image: https: //assets.digitalocean.com/articles/RethinkDB_Ubuntu14/1.png [Image IPtables]

Sélectionnez l’option + Yes (appuyez sur` + Entrée`) pour enregistrer les règles de pare-feu. Vous verrez également un menu similaire sur les règles IPv6, que vous pouvez également enregistrer.

Mise en place d’un utilisateur de gestion

Pour accéder à la console de gestion Web de RethinkDB et à l’interface du pilote, nous devons configurer le tunnel SSH. Créons un nouvel utilisateur pour le tunnel ssh sur * rethink1 *:

sudo adduser ssh-to-me

Configurez ensuite le fichier de clés autorisées pour notre nouvel utilisateur:

sudo mkdir /home/ssh-to-me/.ssh
sudo touch /home/ssh-to-me/.ssh/authorized_keys

Si vous utilisez SSH pour vous connecter au serveur cloud, ouvrez un terminal sur * votre ordinateur local *. Si ce n’est pas le cas, vous pouvez en savoir plus sur les clés SSH. Obtenez votre clé publique et copiez-la dans votre presse-papiers:

cat ~/.ssh/id_rsa.pub

Ajoutez ensuite cette clé au nouveau compte en ouvrant le fichier allowed_keys * sur le serveur *:

sudo nano /home/ssh-to-me/.ssh/authorized_keys

Collez votre clé dans le fichier. Puis sauvegardez et fermez nano (+ Ctrl-X +, puis + Y +, puis + Enter +).

'' '' '

Vous devez répéter toutes ces étapes pour vos autres nœuds de cluster.

Importer ou créer une base de données

Vous souhaiterez peut-être importer une base de données préexistante dans votre cluster. Cela n’est nécessaire que si vous avez une base de données préexistante sur un autre serveur ou sur ce serveur; sinon, RethinkDB créera automatiquement une base de données vide.

  • Si vous avez besoin d’importer une base de données externe: *

Si la base de données que vous souhaitez importer n’est pas stockée sur + rethink1 +, vous devez la copier. Tout d’abord, recherchez le chemin de votre base de données RethinkDB actuelle. Ce serait le répertoire + rethinkdb_data + créé automatiquement si vous utilisiez la commande + rethinkdb + pour démarrer votre ancienne base de données. Ensuite, copiez-le en utilisant + scp + on * rethink1 *:

sudo scp -rpC @://* /var/lib/rethinkdb/cluster_instance/data

Par exemple:

sudo scp -rpC [email protected]:/home/user/rethinkdb_data/* /var/lib/rethinkdb/cluster_instance/data

Puis redémarrez RethinkDB:

sudo service rethinkdb restart

  • Si vous avez une base de données existante sur Rethink1: *

Si vous avez une base de données RethinkDB existante sur * rethink1 *, la procédure est différente. Commencez par ouvrir le fichier de configuration sur * rethink1 *:

sudo nano /etc/rethinkdb/instances.d/cluster_instance.conf

Ensuite, recherchez le chemin de la base de données RethinkDB que vous souhaitez importer. Ce serait le répertoire + rethinkdb_data + créé automatiquement si vous utilisiez la commande + rethinkdb + pour démarrer votre ancienne base de données. Insérez ce chemin dans le fichier de configuration en ajoutant la ligne:

directory=

Fermez le fichier pour enregistrer vos modifications (en utilisant + Ctrl-X +, puis + Y +, puis + Entrée +). Maintenant, redémarrez RethinkDB:

sudo service rethinkdb restart

Il est important de noter que l’importation d’une base de données préexistante signifie que * rethink1 * héritera du nom de l’ancien ordinateur de la base de données. Vous aurez besoin de le savoir lors de la gestion du partage de la base de données ultérieurement.

Créer un cluster

Pour créer un cluster, vous devez autoriser tous les ordinateurs du cluster à traverser les pare-feu des autres. Sur votre ordinateur * rethink1 *, ajoutez une règle IPTables pour autoriser les autres nœuds à traverser le pare-feu. Dans cet exemple, vous devez remplacer + rethink2 IP + par l’adresse IP de ce serveur:

sudo iptables -I INPUT -i eth0 -s  -p tcp --dport 29015 -j ACCEPT

Répétez la commande pour tous les autres nœuds que vous souhaitez ajouter.

Enregistrez ensuite les règles du pare-feu:

sudo sh -c "iptables-save > /etc/iptables/rules.v4"

Répétez ensuite ces étapes pour vos autres nœuds. Pour une configuration à deux serveurs, vous devez maintenant vous connecter à * rethink2 * et débloquer l’IP de * rethink1 *.

Vous devez maintenant connecter tous les nœuds pour créer un cluster. Utilisez SSH pour vous connecter à * rethink2 * et ouvrez le fichier de configuration:

sudo nano /etc/rethinkdb/instances.d/cluster_instance.conf

L’option + join + spécifie l’adresse du cluster à rejoindre. Recherchez la ligne + join + dans le fichier de configuration:

# join=example.com:29015

Et remplacez-le par:

join=

Enregistrez et fermez le fichier de configuration (en utilisant + Ctrl-X +, puis + Y +, puis + Entrée +). Puis redémarrez RethinkDB:

sudo service rethinkdb restart

Le premier noeud, * rethink1 *, n’a PAS besoin de la mise à jour + join +. Répétez l’édition du fichier de configuration sur tous les autres nœuds, à l’exception de * rethink1 *.

Vous avez maintenant un cluster RethinkDB entièrement fonctionnel!

Connexion à la console de gestion Web

La console de gestion Web est une interface en ligne facile à utiliser qui donne accès aux fonctions de gestion de base de RethinkDB. Cette console est utile lorsque vous devez afficher le statut du cluster, exécuter une seule commande RethinkDB et modifier les paramètres de table de base.

Chaque instance RethinkDB du cluster sert une console de gestion, mais cela n’est disponible qu’à partir de l’espace de noms localhost du serveur, car nous avons utilisé les règles de pare-feu pour la bloquer du reste du monde. Nous pouvons utiliser un tunnel SSH pour rediriger nos demandes de + localhost: 8080 + vers * rethink1 *, qui enverra la demande à + ​​localhost: 8080 + à l’intérieur de son espace de noms. Cela vous permettra d’accéder à la console de gestion Web. Vous pouvez le faire en utilisant SSH sur votre * ordinateur local *:

ssh -L 8080:localhost:8080 ssh-to-me@

Si vous allez sur http: // localhost: 8080 [localhost: 8080] dans votre navigateur, vous verrez maintenant votre console de gestion Web RethinkDB.

Si vous recevez une erreur + bind: Address already in use, vous utilisez déjà le port 8080 sur votre ordinateur. Vous pouvez transférer la console de gestion Web sur un autre port, disponible sur votre ordinateur. Par exemple, vous pouvez le transférer sur le port 8081 et accéder à http: // localhost: 8081 [localhost: 8081]:

ssh -L :localhost:8080 ssh-to-me@

Si vous constatez un conflit au sujet de deux bases de données de test, vous pouvez en renommer l’une.

Connexion au cluster avec le pilote Python

Dans cette configuration, tous les serveurs RethinkDB (la console de gestion Web, le port du pilote et le port du cluster) sont bloqués du monde extérieur. Nous pouvons utiliser un tunnel SSH pour nous connecter au port du pilote, comme avec la console de gestion Web. Le port de pilote correspond au mode de connexion des pilotes d’API RethinkDB (ceux avec lesquels vous construisez des applications) à votre cluster.

Tout d’abord, choisissez un nœud avec lequel vous connecter. Si plusieurs clients (serveurs d’applications Web, par exemple) se connectent au cluster, vous souhaiterez les équilibrer à travers le cluster. Ce serait une bonne idée d’écrire une liste de vos clients, puis d’attribuer un serveur pour chaque client. Essayez de regrouper les clients afin que les clients ayant besoin de tables similaires se connectent au même serveur cloud ou au même groupe de serveurs et qu’aucun serveur ne soit surchargé avec un grand nombre de clients.

Dans cet exemple, nous utiliserons * rethink2 * comme serveur de connexion. Toutefois, dans un système plus vaste où la base de données et les serveurs d’applications Web sont séparés, vous souhaiterez utiliser un serveur d’applications Web effectuant des appels de base de données.

Ensuite, sur le * serveur de connexion *, générez une clé SSH:

ssh-keygen -t rsa

Et copiez-le dans votre presse-papiers:

cat ~/.ssh/id_rsa.pub

Puis autorisez la nouvelle clé sur le * nœud du cluster * (dans cet exemple, * rethink1 *) en ouvrant le fichier + allowed_keys + et en collant la clé sur une nouvelle ligne:

sudo nano /home/ssh-to-me/.ssh/authorized_keys

Fermez nano et sauvegardez le fichier (+ Ctrl-X +, puis + Y +, puis + Enter +).

Ensuite, utilisez le tunneling SSH pour accéder au port du pilote, à partir du * serveur de connexion *:

ssh -L 28015:localhost:28015 ssh-to-me@ -f -N

Le pilote est maintenant accessible depuis localhost: 28015. Si vous obtenez une erreur + bind: Address already in use, vous pouvez modifier le port. Par exemple, utilisez le port 28016:

ssh -L 28016:localhost:28015 ssh-to-me@ -f -N

Installez le pilote Python sur le * serveur de connexion *. Il y a une brève analyse des commandes ici, et vous pouvez en savoir plus en détail sur https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-rethinkdb-on-an -ubuntu-12-04-vps [ce tutoriel].

Installez l’environnement virtuel Python:

sudo apt-get install python-virtualenv

Créez le répertoire + ~ / rethink +:

cd ~
mkdir rethink

Déplacez-vous dans le répertoire et créez la nouvelle structure d’environnement virtuel:

cd rethink
virtualenv venv

Activez l’environnement (vous devez l’activer à chaque fois avant de démarrer l’interface Python, sinon vous obtiendrez une erreur concernant les modules manquants):

source venv/bin/activate

Installez le module RethinkDB:

pip install rethinkdb

Maintenant, démarrez Python à partir du * serveur de connexion *:

python

Connectez-vous à la base de données en veillant à remplacer «+ 28015 +» par le port que vous avez utilisé, si nécessaire:

import rethinkdb as r
r.connect("localhost", ).repl()

Créez la table + test:

r.db("test").table_create("test").run()

Insérer des données dans la table + test:

r.db("test").table("test").insert({"hello":"world"}).run()
r.db("test").table("test").insert({"hello":"world number 2"}).run()

Et imprimez les données:

list(r.db("test").table("test").run())

Vous devriez voir une sortie similaire à celle-ci:

[{u'hello': u'world number 2', u'id': u'0203ba8b-390d-4483-901d-83988e6befa1'},
{u'hello': u'world', u'id': u'7d17cd96-0b03-4033-bf1a-75a59d405e63'}]

Mise en place de l’éclatement

Dans RethinkDB, vous pouvez configurer une table pour qu’elle soit partagée (fractionnée) entre plusieurs serveurs de cloud. La fragmentation est un moyen simple d’obtenir des ensembles de données plus volumineux que ceux contenus dans la RAM d’une seule machine, car davantage de RAM est disponible pour la mise en cache. Étant donné que le partage partage également le jeu de données entre plusieurs ordinateurs, vous pouvez disposer de tables plus grandes et moins performantes, car davantage d’espace disque est disponible pour la table. Cela peut être fait via la console de gestion Web.

Pour ce faire, accédez à l’onglet * Tables * de la console de gestion Web.

image: https: //assets.digitalocean.com/articles/RethinkDB_Ubuntu14/2.png [Liste des tableaux]

Cliquez sur le tableau * test * (celui que nous avons créé dans la section précédente) pour entrer ses paramètres. Faites défiler jusqu’à la carte * Paramètres de fragmentation *.

image: https: //assets.digitalocean.com/articles/RethinkDB_Ubuntu14/3.png [Carte de réglages d’éclatement]

Cliquez sur le bouton * Modifier *. Vous pouvez y entrer le nombre de serveurs sur lesquels diviser la table. Entrez * 2 * pour cet exemple. Cliquez sur le bouton * Rééquilibrer * pour enregistrer le paramètre.

Vous remarquerez peut-être qu’il y a un maximum de fragments que vous pouvez avoir. C’est égal au nombre de documents dans votre base de données. Si vous essayez de configurer le sharding pour une nouvelle table, vous devrez soit attendre plus de données, soit ajouter des données factices pour vous permettre d’ajouter plus de fragments.

Éclatement avancé

En interne, RethinkDB a des fragments basés sur la plage, basés sur les identifiants de document. Cela signifie que si nous avons un jeu de données avec les identifiants A, B, C et D, RethinkDB pourrait le scinder en 2 fragments: A, B (-infinity en C) et C, D (C à + infini). Si vous deviez insérer un document portant l’ID A1, il se trouverait dans la plage du premier fragment (-infinity to C), de sorte qu’il irait dans ce fragment. Nous pouvons définir les limites des fragments, ce qui peut optimiser la configuration de votre base de données.

Avant de pouvoir le faire, nous voudrons ajouter un jeu de données avec lequel jouer. Dans l’onglet * Explorateur de données * de la console de gestion Web, vous pouvez créer une table en exécutant cette commande (cliquez sur * Exécuter * après avoir tapé):

r.db('test').tableCreate('testShards')

Ensuite, insérez nos données de test:

r.db("test").table("testShards").insert([
 {id:"A"},
 {id:"B"},
 {id:"C"},
 {id:"D"},
 {id:"E"}])

Nous pouvons maintenant configurer les fragments en détail. Pour ce faire, nous devons entrer dans le shell admin. Le shell admin est un moyen plus évolué de contrôler votre cluster, vous permettant d’affiner votre configuration. Sur la machine * rethink1 *, ouvrez le shell admin:

rethinkdb admin

Ensuite, nous pouvons voir des informations sur notre table:

ls test.testShards

Production attendue:

table 'testShards' b91fda27-a9f1-4aeb-bf6c-a7a4211fb674

...

1 replica for 1 shard
shard      machine uuid                          name      primary
-inf-+inf  91d89c12-01c7-487f-b5c7-b2460d2da22e  rethink1  yes

Dans RethinkDB, il existe plusieurs façons de nommer une table. Vous pouvez utiliser + database.name + (+ test.testShards +), le nom (+ testShards +) ou la table uuid (+ e780f2d2-1baf-4667-b725-b228c7869aab +). Ceux-ci peuvent tous être utilisés de manière interchangeable.

Séparons cet éclat. Nous allons faire 2 fragments: -infinity to C et C to + infinity:

split shard test.testShards C

La forme générique de la commande est la suivante:

split shard

Si vous exécutez + ls testShards + à nouveau, le fragment a été divisé. Vous souhaiterez peut-être déplacer le nouveau fragment d’une machine à une autre. Pour cet exemple, nous pouvons épingler (déplacer) le fragment + -inf-C + (-infinty en C) sur la machine * rethink2 *:

pin shard test.testShards -inf-C --master rethink2

La forme générique de la commande est la suivante:

pin shard  --master

Si vous répétez + ls testShards +, vous devriez voir que la partition a été déplacée sur un autre serveur.

Nous pouvons également fusionner 2 fragments si nous connaissons la limite commune. Fusionnons les fragments que nous venons de créer (-infinity en C et C en + infini):

merge shard test.testShards C

La forme générique de la commande est la suivante:

merge shard

Pour quitter le shell, tapez + exit +

Retirer une machine en toute sécurité

Lorsqu’un document est divisé en plusieurs machines, une machine conservera toujours son index principal. Si le serveur cloud avec l’index primaire d’un document particulier est mis hors ligne, le document sera perdu. Par conséquent, avant de supprimer une machine, vous devez en éloigner tous les fragments principaux.

Dans cet exemple, nous allons essayer de migrer les données du nœud * rethink2 * pour laisser * rethink1 * en tant que nœud unique.

Entrez le shell admin RethinkDB sur * rethink1 *:

rethinkdb admin

Commençons par lister les fragments (groupes de documents) que * rethink2 * est responsable de:

ls rethink2

Votre sortie devrait ressembler à ceci:

machine 'rethink2' bc2113fc-efbb-4afc-a2ed-cbccb0c55897
in datacenter 00000000-0000-0000-0000-000000000000

hosting 1 replicas from 1 tables
table                                 name        shard                                               primary
b91fda27-a9f1-4aeb-bf6c-a7a4211fb674  testShards  -inf-+inf                                           yes

Cela montre que * rethink2 * est responsable du fragment principal d’une table avec l’id «bdfceefb-5ebe-4ca6-b946-869178c51f93». Ensuite, nous allons déplacer ce fragment sur * rethink1 *. C’est ce qu’on appelle épingler:

pin shard test.testShards -inf-+inf --master rethink1

La forme générique de la commande est la suivante:

pin shard  --master

Si vous exécutez maintenant + ls rethink1 + vous verrez que le fragment a été déplacé vers cette machine. Une fois que chaque fragment a été déplacé de * rethink2 * vers * rethink1 *, vous devez quitter le shell admin:

exit

Il est maintenant prudent d’arrêter RethinkDB sur le serveur indésirable. Important: exécutez ceci sur la machine que vous voulez remove. Dans cet exemple, nous allons l’exécuter sur * rethink2 *:

sudo service rethinkdb stop

Lors de votre prochaine visite sur la console de gestion Web, RethinkDB affichera un avertissement rouge vif. Cliquez sur * Résoudre les problèmes *.

image: https: //assets.digitalocean.com/articles/RethinkDB_Ubuntu14/4.png [RethinkDB Issues List]

Si le problème présenté ressemble à celui ci-dessus et qu’aucune responsabilité principale n’est répertoriée, cliquez sur * Supprimer définitivement *. Cela supprimera la machine du cluster. S’il répertorie les responsabilités principales, réactivez RethinkDB (+ sudo service rethinkdb start +) et assurez-vous de migrer chaque fragment principal à partir de ce serveur.

Remarque: Si vous essayez d’ajouter de nouveau la machine au cluster, des messages concernant une machine zombie s’afficheront. Vous pouvez supprimer le répertoire de données pour résoudre ce problème:

sudo rm -r /var/lib/rethinkdb/cluster_instance/
sudo service rethinkdb restart
Related