Was man auch daran sieht, dass man bei einem Kauf mit Privataccount zwei Sachen abnicken muss (AGB und Widerrufsrecht) und mit dem gewerblichen Account nur ersteres
Posts by aRaphael
-
-
Laut Support liegt das an meinem Betriebssystem, auch wenn ich das ganz klar ausschließen kann und auch bewiesen habe.
Wie kann man denn so was zweifelsfrei beweisen?
-
Die Preise im CPP und auf der Angebotsseite sind wahrscheinlich die 16%-Preise
-
Was wird sich denn hinter den RS Black Special 1-3 verbergen?
Hat da jemand Erfahrung aus dem letzten Jahr?
-
Ui. Komplexer als erwartet.
Da es bei mir nicht wirklich zeitkritisch ist und es nicht allzu schlimm ist, wenn der Server auch mal ein paar Stunden nicht erreichbar ist, ist es wahrscheinlich in meinem Fall einfacher auf failover ganz zu verzichten und schlicht die A und AAAA records im Ernstfall zu ändern. (und halt bei der domain eine akzeptable TTL zu setzen)
-
Wie ist das eigentlich:
Wenn ich eine failover-IP habe (Nur ip4, keine für ip6), der Server ausfällt und umgeschaltet wird auf den zweiten Server und die domain nun über ipv6 angesprochen wird, was passiert dann?
Wird ein "Server antwortet nicht" zurückgegeben, oder fällt das dann zurück auf ip4 und wird ebenfalls umgeleitet.
Letztlich interessiert mich:
Wenn ich ip6 nutze, brauche ich dann sowohl ip4 als auch ip6 Failover?
-
Direkt über die Verknüpfung hatte ich das auch nicht hinbekommen.
Ich habe es dann nach der Methode "von hinten durchs Knie ins Auge" gelöst:
Eine Aufgabe mit höchsten Rechten in der Aufgabenplanung erstellt, die das PS-Skript aufruft.
Der Desktoplink ruft dann diese Aufgabe auf. (%Windir%\System32\schtasks.exe /run /TN ....)
Nicht besonders elegant, aber es funktioniert
-
Ich habe mich mal drum gekümmert.
Der Support war auch durchaus hilfsbereit.
Nachdem Aufforderungen an den Verursacher zunächst nichts gefruchtet hatten, sind jetzt wohl entsprechende Maßnahmen ergriffen worden.
Seit heute morgen 9:47 ist wieder Ruhe auf meinen Servern im 45.83.104.0/22-Netblock.
Mal sehen, wie lange das anhält...
taucht bei mir aktuell übrigens in einem ähnlichen Muster auf.
Wie sieht es bei dir aus, nurlennart?
-
Also ich kann eigentlich über die Bandbreite meiner G9 RS (2x4000 und 1x8000) nicht klagen.
Punktuelle speedtests (alle zwei Stunden) über längere Zeit hinweg sind besser als bei einem Server mit dedizierten 1Gbit/s eines anderen Providers.
Der garantierte Wert von durchschnittlich 1Gbit/s ist also gegeben.
Falls halt 1Gbit/s nicht ausreicht, für das Vorhaben, dann muss sowieso was größeres her.
-
Im Feld "host" steht
@ für deinen domainnamen (deinedomain.de)
* für alle subdomains, für die kein eigener Eintrag definiert wurde, also ein Wildcardeintrag (*.deinedomain.de)
mail steht dann explizit für die subdomain mail (mail.deinedomain.de). Da sollte also auch die IP deines Maiservers rein.
ftp ist halt eine weitere subdomain, die standardmäßig da drin steht. Kannst du ignorieren oder löschen
-
@ A muss auch auf deinen root-Server zeigen.
@ steht für deinedomain.de
* steht für subdomain.deinedomain.de
-
Schon mal lokal den Browsercache gelöscht?
In der Regel halten die Browser die Stylesheets im Cache.
-
Das passt. Denn ich habe festgestellt, dass ein zweiter meiner Server, der im gleichen Subnetz liegt auch davon betroffen ist.
Also Leute: Wer ebenfalls einen Server in 45.83.x.x liegen hat, sollte evtl. mal nachschauen
Ich habe zwar ein entsprechendes Ticket laufen, aber falls jemand vom Support hier mitliest:
Schaut euch diese ARP-requests dort doch mal generell an.
-
taucht bei mir aktuell übrigens in einem ähnlichen Muster auf.
Liegst du mit diesem Server evtl. im 45.83.x.x Subnetz?
-
killerbeer
Gute Idee. Genau das das werde ich mir jetzt mal reinziehen.
-
Sollte ich die ip mal an den Support weitergeben?
Kommt ja schließlich aus den netcup-Netz...
Ich habe nun mal den Support deswegen kontaktiert und der geht der Sache tatsächlich nach. (Lob
)Der Kunde des entsprechenden Servers wurde kontaktiert. Ich soll mich wieder melden, wenn der traffic in 48h immer noch da ist.
Na, dann schau mer mal...
-
Was war denn das Ergebnis der Tests? Wieviele Leute konnten gleichzeitig konferieren?
Dazu kann ich insofern keine wirklich belastbaren Aussagen treffen, als dass ich einfach zu wenig Leute für die Tests zu Verfügung hatte.
Es schien aber einigermaßen linear zu skalieren und was die Bandbreite angeht, waren auf diesem Server pro Audionutzer nur ca 200 kbit/s und für jede Kamera ca 1800 kbit/s nötig. Das könnte man zwar hochrechnen auf die Verfügbare Bandbreite, aber da bin skeptisch.
Dennoch vermute ich, dass der weniger der traffic der kritische Faktor ist, sondern vielmehr die Rechenleistung. freeswitch scheint da einigermaßen viel CPU pro Audionutzer zu verbraten. Ich hatte bei 6 Kernen einen Zuwachs von (grob) 1% CPU-Auslastung pro zusätzlichem Nutzer. Bei 100 Nutzern wäre also theoretisch Schluss gewesen. Ausprobieren konnte ich das nicht.
-
Wenn man ins Diagramm reinzoomt kommt es irgendwann, aufgrund der Differenz zwischen der Mittelungsintervall von netdata und der Periodenlänge des traffics zu hübschen Schwebungseffekten.
Zoom:
Nicht, dass das irgendwelche Substanz hätte, aber es sieht zumindest nett aus.
-
Mit "dort" meinte ich auch nicht Österreich, sondern das Subnetz
-
Darf ich fragen, ob das auch ein 8000er war?
Vielleicht liegen die dicken Dinger ja alle dort.
