Unsolved

This post is more than 5 years old

16 Posts

28787

February 2nd, 2007 21:00

AX150i - 1 Disk Pool - 1 Virtual Disk - Multiple Host (Backup Servers)?

We are currently in the process of implementing a secondary Backup Server.
 
The current Primary Backup Server is attached directly to the tape drive and has access to the AX150i.
 
All the disks on the AX150i are configured as 1 disk pool and assigned as 1 Virtual Disk and assigned to the Primary Backup Server.
 
The Secondary Backup will backup data to the Virtual Disk first.  After backup completion, the Primary Backup will backup the data from the same Virtual Disk to Tape.
 
We basically followed the  figure 8 found on page 18 of AX150-Series Planning Your AX150-Series iSCSI Storage-System Configuration manual.  The only difference from figure 8 is the additional server connected to the same 8-port Linksys Gigabit Switch for the dedicated iSCSI LAN.
 
According to Dell Technical Support, it is not supported to have 1 Virtual Disk assigned to more than one host (backup server).
 
Is this true?  If so, what is the best way to have both Primary and Secondary Backup Server to see the same data on the same Virtual Disk?
 
 


Message Edited by Kingsley Mok on 02-02-2007 05:35 PM

4 Operator

 • 

9.3K Posts

February 3rd, 2007 03:00

You cannot share virtual drives between servers on a SAN (fibre channel or iscsi) unless the servers are running a cluster.

When you assign the virtual drive to the 2nd server, Navisphere express even gives you a warning about this.

Each server will be able to write directly to the harddrive without considering the other server. They will eventually overwrite each others changes and update the file allocation table (database) crossing over each other and causing you to lose data.

This is not a thing that "might" happen, it's just a question of time.

This isn't a limitation of Dell and/or EMC SANs, it's the same for any storage device that can allow one or more servers to see the same harddrive at the same time.

You may want to look into the snapshot feature of Navisphere as this can take a 'still picture' of the data on a virtual drive and allow access to this from another server (changes to the original will not be reflected in the snap session).

The reason a cluster would work is that the cluster service treats the disk as a resource that can only be owned by 1 server/cluster node at a time, so it would be impossible for 2 nodes to read and/or write to the same disk at the same time.

16 Posts

February 5th, 2007 14:00

Dev Mgr,
 
Thank you for elaborating that and thank you for enlightening limits of SAN technology itself. 
 
The manual made no mention of this at all.  Something Dell / EMC should've added that in the first place.
 
With regards to a "work around," you mentioned either setup a cluster or use snapshot.  For high performance and faster processing, which method be best suited?  Setup Primary & Secondary as clusters to use the SAN or to set up the Primary to take the snapshot and the Secondary to go to SAN?
 
For ease of use and simplicity in setup, snapshot would be the way to go.  For fast accessibility to the backup data (for recovery), cluster would be the way.  What do you think?
 
 
 
 

4 Operator

 • 

9.3K Posts

February 5th, 2007 16:00

The manual wouldn't have to mention this. This is a given with systems that provide raw disk access to a server (SANs or DAS Scsi (e.g. PV220S)).

If you want disk access from multiple systems/users w/o running a cluster, you'd want to look into a NAS solution instead of a SAN.

If a vendor would have to provide a list of things that a product cannot do, you'd have some really long manuals out there. Vendors only post what it can do, as that's a much more manageable list.

96 Posts

February 5th, 2007 17:00

Typically, you would present the virtual disks to servers and when you want to backup the virtual disks, you create a snapshot and present the new snapshot to a backup server. You can't use a cluster for the scenario you are describing.

There should be plenty of information in the help files on Snapshots.  If you send me a private message, I can send you some additional info on scripting the snapshots.

16 Posts

February 5th, 2007 18:00

For simplicity, I think that assigning the Virtual Disk to one server and share it out to the other server, like NAS setup, is better. 
 
Essentially, it is like setting up a file server.
 
I'm open to hear other's opinion on preferred setup.

96 Posts

February 5th, 2007 20:00

It's really up to you how you want to do it.  Presenting the virtual disk to one server and then sharing out to another as a file share works, but there will be a performance hit since all I/O will have to go through 2 servers to get to the tape drive. 
If you create a snapshot of the virtual disk and present it to the second server, it will see the data as it was when the snapshot was created and you can backup the data bypassing the other server.  The other server can continue opperating, servicing I/O even modifing files without impacting the backup being performed by the other server.

16 Posts

February 5th, 2007 21:00

JTGlenn,
 
That does sound reasonable with snap shot option.  I would then have to redo the Virtual Drive Initialization again.
 
If the Snapshot was used, then how goes with the restore?  Will I still be able to restore files individually or do I actually have to restore the whole thing before pulling individual files out?


Message Edited by Kingsley Mok on 02-05-2007 07:17 PM

96 Posts

February 6th, 2007 02:00

Well I'm not sure exactly your configuration.  You stated you have a server connected to the AX150i via a switch, is it the only computer connected to the AX150i? 
  • I'm not sure if you backing up other computers to the server that is attached to AX150i or
  • do you have file shares presented to other computers and you are backing up those file shares?

Can you clarify? 

If you have 1 big virtual disk and you used all the space, then you will have to destory the virtual disk and rebuild it to enable snapshots.  They take up a little bit of space, depending how changes on the original virtual disk while the snapshot is active.  The snapshot presents the same virtual disk to a different server for backups but through the magic of technology it but only at a point in time.  So it has to keep track of all the changes that occur on either the source virtual disk or the snapshot.  (For backups all the changes occur on the source virtual disk)

Even though you would be using the snapshots to backup to tape, it will create a complete backup of the original virtual disk.  The backup server it doesn't know it is looking at a snapshot virtual disk, it looks just like the origianl disk.  So a restore from tape would be the same as if you had backed up from the original virtual disk.

I hope this helps and isn't too wordy.  If you do rebuild your Disk Pool configuration, I recommend looking at this post for setting up an AX150 or AX150i. 

16 Posts

February 6th, 2007 14:00

JTGlenn,
 
Here is the clarification.
 
Currently we have a Primary Host, with 2 NICs:  1 for LAN and 1 for iSCSI via Linksys SD2008 switch to the AX150i.  It is also attached to the Tape (PowerVault 132T) via SCSI.
 
We are implementing a Secondary Host to do all backup on to the SAN over the weekend.  The backup job to the SAN from the Secondary will take 2 to 3 full days to finish (1.8 TB). 
 
After that, on Monday, the Primary Host will backup the data on the SAN, where the backup data is, to tape as the final step. 
 
This will leave the differentials continue to backup on on SAN while the tape is running which I estimate will take 48 hours.
 
The reasons for this is because, from experience, sometimes the tape medias are bad, due to a particular brand, and the week's full backup job is messed up.  Then I would bring the bad news to management that we've lost a week's full backup due to poor media tapes.  This is where SAN comes in.  It is like backing up to a HD first, then we'll transfer to tape to ensure complete data with redundancy. 
 
I've been researching the following methods:
 
1.)  Connect the Primary to SAN and share out the drive like a file server.  Then, you're backing up data on a file base.  Good thing about this, this allows Primary and Secondary to access, read and write to the SAN at the same time.  Full backup from SAN to Tape and Differential backup to SAN.  Downside to this, the I/O gets dinged and therefore, slow performance.
 
2.)  Setup Primary and Secondary in a cluster.  Even with clusters, it will only allow one node to access the SAN.  So if the Primary does the backup to Tape from the SAN, the Secondary cannot do differentials to the SAN till the Primary is complete and vice versa.
 
3.)  Setup Primary for Snapshot and the Secondary for Virtual Disk.  This will ensure both maximum throughput.  Good thing about this, is that there is a Snapshot of the Virtual Disk at a point in time, which then allows the Primary backs up the Snapshot without any interference on performance while the Secondary will continue to do differentials to the Virtual Disk.  The only downside, is that you have to keep track of the point in time.
 
Obviously, for performance issue, Snapshot is the way to go.  I will have to play around with Method 3 - Snapshot option to see if I can restore files individually from the snapshot.  If I can't I will have to go with method 1 as it is important to extract an individual file from backup without having to restore the whole thing.
 
 
 


Message Edited by Kingsley Mok on 02-06-2007 10:44 AM

96 Posts

February 6th, 2007 16:00

One other thing, if you destroy the virtual disk and re-bind a new one.  Allow plenty of time for the virtual disk to bind.  The very first time you bind a virtual disk, it is almost instantaneous, however if you delete a virtual disk, the storage system must write zeros to the entire disks, which can take a significant amount of time.

16 Posts

February 6th, 2007 16:00

JTGlenn,
 
Thanks for your input.  I really appreciate it.
 
One more question about the snapshot.  You've mentioned that snapshot are just pointers to the original and changes made to the virtual disk.  If the virtual disk becomes double faulted and is no longer available, the snapshot to the virtual disk is not available as well.
 
What about the backup tape that made a backup of the snapshot?  Will restoring from tape be possible?  I'm in the process of preping the snapshot so I'm itching to test this out.  The preparation is sooooo slooooooow.:smileysad:

96 Posts

February 6th, 2007 16:00

I would definitely go with the snapshot method, you should be able to restore from the snapshot.

The snapshot will present the file exactly as it was when the snapshot was created, even if it has changed or was deleted.  It is not a backup, as it is just pointers to the original virtual disk and "changes" made to original virtual disk.  If the original virtual disk becomes double faulted and is no longer available, the snapshot will not be available.  Some people have confused snapshots as backups, they just allow you to perform backups. 

Just an FYI, one other use of snapshots is to create a snapshot of a database or program and test changes before implementing them.  The snapshot is a "virtual" read and write copy of the original disk.  It keeps track of all the changes (or differences) between the original and the snapshot regardless of which disk the change occurs.

Best of luck.

 

 

96 Posts

February 6th, 2007 17:00

When the tape backup occured of the snapshot, it saw a disk that  was made up pointers to the original data and to any changed data.  So it backed up the entire data. The server can't tell it is looking at pointers, it looks like as is the real data since. 
You can test this creating a virtual disk, assign it to a server copy a file to it, then create a snapshot, start it and assign it to another server, verify you can see it from the second server, then go modify the original data.  Open the file on the second server and it will be unchanged.   You can delete the file on either server and it will not effect what the other server sees.  If you change (including delete) the file on either server, before the changes are made to the virtual disk (or snapshot) the data is copied to a hidden virtual disk (this is why you need extra space for snapshots) and pointers are established to point to the new data.  If some data is changed and some is not changed, then the pointers for the disk will point to both the original data and the changed data to present what each server is supposed to see.  When you stop the snapshot session, all pointers are clears and when you start a new snapshot session, the pointers are re-established for the new point in time, so the data presented in the snapshot is no longer available (except in your case it would have been backed up to tape), all the data on the virtual disk is unaffected.
No Events found!

Top