• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

[Ts3] Redundanz möglich?!

Duffman

Azubi
Hallo zusammen,
ich habe schon über die Suchfunktion nachgeschaut, ob es so etwas schon mal hier gestellt wurde. Nach mehreren Seiten später, war ich der Meinung ein Thema auf zumachen da ich nichts dazu gefunden habe. Sollte es doch schon eines geben, einfach den Link hier in das Thema posten und ich lasse es schließen. :)

Meine Idee:
Ich habe momentan einen dedizierten Server bei Hetzner stehen, würde aber gerne noch einen kleinen vServer mieten um meinen Teamspeak Server redundant zu halten. Warum erstmal möchte ich dass?
Auf meinem Server ist das meist genutzte mein Teamspeak 3 Server. Dort halten sich viele meiner Freunde auf, wir spielen zusammen und sind dort einfach sehr oft und lange. Möchte ich aber jedoch mal die Kiste neu starten, oder mal komplett neu aufsetzen --> Ist in dieser Zeit kein Teamspeak Server verfügbar.

Theorie:
Ich habe einen Root Server und einen vServer. Diese 2 Server gleichen permanent für Teamspeak die Daten ab (wie als würde der TS im RAID 1 Verbund laufen). Die User befinden sich primär auf dem Root Server und verbinden sich über die Domain auf den Teamspeak. Sollte nun der Root ausfallen, switcht der DNS Server automatisch die Domain auf die IP des vServers um.
--> User connected zu dem Teamspeak auf dem vServer.

Frage:
Ist dieses Vorhaben umsetzbar?
Wenn ja, wäre ich wirklich sehr froh wenn Ihr mir in diesem Bereich nützliche Links oder gute Tipps geben könntet :)
 
Möchte ich aber jedoch mal die Kiste neu starten, oder mal komplett neu aufsetzen --> Ist in dieser Zeit kein Teamspeak Server verfügbar.

Die Downtime bei einem Restart des Servers bewegt sich im Sekundenbereich, wäre also vernachlässigbar.
Wenn du den Server neu aufsetzt und als erstes deinen TS flottmachst, bewegst du dich mit der Downtime auch in einem Zeitfenster < 1 Stunde, sollte also auch noch verschmerzbar sein.

Deswegen extra nen zweiten Server anzumieten, halte ich für überflüssig.
Wenn du eine NPL verwendest, dürfte es außerdem auch lizenzrechtlich problematisch werden (Ich kann dir leider gerade die entsprechende Seite nicht verlinken, weil die NPL-Registrierung im Moment geschlossen ist).

Sollte nun der Root ausfallen, switcht der DNS Server automatisch die Domain auf die IP des vServers um.

DNS-Informationen können durchaus mehrere (bis zu 48) Stunden brauchen, bis sie sich weltweit auf allen DNS-Servern rumgesprochen haben. Ein einfaches 'Umswitchen' ist in der Form also auch nicht so ohne Weiteres möglich.
 
Nimm als SQL Datenbank nicht SQLIte, wie voreingestellt, sondern MySQL.

Dann noch eine Replikation zwischen den beiden Servern einrichten und einen Sync des File Verzeichnisses, damit Icons usw. auch Persistent sind.

Mögliche Lösungen:
- Network Storage
- GlusterFS
- Rsync
- regelmäßiges SCP per Push
- etc.
 
Möchte ich aber jedoch mal die Kiste neu starten, oder mal komplett neu aufsetzen --> Ist in dieser Zeit kein Teamspeak Server verfügbar.

Natürlich sollte der TS Server im Autostart sein. Ansonsten ist ein Neustart in der Tat im Sekundenbereich erledigt und die Clients reconnecten sogar automatisch, solange die Downtime nicht zu lange ist. Davon abgesehen legt man sich diese Downtimes natürlich als Serveradmin so, dass die User möglichst wenig davon beeinträchtigt werden (also nicht um 21 Uhr). :D

Bei einem Linux Server frage ich mich darüber hinaus, für was - außer einem Kernelupdate - man neustarten müsste?

Keine Ahnung auch wieso man "mal komplett neu aufsetzen" sollte, aber in der Regel macht man das doch nicht wirklich regelmäßig. Nichts für ungut, meine, durch regelmäßige Updates und Dist-Upgrades aktuell gehaltenen Server werden monatelang oder jahrelang nicht neu aufgesetzt. Warum auch? Wenn Du rumprobieren willst, ist ein Rootserver nicht die richtige Umgebung.

Wenn Du wirklich Aufwand treiben willst, könntest Du auf einem Virtualisierungshost (z.B. ESXi oder KVM) Deine Anwendungen kompartimentieren, d.h. eine VM für TS3 aufsetzen, eine für Webserver, eine für Mailserver, etc. So kannst Du Einzelteile austauschen, ohne den Rest zu beeinflussen. Hierfür muss der Server und das Providernetz jedoch bestimmte Voraussetzungen erfüllen und Du braucht mehrere IP Adressen.

EDIT: Rechtschreibung von "Redundanz" im Threadthema korrigiert.

EDIT1: Zum Thema: obgleich man die TTL von DNS Einträgen durchaus kürzer setzen kann, ist das "Umswitchen" von Einträgen kein Standardfeature von DNS Servern. D.h. man steht schon mal vor der Schwierigkeit, das Gewünschte überhaupt umzusetzen. Round Robin ( http://de.wikipedia.org/wiki/Lastverteilung_per_DNS ) hilft hier nicht wirklich.

Davon abgesehen: selbst wenn es funktionieren sollte. Dann hast Du Deine User auf dem alternativen Server. Und was machst Du, wenn der "Hauptserver" wieder da ist? Wie bekommst Du die User wieder auf den Hauptserver zurück? Gar nicht... Die neuen User werden zum Hauptserver connecten und die weitergeleiteten User bleiben auf dem Alternativserver. Keine gute Situation.
 
Last edited by a moderator:
Man kann auch den proprietären TSDNS nutzen. Der Server auf dem der TSDNS läuft müsste aber jederzeit erreichbar sein. Ansinsten wäre das ganze Vorhaben sinnnlos.
 
Kleiner Tip: Wenn die DB synchronisiert wird, darf immer nur einer der beiden Server laufen. Ansonsten müsste die ID des (TS) vServer unterschiedlich sein.
 
Allein schon aus meinen o.g. Gründen sind in dem Konzept doch mehrere Löcher. Ergo ist eine Weiterverfolgung m.E. nur begrenzt sinnvoll. Der TE soll lieber daran arbeiten, seine Updateprozesse zu optimieren und nicht alle 2 Tage den Server neu installieren (wie gesagt monate/jahrelang unnötig).
 
Hallo,
vielen Dank erstmal für die schnellen, zahlreichen und auf jeden Fall hilfreichen Antworten! Ich bin neu hier und echt begeistert, wie schnell einem geholfen wird und zudem wie professionell. :)

@Nexus: Das mit der Downtime von Sekunden war mir bewusst. Alleine das würde ja auch nichts ausmachen. Du hast erwähnt "...Wenn du eine NPL nutzt..." - Daran habe ich überhaupt nicht gedacht, wenn ich einen zweiten Ts3 Server aufsetze. Zudem besitze ich keine NPL. Ich habe darüber überhaupt nicht nachgedacht, mein Ziel war es einfach nur eine Art Ts3 im RAID 1 Verbund (theoretisch). Aber hinzukommend sind ja eine weitere IP und Lizenz technisch nicht ganz legal.

@Terrorkarotte:
Kann ich einen bestehenden Server der mit sqllite läuft auf MySQL switchen? Wenn ja, könnte ich da schon einmal anfangen und später mit rsync die Daten zum ext. Server mit einem Cronjob im Minutentakt abgleichen.

@Thunderbyte:
Thunderbyte said:
Davon abgesehen: selbst wenn es funktionieren sollte. Dann hast Du Deine User auf dem alternativen Server. Und was machst Du, wenn der "Hauptserver" wieder da ist? Wie bekommst Du die User wieder auf den Hauptserver zurück? Gar nicht... Die neuen User werden zum Hauptserver connecten und die weitergeleiteten User bleiben auf dem Alternativserver. Keine gute Situation.
--> :D Ich glaube dadurch hat sich die grundlegende Idee von selbst in den Sand gesetzt ... .

Ps: Das mit dem neu aufsetzen habe ich das letzte mal vor einem halben Jahr gemacht ;) - Ich habe mittlerweile ein tägliches Backup auf einen ext. Server von einem Freund eingerichtet damit ich "falls" ich den Server neu installieren sollte, Teamspeak in wenigen Minuten wieder mit den vorhandenen Daten installieren kann.

Danke für die Super Auskunft!
das Thema kann gerne geschlossen werden.
 
@Thunderbyte:

--> :D Ich glaube dadurch hat sich die grundlegende Idee von selbst in den Sand gesetzt ... .

Nicht ganz. Fassen wir zusammen:

  • mysql-replikation der TS3-DB
  • rsync um Dateien abzugleichen

Was jetzt tu testen wäre:
  • Tsdns einrichten und die Funktion prüfen
  • Via dns connecten
  • 2. Server auf anderem Host starten
  • Konfiguration des tsdns ändern, damit die verwendete dns auf den 2. Server (ip&port) verweist
  • tsdns neustarten (zwecks Übernahme der Konfiguration)
  • Den TS-Server, mit dem du verbunden bist, herunterfahren
  • abwarten und gucken was passiert

Wenn der Client die IP und den Port cached, hast du verloren. Dann würde der Client versuchen zum alten nicht mehr vorhandenen Server zu connecten.

Sollte entgegen aller Erwartung der tsdns erneut abgefragt werden, verbindet sich der Client dann automatisch zum neuen Server.
 
Na ist ja super, wenn die TS Configs synchron sind. Dass man das hinbekommt und selbst den Switch auf den anderen Server noch irgendwie schafft, das mag alles funktionieren.

Trotzdem gibt es keinen Mechanismus, der einmal auf den Alternativserver verlagerte User bei Wiederverfügbarkeit des Hauptservers wieder zurück befördert. Und da liegt der Hase im Pfeffer und der Hund begraben. ;)
 
Wenn es sowieso nur ein Aktiv/Passiv "Cluster" wird. Kann man denn eben so gut ein Passiv/Aktiv Cluster draus machen.
Wer sagt denn, dass man zurückschwenken muss. ;)
 
Trotzdem gibt es keinen Mechanismus, der einmal auf den Alternativserver verlagerte User bei Wiederverfügbarkeit des Hauptservers wieder zurück befördert. Und da liegt der Hase im Pfeffer und der Hund begraben. ;)

Man müßte ein Script basteln, welches im Minutentakt den Hauptserver abfragt ob der online ist. Wenn nicht wird der 2te Ts gestartet und auf den 2ten Server geswitcht. Dann wird das Script von einem anderen abgelöst, welches dann abfragt, wann der Ts vom Hauptserver wieder online ist. Sollte der Server wieder online sein, wird der Ts auf dem 2ten Server wieder beendet und es wird wieder das erste Script gestartet.
Fröhliches basteln :D
 
wenn die Fail over IP umgeroutet wird werden alle disconnectet und verbinden sich dann wieder mit dem neuen Server ;)

http://www.ovh.de/dedicated_server/ip_failover.xml

hier mit Grafiken ;)

die configurationsdateien müsste man wohl mit einem eigenen script auf dem laufenden halten...
und falls der 1. Server down geht(keine config trifft ein, heartbeet, ping, whatever) wird der 2. ts gestartet und die ip auf den anderen Server gelenkt...

alternativ
Colocation Space anmieten und mit NAT arbeiten ;)
 
Trotzdem gibt es keinen Mechanismus, der einmal auf den Alternativserver verlagerte User bei Wiederverfügbarkeit des Hauptservers wieder zurück befördert. Und da liegt der Hase im Pfeffer und der Hund begraben. ;)

Doch, wenn der tsdns geändert wird und der Client das beim Timout erneut abfragt, funktioniert das. Alle neuen User kommen dann eh auf den neuen Server. Tsdns ist eigentlich nichts anderes als der srv-Eintrag beim DNS. Nur handelt es sich da um ein eigenes proprietäres Protokoll im Client. Gleichzeitig nutzt TS aber auch den SRV-Eintrag. Da gibt es auch eine fest definierte Reihenfolge der Abfrage. Ich glaub das war: TSDNS, SRV, A-Record (keine Info über den Port!)

Wobei dei Lösung mit der Failover-IP für mich am einfachsten klingt.
Diese Frickellei mit Scripten, welche die Konfiguration ändern, Server starten und den alten herunterfahren ist ziemlicher Mist. Gleichzeitig noch das Synchronisieren usw.. Ehrlich gesagt wäre mir das bei einer proprietären Anwendung zu unsicher. Man hat keine Möglichkeit den Prozess zu beeinflussen. Mal angenommen das mit dem TSDNS würde so funktionieren, dann kann es beim nächsten Update sein, dass es nicht mehr funktioniert.
 
@Terrorkarotte:
Kann ich einen bestehenden Server der mit sqllite läuft auf MySQL switchen?

TS3 bietet ein Telent Interface. Dort kann man die Befehle Snapshotcreate und Snapshotcreate ausführen. Beim Deploy werden etwaige IDs nicht insertet, sondern neu generiert und die Abhängigkeiten neu hergestellt. So kann man die Einstellungen von einem Server auf einen anderen kopieren.

Das SQL Backend ist dabei dann egal.
 
Hallo zusammen,
ich bin erstmal wirklich erstaunt (again :rolleyes:) wie professionell hier die User unterwegs sind und enorm qualitative und noch durchaus hilfreiche Antworten einem geliefert werden. Dafür bin ich auf jeden Fall sehr dankbar!

Zu dem Problem:
Ich denke nach euren Beiträgen, ist es einerseits möglich andererseits eine sehr instabile Lösung. Wenn ich die Zeit hätte, wäre das mit dem Abgleich der Server per Skripte etc. kein Problem (bin ja in der Ausbildung --> Zeit :) ). Dennoch denke ich gerade in die Zukunft, dass es nach Updates wie DeaD_EyE beschrieben hatte einfach kaputt gehen könnte.

Ich werde mir in nächster Zeit zu euren Inputs Gedanken machen und versuchen eine Lösung zu finden. Wenn ich in den nächsten Monaten eine habe, lasse ich es euch samt einer Dokumentation Wissen. (falls ich bei meinen Vorgängen was falsch mache oder man verbessern könnte)

Ich danke euch auf jeden Fall!
- Der Moderator kann gerne der Übersichtlichkeit das Thema schließen.
 
Normalerweise lassen wir Threads offen - u.a. damit Du ggfalls selbst wieder weiter schreiben kannst.

Du hast ja deutlich gemacht, dass Du erst mal keine weiteren Ideen mehr benötigst. ;)
 
Back
Top