#FlexCache

1 messages · Page 1 of 1 (latest)

autumn orbit
#

@craggy lantern Chris, are you still they goto guy for FlexCache?

craggy lantern
autumn orbit
#

Ah, thank you for responding

#

I would like to use FlexCache to transparently present long term storage from an HDD array to a flash array in and HPC grid. Any thoughts?

craggy lantern
# autumn orbit Ah, thank you for responding

Absolutely perfect use case! You can either let the HPC farm warm the data on-demand... or pre-warm the particular dataset the HPC farm is working on prior to doing to the work.

autumn orbit
#

Chris, from what I am reading, I think it would be best if I created a new SVM in my FlxC target, in the same domain as the source. My initial plans are to use an SVM and with CIFS and NFS on the target cluster and address lcoality through DFS and autofs.

My concern is that I am using Intercluster LIFS; with SM in past, if I lost a node on the source or destination, SM would not update until that node came back up. I am being told I can't have a failover for intercluster, even though in one of the TR's it has instructions on setting up a net failover group.

I can't set a FlexCache if I can't guarantee access during a node outage.

topaz patio
#

An intercluster LIF can only “failover” on the same node. It is not allowed by ONTAP to failover or even move to another node without deleting and recreating.

I run into this more often than I want to. Adding nodes to clusters then removing nodes. Can’t just move the lif. It needs to be deleted and recreated. So it goes for lifs that are of type intercluster

#

Typically, the intercluster lif will reside on a vlan that’s on an ifgrp. The ifgrp provides the local failover in case of link failure. Whenever I configure intercluster lifs, unless there are two physical ports on the box, I set the failover policy to disabled

autumn orbit
#

Yes, we talked about this yesterday. What I am saying is that FlexCache cannot be dependent on intercluster if it can lose connectivity

#

Unless I've missed something... 😦

dense moat
#

There will be no outage.
ONTAP will always use the intercluster LIFs of the node which owns the volume.
So if for example vol1 is located on aggr1 which is owned by node n1, for that volume ONTAP will only use intercluster LIFs located on ports of node n1. If n1 fails n2 will take over, aggr1 is now owned by n2 so the intercluster LIFs located on ports of n2 will be used. Same if you move the vol from aggr1 to aggr2.
That's the same with SnapMirror or FlexCache.

So there are no connectivity issues if one node fails.
You only need to make sure that all intercluster LIFs of all nodes (of your chosen ipspace) are configured in your cluster peering config.

wise prawn
#

This👆

topaz patio
#

History has shown though that replication fails during a node failure even though the partner node takes over and has an intercluster lif. That’s the concern if flexcache behaves the same as snapmirror during node failure

dense moat
#

I'm not aware of that. Also FlexCache has disconnected mode if the ICL might not be available for some seconds during takeover.

topaz patio
#

He’s got a lot of replication that happens (flexgroup related) and when a node has a failure even though the cluster is still serving data, it’s not going through scheduled snapmirror updates

autumn orbit
#

Those are my concerns exactly; thank you TMac

autumn orbit
#

Obviously we are saying the above does not seem to work, unless it was fixed in the 9.12.1/9.14.1 timeframe. Can someone verify?

autumn orbit
#

@craggy lantern Chris any further information? I'd like to stand up a test of FlexCache, but I need to guarantee it will have a failover path if a node fails.

craggy lantern
#

FlexCache always has redundant pathing in terms of Takeover/givebak. It operates like a regular volume in that regard. You have IC lifs on both nodes, and cluster peering ensures that all nodes in a cluster peer relationship are connected in a mesh pattern.