Negativity..its never ending. IT tends to be breeding ground for these spores of mistrust and angst. Its OK everyone.. nothing to see here that really hasn’t been in place for eternity it seems, public or not..

Yes there is something incredibly tangible now, ok, ok. What do I speak of? Virtual Computing Environment-simply put and I mean simply put, this is a turnkey private cloud initiative, established via resources from VMwareCiscoEMC. Now from what I understand there is a certain amount of customization that will go into these solutions based on the customers needs but from the onset it looks to be a prepackaged, ready to use, referenced architecture. On top of that there is a spinning top of newness called Acadia or your one stop shop for pastoral utopias. Sales/Service/Support all funneled through this separate entity of ambiguity..hey I can’t wait to see what these cloud jockey’s produce in 2010. What are they pushing? Vblock’s baby, in three initial configurations as noted below..

• Vblock 0-due out mid year 2010, entry level goose, comprising Cisco compute and nettie, 1k, EMC Celerra and VMware vSphere. 300 to 800 VM’s supported
• Vblock 1-Mid-sized goose, comprising Cisco UCS, 1k, MDS, EMC Clariion, and VMware vSphere. 800 to 3000 VM’s supported.
• Vblock 2-High-end goose, comprising Cisco UCS, MDS, 1k, EMC V-Max and VMware vSphere. 3000 to 6000 VM’s supported.

So three companies become one. Three incredibly influential and market leading companies become one. How is that a bad thing? I don’t see vendor lock-in, I see responsible vendors. Vendors looking to accelerate cloud deployment, offering customers a simplified move to cloud or……NOT…YOUR CHOICE. Customers haven’t lost the power of excellence, they have gained the power of simplicity.

So please act responsibly, Don’t be a hater…this is good

Related articles by Zemanta

For those that are inquisitive, I get a lot of questions on the mysterious layout of the Vault Drives within the Clariion Series Arrays. The Vault drives are an area of the Clariion for software and configuration information. The space is reserved on drives 0-4 in enclosure 0 on bus 0. 62G worth of space is allocated to this private area on each Vault Drive. Consequently, on all other drives user space starts at 34MB as noted here…

One other common focus of the Vault drives is the write cache dump area. During a period of power loss to the array, the contents of the write cache get dumped to this reserved area. Therefore protecting any active writes that have yet been committed to disk.

So in a more granular sense, here is how this discreet area is partitioned…

• 
• PSM LUN or Persistent Storage Manager- 2GB trimmings, triple mirrored on the first 3 disks
• SP and FLARE Boot partition: 45GB, mirrored for each SP
• The Cache Vault area: to save contents of write cache
• The Image Repository: 5.5GB per disk, triple mirrored on disks 0, 1, and 4
• Utility Partition: 3GB, mirrored for each SP

Hope that helps..for additional info please visit the following excellent sites below. 

And btw…after reading Devang’s post and comments I finally got an answer to my post, Clariion FLARE Revision Breakdown. Specifically what the “5” signifies across all FLARE code Designations…I feel better..

[D] Stands for Software Distribution Type
0 – Debug Private
1 – Debug Frozen
2 – Retail Private
3 – Retail Frozen
4 – Early Access
5 – General Release
6 – Special

Related articles by Zemanta

    I, like you, am trying to make sense of vSphere’s new Pluggable Storage Architecture or PSA. Acronym’s galore float through that camp, so if your not careful you may find yourself in the middle of cosmic confusion. So here’s my crack at the different functions of each plug-in and specifically their interrelations. Up first…

PSA- Pluggable Storage Architecture-this is a modular framework within the VMkernel responsible for managing storage arrays and their pathing. This pathing is orchestrated via MPP’s, but before we get to that what else does the PSA provide task wise, take note..

■ Loads and unloads multipathing plug-ins, Hides virtual machine specifics from a particular plug-in, Routes I/O requests for a specific logical device to the MPP managing that device, Handles I/O queuing to the logical devices.

■ Implements logical device bandwidth sharing between virtual machines, Handles I/O queuing to the physical storage HBAs, Handles physical path discovery and removal, Provides logical device and physical path I/O statistics.

Onward fellow storage enthusiasts..

MPP-Multi-Path Plugin’s-These are, you guessed it, modules responsible for multi-path selection for a LUN (and failover). Now within this are third-party and VMware specific plug-in’s. Which brings us to…

NMP- Native Multi-Pathing Plug-in- this is a VMware specific path selection plug-in responsible for providing support for all HCL listed arrays. If the array is listed on the HCL, NMP is there to assign a path policy. But not alone, oh no, this function is delegated to SATP and PSP, sub plug-ins within NMP…

SATP- Storage Array Type Plug-in-What does it provide? Failover specifically. But as the graphic below states it also monitors path health, reports changes in those paths, and  enables inactive paths in storage failover situations.

PSP- Path Selection Plug-in-What does it provide? Load balancing specifically. I/O placement on to the available physical path’s is the name of the game here, Fixed, MRU and Round robin are the native default path selections I speak of within vSphere.

Third Party MPP-Third party MPP (failover and load balancing). Alternative to VMware’s NMP (i.e. EMC PowerPath/VE). Just as you can have multiple arrays attached to a single ESX host, you most certainly can have multi-partner plug-ins side by side. User defined claim rules can be mapped to a specific plug-in for a specific set of LUNs, array types, or  HBA’s. I know,I know, explain claim rules?

What are claim rules?- It goes with out saying that multiple MPP’s cannot manage the same storage device, so claim rules allow you to designate which MPP is assigned to which storage device. As noted here, each claim rule identifies the following parameters:

Vendor/model strings

• Transportation, such as SATA, IDE, FC, and so forth
• Adaptor, target, or LUN location
• Device driver

Claim rules are defined within /etc/vmware/esx.conf on each ESX host and can be managed via the vSphere CLI. Obviously you can change the MP policy (Fixed, MRU, RR) within the vSphere client itself but any claim change/operations need to happen from the command line.

FLOW of I/O, complements of NMP- So lets put it all together as noted here…

When a virtual machine issue an I/O request to a storage device managed my NMP, the following process takes place.

1. The NMP calls the PSP assigned to this storage device (Fixed, MRU or RR)
2. The PSP selects an appropriate physical path on which to issue an I/O
3. If the I/O operation is successful , the NMP reports its completion.
4. If the I/O operation reports an error, the NMP calls an appropriate SATP.
5. The SATP interprets the I/O command errors and , when appropriate, activates inactive paths.
6. The PSP is called to select a new path on which to issue the I/O.

Well I hope this helps, it helps me. Expect more on this topic in the future…

Well here it is, finally.What we all have been dreaming of, what the competitors have been noodling about…Site Recovery Manager 4.0.

Why so much hype, why so much talk? Two words, NFS support..now certainly there are plenty of other features and functionality that are worth mentioning (below), but if any one item could be targeted it would be this.

Why? Well I cant speak for any other NAS array other than the Celerra, but SRM and Celerra Replicator (via iSCSI) were as painful as being smacked in the face with a bag of rocks. 2.5 times (FS for iSCSI LUN) capacity of your production iSCSI LUNs were essentially needed to accomplish this replication..this alone made people angry…hey it is what it is..but it wasn’t pretty.

So where do we stand…for now NFS support has been alienated to NetApp and EMC NAS arrays..

• NS‐120, NS‐480, NS‐960, NS350, NS500, NS700, NX4, NS20, NS40, NS80, NSX
• 5.3.36 or later
• NetApp Arrays? Oh who really cares…

Note: you will have to upgrade your SRA to an SRA that supports NFS.

How good does it get? This dramatically decreases the upfront cost to integrate SRM and Celerra Replicator, while allowing full SRM failback, two features that will, together, continue to drive the proverbial stake into the hearts of Mr. Softee and Simon Crosby’s crew..

Ok what else, how about this as noted here..

• Full compatibility with vCenter 4.
• Full support for NFS-based arrays.<—Did I mention NetApp and EMC Only
• Support for shared recovery sites <—very interesting, enter Public Cloud Service Providers
  Enables many-to-one pairings of protected sites with a recovery site. For more information, see the technical note Installing, Configuring, and Using Shared Recovery Site Support, which is available at http://www.vmware.com/support/pubs/srm_pubs.html.
• Resilience in the face of vCenter unavailability during a test recovery.
  Placeholder virtual machines can be quickly repaired after the protected site vCenter becomes available again.
• New repair-mode installation features.
  You can run the SRM installer in repair mode if you need to change configuration parameters such as vCenter credentials, database connection information or credentials, and certificate details.
• Graphical interface to advanced settings.
  Eliminates most requirements to edit the XML configuration file
• Support for DB2 as an SRM database server.
• New licensing options.
• Improved scalability.
  A single protection group can now include up to 1000 virtual machines.
• Full Compatibility With DPM (Distributed Power Management)
  SRM recovery plans can now power-on or power-off a host that is in standby mode.
• New Option to dr-ip-customizer Utility
  The dr-ip-customizer utility now logs less verbose diagnostic output by default. To force dr-ip-customizer to log the same level of diagnostic output that it produced in earlier releases, use the -verbose option.
• Change in Certificate Validation
  When you select certificate authentication, the SRM installation validates the certificate you supply before continuing. Certificates signed with an MD5 key are no longer allowed.
• Support for Protecting Fault-Tolerant Virtual Machines.
  SRM can now protect virtual machines that have been configured for fault-tolerant operation. When recovered, these virtual machines lose their fault tolerance, and must be manually reconfigured after recovery to restore fault tolerance.
• Improved context-sensitive Help.
• PDF documents available on release media
  Current versions of the PDF documents for this release are available in the docs folder at the root of the SRM 4.0 CD. Updated versions of these documents may be available at http://www.vmware.com/support/pubs/srm_pubs.html.

Nice to see the boys @Uptime sparking it up again, it seems they have been busy…read up will yah?

http://blogs.vmware.com/uptime/2009/10/srm-40-get-it-now.html

http://blogs.vmware.com/uptime/2009/10/a-quick-tour-of-srm-40.html

http://blogs.vmware.com/uptime/2009/10/srm-40-is-here-the-wait-for-vsphere-and-nfs-support-is-over.html

Other useful links here…

http://www.vmware.com/download/srm/

http://www.vmware.com/products/srm/resource.html

http://www.vmware.com/support/pubs/srm_pubs.html

Here’s to a crew of hardworking, motivated and passionate individuals, not to mention dedicated vendors that want nothing but to see us succeed! 

Not bad for a team of 20!