Verschiebung der Einstellung alter PHP-Versionen & Info zur neuen Webserverplattform

[Nils Dornblut]

Guten Tag zusammen,
ich habe bisher nicht verstanden warum ich den Tarif überhaupt wechseln soll? Eine Gegenüberstellung wäre hier sicher sinnvoll. Geht es nur um etwas mehr Webspace und einen schnelleren Prozessor?
Wenn dafür Funktionen wie z.B. individuelle Einstellungen auf dem Server nicht mehr möglich sind und alles 20-30 Euro mehr kostet macht das alles wenig Sinn für mich. Gibt es eine Testmöglichkeit für
Bestandskunden? Eine Art Probeumzug mit der Möglichkeit des Abbruchs nach einigen Tagen? Ich finde die Informationen sehr dürftig und schaue mir das alles vielleicht in 1-2 Jahren nochmals an :-)
Viele Grüße

Das bisherige Image, was auf den Servern läuft, ist in die Jahre gekommen und die Weiterentwicklung dessen ist in vielen Punkten nicht mehr gut möglich. Beispielsweise MySQL kann nicht weiter mit neueren Versionen bedient werden.

Klar, lieb gewonnene Möglichkeiten geben wir auch nicht gerne auf, mussten aber Kompromisse bei der Neuentwicklung eingehen. Es werden hier sicher in den nächsten Monaten und Jahren noch Änderungen und Verbesserungen kommen, es geht aber leider nur nach und nach.

Sie können natürlich einen neuen Tarif/Server einfach zusätzlich buchen und testen. Über die Geld-zurück-Garantie können Sie 60 Tage risikofrei testen. Bei Nichtgefallen erhalten Sie Tarifpreis und Einrichtungsgebühr zurück. Das gilt auch bei Tarifwechseln. Lediglich ausgenommen sind Zusatzleistungen wie Domains, SSL-Zertifikate sowie Sucuri Website Security. Technisch wird ein Rückwechsel aber leider problematisch und sicher auch aus Aufwandsgründen bei Ihnen intern nicht sinnvoll.

Das Einstiegsposting in diesen Thread hier zeigt Unterschiede der Tarife recht umfangreich auf. Dies wurde auch noch aktualisiert in den letzten Tagen.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

Bad-News! Folgende Aussage erhielt ich soeben vom Support: TOP und PS wird es aktuell in den neuen Tarifen nicht geben. Ob und wann dies ggf. verfügbar sein wird, können wir aktuell nicht sagen.

Sorry Nils Dornblut ! Aber einen dedizierten Server ohne Prozessüberwachung??? Konfuse Politik die DF da die letzte Zeit fährt.

Das Thema wird, wie gerade geschrieben, intern diskutiert. Ich melde mich hier, wenn es Neuigkeiten gibt.

Mit freundlichen Grüßen

Nils Dornblut

[gazzo]

Inodes bei Managed Servern und Reseller Dedicated liegen bei 10 Millionen in der Standardeinstellung. Bei Bedarf erhöhen wir diese. Im Shared Hosting limitieren wir diese aktuell auf 1 Million um das System insgesamt stabil zu halten.

Das ist bzw war nicht korrekt. (Wurde das nun angepasst?) Wir haben einen Managed Server und die Standardeinstellung liegt bei 1.000.000. Ebenso wie beim Shared Hosting. Steht auch so in den FAQ, wie mir vom Support gesagt wurde, was aber - da essentiell - in der Leistungsübersicht sinnvoller wäre!

[edit]In der Tat wurden diese für uns zwar erweitert auf 20mio, aber ohne Prozessüberwachung per Script ist der Server für uns so nutzlos[/edit]

Wir haben den Server wieder gekündigt. Greift dann die 60Tage-Rückerstattung nun automatisch?

[AndreasW]

Liebes DF-Team,

nun ist die verschobene PHP-Umstellung so kurzfristig wie nie zuvor angekündigt worden. Krass, was Sie Ihren Kunden abverlangen.

Zudem, wie Sie sicher verfolgt haben, ist es mit der Umstellung nicht getan, viele Applikationen (unter anderem meine) müssen auf eine neue Version gehievt werden, die wiederum weitere Voraussetzungen hat, wie in meinem Fall, eine neuere MySQL-Version.

Wenn Sie die alten PHP-Versionen abschalten, ohne dass neue DB-Versionen zur Verfügung stehen, hört mein Forum auf zu funktionieren, ich werde es möglicherweise nicht einmal mehr updaten oder portieren können.

Wie ist Ihr Zeitplan für die Einführung der neuen MySQL-Versionen (oder Alternativen) und wie stellen Sie sich die Lösung für die Migration und das Updaten der Kunden wie mich vor?

Besten Gruß,

Andreas

[Nils Dornblut]

Wie ist Ihr Zeitplan für die Einführung der neuen MySQL-Versionen (oder Alternativen) und wie stellen Sie sich die Lösung für die Migration und das Updaten der Kunden wie mich vor?

Ein Update von MySQL ist technisch leider nicht möglich. Unter anderem daher haben wir unsere neue Tarifgeneration der 64-Bit-Tarife eingeführt. Dort bieten wir mit MariaDB 10.4 eine aktuelle SQL-Version an. Der Tarifwechsel kann über das Kundenmenü erfolgen.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

Das ist bzw war nicht korrekt. (Wurde das nun angepasst?) Wir haben einen Managed Server und die Standardeinstellung liegt bei 1.000.000. Ebenso wie beim Shared Hosting. Steht auch so in den FAQ, wie mir vom Support gesagt wurde, was aber - da essentiell - in der Leistungsübersicht sinnvoller wäre!

Wir haben es entsprechend hier in den FAQ:

https://www.df.eu/de/support/df-faq/...actory/#c24138

Pro Quota können maximal 10.000.000 Dateien (inodes) angelegt werden.

[edit]In der Tat wurden diese für uns zwar erweitert auf 20mio, aber ohne Prozessüberwachung per Script ist der Server für uns so nutzlos[/edit]

Wie definiert sich für Sie Prozessüberwachung bzw. was wollen Sie damit machen/tun können?

Wir haben den Server wieder gekündigt. Greift dann die 60Tage-Rückerstattung nun automatisch?

Für diese Garantie wenden sie sich bitte über das Kundenmenü an uns. Automatisch greift diese nicht.

Mit freundlichen Grüßen

Nils Dornblut

[gazzo]

Wir waren über 15 Jahre lang begeistere Fans von D)F. Leider wurde die letzten 2, 3 Jahre irgendwie der Zug verpasst! Schön das nun grundsätzlich was passiert! Es muss nur eben auch weiterhin sinnvoll und praktikabel bleiben. Ansonsten bleibt dann nur der Abschied.

Wie definiert sich für Sie Prozessüberwachung bzw. was wollen Sie damit machen/tun können?

Wir nutzen Shopware-Shops! Diese sind mit der Warenwirtschaft (REST) verbunden. Ein "Backlog" Script sorgt dafür, dass Änderungen sequentiell abgearbeitet werden. Damit es nicht zur Überlast kommt. Dieses Shell-Script läuft quasi im Loop und ruft wiederkehrend ein PHP-Script auf. Das Script wiederum ist natürlich auf eine bestimmte Anzahl durchzuführender Operationen limitert. Das Script selbst kommt garnicht von uns, sondern wird so für die WaWi als "Connector" zur Verfügung gestellt.

Nun sollte es aber nicht durch einen möglichen Mehrfachaufruf zu Kollisionen bei der Bearbeitung kommen. Es ist also essentiell, dass das Script nur einmal läuft. Sollte es zu einem Abbruch kommen, stellt ein Cron sicher, dass es wieder gestartet wird. Dazu muss der Cron aber ja wissen ob das Script noch aktiv ist. Wir schreiben also eine PID-File und können so ganz schlicht die Instanz prüfen. Also im Grunde ganz banale PID Überwachung, wie sie schon seit Jahrzehnten praktiziert wird. Dazu benötigt man ja nun zumindest "ps" oder alternativ "pgrep". "top" ist nur nice2have um schnell mal fehler, zombies usw zu finden.

Anderes Beispiel: Wir nutzen für unsere Middleware PHP Scripte, die per REST Daten mit der WaWi in beide Richtungen syncen (Bestellung holen, Artikelverfügbarkeiten schreiben usw.) ... Zwar könnte man hier theoretisch auch (je nach Progammieransatz) mehrere Scripte parallel laufen lassen, allerdings erhöht sich dadurch auch liniear der REST Zugriff. Die meisten API´s sind (zu Recht) zeitlich und in der Anzahl der Calls limitiert. Ein Script z.B. mit 100 Anfragen alle 5 Minuten, bedeutet bei doppelter Ausführung eben 200 Anfragen, bei 3-facher 300 usw. Durch die Limitierung "bremst" man sich wieder selbst aus, da die Schnittstelle geblockt wird bis wieder Kontingent frei wird. Da die Shops und die Middleware mit der WaWi kommunizieren, ist eine Kontrolle hier unerlässlich! (Siehe oben ...) Dafür hat man ja schließlich einen eigenen Server mit SSH Zugriff.

Zumindest "ps" ist also bei vielen Anwendern (z.B. Shopbetreibern) unerlässlich. Ohne ist der Server schlicht unbrauchbar.

Nach einigen Überlegungen haben wir uns, für unsere Shops, nun mittlerweile für einen anderen Hoster mit dedizierter Hardware, vollem Root-Zugriff, deutschem Server-Standort und dennoch gemanaged entschieden. Preis-/Leistung ist dabei weiterhin kostant und vergleichbar. Wir behalten hier bei D)F erstmal noch die Maschine mit dem alten Tarif für die Middleware und hoffen, dass D)F hier in den neuen Tarifen schnellstmöglich nachbessert, so was wir irgendwann dann auch damit "in die Neuzeit" (MariaDB, usw) wechseln können. So wird das erstmal nix!

[Nils Dornblut]

Wir waren über 15 Jahre lang begeistere Fans von D)F. Leider wurde die letzten 2, 3 Jahre irgendwie der Zug verpasst! Schön das nun grundsätzlich was passiert! Es muss nur eben auch weiterhin sinnvoll und praktikabel bleiben. Ansonsten bleibt dann nur der Abschied.

Soweit verständlich und vielen Dank, dass Sie sich die Zeit für diese ausführlichen Worte nehmen. Wir sind beim neuen Image sehr aktiv und möchten gerne Verbesserungen vornehmen.

Wir nutzen Shopware-Shops! Diese sind mit der Warenwirtschaft (REST) verbunden. Ein "Backlog" Script sorgt dafür, dass Änderungen sequentiell abgearbeitet werden. Damit es nicht zur Überlast kommt. Dieses Shell-Script läuft quasi im Loop und ruft wiederkehrend ein PHP-Script auf. Das Script wiederum ist natürlich auf eine bestimmte Anzahl durchzuführender Operationen limitert. Das Script selbst kommt garnicht von uns, sondern wird so für die WaWi als "Connector" zur Verfügung gestellt.

Nun sollte es aber nicht durch einen möglichen Mehrfachaufruf zu Kollisionen bei der Bearbeitung kommen. Es ist also essentiell, dass das Script nur einmal läuft. Sollte es zu einem Abbruch kommen, stellt ein Cron sicher, dass es wieder gestartet wird. Dazu muss der Cron aber ja wissen ob das Script noch aktiv ist. Wir schreiben also eine PID-File und können so ganz schlicht die Instanz prüfen. Also im Grunde ganz banale PID Überwachung, wie sie schon seit Jahrzehnten praktiziert wird. Dazu benötigt man ja nun zumindest "ps" oder alternativ "pgrep". "top" ist nur nice2have um schnell mal fehler, zombies usw zu finden.

Anderes Beispiel: Wir nutzen für unsere Middleware PHP Scripte, die per REST Daten mit der WaWi in beide Richtungen syncen (Bestellung holen, Artikelverfügbarkeiten schreiben usw.) ... Zwar könnte man hier theoretisch auch (je nach Progammieransatz) mehrere Scripte parallel laufen lassen, allerdings erhöht sich dadurch auch liniear der REST Zugriff. Die meisten API´s sind (zu Recht) zeitlich und in der Anzahl der Calls limitiert. Ein Script z.B. mit 100 Anfragen alle 5 Minuten, bedeutet bei doppelter Ausführung eben 200 Anfragen, bei 3-facher 300 usw. Durch die Limitierung "bremst" man sich wieder selbst aus, da die Schnittstelle geblockt wird bis wieder Kontingent frei wird. Da die Shops und die Middleware mit der WaWi kommunizieren, ist eine Kontrolle hier unerlässlich! (Siehe oben ...) Dafür hat man ja schließlich einen eigenen Server mit SSH Zugriff.

Zumindest "ps" ist also bei vielen Anwendern (z.B. Shopbetreibern) unerlässlich. Ohne ist der Server schlicht unbrauchbar.

Danke für die Worte. Ich gebe das an entsprechende Stellen und wir werden es diskutieren. Antwort diesbezüglich werde ich dann hier natürlich teilen.

Nach einigen Überlegungen haben wir uns, für unsere Shops, nun mittlerweile für einen anderen Hoster mit dedizierter Hardware, vollem Root-Zugriff, deutschem Server-Standort und dennoch gemanaged entschieden. Preis-/Leistung ist dabei weiterhin kostant und vergleichbar. Wir behalten hier bei D)F erstmal noch die Maschine mit dem alten Tarif für die Middleware und hoffen, dass D)F hier in den neuen Tarifen schnellstmöglich nachbessert, so was wir irgendwann dann auch damit "in die Neuzeit" (MariaDB, usw) wechseln können. So wird das erstmal nix!

Wie gesagt, danke für die offenen Worte und wir werden schauen, was wir zukünftig, aber dennoch zeitnah davon erfüllen können.

Mit freundlichen Grüße

Nils Dornblut

[Elektron]

Auch mir geht es ähnlich wie dem User gazzo !
Nach fast 15 Jahren guter Zusammenarbeit mit Domainfactory werden sich nun auch unsere Wege trennen! Seit ca. 2 Jahren habe ich auf die 64bit-Server gewartet und mich immer vertrösten lassen! Seit wenigen Wochen nun endlich die 64-bit Server verfügbar! Huhu... Meine eigenen Tests mit 64bit-System waren dann leider sehr ernüchtern, da sie aktuelle nicht das Bieten (weniger Möglichkeit/Funktionen) wie mein alter Server. Das Warten hat nun ein Ende und der Umzug beginnt!
Wünsche dem DF-Team, vor allem dem Support, alles Gute für die Zukunft!

photovoltaikforum.com

[Benutzername]

Ja, auch ich warte nun schon länger auf die neuen Tarife, ein stetiges hin und her. Die ganze PHP Thematik hängt mir auch noch ziemlich nach. Die (oft fehlende) Kommunikation von dF hat bei mir viel Porzellan zerschlagen. Von den versprochenen Synergieeffekten nach der Übernahme durch godaddy habe ich bisher außer Preiserhöhungn nichts gemerkt. Und nun soll auch der neue Server noch mal 40 Euro mehr kosten als mein jetziger. (kein Wunder, dass dieser "geräuscharm" eingeführt wird) Nach nun 19 Jahren bei dF habe auch ich inzwischen einen anderen Anbieter gefunden, der mehr Qualität und vor allem wieder das "df Gefühl" von früher bietet. Ein individuelles Angebot war direkt selbstverständlich. Diese Woche beginnen die ersten Umzüge. Meine einzigen Lichtblicke bei df sind "mein" PVI Betreuer und die Tatsache, dass "mein" Server nun schon recht lang stabil läuft. Letzteres ist allerdings ja wohl die Mindestanforderung, die bei einem Managed Server zu erwarten sind.

[Nils Dornblut]

Auch mir geht es ähnlich wie dem User gazzo !
Meine eigenen Tests mit 64bit-System waren dann leider sehr ernüchtern, da sie aktuelle nicht das Bieten (weniger Möglichkeit/Funktionen) wie mein alter Server.

Was genau hätten Sie denn gebraucht bzw. was vermissen Sie?

Wünsche dem DF-Team, vor allem dem Support, alles Gute für die Zukunft!

Vielen Dank, Ihnen auch!

Mit freundlichen Grüßen

Nils Dornblut

[Elektron]

es ging um die Nachinstallation von Elasticsearch
Also in der heutigen Zeit, nix besonderes oder total Unbekanntes.

Beim neuen Server konnte ich es mit einer Programmzeile selbst, ohne Server-Kenntnis, nachinstallieren ;-)

[cetba]

Was genau hätten Sie denn gebraucht bzw. was vermissen Sie?

• PHP: die gewohnte Möglichkeit, Hunderte von Domains auf einen Schlag upgraden können.
• Der gewohnten Zugang zu den Datenbanken über den SSH Tunnel (Software NAVICAT) - das ist für mich gerade ein ERNSTES Problem.
• Der Filemanager: mal eben 5000 Daten löschen? damit: 5 Sekunden, mit FTP: 90 Minuten. Klar geht das auch anders, aber das Tool war sehr nützlich. Das Ersatztool ist so rudimentär, dass ich es für brandgefährlich halte (habe es aber noch nicht ausprobiert)
• RP2 über meine Subdomain
• FTP Timeouts beim Connect. Hatte ich vorher nie. Einige FTP Zugänge zeigen zudem nach dem Paketwechsel plötzlich auf den Root
• Server Monitoring - oder einen Ersatz dafür - für ein Gefühl, ob alles rund läuft (mehrere Server-/Platten-Crashs der letzten Jahre hatten sich darüber angekündigt)
• Das bequeme Log CGI Tool für die Serverlogs direkt im RP2
• Eine bequeme Möglichkeit, den neuen Cache (NGINX und OP) über RP2 an- und abschalten oder leeren zu können (z.B. bei Fehlersuchen)

Noch mehr?

[Benutzername]

Noch mehr?

Ja bitte! Das ist eine sehr gute Auflistung.

[zzet]

• RP2 über meine Subdomain

Geht das in den neuen Tarifen nicht mehr? Was ist stattdessen möglich?