Cisco had recently added new Fabric Interconnect to their product line up which provide more choice to their client to be consider for their deployment. Previously there were only 6120XP and 6140XP in place for the Fabric interconnect architecture as part of Cisco UCS. The new Fabric Interconnect 6248UP which provide 32 ports FCoE with additional 16 ports expansion module on unified port available which support FCoE, LAN and SAN FC with appropriate module.
While introduce new Fabric Interconnect, the IO Module for UCS Blade Chassis had been further enhance with 2208XP which provide 80Gbps throughput per IO module, and allowed up to 160Gbps per chassis. This option will allow users to provide higher throughput to the blade infrastructure which require more than 80Gbps per chassis.
Read more »
Went through a marathon troubleshooting with my client for the past 1 week to figure out the reason why a cluster failed in place and it could not easily rebuild back after 1 of the node evicted. We had gone through the process to re image both nodes and rebuild from scratch. Follow exactly the best practices and run through the cluster validation without any error. While we try to form the cluster, the system keep provide an unknown error which do not share much information from log. It just keep telling you that the node is not reachable or unauthorized due to security setting.
After few nights of troubleshooting, I was running out of clue. Came to the sudden, I accidentally search the computer name in AD under the category of Users object group, and I found an user account been created in AD with the same name as we define on the cluster name. I was wondering whether this could caused the confuse to the system. Therefore, I was suggesting to remove the user name temporally as it was not use at the moment and tried to reform the cluster. Guess what, the cluster form up as it needed to be in less than 1 minutes. We were so happy to end the marathon troubleshooting every night well and we were also very pissed off with the bugs we face here.
Read more »
NIC teaming is common practice in Data center to avoid link drop due to hardware failure on NIC or Switches. While choosing the teaming policies or architecture consideration, Network Architecture and configuration is the most important thing for you to look at. I will suggest all of us to consider the layer 2 and Layer 3 configuration before jump in to the server teaming policy as different configuration on the network side could caused an outage to the network as well as the servers which both are always relate together.
Beside that, strongly urge all the users to look in to the application tier as well, which there are some applications may not support ip-hashing which could end up confuse the switches and create looping. Most Servers require NIC teaming just for HA but not aggregation through put, if that the case, choose wisely what you need rather than what is good to have to prevent unnecessary down time to the infrastructure.
Read more »
Cisco Unified Computing System had been in the market for more an 18 months now. I am considered 1 of the pioneer members who had sold couple of units to our client locally. It had been proven as 1 of the best blade system with fabric architecture to the client and reliability & quality had able to satisfied the client for more adoption worldwide.
Recently there are public announcement that Cisco UCS is rank #3 in worldwide blade server market. This is really great news for Cisco Team who had put in a lot of efforts and partner who are involve to make this success. Of course the client who had adopted to Cisco UCS should be impress and happy with the value that UCS had brought on which transform the traditional open system computing technology for the day to day operation as well.
If you had not tested or tried the Cisco UCS before, I will strongly urge you to keep an eye open and give it a try on that.
Read more »
I had some discussion internally with my buddy today about this topic mainly due to some challenges been faced by the client as their current active DNS and Domain controller is hung once a while due to unknown issue. The current domain controller are hosted on the Windows server 2005 which was not the matured product that came to market more than 5 years ago. They do have a new VMware vSphere 4 Infrastructure in place now.
The question posted by my buddy was; how we could move or migrate the same state of the virtual machine to a physical or virtual without impact to the production environment? My answer to him was big NO as this is Domain controller and not a normal application or database server migration.
We went through some due diligence and found that certain machines had been pointing to this DC for the DNS server preference IP. In this case, we may need to ensure Preferred DNS server IP on the client are require to change.
Read more »
