Does the NetApp MetroCluster over IP?

NetApp MetroCluster over IP? Enthusiasts some NetApp may now cry out. It was always a law Mäßigkeit however, since year and day, that I for the NetApp MetroCluster either need long SAS cable or a fabric in the backend are got, which is exclusively for the MetroCluster available.

How is DerSchmitz only on the heretical thought that there might be a NetApp MetroCluster over IP?

It's simple. Have you a look at the current top model of NetApp times already? The A700S? Looks like the A700S from behind. Enough free PCI slots for FC-VI cards and FC cards to the wiring on the ATTO bridges. Can be!

And now we look at the sweetheart us again:

Oooops. Internal plates! That was and is not in today's Metro clusters. To ensure access to the remote disks, the controller nodes of the NetApp fabric were Metro cluster never directly with the Diskshelfs connected but via ATTO bridges and a fabric in the background. (As an example here's a 2 node fabric MetroCluster)

 

Mhh, so if the controller in the NetApp fabric Metro cluster never directly with the Diskshelfs are connected, but a fabric and ATTO bridges (or SAS cable) use, how should it then AFF with A700S work? Correct me please if I'm wrong, but between the internal plates of AFF A700S to tinker a fabric and ATTO bridges seems technically something outlandish to me.

Therefore I'm following guesses:

1. For the AFF A700S, there will be no Metro cluster functionality
   • Mhh can be of course. But to equip the flagship not with this opportunity I think for something abstruse. "Clear you can have the hottest and fastest storage NetApp, but unfortunately not as Metro clusters, go to a different model of customer" <-na will not make NetApp.
2. If I have a A700S AFF as MetroCluster wants to operate, can I use any internal disk but must attach external Diskshelfs
   • So would MetroCluster customers, one of the AFF A700S need the barrel kicking the ground. "Yes of clearly Dear customer, since you have slots in it while 24 SFF, need to buy but nevertheless shelfs" <-Nah I don't think that NetApp makes.
3. NetApp builds a MetroCluster over IP

I think my assumptions 1 and 2 very unlikely. Therefore I want to shoot a me a little on the idea, that there could be a NetApp MetroCLuster over IP.

How could a NetApp MetroCluster over IP work?

First, we should lead us envision what has made NetApp clustered DataONTAP operating system in recent years. It has switched to physical storage controller dependencies to be fully virtualized storage systems. Clustered DataONTAP contain even the word cluster. I have two storage controller heads in a chassis, so this is mostly a "switchless cluster". I have more than two nodes in a NetApp cluster, a "switched"cluster becomes so. This "switched"cluster, NetApp has delivered then your own switches. 10 GbE / 40 GbE sees itself.

Yes but what has to do with a MetroCluster over IP?

It's simple. Today, we're talking about 10 GB Ethernet, 25 GB Ethernet, 40GbE and 100 GbE! What NetApp with 10 GbE / 40 GbE Switches in the cluster get, yes still not the end of May. We now present that we could use, for example, the Clusterinterconnect switches by NetApp "to burn down the IntraCluster traffic, as well as the concluded traffic". Also in terms of the cloud, it simply fits activities by NetApp in the picture from the FC Protocol goes away and puts on an Ethernet protocol.

I imagine as follows so a MetroCluster over IP:

The controller nodes are connected via 10GbE to the NetApp ClusterSwitche and then to the customer's network. The customer is responsible for the connection between the sides with its existing infrastructure. And hence for the availability and performance.

Who remembers the architectures of HPE, EMC, DATACORE, etc now feels… Yes, that looks like where. Metro Cluster over IP with all before ins and outs.

I don't know how and if NetApp could solve the 'problem' of shared NVRAMS between the pages and controllers. Because compared to the most SyncMirror provider NetApp has always a synchronously mirrored NVRAM between the heads of the individual pages had. Competitors have mirrored most "just" the data on the plate.

To depict the actual MetroCluster function, so write to Remotedisks at great distance I could however imagine that NetApp is perhaps opts for the iSCSI Protocol.

The experience might be the basis for this that has made NetApp with "ONTAP Select". Here a "SyncMirror" is made also by iSCSI replication in an HA pair. Although only local, but who knows?

And what happens if it comes?

• So if I need more dedicated records for root Aggregrate, and for the "remote Plexe", then to ADP in the MetroCluster function Yes in theory. SO more net of the gross. This makes the MetroCluster from my point of view even more competitive.
• Hooray I'm saving me a bunch of hardware. FC back-end switches, ATTO bridges, cable, etc.

 

I look forward to your comments.