Temporäre Laufzeit-Änderung bei SSL-Zertifikaten

[Rainer.D]

Wie gesagt, das klingt oft besser als das man es wirklich braucht. Selbst eine vielseitig eingesetzte JiffyBox läuft bei mir seit Jahren in gleicher Konfiguration. Es mag anders sein, wenn man Clustert und wirklich sehr wechselnde Lasten hat, aber selbst da würde ich eher weitere Nodes aufmachen als ständig das eine oder andere GB zu ändern oder an den Cores was zu drehen. In meinen Augen oft eher Spieltrieb als wahre Notwendigkeit. Das mögen andere vielleicht anders beurteilen, aber so halt meine Erfahrung.

Wenn man aber einen "virtuellen managed Server" mit gleicher Performance wie einen physischen Server bucht ist dies deutlich günstiger ohne das es irgendwelche Nachteile hat, im Gegenteil, die hohe Flexibilität ist sogar ein Vorteil. (Und natürlich die kostenfreien SSL-Zertifikate, welche bei meinen Tests alle in Frage kommenden Anbieter im Programm hatten). Bei konzeptionell guter Umsetzung ist die Ausfallsicherheit sogar größer als bei einem einezlenen Server.

Wobei man jetzt aber nicht alle Produkte in einen Topf werden darf, meine Bemerkungen beziehen sich auf den Vergleich "managed (Reseller)-Server" und "virtualisiertem managed (Reseller)-Server". Hier sehe ich bei Produkten die auf Virtualisierung basieren klare Vorteile. Jiffy-Box und "gewöhnliche" Hosting-Pakete sind ja wieder was anderes ... (Also Jiffy-Box ist natürlich auch virtualisiert, aber das sind Root-Server und nicht verglichbar mit einer "schlüsselfertigen" managd-Hosting Lösung.)

[Nils Dornblut]

Hallo Rainer,

rein technisch gesehen dürften solche Pakete eigentlich nicht anders sein als unsere aktuellen Shared Hosting Tarife. Klar, der Name suggeriert Ihnen irgendwie etwas mehr eigenes, aber auch da werden sicher die Ressourcen physischer Systeme geteilt. Wenn Sie etwas total eigenständiges wollen, braucht es eigenes Blech sozusagen und das kostet immer mehr als irgendwie geartete Virtualisierungen, wo man als Anbieter mischkalkulieren kann. Das mit der Ausfallsicherheit mag in virtualisierten Umgebungen anders lösbar sein, aber das lässt sich halt auch schwer vergleichen bzw. nachvollziehen.

Mit freundlichen Grüßen

Nils Dornblut

[Rainer.D]

Hallo Nils,

die shared hosting Tarife haben aber (bei DF) deutlich weniger Ressourcen als ein dedizierter Server und sind halt kein Server (im Sinne der Möglichkeiten). Klar, bei Virtualisierung werden Ressourcen geteilt, das kann aber so erfoglen das Arbeitsspeicher und Rechenzeit garantiert werden, dies also keinen Nachteil darstellt. Vorteile von "eigenem Blech" gibt es daher kaum noch, aber diverse Nachteile.

Ich denke schon dass physische Server ein Auslaufmodell sind, die Virtualisierungs-Lösungen sind inzwischen robust und zuverlässig, die Vortiele überwiegen.

An der Stelle kann man dies aber auch nicht weiter diskutieren, da ich mit Beispielen kommen müsste, was hier nicht möglich ist.

[wecotec]

Wie gesagt, das klingt oft besser als das man es wirklich braucht. Selbst eine vielseitig eingesetzte JiffyBox läuft bei mir seit Jahren in gleicher Konfiguration. Es mag anders sein, wenn man Clustert und wirklich sehr wechselnde Lasten hat, aber selbst da würde ich eher weitere Nodes aufmachen als ständig das eine oder andere GB zu ändern oder an den Cores was zu drehen. In meinen Augen oft eher Spieltrieb als wahre Notwendigkeit. Das mögen andere vielleicht anders beurteilen, aber so halt meine Erfahrung.

Ganz konkret machen wir immer folgendes: Wenn es mal wieder einen neuen Server gibt konfigurieren wir möglichst klein. Der Server wächst dann mit den Projekten drauf. Somit bezahlt man nur dass was man benötigt.

Klar, das geht auch bei DF wenn man Stück für den Stück den Tarif erhöht. Das ist aber dann so richtig unwirtschaftlich und nicht zu vergessen dass bei so einem Schritt immer die IP wechselt und der eigentliche Wechsel erst in der Nacht stattfindet.

[Nils Dornblut]

die shared hosting Tarife haben aber (bei DF) deutlich weniger Ressourcen als ein dedizierter Server

Die größeren Tarife bekommen schon sehr viele Ressourcen zugeteilt, ich weiß nicht, ob Sie das mal getestet haben? Bei größeren Shared Hosting Tarifen bin ich immer überrascht wie schnell Dinge laufen. Das liegt auch daran, dass es sehr hochgerüstete Systeme sind, die sich durch Teilen mit anderen Kunden dadurch auch lohnen.

und sind halt kein Server (im Sinne der Möglichkeiten).

Klar, da gibt es Unterschiede. Hier muss man schauen, was man braucht.

Klar, bei Virtualisierung werden Ressourcen geteilt, das kann aber so erfoglen das Arbeitsspeicher und Rechenzeit garantiert werden, dies also keinen Nachteil darstellt. Vorteile von "eigenem Blech" gibt es daher kaum noch, aber diverse Nachteile.

Wirkliche Garantien ohne Schlupfloch sozusagen sind teuer, weil die Systeme dann sehr teuer werden. Oft wird da doch in gewisser weise ein Sharing betrieben, wie soll es auch sonst finanziert werden.

Ich denke schon dass physische Server ein Auslaufmodell sind, die Virtualisierungs-Lösungen sind inzwischen robust und zuverlässig, die Vortiele überwiegen.

In manchen Bereichen denke ich das auch, gerade wenn der Anwendungszweck nicht so breit ist. Aber in vielen Fällen wird das auch bleiben. Ich denke, beides wird bleiben, gerade im Webhosting oder für Reseller. Auch Containerlösungen wie Docker werden werden sicher weiter wachsen. Wie immer, es gibt da kein schwarz oder weiß und wichtig als Anbieter ist hier breit aufgestellt zu sein. Von daher schauen wir mal auf die Zukunft, was noch so bei uns kommt.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

Ganz konkret machen wir immer folgendes: Wenn es mal wieder einen neuen Server gibt konfigurieren wir möglichst klein. Der Server wächst dann mit den Projekten drauf. Somit bezahlt man nur dass was man benötigt.

Klar, das geht auch bei DF wenn man Stück für den Stück den Tarif erhöht. Das ist aber dann so richtig unwirtschaftlich und nicht zu vergessen dass bei so einem Schritt immer die IP wechselt und der eigentliche Wechsel erst in der Nacht stattfindet.

Das wäre mir jetzt etwas theoretisch. Hier müssten Sie mal ein Beispiel machen, was man real da erweitert? Eine Webseite selbst, wird ja kaum in dem Sinne nach und nach in wirklich großen Schritten mehr Leistung erfordern, als dass da ein Tarif von heute auf morgen gesprengt wird. Aber ja, es mag solche Fälle geben. Wir beraten in solchen Fällen gerne und finden sicher auch für die meisten Anforderungen Lösungen. Klar, es kann auch mal auf einen Wechsel der IP hinauslaufen, was aber in vielen Fällen kein Problem darstellt, zumindest nach unserer Erfahrung.

Mit freundlichen Grüßen

Nils Dornblut

[wecotec]

Das wäre mir jetzt etwas theoretisch. Hier müssten Sie mal ein Beispiel machen, was man real da erweitert? Eine Webseite selbst, wird ja kaum in dem Sinne nach und nach in wirklich großen Schritten mehr Leistung erfordern, als dass da ein Tarif von heute auf morgen gesprengt wird. Aber ja, es mag solche Fälle geben. Wir beraten in solchen Fällen gerne und finden sicher auch für die meisten Anforderungen Lösungen. Klar, es kann auch mal auf einen Wechsel der IP hinauslaufen, was aber in vielen Fällen kein Problem darstellt, zumindest nach unserer Erfahrung.

Ich glaube ich muss ergänzen, dass ich von den Resellerservern schreibe. Wenn wir hier einen anmieten zahlen wir sofort den vollen Preis und wenn wir erweitern wollen ändert sich die IP, was gerade bei Resellern unglücklich ist da man nicht selten externe Domains einbinden muss.

Könnte man einen DF-Serverimage auf einer Jiffy-Box realisieren (warum wird das eigentlich nicht gemacht? Das wäre mal Produkt wo man "geil" denken würde) dann könnte man diesen Server preislich und leistungstechnisch entsprechend anpassen, je nachdem wieviel Projekte man draufpackt. Ohne IP-Änderung, ohne dass man sofort den vollen Preis bezahlt. Und auch das Thema "Überlastungsschutz" wäre gegessen. Keine neue IP, und vor allem keine Wartezeit.

Und natürlich kann eine Webseite von heute auf morgen den Tarif sprengen: Wir haben einen Kunden (in dem Fall sogar einen Einzelserver), dessen Auftritt (Ticketshop) zu Coronazeiten kaum genutzt wurde. Davor war immer das Problem, dass man gehofft hat, dass der Server den Ansturm standhält wenn der Kunde im Pressefocus war (was auch nicht immer planbar ist und auch hier eine Lösung die "mal eben" eine Leistungsanpassung ermöglichst toll gewesen wäre).

Ich bin etwas erstaunt, dass Sie von "theoretisch" und "mag ja solche Fälle geben" schreiben....wenn man einmal mit virtualisieren Lösungen produktiv gearbeitet hat möchte man sowas nicht mehr missen....

[Nils Dornblut]

Ich glaube ich muss ergänzen, dass ich von den Resellerservern schreibe. Wenn wir hier einen anmieten zahlen wir sofort den vollen Preis und wenn wir erweitern wollen ändert sich die IP, was gerade bei Resellern unglücklich ist da man nicht selten externe Domains einbinden muss.

Okay, akzeptiert, das ist ein entsprechender Anwendungsfall. Mal sehen was die Zukunft da noch bringt.

Könnte man einen DF-Serverimage auf einer Jiffy-Box realisieren (warum wird das eigentlich nicht gemacht? Das wäre mal Produkt wo man "geil" denken würde) dann könnte man diesen Server preislich und leistungstechnisch entsprechend anpassen, je nachdem wieviel Projekte man draufpackt. Ohne IP-Änderung, ohne dass man sofort den vollen Preis bezahlt. Und auch das Thema "Überlastungsschutz" wäre gegessen. Keine neue IP, und vor allem keine Wartezeit.

In die Richtung kann man sicher mal nachdenken. Es ist halt vom Monitoring und Support durchaus etwas anderes, wenn die Ressourcen für ein durchaus schon so recht komplexes Produkt relativ frei hin und her geändert werden können. Aber der Gedanke hat natürlich was, wenn man in Ihrem Beispiel bleibt.

Und natürlich kann eine Webseite von heute auf morgen den Tarif sprengen: Wir haben einen Kunden (in dem Fall sogar einen Einzelserver), dessen Auftritt (Ticketshop) zu Coronazeiten kaum genutzt wurde. Davor war immer das Problem, dass man gehofft hat, dass der Server den Ansturm standhält wenn der Kunde im Pressefocus war (was auch nicht immer planbar ist und auch hier eine Lösung die "mal eben" eine Leistungsanpassung ermöglichst toll gewesen wäre).

Für solche Fälle soll natürlich der Überlastungsschutz da sein und greifen. Klar so von einer Sekunde auf die andere geht das nur recht schwer, auch in vollkommen virtualisierten Umgebungen.

Mit freundlichen Grüßen

Nils Dornblut

[wecotec]

In die Richtung kann man sicher mal nachdenken. Es ist halt vom Monitoring und Support durchaus etwas anderes, wenn die Ressourcen für ein durchaus schon so recht komplexes Produkt relativ frei hin und her geändert werden können. Aber der Gedanke hat natürlich was, wenn man in Ihrem Beispiel bleibt.

Also wir nutzen inzwischen schon ein halbes Dutzend solcher Systeme und den Eindruck, dass dieses Produkt für den Anbieter komplexer ist habe ich nicht. Das mag an der Erfahrung liegen (der Hoster ist der älteste in D) oder weil man das System einfach nicht so komplex aufzieht wie DF es mit seinen Systemen tut.

Für solche Fälle soll natürlich der Überlastungsschutz da sein und greifen. Klar so von einer Sekunde auf die andere geht das nur recht schwer, auch in vollkommen virtualisierten Umgebungen.

Ich hatte das schon geschrieben: Der Überlastungsschutz scheidet bei einigen Projekten aus. Das liegt an der leidigen Änderung der IP-Adresse und daran dass der Schutz nicht sofort greift da noch ein Server umkopiert werden muss.

[rp_df]

Hallo,

nur eine kleine Anmerkung: Domainfactory bewirbt seine "inhouse" bei Konzernschwester Starfield generierten SSL-Zertifikate auf der Website aktuell mit "10.000 $ gedeckter Garantiewert¹". In der Fußnote 1 heißt es dazu nur "Gedeckter Garantiewert: gemäß Bedingungen von Starfield." Die Bedingungen sind aber nirgends verlinkt. Wenn man selbst die neuerdings wieder existente Starfield-Website googelt, dann kann man sich dort die Bedingungen noch nicht mal selbst aus dem Wust an Dokumenten heraus suchen, weil Starfield zwischen "Basic Assurance Certificates" und "Medium Assurance Certificates" differenziert. Bei domainfactory steht aber nirgends, worunter die verkauften Zertifikate fallen (Beide Varianten sind nur Domain-validiert). Mit 5stelligen Garantiewerten zu werben, ohne auch nur im Ansatz zu erklären, was da überhaupt garantiert wird, verstößt meiner Meinung nach u.a. gegen Wettbewerbsrecht.

[Nils Dornblut]

Hallo rp_df,

danke für den Hinweis. Wir prüfen das und melden uns.

Mit freundlichen Grüßen

Nils Dornblut

[wecotec]

Hallo,

nur eine kleine Anmerkung: Domainfactory bewirbt seine "inhouse" bei Konzernschwester Starfield generierten SSL-Zertifikate auf der Website aktuell mit "10.000 $ gedeckter Garantiewert¹". In der Fußnote 1 heißt es dazu nur "Gedeckter Garantiewert: gemäß Bedingungen von Starfield." Die Bedingungen sind aber nirgends verlinkt. Wenn man selbst die neuerdings wieder existente Starfield-Website googelt, dann kann man sich dort die Bedingungen noch nicht mal selbst aus dem Wust an Dokumenten heraus suchen, weil Starfield zwischen "Basic Assurance Certificates" und "Medium Assurance Certificates" differenziert. Bei domainfactory steht aber nirgends, worunter die verkauften Zertifikate fallen (Beide Varianten sind nur Domain-validiert). Mit 5stelligen Garantiewerten zu werben, ohne auch nur im Ansatz zu erklären, was da überhaupt garantiert wird, verstößt meiner Meinung nach u.a. gegen Wettbewerbsrecht.

Böse böse.....sind eigentlich Fälle bekannt wo in der Praxis der Zertifikatsinhaber auf so einen Garantiewert zurückgreifen musste? Man kann sich da natürlich einiges an Szenarien ausdenken, aber bekannt ist mir aus der Realität nichts....