Benutzer-Werkzeuge

Webseiten-Werkzeuge


nosql:netzkonfiguration_fw_oracle_nosql_db_11gr2

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
nosql:netzkonfiguration_fw_oracle_nosql_db_11gr2 [2014/06/21 19:29] gpipperrnosql:netzkonfiguration_fw_oracle_nosql_db_11gr2 [2014/06/21 19:58] (aktuell) gpipperr
Zeile 1: Zeile 1:
 +====== Oracle NoSQL Netzwerk Konfiguration ======
 +
 +Ein wichtiger Punkt für die Performance einer Oracle NoSQL Umgebung ist das Netzwerk. Wird auf höchste Performance Wert gelegt, lohnt sich durchaus der Einsatz von InfiniBand für die Kommunikation der Knoten untereinander. Jeder Datensatz muss schnellstmöglich auf die Replikate übertragen werden um das Zeitfenster der „Eventual Consistency“ möglichst klein zu halten. 
 +
 +Eine exakte gleiche Systemzeit aller Knoten des Store ist sehr wichtig, der NTP Service auf jeden Knoten ist mit größter Sorgfalt einzurichten um Ausfälle im Store zu vermeiden, bzgl. Ntp siehe dazu auch [[linux:linux_rac_ntp|Die Uhrzeit im Oracle Cluster überwachen/prüfen und kontrollieren]]
 +
 +
 +Die Oracle NoSQL DB benötigt für die Kommunikation der Storage Nodes untereinander und mit Client eine recht hohe Anzahl von Ports. Soll vor der NoSQL DB Umgebung ein FW für erweiterte Sicherheit sorgen, ist darauf zu achten eine Portrange auch für die Client Kommunikation zu reservieren (Parameter servicePortRange beim Anlegen des Stores) damit auch die für die RMI Kommunikation notwendigen Ports zwischen Client und DB Knoten in der FW freigeschaltet werden können. Ist mehr als ein Store in Verwendung, empfiehlt es sich diese Portranges zu standardisiert um die Wartung und den Betrieb erheblich zu erleichtern.
 +
 +
 +Übersicht mit Beispiel Port Nummer:
 +
 +{{ :nosql:oracle_nosql_ports_v01.png?500 | Übersicht über die Ports für eine Oracle NoSQL Umgebung}}
 +
 +
 +
 +**Achtung:**
 +
 +<note tip>Wenn der Paramter **servicePortRange** NICHT gesetzt wird, ist die RMI Kommunikation über eine Firewall NICHT möglich!</note>
 +
 +
 +
 +
 +Die notwendigen Port Ranges:
 +
 +  * Connect von außen              - ein Port wie 5000
 +  * Http Admin Übersicht           - ein Port wie 5001
 +  * Replikation zwischen den Nodes - Minimum: ein Port pro Replication Node
 +  * Admin Range                    - Minimum: zwei Ports pro SN + 3 Ports pro Replication Node + ein Port für den Registry Service
 +
 +
 +Der Client/Applikation Server, der mit dem Store arbeiten soll, muss auf JEDEN Knoten des Stores über den 
 +passenden Connect Port, wie zum Beispiel die 5000, zugreifen können!
 +
 +
 +== Bug in Versionen vor 2.0 ==
 +Parameter "servicerange" konnte angegeben werden, wird aber nicht richtig unterstütz bzw. ignoriert.
 +
 +==== Nachträgliches Anpassen des Admin Ranges==== 
 +Mit Hilfe von "plan change-parameters -service <storage-node-id> -params servicePortRange="5021,5040"" können auf den Storage Nodes der Parameter servicePortRange angepasst werden.
 +
 +Ablauf:
 +  * Id's der Storage node mit Ping oder show topology ermitteln
 +  * Für alle Id's den Wert anpassen
 +  * Store komplett neu starten
 +
 +<code bash>
 +# Admin Console starten
 +java -jar $KVHOME/lib/kvstore.jar runadmin -port 5000 -host $HOSTNAME
 +
 +
 +# Plan für die Änderung erstellen
 +kv-> plan change-parameters -wait -service 1 -params servicePortRange="5021,5040" 
 +kv-> plan change-parameters -wait -service 2 -params servicePortRange="5021,5040"
 +kv-> plan change-parameters -wait -service 3 -params servicePortRange="5021,5040"
 +
 +
 +# Testen mit für jeden Knoten
 +kv->show parameter -service 1
 +
 +
 +# Check the change in the configuration xml on each node
 +
 +cat $KVROOT/config.xml | grep servicePortRange
 +
 +# Alle SN's neu starten
 +
 +</code>
 +
 +==== Test:==== 
 +
 +<code bash>
 +# Port Verwendung:
 +netstat -ntap | grep java
 +</code>
 +
 +Test mit tcpdump auf Fehler:
 +<code bash>
 +
 +# alle Packete zum noSQL Server abfangen:
 +
 +tcpdump -nnvvSX  host 192.168.10.10
 +
 +</code>
 +
 +IP Tables einstellen:
 +<code bash>
 +# einschalten
 +chkconfig --level 0123456 iptables on
 +chkconfig --list iptables
 +
 +#Konfigurieren anpassen 
 +#Logging einrichten
 +vi /etc/sysconfig/iptables
 +
 +*filter
 +:INPUT ACCEPT [0:0]
 +:FORWARD ACCEPT [0:0]
 +:OUTPUT ACCEPT [0:0]
 +-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
 +-A INPUT -p icmp -j ACCEPT
 +-A INPUT -i lo -j ACCEPT
 +-A INPUT -p tcp --dport 22 -j ACCEPT
 +
 +# nosql rule set
 +-A INPUT -p tcp --dport 5000 -j ACCEPT
 +-A INPUT -p tcp --dport 5001 -j ACCEPT
 +-A INPUT -p tcp --dport 5010:5020 -j ACCEPT
 +-A INPUT -p tcp --dport 5021:5040 -j ACCEPT
 +
 +# UDP not in use
 +#-A INPUT -p udp --dport 5000 -j ACCEPT
 +#-A INPUT -p udp --dport 5001 -j ACCEPT
 +#-A INPUT -p udp --dport 5010:5020 -j ACCEPT
 +#-A INPUT -p udp --dport 5021:5040 -j ACCEPT
 +
 +
 +#Logging for debuging nosql ports
 +-N LOGGING
 +-A INPUT -j LOGGING
 +-A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables Drop:: " --log-level 4
 +-A LOGGING -j DROP
 +-A INPUT -j REJECT --reject-with icmp-host-prohibited
 +-A FORWARD -j REJECT --reject-with icmp-host-prohibited
 +COMMIT
 +
 +# Starten 
 +service iptables start
 +
 +# prüfen
 +iptables -L -n
 +
 +# per Tail Logfile überwachen ob alles wie gewünscht funktioniert
 +tail -f /var/log/messages
 +
 +# Store stoppen und neu starten 
 +# Log einträge prüfen
 +
 +</code>
 +
 +
 +FW Log bei Bearf auch wieder ausschalten!
 +
 +
 +
 +
 +=== Quellen ===
 +
 +Beim Anlegen : http://docs.oracle.com/cd/NOSQL/html/AdminGuide/install-config.html
 +\\
 +Ändern: http://docs.oracle.com/cd/NOSQL/html/AdminGuide/setstoreparams.html#adminparameters
  
nosql/netzkonfiguration_fw_oracle_nosql_db_11gr2.txt · Zuletzt geändert: 2014/06/21 19:58 von gpipperr