Here's a good question for the list to ponder over the holiday weekend.
We've got a new cluster system in the works. It will be a heavy lustre user;
our plan is to use lustre as the rootfs and as the primary kind of storage for
applications. I've been thinking through what configuration options we'll
need to deal with for connecting the core of the system to the storage
array(s) with the FC hba's we're qualifying, as I'm going to need to be able
to recommend at least one configuration.
It seems to me there are a couple of obvious strategies, with of course many
sub-options underneath them; those being either a bunch of essentially
point-to-point links from server nodes to storage controllers, or a more
traditional "cloud" implemented with some number of FC switches.
If one views the set of storage as one big filesystem, it's easy to think of
it sort of like a SAN and decide that the right way to set it up is to stick
some switches on the front and plug all the servers in there. But the way
lustre uses the OSTs really isn't SAN-like at all; the metaphor is really much
closer to disk drives attached to individual servers. And indeed, the
literature doesn't talk about anything mix-and-match-like, but talks about
individual (point to point) connections from the OSS's to the OST's. So to
first approximation, it seems like it's much more sensible to structure the FC
that way, ie just plug the hbas straight into the controllers (not forgetting
about criss-cross redundant connections, to support failover) and be done with
it.
A few people I've talked to (at least some from SAN backgrounds) have said
many customers will want to structure it like a SAN because that's what
they're used to thinking about. Separate from that, it's not unlikely that
will will run into situations where customers have existing SANs, which may or
may not be shared with other systems, and want to use them as the backing
store for our lustrefs.
So I'd like to hear what folks are doing.
1. Does it make sense to structure the OSS<->OST connections as point to
point links, or am I missing something?
2. Have you run into customer situations where they have an existing SAN that
they want to run lustre on?
a. If yes, what issues are involved in configuring it to appear as a
bunch of disjoint luns and get lustre set up on it?
b. If no, and they instead tend to buy dedicated storage for lustre, do
they still want to set it up like a SAN even though it isn't?
3. Starting from first principles, when talking about a new deployment, what
do you recommend, and why?
Thanks in advance, and I hope you're all home with family rather than reading
this list :-}
_______________________________________________
Lustre-discuss mailing list
[email protected]
https://mail.clusterfs.com/mailman/listinfo/lustre-discuss
