Removing a Disk from the 12H

[Stefan Saliba]

For performance purposes I added a single 18GB disk to my AutoRaid 12H just to increase the amount of unallocated disk space. Well I got some improvment. What I am not sure now is, can I remove this 18GB from the array without affecting the array and restore the same state before I added this disk ? (Including the redundancy)

BTW I did not create any LUNS after I inserted the disk ..

[Bill McNAMARA_1 · Accepted solution]

If the rest of your disks are all 9GB disks adding an 18GB will make no difference. The autoraid will see it as a 9GB disk until a second 18GB disk is added. The perf increase is due simply to more spindles in your luns.

You can remove it if the autoraid says its in a READY state. arraydsp
get the ID from arraydsp -i

Removing the disk will cause no problem and in fact you'll have more space available for data if you had active hot spare on.

For future add disks in double in the autoraid, and load top down left to right.

Later,
Bill

[Stefan Saliba]

Thanks bill well I was aware of the issue of adding in pairs but the customer was desperate to actually see some perf. In fact I suggested to him to invest in 4x36gigs and dual controller then stripe across luns.

thanks again bill for the quick response. BTW I owe my AutoRaid knowledge all to you ... cos you were my tutor in one of the courses at HP. It was the best course I went at HP I really learnt alot .....

Cheers

[Stefan Saliba]

BTW one last thing ... what kernel and files system parameters do you suggests to change if you have a database application with heavy writes of large files on the Autoraid.

[Bill McNAMARA_1]

Thanks for the compliment!.. always appreciated!

Relating to your question, I'd recommend following the db vendors guidelines for kernel tuning. If you're experimenting, change one parameter at a time, based on an intelligent analysis rather than a guess.. copy the system file to a safe place and/or make an ignite backup before doing too much..

You might want to analyse where perf bottlenecks exist, whether it's in cpu, memory or io and tune accordingly then. Glance will help you out there.

Here is a doc I copied from the itrc before relating to configuring the 12H for Oracle. (I can't quite recall who posted it) You could base an initial configuration on it's recommendations and fine tune after.

1) You really only need 2 LUN's per ORACLE instance. I think the myth of multiple LUN's arose out of Glance/Measureware APPEARING to indicate overloaded devices. The Measureware tools are not very good when looking at arrays; they can't be. All they see is one device.

Dividing your array into more than 2 only makes things APPEAR better but performance remain the same.It's better to save the LUN's for later use. Compute the total amount of space your database will require including archive logs and redo logs.


Create 2 equally sized LUN's that together equal your required Oracle space.


2) Create just two logical volumes but striped across both LUN's in 64K chunks. (Vxfs likes to write at that size). You want LUN0's primary path through controller X (alternate Y) and LUN1 primary path through controller Y (alternate X). This will fully utilize both external SCSI busses and increase your throughput by about 50%.


3) lvol1 will be used to store both the data and the indices. (Now don't have a duck - with the AutoRAID you have no control over the physial layout anyway).


4) lvol2 will be used to store the archive and redo logs.


5) Mount lvol1 with vxfs options convosync=direct,mincache=direct,nodatainlog
(This will bypass the unix buffers and give you essentially all the benefits of raw i/o while still using cooked files.)


6) Mount lvol2 with the conventional options. I find the archive and redo logs do better with the unix buffers.

7) Because you are bypassing so much of the UNIX buffers, you can decrease your filesystem buffers and thus allocate more buffering in the SGA where it belongs. My favorite method for database servers is to turn off dynamic buffer caches by setting bufpages to a value of about 300 MB and that is generous).


8) Allocate no more that about 60% (and less is better) of your total 12H capacity as LUNS. This will keep all your data in RAID 1/0 and again performance will increase.

If you follow these steps, I think you will be quite surprised at how well the old 12H's perform.

The best advice I can give you is: don't take my word for this - measure.


Internal 12H perf links:
(not much more than above)
http://tce-web.boi.hp.com/prod_port/Disk%20Arrays/autoraid/resources.htm

Oracle Kernel Tuning Recommendations:

http://www.hp-uxconsulting.com/hpux/oracle/KernalOracle.html

[Bill McNAMARA_1]

just after seeing.. one controller!
You can't write cache.. as you already mentioned, adding the second will dramatically improve performance.. especially on writes.. not only that, but configuring the striped and balanced lv/vg will gain up to 20MB/s... not to mention the HA advantage.

I think it makes sense to get the second controller.

Bill

[Stefan Saliba]

Excellent Bill ...

Do you know of a quick way how to benchmark writes to a device in HP-UX . Will timing of a large cp help or is there some other accurate way.

[Bill McNAMARA_1]

I'd use sar -d
vmstat -d
to get disk io stats.
Also
iostat -t

to generate the traffic, mm, well I would recommend real usage monitoring because the copy/writes will be more 'random' but to generate sheer io, either read or write,

dd if=/dev/dsk/cXtYdZ of=/dev/null
for reads.

For writes, I suppose, you could create a test lun and do a dd if=/dev/dsk/disk of=/dev/dsk/lun bs=64k

Make sure you of to an unused/test lun!!!

The autoraid will be migrating data during the write as space starts to fill up.. thus keep the test lun to a reasonable size to avoid it going into R5.. unless you want to test R5 io stats also.

If you just want to test the cp you can issue it with a
# date;cp largefile /autoraid/largefile;sync;date

To see the time to complete the command.. this is real dependant on other tasks executing at the same time, so the sar, vmstat and iostat commands will be more useful when analysed over time.

Later,
Bill