nosql:install_oracle_nosql_db_11gr2
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen RevisionVorhergehende Überarbeitung | |||
nosql:install_oracle_nosql_db_11gr2 [2013/09/16 14:42] – gpipperr | nosql:install_oracle_nosql_db_11gr2 [2014/06/06 14:58] (aktuell) – [Boot Konfiguration erstellen] gpipperr | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
+ | ====== Installation Oracle NoSQL Database 11gR2 (11.2.2.0.39) ====== | ||
+ | ==== Übersicht über die Architektur ==== | ||
+ | |||
+ | In der folgenden Übersicht wird von einen Replikationsfaktor von Drei ausgegangen, | ||
+ | Es werden drei physikalische Server eingesetzt. | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | * SN = Storage Node = Physikalischer Rechner mit lokalen Plattenplatz | ||
+ | * SNA = Storage Node Agent = Kontroll Prozess | ||
+ | * KVStore = Das Speicherarray mit den Storage Nodes | ||
+ | * Storage Node Master = Pro Node ein Master (schreibt / ließt) und repliziert mit dem [[http:// | ||
+ | * Storage Node Replication = Kopie der Daten von einen Storage Node Master für die Ausfallsicherheit | ||
+ | * Replikationsgruppe =Ein Master und min. eine Replika | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ==== Installation ==== | ||
+ | |||
+ | |||
+ | Installation einer Oracle NoSQL Datenbank auf drei Oracle Linux 6.4 Server | ||
+ | |||
+ | Ablauf: | ||
+ | * Betriebssystem auf den Servern bereitstellen | ||
+ | * FW Konfiguration plannen, falls FW zwischen den Knoten und der eigentlichen Anwendung | ||
+ | * Java auf den Servern aufsetzen | ||
+ | * Deploy der Oracle NoSQL Software | ||
+ | * Aufsetzen der Store Struktur | ||
+ | |||
+ | |||
+ | === Download Software === | ||
+ | |||
+ | Die benötigte Software: | ||
+ | * [[http:// | ||
+ | * Oracle Linux 6.4 - Download über [[https:// | ||
+ | * Java Kit 7 - Download über [[http:// | ||
+ | * oder alternativ : Oracle JRockit - Download über [[http:// | ||
+ | |||
+ | |||
+ | ===== Installation Linux Umgebung ===== | ||
+ | |||
+ | * Installation Oracle Linux 6.4 Basis ( Desktop Umgebung nur bei Bedarf) | ||
+ | * Yum Repository prüfen, Konfiguration bei Bedarf anlegen <code bash> | ||
+ | # cd / | ||
+ | # wget http:// | ||
+ | </ | ||
+ | * Update mit "yum update" | ||
+ | * SELinux deaktiviert :<code bash> | ||
+ | [root@nosqldb01 ~]# | ||
+ | vi / | ||
+ | .. | ||
+ | SELINUX=disabled | ||
+ | .. | ||
+ | |||
+ | [root@nosqldb01 ~]# reboot | ||
+ | |||
+ | [root@nosqldb01 | ||
+ | |||
+ | </ | ||
+ | * Firewall Einstellungen prüfen und je nach Umgebung einstellen! | ||
+ | * Auf die richtige Uhrzeit achten und per ntpd die Zeit auf allen Servern im Store immer richtig einstellen lassen! | ||
+ | |||
+ | ===Oracle User anlegen=== | ||
+ | |||
+ | <code bash> | ||
+ | groupadd -g 1000 oinstall | ||
+ | useradd -u 1100 -g oinstall oracle | ||
+ | passwd oracle | ||
+ | </ | ||
+ | |||
+ | |||
+ | ===Software Verzeichnis anlegen === | ||
+ | |||
+ | <code bash> | ||
+ | mkdir -p /opt/oracle | ||
+ | chown -R oracle: | ||
+ | chmod -R 775 /opt/oracle | ||
+ | </ | ||
+ | |||
+ | ===Java Version prüfen - JDK nach Bedarf installieren === | ||
+ | ** Als User root! ** | ||
+ | \\ | ||
+ | |||
+ | Kopieren von jdk-7u25-linux-x64.rpm auf dem Server und installieren/ | ||
+ | <code bash> | ||
+ | # Java installieren | ||
+ | yum install | ||
+ | |||
+ | |||
+ | # Java aktivieren | ||
+ | # Neue Java Version dem OS bekannt geben | ||
+ | / | ||
+ | # Versionen anzeigen | ||
+ | / | ||
+ | # Version einstellen | ||
+ | / | ||
+ | # testen | ||
+ | java -version | ||
+ | </ | ||
+ | |||
+ | Alternativ kann auch Oracle JRockit eingesetzt werden, siehe hier als Anleitung [[http:// | ||
+ | \\ | ||
+ | Für das Oracle Sun JDK ist hier ein hilfreicher Link [[http:// | ||
+ | |||
+ | Das Programm jps muss auf dem Server im Pfad liegen/ | ||
+ | |||
+ | <code bash> | ||
+ | jps-m | ||
+ | |||
+ | # falls fehler | ||
+ | # über /usr/bin verlinken | ||
+ | ln -s / | ||
+ | |||
+ | </ | ||
+ | |||
+ | |||
+ | ===Software auf den Server kopieren und entpacken/ | ||
+ | **User Oracle!** | ||
+ | \\ | ||
+ | Entpacken der Software in das Verzeichnis / | ||
+ | |||
+ | <code bash> | ||
+ | mkdir -p / | ||
+ | unzip kv-cc-2.0.39.zip -d / | ||
+ | </ | ||
+ | |||
+ | Umgebungsvariable KVHOME in der Bash setzen und je nach Vorlieben permanent einrichten: | ||
+ | <code bash> | ||
+ | export KVHOME=/ | ||
+ | </ | ||
+ | |||
+ | Testen der Installation mit: | ||
+ | <code bash> | ||
+ | # zeigt die installierte Software Version | ||
+ | java -jar $KVHOME/ | ||
+ | 11gR2.2.0.39 | ||
+ | </ | ||
+ | ==== Anlegen der Storage Location ==== | ||
+ | **User Oracle!** | ||
+ | \\ | ||
+ | |||
+ | Anlegen des KVROOT Verzeichnisses, | ||
+ | |||
+ | <code bash> | ||
+ | |||
+ | mkdir / | ||
+ | |||
+ | </ | ||
+ | |||
+ | ==== Clonen der Umgebung um die weitern Storage Node zu konfigurieren ==== | ||
+ | |||
+ | Die bestehende Umgebung stoppen und als Clone Template verwenden um die Hosts 2 und 3 anzulegen | ||
+ | |||
+ | Tipp: | ||
+ | Daran denken das nach einen Clone einer Linux 6 Maschine die Netzwerkkarten Konfiguration stark verbogen wird, | ||
+ | siehe [[http:// | ||
+ | |||
+ | Die Namensauflösung zwischen den Knoten prüfen und bei Bedarf die Namen in der hosts Datei eintragen. Darauf achten, dass auch der eigenen Name des Servers richtig aufgelöst wird. | ||
+ | |||
+ | |||
+ | ==== FW Konfiguration plannen, falls FW zwischen den Knoten und der eigentlichen Anwendung ==== | ||
+ | |||
+ | Soll eine FW den Zugriff zwischen den Store und der Applikation kontrollieren, | ||
+ | |||
+ | Der Client/ | ||
+ | |||
+ | |||
+ | ==== Boot Konfiguration erstellen ==== | ||
+ | ** User Oracle auf jeden Knoten ** | ||
+ | |||
+ | Vorüberlegungen: | ||
+ | Auf welchen Knoten soll der Admin Service laufen - in unserem Beispiel auf Node 1 | ||
+ | |||
+ | |||
+ | Parameter bestimmen: | ||
+ | |||
+ | * **root** | ||
+ | * KVROOT Verzeichnis für die abzulegenden Daten | ||
+ | * **port** < | ||
+ | * TCP/IP Port um den Knoten auf Client aus zu erreichen wie 5000 | ||
+ | * **admin** < | ||
+ | * TCP/IP Port für die ADMIN Web Console wie 5001 | ||
+ | * **harange** < | ||
+ | * Portrange für die interne Kommunikation der Nodes untereinander wie 5010,5020 | ||
+ | * **servicerange** < | ||
+ | * Portrange für RMI basierende Dienste | ||
+ | * **capacity** optional | ||
+ | * Wieviele Replication Prozesse können auf diesen Server kaufen | ||
+ | * **storagedir** optional | ||
+ | * Alternativer Speicherplatz für die Replication Prozesse | ||
+ | * **num_cpus** | ||
+ | * Wie viele CPU's können die Replication nodes verbrauchen | ||
+ | * **memory_mb** | ||
+ | * Wie viel Speicher können die Replication nodes verbrauchen | ||
+ | |||
+ | Konfiguration anlegen: | ||
+ | <code bash> | ||
+ | export KVROOT=/ | ||
+ | |||
+ | java -jar $KVHOME/ | ||
+ | -port 5000 \ | ||
+ | -admin 5001 \ | ||
+ | -host $HOSTNAME | ||
+ | -harange 5010, | ||
+ | -servicerange 5021,5041 \ | ||
+ | -capacity 3 \ | ||
+ | -num_cpus 1 \ | ||
+ | -memory_mb 500 | ||
+ | </ | ||
+ | |||
+ | **Update V3!** | ||
+ | Für die Version 3 ist nun auch der Parameter -store-security anzugeben, soll der Store sich wie in der Version 2 verhalten mit dem Wert " | ||
+ | |||
+ | ==== Oracle NoSQL Database Storage Node Agent (SNA) starten ==== | ||
+ | |||
+ | <code bash> | ||
+ | nohup java -jar $KVHOME/ | ||
+ | </ | ||
+ | |||
+ | Logfile prüfen: | ||
+ | <code bash> | ||
+ | cd $KVROOT | ||
+ | vi snaboot_0.log | ||
+ | </ | ||
+ | |||
+ | Java Prozesse auf der Maschine lassen sich mit jps und jstat [[http:// | ||
+ | |||
+ | <code bash> | ||
+ | / | ||
+ | |||
+ | 2033 kvstore | ||
+ | ... | ||
+ | |||
+ | / | ||
+ | |||
+ | </ | ||
+ | |||
+ | |||
+ | |||
+ | Connect prüfen: | ||
+ | <code bash> | ||
+ | java -jar $KVHOME/ | ||
+ | |||
+ | SNA at hostname: nosqldb01, registry port: 5000 is not registered | ||
+ | No further information is available | ||
+ | </ | ||
+ | |||
+ | Die Meldung zeigt uns, dass zwar ein SNA Prozess auf dem Knoten schon läuft, diese aber noch nicht konfiguriert ist. | ||
+ | |||
+ | Diese Konfiguration auf den beiden anderen Servern anlegen und über den Host Parameter vom obigen ping Kommando testen ob alle SNA Nodes erreichbar sind. | ||
+ | |||
+ | Damit ist die Grundinstallation der Oracle NoSQL Umgebung abgeschlossen. | ||
+ | |||
+ | ===Um SNA wieder zu stoppen === | ||
+ | <code bash> | ||
+ | java -jar $KVHOME/ | ||
+ | </ | ||
+ | |||
+ | |||
+ | === Autostart einrichten === | ||
+ | |||
+ | Autostart über init.d Mechanismus einrichten. | ||
+ | |||
+ | Beispiel: | ||
+ | <code bash nosql> | ||
+ | #!/bin/bash | ||
+ | # | ||
+ | # Run-level Startup script NoSQL | ||
+ | # | ||
+ | # chkconfig: 2345 08 92 | ||
+ | # description: | ||
+ | # | ||
+ | # | ||
+ | ### BEGIN INIT INFO | ||
+ | # Provides: OracleNoSQLKVStore | ||
+ | # Required-Start: | ||
+ | # Required-Stop: | ||
+ | # Default-Start: | ||
+ | # Default-Stop: | ||
+ | # Short-Description: | ||
+ | # Description: | ||
+ | ### END INIT INFO | ||
+ | |||
+ | |||
+ | # Source function library. | ||
+ | . / | ||
+ | |||
+ | ORACLE_USER=oracle | ||
+ | KVHOME=/ | ||
+ | KVROOT=/ | ||
+ | |||
+ | #Start or stop the Oracle NoSQL Node | ||
+ | case " | ||
+ | start) | ||
+ | # Oracle NoSQL start | ||
+ | echo -n " | ||
+ | su - $ORACLE_USER -c "nohup java -jar $KVHOME/ | ||
+ | echo " | ||
+ | ;; | ||
+ | stop) | ||
+ | # Oracle Nosql shutdown | ||
+ | echo -n " | ||
+ | su - $ORACLE_USER -c "java -jar $KVHOME/ | ||
+ | echo " | ||
+ | ;; | ||
+ | status) | ||
+ | # status | ||
+ | echo -n " | ||
+ | jps -m | grep kv | ||
+ | ;; | ||
+ | reload|restart) | ||
+ | $0 stop | ||
+ | $0 start | ||
+ | ;; | ||
+ | *) | ||
+ | echo " | ||
+ | exit 1 | ||
+ | esac | ||
+ | exit 0 | ||
+ | </ | ||
+ | |||
+ | Start Script einrichten: | ||
+ | <code bash> | ||
+ | # datei nach / | ||
+ | |||
+ | # rechte | ||
+ | chmod 777 / | ||
+ | |||
+ | # | ||
+ | chkconfig | ||
+ | |||
+ | # | ||
+ | chkconfig | ||
+ | |||
+ | </ | ||
+ | |||
+ | ==== KV Store einrichten und konfigurieren ==== | ||
+ | |||
+ | Die Administration der Umgebung erfolgt über ein Kommando Zeilen Werkzeug. | ||
+ | |||
+ | Aufruf: | ||
+ | <code bash> | ||
+ | java -jar $KVHOME/ | ||
+ | |||
+ | Kv-> | ||
+ | |||
+ | </ | ||
+ | |||
+ | |||
+ | Ablauf: | ||
+ | * SNA müssen alle gestartet sein ( mit der Installation erfolgt) | ||
+ | * KV Store einen Namen vergeben | ||
+ | * Data Center anlegen | ||
+ | * Admin Prozess auf einen Knoten anlegen | ||
+ | * Storage Node Pool anlegen | ||
+ | * Weitere Storage Knoten hinzufügen | ||
+ | * Erzeugen und Verteilen der Replication Nodes | ||
+ | |||
+ | |||
+ | |||
+ | === KV Store einen Namen vergeben === | ||
+ | |||
+ | Komandozeilen Werkzeug starten und mit dem Befehl „configure -name <NAME DER DATENBANK> | ||
+ | <code bash> | ||
+ | Kv-> configure -name GPIDB | ||
+ | Store configured: GPIDB | ||
+ | </ | ||
+ | |||
+ | === Data Center anlegen === | ||
+ | |||
+ | |||
+ | Ein Store kann nur ein Data Center enthalten und wird mit dem Befehl "plan deploy-datacenter" | ||
+ | Mit -wait wartet die Console auf der Ergebnis des Befehls. | ||
+ | |||
+ | |||
+ | Parameter: | ||
+ | * name | ||
+ | * datacenter name - eindeutiger Name der Systemumgebung | ||
+ | * rf | ||
+ | * replication factor | ||
+ | |||
+ | |||
+ | Ablauf: | ||
+ | <code bash> | ||
+ | kv-> plan deploy-datacenter -name jupiter -rf 3 -wait | ||
+ | Executed plan 1, waiting for completion... | ||
+ | Plan 1 ended successfully | ||
+ | </ | ||
+ | |||
+ | Ergebnis anzeigen lassen: | ||
+ | <code bash> | ||
+ | kv-> show plans | ||
+ | 1 Deploy Datacenter (1) SUCCEEDED | ||
+ | </ | ||
+ | |||
+ | |||
+ | === Admin Prozess auf einen Knoten anlegen === | ||
+ | |||
+ | Jeder KVStore hat eine administrative Datenbank. Auf dem Knoten der die Admin Datenbank halten soll, mit dem Kommandozeilen Werkzeug anmelden und dort mit den Befehlen deploy-sn und deploy-admin die administrative DB anlegen. | ||
+ | |||
+ | Umgebung (topology) anzeigen lassen: | ||
+ | |||
+ | <code bash> | ||
+ | kv-> show topology | ||
+ | store=GPIDB numPartitions=0 sequence=1 | ||
+ | dc=[dc1] name=jupiter repFactor=3 | ||
+ | </ | ||
+ | |||
+ | Für den deploy-sn Befehl benötigen wir die obigen Ausgaben, wir fügen im ersten Schritt den Node hinzu: | ||
+ | <code bash> | ||
+ | kv-> plan deploy-sn -dc dc1 -host nosqldb01 -port 5000 -wait | ||
+ | Executed plan 2, waiting for completion... | ||
+ | Plan 2 ended successfully | ||
+ | |||
+ | kv->show topology | ||
+ | |||
+ | # => zeigt nun den ersten Node mit an | ||
+ | |||
+ | </ | ||
+ | |||
+ | Nach dem Hinzufügen des ersten Knoten können wir hier den administrativen Prozess konfigurieren. | ||
+ | |||
+ | |||
+ | <code bash> | ||
+ | kv-> plan deploy-admin -sn sn1 -port 5001 -wait | ||
+ | Executed plan 3, waiting for completion... | ||
+ | Plan 3 ended successfully | ||
+ | </ | ||
+ | |||
+ | |||
+ | Für das Einrichten der Umgebung bzw. für unsere drei Knoten Test Umgebung ist das nun ausreichend, | ||
+ | |||
+ | |||
+ | === Storage Node Pool anlegen === | ||
+ | |||
+ | Der Storage Node Pool enthält unser 3 Hosts als Storage Knoten. | ||
+ | Mit "pool create" | ||
+ | |||
+ | <code bash> | ||
+ | |||
+ | kv-> pool create -name JupiterPool | ||
+ | |||
+ | kv-> show topology | ||
+ | dc=[dc1] name=Jupiter | ||
+ | | ||
+ | |||
+ | |||
+ | kv-> pool join -name JupiterPool -sn sn1 | ||
+ | Added Storage Node sn1 to pool JupiterPool | ||
+ | |||
+ | </ | ||
+ | |||
+ | ===Weitere Storage Knoten hinzufügen=== | ||
+ | |||
+ | Nun können die beiden anderen Knoten dem System hinzugefügt werden. | ||
+ | Hinzufügen eines Hosts mit "plan deploy-sn", | ||
+ | |||
+ | |||
+ | <code bash> | ||
+ | kv-> plan deploy-sn -dc dc1 -host nosqldb02 -port 5000 -wait | ||
+ | Executed plan 4, waiting for completion... | ||
+ | Plan 4 ended successfully | ||
+ | |||
+ | kv-> pool join -name JupiterPool-sn sn2 | ||
+ | Added Storage Node sn2 to pool JupiterPool | ||
+ | |||
+ | |||
+ | kv-> | ||
+ | Executed plan 5, waiting for completion... | ||
+ | Plan 5 ended successfully | ||
+ | |||
+ | kv-> pool join -name JupiterPool-sn sn3 | ||
+ | Added Storage Node sn3 to pool JupiterPool | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Erzeugen und Verteilen der Replication Nodes === | ||
+ | |||
+ | Im letzten Schritt werden die Replication Nodes für die " | ||
+ | Dazu wird der Befehl " | ||
+ | |||
+ | Parameter: | ||
+ | * topology name - Name für die Topologie | ||
+ | * pool name - Name des Pools | ||
+ | * number of partitions | ||
+ | |||
+ | |||
+ | Ein wichtiger Wert ist hier die Anzahl der Partitionen. | ||
+ | Faustformel: | ||
+ | Genauer siehe [[http:// | ||
+ | |||
+ | <code bash> | ||
+ | kv-> topology create -name GPItopo -pool JupiterPool-partitions 300 | ||
+ | Created: GPItopo | ||
+ | |||
+ | kv-> plan deploy-topology -name GPItopo -wait | ||
+ | Executed plan 6, waiting for completion... | ||
+ | Plan 6 ended successfully | ||
+ | |||
+ | </ | ||
+ | |||
+ | |||
+ | Mit dem Kommando "show plans" prüfen ob alles geklappt hat. | ||
+ | |||
+ | === Skripten === | ||
+ | |||
+ | Die Befehle lassen sich auch in einem Script bündeln und gemeinsam ausführen, in der Kommandoshell mit dem Befehl "load -file <path to file>" | ||
+ | |||
+ | Siehe auch: | ||
+ | |||
+ | === Test der Umgebung === | ||
+ | |||
+ | Ping auf die Storage Knoten: | ||
+ | |||
+ | <code bash> | ||
+ | java -jar $KVHOME/ | ||
+ | </ | ||
+ | |||
+ | |||
+ | Umgebung mit verify überprüfen: | ||
+ | |||
+ | <code bash> | ||
+ | |||
+ | java -jar KVHOME/ | ||
+ | kv-> verify | ||
+ | |||
+ | </ | ||
+ | |||
+ | == Im Browser Status prüfen == | ||
+ | |||
+ | Aufruf der Admin Console im Browser über den Server Namen und den Admin Port 5001 | ||
+ | |||
+ | Aufruf über den Browser: | ||
+ | {{: | ||
+ | |||
+ | Leider nicht Passwort geschützt! | ||
+ | |||
+ | |||
+ | === Löschen einer Umgebung === | ||
+ | |||
+ | Um eine Umgebung zurückzusetzen muss auf jeden Knoten alles gestoppt und der KVROOT gelöscht werden. | ||
+ | |||
+ | <code bash> | ||
+ | java -jar $KVHOME/ | ||
+ | |||
+ | rm -r $KVROOT | ||
+ | </ | ||
+ | ==== Quellen ==== | ||
+ | |||
+ | * http:// | ||
+ | * http:// |
nosql/install_oracle_nosql_db_11gr2.txt · Zuletzt geändert: 2014/06/06 14:58 von gpipperr