• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

Jiffybox

jeddix

Member
Nachdem das df-Forum ja weiterhin dicht ist, würden mich mal die Meinungen zum derzeitigen Ausfall- und Wartungsverhalten bei Jiffyboxen interessieren.

Bei der Menge an "kurzen" Ausfällen und auch längeren Ausfällen, kann man ja kaum noch an Zufälle denken. Mit den typischen Problemen bei vServern (RAID-Controller) kann diese Flut von Nodewartungen nicht erklärt werden.
Vielleicht steht ein Audit an, wo mal alle Altlasten aufgeholt werden müssen, bevor der Audit beginnt. Oder es werden die Storagesysteme konsolidiert?
Würde man so auch nicht öffentlich schreiben wollen.
 
Meine JiffyBox läuft zum Glück ohne Probleme. War irgendwas gröberes, was ich nicht mitbekommen habe? Also außer dem Hack... :D

Die "Wartungsarbeiten" habe ich schon auf Twitter angesprochen: http://twitter.com/c_schroetter/statuses/1024835423561035776

Wenn man den RSS-Feed der Statusseite im 5-Minuten-Takt abonniert hat, sieht man eine deutliche Zunahme der "Wartungsarbeiten" seit 10. bis 20. Juli 2018. (Genaues Datum habe ich nicht im Kopf, kann erst später nachsehen.)
 
Nachdem das df-Forum ja weiterhin dicht ist, würden mich mal die Meinungen zum derzeitigen Ausfall- und Wartungsverhalten bei Jiffyboxen interessieren.

Meine ganz subjektive Meinung:
Selbst wenn ich wollte, DF würde ich im Moment nicht weiterempfehlen.
Wenn ein derart großer Anbieter das Kundenforum nun inzwischen seit fast 2 Monaten(!) offline hat, dann ist das alleine schon ein Indiz für fehlende Kompetenz...
 
Meine JiffyBox läuft zum Glück ohne Probleme. War irgendwas gröberes, was ich nicht mitbekommen habe?
Nein, lediglich die Flut an Statusmeldungswartungen. Die werden jetzt ja auch immer schneller gelöscht von der Statusseite. Mit Historie wäre das eine Sache.

Forum ist ein Punkt, wobei es ja auch Provider ohne Forum oder unbetreut gibt.
HostEurope hat das Forum völlig unbeacktert gelassen. Da war (ist?) das df-Forum natürlich schon eine andere Welt gegen.

Falls es intern bei GoDaddy Entscheidungen gibt, die das weitere Vorgehen bei df betreffen, dann wird da nicht vor Herbst entschieden. Keine Ahnung wie stark der Kundenabfluss ist. Vielleicht beschleunigt das Konsolidierungsmaßnahmen, die erst 2019 angedacht waren.

Bei Jiffybox hat HetznerCloud nun auch keine guten Argumente in Hinblick auch Stabiltität und Wartungszyklen geliefert. Auf Xen und KVM-Basis mit Features wie Jiffybox oder HetznerCloud sehe ich im deutschen Raum nichts.
Und dass noch mit höherer Ausfallsicherheit auf Hypervisorebene, wäre was.
 
Forum ist ein Punkt, wobei es ja auch Provider ohne Forum oder unbetreut gibt.
HostEurope hat das Forum völlig unbeacktert gelassen. Da war (ist?) das df-Forum natürlich schon eine andere Welt gegen.

Wir hatten ein Kundenforum für etwa 5 Jahre. Leider wurde es durch die Kunden nie wirklich genutzt. Nachdem dann der letzte Beitrag ca. 1 Jahr alt war, haben wir es vom Netz genommen. Scheinbar sind wir zu klein und die Kunden kontaktieren uns lieber direkt im Support als über ein Forum. Dadurch fällt natürlich leider das Kunden helfen Kunden weg.

Bei Jiffybox hat HetznerCloud nun auch keine guten Argumente in Hinblick auch Stabiltität und Wartungszyklen geliefert. Auf Xen und KVM-Basis mit Features wie Jiffybox oder HetznerCloud sehe ich im deutschen Raum nichts.
Und dass noch mit höherer Ausfallsicherheit auf Hypervisorebene, wäre was.

Ja, Eigenentwicklungen sind meist sehr kostenintensiv. Wir selbst haben unser vServer Panel ebenfalls selbst entwickelt auf Xen Basis. Leider sind wir vom Entwicklungsstand bzw. Funktionsumfang her nicht so weit wie Jiffybox, können aber schon sehr viel gerade das Backupkonzept ist recht ausgeklügelt :).

Anbieter die sich diesen Luxus noch leisten kann man am Markt eigentlich an einer Hand abzählen. Hetzner setzt meines Wissens auch nur auf die Proxmox API auf, was dadurch den Part der Entwicklung beim Hypervisor spart. Netcup ist denke ich noch ein Anbieter, der auch einen sehr großen Funktionsumfang im selbst entwickelten vServer Panel bietet. Ansonsten sieht man am Markt leider sehr viel SolusVM und andere fertigen Interfaces.
 
Etwas OT...

t. Ansonsten sieht man am Markt leider sehr viel SolusVM und andere fertigen Interfaces.
Hierzu muss man aber sagen dass einige fertigen Interfaces eigene Weiterentwicklungen erlauben und die entsprechenden Grundfunktionen dokumentieren. Bei SolusVM ist die Dokumentation zwar etwas dürftig ausser dem obligatorischen "Hallo Welt"-Äquivalent, man kann dennoch sehr viel Funktionalität einbringen.

Mit etwas Kreativität kann man so beispielweise blockweise deduplizierende Backup-Konzepte für das zugrunde liegende LV inklusive read-only Mount realisieren. Bei unserer Implementierung von KVM live-migration hat mir der SolusVM Support sogar bei ein paar Stellen Tipps gegeben welche Datenbank-Caches man modifizieren muss damit die Migration in Solusvm korrekt erkannt wird. Und das wohlgemerkt obwohl weder SolusVM noch die Centos7 RPMs eigentlich KVM Live-migration wirklich unterstützen wollen.

Es stellt sich immer die Frage ob zusätzliche Business-Logik wirklich im VM-Panel sinnvoll ist oder nicht eigentlich ins Billing-System ausgegliedert werden sollte. Backups oder das Hochladen/Mounten eigener Iso-Dateien gehören natürlich ins VM Panel, können dort aber mit etwas Know-How durchaus eingepflegt werden ohne dass man das Rad inklusive Achse, Holzbalken, Ochsen und Pflug neu erfinden muss.

Wenn man ein eigenes System entwerfen will, sollte man imho auf der libvirt anfangen. Eine solide und aktiv entwickelte Basis der man dann nur die eigentliche Business-Logik, APIs und die Oberflächen noch beibringen muss.
 
Kann mir mal jemand erklären, wieso man eine Jiffybox haben sollte? Die Preise sind doch bei gleicher Leistung um das 3-5x höher als alles, was die Konkurrenz (z.B. IP-Projects, Netcup, Hetzner Cloud) so aufruft.

Wenn man dann noch von so vielen Problemen von DF hört? Wieso sollte man gerade auf die Plattform setzen?

Disclaimer: ich habe einen klitzekleinen VPS bei Netcup (feines Interface) und schaue mir gerade die Hetzner Cloud an (sieht gut aus). Die beiden sind ziemlich vergleichbar. Eine Jiffybox wäre da 5x teuerer.
 
Last edited by a moderator:
Für mich ist/war der letzte Grund für eine JiffyBox das /56-Subnetz. Und eventuell die Tatsache, dass ich drei zusätzliche IPv4-Adressen zum Nulltarif habe, die nicht auf den Server gebunden sind.
 
Ah, ok, danke für den Hinweis. Ok, 3 zusätzliche IPs ist nett, auf der anderen Seite dann auch wieder: wofür? Ich brauch eigentlich IPs nur für VMs und die macht man da ja nicht drauf. Evtl könnte man Docker Container damit adressieren, wenn da Docker überhaupt drauf funktioniert.

Wenn ich mir solch einen kleinen Cloud Server hole, dann doch um genau eine Anwendung auf einer IP laufen zu haben und von anderen Anwendungen zu isolieren.
Alternativ taugen die natürlich auch zum hoch und runter skalieren und automatisierten Loadbalancen. Aber das können die anderen auch.

Da erscheinen mir nun definitiv die anderen Anbieter sinnvoller zu sein.
 
Ok, 3 zusätzliche IPs ist nett
Damit das nicht falsch rüber kommt: Allerdings erst nach einer einmaligen Einrichtungsgebühr pro IP (konnte man sich mit 50 Euro Startguthaben für Neukunden zeitweise indirekt sparen) und einer Begründung nach RIPE. Wobei Letzteres nicht sehr streng geprüft wird, soweit ich das in Erinnerung habe. Dafür ohne monatliche Kosten und beliebig auf die JiffyBoxen zuweisbar.

Aber das können die anderen auch.
Als die JiffyBox das Licht der Welt erblickte, war der Markt noch ein wenig anders. Mittlerweile stimme ich Dir voll zu: Es gibt im Jahr 2018 kaum noch einen Grund auf die JiffyBox zu setzen. Dafür ist das Produkt fast schon wieder zu unflexibel geworden.
 
Grundsätzlich finde ich das Konzept JiffyBox mal interessant. Sprich: Skalierung nach Bedarf nach oben und unten.

Für mich würden die Droplets von Digital Ocean und ansonsten natürlich die ganzen Cloudprodukte(Google Cloud Platform(GCP), Amazon Webservies(AWS), Microsoft Azure) da noch in die Kategorie fallen.

Bei den Produkten der kleineren(JiffyBox, DO Droplets) ist mit dem Resize immer auch eine Downtime verbunden.

Gibt's da noch andere Produkte/Anbieter auf dem Markt?

Bzgl. der grossen Cloud-Provider fällt mir dann noch mal das ein:
http://blog.fefe.de/?ts=a7868516 (Juni 2017)
 
Last edited by a moderator:
Ja, da gibt es eine ganze Menge abseits der "großen 3". Google, Amazon und MS sind meist deutlich teurer als die folgenden, wenn man nur einen kleinen Applikationsserver benötig (bieten dafür aber natürlich mehr drum herum wie verschiedene Regionen, spezielle Services, etc.):

Nur 1 Lokation, gutes Control Panel, 6 Monate Abrechnungsperiode:
https://www.netcup.de/vserver/vps.php

Gutes Control Panel, 3 Lokationen (einer Helsinki Finnland), stundenbasiert:
https://www.hetzner.de/cloud

Viele Lokationen, stundenbasiert:
https://www.vultr.com/pricing/

https://www.linode.com/pricing

Nur Frankreich und Niederlande als Lokationen, stundenbasiert:
https://www.scaleway.com/pricing/

Deutschland, bis zu 5 IP Adressen kostenfrei:
https://www.ip-projects.de/produkte/virtuelle-server/

Preismäßig nicht ganz konkurrenzfähig und keine stündliche Abrechnung:
https://www.ovh.de/virtual_server/vps-cloud.xml

Hier wird überall ein Resize mit einer Downtime verbunden sein. Aber

Interessant wie unterschiedlich gleich viel kostende Angebote performen können: https://joshtronic.com/2018/05/28/vps-showdown-may-2018-digitalocean-linode-vultr/ (und andere Tests des gleichen Autors)
 
Last edited by a moderator:
Grundsätzlich finde ich das Konzept JiffyBox mal interessant. Sprich: Skalierung nach Bedarf nach oben und unten.

Da das Führungsteam bei Hetzern.Cloud auch bei der Jiffybox beteiligt war, sehe ich beim Konzept durchaus Parallelen. Ein besserer vServer.
Der Begriff "Cloud" ist für eine nähere Betrachtung eher ungeeignet. Man denke nur an Cloudserver. Das kann von einer Nextcloudinstallation bis zum HA-Cluster alles sein.

Als Basis von jeglicher Cloud war mal eine Virtualisierungsschicht / Hypervisor Voraussetzung. (Telekom sieht einen Baremetalserver ohne Hypervisor auch als Cloud an https://cloud.telekom.de/de/infrastruktur/open-telekom-cloud/produkte-service/bare-metal-server )

So Dinge wie "vertikales Skalieren" ohne Downtime, sind eng mit der jeweiligen Hypervisor-Technologie verbunden.

Jiffybox Xen
HetznerCloud KVM
IP-Projects Xen
Netcup KVM

AWS KVM
GCP KVM
Azure Hyper-V

1&1 Cloud VMware
Strato CloudServer Hyper-V
Telekom OpenCloud (OpenStack ->KVM oder Xen)
SKYWAY Cloud Datacenter VMware

Interessant wäre eine Aufstellung, wer die Instanzen aus einem HA-Cluster mit anbietet. Über die Jahre war Jiffybox bei Downtime trotz einzelner Nodes (kein Cluster) recht gut. Da hatten hier andere Anbieter wesentlich mehr Probleme mit Node-Hardware (RAID Controller, I/O-Performance) und Netzwerkmanagement (DHCP Störung wird nicht bemerkt).

Die Frage ist, ob man Instanzen als vServer sehen und nutzen darf.
Teilweise wird ja vertreten, nur eine Applikation pro Instanz. Und Ausfallsicherheit hat man selber auf OS/Applikationsebene zu machen.
Dank API sollte man überhaupt alles automatisieren. Wenn downtime, dann wird alles neu erstellt oder aus dem Backup rausgezogen. Dann dauert es nicht lange, bis Container oder sogar Microservices angeführt werden. Wie die Kosten/Nutzen/Technische Schulden-Rechnung aussieht, ist je Anwendungsfall anders.

Multicloud-Ansätze dürften bei der Vielfalt der APIs und technischer Unterschiede weiterhin Reibungsverluste bringen. Sich von Amazon und Co in die hunderten von Diensten einzuarbeiten, bringt ja schon Firmen, wie PlusServer dazu, sich als Berater für AWS anzudienen. Bedenklich ist z.B., wenn Firmen wie Google,Microsoft und Amazon bereits CPatches für Intel CPU-Lücken eingespielt haben, wenn die Meldung rausgeht. Die anderen Anbieter durften dann noch ein wenig warten. Die CPU-Angriffsvektoren hätten ja eigentlich zum Ausschalten vieler Nodes führen müssen. Man fragt sich, welcher Angriffsvektor zur Einstellung "Sicherheit geht über Verfügbarkeit" führen würde.
 
Bei den Produkten der kleineren(JiffyBox, DO Droplets) ist mit dem Resize immer auch eine Downtime verbunden.
So Dinge wie "vertikales Skalieren" ohne Downtime, sind eng mit der jeweiligen Hypervisor-Technologie verbunden.

Was manche Hoster unter "Cloud" Definitionen verstehen ist schon manchmal sehr abenteuerlich.
Vertikales Skalieren ist die Königsdisziplin von Cloud-Umgebungen und das kann kaum einer wirklich gut. In den Umsetzungen sieht man bei den Hostern meist eins der folgenden
  • Upgrade+Downgrade der Ressourcen an laufender Instanz möglich (sehr kleine Auswahl an Hostern)
  • Upgrade der Ressourcen an laufender Instanz möglich, Downgrade grundsätzlich ausgeschlossen
  • Upgrade der Ressourcen an laufender Instanz möglich, Downgrade nur offline Möglich
  • Upgrade/Downgrade der Ressourcen nur über den Umweg einer neuen Instanz möglich (Zeit X mit Doppelten Kosten, Migrationsaufwand, usw.)

Viele Cloudumgebungen sind auf horizontales Skalieren ausgelegt. Das funktioniert aber halt nicht mit jeder Anwendung mal eben so. Verdammt vielen Nutzern würde es schon ausreichen, wenn sie zu Stoßzeiten einfach mal CPU und RAM aufstocken könnten um es danach wieder abzugeben, damit die Kosten im Rahmen bleiben. Viele Hoster bieten aber nur Pakete an, bei denen auch der Plattenplatz ein Upgrade erfährt und Dateisysteme online zu verkleinern können die wenigsten.


Das Telekom Produkt ist ja noch harmlos. Auf dem Niveau gabs etliche Hoster, die einfach den Hypervisor vorinstalliert haben und das einzelne Blech Cloud genannt haben. Da fallen mir mindestens noch 2 weitere Hoster ein, die sowas Rack-weise (inkl. API zum Buchen und Einschalten der Bleche) und nicht mit einzelnen Servern verkauft haben oder verkaufen wollten. Das Produkt lief bei den meisten nur nicht sonderlich gut. ;)


Die Frage ist, ob man Instanzen als vServer sehen und nutzen darf.
Viele Produkte der hier genannten Hoster sind genau das. Ein vServer, wie man ihn schon 15 Jahre im Hosting kennt. Abgesehen von ein paar wenigen Funktionen die es vor 15 Jahren noch nicht gab, haben die sich auch kaum verändert. Alles was die heute machen, ging auch damals schon. Es hat nur keiner verkauft. Das einzige was sich in den letzten Jahren geändert hat, ist das Produktdesign und wirtschaftliche Konzept dahinter. Die Technik ist immer noch die gleiche.

Man fragt sich, welcher Angriffsvektor zur Einstellung "Sicherheit geht über Verfügbarkeit" führen würde.
Aus 15 Jahren Hostingerfahrung: Keiner.
Kein einziger Hoster wird Kundensysteme wegen Sicherheitsmängeln in Masse abschalten. Die werden erst dann abgeschaltet, wenn sie gehackt sind. Bis dahin ist das das Problem des Kunden.
Kein Hoster wird sich hinstellen und die Kunden vorsorglich abschalten und dem Kunden damit ein Sonderkündigungsrecht zu ermöglichen. Macht das ein einzelner Hoster, brauch er die Systeme nie wieder hochfahren, die Kundschaft ist weg. Dann müsste das Problem schon so gravierend sein, dass sich übereinstimmend die Mehrheit der Hoster dazu entschließt, den Betrieb einzustellen. Wenn das passiert, legen wir das Internet lahm. Dann kann man sich raussuchen, ob man sich freiwillig in die Steinzeit katapultiert oder mit einer Sicherheitslücke leben möchte. In Anbetracht dessen, was wir bereits alles für aktzeptierte Sicherheitslücken haben und den geringen Auswirkungen dieser, bin ich der Meinung macht eine mehr oder weniger den Braten auch nicht fett. Wieder per Rauchzeichen kommunizieren muss ich nicht unbedingt haben.
 
Upgrade+Downgrade der Ressourcen an laufender Instanz möglich (sehr kleine Auswahl an Hostern)
Technisch ist das extrem komplex und teilweise nur mit massiven Einschränkungen möglich. Die einzigen VPS-Systeme welches dies vollumfänglich unterstützen wären OpenVZ und Consorten - also eher Isolation denn Virtualisation und mit massiven Nachteilen der Flexibilität und potentiell Sicherheit verbunden.

Theoretisch kann KVM über seinen Ballooning-Treiber RAM hotpluggen und wieder entfernen, das ist aber mit erhöhtem Ressourcenaufwand verbunden und benötigt explizite Treiberunterstützung durch den Guest sowie kann es zu sehr seltsamen Nebeneffekten führen wenn der Gast eigentlich mehr RAM will...


Dateisysteme online zu verkleinern können die wenigsten.
Das liegt aber eher daran dass lokale Dateisysteme es generell nicht können da diese nicht darauf ausgelegt sind. Es gibt Alternativlösungen mit NFS,SMB aber diese haben doch so einige Abstriche gegenüber dedizierten lokalen Dateisystemen und können auch nicht als Root-Laufwerk benutzt werden.

Flexible Applikationsumgebungen mit direkt umsetzbaren Performance-Änderungen gibt es durchaus, aber dort ist man generell nicht root (Webhosting/Application hosting environment) oder nur pseudo-root (OpenVZ & Co)
 
Anmerkung: Eine Dateisystemverkleinerung ist nicht notwendig, wenn man up- und dann wieder downgraded, solange man nach dem Upgrade das Dateisystem eben nicht vergrößert. Wenn wir Kundenserver vergrößern, dann vergrößern wir eben die Platte und nicht die Partitionen und Dateisysteme des Kunden. Ich würde als Kunde auch nicht wollen, dass mein Provider ungefragt in meinen Daten rumfummelt.
 
Ich bin lang genug in der Branche. Mir müsst ihr die technischen Gegebenheiten nicht erklären. Die kenn ich schon. Mein Beitrag war nur schon recht lang, da wollt ich nicht ganz so sehr ins Detail gehen. :D

Das man als Hoster nicht direkt das Dateisystem vergrößert ist löblich. Viele scheuen trotzdem das Downgrade, weil man halt trotzdem nie weiß, was der Kunde da getrieben hat und man dann nicht garantieren kann, dass alles heile bleibt, wenn man die virtuelle Platte wieder verkleinert.

Ich denke auch, wir brauchen uns hier nun nicht um Details streiten. Die Hälfte der User in diesem Thread vertreten offiziell einen Hoster oder sind bei einem Hoster angestellt. Die meisten kennen die leidige Realität vs. Marketing mit Cloudprodukten.
 
Ich bin lang genug in der Branche. Mir müsst ihr die technischen Gegebenheiten nicht erklären
:D Das weiss ich. Es war eher eine allgmeine Darstellung für Dritte dass es nicht schlichte Faulheit ist dass ein Anbieter so etwas nicht tun will, sondern schlicht dass er es nicht kann oder riskieren will.

Eine Dateisystemverkleinerung ist nicht notwendig, wenn man up- und dann wieder downgraded, solange man nach dem Upgrade das Dateisystem eben nicht vergrößert
Da stellt sich mir die Frage - warum geht man dann überhaupt die Festplatte vergrössern? Entweder man upgraded Speicherplatz weil man es braucht, oder man braucht es nicht und upgraded nicht :D Generell *sollte* bei einem Cloud-Angebot Speicherplatz ja unabhängig vom Arbeitsspeicher variabel sein. Einer Partitionserkennung seitens des Anbieters würde ich als Kunde höchstens bei manuell angestossenem und validierten (Offline)resize vertrauen. Es gibt dazu schlicht zu viele Varianten und zu viele Risiken.

Die meisten kennen die leidige Realität vs. Marketing mit Cloudprodukten.
Amen dazu!
In einem Forum über Server zu schreiben ist aber eh out, man tut das heute auf einer Cloud-fanpage in sozialen Netzwerken. Man weiss weder wo die Daten in der Cloud gespeichert sind, noch was mit den Daten im sozialen Netzen passiert. "A match made in heaven" :D
 
Back
Top