Beiträge von voja

    Sollten 30% Rabatt nicht also doch mit 70% des Normalpreises angenommen werden oder der Text entsprechend richtig gestellt werden?



    Auch erwähnenswert wäre aus meiner Sicht, dass es hier nur noch die Varianten Jahresbindung und stundenbasierte Abrechnung gibt. Modelle mit Dreimonats- oder Sechsmonatsbindung kann ich nicht finden.

    [netcup] Felix P. ?

    Ich stimme Dir zu. Das sollte im Text richtig gestellt werden.


    Das es jetzt nur noch beim größten VPS monatliche Abbuchungen gibt und man ansonsten immer drei Monate bezahlt (bei der stundenbasierten Variante) finde ich auch nicht optimal. Früher war die Grenze für monatliche Zahlungen definitiv niedriger. Das fand ich immer besser um mein Budget zu kalkulieren. Bin gespannt wie das bei den Root-Servern später aussieht. Ich finde das Vorgehen immer weniger attraktiv als Kunde.

    Weiß jemand, ob es möglich ist, aus einem bestehenden Webhostingtarif heraus auf einen Tarif aus dem Osterangebot zu upgraden?

    Upgrades sind nur innerhalb einer Produktgruppe möglich. Also nein.

    Sie können zu jeder Zeit in einen höheren Tarif einer Produktklasse wechseln, vorausgesetzt folgendes ist gegeben:

    • Tarif ist innerhalb der gleichen Produktgeneration
    • Tarif ist kein Aktionsangebot
    • Die Mindestvertragslaufzeit des alten Tarifs wurde erfüllt.

    Hat schon jemand IPv6-Netze gesehen?


    Ich habe zuletzt auf größere Root-Server (mit x-fach SSD) umgestellt. Seit langem ist deshalb bei den Angeboten nichts für mich dabei. So macht Ostern keinen Spaß. ?

    So läuft das bei mir.


    Edit: IPv4 Forwarding muss hierfür aktiviert sein.

    My monitoring has reported a small packet loss or increased ping times to one IPv6 destination in NYC since yesterday late evening. Everything is back to normal since ~30 minutes. No other destinations have been affected.


    Edit: my monitoring checks are done by a Netcup root server.

    Irgendwie scheint niemand so wirklich erwähnen zu wollen das ZFS außerhalb des Solaris Kosmos einfach langsam ist und die rechtliche Frage dahinter auch noch nicht so fundierend beerdigt wurde.

    Wenn du features wie "snapshot" brauchst, bau doch einfach eine Kombination aus LVM und Btrfs.

    Proxmox hat den btrfs Support leider „postponed“. Wie soll man dann selber was kombinieren? Basteln will ich an der Stelle nicht, sondern das machen, was Proxmox vorsieht. Das schließt für mich ZFS ein. Die rechtlichen Lizenzfragen gibt es ja. Wegen Linux gab es auch schon Klagen. Ich bin Privatanwender.

    ZFS kann per Snapshot Backups erstellen.

    lvm kann das nicht, nur lvm-thin. lvm-thin möchte ich wegen dem erhöhten Monitoring aufwand nicht betreiben. Ohne das Monitoring besteht das Risiko des kompletten Datenverlusts, wenn die Metadaten durch ein volles Volume korrupt sind.


    Siehe hierzu auch https://pve.proxmox.com/wiki/Storage


    Mit meinen eignen Messungen war es auch so, dass Backups mit ZFS schneller und reibungsloser liefen. Ich hatte bei lvm über Software Raid teils massive Probleme, wenn das Raid einen Resync fahren wollte und ich in der Zeit ein Backup geplant hatte.


    Seitdem ich konsequent auf ZFS setze, hatte ich keine Probleme mehr in dieser Richtung.

    Kubernetes ist mir für privat zu schwergewichtig. Ich fahre gerade keep it simple Ansätze. Ich möchte weniger Zeit in die Administration stecken.

    Ich setze bei neuen Sachen oft auf die Proxmox Container. Die sind sehr leicht und systemD inzwischen bugfrei genug um das zu betreiben.


    Habe einen RS mit LXD auf ZFS. Der funktioniert auch gut. Da kommt jetzt noch KVM Support dazu, vielleicht ersetzt das bei mir später mal Proxmox.

    Docker verwende ich hauptsächlich für Software deren manuelle Installation und Pflege zu aufwändig ist. Was mich an Docker noch stört ist das fehlende Monitoring ob irgendwelche Software im Container veraltet ist. Das meldet mir mein Monitoring für alle lxc/lxd Container.

    Wenn man keepalived verwendet sollte jeder Node das Skript zum umrouten der Failover IP haben. Solange dann noch ein Node verfügbar ist, kann er sich die Failover IP zuweisen, wenn der Master weg ist.