[lustre-discuss] Lustre failover configuration - Need help in selecting storage

[Cowe, Malcolm J]

Why not use a multi-ported direct attached storage (DAS) enclosure? Performance is retained and configuration is straightforward. There are a number of such enclosures available from a range of vendors, many of whom have solutions that have been qualified with Lustre.

Malcolm Cowe
High Performance Data Division
Intel Corporation | www.intel.com

From: lustre-discuss [mailto:lustre-discuss-bounces at lists.lustre.org] On Behalf Of jeevan.patnaik at wipro.com
Sent: Monday, March 14, 2016 11:37 PM
To: lustre-discuss at lists.lustre.org
Subject: [lustre-discuss] Lustre failover configuration - Need help in selecting storage



We need storage specifically for HPC Lustre failover setup, where it is must that two servers should share same block level storage to have failover configuration.

With very limited knowledge on hardware, I have the below understanding:
*         NAS can be used for shared storage, but there will be bottleneck for speed due to intermediate network.
*         SAN can be used, but it is costly to implement the solution and not really needed for Storage of 50-100TB.
*         If at all we find multiple iscsi ports to the storage enclosure, the storage can be used only by splitting i.e., works as two storage devices and the same storage can't be used by both the
systems. (And one thing to remind here, in the lustre setup, both the servers would be only attached, but only one will be used (not sure, how it is possible, again need to check on this).
*         Having two virtual machines may be how we can do it. But, then, it is not really helpful for the purpose of failover, as the physical machine would be only one.

But, while posting the question, I am thinking, maybe we can compromise on speed in NAS, if we try having one directly attached server (primary) and the other attached via network (failover), so we face slowness only when the primary stops working.

As I posted the similar question on Server Fault: http://serverfault.com/questions/763569/is-it-possible-to-have-a-directly-attached-shared-storage-accessed-at-block-lev, I have got the following response:
"Have you actually attempted to set up a proof of concept, or at least looked through the documentation<http://doc.lustre.org/lustre_manual.xhtml>? Lustre really doesn't care very much how you connect to the underlying storage, so you can do whatever gets you the bandwidth you need."

So, is it true that we don't need to worry about bandwidth of the storage server?

I mean, for example: the communication as I understood is as follows:

==>  Client <----> MGS (Ethernet)

==>  MGS <----> MGT (Direct/ISCSI)

==>  MGS <----> MDS (Ethernet/Internal Communication)

==>  MDS <----> MDT (Direct/ISCSI/Ethernet)

==>  MDS <----> OSS (Ethernet)

==>  OSS <----> OST (Direct/ISCSI/Ethernet)

==>  OST <----> Client (Ethernet)

Does it mean that, the performance won't be affected at any stage, if iscsi is replaced by Ethernet or by using limited bandwidth?








[WNC_Logo]--
Thanks and Regards,
Jeevan Patnaik B | Project Engineer
Nokia IT - HEE Platform | WIPRO Technologies - Hyderabad
Mob: +91-9000607181 | Off: +91-4030970347.

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com<http://www.wipro.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20160314/53948f6e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 25459 bytes
Desc: image001.png
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20160314/53948f6e/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 1913 bytes
Desc: image003.jpg
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20160314/53948f6e/attachment-0001.jpg>