9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@9fans.net
Subject: Re: [9fans] FileServer grid
Date: Fri,  6 Feb 2009 17:53:11 -0500	[thread overview]
Message-ID: <3bcc82557341cfb928026ce6f18e7d1f@quanstro.net> (raw)
In-Reply-To: <e1d437a40902061426h1959837fsc10a8fd61ff4f3de@mail.gmail.com>

> Hello every one...
> In a context of really heavy load and high availability needs, I'm
> evaluating plan 9 to implement a fileserver grid to be used by a web server
> for temporary storage (session's serializations, for example).
>
> I'd like to build a Plan 9 grid exposing a unique filesystem mounted by all
> the web servers.
>
> Each session could be accessible from any web server instantly, but what if
> a fileserver in the grid break?
> Is there a way to mantain such a session (actually the file storing the
> session data) available by keeping it sincronized beetween the Plan 9
> fileservers?

my 2¢.

before plan 9 got a shiny osi license, i did something like this
on linux.  since it was linux, the backend server took commands
much like a scsi device does rather than use 9p.  since there
were no reasonable threading option in those days, it worked
like a task-based operating system.  we used select to schedule
work.  all state was written to disk so that the death of the server
was not fatal.  horrible, i know.  but it worked reasonably well
without declaring war on the system we needed to use.  having
two web servers would have been easy in this setup.  having
multiple back-end servers was not possible.  but neither was ever
a performance limitation for us so it remained unexplored.
this is because all the work was pushed to a cluster of workers
fronted by the backend server.  they were always the limitation.

at some level of throughput, this server would be a limitation.
i would be suprised if the limitation would not be the speed of
your network.  since the amount of traffic this server sees should
be much less than the amount of web traffic, one machine with
a 10gbe card could move a lot of data.

- erik



      parent reply	other threads:[~2009-02-06 22:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-06 22:26 Giacomo Tesio
2009-02-06 22:41 ` Roman V. Shaposhnik
2009-02-07 17:32   ` Giacomo Tesio
2009-02-07 22:57     ` Uriel
2009-02-07 23:00       ` erik quanstrom
2009-02-08  1:43         ` Uriel
2009-02-08 15:24       ` Giacomo Tesio
2009-02-08 17:12         ` ron minnich
2009-02-09  8:12           ` Giacomo Tesio
2009-02-10  3:52     ` Roman Shaposhnik
2009-02-10  8:06       ` Giacomo Tesio
2009-02-10 16:37         ` ron minnich
2009-02-10 21:41           ` Giacomo Tesio
2009-02-11  7:05             ` Skip Tavakkolian
2009-02-10 22:03         ` Roman V. Shaposhnik
2009-02-25  0:09     ` Enrico Weigelt
2009-02-06 22:53 ` erik quanstrom [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3bcc82557341cfb928026ce6f18e7d1f@quanstro.net \
    --to=quanstro@quanstro.net \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).