Asset ID: |
1-71-1487881.1 |
Update Date: | 2012-10-01 |
Keywords: | |
Solution Type
Technical Instruction Sure
Solution
1487881.1
:
Pillar Axiom: How to Copy Data From One Lun To Another One
Related Items |
- Pillar Axiom 600 Storage System
- Pillar Axiom 500 Storage System
|
Related Categories |
- PLA-Support>Sun Systems>DISK>Pillar Axiom>SN-DK: Ax500
|
Created from <SR 3-6086337115>
Applies to:
Pillar Axiom 500 Storage System - Version All Versions and later
Pillar Axiom 600 Storage System - Version All Versions and later
Information in this document applies to any platform.
This document explains steps when you want to move data on an existing LUN to another LUN.
Goal
This document explains steps when you want to move data on an existing LUN to another LUN when:
- new brick added to system and need to move data to new brick(s);
- need to use same data for test/reporting or some other purposes;
- need to change QoS level of existing data/LUN without affecting current environment.
Fix
You can use Copy LUN or Clone LUN options available on Axiom Gui. Startying from release 4.5 these function licenses are already included in standart Axiom.
Copy LUNs
You can copy an existing LUN and give the new LUN different Quality of Service (QoS) metrics. This copying allows system resources to be maximized for the task at hand. For example, a copied volume that is used for reporting is assigned a lower performance priority and a higher read-centric access pattern than would the source volume.
You can also copy a Clone LUN. Such a copy will always depend on its source LUN. Also, you cannot choose different QoS attributes for a Clone LUN.
Copy a Clone LUN when you want to test a new application on an exact copy instead of on the original LUN.
Copy a LUN when you need a new LUN with the same starting data as an existing LUN.
Another reason to create a clone or a copy is to preserve a point-in-time view of the data. If you create a clone for this purpose, at a later time you can restore the data to the source LUN.
Unlike a clone, the new blocks for the copy may be on a different set or even a different type of Brick. In other words, a volume copy of a Fibre Channel or solid state drive (SSD) based, premium priority LUN may be created in the low-priority band on SATA Bricks.
1 Click the Storage icon in the top context pane.
2 Click the LUNs link in the left navigation pane.
3 Select a LUN, and choose Copy LUN from the Actions drop-down list.
4 Name the LUN copy.
5 Click the Quality of Service tab to define the QoS attributes of the new LUN (optional).
6 Click Optimizer to see the effect that these settings would have on the amount of capacity (GB) that is available based on the Storage Class and redundancy settings (optional).
7 To save the new LUN, click OK.
For parameter definitions, see the LUN, Quality of Service Tab.
You can find copy steps and details in Pillar Axiom Administrator's Guide.
Starting with release 5 you can define a storage profile and give bricks to use this new profile while creating Copy LUN action.
QoS – Quality of Service details are below:
Levels: LUNS are balanced across disks (bricks)
· Premium: 100% of FC drives (in a mixed environment only)
· High (Tier 1): 48 Disk Spindles (4 Bricks)
· Medium (Tier 2) 36 Disk Spindles (3 Bricks)
· Low (Tier 3) 24 Disk Spindles (2 Bricks)
· Archive (FS) 24 Disk Spindles (2 Bricks)
Premium — highest performance and availability (available when using Fibre Channel drives)
High (Tier 1) — high performance and availability levels for mission-critical applications
Medium (Tier 2) — increased performance and high availability for mid-performance applications
Low (Tier 3) — adequate performance and availability to support business-utility applications such as file sharing
Archive — cost-effective archive with compliance option
When you would like to move some LUNs from SATA bricks to the FC bricks than you should use higher QoS parameters than existing one and use Premium to make sure they will go to FC brick.
The approximate expected copy speed for a LUN copy job is 2TB per hour. That is given the best circumstances where there isn't a lot of other host I/O being served.
If there are other operations (such as regular day to day traffic, or a backup job) this estimate may be lower.
It is receommended to schedule the copy job at a period of low I/O to allow the Axiom controller to efficiently copy the LUN data without doing much else.
Attachments
This solution has no attachment