Re: best FC-storage sharing/clustering techniques
There is a summary at the end of this email, it got kinda long, and
potentially side tracked away from your original question.
> On Sep 11, Wojciech Ziniewicz illuminated :
> It would be countrywide service like youtube.pl but much more
> specialized thus - smaller.
> NFS won't do unless i would buy extra switch for "storage" layer with
> gigabit ports etc etc.
>
What you could do, and this might be outside the realms of LVS, but in
the realm of f5's kit, is split your read and write requests between
servers (url based balancing). Web traffic is mostly read only, so you
could get away with having one server have direct access to the disk,
and export that via NFS to the read only slaves. The NFS cache
algorithms will make that feasibly quick too.
The big caveat, it won't scale well with increased write requests and
would be very customised for your deployment.
Can you put the web content into a database? That is the easiest way
to scale long term. Look at yotube, livejournal, etc. Creating
clustered scalable databases is a well solved problem.
Just out of interest, how much throughput are you expecting? Tens or
hundres of megabits to your customers?
> Why I ask is that I have very bad experience with GFS and don't want
> to deploy it.
>
There are alternatives to GFS. My only experience is with QFS (a
commercial cluster filesystem from Sun), so can't comment on the
good/bad sides of GFS and the rest. I only know that they exist.
It is also possible that you had a dodgy version of GFS or a non-
optimally configured system.
> Moreover I don't have any LVS servers yet but heard that it is very
> efficient . Maybe I can cluster the servers connected to one storage
> server with LVS without using GFS/ocfs ?
>
That is a very valid option. It depends on where you want to spend the
money. For example, we have a pair of NetApp filers managing some
300,000 user's email over NFS. The business choice here, was spend the
big $$$ on the storage devices, and less on the servers and network.
The alternative was, spend more money on servers and FC fabric, and spend
less money on the storage devices. Both extremes are likely to give
similar performance, but different kinds of management headaches.
We did theorise about migrating our mail servers to fibre channel
attached storage, and then went off and cried when we started
researching the pain and agony that would be involved in managing the
cluster file system for them. The easiest option for us to upgrade, in
this particular situation, is to buy bigger NetApps.
At the end of the day, if you're clustering services using LVS, you will
need three layers of servers. and I would definitely run LVS on
different hardware from the web servers.
- LVS load balancers (two)
- Web servers (as many as you need)
- storage
> And the last question regarding LVS - is that possible to easily
> migrate from one machine with normal kernel/system to two machines
> stacked into lvs cluster ?
>
Kind of. You need to insert the LVS server between the application
server and the end users. That will involve at least a small amount of
downtime. You should be able to make that less than a minute, if you
plan the steps right though.
There are no changes that need to be made to the kernel for a server to
be managed by LVS, only network configuration updates.
################################################################################
Looking back over your original question, I am firmly of the belief that
a clustered file system will not be the right choice. At least, not yet.
It is too complex a solution that will cause grief in the future.
I think that an NFS server will provide you with more than enough
throughput to your web servers.
Deploy some LVS load balancers in front of them, and your throughput and
redundancy will be manageable.
If you can, push the web data into a database. It is much easier to
scale a database.
./jp
--
Jean-Paul Blaquiere
jeanpaul@blaquiere.id.au
http://www.blaquiere.id.au
http://japester.ucc.asn.au/
Reply to: