Highlighted

ForceImport

Hi all,

I need help to good understand attribute ForceImport.

 

There is a table "Failure situations" in Symantec Storage Foundatio and High Availability Solutions Solutions Guide. (221p.)

I don't understant situation number 7 Split-brain situation andstorage interconnect lost.

ForceImport set to 0 - No interruption of service.Can’t import with only 50% of disks available. Disks on the same node are functioning. Mirroring is not working.

ForceImport set to 1 - Automatically imports disks on secondary site. Now disks are online in both locations—data can be kept from only one.

Who can unswer this question:

"Now disks are online in both locations—data can be kept from only one" What is the purpes? What we will get if first 50% of disks will imported on 1 site and  second 50% will imported on 2 site?

 

 

 

 

 

1 Solution

Accepted Solutions
Accepted Solution!

The ForceImport is most

The ForceImport is most applicable in campus clusters when you have one or more nodes at site A in a cluster with one or more nodes at site B using a diskgroup which has mirrored volumes using an array at site A and an array at site B.

So consider the following 4 scenarios:

  1. Site A goes down
  2. Array at Site B does down
  3. SAN Fibre channel is lost between sites
  4. SAN Fibre channel and network is lost between sites

With ForceImport set to 1 the in the 4 sceanrios you have:

  1. Able to import DG on site B
  2. Still able to import DG at site A for local failover or if reboot server at site A
  3. Still able to import DG at either site - VCS will not let you import both at same time, but you could potentially write some data at site A, then fail to site B where you won't have data written at site A and you can still continue to write data at site B, so you can potentially end up having to manually merge data written at both sites or (more likely) have to discard data from one of the sites 
  4. Still able to import DG at either site and in fact in most VCS configurations, VCS will automatically import on the inactive site so you will then have DG imported on both sites, each with half of the disks, so then, as is 3, you end up having to manually merge data written at both sites or (more likely) have to discard data from one of the sites

With ForceImport set to 0 the in the 4 sceanrios you have:

  1. Not able to import DG on site B
  2. Not able to import DG at site A for local failover or if reboot server at site A
  3. Still able to import DG at either site
  4. Still able to import DG at either site

So in essence ForceImport=0 protects against your mirrored volumes writing independently to each mirror (split-brain) at the expense that you will have to take manual steps to import the diskgroup when only half the disks are available.

Personnally I always set ForceImport=1 as there are other ways to protect against split-brain such as:

a. Use GCO with ClusterFailOverPolicy = CONNECTED

b. Use Replicated Data Cluster with AutoFailOver set to 2 (manual failover acrosss sites)

c. Use PreOnline script to code your own logic as to when SG is allowed to online

d. Make DIskgroup resource dependent on IP resource in VCS, so then if public network is up between sites (even is LLT is down) the IP resource will not online if it is online on the other site and hence the diskgroup never gets to online.
 

Mike
 

View solution in original post

5 Replies

Hi Kanstantsin, With the

Hi Kanstantsin,

With the ForceImport attribute set to false, the diskgroup needs greater than 50% of the disks to online.  This is a safety item so that only one node in the cluster has a majority control of the diskgroup at a time.

With the ForceImport attribute set to True, the diskgroup can be imported with any number (greater than zero) of valid disks in the diskgroup.  This gives you the chance to have 50% or less of the diskgroup imported on a single node.  The end result is that if you had mirrored volumes you could have multiple nodes updating your volume at the same time - assuming that the each node as a complete mirror plex.  When the issue with the disks not being available is resulved, SFW will pick one plex as valid/good (usually the last one updated) and then it will resync the data from this plex to the other plex.  The result is that any data on the second plex will be lost.

This is not a setting that is recommended to make except in a true outage situation.

Let us know if you need more information on this.

FYI - In normal operations, the clustered diskgroup will automatically deport if it has less than 50% of the disks in the diskgroup available.

thank you,

Wally

Accepted Solution!

The ForceImport is most

The ForceImport is most applicable in campus clusters when you have one or more nodes at site A in a cluster with one or more nodes at site B using a diskgroup which has mirrored volumes using an array at site A and an array at site B.

So consider the following 4 scenarios:

  1. Site A goes down
  2. Array at Site B does down
  3. SAN Fibre channel is lost between sites
  4. SAN Fibre channel and network is lost between sites

With ForceImport set to 1 the in the 4 sceanrios you have:

  1. Able to import DG on site B
  2. Still able to import DG at site A for local failover or if reboot server at site A
  3. Still able to import DG at either site - VCS will not let you import both at same time, but you could potentially write some data at site A, then fail to site B where you won't have data written at site A and you can still continue to write data at site B, so you can potentially end up having to manually merge data written at both sites or (more likely) have to discard data from one of the sites 
  4. Still able to import DG at either site and in fact in most VCS configurations, VCS will automatically import on the inactive site so you will then have DG imported on both sites, each with half of the disks, so then, as is 3, you end up having to manually merge data written at both sites or (more likely) have to discard data from one of the sites

With ForceImport set to 0 the in the 4 sceanrios you have:

  1. Not able to import DG on site B
  2. Not able to import DG at site A for local failover or if reboot server at site A
  3. Still able to import DG at either site
  4. Still able to import DG at either site

So in essence ForceImport=0 protects against your mirrored volumes writing independently to each mirror (split-brain) at the expense that you will have to take manual steps to import the diskgroup when only half the disks are available.

Personnally I always set ForceImport=1 as there are other ways to protect against split-brain such as:

a. Use GCO with ClusterFailOverPolicy = CONNECTED

b. Use Replicated Data Cluster with AutoFailOver set to 2 (manual failover acrosss sites)

c. Use PreOnline script to code your own logic as to when SG is allowed to online

d. Make DIskgroup resource dependent on IP resource in VCS, so then if public network is up between sites (even is LLT is down) the IP resource will not online if it is online on the other site and hence the diskgroup never gets to online.
 

Mike
 

View solution in original post

Thank you.

Thank you.

Can you explain me solutions

Can you explain me solutions number A and D, please.

I can not find good information about GCO. How it work and What mean CONNECTED and so on. Maybe you get link to information.

 

Hi

Hi Kanstantsin,

ClusterFailoverPolicy has 3 settings: Manual (default), Connected and Auto.  Here is a summary of what each does.

 

1. Manual - failover between GCO sites is a complete manual process.  This means that a user with the correct permissions needs to log into the cluster and manually initiate a site failover/takeover of the global service groups.

2. Connected - failover between GCO sites is automatically initiated as long as the GCO heartbeat is up between the sites - AKA the GCO sites are connected to each other.  If the GCO heartbeat goes down then manual intervent by a user is needed to initiate a site takeover operation.

3. Auto - Failover between GCO sites is completely automated.  GCO will initiate a failover or a takeover of the global service groups as needed regardless of the GCO heartbeat status.  This can cause a site split brain type issue if the heartbeat link is lost between the sites as the remote site will assume the other site has failed and the remote site will attempt to online/takeover the global service group.  This is setting is not recommended.

Thank you,

Wally