HPE Nimble dHCI versus Nimble in pure HPE environment

[parnassus]

Hi all, pardon the question (not an expert about HPE Nimble and HPE storage in general) but I'm dealing with an all HPE based proposal (a cluster of four HPE ProLiant DL380 Gen10 Plus servers, an HPE Nimble AF40 storage to host VMs - not for backup - two HPE SN3600B SAN Switches and Aruba CX 8360 switch series ToR/Core VSX clustered switches for the Ethernet side), all backed by a fresh new VMware 7.0 U2 infrastructure.

Now my simple question: I've read about HPE Nimble dHCI and I though it would fit nicely in the proposal but wasn't offered by the VAR/Integrator (don't know if the current HPE Nimble AF40 price tag would change significantly or not), so what are the pros/cons of using HPE Nimble dHCI versus a plain HPE Nimble? are their deployment models different?

Will asking for a quotation's revision - with the HPE Nimble dHCI instead of the plain HPE Nimble - require a major change in the already proposed SAN/LAN architecture (I'm thinking especially about the SAN FibreChannel connectivity bewteen Servers and the Storage via SAN Fabrics swithces) or the HPE Nimble dHCI would fit the scenario with the same storage role and SAN FC connetivity it was proposed with?

What benefits/restrictions would the IT group managing such solution have by dealing with HPE Nimble dHCI versus HPE Nimble in spite of that scenario?

[Muru123]

Hi,

Nimble Storage dHCI is a Hyper Converged (HCI)/Converged Infrastructure (CI) system, comprised of Nimble Storage, HPE Proliant servers, VMware vSphere and vCenter, HPE InfoSight, and HPE/Aruba switch choices. Hyper-converged infrastructure enables compute, storage and networking functions to be decoupled from the underlying infrastructure.

Considering the customer's all HPE requirement, going with dHCI would be the better option as managing the infrastructure would be simple. With dHCI, customer can achieve below:

> Simple & fast setup wizard to connect to vCenter®, discover/add servers, provision datastores (VMFS/vVols)

> vCenter plugin for centralized solution management, monitoring, expansion

> Infosight (Nimble Storage dHCI view) for full stack analytics, wellness integration with Proliant servers

> Dynamically scale compute and storage capacity

You can also refer to the below blog for more information about dHCI.

https://community.hpe.com/t5/Around-the-Storage-Block/Top-5-reasons-why-HPE-Nimble-Storage-dHCI-is-so-popular/ba-p/7145350#.YUGV_J0zaF4

[SprinkleJames · Accepted solution]

Hello parnassus,

Nimble Storage dHCI definitely has some benefits - mainly the ease of server additions/updates, and the support of the entire swtiches/servers/storage stack via Nimble's outstanding support model.

There are some restrictions with dHCI, such as:

• only being able to manage a single dHCI host cluster
• "one-click" update functionality requires vSphere DRS, and is limited to pre-qualified catalog of software/firmware version combinations

In regards to your question on the SAN switches, Nimble Storage dHCI currently does not support Fibre Channel SAN. It is iSCSI only. You can run the iSCSI network with your LAN on the Aruba 8360 switches, or on separate switches. If you want a separate iSCSI network with dedicated switches, I suggest going all 25Gb with HPE SN2010M switches. The M-Series are some of the lowest latency switches around for Ethernet storage networks.

[parnassus]

Hello @SprinkleJames, thanks for answering. Your explanation cleared all my doubts.

Basically (at least currently) a new proposal have been requested to pinpoint that, moving to HPE Nimble Storage dHCI, would require to rethink storage-to-hosts connectivity (iSCSI) instead of using the more or less traditional FibreChannel SAN approach. At this point we can't ask such type of a revision (we are short in time) and it's a pity.

Very interesting the part about the HPE StoreFabric SN2010M Switch series to setup a physical separated network between Hosts and Storage (I presume the very same network could be setup also using some Aruba 83xx Switch series, especially those with 10/25 ports). Are there technical whitepapers or best practices guides about this part (HPE M-Series with HPE Nimble dHCI)? I know that some configuration guides touch the HPE Nimble and Aruba 83xx pairing.

The cheaper alternative would be to use (segregated) portion of frontend network (again with Aruba 83xx Switch series) to serve the connectiviy between Hosts and Storage but, I believe, this scenario shouldn't be too much encouraged. 

[SprinkleJames]

Hi @parnassus,

A physically separate, redundant SAN switch infrastructure is certainly advantageous in some ways. I typically encourage it, even in smaller environments.

If you have switches dedicated to iSCSI, and design for a separate iSCSI subnet per switch, you don't even need to stack or ISL them. This is similar to a traditional FC SAN infrastructure with redundant FabricA/FabricB switches.

Check out the HPE Storage dHCI and VMware vSphere New Servers Deployment Guide. It has some configuration examples for HPE M-Series, Aruba, and FlexFabric switches, as well as Cisco Nexus switches. It presumes you're converging your LAN/SAN on the same switches, but you can adjust it for dedicated SAN switches too.

[parnassus]

Hi @SprinkleJames, your explanation is absolutely crystal clear and I found particularly interesting the part "If you have switches dedicated to iSCSI, and design for a separate iSCSI subnet per switch, you don't even need to stack or ISL them. This is similar to a traditional FC SAN infrastructure with redundant FabricA/FabricB switches." indeed we are used to deploy and manage medium/large FC SAN infrastructures with redundant Fabrics (A|B) - mostly with IBM hardware - to the point that we understood that, if you decouple the "frontside" of the Network (where the adoption of VSX, IRFC or MC-LAGs approaches is perfectly reasonable) from the "backside" of the Network (from Hosts to Storage), then on this latter part of the network (say the "storage side") is not required the very same approach used on the former one (host to clients) and this island made of ethernet switches "dedicated to Storage" can be kept isolated also at switch level (so no VSX, IRF or MC-LAGs technologies) as it happens with redundant SAN Fabrics when Fabric A is physically separated by Fabric B.

Quite nice the deployment guide you referenced, thanks a lot!