nosql:netzkonfiguration_fw_oracle_nosql_db_11gr2
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende Überarbeitung | ||
nosql:netzkonfiguration_fw_oracle_nosql_db_11gr2 [2014/06/21 19:29] – gpipperr | nosql: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: | ||
+ | |||
+ | |||
+ | 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: | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | |||
+ | |||
+ | **Achtung: | ||
+ | |||
+ | <note tip>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 | ||
+ | * Http Admin Übersicht | ||
+ | * 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/ | ||
+ | passenden Connect Port, wie zum Beispiel die 5000, zugreifen können! | ||
+ | |||
+ | |||
+ | == Bug in Versionen vor 2.0 == | ||
+ | Parameter " | ||
+ | |||
+ | ==== Nachträgliches Anpassen des Admin Ranges==== | ||
+ | Mit Hilfe von "plan change-parameters -service < | ||
+ | |||
+ | 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/ | ||
+ | |||
+ | |||
+ | # Plan für die Änderung erstellen | ||
+ | kv-> plan change-parameters -wait -service 1 -params servicePortRange=" | ||
+ | kv-> plan change-parameters -wait -service 2 -params servicePortRange=" | ||
+ | kv-> plan change-parameters -wait -service 3 -params servicePortRange=" | ||
+ | |||
+ | |||
+ | # Testen mit für jeden Knoten | ||
+ | kv->show parameter -service 1 | ||
+ | |||
+ | |||
+ | # Check the change in the configuration xml on each node | ||
+ | |||
+ | cat $KVROOT/ | ||
+ | |||
+ | # Alle SN's neu starten | ||
+ | |||
+ | </ | ||
+ | |||
+ | ==== Test: | ||
+ | |||
+ | <code bash> | ||
+ | # Port Verwendung: | ||
+ | netstat -ntap | grep java | ||
+ | </ | ||
+ | |||
+ | Test mit tcpdump auf Fehler: | ||
+ | <code bash> | ||
+ | |||
+ | # alle Packete zum noSQL Server abfangen: | ||
+ | |||
+ | tcpdump -nnvvSX | ||
+ | |||
+ | </ | ||
+ | |||
+ | IP Tables einstellen: | ||
+ | <code bash> | ||
+ | # einschalten | ||
+ | chkconfig --level 0123456 iptables on | ||
+ | chkconfig --list iptables | ||
+ | |||
+ | # | ||
+ | #Logging einrichten | ||
+ | vi / | ||
+ | |||
+ | *filter | ||
+ | :INPUT ACCEPT [0:0] | ||
+ | :FORWARD ACCEPT [0:0] | ||
+ | :OUTPUT ACCEPT [0:0] | ||
+ | -A INPUT -m state --state ESTABLISHED, | ||
+ | -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 " | ||
+ | -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 / | ||
+ | |||
+ | # Store stoppen und neu starten | ||
+ | # Log einträge prüfen | ||
+ | |||
+ | </ | ||
+ | |||
+ | |||
+ | FW Log bei Bearf auch wieder ausschalten! | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | === Quellen === | ||
+ | |||
+ | Beim Anlegen : http:// | ||
+ | \\ | ||
+ | Ändern: http:// | ||
nosql/netzkonfiguration_fw_oracle_nosql_db_11gr2.txt · Zuletzt geändert: 2014/06/21 19:58 von gpipperr