10-08-2009
Any ideas how to accomplish this storage move?
We have a datacenter in another part of the country with about a 100Mb WAN between that datacenter and the local datacenter. The remoted datacenter has about 20TB of data on roughly 75 servers that all must be moved to this datacenter with minimal downtime. Please help me come up with the best way to move this data. We figure if we can get maximum throughput on the WAN that we might be able to copy 300-400 GB per day.
Problems:
Downtime should be minimal from a few hours to a couple of days.
Most applications are live databases.
One thought I had was to use iSCSI to mount local disks to the remote servers then use EMC's OpenMigrator to sync the disks. This way the sync can happen in the background and take weeks if necessary. We can tune OpenMigrator to not put too much stress on the network and we will not have to impact the running applications. The problem with this is that our DMX does not currently support iSCSI and according to our storage admin it would be too cost prohibitive.
Another option is to try rsync to sync the data. Obviously, we would shutdown the database on the day of the move and only sync the delta but I am concerned it will have trouble syncing the live database.
We could try NFS but there is no easy way of synchronizing the incremental data on the day of the move. Also, NFS is prohibited in my company for security reasons.
Does anyone have any other suggestions or know of other products that could handle a server to server copy?
4 More Discussions You Might Find Interesting
1. UNIX for Dummies Questions & Answers
Hi All
I am new to Linux and Shell scripting. So bear with me.
I have two file the log.txt and the output.txt.
The log.txt looks like this
-------------------------------------------------------------------------
####
- r34327 | #####| 2008-03-31 10:18:35 -0400 (Mon, 31 Mar 2008) | 1 line... (1 Reply)
Discussion started by: xossarian
1 Replies
2. Red Hat
Guys,
I'm here again with more questions.
I have been asked to perform the following in a few servers:
Check:
OS system messages review
Non-intrusive tests of the hardware
SAN and network(ports,bandwidth and firewall/load balancer checks
Any input how to accomplish all this?
... (0 Replies)
Discussion started by: 300zxmuro
0 Replies
3. AIX
HI AIX experts,
We have a 2-node cluster version 6.1. Running 7 oracle dbs. Everything is on symmetrix. We are going to have a storage migration from one array to another. There will be SRDF setup between two arrays. I will be getting all the luns from new array. I am just looking for the... (7 Replies)
Discussion started by: snchaudhari2
7 Replies
4. Linux
Hi
We have RHEL 7.3 running from local disk and we want to move it to storage.
I am unable to find any proper procedure to do this activity. Please help. (4 Replies)
Discussion started by: powerAIX
4 Replies
SYNC(2) BSD System Calls Manual SYNC(2)
NAME
sync -- synchronize disk block in-core status with that on disk
LIBRARY
Standard C Library (libc, -lc)
SYNOPSIS
#include <unistd.h>
void
sync(void);
DESCRIPTION
The sync() function forces a write of dirty (modified) buffers in the block buffer cache out to disk. The kernel keeps this information in
core to reduce the number of disk I/O transfers required by the system. As information in the cache is lost after a system crash, kernel
thread ioflush ensures that dirty buffers are synced to disk eventually. By default, a dirty buffer is synced after 30 seconds, but some
filesystems exploit ioflush features to sync directory data and metadata faster (after 15 and 10 seconds, respectively).
The function fsync(2) may be used to synchronize individual file descriptor attributes.
CAUTIONS
Many modern disks contain write-back caches. In theory sync() flushes these. In practice there are many possible ways for this mechanism to
go astray. It is prudent (where possible) to allow a few seconds after syncing for everything to settle before e.g. turning off the power.
It may also be desirable to use dkctl(8) or scsictl(8) to disable the write-back cache entirely.
SEE ALSO
fsync(2), dkctl(8), scsictl(8), sync(8)
HISTORY
A sync() function call appeared in Version 6 AT&T UNIX.
Historically, sync() would schedule buffers for writing but not actually wait for the writes to finish. It was necessary to issue a second
or sometimes a third call to ensure that all buffers had in fact been written out. In NetBSD, sync() does not return until all buffers have
been written.
BSD
March 25, 2009 BSD