Hi, David Lee <[EMAIL PROTECTED]> wrote: > On Fri, 19 Oct 2007, Sebastian Reitenbach wrote: > > > after getting the port ready to compile and install smoothly on OpenBSD, > > meanwhile also tested on sparc ;) > > I recognized that I have problems to build a cluster with more than two > > nodes. First I decided to use broadcast, with a ha.cf file like this: > > [...] > > > > Multicast and broadcast work well with that configuration on openSUSE 10.2. > > I tried the unicast configuration too, but it seems heartbeat only uses one > > udpport statement for all ucast lines, is that as intended, or shouldn't it > > use different ports as configured above? > > > > I think these problems are OpenBSD specific, I am just wondering whether > > sth. like this also happens on FreeBSD or Solaris? > > > > Well, a unicast cluster between two OpenBSD nodes doesn't seem to have that > > problem. resources can be created, they migrate between the nodes, etc. > > I am unable, alas, to give anything like a solution to this. All I can do > is offer a few observations from over the years with my (more off than on) > involvement in porting (and maintaining) for some non-Linux/Intel. I hope > it might help, even if only conceptually. > > o I have never yet got BSC to pass completely on Solaris/sparc. > > o My debugging over that time has revealed many issues that are > OS-related. (Naturally I have attempted to solve these, and I had the Hg > "dev" repository in reasonable working shape during summer.) > > o That debugging has also revealed occasional sparc issues. These have > been (for instance) endian, but also occasionally alignment (Intel > tolerates 'int' (etc.) on any boundary but sparc requires alignment). The first tests on sparc I only did some months ago, without any such compiler bail outs for above reasons. On sparc, the standard compiler is only a gcc-2.95, but compiles smoothly the same way as on sparc64 and i386, with gcc-3.36. most likely you have repaired a lot of potential problems that I could have faced, with your fixes to the -dev tree mentioned above. Thanks.
> > o In your sort of situation, I would recommend (if possible) trying out > your configurations firstly on exclusively Linux/Intel (and probably just > 32-bit if possible). If your configurations fail, then there should be > plenty of resources here on "linux-ha-dev" to help fix it. Get your > configs working on Linux/Intel-32. After that is OK, then set about other > OSes and other chipsets (also being alert to 32-v-64 nuances). For > instance, starting from a "known good" three-node Linux/Intel, replace one > node with something else and see what happens. the examples above were all observed on my i386 notebook. for some reason I don't know yet, the logging is not so much on the sparcs, I need to investigate that first, but as far as I can see, they suffer the same problems. at least two node cluster between any combination of architecture, and also together with my Linux desktop seem to work well. At least the few resources I already tested. > > Hope that help you formulate a debugging strategy. I need to get xen up and running on my desktop to simulate/check the Linux behavior. > > And it's nice to know that someone else is working on Solaris/BSD/sparc. > Thanks! I like OpenBSD, and my zoo of hardware, where it's running on. I had one particular issue that the built in clustering capabilities of OpenBSD were not able to solve, and I did know linux-ha could solve the problem for me, in case I get it running. I needed unicast communication between two nodes, and thats already working for me ;) but I'm not really lucky, until the rest is working properly too. > thanks for your insights kind regards Sebastian _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
