Can I reconfigure HSG80 without affecting data on disks

[Ninad_1]

Hello All,

Suppose I have a raidset of 5 disks and a mirrorset of 2 disks configured on a HSG80
controller in a RA8000. Suppose for some reason the configuration goes bad , if I have the details of the configuration with me is it possible to reconfigure the raidsets/mirrorsets
on HSG80 with the disks already having the data and without damaging the data on the disks ?

Thanks in advance
Ninad

[Michael Schulte zur Sur]

Hi,

you should be able to do it. Do however use no init!

Michael

[Ninad_1]

But in the books the init command always follows the configuration commands used for say either raidset or a mirrorset
So you mean to say that after adding disks to a raidset and assigning it a unit number it will be fine if I do not use the
init unitnumber command ?
Will try that on some spare disks and will see if it works.
Please wait for your points till then :)

Thanks
Ninad

[dentistcorn]

The is a section in the configuration & setup manual on moving storage sets. Follow those instructions and you should be OK.

I don't know for sure what you intend to do on the G80 controller but, if you do a config reset with the disks attached you will blow out your disks/storagesets/luns and lose your data.

[Uwe Zessin]

Ninad,
you cannot add disks to an existing raid(-5)set on the HSG80 and expect your data being intact - it does not even remotely work like a Smart Array Controller, if you are familiar with it! Remember how a RAID-5 set distributes its data - a 4-member set has a different strip-size than a 5-member set.

Also, you cannot delete the raid(-5)set, re-create it with additional disks and just put a unit on top of it. The additional disks are missing the metadata that specifies the container they belong to. The 'ADD UNIT' command _should_ fail with an error message like 'Container metadata check failed'. I wrote _should_ because I have seen situations where a controller crashed when I was (incorrectly) working with uninitialized clones.

Only an INITIALIZE writes new metadata down to all disks.


It is possible to leave off the INITIALIZE if you intend to move physical disks around in the array. In that case you delete all affected objects (units, storageset and disks) top-down, move the disks and re-add the objects, just bottom-up.

[Michael Schulte zur Sur]

Uwe,

I think, he justs wants to recreate the units in case the controller loses it's configuration, no adding of disks.

greetings,

Michael

[Ninad_1]

You are right Michael.
I just want to know what all I can do safely before hand so that I am confident if any situation arises.
By the way thanks Uwe, I am aware that I cant add disks to existing raid.
Points for you Uwe and Michael await since first I am going to try with 2 disks I have as spare with a mirrorset , write some data onto it , delete the disks from mirrorset and readd without init and check if the data exists.
Wish me luck and hope nothing else goes wrong folks !!

Ninad

[Uwe Zessin · Accepted solution]

Hello Michael & Ninad,
then it looks like I have misunderstood this question (emphasis mine):
"So you mean to say that after adding disks **to** a raidset and assigning it a unit number it will be fine if I do not use the
init unitnumber command ?"

I'd say it depends on _when_ you loose the configuration on both controllers at the same time. I am sure you can just re-add all objects (disks, storagesets, units) most at the time, because the metadata is not updated very often. If it happens while there is still data in the writeback-cache I would not have much hope for its consistency as the WBC will undermine any 'careful write ordering' of the file system or the database.

Before you start moving disks around I strongly recommend that you take a snapshot of your configuration - here is a list of commands that I use:
--
show this_controller full
show other_controller full
show disks full
show mirrorsets full
show stripesets full
show raidsets full
show concatsets full
show units full
show id
show remote_copy_sets full
show associations full
show connections full
show sparesets
show failedsets
show manager
--
Then you should check that no storageset is reduced or rebuilding. I would make a plan which disks to move (old/new location) and put small labels on all affected disks. If you move spare disks, add them after all other units have been created and found intact. Adding any disk to a spareset overwrites old metadata!

Good luck! It is not really black magic - I have done it several times in the past and never lost any data, pheww..

[Michael Schulte zur Sur]

Ninad,

so far I can only assume, you have a single hsg80 configuration and not a dual redundant one.

If I am not mistaken, you can save the configration in a single controller environment onto the disks, where a replacement controller would restore it's configuration from. This has to be done at the moment of init and it's not possible in dual redundant configuration.

Uwe, I think that the hsg80 behaves like the hzs40/50. If not so, correct me please, ok?

greetings,

Michael

[Uwe Zessin]

Michael,
the HSG80 allows you to save the configuration on the disks of a storage set and you are right that it must be done during INITIALIZE. This reduces the usable size of the storage set by several hundred blocks. There have been problems in the past, so some ACS versions with certain patches do not allow saving the configuration on disks.

It is possible to save the configuration on a dual-controller system, too, but it is not supported by the vendor.

If you ever want to get rid of the configuration you have to use 'INITIALIZE container NOSAVE_CONFIGURATION'. This will make the lost space available again, but you might no longer be able to access your data.

If you can afford it, you can always use a single disk just to hold the configuration.

[Mike Naime]

Ninad:

Yes, you can do what you are asking. You can even do it in another HSG if necessary!

We had an HSG80 backplane fry (It released the magic smoke!!!) that took out both HSG80 controllers, the EMU units, and a cache module.

After replacing everything that fried, we where able to restore the configuration from one of the disks. All of our data was intact. We did not have to re-load from backups.


You can also move/relocate storage sets between HSG80's. I have done this in the past. I took a 22 drive layout that was composed of 7 mirrorsets and 2 raidsets. I transfered it into another HSG80 for some testing.

Experiment 1: I used the exact same same slots on all of the disks drives. I.E. If it came out of DISK10100, I put it back in as DISK10100. Everything came out fine.

Experiment 2: I installed it into a different BA370 shelf. I.E. If it was Disk 10000, I put it into slot 10900... Etc. Basiclly the exact same layout as cabinet 0, but installed into cabinet 2. This also worked!

Experiment #3. Reversing everything. I reversed the order of the drives. Raidsets had the disks installe din revers order.
Once again, everything worked.

Experiment #4. Shuffeling raidset disks.
I mixed the order of the raidset disks. Once again everything worked ok.

Notes:
1.)When I installed the disks into the new cabinet, I used the INIT {storageset} NODESTROY command.
2.)I waited for the drives to normalize/reconstruct before I tried using them. Very important for the raidset re-construction.


Mike Naime