Some interesting blog posts came about yesterday with the start of this article on ESXi Scratch Partition Best Practices on the VMware ESXi Chronicles Blog. This VMware KB article includes more technical detail as well as a resolution. In the KB article, it states that many SAS and Boot From SAN(BFS) installations will NOT create a default scratch partition at install due to the possible shared nature of both the SAS and BFS architectures.
Both Scott Lowe and Forbes Guthrie followed up with articles based on previous ESXi installation experience. Their great articles started me thinking one step further. Since I tend to think of servers in terms of Cisco UCS these days, doesn't this mean that ALL Cisco UCS (and most other vendor servers as well) will not have a default scratch space because most installations are now either SAS or BFS?? If this is the case, shouldn't this KB article represent a new best practice for ALL installations of ESXi in the future as well as all installations in the past??
UPDATE: Jeremy Waldrop shared with me that many of his UCS BFS installs include the scratch space by default and Scott Lowe shared on his blog that sometimes his didn't. Looks like we have a "feature" on our hands where sometimes the scratch partition is created and sometimes it isn't. My recommendation to everyone is to make sure you check for the partition post installation until we gather more information on the subject.
Does this need to be a best practice? I'm sure the answer here will be "it depends." It depends on how much of a difference not having the scratch space is to you. Read the KB article carefully and understand what you are losing by not having a default scratch partition. From reading the article, it seems worth it to me. What are your thoughts?
Showing posts with label HP. Show all posts
Showing posts with label HP. Show all posts
Wednesday, April 27, 2011
Monday, March 15, 2010
Cisco UCS QoS vs. HP Flex-10 vNICs in VMware
This post will be more conceptual than technical. I recently was asked how Cisco's UCS & HP's Flex-10 network design approaches affect vSphere designs. Even though the industry is moving towards a unified 10GB fabric, there are different ways to move data through this big "pipe" and still ensure/prioritize delivery. As you would guess, Cisco and HP approach this problem very differently. Cisco takes a network centric approach to the problem and HP takes a server centric approach to the problem.
HP's Flex-10
HP Flex-10 takes a 10GB connection and carves it up into multiple virtual NICs. The size of the "pipes" can be turned up and down to match the amount of bandwidth needed for the NIC. Think of it as placing smaller pipes in the big 10GB pipe. This approach is great for vSphere admins because the virtual switches in vSphere can be configured to look just like they did with a bunch of 1GB links into the server. The transition to this technology is seamless for the vSphere administrator. I'll borrow a diagram from Barry's awesome article on Flex-10. If you haven't read it, please do!
Cisco UCS's QoS
Cisco UCS uses a method known as Quality of Service (QoS). Most of us "server guys (and gals)" have no idea what this is. Here is how I have come to understand it. If this is wrong, please correct me. Network traffic is given a priority and this priority kicks in WHEN THERE IS CONTENTION on the network. So, instead of smaller pipes inside a large pipe, you have more of a priority system in place to guarantee certain levels of service. Think of this as a FLOOR model. You can have as much as you want as long as everyone else gets their minimums (they get their quality/guarantee of service). If something needs to spike and there is room, it can spike and then return to normal. Here is a diagram of our Cisco UCS with traditional switches. This isn't 1000v but you get the idea. As you can see, two big 10GB pipes into the virtual switches instead of smaller pipes into multiple virtual switches.
As the vSphere administrator, this looks very different from my old multiple 1GB links into my multiple virtual switches!
What is the down side to this method?
That is a very good question. I can't seem to find any documentation on how to actually do this yet. I'm sure there is a Cisco internal doc somewhere but I haven't found anything public that lays out the hardware that is needed (do I need 1000v or Palo for this, can I use a CNA and the standard switches?) nor have I found a "cook book" that documents how to properly make QoS happen in a vSphere environment. I'm sure this will happen in time and if you have a link, please leave a comment!
Which is better?
HP's Flex-10
HP Flex-10 takes a 10GB connection and carves it up into multiple virtual NICs. The size of the "pipes" can be turned up and down to match the amount of bandwidth needed for the NIC. Think of it as placing smaller pipes in the big 10GB pipe. This approach is great for vSphere admins because the virtual switches in vSphere can be configured to look just like they did with a bunch of 1GB links into the server. The transition to this technology is seamless for the vSphere administrator. I'll borrow a diagram from Barry's awesome article on Flex-10. If you haven't read it, please do!
What is the down side to this method?
The down side to this approach is by placing multiple pipes within the larger pipes, you have now placed a CEILING on how much data can pass through that particular pipe. Let's say you present a 1GB vNIC to vMotion and during a vMotion it would be to your advantage to have access to more bandwidth. Too bad, 1GB is all you will ever get.
Cisco UCS's QoS
Cisco UCS uses a method known as Quality of Service (QoS). Most of us "server guys (and gals)" have no idea what this is. Here is how I have come to understand it. If this is wrong, please correct me. Network traffic is given a priority and this priority kicks in WHEN THERE IS CONTENTION on the network. So, instead of smaller pipes inside a large pipe, you have more of a priority system in place to guarantee certain levels of service. Think of this as a FLOOR model. You can have as much as you want as long as everyone else gets their minimums (they get their quality/guarantee of service). If something needs to spike and there is room, it can spike and then return to normal. Here is a diagram of our Cisco UCS with traditional switches. This isn't 1000v but you get the idea. As you can see, two big 10GB pipes into the virtual switches instead of smaller pipes into multiple virtual switches.
As the vSphere administrator, this looks very different from my old multiple 1GB links into my multiple virtual switches!
What is the down side to this method?
At this time, QoS for Cisco UCS appears complex to configure and represents a shift in thinking for the vSphere administrator.
How is the QoS implemented for Cisco UCS and VMware?
That is a very good question. I can't seem to find any documentation on how to actually do this yet. I'm sure there is a Cisco internal doc somewhere but I haven't found anything public that lays out the hardware that is needed (do I need 1000v or Palo for this, can I use a CNA and the standard switches?) nor have I found a "cook book" that documents how to properly make QoS happen in a vSphere environment. I'm sure this will happen in time and if you have a link, please leave a comment!
Which is better?
It depends on your point of view and the comfort level of your team. I can easily see advantages to both approaches. One is easier to implement, the other appears to be a more elegant (but complex) solution. Cisco has once again brought a disruptive technology to the table that can't be ignored. What are your thoughts?
Sunday, February 7, 2010
Why VMWare's VMmark Scores Have Become Useless
Well, it was bound to happen. Every time an industry benchmark standard comes out, the manufacturers eventually figure out ways to "cook the books". I've seen a LOT of FUD flying around from both HP and Cisco lately about VMmark scores and I have been asked a lot of questions about both platforms. After a taking close look at the scores, I'm ready to throw in the towel.
Before I go further, take a look at the VMmark, 8 cores scores posted here. You will see the Cisco B200 Blade is on top right now (of the major vendors, I don't count Fujistu, sorry Fujistu) with 25.06 and the HP is next with the BL490 24.54. A couple of points:
What is the difference between 25.06 and 24.54. Maybe 1-2%? Honestly, not much if they both meet your needs and you won't be pushing them to their limits. I'm sorry but that is within a margin of error and/or the test could be reconfigured by everybody to meet the score. At the end of the day both of them will meet your needs very well and the title of "fastest blade" means nothing!
Take a look at the memory in the details for both of them. Both the HP 490 and B200 use 96GB of memory. Where is the B250 with the larger memory footprint? Where is the BL490 with either 144GB or 192GB of memory? You will also notice that the HP BL490 memory is running at 1333Mhz and the B200 is running at 1066 Mhz. Since there is no big jump in performance numbers the VMmark score isn't memory bandwidth bound or HP would have had an advantage. I suspect (although I don't have proof) that the VMmark score is now CPU bound and any memory above 96GB doesn't help the scores. I further think (again, no proof) that the test isn't pushing the maximum memory bandwidth because there is no change from 1333 Mhz to 1066 Mhz. It would be interesting to see if the drop to 800Mhz by HP would be noticed in the scores.
Take a look at the EMC Storage section on the Cisco benchmark. They are using an EMC CX-240 with SSD drives! There is NOTHING wrong with this, SSD's are coming down in prices but they provide a clear, known advantage to the IOP's numbers that could easily be the sole reason for the 1%-2% increase. I'm willing to bet that if HP used the same storage configuration, they would produce similar scores.
Cisco is using the Q-Logic CNA for the tests. Why didn't they use the Palo card? I suspect because it isn't "technically" released yet but that is the benchmark everyone wants to know about.
What I'm saying is that both HP and Cisco make great products and they will go to great lengths to make the other look bad. They are so close to each other from a VMmark score perspective that any clear difference can't be shown with the current test. Don't make a purchase based on a score!
Before I go further, take a look at the VMmark, 8 cores scores posted here. You will see the Cisco B200 Blade is on top right now (of the major vendors, I don't count Fujistu, sorry Fujistu) with 25.06 and the HP is next with the BL490 24.54. A couple of points:
What is the different between really really fast and really really really fast??
What is the difference between 25.06 and 24.54. Maybe 1-2%? Honestly, not much if they both meet your needs and you won't be pushing them to their limits. I'm sorry but that is within a margin of error and/or the test could be reconfigured by everybody to meet the score. At the end of the day both of them will meet your needs very well and the title of "fastest blade" means nothing!
Both Cisco and HP sell "big memory solutions" but they are no where to be seen!
Take a look at the memory in the details for both of them. Both the HP 490 and B200 use 96GB of memory. Where is the B250 with the larger memory footprint? Where is the BL490 with either 144GB or 192GB of memory? You will also notice that the HP BL490 memory is running at 1333Mhz and the B200 is running at 1066 Mhz. Since there is no big jump in performance numbers the VMmark score isn't memory bandwidth bound or HP would have had an advantage. I suspect (although I don't have proof) that the VMmark score is now CPU bound and any memory above 96GB doesn't help the scores. I further think (again, no proof) that the test isn't pushing the maximum memory bandwidth because there is no change from 1333 Mhz to 1066 Mhz. It would be interesting to see if the drop to 800Mhz by HP would be noticed in the scores.
Cisco is using an EMC SAN with SSD's on the back end!
Take a look at the EMC Storage section on the Cisco benchmark. They are using an EMC CX-240 with SSD drives! There is NOTHING wrong with this, SSD's are coming down in prices but they provide a clear, known advantage to the IOP's numbers that could easily be the sole reason for the 1%-2% increase. I'm willing to bet that if HP used the same storage configuration, they would produce similar scores.
Why didn't Cisco use the Palo card?
Cisco is using the Q-Logic CNA for the tests. Why didn't they use the Palo card? I suspect because it isn't "technically" released yet but that is the benchmark everyone wants to know about.
What am I trying to say here?
What I'm saying is that both HP and Cisco make great products and they will go to great lengths to make the other look bad. They are so close to each other from a VMmark score perspective that any clear difference can't be shown with the current test. Don't make a purchase based on a score!
Saturday, February 6, 2010
HP Blades Offer a 16GB DIMM, With a Catch
I found out something interesting on Friday, HP is offering a 16GB DIMM in their blades! My first thought was wow, that sucker is gonna be expensive (and it is!). But, after that I started to dig deeper as I always do, I found out something that is slightly disturbing. The 16GB DIMM is actually a quad rank DIMM and not a dual rank DIMM and it is only 1066Mhz speed. Many of you are saying... So what?
Well, this actually can make a difference from a design perspective. Take a look at the Memory tables in the BL460 and BL490 QuickSpecs and you will see what I mean.
HP BL460 G6 QuickSpecs
HP BL490 G6 QuickSpecs
Most of the DIMMs sold by the major vendors are dual rank and 1333Mhz Speed. Let me explain the concept of ranks first. According to the Intel Nehalem architecture, you can only have 8 ranks per memory channel. Each memory channel consisted of either 2 or 3 DIMMs per channel. I have more information on memory layout in this article I wrote on Scott Lowe's site awhile back. I never really discussed ranks because it was a limit you didn't hit. You were only using either 4 ranks (2xdual rank dimms on the BL460) or 6 ranks (3xdual ranks on the BL490). Quad rank DIMMs blows the math out of the water. You can only put 2 on a memory bus to generate 8 ranks. This means the BL490 no longer brings extra memory capacity to the table. Both the BL460 and BL490 top out at 192GB with the 16GB DIMMs.
Memory speed is the next issue. If you are running a memory bandwidth intensive application, you will expect about a 7% boost in performance by keeping the memory speed at 1333MHZ instead of dropping down to 1066Mhz. Because the maximum speed of the 16 GB DIMM is 1066Mhz you will never reach a 1333Mhz speed. Furthermore, populating both slots in the memory channel (the max of 12 DIMMs) drops the speed from 1066 Mhz to 800 Mhz. The performance drop from 1333 Mhz to 800 Mhz is over 30%!! This leads to an interesting trade off of memory capacity vs bandwidth speed.
While I applaud HP for thinking outside the box and bringing a 16GB DIMM to market, don't assume it is the same DIMM as the others. Remember, "One of these is not like the others...."
Well, this actually can make a difference from a design perspective. Take a look at the Memory tables in the BL460 and BL490 QuickSpecs and you will see what I mean.
HP BL460 G6 QuickSpecs
HP BL490 G6 QuickSpecs
Most of the DIMMs sold by the major vendors are dual rank and 1333Mhz Speed. Let me explain the concept of ranks first. According to the Intel Nehalem architecture, you can only have 8 ranks per memory channel. Each memory channel consisted of either 2 or 3 DIMMs per channel. I have more information on memory layout in this article I wrote on Scott Lowe's site awhile back. I never really discussed ranks because it was a limit you didn't hit. You were only using either 4 ranks (2xdual rank dimms on the BL460) or 6 ranks (3xdual ranks on the BL490). Quad rank DIMMs blows the math out of the water. You can only put 2 on a memory bus to generate 8 ranks. This means the BL490 no longer brings extra memory capacity to the table. Both the BL460 and BL490 top out at 192GB with the 16GB DIMMs.
Memory speed is the next issue. If you are running a memory bandwidth intensive application, you will expect about a 7% boost in performance by keeping the memory speed at 1333MHZ instead of dropping down to 1066Mhz. Because the maximum speed of the 16 GB DIMM is 1066Mhz you will never reach a 1333Mhz speed. Furthermore, populating both slots in the memory channel (the max of 12 DIMMs) drops the speed from 1066 Mhz to 800 Mhz. The performance drop from 1333 Mhz to 800 Mhz is over 30%!! This leads to an interesting trade off of memory capacity vs bandwidth speed.
While I applaud HP for thinking outside the box and bringing a 16GB DIMM to market, don't assume it is the same DIMM as the others. Remember, "One of these is not like the others...."
Monday, January 25, 2010
Cisco UCS vs IBM and HP - Where are the Brains?
UPDATE: Thank you to everyone for the great comments! Please look for the updated sections that I have highlighted below. I have learned a lot from everyone and I will continue to update this as more information rolls in. I welcome any and all comments. Thank you!
As many of you know, my company recently acquired some very nice lab gear for customer demonstrations and proof of concept work. Many of my peers already know the UCS systems inside and out but I really need hands on to "get it".
As I learn the UCS system I will share my experiences here. My perspective is to share what is different (good and bad) about UCS compared to the IBM and HP Blade products. Before anyone asks, I will only be covering IBM and HP. If you have additional experiences, please share them in the comments. I also have no intention of picking sides. At the end of the day I sell and support all of the above systems and I can get the job done with all of them. They all have their own unique strengths and weaknesses that I intend to highlight.
In case you aren't familiar with what UCS is, I suggest you take a look at Colin's post over on his blog. He does a great job putting all the pieces together. Plus, I'm going to steal a few of his graphics. (thanks Colin!!)
A UCS system consists of one or more chassis and a pair of Cisco 6120 switches that provide both the 10GB bandwidth to the blades as well as the management of the system. The last part of that statement is the key to understanding how UCS is currently different from the competition. I define management in this example as the control of the blade hardware state. This includes identification, power on, power off, remote control, remote media, and the virtual I/O assignments for MAC and WWPN's.
By moving the management from the chassis level to the switch level, the solution can now take advantage of a multi-chassis environment. Here's a simple modification of Colin's diagram to illustrate this point.
(UPDATED!) What are the limitations to the Cisco UCS model?
Someone asked in the comments how this scales. Honestly that was a great question. I'm still learning Cisco and I was wrapped up in making it work. Let's take a look at that. Currently you can have up to 8 chassis per pair of UCS Managers (Cisco 6100's). That number will increase in the upcoming weeks and eventually the limit will top out at 40. But, the more realistic limitation is either 10 or 20 depending on the number of FEX uplinks from the chassis to the 6100's unless you are using double wide blades. If you don't understand what that means right now, don't sweat it. I'll be posting about that shortly.
(UPDATED) What if you need to manage more than the chassis limitations today?
If you need to go above the limit, then you have two options. The first option is to purchase another pair of 6100's to create another UCS System and they will be independent of each other. The second option is provided by BMC software. This will allow you to manage more chassis and the solution also provides additional enhancements. I admit I know little to nothing about the product so I'll just post the link from the comments and you can take a look. The brain mapping for that would like this.
How do you get into the brains?
Each 6120 has an ip address and both 6120's are linked together to create a clustered ip address. The clustered ip is the preferred way to access the software. The clustering is handled over dual 1GB links labeled L1 and L2 on each switch. They are connected together like this:
Cisco uses a program to manage this environment called creatively enough, Cisco UCS Manager or UCSM. To access UCSM, point a browser at the clustered ip address. Once authenticated, you will be prompted to download a 20MB java package (yes it is java, yuck!). Here is a pic of ours with both chassis powered up.
Notice that both chassis are in the same "pane of glass". This allows for management of all the blades from one interface and the movement of server profiles (covered later) from one chassis to another within the same management tool.
How does this compare to IBM?
IBM is a two part answer.
IBM Part One - Single Chassis Interface in AMM
IBM uses a module in each BladeCenter chassis called the Advanced Management Module (AMM). There can be up to two AMM's in each chassis. If there are two AMM's, one is active and the other is passive. They share the configuration and a single ip address on the network. In the case of failure of the primary, the passive module becomes active and communication resumes on the original ip address. The AMM will control power state, identification, virtual media and remote control out of the box. Virtual I/O (both WWPN and MAC) is an additional purchased license in the AMM. The product is called the Blade Open Fabric Manager (BOFM). I don't know if BOFM supports 10GB but I know it supports 1GB ethernet and 2/4GB FC. This is what it would look like with brains in place:
As you can see, each chassis is managed individually. In my experience, this is the most common configuration I have seen.
IBM Part Two - Multiple Chassis Management with IBM Director
IBM does have a free management product called IBM Director that can pull all this together into a single pane of glass. The blade administration tasks are built into the interface and virtualized I/O is handled through the Advanced BladeCenter Open Fabric Manager. Advanced BOFM is a Director plug-in and is a fee based product. Logically it would look something like this:
The downside to this solution is you now have another server in your environment to manage. In my experience Director is a little flaky at times but I also haven't tried the newest version which is a redesign to address many of the issues.
How does this compare to HP?
HP is a two part answer as well. I haven't implemented HP's Virtual Connect over multiple chassis so I will ask that if you know this answer and can throw some links my way, please do and I will update this section.
(UPDATED!) HP Part One - Single Chassis Interface in Onboard Administrator (OA)
HP's approach is very similar to IBM. HP's management modules are called the Onboard Administrator and there can be a maximum of two in each chassis. HP is different from IBM because each module requires an ip address. At any given time one ip address is active and one ip address is passive. If you access the passive module on the network, it will tell you that you are on the passive module and instruct you connect to the active module. Like the IBM AMM, the OA will control all basic functions such as power state, identification, virtual media, and remote control. Like IBM, HP has a separate product for virtual I/O called Virtual Connect. Unlike the IBM and Cisco products, HP's Virtual Connect is implemented at the I/O module level. The only way to achieve virtual I/O is to purchase the HP I/O modules. HP's brain mapping is a little different than IBM because you can connect up to four chassis into one interface. Since you probably won't be able to power more than four chassis in a rack, think of it as consolidation at the rack level.
(UPDATED!) HP Part Two - Multiple Chassis Interface in HP Insight Tools
After you get to four chassis, HP Insight Tools need to be brought in to fulfill the needs. Based on the comments below it appears that two products will fit the bill. To manage the chassis and blade functions you will need Insight Dynamics VSE Server Suite and to manage the virtual I/O you will need the Virtual Connect Enterprise Manager product. Both the Insight Dynamics VSE Server adn the Virtual Connect Enterprise Manager is fee based.
Summary
(If you made it this far, I'm impressed!) Cisco's approach feels very "up to date". I really like the idea of not having to add another server (and additional fees for virtualized I/O) to the environment for management of the products. By moving all of the management centrally to the switches you are better able to see the environment and implement a multi-chassis/multi-rack solution. IBM and HP offer a similar solution that has grown over time but the roots of the interface are in single chassis/rack management. But, at the end of the day both IBM and HP offer a centralized management solution.
Thoughts? Concerns? Please leave a comment!
As many of you know, my company recently acquired some very nice lab gear for customer demonstrations and proof of concept work. Many of my peers already know the UCS systems inside and out but I really need hands on to "get it".
As I learn the UCS system I will share my experiences here. My perspective is to share what is different (good and bad) about UCS compared to the IBM and HP Blade products. Before anyone asks, I will only be covering IBM and HP. If you have additional experiences, please share them in the comments. I also have no intention of picking sides. At the end of the day I sell and support all of the above systems and I can get the job done with all of them. They all have their own unique strengths and weaknesses that I intend to highlight.
In case you aren't familiar with what UCS is, I suggest you take a look at Colin's post over on his blog. He does a great job putting all the pieces together. Plus, I'm going to steal a few of his graphics. (thanks Colin!!)
A UCS system consists of one or more chassis and a pair of Cisco 6120 switches that provide both the 10GB bandwidth to the blades as well as the management of the system. The last part of that statement is the key to understanding how UCS is currently different from the competition. I define management in this example as the control of the blade hardware state. This includes identification, power on, power off, remote control, remote media, and the virtual I/O assignments for MAC and WWPN's.
By moving the management from the chassis level to the switch level, the solution can now take advantage of a multi-chassis environment. Here's a simple modification of Colin's diagram to illustrate this point.
(UPDATED!) What are the limitations to the Cisco UCS model?
Someone asked in the comments how this scales. Honestly that was a great question. I'm still learning Cisco and I was wrapped up in making it work. Let's take a look at that. Currently you can have up to 8 chassis per pair of UCS Managers (Cisco 6100's). That number will increase in the upcoming weeks and eventually the limit will top out at 40. But, the more realistic limitation is either 10 or 20 depending on the number of FEX uplinks from the chassis to the 6100's unless you are using double wide blades. If you don't understand what that means right now, don't sweat it. I'll be posting about that shortly.
(UPDATED) What if you need to manage more than the chassis limitations today?
If you need to go above the limit, then you have two options. The first option is to purchase another pair of 6100's to create another UCS System and they will be independent of each other. The second option is provided by BMC software. This will allow you to manage more chassis and the solution also provides additional enhancements. I admit I know little to nothing about the product so I'll just post the link from the comments and you can take a look. The brain mapping for that would like this.
How do you get into the brains?
Each 6120 has an ip address and both 6120's are linked together to create a clustered ip address. The clustered ip is the preferred way to access the software. The clustering is handled over dual 1GB links labeled L1 and L2 on each switch. They are connected together like this:
Cisco uses a program to manage this environment called creatively enough, Cisco UCS Manager or UCSM. To access UCSM, point a browser at the clustered ip address. Once authenticated, you will be prompted to download a 20MB java package (yes it is java, yuck!). Here is a pic of ours with both chassis powered up.
Notice that both chassis are in the same "pane of glass". This allows for management of all the blades from one interface and the movement of server profiles (covered later) from one chassis to another within the same management tool.
How does this compare to IBM?
IBM is a two part answer.
IBM Part One - Single Chassis Interface in AMM
IBM uses a module in each BladeCenter chassis called the Advanced Management Module (AMM). There can be up to two AMM's in each chassis. If there are two AMM's, one is active and the other is passive. They share the configuration and a single ip address on the network. In the case of failure of the primary, the passive module becomes active and communication resumes on the original ip address. The AMM will control power state, identification, virtual media and remote control out of the box. Virtual I/O (both WWPN and MAC) is an additional purchased license in the AMM. The product is called the Blade Open Fabric Manager (BOFM). I don't know if BOFM supports 10GB but I know it supports 1GB ethernet and 2/4GB FC. This is what it would look like with brains in place:
As you can see, each chassis is managed individually. In my experience, this is the most common configuration I have seen.
IBM Part Two - Multiple Chassis Management with IBM Director
IBM does have a free management product called IBM Director that can pull all this together into a single pane of glass. The blade administration tasks are built into the interface and virtualized I/O is handled through the Advanced BladeCenter Open Fabric Manager. Advanced BOFM is a Director plug-in and is a fee based product. Logically it would look something like this:
The downside to this solution is you now have another server in your environment to manage. In my experience Director is a little flaky at times but I also haven't tried the newest version which is a redesign to address many of the issues.
How does this compare to HP?
HP is a two part answer as well. I haven't implemented HP's Virtual Connect over multiple chassis so I will ask that if you know this answer and can throw some links my way, please do and I will update this section.
(UPDATED!) HP Part One - Single Chassis Interface in Onboard Administrator (OA)
HP's approach is very similar to IBM. HP's management modules are called the Onboard Administrator and there can be a maximum of two in each chassis. HP is different from IBM because each module requires an ip address. At any given time one ip address is active and one ip address is passive. If you access the passive module on the network, it will tell you that you are on the passive module and instruct you connect to the active module. Like the IBM AMM, the OA will control all basic functions such as power state, identification, virtual media, and remote control. Like IBM, HP has a separate product for virtual I/O called Virtual Connect. Unlike the IBM and Cisco products, HP's Virtual Connect is implemented at the I/O module level. The only way to achieve virtual I/O is to purchase the HP I/O modules. HP's brain mapping is a little different than IBM because you can connect up to four chassis into one interface. Since you probably won't be able to power more than four chassis in a rack, think of it as consolidation at the rack level.
(UPDATED!) HP Part Two - Multiple Chassis Interface in HP Insight Tools
After you get to four chassis, HP Insight Tools need to be brought in to fulfill the needs. Based on the comments below it appears that two products will fit the bill. To manage the chassis and blade functions you will need Insight Dynamics VSE Server Suite and to manage the virtual I/O you will need the Virtual Connect Enterprise Manager product. Both the Insight Dynamics VSE Server adn the Virtual Connect Enterprise Manager is fee based.
Summary
(If you made it this far, I'm impressed!) Cisco's approach feels very "up to date". I really like the idea of not having to add another server (and additional fees for virtualized I/O) to the environment for management of the products. By moving all of the management centrally to the switches you are better able to see the environment and implement a multi-chassis/multi-rack solution. IBM and HP offer a similar solution that has grown over time but the roots of the interface are in single chassis/rack management. But, at the end of the day both IBM and HP offer a centralized management solution.
Thoughts? Concerns? Please leave a comment!
Monday, January 5, 2009
HP Proliant Server Power Calculator
Here is a link to a PDF describing HP Power
Here is the link to the HP Proliant Power Calculator
They are basically a bunch of spread sheets but it gets the job done.
Here is the link to the HP Proliant Power Calculator
They are basically a bunch of spread sheets but it gets the job done.
HP Blade QMH4062 iSCSI Card Boot Drivers
I have been playing around with HP’s new iSCSI card for the Blades, the QMH4062. It is a very nice card but I noticed there are no boot drivers for Windows on the HP website. There is a STOR driver and a MINI driver but no Boot or SCSI driver.
So, off to the Q-Logic website and bingo… Download the SCSI drivers, copy them to a floppy, hit F6 during the Windows install, and I’m off and booting with iSCSI. Here’s the link if you need it:
How to Reboot / Reset an HP Blade iLO2
Every once and awhile an iLO2 Remote Control session will get "stuck". By this I mean when you try to connect, it will say that there is a session already in progress. A reboot of the iLO2 will clear this state. To restart the iLO2, follow these steps.
- From the Web Administration page for the iLO2, you should be on the System Status tab by default
- Click Diagnostics on the left hand side
- On the bottom of this page is a Reset button for the iLO2
HP Blade iLo2 Mouse Lag & Synchronization Issues
Has anybody else ever seen really bad mouse lag and synchronization from the iLO2 Remote Control on an HP Blade? I have seen this a few times and the solution has always been to change a setting in the iLO2 settings for high performance mouse. It is normally set to auto-detect. I have found that changing it to enabled will usually correct this problem. Here are the steps to change this setting.
- From the Web Administration page for the iLO2, Click the Remote Console tab on the top
- Click Settings
- The first entry is High Performance Mouse, change this from Automatic to Enabled
Quick and Dirty Config of the HP Blade GbE2c Switch
This is more of a brain dump than an informative article. I recently had to put an IP address on an HP Blade GbE2c switch for a lab setup. The switch does BootP by default but we didn’t have this available and only one uplink out of the switch. It has been a few years since I worked on one but the last time I did this the switch would not accept an EBIPA address. So, here are the config commands:
- /cfg/sys/bootp to access the bootp settings, bootp must be disabled to apply an ip addressd to disable bootp/cfg/l3/if (interface number) - I used 21 in this case.
- 19 is the interface to the Onboard Administrator (OA)
- enter the ip, mask, etcena to enable the port
- apply to save to running configsave to save to flash memory
Maximum of Two 10GB Ethernet Adapters in HP Blades/Servers
Here is something interesting I came across earlier this year while trying to add a bunch of 10G cards into a DL580 server. It turns out that HP will only support a maximum of two 10G adapters in most systems. I have included the link below for more information from HP. As adapter cards increase in speed, we will have to consider bandwidth limitations such as this going forward.By the way, IBM has similar problems. I’m still tracking down some last second details on that one and I will post an IBM specific version shortly.
Not all 10G Cards are Equal
I found this out while configuring some 10G Ethernet cards for a customer recently. Be careful who makes your 10G cards. It turns out the NetXen 10G card (OEMed to HP, IBM and Others) has a hard limitation of only being able to address 32GB of system memory in the box. If the system has more than 32GB of memory, the card will start dropping packets.
My sources tell me there will not be a firmware fix for this at this time.To say this was a surprise to me is an understatement! I have never seen a card with a limitation based on memory before. IBM has pulled support for the card on the 3850 M2 model even though it is still a valid configuration in the configuration tools. I haven’t had a chance to check the DL580 but be careful if you are considering either of these boxes with the 10G card. Right now you will have to go 3rd party and your level of support may vary.
HP BladeSystem Power Sizer
In case you haven’t seen it, HP has a great power sizer for the BladeSystem that is available here. You will need an HP Passport ID to get into the site. The tool is very easy to use and configure. I like the ability to customize the utilization level to choose a value other than 100%. When the calculations are complete an idle amount is given as well as a utilization level.
There are three different types of reports the tool will produce: A printable version (that you can print to PDF), a Doc version, and an Xls version. Of the three different versions, the doc version is the most complete and looks the best for customer consumption.
One pet peeve though… HP, please remove the shopping list at the end with list prices!! Let’s face facts, list prices are useless to most people and this should be a technical report, not a sales pitch! Other than that, it is a very easy to use tool, check it out!
VTP Mode and Service Config for HP and IBM Cisco Blade Switches
Some time ago Scott Lowe wrote up a great article on how to set up link state tracking for Cisco switches on both IBM and HP Blades.
I have set up a number of the switches lately and I wanted to add two more commands that I consider default settings on the switch to make your life easier before deployment. You will want to check with the network admin once you are on-site and probably modify them again to meet customer requirements.
vtp mode transparent
no service config (on the HP Cisco 3020 switches)
VTP Mode Transparent will place the switches into a mode where they will not participate in the VTP Domain to pass VLAN information to other Cisco switches in your organization. This allows you to “sandbox” the switch at the customer site and make sure everything plays well before you place the switch in the VTP domain. This prevents VTP problems if your VTP number is higher than the customer’s number, which would push your VTP settings out to the rest of the organization, providing they didn’t change the default VTP domain name. Sounds crazy, but it can happen.
No Service Config on the HP Blade Cisco switches will disable the “smart” feature in the switch where it will broadcast for a TFTP service to configure itself. If you don’t want/need this feature, simply enter this command in the config and it will go away. You will know you have this feature turned on if you are getting the following error in the switch logs and console on a regular basis:
%Error opening tftp://255.255.255.255/network-confg (Socket error)
%Error opening tftp://255.255.255.255/cisconet.cfg (Socket error)
%Error opening tftp://255.255.255.255/3620-confg (Socket error)
%Error opening tftp://255.255.255.255/3620.cfg (Socket error)
HP Blade Quad Port Nics and VMWare
If you have a need for a quad port NIC on the HP c-Class Blades on ESX, make sure it is the NC325m and not the NC364m. The NC325m is certified for VMWare ESX and the NC364m isn’t.
The NC325m is Broadcom based (I believe) and the NC364m is Intel based.Link to the Quick specs for the cards and the VI3 Compat Guide:
A big thanks to Don at my company for helping out with this one!
Subscribe to:
Posts (Atom)