This post is more than 5 years old
2 Intern
•
356 Posts
0
2047
CIFS mounting
Hey Isilon Support Community,
Can you mount CIFS shares between Isilons? If so can you help out with syntax, because I seem to be having an issue doing so.
Thank you,
This post is more than 5 years old
2 Intern
•
356 Posts
0
2047
Hey Isilon Support Community,
Can you mount CIFS shares between Isilons? If so can you help out with syntax, because I seem to be having an issue doing so.
Thank you,
Top
dynamox
2 Intern
2 Intern
•
20.4K Posts
0
May 15th, 2014 06:00
why ? You don't have SyncIQ ? If you don't have SyncIQ you could use rsync/scp to copy data between the clusters. Or you could use a "proxy" windows systems that will map CIFS shares from both clusters and then use robocopy/emcopy to copy the data.
dynamox
2 Intern
2 Intern
•
20.4K Posts
0
May 15th, 2014 05:00
Title says NFS mounting, you are asking about CIFS shares ? What is it exactly you are trying to do ?
lit-cs
4 Posts
0
May 15th, 2014 06:00
This is a case where your users would be much better served by setting up something that you can drive with SyncIQ. This is the sort of situation where you have to do what they need rather than what they ask for.
Start with the idea of defining a share that syncs to the other site frequently and tell them it is a dropbox or a time warp portal or whatever suits your organizational culture, have it sync on the hour, and create subdirectories in it for different user groups. SyncIQ is going to get more performance and reliability from your WAN no matter how slow it is than any homebrew concoction of CIFS/scp/rsync.
If the unidirectionality of SyncIQ is an issue, you may want to consider running Unison on an NFS client at each site. We run that continuously on a 5-second interval to achieve bidirectional (multi-master) synchronization over WAN. It uses block-based differential internally. Again, it won't go as fast as SyncIQ's parallel streams, but it might help you satisfy the use case where both sides need to write.
chjatwork
2 Intern
2 Intern
•
356 Posts
0
May 15th, 2014 06:00
The bandwidth between the clusters is a huge impact for why this is important to have in place. Users at our remote sites request access to certain data that would take to long to wait to transfer in a regular sitting. With this said the users at the remote location can make a request for data and the users at the sources can drop the data into a location where the SyncIQ will copy the data to the remote cluster and in all cases the data will be ready to go for the remote user on the next day (data overall size depend.) No different then the sources data location users kicking off a FTP or SCP or drag and drop, just that in this case its a little quicker, because the data is already on the NAS and its just getting copied to a folder that SyncIQ will on schedule copy over to the remote cluster(s). Neither user (Source or Destination) has to wait around as the system will take care of the transfer. Not a 100% perfect, but until money is allotted to allow for a much large pipe between locations this will have to do.
chjatwork
2 Intern
2 Intern
•
356 Posts
0
May 15th, 2014 06:00
Sorry CIFS. I want to mount a CIFS share between Isilons so that I can copy data to the other.
dynamox
2 Intern
2 Intern
•
20.4K Posts
0
May 15th, 2014 06:00
i am curious what is the use case, is it just regular "office" shares and users need to move files between clusters ?
chjatwork
2 Intern
2 Intern
•
356 Posts
0
May 15th, 2014 06:00
Its not that I didnt want to use SyncIQ. I did use that originally, but when users are giving me different source locations to copy from it make SyncIQ not very useful as I have to create a totally different policy for each request and they all can not copy to the exact same destination with there being a conflict within the SyncIQ. Maybe I am doing something wrong? Needless to say I totally forgot about scp. The users are not going to want to use Windows drag and drop because the bandwidth between the location is not great.
peglarr
99 Posts
1
May 15th, 2014 07:00
The situation described is actually one of several reasons why 'continuous mode' was implemented in SIQ in OneFS 7.1. It copies the deltas at least every 10 seconds from the source to the target. With that, there is little need for 3rd party tools such as Unison that add another layer of complexity and (as was mentioned) can present performance/time-to-complete problems compared to SIQ.
lit-cs
4 Posts
0
May 15th, 2014 08:00
Cool. What about the bidirectional/multi-master use case? That's the rationale for Unison, not the frequency.
Peter_Sero
1.2K Posts
1
May 15th, 2014 09:00
Same thought here...
Search for EMC World 2014: Isilon Cloud Pools and vIMSOCOOL
on youtube -- and more materials will be published on May 28, according
to a note on the EMC World website.
chjatwork
2 Intern
2 Intern
•
356 Posts
0
May 15th, 2014 10:00
@ Peter_Sero,
Thank you for sharing. I will look into this.
chjatwork
2 Intern
2 Intern
•
356 Posts
0
May 15th, 2014 10:00
@ lit-cs
For now we are not performing writes in both direction, but thank you for the idea.