Clusterlösung mit Asterisk-Servern

rowitech

Neuer User
Mitglied seit
30 Sep 2004
Beiträge
115
Punkte für Reaktionen
0
Punkte
0
Hallo,

ich möchte eine Asterisk-Clusterlösung entwickeln. Vielfach wird der Begriff Cluster mit einer HA-Lösung gleichgesetzt, doch das ist nicht mein direktes Ziel.

Bei einer Clusterlösung (Bildlich von Asterisk01 bis Asterisk 08) darf sich ein Endgerät an einem beliebigen Asterisk anmelden. Wenn sich aber ein User A and Asterisk02 anmeldet und eine User B an Asterisk08, so sollten auch diese untereinander ohne Kenntnis des Anmeldeservers untereinander telefonieren können. Um einen echten Cluster zu haben, möchte ich keinen Haupt-Asterisk verwenden, alle Systeme sollen gleichberechtigt sein.

Wenn sich ein Endgerät anmeldet, soll diese Anmeldeprozedur von Asterisk, einem AGI oder wie auch immer, bemerkt und in meine (replizierte) MySQL-Datenbank eingepflegt werden, so dass ich dort lieschenmueller@asterisk02 habe (oder einfach asterisk02 in einem Feld).

Habe ich die Information des "Aufenthaltsortes" (welcher Asterisk das ist), kann ich die Gespräche mit einem Dial.. @${meinasterisk} dort hin leiten.

Im Prinzip bin ich dann völlig frei: Ein Nutzer könnte sich dann auf seinem eigenen Asterisk anmelden, der dann ggfs. wieder Teil des Verbunds werden könnte. Nutzer, die nicht im Cluster angemeldet sind, würden dann z:b. anhand der Vorwahl ins Festnetz oder zu anderen SIP/IAX/...-Carriern geroutet.

Liege ich mit meiner Idee falsch?

Zur möglichen Frage, warum ich keinen SER nehme:
Ein reiner Asterisk lässt sich viel einfacher handhaben (auch im Cluster) als die Vermittlung durch einen SER. Wenn es nicht mehr um reine Telefoni e als Hauptziel geht, wird es schwer, die Last aus dem Asterisk zu nehmen.
Doch dazu möchte ich einen weiteren Thread aufmachen, um das Thema nicht zu vermischen.

Gruß
Rolf
 
Hm, sollte es nicht gehen wenn man Asterisk mit Realtime aufsetzt, dann einen extra MySQL Server, auf dem die von allen Asterisk zu verwendende Datenbank liegt? Ein "Dial(SIP/XXXX)" sollte dann von jedem Asterisk gehen, denn alle wissen durch die Datenbank, welche "Adresse" der SIP Client hat. Oder liege ich daneben?
 
speedy1980 schrieb:
Hm, sollte es nicht gehen wenn man Asterisk mit Realtime aufsetzt, dann einen extra MySQL Server, auf dem die von allen Asterisk zu verwendende Datenbank liegt? Ein "Dial(SIP/XXXX)" sollte dann von jedem Asterisk gehen, denn alle wissen durch die Datenbank, welche "Adresse" der SIP Client hat. Oder liege ich daneben?

Ich fürchte, du liegst falsch, denn wenn sich z.B. die 101 an asterisk01 und die 102 an asterisk02 anmeldet, dann muss der Dial per
Dial(SIP/102@asterisk02)
durchgeführt werden.

Aber das kann ja ein AGI-Script übernehmen (das zusammenbasteln des Dialstrings).

Blöd nur, dass Asterisk nicht in eine MySQL-DB die angemeldeten User loggt. Aber da kann der OP ja gewiss das dazugehörige Modul, oder ein Addon zu schreiben. Dann wird halt nicht in die astdb geschrieben, sondern in eine MySQL-DB (oder gibt es da schon ein Modul zu?)

Vielleicht geht auch ein Konstrukt der Art
Dial(SIP/102@asterisk01&SIP/102@asterisk02&...)

Gruss,
Sancho
 
Sancho schrieb:
Blöd nur, dass Asterisk nicht in eine MySQL-DB die angemeldeten User loggt. Aber da kann der OP ja gewiss das dazugehörige Modul, oder ein Addon zu schreiben. Dann wird halt nicht in die astdb geschrieben, sondern in eine MySQL-DB (oder gibt es da schon ein Modul zu?)

Also ich nutze kein Realtime, sondern ast_data. Da hab ich die SIP-User auch in einer MySQL Datenbank. Dort gibts Felder wie "fullcontact" (SIP-URI), useragent, port, ipadress, regseconds. Meldet ein SIP-Client sich an, so werden die Felder aktualisiert. In ähnlicher Form gibts die auch bei Realtime. Da kann man doch sicher was mit anfangen ...
Ansonsten hast Du Recht, man müßte die Registrierungen in die astdb umleiten und zentral halten. Bist Du mit dem Anliegen schon auf einer Asterisk Mailingliste aktiv geworden? Vielleicht kann da ein Entwickler weiterhelfen.
 
Hallo zusammen,

>Vielleicht geht auch ein Konstrukt der Art
>Dial(SIP/102@asterisk01&SIP/102@asterisk02&...)

nee, das gefällt mir nicht so, da man ja für 7 von 8 Servern einen Fehler produzieren würde, gehen würde das wohl, aber eben nicht so sauber, wie ich das gern hätte.

Um den Realtime-Mode kommen wir eh nicht drumherum, allerdings ist mir bislang nicht bewusst, dass die bloße Anmeldung schon in die DB geschrieben werden kann. Wo wird das eingestellt?

Und auch wenn kein Relatime-Mode vorliegt: Wo lässt sich das einstellen, dass die Anmeldedaten in eine MySQL geschrieben werden? Das würde ja schon den Knoten lösen!

Gruß
Rolf
 
Hallo Rolf,


ein Ansatz für Deine Aufgabenstellung währe auch folgender:

Code:
+------------------------+
|table clientsession     |
+------+------+----------+
|client|clust*| ip       |
+------+------+----------+
|101   | *01  | 10.0.0.1 |
|102   | *02  | 10.0.0.2 |
|103   | *03  | 10.0.0.3 |
|104   | *01  | 10.0.0.1 |
+------+------+----------+


table clusterasterisk
---+-----+--------+--------+--------+
id |name |username|password| context|
---+-----+--------+--------+--------+
01 | *01 | user01 | pass01 | dialin |
02 | *02 | user02 | pass02 | dialin |
03 | *03 | user03 | pass03 | dialin |

Code:
extensions.conf *01
===================

[dialout]
exten=>_1XX,1,Wait(1)
exten=>_1XX,2,AGI(remote.py)                                 ; AGI-Skript zur DB-Auswertung
     =>AGI: SET VARIABLE REMOTE IAX2/user02:[email protected]       ; Verbindung zu Cluster*02
     =>AGI: SET VARIABLE REMOTECONTEXT dialin                     ; Cluster*02 Kontext
exten=>_1XX,3,Dial(${REMOTE}/${EXTEN}@${REMOTECONTEXT})      ; Clientverbindung auf Cluster*02

Wenn also das Problem der zentralen Client-Registrierung in einer DB gelöst ist, müsste das ganze so klappen.

@Rolf: Eine zentrale DB zur Clientverwaltung ist ja schön und gut, aber sollte die ausfallen, kann der ganze *Cluster nicht mehr telefonieren. Seh ich das richtig, dass Du das ganze eher auf einem "grossen" Host mit mehreren (virtuellen) Servern machen möchtest (loadbalancing?). Dann könnte das ganze natürlich mehr Sinn machen...

Gruss Tabellar
 
hmm, wäre ein einzellner asterisk der sich rechenpower über ein Grid besorgt nicht die eleganteste Lösung? Hab zwar null ahnung von Grid Computing, aber das wäre ne´feine Sache.
 
Hallo zusammen,

@Tabellar: Deine Lösung, wenn ich sie recht erkenne, würde mit jemden ausgehenden Telefonat ein AGI aufrufen, das die Position speichert. Der Abruf aus der DB per AGI sollte ja nicht das Problem sein, doch sollte auch ohne Aktion, d.h. abgehende Telefonate gleich bei der Registrierung, also beim Einstöpseln des Telefons, ein Eintrag in der Datenbank erfolgen.

@all:

Bei der Clusterlösung darf ein belibiger Rechner ausfallen und alles läuft wie gehabt weiter. Die Datenbank ist natürlich repliziert, d.h. es gibt mehrere Server, die sich ständig gegenseitig abgleichen (-> MySQL Replication). Somit ist auch die DB kein single Point of Failure. Ein einzelner großer Rechner macht auch keinen Sinn, denn was hilfts, wenn dort etwas passiert? Das Gesamtsystem soll immer weiterlaufen, auch wenn einzelne System ausfallen. 100% kann man natürlich nie sicher sein, aber das ist auch nicht das Ziel des Ganzen.

Nochmal zu meiner Frage:
Ich suche nach wie vor nach einer Lösung, wie ich eine reine Anmeldung eines Telefons (keine Aktion des Users, nur "Einstöpseln") in eine Datenbank schreiben kann. AGI scheidet aus, da ich ja keine Aktion habe, d.h. der User wählt nicht, er hebt den Horer nicht ab, er führt kein SIP-Gespräch.

Gruß
Rolf
 
@Rolf:
Im Prinzip muss auf dem jeweiligen *ClusterServer ein Programm laufen, das die entsprechenden Events vom * abfängt. Registriert sich ein neuer Client(Einstöpseln) wird ein neues Event geliefert und somit kann der "EventDeamon" die Daten an die zentrale DB liefern.

Ich bin ja neu in der *-Welt, aber im Moment probiere ich gerade diese Events mit der Mangager API zu bekommen, hab da aber im Moment noch so meine Probleme (Socket error, broken pipe...).

Ansonsten interessiert mich das Thema auch...

Tabellar
 
Und auch wenn kein Relatime-Mode vorliegt: Wo lässt sich das einstellen, dass die Anmeldedaten in eine MySQL geschrieben werden? Das würde ja schon den Knoten lösen!

Wenn man Asterisk(1.0.6) mit MYSQL_FRIENDS kompiliert, wird normalerweise bei jeder Client-Anmeldung der dazu gehörige Datensatz in MySQL aktualisiert. Dann kannst du z.B. die IP-Adresse und Port von Clients abfragen.

Siehe http://www.voip-info.org/wiki-Asterisk+SIP+Mysql+Peers

Gruß
 
@poppy: MYSQL_FRIENDS sollte man nicht mehr nutzen, im aktuellen CVS gibts das nicht mehr. Lieber mit Realtime und einer aktuellen CVS Version arbeiten, das ist zukunftssicherer. MYSQL_FRIENDS macht aber auch nichts anderes als ast_data oder Realtime. IP-Adresse und Port stehen dort auch drin.
 
Wenn ich das recht verstehe, dann lässt sich im Realtime-Mode die Anmeldung auch in die MySQL-DB packen? Wie geht das genau? Wo wird das eingestellt?

Gruß
Rolf
 
Ich bin gerade an der Realtime Geschichte dran. Das ganze ist ja wohl ziemlich neu und ist speziell auf die Versionen von Asterisk >=v1.1 mit einer einheitlichen DB API ausgerichtet. Leider war der voip-info.org Server heute abend nicht erreichbar (Realtime Doku), sonst hätte ich vielleicht schon Ergebnisse :evil: .

Für mich als Asterisk und Linux Neuling kommt da ganz schön was zusammen: Linux und Asterisk an sich, PostgreSQL, MySQL, unixODBC, AGI, ARA, AMI, CDR,SIP,IAX,Events,Python... :?

CDR und PostgreSQL hat auf Anhieb geklappt. Realtime möchte ich am liebsten auf PostgreSQL über unixODBC laufen lassen (PostgreSQL native soll wohl vorerst nicht kommen). MySQL verwende ich nur, wenn es nicht anders geht, wird aber native unterstützt ... :roll:

Tabellar
 
Das Problem im Moment ist wohl, dass Asterisk Realtime erst ab Version >= 1.0.7 läuft. Sprich, man müsste sich Asterisk aus dem CVS holen :roll: .

@Speedy:
Du verwendest doch AST_DATA, oder? Ich hätte da ein Frage dazu: Setzt Asterisk alle Clients auf "not available (oder so ähnlich)", wenn Asterisk beendet wird? Beim Neustart von Asterisk werden alle Clients wahrscheinlich neu registriert und mit der DB synchronisiert. Was passiert im Fehlerfall, wenn sich Asterisk mal "aufhängen" sollte? Dann gibt es doch wohl inkonsistente Clienteinträge in der DB...

Tabellar
 
tabellar schrieb:
Das Problem im Moment ist wohl, dass Asterisk Realtime erst ab Version >= 1.0.7 läuft. Sprich, man müsste sich Asterisk aus dem CVS holen :roll: .
Realtime gibts sogar erst ab Version >1.0. In der 1.0 Reihe werden nur noch Bugfixes gemacht. Es gab zwar mal einen Ansatz Realtime auch nach Asterisk 1.0 zu bekommen, aber was draus geworden ist weiss ich nicht.

tabellar schrieb:
@Speedy:
Du verwendest doch AST_DATA, oder? Ich hätte da ein Frage dazu: Setzt Asterisk alle Clients auf "not available (oder so ähnlich)", wenn Asterisk beendet wird? Beim Neustart von Asterisk werden alle Clients wahrscheinlich neu registriert und mit der DB synchronisiert. Was passiert im Fehlerfall, wenn sich Asterisk mal "aufhängen" sollte? Dann gibt es doch wohl inkonsistente Clienteinträge in der DB...

Tabellar

Also ich starte den Asterisk ganz selten neu. Der läuft durchgängig weil er kein Spielzeug mehr ist (siehe Signatur)...
Soweit ich das bisher beobachtet habe werden die Clients aber nicht abgemeldet bei Beenden von Asterisk. In meiner MySQL und in der Asterisk internen Datenbank ("database show" auf der Konsole) ändert sich nichts. Wär ja auch nicht so praktisch wenn Asterisk sich selbst neu startet wegen eines Fehlers (Neustart = beenden + starten) und dann alle Clients erst mal "offline", also nicht erreichbar, sind.
Da die Clients sich jedoch mit einer Ablaufzeit (register expiration) anmelden, nach der sie sich wieder melden müssen, um nicht als "offline" zu gelten, ist der Clientstatus eigentlich ziemlich gut. Die SIP Clients melden sich von Zeit zu Zeit, dadurch wird das Feld regseconds in der MYSQL Datenbank aktualisiert. In dem Feld steht dann ein Zeitstempel in der Zukunft, bis zu dem sie sich spätestens wieder melden müssen. Meldet sich ein Client nicht mehr, so liegt der Zeitstempel irgendwann in der Vergangenheit und der Client gilt als "nicht online" bzw. nicht erreichbar.
 
Der Realtime-Mode läuft bei mir auf einem 1.05er Asterisk, das klappt schon, nur die Einträge für die Anmeldung finde ich nicht, falls es sie geben sollte.

Gruß
Rolf
 
Oh, das ist mir neu mit Realtime bei Asterisk 1.0. Muß ich mir dann dringend mal ansehen ...
Welche Einträge für die Anmeldung meinst Du denn? Hast Du die Tabellenstruktur von voip-info.org?
 
rowitech schrieb:
Der Realtime-Mode läuft bei mir auf einem 1.05er Asterisk, das klappt schon, nur die Einträge für die Anmeldung finde ich nicht, falls es sie geben sollte.

Das wäre ja schön, wenn das klappen sollte! Wie hast du denn Realtime schon testen können? Welche Familiy verwendest du?

extconfig.conf:
sipfriends => mysql,asterisk,customer_lines ???

Tabellar
 
Servus,

also, ich hab Asterisk Realtime mit den unixODBC (PostgreSQL) und MySQL Treibern auf meiner 1.0.5-*-Version getestet. Tut leider nicht trotz Anleitung nach voip-info.org/wiki-Asterisk+RealTime. Scheint also zu stimmen, dass Asterisk Realtime erst ab *>=1.0.7 läuft, oder ich hab den ein oder anderen Schalter vergessen :roll: !

Das Konzept von ARA (Asterisk Realtime Architecture) überzeugt mich, da es ohne Zusatz-Addons wie z.B. AST_DATA direkt in Asterisk implementiert ist. Ausserdem ist Marc Spencer persönlich an der ARA Entwicklung beteiligt und hat somit beste Zukunftsaussichten. Warten wir also ab, bis die entsprechenden *Releases kommen ... :p

Tabellar
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.