Data Center Pulse Blogs


DCIM - Its not about the tool; its about the implementation

 

Failure Success Road Sign

So you just finished your extensive purchase process and now the DCIM DVD is on your desk.

Guess what; the real work just started…

The DCIM solution you bought is just a tool, implementing it will require change in your organization. Some of the change will be small; for example no longer having to manually put data in an Excel file but have it automated in the DCIM tool. Some of the change will be bigger like defining and implementing new processes and procedures in the organization. A good implementation will impact the way everyone works in your datacenter organization. The positive outcome of that impact is largely determined by the way you handle the implementation phase.

These are some of the most important parts you should consider during the implementation period:

Implementation team.

The implementation team should consist of at least:

  • A project leader from the DCIM vendor (or partner).
  • An internal project leader.
  • DCIM experts from the DCIM vendor.
  • Internal senior users.

(Some can be combined roles)

Some of the DCIM vendors will offer to guide the implementation process themselves others use third party partners.

During your purchase process its important to have the DCIM vendor explain in detail how they will handle the full implementation process. Who will be responsible for what part? What do they expect from your organization? How much time do they expect from your team? Do they have any reference projects (same size & complexity?)?

The DCIM vendor (or its implementation partner) will make implementation decisions during the project that will influence the way you work. These decisions will give you either great ease of working with the tool or day-to-day frustration. Its important that they understand your business and way of working. Not having any datacenter experience at all will not benefit your implementation process, so make sure they supply you with people that know datacenter basics and understand your (technical) language.

The internal senior users should be people that understand the basic datacenter parts (from a technical perspective) and really know the current internal processes. Ideal candidates are senior technicians, your quality manager, backoffice sales people (if you’re a co-lo) and site/operations managers.

The internal senior users also play an important role in the internal change process. They should be enthusiast early adapters who really want to lead the change and believe in the solution.

Training.

After you kicked off your implementation team, you should schedule training for your senior users and early adaptors first. Have them trained by the DCIM vendor. This can be done on dummy (fictive) data. This way your senior users can start thinking about the way the DCIM software should be used within your own organization. Include some Q&A and ‘play’ time at the end of the training. Having a sandbox installation of the DCIM software available for your senior users after the training also helps them to get more familiar with the tool and test some of their process ideas.

After you have done the loading of your actual data and you made your process decisions surrounding the DCIM tool, you can start training all your users.

Some of the DCIM vendors will tell you that training is not needed because their tool is so very user friendly. The software maybe user friendly but your users should still need to be trained on the specific usage of the tool within your own organization.

Have the DCIM vendor trainer team up with your senior users in the actual training. This way you can make the training specific for your implementation and have the senior users at hand to answer any organization specific questions.

The training of general users is an important part of the change and process implementation in your organization.

Take any feedback during the general training seriously. Provide the users with a sandbox installation of the software so they can try things without breaking your production installation and data. This will give you broad support for the new way of working.

Data import and migration.

Based on the advise in the first article , you will already have identified your current data sources.

During the implementation process the current data will need to be imported in to the DCIM data structure or integrated.

Before you import you will need to assess your data; are all the Excel, Visio and AutoCAD drawings accurate? Garbage import means garbage output in the DCIM tool.

Intelligent import procedures can help to clean your current data; connecting data sources and cross referencing them will show you the mismatches. For example: adding (DCIM) intelligence to importing multiple Excel sheets with fiber cables and then generating a report with fiber ports that have more than 1 cable connected to them (which would be impossible i.r.l ).

Your DCIM vendor or its partner should be able to facilitate the import. Make sure you cover this in the procurement negotiations; what kind of data formats can they import? Should you supply the data in a specific format?

This also brings us back to the basic datacenter knowledge of the DCIM vendor/partner. I have seen people import Excel lists of fiber cable and connect them to PDU’s… The DCIM vendor/partner should provide you a worry free import experience.

Create phases in the data import and have your (already trained) senior users preform acceptance tests. They know your datacenter layout and can check for inconsistencies.

Prepare to be flexible during the import; not everything can be modeled the way you want it in the software.

For example when I bought my first DCIM tool in 2006 they couldn’t model blade servers yet and we needed a work around for it. Make sure the workarounds are known and supported by the DCIM vendor; you don’t want to create all your workaround assets again when the software update finally arrives that supports the correct models. The DCIM vendor should be able to migrate this for you.

Integration.

The first article did a drill down of the importance of integration. Make sure your DCIM vendor can accommodate your integration wishes.

Integration can be very complex and mess-up your data (or worse) if not done correctly. Test extensively, on non-production data, before you go live with integration connections.

The integration part of the implementation process is very suitable for a phased approach. You don’t need all the integrations on day one of the implementation.

Involve IT Information architects if you have them within your company and make sure external vendors of the affected systems are connected to the project.

Roadmap and influence.

Ask for a software development roadmap and make sure your wishes are included before you buy. The roadmap should show you when new features will be available in the next major release of your DCIM tool.

The DCIM vendor should also provide you with a release cycle displaying the scheduled minor releases with bug fixes. When you receive a new release it should include release-notes mentioning the specific bugs that are fixed and the new features included in that new release. Ask the DCIM vendor for an example of the roadmap and release-notes.

During the purchase process you may have certain feature requests that the vendor is not able to fulfill yet. Especially new technology, like the blade server example I used earlier, will take some time to appear in the DCIM software release. This is not a big problem as long as the DCIM vendor is able to model it within reasonable time.

One way to handle missing features is to make sure it’s on the software development roadmap and make the delivery schedule part of your purchase agreement.

After you signed the purchase order your influence on the roadmap will become smaller. They will tell you it doesn’t… but it does… Urge your DCIM vendor to start a user-group. This group should be fully facilitated by the vendor and provide valuable input for the roadmap and the future of the DCIM tool. A strong user-group can be of great value to the DCIM vendor AND its customers.

Got any questions on real world DCIM ? Please post them on the Datacenter Pulse network: http://www.linkedin.com/groups?gid=841187 (members only)

My Data Center Drives Faster Than Yours

I jumped on my data center the other day and rode into town for a beer at the local saloon. I tell you, these data centers keep getting bigger and faster every year. Did I confuse you? What does a data center mean to you? Is it some converged infrastructure with virtualization on it or is it a container with some racks of computers?


Why am I Bothered?


I probably should just ignore the vendor driven Data Center references, since it did little good when many of us discussed, debated, and argued over twitter where and how the term "cloud" should be used. Unfortunately, I can't ignore it, as I think there are real and important distinctions to be made about what a data center is.
Like many of the blogs and marketing splashes suggest, the "data center" is changing, but not because it's converged infrastructure or bigdata or SD(XYZ). The data center is changing because there are business, technical and sustainability drivers that require it to change. I'm bothered about the liberal use of the term "data center" because I fear it dilutes the focus on the larger picture of your environment. When thinking about your infrastructure and how it needs to work to support your enterprise, you must consider the entire envelope, not just some hardware or software. I've commented on this several times as it relates to the actual data center by using the Data Center Pulse "Data Center Stack". After looking at the Stack you are more likely to appreciate the importance and opportunity of a more holistic approach. The Stack can be immensely valuable, even if it's just used to help with communication and guide your partners.


References to "Data Center"


I won't call out all the offending vendors, but suffice it to say, many of the top names in the industry (Software & Hardware providers) have referenced their "data center" and how it will change organizations, strategy, make you coffee, and with an upgrade get you to Mars. What each of these companies failed to comment on is how their "data center" will affect the actual data center.
It would be great to see some of these providers step up and comment on how modern infrastructure concepts (not data centers) will affect data center design and or put your current data center at risk. I realize doing this would likely extend the sales cycle and scare buyers, so I'm assuming it won't happen. In the absence of vendor action, I felt it necessary to highlight a few considerations that IT buyers should consider.
Impact of Modern Tech on Data Center Requirements
There are myriad ways in which you can affect or impact the performance of your data center, but in this case I'm only going to cover a few of the top considerations associate with IT infrastructure.

Power density:
o 85% or more of existing data centers can't support more than about 6 kW per cabinet or roughly 240 Watts per square foot. With the density of most modern server gear, you can easily get to over 35 kW in a cabinet which equates to ~1400 Watts per square foot. This type of power requirement isn't something that can be easily retrofitted to an existing facility. If you install without retrofitting you will be forced to use an enormous amount of additional floor space to allow for adequate cold air. Or you can rip and replace with in row cooling options. However, most of these changes are only stopgap at best.

Network Diversity and capacity
o Few existing data centers have more than 1-3 network (WAN) providers on premise. With greater use of cloud, adoption of agile business/IT, and a more broadly distributed customer and partner base you must have a wider selection of providers. With so few providers you won't have price contestability and likely won't always get optimal solution and route options.

Weight of racks being installed
o We still say "raised floor" when we're talking about usable data center space. Sad, but true, roughly 85% of existing data centers still use raised floors. Depending on when the raised floor was put in, you might find that your floor can't support the weight of modern gear. This is just one of the important considerations that should help convince you to move to a slab environment for your infrastructure needs.

Accessibility requirements
o As you begin moving in fully configured racks or large storage assemblies you'll soon come to recognize issues with loading docks, door sizes, hall sizes, space between aisles, height (space above racks), etc., etc.

You don't have to say no

There are numerous options for solving the problems I've outlined above, but the most important thing is awareness. Awareness will help you make plans for your transition and put you on a better negotiating footing with your supplier partners. Awareness is also ammunition to help you push for change. You shouldn't lock yourself into a strategy because of assumptions you or your team have made about what will or won't work in your environment. You don't have to address these issues alone, and being armed with knowledge about the gaps in your current data centers (internal and external) will better position you to take advantage of the tech you need, when you need it without putting your business at risk.

Twitter: mthiele10

Before you jump in to the DCIM hype...

dilbert-information-strategy

 

You’re ready to enter the great world of DCIM software and jump right into the hype ?

Do you actually know what you need from a DCIM solution ? What are your functional requirements ?

So before you jump in, let’s take a step back and look at DataCenter Information Management from a 40,000 feet level: the datacenter facility information architecture.

Let’s start with ‘data’;

Data is all around us in the datacenter environment. It’s on the post-it notes on your desk, the dozen Excel files you manage to report and collect measurements and the collection of electrical and architectural drawings sitting in your desk drawer.

A modern day datacenter is filled with sensors connected to control systems. Some of the equipment is connected to central SCADA or BMS systems, some handle all the process control locally at the equipment. HVAC, electrical distribution and conversion systems, access control and CCTV; they all generate data streams. With the growth of datacenters in square meters and megawatts, the amount of data grows too.

The introduction of PUE and focus on energy efficiency have shown us the importance of data and especially data analysis. For most of us this has introduced even more data points, but enabled us to do better analysis of our datacenter’s performance. So; more data has enabled more efficiency and a better return on investment. Some of us could even say they entered the BigData era with datacenter facility data.

DCIM can play a role in the analysis of all this data, but it’s important to know where your data is first. Where is the current data stored ? What are the data streams within your datacenter ? What data is actually available and what data actually matters to your operation ? It’s a false assumption that all the data needs to be pulled in to a DCIM solution; that depends on your processes and your information requirements.

Process

Every datacenter has its collection of structured activities or tasks that produce a specific service or product for our internal or external customer. These are the primary processes focusing on the services your datacenter needs to provide. Examples are operations processes like Work Orders or Capacity Management.

These primary processes are assisted by supporting processes that make the core (primary) processes work and optimize them. Examples are Quality, Accounting or Recruitment processes.

Indentifying the primary and supporting processes in your datacenter enables you to optimize them by executing them in a consisted way very time and checking the output.

If you run an ISO9001 certified shop, you will definitely know what I’m talking about.

To run the processes we need information. Information is used in our processes to make decisions. The needed information can be collected and supplied by an individual or an (IT) system.

When data is collected it’s not yet information. Applying knowledge creates information from data. IT systems can assist us to create information from data, with built-in or collected knowledge.

Indentifying your datacenter processes also enables you to get a grip on the information that is needed to move the processes forward. Is this information available ? What is the quality of the information and process output ? How much time does it take to make it available ? Can this be optimized ?

DCIM solutions can assist you in creating information from data and provide information and process optimization. Most of the DCIM solutions depend on built-in knowledge on how datacenters work and operate, to facilitate this and optimize processes.

DCIM is only one of the applications used to support and optimize our datacenter processes. To support the full stack of processes we need a whole range of applications and tools. These applications can be everything from Planning to Asset Management to Customer Relationship Management (CRM) to SCADA/BMS tools.

Most of us already have some type of SCADA or BMS system running in our datacenter to control and monitor our facility infrastructure. This SCADA or BMS system will handle typical facility protocols like Modbus, BACnet or LonWorks. The programming logic used in most SCADA/BMS systems is not something found in typical DCIM solutions.

With the growing amount of sensors and their data, the SCADA/BMS system must be able to handle hundreds of measurements per minute. It must store, analyze and be able to react-on the provided data to control things like remote valves and pumps. This functionality is also typically not found in DCIM solutions. (So SCADA/BMS does not equal (!=) DCIM.)

Anyone running a production datacenter will already have a collection of applications to support their datacenter processes. You may have a ticketing system, a CRM application, MS Office application, etc.. Some times DCIM is perceived as the only tool you need to manage your datacenter but it will definitely not replace all your current tools and applications.

Model

Now that you have indentified your data, processes and current applications it’s time to focus on what you need DCIM for anyway; define your functional requirements.

One way of assisting you in this definition is creating your own datacenter facility information model.

IT architects are trained in creating information models, so if you have any walking around ask them to assist you.

Example of a model would be the one that the 451 Group created for their DCIM analysis. This is featured in the DCK Guide to Data Center Infrastructure Management (DCIM) (The model doesn’t cover the full scope for every organization, but it helps me to explain what I mean in this blog…)

dcim-451group

The model displays functionality fields what would typically exist when operating a datacenter.

You can use a model like this to identify what functionality you currently don’t have (from a process and application perspective) and what can be optimized.

It also enables you to plot your current tools on the model and indentify gaps and overlap. In this example I have plotted one of my SCADA/BMS systems on the (slightly modified) model:

dcim-plot-bms

I have also plotted the DCIM need for that project:

dcim-plot-dcim

Using models like this will give you a sense of what you actually expect from a DCIM solution and assist in creating your functional requirements for DCIM tool selection (RFP/RFI).

Integration is key

Modern day IT information management consists of collections of applications and datastores, connected for optimal information exchange. IT information and business architects have already tried the ‘one application to rule them all’ approach before and failed. Because creating information islands also doesn’t work, we need to enable applications and information stores to talk to each other.

You may have some customer information about the usage of datacenter racks in a CRM system like Salesforce. You may already have some asset information of your CRAC’s in a asset management system or maybe an procurement system. This is all interesting and relevant information for your ‘datacenter view on the world’. Connecting all the systems and datastores could get really ugly, time consuming and error-prone:

dc-info-connect

IT architects have already struggled with this some time ago when integrating general business applications. This has started things like Service-oriented architecture (SOA) , enterprise service bus (ESB) and application programming interface (API). All fancy words (and IT loves their 3 letter acronyms) for IT architectural models, to be enable applications to talk to each other.

dc-info-connect-soa

The DCIM solution you select, needs to be able to integrate in to your current world of IT applications and datastores.

When looking at integration, you need to decide what information is authoritative and how the information will flow. Example: you may have an asset management system containing unique asset names and numbers for your large datacenter assets like pumps, CRACs and PDUs. You would want this information to be pushed out to the DCIM solution but changes in the asset names should only be possible in the asset management system. Your asset management system would then be considered authoritative for those information fields and information will only be pushed from the asset system to DCIM and not vice versa (flow).

Integration also means you don’t have to pull all the data from every available data source in to your DCIM solution. Select only the information and data that would really add value to your DCIM usage. Also be aware that integration is not the only way to aggregate data. Reporting tools (sometimes part of the DCIM solution) can collect data from multiple datasources and combine them in one nice report, without the need to duplicate information by pulling a copy in to the DCIM database.

The 451group model does an excellent job of displaying this need for integration showing the “integration and reporting” layer across all layers.

Using your own information model you can also plot integration and data sources.

dcim-plot-integrate

Integration within the full datacenter stack (from facilities to IT)  is also key for the future of datacenter efficiency like I mentioned in my “Where is the open datacenter facility API ?” blog.

So, to summarize:

  • Look at what data you currently have, where it is stored and how that data flows across your infrastructure.
  • Look at the information and functionality you need by analyzing your datacenter processes. Indentify information gaps and translate them to functional requirements.
  • Look at the current tools and applications ; what applications to replace with DCIM and what applications to integrate with DCIM. What are the integration requirements and what information source is authoritative ?
  • Create your own datacenter facility information model. Position all your current applications on the model. (If you have in-house IT (information) architects; have them assist you…)

Preparing your DCIM tool selection this way will save you from headaches and disappointment after the implementation.

In my next blog we will jump to the implementation phase of DCIM.

 

More resources:

Full credits for the DCIM model used in this blog, go to the 451Group. Taken from the excellent DCK Guide to Data Center Infrastructure Management (DCIM) at http://www.datacenterknowledge.com/archives/2012/05/22/guide-data-center-infrastructure-management-dcim/

Disclosure: between 2006 and 2012 I have selected, bought and implemented three different DCIM solutions for the companies I worked for. At that time I was also part of either the beta-pilot group for those vendors or on the Customer Advisory Board. That doesn’t make me a DCIM expert, but it generated some insight into what is sold and what actually works and gets used.

Where is the open datacenter facility API ?

For some time the Datacenter Pulse top 10 has featured an item called ‘ Converged Infrastructure Intelligence‘. The 2012 presentation mentioned:stack21-forceX

Treat the DC infrastructure as an IT system;

- Converge in the infrastructure instrumentation and control systems

- Connect it into the IT systems for ultimate control

Standardize connections and protocols to connect components

With datacenter infrastructure becoming a more complex system and the need for better efficiency within the whole datacenter stack, the need arises to integrate layers of the stack and make them ‘talk’ to each other.

This is shown in the DCP Stack framework with the need for ‘integrated control systems’; going up from the (facility) real-estate layer to the (IT) platform layer.

So if we have the ‘integrated control systems’, what would we be able to do?

We could:

  • Influence behavior (can’t control what you don’t know); application developers can be given insight on their power usage when they write code for example. This is one of the needed steps for more energy efficient application programming. It will also provide more insight of the complete energy flow and more detailed measurements.
  • Design for lower level TIER datacenters; when failure is imminent, IT systems can be triggered to move workloads to other datacenter locations. This can be triggered by signals from the facility equipment to the IT systems.
  • Design close control cooling systems that trigger on real CPU and memory temperature and not on room level temperature sensors. This could eliminate hot spots and focus the cooling energy consumption on the spots where it is really needed. It could even make the cooling system aware of oncoming throttle up from IT systems.
  • Optimize datacenters for smart grid. The increase of sustainable power sources like wind and solar energy, increases the need for more flexibility in energy consumption. Some may think this is only the case when you introduce onsite sustainable power generation, but the energy market will be affected by the general availability of sustainable power sources also. In the end the ability to be flexible will lead to lower energy prices. Real supply and demand management in the datacenters requires integrated information and control from the facility layers and IT layers of the stack.

Gap between IT and facility does not only exists between IT and facility staff but also between their information systems. Closing the gap between people and systems will make the datacenter more efficient, more reliable and opens up a whole new world of possibilities.

This all leads to something that has been on my wish list for a long, long time: the datacenter facility API (Application programming interface)

I’m aware that we have BMS systems supporting open protocols like BACnet, LonWorks and Modbus, and that is great. But they are not ‘IT ready’. I know some BMS systems support integration using XML and SOAP but that is not based on a generic ‘open standard framework’ for datacenter facilities.

So what does this API need to be ?

First it needs to be an ‘open standard’ framework; publicly available and no rights restrictions for the usage of the API framework.

This will avoid vendor lock-in. History has shown us, especially in the area of SCADA and BMS systems, that our vendors come up with many great new proprietary technologies. While I understand that the development of new technology takes time and a great deal of money, locking me in to your specific system is not acceptable anymore.

A vendor proprietary system in the co-lo and wholesale facility will lead to the lock-in of co-lo customers. This is great for the co-lo datacenter owner, but not for its customer. Datacenter owners, operators and users need to be able to move between facilities and systems.

Every vendor that uses the API framework needs to use the same routines, data structures, object classes. Standardized. And yes, I used the word ‘Standardized’. So it’s a framework we all need to agree up on.

These two sentences are the big difference between what is already available and what we actually need. It should not matter if you place your IT systems in your own datacenter or with co-lo provider X, Y, Z. The API will provide the same information structure and layout anywhere…

(While it would be good to have the BMS market disrupted by open source development, having an open standard does not mean all the surrounding software needs to be open source. Open standard does not equal open source and vice versa.)

It needs to be IT ready. An IT application developer needs to be able to talk to the API just like he would to any other IT application API; so no strange facility protocols. Talk IP. Talk SOAP or better: REST. Talk something that is easy to understand and implement for the modern day application developer.

All this openness and ease of use may be scary for vendors and even end users because many SCADA and BMS systems are famous for relying on ‘security through obscurity’. All the facility specific protocols are notoriously hard to understand and program against. So if you don’t want to lose this false sense of security as a vendor; give us a ‘read only’ API. I would be very happy with only this first step…

So what information should this API be able to feed ?

Most information would be nice to have in near real time :

  • Temperature at rack level
  • Temperature outside of the building
  • kWh, but other energy related would be nice at rack level
  • warnings / alarms at rack and facility level
  • kWh price (can be pulled from the energy market, but that doesn’t include the full datacenter kWh price (like a PUE markup))

(all if and where applicable and available)

The information owner would need features like access control for rack level information exchange and be able to tweak the real time features; we don’t want to create unmanageable information streams; in security, volume and amount.

So what do you think the API should look like? What information exchange should it provide? And more importantly; who should lead the effort to create the framework? Or… do you believe the Physical Datacenter API framework is already here?

More:

Good API design by Google : http://www.youtube.com/watch?v=heh4OeB9A-c&feature=gv

The green PUE monster

green-monster_thumb

My fellow Datacenter Pulse (DCP) colleague Mark Thiele wrote a good article on the use of PUE in the datacenter industry. He basicly argues that you should look at the TCO of the datacenter and have a holistic view (like we promote with the DCP stack)

He opens with the ‘my PUE is better than yours remark’ we see going around in the industry. As mentioned before by the Green Grid; the misuse of PUE. (I have written several articles about this issue on my Dutch datacenter blog)

Well guess what… we kinda created this monster ourselves;

Commodity

Datacenters are going commodity. Differentiation is in efficiency; Looking at all the signs in the datacenter industry: the datacenter is becoming a commodity. The general idea is that any product will end up a commodity. See Simon Wardley’s excellent presentations on this subject.

Example signs are:

(got lots more but for an other blog and beyond the point now…)

Most of it leads to technology being available to everyone. You still need a big budget to start building a datacenter but cost is coming down thanks to advances in IT technology (like: do we still need to build TIER4?) and facility technology. Great example is the option to build modular and from an assembly line. This reduces datacenter production cost and you can spread CAPEX across time.

For any commodity product the competitive advantage diminishes, prices go down and if you’re in the market of selling the stuff: your differentiation is on price and efficiency.

So we drive towards efficiency and lowering our operational cost to be cheaper that the competition. It doesn’t matter what type of datacenter owner you are (enterprise, cloud, co-lo, whole sale..) the competitive advantage is in the operational cost. Everyone already has an SAS70, ISO27001, ISO9001, PCI, etc.. certificate. Everyone can get and build the technology and at some point it doesn’t pay off to worry about the small engineering details anymore; the cost are too high to get enough competitive advantage in return.

Marketing & Sales

If you’re in the datacenter co-lo or whole-sales business then your marketing and sales guys are trying to look for the (next) USP.

With the datacenter efficiency on the rise it’s nice to have a single figure to tell your customer you are more efficient that the competition (and able to offer lower prices with it..).

PUE presented a great opportunity to get a nice USP for our sales guys. And I can’t blame them: it’s hard to sell a (going) commodity product and it’s something our customers are asking for.

Sustainable & marketing

The whole ‘green wash/hype’ (before the economic crisis) added to the misuse of PUE from a sales and marketing perspective. Everyone was ,and still is, building the next greenest datacenter on this planet. It would be nice to have a single figure to promote this ‘green stuff’ and tell the world about this new engineering marvel… and PUE is happily adopted for this.

On the enterprise/cloud datacenter part it’s not very different.. just another angle. Especially the larger datacenter (cloud) owners are pushed from a marketing perspective thanks to organizations like Greenpeace. They demand full disclosure of datacenter energy use and sustainability on behalf of the world’s population.

PUE is a nice tool to get some of the pressure off and tell the world you have the greenest datacenter operation, like Facebook, Google, Microsoft and others are now doing. The problem with those numbers is they don’t say anything without the full context. And like Mark says in his article; it doesn’t say anything about the full datacenter stack.

Sustainable & Government

The really interesting thing I have been dealing with recently is government and PUE.

Many state and local government organizations are looking at datacenters from an energy use perspective. This focus is thanks to reports from research and governmental institutes (for example EPA) and organizations like Greenpeace.

Government can use the ‘carrot (subsidies) or stick (penalties)’ approach but it always requires some kind of regulation and some form of measurement. They happily adapted PUE for this.

The main problem for this is that PUE is not ready to be audited. Sure general guidelines for PUE calculation are available, but it still doesn’t have all the full details and leaves opportunity to ‘game the system’. It also doesn’t address the full holistic datacenter approach and the fact that you cannot use PUE to compare different datacenters.

Datacenter customer

Some of the governmental organizations are also using PUE for their co-lo tenders. They are not the only ones. More and more RFP’s on the datacenter market state a specific PUE number or target with additional credits for the lowest number.

I can’t blame the datacenter customer; the datacenter is a pretty complex facility box if you’re not educated in that industry. It would be nice to just throw some numbers at it like TIER1-4 and PUE1-2 and see the best solution provider out there…

I can’t blame the datacenter owner for the answer with the best possible number he can ‘think’ of… they just want the business…

Datacenter vendor

As usual I’m part of the problem also. When I go shopping for the next big thing in datacenter technology, PUE is always part of the conversation.

Datacenter equipment vendors (especially cooling and power) are happy to throw some numbers my way to convince me that their solution is the most efficient.

The PUE numbers are on the equipment spec sheets, on the vendor website and in the sales meeting… but at the end I always have to conclude that our little number dance really doesn’t tell me anything. Just like Mark mentions.. I go back to TCO.

Our own monster

So… we created this monster as an datacenter industry. Owners and consumers. Government and industry groups. I can also assure you that this will continue and will also happen to some of the great other Green Grid initiatives like CUE, WUE and the Maturity Model. It’s just a way of trying to put a number on what can be a very complex stack of functions called the datacenter.

Only way to diminish the monster is to educate our industry colleagues and our customers. And stop throwing the numbers around…

For the record1: the use of PUE

Don't get me wrong, I love PUE and have used it successfully many times to benchmark my own data centers and prove to senior management that we progressed in efficiency. Its the way the EU Datacenter Code of Conduct works: show progress every year by calculating the PUE for the same datacenter with the same calculation method. This way you will have an apples - apples situation.

Its just that I don't like the way PUE is used in the above examples...

For the record2: On datacenter and green

Full disclosure: Datacenters are not green and will never be green. They consume large amounts of energy and will consume more energy in the future. All thanks to Jevons Paradox and the fact that we consume more CPU/Storage if prices go down…. And yes, someone has to build datacenters for all the CPU’s and disk’s…

See GreenMonk - Simon Wardley on ‘Cloud & Green’

I do think that:

1. We should aim to build the most efficient datacenters on the planet. It should not only focus on energy consumption but on all resources used for build and operation.

2. We cannot keep up with the rising demand from an energy-grid perspective. We should start looking for alternative ways for datacenter build and deployment.

 

Starting a blog avalanche

After some time of blogging on my Dutch website (www.janwiersma.com ), some of my English friends asked me if I could re-publish and extend some of them in English. This way the knowledge can be shared with a bigger audience.

While my English writing style definitely needs some work, I will give it a go at my DCP blog.

Get ready for an avalanche of blog’s. ;-)

Server Power Consumption Cost Exceeds the Cost of the Server – SO WHAT!

Saying a modern server uses too much power is like saying a train uses more power than a horse drawn wagon. Of course it does, but it also does way more work. Let's not forget what's important to the question of cost and that is simply how much work is the server performing?

I've contributed to this noise in the past, but recently I've had a change of heart. After reading several recent articles that mention the cost of power exceeding the cost of the server, I've come to a new realization on this issue. The power use must be measured as it pertains to work potential.

Watts vs. Work Output

A single server today is twice as capable as a single server from two years ago.  There are more CPUs and each CPU is more powerful. There's more memory and each dimm is faster and has more capacity than its predecessor. So, even though the amount of power being used by each server has gone up, the actual "watts per work output" has gone down.

We must always be looking to make the solutions we create more efficient in design, life cycle and use characteristics.  However, we shouldn't overlook the fact that these systems are replacing work that would otherwise use much more power.

So, if you're really worried about how much power your servers are using, there are myriad opportunities you can pursue;

Greater virtualization
Use of cloud
Improved Management platforms for your infrastructure (Cloud & Virtual)
Applications (software) written with efficiency of operation as a consideration
Right sizing your environments
Using a well design and efficient data center
Etc., etc..

What you shouldn't do is fall into the trap of "not seeing the forest for the trees". Focus on the activities that generate business benefit and do those actions with sustainability and efficiency as part of your process. If you start trying to extend your servers life instead of implementing solutions that create business opportunity you'll be missing the forest. You might also find that many companies are actually improving their bottom line by replacing efficiently utilized servers more often, so they can reduce wasted energy and increase the work output per Watt.

 

 

No Man is an Island and neither is a Data Center

Is it safe to build a data center anywhere along the coast? Can you really protect the availability or accessibility of your systems in the face of hurricanes, earthquakes, and other natural disasters? Just because you've built a solid structure, doesn't mean you can guarantee accessibility and your data center is nothing without connections.

Keeping the Data Center alive

The general assumption by most is that keeping your data center running is akin to keeping it "available". The reality is that availability and running do go hand in hand. However, running doesn't guarantee availability.

The data center community spends billions of dollars every year on facilities that can withstand a variety of disasters.  Money is spent on risk avoidance for fire, floods, earthquakes, hurricanes, minor terrorist attacks or even the angry worker trying to drive a truck through the door.  However, the primary limitation is still that these protections in most cases only help to guarantee that the data center keeps running.  

My Data Center is Safe, what else matters?

So, you figured out how to protect your data center from the disaster du jour, congratulations. It's too bad that even though your data center was protected your customers can't use it or your employees can't access it.  That's right, you've got power and HVAC, the servers and disk drives are humming, but your customers can't access anything, why is that?

The data center is no different than a man (person). As with any living being you need your ecosystem to support your existence. 

Example disaster scenario: Human in an urban environment

You've built a strong house, with good security. You maintain a small supply of food and water, and maybe even have a generator.  Then a major disaster occurs that eliminates your ability to be mobile and your access to many external services.

What happens when:

-          you need a doctor?

-          you run out of milk?

-          you need a firefighter or police officer?

-          you need to travel?

-          you can't connect to NetFlix?

-          your 15 year old can't update Facebook?

-          Etc., etc.

As you can quickly gather from the above example the human in this case is likely to start having problems fairly quickly, even though they are "alive" post disaster. While alive is almost always better than the alternative, being alive for a few extra days is not the same as surviving to live on.

Example disaster scenario: Data Center

You've built an earthquake safe data center (A building that can withstand the proverbial "big one"). You've even installed base isolation under the server cabinets to avoid any serious vibration or shock to the IT equipment.  Unfortunately, the water main two blocks away doesn't have the same earthquake protection, and neither did the nearby highway overpass that feeds the area your data center is in. Then, because of a road cracking and the overpass collapse all the fiber coming to your facility is gone. Good news though, the data center is still running on its own generators and temporary water supply.

What happens when;

-          your customer(s) needs to access equipment remotely like they most often do?

-          your staff can't gain access to the facility because of local conditions?

-          your staff is unavailable because they are worried about their own family safety and health issues?

-          you begin to run low on diesel, or water and the roads are impassable or you aren't the priority for limited supplies?

-          Etc., etc.

The above situation can apply to any number of disasters from a hurricane to a tornado or even a major fire, snow storm or flood.  In the above scenario your data center might actually be functioning as an island, but what good does that do you? Sure, your equipment is safe, and when services are restored you won't have to rebuild your infrastructure, but in the mean time you are down as far as your customers are concerned.

Modified thinking around data center design and location is required

Historically the concerns I've voiced above were more limited in risk and to some degree even to potential of disaster occurrence. However, there are several factors that are changing or should be changing our long held assumptions about what "safe" means for our data center facilities.

Factor 1: Climate Change

Believe in Climate Change or not the fact remains that on a regional and global scale we are seeing more natural disasters than ever and these disasters are getting bigger in scope. Fires, hurricanes, droughts, tornadoes, and other weather phenomenon are increasingly getting nastier.   If we hold the assumption that weather related disasters will occur more frequently, and will impact new regions, we see a significant magnification of the problem occurring (I.e., More storms that are stronger, in combination with a wider area of influence or impact). There's even a new study that suggests that rapid climate change can increase the number and severity of volcanic eruptions.

Factor 2: Density & Value

We are continuing to place more value (real & perceived) on our access to technology. Every day we move more of what we used to do with a car or our hands in to a technology solution.  Through the increased availability of technology we are finding even more ways to take advantage of it, effectively accelerating the growth of technology use.  This greater our emphasis on technology becomes, the more dependent on it we becomes. As this dependence grows, the importance of it being available to us goes up.

Factor 3: Infrastructure Demands Changing

There are many variables that affect how our IT infrastructure solutions are built and protected. In some cases the advent of cloud oriented solutions means you have greater protection from localized disasters (I.e., Google, Microsoft, Yahoo, etc). However, in other cases, legacy IT, enterprise IT, and Big Data there is likelihood that more protection in a given location will be necessary, not less.

Given the three factors above it would seem to point to the notion that how you build to protect your data center should get a higher priority, but even more importantly, where you build is critical.

Decision Process

As with any major IT or business decision a number of factors of opportunity and risk need to be weighed before you make a final choice. Each of the factors need to be considered; latency, sustainability, access to connectivity, power, water, and skilled staff, etc.  So, if you find yourself looking at several options whose costs are similar, but one has a better more survivable location, you know what you should pick. Why accept the risk that a tornado might remove the data centers roof or a flood might inundate your equipment, if you don't need to?

Location, Location, Location...

I've written about site selection decisions before (Blog 1 & Blog 2), but never have I felt it so important to consider the disaster risk at the same level as I do now. With the recent hurricanes on the East Coast, and tornados hitting more often in more locations than ever, I don't see how you can avoid the question of "Is this the safest place for me to entrust my companies IT jewels?"  

Whether Human or Data Center, your ecosystem of support is critical

Dig deep into your list of requirements for where you company's compute infrastructure should be placed, eliminate the requirements associated with latency, power, sustainability, political risk, etc. Then using the remaining options, pick the one that offers the best combination of price and protection, keeping in mind that protection is much more than a well-built facility.  However, that doesn't mean that if you find a safe geographic location you can forget about things like roof penetrations, wood in the construction, poor operational habits, and other basic facility operations and design factors that are critical to service availability. With all the concern I've voiced about weather and geography, the two most likely issues are fire (keep wood out) and people (have excellent operations habits and tools).  

 

Announcing eBay Inc.'s Renewable Energy RFQ

Back in March, I wrote about the 2012 Data Center Top 10, the current pulse of what is hot, interesting, challenging or emerging from the DCP community. “Renewable Power Options” came in at Number Five but for eBay, it’s near the top of the list.


We fundamentally believe that the future of commerce can be better than it is today; not only more convenient and accessible to consumers, but greener, cleaner and more efficient. The technology infrastructure and energy behind eBay’s commerce platforms are core to this vision. I’ve written here many times about the radical efficiency measures and innovative design approaches that my team, in tandem with our industry partners, has integrated into our data center portfolio. But as remarkable as those accomplishments have been, we are still using more carbon-intensive electricity than we would like. For the last three years, we’ve traversed the complicated regulatory environment and ever-expanding technology arena to source clean energy where we operate. Today, I’m excited to announce our next step in that journey.


On September 4th, eBay sent a Request For Qualifications (RFQ)  to organizations that can supply or develop renewable energy for eBay data centers and office locations in Utah and other locations in the Western U.S. A natural next step following the clean energy legislation we helped develop and pass in Utah earlier this year, this work will also supplement other clean energy programs eBay is pursuing, including our recently-announced collaboration with Bloom Energy. As with our entire corporate energy portfolio, we are agnostic as to the renewable technology used, and are open to everything from wind to solar to geothermal to trash power – or anything else that makes economic and ecological sense for our business, and for the local community. To ensure that we have a complete picture of the options available to us, we are leveraging our public Request For Information (RFI) process, established in 2010, which yielded our award winning Data Center, Project Mercury in Arizona and our latest expansion, Project Quicksilver in Utah. My hope is that the renewable power community will step up with proposals on how we can expand our portfolio with innovative and cost effective clean energy solutions in our own backyard.


Vendors who meet the requirements of the RFQ will be invited to respond to a more detailed RFI under a mutual non-disclosure agreement (MDNA). RFI responses are due by October 31, 2012.


Email modular@ebay.com if you wish to participate, or have any questions about the RFQ or this process. We want to hear from you. We can’t wait to announce the results and take a big step closer to our vision of a commerce platform powered 100% by clean energy. Stay tuned for updates!

Upcoming Events - Cloud Asia Conference 2012 Singapore

Join Mark Thiele at the 2012 Cloud Asia Conference in Singapore on May 14th. 

This is an outstanding regional conference, with a long list of very strong industry and end-user speakers. 

It would be great to meet in person, so if you decide to join us, please look me up. 

Cloud Asia 2012 Website & Registration