|
> That's the second response along those lines that I've heard regarding
> using VS-DR over VS-NAT. The reason I picked the VS-NAT method was
> because I had seen in a couple of different places in the documentation
> that VS-NAT was really the only fully-functional method at the moment.
> Maybe the LinuxVirtualServer.org website is outdated, then? VS-DR would
> actually fit our current network model better anyway.
Hm. I ne'er thought of VS-NAT being the only fully-functional method, and
I've tried to keep track of LVS for a while.
A lot of us are using VS-DR, and I think there are a good number of people
using VS-TUN as well. Tunneling and direct routing are by far going to be
the fastest and probably suit higher traffic sites a lot better. There's a
lot more latency with VS-NAT which makes it better for smaller operations.
If VS-DR would fit your network model better, go for it. I use it in a
production environment and have no problems. When setting up DR, be sure to
investigate using HIDDEN INTERFACES -- it will make things a lot easier. For
example, turn on hidden interfaces and then hide your loopback device. Bring
up a network on your loopback device and it's just like bringing up every
single IP on that network up as its own non-arping alias. It's very helpful
and easy.
However -- if you're using NT for your real servers, DR might cause you some
trouble. You're going to have to be sure you have your non-arping loopback
support setup correctly in NT.
> I could give an example output from ipvsadm -L, but it doesn't look like
> anything's running right now.... (One of the problems with diagnosing
> the problems here is that the client keeps bringing machines up and down
> behind the LVS boxes so sometimes I can't tell if the LVS is not working
> or their server has just crashed...)
If nothing really is running right now and you're still using a great amount
of files, I really cannot understand how LVS could be the one causing the
trouble.
> Also, I have a real problem in that we have confidentiality agreements
> with our client that would prevent me from giving out too much
> information. I can probably "sanitize" the output and config files and
> whatnot, but I'm not sure they would be entirely useful at that point...
I was just looking for Active/InActive connection numbers. That's all.
> That was one of my big questions. If other people are doing the same
> thing with LVS and not having these problems, then we're obviously doing
> something different where different==wrong. If other people see same
> problems, then it's just something we have to keep an eye on.
You might try going the bare-bones route and doing it all yourself without
RedHat's help.
* Install a base RH6.2 image.
* Get the latest ipvsadm tools
* Be sure the kernel is compiled with LVS support (even though it's not the
most up-to-date, it'll do just fine)
* Use raw ipvsadm to setup your LVS. See if you have the same problems.
> > Perhaps you could send us some of your configuration files? Perhaps the
> > output of some of the RedHat-HA utilities? Give us a better model of
your
> > system. Maybe someone will come up with some other ideas.
> If I can convince someone there to put some services back online, I'll
> try to get some more detailed config data. I'm also thinking about
> looking at Ultramonkey and see if a change in the toolset we're using
> clears up the problems.
A good idea.
All the best --
Ted
|
