PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Squid-Probleme => Serverabsturz



Sorehead
10.03.06, 09:22
Hallo!
Ich habe ein größeres Problem. Es ist etwas schwierig das zu beschreiben, aber ich versuche es mal.
Wir haben einen Proxy-Server auf dem drei Squidprozesse laufen. Jeder hat andere Restriktionen, wer was im Netz machen darf. Vor allem ist bei zweien KEIN Download möglich. Über diese beiden Squids laufen ca. 2600 User.
Soweit zur Ausgangssituation. In unregelmäßigen Abständen stürzt allerdings der ganze Server ab; und zwar richtig, so das snur ein Reset hilft.
Wenn ich mir das Log der Squids angucke, sehe ich, dass auf den Squids, die keine Downloadberechtigung haben, die Adobe-Update-Seute angefragt wird und ein "TCP_DENIED" zurückbekommt. Von diesen Anfragen haben sich bei einem Absturz so ca. 40.000-60.000 angesammelt.
Nun meine Frage: Kann dieses Adobeupdate der Grund für den Absturz sein? Am TCP_DENIED kann es eigentlich nciht liegen, weil in dem Log noch ca 100.000 andere TCP_DENIED von aderen Seiten kommen. Es ist halt nur auffällig, das Adobe fast immer der letzt Eintrag ist.
Das komplette Aufhängen könnte am Bufferüberlauf der Netzkarte liegen. Kann man das überprüfen? Wer weiß einen Rat?

Gruß, Sascha

bla!zilla
10.03.06, 09:26
Versucht doch mal einen Packetsniffer zwischen den Squid und das Gateway zu hängen um mal den Verkehr zu analysieren. Habt die von euch verwendete Kernelversion mal auf Bugs hin überprüft, spricht das defekte Pakete zum Absturz führen?

Sorehead
10.03.06, 09:35
Also das ist Suse Enterprise 8, Kernelversion 2.4.19-4GB

Mit dem Packetsniffer ist das son Problem. Ich habe leider nicht die Rechte woanders was zu machen. Ich habe auf dem Proxy zwar root-Rechte, aber das war es auch schon. Und bei dem Traffic auf der Kiste wird das Log des Sniffers doch recht umfangreich denke ich.
Oder gibts es spezielle Parameter, die ich da nutzen sollte?

bla!zilla
10.03.06, 09:39
Du kannst ja z.B. bei Ethereal filtern, dir z.B. nur Traffic von dem einen Host anzeigen lassen. Was für eine Anbindung hängt denn hinter dem Proxy? Du solltest natürlich schon einen ordentlichen Rechner mit entsprechend viel Plattenplatz als Sniffer verwenden.

Wenn du (aus welchem Grund auch immer) direk am Core sniffen musst, dann brauchst du Spezialhardware. Alles andere ist kaum in der Lage mehrere Gigabit pro Sekunde in Echtzeit aufzuzeichnen.

Alternativ kannst du versuchen einen Squid-Prozess auf eine andere Maschine auszulagern und dort zu testen.

Sorehead
10.03.06, 09:49
Hehe... Also das mit der Anbindung ist hier eine lustige Sache..

Ich beschreibe mal das Umfeld: Ich arbeite im Rechenzentrum Nord der Deutschen Rentenversicherung als Anwendungsentwickler. Den Proxy haben wir mal als Test aufgesetzt und "irgendwie" ist der dann produktiv geworden. Das bedeutet also: Ich arbeitete quasi im öffentlichen Dienst und da ist einiges anders. Der Proxy ist speziell für den Standort Hannover-Braunschweig. Alle anderen DRVen gehen direkt über Wützburg ins Netz. Da gibts ne dicke Standleitung. Nur Hannover-Braunsschweig brät sich ne extrawurst und nimmt nen eigenen Proxy. Die User hier authentifizieren sich an unserem Proxy und der sich in Würzburg.
Der Proxy ist dabei kein richtiger Server sondern ein normaler Desktoprechner mit P4 2,6Ghz und 1GB RAM. Ich weiß, dass das schei*** ist, aber hier läuft das alles etwas anders.
Auf jeden Fall ist die Platte begrenzt und an andere Geräteinstanzen komme ich nicht ran.
Ich muss also auf dem Rechner selbst was machen können. Kann man den zum Bespiel den Netzbuffer loggen? Für alle anderen Sachen muss man nunmal erst Anträge stellen usw.

bla!zilla
10.03.06, 10:04
Hehe... Also das mit der Anbindung ist hier eine lustige Sache..

Okay, schaun´ mer mal.



Ich beschreibe mal das Umfeld: Ich arbeite im Rechenzentrum Nord der Deutschen Rentenversicherung als Anwendungsentwickler. Den Proxy haben wir mal als Test aufgesetzt und "irgendwie" ist der dann produktiv geworden.

Quasi eine produktive Testumgebung. Sehr lustig sowas - kenne ich selber. :)



Das bedeutet also: Ich arbeitete quasi im öffentlichen Dienst und da ist einiges anders. Der Proxy ist speziell für den Standort Hannover-Braunschweig. Alle anderen DRVen gehen direkt über Wützburg ins Netz. Da gibts ne dicke Standleitung. Nur Hannover-Braunsschweig brät sich ne extrawurst und nimmt nen eigenen Proxy. Die User hier authentifizieren sich an unserem Proxy und der sich in Würzburg.


Die Proxies sind also kaskadiert?



Der Proxy ist dabei kein richtiger Server sondern ein normaler Desktoprechner mit P4 2,6Ghz und 1GB RAM. Ich weiß, dass das schei*** ist, aber hier läuft das alles etwas anders.

Wieviele User? Wieviel Plattenplatz? Was für Platten (RAID?) für den Proxy-Cache?



Auf jeden Fall ist die Platte begrenzt und an andere Geräteinstanzen komme ich nicht ran.
Ich muss also auf dem Rechner selbst was machen können. Kann man den zum Bespiel den Netzbuffer loggen? Für alle anderen Sachen muss man nunmal erst Anträge stellen usw.

Okay... kannst du mal die squid.conf posten (ruhig anonymisiert, also ohne IPs usw.). Steht denn irgendwas in /var/log/messages oder auf der Konsole wenn die Maschine crashed?

Sorehead
10.03.06, 10:57
Jup, in Hannover sin ddie Proxies kaskadiert.

Der Proxy hier in Hanover (der Desktoprechner) verwaltet ca. 700 LDAP einträge und muss den Traffic für ca. 2600 - 3000 User regeln.
Platte hat 40GB, es sind aber nur noch 20GB frei. Es ist auch nur eine Platte, also kein Raid, kein gar nix.

Die Cfgs:
Squid 1 und Squid 3 haben keine Downloadberechtigung

Squid1:


http_port X.X.X.X:8080


cache_peer X.X.X.X parent 9991 0 no-query login=XXX:XXX


hierarchy_stoplist cgi-bin

acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY


cache_dir ufs /var/cache/squid8080 100 16 256

cache_access_log /var/log/squid8080/access.log

cache_log /var/log/squid8080/cache.log

cache_store_log /var/log/squid8080/store.log


pid_filename /var/run/squid8080.pid

debug_options ALL,1

ftp_user XXX@rzn.vdr.de


authenticate_program /usr/sbin/squid_ldap_auth -b ou=default,dc=rzn,dc=vdr,dc=de -u uid X.X.X.X


acl LDAP_AUTH proxy_auth REQUIRED
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localnet src X.X.X.X/255.255.0.0
acl localip myip X.X.X.X/255.255.255.255
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
acl CONNECT method CONNECT

http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow LDAP_AUTH

http_access allow localhost
http_access allow localnet
http_access allow localip
http_access deny all

icp_access allow all

proxy_auth_realm RZN Default Squid Cache

logfile_rotate 10

always_direct allow localhost

acl internet src 0.0.0.0/0.0.0.0
never_direct allow internet

error_directory /usr/share/squid/lvaerrors


httpd_accel_host localhost
httpd_accel_port 8090
httpd_accel_with_proxy on

Squid2:


http_port X.X.X.X:8081

cache_peer X.X.X.X parent 9994 0 no-query login=XXX:XXX

hierarchy_stoplist cgi-bin

acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY

cache_dir ufs /var/cache/squid8081 100 16 256

cache_access_log /var/log/squid8081/access.log

cache_log /var/log/squid8081/cache.log

cache_store_log /var/log/squid8081/store.log

pid_filename /var/run/squid8081.pid

debug_options ALL,1


ftp_user XXX@rzn.vdr.de

authenticate_program /usr/sbin/squid_ldap_auth -b ou=down,dc=rzn,dc=vdr,dc=de -u uid X.X.X.X


acl LDAP_AUTH proxy_auth REQUIRED
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localnet src X.X.X.X/255.255.0.0
acl localip myip X.X.X.X/255.255.255.255
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
acl CONNECT method CONNECT

http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow LDAP_AUTH

http_access allow localhost
http_access allow localnet
http_access allow localip
http_access deny all

icp_access allow all



proxy_auth_realm RZN Download Squid Cache


logfile_rotate 10

always_direct allow localhost

acl internet src 0.0.0.0/0.0.0.0
never_direct allow internet

error_directory /usr/share/squid/lvaerrors

httpd_accel_host localhost
httpd_accel_port 8091
httpd_accel_with_proxy on



Squid3:


http_port X.X.X.X:8084

cache_peer X.X.X.X parent 9991 0 no-query login=XXX:XXX

acl QUERY urlpath_regex cgi-bin \?

no_cache deny QUERY

cache_dir ufs /var/cache/squid8084 100 16 256

cache_access_log /var/log/squid8084/access.log

cache_log /var/log/squid8084/cache.log

cache_store_log /var/log/squid8084/store.log


pid_filename /var/run/squid8084.pid

debug_options ALL,1


ftp_user XXX@rzn.vdr.de


acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl rznnetz src X.X.X.X/255.255.0.0
acl vdr src X.X.X.X/255.0.0.0
acl braunschweig src X.X.X.X/255.0.0.0

acl SSL_ports port 443 563
acl CONNECT method CONNECT

acl whitelist url_regex "/var/squid/allow_url.txt"


http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow whitelist
http_access allow localhost

http_access deny all

icp_access allow all



proxy_auth_realm RZN Whitelist Squid Cache


httpd_accel_single_host on


httpd_accel_uses_host_header on

logfile_rotate 10

always_direct allow localhost

never_direct allow all




error_directory /usr/share/squid/lvaerrors


httpd_accel_host localhost
httpd_accel_port 8094
httpd_accel_with_proxy on

Sorehead
10.03.06, 11:30
Achso, nur zur Info. Das System läuft seid ca 2 jahren.. Der Fehler kommt erst seid ca. 3/4 jahr..

bla!zilla
10.03.06, 19:40
Welche der beiden von dir geposteten Konfigs dürfen nix downloaden und mit welcher ACL regulierst du das? Ich sehe das einer eine Whitelist von URLs abfragt, aber mehr auch nicht - oder ich habe gerade Tomaten auf den Augen. ;)

Was sind denn die letzten Logeinträge vor einem Absturz? Stehen evtl. Meldungen auf der Console?

Sorehead
14.03.06, 09:12
Also, die beiden erwähnten Configs waren die erste und die letzte. Wobei dabei die Besonderheit, dass die Downloadbeschränkung in Würzburger Proxy eingerichtet ist. Wir haben hier zwei Ports, die wir ansteuern: Einmal den zum Downloaden (Config2) und einen Port, der nicht downloaden darf (Config 1 und Config3). Bei Config3 wird zusätzlich unsere Whitelist abgefragt.

Logeinträge vor dem Absturz gibt es nicht. Das Log beschränkt sich lediglich auf LDAP-Abfragen, mehr nicht.

bla!zilla
14.03.06, 09:46
Hi,

es muss doch irgendwelche Auffälligkeiten geben. Du könntest natürlich mal versuchen deine Konfig komplett runterzustrippen, also im Prinzip die Daten 1 zu 1 an den Würzburger Proxy weiterzuleiten. Alternativ mal die Squid Version aktualisieren. Richte doch mal ein Monitoring für den Server ein. Du setzt einen zweiten Server mit Nagios auf und überwachst die CPU Last, Speicherauslastung, den Squid Proxy selber und evtl. die Bandbreite der NIC. Bei einem Absturz wirst du sofort alarmiert und kannst prüfen wie sich die Last auf der Maschine zum Zeitpunkt des Absturzes verhalten hat.

Sorehead
14.03.06, 09:56
Den Gedanken habe ich ja auch schon gehabt.
Ich lasse alle 10min nen Cronjob laufen, der mir CPU-Last, Speicherauslastung, Prozessauslastung und Netzwerkkartenparameter in eine Logdatei schreibt.
Da is nicht wirklich aussergewöhnliches.
Ein Kollege war der Meinung, dass der Fehler von einem Bufferüberlauf der Netzkarte kommt. Ist das möglich? Wie kann ich das monitoren?
Diese Nagios ist vermutlich nicht konstenlos, oder? Wenn ich hier anfange nach Lizenzen zu betteln, wird das nie was..

bla!zilla
14.03.06, 10:50
Ist die Vermutung deines Kollegen fundiert oder ein Schuss ins blaue? AFAIK müsste es aber dahingehend Meldungen unter /var/log/messages vom Kernel her geben, da das Kernelmodul sowas abfangen müsste.

Sorehead
14.03.06, 10:55
Keine Ahnung.. Ich denke das war nur Vermutung. Im Kernel ist aber nix. Ich meine lesen kann ich auch...*g*

Gibts es einen Parameter für den Loglevel des Kernels?

bla!zilla
15.03.06, 08:51
AFAIK nein. Was geloggt wird steuerst du halt über den Syslog Daemon, bzw. Facility und Priority (kern.altert usw.). Mit den dir gegebenen Mitteln hast du nicht viele Möglichkeiten. Mal an eine defekte NIC oder andere defekte Hardware gedacht? Defekter Speicher usw.? Wegen der Buffer:

Schau dir mal die Werte für

/proc/sys/net/core/rmem_max
/proc/sys/net/core/rmem_default
/proc/sys/net/core/wmem_max
/proc/sys/net/core/wmem_default
/proc/sys/net/ipv4/tcp_rmem (drei Werte: min default max)
/proc/sys/net/ipv4/tcp_wmem (drei Werte: min default max)

an.

Sorehead
15.03.06, 09:14
franz:~ # cat /proc/sys/net/core/rmem_max
131071
franz:~ # cat /proc/sys/net/core/rmem_default
65535
franz:~ # cat /proc/sys/net/core/wmem_default
65535
franz:~ # cat /proc/sys/net/core/wmem_max
131071
franz:~ # cat /proc/sys/net/ip
ipsec ipv4 ipv6
franz:~ # cat /proc/sys/net/ipv4/tcp_r
tcp_reordering tcp_retries1 tcp_rfc1337
tcp_retrans_collapse tcp_retries2 tcp_rmem
franz:~ # cat /proc/sys/net/ipv4/tcp_rmem
4096 87380 174760
franz:~ # cat /proc/sys/net/ipv4/tcp_wmem
4096 16384 131072

Und nu?

Also ich befürchte, dass er heute wieder abkackt...



Wed Mar 15 09:10:00 CET 2006
>>>Speicher<<<
total: used: free: shared: buffers: cached:
Mem: 1057779712 1025527808 32251904 0 142966784 743862272
Swap: 1077469184 0 1077469184
>>>Squids (80/81/84)<<<
Checking for WWW-proxy squid
Checking for WWW-proxy squid
Checking for WWW-proxy squid
>>>CPU<<<
31129 root 24 0 1056 1056 880 S 0.0 0.1 0:00 squid8080
31142 squid 15 0 20404 19M 1240 S 0.0 1.9 5:20 squid8080
31143 squid 15 0 1472 1472 1172 S 0.0 0.1 0:00 squid_ldap_auth
31144 squid 15 0 1472 1472 1172 S 0.0 0.1 0:00 squid_ldap_auth
31145 squid 15 0 1472 1472 1172 S 0.0 0.1 0:00 squid_ldap_auth
31146 squid 15 0 1472 1472 1172 S 0.0 0.1 0:00 squid_ldap_auth
31147 squid 25 0 1016 1016 784 S 0.0 0.0 0:00 squid_ldap_auth
31148 squid 15 0 284 284 240 S 0.0 0.0 0:08 unlinkd
31151 root 23 0 1056 1056 880 S 0.0 0.1 0:00 squid8081
31153 squid 15 0 12280 11M 1236 S 0.0 1.1 0:03 squid8081
31154 squid 15 0 1472 1472 1172 S 0.0 0.1 0:00 squid_ldap_auth
31155 squid 25 0 1016 1016 784 S 0.0 0.0 0:00 squid_ldap_auth
31160 squid 25 0 1016 1016 784 S 0.0 0.0 0:00 squid_ldap_auth
31161 squid 25 0 1016 1016 784 S 0.0 0.0 0:00 squid_ldap_auth
31162 squid 25 0 1016 1016 784 S 0.0 0.0 0:00 squid_ldap_auth
31163 squid 15 0 284 284 240 S 0.0 0.0 0:00 unlinkd
31173 root 24 0 1132 1132 884 S 0.0 0.1 0:00 squid8084
31175 squid 15 0 19040 18M 1232 S 0.0 1.8 7:21 squid8084
31176 squid 15 0 284 284 240 S 0.0 0.0 0:01 unlinkd
CPU states: 0.1% user, 0.2% system, 0.0% nice, 0.0% idle
CPU states: 0.5% user, 1.9% system, 0.0% nice, 97.4% idle
>>>Netz<<<
Rx_Errors 1
Tx_Errors 0
Rx_Length_Errors 0
Rx_Over_Errors 0
Rx_CRC_Errors 1
Rx_Frame_Errors 0
Rx_FIFO_Errors 12868
Rx_Missed_Errors 0
Tx_Aborted_Errors 0
Tx_Carrier_Errors 0
Tx_FIFO_Errors 4
Tx_Heartbeat_Errors 0
Tx_Window_Errors 0
Rx_Long_Length_Errors 0
Rx_Align_Errors 0

bla!zilla
15.03.06, 10:07
Öhm...



Rx_Errors 1
Tx_Errors 0
Rx_Length_Errors 0
Rx_Over_Errors 0
Rx_CRC_Errors 1
Rx_Frame_Errors 0
Rx_FIFO_Errors 12868
Rx_Missed_Errors 0
Tx_Aborted_Errors 0
Tx_Carrier_Errors 0
Tx_FIFO_Errors 4
Tx_Heartbeat_Errors 0
Tx_Window_Errors 0
Rx_Long_Length_Errors 0
Rx_Align_Errors 0

Möchtest du die Fehler nicht erstmal beheben bis wir weitersuchen?

Sorehead
15.03.06, 10:08
Hmmm...

Nur mal zum Verstädnis. Was genau sagen denn diese Fehler aus? bzw wie kann ich die denn beheben...?

bla!zilla
15.03.06, 11:58
Wenn ein NIC ein Paket empfängt, wandert das erstmal in einen Buffer bevor es per DMA in den Speicher geschoben wird. Wenn die Daten aber nicht in den Speicher kommen, aber weiter Pakete in den Buffer laufen, dann quillt der irgendwann über. Das ist bei den eingehenden Paketen ein RX_FIFO_Error. Wenn die Pakete aus dem Speicher zur NIC kommen und in den Buffer wandern, dann aber nicht weiter geschickt werden, quillt der auch irgendwann über. Das ist dann ein TX_FIFO_Error. CRC Fehler sollten bekannt sein. Üblicherweise tritt das bei Überlastung auf.

Sorehead
15.03.06, 12:37
Und wie kann man sowas beheben..

bla!zilla
15.03.06, 12:40
Üblicherweise tritt das bei Überlastung auf

Überlast abbauen? Evtl. defekte Hardware finden und austauschen.

Sorehead
15.03.06, 12:43
Wa skann denn in diesem Fall die defekte Hardware sein? Der Speicher? Oder ist die Netzwerkkarte zu schwach??

Es ist jetzt ne Intel Pro/100 S Desktop drin....

bla!zilla
15.03.06, 12:44
Speichertest durchführen, mal die NIC tauschen gegen ein gleiches Modell oder das nächstgrößere Modell. Mal die Last der Maschine vor den Abstürzen beobachen.

Sorehead
15.03.06, 12:47
Hmm, was ist denn das Nächstgrößere Modell?? Danach kommen doch eigentlich die 1000er und die Serveradapter, die aber nicht in den normalen PCI-Port passen...

NIC tauschen kann ich mal testen. Speichertest ebenfalls..

Sonst noch Ideen?

bla!zilla
15.03.06, 13:03
Es gibt auch 1000Mbit Adapter für 32 Bit / 66MHz PCI. Zudem ist 64Bit PCI / 66Mhz abwärtskompatibel zu 32 Bit PCI /66Mhz Slots.

Sorehead
15.03.06, 14:09
Aber meinst Du, dass die 1000er das Problem beheben bzw. mindern würde?

bla!zilla
15.03.06, 14:18
Egal, nimm irgendeine andere NIC von der du weißt das sie okay ist. Teste den Speicher und beobachte die Last der CPU, des Speichers und die Auslastung der NIC.