Benutzer-Werkzeuge

Webseiten-Werkzeuge


nosql:netzkonfiguration_fw_oracle_nosql_db_11gr2

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 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:

 Übersicht über die Ports für eine Oracle NoSQL Umgebung

Achtung:

Wenn der Paramter servicePortRange NICHT gesetzt wird, ist die RMI Kommunikation über eine Firewall NICHT möglich!

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
# 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

Test:

# Port Verwendung:
netstat -ntap | grep java

Test mit tcpdump auf Fehler:

# alle Packete zum noSQL Server abfangen:
 
tcpdump -nnvvSX  host 192.168.10.10

IP Tables einstellen:

# 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

FW Log bei Bearf auch wieder ausschalten!

Quellen

Diese Website verwendet Cookies. Durch die Nutzung der Website stimmen Sie dem Speichern von Cookies auf Ihrem Computer zu. Außerdem bestätigen Sie, dass Sie unsere Datenschutzbestimmungen gelesen und verstanden haben. Wenn Sie nicht einverstanden sind, verlassen Sie die Website.Weitere Information
nosql/netzkonfiguration_fw_oracle_nosql_db_11gr2.txt · Zuletzt geändert: 2014/06/21 19:58 von gpipperr

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki