Les navigateurs ont un cache DNS, donc pendant qques temps le navigateur ira vers le même serveur (60s sous Firefox par exemple).
De plus, le serveur DNS ne sait pas si le serveur est up ou pas, tu fais de la répartition de charge, mais pas du fail over, potentiellement, tu vas impacter la moitié de tes utilisateurs pendant le temps des différents caches DNS.
Alors certes, il y a des serveurs DNS qui font des tests de vie, mais pour de l'hébergement personnel, ça nécessite une infra encore plus compliquée à mettre en place. En libre je n'en connais pas, sinon cf http://www.a10networks.com/products/global-server-load-balancing.php .
Le titre "disponibilité des services", et on parle répartition de charge
Je ne comprends pas cette remarque : à quoi peut bien servir la répartition de charge si ce n'est pas pour améliorer la disponibilité de ses services ? Parmi mes nombreux défauts j'ai aussi celui de ne pas être un geek, je ne fais de la technique que pour répondre à un besoin, pas pour la beauté conceptuelle ou technique du geste.
Ce n'est pas du tout conceptuel, ce sont deux choses totalement différentes, la répartition de charge et la gestion de la haute dispo. Connectées, mais différentes.
Côté répartition de charge, tu l'as expliqué, on a le round robbin, le least connection, bref un ensemble de techniques pour distribuer la charge plus ou moins justement sur un ensemble de serveurs, tous actifs.
Côté haute dispo, la virtual ip du service qui se balade du serveur actif au passif, la bascule d'une BDD avec linux ha (ou l'équivalent à la mode du moment), la redondance du stockage.
On fait plus souvent de la haute dispo sans répartition de charge, pour s'assurer la disponibilité d'une base de donnée par exemple. On met un mysql ou un postgresql en cluster actif/passif, et on bascule les clients (par modif de conf et arrêt/relance, ou par gestion de la couche client qui se connecter).
La répartition de charge sans haute dispo, google fait ça. Il faut du shared nothing sur des zilliards de serveur, ça monte très bien en charge, on peut rajouter des noeuds sans s'embêter. Et tant pis si le crash d'un serveur prive de service 0.1% des utilisateurs. Parce que c'est compliqué de faire de la haute dispo sur toute la chaine, c'est souvent plus simple, moins complexe à gérer, d'accepter une certaine perte de service pour une partie des utilisateurs.
Là dans la dépêche par exemple, on parle surtout faire du Load balancing / high availibility sur du service HTTP. Mais ça parle du serveur NFS pour stocker les sessions utilisateurs. Si le serveur NFS n'est pas là, tout le service est indisponible (en tout cas, le test de vie applicatif devrait échouer). Le maillon le plus faible conditionne la disponibilité de l'ensemble.
La répartition de charge sur des services autre que http, c'est moins courant par contre. Côté BDD relationnelle on a tendance à pas trop s'embêter avec ça, et si on veut pas de relationnel (ou qu'on peut s'en passer) il reste les quelques nosql prévus pour ça, comme Cassandra ou Couchdb.
Côté système de fichier, les rares qui gèrent ça (de ma faible expérience, j'en ai pas testé des masses) ont tendance à être compliqués à mettre en place, pour des perfs assez aléatoires.
On peut toujours mettre un test de vie et envoyer les utilisateurs vers un autre serveur, mais comme les serveurs ne partagent rien, l'utilisateur perd la session, et donc ce qu'il était en train de faire. La haute dispo du pauvre.
WTF. Tu as eu des cours de réseau quand tu étais jeune? Révise les.
La différence entre DNS, TCP et HTTP est quand même assez bien décrite un peu partout pour que les mécanismes soient clairs, bien définis et bien séparés. Le navigateur lie tout ça, mais la norme HTTP ne s'occupe pas de comment est ouverte la connexion, ni comment les noms sont résolus.
Le titre est trompeur je trouve. C'est selon moi plus un article mode d'emploi sur LVS que sur la dispo des services.
Le titre "disponibilité des services", et on parle répartition de charge. Les deux sujets sont connexes, mais on peut faire l'un ou l'autre, pas forcément les deux.
On ne parle que de LVS alors que les outils de répartition logicielle sont parfois plus simples à prendre en main (comme haproxy ou apache).
On ne parle pas des autres services (NFS, Base de données).
C'est utilisé par xmpp, ldap et sip, mais je vois pas en quoi c'est la faute de http si les navigateurs n'utilisent pas SRV pour les services Web. Des tickets ont pourtant été ouverts dans Mozilla et Chromium (et Webkit).
Que je n'ai pas lu, hein, donc je ne sais pas quel est l'avancement du sujet dans ces tickets.
De plus pour ce qui est de la "simplicité", c'est bien d'avoir un système comme le SRV pour la répartition et la haute dispo, mais faut toujours bien répliquer les données derrière les services et assurer ce service de bout en bout (la "haute dispo" smtp par champ MX, ça permet tout de même pas à l'utilisateur de lire le mail quand tu utilises un MX backup non relié à ton MDA).
Merci pour la réponse in extenso de ce qu'est la tribune, mais vu que je la cottoie un truc genre 10 ans, je connais. Et même si je suis d'accord avec la description, ça ne répond pas trop à la question.
Tu sembles dire que ça pose pas de problème à l'équipe si des bots d'archivage existe, sans vraiment le dire explicitement. C'est ainsi que je comprends
Si des personnes externes à l'équipe du site créent des archives de leur côté, ce seraient donc de leur propre choix
On sait bien que prévenir l'usager de dlfp est pas une habitude, mais un petit texte genre "la recherche est temporairement désactivée", ça serait bien quand même.
Arf, je me souviens combien papatte3< m'avait vraiment faire ch**r là dessus à l'époque où j'avais commencé à faire Olccs. Je m'interroge encore sur sa motivation à refaire un truc d'archivage quand on a sorti tout ce qu'il m'avait sorti à ce moment là.
Alors en fait, je ne voulais pas savoir si un consensus existait ou si une RFC décrivait dans le détail les différentes interactions, mais quel était l'avis des admins. D'où je suis donc intéressé par avoir l'avis des administrateurs du site.
Par conséquent, je voulais savoir si dans l'esprit de la mise en place du robots.txt sur le site, ils comptaient également interdire les différents bots de tribune ou pas. Dont le tiens. Je me doute que de toutes façons, si tu as écris un bot, tu vas forcément penser qu'il a le droit d'aller sur la tribune.
Et c'est en ne comptant pas le fait d'ignorer le robots.txt de linuxfr qui interdit d'archiver la tribune… Merci, beaucoup pour notre droit à l'oubli !
On sait bien que prévenir l'usager de dlfp est pas une habitude, mais un petit texte genre "la recherche est temporairement désactivée", ça serait bien quand même.
Le backend xml n'est rechargé que lors d'un post sur la tribune web, peut-être qu'un wants.xml vide devrait être présent dans le create? C'est peut-être ça qui empêche le after_action d'être lancé après un post avec un accept xml.
[^] # Re: Le bon outil !
Posté par hermenegilde . En réponse au journal [ANN] Channel IRC Sur le Domain Driven Design #dddfr. Évalué à 4.
Ok, penche toi et tousse.
[^] # Re: feature linuxfr
Posté par hermenegilde . En réponse à la dépêche Améliorer la disponibilité de ses services. Évalué à 2.
Mais non! Tu peux autohéberger un serveur mozilla sync: https://wiki.archlinux.org/index.php/Mozilla_Firefox_Sync_Server
Il semble même y avoir un plugin Mozilla Sync pour Owncloud: http://apps.owncloud.com/content/show.php/Mozilla+Sync?content=161793
[^] # Re: Contournement de déficiences du Web
Posté par hermenegilde . En réponse à la dépêche Améliorer la disponibilité de ses services. Évalué à 2.
Les navigateurs ont un cache DNS, donc pendant qques temps le navigateur ira vers le même serveur (60s sous Firefox par exemple).
De plus, le serveur DNS ne sait pas si le serveur est up ou pas, tu fais de la répartition de charge, mais pas du fail over, potentiellement, tu vas impacter la moitié de tes utilisateurs pendant le temps des différents caches DNS.
Alors certes, il y a des serveurs DNS qui font des tests de vie, mais pour de l'hébergement personnel, ça nécessite une infra encore plus compliquée à mettre en place. En libre je n'en connais pas, sinon cf http://www.a10networks.com/products/global-server-load-balancing.php .
[^] # Re: Titre de l'article
Posté par hermenegilde . En réponse à la dépêche Améliorer la disponibilité de ses services. Évalué à 7.
Ce n'est pas du tout conceptuel, ce sont deux choses totalement différentes, la répartition de charge et la gestion de la haute dispo. Connectées, mais différentes.
Côté répartition de charge, tu l'as expliqué, on a le round robbin, le least connection, bref un ensemble de techniques pour distribuer la charge plus ou moins justement sur un ensemble de serveurs, tous actifs.
Côté haute dispo, la virtual ip du service qui se balade du serveur actif au passif, la bascule d'une BDD avec linux ha (ou l'équivalent à la mode du moment), la redondance du stockage.
On fait plus souvent de la haute dispo sans répartition de charge, pour s'assurer la disponibilité d'une base de donnée par exemple. On met un mysql ou un postgresql en cluster actif/passif, et on bascule les clients (par modif de conf et arrêt/relance, ou par gestion de la couche client qui se connecter).
La répartition de charge sans haute dispo, google fait ça. Il faut du shared nothing sur des zilliards de serveur, ça monte très bien en charge, on peut rajouter des noeuds sans s'embêter. Et tant pis si le crash d'un serveur prive de service 0.1% des utilisateurs. Parce que c'est compliqué de faire de la haute dispo sur toute la chaine, c'est souvent plus simple, moins complexe à gérer, d'accepter une certaine perte de service pour une partie des utilisateurs.
Là dans la dépêche par exemple, on parle surtout faire du Load balancing / high availibility sur du service HTTP. Mais ça parle du serveur NFS pour stocker les sessions utilisateurs. Si le serveur NFS n'est pas là, tout le service est indisponible (en tout cas, le test de vie applicatif devrait échouer). Le maillon le plus faible conditionne la disponibilité de l'ensemble.
La répartition de charge sur des services autre que http, c'est moins courant par contre. Côté BDD relationnelle on a tendance à pas trop s'embêter avec ça, et si on veut pas de relationnel (ou qu'on peut s'en passer) il reste les quelques nosql prévus pour ça, comme Cassandra ou Couchdb.
Côté système de fichier, les rares qui gèrent ça (de ma faible expérience, j'en ai pas testé des masses) ont tendance à être compliqués à mettre en place, pour des perfs assez aléatoires.
On peut toujours mettre un test de vie et envoyer les utilisateurs vers un autre serveur, mais comme les serveurs ne partagent rien, l'utilisateur perd la session, et donc ce qu'il était en train de faire. La haute dispo du pauvre.
[^] # Re: Contournement de déficiences du Web
Posté par hermenegilde . En réponse à la dépêche Améliorer la disponibilité de ses services. Évalué à 10.
WTF. Tu as eu des cours de réseau quand tu étais jeune? Révise les.
La différence entre DNS, TCP et HTTP est quand même assez bien décrite un peu partout pour que les mécanismes soient clairs, bien définis et bien séparés. Le navigateur lie tout ça, mais la norme HTTP ne s'occupe pas de comment est ouverte la connexion, ni comment les noms sont résolus.
[^] # Re: Contournement de déficiences du Web
Posté par hermenegilde . En réponse à la dépêche Améliorer la disponibilité de ses services. Évalué à 6.
Non, les RFC HTTP ne spécifient pas la manière dont doit être résolu le nom du serveur. Donc l'utilisation du SRV est hors scope de la norme.
# Titre de l'article
Posté par hermenegilde . En réponse à la dépêche Améliorer la disponibilité de ses services. Évalué à 10.
Le titre est trompeur je trouve. C'est selon moi plus un article mode d'emploi sur LVS que sur la dispo des services.
Un article sur ces sujets est prévu Denis?
[^] # Re: Contournement de déficiences du Web
Posté par hermenegilde . En réponse à la dépêche Améliorer la disponibilité de ses services. Évalué à 4.
C'est utilisé par xmpp, ldap et sip, mais je vois pas en quoi c'est la faute de http si les navigateurs n'utilisent pas SRV pour les services Web. Des tickets ont pourtant été ouverts dans Mozilla et Chromium (et Webkit).
https://bugzilla.mozilla.org/show_bug.cgi?id=14328
https://code.google.com/p/chromium/issues/detail?id=22423
Que je n'ai pas lu, hein, donc je ne sais pas quel est l'avancement du sujet dans ces tickets.
De plus pour ce qui est de la "simplicité", c'est bien d'avoir un système comme le SRV pour la répartition et la haute dispo, mais faut toujours bien répliquer les données derrière les services et assurer ce service de bout en bout (la "haute dispo" smtp par champ MX, ça permet tout de même pas à l'utilisateur de lire le mail quand tu utilises un MX backup non relié à ton MDA).
[^] # Re: feature linuxfr
Posté par hermenegilde . En réponse à la dépêche Améliorer la disponibilité de ses services. Évalué à 1.
Ton navigateur doit avoir une fonctionnalité de bookmark. Le raccourci ctrl-d doit même être relativement courant pour bookmarker une page.
[^] # Re: Connu
Posté par hermenegilde . En réponse à l’entrée du suivi Page d'erreur lors de la recherche d'un terme. Évalué à 1 (+0/-0).
Ah bon? Ah mince, je m'en étais pas aperçu que j'avais fait un copier/coller de mon propre commentaire, merci!
[^] # Re: Connu
Posté par hermenegilde . En réponse à l’entrée du suivi Page d'erreur lors de la recherche d'un terme. Évalué à 3 (+0/-0).
« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos
[^] # Re: C'est possible
Posté par hermenegilde . En réponse à l’entrée du suivi robots.txt pour les outils d'archivage Web. Évalué à 4 (+0/-0).
Merci pour la réponse in extenso de ce qu'est la tribune, mais vu que je la cottoie un truc genre 10 ans, je connais. Et même si je suis d'accord avec la description, ça ne répond pas trop à la question.
Tu sembles dire que ça pose pas de problème à l'équipe si des bots d'archivage existe, sans vraiment le dire explicitement. C'est ainsi que je comprends
J'ai bon?
[^] # Re: Connu
Posté par hermenegilde . En réponse à l’entrée du suivi Page d'erreur lors de la recherche d'un terme. Évalué à 3 (+0/-0).
On sait bien que prévenir l'usager de dlfp est pas une habitude, mais un petit texte genre "la recherche est temporairement désactivée", ça serait bien quand même.
[^] # Re: Chère bombe fourchette, bomba fork à steack alias ... alias papatte3<,
Posté par hermenegilde . En réponse au journal De l'approche ultra-légère de la sécurité sur linuxfr. Évalué à 2.
Arf, je me souviens combien papatte3< m'avait vraiment faire ch**r là dessus à l'époque où j'avais commencé à faire Olccs. Je m'interroge encore sur sa motivation à refaire un truc d'archivage quand on a sorti tout ce qu'il m'avait sorti à ce moment là.
[^] # Re: C'est possible
Posté par hermenegilde . En réponse à l’entrée du suivi robots.txt pour les outils d'archivage Web. Évalué à 4 (+0/-0).
Alors en fait, je ne voulais pas savoir si un consensus existait ou si une RFC décrivait dans le détail les différentes interactions, mais quel était l'avis des admins. D'où je suis donc intéressé par avoir l'avis des administrateurs du site.
Par conséquent, je voulais savoir si dans l'esprit de la mise en place du robots.txt sur le site, ils comptaient également interdire les différents bots de tribune ou pas. Dont le tiens. Je me doute que de toutes façons, si tu as écris un bot, tu vas forcément penser qu'il a le droit d'aller sur la tribune.
[^] # Re: Chère bombe fourchette, bomba fork à steack alias ... alias papatte3<,
Posté par hermenegilde . En réponse au journal De l'approche ultra-légère de la sécurité sur linuxfr. Évalué à 2.
http://linuxfr.org/suivi/robots-txt-pour-les-outils-d-archivage-web
[^] # Re: Yakafokon
Posté par hermenegilde . En réponse au journal De l'approche ultra-légère de la sécurité sur linuxfr. Évalué à 3.
Ça veut pas dire qu'ils le stockent non chiffré, peut-être que l'algo est réversible, et qu'ils utilisent une clé dans l'appli.
Bon, ok, j'y crois moyen moi aussi, mais tu ne peux pas présumer d'un fonctionnement alors que tu n'en vois qu'un si petit morceau.
[^] # Re: Normal
Posté par hermenegilde . En réponse à l’entrée du suivi La recherche retourne systématiquement une erreur. Évalué à 5 (+0/-0).
On sait bien que prévenir l'usager de dlfp est pas une habitude, mais un petit texte genre "la recherche est temporairement désactivée", ça serait bien quand même.
[^] # Re: Problème trouvé \o/
Posté par hermenegilde . En réponse à l’entrée du suivi Lenteurs et problèmes d'accès. Évalué à -2 (+0/-0).
J'espère que l'expérience aura servi alors.
[^] # Re: Problème trouvé \o/
Posté par hermenegilde . En réponse à l’entrée du suivi Lenteurs et problèmes d'accès. Évalué à 2 (+0/-0).
Vous avez tout fermé SAUF le truc qui permet de trouer le luc de tout un serveur?
Une lecture de https://www.found.no/foundation/elasticsearch-security/ s'impose.
[^] # Re: Problème trouvé \o/
Posté par hermenegilde . En réponse à l’entrée du suivi Lenteurs et problèmes d'accès. Évalué à 0 (+0/-0).
Sans rire, vous avez laissé ouvert 2 services sans aucune sécurité à poil sur le net?
[^] # Re: Docker pour le bureau, est-ce le futur ?
Posté par hermenegilde . En réponse à la dépêche La folie Docker. Évalué à -5.
T'inquiètes pas, un mec qui dit utiliser Fedora qui tente de faire une réponse technique, ça donne ça.
[^] # Re: Ansible+Vagrant
Posté par hermenegilde . En réponse à la dépêche La folie Docker. Évalué à 1.
Vagrant peut utiliser docker: http://docs.vagrantup.com/v2/docker/index.html
Donc la différence est carrément moins fondamentale, du coup.
[^] # Re: Réparé
Posté par hermenegilde . En réponse à l’entrée du suivi Refresh du backend XML de la tribune. Évalué à 2 (+0/-0).
Le backend xml n'est rechargé que lors d'un post sur la tribune web, peut-être qu'un wants.xml vide devrait être présent dans le create? C'est peut-être ça qui empêche le after_action d'être lancé après un post avec un accept xml.
[^] # Re: Réparé
Posté par hermenegilde . En réponse à l’entrée du suivi Refresh du backend XML de la tribune. Évalué à 1 (+0/-0).
A priori, c'est raté, le bug est toujours là