Failover OVH

24 réponses

Page 1 2

Auteur	Message
Bool \| Modérateur Inscrit le : 09/05/2005	# Le 25/07/2008 à 14:10 Hello, sauriez vous à tout hasard si les "ip failover" d'OVH sont utilisables de manière automatique ? (via heartbeat, keepalived ou autres jouets du genre) J'espère que oui mais je voudrais en être certain avant de mettre en place un cluster chez eux. J'ai demandé au support mais si je pouvais avoir la réponse avant lundi ça m'arrangerait daevel : infogérance et conseil \|\| moi
devtribu \| Olivier Modérateur Inscrit le : 16/06/2005	# Le 25/07/2008 à 14:15 A priori l'api permet de gerer les failover http://www.ovh.com/soapi/fr/?group=dedicated Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 25/07/2008 à 14:19 J'ai eu la réponse d'OVH : (réponse rapide et pas à coté de la plaque pour une fois) Cela ce fait obligatoirement depuis le manager V3. Via l'API ça ne m'arrange pas trop non plus, mais au moins ça reste automatisable, merci. daevel : infogérance et conseil \|\| moi
devtribu \| Olivier Modérateur Inscrit le : 16/06/2005	# Le 25/07/2008 à 14:26 Tu t'interesses à OVH bool ? Pour un cluster, tu prevois quelle architecture ? Est-ce qu'il faut un doublon de la machine load balancer ? Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 25/07/2008 à 14:36 J'ai déjà plusieurs clients chez OVH oui, mais pas encore de cluster en fait. Pour le load balancer ce n'est pas obligatoire de le doubler non, ce n'est qu'une précaution supplémentaire. Mais en fait j'en profite pour faire du round robin sur 2 IP "fail over", comme ça le trafic est réparti sur les 2 load balancer (ça évite d'avoir une machine qui glande 95% du temps). daevel : infogérance et conseil \|\| moi
krucial \| Jean Christophe Administrateur Inscrit le : 09/03/2005	# Le 25/07/2008 à 16:37 Devtribu : perso, j'ai monté un LB chez OVH. Chaque machine est conf comme un LB. Juste un fichier de conf sur le serveur le declare en primaire ou esclave. Avec l'IP du failover conf sur toutes les machines aussi. Si la machine primaire crash, je passe l'IP failover sur une seconde, je touche un fichier de conf, et c reparti. Mais c pas automatique. JC - Mes sites \| Affiliation devis travaux \| Cotes voitures anciennes
devtribu \| Olivier Modérateur Inscrit le : 16/06/2005	# Le 25/07/2008 à 16:47 Faut prevoir quoi comme machine pour le LB ? A priori, pas besoin d'une puissance enorme non ? La solution du round robin me parait pas mal du tout Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 25/07/2008 à 16:50 Tout dépend de ce que tu veux lui faire faire Pour un simple load balancer de type "ipvs", le premier kimsufi suffit amplement. Mais si la machine gère le keepalived http, la compression à la volée et la distribution des fichiers statiques, une machine un peu plus véloce peut être préférable. daevel : infogérance et conseil \|\| moi
caaptusss \| Jérémy Membre Inscrit le : 25/09/2007	# Le 25/07/2008 à 17:54 C'est dans ces cas là ou je suis heureux d'avoir une architecture du type P2P non redondant. Chaque serveur est totalement indépendant des autres ce qui confère une tolérance de panne au réseau. Mettez quelques machines dotés de plusieurs Terra, et faites un backup automatique et votre architecture ne coute que 25 % du prix que celle d'un ovh like, pour la même qualité (en terme de timing), mais un peux moins fiable (donc pas de SLA), du genre, 90-95 % de dispo au lieu des 99 % habituels. Je préserve la majorité des clients pour en sacrifier une partie en fait (plutôt que de tout sacrifier si j'utilisais des filer qui me couterais une fortune... quand je vois comment OVH galère déjà avec les leurs). Mais on est d'accord, ce type d'architecture ne conviens absolument pas à un site ne pouvant pas tenir sur un seul serveur pour des raisons de capacités de charge ou de redondance. FirstHeberg.com
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 25/07/2008 à 18:04 Ni pour un site qui perd quelques milliers d'euros par heure de coupure. daevel : infogérance et conseil \|\| moi
devtribu \| Olivier Modérateur Inscrit le : 16/06/2005	# Le 25/07/2008 à 18:06 Pour le moment, le cluster n'est pas obligatoire chez moi. Je travaille sur la sécurisation/synchronisation et les ipfail over pour envoyer sur un serveur de secours en cas de mort subite par noyade du serveur (ce qui arrive chez ovh) caaptus> 90% de disponibilité, t'es sur ? Ca fait plus de 3 jours de panne par mois... Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 25/07/2008 à 18:17 Pour donner un ordre d'idée, à partir d'un petit core2duo : load average: 0.03, 0.02, 0.00 Cpu(s): 0.0%us, 0.2%sy, 0.0%ni, 98.7%id, 0.3%wa, 0.2%hi, 0.7%si, 0.0%st Et consommation mémoire de 20Mo. C'est la charge actuelle d'un load balancer qui va faire environ 5 Millions de hits aujourd'hui (+1 Million envoyés vers les backends) ; et qui fait aussi office de serveur memcached. Bref, coté perfs y a de la marge. daevel : infogérance et conseil \|\| moi
devtribu \| Olivier Modérateur Inscrit le : 16/06/2005	# Le 25/07/2008 à 18:18 Il hiberne ton serveur ! Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 25/07/2008 à 18:23 C'est un peu ça oui. Et comme il se charge de tout ce qui emmerde Apache, les nodes web sont un peu dans le même état. daevel : infogérance et conseil \|\| moi
caaptusss \| Jérémy Membre Inscrit le : 25/09/2007	# Le 25/07/2008 à 18:49 devtribu a dit : caaptus> 90% de disponibilité, t'es sur ? Ca fait plus de 3 jours de panne par mois... Désolé pour la longueur du message C'est le rapport hebdo de la semaine dernière. Sachant qu'on a une sacré croissances depuis quelques semaines, les serveurs ne sont pas en hibernation chez nous Application Mail: (http://mail.freeheberg.com ) % up : 99,98% % down : 0,02% durée en erreur : 2 minutes durée sans erreur : 6 jours 23 heures 58 minutes temps de réponse moyen : 0,693 seconde temps de réponse le plus bas : 0,086 seconde temps de réponse le plus haut : 9,406 secondes nombre de vérifications : 171 nombre de succès : 169 nombre d'erreurs : 2 date de début : 18/07/2008 00:00:00 date de fin : 24/07/2008 23:59:59 application NS0: (http://ns0.freeheberg.com/~freehebe/home/ ) % up : 99,98% % down : 0,02% durée en erreur : 2 minutes durée sans erreur : 6 jours 23 heures 58 minutes temps de réponse moyen : 0,335 seconde temps de réponse le plus bas : 0,087 seconde temps de réponse le plus haut : 1,279 seconde nombre de vérifications : 173 nombre de succès : 171 nombre d'erreurs : 2 date de début : 18/07/2008 00:00:00 date de fin : 24/07/2008 23:59:59 application NS2: (http://ns2.freeheberg.com/test.php ) % up : 100% % down : 0% durée en erreur : 0 seconde durée sans erreur : 7 jours temps de réponse moyen : 0,391 seconde temps de réponse le plus bas : 0,097 seconde temps de réponse le plus haut : 5,854 secondes nombre de vérifications : 168 nombre de succès : 168 nombre d'erreurs : 0 date de début : 18/07/2008 00:00:00 date de fin : 24/07/2008 23:59:59 application NS3: (http://ns3.freeheberg.com/test.php ) % up : 100% % down : 0% durée en erreur : 0 seconde durée sans erreur : 7 jours temps de réponse moyen : 0,343 seconde temps de réponse le plus bas : 0,113 seconde temps de réponse le plus haut : 3,152 secondes nombre de vérifications : 168 nombre de succès : 168 nombre d'erreurs : 0 date de début : 18/07/2008 00:00:00 date de fin : 24/07/2008 23:59:59 application NS4: (http://ns4.freeheberg.com/test.php ) % up : 100% % down : 0% durée en erreur : 0 seconde durée sans erreur : 7 jours temps de réponse moyen : 0,418 seconde temps de réponse le plus bas : 0,117 seconde temps de réponse le plus haut : 4,367 secondes nombre de vérifications : 169 nombre de succès : 169 nombre d'erreurs : 0 date de début : 18/07/2008 00:00:00 date de fin : 24/07/2008 23:59:59 application NS5: (http://ns5.freeheberg.com/test.php ) % up : 99,98% % down : 0,02% durée en erreur : 2 minutes durée sans erreur : 6 jours 23 heures 58 minutes temps de réponse moyen : 0,414 seconde temps de réponse le plus bas : 0,140 seconde temps de réponse le plus haut : 10,680 secondes nombre de vérifications : 171 nombre de succès : 169 nombre d'erreurs : 2 date de début : 18/07/2008 00:00:00 date de fin : 24/07/2008 23:59:59 application NS6: (http://ns6.freeheberg.com/test.php ) % up : 99,375% % down : 0,625% durée en erreur : 1 heure 3 minutes durée sans erreur : 6 jours 22 heures 57 minutes temps de réponse moyen : 0,601 seconde temps de réponse le plus bas : 0,074 seconde temps de réponse le plus haut : 23,888 secondes nombre de vérifications : 233 nombre de succès : 170 nombre d'erreurs : 63 date de début : 18/07/2008 00:00:00 date de fin : 24/07/2008 23:59:59 application POP: (pop3.freeheberg.com sur le port 110) % up : 97,584% % down : 2,416% durée en erreur : 4 heures 3 minutes 30 secondes durée sans erreur : 6 jours 19 heures 56 minutes 30 secondes temps de réponse moyen : 0,335 seconde temps de réponse le plus bas : 0,049 seconde temps de réponse le plus haut : 5,857 secondes nombre de vérifications : 408 nombre de succès : 165 nombre d'erreurs : 243 date de début : 18/07/2008 00:00:00 date de fin : 24/07/2008 23:59:59 application SMTP: (smtp.freeheberg.com sur le port 25) % up : 99,177% % down : 0,823% durée en erreur : 1 heure 23 minutes durée sans erreur : 6 jours 22 heures 37 minutes temps de réponse moyen : 0,692 seconde temps de réponse le plus bas : 0,009 seconde temps de réponse le plus haut : 28,786 secondes nombre de vérifications : 257 nombre de succès : 174 nombre d'erreurs : 83 date de début : 18/07/2008 00:00:00 date de fin : 24/07/2008 23:59:59 FirstHeberg.com
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 25/07/2008 à 19:02 dob a dit : C'est un load balancer Apache ou c'est au niveau tcp ? Load balancer HTTP. Mais les infras comme ça que j'ai ont toutes leur propre switch (gigabit pour la plupart). Pas encore testé chez OVH... je ne sais donc pas si leur réseau a un fort impact ou non. nombre de vérifications : 171 Tu ne contrôles qu'une fois par heure ? daevel : infogérance et conseil \|\| moi
caaptusss \| Jérémy Membre Inscrit le : 25/09/2007	# Le 25/07/2008 à 19:06 oui, avant je contrôlais toutes les 20 mn mais avec la multiplication des serveurs, et vu la stabilité du réseau, j'suis passé à 1 heure, ça coute vraiment moins cher et globalement, j'ai pas vu de différence sur les résultats. FirstHeberg.com
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 25/07/2008 à 19:15 C'est bien un commercial tiens ;) daevel : infogérance et conseil \|\| moi
caaptusss \| Jérémy Membre Inscrit le : 25/09/2007	# Le 25/07/2008 à 19:27 dob a dit : Comment tu peux dire 2 minutes de down si tu check une fois par heure ?? En cas d'erreur constaté, ils rechecke toutes les 30 secondes... FirstHeberg.com
Julgates \| Julien Administrateur Inscrit le : 09/03/2005	# Le 25/07/2008 à 20:01 Ouais donc si ça se trouve ça fait 59 minutes + 2 Shopping Time Network - Founder / CTO

Auteur

Message

Bool |
Modérateur

Inscrit le : 09/05/2005

# Le 25/07/2008 à 14:10

Hello,

sauriez vous à tout hasard si les "ip failover" d'OVH sont utilisables de manière automatique ? (via heartbeat, keepalived ou autres jouets du genre)

J'espère que oui mais je voudrais en être certain avant de mettre en place un cluster chez eux.
J'ai demandé au support mais si je pouvais avoir la réponse avant lundi ça m'arrangerait

daevel : infogérance et conseil || moi

devtribu | Olivier
Modérateur

Inscrit le : 16/06/2005

# Le 25/07/2008 à 14:15

A priori l'api permet de gerer les failover

http://www.ovh.com/soapi/fr/?group=dedicated

Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 25/07/2008 à 14:19

J'ai eu la réponse d'OVH : (réponse rapide et pas à coté de la plaque pour une fois)

Cela ce fait obligatoirement depuis le manager V3.

Via l'API ça ne m'arrange pas trop non plus, mais au moins ça reste automatisable, merci.

daevel : infogérance et conseil || moi

devtribu | Olivier
Modérateur

Inscrit le : 16/06/2005

# Le 25/07/2008 à 14:26

Tu t'interesses à OVH bool ?

Pour un cluster, tu prevois quelle architecture ?
Est-ce qu'il faut un doublon de la machine load balancer ?

Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 25/07/2008 à 14:36

J'ai déjà plusieurs clients chez OVH oui, mais pas encore de cluster en fait.

Pour le load balancer ce n'est pas obligatoire de le doubler non, ce n'est qu'une précaution supplémentaire.
Mais en fait j'en profite pour faire du round robin sur 2 IP "fail over", comme ça le trafic est réparti sur les 2 load balancer (ça évite d'avoir une machine qui glande 95% du temps).

daevel : infogérance et conseil || moi

krucial | Jean Christophe
Administrateur

Inscrit le : 09/03/2005

# Le 25/07/2008 à 16:37

Devtribu : perso, j'ai monté un LB chez OVH. Chaque machine est conf comme un LB. Juste un fichier de conf sur le serveur le declare en primaire ou esclave. Avec l'IP du failover conf sur toutes les machines aussi. Si la machine primaire crash, je passe l'IP failover sur une seconde, je touche un fichier de conf, et c reparti. Mais c pas automatique.

JC - Mes sites | Affiliation devis travaux | Cotes voitures anciennes

devtribu | Olivier
Modérateur

Inscrit le : 16/06/2005

# Le 25/07/2008 à 16:47

Faut prevoir quoi comme machine pour le LB ? A priori, pas besoin d'une puissance enorme non ?

La solution du round robin me parait pas mal du tout

Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 25/07/2008 à 16:50

Tout dépend de ce que tu veux lui faire faire Pour un simple load balancer de type "ipvs", le premier kimsufi suffit amplement.

Mais si la machine gère le keepalived http, la compression à la volée et la distribution des fichiers statiques, une machine un peu plus véloce peut être préférable.

daevel : infogérance et conseil || moi

caaptusss | Jérémy
Membre

Inscrit le : 25/09/2007

# Le 25/07/2008 à 17:54

C'est dans ces cas là ou je suis heureux d'avoir une architecture du type P2P non redondant.
Chaque serveur est totalement indépendant des autres ce qui confère une tolérance de panne au réseau.

Mettez quelques machines dotés de plusieurs Terra, et faites un backup automatique et votre architecture ne coute que 25 % du prix que celle d'un ovh like, pour la même qualité (en terme de timing), mais un peux moins fiable (donc pas de SLA), du genre, 90-95 % de dispo au lieu des 99 % habituels.

Je préserve la majorité des clients pour en sacrifier une partie en fait (plutôt que de tout sacrifier si j'utilisais des filer qui me couterais une fortune... quand je vois comment OVH galère déjà avec les leurs).

Mais on est d'accord, ce type d'architecture ne conviens absolument pas à un site ne pouvant pas tenir sur un seul serveur pour des raisons de capacités de charge ou de redondance.

FirstHeberg.com

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 25/07/2008 à 18:04

Ni pour un site qui perd quelques milliers d'euros par heure de coupure.

daevel : infogérance et conseil || moi

devtribu | Olivier
Modérateur

Inscrit le : 16/06/2005

# Le 25/07/2008 à 18:06

Pour le moment, le cluster n'est pas obligatoire chez moi.
Je travaille sur la sécurisation/synchronisation et les ipfail over pour envoyer sur un serveur de secours en cas de mort subite par noyade du serveur (ce qui arrive chez ovh)

caaptus> 90% de disponibilité, t'es sur ?
Ca fait plus de 3 jours de panne par mois...

Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 25/07/2008 à 18:17

Pour donner un ordre d'idée, à partir d'un petit core2duo :

load average: 0.03, 0.02, 0.00

Cpu(s):  0.0%us,  0.2%sy,  0.0%ni, 98.7%id,  0.3%wa,  0.2%hi,  0.7%si,  0.0%st

Et consommation mémoire de 20Mo.

C'est la charge actuelle d'un load balancer qui va faire environ 5 Millions de hits aujourd'hui (+1 Million envoyés vers les backends) ; et qui fait aussi office de serveur memcached.
Bref, coté perfs y a de la marge.

daevel : infogérance et conseil || moi

devtribu | Olivier
Modérateur

Inscrit le : 16/06/2005

# Le 25/07/2008 à 18:18

Il hiberne ton serveur !

Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 25/07/2008 à 18:23

C'est un peu ça oui. Et comme il se charge de tout ce qui emmerde Apache, les nodes web sont un peu dans le même état.

daevel : infogérance et conseil || moi

caaptusss | Jérémy
Membre

Inscrit le : 25/09/2007

# Le 25/07/2008 à 18:49

devtribu a dit :
caaptus> 90% de disponibilité, t'es sur ?
Ca fait plus de 3 jours de panne par mois...

Désolé pour la longueur du message

C'est le rapport hebdo de la semaine dernière. Sachant qu'on a une sacré croissances depuis quelques semaines, les serveurs ne sont pas en hibernation chez nous

Application Mail: (http://mail.freeheberg.com

)

% up : 99,98%
% down : 0,02%
durée en erreur : 2 minutes
durée sans erreur : 6 jours 23 heures 58 minutes
temps de réponse moyen : 0,693 seconde
temps de réponse le plus bas : 0,086 seconde
temps de réponse le plus haut : 9,406 secondes
nombre de vérifications : 171
nombre de succès : 169
nombre d'erreurs : 2
date de début : 18/07/2008 00:00:00
date de fin : 24/07/2008 23:59:59

application NS0: (http://ns0.freeheberg.com/~freehebe/home/

)

% up : 99,98%
% down : 0,02%
durée en erreur : 2 minutes
durée sans erreur : 6 jours 23 heures 58 minutes
temps de réponse moyen : 0,335 seconde
temps de réponse le plus bas : 0,087 seconde
temps de réponse le plus haut : 1,279 seconde
nombre de vérifications : 173
nombre de succès : 171
nombre d'erreurs : 2
date de début : 18/07/2008 00:00:00
date de fin : 24/07/2008 23:59:59

application NS2: (http://ns2.freeheberg.com/test.php

)

% up : 100%
% down : 0%
durée en erreur : 0 seconde
durée sans erreur : 7 jours
temps de réponse moyen : 0,391 seconde
temps de réponse le plus bas : 0,097 seconde
temps de réponse le plus haut : 5,854 secondes
nombre de vérifications : 168
nombre de succès : 168
nombre d'erreurs : 0
date de début : 18/07/2008 00:00:00
date de fin : 24/07/2008 23:59:59

application NS3: (http://ns3.freeheberg.com/test.php

)

% up : 100%
% down : 0%
durée en erreur : 0 seconde
durée sans erreur : 7 jours
temps de réponse moyen : 0,343 seconde
temps de réponse le plus bas : 0,113 seconde
temps de réponse le plus haut : 3,152 secondes
nombre de vérifications : 168
nombre de succès : 168
nombre d'erreurs : 0
date de début : 18/07/2008 00:00:00
date de fin : 24/07/2008 23:59:59

application NS4: (http://ns4.freeheberg.com/test.php

)

% up : 100%
% down : 0%
durée en erreur : 0 seconde
durée sans erreur : 7 jours
temps de réponse moyen : 0,418 seconde
temps de réponse le plus bas : 0,117 seconde
temps de réponse le plus haut : 4,367 secondes
nombre de vérifications : 169
nombre de succès : 169
nombre d'erreurs : 0
date de début : 18/07/2008 00:00:00
date de fin : 24/07/2008 23:59:59

application NS5: (http://ns5.freeheberg.com/test.php

)

% up : 99,98%
% down : 0,02%
durée en erreur : 2 minutes
durée sans erreur : 6 jours 23 heures 58 minutes
temps de réponse moyen : 0,414 seconde
temps de réponse le plus bas : 0,140 seconde
temps de réponse le plus haut : 10,680 secondes
nombre de vérifications : 171
nombre de succès : 169
nombre d'erreurs : 2
date de début : 18/07/2008 00:00:00
date de fin : 24/07/2008 23:59:59

application NS6: (http://ns6.freeheberg.com/test.php

)

% up : 99,375%
% down : 0,625%
durée en erreur : 1 heure 3 minutes
durée sans erreur : 6 jours 22 heures 57 minutes
temps de réponse moyen : 0,601 seconde
temps de réponse le plus bas : 0,074 seconde
temps de réponse le plus haut : 23,888 secondes
nombre de vérifications : 233
nombre de succès : 170
nombre d'erreurs : 63
date de début : 18/07/2008 00:00:00
date de fin : 24/07/2008 23:59:59

application POP: (pop3.freeheberg.com sur le port 110)

% up : 97,584%
% down : 2,416%
durée en erreur : 4 heures 3 minutes 30 secondes
durée sans erreur : 6 jours 19 heures 56 minutes 30 secondes
temps de réponse moyen : 0,335 seconde
temps de réponse le plus bas : 0,049 seconde
temps de réponse le plus haut : 5,857 secondes
nombre de vérifications : 408
nombre de succès : 165
nombre d'erreurs : 243
date de début : 18/07/2008 00:00:00
date de fin : 24/07/2008 23:59:59

application SMTP: (smtp.freeheberg.com sur le port 25)

% up : 99,177%
% down : 0,823%
durée en erreur : 1 heure 23 minutes
durée sans erreur : 6 jours 22 heures 37 minutes
temps de réponse moyen : 0,692 seconde
temps de réponse le plus bas : 0,009 seconde
temps de réponse le plus haut : 28,786 secondes
nombre de vérifications : 257
nombre de succès : 174
nombre d'erreurs : 83
date de début : 18/07/2008 00:00:00
date de fin : 24/07/2008 23:59:59

FirstHeberg.com

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 25/07/2008 à 19:02

dob a dit :
C'est un load balancer Apache ou c'est au niveau tcp ?

Load balancer HTTP. Mais les infras comme ça que j'ai ont toutes leur propre switch (gigabit pour la plupart).
Pas encore testé chez OVH... je ne sais donc pas si leur réseau a un fort impact ou non.

nombre de vérifications : 171

Tu ne contrôles qu'une fois par heure ?

daevel : infogérance et conseil || moi

caaptusss | Jérémy
Membre

Inscrit le : 25/09/2007

# Le 25/07/2008 à 19:06

oui, avant je contrôlais toutes les 20 mn mais avec la multiplication des serveurs, et vu la stabilité du réseau, j'suis passé à 1 heure, ça coute vraiment moins cher et globalement, j'ai pas vu de différence sur les résultats.

FirstHeberg.com

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 25/07/2008 à 19:15

C'est bien un commercial tiens ;)

daevel : infogérance et conseil || moi

caaptusss | Jérémy
Membre

Inscrit le : 25/09/2007

# Le 25/07/2008 à 19:27

dob a dit :
Comment tu peux dire 2 minutes de down si tu check une fois par heure ??

En cas d'erreur constaté, ils rechecke toutes les 30 secondes...

FirstHeberg.com