We've got a head office in Melbourne Australia with a site office in San
Diego. Latency is a killer! Actually another one in Newcastle in the UK
too - we get about 360ms RTT to that. :-)
We're in the process of deploying the riverbed steelheads now, and
they're amazing. CIFS still isn't "fast", but it is at least "fairly
usable". The round trip reduction magic it does really makes a
difference for the simple stuff like browsing folders etc.
Opening/Saving files is still a 15-30 second affair, which is annoying,
but before it was 2-15 minutes, which is unusable.
However, we're still using DFSR for various things, and it works fairly
well, although as others have pointed out there can be issues with
locking. We started looking at a product called PeerLock to address
that, but the that expense budget got binned so we didn't get very far.
Might be worth a look.
We've also tried:
Source Control systems (SVN/TortoiseSVN): - Non
technical/programming users hate the checkin/checkout cycle.
WebDav/WebFolders ( "davenport" on the server) - It's OKish. Office
apps will load/save from a web folder, but most others wont. And
Explorer has a horrible habit of switching out of web folders mode and
into web page mode at the slightest provocation.
FTP and windows "Network Places" - Similar problems to webdav, and
it's far to easy to poke windows into displaying the users password in
the explorer status bar!
For our CAD stuff, we're likely to evaluate some PDM systems for data
sharing.
We've almost dabbled with some document managment systems like
KnowledgeTree, with the office add-ons, but it was too much of a change
to the day to day lives of our users - and a little bit too
single-document centric for the work a number of our staff actually do.
A compromise might be set up a local DFSR server at the remote site,
replicating to a backup server at the central office. Move all "their
files" to the DFSR system - they can work on the files locally, but you
can back up the DFSR replica at the main office. You don't have to worry
about managing the backups at the remote site, and you can probably get
away with putting in a lower end server their too - if it crashes then
users can still access the DFSR replica at head office, it's just
slower. The server management side of this scales out relatively well,
but the data management side might not. :-(
Good Luck,
T
On 12/01/2010 10:46 AM, Jeremy Charles wrote:
> I'd like to hear from those who have had to manage IT resources for offices
> that are located on opposite sides of oceans.
>
> Our primary challenge right now is this: Our original offices, and our CIFS
> file servers, are located in Wisconsin, USA. We also have an office in the
> Netherlands. The folks in the Netherlands interact heavily with files on the
> CIFS file servers in Wisconsin - as does the entire company.
>
> Performance was understandably painful for the Netherlands folks until we
> added a Riverbed system to optimize the CIFS traffic. It's better now, but
> the Netherlands folks are still pointing out productivity losses due to
> slowness working with the CIFS file servers. Note that the link between the
> Netherlands and Wisconsin offices has never been strained for capacity - this
> purely seems to be a latency issue.
>
>
> One of the obvious thoughts is to set up file servers (and backups) in the
> Netherlands office, and move "their" files over to "their" file servers. Of
> course, there is no clear division between what the Wisconsin folks use and
> what the Netherlands folks use, so somebody will always be the winner and
> somebody will always be the loser when it comes to performance in accessing a
> particular piece of data.
>
> It's also worth noting that we may have one or more other office(s) popping
> up in the eastern hemisphere at some point. If we add a file server and
> backups to each office to store each office's most heavily utilized data,
> we'll end up with a lot of systems to manage. (Yes, we've thought of
> renting space in a data center that's a reasonable compromise location among
> the eastern hemisphere offices - wherever they end up being.)
>
>
> Is our best bet to simply try to locate data closest to the people who use it
> the most (and set expectations accordingly with those who are not near a
> given piece of data), or is there a better way to deal with this?
>
>
>
> ===
> Jeremy Charles
> Epic - Computer and Technology Services Division
> jchar...@epic.com
>
> Phone: 608-271-9000 Fax: 608-271-7237
>
>
> _______________________________________________
> Discuss mailing list
> Discuss@lopsa.org
> http://lopsa.org/cgi-bin/mailman/listinfo/discuss
> This list provided by the League of Professional System Administrators
> http://lopsa.org/
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
_______________________________________________
Discuss mailing list
Discuss@lopsa.org
http://lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
http://lopsa.org/
