Many companies are turning alternative solutions, such as IT equipment rentals, as a cost-effective means of solving a variety of short-term IT equipment needs. Whether it be looking for a solution for Disaster Recovery (DR), IT capacity needs or performing a Proof of Concept, renting IT equipment can provide another option for short-term projects while still maintaining financial flexibility and preserving capital.

Download our Rapid Rental Program brochure to learn more.

delicious  |   facebook  |   digg it  |   twitter  |   stumbleupon  |   ping this!

Comments (0)
Stacy Mancinelli December 17 2009 01:32:09 PM

If recent studies are correct, companies are spending $.70 of every dollar maintaining their current IT environment versus adding new capabilities.  Beating up vendors over the initial price for hardware, software and services is not nearly as important as what happens after the sale. So many companies lose sight of this and focus only on the initial cost of a solution or project.  

Performance tuning and assessments of existing infrastructure can offer significant, and more importantly, ongoing savings.  Champion Solutions Group's vBoost program offers a guaranteed decrease in virtualized server utilization of over 50%.  Buying back over 50% of your existing server utilization offers both cost avoidance (no need for new servers) as well as immediate cost savings (fewer servers, power, A/C etc.).  Other programs offer similar savings for storage and networking.  Businesses that realize the initial cost is only a small portion of the overall investment and are now going a long way toward decreasing costs and increasing efficiency.

Visit the vBoost page on our website to learn more.

delicious  |   facebook  |   digg it  |   twitter  |   stumbleupon  |   ping this!

Comments (0)
Michael Gray September 10 2009 04:12:26 PM

Over the past two years, I have met almost 200 CIO’s at Champion’s IT Executive Roundtables. Our discussions have traversed the business spectrum of the IT management challenges that confront today’s CIO. These challenges ranged from high-level tactical issues including the retention of key employees, balancing governance and regulation requirements, disaster recovery, and security versus supporting the applications that drive business, and transforming data into useful information – to high-level strategic challenges like the transformation of traditional IT organizations into Consumptive Computing environments, how Cloud Computing has become a reality, and Leadership in these swirling economic times.

Leadership is the challenge that has emerged from the Roundtables that separates truly successful CIO’s from the pack. Leadership holds the key to addressing all of these challenges. Leadership takes courage, conviction, clarity of purpose, and resolve.

The obstacle to change is fear – inertia, people protecting their places in the organization, and adherence and loyalty to the status quo. People would rather accept marginal performance than risk taking a path that is unknown to them. True leaders put aside their own fear – and lead their people into unchartered waters that bring new value and success to their organization.

For Champion, the CIO’s who manifest this Leadership mantle are “Rich CIO’s.” Other CIO’s whose organizations are hamstrung by practices that do not create a competitive advantage for their companies are “Poor CIO’s.” Every month, Champion will compare and contrast how RICH CIO’S and POOR CIO’S address specific issues.

Visit www.richciopoorcio.com to learn more.

delicious  |   facebook  |   digg it  |   twitter  |   stumbleupon  |   ping this!

Comments (0)
David Boim August 17 2009 11:00:00 AM

I wanted to discuss about one of the most talked about new features in vSphere. The new fault tolerance feature allows you to have a primary Virtual machine on one ESX host and a mirror of that Virtual Machine on another in lock step with the primary. If the primary virtual machine goes down for any reason, the mirror Virtual machine with takeover in 2 milliseconds. Since the memory and processor are in lockstep with each other, you do not lose any transactions. This sounds great but there are some restrictions that you have to take into account. Fault Tolerance (FT) provides continuous availability for applications by creating a live shadow instance of a virtual machine that is in virtual lockstep with the primary instance. By allowing instantaneous failover between the two instances in the event of hardware failure, VMware Fault Tolerance eliminates even the smallest of data loss or disruption.

The guest operating system support for VMware FT is different for vSphere in general. For specific guest operating system version information, see the Guest Operating System Installation Guide.

VMware collaborated with AMD and Intel in providing an efficient VMware FT capability on modern x86 processors. The collaboration required changes in both the performance counter architecture and virtualization hardware assists of both Intel and AMD. These changes could only be included in recent processors from both vendors: 3rd-Generation AMD Opteron based on the AMD Barcelona, Budapest and Shanghai processor families; and Intel Xeon processors based on the Penryn and Nehalem microarchitectures and their successors.

Some system vendors are certifying that their systems work with FT. You can find details on the at FT-certified systems.

You can also check processor, operating system, and virtual machine configuration compliance with VMware FT by downloading and running the VMware SiteSurvey utility from Champion Solutions Group Tools Section. It highlights compliance issues and describes how to correct them.

There are a number of requirements which must be met before FT can be setup.

• CPUs: Limited processors must be the same family (no mix/match)
• Requires Intel 31xx, 33xx, 52xx, 54xx, 55xx, 74xx or AMD 13xx,23xx, 83xx series of processors
• SMP virtual machines are not supported.
• Hardware Virtualization must be enabled in the BIOS.
• Hosts must be in a VMware High Availability enabled cluster.
• Storage: shared storage (FC, iSCSI, or NAS).
• Network: minimum of 3 NICs for various types of traffic (ESX Management/VMotion, virtual machine traffic, FT logging).
• GigE required for VMotion and FT logging.
• Minimized single points of failures in the environment. For example, NIC teaming, multiple network switches, storage multipathing.
• Primary and secondary hosts must be running the same build of ESX.

For VMware FT to perform as expected, it must run in an environment that meets specific pre-requisites.

• The primary and secondary fault tolerant virtual machines must be in a VMware HA cluster.
• Primary and secondary virtual machines must not run on the same host. FT automatically places the secondary virtual machine on a different host.
• Virtual machine files must be stored on shared storage.
• Shared storage solutions include NFS, FC, and iSCSI.
• For virtual disks on VMFS-3, the virtual disks must be thick, meaning they cannot be thin or sparsely allocated.
• Turning on VMware FT automatically converts the virtual machine to thick-eager zeroed disks.
• Virtual Raw Disk Mapping (RDM) is supported. Physical RDM is not supported.
• Multiple gigabit Network Interface Cards (NICs) are required.
• A minimum of two VMKernel Gigabit NICs dedicated to VMware FT Logging and VMotion.
• The FT Logging interface is used for logging events from the primary virtual machine to the secondary FT virtual machines.
• For best performance, use 10Gbit NIC rather than 1Gbit NIC, and enable the use of jumbo frames.
• VMware FT requires that Hardware Virtualization (HV) be turned on in the BIOS. The process for enabling HV varies among BIOSs. Contact your vendor for specifics.

VMware FT provides more continuity than VMware HA since FT does not require a virtual machine restart, and the secondary virtual machine immediately comes online with all, or almost all state information preserved.

Virtual machines protected by FT are not handled by VMware HA for restart priority. It is considered disabled in the restart priority.

I hope this helps when you are considering Fault Tolerance for your vSphere environment.

delicious  |   facebook  |   digg it  |   twitter  |   stumbleupon  |   ping this!

Comments (0)
Kevin Vogl July 20 2009 02:00:00 PM

In order for some manufacturers to try to gain an edge over a competing product they will typically try to use and create some kind of uncertainty around that product using what is known in the IT world as “FUD”, where FUD is an acronym for Fear, Uncertainty, and Doubt.  A couple of the common misconceptions or FUD that competitors try to portray is that Riverbed technologies will “tunnel” all traffic between remote sites and the other is that the Riverbed appliances will cache files, which can result in a client receiving an old copy of information.  Since I have just gotten back from a week of intensive Riverbed training, I would like to help dispel this FUD.  Keep in mind that I’ve been a Cisco trainer for about 7 years and hold many various Cisco certifications, minus CCIE, so I’m leaving any kind of bias at the door. Tunneling FUD

In order to completely understand this you need to be a little bit familiar with the TCP connection sequence of a three-way-handshake.  As a quick review, the three-way handshake is used for two hosts to basically get their ducks in a row before they start sending traffic to each other.  The first segment is a synchronize (SYN) packet that indicates the two hosts wanting to start a connection.  The second packet that comes back to the originator of the first packet is a SYN/ACK packet and then the third packet is an ACK packet.  After that short sequence, then the two hosts can send TCP based traffic.  These packets have lots of info that help with reliability, quality of service (QoS), and flow-control between the hosts.

When we have two Riverbed Steelhead appliances in between the two hosts that are trying to communicate, then basically what happens is that the TCP connection sequence is intercepted between the two hosts and instead of the hosts doing the connection sequence directly with each other they are unknowingly exchanging the connection sequence packets with the intermediary Steelhead appliances.  The TCP handshake still occurs between the two hosts but is proxied between the Steelhead appliances, whereas the Riverbed devices create their own TCP handshake to begin the optimization process.  It can get a little more complex than this in certain instances, but as you can see there is no tunneling that is occurring between the Steelheads or hosts…  just some TCP 3-way handshakes.

Caching FUD

Riverbed Steelhead appliances use a proprietary algorithm called Scalable Data stReamlining (SDR) to break up large amounts of data into smaller pieces called references and stores them on the Steelhead.  The first time that a file is transferred between two Steelheads (cold transfer) all data and references to the data are sent across the wire.  Subsequent transfers are sent using the references and that is where the majority of WAN optimization savings occur.

But what happens when a user goes into a document and changes a few letters, saves it, and another user requests the file?  Does the entire file have to get retransmitted?  The answer is no.  Remember, the Steelhead appliance breaks the file into references so the entire file didn’t change, only some of the references changed.  Now the Steelhead will send the original references that didn’t change along with the new data and new references that point to the new data.  During a warm transfer, the Steelheads are only sending references to blocks of data across the wire and not files so there is no chance that a user can receive an old or outdated copy of a file.  The Steelheads never send a file to a host that has not been requested and will compare references every time a file is transmitted.

delicious  |   facebook  |   digg it  |   twitter  |   stumbleupon  |   ping this!

Comments (0)
Dave Asher July 1 2009 03:51:30 PM

Several years ago, company's IT solution decisions were moving from the IT departments to the corporate purchasing departments.  IT was still able to decide what to buy so long as it was in their budget.   What they were losing was the power to decide "who" to purchase from as companies focused on getting multiple bids to reduce costs and remain compliant with Sarbanes Oxley and other compliance regulations.  In this economic environment we are seeing the next shift in this cycle.   Decision making is now moving from purchasing to the finance organizations and CFO's. Formerly, technology solutions and projects required a solid analysis of TCO, Total Cost of Ownership.  If IT could prove that a project paid for itself over a long period of time and possibly reduced costs over the current solution, they were allowed to move forward.

This has changed rapidly as the finance teams begin to look for a true ROI, Return on Investment, and how quickly a project can pay for itself.  IT managers without experience in this type of analysis are leaning heavily on their partners and consultants for help in justifying projects.  

Firms such as Champion Solutions Group have the tools and expertise to prove that projects have the proper ROI and that they deliver immediate value to their clients.  

delicious  |   facebook  |   digg it  |   twitter  |   stumbleupon  |   ping this!

Comments (0)
Michael Gray July 1 2009 12:04:14 PM