Digimer wrote: > > On 07/12/15 12:35 PM, Lentes, Bernd wrote: > > Hi, > > > > i've been asking all around here a while ago. Unfortunately I couldn't > > continue to work on my cluster, so I'm still thinking about the design. > > I hope you will help me again with some recommendations, because > when > > the cluster is running changing of the design is not possible anymore. > > > > These are my requirements: > > > > - all services are running inside virtual machines (KVM), mostly > > databases and static/dynamic webpages > > This is fine, it's what we do with our 2-node clusters. > > > - I have two nodes and would like to have some vm's running on node > A > > and some on node B during normal operation as a kind of loadbalancing > > I used to do this, but I've since stopped. The reasons are: > > 1. You need to know that one node can host all servers and still perform > properly. By always running on one node, you know that this is the case. > Further, if one node ever stops being powerful enough, you will find out > early and can address the issue immediately. > > 2. If there is a problem, you can always be sure which node to terminate > (ie: the node hosting all servers gets the fence delay, so the node > without servers will always get fenced). If you lose input power, you can > quickly power down the backup node to shed load, etc.
Hi Digimer, thanks for your reply. I don't understand what you want to say in (2). > > > - I'd like to keep the setup simple (if possible) > > There is a minimum complexity in HA, but you can get as close as > possible. We've spent years trying to simplify our VM hosting clusters as > much as possible. > > > - availability is important, performance not so much (webpages some > > hundred requests per day, databases some hundred inserts/selects > per > > day) > > All the more reason to consolidate all VMs on one host. > > > - I'd like to have snapshots of the vm's > > This is never a good idea, as you catch the state of the disk at the point of > the snapshot, but not RAM. Anything in buffers will be missed so you can > not rely on the snapshot images to always be consistent or even > functional. > > > - live migration of the vm's should be possible > > Easy enough. > > > - nodes are SLES 11 SP4, vm's are Windows 7 and severable linux > > distributions (Ubuntu, SLES, OpenSuSE) > > The OS installed on the guest VMs should not factor. As for the node OS, > SUSE invests in making sure that HA works well so you should be fine. > > > - setup should be extensible (add further vm's) > > That is entirely a question of available hardware resources. > > > - I have a shared storage (FC SAN) > > Personally, I prefer DRBD (truly replicated storage), but SAN is fine. > > > My ideas/questions: > > > > Should I install all vm's in one partition or every vm in a seperate > > partition ? The advantage of one vm per partition is that I don't need > > a cluster fs, right ? > > I would put each VM on a dedicated LV and not have an FS between the > VM and the host. The question then becomes; What is the PV? I use > clustered LVM to make sure all nodes are in sync, LVM-wise. Is this the setup you are running (without fs) ? > > > I read to avoid a cluster fs if possible because it adds further > > complexity. Below the fs I'd like to have logical volumes because they > > are easy to expand. > > Avoiding clustered FS is always preferable, yes. I use a small gfs2 > partition, but this is just for storing VM XML data, install media, etc. > Things that change rarely. Some advocate for having independent FSes > on each node and keeping the data in sync using things like rsync or what > have you. > > > Do I need cLVM (I think so) ? Is it an advantage to install the vm's > > in plain partitions, without a fs ? > > I advise it, yes. > > > It would reduce the complexity further because I don't need a fs. > > Would live migration still be possible ? > > Live migration is possible provided both nodes can see the same physical > storage at the same time. For example, DRBD dual-primary works. If you > use clustered LVM, you can be sure that the backing LVs are the same > across the nodes. And this works without a cluster fs ? But when both nodes accesses the LV concurrently (during the migration), will the data not be destroyed ? cLVM does not control concurrent access, it just cares about propagating the lvm metadata to all nodes and locking during changes of the metadata. > > > snapshots: > > I was playing around with virsh (libvirt) to create snapshots of the vm's. > > In the end I gave up. virsh explains commands in its help, but when > > you want to use them you get messages like "not supported yet", > > although I use libvirt 1.2.11. This is ridiculous. I think I will > > create my snapshots inside the vm's using lvm. > > We have a network based backup solution (Legato/EMC) which saves > the > > disks every night. > > Supplying a snapshot for that I have a consistent backup. The > > databases are dumped with their respective tools. > > > > Thanks in advance. > > I don't recommend snapshots, as I mentioned. Focus on your backup > application and create DR VMs if you want to minimize the time to > recovery after a total VM loss is what I recommend. > What do you mean with DR ? Bernd Helmholtz Zentrum Muenchen Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH) Ingolstaedter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Dr. Nikolaus Blum, Dr. Alfons Enhsen Registergericht: Amtsgericht Muenchen HRB 6466 USt-IdNr: DE 129521671 _______________________________________________ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org