Ibm Bto SNV1 Student Guide Book 1 525 593 1 35 PDF

Student Notebook
Create volume copy in lower-cost storage tier
© Copyright IBM Corporation 2011, 2014
Figure 5-65. Create volume copy in lower-cost storage tier SNV13.0
Notes:
To request a thin-provisioned volume copy, click the radio button for Thin-Provisioned in the
Volume Type box.
The target pool selected is the DS3K_SATApool (pool ID 1). The aim of this exercise is not only to
convert the volume to Thin-Provisioned, but also migrate it to a lower cost storage tier.
Study the addvdiskcopy command generated by the GUI. A thin-provisioned volume copy 1 is
being add to volume ID 9; using extents in pool ID 1 which is the DS3K_SATApool.
Not surprisingly, the GUI uses the Thin-Provision preset attributes for this copy - automatically
expand, real capacity as 2% of virtual capacity, and a warning threshold of 80%. The default grain
size is taken and is not be explicitly coded.
5-68 SVC Implementation Workshop © Copyright IBM Corp. 2011, 2014

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
V10.0
Student Notebook
Uempty
Thin-provisioned volume copy 1 allocated
Figure 5-66. Thin-provisioned volume copy 1 allocated SNV13.0
Notes:
The volume details pane confirms two volume copies exist with copy 1 being very thin.
© Copyright IBM Corp. 2011, 2014 Unit 5. SVC enhanced features 5-69
Student Notebook
Thin-provisioned volume copy synchronization
Thin-Provisioned
copy added for
APPVOL1
Figure 5-67. Thin-provisioned volume copy synchronization SNV13.0
Notes:
Synchronization for volume copy 1 of the APPVOL1 volume is in progress.
Examine the Volume Allocation capacity bar for the DS3K_SATApool in the Volumes by Pool
view and note the capacity values displayed. In addition to the real capacity consumed by the
volumes of the pool: Two values for the pool capacity are displayed:
Capacity (atop the bar): This is the total capacity of the MDisks of the pool.
Virtual Capacity (beneath the bar): This is the total capacity of the volumes (based on the virtual
capacity of volumes).
Note that the virtual capacity of the pool might be greater than the actual or physical capacity of the
pool (referred to as overallocation). This is why storage pools might also be defined with a space
warning threshold. Pools created using the GUI have warning threshold default of 80% (of physical
capacity).

V10.0
Student Notebook
Uempty
Volume copy 1 synchronized with copy 0
Figure 5-68. Volume copy 1 synchronized with copy 0 SNV13.0
Notes:
Review the used and real capacity values for volume copy 1. Recall the host capacity data: The free
capacity of the disk is around 38 GB of the 100 GB total capacity. SVC shows volume copy 1 is
using around 62 GB real capacity - pretty close to host capacity data.
SVC Volume Mirroring releases unused capacity during volume copy synchronization. Unused
capacity is defined to be a string of zeros - where the length of the string is defined by and aligned
with the grain size. In this example the grain size for copy 1 was defaulted to 256 K when copy 1
was added to the volume. Each 256 K grain of zeros found in volume copy 0 became free space
and does not use real capacity in copy 1.
As an aside, when host write activity to a thin-provisioned volume aligns to a grain sized area of
zeros, no real capacity is allocated/used when running with SVC models 2145-CF8 or 2145-CG8.
Also note that copy 1 has an Easy Tier status of inactive because it resides in a pool whose Easy
Tier status is inactive.
Student Notebook
APPVOL1 extent distribution of volume copies
copy 0
copy1
extents
extents
SWV7K_SASpool DS3K_SATApool
Figure 5-69. APPVOL1 extent distribution of volume copies SNV13.0
Notes:
Volume copy 0 (the extents in the SWV7K_SASpoo) will be deleted since the goal is to convert the
fully allocated volume to Thin-Provisioned in a lower tier storage pool based on life cycle objectives.
Take note that 22 extents of volume copy 0 had been moved by Easy Tier to the SSD-based MDisk.
These extents, along with all the extents on the other MDisks, will be freed once volume copy 0 is
deleted. Each volume copy is managed independently by Easy Tier; based on the activity
associated with extents of the individual volume copy.

V10.0
Student Notebook
Uempty
Delete fully allocated volume copy 0
copy 0
copy1
extents
extents
SWV7K_SASpool DS3K_SATApool
Figure 5-70. Delete fully allocated volume copy 0 SNV13.0
Notes:
Right-click the volume copy 0 entry and select Delete this Copy. Extents associated with volume
copy 0 are freed in the SWV7K_SASpool. The APPVOL1 will no longer be a member of this pool.
Student Notebook
Volume details: After copy 0 has been deleted
Copy 1
APPVOL1
Note: Host system deletes do not zero out data areas.

OS utilities might be available to zero unused data areas.
Volume copy releases grain-sized strings of zeros.
Figure 5-71. Volume details: After copy 0 has been deleted SNV13.0
Notes:
Only volume copy 1, the Thin-Provisioned copy, remains. It is using less storage capacity. The
volume also has been migrated to the DS3K_SATApool (lower cost storage tier) as part of its life
cycle management.

V10.0
Student Notebook
Uempty
Volume converted to Thin-Provisioned
11
9
Copy 1 Copy 1
APPVOLA
APPVOL1
SWV7K_SASpool
DS3K_SATApool
APPVOL1 is Thin-Provisioned (no longer fully allocated)

APPVOL1 migrated to lower-cost tier storage pool
Figure 5-72. Volume converted to Thin-Provisioned SNV13.0
Notes:
From the host perspective, nothing has changed: The same two volumes are still mapped to the
host for both read/write access.
Recall the example environment from the beginning of this unit:
• APPVOL1 was a 100 GB fully allocated volume in the SWV7K_SASpool.
• APPVOLA was a 100 GB thin-provisioned volume in the DS3K_SASpool.
• And note now:
• APPVOL1 is a 100 GB thin-provisioned volume in the DS3K_SATApool.
• APPVOLA is a 100 GB fully allocated volume in the SWV7K_SASpool.
Both volumes obviously still have the same object IDs and UIDs: Preserving host access
transparency.
The magic of SVC virtualization (actually extent pointers) affords the freedom of changing the
backend storage infrastructure without host impact; and the opportunity to exploit newer technology
to optimize storage efficiency for better returns on storage investments.
Student Notebook
Host view: Volume is still original size
Figure 5-73. Host view: Volume is still original size SNV13.0
Notes:
Nothing has changed from a host perspective.

V10.0
Student Notebook
Uempty
SVC enhanced features topics (4 of 6)

• Easy Tier
• Thin Provisioning
• Volume Mirroring
• Real-time Compression
• Comprestimator utility
• Easy Tier STAT reporting
Figure 5-74. SVC enhanced features topics (4 of 6) SNV13.0
Notes:
In this topic discusses, we will take a look a how Real-time Compression works in an SVC
environment.
Student Notebook
Real-time Compression (RtC) integration

SVC node I/O stack Active primary data
SCSI Target of host
Forwarding • Host servers operate with uncompressed data
Replication • Copy services operate with uncompressed data
• Compression implemented within Thin Provisioning layer of
Upper Cache node I/O stack
FlashCopy
• Only uses physical storage for compressed data
• Volume Mirroring allows non-disruptive conversions –
Mirroring uncompressed ÅÆ compressed
Random Access
Thin Provisioning Compression
Compression Engine
Lower Cache (RACE)
Virtualization Easy Tier 3 Available with v6.4.0
Forwarding 2145-DH8 A compressed volume is

Compression a variation of
RAID a thin-provisioned volume.
Accelerator card
Forwarding required Volume properties
includes uncompressed
Compressed volume capacity indicator.
SCSI Initiator in storage box
Figure 5-75. Real-time Compression (RtC) integration SNV13.0
Notes:
Beginning with v6.4.0, Real-time Compression (RtC) software is embedded in the SVC to address
the requirement of data reduction for active primary data while maintaining application
performance. With the v7.3 code, Real-time Compression has been enhanced to provide
improvements in performance with the delivery of SAN Volume Controller (2145-DH8) hardware
platforms, including use of the optional compression accelerator card feature. Updates to the cache
architecture provide further improvements to overall performance. However, in order to use the
compression function, you must obtain the IBM Real-time Compression license and the hardware
level for both nodes within the I/O group must be either SAN Volume Controller 2145-DH8,
2145-CG8, or 2145-CF8 for that I/O group to support compression.
Compression technology delivered by the Random Access Compression Engine (RACE) has been
integrated seamlessly in the Thin Provisioning layer of the node I/O stack so that existing SVC
functions and features are supported for compressed volumes.
A compressed volume is a variation of a thin-provisioned volume. Host servers and Copy Services
operate with uncompressed data. Compression occurs on the fly in the Thin Provisioning layer so
that physical storage is only consumed by compressed data.

V10.0
Student Notebook
Uempty For existing volumes, the Volume Mirroring function can be used to nondisruptively add a
compressed volume copy. The original uncompressed volume copy can then be deleted. A
compressed volume can also become uncompressed with the same volume copy functionality
provided by Volume Mirroring.
Student Notebook
SVC v7.3 Compression enhancements

• Compression enhancements:
ࡳ Main cache stores compressed data (more effective cache capacity)
ࡳ Full stride writes for compressed volumes
ࡳ Support larger number of compressed volumes
• Compression Accelerator Card mandatory for I/O Group with 2145-DH8
(minimum of one for each node)
௅ Attempts to create a compressed volume will fail
௅ Addnode command will fail if trying to add a DH8 without Compression
Accelerator card
• Up to two Compression Accelerator adapters
௅ Installed in slots 4 and 6
• Can be installed in any I/O slot connected to
second processor – if available
௅ Up to 512 compressed volumes x4 compressed
accelerator adapters
Figure 5-76. SVC v7.3 Compression enhancements SNV13.0
Notes:
SAN Volume Controller 2145-DH8 nodes must have two processors, 64 GB of memory, and at least
one Compression Accelerator adapter installed in order to use compression. Enabling compression
on SAN Volume Controller 2145-DH8 nodes does not affect non-compressed host to disk I/O
performance.
I/O group recommendations:
• It is strongly recommend to place Compression Accelerator cards into their dedicated slots 4
and 6. However, if there is no I/O card installed in slot 5, a compression card can be in any slot
connected to this second processor.
• Up to a total of two Compression Accelerator adapters can be installed. Each additional that is
installed improves the I/O performance and in particular the maximum bandwidth when using
compressed volumes.
• For an I/O group containing a 2145-DH8 with no Compression Accelerator, an attempt to create
a compressed volume fails. The addnode command will also fail if trying to add a 2145-DH8
without a Compression Accelerator to an I/O group or system which already has any
compressed volumes.

V10.0
Student Notebook
Uempty • An I/O group consisting of 2145-DH8 nodes with a single Compression Accelerator in each
supports a maximum of 200 compressed volumes, while a fully equipped I/O group with four
Compression Accelerators supports up to 512 compressed volumes.
In the previous SVC code, compression is supported for a maximum of 200 compressed volumes
per I/O group – this limit applies only to compressed volumes. A cluster with four (4) I/O groups can
support as many as 800 compressed volumes. With SVC v7.3 code using SAN Volume Controller
(2145-DH8), compression is supported for a new maximum of 512 compressed volumes per I/O
group.
Student Notebook
RtC: Storage asset optimization efficiency

SVC embedded Real-time Compression (RtC):
• Provides high performance compression of active primary data
• Operates transparently and immediately for ease of management
• Enhances and prolongs value of existing storage assets
• Supports both internal and externally virtualized storage
Figure 5-77. RtC: Storage asset optimization efficiency SNV13.0
Notes:
SVC embedded Real-time Compression (RtC):
• Provides high performance compression of active primary data
- Supports workloads off-limits to other alternatives
- Expands candidate data types for compression
- Derives greater capacity gains due to more eligible data types
• Operates transparently and immediately for ease of management
- Eliminates need to schedule post-process compression
- Eliminates need to reserve space for uncompressed data pending post-processing
• Enhances and prolongs value of existing storage assets
- Increases operational effectiveness and capacity efficiency; optimizing back-end cache and
data transfer efficacy
- Delays the need to procure additional storage capacity; deferring additional capacity-based
software licensing

V10.0
Student Notebook
Uempty • Supports both internal and externally virtualized storage

- Compresses up to 512 volumes per I/O group (v7.3 code)
- Exploits the thin-provisioned volume framework
Student Notebook
RACE innovation: Temporal locality compression

RACE: Dynamic compression of data
written temporally (around the same
Host update sequence
time); not according to physical location
1
2 Temporal locality adds time dimension
3 to live application data access patterns
Traditional compression RACE compression innovation:

Location Achieves higher compression ratios
Compression Enables advanced read ahead
1 Window Obtains superior decompression efficiency
2
Facilitates on the fly
data compression
Temporal and random access retrieval
3 Compression
Three compression actions Window One compression
(based on physical data location) action
1 2 3
# = File Update RACE compression
Time
Figure 5-78. RACE innovation: Temporal locality compression SNV13.0
Notes:
Traditional data compression is location-based. It compresses data by locating repetitions of bytes
within a given chunk of data to be compressed. The compression ratio is affected by how
repetitions can be detected and how much these bytes stored in the same chunk are related. The
relationship between bytes is affected by the format of the object (for example, text and graphics
embedded together); which might yield a lower compression ratio.
RACE offers an innovation leap by incorporating a time-of-data-access dimension into the
compression algorithm called temporal compression. When host writes arrive, multiple compressed
writes are aggregated into a fixed size chunk called a compressed block. These writes are likely to
originate from the same application and same data type, thus more repetitions can usually be
detected by the compression algorithm.
Due to the time-of-access dimension of temporal compression (instead of creating different
compressed chunks each with its unique compression dictionaries) RACE compression causes
related writes to be compressed together using a single dictionary; yielding a higher compression
ratio as well as faster subsequent retrieval access.

V10.0
Student Notebook
Uempty
Compression implementation guidelines

• Target workloads suitable for compression - examples:
Data types/applications Compression ratio
Oracle/DB2/SQL/SAP Up to 80%
MS Office 2003 Up to 60%
CAD/CAM Up to 70%
Oil/Gas Up to 50%
VMware – Windows OS Up to 45-55%
VMware – Linux OS Up to 70%
• Avoid workloads not suitable for compression:

– Pre-compressed data (MS Office 2007 or later, video, audio,
images, executables, zipped, encrypted, PDFs)
– Heavy sequential writes and reads
• Use Comprestimator utility to evaluate expected compression
benefits for data on existing volumes
Figure 5-79. Compression implementation guidelines SNV13.0
Notes:
Not all workloads are good candidates for compression. The best candidates are data types that
are not compressed by nature. These data types involve many workloads and applications such as
databases, character/ASCII based data, email systems, server virtualization infrastructures,
CAD/CAM, software development systems, and vector data.
Use the IBM Comprestimator utility to evaluate workloads or data on existing volumes for potential
benefits of compression. Implement compression for data with an expected compression ratio of
45% or higher.
Do not attempt to compress data that is already compressed or with low compression ratios. They
consume more processor and I/O resources with small capacity savings.
RtC algorithms are optimized for application workloads that are more random in nature. Heavy
sequential read/write application access profiles might not yield optimal compression ratios and
throughput.
Refer to the Redpaper REDP-4859: Real-time Compression in SAN Volume Controller and the
Storwize V7000 for reference.
Student Notebook
Compression Performance
Maximum performance (one I/O Group)
Compressed SVC CG8 SVC DH8
Read Miss IOPS 2,600-50,000 71,000-175,000
Write Miss IOPS 1,200-16,000 28,000-115,000
“DB-like” 2,200-40,000 59,000-149,000
•Compressed performance shows a range depending on I/O

distribution
•Compressed performance is better than uncompressed in some
cases because of fewer I/Os to drives and additional cache benefits
Figure 5-80. Compression Performance SNV13.0
Notes:
The compression process on older 2145-CG8 and CF8 models was entirely software-based,
consuming some of the CPU resources, which lowered the maximum IOPS of the solution. With the
2145-DH8 compression using eight cores, more RAM, and hardware-assisted compression chips,
provides more IOPS than an older 2145-CG8 without compression. This example lists a range of
compressed IOPS that are based on one I/O group. For instance, the Read Miss IOPS between the
CG8 node versus the DH8 node shows that the DH8 more than doubled the performance in IOPS,
around 2x the IOPs and up to 3x the GB/sec.

V10.0
Student Notebook
Uempty
SVC node hardware resources used by RtC

No compressed At least one compressed
SVC node model
volumes volume allocated
System CPU System CPU Compression
cores cores CPU cores
2145-CF8 – 4 cores CPU type E5530 4 1 3
2145-CG8 – 4 cores CPU type E5630 4 1 3
2145-CG8 – 6 cores CPU type E5645 4 2 4
2145-CG8 Chubby CPU type E5645 x 2 4 4 8
2145-DH8 (Dual) CPU type Intel Xeon E5

8 8 8
2650 v2
• Prior to creating a compressed volume, CPU utilization should be:

௅ No more than 25% for listed CPU types with 4 cores
௅ No more than 50% for listed CPU type with 6 cores
• Chubby node iRPQ recommended as all 6 additional CPU cores and 24 GB cache are used
for compression
• 2145-DH8 second CPU 8-cores used only for compressed volumes
௅ Open PCIe lanes and schedule traffic into and out of the compression accelerator cards
Figure 5-81. SVC node hardware resources used by RtC SNV13.0
Notes:
For the compression-capable SVC CG8 or CF8 node models, if compression is not activated, each
node’s 4 CPU cores and 24 GB of cache memory are used for system processing. Compression is
activated on a per I/O group basis. When the first compressed volume is allocated for the I/O group,
a required amount of CPU cores and 2 GB of cache is reserved or dedicated to compression
processing on a per node basis.
For nodes shipped with 4 CPU cores, 3 of the 4 CPU cores are set aside for compression
processing, leaving only 1 CPU core for system processing. Therefore the existing CPU utilization
(before compression) should not exceed 25%.
For nodes shipped with 6 CPU cores, 2 of the 4 CPU cores are set aside for compression
processing; leaving 2 CPU cores for system processing. Therefore the existing CPU utilization
(before compression) should not exceed 50%. The 2 CPU cores taken from system processing
along with 2 reserved CPU cores provide 4 CPU cores for compression.
The Chubby node iRPQ is recommended - it provides an additional 24 GB of cache and 6 CPU
cores dedicated to compression; and returns 2 CPU cores to system processing.
Student Notebook
Whereas with the 2145-DH8 node you have 16-cores (two 8-core processors), each with 32 GB of
memory. Without RtC activated, non-compressed volumes utilizes 8-cores for system processing.
When RtC compression is activated, the second 8-core is used only (at this time) to open the PCIe
lanes as well as schedule traffic into and out of the compression accelerator cards installed.

V10.0
Student Notebook
Uempty
SVC node hardware data and Chubby node iRPQ
CG8 Chubby node iRPQ 8S1296 adds

another CPU card with 24 GB cache
Figure 5-82. SVC node hardware data and Chubby node iRPQ SNV13.0
Notes:
Node hardware data can be displayed from the GUI Monitoring > System view for a given node.
Within the node properties notebook, the Hardware tab displays the node hardware model, cache
memory amount, and the CPU core type.
In this example, an iRPQ (8S1296) is available to optionally add another CPU card to the
2145-CG8 CPU type 5645 node (if no internal SSDs are installed due to overlap in physical
location). This card provides 6 CPU cores and 24 GB cache memory dedicated to compression.
When installed, the CG8 node is fondly referred to as a Chubby node.
Student Notebook
Allocate compressed volume: Compressed preset
1 RtC compression is
activated when the first
compressed volume is
created; and
deactivated when the
last compressed
volume is removed
from the I/O group.
Storage pool to
2 I/O group allegiance
due to Easy Tier
active pool using
internal SSDs from
io_grp0
Figure 5-83. Allocate compressed volume: Compressed preset SNV13.0
Notes:
Select the Compressed preset to create compressed volumes. A warning message is
automatically displayed when the first compressed volume is to be created. Hardware resources
(CPU cores and cache) are reserved when compression is activated for an I/O group. These
resources are freed when the last compressed volume is removed from the I/O group.
Focus on the Preferred I/O group ID column for the listed storage pools. The DS3K_SASpool has
a preference or allegiance to I/O group 0 as it contains a SSD-based MDisk created from internal
drives of nodes in I/O group 0. By default the GUI assigns volumes being created in this pool to I/O
group 0.

V10.0
Student Notebook
Uempty
Allocate a compressed volume: Preset defaults
4
Compressed
8 preset defaults
(Thin-Provision preset
Click the Create button
minus grain size)
7
Figure 5-84. Allocate a compressed volume: Preset defaults SNV13.0
Notes:
Review the Summary statement resulting from this volume creation request. Notice that only 1 GB
of real capacity is to be allocated for this 50 GB volume.
To view the defaults for by the Compressed preset, click the Advanced button from the New
Volume pane then select the Capacity Management tab of the Advanced Settings - New
Volume pane. The Compressed radio button is selected by default with this preset.
Review the Options box for the Compressed preset: Its defaults are almost identical to that of the
Thin-Provision preset. A compress volume is a variation of a thin-provisioned volume. The only
difference between the two presets is the grain size attribute. Compressed volumes do not have an
externally controlled grain size.
Student Notebook
Allocate compressed volume and map to host
Compressed 50 GB volume
in io_grp0
object ID 12 created
Figure 5-85. Allocate compressed volume and map to host SNV13.0
Notes:
Review the mkvdisk command generated by the GUI - the -compressed parameter defines the
volume being allocated as a compressed volume.
The -autoexpand, -rsize, and -warning parameters, used to define thin-provisioned volumes,
are also used to define compressed volumes.
A compressed volume, COMP1 of 50 GB, is created with an assigned object ID of 12 and a caching
IO group of 0. It is then mapped to host REDWIN1.

V10.0
Student Notebook
Uempty
Compressed volume copy: Details
Beginning with v7, Easy Tier is

supported for compressed volumes
Figure 5-86. Compressed volume copy: Details SNV13.0
Notes:
Examine the Copy 0 details of the COMP1 volume. The capacity bar has the appearance of a
thin-provisioned volume. Its capacity details contain statistics related to compression. At initial
creation, only capacity for volume metadata has been allocated.
A volume is owned by an I/O group and is assigned a preferred node within the I/O group at volume
creation. Unless overridden, the preferred node of a volume is assigned in round robin fashion by
the system.
This volume is owned by io_grp0 and NODE2 has been assigned as its preferred node. Data
compression is performed by the preferred node of the volume.
Beginning with v7.1, Easy Tier supports compress volumes. Only random read operations are
monitored for compressed volumes (versus both reads and writes). Extents with high random reads
(64 K or smaller) of compressed volumes are eligible to be migrated to tier 0 storage.
Student Notebook
Compression active for I/O group
Compression Active –
node CPU cores +
cache are reserved
for I/O group
Figure 5-87. Compression active for I/O group SNV13.0
Notes:
In the Monitoring > System view, the system capacity column now offers a Compression View
option. The Storage Allocation status pod at the lower left corner of every GUI view now contains
a Compression option to display capacity savings related to compression.
Since compression is managed at the I/O group level, click the io_grp0 enclosure to open its
properties notebook. The Compression Active setting now contains a Yes to indicate
compression has been activated for the I/O group. Node CPU cores and cache memory are now
reserved for both nodes of the I/O group.

V10.0
Student Notebook
Uempty
Host view of (compressed) volume and host I/O
Compression done
by volume’s
preferred node
Write
activity
Host sees
50 GB volume
Figure 5-88. Host view of (compressed) volume and host I/O SNV13.0
Notes:
Real-time Compression is totally transparent to the host. A compressed volume appears a standard
volume with its full capacity to the attaching host system. Host reads and writes are handles as
normal I/O.
Behind the scene, compression is managed by the preferred node of the volume. As data is written,
it is compressed on the fly by the preferred node before written to the storage pool.
In this example, the Window host “sees” a 50 GB volume. After some write activity, it has about 30
GB of free space.
Compression CPU utilization can be monitored from Monitoring > Performance. Use the
drop-down list to select and view CPU utilization data of the preferred node of the volume.
Student Notebook
Volume copy details and compression statistics
Figure 5-89. Volume copy details and compression statistics SNV13.0
Notes:
As write activity occur, compression statistics are updated for the volume. In this example, the
folder written would have taken 19.45 GB of capacity. But due to compression, only 5.43 GB was
written, resulting in a capacity savings around 72% ((19.45-5.43)/19.45).
Beginning with v7, compressed volumes are eligible for Easy Tier management. With v6.4, a
compressed volume can reside in a hybrid storage pool, but its extents will not be migrated to/from
the SSD-based storage tier.

V10.0
Student Notebook
Uempty
Storage pool view and compression statistics
GUI provided GUI provided

benefit analysis benefit analysis
of compression of compression
for volume for pool
(14.02 / (14.02+5.43)) = 72.08%
Figure 5-90. Storage pool view and compression statistics SNV13.0
Notes:
One way to view the details of the storage pool that contains the COMP1 volume is to go to
Volumes > Volume by Pools then click the pool name, DS3K_SASpool, in the Pool Filter list.
Upon the creation of the first compressed volume in a storage pool, the Compression Savings bar
is included in the pool details to display compression statistics at the pool level. In this case, the
total compression savings thus far is 72%. Using the numbers shown in the savings capacity bar
area, the 76% savings is derived from (14.02/(14.02+5.43)).
The compression statistics for the volume entry is displayed in the Compression Savings column.
The statistics related to compression are dynamically calculated by the GUI. These calculations of
percentages of savings are not available with the CLI.
Student Notebook
System level compression statistics and

storage efficiency savings
GUI provided
benefit analysis
of compression
for system
GUI provided
storage efficiency
savings due to
compression
(1 – (5.43/50.00)) = 89.14%
Figure 5-91. System level compression statistics and storage efficiency savings SNV13.0
Notes:
Go to the Monitoring > System view to obtain compression statistics and savings aggregated at
the system level. Given that only one 50 GB compressed volume has been allocated so far, it is a
bit easier to relate to the capacity values shown.
The Compression View of the system capacity column presents capacity utilization from three
different perspectives:
The total virtual capacity of compressed volumes and their capacity savings due to Thin
Provisioning (if no writes were issued from the host, due to being Thin-Provisioned, no real capacity
would be allocated for compressed volumes).
The total capacity that would have been written if compression wasn’t implemented
(Thin-Provisioned but not compressed) and the amount of capacity saved due to compression. This
data is also a display option in the Storage Allocation status pod.
The total actual capacity consumed to store the compressed data.
The Compressed Volumes section of the system Info notebook identifies the storage efficiency
savings due to compression. Only 5.43 GB, instead of 50 GB, has been used; resulting in a
capacity savings of 89%.

V10.0
Student Notebook
Uempty
SVC enhanced features topics (5 of 6)

• Easy Tier
• Thin Provisioning
• Volume Mirroring
• Real Time Compression
• Comprestimator utility
• Easy Tier STAT reporting
Figure 5-92. SVC enhanced features topics (5 of 6) SNV13.0
Notes:
This topic discusses examines the benefits of the Comprestimator utility tool.
Student Notebook
Comprestimator: Compression benefits
Supported host OS’s:

AIX, HP-UX, Linux, Solaris
IBM i series through VIOS host
ESXi
Windows (32/64-bit)
Comprestimator: Identify compression candidates:
•Runs on hosts that have access to candidate volumes to
be compressed
•Samples (reads, no writes) existing volume content to
analyze potential compression savings
• Provides an estimated compression savings range
Download tool and documentation
http://www14.software.ibm.com/webapp/set2/sas/f/comprestimator/home.html
Figure 5-93. Comprestimator: Compression benefits SNV13.0
Notes:
Not all data types are suitable for compression. The Comprestimator utility is designed to estimate
expected compression rates for block-based volumes that contain existing data.
The Comprestimator is a host based command line executable available from the SVC support
website. The utility and its documentation can also be found by performing a web search using the
key words ‘IBM Comprestimator’.
The Comprestimator supports a variety of host platforms. It employs advanced mathematical and
statistical algorithms to efficiently perform read-only sampling and analysis of existing data volumes
owned by the given host. For each volume analyzed, it reports an estimated compression capacity
savings range; within an accuracy range of 5 percent.

V10.0
Student Notebook
Uempty
Comprestimator example 1: Low savings
JPEGs = pre-compressed data
-n : Disk number
-P : Output in
paragraph format
Copy 1
APPVOL1
Figure 5-94. Comprestimator example 1: Low savings SNV13.0
Notes:
Once the downloaded Comprestimator utility has been copied to a Windows system folder, it can
then be invoked as a program to scan an existing volume of this host.
This example shows how the Comprestimator is used to evaluate the APPVOL1 thin-provisioned
volume whose virtual size is 100 GB which comprises of JPEGs or already compressed data. The
output of the Comprestimator for the volume indicates the capacity savings of the volume is derived
mainly from Thin-Provisioning; the compression savings is not even one percent of the total
capacity. Based on this finding, this volume is definitely not a good candidate for compression.
Student Notebook
Comprestimator example 2: High savings
DBs = compression-friendly
11
Copy 1
APPVOLA
Figure 5-95. Comprestimator example 2: High savings SNV13.0
Notes:
In this example, the Comprestimator is used to evaluate the APPVOLA 100 GB, a fully allocated
volume that contains database-like files.
The Comprestimator output for this volume indicates that the real storage capacity consumption for
this volume would be reduced from 100 GB to 18.6 GB. This represents a saving of 79.1% within an
accuracy range of 5%. Only 11.2% of the capacity savings would be derived from
Thin-Provisioning.
The guideline for a volume to be considered as a good candidate is a compression savings of 45%
or more.


Ibm Bto SNV1 Student Guide Book 1 525 593 1 35 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ibm Bto SNV1 Student Guide Book 1 525 593 1 35 PDF

Uploaded by

Copyright:

Available Formats

Student Notebook

Create volume copy in lower-cost storage tier

© Copyright IBM Corporation 2011, 2014

Figure 5-65. Create volume copy in lower-cost storage tier SNV13.0

5-68 SVC Implementation Workshop © Copyright IBM Corp. 2011, 2014

Thin-provisioned volume copy 1 allocated

© Copyright IBM Corporation 2011, 2014

Figure 5-66. Thin-provisioned volume copy 1 allocated SNV13.0

Thin-provisioned volume copy synchronization

© Copyright IBM Corporation 2011, 2014

Figure 5-67. Thin-provisioned volume copy synchronization SNV13.0

5-70 SVC Implementation Workshop © Copyright IBM Corp. 2011, 2014

Volume copy 1 synchronized with copy 0

© Copyright IBM Corporation 2011, 2014

Figure 5-68. Volume copy 1 synchronized with copy 0 SNV13.0

APPVOL1 extent distribution of volume copies

© Copyright IBM Corporation 2011, 2014

Figure 5-69. APPVOL1 extent distribution of volume copies SNV13.0

5-72 SVC Implementation Workshop © Copyright IBM Corp. 2011, 2014

Delete fully allocated volume copy 0

© Copyright IBM Corporation 2011, 2014

Figure 5-70. Delete fully allocated volume copy 0 SNV13.0

Volume details: After copy 0 has been deleted

Note: Host system deletes do not zero out data areas.

© Copyright IBM Corporation 2011, 2014

5-74 SVC Implementation Workshop © Copyright IBM Corp. 2011, 2014

Volume converted to Thin-Provisioned

APPVOL1 is Thin-Provisioned (no longer fully allocated)

© Copyright IBM Corporation 2011, 2014

Figure 5-72. Volume converted to Thin-Provisioned SNV13.0

Host view: Volume is still original size

© Copyright IBM Corporation 2011, 2014

Figure 5-73. Host view: Volume is still original size SNV13.0

5-76 SVC Implementation Workshop © Copyright IBM Corp. 2011, 2014

SVC enhanced features topics (4 of 6)

• Easy Tier STAT reporting

© Copyright IBM Corporation 2011, 2014

Figure 5-74. SVC enhanced features topics (4 of 6) SNV13.0

Real-time Compression (RtC) integration

Virtualization Easy Tier 3 Available with v6.4.0

Forwarding 2145-DH8 A compressed volume is

© Copyright IBM Corporation 2011, 2014

Figure 5-75. Real-time Compression (RtC) integration SNV13.0

5-78 SVC Implementation Workshop © Copyright IBM Corp. 2011, 2014

SVC v7.3 Compression enhancements

© Copyright IBM Corporation 2011, 2014

Figure 5-76. SVC v7.3 Compression enhancements SNV13.0

5-80 SVC Implementation Workshop © Copyright IBM Corp. 2011, 2014

RtC: Storage asset optimization efficiency

• Operates transparently and immediately for ease of management

• Enhances and prolongs value of existing storage assets

• Supports both internal and externally virtualized storage

© Copyright IBM Corporation 2011, 2014

Figure 5-77. RtC: Storage asset optimization efficiency SNV13.0

5-82 SVC Implementation Workshop © Copyright IBM Corp. 2011, 2014

Uempty • Supports both internal and externally virtualized storage

RACE innovation: Temporal locality compression

Traditional compression  RACE compression innovation:

Figure 5-78. RACE innovation: Temporal locality compression SNV13.0

5-84 SVC Implementation Workshop © Copyright IBM Corp. 2011, 2014

Compression implementation guidelines

• Avoid workloads not suitable for compression:

Figure 5-79. Compression implementation guidelines SNV13.0

Traditional compression RACE compression innovation: