Greetings,
We have to split a cluster and one shelf will go to one site, and the rest go to another site. The single shelf (DS4243, 2 TB SATA) comprising 2 aggregates and 11 volumes will get moved to a different NetApp. The shelf will end up on a system with new names and no aliases can be used. There are some variable moving parts so I need a sanity check.
FilerA 7.3.7 - owner of the one shelf FilerB 8.1.2P4 - soon to be owner of the one shelf
I've setup a snapmirror with a daily cron update that goes from FilerA to FilerB. This seems OK. If we can get the shelf owners to split the same day the other moves, I'm just going to move the shelf, change ownership, import the aggregate/volumes, create cifs shares, and update the snapvault relationship.
If they insist on moving before that, I have to break the mirrors after a final sync, rename the current snapmirror destination volumes, update snapvault relationships and create cifs shares. This seems OK.
Now the questions :-)
1. Are there any issues associated with this process with the OS differences or snapmirror not keeping filesystem security type, share, permissions, etc?
2. If I have to split the shelf later, I want to add it to FilerB and make that shelf the production shelf. This is a short term solution and the heads and shelves are not supported. Is there a graceful way to sync back to the DS4243 shelf? I don't want to disrupt the CIFS users very much.
3. Any other glaring issues that stand out?
Thanks,
Jeff
Not sure about the security on the volumes, but the NTFS perms should follow, as long as its in the same AD domain, but the shares won’t follow; you will have to recreate the shares. I would update the disk/shelf firmware prior personally.
From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Jeff Cleverley Sent: Friday, March 27, 2015 12:55 PM To: Toasters@teaparty.net Subject: Snapmirror relationships
Greetings,
We have to split a cluster and one shelf will go to one site, and the rest go to another site. The single shelf (DS4243, 2 TB SATA) comprising 2 aggregates and 11 volumes will get moved to a different NetApp. The shelf will end up on a system with new names and no aliases can be used. There are some variable moving parts so I need a sanity check.
FilerA 7.3.7 - owner of the one shelf FilerB 8.1.2P4 - soon to be owner of the one shelf
I've setup a snapmirror with a daily cron update that goes from FilerA to FilerB. This seems OK. If we can get the shelf owners to split the same day the other moves, I'm just going to move the shelf, change ownership, import the aggregate/volumes, create cifs shares, and update the snapvault relationship.
If they insist on moving before that, I have to break the mirrors after a final sync, rename the current snapmirror destination volumes, update snapvault relationships and create cifs shares. This seems OK.
Now the questions :-)
1. Are there any issues associated with this process with the OS differences or snapmirror not keeping filesystem security type, share, permissions, etc?
2. If I have to split the shelf later, I want to add it to FilerB and make that shelf the production shelf. This is a short term solution and the heads and shelves are not supported. Is there a graceful way to sync back to the DS4243 shelf? I don't want to disrupt the CIFS users very much.
3. Any other glaring issues that stand out?
Thanks,
Jeff
-- Jeff Cleverley IT Engineer 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611
If you want to retain the shares, copy the file in /vol/vol0/etc called cifsconfig_share.cfg.
That file basically runs commands at boot that creates the shares:
# cat cifsconfig_share.cfg
#Generated automatically by cifs commands
cifs shares -add "ETC$" "/etc" -comment "Remote Administration"
cifs access "ETC$" S-1-5-32-544 Full Control
cifs shares -add "HOME" "/vol/vol0/home" -comment "Default Share"
cifs access "HOME" S-NONE "nosd"
cifs shares -add "C$" "/" -comment "Remote Administration"
cifs access "C$" S-1-5-32-544 Full Control
cifs shares -add "CIFS" "/vol/cifs" -comment "CIFS"
cifs access "CIFS" S-NONE "nosd"
If you have shares in that file already on the destination filer, append the new shares.
If you want to load the shares without rebooting after you add the ones you want, use the source command.
parisi-7mode> source /vol/vol0/etc/cifsconfig_share.cfg
There is already a share named ETC$.
1 share(s) have been successfully modified
There is already a share named HOME.
1 share(s) have been successfully modified
There is already a share named C$.
1 share(s) have been successfully modified
There is already a share named CIFS.
1 share(s) have been successfully modified
Snapmirror is a block for block copy of files, which includes permissions/ACLs. If using the same domain, no issues.
From: <Klise>, Steve <Steve.Klise@wwt.commailto:Steve.Klise@wwt.com> Date: Friday, March 27, 2015 at 4:10 PM To: Jeff Cleverley <jeff.cleverley@avagotech.commailto:jeff.cleverley@avagotech.com>, "Toasters@teaparty.netmailto:Toasters@teaparty.net" <Toasters@teaparty.netmailto:Toasters@teaparty.net> Subject: RE: Snapmirror relationships
Not sure about the security on the volumes, but the NTFS perms should follow, as long as its in the same AD domain, but the shares won't follow; you will have to recreate the shares. I would update the disk/shelf firmware prior personally.
From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Jeff Cleverley Sent: Friday, March 27, 2015 12:55 PM To: <Toasters@teaparty.netmailto:Toasters@teaparty.net> Subject: Snapmirror relationships
Greetings,
We have to split a cluster and one shelf will go to one site, and the rest go to another site. The single shelf (DS4243, 2 TB SATA) comprising 2 aggregates and 11 volumes will get moved to a different NetApp. The shelf will end up on a system with new names and no aliases can be used. There are some variable moving parts so I need a sanity check.
FilerA 7.3.7 - owner of the one shelf FilerB 8.1.2P4 - soon to be owner of the one shelf
I've setup a snapmirror with a daily cron update that goes from FilerA to FilerB. This seems OK. If we can get the shelf owners to split the same day the other moves, I'm just going to move the shelf, change ownership, import the aggregate/volumes, create cifs shares, and update the snapvault relationship.
If they insist on moving before that, I have to break the mirrors after a final sync, rename the current snapmirror destination volumes, update snapvault relationships and create cifs shares. This seems OK.
Now the questions :-)
1. Are there any issues associated with this process with the OS differences or snapmirror not keeping filesystem security type, share, permissions, etc?
2. If I have to split the shelf later, I want to add it to FilerB and make that shelf the production shelf. This is a short term solution and the heads and shelves are not supported. Is there a graceful way to sync back to the DS4243 shelf? I don't want to disrupt the CIFS users very much.
3. Any other glaring issues that stand out?
Thanks,
Jeff
-- Jeff Cleverley IT Engineer 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611
Justin and Steve,
Thanks for the information about the shares and also the cifsconfig_share.cfg file. The location I primarily support does very little CIFS. The group I inherited uses a lot of CIFS. I'm having to get up to speed on some things.
The AD will be the same so that won't be a problem. I expected I would have to create shares since the FilerB volume names don't match the originals. I'll double check the security on both sides and make sure those are the same.
It seems this should work either way I do it, but things don't always work as I planned them :-)
Jeff
On Fri, Mar 27, 2015 at 2:22 PM, Parisi, Justin Justin.Parisi@netapp.com wrote:
If you want to retain the shares, copy the file in /vol/vol0/etc called cifsconfig_share.cfg.
That file basically runs commands at boot that creates the shares:
# cat cifsconfig_share.cfg
#Generated automatically by cifs commands
cifs shares -add "ETC$" "/etc" -comment "Remote Administration"
cifs access "ETC$" S-1-5-32-544 Full Control
cifs shares -add "HOME" "/vol/vol0/home" -comment "Default Share"
cifs access "HOME" S-NONE "nosd"
cifs shares -add "C$" "/" -comment "Remote Administration"
cifs access "C$" S-1-5-32-544 Full Control
cifs shares -add "CIFS" "/vol/cifs" -comment "CIFS"
cifs access "CIFS" S-NONE "nosd"
If you have shares in that file already on the destination filer, append the new shares.
If you want to load the shares without rebooting after you add the ones you want, use the source command.
parisi-7mode> source /vol/vol0/etc/cifsconfig_share.cfg
There is already a share named ETC$.
1 share(s) have been successfully modified
There is already a share named HOME.
1 share(s) have been successfully modified
There is already a share named C$.
1 share(s) have been successfully modified
There is already a share named CIFS.
1 share(s) have been successfully modified
Snapmirror is a block for block copy of files, which includes permissions/ACLs. If using the same domain, no issues.
From: <Klise>, Steve Steve.Klise@wwt.com Date: Friday, March 27, 2015 at 4:10 PM To: Jeff Cleverley jeff.cleverley@avagotech.com, "Toasters@teaparty.net" Toasters@teaparty.net Subject: RE: Snapmirror relationships
Not sure about the security on the volumes, but the NTFS perms should follow, as long as its in the same AD domain, but the shares won’t follow; you will have to recreate the shares. I would update the disk/shelf firmware prior personally.
*From:* toasters-bounces@teaparty.net [ mailto:toasters-bounces@teaparty.net toasters-bounces@teaparty.net] *On Behalf Of *Jeff Cleverley *Sent:* Friday, March 27, 2015 12:55 PM *To:* Toasters@teaparty.net *Subject:* Snapmirror relationships
Greetings,
We have to split a cluster and one shelf will go to one site, and the rest go to another site. The single shelf (DS4243, 2 TB SATA) comprising 2 aggregates and 11 volumes will get moved to a different NetApp. The shelf will end up on a system with new names and no aliases can be used. There are some variable moving parts so I need a sanity check.
FilerA 7.3.7 - owner of the one shelf
FilerB 8.1.2P4 - soon to be owner of the one shelf
I've setup a snapmirror with a daily cron update that goes from FilerA to FilerB. This seems OK. If we can get the shelf owners to split the same day the other moves, I'm just going to move the shelf, change ownership, import the aggregate/volumes, create cifs shares, and update the snapvault relationship.
If they insist on moving before that, I have to break the mirrors after a final sync, rename the current snapmirror destination volumes, update snapvault relationships and create cifs shares. This seems OK.
Now the questions :-)
- Are there any issues associated with this process with the OS
differences or snapmirror not keeping filesystem security type, share, permissions, etc?
- If I have to split the shelf later, I want to add it to FilerB and
make that shelf the production shelf. This is a short term solution and the heads and shelves are not supported. Is there a graceful way to sync back to the DS4243 shelf? I don't want to disrupt the CIFS users very much.
- Any other glaring issues that stand out?
Thanks,
Jeff
--
Jeff Cleverley IT Engineer
4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611
I have seen (when running the cifs shares –add command manually) it will create EVERYONE/Full Control by default.. but not when cifsconfig_share.cfg is processed when cifs starts. This may have changed in newer ontap but you may need to delete or modify EVERYONE access if you run from the cli or source command. If you stop and start cifs it always worked for me and didn’t assume the default EVERYONE permission like the cli. Just a note to compare cifs access before and after so you don’t have all shares wide open at the share level.
From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Jeff Cleverley Sent: Friday, March 27, 2015 3:05 PM To: Parisi, Justin Cc: Toasters@teaparty.net Subject: Re: Snapmirror relationships
Justin and Steve,
Thanks for the information about the shares and also the cifsconfig_share.cfg file. The location I primarily support does very little CIFS. The group I inherited uses a lot of CIFS. I'm having to get up to speed on some things.
The AD will be the same so that won't be a problem. I expected I would have to create shares since the FilerB volume names don't match the originals. I'll double check the security on both sides and make sure those are the same.
It seems this should work either way I do it, but things don't always work as I planned them :-)
Jeff
On Fri, Mar 27, 2015 at 2:22 PM, Parisi, Justin <Justin.Parisi@netapp.commailto:Justin.Parisi@netapp.com> wrote: If you want to retain the shares, copy the file in /vol/vol0/etc called cifsconfig_share.cfg.
That file basically runs commands at boot that creates the shares:
# cat cifsconfig_share.cfg
#Generated automatically by cifs commands
cifs shares -add "ETC$" "/etc" -comment "Remote Administration"
cifs access "ETC$" S-1-5-32-544 Full Control
cifs shares -add "HOME" "/vol/vol0/home" -comment "Default Share"
cifs access "HOME" S-NONE "nosd"
cifs shares -add "C$" "/" -comment "Remote Administration"
cifs access "C$" S-1-5-32-544 Full Control
cifs shares -add "CIFS" "/vol/cifs" -comment "CIFS"
cifs access "CIFS" S-NONE "nosd"
If you have shares in that file already on the destination filer, append the new shares.
If you want to load the shares without rebooting after you add the ones you want, use the source command.
parisi-7mode> source /vol/vol0/etc/cifsconfig_share.cfg
There is already a share named ETC$.
1 share(s) have been successfully modified
There is already a share named HOME.
1 share(s) have been successfully modified
There is already a share named C$.
1 share(s) have been successfully modified
There is already a share named CIFS.
1 share(s) have been successfully modified
Snapmirror is a block for block copy of files, which includes permissions/ACLs. If using the same domain, no issues.
From: <Klise>, Steve <Steve.Klise@wwt.commailto:Steve.Klise@wwt.com> Date: Friday, March 27, 2015 at 4:10 PM To: Jeff Cleverley <jeff.cleverley@avagotech.commailto:jeff.cleverley@avagotech.com>, "Toasters@teaparty.netmailto:Toasters@teaparty.net" <Toasters@teaparty.netmailto:Toasters@teaparty.net> Subject: RE: Snapmirror relationships
Not sure about the security on the volumes, but the NTFS perms should follow, as long as its in the same AD domain, but the shares won’t follow; you will have to recreate the shares. I would update the disk/shelf firmware prior personally.
From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Jeff Cleverley Sent: Friday, March 27, 2015 12:55 PM To: <Toasters@teaparty.netmailto:Toasters@teaparty.net> Subject: Snapmirror relationships
Greetings,
We have to split a cluster and one shelf will go to one site, and the rest go to another site. The single shelf (DS4243, 2 TB SATA) comprising 2 aggregates and 11 volumes will get moved to a different NetApp. The shelf will end up on a system with new names and no aliases can be used. There are some variable moving parts so I need a sanity check.
FilerA 7.3.7 - owner of the one shelf FilerB 8.1.2P4 - soon to be owner of the one shelf
I've setup a snapmirror with a daily cron update that goes from FilerA to FilerB. This seems OK. If we can get the shelf owners to split the same day the other moves, I'm just going to move the shelf, change ownership, import the aggregate/volumes, create cifs shares, and update the snapvault relationship.
If they insist on moving before that, I have to break the mirrors after a final sync, rename the current snapmirror destination volumes, update snapvault relationships and create cifs shares. This seems OK.
Now the questions :-)
1. Are there any issues associated with this process with the OS differences or snapmirror not keeping filesystem security type, share, permissions, etc?
2. If I have to split the shelf later, I want to add it to FilerB and make that shelf the production shelf. This is a short term solution and the heads and shelves are not supported. Is there a graceful way to sync back to the DS4243 shelf? I don't want to disrupt the CIFS users very much.
3. Any other glaring issues that stand out?
Thanks,
Jeff
-- Jeff Cleverley IT Engineer 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611
-- Jeff Cleverley IT Engineer 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611
Scott,
Thanks for the update. I'll be looking at these this weekend.
Thanks,
Jeff
On Fri, Mar 27, 2015 at 9:04 PM, Gelb, Scott scott@redeight.com wrote:
I have seen (when running the cifs shares –add command manually) it will create EVERYONE/Full Control by default.. but not when cifsconfig_share.cfg is processed when cifs starts. This may have changed in newer ontap but you may need to delete or modify EVERYONE access if you run from the cli or source command. If you stop and start cifs it always worked for me and didn’t assume the default EVERYONE permission like the cli. Just a note to compare cifs access before and after so you don’t have all shares wide open at the share level.
*From:* toasters-bounces@teaparty.net [mailto: toasters-bounces@teaparty.net] *On Behalf Of *Jeff Cleverley *Sent:* Friday, March 27, 2015 3:05 PM *To:* Parisi, Justin *Cc:* Toasters@teaparty.net *Subject:* Re: Snapmirror relationships
Justin and Steve,
Thanks for the information about the shares and also the cifsconfig_share.cfg file. The location I primarily support does very little CIFS. The group I inherited uses a lot of CIFS. I'm having to get up to speed on some things.
The AD will be the same so that won't be a problem. I expected I would have to create shares since the FilerB volume names don't match the originals. I'll double check the security on both sides and make sure those are the same.
It seems this should work either way I do it, but things don't always work as I planned them :-)
Jeff
On Fri, Mar 27, 2015 at 2:22 PM, Parisi, Justin Justin.Parisi@netapp.com wrote:
If you want to retain the shares, copy the file in /vol/vol0/etc called cifsconfig_share.cfg.
That file basically runs commands at boot that creates the shares:
# cat cifsconfig_share.cfg
#Generated automatically by cifs commands
cifs shares -add "ETC$" "/etc" -comment "Remote Administration"
cifs access "ETC$" S-1-5-32-544 Full Control
cifs shares -add "HOME" "/vol/vol0/home" -comment "Default Share"
cifs access "HOME" S-NONE "nosd"
cifs shares -add "C$" "/" -comment "Remote Administration"
cifs access "C$" S-1-5-32-544 Full Control
cifs shares -add "CIFS" "/vol/cifs" -comment "CIFS"
cifs access "CIFS" S-NONE "nosd"
If you have shares in that file already on the destination filer, append the new shares.
If you want to load the shares without rebooting after you add the ones you want, use the source command.
parisi-7mode> source /vol/vol0/etc/cifsconfig_share.cfg
There is already a share named ETC$.
1 share(s) have been successfully modified
There is already a share named HOME.
1 share(s) have been successfully modified
There is already a share named C$.
1 share(s) have been successfully modified
There is already a share named CIFS.
1 share(s) have been successfully modified
Snapmirror is a block for block copy of files, which includes permissions/ACLs. If using the same domain, no issues.
*From: *<Klise>, Steve Steve.Klise@wwt.com *Date: *Friday, March 27, 2015 at 4:10 PM *To: *Jeff Cleverley jeff.cleverley@avagotech.com, " Toasters@teaparty.net" Toasters@teaparty.net *Subject: *RE: Snapmirror relationships
Not sure about the security on the volumes, but the NTFS perms should follow, as long as its in the same AD domain, but the shares won’t follow; you will have to recreate the shares. I would update the disk/shelf firmware prior personally.
*From:* toasters-bounces@teaparty.net [ mailto:toasters-bounces@teaparty.net toasters-bounces@teaparty.net] *On Behalf Of *Jeff Cleverley *Sent:* Friday, March 27, 2015 12:55 PM *To:* Toasters@teaparty.net *Subject:* Snapmirror relationships
Greetings,
We have to split a cluster and one shelf will go to one site, and the rest go to another site. The single shelf (DS4243, 2 TB SATA) comprising 2 aggregates and 11 volumes will get moved to a different NetApp. The shelf will end up on a system with new names and no aliases can be used. There are some variable moving parts so I need a sanity check.
FilerA 7.3.7 - owner of the one shelf
FilerB 8.1.2P4 - soon to be owner of the one shelf
I've setup a snapmirror with a daily cron update that goes from FilerA to FilerB. This seems OK. If we can get the shelf owners to split the same day the other moves, I'm just going to move the shelf, change ownership, import the aggregate/volumes, create cifs shares, and update the snapvault relationship.
If they insist on moving before that, I have to break the mirrors after a final sync, rename the current snapmirror destination volumes, update snapvault relationships and create cifs shares. This seems OK.
Now the questions :-)
- Are there any issues associated with this process with the OS
differences or snapmirror not keeping filesystem security type, share, permissions, etc?
- If I have to split the shelf later, I want to add it to FilerB and
make that shelf the production shelf. This is a short term solution and the heads and shelves are not supported. Is there a graceful way to sync back to the DS4243 shelf? I don't want to disrupt the CIFS users very much.
- Any other glaring issues that stand out?
Thanks,
Jeff
--
Jeff Cleverley IT Engineer
4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611
--
Jeff Cleverley IT Engineer
4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611
Nothing additional to add to the questions but nice to see another Northern Colorado Toaster!! :)
-Chris
On Apr 1, 2015, at 7:39 PM, Jeff Cleverley jeff.cleverley@avagotech.com wrote:
Scott,
Thanks for the update. I'll be looking at these this weekend.
Thanks,
Jeff
On Fri, Mar 27, 2015 at 9:04 PM, Gelb, Scott scott@redeight.com wrote: I have seen (when running the cifs shares –add command manually) it will create EVERYONE/Full Control by default.. but not when cifsconfig_share.cfg is processed when cifs starts. This may have changed in newer ontap but you may need to delete or modify EVERYONE access if you run from the cli or source command. If you stop and start cifs it always worked for me and didn’t assume the default EVERYONE permission like the cli. Just a note to compare cifs access before and after so you don’t have all shares wide open at the share level.
From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Jeff Cleverley Sent: Friday, March 27, 2015 3:05 PM To: Parisi, Justin Cc: Toasters@teaparty.net Subject: Re: Snapmirror relationships
Justin and Steve,
Thanks for the information about the shares and also the cifsconfig_share.cfg file. The location I primarily support does very little CIFS. The group I inherited uses a lot of CIFS. I'm having to get up to speed on some things.
The AD will be the same so that won't be a problem. I expected I would have to create shares since the FilerB volume names don't match the originals. I'll double check the security on both sides and make sure those are the same.
It seems this should work either way I do it, but things don't always work as I planned them :-)
Jeff
On Fri, Mar 27, 2015 at 2:22 PM, Parisi, Justin Justin.Parisi@netapp.com wrote:
If you want to retain the shares, copy the file in /vol/vol0/etc called cifsconfig_share.cfg.
That file basically runs commands at boot that creates the shares:
# cat cifsconfig_share.cfg #Generated automatically by cifs commands
cifs shares -add "ETC$" "/etc" -comment "Remote Administration" cifs access "ETC$" S-1-5-32-544 Full Control cifs shares -add "HOME" "/vol/vol0/home" -comment "Default Share" cifs access "HOME" S-NONE "nosd" cifs shares -add "C$" "/" -comment "Remote Administration" cifs access "C$" S-1-5-32-544 Full Control cifs shares -add "CIFS" "/vol/cifs" -comment "CIFS" cifs access "CIFS" S-NONE "nosd"
If you have shares in that file already on the destination filer, append the new shares.
If you want to load the shares without rebooting after you add the ones you want, use the source command.
parisi-7mode> source /vol/vol0/etc/cifsconfig_share.cfg There is already a share named ETC$. 1 share(s) have been successfully modified There is already a share named HOME. 1 share(s) have been successfully modified There is already a share named C$. 1 share(s) have been successfully modified There is already a share named CIFS. 1 share(s) have been successfully modified
Snapmirror is a block for block copy of files, which includes permissions/ACLs. If using the same domain, no issues.
From: <Klise>, Steve Steve.Klise@wwt.com Date: Friday, March 27, 2015 at 4:10 PM To: Jeff Cleverley jeff.cleverley@avagotech.com, "Toasters@teaparty.net" Toasters@teaparty.net Subject: RE: Snapmirror relationships
Not sure about the security on the volumes, but the NTFS perms should follow, as long as its in the same AD domain, but the shares won’t follow; you will have to recreate the shares. I would update the disk/shelf firmware prior personally.
From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Jeff Cleverley Sent: Friday, March 27, 2015 12:55 PM To: Toasters@teaparty.net Subject: Snapmirror relationships
Greetings,
We have to split a cluster and one shelf will go to one site, and the rest go to another site. The single shelf (DS4243, 2 TB SATA) comprising 2 aggregates and 11 volumes will get moved to a different NetApp. The shelf will end up on a system with new names and no aliases can be used. There are some variable moving parts so I need a sanity check.
FilerA 7.3.7 - owner of the one shelf
FilerB 8.1.2P4 - soon to be owner of the one shelf
I've setup a snapmirror with a daily cron update that goes from FilerA to FilerB. This seems OK. If we can get the shelf owners to split the same day the other moves, I'm just going to move the shelf, change ownership, import the aggregate/volumes, create cifs shares, and update the snapvault relationship.
If they insist on moving before that, I have to break the mirrors after a final sync, rename the current snapmirror destination volumes, update snapvault relationships and create cifs shares. This seems OK.
Now the questions :-)
Are there any issues associated with this process with the OS differences or snapmirror not keeping filesystem security type, share, permissions, etc?
If I have to split the shelf later, I want to add it to FilerB and make that shelf the production shelf. This is a short term solution and the heads and shelves are not supported. Is there a graceful way to sync back to the DS4243 shelf? I don't want to disrupt the CIFS users very much.
Any other glaring issues that stand out?
Thanks,
Jeff
--
Jeff Cleverley IT Engineer
4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611
--
Jeff Cleverley IT Engineer
4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611
-- Jeff Cleverley IT Engineer 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611 _______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
Either way, I'd recommend using NTFS permissions over share permissions. Share permissions are a little ephemeral...
On Fri, Mar 27, 2015 at 11:04 PM, Gelb, Scott scott@redeight.com wrote:
I have seen (when running the cifs shares –add command manually) it will create EVERYONE/Full Control by default.. but not when cifsconfig_share.cfg is processed when cifs starts. This may have changed in newer ontap but you may need to delete or modify EVERYONE access if you run from the cli or source command. If you stop and start cifs it always worked for me and didn’t assume the default EVERYONE permission like the cli. Just a note to compare cifs access before and after so you don’t have all shares wide open at the share level.
*From:* toasters-bounces@teaparty.net [mailto: toasters-bounces@teaparty.net] *On Behalf Of *Jeff Cleverley *Sent:* Friday, March 27, 2015 3:05 PM *To:* Parisi, Justin *Cc:* Toasters@teaparty.net *Subject:* Re: Snapmirror relationships
Justin and Steve,
Thanks for the information about the shares and also the cifsconfig_share.cfg file. The location I primarily support does very little CIFS. The group I inherited uses a lot of CIFS. I'm having to get up to speed on some things.
The AD will be the same so that won't be a problem. I expected I would have to create shares since the FilerB volume names don't match the originals. I'll double check the security on both sides and make sure those are the same.
It seems this should work either way I do it, but things don't always work as I planned them :-)
Jeff
On Fri, Mar 27, 2015 at 2:22 PM, Parisi, Justin Justin.Parisi@netapp.com wrote:
If you want to retain the shares, copy the file in /vol/vol0/etc called cifsconfig_share.cfg.
That file basically runs commands at boot that creates the shares:
# cat cifsconfig_share.cfg
#Generated automatically by cifs commands
cifs shares -add "ETC$" "/etc" -comment "Remote Administration"
cifs access "ETC$" S-1-5-32-544 Full Control
cifs shares -add "HOME" "/vol/vol0/home" -comment "Default Share"
cifs access "HOME" S-NONE "nosd"
cifs shares -add "C$" "/" -comment "Remote Administration"
cifs access "C$" S-1-5-32-544 Full Control
cifs shares -add "CIFS" "/vol/cifs" -comment "CIFS"
cifs access "CIFS" S-NONE "nosd"
If you have shares in that file already on the destination filer, append the new shares.
If you want to load the shares without rebooting after you add the ones you want, use the source command.
parisi-7mode> source /vol/vol0/etc/cifsconfig_share.cfg
There is already a share named ETC$.
1 share(s) have been successfully modified
There is already a share named HOME.
1 share(s) have been successfully modified
There is already a share named C$.
1 share(s) have been successfully modified
There is already a share named CIFS.
1 share(s) have been successfully modified
Snapmirror is a block for block copy of files, which includes permissions/ACLs. If using the same domain, no issues.
*From: *<Klise>, Steve Steve.Klise@wwt.com *Date: *Friday, March 27, 2015 at 4:10 PM *To: *Jeff Cleverley jeff.cleverley@avagotech.com, " Toasters@teaparty.net" Toasters@teaparty.net *Subject: *RE: Snapmirror relationships
Not sure about the security on the volumes, but the NTFS perms should follow, as long as its in the same AD domain, but the shares won’t follow; you will have to recreate the shares. I would update the disk/shelf firmware prior personally.
*From:* toasters-bounces@teaparty.net [ mailto:toasters-bounces@teaparty.net toasters-bounces@teaparty.net] *On Behalf Of *Jeff Cleverley *Sent:* Friday, March 27, 2015 12:55 PM *To:* Toasters@teaparty.net *Subject:* Snapmirror relationships
Greetings,
We have to split a cluster and one shelf will go to one site, and the rest go to another site. The single shelf (DS4243, 2 TB SATA) comprising 2 aggregates and 11 volumes will get moved to a different NetApp. The shelf will end up on a system with new names and no aliases can be used. There are some variable moving parts so I need a sanity check.
FilerA 7.3.7 - owner of the one shelf
FilerB 8.1.2P4 - soon to be owner of the one shelf
I've setup a snapmirror with a daily cron update that goes from FilerA to FilerB. This seems OK. If we can get the shelf owners to split the same day the other moves, I'm just going to move the shelf, change ownership, import the aggregate/volumes, create cifs shares, and update the snapvault relationship.
If they insist on moving before that, I have to break the mirrors after a final sync, rename the current snapmirror destination volumes, update snapvault relationships and create cifs shares. This seems OK.
Now the questions :-)
- Are there any issues associated with this process with the OS
differences or snapmirror not keeping filesystem security type, share, permissions, etc?
- If I have to split the shelf later, I want to add it to FilerB and
make that shelf the production shelf. This is a short term solution and the heads and shelves are not supported. Is there a graceful way to sync back to the DS4243 shelf? I don't want to disrupt the CIFS users very much.
- Any other glaring issues that stand out?
Thanks,
Jeff
--
Jeff Cleverley IT Engineer
4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611
--
Jeff Cleverley IT Engineer
4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
-
Basil -
CH -
Gelb, Scott -
Jeff Cleverley -
Klise, Steve -
Parisi, Justin