Version imprimable
bonjour tous le monde;
je ss intéressé par la solution FOS avec heartbeat. la solution est en marche en ce moment, j'utilise asterisk 1.4 sous debian et heartbeat .... le soucis :
est que je veut basculer vers le serveur esclave quand asterisk crash ... alors que heartbeat ne bascule pas vers le serveur esclave que lors d'un crash du serveur master c.a.d quant le serveur master soit injoignable.
s'il ya une solution je serai tres reconnaissent .. merci d'avance :jap:
Pour vous aider dans le raisonnement, définissez ce qu'est un "crash Asterisk" :wink:
merci ffossard;Citation:
Envoyé par ffossard
un cas pratique, on a mis un call-center sous asterisk avec une machine un peu limité en terme de ressources (a mon avis ) et vue la charge ( le nbre d'appels ) s'arrivent souvent qu'asterisk ne fait pas passer les appels au agents donc du coup asterisk est en marche mais les appels ne passe pas !!!!
1- donc est ce que c'est possible de vérifier si asterisk en bonne fonctionnement ????
2- si vous avez une approche sur le type de crash asterisk je serai tres reconnaissons pour poncer au solutions plus pratique :)
merci d'avance
Quand vous parlez de charge, vous parlez de combien d'appels simultanés ?
Et sur quel type de machine ? (processeur, RAM ?)
a propos de la charge pour l'instant on fait les testes avec 2 agents cad 2 appels simultané mais apres serons 6 agents ou 8 tous dépend
et pour la machine on utilise une PIKA warp avec :
1-AMCC Power PC 440EP Embedded 533 MHz Processor 1200 mips
2-RAM 256 MB
3-Internal flash 256 MB
donc du coup je me doute si c'est un problème matériel.
8 coms simultanés c'est pas énorme, mais c'est vrai que niveau hadware, c'est pas non plus énorme..
Avez-vous regardé la console pour voir ce qui se passait lorsqu'un appel échoue :
asterisk -r -vvvvvvvvv
merci therebel23;
oui tous dépend du probleme une fois y'avait un probléme de scripte qui ne s'exécute pas .... et une autre fois y'avait le un crond qui boucle... :-)
ce que je veut c'est de mettre un asterisk HA ... donc si vous avez une idée sur les type de bug qui pourront survenir je serai trés reconnaissons ....:wink:
appart ça .... pour moi ça marche avec heartbeat dans le cas ou le asterisk master est injoignable .
merci
C'est à cause de la diversité des problèmes qu'il n'est pas possible de solutionner ça avec de la haute dispo, le système a besoin d'un indicateur précis et mesurable pour déterminer quand il doit basculer sur le serveur de secours.Citation:
Envoyé par mus
Vu le type de problème, il peut aussi y'avoir le même type de problème sur le deuxième serveur, donc aucun intérêt.
Par rapport à la charge, quelle est la distribution utilisée ? (je ne me fais pas trop de soucis pour le processeur, par contre 256Mo de ram, en 2011 ça peut être trop faible si ça n'est pas une distribution légère et optimisée pour votre architecture matérielle)
Concernant l'indicateur dont parle ffossard, j'ai réflechi la question,
et j'en ai isolé un que me convient me concernant :
depuis le spare, vérifier :
1) que l'envoi d'une requête SIP au serveur de prod obtient une réponse (ACK) dans un temps correct. Si pas de ACK, réessayer X fois avant de prendre l'IP publique du prod..
Oui c'est pas mal, finalement plus la requête est de haut niveau, plus elle a de chances de détecter un mauvais fonctionnement.
Citation:
Envoyé par ffossard
pour la distribution j'utilise 2 machines virtuelles avec debian 5 et asterisk 1.4 pour les testes, en parallèle ce qui en production :
un module Pika warp avec un système embarqué conçu pour la TOIP
http://www.pikatechnologies.com/english/view.asp?x=347
merci ffossard.
c'est une bonne idée therebel23 pourriez vous me guidé un peu ou m'éclaircir un peu la voie :ouimaitre:Citation:
Envoyé par therebel23
SVP c'est quoi le spare .???
merci d'avance
Attention avec les machines virtuelles, c'est plus sensible aux problèmes de charges (et ça n'a pas grand chose à voir avec le dimensionnement processeur/mémoire)Citation:
Envoyé par mus
Ok pour le Pikawarp, la distribution est spécialisée ("juste le nécessaire" et optimisation pour l'architecture matérielle de l'appliance utilisée), aucun problème de charge avec moins de dix personnes.