Since I last wrote, we have put out an RFP for bid and have many return submissions to go through. At this time, we have weeded the total proposals being entertained down to 4 teams. These teams are currently doing a re-write of their proposals to reflect the new budget constraints.

Since the budget has been reduced, it goes without saying that we will not be accomplishing as mush as we had hoped for. For this first year phase 1 network refresh, this what is currently being looked at:

* Wired and Wireless gear for the Welcome Center
* Wired and Wireless gear for the East Street Apartments
* Wired and wireless gear for the President’s house
* Wireless gear for Harriett House
* Wireless gear for Adam’s
* Wireless network backbone to tie all wireless AP’s together
* Some mechanism to provide guest access over wireless
* Extending the network core router/switch to accommodate all the new buildings

Currently, the new proposals are coming in from our 4 selected vendor teams and these will be reviewed to select the best plan, as well as the best team that we (IT) feel we should partner with.

Once the team has been selected, it will be time to get busy. We have a lot to do and not much time to get it done.

To see a list of projects that NSG is currently working on, it’s status and what is yet to be done for those projects, look for an upcoming post from me.

We have made some movement on getting the Blade Server into the IWU data center. It has been approved this year and we are in the process of determining the spec’s of the gear before we put it on order.

The next step would be to get the gear in and get it setup for virtual servers. Once this has happened, we will need to make the servers that will be running on this machine. This may sound a bit simplistic, but it does require time and a bit of forethought. One of the issues at hand is, what servers are we going to put on this Blade and what OS’s are we running them on.

Currently, there are a lot of ideas as to what servers/services should go onto this new machine AND, as you know, things never go according to what you had envisioned. But, the likely candidates as of now would be LDAP, SMTP, Titan, Ariel, ElecRes and a few of the extremely old servers in the data center.

It is our hopes to get this in before the Fall semester and start turning over services to this machine. It will be in our (IWU’s) interest to move slow with this and make sure that we do not oversell this hardware and it’s capabilities. We will need to monitor this server after every service install and through peak usage times to get an idea of just how many services we can put on this hardware.

Is the technology proprietary? Yes, each blade system takes its own type of blades which are only made by the manufacturer. There really aren’t any 3rd party parts for a blade system. That being said, the average lifespan for a blade series is 12 years.

Do blades have a higher redundancy but bigger cost of failure? With blade technology everything is duplicated a few times. It would take a large number of non-trivial failures to bring a blade system down. These failures could happen, but to compare it to our current architecture, it is in every way possible for the motherboard in Sun to fail on the same day that the motherboard in my fails while setting fire to Triton. This could honestly happen. Then what? We need expensive parts for three different systems each of which could be on back order and would require some time to replace. How do you decide which core system is most important. With a blade the type of catastrophic failure that would bring it down is of the same likelyhood, but, with things linked up this way, if we do suffer a serious enough failure, the parts all go in the same place. There is no triage conflict. And because all the parts are in the same place we could afford a much more extensive hardware contract - 4 hour support instead of next day. And with that we would probably still be saving money.

Currently, the Blade technology is the best solution out there that I have seen that will allow us to use hardware for an extended period of time. The Blade chassis is populated with “Blades”. These blades are like mini, powerful computers and, once placed in the chassis, become part of a resource pool. You need more resources for your virtual servers, buy another Blade. Don’t get me wrong here, there is still hardware to purchase on an ongoing basis. Blades are not a “one time” purchase and all your computing needs are taken care of forever. What they do well is; they share resources among all your virtual servers so that your resources are used more efficiently. You will have to purchase hardware less often.

I guess I did not address redundancy very well. So…. I will now.
We would not think about implementing this technology if there were not a bit of redundancy in the hardware. Here is what I mean:

POWER:
The Blade server that we have looked at has a variety of options as to how many power supplies it can have. We have spec’d one out that has fully redundant power. If a power supply should go out, there is another to take it’s place. This is about as good as it gets.

As far as building power, IWU has recently purchased a central UPS unit for the data center. If the building power should go out, this UPS will keep the data center powered until the CNS emergency generator takes over. There is just one caveat here though, that is, the blade server hardware runs on 220V 3 phase power and I would have to check to see what it would take to put that on the UPS. Currently, that is an unknown. Edit: this is already all set and on the UPS.

HARDWARE:
By it’s nature the Blade is hardware redundant. If a disk drive fails, there are others there to take up the slack. “What about the data on the failed disk”, you ask? Almost all our servers in the data center are running what is called RAID. This allows data from any one disk that fails to be rebuilt and restored across all the other disks. Once a new disk is put back in, all the other drives rebuild the new disk. It is pretty cool, but that is as far as I will go into explaining that.

Since resources are all pooled together, having memory or a CPU go bad is really kind of trivial. If this should happen, the other pooled resources take the load until we replace the failed card.

I think it is very important to add here that if you are going to serve any user disk space, or any application disk space that has large growth potential, then an attached SAN (an appliance that holds many disk drives) would be needed.

NETWORK CONNECTIVITY:
It is very seldom that a network card fails in a server, but it can happen. The Blade has redundant network connections too. The unit we have looked at has options for Gig and 10Gig network connections. The good thing about this is, when we go to the next generation of network speeds (10G), this unit is ready.

SERVER/APPLICATIONS:
So far we have just addressed hardware redundancy, but the beauty of this technology goes beyond the hardware. Blades will allow us to set up redundant services too. Here is an example:

We have a new service that is needed here at IWU. We try not to implement services that are going to be used heavily by the university without preparing a backup server in case that service should go down. So, this requires 2 separate pieces of hardware to run the service and the backup to that service on. With Blades, it is the same box!

Not only is that a huge cost savings, we can also build test environments on the Blade. Let’s say that there is a huge upgrade to the Banner service. In the past (and even now) we have had to handle this in one of two ways:

1.) Put the upgrade on the production server
2.) Build a brand new server for the upgrade (very expensive)

With Blades, we can copy the Banner virtual server over to another virtual server, let’s call it Banner Test Server. We could then install upgrades, patches and config changes to the Banner Test Server before we ever think about touching the production Banner server.

I think I am getting farther into this than I need to, so, I will reel myself in.

COSTS:
Blades do bring a lot to the table. On the flip side, there is an “upfront” cost that has to be dealt with. To start ourselves off with a Blade server, without a SAN, could cost between 20 - 30 thousand. But, that does get you 10 cup holders, 8 speaker premium surround sound and a sun roof.

If we needed to attach a SAN, you could double that. However, if we keep our eyes on the bigger picture, what we save is immense. We don’t have to keep purchasing individual servers, individual service agreements and backup servers. We will not be using desktop grade computers for university core applications. We keep our power and cooling costs down, well, as much as we can and still have a data center. We gain the ability to replace one Blade card at a time making upgrading our hardware a bit easier on the pocket book.

I want to make sure that all know that the amount of administration for these servers is not decreased via the use of Blades. The amount of maintenance is still the same, just the hardware requirements are minimized.

I hope this answers some of your concerns.

Also, how does the blade architecture compensate for redundancy? Doesn’t consolidating into virtual servers mean that there are fewer hardware points of failure, but the ones that are left are Really Big?

http://www.youtube.com/watch?v=DO9ZWDaLLxA

It looks like my U of I Netfiles account is still active.

It serves webpages just fine.

http://netfiles.uiuc.edu/fmmiller/www

I’ll be happy to let you see how the U of I’s Xythos implementation works from a user’s perspective.