Risk of assigning disks in a loop to two controllers

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Risk of assigning disks in a loop to two controllers

BERNTSEN Basil

Hi folks,

 

I have a CDOT 8.2 system (in prod) where new shelves were installed on a SAS stack on the wrong node. I want to create an aggregate on node1, but the disks are on node2. Based on the guidelines, I'm thinking of delaying the aggregate creation and changing the shelves.

 

My question is whether it's worth the delay. What are the risks of just assigning the disks to the partner of the node they're currently assigned to? The documentation says to "Always assign all disks on the same loop or stack to the same system." Why?

 

Thanks!

 

Basil

************************************************************************* 
This message and any attachments (the "message") are confidential, intended solely for the addressee(s), and may contain legally privileged information.  Any unauthorized use or dissemination is prohibited. E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. Please visit http://sgasdisclosure.com for important information regarding SG Americas Securities, LLC (“SGAS”). Please visit http://swapdisclosure.sgcib.com for important information regarding swap transactions with SOCIETE GENERALE.  
*************************************************************************


_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Risk of assigning disks in a loop to two controllers

andrei.borzenkov@ts.fujitsu.com
Mostly this simplifies administration and allows auto-assignment to work. Today auto-assignment is possible with shelf granularity too.

Отправлено с iPhone

10 июня 2016 г., в 18:17, BERNTSEN Basil <[hidden email]> написал(а):

Hi folks,

 

I have a CDOT 8.2 system (in prod) where new shelves were installed on a SAS stack on the wrong node. I want to create an aggregate on node1, but the disks are on node2. Based on the guidelines, I'm thinking of delaying the aggregate creation and changing the shelves.

 

My question is whether it's worth the delay. What are the risks of just assigning the disks to the partner of the node they're currently assigned to? The documentation says to "Always assign all disks on the same loop or stack to the same system." Why?

 

Thanks!

 

Basil

************************************************************************* 
This message and any attachments (the "message") are confidential, intended solely for the addressee(s), and may contain legally privileged information.  Any unauthorized use or dissemination is prohibited. E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. Please visit http://sgasdisclosure.com for important information regarding SG Americas Securities, LLC (“SGAS”). Please visit http://swapdisclosure.sgcib.com for important information regarding swap transactions with SOCIETE GENERALE.  
*************************************************************************

_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters

_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Risk of assigning disks in a loop to two controllers

Scott M Gelb
In reply to this post by BERNTSEN Basil
Disk auto assignment can be set to bay|shelf|stack now... so disk option modify can set that (need to confirm 8.2 supports that but 8.3 for sure has it).  Another option is aggregate relocate... you can create the aggr on node2, then ARL to node1.  Make sure enough spares assigned though per node for each disk type. 

8.2 also supports hot removal, so if you want a stack based assignment you can hot remove and hot add back.



From: BERNTSEN Basil <[hidden email]>
To: "[hidden email]" <[hidden email]>
Sent: Friday, June 10, 2016 8:07 AM
Subject: Risk of assigning disks in a loop to two controllers

Hi folks,
 
I have a CDOT 8.2 system (in prod) where new shelves were installed on a SAS stack on the wrong node. I want to create an aggregate on node1, but the disks are on node2. Based on the guidelines, I'm thinking of delaying the aggregate creation and changing the shelves.
 
My question is whether it's worth the delay. What are the risks of just assigning the disks to the partner of the node they're currently assigned to? The documentation says to "Always assign all disks on the same loop or stack to the same system." Why?
 
Thanks!
 
Basil
************************************************************************* 
This message and any attachments (the "message") are confidential, intended solely for the addressee(s), and may contain legally privileged information.  Any unauthorized use or dissemination is prohibited. E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. Please visit http://sgasdisclosure.com for important information regarding SG Americas Securities, LLC (“SGAS”). Please visit http://swapdisclosure.sgcib.com for important information regarding swap transactions with SOCIETE GENERALE.  
*************************************************************************

_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters



_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Risk of assigning disks in a loop to two controllers

Tim McCarthy
In reply to this post by BERNTSEN Basil
The main reason for that is "ease of use"
By doing all disks in one stack to one shelf...when you replace a failed disk it is automatically assigned ownership.

If even one disk on the stack belongs to the "other" node, the auto-assign no longer works.

With that in mind, something I do occasionally is this during initial setup/config:

make all EVEN numbered disks (*0,*2,*4,*6, *8) owned by node 2 in the HA pair 
and all ODD numbered disks (*1, *3, *5, *7, *9) owned my node 1 in the HA pair.

This way when a disk fails, I know if it is an even numbered disk it gets assigned to node 2 and an odd numbered disk to node 1

The extra benefit I get is mode disks possibly shuffled across more SAS controllers getting me possibly a bit more performance too.

--tmac

Tim McCarthy, Principal Consultant





On Fri, Jun 10, 2016 at 11:07 AM, BERNTSEN Basil <[hidden email]> wrote:

Hi folks,

 

I have a CDOT 8.2 system (in prod) where new shelves were installed on a SAS stack on the wrong node. I want to create an aggregate on node1, but the disks are on node2. Based on the guidelines, I'm thinking of delaying the aggregate creation and changing the shelves.

 

My question is whether it's worth the delay. What are the risks of just assigning the disks to the partner of the node they're currently assigned to? The documentation says to "Always assign all disks on the same loop or stack to the same system." Why?

 

Thanks!

 

Basil

************************************************************************* 
This message and any attachments (the "message") are confidential, intended solely for the addressee(s), and may contain legally privileged information.  Any unauthorized use or dissemination is prohibited. E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. Please visit http://sgasdisclosure.com for important information regarding SG Americas Securities, LLC (“SGAS”). Please visit http://swapdisclosure.sgcib.com for important information regarding swap transactions with SOCIETE GENERALE.  
*************************************************************************


_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters



_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Risk of assigning disks in a loop to two controllers

John Stoffel-5
In reply to this post by BERNTSEN Basil

BERNTSEN> I have a CDOT 8.2 system (in prod) where new shelves were
BERNTSEN> installed on a SAS stack on the wrong node. I want to create
BERNTSEN> an aggregate on node1, but the disks are on node2. Based on
BERNTSEN> the guidelines, I'm thinking of delaying the aggregate
BERNTSEN> creation and changing the shelves.

Do you want to move the shelves because you're trying not to mix
SATA/SAS on nodes?  Or is it just because you want to put the disks on
N1 since N2 is already under load?  

As others have said, you could probably hot-remove the shelf(s) and
move them over to the other node, but you'll want to open a ticket
first to make sure it's supported and done properly.

But since they should be dual pathd to each node in the HA pair, you
should be able to just re-assign the disks to the other node.



BERNTSEN> My question is whether it's worth the delay. What are the
BERNTSEN> risks of just assigning the disks to the partner of the node
BERNTSEN> they're currently assigned to? The documentation says to
BERNTSEN> "Always assign all disks on the same loop or stack to the
BERNTSEN> same system." Why?

I think it's probably to make failover simpler and more robust.  Not
sure.  
_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Risk of assigning disks in a loop to two controllers

Francis Kim
In reply to this post by BERNTSEN Basil
Basil,

NetApp’s automatic disk assignment rule starts at the stack level by default, where new disks introduced to the stack get assigned to the same controller as the other disks already in the stack.  If you have disks in the stack owned by more than one controller, then autoassign does not happen and you’re on your own.

If you want finer granularity of automatic disk assignment, say at the shelf level because you only have a single stack between the two controllers, then something like the following should be enough:

storage disk option modify ‑autoassign on ‑autoassign-shelf on

From a system operations standpoint, there’s no harm to assigning disks in the same stack to the partner node.  However, keeping the stack/controller disk ownership aligned does make ARL for non-disruptive headswap simpler (or possible).


Francis Kim
Cell: 415-606-2525
Direct: 510-644-1599 x334 

On Jun 10, 2016, at 8:07 AM, BERNTSEN Basil <[hidden email]> wrote:

Hi folks,
 
I have a CDOT 8.2 system (in prod) where new shelves were installed on a SAS stack on the wrong node. I want to create an aggregate on node1, but the disks are on node2. Based on the guidelines, I'm thinking of delaying the aggregate creation and changing the shelves.
 
My question is whether it's worth the delay. What are the risks of just assigning the disks to the partner of the node they're currently assigned to? The documentation says to "Always assign all disks on the same loop or stack to the same system." Why?
 
Thanks!
 
Basil

************************************************************************* 
This message and any attachments (the "message") are confidential, intended solely for the addressee(s), and may contain legally privileged information.  Any unauthorized use or dissemination is prohibited. E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. Please visit http://sgasdisclosure.com for important information regarding SG Americas Securities, LLC (“SGAS”). Please visit http://swapdisclosure.sgcib.com for important information regarding swap transactions with SOCIETE GENERALE.  
*************************************************************************

_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters


_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters
Loading...