[Résolu] Disque de stockage USB sur un 4860 1U et déplacement de données (log ?)
-
Je reviens.
Squid utilise le disque pour le cache et les logs (2 stockages différents).
La taille du cache (ligne cache_dir) doit être en rapport avec la mémoire (puisque Squid stocke en mémoire un lien vers chaque object du cache).
Par exemple, un cache de 10 Go est incompatible avec 1 Go de mémoire !
Le cache est stocké usuellement /var/spool/squid/Les logs Squid sont usuellement dans /var/log/squid/access.log.
De façon usuelle (sur un proxy dédié), il doit y avoir une 'rotation' des logs (access.log -> access.log.0 -> access.log.1 …)Concernant le disque USB, il semble connu sous le nom 'da1'.
Il doit donc y avoir une partition sous un nom 'da1s1a' (/dev/xxxx).
Il faut donc avoir une partition d'un type connu de pfSense et donc FreeBSD : typiquement ufs
Il faut ensuite la monter à un endroit prévu, avec montage auto (dans /etc/fstab).
Ne pas compter sur une partition de type ntfs ou ext2/3 ... (faut-il le préciser ?) -
@jdh:
Ce boitier (appliance pfsense visible sur https://store.pfsense.org/SG-4860) est visiblement conçu pour être un firewall sans Squid/SquidGuard (mais avec VPN).
Il est presque certain qu'après un petit temps, vous serez déçu de la performance parce que Squid va utiliser toute la puissance.
ça dépend vraiment du nombre d'utilisateurs et de leur activité.
Je fais, en ce moment même, tourner un MTA (postfix) avec Squid (mais presque sans filtrage) sur un C1037UN qui est à peu près équivalent (un peu moins performant) que le C2558 du 4860. Entre 4 et 8 utilisateurs et ça marche correctement.Pour le stockage de log Squid,
Pour ce boitier, seul un disque mSata semble prévu, mais ce type de disque (flash) ne me parait pas très adapté à l'usage de stockage même de (simples) logs syslog (généralement soit on limite drastiquement les logs soit on utilise un syslog distant).
Ajouter un disque USB suppose des drivers USB dont je ne suis pas sûr qu'ils soient installés …mSATA, c'est du microSATA et ça décrit le format physique du connecteur SATA.
C'est vrai qu'il y a des fabricants qui proposent du flash avec une interface mSATA (et je suis d'accord que ça ne présente pas d'intérêt ici) mais la plupart proposent du mSATA qui est du SSD, donc avec des performances très correctes, voire excellentes pour du cache proxy ou du log (lequel n'est pas le bottleneck).
Reste à parier sur la durabilité ;)Ce 4860 est assez cher si on regarde les performances brutes mais également intéressant, à tel point que je vais en recevoir un demain pour un de mes clients ;D
-
Il y a les gens prudents (matériels avec un peu de marge, organisation saine, best practices, …) et il y a ... l'ergoteur en chef
C'est fatiguant ...
-
Je comprends bien l'objectif de sécurité et de fiabilité que de répartir les différents usages sur différents serveurs.
Ceci dit il est parfois compliqué, en terme de couts mais surtout en terme d'administration, de multiplier les serveurs et systèmes au seins d'une petite structure.Effectivement et c'est pour cette raison que beaucoup de solutions de type "all-in-one" on du sucés. Et globalement, ça marche plutôt bien lorsque c'est adapté à la taille de la structure.
L'usage du port Sata est parfaitement cohérent, et j'ai fais l'erreur de ne pas prendre un disque ssd optionnel au moment de l’achat.
Il faut que je vois si l'ouverture du boitier risque de poser un problème en terme de garantie.Il n'y a pas de raison. Ton retour à ce sujet m'intéresse beaucoup.
-
@jdh:
Il y a les gens prudents (matériels avec un peu de marge, organisation saine, best practices, …)
Ils ont bien raison d'être prudents 8)
Il est effectivement important de bien choisir son design et son déploiement en fonction de ses besoins, nous sommes d'accord.D'ailleurs voila à titre d'exemple, en attachement, un profil de charge CPU sur un proxy (standalone) pour une entreprise d'environ 80 utilisateurs dont la moitié accède à internet via le proxy (avec un filtrage standard, c'est à dire les entrées classiques de la liste toulousaine, porno, violence etc…).
Suis-je dans les best practices en termes de marge au niveau matériel selon tes critères ? J'espère que oui ;D
En tous cas, pas de swap ni I/O wait. So far, tout va bien 8)Et pourtant, cette machine est un pauvre petit Atom 330 avec 1 Go de mémoire, soit bien moins que le C2558 auquel nous faisons référence dans ce fil :P
Ce que je veux illustrer par là, c'est que ce qui est important, c'est de factuellement bien comprendre quel est le besoin dans l'infrastructure globale dans laquelle ta solution s'inscrit avant de juger si la solution est bonne ou pas bonne.
Pourquoi ça marche dans le cas que je décris ? Simplement parce que l'accès internet tourne autour de 20 Mb/s et que les utilisateurs ont un usage modéré du web.
La plate-forme que je montre est une solution temporaire dans le cadre d'une réorganisation globale mais ce graphe illustre bien qu'il n'est pas nécessaire de prévoir une machine beaucoup plus puissante dans le design cible.PS:
dans les best practices que tu mets systématiquement en avant, il y en a une que je ne saurais trop conseiller d'appliquer: avoir une vraie connaissance du fonctionnement de son infrastructure. Et ça passe souvent, même pour des petites plate-formes, par la mise en œuvre de graphes type RRD. Quand on sait les lire, ça apporte beaucoup.
De ce point de vue, pfSense a le bon sens d'inclure ce type dans son interface 8)
-
Concernant Squid/SquidGuard,
Compte tenu des tailles de cache, des logs, de la nature du fonctionnement, il est NECESSAIRE d'avoir un disque mécanique et non flash/ssd !
(Outre que les tailles doivent être adaptées ce que peu mentionne !)Par voie de conséquence, je répète que cette appliance NE DOIT PAS utiliser Squid/SquidGuard (en dépit de la fiche).
Par ailleurs la mention 'petite entreprise' ne donne aucune indication sur nombre d'utilisateurs et petit/moyen/gros usage du web.
Il est donc impossible de prévoir la charge d'un proxy.J'ai déjà écrit qu'approximativement, à partir de 10 utilisateurs, il FAUT un proxy dédié.
En outre, Squid/SquidGuard sur pfsense ne permet pas de respecter la loi, à savoir conserver 1 an de log de proxy …
(Encore une fois peu le mentionne)Bref encourager ces idées est un mauvais conseil .... Et comme à l'accoutumée ...
-
@jdh:
Concernant Squid/SquidGuard,
Compte tenu des tailles de cache, des logs, de la nature du fonctionnement, il est NECESSAIRE d'avoir un disque mécanique et non flash/ssd !
Peux-tu expliquer pourquoi ? ;D
Sur les aspects taille du disque la différente HDD vs. SSD n'est pas significative. Tu peux facilement mettre un SSD de 512 Go si tu penses que c'est nécessaire.
Pour parler de choses plus factuelles, si je reprends mon exemple de "petite entreprise" de 80 utilisateurs avec un usage modéré du web (puisque ce qui nous intéresse ici, c'est le web et pas internet), voila quelques chiffres:
- access.log => env. 40 Mo / jour
- access.log.n.gz => env. 5 Mo / jour
- cache.log => env. 1.5 Go / jour
- cache.log.n.gz => env. 100 Mo /jour
Si tu gardes une semaine en ligne avant que ton script de rotation compresse, ça donne à la fin de l'année, sur la base de 300 jours d'activité, 1,5 Go de fichier access.log compressé.
Aucun intérêt de conserver les fichiers cache.log ;-)Donc ce n'est pas si gros de ça et rien ne t'interdit de pousser ces fichier vers un serveur externe (c'est même plutôt fortement recommandé pour des raisons d'archivage)
Le reste, coté disque en ce qui concerne Squid, c'est du cache.
A chacun de gérer la taille du cache en fonction de ses besoins. C'est un exercice potentiellement difficile sur de grosses organisations mais ici, c'est assez simple et le facteur limitant est rapidement la mémoire car Squid gère l'indexation de son cache en mémoire. (env. 1/100 du cache disque)Voila pour la taille.
L'autre aspect important à prendre en compte, c'est la performance du disque.
La différence en lecture entre un bon SSD et un HDD est juste énorme (c'est moins vrai en écriture mais l'objectif du cache, c'est quand même principalement d'être lu) et donc dans ce domaine, mettre son cache sur du SSD pour Squid est une excellent idée.Dans un environnement de grande dimension ou avec un usage important du web, même du simple SSD peut devenir le bottleneck. Un lot de SSD en RAID0 peut être nécessaire pour assurer un débit correct. Bien sûr ça marche aussi en HHD, mais moins bien.
Mais peut-être y a t-il des points qui vont à l'encontre de cette solution. N'hésite pas à développer au lieu de juste écrire que c'est NECESSAIRE ;)
(Outre que les tailles doivent être adaptées ce que peu mentionne !)
Par voie de conséquence, je répète que cette appliance NE DOIT PAS utiliser Squid/SquidGuard (en dépit de la fiche).
Par ailleurs la mention 'petite entreprise' ne donne aucune indication sur nombre d'utilisateurs et petit/moyen/gros usage du web.
Il est donc impossible de prévoir la charge d'un proxy.J'ai déjà écrit qu'approximativement, à partir de 10 utilisateurs, il FAUT un proxy dédié.
Mon point au dessus était relatif à la technologie disque (faut-il NECESSAIREMENT un HDD plutôt qu'un SSD ?)
Sur les aspects "proxy dédié vs. sur pfSense", comme le dit Yarglo,
Je comprends bien l'objectif de sécurité et de fiabilité que de répartir les différents usages sur différents serveurs.
Ceci dit il est parfois compliqué, en terme de couts mais surtout en terme d'administration, de multiplier les serveurs et systèmes au seins d'une petite structure.et je partage ce point de vue.
Au lieu d'asséner des "il FAUT" en majuscule, explique donc pourquoi, ce sera beaucoup plus didactique pour tous.Mon exemple précédent même si il ne faut bien sûr pas en faire une généralité, montre que ça marche tout à fait bien sur un Atom 330 et donc ça marcherait à l'identique, voire mieux sur le C2558 du pfSense dont il est question ici.
En outre, Squid/SquidGuard sur pfsense ne permet pas de respecter la loi, à savoir conserver 1 an de log de proxy …
(Encore une fois peu le mentionne)1 - ??? D'où sors tu cela ? quel est ton calcul ?
2 - cette contrainte de conservation des logs est valable en France (et certainement d'en d'autres pays) mais rien ne stipule que tu doives conserver ces logs sur la même et unique machine ;)Bref encourager ces idées est un mauvais conseil …. Et comme à l'accoutumée ...
;D ;D de ton point de vue, j'en conviens.
Après, c'est au lecteur de choisir dans ce qu'il lit pour se faire une idée. -
Pour ce qui est ma question initiale : Est-il possible de déclarer un stockage de masse externe sur un appliance 4860 ?
Je viens juste d'en déballer un.
Je fais des tests d'ici demain et je reviens vers toi avec mes résultats :) -
Juste un précision sur le sujet HDD vs. SSD, histoire que mon propos ne soit pas interprété de manière erronée 8)
Je ne fais pas, dans mon argumentaire, l'apologie du SSD en essayant de faire croire que c'est génial et qu'il faut tout le temps remplacer les HDD par des SSD.
Le principal, et potentiellement gros, problème du SSD, c'est la manière dont il se détériore et cesse de fonctionner.La très grande majorité des HDD supporte SMART et donc envoie le plus souvent des alertes avant de cesser de fonctionner, ce qui permet généralement de sauvegarder les données avec un minimum de perte avant remplacement du disque.
Dans le cas du SSD, c'est beaucoup plus souvent un arrêt brutal sans avertissement, avec peu de chances de récupérer des données.Mais en l’occurrence, on parle dans ce sujet de cache, de log temporaire (puisque l'archivage des logs d'accès est fait poussé ailleurs) et de performance et dans ce cas, le SSD, c'est vraiment bien ;) à mon avis…
-
Pour ce qui est ma question initiale : Est-il possible de déclarer un stockage de masse externe sur un appliance 4860 ?
Donc je viens de faire le test sur un 2440 car le 4860 n'est pas encore configuré.
je ne rencontre pas de problème particulier pour accéder à la clé USB.
En tant que root (en SSH) :
- camcontrol devlist voit ma clé at scbus5 target 0 lun 0 (da1,pass1)
- j'ai créé un filesystem ufs => newfs /dev/da1s1
- que je peux monter sans problème: _mount -t ufs /dev/da1s1 /mnt/usbmount[/i[/color]]
- j'y ai ensuite copier un fichier log, juste pour voir ;-)
il n'y a aucune raison pour que ce soit différent avec le 4860.
A partir de là, l'étape suivante consisterait à configurer Squid pour écrire ses logs sur ce point de montage, mais encore une fois, en USB, ça ne me parait pas terrible comme idée._ -
Si vous aviez une idée pour résoudre ce problème cela m’aiderait grandement.
je viens de regarder l'intérieur du 4860 (dans sa version 1U) car j'y ai ajouté un ventilateur et il y a de la place et des connecteurs pour :
- 3 ports mSATA :o
- 3 ports SATA
- un connecteur d'alimentation pour un HDD ou un disque SATA
- physiquement (pour le 1U) de la place pour un HDD
Bref, de quoi y mettre du stockage supplémentaire ;D si nécessaire :-X
-
Merci Chris pour tous ces développements, tests, explications et argumentations !
Je vais potasser le fonctionnement de FreeBsd et voir ce qui ne va pas de mon coté : sans aucun doute une erreur de ligne de commande ou de droits …
Je vais aussi étudier l’installation d'un sdd interne.Mais j'ai bien compris l'essentiel :
- Squid sur FW : c'est pas bien (mais tolérable ...)
- Log squid sur USB : C'est mal !
A+