EMC Centera Virtual Pools Introduction and Principles of ... · EMC Centera Virtual Pools...

EMC Centera Virtual Pools Introduction and Principles of Operation

A Detailed Review

Abstract

This white paper describes the major principles of operation of EMC® Centera® virtual pool technology. It has been updated to reflect the specific virtual pool changes with CentraStar® 4.1. It should not be used as a replacement to the Centera Online Help for creating pools and profiles.

December 2009

Copyright © 2008, 2009 EMC Corporation. All rights reserved.

EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.

For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com

All other trademarks used herein are the property of their respective owners.

Part number H4496.1

EMC Centera Virtual Pools Introduction and Principles of Operation A Detailed Review 2

Table of Contents Executive summary ............................................................................................5 Introduction.........................................................................................................5

Audience ...................................................................................................................................... 5 Terminology ................................................................................................................................. 5

Principles of operation .......................................................................................6 Pool setup in pre-CentraStar 3.0 versions................................................................................... 6 Virtual pools in CentraStar 3.0 and later versions ....................................................................... 7

Application pool attributes ................................................................................8 Pool/profile access privileges ...........................................................................8

Privilege hierarchy ....................................................................................................................... 8 Profile types ................................................................................................................................. 9 Pool and cluster masks................................................................................................................ 9 Application pool membership..................................................................................................... 10

Pool Quota Hard Stop.......................................................................................10 Virtual pools setup............................................................................................11 Frequently asked questions (FAQs)................................................................14 Conclusion ........................................................................................................15


List of Figures Figure 1. Pool setup for pre-CentraStar 3.0 versions...................................................................... 6 Figure 2. Virtual pools for CentraStar 3.0 and later versions .......................................................... 7 Figure 3. Privilege hierarchy.......................................................................................................... 10 Figure 4. CLI command create pool <pool name>........................................................................ 12 Figure 5. CLI command show pool list .......................................................................................... 12 Figure 6. CLI command create profile <profile name>.................................................................. 12 Figure 7. CLI command show pool detail <pool name>................................................................ 13 Figure 8. CLI command show pool capacity ................................................................................. 13 List of Tables Table 1. Terminology....................................................................................................................... 5 Table 2. Summary of virtual pool changes in CentraStar 4.1........................................................ 11


Executive summary Virtual pools (VP) allow storage administrators the ability to logically segregate application data stored on EMC® Centera®. In pre-CentraStar® 3.0 incarnations, CentraStar presented a single, communal pool that housed all data stored on a cluster. The value of the VP model is that it presents a highly abstracted method of operation that protects applications from details of the underlying storage mechanics. VPs represent a natural evolution of the pool model. The advantages of subdividing the communal pool are substantial and include: • The ability to perform CentraStar operations on select subsets of data • Segregation of application data on the cluster • Capacity reporting by pool The exposed use of VPs is in data segregation and the ability to change the scope of the CentraStar Replication/Restore functions from the cluster at large to a set of discrete VPs. VPs allow us to change the scope of most cluster functions away from the global cluster to individual pools and they also make it transparent to the application accessing the EMC Centera storage.

Introduction This white paper presents an introduction to the CentraStar virtual pools technology feature introduced in CentraStar version 3.0. It also discusses the principles of operation of the virtual pools, application pool attributes, pool/profile access privileges, and answers to some of the most frequently asked questions (FAQs).

Audience This white paper is intended for customers, including IT planners, storage architects and administrators, and any others involved in evaluating, acquiring, and managing the EMC Centera storage system. This paper should not be used as a guide to create virtual pools.

Terminology The following table summarizes the commonly used terms used in this white paper.

Table 1. Terminology

Terms Definitions

BLOB Denotes the finite bit string that is the customer data. A single C-Clip™ can contain pointers to multiple BLOBs. The content of a BLOB is opaque to CentraStar. BLOBs also have associated content addresses (CAs), but they are not exposed to the applications accessing EMC Centera. This is to ensure the path to the data is always through the appropriate pointer (C-Clip).

CDF Clip Descriptor File that contains the associated metadata for the clip. C-Clip The union of a CDF and its associated data BLOB(s). The CA returned to the access

application upon data storage is the address of the C-Clip. Centera Viewer (CV) Management tool used for EMC Centera configuration. CentraStar The EMC firmware used by EMC Centera.

Pool C-Clip Count Number of C-Clips stored in the pool. Pool Quota Alert Maximum capacity set by Sysop to receive alerts when the used capacity nears this

value. Alerts are sent when the used capacity reaches 80%, 90%, and 100% of this set value.

Pool Quota Hard Stop Maximum allowed value for user data in a pool before new writes are disallowed. Pool User File Count Number of user files stored in the pool.


Principles of operation

Pool setup in pre-CentraStar 3.0 versions In pre-version 3.0 EMC Centera clusters, CentraStar presents a communal pool where all data ingested into the cluster is stored. Figure 1 presents this graphically.

Introduction and Principles of Operation A Detailed Review 6

Figure 1. Pool setup for pre-CentraStar 3.0 versions

The major elements of this construction are enumerated in the following:

• Centera Pool: The communal pool where all data is stored; represents the set of data (that is, the scope) against which all cluster functions are performed.

• C-Clip: The union of a CDF and its associated data BLOB(s). The content address (CA)

returned to the access application upon data storage is the address of the C-Clip.

• Tag: Unlike HTML, where tags are actually defined in the standard itself, XML does not specify tags. It is the application’s responsibility to create its own tags (also known as elements). For EMC Centera, the tags/attributes reside in the CDF and constitute the metadata.

• Attribute: Represents the value in the name/value pair.

• Data Blob: Denotes the finite bit string that is the customer data. A single C-Clip can contain

pointers to multiple BLOBs. The content of a BLOB is opaque to CentraStar. BLOBs also have associated CAs, but they are not exposed to the applications accessing EMC Centera. This is to ensure the path to the data is always through the appropriate pointer (C-Clip).

EMC Centera Virtual Pools

Virtual pools in CentraStar 3.0 and later versions With CentraStar 3.0 the clusters can have multiple application pools that logically segregate data. Every cluster contains four pre-defined pools, called Cluster, Default, ConsoleArchive and AuditArchive1. The ConsoleArchive pool archives alert and reporting history; the AuditArchive pool stores audit trails. A single logical cluster can contain an additional 99 application (custom) pools, created by the Sysop2 , to store user data. Figure 2 presents this concept graphically.

Pool 1

CDF= Blob=

Default Pool

Pool 2

Pool 3

Pool 1

CDF=CDF= Blob=Blob=

Default Pool

Pool 2

Pool 3

Cluster Pool

Figure 2. Virtual pools for CentraStar 3.0 and later versions

The major differences are enumerated in the following:

• Cluster pool: Contains every other pool on the cluster. All the BLOBs are located in the cluster pool and the Sysop (administrator) cannot delete or in any way modify the cluster pool.

• System pools: Pre-defined pools that were introduced in CentraStar 3.1.2. They are used by EMC

Centera to store temporary (internal) data. System pools cannot be deleted.

• Default pool: An application pool that exists largely for backward compatibility for EMC Centera clusters running pre-3.0 CentraStar versions.

• Application pool: A cluster can contain up to 99 application pools. These are created by the Sysop (administrator) and are custom to each cluster.

The default and application pools displayed in Figure 2 can be thought of as a macroscopic view of the EMC Centera pool in Figure 1. That is, each of these pools contains the same elements described and illustrated earlier.

1 ConsoleArchive and AuditArchive are system pools introduced in CentraStar version 3.1.2. The Default pool, Cluster pool, ConsoleArchive pool, and AuditArchive pool are pre-defined and cannot be deleted. 2 Sysop (administrator) performs the basic configuration/admin tasks on the EMC Centera cluster. EMC Centera Virtual Pools Introduction and Principles of Operation A Detailed Review 7

Application pool attributes Common attributes for application pools are enumerated in the following:

• For CentraStar 3.0 and later versions, pools are immutable. That is, clips in application pools cannot change pool membership, and pools cannot overlap (intersect) or be included – in whole or in part – inside another pool (other than the cluster pool).

• Clips are explicit members of a pool; BLOBs are implicit members and potentially of different pools (by virtue of the pointers in the CDF). This implies that BLOB single instancing is still applicable and works across application pools.

• Clips are always a member of exactly two pools; the cluster pool and either an application or the

default pool.

• A pool is identified by its Pool ID, which is a globally unique ID (GUID) automatically calculated by CentraStar when the pool is created. Every pool has an associated Pool ID, except the Cluster and Default pools – which are pre-defined pools. Once created a Pool ID can never be changed.

• A pool cannot span multiple clusters but may exist on a replica cluster but with the same unique

Pool ID.

• Pool IDs are long and difficult to remember. Therefore, all pools also have a Display Name. The maximum size of the Display Name is 255 alphanumeric characters and cannot be named either Cluster or Default. Display Names can be changed at will as they are largely irrelevant to cluster operations (beyond the obvious requirement that Display Names must be unique to a cluster); they exist only as a convenience function to the human operator.

• Once an application pool has had data written to it, it cannot be deleted. As a best practice when

creating application pools the Sysop (administrator) should not grant the “write” or “clip-copy” privileges until it is certain that the pool is indeed desired.

• A clip cannot be moved from one pool to another. An exception to this rule is the pool migration

activity that is performed by EMC service personnel. This paper does not discuss pool migration activity. Please contact EMC service personnel for more information.

Pool/profile access privileges

Privilege hierarchy Prior to CentraStar v3.0, control of privileges was the domain of the application profile. Starting with CentraStar 3.0 the application profile has morphed into the access profile and privileges are granted by individual application pools, coupled with privilege masks. The following sections will briefly discuss how the privileges are controlled. Profiles In pre-3.0 CentraStar systems there were application profiles, which defined the properties for both authentication and authorization3. Starting with CentraStar 3.0, application profiles are replaced by access profiles (for authentication) and pool ACLs4 for authorization.


3 Authentication is defined as the process of proving identity. Authorization is the process of determining which actions an identity can perform. 4 Access Control List EMC Centera Virtual Pools

Application profiles contain:

• Name + Secret (properties used for authentication) • Capabilities (properties used for authorization)

Access profiles contain:

• Name + Secret (properties used for authentication) • Cluster level capabilities (Monitor and Profile-Driven Metadata) • Home pool (used to determine membership of clips written to the cluster using the access profile)

Authorization works on the profile performing a certain operation (for example, read, write, delete, query) and also on replication.

Profile types There are two basic types of profiles - access profiles and cluster profiles. These are summarized in the following along with anonymous profiles: Cluster profile:

• Home pool is the cluster pool. • They cannot be used to write data to EMC Centera.

Access profile:

• Each has a home pool associated with it. • These profiles are used by an application to perform data operations (write, read, delete, query,

and so on) on the EMC Centera cluster. • These can be granted read/write/delete rights provided the rights are also granted at the pool level.

Anonymous profile:

• These profiles are a special case of an access profile used for backward compatibility. • Home pool is set to the default pool but can be changed to any other application pool. • As a best practice, the use of anonymous profiles is discouraged and access profiles are

recommended.

Pool and cluster masks Pool ACLs allow fine-grain control over the capabilities a given application pool grants. Pools explicitly grant capabilities to profiles. If a certain capability is not allowed at the cluster level (referred to as cluster mask) the profiles will not be able to make use of it even if they are allowed that capability at the pool level. There are two masks in an EMC Centera cluster: Pool mask: Affects the access profile rights for a specific application pool. Pool masks are generally used to allow/deny access/data operation rights to profiles. In the case of having a large number of profiles with the same home pool, it is easier to change the access rights at the pool level then to change access rights for each access profile. Cluster mask: Affects all actions on the cluster as a whole. With the possibility of having a large number of pools on a cluster, it could become cumbersome to individually change capabilities for every single pool. This is when the concept of cluster mask comes in to picture. If any operation needs to be denied to all the pools and profiles, it can easily be achieved by changing the rights at the cluster level. The cluster mask needs to allow capabilities in order for the application pools and profiles to make use of those capabilities, as shown in Figure 3.


Cluster pool Mask

Access Profile

Access Profile/App pool ACL

Clip

Cluster Mask

Cluster Profile

Application pool Mask

Cluster Profile/Cluster pool ACL

Figure 3. Privilege hierarchy

The point suggested by the hierarchy is that once a capability is taken away at the higher level, it cannot be given back at a lower level.

Application pool membership Pool membership is determined by the clip attributes that are added by the EMC Centera SDK during writes. There are two attributes in the clip that determine pool membership. If both of these attributes are null (or, in the case of clips written with a pre-2.3 SDK, absent) then the clips will always be members of the default pool. The two attributes are modification.poolid and modification.profile. If the CDF contains a value for the modification.poolid then the clips become members of the pool specified in the modification.poolid. If the modification.poolid value is missing then the writes are vetoed and sent to the default pool.

Pool Quota Hard Stop Prior to CentraStar 4.1 the pool quota limitation was not enforced. With CentraStar 4.1 the Sysop (administrator) now has the ability to enforce pool quota restrictions and also get alerts when the available capacity for a pool reaches a certain threshold. If no value is specified for the “Pool Quota Hard Stop” a value of infinite is set by default. Note: The hard-stop policy per pool applies only to access and replication/restore types of write transactions. It is not applicable to reflection writes or pool migration tasks. Table 2 summarizes the changes made to the traditional virtual pool operations with the release of CentraStar 4.1.


Table 2. Summary of virtual pool changes in CentraStar 4.1

Functional Area(s) Changes with CentraStar 4.1

Virtual pool creation / Virtual pool update

“Pool Quota” is renamed to “Pool Quota Alert”

The following alerts will be sent if the used capacity nears this limit. Notification: 80% of Pool Quota Alert Warning: 90% of Pool Quota Alert Error: 100% of Pool Quota Alert

The command create pool <pool name> will ask for a value to be entered for “Pool Quota Hard Stop”

If a finite value is specified, no new writes will be allowed if the used capacity reaches this value.

Virtual pool detail

“Pool Quota” is renamed to “Pool Quota Alert”

“Free Pool Capacity” is renamed to “Free Pool Capacity (Alert)”

Prints an additional line for “Pool Quota Hard Stop” Updated results for the CLI command: show pool detail <pool name>

Prints an additional line for “Free Pool Capacity (Hard Stop)”

Virtual pool capacity reporting

“Quota” column is renamed to “Quota A” that is, Quota Alert.

A new column named “Quota HS” (Quota Hard Stop) is added.

The “Free” column removed

Updated results for the CLI command: show pool capacity

In CentraStar 4.1 the row named “Total” will now show the aggregated results of all entries shown in the list.

Virtual pools setup The Sysop (administrator) sets up the virtual pools on the cluster via the CLI. This paper is not intended to replace the official product documentation. We provide sample CLI commands next to provide a sense of the flow of operations involved in setting up virtual pools on EMC Centera. Wherever there is a conflict between the CLI examples in this paper and the product documentation, the official product documentation should be followed. Note: CentraStar 4.1 and Centera Viewer 4.1 were used for the following CLI command examples.

1. Create an application pool, and set the Pool Mask and Pool Quota Alert via this CLI command. With CentraStar Iris you can also specify the Pool Quota Hard Stop:

create pool <pool name>


Config# create pool finance Pool Mask [rdqeDcw-]: Pool Quota Alert [1 GB]: 2 GB Pool Quota Hard Stop [infinite]: 10 GB Issue the command? (yes, no) [no]: yes Created pool finance with ID c9b17700-1dd1-11b2-8063-d93067d1bbba-5.

Figure 4. CLI command create pool <pool name>

In the CLI example above if the virtual pool capacity reaches 2 GB (Pool Quota Alert) of the total available capacity (Pool Quota Hard Stop), alerts will be sent to the Sysop (administrator). Table 2 has more information on alerts. When the used capacity reaches the Pool Quota Hard Stop value, any new writes to that pool will be disallowed by CentraStar.

2. Check the list of pools available on the cluster by using this CLI command: show pool list

Figure 5. CLI command show pool list

3. Create an access profile, generate the profile secret, determine the profile type, and define the home pool and what rights to grant via this CLI command:

create profile <profile name>

\

Config# create profile finance_dept Enable Profile? (yes, no) [yes]: yes Set Data Access Capabilities (yes, no) [no]: yes Profile Type (access, cluster) [access]: access Home Pool [default]: finance Granted Rights for the Profile in the Home Pool [rdqeDcw-]: Profile-Metadata Capability? (yes, no) [no]: Set Cluster Management Roles (yes, no) [no]: yes Accesscontrol role? (yes, no) [no]: Audit role? (yes, no) [no]: Compliance role? (yes, no) [no]: Configuration role? (yes, no) [no]: Migration role? (yes, no) [no]: Monitor role? (yes, no) [no]: Replication role? (yes, no) [no]: Profile Secret (prompt, generate, file) [prompt]: Issue the command? (yes, no) [no]: yes Establish a Pool Entry Authorization for application use? (yes, no) [no]: yes Please enter PEA file location: C:\finance_dept.pea Config#

Config# show pool list Pool Name ID Profiles Mask ---------------------------------------------------------------------------- cluster cluster 0 rdqeDcp- default default 1 rdqeDcw- AuditArchive c9b17700-1dd1-11b2-8063-d93067d1bbba-2 0 rdqeDcw- SystemArchive c9b17700-1dd1-11b2-8063-d93067d1bbba-3 0 rdqeDcw- finance c9b17700-1dd1-11b2-8063-d93067d1bbba-5 0 rdqeDcw- ----------------------------------------------------------------------------

Figure 6. CLI command create profile <profile name>

In this example when creating the access profile, the pool created in step 1 is used as the home pool and appropriate permissions are set.


Config# show pool detail finance Centera Pool Detail Report ------------------------------------------------------ Generated on Monday, November 2, 2009 11:54:51 AM EST


Pool Name: finance Pool ID: c9b17700-1dd1-11b2-8063-d93067d1bbba-5 Pool Mask: rdqeDcw- Cluster Mask: rdqe-cw--h Pool Quota Alert: 2 GB Pool Quota Hard Stop: 10 GB Used Pool Capacity: 0 GB Free Pool Capacity (Alert): 2 GB Free Pool Capacity (Hard Stop): 10 GB Number of C-Clips: -- Number of Files: -- Number of scheduled tasks: 0 Granted Rights to Access Profiles: Profile Name Granted Effective Monitor Cap Enabled Home Pool --------------------------------------------------------------------------- finance_dept rdqeDcw- rdqe-cw- no yes yes --------------------------------------------------------------------------- Pool Mappings: none Config#

4. Verify successful creation and pool assignment for the profile by using this CLI command: show pool detail <pool name>

Figure 7. CLI command show pool detail <pool name>

5. Check the pool capacity of all pools on the cluster by using the CLI command:

show pool capacity

SystemArchive -- -- 0 GB 0 0 Total 11 GB 20 GB 1 MB 874 7 ------------------------------------------------------------------------ Config#

Config# show pool capacity Capacity / Pool Quota A Quota HS Used C-Clips Files ------------------------------------------------------------------------ AuditArchive -- -- 1 MB 866 0 test 8 GB 10 GB 0 GB 1 0 finance 2 GB 10 GB 0 GB 0 0 default -- -- 0 GB 0 0

Figure 8. CLI command show pool capacity

It can be seen from Figure 8 that the Hard Stop Pool Quota (Quota HS) on the virtual pool “finance” is set to 10 GB and the Pool Quota Alert (Quota A) is set to 2 GB. Sysop will receive alerts at 80%, 90%, and 100% usage of the Pool Quota Alert (Quota A) value (2 GB in this case) if the used capacity (Used) on this virtual pool nears this value. When the used capacity reaches the Quota HS value any new writes by the application to this pool are disallowed. The steps explained in this section allow a Sysop (administrator) to create a virtual pool, create an access profile, and assign the virtual pool as the “home pool” for the access profile. It also allows the Sysop to set a finite value for the virtual pool (Pool Quota Hard Stop) and an alert value (Pool Quota Alert).

EMC Centera Virtual Pools

Note that applications that authenticate to the cluster with the access profile created in step 3 will have all new clips written to the cluster as members of the pool created in step 1.

Frequently asked questions (FAQs) This section provides brief answers to some of the commonly asked questions. • Can a clip be moved from one pool to another on the same cluster?

Not explicitly. This is why pools in CentraStar 3.0 and later versions are called immutable. The exception, noted earlier, is that qualified clips in the default pool can be migrated to the home pool associated with the access profile indicated in the modification.profile clip attribute. Note that the migration activity can only be performed by EMC service personnel.

• Can I replicate/restore to pools on the same cluster? No. This would imply pools are mutable, which they are not in CentraStar 3.0 and later versions.

• Can a pool span multiple clusters? A pool cannot span multiple clusters, however, in case of a replicated setup, a pool with the same unique ID can exist on both source and replica EMC Centera clusters.

• Is it possible to map a pool to specific physical nodes on the cluster?

No.

• What is the maximum number of application pools allowed on a single cluster running CentraStar 3.0 and later versions? 103: 4 system pools and 99 application (custom) pools.

• Can I purge BLOBs from an access profile? No. Only the cluster profile with purge capability enabled can be used to purge BLOBs.

• Can I delete a pool once it has been written to? Yes, but the process is not easy and is not recommended. A pool that has been written to can be deleted only after following a proper procedure. That is, all the content needs to be deleted from the pool; all the reflections that result after deletion need to be retired. Once everything has been removed from the pool, only then can the pool be deleted. (Note that reflection retirement is on a cluster basis and not a per-pool basis.)

• Can I replicate/restore pools from a version 3.x or later EMC Centera to a pre-3.0 version? Only the default pool can be replicated/restored in this case since the pre-version 3 cluster will not have any concept of an application pool. This is not a recommended practice.

• Should I create an application pool even if I have only one application?

The best practice is that you should.

• Can I change the Display Name of a pool? Yes, you can at any time change the Display Name of an application pool. You can never change the name of a pre-defined pool. Further, you can never change the Pool ID of an application pool.

• Does every pool have an associated Pool ID? Every application pool does. Default and cluster system pools do not.

• Can a BLOB be Single-instance Stored (SIS) across pools on the same cluster? Yes. Note that only BLOBs are SIS; clips are not.


• Do the root and anonymous profiles still exist on clusters running CentraStar 3.0 and later

versions? The root profile does not; it has been replaced by the cluster mask. The anonymous profile continues to exist for backward compatibility. Best practice is that the anonymous profile should be disabled.

• Is it legal to create an application pool without assigning an access profile? Yes, but it will serve no purpose as the application pools are used by means of access profiles that allow applications to write data to EMC Centera.

• Can an application pool act as home pool to more than one access profile? Yes. Be advised that you will have clips from different applications stored in the same pool.

• What happens if the home pool for an imported profile doesn’t already exist? The CLI will indicate this and use the default pool.

• When are pool capabilities evaluated? Each transaction is vetted against the current pool capability setting. This implies that if the Sysop (administrator) changes the capabilities for a pool (for example, disables the write capability), access applications that already have the pool open will be immediately affected.

• Can I set a hard stop limit per VP? Yes, with CentraStar 4.1 a Sysop (administrator) is able to set a “Pool Quota Hard Stop” limit per virtual pool. This is set by using the CLI commands create pool <pool name> or update pool access <pool name>.

• When is the Pool Quota Hard Stop restriction enforced? Quota is checked at the end of write transaction, that is, during CDF write. Thus the new value of Pool Quota Hard Stop has an “immediate” effect.

• What happens if Pool Quota Hard Stop is exceeded? CentraStar 4.1 will disallow any further writes (ingest) to the pool once the “Pool Quota Hard Stop” limit is reached. Centera SDK will return an error of FP_SERVER_NO_CAPACITY_ERR (the server has no capacity to store this data) to the application.

• Is there a setting that allows Sysop to receive alerts when the used capacity nears the Pool Quota Hard Stop limit? Sysop (administrator) can set a Pool Quota Alert value for any specific virtual pool. Alerts are sent when the virtual pool used capacity reaches 80%, 90%, and 100% of the Pool Quota Alert value.

• Is Pool Quota Hard Stop set for existing pools after an upgrade to CentraStar 4.1? No. Pool Quota Hard Stop is not set for existing pools after an upgrade to CentraStar 4.1. Current pools’ settings are not affected. In order to enforce pool quota restrictions, Sysop (administrator) will need to update the existing virtual pool settings after the upgrade.

• When was virtual pool compatibility added to the SDK? SDK version 2.3.290

Conclusion This white paper provided an overview, introduction, and an update to the principles of operation of the EMC Centera virtual pools technology. It is expected that the information provided in this paper will help storage administrators to be able to understand the concept of the virtual pool and the underlying features it provides.


EMC Centera Virtual Pools Introduction and Principles of ... · EMC Centera Virtual Pools...

Documents

Transcript of EMC Centera Virtual Pools Introduction and Principles of ... · EMC Centera Virtual Pools...