Bonjour,
je cherche des retours d'expérience avec FS-Cache + CacheFS ou CacheFiles. Je voudrais m'en servir pour mettre en cache disque local, un montage NFS, dans le but de continuer à servir les documents en cache si le serveur NFS tombe.
Sinon j'me lance dans le noir, mais si je peux gagner quelques jours de tests ce serait cool :)
Bonjour Gregory,
J'ai peur que fs-cache ne te serve pas si ton NFS est down, enfin, ça serait à tester. Je ne l'ai jamais utilisé en ce sens.
De mon coté, je l'utilise (fs-cache) sur de nombreuses machines (comprendre > 10) en prod, mais surtout pour soulager le NFS et servir les documents des disques locaux. Par contre, c'est encore "jeune" comme techno. Mais je n'ai pas trouvé mieux pour le moment.
Déjà, sur un 2.6.xx, on a eu plein de soucis. La on est sur du 3.2 (après passage sur du 3.0), c'est déjà plus stable et encore des fois, suffit d'un upgrade "mineur" du kernel et ça peut partir en live.
On a aussi rencontré des soucis entre fs-cache et xfs (pour les disques locaux), on est passé en ext4, c'est plus stable.
Pour finir, l'outil intégré pour "nettoyer" le cache s'il est trop plein ne fonctionne pas toujours très bien. Sur certaines de mes machines, le process se bloque dans une loop et prend 100% d'un coeur CPU. C'est rare, mais ça arrive. Le process nettoie bien, mais en boucle et très lentement. Il peut se débloquer tout seul quand on rajoute des nouveaux fichiers sur le nfs et qu'il se met à cacher. Sinon, il faut arréter le démon et le relancer...
Bonne soirée. David.
Le 29/05/2012 17:23, Gregory Duchatelet a écrit :
Bonjour,
je cherche des retours d'expérience avec FS-Cache + CacheFS ou CacheFiles. Je voudrais m'en servir pour mettre en cache disque local, un montage NFS, dans le but de continuer à servir les documents en cache si le serveur NFS tombe.
Sinon j'me lance dans le noir, mais si je peux gagner quelques jours de tests ce serait cool :)
Bonjour David,
Le 29/05/2012 18:04, David B. a écrit :
J'ai peur que fs-cache ne te serve pas si ton NFS est down, enfin, ça serait à tester. Je ne l'ai jamais utilisé en ce sens.
pourtant, c'est en ce sens que la techno m'intéresse : mon serveur NFS dépote grace au SAN en RAID10 SAS @15krpm...
Déjà, sur un 2.6.xx, on a eu plein de soucis. La on est sur du 3.2 (après passage sur du 3.0), c'est déjà plus stable et encore des fois, suffit d'un upgrade "mineur" du kernel et ça peut partir en live.
Vraiment pas rassurant !
On a aussi rencontré des soucis entre fs-cache et xfs (pour les disques locaux), on est passé en ext4, c'est plus stable.
Pour finir, l'outil intégré pour "nettoyer" le cache s'il est trop plein ne fonctionne pas toujours très bien. Sur certaines de mes machines, le process se bloque dans une loop et prend 100% d'un coeur CPU. C'est rare, mais ça arrive. Le process nettoie bien, mais en boucle et très lentement. Il peut se débloquer tout seul quand on rajoute des nouveaux fichiers sur le nfs et qu'il se met à cacher. Sinon, il faut arréter le démon et le relancer...
Le but, c'est d'avoir mieux, là j'ai bien peur que ce ne soit pas le cas. Merci pour ce retour, parce que du coup je vais jeter un oeil aux alternatives, notamment en ce qui me concerne au module NGiNX ngx_slowfs_cache ...
Attention ceci peut etre un troll.
Et redonder ton serveur nfs c'est tricher ? :D
Le 30 mai 2012 13:22, Gregory Duchatelet greg-frsag@duchatelet.net a écrit :
Bonjour David,
Le 29/05/2012 18:04, David B. a écrit :
J'ai peur que fs-cache ne te serve pas si ton NFS est down, enfin, ça serait à tester. Je ne l'ai jamais utilisé en ce sens.
pourtant, c'est en ce sens que la techno m'intéresse : mon serveur NFS dépote grace au SAN en RAID10 SAS @15krpm...
Déjà, sur un 2.6.xx, on a eu plein de soucis. La on est sur du 3.2 (après passage sur du 3.0), c'est déjà plus stable et encore des fois, suffit d'un upgrade "mineur" du kernel et ça peut partir en live.
Vraiment pas rassurant !
On a aussi rencontré des soucis entre fs-cache et xfs (pour les disques locaux), on est passé en ext4, c'est plus stable.
Pour finir, l'outil intégré pour "nettoyer" le cache s'il est trop plein ne fonctionne pas toujours très bien. Sur certaines de mes machines, le process se bloque dans une loop et prend 100% d'un coeur CPU. C'est rare, mais ça arrive. Le process nettoie bien, mais en boucle et très lentement. Il peut se débloquer tout seul quand on rajoute des nouveaux fichiers sur le nfs et qu'il se met à cacher. Sinon, il faut arréter le démon et le relancer...
Le but, c'est d'avoir mieux, là j'ai bien peur que ce ne soit pas le cas. Merci pour ce retour, parce que du coup je vais jeter un oeil aux alternatives, notamment en ce qui me concerne au module NGiNX ngx_slowfs_cache ...
-- Greg
Liste de diffusion du FRsAG http://www.frsag.org/
Le 30/05/2012 13:43, Sébastien FOUTREL a écrit :
Attention ceci peut etre un troll.
Et redonder ton serveur nfs c'est tricher ? :D
Il est déjà redondé, le SAN aussi, mais le temps de bascule est juste long. Si je pouvais faire d'une pierre 2 coups, améliorer la dispo et ajouter du cache donc améliorer les perfs, ce serait bien :)
Merci pour ta réponse qui m'a permis de comprendre un peu plus ta problematique. Et le temps de bascule "juste long" c'est combien de temps pour qu'on ait une echelle de valeur commune ?
Je travaille depuis quelques années avec du nfs sur des plateformes haute-dispo et a forte charge et je n'ai pas eu beaucoup de problemes de ce genre.
Le 30 mai 2012 13:50, Gregory Duchatelet greg-frsag@duchatelet.net a écrit :
Le 30/05/2012 13:43, Sébastien FOUTREL a écrit :
Attention ceci peut etre un troll.
Et redonder ton serveur nfs c'est tricher ? :D
Il est déjà redondé, le SAN aussi, mais le temps de bascule est juste long. Si je pouvais faire d'une pierre 2 coups, améliorer la dispo et ajouter du cache donc améliorer les perfs, ce serait bien :)
-- Greg
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour Sébastien,
Le 30/05/2012 21:06, Sébastien FOUTREL a écrit :
Merci pour ta réponse qui m'a permis de comprendre un peu plus ta problematique. Et le temps de bascule "juste long" c'est combien de temps pour qu'on ait une echelle de valeur commune ?
Le plus court, c'est quand le serveur NFS tombe, mais pas le SAN. Heartbeat : ~10s Stale NFS handle : ~90s Restart des serveurs Apache et NGiNX dont le load est monté en flèche : non géré (souvent, il faut les rebooter complètement)
En cas de plantage et bascule du SAN, ça se compte en heure, j'ai pas encore eu les corones de me projeter :)
Alors qu'avec un simple cache disque local, je pourrais gérer la situation bien plus sereinement !
Si NFS est un vraiment problème et que le site est cacheable, le mieux IMHO est de rajouter un reverse-proxy devant nginx (ex varnish).
Varnish est génial, parce qu'il est programmable : on peut définir ses propres règles de gestion pour adapter le fonctionnement du cache en fonction de son applicatif (en contrepartie, on peut aussi bien se vautrer et faire baver les sessions utilisateurs d'un utilisateur sur l'autre).
Au niveau de varnish : => backend nginx avec un healthcheck HTTP (https://www.varnish-cache.org/trac/wiki/LoadBalancing) => utiliser la fonction "grace" de varnish pour prolonger le TTL du cache en cas de problème de backend (https://www.varnish-cache.org/trac/wiki/VCLExampleGrace)
varnish sera capable de servir les objets en cache (y compris, avec certaines limitations, les objets expirés récemment) lorsque nginx sera en vrac.
Si le site réagit différemment en fonction de l'utilisateur (ex: pour une même url, non connecté/pas de cookie => page statique, utilisateur connecté/cookie présent => page dynamique/personnalisé), il est tout à fait possible de demander à varnish de basculer les utilisateurs connectés sur la version statique en cas de panne de backend.
en pseudo code :
if (cookie absent || backend hs) { if (backend hs) { prolonge la durée de vie du cache } vérifie le cache et sinon, accède au backend } else { pas de cache, accède au backend }
On peut aussi définir plusieurs backend (backend1/primaire : version normale, backend2/version dégradée) et demander à varnish de basculer de l'un à l'autre :
if (backend1 ok) { utiliser backend1 } else if (backend2 ok) { utiliser backend2 } else { servir une HTTP/500 personnalisée }
Bon, je dérive de l'admin sys vers des problématiques plus devops voire dev...
JFB
Le 31 mai 2012 à 09:35, Gregory Duchatelet a écrit :
Bonjour Sébastien,
Le 30/05/2012 21:06, Sébastien FOUTREL a écrit :
Merci pour ta réponse qui m'a permis de comprendre un peu plus ta problematique. Et le temps de bascule "juste long" c'est combien de temps pour qu'on ait une echelle de valeur commune ?
Le plus court, c'est quand le serveur NFS tombe, mais pas le SAN. Heartbeat : ~10s Stale NFS handle : ~90s Restart des serveurs Apache et NGiNX dont le load est monté en flèche : non géré (souvent, il faut les rebooter complètement)
En cas de plantage et bascule du SAN, ça se compte en heure, j'ai pas encore eu les corones de me projeter :)
Alors qu'avec un simple cache disque local, je pourrais gérer la situation bien plus sereinement !
-- Greg
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour Grégory,
Je n'ai pas dis que fs-cache ne fonctionnait pas si le NFS était down, j'ai juste indiqué que je ne savais pas si cela fonctionnait. :) En effet, fs-cache semble commencer par faire un getattr NFS pour savoir s'il doit servir son fichier du cache ou du NFS. Du coup, je ne sais pas comment il se comporte sans le NFS.
Au sujet des mes soucis avec les kernel 2.6.xx, c'était il y a plusieurs mois. C'est peut être corrigé depuis (via des patchs sur des kernel 2.6), je ne sais pas. Je n'ai pas downgrader pour tester.
J'en profite pour préciser une chose que j'avais oubliée la dernière fois. Nous ne faisons que du READ en NFS, d'ailleurs, le NFS est monté en RO. Du coup, je ne sais pas comment se comporte FS-Cache dans un environnement read-write. Mes machines qui ont besoin d'écrire, elles n'ont pas fs-cache. :)
Par contre, j'ai remarqué un soucis d'invalidation du cache. Si un fichier toto est servi de façon intensive sur le serveur et que ce fichier est modifié en NFS. FS-cache est censé servir toto du NFS en attendant de mettre à jour son cache. Nous, on a constaté que si les accès sont importants, FS-cache plantait lamentablement (entrainant le kernel avec lui des fois).
On a contourné le soucis coté applicatif. Si je dois changer un fichier, au lieu de le modifier, je vais en créer un nouveau avec un nouveau nom. Ca a le mérite de fonctionner. Idem pour ce soucis, je n'ai pas retesté pour voir si le bug était corrigé depuis.
Le 30/05/2012 13:22, Gregory Duchatelet a écrit :
Le but, c'est d'avoir mieux, là j'ai bien peur que ce ne soit pas le cas. Merci pour ce retour, parce que du coup je vais jeter un oeil aux alternatives, notamment en ce qui me concerne au module NGiNX ngx_slowfs_cache ...
Je note l'idée, je regarderais aussi ngx_slowfs_cache. :)
David.
-
David B. -
Gregory Duchatelet -
JF Bustarret -
Sébastien FOUTREL