vSphere Design, Get your basics right the first time!!!!!

How to start designing a vSphere environment, what is involved, whom to involve?

What is a Design?

“A streamlined process which helps the various elements in the organization to determine how to assemble and configure a
Virtual Infrastructure which is strong and Flexible. A design should contain all the important information that meets the
Functional Requirements of an Organization.”

The functional requirments unify 3 different facets of the design:

Technical – What to deploy?
Operational – How to deploy and Support?
Organizational – Who will deploy and support?

Why Vmware or any other Virtualization product for that matter?

There should be a strong reason/objective to deploy Virtualization in the organization, some of them are:

  • Datacenter Consolidation which will help saving Datacenter space, power and Cooling costs etc
  • New Application rollout, Exchange 2010 for ex.
  • Disaster Recovery/Business continuity, Deploy new DR/BC Solution using VMware vSphere and SRM
  • Virtual Desktop Infrastructure

Facets of the design:

Technical:

  • What type of servers, blades or Rack Mounted?
  • Type of Physical CPU’s in the server?
  • Type & Quantity of Storage?
  • Kind of Networking etc?

Organizational:

  • Who will manage the whole environment?
  • Who will provision what? Storage, Network etc?
  • Who will support VM’s, their backup’s etc?
  • Who will be responsible for Security Policies?

Operational:

  • How will the Hosts be managed?
  • How will the VM’s be provisioned?
  • How will I Failover to DR Site?
  • How will compliance be verified?

How to go about desigining any Infrastructure?

  • Review Infrastructure documents provided by the client, although it  may not provide the complete but most of the Functional Requirements
  • Interview the IT teams and IT Management teams (everyone and anyone as required) to understand the environment better
  • Top 5 issues at the user level that can be resolved using VMware Platform

 Assemble bits and pieces?

  • It’s always acceptable to remove functional requirements, if at any point, they don’t serve any purpose what’s the point in having them?
  • Set standards and Best practices, but every Best practice recommended by a vendor may not suite your environment, get a deeper look into the Best Practices and ensure they meet your functional requirements
  • Start documenting every bit of the Design, so that the implementation teams find it easy

All in all, “get your basics right” before you jump into any Technical Jargons 🙂

*Most of the information is being taken from Scott Lowe’s Design book which I thought is the best information available so far 🙂

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s