<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <?xml-stylesheet href="/s/inc/rss.xsl" type="text/xsl"?>
    <rss version="2.0"  xmlns:atom="http://www.w3.org/2005/Atom">
        <channel>
            <title>RSS feed for tag cluster on Raymii.org</title> 
            <link>https://raymii.org/s/tags/cluster.xml</link> 
            <description>RSS feed for tag cluster on Raymii.org</description>
            <atom:link href="https://raymii.org/s/tags/cluster.xml" rel="self" type="application/rss+xml" />
    
            <item>
                <title>High Available k3s kubernetes cluster with keepalived, galera and longhorn</title> 
                <link>https://raymii.org/s/tutorials/High_Available_k3s_kubernetes_cluster_with_keepalived_galera_and_longhorn.html?utm_medium=rss&amp;utm_source=raymii&amp;utm_campaign=tagrss</link> 
                <guid>https://raymii.org/s/tutorials/High_Available_k3s_kubernetes_cluster_with_keepalived_galera_and_longhorn.html</guid>
                <description> After my [first adventure with Kubernetes](/s/tutorials/My_First_Kubernetes_k3s_cluster_on_3_Orange_Pi_Zero_3s_including_k8s_dashboard_hello-node_and_failover.html), getting started with k3s on my small 3 node ARM cluster that [boots via PXE / NFS](/s/tutorials/Netboot_PXE_Armbian_on_an_Orange_Pi_Zero_3_from_SPI_with_NFS_root_filesystem.html), I noticed that there is only one k3s node that has the `control-plane,master` role. If that node fails you can no longer manager the cluster. Other nodes can fail and then the workloads (pods) will be restarted eventually after 5 minutes, but this node is special. Time to change that and make it a high available cluster.
K3s [supports](https://web.archive.org/web/20240703112841/https://docs.k3s.io/datastore/ha) high-availability with embedded `etcd` and with external databases like `MySQL` and `postgres`. `etcd` will thrash your storage (SD cards) so I decided to go with a `MySQL` cluster using `Galera` for the database and `keepalived` for the High Available Cluster IP. This guide will show you how to configure the HA database and HA-IP and I'll also setup [longhorn](https://web.archive.org/web/20240707025724/https://longhorn.io/) for high-available block storage inside kubernetes. The end result is that I can pull the power from any two of the three nodes without the k3s cluster or workloads going down. </description> 
                <pubDate>Tue, 09 Jul 2024 22:30:00 GMT</pubDate>
                <lastBuildDate>Tue, 09 Jul 2024 22:30:00 GMT</lastBuildDate>
            </item>
    
            <item>
                <title>Proxmox VE 7 Corosync QDevice in a Docker container</title> 
                <link>https://raymii.org/s/tutorials/Proxmox_VE_7_Corosync_QDevice_in_Docker.html?utm_medium=rss&amp;utm_source=raymii&amp;utm_campaign=tagrss</link> 
                <guid>https://raymii.org/s/tutorials/Proxmox_VE_7_Corosync_QDevice_in_Docker.html</guid>
                <description>At home I have a 2 node Proxmox VE cluster consisting of 2 HP EliteDesk Mini machines, both running with 16 GB RAM and both an NVMe and SATA SSD with ZFS on root (256 GB). It's small enough (physically) and is just enough for my homelab needs specs wise. Proxmox VE has support for clustering. For a cluster (in any sense of the word), you need at least 3 nodes, otherwise there is no quorum. Corosync, the cluster software used by Proxmox, supports an external Quorum device. This is a small piece of software running on a third node which provides an extra vote for the quorum. In my case I wanted to run this on my NAS, since (physical) space is a premium. The NAS supports Docker, this guide explains how to run the QDevice for Proxmox VE 7 in a Docker container. There is a qdevice Docker image on the Docker hub but that guide does not work for Proxmox VE 7 and requires a lot of manual setup. Using my method involves a lot less steps, since you're basically running an extra debian VPS (a container with systemd and openssh).</description> 
                <pubDate>Sun, 17 Apr 2022 00:00:00 GMT</pubDate>
                <lastBuildDate>Mon, 29 Jan 2024 04:30:00 GMT</lastBuildDate>
            </item>
    
            <item>
                <title>Sparkling Network</title> 
                <link>https://raymii.org/s/static/Sparkling_Network.html?utm_medium=rss&amp;utm_source=raymii&amp;utm_campaign=tagrss</link> 
                <guid>https://raymii.org/s/static/Sparkling_Network.html</guid>
                <description>This is an overview of all the servers in the Sparkling Network, mostly as an overview for myself, but it might be interesting for others. It also has a status overview of the nodes. Prices are monthly, excluding VAT.</description> 
                <pubDate>Sat, 12 Jan 2019 00:00:00 GMT</pubDate>
                <lastBuildDate>Sat, 12 Jan 2019 00:00:00 GMT</lastBuildDate>
            </item>
    
            <item>
                <title>Adding IPv6 to a keepalived and haproxy cluster</title> 
                <link>https://raymii.org/s/articles/Adding_IPv6_to_a_keepalived_and_haproxy_cluster.html?utm_medium=rss&amp;utm_source=raymii&amp;utm_campaign=tagrss</link> 
                <guid>https://raymii.org/s/articles/Adding_IPv6_to_a_keepalived_and_haproxy_cluster.html</guid>
                <description>At work I regularly build high-available clusters for customers, where the setup is distributed over multiple datacenters with failover software. If one component fails, the service doesn't experience issues or downtime due to the failure. Recently I was tasked with expanding a cluster setup to be also reachable via IPv6. This article goes over the settings and configuration required for haproxy and keepalived for IPv6. The internal cluster will only be IPv4, the loadbalancer terminates HTTP and HTTPS connections. </description> 
                <pubDate>Sun, 24 Sep 2017 00:00:00 GMT</pubDate>
                <lastBuildDate>Sun, 24 Sep 2017 00:00:00 GMT</lastBuildDate>
            </item>
    
            <item>
                <title>Nitrokey HSM/SmartCard-HSM and Raspberry Pi web cluster</title> 
                <link>https://raymii.org/s/articles/Nitrokey_HSM_web_cluster.html?utm_medium=rss&amp;utm_source=raymii&amp;utm_campaign=tagrss</link> 
                <guid>https://raymii.org/s/articles/Nitrokey_HSM_web_cluster.html</guid>
                <description>This article sets up a Nitrokey HSM/SmartCard-HSM web cluster and has a lot of benchmarks. This specific HSM is not a fast HSM since it's very inexpensive and targeted at secure key storage, not performance. But, what if you do want more performance? Then you scale horizontally, just add some more HSM's and a loadbalancer in front. The cluster consists of Raspberry Pi's and Nitrokey HSM's and SmartCard-HSM's, softwarewise we use Apache, `mod_nss` and haproxy. We benchmark a small HTML file and a Wordpress site, with a regular 4096 bit RSA certificate without using the HSM's, a regular 2048 bit RSA certificate without using the HSM's, a 2048 bit RSA certificate in the HSM, a 1024 bit RSA certificate in the HSM and an EC prime256v1 key in the HSM. We do these benchmarks with the `OpenSC` module and with the `sc-hsm-embedded` module to see if that makes any difference.</description> 
                <pubDate>Mon, 01 Aug 2016 00:00:00 GMT</pubDate>
                <lastBuildDate>Mon, 01 Aug 2016 00:00:00 GMT</lastBuildDate>
            </item>
    
            <item>
                <title>Openstack - (Manually) migrating (KVM) Nova compute virtual machines</title> 
                <link>https://raymii.org/s/articles/Openstack_-_(Manually)_migrating_(KVM)_Nova_Compute_Virtual_Machines.html?utm_medium=rss&amp;utm_source=raymii&amp;utm_campaign=tagrss</link> 
                <guid>https://raymii.org/s/articles/Openstack_-_(Manually)_migrating_(KVM)_Nova_Compute_Virtual_Machines.html</guid>
                <description>This guide shows you how to migrate KVM virtual machines with the  Openstack Nova compute service, either manually or with the Openstack tooling. Openstack provides a few different ways to migrate virtual machines from one compute node to another. Each option has different requirements and restrictions, for example, you can't live-migrate without shared storage. You can't live-migrate if you have a configdrive enabled. You can't select the target host if you use the nova migrate (non-live) command etc. This article describes the most common migration scenario's including live and manual migration using native linux tools.</description> 
                <pubDate>Sat, 13 Jun 2015 00:00:00 GMT</pubDate>
                <lastBuildDate>Sat, 13 Jun 2015 00:00:00 GMT</lastBuildDate>
            </item>
    
            <item>
                <title>Openstack Affinity Groups, make sure instances are on the same or different compute hypervisor hosts</title> 
                <link>https://raymii.org/s/articles/Openstack_Affinity_Groups-make-sure-instances-are-on-the-same-or-a-different-hypervisor-host.html?utm_medium=rss&amp;utm_source=raymii&amp;utm_campaign=tagrss</link> 
                <guid>https://raymii.org/s/articles/Openstack_Affinity_Groups-make-sure-instances-are-on-the-same-or-a-different-hypervisor-host.html</guid>
                <description>This guide shows you how to use Openstack Affinity groups. Affinity or Anti-Affinity groups allow you to make sure instances (VM/VPS) are on the same hypervisor host or on a different one. There are cases when you want two instances on different compute nodes, for example, when they are clustered servers like a load balancer or a database master-master setup. All VMs in each Affinity group are hosted in the same hypervisor, while no two VMs of a same Anti-Affinity group are hosted in the same hypervisor.</description> 
                <pubDate>Sat, 29 Nov 2014 00:00:00 GMT</pubDate>
                <lastBuildDate>Sat, 29 Nov 2014 00:00:00 GMT</lastBuildDate>
            </item>
    
            <item>
                <title>Keepalived notify script, execute action on failover</title> 
                <link>https://raymii.org/s/tutorials/Keepalived_notify_script_execute_action_on_failover.html?utm_medium=rss&amp;utm_source=raymii&amp;utm_campaign=tagrss</link> 
                <guid>https://raymii.org/s/tutorials/Keepalived_notify_script_execute_action_on_failover.html</guid>
                <description>Keepalived supports running scripts on VRRP state change. This can come in handy when you need to execute an action when a failover occurs. In my case, I have a VPN running on a Virtual IP and want to make sure the VPN only runs on the node with the Virtual IP.</description> 
                <pubDate>Sun, 26 Oct 2014 00:00:00 GMT</pubDate>
                <lastBuildDate>Sun, 26 Oct 2014 00:00:00 GMT</lastBuildDate>
            </item>
    
            <item>
                <title>Simple keepalived failover setup on Ubuntu 14.04</title> 
                <link>https://raymii.org/s/tutorials/Keepalived-Simple-IP-failover-on-Ubuntu.html?utm_medium=rss&amp;utm_source=raymii&amp;utm_campaign=tagrss</link> 
                <guid>https://raymii.org/s/tutorials/Keepalived-Simple-IP-failover-on-Ubuntu.html</guid>
                <description>We are going to set up very simple keepalived IP failover on Ubuntu 14.04. Keepalived is a piece of software which can be used to achieve high availability by assigning two or more nodes a virtual IP and monitoring those nodes, failing over when one goes down.  Keepalived can do more, like load balancing and monitoring, but this tutorial focusses on a very simple setup, just IP failover.</description> 
                <pubDate>Fri, 13 Jun 2014 00:00:00 GMT</pubDate>
                <lastBuildDate>Fri, 13 Jun 2014 00:00:00 GMT</lastBuildDate>
            </item>
    
            <item>
                <title>Corosync Pacemaker - Execute script on failover</title> 
                <link>https://raymii.org/s/tutorials/Corosync_Pacemaker_-_Execute_a_script_on_failover.html?utm_medium=rss&amp;utm_source=raymii&amp;utm_campaign=tagrss</link> 
                <guid>https://raymii.org/s/tutorials/Corosync_Pacemaker_-_Execute_a_script_on_failover.html</guid>
                <description>With Corosync/Pacemaker there is no easy way to simply run a script on failover. There are good reasons for this, but sometimes you want to do something simple. This tutorial describes how to change the Dummy OCF resource to execute a script on failover.</description> 
                <pubDate>Wed, 20 Nov 2013 00:00:00 GMT</pubDate>
                <lastBuildDate>Wed, 20 Nov 2013 00:00:00 GMT</lastBuildDate>
            </item>
    
            <item>
                <title>Corosync Notes</title> 
                <link>https://raymii.org/s/snippets/Corosync_Notes.html?utm_medium=rss&amp;utm_source=raymii&amp;utm_campaign=tagrss</link> 
                <guid>https://raymii.org/s/snippets/Corosync_Notes.html</guid>
                <description>These are my notes and command snippets for usage with Corosync.</description> 
                <pubDate>Sat, 02 Nov 2013 00:00:00 GMT</pubDate>
                <lastBuildDate>Sat, 02 Nov 2013 00:00:00 GMT</lastBuildDate>
            </item>
    
            <item>
                <title>Set up your own distributed, redundant, and encrypted storage grid with Tahoe-LAFS</title> 
                <link>https://raymii.org/s/tutorials/Tahoe_LAFS_Storage_Grid.html?utm_medium=rss&amp;utm_source=raymii&amp;utm_campaign=tagrss</link> 
                <guid>https://raymii.org/s/tutorials/Tahoe_LAFS_Storage_Grid.html</guid>
                <description>This article covers the installation and configuration of Tahoe/LAFS, a distributed, encrypted and redundant storage clustering grid.</description> 
                <pubDate>Thu, 08 Nov 2012 00:00:00 GMT</pubDate>
                <lastBuildDate>Thu, 08 Nov 2012 00:00:00 GMT</lastBuildDate>
            </item>
    
        </channel>
    </rss>
    
    