But why do I need a #proxmox test cluster?
Well, I have #glusterfs since a few month installed, and its quite easy and straight forward (and reliable so far).
Unfortunately Proxmox will not support it anymore and therefore I need an alternative solution.
#DRBD is my candidate to go, #ceph is far to much for my #homelab..
#DRBD
Angenommen ich habe einen Host miteinem halben Dutzend #Docker Containern. Ich hätte den Host (also eigentlich die Container) gerne hochverfügbar.
Welche einfachen Lösungen bieten sich an?
Kubernetes wäre scheinbar overkill.
#Rancher? #K3s? #Portainer? Oder klassisch mit #Linux-HA und #DRBD? Oder ganz anders?
Welche einfachen Lösungen bieten sich an?
Kubernetes wäre scheinbar overkill.
#Rancher? #K3s? #Portainer? Oder klassisch mit #Linux-HA und #DRBD? Oder ganz anders?
@ij ach Kuck an. Lange nicht mehr „Open-e“ gehört. Hatte das in der Uni (2011?) im Einsatz, für #proxmox. Hatten auch so manches Problem damit, vor allem wenn sich die Conf von dem internen #DRBD zerschossen hat. Aber es lief recht lange, bis mein Nachfolger es sinnigerweise durch #ceph ersetzt hat.
Le seul point qui me chiffonne c’est la compilation du module noyau #DRBD9 même si un tout est fait pour gérer la compatibilité avec le noyau
https://linbit.com/blog/how-to-make-drbd-compatible-to-the-linux-kernel/
Mais j’ai toujours du mal avec l’installation d’une chaîne de compilation complète sur mes serveurs.
Bon, c’est gérable de façon centralisée, paquet ou distribuer le binaire par #saltstack, #ansible ou autre
#virtualisation #kvm #OpenNebula #proxmoxVE #proxmox #xen #cloudStack #linbit #linstor #DRBD #LVM #sysadmin
J’ai testé sur une petite infrastructure de test l’outil de stockage distribué #linstor basé sur #DRBD et qui s’intègre bien avec plusieurs systèmes de virtualisation
https://linbit.com/blog/comparing-open-source-cloud-virtualization-platforms/
https://linbit.com/blog/open-source-vmware-alternatives/
#virtualisation #kvm #OpenNebula #proxmoxVE #proxmox #xen #cloudStack #linbit #LVM #sysadmin
Und jetzt stellt sich die Frage, was machen. #glusterfs , oder #drbd
Geht mir um Performance und Sicherheit. Drei Server in unterschiedlichen Brandabschnitten hätte ich ja. Hmm....
I’m also curious if anyone has looked at using #DRBD with #Umbrel in general (not just for #lightning).
[ #umbrelOS #btc #bitcoin #SelfHosting ]
Anyone considered using #DRBD as the foundation of a highly available #lightning node? To me, it seems like a fairly straightforward way to mitigate a node being a single point of failure.
[ #value4value #bitcoin #btc #lnd ]
https://hackage.haskell.org/package/hnix-0.3.4
haskell implementation of nix includes #drbd by callpackage
For a new e-mail cluster that will eventually consist of a number of #IMAP servers, I need some shared storage that all servers can read from and write to at the same time. I have some experience with #DRBD, but I was told that DRBD isn't going to be the solution for what I want.
It will start small, with only several hundreds of mailboxes, but it should be able to scale up to many thousands or even hundreds of thousands in the distant future. What I want is a variable number of #Dovecot servers with an HA Director in front of them, so that I can upgrade and reboot individual nodes without users noticing.
#NFS would -on paper- be ideal, but when working with lots and lots of small files it gets very slow. #ZFS is pretty cool, but that wasn't designed as a cluster filesystem and I'm not sure if it can be made to do that reliably. I find #GlusterFS and #GFS2 in many articles, but I don't have any experience with those. I have a bit of experience with #Ceph, just enough to know that I don't want that.
What do you guys think, what is the system I should go for? And, or course, why? Did I overlook systems that are worthwhile?
It will start small, with only several hundreds of mailboxes, but it should be able to scale up to many thousands or even hundreds of thousands in the distant future. What I want is a variable number of #Dovecot servers with an HA Director in front of them, so that I can upgrade and reboot individual nodes without users noticing.
#NFS would -on paper- be ideal, but when working with lots and lots of small files it gets very slow. #ZFS is pretty cool, but that wasn't designed as a cluster filesystem and I'm not sure if it can be made to do that reliably. I find #GlusterFS and #GFS2 in many articles, but I don't have any experience with those. I have a bit of experience with #Ceph, just enough to know that I don't want that.
What do you guys think, what is the system I should go for? And, or course, why? Did I overlook systems that are worthwhile?
heise-Angebot: storage2day 2021: Open-Source-Speicher im Rechenzentrum
Einen Tag lang weiterbilden zu Open-Source-Speicher auf Commodity-Hardware – damit startet die Online-Konferenz storage2day ihr Programm 2021.
storage2day 2021: Open-Source-Speicher im Rechenzentrum
Einen Tag lang weiterbilden zu Open-Source-Speicher auf Commodity-Hardware – damit startet die Online-Konferenz storage2day ihr Programm 2021.
storage2day 2021: Open-Source-Speicher im Rechenzentrum
La virtu pour les nuls : le stockage #autohébergement #cluster #drbd #kiss #libvirt #lvm #san #stockage #tutoriels #virtualisation https://hashtagueule.fr/posts/la-virtu-pour-les-nuls-le-stockage
GNOME Packages, More Updated in Tumbleweed This Week https://news.opensuse.org/2019/07/25/gnome-packages-more-updated-in-tumbleweed-this-week/ #openSUSETumbleweed #linuxkernel5.2 #Announcements #GNOMEBuilder #python-parso #Tumbleweed #WeeklyNews #firefox68 #wireshark #darkmode #hylafax #rubygem #hwinfo #Kubic #Guile #hbogo #intel #Krita #dasd #drbd #gcc9 #gvfs #perl #vala #CVE
#LINSTOR ist nominiert in der Kategorie Open Software. Jurybegründung: @philipp_reisner@twitter.com (Autor #DRBD) hat die #OpenSource Wartungsoberfläche um Anforderungen von #Container und #Cloud Lösungen erweitert. Mehr: https://www.openminds.at/nominees-open-software-2018 @linbit@twitter.com @linuxwochen@twitter.com #OpenShift #Kubernetes
Client Info
Server: https://mastodon.social
Version: 2025.07
Repository: https://github.com/cyevgeniy/lmst