Sfcache (SmartIO) volume Kstate DISABLED after SG switch over to alternate node

Hi,

Could you post the extracts of the VCS main.cf file, that shows the resources you are failing over (DG etc)

Also could you simmarise what devices you are using for the SMARTIO cache and which nodes they are located

 

thanks

tony

Hello 

The servicegroup is made of a DG with a volume on top of which resides a vxfs FS and a IP address.

The whole servicegroup is switched over the alternate node.

For now we are testing the cache on regular disk storage, each node having a dedicated local cache area.

This is noted as working in the Smartio documentation.

Brem  

 

 

Hi Brem,

So if I understood, you are currently testing the SMARTIO feature using regular SAN disk storage (non-shared).

The SMARTIO cache is intended to be used on fast host based flash devices that will provide a high speed cache. Using disk storage will not provide any real gain and may even be slower.

Is the testing to better understand how SMARTIO works ? or you intend to move this to a live/production state ?

thanks

tony

Hi Tony,

You guessed right. Actually we plan to deploy new clusters with some local Flash PCIe for caching purposes. These machines are not yet deployed, and we wanted to anticipate a bit our integration on a test cluster (deployment of SFHA 6.1, how to configure the cache, observe the behaviour, etc...)

However, it would have made sense if we were using different tiers of storage (high end SAN for the cache and  cheaper/slower  and more capacitive for the data) .

So yes it is for testing purposes currently.

Brem  

 

Thanks Brem, understood.

As for the failover aspect, is it the failover of the data disk group that you are having problems with ?

cheers

tony

No, failover of the SG (including DG, volume and FS are fine) as well as fallback work fine .

The only thing is that the cache area is not used anymore (failover and fallback).

 Rgrds

Brem 

Hi Tony.

Are you working with Read caching or write-back caching?    You mention that you are NOT using CFS, but I wanted to make sure that you are testing Read Caching pre Chapter 2 of the SmartIO for Solid State Solutions Guide for Linux.

Hello Clifford,

 

Actually it's Brem not Tony, who works with you.

We plan to use it for read caching only, as we need to maintain write consistency across sites.

 

@Tony, I think I could figure out what my problem is.

My data disk is replicated (htc agent), and when it fails over the remote site, the udid_mismatch and clone_disk flags are not cleared (actually we have a preonline trigger script for this but it's not working on this 6.1 new cluster).

Clearing manually the flags and disabling/enabling the cache for the volumes reactivates the cache.

Brem   

 

 

Hi Brem,

Looks like you have handle on the issue. As you mentioned, the data diskgroup can failover in VCS like a traditional disk group. 

The SMARTIO cache device is local to a node and cannot failover/migrate to another node. If you failover the data disk group. the SMARTIO cache device will be left on the original node.

cheers

tony