Super NetCup Fail-Routing Geschichte !

Der Kunde agiert nur innerhalb des vServers, d.h. innerhalb einer Unit. Da bekommt man nicht mit, was andere machen. Egal was innerhalb einer Unit passiert, das darf keinerlei Auswirkung auf die anderen Units haben. Das ist ja gerade der Witz an der Isolierung.

Oder willst du mir sagen, der Kunde installiert seine TS-Lizenz auf dem Node selbst? Da sollte keiner außer Netcup Zugriff haben

Das Problem scheint ja nur isoliert eine einzelne Anwendung in einer speziellen Version Testversion zu betreffen. Denke auch, dass die Software einfach noch in der Betaphase steckt

Ich habe niemals gesagt, Kunden sehen Prozesse von anderen. Linux-VServer funktioniert mit dem chroot-Prinzip, mit dem Unterschied der Prozessisolierung (jeder Kunden sieht nur seine eigenen Prozesse und der Prozess sieht auch nur deinen "chroot", also deine Containerumgebung). Kunde A sieht die Prozesse von Kunde B nicht. Auf dem Node jedoch sind die Prozesse ALLER vServer sichtbar.

Beispiel: Du startest einen Prozess. Dieser wird in einem chroot auf dem Node gestartet, aber so, dass nur du ihn siehst. Andere Kunden sehen ihn nicht und können ihn auch über die PID-Nummer nicht killen. Das ganze ist Container-Virtualisierung. Bei anderen Virtualisierungen, wie zB XEN HVM, KVM, VMware hat jeder Kunde seine eigene, vollständig virtualisierte Umgebung.

http://de.wikipedia.org/wiki/V…rung_mittels_OS-Container

Etwas mehr als chroot steckt da schon hinter. Vollständig virtualisiert sind die anderen aber auch nicht, denn die CPU ist immernoch real.

Zurück zum Thema: Welchen Unterschied bzw. Auswirkung sollte die Virtualisierung auf eine Anwendung wie Teamspeak haben? Ob der Prozeß jetzt auf einem eigenem Host oder in einer Unit läuft, das bekommt die Anwendung ja nicht mit.

Eben, hab ich ja gesagt... chroot + Prozessisolierung + init-Pid auf 1 virtualisiert + Pakettrennung Virtualisiert wird eigentlich nur die PID. Die anderen (XEN, KVM etc) haben eine emulierte CPU, sonst würdest Du die des Hosts sehen.

Ich gehe davon aus, dass TS ein Problem mit der Virtualisierung bekommt, sobald mehrere TS Instanzen virtualisiert werden.

Virtualisierung ist nicht Emulation.... Ein Emulator ist z.B. QEMU, hiermit kannst du CPU-Plattform emulieren. In einer Virtualisierung kann ich nur die CPU "durchreichen".

Zurück zum Thema: Woher soll denn mein TS wissen, dass es da noch ein anderes TS gibt bzw. läuft?

Irgendwie müssen die es ja mitbekommen, sonst würden nicht 2 abschmieren wenn man einen startet Aber wie gesagt, ich kenne TS nicht, darum kann ich nichts weiteres sagen.

Mist, die Ausrede hat so lange gezogen

Also, das hat mir nun keine Ruhe gelassen. Wir haben das einmal direkt behandelt und testen das ganze nun selbst. Die Technikabteilung ist ebenfalls direkt involviert worden.

Bitte haben Sie jedoch Verständnis dafür das wir hier nicht laufend Informationen dazu bekannt geben können da es zum einen Wochenende ist und wir uns das ganze zum anderen auch ausgiebig anschauen und auch weitreichend testen müssen. Dies kann mitunter auch einige Tage andauern.

Erste Prüfungen der technischen Umgebungen unsererseits zeigten keinerlei Fehler was die vServer seitens der Wirte oder Netzwerke betrifft. Nun liegt es daran das explizite Teamspeak Problem zu lokalisieren.

Wie Sie sehen sind wir bemüht Ihnen zu helfen das Problem zu finden, auch ausserhalb der regulären Supportleistungen da es sich um ein Softwareproblem eines Drittherstellers zu handeln scheint. Wir bitten daher um etwas Verständnis bis ausreichende Tests abgeschlossen sind.

Wir werden in diesem Thema dann nähere Informationen bekannt geben sobald diese vorliegen. Ggf. werden wir hier betroffene und genannte Kunden auch direkt kontaktieren um z.B. Tests auszuweiten. Dies erfolgt dann jedoch per E-Mail.

Vielen Dank.

habe auch das problem,
seit einigen tagen war ich offline.heute saß ich wieder am pc und wollte auf meinen teamspeak, der war aber down ich dachte erst an hacker... dann habe ich ihn wieder gestartet und schon kam myzed auf meinen ts und meinte sein ts ist grad abgestürtzt. als er seinen angeschaltet hatte ist meiner wieder abgestürtzt

meine ip 46.38.232.206

benutze auch den port 9987

Wenn Kunden unabhängig von einander Teamspeak installieren und durch das Starten eines eigenen Servers einen fremden Server auf den gleichen Node stoppen, kann es sich wohl kaum um einen Fehler handeln, der nur von Teamspeak abhängt. Denn irgendwie muss es ja eine Kommunikation auf den anderen Server geben.

Habt ihr eigentlich alle eine Lizenz für Teamspeak oder verwendet ihr diese seltsame Mount-Geschichte ohne Lizenz, die der Support freischalten kann? Denn dann wäre die gemeinsame Schnittstelle vielleicht doch gegeben...

MfG Christian

Quote from Elradon;37343

Wenn Kunden unabhängig von einander Teamspeak installieren und durch das Starten eines eigenen Servers einen fremden Server auf den gleichen Node stoppen, kann es sich wohl kaum um einen Fehler handeln, der nur von Teamspeak abhängt. Denn irgendwie muss es ja eine Kommunikation auf den anderen Server geben.

Nein. Es geht nicht darum das ggf. Server andere Server beeinflussen, dies ist nicht möglich. Viel mehr wird ein Fehler im Lizenzierungsverfahren direkt beim Hersteller vermutet. Also in der Kommunikation zwischen TS3 Server und Lizenz-Server, nicht aber zwischen den TS3 Server-Instanzen.

Vermutungen helfen hier jedoch auch nichts, wir untersuchen dies nun bereits und bitten weiterhin um etwas Geduld.

Wir haben nun weitere Prüfungen durchgeführt. Es wurden soeben Wartungsarbeiten für das betroffene System angekündigt womit wir weitere Analysen durchführen werden die jedoch einen Neustart der vServer bedingt. Die genaue Quelle und Ursache ist weiterhin nicht bekannt, wir sind jedoch entsprechend bemüht Sie bei der Suche hiernach zu Unterstützen, daher auch die kurzfristigen Wartungsarbeiten.

Wir bitten damit auch weiterhin um etwas Geduld bis die weiteren Analysen abgeschlossen sind.

Ich versuche mal kurz zusammen zu fassen was hier eigentlich passiert.

Es gibt 3 Teamspeak Server auf 3 verschiedenen vServern

Server 1 46.38.232.180:9987
Server 2 46.38.232.208:9987
Server 3 46.38.232.236:9987

Solange nur einer läuft ist alles in Ordnung, startet aber ein andere auf dem selben Port ist der erste nicht mehr erreichbar (läuft aber weiterhin). Der neu gestartete Server ist dann plötzlich auch unter der IP des ersten Servers zu erreichen.

Also z.B. Server 1 läuft und alles ist wunderbar, aber jetzt wird Server 2 gestartet und wenn man dann zu Server 1 verbindet landet man auf Server 2, aber Server 1 läuft weiterhin (man landet beim verbinden halt nur auf dem falschem Server).

Wenn ich das soweit richtig verstanden habe kann es eigentlich kein Problem seitens Teamspeak sein wenn eine IP Port Kombination plötzlich auf den falschen vServer zeigt. Es kann auch kein Lizenzierungsproblem sein, weil die Server nicht abstürzen sondern wie gesagt direkt auf den falschen vServer verbunden wird.

Ich wollte das ganze nur mal zusammen fassen, weil es so aussieht als gab es hier zwischendurch ein paar Missverständnisse.

Kann es mir zwar nicht vorstellen, aber vielleicht "vertauscht" der Node die Prozesse? Habt ihr mal versucht, den TeamSpeak an eure IP zu binden?

So, wir haben nun Optimierungen am Netzwerk-Stack vorgenommen, ein Reboot der vServer ist bereits erfolgt. Wir konnten das Problem nun nicht mehr nachstellen.

Der Node kann die Prozesse nicht "vertauschen", ebenfalls haben die vServer keinen Einfluss auf andere vServer. Wir vermuten dass das Problem durch einen Bug im Netzwerk-Stack zustande kam, wobei noch unerklärlich ist wie es lediglich bei Teamspeak dazu kam das -scheinbar- Ports nicht explizit exklusiv gebunden waren. Die Optimierungen dahingehend sind nun jedoch erfolgreich, zumindest nach unseren Tests landete man immer auf dem Teamspeakserver zu dem man sich auch verbunden hat.

Wir weisen nochmal daraufhin das kein vServer Einfluss auf einen anderen hatte, die Teamspeakserver haben sich also nicht untereinander beeinflusst. Wir werden das ganze aber weiterhin im Auge behalten.

Heißt soviel wie,
wir können alle wieder den Standard Port (9987) nutzen ohne Fehler?