Mailing List Archive

On Tue, May 08, 2018 at 01:33:47AM +0000, Fenn, Michael wrote:
> How many total shares do you have? We've had good luck with a 1:1 ratio of volumes to shares since the platform limit is 1000 volumes/node on most recent hardware. With that model, you can shuffle volumes (and thus shares) between aggregates online with vol move, and you get easy access to goodies like QoS.

We have about 1300 shares at the moment. More volumes is not manageable IMHO.
For example, an altavault restricts snapmirror to 100 volumes. We already have
more volumes that that.

Regards,
pdg


_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters

I don't have an answer, but more of an observation. I tend to try and
keep one volume per project, assuming they're as big as you say they
are. Since you can grow/shrink volumes, it's an easier way to keep
things balanced.

It's not perfect of course... nothing is.

And as for moving CIFS shares, can you do symlinks in CIFS? Robocopy
the data to a new volume, turn off CIFS share, finish the copy, then
re-create the share pointing to the new location.

You will probably have to kill sessions though... CIFS sucks that
way....

Peter> Background: we have 20 odd volumes for fileshares. We limit the
Peter> size of the volumes to 10T. When a volume gets near full, we
Peter> need to shuffle shares to new volumes or volumes with plenty of
Peter> space.

Peter> Does anybody have a magical solution for moving fileshares
Peter> between volumes? With minimal but not necessarily zero downtime?

Peter> Obvious solutions are:

Peter> 1) Down share, copy share to new volume, up share
Peter> 2) Down share, clone volume, up share on new volume, split volume, cleanup mess.

Peter> I was wondering if anybody has seen a system to proxy the share and move
Peter> it in the background. I have seen this work with NFS shares
Peter> but not with CIFS.

Peter> Any magicians out there?


Peter> Regards,
Peter> pdg


Peter> _______________________________________________
Peter> Toasters mailing list
Peter> Toasters@teaparty.net
Peter> http://www.teaparty.net/mailman/listinfo/toasters
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters

No magic.
I used robocopy (back in the day). I would robocopy to the destination (to seed the data), and when ready to cut over, stop the source share (to kick everyone off or make changes while cutting over. Run robocopy with /MIR (DANGEROUS) and /e/b/z/ (make sure you understand and use the correct switches)... whatever switches you want. Make sure you copy security/ownership. Offline original, bring new share online. There is also an AD component so be aware of that requirement as well (NETBIOS workstation reset, file server name redirection/DNS/WINS requirements if needed). When I would cut over, it was a whole file server (namespace). Impossible to do individual shares unless using a global name space. So, move all the shares at once for \\server1\share1 \\\server1\share2 etc.. all at the same time.

You can also snapmirror; that worked very well, especially for larger, or many file volumes. Its what I used for the larger datasets. Maybe you can ask your Netapp/VAR for a temp key if you don’t have it. Love snapmirror.

You can pay and use StorageX or some others solutions. Komprise is an up-and-come'er but does not support CIFS moves/migrations until end of this month.. I like Komrpise..

PM me if you want me to forward some instructions I used when I used to manage 7-mode. I would assume it's still relevant. Nothing I know about a proxy the share move. Robocopy can seed the data, and MIR option, which can be dangerous, mirrors source/destination.

Hope this was of some value.

-Steve


?On 5/7/18, 6:23 PM, "toasters-bounces@teaparty.net on behalf of Peter D. Gray" <toasters-bounces@teaparty.net on behalf of pdg@uow.edu.au> wrote:

Hi people,

Background: we have 20 odd volumes for fileshares. We limit the size of the volumes to
10T. When a volume gets near full, we need to shuffle shares to new volumes or
volumes with plenty of space.

Does anybody have a magical solution for moving fileshares
between volumes? With minimal but not necessarily zero downtime?

Obvious solutions are:

1) Down share, copy share to new volume, up share
2) Down share, clone volume, up share on new volume, split volume, cleanup mess.

I was wondering if anybody has seen a system to proxy the share and move
it in the background. I have seen this work with NFS shares
but not with CIFS.

Any magicians out there?


Regards,
pdg


_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters



_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters

On Mon, May 07, 2018 at 10:18:02PM -0400, John Stoffel wrote:
>
> I don't have an answer, but more of an observation. I tend to try and
> keep one volume per project, assuming they're as big as you say they
> are. Since you can grow/shrink volumes, it's an easier way to keep
> things balanced.
>

We are a University. The number of "projects" seems to be
unbounded :-)

And I really want to avoid huge volumes for all the obvioul reasons.


> It's not perfect of course... nothing is.
>
> And as for moving CIFS shares, can you do symlinks in CIFS? Robocopy
> the data to a new volume, turn off CIFS share, finish the copy, then
> re-create the share pointing to the new location.
>
> You will probably have to kill sessions though... CIFS sucks that
> way....
>

Yeah, this is what we are doing now. It sucks.


Regards,
pdg


_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters

I've used solution 2 previously to split up 6 shares.
Vol clone create
Vol clone split
Cleanup mess. (did this using systemshell as it doesn't care about permissions)

Part of the reason we had to do it this was that some of the file \ folder lengths \ depths were too long for robocopy.
Plus, this is the quickest way to get up and running again when you are talking about a large amount of data.

It may have been easier to have new volumes and use junction paths or DFS to keep everything simple for the users.

Good luck!

-----Original Message-----
From: toasters-bounces@teaparty.net <toasters-bounces@teaparty.net> On Behalf Of Peter D. Gray
Sent: 08 May 2018 02:13
To: toasters@teaparty.net
Subject: moving CIFS shares

Hi people,

Background: we have 20 odd volumes for fileshares. We limit the size of the volumes to 10T. When a volume gets near full, we need to shuffle shares to new volumes or volumes with plenty of space.

Does anybody have a magical solution for moving fileshares between volumes? With minimal but not necessarily zero downtime?

Obvious solutions are:

1) Down share, copy share to new volume, up share
2) Down share, clone volume, up share on new volume, split volume, cleanup mess.

I was wondering if anybody has seen a system to proxy the share and move it in the background. I have seen this work with NFS shares but not with CIFS.

Any magicians out there?


Regards,
pdg


_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters

_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters

>>>>> "Peter" == Peter D Gray <pdg@uow.edu.au> writes:

Peter> On Tue, May 08, 2018 at 01:33:47AM +0000, Fenn, Michael wrote:
>> How many total shares do you have? We've had good luck with a 1:1 ratio of volumes to shares since the platform limit is 1000 volumes/node on most recent hardware. With that model, you can shuffle volumes (and thus shares) between aggregates online with vol move, and you get easy access to goodies like QoS.

Peter> We have about 1300 shares at the moment. More volumes is not
Peter> manageable IMHO. For example, an altavault restricts
Peter> snapmirror to 100 volumes. We already have more volumes that
Peter> that.

Yeah, I can see how that would grow pretty badly. Of course 1300
shares is a huge number too, maybe too many? It would be interesting
to see how you logically split things up. It tends to grow over time
unfortunately, without planning until you hit the point you need
planning. Heh.

I assume you're in cDOT mode? Would maybe setting up juntion paths
would be the better solution, where you share out a group of top level
CIFS shares, and then the next level down you have volumes
mounted... but you said you have too many volumes already, so that
probably won't fly.

I personally would be pushing to have *fewer* shares and more
volumes/qtrees. Though I'm not sure if qtrees have gotten all the
abilities of 7-mode yet in the 9.x series of cDOT.

Can you give a made up example maybe? Then again, I'm really just
bikeshedding here, not providing a good solution. :-(

John

_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters