Reason #1  – Super secret projects

I have been doing detailed design work for a couple REALLY LARGE data centers clients (the type that dominate top 10 lists) . These builds were extremely sensitive, and inadvertently  leaking internal information would not have been a good thing. Since I tend to write about what I am currently working on, I had decided to limit my posting just to avoid the chance of leaking any specific design elements.

Reason #2 – Business is booming

Things got really busy. For me the great recession of 2009 was spent aggressively marketing new product lines and attracting new talent. There is a saying that your marketing dollars go twice as far during a down turn. That saying is completely true. Every day was spent working my tail off to ensure that the region stayed afloat. During that time there were zero layoffs, as well as some key talent acquisitions.

During that same time many of the competitors in my region were forced to downsize their team, and limit the amount of time and money they spent helping their clients. While I can understand the business conditions that can force you to make the decision to lay off, it isn’t the best long term strategy to put your best talent onto the market. It is like burning your winter clothing in a blizzard. In the short term it seems like a good decision, but in the long term you will pay dearly.

Avoiding layoffs, doubling down on marketing, and aggressively supporting Cisco’s entrance into the server market all came together and resulted in my region dominating the stack rankings, taking and holding number one positions in Enterprise, Select and Commercial regions in 2010. In retrospect this could be written up into a case study how to grow a business during an economic downturn. Dominating the market however translates into your free time being dominated. Luckily I work with extremely capable and talented Sales and Engineering teams, which was the only thing that saved me from going insane from the amount of work this last year.

Getting to number one isn’t easy. Staying number one is harder still.

Reason #3 – Certifications

If I haven’t been in a design session I have been nose down in a book this year. I had to re-certify a bunch of my certs as well as add EMC’s Technical Architect and Implementation engineer to balance out my NetApp certifications. I also managed to create a nice amount of work for myself by contributing to design sessions around the joint VMware / Cisco data center certifications. Pretty much every suggestion I threw up on the board got implemented, and I ended up having to pass quite a few tests to fill those roles for my current employer.

Reason #4 – Getting healthy

The day I got back from Networkers in 2009 I had one of those life changing moments that was just the kick in the pants I needed. As of writing this article I am down 92 pounds from that day. I have changed my dietary habits to something resembling what humans are intended to eat, as well as started racing bicycles again.

Being competitive on a bike requires quite few hours a week, and that has cut into time that I had previously scheduled to write. Thankfully I learned a lot about effective training this last year, and I am making much better use of my training hours now. This is resulting in much more free time for writing.

What can you expect to hear about in 2011?

I would look forward to some very cool stuff. Most of the technologies from Cisco I have been working with have become public, and don’t have NDA restrictions around them. The NetApp and EMC (FlexPod and VBlock) solutions are both developing nicely and in the public domain now. There are still quite a few topics that are off limits, but now there are more things that I can talk about vs things I cannot talk about.

In short, I’m back. Expect more from me soon.Similar Posts:

• What does it take to pass the CCIE exam?
• Why was Storage Networking my first CCIE? And What did I do to prepare?
• Certguard, Ethan Banks, Network World and Common Sense
• How to succede in 2007 – By Tim O’Reilly
• Me and the Nexus 7000 last week at the Data Center VT
• Cisco Certified Design Expert – CCDE – officially released by Cisco

--Colin McNamara

Where was Colin in 2010?

The Problem

Apparently when the UCS pod’s firmware was updated to 1.3(1c) an interesting bug was encountered. What happens is when you associate your service profile to a server which has had another service profile associated with it previously you a config failure error stating that the local disk config you are applying is destructive to the physical server and violates a requirement.

I headed over to the local disk policies section of UCSM to see what was going on. Once I got there I noticed a new check box labeled “Protect Configuration”.

It’s a lab, which means that change controls should be followed but rarely are. Following that mantra and went ahead and unchecked the “Protect Configuration” box on one of the commonly used local disk policies and saved my changed. A little background on HOW I am shelled into this lab. I am shelled in via a VMware View server that has component installed on blades 1 and 2 of this chassis. And, yes the local disk configuration that I made a change to was used by these profiles.

A little while later, after all the servers went through a reboot and settings application cycle and a coworker kicked a View server in the butt I was back in. The first thing I did was try to apply my service profile. I got the same error message.

I went back to the local disk config profile section to see if maybe the change hadn’t applied. But, when I edited the profile, it showed that the local disk config should not be in a protected configuration.

However when I went into a service profile to change the same local disk policy, you will notice that this same local disk config was still showing up as a protected configuration.

The Solution

When you encounter a bug, the first thing you do if the obvious isn’t working is check the release notes. This bug did show up int he 1.3 release notes, with a tag of “no workaround”. I don’t believe in not having workarounds so proceeded to bang my head up against a wall trying time consuming things like rediscovering servers, recovering bios’s, creating custom firmware packs and more.

After all that failed, I tried the simple things (you like the reverse order?). My excuse was that I assumed that TAC who had created the bug had already tried this. I guess I should assume less often…

The simple thing, that I should have done from the start was create a brand new local disk profile. I named this profile FIX-PERSIST-ANY, choosing to use any local disk config and expressly making it non-persistent. I then applied the same local disk policy that was on previously to my service profile, and then once applied changed it to FIX-PERSIST-ANY.

At that point I whatever flag that had gotten stuck in the UCSM database got unstuck and I was able to get my service profile applied.

Moral of the story

Just because a bug shows no workaround, it doesn’t mean you can’t fix it. It just means that the engineer who submitted the bug wasn’t able to.

Now I can finally get around to what I was originally trying to do today, getting scripted PXE installs of ESXi 4.1 working.Similar Posts:

• Cisco Nexus 4000 Blade Switch
• Cisco introduces the C-Series Rack Servers
• Cisco Unified Computing System Quoting and Configuration with Netformx
• Where was Colin in 2010?
• Cisco EMC and VMware partneship VCE VBlocks Acadia and the Partner Ecosystem

--Colin McNamara

Fixing UCS Config Failures due to local disk config requirements

VBlock Infrastructure Packages

VBlock infrastructure packages are pre-configured bundles that are sized to support specific workloads. These packages are available to run both on the customer site, as well as in a hosted (cloud) facility. If you have been listening to anything that has come out of VMware in the past couple years, it has been centered around the unification of private and public clouds. VBlock is a building block of this integrated cloud.

The VBlock infrastructure packages are offered in “bundles”. These bundles are numbered 0-2 at the time of writing.

VBlock 0 is an entry level package supporting 300-800 virtual machines. This is built on Cisco UCS, EMC Celerra Unified Storage, VMware vSphere and the Nexus 1000v.

VBlock 1 is a mid level package supporting 800 – 3000 virtual machines. This is built on Cisco UCS, Cisco MDS, EMC Clarion, VMware vSphere and the Nexus 1000V

Vblock 2 is a high end package supporting 3000 – 6000 virtual machines. This is buit on Cisco UCS, Cisco MDS, EMC Symmetrix V-Max, VMware vSphere and the Nexus 1000V

Integrated Pre-Sales, Service and Support – Fighting the skill silo

The defining factor in the successfully sales and deployment of virtualization infrastructure has been cross platform knowledge and experience. Storage, Network, and Virtualization vendors, as well as partners have struggled to attract and train engineering and sales forces with this cross functional skillset. Partners who have engineering teams with skills that cross these functional areas have seen success even in this down economy. Cisco EMC and VMware are smart enough to recognize this trend and have linked sales teams at the hips in engagements. Nothing makes this more apparent than John Chambers himself addressing Field Sales in the VCE webcast and requiring that these teams coordinate and act as one cohesive unit.

Acadia

Cisco, EMC and VMware have jointly funded a venture called Acadia. This venture, initially staffed at 120 employees is charted with the development and validation of cross platform solutions. They are focused on a “build operate transfer” model for service providers and large enterprise customers. The target date for Acadia’s launch is Q1 2010.

Partner Ecosystem

This was my biggest worry about this release. Does Cisco, VMware and EMC funding Acadia mean that they are going to go direct and bypass their channel? The party line is no, that all three partners will still utilize the channel to sell and distribute the VBlocks. An interesting new twist however is that there is not one master partner certification to sell “validated” VBlock solutions. To participate a partner has to be certified at reasonably high levels with all three partners to have the ability to register and sell deals under the VBlock mantra.

What hasn’t been clearly answered is what happens when a workload is moved to the “cloud”. Does that go through the channel? What if that cloud infrastructure is built onsite but maintained by Acadia? It sounds like we have to wait till January 2010 to get that answer. In the end time will tell whether Cisco will hold true to the success they have found in the channel, or whether Cisco will end up in an MBA case study of what not to do.

Want to learn more ?

Enterprise Strategy Groups write up

Scott Lowe – VCE quick thoughts

Joint Offering Portal – Privatecloud.com

Chad Sakac – an insiders view of VCE

Cisco Press Release on VCESimilar Posts:

• Nexus 5020 – Consolidated 10 Gig Ethernet and 4 Gig Fibre Channel
• VMworld 2009 Schedule
• Cisco’s Cloud Computing Offering
• Where is Colin ? Passing the VCP exam (VMware Certified Professional)
• Cisco Nexus 5020 and 5010 FCOE video ordering guide
• New features in VMware 3.1

--Colin McNamara

Cisco EMC and VMware partneship VCE VBlocks Acadia and the Partner Ecosystem

What does this mean?  In Cisco’s view of the world this means supporting the transport of Fibre Channel, Fibre Channel over Ethernet, iSCSI, NFS and CIFS in a scalable and dependable fashion.

What is the Nexus 4000?

The Nexus 4000 is the 5th release of the Nexus line of switches (counting the UCS 6100 as a release).  This switch fits in the blade center form factor. It is intended to be used in the place of the Catalyst 3000 and 3100 series blade switches. It is a full featured Nexus switch, very similar to it’s big brother the Nexus 5000.

What protocols will it support?

In keeping with Cisco’s vision of a Unified IO platform in the data center the Nexus 4000 will support Converged Enhanced Ethernet (CEE) (yes, they finally caved on the naming) as well as providing the same reliable transport of iSCSI, NFS, and CIFS that you get with the Nexus 5000.

What blade centers will it work with?

Cisco is playing close to the chest announcing what blade server vendors will support this product.

My initial gut reaction was that HP would not be supporting this product, however I just saw that HP is OEM’ing the Nexus 5020. It would make sense that they would support the Nexus 4000 in their C Class blade centers, though only time will tell.

IBM however has been very supportive of integrating Cisco technology, as well as OEM’ing the Nexus 5000 switch in their portfolio. I fully expect the Nexus 4000 to be supported in the IBM BladeCenter platform, though again I cannot confirm.

Dell also has resold Cisco blade switches, and although they do not OEM the nexus 5000 they have been large proponents of the Nexus solution and unification of IO workloads throughout their platforms.

Is it the same as a Fabric Extender?

The Nexus 4000 is not a Fabric Extender. What is the difference? A Fabric Extender is a really efficient multiplexer. While using a Fabric Extender the main goal is vast simplification. What you end up with is a dumbed down remote line card that provides simple, fast services to your access layer. This is great for most uses, however there are instances where you need to provide richer services. A full function switch like the Nexus 4000 is appropriate in this case.

What does it run?

The Nexus 4000 runs NX-OS, Cisco’s data center switching operating system. This is the fourth release of what was previously named SAN-OS which ran on Cisco’s MDS line of SAN switches. This operating system is shared between the Nexus 7000, 5000, 4000, 1000v,UCS Fabric Interconnect and MDS line of SAN switches. Now you can have a consistent operating system platform from your data center core, all the way down through your blade switches and into your virtualization layer.

When will it be available?

Just like when the 3000 and 3100 series blade switches got announced, we are going to have to wait on the individual server manufactures to announce support at their own pace. My gut feel says we will be waiting a couple months for units to get out, and for the vendor certification process to complete. Though with business picking back up, this product may get out sooner.Similar Posts:

• Simplifying your Data Center with Cisco’s Nexus 2000 Fabric Extender (FEX)
• Cisco Nexus 7000 DataCenter switch released – Welcome to DataCenter 3.0
• Nexus 5020 – Consolidated 10 Gig Ethernet and 4 Gig Fibre Channel
• Cisco NX-OS 4.0 | Next Generation Internet Operating System
• Cisco introduces the C-Series Rack Servers
• Humor inside the Nexus 5000 switch fabric architecture

--Colin McNamara

Cisco Nexus 4000 Blade Switch

You may notice that I am using a tool called Netformx. You may ask – since this is a Cisco product, why aren’t we using the Dynamic Configuration Tool or the MultiLine Configurator? The answer that was given to me was that UCS requires a bottom up configuration. It requires that you start with the type and number of systems, and then work your way up to the amount of Chassis, FEX’s, links and Fabric Interconnects that are required. All of the workflows in Cisco’s existing tools require a top down approach. Until the new configuration workspace is released from Cisco, Netformx is your only option to quote any UCS product.

.

Thank you for taking the time to watch this walk through. If you found this helpful, please feel free to leave a comment or ping me on twitter.Similar Posts:

• Twitter Updates for 2008-06-05
• Cisco Nexus 5020 and 5010 FCOE video ordering guide
• Vote for my VMworld presentation – #3221 Built to fail (shameless pandering)
• Cisco NX-OS 4.0 | Next Generation Internet Operating System
• Simplifying remote site security with Cisco’s new video surveillance modules on the ISR
• Cisco Nexus 4000 Blade Switch

--Colin McNamara

Cisco Unified Computing System Quoting and Configuration with Netformx

“it looks like one of the key features not on the list of components for the California boxes is going to be a red discount pen”

Timothy references sources who have obtained a price list and shared it with “El Reg” . I wish Timothy would have contacted an actual Cisco Unified Computing System Advanced Technology Partner, because any partner that is involved in the launch could have explained to him the concepts of List price (List), Manufacturers Suggested Retail Price (MSRP), and Purchase or Buy price.

In this article I want to dispel the myths of server and network manufacturer pricing, demonstrate the true cost of building a data center with blade systems, and at the end provide a cost comparison between legacy server vendors options and Cisco’s Unified Compute System.

First, lets go over some the basic concepts of vendor pricing. At the end of this you should understand the difference between list price, manufacturers suggested retail price, and purchase price.

List Price

List price is a high level number that Cisco publishes weekly in its global price list. The purpose of this list price is to provide a uniform price list across all product sets that Cisco offers. The most important thing about list price is NOBODY EVER PAYS LIST PRICE. Let me repeat that again NOBODY EVER PAYS LIST PRICE. Are we clear? This is similar to list price on a car on the car lot. All list price provides is a starting point where a Cisco partner and a customer can negotiate a common discount and end up with something close to (generally at or below depending on technology type and yearly spend) MSRP.

Manufacturers Suggested Retail Price (MSRP)

This concept is something that anyone who has purchased a car before is familiar with. The number that is on the window of the car when you look on the lot is list price. The first number the dealer brings up lower then sticker is MSRP. Depending on the popular of the product, the competition in that particular space, and the negotiating power of the customer you will either pay that price, or some percentage below. For example if you are buying one new car you may have the negotiating power to get the price to drop 5% off of list. If you are buying 200 new cars (say a fleet) you have significantly higher negotiating power, and you may be able to drop the price by 15% of of list price.

In Networking Sales MSRP is significantly less then list price. A good exercise to see what this number is, is to find a device, say a WS-C3560E-12SD-E (3560 with 12 Gig SFP ports and 2 10 Gig ports) in the Global Price List. You have access to this at any partner level at www.cisco.com/dprg . (my point here is that this is no big secret). As of Friday June 12 2009 the LIST price for this product is $19,995.

Now take that same part number - WS-C3560E-12SD-E and pop it into your google search window. Within the top four links I found this product for $12,434.15 . This price is for  pure fulfillment, with no value added consulting or design work from you local Cisco partner.

If you do the quick math, this price difference is equal to 38% off of list price. Come to your own conclusions, but it would be safe to say that this could be considered MSRP for Cisco products.

Purchase / Buy Price

Buy price is just that, the price at which the customer purchases (buys) the product. This is can be at MSRP, or if the customer is buying significant amounts of hardware at a time, or if there is a “special” (programs and incentives) going on the number could be slightly lower then MSRP.

Percent off of list differences between legacy server vendors and networking vendors

This is where the biggest confusion is coming from. Legacy server manufacturers  have set their list prices much closer to MSRP then networking vendors (remember, MSRP is the price where most customers purchase at).

Why is this? In the networking space, vendors have historically created their own processors, ASICS and boards. This means that the sales discussions are feature to feature. It also meant that you had to have a conversation with the networking vendor or networking partner to properly size your network devices and get a quote – which is around MSRP, not List price.

In the legacy server space, especially the majority of the x86 server space, the market has been essentially commoditized. E.G. – You can buy an intel based server with X amount of memory and hard drives that will perform roughly equally from any of the main manufacturers. That made it much easier for a sever admin to just pull a price off of the web and compare. So what the server vendors ended up doing is setting their list price  only slightly above MSRP.

What this translates to is the list price, between legacy compute vendors and Cisco will be drastically unequal. What is equal is MSRP, or the generally accepted purchase price by common customers.

Why did Cisco set the list price of UCS higher then the legacy server manufacturers?

For the vast majority of its sales, Cisco relies on what is called the channel model. This means that Cisco partners with local Value Added Resellers (VAR’s) who sell Cisco’s products and then provide consultative services to design and implement them in customer networks. Most customers who purchase any regular amount of Cisco product either have a general expectation that they will buy Cisco product at a certain percentage discount off of list and sometimes the partner and customer have entered into purchasing contracts which require that all Cisco product is provided at a specific discount off of list price.

If Cisco decided to set the List price at a small percentage lift over MSRP, this would cause a problem for the entire channel. This would be especially hard for any customer who had a contract to buy product at a specific discount. What would happen is contracts would have to be renegotiated, which generally takes months and is about as fun as pulling teeth.

The second reason for setting list price the for compute the same as list for network is quoting. Right now, if you buy hundreds of different Cisco devices through a reseller it is very likely that the discount is going to be the same across all products. This makes the mechanics of sales much simpler, because you don’t have a lot of math in the quote (this can cause errors). On the customer side, having one set discount makes it much easier to compare quotes and to ensure that they are getting the best deal possible. In short, sticking with Cisco’s current list pricing structure benefits both the customer and the partner.

Now that we have set the record straight on list price, MSRP, and Buy price, lets take a deeper dive into what components make up a blade system powered data center. And then we will compare the price structures of both.

Components of all Blade Systems

Blade Server – The compute blade where commodity silicon elements such as the CPU and RAM are housed. As of writing this article, the latest high performance blades from all major server manufactures support two xeon 5500 processors (Nehalem) and DDR3 memory.

Mezzanine cards – These cards take the place of PCI-e cards in a rack form factor server. In a blade system these provide data network and storage network connectivity. They attach to the blade itself via proprietary connectors that implement either PCI-e 8 or 16 lane connectivity at the time of writing. In some cases other functions such as IO accelerators can also be attached in the mezzanine card form factor.

Blade Enclosure – This is functionally a tin can where eight to sixteen blades are placed. It also is used to provide a centralized power distribution fabric, as wells as slots for interconnections of data and storage network devices.

Data Network Modules – These are effectively ethernet switches that have been miniaturized to fit into the tight confines of a blade enclosure. Classically they have provided 1 gig connectivity to the servers, and 10 gig to the distribution layer, however with Nehalem processors and VMware there is a move towards presenting 10 gig connections to the server, and multiple 10 Gig connections into the distribution layer.

Storage Network Modules – The local disk in a blade server is classically anemic. To provide higher IOPS (input outputs per second) to disk, Fibre Channel connectivity is extended by taking SAN fabric switches and miniaturizing them to fit into the blade enclosure.

Data Network Distribution – If you have multiple blade enclosures there is a need to connect them together at a reasonably high bandwidth. To serve that need a variety of 10 Gig distribution switches are provided from all server manufactures at varying cost and performance levels.

Storage Network Distribution – Along the same lines of the data network distribution, SAN fabric switches have to aggregate up to a SAN distribution layer, or if the installation is reasonably large a “director” class SAN switch. This allows all the blade enclosures to see the same storage network, as well as providing for deterministic storage network performance as you scale out.

Management Infrastructure – All manufactures have a need to manage and monitor all of the devices that comprise their blade system. Many manufactures have multiple management modules per blade enclosure.

Comparison of Costs – Cisco vs Legacy Server Manufacturers

The funny thing, is that many people have assumed that Cisco’s Unified Computing System will be priced higher then legacy server manufactures products. In my mind this is because they associate higher quality with higher price (basically the Mercedes vs Kia discussion). Here is something that will shock you - it costs less to buy an entire blade system through Cisco then to buy from the legacy server manufacturers.

When people hear this, they are puzzled. How can two server manufacturers, who buy their CPU’s from the same company (Intel) and their memory from the same fabs end up with different prices? The answer is elegance in engineering. Lets go through each of the elements of a blade system infrastructure and find out where the costs are. More importantly lets look at where Cisco has innovated to provide higher performance at a lower cost.

Dollars and Cents – How much is the cost difference

I worked up two quotes recently. These quotes included all elements required to build an end to end blade system using both legacy server manufactures devices, and using Cisco’s Unified Computing System. I have broken out two scenarios.

8 blade servers - Cisco wins with a savings of 11%

In this scenario the cost of servers and enclosures were fairly equal. The cost savings started racking up as storage and data networking devices were included, as well as base management software was taken into consideration.

320 blade servers - Cisco wins with a savings of 31%

With 32o blade servers the same cost savings seen in the 8 server scenario were amplified. Economies of scale translated into significantly less devices being required to support the individual compute blades. This resulted in 31% savings compared to the legacy server manufacturers.

Summing it up

Cisco has entered into a highly competitive server market by taking an elegant approach to its blade systems. This approach lowers the purchase price of the UCS through reducing the amount of components compared to legacy server manufacturers. I know that there is a lot of misinformation flying around, and I hope this helps to set the record straight on the pricing of Cisco’s Unified Computing System.Similar Posts:

• Cisco Nexus 4000 Blade Switch
• Simplifying your Data Center with Cisco’s Nexus 2000 Fabric Extender (FEX)
• Cisco introduces the C-Series Rack Servers
• Nexus 5020 – Consolidated 10 Gig Ethernet and 4 Gig Fibre Channel
• Is your network ready for Cloud Computing with Virtual Infrastructure 4?
• Cisco’s Cloud Computing Offering

--Colin McNamara

Confusion about Cisco UCS pricing – Setting the Record Straight

The Server Landscape

If you take a look at most enterprise and commercial customers data centers, you will notice a trend of larger fixed workloads running on two rack unit servers (very commonly HP’s DL380), and newer virtualization workloads consolidated onto blade center form factor servers (commonly c7000 class blade systems, and soon Cisco UCS B-Series blades).

However when you go to a remote site where the compute needs are much smaller, you tend to see a few 1 and 2 rack unit system (DL360 or DL380). Why is this? There are a couple reasons, but the most pressing reason is cost. In a blade system, even if you virtualize there is a tipping point where it costs less to install blades and use centralized storage then it costs to use rack form factor servers with local storage. I find that tipping point is generally between five and 8 blades.

If you are a small remote site, or small to medium size business you may not have the compute needs (especially with virtualization) to push you over that tipping point into the blade center form factor. In that case, a few rack optimized servers provide the optimal return on investment for that smaller site.

Taking a closer look at Cisco’s C-Series Servers

Cisco UCS C 200 M1 -

Effectively this is a clone of the B-200 M1 blade in the B series UCS chassis with the addition of two PCIe slots and two more SFF SAS/SATA drives..

The C 200 M1 is a 1 rack unit form factor server (pizza box). It supports a dual port 10 gigabit converged network adapter. two Xeon 5500 series processors, four small form factor SAS drives, 12 dimms for a total of 96 Gigabytes of memory.

Cisco UCS C 210 M1 -

The C 210 is a 2 rack unit form factor server, with the same CPU and memory architecture as the C 200. What has been added is 3 additional PCIe slots (for a total of 5). There is also support for up to 16 SFF SAS/SATA drives.

Out of all the C-Series servers I think this will be the most popular. The extra local disk and PCIe slots will be extremely tempting. For example if this server was populated with 750 Gig SFF SATA drives and augmented with some Fusion-io cards you could have 6 Terabytes of raw disk inside this server. An end user could install Open Filer or iSCSI Enterprise Target and have a pretty respectable NAS head. The other possibility is someone will notice that the Palo adapter can be used as a FCoE target, and use a couple of these as backends for FC storage. (This FC target functionality is mentioned in Silvano Gai’s book).

Cisco UCS C 250 M1 -

Effectively this is a clone of the B-250 M1 blade in the B series UCS chassis with the addition of five PCIe slots and eight SFF SAS/SATA drives.

The C 250 M1 is a 2 rack unit form factor server. It supports a dual port 10 gigabit converged network adapters. two Xeon 5500 series processors, eight small form factor SAS/SATA drives, and 48 dimms for a total of 384 Gigabytes of memory.

This server utilizes the same catalina chipset for memory expansion that it’s cousing the B-250 M1 utilizes.  The ability to aggregate low cost memory plus the PCIe slots to insert solid state I/O acceleration make this a prime candidate to business intelligence / data warehousing workloads as well as Electronic Design Automation.

When can I buy these?

Putting any new product line into production is a monumental effort that many of us take for granted. My gut feel is that Cisco will focus on satisfying demand for the B Series Unified Compute System first, and once manufacturing has hit their stride with the UCS Cisco will start production of the C-Series. In short, I’m  expecting the first C-Series servers to roll off the line at the end of 2009, and  meaningful availability of the C-Series in the first quarter of calendar year 2010.

How do I integrate these into my network?

This is a question that is bound to come up. Cisco’s C-Series servers can integrate directly into your 10 Gig enabled network. Now, to get the best bang for your buck, you should ideally connect these into a pair of Nexus 5000′s to converge your storage and data networks into simple 10 Gig Data Center Ethernet links.

You may however have site without 10 gig enabled switches. In that case, there are multiple PCIe slots in these servers so we should be free to utilize 10/100/1000 adapters. Then when these sites have the need to move to 10 Gig, the server will be capable of supporting that level of connectivity.

My Perspective

At the end of the day, Cisco is now a server manufacture. Just like the HP and IBM, Cisco has to provide platforms that meet customer needs. While the B-Series Unified Computing System is an outstanding platform, it shares similar entry costs that other blade systems have (the need to purchase chassis and interconnects first) which can server as a barrier for smaller server installations. By introducing a 19″ rack form factor line of servers that share many of the I/O and memory benefits of the B-Series servers, Cisco is directly answering the needs it’s customer base by providing a form factor that can scale across all size of customer installation.

Want to learn more?

Cisco Unified Computing System Overview – colinmcnamara.com

UCS C-Series Rack Servers: A New Path to Unified Computing – Cisco.com

Cisco unveils rackmount servers for UCS - datacenterknowledge.comSimilar Posts:

• Cisco Nexus 4000 Blade Switch
• Nexus 5020 – Consolidated 10 Gig Ethernet and 4 Gig Fibre Channel
• Simplifying your Data Center with Cisco’s Nexus 2000 Fabric Extender (FEX)
• Cisco Nexus 5010 released
• Simplifying remote site security with Cisco’s new video surveillance modules on the ISR
• Usability features in Cisco’s Nexus 7000

--Colin McNamara

Cisco introduces the C-Series Rack Servers