DomainFactory leistet sich den nächsten Knaller! Oder Tarifwechsel des Grauens!

Geschrieben von Robin Köhler am . Veröffentlicht in News.

Bewerten Sie unsere News:
3.80 von 5 - 5 Bewertungen
Vielen Dank für die Bewertung dieses Beitrags.

Wir hatten im Januar ein Tarif-Upgrade geplant und durchgeführt, um unseren Kunden eine bessere Webserver-Performance bieten zu können. Hier nun der Bericht dieser schmerzlichen Erfahrung.

Auf die Tatsache, dass alle Websites, die über das CDN Cloudflare liefen, mehrere Tage offline waren, da DF bei den neuen Tarifen einen zusätzlichen ngnix Webserver vorschaltet, möchte ich hier gar nicht eingehen. Ja, Sie lesen richtig, alle zuvor funktionierenden, lokalen redirects für HTTPS funktionierten mit Cloudflare nicht mehr. Aus, bis dato immer noch unbekannten Gründen schießt die neue Webserver-Konfiguration bei DF diese internen redirects ab und erzeugt eine Endlos-Redirect-Schleife. Interessieren tut das DomainFactory bis heute nicht! Ergo: Joomla-Websites, die über Cloudflare laufen, funktionieren bei DF nicht mehr.

Nein es soll in diesem Blog-Beitrag um ein anderes Thema gehen!

DF begrenzt die Anzahl der Dateien auf einem Shared-Hosting-Server für Reseller.

Wo von dir ausgegangen waren: neue 64-Bit-Tarife bieten mehr Leistungen und weniger Beschränkungen durch die 64-Bit-Architektur. Pustekuchen! Genau das Gegenteil war der Fall. DomainFactory führte bei den neuen Reseller-Tarifen ein künstliches Limit an Dateien ein. Pro Quota sind nun maximal 1 Million Inodes (Dateien) erlaubt. Das klingt viel, dieses Limit ist aber schnell erreicht, werden CMS wie WordPress oder Joomla eingesetzt. DF wirbt bei den neuen Tarifen damit bis maximal 200 Kunden (und mehr) auf einem Server verwalten zu können. Nutzen diese Kunden allerdings alle ein CMS, ist die künstliche Grenze von 1 Million Dateien sehr schnell erreicht. Bei uns war dies bereits bei etwa 20 Kunden / Websites der Fall. Die Stellungnahme von DF auf dieses gravierende Problem war – nutzen Sie mehrere Quotas. Nun ist die Idee verschiedener Quotas grundsätzlich eine gute Sache, erhöhte dies z.B. die Sicherheit. Gleichzeitig steigt aber auch die Organisation und Verwaltung der Websites auf dem Server. Für jede Quota ist ein eigener FTP/SSH-Zugang notwendig. In unserem Fall waren dies 10 Quotas die für unsere Websites erforderlich wurden, was vorher alles in 3 Quotas passte. Dazu kommt, dass man sich hier nun ständig an der Grenze des Limits befindet. Es dürfen also nicht viele Dateien dazu kommen. Um etwas Luft in den einzelnen Ouotas zu haben sind also 15 Quotas für etwa 200 Kunden erforderlich. Dies steigert die Verwaltung der Organisation massiv und sorgt für weitere Probleme. Führen Skripte im Hintergrund Arbeiten aus z.B. über Cronjobs, so können diese nicht mehr auf alle Dateien bzw. Websites zugreifen. Es muss für jede Quota ein separates Skript erstellt werden.

Weiteres Problem ist der limitierte Speicherplatz pro Quota. Beim Erstellen einer Quota muss eine Größe derselben angegeben werden. Ich muss also vorher genau wissen wie viel Speicherplatz die gewünschten Websites gemeinsam benötigen. Auch hier ist eine Planung schwierig, da der Speicherplatz auch etwas Luft nach oben haben sollte. Stichwort „Userdata“ und Logfiles. Dabei wird der zugewiesene Webspace einer Quota automatisch zu 100% beim Gesamt-Webspace angerechnet. Es wird also nicht der tatsächlich verwendete Speicherplatz pro Quota vom Wepspace des gebuchten Tarifs bemessen, sondern die zugewiesene Größe der Ouota. Was technisch sicherlich korrekt ist, führt schnell zu dem Problem, dass der zu Verfügung stehende Webspace des Webservers erreicht ist, obwohl der tatsächlich verwendete Speicherbedarf noch weit vom Limit des tariflich zugesicherten Webspaces, entfernt ist. Dazu kommt der ungeheure Zeitaufwand für die Planung und Organisation der Neustrukturierung des Webservers.

Wie so oft in der Vergangenheit interessiert DomainFactory das Thema nicht. Die unnötige Limitierung auf 1 Mio. Dateien pro Quota bleibt, und man muss selbst schauen, wie man damit klarkommt. Allerdings ist das Werbesprechen, eine gewisse Anzahl an Kunden auf den neuen Tarifen hosten zu können, irreführend. Und dass in Zeiten, in denen Webspace nichts mehr kostet, ein Rückschritt in die Anfangszeit des Internets. Als Grund für diese Limitierung nennt DF übrigens hohe Kosten für Backup-Lösungen und Server-Infrastrukturen. Anstatt in moderne Infrastrukturen zu investieren, geißelt DomainFactory lieber die Kunden und schiebt die Verantwortung lieber dem Kunden in die Schuhe. Service- und Kundenorientierung geht anders!

Schändlich, dass es DomainFactory immer wieder aufs Neue schafft, langjährige Kunden vor den Kopf zu stoßen. Von der harten Begrenzung der Inodes haben wir erst nach dem Tarifwechsel erfahren! Genau gesagt erst dann, als unsere Websites die Limitierung massiv sprengten und die Seiten dadurch offline waren! Danke DF!

Es sei zum Schluss noch angemerkt, dass der geplante Umzugstermin dreimal von DomainFactory verschoben wurde.

RK Mediawork, Tipps für Websites, Alle

https://www.gravatar.com/avatar/e3bda97d41ff6e088a8bcd660cf9a7b7?d=https%3A%2F%2Fwww.rk-mediawork.de%2Fmedia%2Fcom_rscomments%2Fimages%2Fuser.png&s=60
NanoPolymer
Seit der Umstellung auch nur Probleme.
Aus dem Firmennetz gehen an die neuen Hostings keine FTP Verbindungen mehr via Filezilla, wohl aber über Cyberduck.
Einspielen von Datenbanken via Skript geht nicht mehr.
Das ganze Verhalten der FTP-Accounts ist einfach nur Müll. Vorher konnte ein Account nicht aus seinem Verzeichnis ausbrechen und war auch SFTP. Jetzt muss ich extra erst ein Quota einrichten mit allen negativen Effekten.

Für neue Kunden werde ich die df leider nicht mehr empfehlen. Das Backend ist grundlegend immer noch extrem gut. Technisch bin ich aber mittlerweile unzufrieden und war so ein Quatsch eher von anderen Hostern gewohnt.
Ob das alles eine Entwicklung mit dem Verkauf an Hosteurope zu tun hat?

https://www.gravatar.com/avatar/2cf80c386646a2e962564c85e32bad6b?d=https%3A%2F%2Fwww.rk-mediawork.de%2Fmedia%2Fcom_rscomments%2Fimages%2Fuser.png&s=60
Interessant, wenn ich als Halblaie das grundsätzlich verstehe, mir aber die tieferen Einblicke fehlen.
Wir haben dort ein unscheinbares PHPBB3.2.9 Forum laufen. DF hat alle Verträge von "ManagedHosting Basic" auf "ManagedHosting 64 Basic" umgestellt. Für uns reichte bislang das kleinste Paket aus. Seit der Umstellung, war die Seite plötzlich nicht mehr erreichbar, endete i.d.R. in eine 502. DF hat dann Serverdienste neu gestartet, und es schien erst einmal wieder alles zu laufen. Aber immer wieder ist die Seite schwer oder gar nicht erreichbar. Dann empfiehlt DF das Upgrade zu einem größeren Paket (riecht nach ....)
Begründet es mit "in regelmäßigen Abständen die maximalen PHP Prozesse erreicht" - "zu viele Zugriffe zur gleichen Zeit stattfinden, welche in einer Abarbeitung von PHP Prozessen resultieren, können dann keine weiteren Prozesse mehr "gespawnt" werden - alle weiteren Verbindungen, welche php nutzen, müssen dann "warten"" ...
also klar eine Verschlechterun g der Leistung.

https://www.gravatar.com/avatar/c490505bbdb2239484aace59ec70c068?d=https%3A%2F%2Fwww.rk-mediawork.de%2Fmedia%2Fcom_rscomments%2Fimages%2Fuser.png&s=60
Robin
Unser neuer 64 Bit-Webserver war die Tage für 20 Minuten nicht erreichbar. Grund:
Ein künstlich gesetztes Verbindungslimi t, welches auf einer Entscheidung der Geschäftsführung basiert, und nur 600 gleichzeitige Verbindungen zulässt. Werden diese überschritt en, ist der ganze Server nicht mehr erreichbar. Und 600 gleichzeitige Verbindungen sind schneller erreicht, wie man vermuten mag. Eine nachvollziehbar e Erklärung für dieses Limit konnte man mir nicht mitteilen. Gefährlich auf einem Webservern mit vielen Kundenwebsites!

https://www.gravatar.com/avatar/e6594641bb33964d12775ca3bc5e8a0a?d=https%3A%2F%2Fwww.rk-mediawork.de%2Fmedia%2Fcom_rscomments%2Fimages%2Fuser.png&s=60
Robert
Hi Robin,

danke für den interessanten Artikel! Wir haben auch einige Probleme mit dem Tarifupgrade bei Domain Factory gehabt. Bei dem Punkt Quota muss ich allerdings sagen, dass es tatsächlich keine gute Idee ist, mehrere oder sogar alle Kundenprojekte unter einer Quota laufen zu lassen. Damit kann nämlich eine kompromittierte Seite generell Schaden auch auf den anderen Seiten anrichten, da diese in der einen Quoate auf das gesamte Dateisystem zugreifen kann. Schon alleine aus dem Grund sollte man pro Kunde zumindest eine separate Quota festlegen. Ist bei Reseller Tarifen sowieso auch der sinnvolle Weg, um die Limits im Kundentarif steuern zu können.

Viele Grüße
Robert

https://www.gravatar.com/avatar/8f1ebcfc827cd53f7d034a52b0537c4b?d=https%3A%2F%2Fwww.rk-mediawork.de%2Fmedia%2Fcom_rscomments%2Fimages%2Fuser.png&s=60
Martin
Hallo,
ich verwalte für meine Firma einen Domainfactory Account mit zwei großen Aufträgen, beide alte 32bit Tarife, einen Reseller Dedicated L4 und einen Reseller Managed Hosting Pro mit jeweils ca. 40 Webseiten (hauptsächlich Joomla u. Wordpress). Mein Plan war eigentlich aus Kostengründen und wg. PHP 7.4+ den Reseller Dedicated L4 auf einen Reseller Ded. 64 Basic umzuwandeln und mit dem anderen Server zusammenzuführen, sodass am Ende eben ein Auftrag übrig bleibt. Bin mir nach dem Lesen des Artikel allerdings unsicher, wie das mit diesen Inodes ist, auf einem Server haben wir fast keine Quotas definiert. Ich habe auch nirgends etwas über dieses Limit gelesen. Cloudflare nutzen wir allerdings nicht.

https://www.gravatar.com/avatar/c490505bbdb2239484aace59ec70c068?d=https%3A%2F%2Fwww.rk-mediawork.de%2Fmedia%2Fcom_rscomments%2Fimages%2Fuser.png&s=60
Robin
Hallo Martin,

danke für dein Kommentar.
Lasse dir von DF die Dateianzahl pro Auftrag geben und frage nach der aktuellen Grenze bei den Inodes. Daraus ergibt sich dann die Anzahl der benötigten Quotas. Leider kommuniziert DF dieses Thema nicht öffentlich.

Viele Grüße
Robin

https://www.gravatar.com/avatar/57a4ab91313c5f48fe3f84b974e4bfae?d=https%3A%2F%2Fwww.rk-mediawork.de%2Fmedia%2Fcom_rscomments%2Fimages%2Fuser.png&s=60
Martin
Hallo Robin,
ich habe heute einen Tarifwechsel von Managed Hosting Pro auf Managed Hosting Pro 64 durchführen lassen und bin soweit zufrieden, die Umstellung klappte sehr reibungslos inkl. Anpassung der Datenbank-Hosts. Die Ladezeiten der Webseiten sind gefühlt schneller und auch die Gesamtdateianza hl war in dem Fall kein Problem mit ca. 700.000 Dateien. Wobei ich jetzt ein paar Quotas eingerichtet habe, was die Anzahl natürlich verringert.
Deine Aussage stimmt allerdings nicht ganz, die Dateianzahl wird in den FAQs (https://www.df.eu/de/support/df-faq/64bit/neue-64-bit-tarife-bei-domainfactory/) öffentlich angegeben, wenn auch etwas versteckt (könnte man durchaus direkt bei den Tarifen auch angeben), bei Dedicated-Servern ist das Limit übrigens höher, nämlich 10.000.000 Inodes.
Die Server werde ich wohl getrennt lassen und den dedizierten Server in Folge auch auf ManagedHosting umwandeln, das spart die Migration und Kosten.
Soweit mein Erfahrungsberic ht zum Tarifwechsel.

https://www.gravatar.com/avatar/43e771dd88f6da673d1cd8e63184f274?d=https%3A%2F%2Fwww.rk-mediawork.de%2Fmedia%2Fcom_rscomments%2Fimages%2Fuser.png&s=60
Robert
Hi, es wäre gut zu wissen von wann dieser Artikel ist. Also Datum oder wenigstens Jahr. Wenn da "Januar" steht, bringt es auch nicht viel. Kann sein dass der Artikel nicht mehr relevant ist.
https://www.gravatar.com/avatar/c490505bbdb2239484aace59ec70c068?d=https%3A%2F%2Fwww.rk-mediawork.de%2Fmedia%2Fcom_rscomments%2Fimages%2Fuser.png&s=60
Robin
Hallo Robert,
danke für deinen Hinweis. Das ist eine gute Idee. Bisher steht das Datum nur auf der Übersicht.
Grüße
Robin

https://www.gravatar.com/avatar/c490505bbdb2239484aace59ec70c068?d=https%3A%2F%2Fwww.rk-mediawork.de%2Fmedia%2Fcom_rscomments%2Fimages%2Fuser.png&s=60
Robin
Nachtrag: Probleme bereiten auch Downloads, die auf Websites angeboten werden. Hier wird der Nutzer oft mit einer SSL-Warnung bestraft. Lösung ist dieser Befehl für die .haccess "RequestHeader unset Range". Die Notwendigkeit dieses Parameters ist abhängig von den .htaccess Regeln sowie dem Framework. Es muss also jede Seite geprüft werden ;)
Kommentareingabe ausblenden

1000 Buchstaben übrig