Archive for the ‘Data Center Migration (DCM)’ Category

Data Center Infrastructure Management (DCIM) in Small to Medium Data Centers

Thursday, July 21st, 2011

Data Center Infrastructure Management (DCIM)

Last week I was interviewed by a reporter from SearchITChannel.com about why IDMWORKS is having success with DCIM solutions in small to midsized data centers (20-100 cabinets). Although there are a multitude of benefits associated with implementing a DCIM solution, most (DCIM) companies are focusing solely on the enterprise market. Until recently that has been a major disadvantage for organizations in the small to mid size space that have some of the same needs, just on a smaller scale.  DCIM solutions as a planning tool can provide a real world proof of concept that will give clients the confidence to implement and utilize a DCIM solution for their Data Center Infrastructure Management needs. SME and Enterprise clients should both benefit from the value these solutions can provide when integrated with migration or consolidation projects.

IDMWorks’ Data Center Migration team is certified by several of the industry leading DCIM solution providers. We have put our timeand experience tested twist on how we deliver our services and how we believe DCIM solutions should be positioned in the data center space.

The Data Center Migration team specializes in migration planning. The evolution of our process has taken us from homegrown proprietary tools to the use of DCIM solutions during our engagements that provide strong benefits and features than we could not have offered years ago. Traditional methods would have the client going back to documenting their hardware and application inventories and circuit and connectivity in spreadsheets, Visio and CAD.  The reality is once clients see the value that the DCIM solutions provide, and have worked with the product throughout a migration, the thought of going back to the old way of managing their the environment is not appealing.   Additionally we do not utilize the typical auto-discovery features built into the DCIM solutions we work with as we have found there is much greater value derived in the manual process we deploy (basically the auto-mated processes give customers the bare minimum or less needed to have a successful engagement), and that most clients are reluctant to allow these applications to perform their auto-discovery functions on their networks (as to do so violates many tried and true network IT security principles).

No matter what the size of your organization is there are quantifiable benefits from utilizing DCIM solutions for planning, modeling, and scheduling an efficient equipment migration. Once the migration is complete, our team can install a fully populated DCIM solution for a client to use. 

Do you have questions?  We have answers!

Feel free to reach out to us at IDMWorks.

Tags: , , , , ,
Posted in Data Center Infrastructure Management (DCIM), Data Center Migration (DCM) | No Comments »

Ten Questions to Ask Yourself before a Data Center Relocation

Friday, March 25th, 2011

This is not a “top ten” list ordered by level of humor. This isn’t necessarily in order of importance. The following are just ten queries with thoughts on business-as-usual status, relocation impact, and how IDMWorks Data Center Migration (DCM) specialists might help you.

1. How long can you freeze progress?
Business goes onward. The primary purpose of the enterprise is not IT. IT exists to support the primary goals of the enterprise and to do it economically. Even when you are preparing for relocation business units expect most changes when they want them. Periods with even partial freezes for relocation must be minimal to maintain your enterprise’s real primary purpose.

2. How much spare resource capacity do you have?
If you have the resources to do a Data Center Migration internally, some may think you are overstaffed. Most enterprises have been trimming expenses wherever they could, including IT staffing.  This generally means that your technical people are pressed to keep up with current operations.  You may be stretching them just by asking them to learn and practice new techniques. Now, on top of that, you are looking at migrating to a new Data Center. You probably won’t avoid changes to your technology. In fact, some technology changes may be in the reasons to execute the migration.

3. How big is a relocation project?
You have a Data Center full of units that will have an average age of four years when they are replaced. This means that on average your staff replaces 2% of the equipment every month. A relocation calls for de-installing and re-installing 100% of the equipment in about two months. Relocation is 24 times the normal workload.

4. Do you have expertise on your staff?
Few companies move a Data Center more than once a decade. Even if you have people on staff who moved a Data Center ten years ago, they won’t recognize how constant process improvement has changed the applicable processes.

Ask yourself this:
• Do you know the lead times for the technology changes in a migration?
• Have you considered what topology will carry you into the future best?
• Is your purchasing department well versed in the nuances of the trades you will engage?

5. How well do your silos work together?
Your teams are probably in silos. We can assume that your enterprise executes deployments beautifully with application, server, network, storage, and backup teams all getting their jobs done in a few days.  Remember that Relocation is 24 times the normal workload? In a migration, you will need power, networking, storage, equipment, and applications to execute seamlessly in minutes.

6. How do you want to be remembered?

Quality will be remembered. If you spend a vast sum to obtain the proper facility; but have problems bringing up the applications in it, that memory will live anecdotally through many budget cycles. The saying is that Data Center Migrations are career changing – which way would you like your change to be?

7. Do you know the risks of a DCM?
You know your day-today risks however, there are additional risks to consider in a migration.  Statistically, only 4% of system failures are the result of hardware failing when running in place.  That risk quadruples (16%) when you de-install and re-install equipment. Plus it is typical to add almost the same amount from human error when operators are only trying to restart systems as they were. How many of your systems were configured by parties who are no longer present? Plus there may be network configuration complications. One of the most irritating statistics is about 2% of “outages” being caused by tests that report false defects. Unfortunately you have to remember to test the tests.

8. How much can you rely on your IT structure?
There are a collection of things that you expect to be working in your favor. Like your network, phones, email, identity validation, help desk, fire alarm sensors and other infrastructure. When you are moving these very systems can fail on you in the most interesting ways. I believe there is a corollary to Murphy’s Law that “If a reliable system fails, it will fail at the most inopportune time.”

And yet sometimes reliability is actually the enemy. Those landscape sprinklers that always come on at 2AM? Not so good when you are moving a load of switches and servers past them at 2AM.  For that matter, from a staff standpoint, don’t schedule a move for Mothers’ Day weekend, you won’t have time to handle all the complaints.

9. How large is the “team” to whom you will communicate?
There are actually several aspects to the communication problem.  For example, I once heard of an unhappy board member whose first notice of a major move came from an outside acquaintance at a sporting event.

  • As situations change you need to document status at the time decisions are made so that hindsight does not become obscured by changes after the fact.
  • Upper management expects IT management to clearly convey the risks they are accepting and the financial reasons for accepting that level of risk.
  • There are teams inside of IT and Accounting, business units, IT vendors, communication vendors, management teams, relocation vendors, maintenance teams (contract updates, tax rate changes, standby), general employee pool, customer pool, non-IT vendors, and maybe a dozen more categories of communication targets. For these various targets, there will be a variety of different message mediums and timings.

10. Does your budget fit your needs?
Also known as the Goldilocks question: Are you buying just right, or too much (wasting resources), or too little (limiting future processing)?
The relocation should fund infrastructure for a period specified in the goals of the project. The physical facility usually needs to be serviceable through the end of lease/life. At the same time you consider that the exit date for the new Data Center is years away; you should also weigh throughput that will become available using newer technologies. In an ever-’green‘er world, there may be financial reasons to plan for future changes.  With increasing availability of collocation and cloud resources, there is a serious risk of overbuilding. Enterprise management needs to be assured that funds committed to IT are being used wisely. It is beneficial to have experts involved before you commit to particular topologies and technologies and before you are requesting bid proposals.

What IDMWorks can do for you

At IDMWorks we have a phased approach to the relocation:
1. We will ensure your goals are met. We consider your stated and implied goals for the relocation project and help you set-up a core team to coordinate the project.
2. We will ensure proper discovery. We gather and combine data on your systems, information communication, and applications in a discovery effort. This includes interviews on expected technology changes.
3. We will ensure you plan correctly (and obtain final budget approvals). This includes analyzing prototypes to illustrate alternatives, checking designs for facilities and cable infrastructure, actually planning (with your staff’s input) equipment locations, move timing and patching.
4. We will test, retest and ensure proper execution. With your staff and our support teams, we test readiness before moves, execute moves, and confirm results of each move.
5. We will ensure you close your old facilities (if applicable) and the project. There are many Project Management Phases that apply to DCM – Charter, Discover, Design, Deploy and Validate, and then Close.  Our DCM PMs handle status reports, core team meetings, to-do lists and both create and maintain project plans at various levels of detail.

Get to know peace of mind, get to know IDMWorks Data Migration Services.

IDMWORKS specialists help your teams understand the fit and take pride in overall success. Successful relocations often become bonding experiences that even reduce staff turnover. Smarter, faster, and happier.

Tags: , , , ,
Posted in Best Practices, Data Center Migration (DCM) | No Comments »

What does it take to move a Data Center?

Friday, February 11th, 2011

What does it take to move a Data Center? After all it can’t be that hard, its just moving boxes.  At least that is what some organizations think.

Just get a moving dolly, unplug the power to your cabinet, jack it up and throw it into the back of a truck. It’s only a few servers and other things, what is the big deal?   That’s an option and maybe it could work for you, after all,  you don’t need to worry about lost data, service level agreements and down time is all over rated.

But let’s get serious.

In today’s environment those boxes are the brains of your business and they house medical records, transactions, and other critical data. You probably can’t just throw your servers into the back of a truck and move them. So let’s review exactly what it would take to do this the right way.

1) Coordination (and Experience helps)

For the successful migration of a Data Center  there are many parts to the puzzle that need to be properly aligned to get the desired effect. Consider what it takes to have an orchestra produce a concerto. The orchestra is comprised of more than just instruments. There are multiple groups within the orchestra. The woodwinds, brass, percussion, keyboards, and string sections are comprised of multiple instruments, with individual members, and group leaders. Each instrument produces a unique sound and fulfills a specific requirement in completing the musical score. Having talented musicians is not enough. Without the conductor keeping time and guiding the musicians the expected notes, beat and music would not be produced. This is similar to the coordination that is required by the Data Center Migration Team.

So consider the environment surrounding your Data Center for a moment.   I am sure that you have separate groups all performing their daily tasks.  These tasks are accomplished either flawlessly or maybe there is some room for improvement.  In either case, the level of difficulty, the amount of time, and resources required to move a Data Center increase astronomically over your normal routine.

The missing element from your routine that is needed to successfully migrate a Data Center is the coordination and experience of the conductor.

At IDMWorks we strive to provide this piece of the puzzle.  Just as the conductor’s task is to take the talent and skills of the musicians and guide them so they can ultimately play a synchronized score of music.  We utilize our experience with Data Center migrations to fully develop your teams’ knowledge and talents and manage them through a successful migration process. The result is more than just the movement of gear and applications to a new site. You will now have a unified team with a greater understanding of your Data Center and its applications.

The IDMWorks project approach that we utilize progresses through five distinct phases of the project:

1) Start up
In the Start up stage we define the scope and nature of the project. We work with your project champion to create a project charter which documents the business and technical drivers that are affecting the project, high level tasks, project deliverables and a schedule. Stakeholders and other team members are identified which will be supporting the project.

2) Discovery
The purpose of the discovery stage is to identify your hardware, applications, and circuit inventories. This is done through a multi-pronged approach. The IDMWorks team will gather the current documentation that is in existence, interview the subject matter experts, perform necessary site surveys and establish and run work group meetings.  The gathered information will be processed within IDMWorks’ Data Center Infrastructure Management (DCIM) toolset, which allows us to further refine the project plan and to begin the design phase. Status meetings are routinely conducted to keep all team members informed of the project’s progress.

3) Design
The intent of the design stage is to develop and publish all necessary plans. This is an iterative process conducted in small work group meetings. We work with individual teams to develop their designs and published them to the rest of the teams for comment.  All team members need to consider not only their individual plan but also how their plan will affect the designs of others (the dependencies).  The designs that are to be developed during this phase include (but are not limited to); the equipment power, space, and elevations within the Data Center; the structured cabling, the connectivity and patching plan for the new Data Center, LAN/WAN/Storage design, telephony, and the actual migration waves.  The compilation of these designs are what creates the project plan.

4) Deployment & Validation
Deployment consists of not only the actual migration, but also the coordinated implementation of the project plan. This process involves the management of resources and of time. As each portion of the project plan is completed, the team needs to understand the status of the project and if anything changed that will affect the remaining tasks? There is constant oversight required and as steps are completed the team must ensure that the proper validation has taken place.   For the actual migration we follow this same process but on a micro level.  The process is actually started at least a week prior to the move when pre-migration tests are performed.  Each system is tested for its migration readiness. During the migration, each system that is brought down, shipped and reinstalled in the new Data Center and is tested and validated prior to being reinstated as being back in production.

5)  Closeout
After all hardware and applications have been successfully migrated to the new Data Center the team is ready to begin the closeout process. This can involve the return of rental gear that was utilized to facilitate the migration, turning off of circuits that are no longer needed, and returning the old Data Center to pre-lease conditions. Vendor invoices need to be finalized. Warranty and paperwork needs to be filed and a final communication needs to be issued describing what took place and the benefits that your organization will receive because of the project.

So If you believe that you will be undertaking a future Data Center Migration or have questions regarding it’s possibility, we at IDMWorks invite you to contact us and get to know peace of mind.

Tags: , ,
Posted in Data Center Migration (DCM) | No Comments »

Data Center Migrations & Pretesting– How to Avoid an Executive Caused Disaster

Tuesday, February 1st, 2011

When we at IDMWorks are coaching clients in regards to relocation we request that they pretest systems that are going to be moved.  Often we get push back.  So let’s define what pretesting is and why it needs to occur.

Pretesting Defined

IDMWorks always ask our clients to shut off and restart all equipment that is going to be moved at least a week before the live move. During this process all drivers should be updated & tested and and any IP address changes should be tested.  This is done at least a week prior to give adequate time for discovery of problems. Additionally in the case of critical applications, such as accounting applications, we suggest the shutdown should be before a month end or quarter end preceding the move.

What to include in Pretesting

Any machine that has not been shut down recently should be cycled. This will prove that power supplies and disk drives can take the added strain of a cold start. For that reason we recommend the machines be down for more than a few minutes during the test.

Any machine that needs drivers changed to function in the new data center should have those new drivers installed during the pretest. These drivers do not necessarily have to be the newest but should be at a level known to be compatible with the new site.

If the IP addresses of the equipment will be changed at the new site; they should be changed during the pretest.  For example, if 10.192.80.121 must be changed to 192.168.64.12 at the new site, then during the pretest you may want to change it to 10.192.80.140 (or any site specific, usuable IP). The DHCP service that distributes the address range  must also be updated and have time to prepare to distribute the new address. Some users may have to be reminded (or forced) to reboot to get the new addresses.

So a machine that has recently been rebooted, that will use the same IP address, and has the latest drivers would appear to not need to be tested. Don’t let the appearance deceive you.

Examples of Discoveries with Pretesting

Often we discover that disk drives or power supplies fail during or after pretesting. If they are still under warranty or maintenance at that point  the repairs should be covered however many may charge for a failure on the move day that would have been covered a week before hand at the old data center.

Often with even minor IP address changes we find systems that nobody thought were related failing because of a hard coded IP address for a “trivial” connection (who gets to tell an executive that his or her scheduling tool is “trivial”?).

Making these discoveries ahead of time means an opportunity to change the IP address in the trivial system or even change a scheduled date on a system to avoid problems of reliance of one system on another.

Many clients find that when drivers are changed there are unexpected consequences in those or other dependent systems.  For example, changing a storage driver to be compatible with a device at the new data center may cause an incompatibility with an older piece of equipment that was not planned to be upgraded. Therefore driver changes sometimes lead to multiple upgrades to maintain compatibility. This requires additional time and resources that one probably does not have on the move weekend.

Examples of Discoveries without Pretesting

There are many horror stories in this category.  I have chosen three to illustrate the point.

1)  Client went to shutdown System-X. They could see a System-X label and so pressed the button. System-Y went down. Months prior System-X had failed and the server intended for (the then new) System-Y was reconfigured to run System-X. When damaged System-X server was fixed System-Y was brought up on it.  Unfortunately, nobody remembered to exchange the labels on the machines. The entirely wrong machine was turned off by the very Systems Administrator that had remotely loaded both System-X and System-Y.

Which application would you not like to unexpectedly fail? A pretest would have turned this up in a maintenance window and saved embarrassment.  As this was supposed to be a machine that had been off about 3 months before the move, had no IP changes, and no driver changes; the customer specifically excluded it from tests. D’oh!

2)  A company moving out of a $250,000/month building discovered on move day that they had no one on staff who could remember how to stop and start an old DOS machine that had been running an essential program for years. After the next month’s rent (and several calls to keep circuits and utilities running) they called a specialist with experience to handle the situation.  A pretest would have flagged the problem in time to save that month’s rent.

3)  A car manufacturer was certain a server was only accessed through it’s FQDN so it did not get an IP address change as part of  the pretest. After the move it was discovered that several small parts suppliers had hard-coded the IP address (thus not using the FQDN at all).  When the move occurred the suppliers could no longer get to the application.  The result was a failure to receive specific parts (in this case Screws) for manufacture.

80:20 Rule

There will be failures undoubtedly with the numbers of failures that kick up during pretesting look like a spike.  I am taking the liberty of stating this as two uses of the 80:20 rule.

  • 80% of system failures are from people; 20% from machines.
  • 80% of system failures are from changes made that affect the system; 20% are the standing system unable to continue as normal.

When you apply these both, you get this breakdown of most system failures:

  • 64% are from changes made by people (change a parameter, upgrade a feature, etc.),
  • 16% are from changes made to equipment (memory or disk upgrades, the move, etc.),
  • 16% are from input changes (epidemic overload, new diseases, market spikes, etc.), and
  • 4% are from hardware spontaneously failing in place.

Fortunately this is almost completely avoidable through well run pretesting.

In summation, one of my life’s mantras is “No thinking on the weekends!”.  I rarely accomplish that completely; but in the finer discussion it is really defined as saving your 2:00 AM brain cells for real problems by avoiding issues for which you can economically test and build contingencies. That is in keeping with Six Sigma principles to put in effort to eliminate failures until the marginal cost outweighs the marginal saving.

Expect to see about four times the normal level of errors during the pretest cycle that you normally see.  If you do, you will still probably get a 1% failure to start.  That is about one-quarter of the normal run for engine failures.

You do not want to have even a normal level of failures spoil the look and feel of a data center migration.

Pretesting is just another tool to help you get to know peace of mind.

Comments?  Sound off below or contact us at IDMWorks.

Tags: , , ,
Posted in Data Center Migration (DCM) | No Comments »

The 411 on Data Center Migration (DCM)

Tuesday, February 1st, 2011

Even within IT most people do not clearly understand Data Center Migrations or why you would want to do them.

In a nutshell, a Data Center Migration (DCM) is moving technology.

They come in three general forms (and assorted hybrids of the three):

  1. Standing up a new data center and moving into it
  2. Relocation into a colocation site/facility
  3. Moving from one technology to another

Considering how much effort is put into Uninterruptable Power Supplies (UPS), generators, batteries, and other technology to keep equipment up and running, one can assume there must be a pretty good reason to shut things down on purpose.

Let’s take a look at why an enterprise may accept the risks associated with a DCM.

Existing Data Center Not Keeping Up

  • If your enterprise is growing or merging ,or just keeping more data for transaction research, you may outgrow your current capacity.
  • If your facility is aging you may find that maintaining its infrastructure is becoming problematic. Perhaps aging equipment cannot be enlarged or the maintenance costs are rising.
  • Upgrading on site is often not satisfactory because it may require operating without redundant support.
  • Many financial and healthcare enterprises cannot accept the risk of system failures even during a few days needed for an efficient upgrade.

For example, a hospital’s radiologist may actually read images using computer systems in a remote location. If we know which hour the system will be down we can arrange to have a radiologist come to the hospital to read images in person; but if there is a risk of failure spread over many days it may be difficult to keep a radiologist at the hospital 24×7.  This could leave your emergency room or surgical suite without the level of information to which they have become accustomed.

In another example, a broker takes orders to buy or sell in specific circumstances. If the systems fail, and a client misses a profitable opportunity, the firm is liable for the client’s losses. Or if a bank’s fraud detection system goes off line, in just a few minutes, the bank can incur substantial losses. A bank that cannot “balance up” with the financial networks may be subject to penalties. Similarly there are penalties in other industries for failing to meet audit requirements in a timely manner.

Therefore it is possible for an enterprise with growing IT requirements to prefer to build a new data center and move at a defined point in time to avoid a prolonged risk of failure at an unknown time.

Is Colocation the Answer?

For several years SaaS (Software as a Service) has been an acceptable means to support many applications.  In the last few years colocation facilities have become widely dispersed and reasonably priced. A colocation facility can be thought of as “Facilities as a Service”.

However, just as leasing a car is usually, but not always, less expensive than buying one; there are circumstances that merit building (or refurbishing) a Data Center rather than co-locating. For example, how will culture clashes be resolved or is there a graceful exit strategy or will they support the density of equipment that the enterprise anticipates?

Why Is Moving From A Technology A Form Of DCM?

There have been many studies of the cost of old technologies.  Have you noticed that the “Baby Bells” do not hang onto old equipment? The cost of maintaining it becomes burdensome. It is not just the parts. It is also the expertise. After a type of equipment stops being manufactured the training usually stops. Then for how long can you find people who know how to keep it running (without paying them a premium)?

When an enterprise decides to replace a technology they need to ask several questions. There are the financial and performance questions about the new solution but there is also the question about how quickly an enterprise can abandon the old technology so that they are not carrying the burden of maintaining it.

Some examples include replacing old categories of UTP cabling with new categories that are capable of fast throughput with fewer errors, replacing old phone switches with VoIP, or virtualizing applications. The quicker the completion of the migration to the new technology the greater the savings and efficiencies that can be recognized.

To summarize, whichever form of DCM an your enterprise may be considering, you should review the costs of doing nothing as well as the benefits of doing the migration. Additionally you must consider the costs of not completing the project on time and the risks of not completing the elimination of the old technology.

So what can IDMWORKS offer our customers and prospective clients?

  1. We can assist our clients to quantify the possible regulatory penalties and transaction losses along with the changes in risk levels to continue operating in less than ideal situations. This is often required by management to justify a project that represents a major distraction to business as usual.
  2. We can help a client determine if colocation is beneficial and, if so, which colocation facility is best aligned with their enterprises needs.
  3. We can be a third party counselor to check the vendors’ assumptions and coordinate research and execution of technology migrations.

Large and small enterprises need an experienced third eye on the ball to keep things on track. This is why  IDMWorks offers DCM services, so clients can stop worrying and get to know peace of mind.

Tags: , , ,
Posted in Colocation, Data Center Migration (DCM) | 1 Comment »