http://storagetuning.wordpress.com/2011/05/25/linux-elevator-settings-impact-on-ssds/

I found this very interesting as it shows how performance testing can be so difficult to describe and/or manipulate.  Obviously this author is trying to get it right, but it shows that you have to know what you’re doing to get it right.  It also demonstrates how SSD performance can have a great impact on application performance IF YOU KNOW WHAT YOU’RE DOING.

http://calfo.wordpress.com/2011/08/22/vnxe-deduplication-and-compression/

Processor Requirements

Servers must have Intel Xeon 5600 or 7500 series of processors. No other processor vendors or models are supported.

Total physical core count required is based on the sum of UC virtual machine core requirements and the co-residency support policy).

Minimum physical core speed required is based on what UC virtual machines will be used, and at what intended load per VM. Processors of Tested Reference Configurations are sized for full-load virtual machines. It is recommended to use processors with same or higher speeds, as Cisco UC does not test or document lower performance points.

Recall that physical CPU cores may not be over-subscribed for UC VMs at this time (one physical CPU core = one vCPU core).

Cisco TAC will not troubleshoot performance problems in deployments with insufficient physical cores.

Servers

The only supported server vendors are:

Cisco Unified Computing System

HP

IBM

Cisco UCS Express, Dell and all other server vendors are not supported at this time.

All servers used must be on the VMware Hardware Compatibility List for the version of ESXi you will be running, and must meet all other policy requirements such as required CPU.

Otherwise, any server model/generation from the above vendors that satisfies all other criteria of this policy is supported for UC.

RAM

Minimum physical RAM required is 2GB for ESXi plus the sum of UC virtual machines’ vRAM.

Recall that physical memory may not be over-subscribed for UC VMs.

Aside from total physical RAM, UC does not mandate memory module size, density, speed or quantity – follow server vendor requirements for memory hardware configuration.

Cisco TAC will not troubleshoot performance problems in deployments with insufficient physical RAM.

IO Devices

All I/O controllers and adapters used must be on the VMware Hardware Compatibility List for the version of ESXi you will be running.

Only the following I/O Devices are supported:

HBA

FC – 2Gbps or faster

InfiniBand

NIC

Ethernet – 1Gbps or faster

NFS and iSCSI are supported, but require minimum 10Gbps and dedicated NIC for network storage access

Converged Network Adapter or Cisco VIC

FCoE + Ethernet – 10Gbps or faster

RAID Controllers for DAS

SAS

SAS SATA Combo

SAS-RAID

SAS/SATA-RAID

SATA

Note that diskless servers for “boot from SAN” (FC, iSCSI, or FCoE) are only supported for UC if the UC app supports both ESXi 4.1 and the “boot from SAN” feature on the VMware Requirements page.

The customer is responsible for configuring an adequate number of I/O devices to handle the aggregate load that the virtual machines running on the server will generate.

Storage access I/O requirements for UC VMs are described in the IO Operations Per Second (IOPS) page..

LAN access I/O requirements for UC VMs are described in the UC application design guides. See also network link sizing and QoS considerations here.

The customer is also responsible for configuring redundant interfaces on the server to handle component failures (e.g. redundant NIC, CNA, HBA or VIC adapters.)

There are no UC restrictions on hardware vendors for I/O Devices other than that VMware and the server vendor/model must both support them.

Cisco TAC will not troubleshoot performance problems in a deployment designed with insufficient I/O devices or overloaded I/O devices. For example, a single 100Mbps NIC servicing eight “CUCM 7500 user OVAs” would be both insufficent and overloaded.

Storage

Each OVA provided by Cisco for running a UC application has a published IOPS and disk space requirement. It is the responsibility of the customer to provide a storage system that exceeds the disk space (see Unified Communications Virtualization Downloads (including OVA/OVF Templates) and average IOPS requirements (see IO Operations Per Second (IOPS)) of the UC virtual machines they will be running on that storage system.

If you are using NFS, iSCSI, or FCoE for storage connectivity, the networking configuration must provide Cisco Platinum Class QOS (Fiber Channel Equivalent): http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/Virtualization/securecldg.html.

See also Shared Storage Considerations here.

It is not necessary to configure the storage to handle the simultaneous maximum IOPS load of every virtual machine on the storage system, but the customer must be aware of the excess capacity of the storage system and not, for example, run multiple software upgrades on the virtual machines such that the storage system is over extended.

The kernel disk command latency must not be greater than 2-3 ms and the physical device command latency must not be greater than 15-20 ms. When either of these metrics is not met, Cisco considers the storage system inadequate to serve the UC virtual machines. Cisco will not troubleshoot performance problems in an environment where either metric is not being met.

As a guideline, Cisco has found the use of 15K rpm SAS or FC drives in a RAID 5 configuration to work well. The number of drives used in the array is 5. The recommended size of the hard drives is 300 to 450GB. Recommended LUN size is 500GB to 1.5TB, so that not more than 10 virtual machines reside on a LUN – preferably 8 or less.

This is only a guideline, it is left to the customer to configure their storage for adequate performance and for the redundancy level desired.

It was only a 15 minute lightning session so there’s not much depth one can get in to in that time.  There are other ways to delivery a Windows 7 look and feel on Windows 2008 R2, but this is quite applicable for most of the folks attending BriForum.

http://www.slideshare.net/danielbrinkmann/briforum

(Denver, CO – June 20, 2011) Lewan & Associates, a Xerox company, announces the rebranding of our IT Managed Services portfolio as Cloud 9 Care, a name that reinforces our commitment to managing your technology so you can manage your business and free yourself from the headaches of IT and Print Management.

Our Cloud 9 Care IT Managed Services provide comprehensive support for your technology environment and business users. By monitoring and supporting your network, print and IT infrastructure, Lewan can help your business reduce costs and mitigate risk. We provide levels of support ranging from on-call/as-needed for specific components of your infrastructure to full management of your IT environment.

We proactively monitor and identify issues before they become problems. We also provide support for maintenance, remediation, moves/adds/changes and quarterly strategic planning sessions. Our Cloud 9 Care service offerings include:

• Intensive Care—Full service management of one or many IT functions.
• Data Protection—Cloud-based backup and recovery service.
• Messaging and Collaboration—Cloud-based email, document management and collaboration services.

Complementing our Cloud 9 Care portfolio is the reliability of the same local service and support Lewan has been providing the Rocky Mountain region for almost 40 years. Scott Pelletier, VP of Lewan’s Enterprise Technology Division, explains, “In addition to Lewan’s broad scope of technology support, we provide local customer touch. Try getting that from a national provider with no local support. Our on-premise services are as important as our remote support.” Lewan’s Cloud 9 Care IT Managed Services give you a single point of contact with one account team, one management team and one support team.

Storage is cheap, right?  Just buy some more capacity when you need it.  I can go to Best Buy and purchase a 2TB drive for about $100.  What’s the problem? …you ever heard a developer in your shop say something like this when complaining about getting more storage capacity…..

One of the things we try to help our customers with is managing the data they have a bit better versus just buying more capacity all the time.  I’m telling you storage isn’t cheap and this blog post will attempt to prove it.

Think of your data as a liquid in a glass and the glass container as your storage infrastructure.  We want to help our customers manage the liquid (their data) to keep the container to a manageable size.  The larger the container the more our customers end up spending.  Now, picture this.  You are going to have more than one container if you’re managing your data properly, so now we have multiple liquid containers to purchase and manage.  Here’s a little more background on the purpose of these containers and associated costs.

Container #1:  This is your primary data.  The data that runs the applications that run your business.  This container is built not only to store the capacity you need for your data, but it’s also built to adhere to availability and performance requirements that your applications demand.  If you don’t have access to your data or the access is slow you don’t have a business.  RTO (Recovery Time Objectives) and application response time often govern these aspects of your data access.  There are several technologies utilized to address these challenges, and guess what, they’re expensive.  Things like RAID, redundant components like controllers and power supplies, load balancing, various drive types that perform differently, connectivity protocols, application integration and the like.  I’m not going to deep dive on all those concepts in this blog, but know that they (and many others) exist and they all add cost to the storage solution.  Hardware, software, maintenance and ongoing management costs all add up. So, you remember that $100 2TB drive?  For enterprise class storage that has the resilience and performance we need, we’ll be spending more like $5,000 per useable TB versus $50 in the Best Buy example.  That’s two orders of magnitude more, wow!

Container #2:  As if Container #1 wasn’t bad enough, what about these other containers?  We also need to help protect our customer’s data over time.  We need to protect the data from accidental or malicious corruption or data loss.  high availability and resilience isn’t enough.  We need several points of time so we can go back in time in case we lose some information and we also may have the need to save information for long periods of time for compliance reasons.  This second container is where we keep information over time for functions like backup, recovery and archival.  So, not only do I need to store all my primary data in an expensive container, I need another container with several more copies to protect my data over time.  Well, I hate to break it to you, but this container isn’t any less expensive than the original container #1.  Come on now, tape is cheap isn’t it?  Just chuck this stuff on some cheap tape media and call it good, right? ….wrong…. Well, there’s a lot more to it than that.  We need to have some software to manage the data protection, recovery, archival and discovery processes.  That stuff aint cheap nor are the people, time and infrastructure to manage all that.  We now need more storage capacity for this data and the attributes of this container aren’t the same as container #1 as this data doesn’t usually have the same performance or availability requirements.  This data has requirements around storing multiple copies (or points of time) for longer periods of time.  We also need to get this information off-site if we’re really going to do this right.  Wait a minute, am I talking about yet another container?  Yes I am, container #3 is for disaster recovery purposes.  We’ll talk about that one next.  Back to container #2 for a minute.  Container #2 needs to be able to hold large amounts of capacity, preferably on disk and then make another copy on a removable medium to store it offsite or even replicate it off-site if possible.  Also, make sure we store several points of time so we can go back in time to recovery or discovery older information.  So this container consists of more capacity than the primary container on at least two types of media and/or off-site storage.  So I have to pay for the offsite storage location and shipping too, to store old tapes (and hope to god that I can recover off them if needed) and  the software, people and management to be able to recover this information.  Trust me, this container is every bit as expensive as container #1.

Container #3:  Seriously, what happened to that $50/TB disk drive?  We’re up to $10,000 per TB anyway and we haven’t even discussed container #3 in any detail.  Container #3 is for disaster recovery.  In the event we had something bad happen to our primary data and we needed to bring up our applications and data in another location, we need to protect our data over distance.  Some of this can be mitigated with container #2 as we should have a copy of our data somewhere else, but this copy isn’t in running condition.  It’s an offline copy just waiting for someone to restore somewhere so it can become online and useable to your applications and users.  Well, guess what, this container isn’t inexpensive either.  This container has to have similar features as container #1 plus all the other resources like servers, network, storage, applications, remote access (shall I continue) in order to have a place to restore the information to.  If you have this infrastructure just sitting around waiting for the disaster it can be a very expensive insurance policy.  Even if you rent this space in the event of a disaster it’s expensive to spin all this up and you better have practiced this at least a few times so you’re ready and you’ve covered all your bases with a disaster recovery plan.  So, let’s be conservative and say that the people, processes and technology for container #3 is the same as #1 and #2 let alone more data needed for things like test and development, holy mackerel. 

All this being said, we’re talking about a “managed” TB of data costing a minimum of $15,000+.  Now factor in that storage utilization of 50% is about average and so we need to double the number again to $30,000 per useable TB of capacity.  Kind of scary isn’t it.

This is why we want to help our customers manage the liquid in the glass (the data) versus focusing on just the cost of the primary container.  If we can control the data we can control container #1.  Since we know that containers #2 and #3 are proportional to the primary container we end up with a compounded savings effect. 

We are expert in our ability to analyze your data and storage infrastructure.  We have a data classification methodology that help customers shrink their data and therefore their containers and associated costs.  We also have purpose build solutions to maximize our customers investments in their data management and supporting infrastructure.  In as quickly as a day or two for smaller customers and at most a few weeks for a larger customer, we can demonstrate significant savings and a roadmap to help our customers with a data management strategy that works.  Contact me for more information: Scott Pelletier – VP Technology, Lewan & Associates, 303-968-2338.

If you didn’t get time to vote at our Tech Review please take time to vote now!

http://www.polleverywhere.com/multiple_choice_polls/MTI0Nzc3OTEwNw