Re: RE: Nimble’s key deficiencies
Thank you so much for your opinion into the direction Nimble should take. Many large shops are on FC and have no desire to change. FC vs. iSCSI isn't as much as a performance discussion as it once was - Nimble delivers <1ms latency on iSCSI now - but sometimes we do need to addressees the top three layers (layers 8-10) of the OSI model.
For those that only are familiar with the classic seven layer model:
Layer 1: physical layer
Layer 2: data link layer
Layer 3: network layer
Layer 4: transport layer
Layer 5: session layer
Layer 6: presentation layer
Layer 7: application layer
The full model adds the business environment that solutions must exist in:
Layer 8: political layer
Layer 9: financial layer
Layer 10: religious layer
As a company gets into bigger and bigger shops and opportunities, Layers 8-10 can become barriers to entry. A classic example is the storage admin who will not allow iSCSI because IP solutions mean engaging the network team, and the storage guy thinks the network guy is a tool (Layer 8). Or the company has an existing FC implementation that it wants to leverage (Layer 9). Or the DBA insists he must have FC for mystical reasons (Layer 10)
I agree, at <1 ms latency, FC is irrelevant for most shops and iSCSI will work just fine. Adding file level protocols, on the other hand, opens a new can of worms. We have many customers deploying Nimble for file services, and the choice has usually been a native gateway server (physical or virtual) for the protocols needed. In particular, Windows 2012R2 has got REAL potential for this usage.
Call me crazy, but not until you've tested it...With well deployed multipathing on a 10 GbE iSCSI network and a Nimble CS-400 device behind it - I've seen performance that tripled the incumbent "Multi-protocol" solution that cost 5x as much as the new solution...and that solution was from one of the major players well known for their fantastic NFS product.
That customer runs on Nimble now.