Comments for BRAD HEDLUND .com

Comment on The FOLLY in the HP vs Cisco UCS Tolly Group report on bandwidth by Jeremy Foster

Jeremy Foster — Thu, 29 Jul 2010 06:32:26 +0000

Sri,
First off I work on the UCS team at Cisco, lets make that clear.
Second I think you are missing the point of UCS entirely. This whole management point argument is just not one that really makes sense for you to make. UCS Manger is like a mega blade chassis that holds 320 servers under single management point including both LAN and SAN connectivity to any server at any time. UCS manger is simply a remote control for your TV. The open XML API which can be leveraged into the existing tools in the datacenter (BMC,Ionix, Tivoli,SCOM, ETC…). The existing tools are the ‘Universal Remote’ to control the data center Home theatre.

Every other manufacture scales on a Chassis Basis (16 or 14 Servers) We scale on a datacenter or Mega Chassis 320 Server Basis. If you want to incorporate the 321st server then most likely your existing tools already have plug ins to make them ‘UCS Aware’ and they can scale across multiple UCS PODS. Cisco’s approach is about Choice.

Here is a ‘Challenge’ go setup UCS System. Outside of giving the Mangers IP addresses out of the box you can control everything else directly from BMC BladeLogic or Ionix or Tivoli or SCOM. Cisco Is not in the OS provisioning business. Cisco is not in the orchestration business.The value add of UCS is to allow UCS Manager XML API to provide the ‘Missing Link’ between existing customer management stacks and the internal cloud.

Cisco UCS customer can do more WITH THEIR EXISTING MANAGEMENT TOOLS by using UCS.

I really encourage you to setup a UCS because it really is something you appreciate once you do. If not that is just as well, I really like all the FUD that is thrown at UCS because it is so off base it really helps us out. Also glad to see Dell saved scalent from bankruptcy and look forward to competing with dell for customers compute business.

Comment on Cisco UCS Networking Best Practices (in HD) by Karan Bhagat

Karan Bhagat — Wed, 21 Jul 2010 21:52:34 +0000

Brad,
awsome post…i was just having a tech session with your Cisco peer Steve Fishman… good stuff… I’d like to see the same for BP on FCoE to FC from the 6100 to MDS91xx… and how to scale FC to large SAN env from UCS.

Comment on Cisco UCS Networking Best Practices (in HD) by Joe Ignatius

Joe Ignatius — Tue, 20 Jul 2010 01:02:21 +0000

Hi Brad,

These videos are really informative and clear. It is great to have a place to review topics.

I would love to see something similar where the subject is “How Nexus platform works with UCS, in the data center”.

Joe

Comment on Cisco UCS and Nexus 1000V design diagram with Palo adapter by Brad Hedlund

Brad Hedlund — Sat, 17 Jul 2010 14:47:25 +0000

IPK,
With design #2 (VN-Link in HW) you can have the Palo adapter provide 54 dynamic vNIC’s per host, and therefore 54 virtual machines per host. Should be no problem with your 10:1 consolidation ratio.
As far as extending this across multiple B-Series blades, the Fabric Interconnect is acting as a vDS from the perspective of vCenter and therefore has the same configuration maximums as a normal software based vDS. According to the new vSphere 4.1 Configuration Maximums Guide you can have 350 hosts in one vDS. http://www.vmware.com/pdf/vsphere4/r41/vsp_41_config_max.pdf

Having said that, the theoretical maximum number of blades under the auspices of a Fabric Interconnect cluster is 320. The current supported number of chassis in one cluster is (14), so the actual maximum as of today would be 112 blades in one HW VN-Link DVS.
For HA/DRS clusters the VMware maximum is still 32 hosts.

Cheers,
Brad

Comment on Cisco UCS and Nexus 1000V design diagram with Palo adapter by IPK

IPK — Sat, 17 Jul 2010 03:57:09 +0000

Hi Brad,
Just a simple query from a design perspective. I want to compare the following designs;

1) Nexus 1000v with Palo adapter [VN-Link in SW]
2) Palo adapter with Passthru switching with FI acting as the vDS [VN-Link in HW]

in a VMware virtualization environment where there is 10:1 VM density across three B-Series HH blades. Workloads are fairly I/O intensive hence I preferred the second approach. Any limitation in terms of extending this design across B-Series blade systems?

IPK

Comment on How to Calculate TCP throughput for long distance WAN links by Brad Hedlund

Brad Hedlund — Fri, 16 Jul 2010 01:49:09 +0000

Mina,
The throughput calculations will tell you the maximum possible throughput. If your DSL line is much slower than what your calculation says, well, of course your actual throughput will be limited to your link speed.
If your link speed is much faster than the result of your calculations, you will not transmit any faster than what your calculation states, because that is the maximum possible throughput. This is the entire point this article tries to make.

Cheers,
Brad

Comment on How to Calculate TCP throughput for long distance WAN links by mina

mina — Wed, 14 Jul 2010 10:10:04 +0000

Dear Brad ..
any Update?

Comment on Cisco UCS Networking Best Practices (in HD) by Brad Hedlund

Brad Hedlund — Wed, 14 Jul 2010 02:29:54 +0000

Andy,
The Fabric Interconnect in End Host Mode connects to the upstream switch like a “Host”, not as a “Switch”. Therefore you should configure the upstream switch port (or port channel in your case) just as you would if it were a server attaching to it. Therefore the best configuration on the 5K, in your case, would be: ‘spanning-tree port type edge trunk‘

Cheers,
Brad

Comment on Cisco UCS Networking Best Practices (in HD) by Andy

Andy — Tue, 13 Jul 2010 16:02:23 +0000

Brad,
I have configuration question. when connecting a Fabric Interconnect running in End Host Mode to a nexus 5k vPC, what spanning-tree port type should the 5k port channel be? i.e. spanning-tree port type edge or spanning-tree port type network?

thanks!

Comment on How to Calculate TCP throughput for long distance WAN links by mina

mina — Sun, 11 Jul 2010 00:00:51 +0000

any update please??