Questions diverses
-
Je pose cette question car pour le moment je n'ai qu'un serveur de disponible avec un disque HDD de 100 Go.
Comme vous le dîtes, peut-être que je pourrais séparer Squid et les logs.
Le mieux à faire serait que je puisse exporter les logs avec le log rotate car à côté j'ai un NAS qui a de la place. Est-ce envisageable et propre comme solution ?
-
Je pose cette question car pour le moment je n'ai qu'un serveur de disponible avec un disque HDD de 100 Go.
C'est largement suffisant en termes d'espace disque.
Comme vous le dîtes, peut-être que je pourrais séparer Squid et les logs.
Mon point sur la séparation n'est pas le log mais le cache. Non pas que les aspects partitionnement ne soient pas importants (autant anticiper les réactions genre "c'est n'importe quoi" ;D) mais ce que j'exprimais au sujet de la séparation, c'est que le proxy, si il y a beaucoup d'utilisateurs, est sensible à la latence induite par les I/O disques dus à la lecture du cache si il y a beaucoup d'utilisateurs.
Du coup, un seul axe (HDD) complique un peu les choses.
Un SSD est bien plus rapide mais la technologie n'est pas adaptée à ce type d'usage, sauf si tu as un SSD dédié au cache et que tu as prêt à le changer de temps en temps (ce n'est plus très cher)Dans tous les cas, ne te prends pas trop la tête avec ça pour le moment car avec HTTPS il y a de mons en moins de cache mais garde le à l'esprit si tu rencontres des problèmes de performance avec Squid.
Le mieux à faire serait que je puisse exporter les logs avec le log rotate car à côté j'ai un NAS qui a de la place. Est-ce envisageable et propre comme solution ?
Envisageable ? certainement !
le mieux ? ça dépend du risque que tu veux couvrir.- si c'est de l'archivage de fichier access.log compressés, oui c'est une des bonnes solutions
- si il s'agit de garantir la sauvegarde du fichier access actif et que tu veux palier au fait qu'il n'y a pas un système de disque redondant (type RAID 1, 5 ou autre) surveillé (1) sur le serveur Squid, alors non ce n'est pas la bonne solution car en cas de crash du disque du serveur Squid, tu perds le contenu du fichier access.
C'est, entre autres, pour cela que certains utilisent rsyslog: externalisation en temps (presque) réel des fichiers log.
L'autre usage de rsyslog (mais pas très utile à mon sens pour le proxy) c'est la corrélation: si tes machines sont bien alignées temporellement (NTP), faire du debug avec un fichier de log qui centralise tous les logs, c'est vraiment très pratique 8)
(1): car rien n'est pire qu'un système RAID sans monitoring :P
-
En parlant de cache, je recherche un tutoriel sur comment bien sizer son cache car je ne me rends pas trop compte.
Si vous aviez ça sous la main, je suis preneur :D
Sinon pour l'exportation, je parle surtout pour l'archivage. C'est-à-dire que les logs sont enregistrés en temps réel sur la machine Squid et lorsqu'il faut les sauvegarder, hop sur le NAS !
Quand vous dîtes "séparer les axes", ça veut dire quoi concrètement ? Partitionnement ?
Encore merci :)
Dès lundi je me lance là-dedans ;)
-
En parlant de cache, je recherche un tutoriel sur comment bien sizer son cache car je ne me rends pas trop compte.
Si vous aviez ça sous la main, je suis preneur :DQuand vous dîtes "séparer les axes", ça veut dire quoi concrètement ? Partitionnement ?
non justement. Le partitionnement n'a pas d'impact réel sur la performance. Ce n'est pas le partitionnement qui est important mais la manière dont celui-ci est fait en fonction des disques.
Le cache, c'est du fichier sur le disque, donc de la lecture et de l'écriture.
La performance du disque est liée d'une part au taux de transfert mais également, et surtout dans le cas de lecture "non continue" au temps de positionnement des têtes (qui je le rappelle se déplacent toute en même temps pour les têtes associées à un axe donné - spindle en anglais si tu dois lire de la doc à ce sujet et sur l'importance du "seek time").Donc si ton disque doit supporter en même temps le fonctionnement du système, l'écriture du log et gestion du cache Squid, l'impact en termes de performance est sensible.
Donc il est est souhaitable de :- créer une partition dédiée sur un disque dédié
- de configurer le cache pour qu'il ne prenne pas toute la taille de la partition qui lui est dédiée
un peu de lecture.
Encore une fois, c'est intéressant mais pas forcément critique selon le nombre et l'activité des utilisateurs. juste à bien comprendre pour le jour où ça ne va pas bien fonctionner.
-
Sachant que j'ai qu'un disque de disponible pour le moment, j'espère que ça ne sera pas un problème.
Le mieux à faire ? :
-
1 partition pour le système et Squid
-
Une partition pour les logs
-
-
La manière de gérer les partitions dépend des habitudes de chacun et chaque administrateur va pouvoir t'expliquer pourquoi sa méthode est la bonne et toute autre méthode différente n'est pas "la bonne pratique". Je ne vais donc pas m'aventurer sur ce terrain ;D ;D ;D :-X
Ma seule suggestion: fais au moins une partition à part pour /var/log ou pour /var
-
Hm petite question, si le proxy est configuré, que j'arrive à y accéder à partir d'un client mais que c'est particulièrement lent ça peut venir d'où ?
Même si le site est chargé, il y a encore le petit rond qui tourne en haut.
J'ai essayé avec plein de fichiers de conf, toujours la même chose (même sur deux machines différentes).
acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT acl Local_Net src 10.1.0.0/16 http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow localhost manager http_access deny manager http_access allow localhost http_access allow Local_Net http_access deny all http_port 3128 # -------------------------------------------- # Mise en tampon de Squid : # -------------------------------------------- # Par défaut, le tampon de Squid est activé, # ce qui permet d'accélérer le chargement de certaines pages. # La taille par défaut est de 100 Mo (situé dans /var/spool/squid3). # Vous pouvez changer la valeur 100 par ce que vous voulez (par exemple 128 pour 128 Mo) : # cache_dir ufs /var/spool/squid 1 00 16 256 cache_dir ufs /var/spool/squid3 128 16 256 # Taille maximum de mémoire vive utilisée pour stocker le tampon : cache_mem 128 MB # Taille maximum des objets stockés dans le tampon : maximum_object_size 16 MB # -------------------------------------------- # Tampon DNS : # -------------------------------------------- # Par defaut, Squid est configuré pour garder 6 heures le tampon DNS # dont il a pu résoudre le nom et 5 minutes celui dont il n'a pas pu résoudre le nom DNS. # Modification du temps de tampon pour la résolution de nom - positive - positive_dns_ttl 8 hours # Modification du temps de tampon pour la résolution de nom - négative - negative_ttl 4 minutes refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320 # -------------------------------------------- # Messages d'erreur en français : # -------------------------------------------- error_directory /usr/share/squid3/errors/French -
Squid est sensible au dimensionnement des ressources et notamment taille du cache.
Ce document peut vous servir de base : http://wiki.squid-cache.org/SquidFaq/SquidMemory
Après il peut y avoir d'autres facteurs qui impactent les temps de réponse. -
Même en étant tout seul sur le réseau et en essayant d'accéder à google ?
Je n'ai vraiment pas la solution là .. Le rond tourne pendant au moins 1 minute et la page a encore du mal a se charger après.
-
je pense que oui. Après il y a tous les paramètres habituels réseau ….
-
C'est peut-être le cache mais je me suis inspiré d'au moins 10 fichiers de conf trouvés sur internet et imposible ..
L'accès aux sites est super lent .. je ne sais vraiment pas quoi faire
-
Ce n'est très probablement pas une problématique de cache si tu as un seul client, sauf si ta machine est déjà très chargée.
Il y a des plugins, en fonction du browser que tu utilises, qui sont capables de déterminer combien de temps tu passes à quel endroit quand tu télécharges tous les objets d'une page, y compris le temps du proxy.Avec quel browser fait-tu le test ?
Par ailleurs, il y a peut-être d'autres aspects liés à ta conf réseau.
Comment se passe un wget sur la machine proxy ? -
Salut Chris,
Pour les plugins, je ne savais pas, je vais regarder dès demain. Mais pour moi le temps que je perds c'est surtout sur le proxy.
Sur le serveur wget passe très bien et sur l'autre debian que j'ai essayé, en allant sur internet via un browser ça va tout seul.
Sur mon client j'ai essayé avec Firefox et IE.
C'est vraiment très étrange, j'ai passé beaucoup de temps dessus et je sais plus trop quoi faire .. J'ai dejà visite beaucoup de liens Google.
J'ai aussi essayé de faire des fichiers de conf vraiment simples (Acl, http_access) mais rien n'y fait.Configuration réseau :
Le proxy en 192.168.2.254/24
Le pfsense en 192.168.2.253/24
Le client en 192.168.2.100/24(En passant du client au squid du pfsense aucun soucis)
-
Avec une conf pratiquement par défaut de Squid et un seul utilisateur, il n'y a pas de raison pour qu'il y ait le moindre problème.
ACL pour autoriser ton LAN (mais avec un proxy sur le LAN ce n'est même pas indispensable, en tous cas pour le moment).
Ce que je veux dire c'est que le tuning de la conf du proxy, c'est critique mais uniquement avec de la charge, pas dans ton cas.Tu peux essayer de désactiver le cache pour vraiment limiter la charge du proxy au maximum, juste pour voir.
Ce qu'il faut bien comprendre, c'est qu'au niveau DNS par exemple, si ce n'est pas bien configuré, ça peut avoir un impact très important.Il faut par exemple bien comprendre que lorsque tu es en mode "no proxy" ou en mode "tranparent proxy", c'est la machine sur laquelle est le browser qui fait les requêtes DNS.
Dans le cas d'un proxy explicite, c'est le proxy qui fait prend en charge la résolution de URL en IP.
Si le DNS au niveau du proxy est mal configuré, ça marche beaucoup moins bien. -
Oui j'ai pensé au DNS aussi mais quand je prends un browser sur le serveur que je vais sur internet ça marche très bien .. Ça veut donc dire que ça ne vient pas de là si ?
Sachant que quand je rentre l'URL sur un browser client, le titre de la page s'affiche directement mais le contenu met du temps à venir.
-
Oui j'ai pensé au DNS aussi mais quand je prends un browser sur le serveur que je vais sur internet ça marche très bien ..
:o oops, un browser sur le serveur ::) mais ce n'est pas un serveur :P
Il y a Gnome sur ton serveur ?
Pour répondre à ta question, la configuration DNS du proxy peut être différente de celle du serveur qui le supporte.
Sachant que quand je rentre l'URL sur un browser client, le titre de la page s'affiche directement mais le contenu met du temps à venir.
Il faut regarder dans le log du proxy de qui est en HIT et en MISS, autrement dit ce qui vient du cache et ce qui vient du web.
Et comparer HTTP avec HTTPS.
Par ailleurs, jeter un coup d’œil aux log de Squid ne peut pas faire de mal.Pour du debug, il faut également avoir une idée de l'espace disque disponible et de la manière dont tu as configuré le cache. Si par exemple tu crées un partition dédié au cache et que tu configure le proxy pour utiliser TOUTE cette partition, ça ne marche pas. C'est très bien expliqué sur le site de Squid.
Avec quels sites fais tu le test ?
As-tu, par ailleurs, regardé le comportement, au niveau OS, de ton "serveur" (si on peut dire :p) Squid ? swapping par exemple ?
-
Sur le premier serveur où j'ai testé, il n'y a pas gnome mais j'ai une debian avec gnome donc j'ai testé dessus x)
D'après mes souvenirs il me semble que tout est en MISS.
Les liens HTTP sont beaucoup plus rapides que HTTPS.
Je n'ai pas de partition spéciale pour le cache, c'est une partition pour /var/
Même sans configurer de cache ça ne marche pas ..
J'ai testé des sites légers et des sites lourds. Les sites légers répondent un peu plus vite mais le temps que ça met n'est pas normal.
Je sais pas qu'est ce que je peux faire d'autre .. Je t'ai laissé un mail chris si tu as le temps de check ;)
Il me manque que ça pour finir c'est énervant x)