[ClusterLabs] [Linux-HA] Cluster for HA VM's serving our local network
j.echter at echter-kuechen-elektro.de
Wed Sep 23 12:33:01 EDT 2015
Am 23.09.2015 um 16:48 schrieb Digimer:
> On 23/09/15 10:23 AM, J. Echter wrote:
>> Hi Digimer,
>> Am 23.09.2015 um 15:38 schrieb Digimer:
>>> Hi Juergen,
>>> First; This list is deprecated and you should use the Cluster Labs -
>>> Users list (which I've cc'ed here).
>> i already got that reminder as i sent my message, and i subscribed :)
> I'm switching the thread to there then.
>>> Second; That tutorial is quite old and was replaced a while ago with
>>> this one: https://alteeve.ca/w/AN!Cluster_Tutorial_2. It has a lot of
>>> improvements we made after having many systems out in the field, so it
>>> is well worth re-doing your setup to match it. It's mostly the same, so
>>> it shouldn't be a big job.
>> i'll have a look over the new one.
> The main change, relative to this discussion, is more descriptive
> interface names.
ok, this can wait, for now. :)
>>> I'll address your comments in-line:
>>> On 23/09/15 08:38 AM, J. Echter wrote:
>>>> i was using this guide
>>>> https://alteeve.ca/w/2-Node_Red_Hat_KVM_Cluster_Tutorial_-_Archive to
>>>> set up my cluster for some services, all works pretty good.
>>>> I decided to use this cluster as a HA vm provider for my network.
>>>> I have a little, maybe silly, question.
>>>> The guide tells me to disable qemu default network, like this:
>>>>> Disable the 'qemu' Bridge
>>>>> By default, libvirtd <https://alteeve.ca/w/Libvirtd> creates a bridge
>>>>> called virbr0 designed to connect virtual machines to the first eth0
>>>>> interface. Our system will not need this, so we will remove it now.
>>>>> If libvirtd has started, skip to the next step. If you haven't started
>>>>> libvirtd yet, you can manually disable the bridge by blanking out the
>>>>> config file.
>>>>> cat /dev/null>/etc/libvirt/qemu/networks/default.xml
>>>> i skipped the step to create the bridge device, as it was not needed for
>>>> my belongings.
>>>>> vim /etc/sysconfig/network-scripts/ifcfg-vbr2
>>>>> # Internet-Facing Network - Bridge
>>>> Now i want to know how to proceed?
>>>> i have bond0 - connected to my network (both nodes got different ip's
>>>> from my dhcp)
>>>> bond1 & bond2 are used for corosync and drbd.
>>>> what would be the best decision to have some vm's served from this
>>>> 2-node cluster too?
>>> From a bridging perspective, the quoted example config above is good.
>>> The default libvirtd bridge is a NAT'ed bridge, so your VMs would get
>>> IPs in the 192.168.122.0/24 subnet, and the libvirtd bridge would route
>>> them to the outside world. Using the bridge type in the tutorial though,
>>> your VMs would appear to be directly on your network and would get (or
>>> you would assign) IPs just the same as the rest of your system.
>> so i can just use this example on my setup?
>> bond0 = LAN = 192.168.0.0/24
> This is the BCN, and is usually on 10.20.0.0/16
maybe i messed your tut a bit on my system :)
thats how i did it:
192.168.0.200 cluster (virtual ip)
192.168.0.205 mule (node1) (bond0)
192.168.0.211 bacula (node2) (bond0)
10.20.0.1 mule.bcn (bond1)
10.10.0.1 mule.sn (bond2)
10.20.0.2 bacula.bcn (bond1)
10.10.0.2 bacula.sn (bond2)
>> bridge = 10.255.0.1
> The bridge is on the IFN, which in the tutorial is on 10.255.0.0/16, so
> yes. Note that the IP assigned to the bridge has no bearing at all on
> the IPs set in the VMs.
>> can i use my own dns server, working on the lan?
>> like this:
> Sure. With this style of bridging, it's like you VMs are plugged
> directly into the physical switch. What you do on the node has no
> bearing. The only thing is that you move the IP assignment for the node
> out of the bond and into the bridge. In fact, you can assign no IP to
> the bridge and traffic from the VMs will route fine.
> So think of this bridge as being like a regular hardware switch that the
> VMs plug into and that the node itself plugs into, and the bond as the
> "cable" linking the vritual switch to the hardware switch. When you
> think of it like that, you can see how the setup of the node has no
> bearing on anything else.
ok, then i could use any free ip i like, as long i don't use it
elsewhere in my lan (openvpn, etc)
so i could use the above example as it is and it should work :)
still have to get some more network stuff into my head ;)
>>>> thanks, and please tell me what infos i may have forgotten to provide
>>>> for you. :)
>> thanks for your support.
>> Linux-HA mailing list is closing down.
>> Please subscribe to users at clusterlabs.org instead.
>> Linux-HA at lists.linux-ha.org
again, lots of thanks for your help.
More information about the Users