Długo trwa commit

[mardi4]

Witam.

Mam mały (chyba) problem. Od pewnego czasu commit konfiguracji na klastrze SRX 1400 trwa strasznie dużo czasu (minuta) commit check tak samo. Wcześniej to commit trwał pare sekund. Czym to może być spowodowane? Obciążenie procka jest malutkie.

Dzięki z góry za pomoc.

[House]

Na długość commita w klastrze może mieć wpływ konfiguracji tacacs (polecenia z serwera), użycie nazw domenowych zamiast adresów IP w konfiguracji klastra.
jak możesz wklej wynik działania commit | display detail. Zobaczymy co zajmuje tyle czasu.
Ile masz interfaceów na firewallu (fizyczne i unit), jak masz klaster to pewnie wykorzystujesz interface reth, ile ich jest?

[michaliwanczuk]

przy klastrze 1400 comit trwa długo sprawdzałem:-)

[mardi4]

Wynik:

Kod: Zaznacz cały

user@SRX1# commit check | display detail
node0:
2014-06-25 07:24:45 CEST: merging latest committed configuration
2014-06-25 07:24:46 CEST: reading commit script configuration
2014-06-25 07:24:47 CEST: testing commit script configuration
2014-06-25 07:24:47 CEST: opening commit script '/var/db/scripts/commit/templates.xsl'
2014-06-25 07:24:47 CEST: reading commit script 'templates.xsl'
2014-06-25 07:24:47 CEST: running commit script 'templates.xsl'
2014-06-25 07:24:57 CEST: processing commit script 'templates.xsl'
2014-06-25 07:24:57 CEST: no errors from templates.xsl
2014-06-25 07:24:57 CEST: saving commit script changes for script templates.xsl
2014-06-25 07:24:57 CEST: summary of script templates.xsl: changes 8, transients 0, syslog 0
2014-06-25 07:24:57 CEST: start loading commit script changes
2014-06-25 07:24:57 CEST: loading commit script changes into real db
2014-06-25 07:24:58 CEST: finished commit script changes into real db
2014-06-25 07:24:59 CEST: no transient commit script changes
2014-06-25 07:24:59 CEST: finished loading commit script changes
2014-06-25 07:24:59 CEST: copying juniper.db to juniper.data+
2014-06-25 07:24:59 CEST: finished copying juniper.db to juniper.data+
2014-06-25 07:24:59 CEST: exporting juniper.conf
2014-06-25 07:24:59 CEST: Exporting /config/juniper.conf.spu
2014-06-25 07:24:59 CEST: expanding interface-ranges
2014-06-25 07:24:59 CEST: finished expanding interface-ranges
2014-06-25 07:24:59 CEST: expanding groups
2014-06-25 07:24:59 CEST: finished expanding groups
2014-06-25 07:24:59 CEST: setup foreign files
2014-06-25 07:24:59 CEST: update license counters
2014-06-25 07:24:59 CEST: finish license counters
2014-06-25 07:24:59 CEST: propagating foreign files
2014-06-25 07:24:59 CEST: complete foreign files
2014-06-25 07:24:59 CEST: executing 'ffp propagate'
2014-06-25 07:24:59 CEST: daemons checking new configuration
2014-06-25 07:24:59 CEST: IDP policy daemon checking new configuration
2014-06-25 07:25:25 CEST: Network security daemon checking new configuration
2014-06-25 07:25:26 CEST: obtaining db lock on node1
configuration check succeeds
2014-06-25 07:25:26 CEST: sending pull-configuration rpc to node1
2014-06-25 07:25:26 CEST: filename /config/juniper.conf+.gz, size 13242
2014-06-25 07:25:26 CEST: pull-configuration success. URL: /var/tmp/juniper.conf+.gz
2014-06-25 07:25:26 CEST: sending load-update rpc to node1
2014-06-25 07:25:27 CEST: remote load-configuration success on node1
2014-06-25 07:25:27 CEST: sending file-delete rpc to node1
2014-06-25 07:25:27 CEST: asking node1 to commit
2014-06-25 07:25:27 CEST: waiting for commit reply from node1
node1:
2014-06-25 07:25:24 CEST: reading commit script configuration
2014-06-25 07:25:24 CEST: testing commit script configuration
2014-06-25 07:25:24 CEST: opening commit script '/var/db/scripts/commit/templates.xsl'
2014-06-25 07:25:24 CEST: reading commit script 'templates.xsl'
2014-06-25 07:25:24 CEST: running commit script 'templates.xsl'
2014-06-25 07:25:34 CEST: processing commit script 'templates.xsl'
2014-06-25 07:25:34 CEST: no errors from templates.xsl
2014-06-25 07:25:34 CEST: saving commit script changes for script templates.xsl
2014-06-25 07:25:34 CEST: summary of script templates.xsl: changes 8, transients 0, syslog 0
2014-06-25 07:25:34 CEST: start loading commit script changes
2014-06-25 07:25:34 CEST: loading commit script changes into real db
2014-06-25 07:25:36 CEST: finished commit script changes into real db
2014-06-25 07:25:36 CEST: no transient commit script changes
2014-06-25 07:25:36 CEST: finished loading commit script changes
2014-06-25 07:25:36 CEST: copying juniper.db to juniper.data+
2014-06-25 07:25:36 CEST: finished copying juniper.db to juniper.data+
2014-06-25 07:25:36 CEST: exporting juniper.conf
2014-06-25 07:25:36 CEST: Exporting /config/juniper.conf.spu
2014-06-25 07:25:36 CEST: expanding interface-ranges
2014-06-25 07:25:36 CEST: finished expanding interface-ranges
2014-06-25 07:25:36 CEST: expanding groups
2014-06-25 07:25:36 CEST: finished expanding groups
2014-06-25 07:25:36 CEST: setup foreign files
2014-06-25 07:25:36 CEST: update license counters
2014-06-25 07:25:36 CEST: finish license counters
2014-06-25 07:25:36 CEST: propagating foreign files
2014-06-25 07:25:36 CEST: complete foreign files
2014-06-25 07:25:36 CEST: executing 'ffp propagate'
2014-06-25 07:25:36 CEST: daemons checking new configuration
2014-06-25 07:25:36 CEST: IDP policy daemon checking new configuration
2014-06-25 07:26:02 CEST: Network security daemon checking new configuration
configuration check succeeds

Nie używam nazw domenowych, ani konfiguracji serwera tacacs.
Klaster mam już prawie od połowy roku, zawsze działało to zdecydowanie szybciej, aż zwolniło jakoś ostatnimi czasy. Mam 3 int reth

[Szutor]

Stosowałeś ostatnio jakieś "configuration groups with wildcard" (sorry nie potrafię tego przetłumaczyć) ? To ma dosyć duży wpływ na czas commit'a...

Ps. U Nas na 3600 commit trwa 1,5 minuty i nikt nie płacze

[mardi4]

Niestosowałem. Ja nie płaczę tylko tak jakoś z dnia na dzień wydłużył się commit

[lxs]

Czas commitowania na SRX bierze się z priorytetów dostępów procesów do CPU. Na JunOS najwyższe priorytety ma dataplane. Zmiana konfiguracji to czysty control plane i prawdopodobnie ma to najniższy priorytet. Czas dla klastra jest większy, bo proces musi dostać się do dwóch procesorów. Jeżeli na NPU jest duże obciążenie, to czas commitowania będzie znacznie większy. Na 99% Twój SRX jest bardziej obciążony i możliwe, że masz "cięższą" konfiguracje (redundant grupy, routing polityki, virtualne routery...) albo większy throughput.
Kiedyś nawet zgłaszaliśmy case do JTACa i niczego nam nie znaleźli. Natomiast nasze pudła (średnio 10Gpbs SRX 3400 ) to commit zajmuje 1 minutę.