Thanks Ben and Malcolm, Yes, now I have an idea what to do. I thought multiport DAS that could share a single storage on two servers is hard to find. Also, if there is any cost concern, we can still use one directly attached Primary node and Network attached Failover node.
-- Regards, Jeevan. From: Cowe, Malcolm J [mailto:[email protected]] Sent: 15 March 2016 01:58 To: Jeevan Behara Patnaik (GIS) <[email protected]>; [email protected] Subject: RE: [lustre-discuss] Lustre failover configuration - Need help in selecting storage 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<http://www.intel.com> From: Ben Evans [mailto:[email protected]] Sent: 14 March 2016 19:15 To: Jeevan Behara Patnaik (GIS) <[email protected]>; [email protected] Subject: Re: [lustre-discuss] Lustre failover configuration - Need help in selecting storage You'll only go as fast as your slowest piece. With that in mind, First figure out what sorts of bandwidth you can actually get across your chosen network type (per server). That will dictate how fast you want your storage to be. Benchmark it, make sure you can get the I/O over the wire that you think you can for that one server. Next, find a disk system that can deliver that speed for you (you'll be able to get some of the info, but you'll want to benchmark that as well, with different RAID configurations, settings, etc.). You may want to overprovision storage speed, since you probably won't be getting ideal throughput numbers. As to redundancy, there are a number of direct-attach systems that allow you to connect two servers to the same set of disks. You don't need (or really want) anything fancy like a SAN. Given the cost/performance ratios, you might also experiment with a few smaller OSTs made up of SSDs, or using something like flashcache on the MDT(s). -Ben Evans From: lustre-discuss <[email protected]<mailto:[email protected]>> on behalf of "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Monday, March 14, 2016 at 8:36 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> 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> 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
_______________________________________________ lustre-discuss mailing list [email protected] http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
