[lustre-discuss] Designing a new Lustre system

[John Bent]

Last I looked at Isilon, it serializes parallel writes to a single file.
Ultimately, the data is striped across multiple data servers but it all
channels through a single data server.  If you only have file-per-process
workloads, and you have a lot of money, then Isilon is considered a solid
enterprise solution.

On Thu, Dec 21, 2017 at 7:15 PM, Glenn Lockwood <glock at lbl.gov> wrote:

>
> On Wed, Dec 20, 2017 at 8:21 AM, E.S. Rosenberg <
> esr+lustre at mail.hebrew.edu> wrote:
>
>>
>> 4. One of my colleagues likes Isilon very much, I have not been able to
>> find any literature on if/how Lustre compares any pointers/knowledge on the
>> subject is very welcome.
>>
>>
> I haven't looked at Isilon in a while, but my recollection was that
>
> 1. It's phenomenally expensive, especially at smaller scales.  This is the
> most obvious detractor vs. Lustre, especially at low node counts.
>
> 2. It's completely proprietary and architecturally complex, so management
> and support model is difficult to shape into existing operations.  There
> are also cost implications here.
>
> 3. It uses NFS for transport, so it doesn't offer POSIX consistency
> between clients.  This makes shared-file parallel I/O extremely hazardous.
>
> In my experience, Isilon is popular in markets flush with money but scarce
> in institutional storage expertise.  In such cases, #1 and #2 are
> non-issues, and #3 often doesn't apply because such industries' workloads
> are throughput-oriented and rarely use MPI.
>
> Glenn
>
> _______________________________________________
> lustre-discuss mailing list
> lustre-discuss at lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20171221/6871f954/attachment-0001.html>