This blog post was written by Mark Schlack, vice president of editorial, TechTarget.

What kind of network works best for high-density virtual machine (VM) farms? Can you run OLTP databases on VMs? If you put your email server on a VM, what should you beware of?

It’s hard to find answers to those kinds of questions, and answers often start with “It depends.” But the questions are important, indeed critical, for some shops as they scale up. For that reason, we are launching an e-zine this week called Virtual Data Center.

If you’re looking for a deeper dive into some of the thornier questions about virtualization and the new data center being built around it, this is for you. Take the first issue: It features an article by a veteran integrator of Oracle and VMware that makes the case for putting production databases on virtual machines. The article gets into what you need to do to make that work. Similarly, a second article gets into creating a storage architecture for VM farms.

Our goal is to create, magazine-style articles that can go further than tips or blog posts in analyzing these issues. It’s free and will appear six times a year. Each issue will address an application area and a technology issue. The authors will be experts, frequently with direct hands-on experience.

We’ll also follow up articles with blog posts and survey research that’s part of each article. You can take our survey on virtual databases here as well as our survey on storage in virtual environments.

San Diego, Calif.-based Verari Systems has joined Sun Microsystems and Rackable Systems, Inc. in the data center mobilization trend with its new Verari FOREST containerized data center.

These mobile data center offerings address the need for space and low cost power. Companies without room for more servers can buy one of these containers for less than it would cost to build a brick and mortar data center, fill it with servers and storage, and plop it down in an area where electricity costs are low - like an abandoned coal mine in Japan.

Case in point, Verari’s FOREST container can house up to 1400 blade-based compute servers or nearly 12 petabytes of blade-based storage using Verari’s new BladeRack 2 X-Series platforms in the modular unit.

Sun’s containerized data center, project BlackBox, is in a standard metal shipping container — 20 feet long, eight feet wide and eight feet tall — and can house about 250 single unit rack servers. Introduced in March 2007, Rackable Systems Inc.’s Concentro is a 40 foot by 8 foot shipping container that houses up to 1,200 of Rackable Systems’ rack-mount DC powered servers and up to 3.5 petabytes of storage. The company came out with a denser mobile data center called ICE cube in October. IBM came out with one, the Scalable Modular Data Center in July 2007.

Who first invented the idea of a mobile data center? Probably Google, which patented the containerized data center in October, and which reportedly has been using them for its own purposes since long before Sun or anyone else did. Whether the patent will cause issues for other vendors has yet to be seen, as no infringement suits have been filed yet.

But for all this activity, mobile data centers aren’t exactly selling like hotcakes; Sun announced its first customer in June 2007, and Rackable hasn’t disclosed any, other than saying they have some.

On Feb. 19, Symantec Corp. announced several new products in its Solutions for Windows portfolio. In essence, the new products—specifically Symantec Backup Exec 12 and Symantec Backup Exec System Recovery 8 extend backup and recovery support to Windows Server 2008, and as such are the first products to receive logo certification from Microsoft.

Analyst Lauren Whitehouse of the Enterprise Strategy Group said that in and of itself, the latest announcement from Symantec is significant because it places the Cupertino, Calif.-based vendor at the front of the pack in terms of Windows Server 2008 backup and recovery support. “Microsoft has made under-the-hood changes to [Windows Server 2008] transactional file systems, which affect how backup is done,” Whitehouse said. “Symantec does have first-mover advantage,” she added, particularly in terms of getting its products into the hands of channel partners.

Once Windows Server 2008 hits the market and gains traction in data centers, only time will tell whether Symantec converts its channel-partner advantage into dominant market share. If nothing else, Symantec has mustered its internal resources to focus on its mainstay storage-related business now that it has gotten out of the application performance management (APM) space.

In January, Symantec announced plans to sell its APM business to Vector Capital, a private equity firm in San Francisco. (The deal is scheduled to be finalized around March 1.) Under terms of the sale, Vector will create Precise Software Solutions Inc.,  which will assume responsibility for the development, marketing and sales of Symantec’s various i3 products for enterprise applications, database and storage systems, and middleware.

According to Henri Isenberg, vice president of Symantec’s application management group, the i3 products just didn’t fit into the company’s portfolio. As something of a redheaded stepchild, the APM business wasn’t getting the attention required to turn it into a flourishing business. (Symantec does not report revenues for product lines and declined to provide figures for the i3 business.) Plus, the line had taken a toll on its parent. “The APM business diverted attention from our main line of products,” he said.

By selling its APM products, Symantec, Isenberg added, will be in a better position to focus on four main product areas: backup and recovery, storage management, disaster and recovery; and data center automation. And the new products in the Solutions for Windows group certainly fit into the backup-and-recovery category.

Isenberg added that a major challenge for Symantec in selling APM products is how to targeting buyers who typically are part of an organization’s application or database administration groups. Symantec’s other products target buyers in the data center. “Just from a sales-efficiency standpoint, we can now focus on our core products,” he said.

Yet by ditching its APM business, Symantec forfeits a potential area of growth. According to SearchDataCenter.com’s 2007 Purchasing Intentions Survey, the top area for systems management software investment — of 344 respondents, 59% cited it in the survey — is performance management. (Of course, APM software is only part of the performance management category.) By spinning off its i3 product line — and effectively conceding defeat in the APM market– Symantec could lose some business to rival CA, a company that maintains a presence in backup and recovery as well as APM.

David Russell, vice president of storage technologies and strategies at Gartner, isn’t overly concerned about the effect of Symantec’s APM sell-off on the long-term prospects of the company. “This is a natural evolution,” Russell said about Symantec’s move to abandon the APM market. “As a growing portfolio company, you place your bets, and some work out and some don’t.”

For his part, Russell thinks the latest additions to Symantec’s portfolio will have particular appeal for large Windows shops, which should position the company to move higher up the software stack. “One of the value propositions of the new products is how Symantec can integrate and leverage the rest of its portfolio,” he said. For example, the backup and recovery products now integrate with Altiris, Symantec’s asset management product that has, in Russell’s words, “a significant customer-installed base.”

So by bailing out of one market, Symantec hopes to muster its resources to gain traction in another: 24% of respondents in SearchDataCenter.com’s survey said asset management was among the top two areas of systems management software in which they plan to invest.

IT folks adopted technologies like message boards, SMS messages, email, chat protocols, web logs, RSS, and micro-blogging long before they were widely adopted. How can the data center manager put these communications channels to use as disaster recovery tools? The simple answer is “use them.” However to use them successfully is not that simple. This is part two of the column Communication: A neglected key to surviving a data center disaster.

“How can you tell an engineer is an extrovert?”

“They look at your shoes instead of their own when they talk to you.”

Yes, it is a funny stereotype, and like all stereotypes it has a kernel of truth. Engineers, technical people, geeks, whatever term you want to apply to us (I say “us” because I certainly fall on this side of the dividing line) share that particular trait to a certain degree. We tend to be thinkers and analyzers, drawn to interacting with machines. When we have something to say it is frequently seen as blunt. However, that does not mean that technical people are not capable of being great communicators.

Quite the opposite in fact: We tend not to speak until we are certain of what we say. Additionally we embrace communications technology and put them to use long before they become mainstream. Think about the history and adoption curve of these recent technologies: message boards, SMS messages, email, chat protocols, web logs, RSS, and micro-blogging. What sort of people used these technologies before they were widely adopted? That’s right… us.

How can the data center manager put these communications channels to use as disaster recovery tools? The simple answer is “use them.” However to use them successfully is not that simple.

First you have to choose the appropriate tool for this external communications channel. In some instances email may be the best, in others a web log with an RSS feed may be the better choice. It may not even involve a “high tech” solution, as it can also be something as simple as a welcome/status message on your phone system, or even a “scoreboard” hanging above your cubicle. The key is to pick something that works within the context of your organization, and most importantly, will be effective in touching the greatest number of your users or customers with the least amount of effort.

All the same considerations you consider when designing a critical system have to be taken into account, when you make this decision. It must be able to function in a highly reliable fashion, even during an outage. It must also have a secondary and even tertiary backup system in order to continue to function in the case of an emergency that disables your primary system.

Next, and this is the critical step, you have to use it. Not just as harbinger of doom, also make it the teller of your tales, the bulletin of the boring, the messenger of the mundane. Use it constantly to inform of what is happening within your facility, your network, your systems, even your staff. Announce every scheduled maintenance interval, every successful circuit installation, the delivery of new equipment, everything.

This accomplishes two things. First it gets you and your staff in the habit of updating your external communications channel. Something happening? It gets communicated. It is critical that this becomes an ingrained habit, something is happening? Relay the status as well as investigate. Making progress? Update the status, and keep working on it. If one staff member is not directly involved in the activity, then they can certainly be the updater of information via the external communications channel.

Secondly, and most importantly this trains your users and customers to look to the channel for all data concerning your data center status. If you have set an expectation among all your users and customers about how they learn what is going on within your realm, then when the going gets tough, whether dealing with an outage, or executing a major facility migration, or whatever circumstance throws your way, then you can keep them informed. Informed users are satisfied users. Remember that paradigm shifting conclusion from part one: Awareness is more important than uptime.

Your users and customers will tolerate incidents of downtime, but ONLY IF they are aware of them, and kept informed as to what is happening, and what is being done to restore things to an up state. By keeping them in a state of constant communication, even of mundane day-to-day operational matters, you build their trust while you keep them aware. The payoff comes when you have that big project or that unplanned outage and rather than being assaulted from multiple directions via multiple channels asking you for status, your users and customers refer to your now well-established external communications channel.

In the event of a large project — a data center migration, for example — you can use your communication channel to provide a far-ahead warning of what is going to happen. You can provide details of what is going to be done and how it will be done. You can elaborate on schedules, fall-back plans, contingencies, and expected results. You can announce reminders in the days and hours leading up to the start of each segment. You can post after-action reports of the successful, and perhaps unsuccessful moves. You can announce the ultimate completion of the project.

In the case of an outage, you can post updates and ETAs, you can use your channel to inform your users and customers of the root cause and what has been done to prevent the issue from recurring.

The purpose of this is to keep your users and customers informed. By remaining informed they will build trust in you. That trust is built through awareness of not only the critical, but the mundane and day-to-day. By staying aware, issues within your realm are perceived by your users in a positive light, and things which would have been seen as full blown train wrecks had they been unaware, are now likely to be seen as mere speed bumps.

A friend of mine once said “So long as you are not on the train, everyone likes a good train wreck.”

Since I am responsible for maintaining data centers I like to read as much about the occasional “train wreck” in my industry. I find it is beneficial to investigate events with the goal of learning as much from them as possible. As I’ve written about this before here on ServerSpecs, how else can we avoid pitfalls if we don’t observe those made by others?

Since that was written, a few high-profile outages have happened. And through coincidental relationships I was able to get a lot of information about a recent event involving one large Web hosting organization acquiring another, then relocating the servers to another facility. It devolved into the proverbial train wreck and multi-day outages ensued.

I have a very low-tech hobby, something that serves as a distraction from my high-tech daily life, namely maintaining and driving a classic car once owned by my father. Like any oddball pursuit, the Internet has become the glue that holds the far-flung devotees of this particular make and model of car together. I spend my evenings chatting with people all over the globe on a mailing list devoted specifically to this particular car. Through this group I met a person whose business website was hosted by the acquired in the above-referenced data center outage incident. After his website finally came back online I inquired about his experience as an affected party.

His reply underlined an important lesson for data center operators. All too often we focus on the problem at hand. Be it planning a migration, or bringing an outage to an end. Just as often we forget two important factors: Why we are doing it, and who we are doing it for. The “whys” are usually obvious to the point of being forgotten. However it is vitally important to identify those reasons why we do what we do. Even more important is that we communicate the reasons to the people our actions affect.

We look at “our” data centers and see infrastructure: Power, cooling and network systems to be maintained and managed. Servers are often seen as the object of all that care, but in reality those servers serve human beings. Those human beings could be defined as your users, your customers, or in many cases both. So really “our” data centers are not “ours” at all, they exist to serve our customers. We are not here to just manage a facility, we are here to manage a facility on behalf of our customers. They rely on us to do our jobs and keep the data center running.

Ask any user/customer about an incident like an outage or data center disaster they’ve lived through and one thing starts to become very clear: Awareness is more important than uptime. To those of us who live with the view that our paychecks depend upon uptime numbers, this is a startling concept.

If you ponder it for a while however it makes sense. Human beings are tremendously adaptable, provided we are aware of our circumstances. We can handle a disruption of our routine if we are able to plan for it, understand its duration, and can anticipate its affect. But, if handled in a fashion that they view as arbitrary, capricious, or inconsiderate those same humans become angry, bitter, and frustrated.

In my conversation with my acquaintance who survived the multi-day data center outage he summarized with thoughts like:

“Things they did wrong? I can only guess at half of it. Very little communication with customers. The move was postponed once, postponed twice, and abandoned, without explanation. By Monday, there was essentially no communication at all. Through the critical first 48 hours, the news was glowing. Through the next desperate 24, they were incommunicado. Then came the lies…the network is down because of a DoS attack, they always planned to move the servers, most sites are up, all sites are up, etc.”

Note the overall expression of frustration in those words, and the central theme of feeling ignored and abandoned. He had specific technical complaints about procedure, but note the most important theme recurring again in this statement:

“In an apparent attempt to limit network traffic, they brought up servers, but seem to have blocked certain protocols. Having a server up and running for e-commerce, yet being unable to control it with ftp, ssh, telnet, etc could have been a disaster within a disaster for some. E-mail service was among the last things that came back, so you couldn’t even communicate with your own clients.”

By not communicating with him he felt abandoned. By cutting off his means of explaining the situation to HIS customers the problem was compounded exponentially. While this is a single cited case, the same theme crops up again and again when you talk to the end-users affected by data center outages.

So what lessons are to be learned? How can data center operators deflect the ire of their customers while managing a disaster?

The simple answer of course is “Communicate with the customer.” Actually accomplishing that in the midst of crisis however is not as simple as it would seem. If you find yourself on that proverbial train in the process of going off the rails, how do you communicate on top of all the other, seemingly more important tasks? Technical people have often been stereotyped as poor communicators as well .

“All the social graces of a highly trained engineer” is an achingly funny phrase with plenty of truth buried within it. In part two of this article I’ll delve into that stereotype and elaborate on simple communication strategies for data center, or indeed any sort of IT Management role.

Last week we asked readers to offer up their best duct-tape data center fix-it stories, and the response was great. Data center managers are the real MacGyvers of IT. Here are some of the stories:

---

About four years ago, my small data center was located on the top floor of an office building. After we had been there for about four years, we noticed that the roof had developed a leak when some ceiling tiles started getting wet. At first, we thought it was possibly some condensation from the A/C unit that we used to keep the equipment cool and dry, but we could not find the problem. So, we called building management. Without telling us, they sent someone up on the roof with a water hose to see if they could find a leak. They did.

Fortunately, the new ceiling tile soaked up that water before it could run onto the equipment. Supposedly, they fixed it, but after another wet ceiling tile during the next rainstorm, we invested in some very nice bright blue tarps that we installed over the server racks to make sure that any other leaks were diverted from doing an damage. That turned out to be a really good investment since the leak got worse and we moved to another building before it was repaired. The data center tarps were formally listed as one of our risk mitigations in our Sarbanes-Oxley reporting that year.

DP

---

My example (seen at a client’s site) is an emergency drip tray made from plastic milk bottles to catch the run-off from an air-conditioning unit. The A/C unit had been installed and placed over a fully populated 42u rack by non-specialists. On a very humid night the base of the A/C unit started dripping and the run-off had nowhere to go but into the server rack. To keep the IT services running, the night shift put together a gutter made from plastic bottles to carry the fluid away from the rack and into a bucket.

CR

---

A number of years ago, at a previous employer, there was an electrical fire above the ceiling tiles in a server room. The room, in the past, was a large mainframe and DASD room. Since the company had been acquired by another company the mainframes and DASD were removed. The large room was relegated to a half dozen racks, of servers and network gear, for the existing building business units.Apparently the fire smoldered for quit a while and thanks to a closing shift security guard a major disaster was avoided. At that time there were no smoke senors “above” the ceiling tiles. Minor water damage, from the fire department, to unoccupied areas of the room was the result.

As part of the decommission of the mainframes and disks a decision was made to remove the Halon fire suppression systems. Water suppression was installed. However the server administrators were concerned about “water damage” if the system should be set off or happen leak. So they commissioned the Facilities team to install large plexiglass panels to be hung above the equipment racks, like an indoor roof. The panels were hung at an angle that allowed the water to run off on to the floor behind the racks.

So now they have a fire suppression system that will not suppress a fire that may begin in any of the equipment racks. That is of course until the flames get big enough and melt the plexiglass.

JJ

---

When a broken pipe led to opening all the raised floors in the data center, we discovered vermouth, gin, olives and very cold martini glasses.

CN

---

At our off-site location, we had a flaky NIC card connector in one of our main servers. It wasn’t the cable, we tried a number of them. The connector was loose, and would only work if the cable connector was pushed up a certain way.We didn’t have a spare, and since that data center is locked down, and you can’t bring in any equipment or parts that aren’t pre-authorized, we were stuck. We ended up having to fold up some stiff cardboard that fit perfectly between the server case and network cable to keep pressure on the connection. Worked like a champ until we could return and replace.

I would love to have photographed it, but taking pictures of shared cages is a no-no. Oh, and it was my boss that installed the solution.

DH

---

When I was at Sprint one of my data centers had “rolls” of plastic sheeting next to each server complex. What for? We were located in a basement right under a restaurant. It had frequent water overflow problems so in an emergency we would cover the servers with plastic until the water stopped dripping. I put together three business cases to move the data center, but never got funded.

RH

---

Funny thing happened as I was reading your email about Duct Tape Data Centers… I heard a shout out for duct tape and got the attached pictures as our IT Manager patched a torn link to our fix for a server room with inadequate AC.

WS

---

We could also call this “green computing”. I have been with a small software development shop for a couple of years now. My boss is one who believes that HVAC comes with the building, no matter how many servers we pack into an 8 x 10 room that is our “data center”.Since I’ve been with the company, we’ve managed to destroy four wall units that cool the server room, and prior to my arrival, I’m told that two more had been worked to death.The building owner put his foot down that he would provide no more wall A/C units and went to the trouble to remove the unit from the server room wall, leaving a hole in the wall approx 4′ by 2′. My boss also chose not to back down, and has not provided his own cooling unit.

We are located in suburban Chicago, so needless to say that since the A/C removal and the arrival of winter, it has become quite cold in that server room. My Dell servers now go into alarm as their internal temps drop to 4 degrees centigrade.

I was able to ask for and get a blanket (actually a used painter’s tarp) to cover the missing A/C unit hole in the wall - prior to that, I stuffed it with shipping foam and newspapers (what we call the “homeless mode”) of temperature regulation.Today was a warm day in Chicago - up to the mid 40’s, so I had to remove the tarp. I don’t know what’s coming, but spring is going to be interesting.

BF

---

At a hospital data center I managed many years ago (no photos, sorry) we had a roof that leaked directly on a large Tandem system. After repeated calls, attempts by building engineering to patch the leak, and a few very close calls with water dripping on the systems, the building engineers installed the obvious high tech solution; a bucket sitting on top of the ceiling tiles directly under the leak.Ahh, I see you thinking this through… what if the weight of the water in the bucket exceeded the strength of the ceiling tile? Disaster awaits!? No problem! Our brilliant engineering team cut a hole in the bucket not far from the bottom, taped a plastic hose from the bucket down through the ceiling tile into an “overflow” bucket on the raised floor behind the Tandem system. This worked much like the overflow tank for the coolant in your radiator. Then, when we saw water accumulate in the bucket on the raised floor, we’d empty both buckets and reconfigure for the next rainstorm.A $5 engineering marvel that protected our $1,000,000 system for well over a year before the roof repairs were properly executed.

PB

Have a duct-tape data center horror story? Tell your tale of woe or heroism in the comments.

At the Emerson AdaptiveXchange conference in Baltimore last week, disaster recovery consultant Pablo Gonzalez with Miami-based Crisis Management gave attendees advice on detecting vulnerabilities and assessing risks in their data centers. Gonzalez’s background is in emergency and terrorist response (he was part of the team sent to manage and mitigate the first recorded anthrax attacks against the U.S.

Cookie-cutter disaster planning

One of the biggest problems that Gonzalez sees is what he called “cookie-cutter planning.” This refers to copying a plan or using a template developed by someone else for a specific organization. “People will copy someone else’s plan, make some minor changes to adapt it and integrate it into their planning.”

He described an incident with one of his former clients. Part of the way through reviewing their disaster recovery plan he realized that it was the exact same plan that he had written for a different client, under different circumstances and unique issues. He said that each situation is almost always to unique for this type of planning. For example, access to airports, distances to infrastructure service providers, on-site employees, distance to recovery site are all going to be specific to each facility.

Prioritizing: Risk assessment measures

It might be tempting to identify everything in the data center as being critical or serving critical functions, but properly assessing the criticality and risk levels of equipment as it pertains to the business function is a crucial part of disaster recovery planning.

Gonzalez advocates using a couple different assessments schemes. CARVER is an old scheme dating back to World War II and stands for criticality, accessibility, recoverability, vulnerability, effect, recognizability. The idea is to list as many assets with descriptions as possible and rank them one to five in each point to help you determine the vulnerability of your data center as a system. This research from American Security International Corp. outlines how to apply CARVER to your disaster recovery planning.

What I found to be the beauty of the CARVER method is its scalability — you could assess each server or piece of equipment as its own system to determine its vulnerability in relation to the rest of the computing environment.

Gonzalez also discussed FEMA’s risk assessment worksheet. Disaster planning folks list their assets and rank each, one to five, based on probability, human impact, property impact, business impact, internal resources and external resources. The advantage of this method is that it forces planners to look more broadly at how the hazards affect operations, as opposed to CARVER’s straight-up analysis.

Response triggers

All the charts and worksheets in the world won’t help unless disaster recovery planners outline response triggers. This term refers to the events that enact the plan. Gonzalez gives the example of a fire starting. If there is no alarm that prompts people to move to the exits, go for the extinguishers, etc., then all of the plans that describe those procedures are moot. If a hurricane is making its way to your data center, someone needs to be charged with disseminating information and getting the plan enacted.

Don’t worry, there is help

Worrying about having the budget to develop a DR plan should not be an excuse. Gonalez said at the end of his presentation that free resources are available, especially for data centers whose criticality fall within federal jurisdiction, i.e. telecom and power companies. Though these resources may not take the form of money, FEMA and other DR-related agencies in the government can provide training for your data center folks and that the best way to access these resources is to contact local government offices and just ask.

Cathy Taylor is the IT operations supervisor at QS/1 Data Systems, which provides products and services to health care providers. Taylor offered some lessons learned based on her own experience with a natural disaster, which prompted her IT department to develop a disaster recovery (DR) plan.

---

What happened during the disaster; did you have plans in place?
In 2003, when Hurricane Isabel hit Richmond, Va., we didn’t have a disaster recovery plan in place. The BellSouth/AT&T central office there was completely flooded, so we lost all communication to our Richmond office. The hurricane made us realize the need to develop a plan. We only lost communication with the one office, and the office itself was not damaged. We also learned what problems were caused by losing communication to that office.

How should businesses ensure that their DR plans are up to date?
Making sure Express Metrix [Software Manager] is installed on every workstation and server is a must. We now make sure we have current backups of all key servers, along with off-site backups. We poll Express Metrix nightly, and all the information about the key servers is recorded in a Lotus Domino database. The information we get from Express Metrix includes the domain joined to, the IP address, manufacturer, model, serial number, number of processors, processor speed, memory, operating system, network adapter information, disk drive information and software installed. This information is replicated to two off-site locations. With this information, we could quickly replace any equipment we needed to.

A lot of companies have chosen to outsource the entire DR process. Have you considered this option?
No, this is not something we have considered or looked into. The argument against it would be cost and the lack of knowledge that an outside source would have of our business. The argument in favor of outsourcing would be that it takes the burden off employees to keep up with and make sure the plan is in place.

John Toigo, the keynote speaker this morning at Data Center Decisions, is not very high on VMware ESX. During his speech on disaster recovery planning, he said that he is testing VMware in his lab and found that it’s full of bugs.

Toigo, the CEO and managing principal of Toigo Partners International, added that he can’t understand why people continue “wallow” to VMware like “penguins on their bellies.”

“Put in a z/OS mainframe,” he said. “The costs are actually less than having a bunch of tinker-toy servers running shoddy software.”

Indiana University (IU) broke ground Friday on a new “tornado proof” data center in the twister-prone state.

Compared with the other 49 states in the U.S. by the frequency of tornadoes per square mile, Indiana ranks seventh, so it makes sense for it to spend the extra bucks on a sturdy facility.

The new 82,700-square-foot data center will contain IU’s supercomputer, as well as other IT infrastructure and mission-critical systems. In addition to disasters like tornadoes and storms, the data center is also being designed to withstand electrical damage, power outages and malicious damage, the university reported.

IU’s information technology systems have long been housed in fragile, obsolete old-school buildings.

“Our current data center has long been vulnerable to acts of nature and is insufficient for the needs of IU,” stated IU Vice President of IT Brad Wheeler.

The new data center is designed to withstand an F5 tornado. It provides almost four times the current space and 10 times the electrical capacity of the severely constrained current facility, and has advanced fire suppression and security systems.

When complete, the data center will be connected to a similar facility at IUPUI in Indianapolis by the I-Light optical fiber network, which runs over two separate routes. This enables data to be instantly backed up and shared between both hardened sites, giving reliable backup capabilities.

The University Architect’s Office, SmithGroup, estimates the building will be finished in spring 2009.