Does Creating an Array Erase Disks???

[Dan Hawker]

Hi All,

Quick question regarding another problem I am experiencing.

If I create an array using the ACU and then make a Logical Volume, using disks from a different server, will the disks be erased in the process???

I've a drive that I'd like to move to another server but I need the data on it.

TIA

Dan

[Andrzej Kowalik]

YES, you lost your data.

regards,
Andrzej Kowalik

[Dan Hawker]

Hi Andrzej,

Thanks for the reply, thought as much when looking at the ACU, but thought something could be done. This seems rather stupid, after all its just a disk.

When a RAID 0 array fails, you add disks and bring it back up. Surely in this case (just a single disk is the entire Array) its just like having a degraded array.

Ah well, will investigate other methods.

Thanks

Dan

[Roy Main]

I'm not exactly sure what you're asking - in some scenarious you can move a drive with data on it to another server. You're Smart Array user guide covers these situations.

If the drive was the only one in an array and you moved it to another server - that server's SA controller would discover the new array and allow you access to it and the data.

However, if you were to move it AND reconfigure the drive in ACU - you would mostly likely lose the data. I have not experimented with reconfiguring a drive with the SAME configuration to see what would happen.

[Uwe Zessin]

> I've a drive that I'd like to move to another server but I need the data on it.

If you power down the server, plug in the disk drive which is a self-contained array, shouldn't the Smart Array controller automatically 'import' this array+ logical disk after power-up so that there is no need to configure it explicitly?

[kris rombauts]

Dan,

your description of the scenario/question isn't 100% clear to me either.

Uwe is absolutely right and if you folluw the steps (insert disk from old server in new server while the new server is powered off) then any array with any kind of raid level (0,1,5,..) will be imported into the new controller and no data will be affected.

Maybe the disk manager (i.e. Windows) will have to put a drive letter on that disk but that's about all you need to do before you are able to access the data, this under the condition that the OS version used here is compatible.

HTH

Kris

[Dan Hawker]

Hi All,

Thanks for the responses, I'll try and answer your queries...

I have inherited (new job) a DL380 G3 that runs Linux. It is presently setup as a single disk, configured as Array A and populates Slot-0. For clarity call this ServerA.

I also have an identical DL 380 G3 that has 4 drives configured as a RAID5. This is configured as Array A and populates Slots 0-3. (ServerB)

ServerB is also Linux and uses Xen (an open source virtualisation tech). What I planned to do is migrate the (poorly utilised) serverA to serverB but running as a VM. Predominantly for ease and speed, I hoped I'd be able to power down serverA, pop the drive and insert into serverB (in slot 4 or 5), light it up using the ACU and then get Linux to access the drive as normal. I could then use Xen to start up serverA as a VM, using the drive and data from serverA.

However, when I tried this, the ACU recognised the newly inserted drive, but didn't do anything with it. It just labelled it as an *Unallocated drive*.

I didn't like the sound of creating an array, as I presumed (rightly it seems from previous answers) that it'd hose my data. However I couldn't find a sensible way to start it up. I presumed it would *just work*; the array would see the drive and do its magic to allow Linux to access the drive, but it seems this is not the case.

Hope that clarifies my problem/scenario and what I'd like to achieve. It seems a pretty simple problem, but so far I haven't worked out if it is possible.

Thanks again for your responses.

Dan

[Dan Hawker]

Hi All,

Re-reading things again. Am I correct in assuming that you have to power-off the target server (serverB in my case) and power it back on for the SA to import any new devices???

I thought this was a hot-swap server??? This kind of scenario (along with RAID rebuilds) are exactly why hot-swap drives are useful.

The target server is a heavily used production server (with a couple of VMs running on it), and as such powering off/on again is not something I can do at the drop of a hat.

Thanks

Dan

[Uwe Zessin]

> I thought this was a hot-swap server???

Ahem. This is for failed components. What you intend is a configuration change. The SmartArray controllers pick them up during power-on in order to detect any drive roaming.

You are expecting a little too much.

[Dan Hawker]

Hi Uwe,

> You are expecting a little too much.

I guess I am :(

Ah well, so if I understand correctly, yes it should work (ie the SA will read the disk fine and import the array), however to do so I'll have to reboot the box.

Guess I'll have to arrange a reboot in the next few days.

Thanks for your replies everyone :)

Dan

[kris rombauts · Accepted solution]

Dan,

did a quick test for you on Windows 2003:

- created raid0 array with one logical drive on one physicall disk
- formatted NTFS, copied 6 GByte files on it
- removed disk from server
- hot inserted it in another running server
- started ACU utility/rescanned bus
- saw one unconfigured disk
- created raid0 array with one logical drive on this disk
- started disk manager and saw this disk as "Healthy" but no drive letter.
- assigned drive letter
- all data was visible and chkdsk ran without any error, could copy new files to
driveletter, all looks ok.

....

I don't consider this as a supported method but at least on Windows it seems to work just fine without downtime.


HTH

Kris

[kris rombauts]

..... so the point is that if you create the array with the same properties (stripe size ,logical drive size ..etc) the data does not get erased by just creating the array and logical drive information again as it writes just that piece of configuration information onto the disk(s).


Kris

[Dan Hawker]

Hi Kris,

Thanks for trying that for me. That is certainly promising and more as I'd expect. I was just unsure as to whether the array/logical volume creation was would be more destructive of the disk than that.

As you say, no guarantees, but certainly more hopeful...

I'd guess that the controller sets aside a small area of the disk for the controller info and this is the area that gets edited/wiped when moving drives around from machine to machine.

I've managed to organise a reboot of this machine in a couple of days, so I'll probably leave it until then and give it the kick. If I'm feeling brave I'll try the true hot-swap method. Think I'll test my backup between now and the reboot :)

Thanks for the info.

Dan

[Uwe Zessin]

> I'd guess that the controller sets aside a small
> area of the disk for the controller info

Yes, that is why you can move complete disk drive arrays - because the controller can find out which disks belong together.

[Dan Hawker]

And indeed why it should be fine to move drives about without fear of data loss. If it only edits the array config part of the drive, surely the data on the disk(s) should be left intact.

Obviously this wouldn't be feasible in certain instances (moving part of a stripe or RAID5 about would obviously fail) however mirrors and stripes of single disks *should* be unaffected.

Or am I asking too much again :)

My reboot happens tomorrow, will post any results, good or bad...

Dan

[Dan Hawker]

Hi All,

Thanks for all your advice so far.

Basically, as mentioned I ended up going with the *insert drive, reboot, let the controller do its magic* method and I am glad to report it worked perfectly.

The controller did its job and sorted things and my host OS (FC5 x86_64, I decided to chuck it in a DL380 G4 x86_64 instead) displayed it as usual. I have since created a Xen VM with the drive and it is now back up and happily compiling something as we speak (once I did a setarch fudge of bash to make logons/apps believe it is an x86_32 machine).

Anyway, just reporting it worked as I'd hoped. As I'd organised a reboot there was no need to try the *live* method. Another time when I have some test data to try it on.

Thanks again

Dan

[Dan Hawker]

See above.

[Michele Albrigo]

Bumping this up to ask some details...
My setup is:
Server A: ML370G3, SmartArray 642, 2x72gb raid 1 (Vol A1), 4x72gb raid 0+1 (Vol A2)
Server B: ML370G3, SmartArray 641, 2x72gb raid 1 (Vol B1), 2x72gb raid 1 (Vol B2)
The OS is Linux on both.

The operation I'd like to perform is moving Vol A2 to Server B, and moving Vol B2 to Server A, while keeping both Vol A1 and Vol B1 in place.

I always preserved the order of the disks in each operation, same disk in same slot, and I've always turned off the servers before moving disks. All operations of creation/deletion of volumes have been made from the SmartArray console (F8 at boot).

This is what I've done:
- take out Vol A2, took out Vol B2
- put Vol B2 into Server A, turned on Server A
- Server A didn't recognize the array on Vol B2
- take out Vol B2, deleted both arrays from Server A's controller, created array on Vol A1 disks (same settings) -> lost Vol A1 (I assume)
- put Vol A2 into Server B, Server B didn't recognize Vol A2 disks
- take out Vol A2, put Vol B2 back into Server B, Server B complained about a possible hardware failure, I told it to go on and now works fine (it just needed some reboots to go out of degraded mode, check filesystems etc.)
- put Vol A2 back into Server A, it recognized the array (still unable to boot, so I can't tell if there still are data on it, because Vol A1 was the OS partition).

Now the questions:
- can I assume that Vol A2 still has data on it?
- is there any way to accomplish my original objectives (moving Vol A2 to Server B and Vol B2 to Server A)? What should I do?

Next step I'd do would be the following:
- take out Vol B2
- delete the raid configuration for Vol B2 on Server B
- put Vol A2 into Server B
- pray for the autodetection to work fine

Is this the right thing to do?

Optionally I'd like to restore content on Vol A1, but that's not vital, since I can clone Server A from Server B quite easily (and Server A is going to be reinstalled anyway).

Thank you in advance!

[Roy Main]

uh.... there should still be data on A2. Haven't seen anything you said that would have caused loss of data on that volume...

Here's the way I would try it - one change at a time.

Take B2 out and put it in Server A. Leaving the rest of Server A in it's original configuration. Only change is a new B2.

Then when all is well with Server A, remove A2 and move it to Server B. Follow the same steps.

The SA firmware should see the new disks and add them in using the configuration already on the disks.