testbed : NoSQL 11.2.2.0

Détails: Catégorie : TestBed; Publié le jeudi 2 mai 2013 20:20; Écrit par Administrator; Affichages : 8046

Cet article décrit la procédure pour installer et paramétrer une base de données NoSQL 11gR2 (11.2.2.0) sous Oracle Linux 6U3.

Prérequis

La version installé dans le présent article est la 11.2.2.0.26 version CE.

A l’heure où l’article est écrit il y a déjà la 11.2.2.0.39 qui est sortie.

Pour télécharger la 11.2.2.0.x, aller sur le lien Download NoSQL (ou bien mon ami google : download nosql oracle )

Pour les OS linux, ils ont été créés avec Oracle VirtualBox, avec exactement les mêmes packages que dans l'excellent article testbed : 11gR2 RAC ASM. Ce sont donc des Oracle Entreprise Linux 6 Update 3.

Installation du moteur NoSQL

Prérequis

Pour installer Oracle NoSQL, préparez 2 serveurs Oracle Linux 6 (même type d’installation que dans testbed : 11gR2 RAC ASM) grâce à Oracle VirtualBox. Vous pouvez utiliser plus de serveurs mais ici, deux suffiront pour comprendre comment NoSQL s’installe.

Prérequis avant de commencer l’installation :

- Les deux serveurs doivent pouvoir être pingable entre eux.

- Le hostname doit être « résolvable » dans le /etc/hosts.

- Les serveurs doivent être synchronisés au niveau temps. Il est recommandé d’avoir moins d’une demi-seconde d’écart. Comme nous utilisons VirtualBox pas de soucis de paramétrage NTP, les machines invités sont synchro à la machine hôte.

- La version de java doit être au minimum JDK 1.6.0u25. La version de java est la 1.6.0u24 en suivant la documentation testbed : 11gR2 RAC ASM, il faut donc faire un upgrade. Ici nous avons installé la 1.6.0u43:

[nosql@nosqldc1 ~]$ java -version
java version "1.6.0_43"

Installation

Dans la documentation il n’est pas précisé s’il faut utiliser un compte particulier avec des droits particuliers. Il y a juste écrit :

You do not necessarily need root access on each node for the installation process.

Donc nous créons sur nos serveurs un compte nommé nosql (original non ?) :

[root@nosqldc1 ~]# useradd -u 2000 nosql

Créons alors le répertoire /NOSQL dans lequel sera stocké le moteur NoSQL et la database (/NOSQL/DATA).

[root@nosqldc1 NoSQL]# mkdir -p /NOSQL
[root@nosqldc1 NoSQL]# mkdir -p /NOSQL/DATA

Décompressons alors le moteur

[root@nosqldc1 NoSQL]# unzip kv-ce-2.0.26.zip -d /NOSQL
[root@nosqldc1 ~]# chown -R nosql.nosql /NOSQL/

Et voilà le moteur NoSQL database est installé. Eh oui c’est plus simple qu’un moteur RAC… oui bon en fait c’est vrai, « installer n’est pas configurer », c’est souvent la configuration qui est plus délicate. Mais aussi une différence avec un moteur Oracle Database, il n’y a pas de compilation de binaire donc de dépendance à des packages.

Configuration

Nous nommerons par la suite KVHOME le répertoire d’installation /NOSQL/kv-2.0.26 des binaires de NoSQL, et nous nommerons KVROOT celui où seront mis les données soit /NOSQL/DATA.

KVHOME et KVROOT doivent être locaux aux serveurs. Evidement vous pouvez utiliser 2 filesystems différents, ici tout a été mis dans le même répertoire (/NOSQL) dans / par facilité.

Ce n’est pas obligatoire, mais peut être pratique, mettre dans le profile du compte nosql:

vi .bash_profile
export KVHOME=/NOSQL/kv-2.0.26
export KVROOT=/NOSQL/DATA

Il faut créer sur chaque nœud le fichier de configuration de boot (de NoSQL)

Sur nosqldc1:

java -jar $KVHOME/lib/kvstore.jar makebootconfig -root $KVROOT -port 5000 -admin 5001 -host nosqldc1 -harange 5010,5020 -capacity 1 -num_cpus 0

A la racine de KVROOT, il y a entre autre le fichier config.xml, que vous pouvez ouvrir. Il contient la configuration.

Puis sur nosqldc2, idem mais on ne précise pas le port d’admin, nosql1 sera le serveur d’admin par défaut au démarrage :

java -jar $KVHOME/lib/kvstore.jar makebootconfig -root $KVROOT -port 5000 -host nosqldc2 -harange 5010,5020 -capacity 1 -num_cpus 0

Pour une explication rapide des paramètres:

-root $KVROOT : là où seront les données

-port 5000 : le port TCP/IP pour se connecter à la base (c’est un peu le 1521 d’Oracle Database )

-admin 5001 : le port TCP/IP d’administration

-host nosql2 : le nom du serveur sur lequel on installe. Le nom et donc l’IP sur laquelle on pourra se connecter.

-harange 5010,5020 : la plage de port pour les nœuds de réplication pour leur communication intrinsèque. Un nœud de réplication = port, donc ici 10 nœuds de réplication possible.

-capacity 1 : la capacité d’un nœud de stockage (ici nosql1 ou nosql2) à supporter un nœud de réplication. 1 est le par défaut, le mettre à plus de 1 dépend de la puissance du serveur.

-num_cpus 0 : le nombre de CPU disponible pour les nœuds de réplication. Le par défaut est 0, et signifie que le nombre total de CPU du serveur pourra être utilisé.

Il y a aussi comme paramétrage possible :

-memory_mb 0 :Comme pour le cpu ci-dessus, mais pour la mémoire. 0 le par défaut et signifie toute la mémoire du serveur.

L’agent des nœuds de stockage (SNA : Storage Node Agent) de la base NoSQL peut être démarré sur chaque nœud comme suit:

nohup java -jar $KVHOME/lib/kvstore.jar start -root $KVROOT&

Pour vérifier que les process de la base NoSQL sont bien up:

[nosql@nosqldc1 NOSQL]$ jps -m
2822 kvstore.jar start -root /NOSQL/DATA
2904 Jps -m
2874 ManagedService -root /NOSQL/DATA -class Admin -service BootstrapAdmin.5000 -config config.xml

Nous constatons un process de plus sur nosql1, celui du service d’administration.

Pour vérifier que le client NoSQL peut contacter le SNA (Storage Node Agent)

[nosql@nosqldc1 NOSQL] java -jar $KVHOME/lib/kvstore.jar ping -port 5000 -host nosqldc1

[nosql@nosqldc1 NOSQL]$ java -jar $KVHOME/lib/kvstore.jar ping -port 5000 -host nosqldc1
SNA at hostname: nosqldc1, registry port: 5000 is not registered.
No further information is available

Non ce n’est pas un message d’erreur, tout va bien, le ping répond qu’il n’y a que le SNA qui est up. En fait c’est un peu comme un « lsnrctl status », qui répondrait que le listener est up mais qu’il n’y a aucune base de donnée Oracle d’enregistrée.

Configurer le "magasin"

Nous avons un moteur qui tourne, c’est bien, mais maintenant il faut configurer le KVStore : collection de nœud de stockage (Storage Node SN)

Pour configurer, il faut utiliser l’utilitaire runadmin. C’est un outil de ligne de commande :

[nosql@nosqldc1 NOSQL]$ java -jar $KVHOME/lib/kvstore.jar runadmin -port 5000 -host nosqldc1
kv->

Nommons le KVstore :

kv-> configure -name monmagasin
Store configured: monmagasin

Crééons le Data Center

kv-> plan deploy-datacenter -name "Toulouse" -rf 2 -wait
Executed plan 1, waiting for completion...
Plan 1 ended successfully

kv-> show plans
1 Deploy Datacenter (1) SUCCEEDED

Nous avons mis ici 2 à la variable rf (Replication Factor), cela signifie que nous aurons des Shards de 2 RN (Replication Node).

kv-> show topology
store=monmagasin numPartitions=0 sequence=1
dc=[dc1] name=Toulouse repFactor=2

Maintenant il faut créer le process d’administration sur un SN en particulier… choisissons au hasard nosqldc1

kv-> plan deploy-sn -dc dc1 -host nosqldc1 -port 5000 –wait

kv-> plan deploy-admin -sn sn1 -port 5001 –wait

kv-> show topology
store=monmagasin numPartitions=0 sequence=2
dc=[dc1] name=Toulouse repFactor=2
sn=[sn1] dc=dc1 nosqldc1:5000 capacity=1 RUNNING

Créeons un pool de SN, et mettons y le sn1 (nosqldc1):

kv-> pool create -name ToulousePool

kv->pool join -name ToulousePool -sn sn1
Added Storage Node(s) [sn1] to pool ToulousePool

Comme nous avons créé précédemment un process d’administration, nous pouvons nous y connecter en http (nosqldc1:5001)…

…et voir graphiquement ce que nous sommes en train de construire... comme c'est beau!

Nous ne voyons que nosqldc1, nous allons maintenant rajouter son copain nosqldc2.

Sur nosqldc2 nous vérifions que le moteur NoSQL est bien up:

[nosql@nosqldc2 DATA]$ jps -m
2580 Jps -m
2540 kvstore.jar start -root /NOSQL/DATA

Et à partir de nosqldc1 nous rajoutons nosqldc2 dans notre Data Center Toulouse (DC1):

kv-> plan deploy-sn -dc dc1 -host nosqldc2 -port 5000 -wait
Executed plan 5, waiting for completion...
Plan 5 ended with errors. Use "show plan -id 5" for more information

Aïe aïe… que ce passé-t-il donc ? Moi qui aime quand un plan se déroule sans accroc.

Voyons voir:

kv-> show plan -id 5
Plan Deploy Storage Node (5)
State:                 ERROR
Attempt number:        1
Started:               2013-04-13 19:55:23 UTC
Ended:                 2013-04-13 19:55:23 UTC
Plan failures:
       Failure 1: 1/DeploySN failed.: Exception creating connection to: nosqldc2; nested exception is:
       java.net.NoRouteToHostException: No route to host
Total tasks:          1
Failed:               1
Failures:   Task   1       ERROR at   2013-04-13 19:55:23 UTC: DeploySN sn2(nosqldc2:5000): 1/DeploySN failed.: Exception creating connection to:
nosqldc2; nested exception is:
       java.net.NoRouteToHostException: No route to host: java.rmi.ConnectIOException: Exception creating connection to: nosqldc2; nested exception is:
       java.net.NoRouteToHostException: No route to host
       at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:614)
[...]
       at java.lang.Thread.run(Thread.java:662)
Caused by: java.net.NoRouteToHostException: No route to host
       at java.net.PlainSocketImpl.socketConnect(Native Method)
       at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
       at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
[...]
      at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:128)
       at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:595)
       ... 16 more

java.net.NoRouteToHostException: No route to host --> Pourtant nosqldc2 est bien résolvable est joignable à partir de nosqldc1 et vice versa…

Comme souvent il faut penser au firewall...

[root@nosqldc1 ~]# /etc/init.d/iptables stop
iptables: Flushing firewall rules:                         [ OK ]
iptables: Setting chains to policy ACCEPT: filter          [ OK ]
iptables: Unloading modules:                               [ OK ]
[root@nosqldc1 ~]# chkconfig iptables off

Et même punition sur nosqldc2

Recommençons

kv-> plan deploy-sn -dc dc1 -host nosqldc2 -port 5000 -wait
Executed plan 6, waiting for completion...
Plan 6 ended successfully

Parfait! J'aime quand un plan se déroule sans accroc.

kv-> show topology
store=monmagasin numPartitions=0 sequence=3

dc=[dc1] name=Toulouse repFactor=2

sn=[sn1] dc=dc1 nosqldc1:5000 capacity=1 RUNNING
sn=[sn2] dc=dc1 nosqldc2:5000 capacity=1 RUNNING

Voyons cela graphiquement:

Ajoutons nosqldc2 (sn2) dans le pool à son tour

kv-> pool join -name ToulousePool -sn sn2
Added Storage Node(s) [sn2] to pool ToulousePool

Créeons enfin notre Topology.

kv-> topology create -name topo -pool ToulousePool -partitions 300
Created: topo

kv-> plan deploy-topology -name topo -wait

Le 300, ici, représente le nombre maximal de Shards. Ce nombre ne pourra plus être changé, c’est pour la vie !!! Donc ici nous avons mis 300 Shards, donc nous ne devrons jamais avoir plus de 300 partitions.

Admirons cela en texte…

kv-> show topology
store=monmagasin numPartitions=300 sequence=306
dc=[dc1] name=Toulouse repFactor=2

sn=[sn1] dc=dc1 nosqldc1:5000 capacity=1 RUNNING
    [rg1-rn1] RUNNING
          No performance info available
sn=[sn2] dc=dc1 nosqldc2:5000 capacity=1 RUNNING
    [rg1-rn2] RUNNING
          No performance info available

shard=[rg1] num partitions=300
    [rg1-rn1] sn=sn1
    [rg1-rn2] sn=sn2

… bof pas très visual tout ça…

En mode graphique…

… ah oui.

Nous avons clairement 2 SN (nosqldc1 et nosqldc2), avec le même RG (Replication Group), ils forment donc un Shard.

[A SUIVRE]

Nous avons ici une configuration assez simple, avec un seul Shard. Ici peut peut-être prochainement, comment rajouter des Shards ou alors cela sera dans la rubrique « about tech ».