Dimensionierung Hardware und Software für einen Radius Server

[squize]

Hallo Leute,
ich wurde gebeten Vorschläge für eine Radiusinfrastruktur zu machen.

Es geht um einen Telekomanbieter der folgendes Szenario bedienen will:

Ein IP-DSLAM ( Zyxel IES-3000, angedacht sind bis zu 5000 Kunden) werden über einen BRAS ( ebenfalls Zyxel, SMG-700 ) ans Netz angebunden.
Der Radius-Server dient als AAA-Server und soll in einem eingeschränkten Masse HA bieten.

Mein Grundidee ist folgende:

2 SATA Raid-5 2HE Kisten mit DRBD und HEARTBEAT zusammenschalten. Beide Kisten jeweils mit redundanten Netzteilen und USV.

Alternative wäre fertige Appliances zu kaufen, die gibt es bereit s als fertige HA-Lösung, ist natürlich gleich eine Stange Geld, die über die Theke geworfen werden muss.

Mein Problem ist nun, dass ich leider keine ERfahrungswerte habe, was die zu erwartende Last angeht.

Doku gibt es zum Thema Radius leider auch nicht besonders viel, also frage ich euch mal.

Wisst ihr vielleicht, wo ich weitere Infos zum Thema finde oder hat jemand von euch schon einmal mit dem Thema zu tun gehabt und kann mir Tipps geben?


Gruss

Marc

[isotopp]

Mein Problem ist nun, dass ich leider keine ERfahrungswerte habe, was die zu erwartende Last angeht.

Radius erzeugt fast keine Last, außer wenn eine Leitung zusammen bricht - dann müssen Logrecords von den ganzen Disconnect-Events geschrieben werden und das sind dann binnen kürzester Zeit mal alle Deine Kunden.

Die meßbare Last, die Radius erzeugt, kommt in der Regel nicht aus dem Radius-Server, sondern aus dem LDAP-Backend, das man da hinter schrauben will.

[mmm]

Die Last ist tatsächlich so gut wie vernachlässigbar, auch noch bei der doppelten Anzahl an Usern, wenn die sich "normal" verhalten. Das ist so ähnlich wie bei DHCP.

Wenn der Dienst hochverfügbar sein soll, dann kommt man am Ende aber doch zu 2HE-Servern mit Doppelnetzteil und RAID5. Das ist ein bisschen "Perlen vor die Säue", wenn einem denn gerade nichts anderes einfällt, was man mit den zwei Servern nebenbei oder hauptsächlich anfangen kann, aber das Leben ist manchmal verschwenderisch.

Meine Empfehlung hinsichtlich Software wäre Freeradius (freeradius.org) unter Debian. Freeradius unterstützt auch fail-over.

[squize]

Freeradius ist auch in meinem Szenario die Wahl. Failover wollte ich mit DRBD und Haertbeat umsetzen.
Wenn die Kisten keine grosse Last abbekommen, dann habe ich auf jeden Fall noch Optionen ihnen ordentlich Last zu verschaffen. :)
Die Kisten werden in einem 19"-Zoll Rack in einem Telco-Haus stehen.

Ich danke schon einmal für die Auskünfte und freue mich, dass meine Annahmen in die gleiche Richtung gingen.

Dass beim gleichzeitigen Einwählen aller Kunden wahrscheinlich Lastspitzen zu bewältigen sind, hatte ich auch angedacht.

Mir fehlt nur die Erfahrung welche Last das Accounting erzeugt, nach ein bissen stöbern in der spärlich zu findenden Dokus, ist mir dann auch klar geworden, dass es soviel auch nicht sein kann.


Ich habe mir mal das einzige Buch zum Thema Radius ( O'Reilly ) bestellt, nach den Rzensionen scheint es aber nicht wirklich ins Detail zu gehen.

@mm: Hast du Infos zu Fail Over für FreeRadius?

Gruss

Marc

[mmm]

@mm: Hast du Infos zu Fail Over für FreeRadius?

Nein, ich muss gestehen, das habe ich nicht. Freeradius im Einsatz schon, und ein kleines Perl-Skript auf einem anderen Host fragt regelmäßig auf einen User ab und alarmiert mich per SMS, wenn da etwas nicht mehr klappt.

Das ist eine dieser kleinen Schlampereien - Dinge die man eigentlich tun sollte (fail-over) und vor sich herschiebt, weil der Leidensdruck im Störungsfall nicht allzu bedrohlich erscheint. In Deinem Fall kann das, bei entsprechendem SLA mit dem Telco, natürlich ganz anders sein.

[squize]

so langsam komme ich weiter :)

Eine Frage, die sichmir noch stellt, ist die nach dem Backend. FreeRadius beherscht sowohl direkt ein DB-Backend wie auch ein LDAP-Backend.
Durch LDAP habe ich sozusagen eine extra Schicht in meinem Setup. Kennt einer Argumente es trotzdem oder gerade deshalb mit LDAP zu machen?

Meine Wahl wäre entweder Mysql oder PostGresSQL.

Gruss

Marc

[mmm]

Kennt einer Argumente es trotzdem oder gerade deshalb mit LDAP zu machen?

Mit mehr als einem Frontend- bzw. hier Radius-Server kommt automatisch ein zentrales Backend ins Spiel. Das kann LDAP sein, muss es aber nicht.

Gibt es die User nicht nur im Radius-Server sondern auch in anderen Diensten, dann ist die Entscheidung klar für LDAP als gemeinsame Schnittstelle, auch wenn unterschiedliche LDAP-Schemata benötigt werden, und somit hinter dem Backend tatsächlich "was auch immer" noch kommen muss, um den Userstamm auf die verschiedenen Schemata abzubilden (z.B. ein Cronjob). Eine ganz einfache Frage dazu: Wo können Passwörter durch die Kunden geändert werden?

Mit nur einem Radius-Server in der "Sparlösung" und ohne weitergehende Perspektive würde ich mir persönlich keinen Zwang antun und den Favoriten nach eigenem Gusto wählen. Das hängt davon ab, wie Du die Daten geliefert bekommst, und das könnte dann auch Unix-Authentifizierung werden. SQL klingt aber nicht schlecht, weil einfacher zu administrieren.

[squize]

@mm: Danke für die Info

In der Tat wird da noch einiges zusätzlichen Informationen für einen User vorgehalten. Das geht von Kupferaderzuordnung über Tarif bis zur Telefoneinstellungen.
Es existiert bereits eine Mysql Datenbank für alle Kunden mit den entsprechenden Tarifen usw.
Die Voip-Komponente hat ebenfalls eine interne Verwaltung, die natürlich letztendlich auch synchron gehalten werden muss.
Dass würde erst einmal für LDAP sprechen, nur wird der Master, der alle Daten beinhaltet, beim ISP sitzen, die Radiusserver aber im Telcohaus und dort alle Daten vorhalten, halte ich für nicht sinnvoll.

Deswegen bin ich im Moment noch auf der DBMS Seite, aber mal schauen wie sich das Projekt entwickelt :).


Aaaaah, eine Info vielleicht noch, das DB/LDAP-Backend wird auf der gleichen Kiste laufen, deswegen bezieht sich die zu erwartende Last auf das Gespann, nicht nur auf den Radius-Server.


Gruss

Marc