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 guidelineshttps://library.netapp.com/ecmdocs/ECMP1196912/html/GUID-99C1AA7C-79D9-4E4F-9392-5418EE927B7B.html, 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. *************************************************************************
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 <basil.berntsen-ext@socgen.commailto:basil.berntsen-ext@socgen.com> ???????(?):
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 guidelineshttps://library.netapp.com/ecmdocs/ECMP1196912/html/GUID-99C1AA7C-79D9-4E4F-9392-5418EE927B7B.html, 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 Toasters@teaparty.netmailto:Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
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 basil.berntsen-ext@socgen.com To: "toasters@teaparty.net" toasters@teaparty.net Sent: Friday, June 10, 2016 8:07 AM Subject: Risk of assigning disks in a loop to two controllers
<!--#yiv5069701909 _filtered #yiv5069701909 {font-family:"Cambria Math";panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv5069701909 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv5069701909 #yiv5069701909 p.yiv5069701909MsoNormal, #yiv5069701909 li.yiv5069701909MsoNormal, #yiv5069701909 div.yiv5069701909MsoNormal {margin:0cm;margin-bottom:.0001pt;font-size:11.0pt;font-family:"Calibri", "sans-serif";}#yiv5069701909 a:link, #yiv5069701909 span.yiv5069701909MsoHyperlink {color:blue;text-decoration:underline;}#yiv5069701909 a:visited, #yiv5069701909 span.yiv5069701909MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv5069701909 span.yiv5069701909EmailStyle17 {font-family:"Calibri", "sans-serif";color:windowtext;}#yiv5069701909 .yiv5069701909MsoChpDefault {} _filtered #yiv5069701909 {margin:72.0pt 72.0pt 72.0pt 72.0pt;}#yiv5069701909 div.yiv5069701909WordSection1 {}-->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 theguidelines, 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%C2%A0for important information regarding swap transactions with SOCIETE GENERALE. ************************************************************************* _______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
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 < basil.berntsen-ext@socgen.com> 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 https://library.netapp.com/ecmdocs/ECMP1196912/html/GUID-99C1AA7C-79D9-4E4F-9392-5418EE927B7B.html, 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 Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
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.
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 fkim@berkcom.commailto:fkim@berkcom.com www.berkcom.comhttp://www.berkcom.com
On Jun 10, 2016, at 8:07 AM, BERNTSEN Basil <basil.berntsen-ext@socgen.commailto:basil.berntsen-ext@socgen.com> 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 guidelineshttps://library.netapp.com/ecmdocs/ECMP1196912/html/GUID-99C1AA7C-79D9-4E4F-9392-5418EE927B7B.html, 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.comhttp://sgasdisclosure.com/ for important information regarding SG Americas Securities, LLC (“SGAS”). Please visit http://swapdisclosure.sgcib.comhttp://swapdisclosure.sgcib.com/ for important information regarding swap transactions with SOCIETE GENERALE. *************************************************************************
_______________________________________________ Toasters mailing list Toasters@teaparty.netmailto:Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
-
andrei.borzenkov＠ts.fujitsu.com -
BERNTSEN Basil -
Francis Kim -
John Stoffel -
Scott M Gelb -
tmac