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 <gl...@lbl.gov> wrote: > > On Wed, Dec 20, 2017 at 8:21 AM, E.S. Rosenberg < > esr+lus...@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@lists.lustre.org > http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org > >
_______________________________________________ lustre-discuss mailing list lustre-discuss@lists.lustre.org http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org