EMC CLARIION FLARE : Fibre Logic Array Runtime Environment

The Clariion Environment is governed by FLARE Code and the Symmetrix / DMX by Enginuity Code. FLARE Code was developed internally at EMC (Data General).

FLARE: Fibre Logic Array Runtime Environment

Clariion name comes from Data General, where they designed the first 16bit minicomputer called NOVA. Later NOVA was called NOVAII. NOVAII became AVIION (letters rearranged). CLARiiON is a simple derivative of that naming convention. AVIION name still exist with AX100, AX150 and AX-4.

EMC Engineering is the crown of EMC, inventing new technology and pushing the envelope in terms of defining future products, technologies and markets. That is exactly what has happened with acquisition of Data General by EMC. They have really taken the Clariion products, rebranded them with tons of features and user interfaces to make it the flagship product. If you asked anyone at EMC about 3 to 5 years ago about their flagship product, the answer would have been Symmetrix, ask them now? Clariion has dominated the SMB and the Mid Tier Enterprise market making it the cash cow at EMC.

Unlike the Enginuity Code, the FLARE Code is customer self upgradable. This Code sits on the first 5 drives of the Clariion SPE or DAE (depending on the model), the drives that are marked with numbers (0 to 4) and do not remove stickers.

With a Code upgrade, the FLARE Operating Environment gets loaded onto the service processor and this can be performed while the machine is running. The funny part is, a Clariion service processor is merely a PC running Microsoft Windows XP 32 Bit (which might have changed with CX4 to possibly a Windows XP 64Bit Version). In short when you reboot your Clariion service processors, Windows XP will start and load the FLARE Operating Environment from the first 5 drives and bring the system online.

With these first 5 drives, do not to configure any user-host LUN Space on them. Best bet, get 5 x 73GB 15K drives and only use it for FLARE Code operation. The total space the FLARE Code occupies is 6GB per disk if its release 19 and lower and for releases 24 and above its 33GB per disk drive. Also along with the Flare Operating Environment on the first 5 drives is stored the PSM LUN (Persistent Storage Manager), Flare Database LUN and Vault Data (Save Area for write cache in case of a catastropic failure of SP). Do not move your drives around on the Clariion. Also do not insert a different drive type when replacing the first 5 drives.

From the Data General days with the Clariion, the FLARE Operating Environment is pretty open; in sense the customer can perform all sorts of changes without any restrictions (unlike the Symmetrix and DMX) where a lot of it is done through Hardware BIN file changes. Upgrades in terms of hardware, software, etc can all be performed by the customer themselves making it a neat product to work on.

As new FLARE Code releases hit market, customers can download those FLARE Code upgrades from EMC’s Customer Website (Powerlink) and self install it (I believe if you have purchased Clariion from Dell, you have to obtain FLARE Code through Dell).

The service processors run the Flare Operating Environment along with the first 5 drives. During a Non Disruptive Upgrade (NDU), the FLARE Code is loaded on one SP at a time and then reboot is performed. In short if your failover and redundancy is setup correctly you will not have any outages. It is highly recommended you perform these changes during quite times or possibly take your SQL and Oracle databases down before performing this upgrade. Also a good practice would be to get EMC Grabs out of the host that are connected to this Clariion and verify that they are new FLARE Code compatible.

If you are new to Clariion Environment, it is highly recommended you perform the pre-installation steps or read release notes before performing an upgrade or get professional assistance. It is very normal for customers to go through multiple code upgrades during the 3 to 5 year life cycle of these machines.

These Service processors also sent you service alerts through an email or sms system for proactive replacement and failing components example: failing drive, failing SP, backend issues, data sector invalidates, etc. The replacement of these parts should be carried out by an EMC trained and qualified engineer.

It is common knowledge, you can enter Engineering mode on FLARE Code using keys Ctrl + Shft + F12 and using the engineering password. The Engineering mode will allow you to perform certain functions not allowed in a normal Admin or User mode.

Initially with the FC series of Clariion, there was no web interface into the Service Processors, which has been added with the CX series of machines. With release 26 new features enhancing customers to perform a lot of maintenance work themselves has been added including performing SP Collects, etc.

FLARE Code version information is as follows.

For the sake of this blog we will limit our explanation only to CX, CX3 and CX4 platforms.

Generation 1: CX200, CX400, CX600

Generation 2: CX300, CX500, CX700 including the iSCSI flavors

Generation 3: CX3-10, CX3-20, CX3-40, CX3-80

Generation 4: CX4-120, CX4-240, CX4-480, CX4-960
(last three digits are the number of drives it can support)

The FLARE Code is broken down as follows (Please see the color coded scheme below).

1.14.600.5.022 (32 Bit)

2.16.700.5.031 (32 Bit)

2.24.700.5.031 (32 Bit)

3.26.020.5.011 (32 Bit)

4.28.480.5.010 (64 Bit)

The first digit: 1, 2, 3 and 4 indicate the Generation of the machine this code level can be installed on. For the 1^st and the 2^nd generation of machines (CX600 and CX700), you should be able to use standard 2^nd Generation code levels. CX3 code levels would have a 3 in front of it and so forth.

These numbers will always increase as new Generations of Clariion machines are added.

The next two digits are the release numbers; these release numbers are very important and really give you additional features related to the Clariion FLARE Operating Environment. When someone comes up to you and says, my Clariion CX3 is running Flare 26, this is what they mean.

These numbers will always increase, 28 being the latest FLARE Code Version.

The next 3 digits are the model number of the Clariion, like the CX600, CX700, CX3-20 and CX4-480.

These numbers can be all over the map, depending what the model number of your Clariion is.

The 5 here is unknown, its coming across from previous FLARE releases. Going back to the pre CX days (FC), this 5 was still used in there. I believe this was some sort of code internally used at Data General indicating its a FLARE release.

The last 3 digits are the Patch level of the FLARE Environment. This would be the last known compilation of the code for that FLARE version.

Again if you are looking at the CX and the FLARE Code Operating Environment it is pretty strong, powerful, lots of features a customer can use and does blow away a lot of other manufacturers in the same market space.

Hope this information was useful in your endeavor while searching for Clariion Flare Code Operating Environment information.

Powerpath Host Agent Software Utility

powercf

During installation on Solaris hosts, the powercf utility configures PowerPath devices by scanning the host adapter buses for both single-ported and multiported Symmetrix volumes. (A multiported volume shows up on two or more host bus adapters with the same Symmetrix subsystem/device identity. The identity comes from the serial number for the volume.) For each Symmetrix volume found in the scan of the host adapter buses, powercf creates a corresponding emcpower device entry in the emcp.conf file, and saves a primary path and an alternate primary path to that device. The powermt config command, run at boot time by init (1M), adds additional paths to the Symmetrix volume.

After PowerPath is installed, you only need to run the powercf command when the physical configuration of the Symmetrix or the host changes. The configuration changes that require you to reconfigure PowerPath devices include:
• Adding or removing host bus adapters
• Adding, removing, or changing Symmetrix logical devices
• Changing the cabling routes between host bus adapters and Symmetrix ports
• Adding or removing Symmetrix channel directors

powercf -i|p|q

Arguments

-i
Scans the host adapter buses for single-ported and multiported Symmetrix volumes. Compares those volumes with the PowerPath device entries in the emcp.conf file. Prompts you to accept or reject any addition or deletion of Symmetrix devices in the emcp.conf file.

-p
Scans the host adapter buses for single-ported and multiported Symmetrix volumes. Compares those devices with the emcpower entries in the emcp.conf file. Prints information on any inconsistencies.

-q
Scans the host adapter buses for single-ported and multiported Symmetrix volumes. Compares those volumes with the PowerPath device entries in the emcp.conf file. Updates the emcp.conf file by removing PowerPath devices that were not found in the host adapter scan and by adding new PowerPath devices that were found. Saves a primary and an alternate primary path to each PowerPath device.

The powermt Commands

This section describes each powermt command. Refer to the preface of this document for information on the conventions used in the command syntax. You can run powermt commands from either the command line.

Powermt

Displays the syntax for the commands in the powermt management utility.

Syntax
powermt
powermt check
Verifies that all paths are connected to the correct Symmetrix volumes.

Syntax
powermt check [dev=power#|all] [adapter=adapter#|all]

The dev parameter and the adapter parameter are optional. You must, however, specify at least one in the powermt check command.

powermt check_registration

Provides PowerPath license registration information. The powermt check_registration command is available from the command line only. It does not have an equivalent SMIT command.

Syntax
powermt check_registration

powermt config
Configures paths to all known Symmetrix logical devices for maximum accessibility.

Syntax
powermt config

powermt display
Displays a table that shows the state of all host adapters found by PowerPath.

Syntax
powermt display

powermt display dev
Displays a table that shows the state of the specified PowerPath device or all PowerPath devices.

Syntax
powermt display dev=power#|all

powermt restore
Attempts to reopen, or restore to service, all device paths currently marked as Closed.

Syntax
powermt restore

powermt save
Saves changes to the PowerPath devices’ policy and priority attributes to the ODM so that the new values are in effect at system startup.

Syntax
powermt save

powermt set adapter_switch
Enables or disables the specified host adapter.

Syntax
powermt set adapter_switch=disabled|enabled adapter=adapter#

Parameters

disabled
Does not allow the specified host adapter to accept I/O traffic for any device path it serves.

enabled
Allows the specified host adapter to accept I/O traffic for any device path it serves.

adapter#
The host adapter number shown in the ## column in the table displayed when you enter the powermt display dev command.
powermt set mode
Sets device path(s) to either active or standby mode for the specified PowerPath device or for all PowerPath devices on the specified adapter.
Syntax
powermt set mode=active|standby adapter=adapter# [dev=power#|all]
The dev parameter is optional. If you do not include the dev parameter, the powermt set mode command changes the mode of all PowerPath devices on the specified adapter.
powermt set policy
Sets the load balancing policy for the specified PowerPath device or all PowerPath devices.
Syntax
powermt set policy=rr|io|lb|so [dev=power#|all]
The dev parameter is optional. If you do not include the dev parameter, the powermt set policy command changes the policy of all PowerPath devices.
Parameters

Rr Round-robin. Future I/O requests are assigned to each of the available paths in rotation.
Io I/O. Load balance is based on the number of pending I/Os.
Lb Least blocks. Load balance is based on the number of blocks in the pending I/Os.
powermt set priority
Sets the I/O priority for the specified PowerPath device or for all PowerPath devices.
Syntax
powermt set priority= [dev=power#|all]
The dev parameter is optional. If you do not include the dev parameter, the powermt set priority command changes the priority of all PowerPath devices.
The powermt set priority command is only meaningful when the load-balancing policy is Symmetrix optimized (so). This setting allows the I/O performance of a few, individual PowerPath devices to be improved at the expense of the rest of the devices, while otherwise maintaining the best possible load balance across all paths.
powermt validate
Verifies that the primary path opened for each PowerPath device is connected to the correct Symmetrix volume.
Syntax
powermt validate
powermt watch
Displays a table that shows the state of the host adapters for the specified PowerPath device or all PowerPath devices.
Syntax
powermt watch every=#seconds
powermt watch dev
Displays a table that shows the state of the specified PowerPath device or all PowerPath devices.
Syntax
powermt watch dev=power#|all every=#seconds

EMC Symmetrix Specifications Sheet for different models

DMX800 Specifications sheet

DMX1000 Specifications sheet

DMX2000 Specifications sheet

DMX3000 Specifications sheet

DMX 3 Specification sheet

DMX-3 950 Specifications sheet

DMX-4 Specifications sheet

DMX-4 950 Specifications sheet

Clariion : Disk format

Disk Format

The Clariion Formats the disks in Blocks. Each Block written out to the disk is 520 bytes in size. Of the 520 bytes, 512 bytes is used to store the actual DATA written to the block. The remaining 8 bytes per block is used by the Clariion to store System Information, such as a Timestamp, Parity Information, Checksum Data.

Element Size – The Element Size of a disk is determined when a LUN is bound to the RAID Group. In previous versions of Navisphere, a user could configure the Element Size from 4 blocks per disk 256 blocks per disk. Now, the default Element Size in Navisphere is 128. This means that the Clariion will write 128 blocks of data to one physical disk in the RAID Group before moving to the next disk in the RAID Group and write another 128 blocks to that disk, so on and so on.

Chunk Size – The Chunk Size is the amount of Data the Clariion writes to a physical disk at a time. The Chunk Size is calculated by multiplying the Element Size by the amount of Data per block written by the Clariion.

128 blocks x 512 bytes of Data per block = 65,536 bytes of Data per Disk. That is equal to 64 KB. So, the Chunk Size, the amount of Data the Clariion writes to a single disk, before writing to the next disk in the RAID Group is 64 KB.

Clariion Cache : Read and Write Caching

Clariion Read Caching

The Diagram on the left explains Read Caching (Only One SP involved in this process)

Step A: The host is requesting data from the active path to the Clariion.

Step B: If the data is in Cache, the data is sent over to the host.

Step Aa: This step comes into picture if the requested data is not in cache and is now requested from the Disk.

Step Ab: The Disk reads the data in the cache and Step B is performed completing the request.

Clariion Write Caching

The Diagram on the right explains Write Caching (Both the SP’s are involved in this process)

Step A: The host writes data to the disk (lun) through the active path between Host and Clariion. The data is written in cache.

Step B: The Data from above is in Cache (example SPA) is now copied over to the Cache of SPB using the Clariion Messaging Interface (CMI)

Step C: At this point an acknowledgement is sent to the host that the Write is now complete.

Step D: Using the Cache flushing techniques the data is written to the Clariion Disk (lun)

EMC Symmetrix DMX-4 and Symmetrix V-Max: Basic Differences

EMC Symmetrix DMX-4 and Symmetrix V-Max: Basic Differences

In this post we will cover some important aspects / properties / characteristics / differences between the EMC Symmetrix DMX-4 and EMC Symmetrix V-Max. It seems like a lot of users are searching on blog posts about this information.

From a high level, I have tried to cover the differences in terms of performance and architecture related to the directors, engines, cache, drives, etc

It might be a good idea to also run both the DMX-4 and V-max systems through IOmeter to collect some basic comparisons between the front end and coordinated backend / cache performance data.

Anyways enjoy this post, and possibly look for some more related data in the future post.

EMC Symmetrix DMX-4 EMC Symmetrix V-Max

Called EMC Symmetrix DMX-4		Called EMC Symmetrix V-Max
DMX: Direct Matrix Architecture		V-Max: Virtual Matrix Architecture
Max Capacity: 1 PB Raw Storage		Max Capacity: 2 PB of Usable Storage
Max Drives: 1900. On RPQ: 2400 max		Max Drives: 2400
EFD’s Supported		EFD’s Supported
Symmetrix Management Console 6.0		Symmetrix Management Console 7.0
Solutions Enabler 6.0		Solutions Enabler 7.0
EFD: 73GB, 146GB, 200GB, 400GB		EFD: 200GB, 400GB
FC Drives: 73GB, 146GB, 300GB, 400GB, 450GB		FC Drives: 73GB, 146GB, 300GB, 400GB
SATA II: 500GB, 1000 GB		SATA II: 1000 GB
FC Drive Speed: 10K or 15K		FC Drive Speed: 15K
SATA II Drive Speed: 7.2K		SATA II Drive Speed: 7.2K
Predecessor of DMX-4 is DMX-3		Predecessor of V-Max is DMX-4
DMX-4 management has got a bit easy compared to the previous generation Symmetrix		Ease of Use with Management – atleast with SMC 7.0 or so called ECC lite
4 Ports per Director		8 Ports per Director
No Engine based concept		Engine based concept
24 slots		The concept of slots is gone
1 System bay, 9 Storage bays		1 System bay, 10 Storage bays
No engines		8 Engines in one System (serial number)
64 Fiber Channel total ports on all directors for host connectivity		128 Fiber Channel total ports on directors/engines for host connectivity
32 FICON ports for host connectivity		64 FICON ports for host connectivity
32 GbE iSCSI ports		64 GbE iSCSCI ports
Total Cache: 512GB with 256 GB usable (mirrored)		Total Cache: 1024 GB with 512 GB usable (mirrored)
Drive interface speed either 2GB or 4GB, drives auto negotiate speed		Drive interface speed 4GB
Green color drive LED means 2GB loop speed, Blue color drive LED means 4GB loop speed		Only 4GB drive speed supported.
512 byte style drive (format)		520-byte style drive (8 bytes used for storing data check info). Remember the clarion drive styles, well the data stored in both the cases is different. The 8 bytes used with the Symmetrix V-Max are the data integrity field based on the algorithm D10-TIF standard proposal
FAST: Fully Automated Storage Tiering may not be supported on DMX-4’s (most likely since the support might come based on a microcode level rather than a hardware level)		FAST: Fully Automated Storage Tiering will be supported later this year on the V-Max systems
Microcode: 5772 / 5773 runs DMX-4’s		Microcode: 5874 runs V-Max
Released in July 2007		Released in April 2009
Concepts of Directors and Cache on separate physical slots / cards		Concept of condensed Director and Cache on board
DMX-4 Timefinder performance has been better compared to previous generation		300% better TImefinder Performance compared to DMX-4
No IP Management interface into the Service Processor		IP Management interface to the Service Processor, can be managed through the customer’s Network – IP infrastructure
Symmetrix Management Console is not charged for until (free) DMX-4		Symmetrix Management Console to be licensed at a cost starting the V-Max systems
Architecture of DMX-4 has been similar to the architecture of its predecessor DMX-3		Architecture of V-Max is completely redesigned with this generation and is completely different from the predecessor DMX-4
Microcode 5772 and 5773 has be build on previous generation of microcode 5771 and 5772 respectively		Microcode 5874 has been build on base 5773 from previous generation DMX-4
No RVA: Raid Virtual Architecture		Implementation of RVA: Raid Virtual Architecture
Largest supported volume is 64GB per LUN		Large Volume Support: 240GB per LUN (Open Systems) and 223GB per LUN (Mainframe Systems)
128 hypers per Drive (luns per drive)		512 hypers per Drive (luns per drive)
Configuration change not as robust as V-Max Systems		V-Max systems introduced the concept of concurrent configuration change allowing customers to perform change management on the V-Max systems combined to work through single set of scripts rather than a step based process.
DMX-4 does present some challenges with mirror positions		Reduced mirror positions giving customers good flexibility for migration and other opportunities
No Virtual Provisioning with RAID 5 and RAID 6 devices		Virtual Provisioning allowed now with RAID 5 and RAID 6 devices
No Autoprovisioning groups		Concept of Autoprovisioning groups introduced with V-Max Systems
Minimum size DMX-4: A single storage cabinet system, supporting 240 drives can be purchased with a system cabinet		Minimum size V-Max SE (single engine) system can be purchased with 1 engine and 360 drive max.
No concepts of Engine, architecture based on slots		Each Engine consists of 4 Quad Core Intel Chips with either 32GB, 64GB or 128GB cache on each engine with 16 front-end ports with each engine. Backend ports per engine is 4 ports connecting System bay to storage bay
Power PC chips used on directors		Intel Quad Core chips used on Engines
Powerpath VE support for Vsphere – Virtual machines for DMX-4		Powerpath VE supported for Vsphere – Virtual machines for V-Max
Concept of Backplane exists with this generation of storage		V-Max fits in the category of Modular Storage and eliminates the bottle neck of a backplane
DMX-4 was truly sold as a generation upgrade to DMX-3		V-Max systems have been sold with a big marketing buzz around hundreds of engines, millions of IOPs, TB’s of cache, Virtual Storage
Systems cannot be federated		The concept of Federation has been introduced with V-Max systems, but systems are not federated in production or customer environments yet
Directors are connected to the system through a legacy backplane (DMX – Direct Matrix Architecture).		Engines are connected through copper RAPID IO interconnect at 2.5GB speed
No support for FCOE or 10GB Ethernet		No support for FCOE or 10GB Ethernet
No support for 8GB loop interface speeds		No support for 8GB loop interface speeds
Strong Marketing with DMX-4 and good success		Virtual Marketing for Virtual Matrix (V-Max) since the product was introduced with FAST as a sales strategy with FAST not available for at least until the later part of the year.
No support for InfiniBand expected with DMX-4		Would InfiniBand be supported in the future to connect engines at a short or long distance (several meters)
No Federation		With Federation expected in the upcoming versions of V-Max, how would the cache latency play a role if you had federation between systems that are 10 to 10 meters away?
Global Cache on Global Memory Directors		Global Cache on local engines chips: again as cache is shared between multiple engines, cache latency is expected as multiple engines request this IO
DMX-4 is a monster storage system		The V-Max building blocks (engines) can create a much larger storage monster
256GB total vault on DMX-4 systems		200GB of vault space per Engine, with 8 engines, we are looking at 1.6TB of vault storage
Performance on DMX-4 has been great compared to its previous generation DMX, DMX2, DMX-3		IOPS per PORT of V-Max Systems 128 MB/s Hits 385 Read 385 Write IOPS for 2 PORT of V-Max Systems 128MB/s Hits 635 Read 640 Write
V-Max performs better compared to DMX-4 FICON		2.2 x Performance on FICON compared to DMX-4 Systems. 2 Ports can have as many as 17000 IOPS on FICON
Large Metadata overhead with the amount of volumes, devices, cache slots, etc, etc		A reduction of 50 to 75% overhead with the V-Max related to metadata
SRDF Technology Supported		New SRDF/EDP (extended distant protection) Diskless R21 passthrough device, no disk required for this passthrough
Symmetrix Management Console 6.0 supported, no templates and wizards		Templates and Wizards within the new SMC 7.0 console
Total SRDF Groups supported 128		Total SRDF Groups supported 250
16 Groups on Single Port for SRDF		64 Groups on Single Port for SRDF
V-Max comparison on Connectivity		2X Connectivity compared to the DMX-4
V-Max comparison on Usability (Storage)		3X usability compared to the DMX-4
DMX-4 was the first version of Symmetrix where RAID6 support was rolled out		RAID 6 is 3.6 times better than the DMX-4
RAID6 support on DMX-4 is and was a little premature		RAID 6 on V-Max (performance) is equivalent to RAID 1 on DMX-4
SATA II performance on DMX-4 is better than V-Max		SATA II drives do not support the 520-byte style. EMC takes those 8 bytes (520 – 512) of calculation for data integrity T10-DIF standard proposal and writes it in blocks or chunks of 64K through out the entire drive causing performance degradation.
SATA II performance on DMX-4 is better than V-Max		The performance of SATA II drives on V-Max is bad the DMX-4 systems
Fiber Channel performance better compared to DMX and DMX-2’s.		Fiber Channel performance compared to DMX-4 improved by about 36%
DMX-4 start supporting 4GB interface host connectivity		Fiber Channel performance 5000 IOPS per channel
RVA not available on DMX-4 platforms		RVA: Raid Virtual Architecture allows to have one mirror position for RAID volumes allowing customers to used the rest of the 3 positions for either BCV’s, SRDF, Migration, etc, etc.
No MIBE and SIB with DMX-4. Rather the DMX-4 directors are connected through a common backplane.		MIBE: Matrix Interface Board Enclosure connects the Odd and the Evens or (Fabric A and Fabric B) Directors together. The SIB (System Interface Board) connects these engines together using Rapid IO
Director count goes from Director 1 on the left to Director 18 (Hex) on the right		Director count goes from 1 on the bottom to 16 (F) on the top, based on each engine having 2 directors. 8 Engines, 16 Directors.
2 Directors failures if not in the same fabric or bus, rather are not DI’s (Dual Initiators) of each other will not cause a system outage or data loss / data unavailable		Single engine failure (2 Directors) will not cause Data Loss / Data Unavailable and the system will not cause an outage. Failed components can be Directors, Engines, MIBE, PS’s, Fan, Cache in a single Engine or 2 directors.
Single loop outages will not cause DU		Single loop outages will not cause DU

More architectural details related to drives, cache, directors, cabinets, Mibe, SIB, Service Processor to come in the V-Max architecture expansion and modularity post over the next week.

Enjoy!!!!

Clariion Cache : Page Size

There are 4 different Cache page size settings available in a Clariion; the default size is 8kb with other available options at 2kb, 4kb and 16kb.

Based on your applications you should customize your Cache page size. Applications like Exchange data blocks consume 4kb page size, SQL uses 8kb and Oracle uses 16kb.

Let’s say you are running Exchange and SQL on your Clariion. Your defined cache page size is 4kb in the Clariion. Each Exchange data block will occupy 4kb cache page size and the application along with cache will work excellent. Now assume SQL is running on the same machine which has a data block size of 8kb, so every SQL block will be broken down into 2 separate pages in cache at 4kb each. Now imagine running Oracle on it which has a data block size of 16kb, here each data block will be broken into 4 cache pages, at this point your applications will start having backend performance issues.

In this scenario Exchange will work perfect, SQL with a little performance impact and Oracle heavy impacted with 4 cache pages per data block.

Now let’s imagine a scenario where you are using 16kb page size for Oracle as the primary application for that machine. Time goes by and the machine is upgraded with disk etc and used for SQL and Exchange along with Oracle. Your page size is 16kb, Oracle applications run fine. SQL starts putting its block of data in cache at 8kb, but your size is 16kb, wasting 8kb per block of SQL data that comes in. Similarly with Exchange you have 4kb block size, and you are wasting 12kb per block of data in the cache. In these scenarios you will fill up your cache much faster not with data, but with wasted open space rather called holes.

Best recommendation would be to have separate machines (Clariion) based on the applications you run on them. If you are running SQL and Exchange primarily, it might be a good idea to run it at 8kb Cache size on one Clariion. For Oracle possibly run another machine at 16kb Cache size. If you try to slam all of them together, either the applications will have issues or the cache will have issues or worst you will see performance issues throughout your Clariion.

EMC Clariion RAID-6 requirements and limitations

Here are some requirements and limitations related to using the RAID-6 technology on the EMC Clariion platforms.

• RAID-6 is only supported with Flare Release 26 and above on Clariion systems.
• Flare 26 only works on the EMC Clariion CX300, CX500, CX700, all CX3-xx platforms and all CX4-xxx platforms.|
• Any systems running below Flare Release 26 (example Release 13, 16, 19, 24) are not compatible to run RAID-6 (Clariion Systems like CX200, CX400 and CX600).

• Minimum disk required to support RAID-6 with Clariion systems is 2 or 4 or 6 or 8 or 14 data disks with 2 Parity disks (Your typical configuration would look like 2D+2P or 4D+2P or 6D+2P or 8D+2P or 14D+2P, where D = Data Disk and P = Parity Disk)
• To configure RAID-6, you will need even number of disk drives in the RAID Group that you are trying to configure.
• RAID-6 is supported on either EFD (Enterprise Flask Disk) or Fiber (FC) or ATA or SATA drives on EMC Clariion Systems.
• RAID-6 Raid group (RAID SET) can be implemented within an enclosure or expanded beyond a single enclosure
• RAID-6 can co-exist in the same DAE (disk array enclosure) as a RAID-5 and/or RAID-1/0 and/or other RAID types.
• RAID-6 supports global hot sparing like other RAID technologies.
• Supports MetaLUN expansion through concatenated or striped expansion only if all the meta member LUNs are RAID-6 devices (LUNs).
• RAID-6 configuration is possible through Navisphere and naviseccli only.
• With RAID-6 traditionally supported CLI interfaces like Java CLI and Classic CLI have been retired.
• Defragmentation with RAID-6 is currently not supported on Flare Release 26.
• You cannot add new drives to an existing RAID-6 LUN, but you can expand the LUN through RAID-6 MetaLUN technology. Example of this will be, if you have a 6D+2P RAID-6 set and would like to add 16 more drives to the same RAID Group, you cannot accomplish it, but if you manage to create either 2 sets of 6D+2P or 1 set of 14D+2P, and then run a MetaLUN concatenate, you will be able to necessarily achieve the same end result.
• You can have Clariion systems with various different RAID group technologies in the same global domain, but again from a management perspective certain traditional CLI interfaces will not work with RAID-6.
• Using the Virtual LUN Technology with Flare Release 26, now customers can migrate various LUNs (RAID-5, RAID-1/0) to RAID-6 technology. The technology allows the new RAID-6 LUN to assume the exact identity of the previous LUN making the migration process much easy.
• Traditional replication and copy software’s like SANCopy, SnapView, MirrorView, and RecoverPoint are all supported for RAID-6 technology.
• Never use RAID-6 technology with a mix of EFD, FC, ATA and SATA drives in the same RAID Group.
• Never use RAID-6 technology with a mix of various drive speeds like 15K or 10K or 7.2K RPM, drive speed should be exactly similar.

• Oh the most important note: 2 drive failures in the same RAID Group and no data loss or data unavailable (DU / DL), making this a very robust RAID technology. There are some performance overhead related to use of RAID-6 systems with small and random writes. While there is an added penalty with Row Parity and Diagonal Parity calculations on the Clariion.

If you would like to see any further post on RAID-6 workings on Clariion Platforms, please feel free to leave a comment.

To read about other RAID-6 implementations with various platforms, please see below.

FLARE in Clariion ( Fibre Logic Array Runtime Environment )

Clariion name comes from Data General, where they designed the first 16bit minicomputer called NOVA. Later NOVA was called NOVAII. NOVAII became AVIION (letters rearranged). CLARiiON is a simple derivative of that naming convention. AVIION name still exist with AX100, AX150 and AX-4.

EMC Engineering is the crown of EMC, inventing new technology and pushing the envelope in terms of defining future products, technologies and markets. That is exactly what has happened with acquisition of Data General by EMC. They have really taken the Clariion products, rebranded them with tons of features and user interfaces to make it the flagship product. If you asked anyone at EMC about 3 to 5 years ago about their flagship product, the answer would have been Symmetrix, ask them now? Clariion has dominated the SMB and the Mid Tier Enterprise market making it the cash cow at EMC.

Unlike the Enginuity Code, the FLARE Code is customer self upgradable. This Code sits on the first 5 drives of the Clariion SPE or DAE (depending on the model), the drives that are marked with numbers (0 to 4) and do not remove stickers.

With a Code upgrade, the FLARE Operating Environment gets loaded onto the service processor and this can be performed while the machine is running. The funny part is, a Clariion service processor is merely a PC running Microsoft Windows XP 32 Bit (which might have changed with CX4 to possibly a Windows XP 64Bit Version). In short when you reboot your Clariion service processors, Windows XP will start and load the FLARE Operating Environment from the first 5 drives and bring the system online.

With these first 5 drives, do not to configure any user-host LUN Space on them. Best bet, get 5 x 73GB 15K drives and only use it for FLARE Code operation. The total space the FLARE Code occupies is 6GB per disk if its release 19 and lower and for releases 24 and above its 33GB per disk drive. Also along with the Flare Operating Environment on the first 5 drives is stored the PSM LUN (Persistent Storage Manager), Flare Database LUN and Vault Data (Save Area for write cache in case of a catastropic failure of SP). Do not move your drives around on the Clariion. Also do not insert a different drive type when replacing the first 5 drives.

From the Data General days with the Clariion, the FLARE Operating Environment is pretty open; in sense the customer can perform all sorts of changes without any restrictions (unlike the Symmetrix and DMX) where a lot of it is done through Hardware BIN file changes. Upgrades in terms of hardware, software, etc can all be performed by the customer themselves making it a neat product to work on.

As new FLARE Code releases hit market, customers can download those FLARE Code upgrades from EMC’s Customer Website (Powerlink) and self install it (I believe if you have purchased Clariion from Dell, you have to obtain FLARE Code through Dell).

The service processors run the Flare Operating Environment along with the first 5 drives. During a Non Disruptive Upgrade (NDU), the FLARE Code is loaded on one SP at a time and then reboot is performed. In short if your failover and redundancy is setup correctly you will not have any outages. It is highly recommended you perform these changes during quite times or possibly take your SQL and Oracle databases down before performing this upgrade. Also a good practice would be to get EMC Grabs out of the host that are connected to this Clariion and verify that they are new FLARE Code compatible.

If you are new to Clariion Environment, it is highly recommended you perform the pre-installation steps or read release notes before performing an upgrade or get professional assistance. It is very normal for customers to go through multiple code upgrades during the 3 to 5 year life cycle of these machines.

These Service processors also sent you service alerts through an email or sms system for proactive replacement and failing components example: failing drive, failing SP, backend issues, data sector invalidates, etc. The replacement of these parts should be carried out by an EMC trained and qualified engineer.

It is common knowledge, you can enter Engineering mode on FLARE Code using keys Ctrl + Shft + F12 and using the engineering password. The Engineering mode will allow you to perform certain functions not allowed in a normal Admin or User mode.

Initially with the FC series of Clariion, there was no web interface into the Service Processors, which has been added with the CX series of machines. With release 26 new features enhancing customers to perform a lot of maintenance work themselves has been added including performing SP Collects, etc.

FLARE Code version information is as follows.

For the sake of this blog we will limit our explanation only to CX, CX3 and CX4 platforms.

Generation 1: CX200, CX400, CX600

Generation 2: CX300, CX500, CX700 including the iSCSI flavors

Generation 3: CX3-10, CX3-20, CX3-40, CX3-80

Generation 4: CX4-120, CX4-240, CX4-480, CX4-960
(last three digits are the number of drives it can support)

The FLARE Code is broken down as follows (Please see the color coded scheme below).

1.14.600.5.022 (32 Bit)

2.16.700.5.031 (32 Bit)

2.24.700.5.031 (32 Bit)

3.26.020.5.011 (32 Bit)

4.28.480.5.010 (64 Bit)

The first digit: 1, 2, 3 and 4 indicate the Generation of the machine this code level can be installed on. For the 1^st and the 2^nd generation of machines (CX600 and CX700), you should be able to use standard 2^nd Generation code levels. CX3 code levels would have a 3 in front of it and so forth.

These numbers will always increase as new Generations of Clariion machines are added.

The next two digits are the release numbers; these release numbers are very important and really give you additional features related to the Clariion FLARE Operating Environment. When someone comes up to you and says, my Clariion CX3 is running Flare 26, this is what they mean.

These numbers will always increase, 28 being the latest FLARE Code Version.

The next 3 digits are the model number of the Clariion, like the CX600, CX700, CX3-20 and CX4-480.

These numbers can be all over the map, depending what the model number of your Clariion is.

The 5 here is unknown, its coming across from previous FLARE releases. Going back to the pre CX days (FC), this 5 was still used in there. I believe this was some sort of code internally used at Data General indicating its a FLARE release.

The last 3 digits are the Patch level of the FLARE Environment. This would be the last known compilation of the code for that FLARE version.

Again if you are looking at the CX and the FLARE Code Operating Environment it is pretty strong, powerful, lots of features a customer can use and does blow away a lot of other manufacturers in the same market space.

Hope this information was useful in your endeavor while searching for Clariion Flare Code Operating Environment information.

EMC SRDF Basics

Conceptually and operationally, SRDF is designed to work in a WAN/Internet/Cloud/SAN environment with multiple Symms involved, while Timefinder is local to a Symm, but performs the same functions.

The difference, SRDF can be performed without Geographic boundaries, while Timefinder is local. The following are various different forms of SRDF that can be used by a customer to perform SRDF operations.

Synchronous mode

With Synchronous mode, the remote symm must have I/O in cache before the application receives the acknowledgement. Depending on distance where these Symmetrix machines are located, this may have a significant impact on performance. This form of SRDF is suggested to be implemented in a campus environment.

If you want to ensure that the data is replicated real time without dirty tracks from one symmetrix to the other, you might want to enable Domino effect. With Domino effect, your R1 devices will become not ready if the R2 devices cant be reached.

Semi-synchronous mode

With Semi-synchronous mode, the I/O between the R1 and R2 devices are always out of sync. The application receives the acknowledgement from the first write I/O to the local cache. The second I/O isn’t acknowledged until the first is in the remote cache. This form of SRDF is faster than the previous mentioned Synchronous mode.

Adaptive Copy-Write Pending

With Adaptive Copy-Write Pending, all the R2 volumes are copied over without the delay of acknowledgement from the application. With this mode, we can setup a skew parameter that will allow max number of dirty tracks. Once that number is reached, the system switches to a preconfigured mode like the semi-synchronous mode until the remote data is all synced. Once this is hit, SRDF is switched back to Adaptive Copy-Write Pending mode.

Clariion SPCollects for CX, CX3, CX4

The following is the procedure for SPCollects on a Clariion, CX, CX3 and CX4 machines.

If you are running release 13 and above, you will be able to perform the SP Collects from the GUI of Navisphere Manager Software.

Using Navisphere perform the following steps to collect and transfer the SPCollects to your local drive.

1. Login to Navisphere Manager
2. Identify the Serial number of the array you want to perform the SP Collects on
3. Go to SP A using expand (+)
4. Right click on it and from the menu, select SPCollects
5. Now go to SP B in the same array
6. Right click on it and from the menu, select SPCollects
7. Wait for 5 to 10 minutes depending on the how big your array is and how busy your array is
8. Now right click on SP A and from the menu select File Manager
9. From the window, select the zip file SerialNumberOfClariion_spa_Date_Time_*.zip
10. From the window, hit the transfer button to transfer the files to your local computer.
11. Follow a similar process ( 8, 9, 10) for SPB, from the File Manager
12. The SP B file name will be SerialNumberOfClariion_spb_Date_Time_*.zip

For customers that do not have SPCollects in the menu (running release 13 below), there is a manual way to perform SPCollects using Navicli from your management console or an attached host system.

To gather SPCollects from SP A, run the following commands

navicli –h xxx.xxx.xxx.xxx spcollect –messner

Wait for 5 to 7 mins

navicli –h xxx.xxx.xxx.xxx managefiles –list

The name of the SPCollects file will be SerialNumberOfClariion_spa_Date_Time_*.zip

navicli –h xxx.xxx.xxx.xxx managefiles –retrieve

where xxx.xxx.xxx.xxx is the IP Address of SP A

For SP B, similar process like above, the name of the file you will be looking for is SerialNumberOfClariion_spb_Date_Time_*.zip

Where xxx.xxx.xxx.xxx will be the IP Address of SP B

SPCollects information is very important with troubleshooting the disk array and will give the support engineer all the necessary vital data about the storage array (environment) for troubleshooting.

The following data that is collected using the SP Collects from both the SP’s:

Ktdump Log files

iSCSI data

FBI data (used to troubleshoot backend issues)

Array data (sp log files, migration info, flare code, sniffer, memory, host side data, flare debug data, metalun data, prom data, drive meta data, etc)

PSM data

RTP data (mirrors, snaps, clones, sancopy, etc)

Event data (windows security, application and system event files)

LCC data

Nav data (Navisphere related data)

To read previous blog post on Clariion Technology, please see the following links