Mailing List Archive

On 2000-11-21T19:19:03,
huatao <thua@sei.xjtu.edu.cn> said:

> So if i have dynamic webserver content, the realservers will share one
> database or they each have one and keep them snychro? If those
> requests are mostly database related, i guess the workload will not be
> balanced very well if there is only one database. And if those
> realsevers each have a database, let's say MySQL, is it possible to
> keep them synchro?

Having a single database server in the back would be the most common setup in
this case.

Of course, if your database is the bottleneck instead of the
application/webservers, this won't help much ;-)

Synchronising multiple instances of the same database is rather difficult if
your database doesn't support it: You would need online replication for Oracle
for example.

If your database only changes once per day or so, you could use rsync to
replicate read-only copies of it to each real server after an update.

Even if you would still use a single server to keep the per user data, this
would replicate the bulk of the queries (your database content) and ease the
load on your database server considerably.

> Sorry, i think i did not make myself very clear in last letter, but
> your answer is very helpful, i can learn a lot from it as well :-)
> What i really wanted to say is how to verify those scheduling
> algorithms like rr,wrr,lc,wlc, using browser? But cache is a big
> problem when making verifications.

You can verify this using the logfiles on the real servers.

You can also just have a "hidden" document at a specific location on your real
servers with different content on each node and see whether reloading that
document gives roughly the result you expect.

Sincerely,
Lars Marowsky-Brée <lmb@suse.de>
Development HA

--
Perfection is our goal, excellence will be tolerated. -- J. Yahl

On Tue, 21 Nov 2000, huatao wrote:

> So if i have dynamic webserver content, the realservers will share one
> database or they each have one and keep them snychro?

from the next version of the HOWTO

Joe
------

6.6.2.6 Databases

Normal databaseds (eg mysqld, ie anything else but
Oracle's parallel database server for several 100k$)
running under LVS suffer the same restrictions of single
writer/many readers as does any other service where user
can write to files on the real-server (eg smtp).

Databases running independantly on several real-servers
have to be kept synchronised for content, just as do
webservers. If the database files are read-only as far
as the LVS users are concerned, and the LVS administrator
can update each copy of the database on the real-servers
at regular intervals (eg a script running at
3am) then you can run a copy of the databased on each
real-server, reading the files which you are
keeping synchronised.

Online transaction processing requires that LVS users
be able to write to the database.

If you try to do this by setting up an LVS where each real-server
has a databased and its own database files, then writes
from a particular user will go to only one of the real-servers.
The database files on the other real-servers will not
be updated and subsequent LVS users will be presented
with inconsistent copies of the database files.

The Linux Scalable Database project
http://lsdproject.sourceforge.net/ is working on code to
serialise client writes so that they can be written to all
real-servers by an intermediate agent. Their code is experimental
at the moment, but is a good prospect in the long term for
setting up multiple databased and file systems on separate
real-servers.

The next approach, of having databaseds on each real-server
accessing a common filesystem on a back-end server, fails.
Tests with mysqld running on each of two real-servers working off
the same database files mounted from a backend machine, showed that
reads were OK, but writes from any real-server either weren't seen
by the other mysqld or corrupted the database files. Presumably
each mysqld thinks it owns the database files and keeps copies
of locks and pointers. If another mysqld is updating the filesystem
at the same time then these first set of locks and pointers are invalid.

In an early attempt to setup this sort of LVS
jake buchholz <jake@execpc.com> setup an LVS'ed mysql
database with a webinterface. LVS was to serve http
and each real-server to connect to the mysqld running
on itself. Jake wanted the mysql service to be lvs'ed as
well and for each real-server to be a mysql client. The solution
was to have 2 VIPs on the director, one for http and the other
for mysqld. Each http real-server makes a mysql request to the
myqslVIP. In this case no real-server is allowed to have both
a mysqld and an httpd. A single copy of the database is nfs'ed from a
fileserver. This works for reads.

Production LVS databases, eg the service implemented by
Ryan Hulsker <RHulsker@ServiceIntelligence.com> (sample load
data at http://www.secretshopnet.com/mrtg/) have the LVS users
connect to database clients (perl scripts running under a webpage)
on each real-server. These database clients connect to a
single databased running on a backend machine that the LVS
user can't access. The databased doesn't with LVS this way,
but the user connects to the database client on the real-server
which handles the intermediate dataprocessing, increasing
your throughput.



--
Joseph Mack mack@ncifcrf.gov

> 6.6.2.6 Databases
>
> Normal databaseds (eg mysqld, ie anything else but
> Oracle's parallel database server for several 100k$)
> running under LVS suffer the same restrictions of single
> writer/many readers as does any other service where user
> can write to files on the real-server (eg smtp).

I don't know how well it works, but from what I understand, recent
versions of MySQL contain replication code that allows you to replicate
(read only, mind you) from one server to another.

Something I was considering was creating a star-like topology of MySQL
databases -- a central one which accepts writes, and the arms being
exclusively for reads.

While this obviously isn't the ideal situation -- there is a single point
of failure for writes -- it does at least allow for high availability and
load balancing for reads. When a program needs to read, connect to an LVS
balanced IP/port, which sends off to the read-only databases. When you
need to write, connect to the real IP/port of the writable database...

For some people, it might just be enough to get by...

I haven't actually tried this yet. It's a possibility though, and I'd
certainly be interested in how it works out, if someone does try it.

Thanks,

Kyle Sparger

Kyle Sparger wrote:
>
> > 6.6.2.6 Databases
> >
> > Normal databaseds (eg mysqld, ie anything else but
> > Oracle's parallel database server for several 100k$)
> > running under LVS suffer the same restrictions of single
> > writer/many readers as does any other service where user
> > can write to files on the real-server (eg smtp).
>
> I don't know how well it works, but from what I understand, recent
> versions of MySQL contain replication code that allows you to replicate
> (read only, mind you) from one server to another.
>
> Something I was considering was creating a star-like topology of MySQL
> databases -- a central one which accepts writes, and the arms being
> exclusively for reads.
>
> While this obviously isn't the ideal situation -- there is a single point
> of failure for writes -- it does at least allow for high availability and
> load balancing for reads. When a program needs to read, connect to an LVS
> balanced IP/port, which sends off to the read-only databases. When you
> need to write, connect to the real IP/port of the writable database...
>
> For some people, it might just be enough to get by...
>
> I haven't actually tried this yet. It's a possibility though, and I'd
> certainly be interested in how it works out, if someone does try it.

People are working on these style systems.

If you can tweak your DB api, you could make the masters server
redundant i.e fall back to an slave.

In order to trap any new insert/updates if the master has been down I
think you need to make the master a slve for the secondary slave.

Just my 2 pence worth.

Greg.

>
> Thanks,
>
> Kyle Sparger
>
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org
> Send requests to lvs-users-request@LinuxVirtualServer.org
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users

Kyle Sparger <ksparger@dialtoneinternet.net> writes:
> Something I was considering was creating a star-like topology of MySQL
> databases -- a central one which accepts writes, and the arms being
> exclusively for reads.

This is what we do for our web farm. We've got a custom db server
(simple berkdb databases) that runs on every webserver, and a special IP
address that maps to just the write server. We also use heartbeat to
fail over the write server address in case the primary fails.

Brian.

Hello Lars,

Tuesday, November 21, 2000, 7:30:27 PM, you wrote:

LMB> Having a single database server in the back would be the most common setup in
LMB> this case.

LMB> Of course, if your database is the bottleneck instead of the
LMB> application/webservers, this won't help much ;-)

I think i should try a single-database-server-setup first :-)

LMB> Synchronising multiple instances of the same database is rather difficult if
LMB> your database doesn't support it: You would need online replication for Oracle
LMB> for example.

LMB> If your database only changes once per day or so, you could use rsync to
LMB> replicate read-only copies of it to each real server after an update.

LMB> Even if you would still use a single server to keep the per user data, this
LMB> would replicate the bulk of the queries (your database content) and ease the
LMB> load on your database server considerably.

I could not understand this very well due to my limited knowledge
about database :-) I want to know how this could ease the load on
the database server condiserably by replicating the bulk of the
queries even if i use a single server.

Your answers are quite helpful, thank you very much.

--
Best regards,
huatao mailto:thua@sei.xjtu.edu.cn