Primary Storage

1. No actual question here but not sure what A1/A2 are with SQL cluster - are they server nodes in the cluster located at A
   But sounds like A and B are separate SQL applications.... as well as being different sites A/B. Continue on that basis
2. It is valid to use separate policies A>B and B>A for the SQL applications A/B but it might be valid to use the same. Top question is which site/system do you prefer would keep operating if the comms between the two sites breaks? That is the top feature that the policy defines. As a side-effect of this the policy will also control which system you will manage the partition from in GUI and CLI
3. If you want applications A / B to run separately on sites A / B when the link breaks, then yes they must be separate partition. If they actually both (say) want to be on A then they could share a partition
4. You can reuse policies. There can be up to 4 partitions per system
5. It is a good policy to put each large application into its own partition. But you can put multiple applications into the same partition with understanding that they will all failover/failback together - which might or might not be desirable
6. See the new 870 functionality (announced this week). Volumes for A1 are accessible via the storage on either site. The host A1 can now (in 870) be configured with a 'host location' setting that describes which system is co-located with host A1 and so will be used by preference. Hosts A1 and A2 can be configured with different preferred site locations... even though each continues to have access to all volumes through both systems. Host access can swap dynamically from one site to another with no need to manage at the storage system.... it will just work on the new site.
   
7. As in 6.... SQL application can be migrated from one site to another using new servers and will be able to access with no storage management /reconfiguration required
8. n/a - no switch manual or automatic requierd
9. Host maintenance doesn't matter - doesn't need to be reflected in the volumegroup or partition design - only need to worry about application consistency for the clustered-volume-scope data
10. I don't think the question arises because there is no workflow storage admin needs to invoke to do this even for planned maintenance.
    
    Storage admin could alter the preferred location setting for a host which might swap the ALUA states but this would not impact host IO capability. Assuming hosts are zoned to both systems then that would cause host IO to start using a different system but this doesn't require SQL admin engagement.
    
    If hosts are only zoned to a single system (needs SCORE today) then shutting down a storage system will affect that host access but this would be expected.
    
    
    
    
    

1. No actual question here but not sure what A1/A2 are with SQL cluster - are they server nodes in the cluster located at A
   But sounds like A and B are separate SQL applications.... as well as being different sites A/B. Continue on that basis
2. It is valid to use separate policies A>B and B>A for the SQL applications A/B but it might be valid to use the same. Top question is which site/system do you prefer would keep operating if the comms between the two sites breaks? That is the top feature that the policy defines. As a side-effect of this the policy will also control which system you will manage the partition from in GUI and CLI
3. If you want applications A / B to run separately on sites A / B when the link breaks, then yes they must be separate partition. If they actually both (say) want to be on A then they could share a partition
4. You can reuse policies. There can be up to 4 partitions per system
5. It is a good policy to put each large application into its own partition. But you can put multiple applications into the same partition with understanding that they will all failover/failback together - which might or might not be desirable
6. See the new 870 functionality (announced this week). Volumes for A1 are accessible via the storage on either site. The host A1 can now (in 870) be configured with a 'host location' setting that describes which system is co-located with host A1 and so will be used by preference. Hosts A1 and A2 can be configured with different preferred site locations... even though each continues to have access to all volumes through both systems. Host access can swap dynamically from one site to another with no need to manage at the storage system.... it will just work on the new site.
   
7. As in 6.... SQL application can be migrated from one site to another using new servers and will be able to access with no storage management /reconfiguration required
8. n/a - no switch manual or automatic requierd
9. Host maintenance doesn't matter - doesn't need to be reflected in the volumegroup or partition design - only need to worry about application consistency for the clustered-volume-scope data
10. I don't think the question arises because there is no workflow storage admin needs to invoke to do this even for planned maintenance.
    
    Storage admin could alter the preferred location setting for a host which might swap the ALUA states but this would not impact host IO capability. Assuming hosts are zoned to both systems then that would cause host IO to start using a different system but this doesn't require SQL admin engagement.
    
    If hosts are only zoned to a single system (needs SCORE today) then shutting down a storage system will affect that host access but this would be expected.
    
    
    
    
    

• We don't use the descriptions 'production' and 'recovery' with HA - both sites are production. We only use those descriptions when discussing the PBR DR solution where the volumes have different roles
• We don't use the term immutable for the PBHA either - we often use that term for snapshots . It doesn't apply to the 870 solution.... for the 861 solution from last year we might have used the word 'standby' but that is old news now
• We tend to use the same names for objects like volumes and volumegroups... in each site... so I'll use phrase 'volume A-at-site-A' or 'A-at-A' here...

before switching the application:

• host SQL_A1 has preferred location A, volume group A1-at-A is R/W and volume group A1-at-B is R/W as well but not receiving IO
  
• host SQL_A2 has preferred location A, volume group A2-at-A is R/W and volume group A2-at-B is R/W too
  
• Both VG (A1-at-A, A2-at-A) are in same partition at site A and has the same policy.
• Both VG at site B (A1-at-B, A2-at-B) are in same partition and has the same policy.

SQL Admin needs to move the clustered SQL_A1 application to site B.

He want to avoid ISL work from the host on site B to volumes on site A so he need use A1-at-B volumes after switching.

Application SQL_A2 must continue to run on site A.

Please clarify:

After switching the application SQL_A1 to site B the application runs on new host (lets name it B_SQL_A1). 

Will it work as below? Please confirm or explain if this is wrong...

• host B_SQL_A1 has preferred location B, volume group A1-at-A remains R/W but no longer receives IO and volume group A1-at-B is R/W and now receives IO,
  
• host SQL_A2 has preferred location A, volume group A2-at-A is R/W and volume group A2-at-B is still R/W but unused,
• Both VG at site A (A1-at-A, A2-at-A) are in same partition and has the same policy.
• Both VG at site B (A1-at-B, A2-at-B) are in same partition and has the same policy.

Let me explain: the client has hundreds independent application not only 4. Some are working at site A, all others at site B. I used numbers A1, A2 to keep it simple on picture. So the challenge is have to good plan for storage since every months the SQL Admins have planned outage for host maintenance (apply patches, fixes, etc). When making change for one host/application they don't want to switch all other servers from site A to site B. And more: the storage guys tell me that they do not want be involved into server maintenance process.

1. No actual question here but not sure what A1/A2 are with SQL cluster - are they server nodes in the cluster located at A
   But sounds like A and B are separate SQL applications.... as well as being different sites A/B. Continue on that basis
2. It is valid to use separate policies A>B and B>A for the SQL applications A/B but it might be valid to use the same. Top question is which site/system do you prefer would keep operating if the comms between the two sites breaks? That is the top feature that the policy defines. As a side-effect of this the policy will also control which system you will manage the partition from in GUI and CLI
3. If you want applications A / B to run separately on sites A / B when the link breaks, then yes they must be separate partition. If they actually both (say) want to be on A then they could share a partition
4. You can reuse policies. There can be up to 4 partitions per system
5. It is a good policy to put each large application into its own partition. But you can put multiple applications into the same partition with understanding that they will all failover/failback together - which might or might not be desirable
6. See the new 870 functionality (announced this week). Volumes for A1 are accessible via the storage on either site. The host A1 can now (in 870) be configured with a 'host location' setting that describes which system is co-located with host A1 and so will be used by preference. Hosts A1 and A2 can be configured with different preferred site locations... even though each continues to have access to all volumes through both systems. Host access can swap dynamically from one site to another with no need to manage at the storage system.... it will just work on the new site.
   
7. As in 6.... SQL application can be migrated from one site to another using new servers and will be able to access with no storage management /reconfiguration required
8. n/a - no switch manual or automatic requierd
9. Host maintenance doesn't matter - doesn't need to be reflected in the volumegroup or partition design - only need to worry about application consistency for the clustered-volume-scope data
10. I don't think the question arises because there is no workflow storage admin needs to invoke to do this even for planned maintenance.
    
    Storage admin could alter the preferred location setting for a host which might swap the ALUA states but this would not impact host IO capability. Assuming hosts are zoned to both systems then that would cause host IO to start using a different system but this doesn't require SQL admin engagement.
    
    If hosts are only zoned to a single system (needs SCORE today) then shutting down a storage system will affect that host access but this would be expected.
    
    
    
    
    

• We don't use the descriptions 'production' and 'recovery' with HA - both sites are production. We only use those descriptions when discussing the PBR DR solution where the volumes have different roles
• We don't use the term immutable for the PBHA either - we often use that term for snapshots . It doesn't apply to the 870 solution.... for the 861 solution from last year we might have used the word 'standby' but that is old news now
• We tend to use the same names for objects like volumes and volumegroups... in each site... so I'll use phrase 'volume A-at-site-A' or 'A-at-A' here...

before switching the application:

• host SQL_A1 has preferred location A, volume group A1-at-A is R/W and volume group A1-at-B is R/W as well but not receiving IO
  
• host SQL_A2 has preferred location A, volume group A2-at-A is R/W and volume group A2-at-B is R/W too
  
• Both VG (A1-at-A, A2-at-A) are in same partition at site A and has the same policy.
• Both VG at site B (A1-at-B, A2-at-B) are in same partition and has the same policy.

SQL Admin needs to move the clustered SQL_A1 application to site B.

He want to avoid ISL work from the host on site B to volumes on site A so he need use A1-at-B volumes after switching.

Application SQL_A2 must continue to run on site A.

Please clarify:

After switching the application SQL_A1 to site B the application runs on new host (lets name it B_SQL_A1). 

Will it work as below? Please confirm or explain if this is wrong...

• host B_SQL_A1 has preferred location B, volume group A1-at-A remains R/W but no longer receives IO and volume group A1-at-B is R/W and now receives IO,
  
• host SQL_A2 has preferred location A, volume group A2-at-A is R/W and volume group A2-at-B is still R/W but unused,
• Both VG at site A (A1-at-A, A2-at-A) are in same partition and has the same policy.
• Both VG at site B (A1-at-B, A2-at-B) are in same partition and has the same policy.

Let me explain: the client has hundreds independent application not only 4. Some are working at site A, all others at site B. I used numbers A1, A2 to keep it simple on picture. So the challenge is have to good plan for storage since every months the SQL Admins have planned outage for host maintenance (apply patches, fixes, etc). When making change for one host/application they don't want to switch all other servers from site A to site B. And more: the storage guys tell me that they do not want be involved into server maintenance process.

1. No actual question here but not sure what A1/A2 are with SQL cluster - are they server nodes in the cluster located at A
   But sounds like A and B are separate SQL applications.... as well as being different sites A/B. Continue on that basis
2. It is valid to use separate policies A>B and B>A for the SQL applications A/B but it might be valid to use the same. Top question is which site/system do you prefer would keep operating if the comms between the two sites breaks? That is the top feature that the policy defines. As a side-effect of this the policy will also control which system you will manage the partition from in GUI and CLI
3. If you want applications A / B to run separately on sites A / B when the link breaks, then yes they must be separate partition. If they actually both (say) want to be on A then they could share a partition
4. You can reuse policies. There can be up to 4 partitions per system
5. It is a good policy to put each large application into its own partition. But you can put multiple applications into the same partition with understanding that they will all failover/failback together - which might or might not be desirable
6. See the new 870 functionality (announced this week). Volumes for A1 are accessible via the storage on either site. The host A1 can now (in 870) be configured with a 'host location' setting that describes which system is co-located with host A1 and so will be used by preference. Hosts A1 and A2 can be configured with different preferred site locations... even though each continues to have access to all volumes through both systems. Host access can swap dynamically from one site to another with no need to manage at the storage system.... it will just work on the new site.
   
7. As in 6.... SQL application can be migrated from one site to another using new servers and will be able to access with no storage management /reconfiguration required
8. n/a - no switch manual or automatic requierd
9. Host maintenance doesn't matter - doesn't need to be reflected in the volumegroup or partition design - only need to worry about application consistency for the clustered-volume-scope data
10. I don't think the question arises because there is no workflow storage admin needs to invoke to do this even for planned maintenance.
    
    Storage admin could alter the preferred location setting for a host which might swap the ALUA states but this would not impact host IO capability. Assuming hosts are zoned to both systems then that would cause host IO to start using a different system but this doesn't require SQL admin engagement.
    
    If hosts are only zoned to a single system (needs SCORE today) then shutting down a storage system will affect that host access but this would be expected.
    
    
    
    
    

• We don't use the descriptions 'production' and 'recovery' with HA - both sites are production. We only use those descriptions when discussing the PBR DR solution where the volumes have different roles
• We don't use the term immutable for the PBHA either - we often use that term for snapshots . It doesn't apply to the 870 solution.... for the 861 solution from last year we might have used the word 'standby' but that is old news now
• We tend to use the same names for objects like volumes and volumegroups... in each site... so I'll use phrase 'volume A-at-site-A' or 'A-at-A' here...

before switching the application:

• host SQL_A1 has preferred location A, volume group A1-at-A is R/W and volume group A1-at-B is R/W as well but not receiving IO
  
• host SQL_A2 has preferred location A, volume group A2-at-A is R/W and volume group A2-at-B is R/W too
  
• Both VG (A1-at-A, A2-at-A) are in same partition at site A and has the same policy.
• Both VG at site B (A1-at-B, A2-at-B) are in same partition and has the same policy.

SQL Admin needs to move the clustered SQL_A1 application to site B.

He want to avoid ISL work from the host on site B to volumes on site A so he need use A1-at-B volumes after switching.

Application SQL_A2 must continue to run on site A.

Please clarify:

After switching the application SQL_A1 to site B the application runs on new host (lets name it B_SQL_A1). 

Will it work as below? Please confirm or explain if this is wrong...

• host B_SQL_A1 has preferred location B, volume group A1-at-A remains R/W but no longer receives IO and volume group A1-at-B is R/W and now receives IO,
  
• host SQL_A2 has preferred location A, volume group A2-at-A is R/W and volume group A2-at-B is still R/W but unused,
• Both VG at site A (A1-at-A, A2-at-A) are in same partition and has the same policy.
• Both VG at site B (A1-at-B, A2-at-B) are in same partition and has the same policy.

Let me explain: the client has hundreds independent application not only 4. Some are working at site A, all others at site B. I used numbers A1, A2 to keep it simple on picture. So the challenge is have to good plan for storage since every months the SQL Admins have planned outage for host maintenance (apply patches, fixes, etc). When making change for one host/application they don't want to switch all other servers from site A to site B. And more: the storage guys tell me that they do not want be involved into server maintenance process.

1. No actual question here but not sure what A1/A2 are with SQL cluster - are they server nodes in the cluster located at A
   But sounds like A and B are separate SQL applications.... as well as being different sites A/B. Continue on that basis
2. It is valid to use separate policies A>B and B>A for the SQL applications A/B but it might be valid to use the same. Top question is which site/system do you prefer would keep operating if the comms between the two sites breaks? That is the top feature that the policy defines. As a side-effect of this the policy will also control which system you will manage the partition from in GUI and CLI
3. If you want applications A / B to run separately on sites A / B when the link breaks, then yes they must be separate partition. If they actually both (say) want to be on A then they could share a partition
4. You can reuse policies. There can be up to 4 partitions per system
5. It is a good policy to put each large application into its own partition. But you can put multiple applications into the same partition with understanding that they will all failover/failback together - which might or might not be desirable
6. See the new 870 functionality (announced this week). Volumes for A1 are accessible via the storage on either site. The host A1 can now (in 870) be configured with a 'host location' setting that describes which system is co-located with host A1 and so will be used by preference. Hosts A1 and A2 can be configured with different preferred site locations... even though each continues to have access to all volumes through both systems. Host access can swap dynamically from one site to another with no need to manage at the storage system.... it will just work on the new site.
   
7. As in 6.... SQL application can be migrated from one site to another using new servers and will be able to access with no storage management /reconfiguration required
8. n/a - no switch manual or automatic requierd
9. Host maintenance doesn't matter - doesn't need to be reflected in the volumegroup or partition design - only need to worry about application consistency for the clustered-volume-scope data
10. I don't think the question arises because there is no workflow storage admin needs to invoke to do this even for planned maintenance.
    
    Storage admin could alter the preferred location setting for a host which might swap the ALUA states but this would not impact host IO capability. Assuming hosts are zoned to both systems then that would cause host IO to start using a different system but this doesn't require SQL admin engagement.
    
    If hosts are only zoned to a single system (needs SCORE today) then shutting down a storage system will affect that host access but this would be expected.
    
    
    
    
    

• We don't use the descriptions 'production' and 'recovery' with HA - both sites are production. We only use those descriptions when discussing the PBR DR solution where the volumes have different roles
• We don't use the term immutable for the PBHA either - we often use that term for snapshots . It doesn't apply to the 870 solution.... for the 861 solution from last year we might have used the word 'standby' but that is old news now
• We tend to use the same names for objects like volumes and volumegroups... in each site... so I'll use phrase 'volume A-at-site-A' or 'A-at-A' here...

before switching the application:

• host SQL_A1 has preferred location A, volume group A1-at-A is R/W and volume group A1-at-B is R/W as well but not receiving IO
  
• host SQL_A2 has preferred location A, volume group A2-at-A is R/W and volume group A2-at-B is R/W too
  
• Both VG (A1-at-A, A2-at-A) are in same partition at site A and has the same policy.
• Both VG at site B (A1-at-B, A2-at-B) are in same partition and has the same policy.

SQL Admin needs to move the clustered SQL_A1 application to site B.

He want to avoid ISL work from the host on site B to volumes on site A so he need use A1-at-B volumes after switching.

Application SQL_A2 must continue to run on site A.

Please clarify:

After switching the application SQL_A1 to site B the application runs on new host (lets name it B_SQL_A1). 

Will it work as below? Please confirm or explain if this is wrong...

• host B_SQL_A1 has preferred location B, volume group A1-at-A remains R/W but no longer receives IO and volume group A1-at-B is R/W and now receives IO,
  
• host SQL_A2 has preferred location A, volume group A2-at-A is R/W and volume group A2-at-B is still R/W but unused,
• Both VG at site A (A1-at-A, A2-at-A) are in same partition and has the same policy.
• Both VG at site B (A1-at-B, A2-at-B) are in same partition and has the same policy.

Let me explain: the client has hundreds independent application not only 4. Some are working at site A, all others at site B. I used numbers A1, A2 to keep it simple on picture. So the challenge is have to good plan for storage since every months the SQL Admins have planned outage for host maintenance (apply patches, fixes, etc). When making change for one host/application they don't want to switch all other servers from site A to site B. And more: the storage guys tell me that they do not want be involved into server maintenance process.

1. No actual question here but not sure what A1/A2 are with SQL cluster - are they server nodes in the cluster located at A
   But sounds like A and B are separate SQL applications.... as well as being different sites A/B. Continue on that basis
2. It is valid to use separate policies A>B and B>A for the SQL applications A/B but it might be valid to use the same. Top question is which site/system do you prefer would keep operating if the comms between the two sites breaks? That is the top feature that the policy defines. As a side-effect of this the policy will also control which system you will manage the partition from in GUI and CLI
3. If you want applications A / B to run separately on sites A / B when the link breaks, then yes they must be separate partition. If they actually both (say) want to be on A then they could share a partition
4. You can reuse policies. There can be up to 4 partitions per system
5. It is a good policy to put each large application into its own partition. But you can put multiple applications into the same partition with understanding that they will all failover/failback together - which might or might not be desirable
6. See the new 870 functionality (announced this week). Volumes for A1 are accessible via the storage on either site. The host A1 can now (in 870) be configured with a 'host location' setting that describes which system is co-located with host A1 and so will be used by preference. Hosts A1 and A2 can be configured with different preferred site locations... even though each continues to have access to all volumes through both systems. Host access can swap dynamically from one site to another with no need to manage at the storage system.... it will just work on the new site.
   
7. As in 6.... SQL application can be migrated from one site to another using new servers and will be able to access with no storage management /reconfiguration required
8. n/a - no switch manual or automatic requierd
9. Host maintenance doesn't matter - doesn't need to be reflected in the volumegroup or partition design - only need to worry about application consistency for the clustered-volume-scope data
10. I don't think the question arises because there is no workflow storage admin needs to invoke to do this even for planned maintenance.
    
    Storage admin could alter the preferred location setting for a host which might swap the ALUA states but this would not impact host IO capability. Assuming hosts are zoned to both systems then that would cause host IO to start using a different system but this doesn't require SQL admin engagement.
    
    If hosts are only zoned to a single system (needs SCORE today) then shutting down a storage system will affect that host access but this would be expected.
    
    
    
    
    

• We don't use the descriptions 'production' and 'recovery' with HA - both sites are production. We only use those descriptions when discussing the PBR DR solution where the volumes have different roles
• We don't use the term immutable for the PBHA either - we often use that term for snapshots . It doesn't apply to the 870 solution.... for the 861 solution from last year we might have used the word 'standby' but that is old news now
• We tend to use the same names for objects like volumes and volumegroups... in each site... so I'll use phrase 'volume A-at-site-A' or 'A-at-A' here...

before switching the application:

• host SQL_A1 has preferred location A, volume group A1-at-A is R/W and volume group A1-at-B is R/W as well but not receiving IO
  
• host SQL_A2 has preferred location A, volume group A2-at-A is R/W and volume group A2-at-B is R/W too
  
• Both VG (A1-at-A, A2-at-A) are in same partition at site A and has the same policy.
• Both VG at site B (A1-at-B, A2-at-B) are in same partition and has the same policy.

SQL Admin needs to move the clustered SQL_A1 application to site B.

He want to avoid ISL work from the host on site B to volumes on site A so he need use A1-at-B volumes after switching.

Application SQL_A2 must continue to run on site A.

Please clarify:

After switching the application SQL_A1 to site B the application runs on new host (lets name it B_SQL_A1). 

Will it work as below? Please confirm or explain if this is wrong...

• host B_SQL_A1 has preferred location B, volume group A1-at-A remains R/W but no longer receives IO and volume group A1-at-B is R/W and now receives IO,
  
• host SQL_A2 has preferred location A, volume group A2-at-A is R/W and volume group A2-at-B is still R/W but unused,
• Both VG at site A (A1-at-A, A2-at-A) are in same partition and has the same policy.
• Both VG at site B (A1-at-B, A2-at-B) are in same partition and has the same policy.

Let me explain: the client has hundreds independent application not only 4. Some are working at site A, all others at site B. I used numbers A1, A2 to keep it simple on picture. So the challenge is have to good plan for storage since every months the SQL Admins have planned outage for host maintenance (apply patches, fixes, etc). When making change for one host/application they don't want to switch all other servers from site A to site B. And more: the storage guys tell me that they do not want be involved into server maintenance process.

1. No actual question here but not sure what A1/A2 are with SQL cluster - are they server nodes in the cluster located at A
   But sounds like A and B are separate SQL applications.... as well as being different sites A/B. Continue on that basis
2. It is valid to use separate policies A>B and B>A for the SQL applications A/B but it might be valid to use the same. Top question is which site/system do you prefer would keep operating if the comms between the two sites breaks? That is the top feature that the policy defines. As a side-effect of this the policy will also control which system you will manage the partition from in GUI and CLI
3. If you want applications A / B to run separately on sites A / B when the link breaks, then yes they must be separate partition. If they actually both (say) want to be on A then they could share a partition
4. You can reuse policies. There can be up to 4 partitions per system
5. It is a good policy to put each large application into its own partition. But you can put multiple applications into the same partition with understanding that they will all failover/failback together - which might or might not be desirable
6. See the new 870 functionality (announced this week). Volumes for A1 are accessible via the storage on either site. The host A1 can now (in 870) be configured with a 'host location' setting that describes which system is co-located with host A1 and so will be used by preference. Hosts A1 and A2 can be configured with different preferred site locations... even though each continues to have access to all volumes through both systems. Host access can swap dynamically from one site to another with no need to manage at the storage system.... it will just work on the new site.
   
7. As in 6.... SQL application can be migrated from one site to another using new servers and will be able to access with no storage management /reconfiguration required
8. n/a - no switch manual or automatic requierd
9. Host maintenance doesn't matter - doesn't need to be reflected in the volumegroup or partition design - only need to worry about application consistency for the clustered-volume-scope data
10. I don't think the question arises because there is no workflow storage admin needs to invoke to do this even for planned maintenance.
    
    Storage admin could alter the preferred location setting for a host which might swap the ALUA states but this would not impact host IO capability. Assuming hosts are zoned to both systems then that would cause host IO to start using a different system but this doesn't require SQL admin engagement.
    
    If hosts are only zoned to a single system (needs SCORE today) then shutting down a storage system will affect that host access but this would be expected.