In Part I of this series, I discussed some design options for a virtual infrastructure (Traditional Rackmount, Converged Rackmount, and Converged Blade). Using the Converged Blade option as the model going forward, we’ll explore the individual components of this solution in more detail. This post will explore the Compute Platform (UCS B-Series) in more detail.

Let’s start with the “brains” of the UCS B-Series, the 6100 series fabric interconnects.

6100 Series Fabric Interconnects:

Interconnect / Module Options:

• 6120XP – (20) 10gbE and FCoE capable SFP+ port Fabric Interconnect with a single expansion module slot
• 6140XP – (40) 10gbE and FCoE capable SFP+ port Fabric Interconnect with two expansion module slots

Expansion Module Options:

• 10Gbps SFP+ – (6) ports
• 10Gbps SFP+ – (4) ports, 1/2/4 Gbps Native Fibre Channel SFP+ – (4) ports
• 1/2/4 Gbps Native Fibre Channel SFP+ – (8) ports
• 2/4/8 Gbps Native Fibre Channel SFP+ – (6) ports

Below is a diagram of the UCS 6120XP labeled with the different ports:

(Read more…)

{ 0 comments }

Server virtualization is infectious. It is a technology that tends to take off in record pace in IT organizations that have adopted it as part of their infrastructure. It has been my experience that organizations fall into one of two broad categories when it comes to their virtualization initiatives. They either look at server virtualization as a “Strategic Initiative” or they use server virtualization as a “Tactical Tool.” Let’s explore these categories and then I’ll discuss some infrastructure options for a structured virtual infrastructure.

Server Virtualization as a “Tactical Tool”

I have seen this in many organizations. The IT group needed to test a new application or needed to spin up a new server quickly. What’s the quickest way to spin up a new server? Server virtualization, of course. So, here is how I see many infrastructures get started:

• IT department downloads the free vSphere Hypervisor
• IT department proceeds to click next until the hypervisor is installed
• IT department spins up a few virtual machines on the hypervisor
• “Life is good. That was easy wasn’t it?”
• "It’s so easy and cool that more demand creeps up for further virtual machines
• Pretty soon the IT department wants to host production workloads on the hypervisor
• “But wait? What about failover, live migration, etc. Don’t I need a SAN for that?”
• How “much” storage do I need?
• IT department calculates how much space they are using on their servers, or worse yet, how much disk space in total is available on all of their servers combined
• “Wow! I need a lot of space to host all of those servers”
• IT department buys large slow “shared disks” of some variety to satisfy the SAN requirement
• IT department sets up vCenter on a spare server
• IT department clicks next until a few hypervisors are installed and added to the new cluster complete with “shared storage”
• Now there is some equipment and software in place to host virtual machines
• IT department spins up new virtual machines until they are suddenly out of capacity or things are “just slow and error prone”
• Virtualization stalls because there is no more capacity and there is a lack of trust in the virtual infrastructure as it stands
• IT department starts purchasing physical servers again for “critical” applications
• “Now DR must be provided for those “critical” applications. How can we protect them?”
• “The easiest thing to do would be to leverage virtualization, but we’re out of capacity and the platform has been problematic”
• “What do we need to do to leverage virtualization on a larger scale in our infrastructure?”

It’s a vicious cycle and it is why I continue to see companies only 20-40% virtualized. It is great that server virtualization technology has been embraced. However, without proper planning and a structured approach to building and maintaining the virtual infrastructure, many organizations will continue to be only 20-40% virtualized. They are leaving the many benefits of server virtualization and even money on the table if they stall.

So, this series of posts will explore the alternative of server virtualization as a “Strategic Initiative”. This is the approach that I take with my clients at TBL to either build a structured virtual infrastructure from the ground up or remediate a “tactical …
(Read more…)

{ 1 comment }

On Thursday, May 5th I had my second Ask Harley Session, the Ask Harley: Guitar Hero Edition. This was a session where I answered virtualization and VMware related questions on Twitter. I received a lot of great questions during this session. At the end of the session my virtual band, “Harley Stagner and the 46er’s” played Michael Jackson’s “Beat It” live on Guitar Hero. The song was determined by a vote and the stream was provided by Cisco Show and Share. Thank you to all who participated. Below are the questions and their answers in case you missed them on Twitter.

Ask Harley: Question 1 – What are the reasons / cases for using different VMware NMP PSPs? Why would you not use Round-Robin? Thanks!

NOTE: This answer was originally provided over a series of Tweets by Harley Stagner on 5/5/11 at TBL Networks’ Twitter site as part of our “Ask Harley” series.

Answer:

The VMware NMP PSP that is chosen (either MRU or Fixed) by default will typically be the supported PSP for the storage array.

You should not change to Fixed or MRU from the default.

Changing to Round-Robin is supported on all arrays unless specifically noted by the …
(Read more…)

{ 0 comments }

So I’ve been spending a lot of time in our lab with the Cisco Nexus Virtual Security Gateway. I have come to the conclusion that it rocks! Finally, the virtual infrastructure is no longer treated as a second class citizen when it comes to securing network traffic between virtual machines. We are at a point now with the Cisco VSG that we can have robust Cisco infrastructure, including security, from the upstream physical network to the virtual network.

The Cisco Nexus VSG builds upon the Nexus 1000v distributed virtual switch and communicates with the Virtual Ethernet Modules in the Nexus 1000v to provide a very robust security policy engine that can perform granular filtering and matching on a number of parameters. For example:

• Network (ip address, port number, etc.)
• VM (VM Name, Installed OS Name, Cluster, Host, Zone)

Yep, that’s right, I said VM. Since the Cisco VSG integrates with the vSphere API’s and vCenter, you can filter on items like a virtual machine name or partial name, installed OS, cluster, etc. This is very powerful. I no longer have to rely on network and IP rules alone to filter traffic between virtual machines. This is a more intelligent approach to filtering that really highlights the synergies that Cisco and VMware have established. Best of all, once it is set up everything is managed from a single Cisco Virtual Network Management Center (VNMC) instance. This web-based management tool let’s you manage multiple Virtual Security Gateway instances. Let’s look at a simple example of how easy it is to perform traffic filtering in the virtual infrastructure with the Cisco VSG.

Topology and Components:

• vSphere 4.1 Enterprise Plus Host Servers
• Cisco VNMC VM
• Cisco Nexus 1000v Infrastructure
• Cisco VSG Infrastructure
• tenanta-srv1 VM
• tenanta-srv2 VM
• tenantb-srv1 VM
• tenantb-srv2 VM

The goal of this configuration is to allow the following communication flows:

• tenanta-srv1 and tenanta-srv2 should communicate
• tenantb-srv1 and tenantb-srv2 should communicate
• The Tenant A servers(tenanta-srv1 and tenanta-srv2) should not be able to communicate with the Tenant B servers (tenantb-srv1 and tenantb-srv2)
• Anyone else should be able to communicate with both the Tenant A and Tenant B servers
• There is a further caveat that the Tenant A and Tenant B servers are both on the same subnet (don’t worry these servers belong to the same company )

Below are the network settings:

• tenanta-srv1 VM – 10.91.41.200
• tenanta-srv2 VM – 10.91.41.201
• tenantb-srv1 VM – 10.91.41.202
• tenantb-srv2 VM – 10.91.41.203
• a client with another ip address

Here are the general steps for setting up this scenario once the Cisco VSG infrastructure is in place:

• Create a tenant
• Assign the VSG to the tenant
• Create a zone each for the Tenant A and Tenant B servers (these zones match VM’s with names that contain “tenanta” and “tenantb” respectively)
• Create a firewall policy for the VSG
• Create a policy set that includes the policy
• Bind …
  (Read more…)

  { 0 comments }

So I’ve been spending a lot of time in our lab with the Cisco Nexus Virtual Security Gateway. I have come to the conclusion that it rocks! Finally, the virtual infrastructure is no longer treated as a second class citizen when it comes to securing network traffic between virtual machines. We are at a point now with the Cisco VSG that we can have robust Cisco infrastructure, including security, from the upstream physical network to the virtual network.

The Cisco Nexus VSG builds upon the Nexus 1000v distributed virtual switch and communicates with the Virtual Ethernet Modules in the Nexus 1000v to provide a very robust security policy engine that can perform granular filtering and matching on a number of parameters. For example:

• Network (ip address, port number, etc.)
• VM (VM Name, Installed OS Name, Cluster, Host, Zone)

Yep, that’s right, I said VM. Since the Cisco VSG integrates with the vSphere API’s and vCenter, you can filter on items like a virtual machine name or partial name, installed OS, cluster, etc. This is very powerful. I no longer have to rely on network and IP rules alone to filter traffic between virtual machines. This is a more intelligent approach to filtering that really highlights the synergies that Cisco and VMware have established. Best of all, once it is set up everything is managed from a single Cisco Virtual Network Management Center (VNMC) instance. This web-based management tool let’s you manage multiple Virtual Security Gateway instances. Let’s look at a simple example of how easy it is to perform traffic filtering in the virtual infrastructure with the Cisco VSG.

Topology and Components:

• vSphere 4.1 Enterprise Plus Host Servers
• Cisco VNMC VM
• Cisco Nexus 1000v Infrastructure
• Cisco VSG Infrastructure
• tenanta-srv1 VM
• tenanta-srv2 VM
• tenantb-srv1 VM
• tenantb-srv2 VM

The goal of this configuration is to allow the following communication flows:

• tenanta-srv1 and tenanta-srv2 should communicate
• tenantb-srv1 and tenantb-srv2 should communicate
• The Tenant A servers(tenanta-srv1 and tenanta-srv2) should not be able to communicate with the Tenant B servers (tenantb-srv1 and tenantb-srv2)
• Anyone else should be able to communicate with both the Tenant A and Tenant B servers
• There is a further caveat that the Tenant A and Tenant B servers are both on the same subnet (don’t worry these servers belong to the same company )

Below are the network settings:

• tenanta-srv1 VM – 10.91.41.200
• tenanta-srv2 VM – 10.91.41.201
• tenantb-srv1 VM – 10.91.41.202
• tenantb-srv2 VM – 10.91.41.203
• a client with another ip address

Here are the general steps for setting up this scenario once the Cisco VSG infrastructure is in place:

• Create a tenant
• Assign the VSG to the tenant
• Create a zone each for the Tenant A and Tenant B servers (these zones match VM’s with names that contain “tenanta” and “tenantb” respectively)
• Create a firewall policy for the VSG
• Create a policy set that includes the policy
• Bind …
  (Read more…)

  { 0 comments }

This has been a very cool couple of weeks for the VDI landscape with VMware View. The View client for the iPad that was first seen in a demo at VMword US in 2010 is finally here. Now I know what may have taken them so long.

VMware View 4.6 was also released in the past couple of weeks. With version 4.6 came the ability to use the PCOIP protocol on the VMware View Security Server that sits in your DMZ. This eliminates the need to set up a VPN for the endpoint device to access a desktop pool using the PCOIP protocol from outside your firewall.

I can now see where this functionality would be absolutely necessary to access a View desktop from the iPad. Super-mobile VDI is really cool, but it would have been a drag to only access your desktops over RDP. Also, having to set up a VPN connection from your iPad would go against the ease of use that the iPad offers.

Below is a video demo of the new iPad client. Among some of the coolest features are the virtual laptop track …
(Read more…)

{ 0 comments }

In this series we’ve already looked at virtual desktop storage efficiency with “linked clones” and user profile management options. In this post we will discuss another piece of the desktop image that can potentially be offloaded to the network. The applications.

Remember that in a virtual desktop environment one of our goals is to make the “gold” master image as vanilla as possible. We do this by offloading unique components of the desktop off of the image and onto the network. VMware has a way to virtualize your applications so that they can be offloaded onto a network share. This means that the applications can be streamed to the user when they log in to their desktop. So, the desktop becomes disposable and the user gets the appropriate applications when …
(Read more…)

{ 0 comments }

On Thursday, January 13th I had my first Ask Harley Session. This was a session where I answered virtualization and VMware related questions on Twitter. I received a lot of great questions during this session. Thank you to all who participated. Below are the questions and their answers in case you missed them on Twitter.

Ask Harley: Question 1 – What common issues or mistakes do you see with your customers who have setup VMware infrastructure or are looking to setup VMware?

NOTE: This answer was originally provided over a series of Tweets by Harley Stagner on 1/13/11 at TBL Networks’ Twitter site as part of our “Ask Harley” series.

Question:

What common issues or mistakes do you see with your customers who have setup VMware infrastructure or are looking to setup VMware?

Answer:

Most of the issues in an initial deployment occur from a lack of capacity, application, and infrastructure planning.

Consider the 4 core (CPU, RAM, DISK, NET) resources from a capacity standpoint. Consider application requirements (MS Clustering, Dongles, Vendor Support, Etc.).

Consider scalability and ease of management from the infrastructure standpoint. Infrastructure item examples: Scale up vs scale out(more hosts = more DRS opportunities,Less hosts = more risk).

Details. Details. Details. Example- Do I have enough space for VMDK and Swap files? Do I have a syslog server for ESXi?

Keep it simple. Avoid Resource Pools, Reservations, and Limits unless they are needed.

Resource pools are NOT for organization. That’s worth repeating. Resource pools are NOT for organization. Folders are.

There is more involved in a virtualization design / deployment than clicking next.

Ask Harley: Question 2 – Why would you use Virtual Port-ID NLB instead of IP-Hash NLB?

NOTE: This answer was originally provided over a series of Tweets by Harley Stagner on 1/13/11 at TBL Networks’ Twitter site as part of our “Ask Harley” series.

Question:

Why would you use Virtual Port-ID NLB instead of IP-Hash NLB?

Answer:

The summary answer would be simplicity. Port-ID is the default load balancing and good in a wide range of use cases.

Port-ID Advantage: Simple, effective. Port-ID Disadvantage: Only egress traffic is load balanced as it depends on the source virtual port id

IP-Hash has an upstream dependency on 802.3ad static link aggregation. An example is etherchannel on Cisco Switches. Even if the dependency is met. You may not be load balancing as efficiently as you think. You need MANY destinations in order for IP-Hash maximum effectiveness.

Why? Because IP-Hash algorithm uses an Xor of source and destination IP using the least significant byte (LSB) of both addresses. …
(Read more…)

{ 0 comments }

On Thursday, January 13th I had my first Ask Harley Session. This was a session where I answered virtualization and VMware related questions on Twitter. I received a lot of great questions during this session. Thank you to all who participated. Below are the questions and their answers in case you missed them on Twitter.

Ask Harley: Question 1 – What common issues or mistakes do you see with your customers who have setup VMware infrastructure or are looking to setup VMware?

NOTE: This answer was originally provided over a series of Tweets by Harley Stagner on 1/13/11 at TBL Networks’ Twitter site as part of our “Ask Harley” series.

Question:

What common issues or mistakes do you see with your customers who have setup VMware infrastructure or are looking to setup VMware?

Answer:

Most of the issues in an initial deployment occur from a lack of capacity, application, and infrastructure planning.

Consider the 4 core (CPU, RAM, DISK, NET) resources from a capacity standpoint. Consider application requirements (MS Clustering, Dongles, Vendor Support, Etc.).

Consider scalability and ease of management from the infrastructure standpoint. Infrastructure item examples: Scale up vs scale out(more hosts = more DRS opportunities,Less hosts = more risk).

Details. Details. Details. Example- Do I have enough space for VMDK and Swap files? Do I have a syslog server for ESXi?

Keep it simple. Avoid Resource Pools, Reservations, and Limits unless they are needed.

Resource pools are NOT for organization. That’s worth repeating. Resource pools are NOT for organization. Folders are.

There is more involved in a virtualization design / deployment than clicking next.

Ask Harley: Question 2 – Why would you use Virtual Port-ID NLB instead of IP-Hash NLB?

NOTE: This answer was originally provided over a series of Tweets by Harley Stagner on 1/13/11 at TBL Networks’ Twitter site as part of our “Ask Harley” series.

Question:

Why would you use Virtual Port-ID NLB instead of IP-Hash NLB?

Answer:

The summary answer would be simplicity. Port-ID is the default load balancing and good in a wide range of use cases.

Port-ID Advantage: Simple, effective. Port-ID Disadvantage: Only egress traffic is load balanced as it depends on the source virtual port id

IP-Hash has an upstream dependency on 802.3ad static link aggregation. An example is etherchannel on Cisco Switches. Even if the dependency is met. You may not be load balancing as efficiently as you think. You need MANY destinations in order for IP-Hash maximum effectiveness.

Why? Because IP-Hash algorithm uses an Xor of source and destination IP using the least significant byte (LSB) of both addresses. …
(Read more…)

{ 0 comments }