|
Data Center Migration
Introduction Data Center Migration is the process of deploying and transferring an existing data center environment to another data center operating environment. Migrations include hardware, software, storage, network equipment, cooling systems, power supplies and data. Searching the internet for the cost of data center migration and downtime, both costs are substantial . The average data center relocation costs $120,000 or $10,000 per rack and one minute of data center downtime costs US$7,900 on average. We can also add the management and testing of the new center is critical to reducing the cost. Use Case: Migrating Data Center Using Object Oriented (OO) Description: We believe that using good management, virtualization, intelligent building tools and automation would reduce the cost of migration and the running data center to a fraction of what is done today.today Briefly Describe This Use Case The guzzle of building or migrating data center rests the shoulders of management and building-migrating processes. For example, if you compare the cost and time of building power plants in 1960s and 1970s, you would found that the cost and time between different companies range in billions and tens of years. The main difference between these companies is their performance in term of good management and the use of latest technologies. Therefore, we believe that our approach of using good management, virtualization, intelligent building tools and using the latest technologies would result in saving $billions and years of construction. Primary Actor: Executives, stakeholders, Infrastructure directors and architects. Goals: To present a solid and sound approaches with an architect which removes any doubt about we are presenting. Analysis Migrating Data Center Using Object Oriented (OO) Can we use Object Oriented Design to migrate Data Center? Again, our answer is a definite "Yes." First, Data Center Migration is a different animal than Data Center Building and it may not be a piece of cake. Time, cost, errors-issues and effort may vary based on what these data center are running and how fare and where they would be moved to. Breaking a running data center to components or objects is not an easy task. These centers are running systems with supporting networks which have numerous setting and parameters and may not have any documentation. Migrating them is not an easy task. The Migration-able Objects are different than the Building ones, but still we are providing an editor for creating Migration objects. We are presenting the following topics on our approach to migration using OOD: • Migration Definitions and Issues • Object Oriented Design and Migration • Quick Plan • Key Ingredients and Inventory Matrix • Basic Migration Classes • Data Center Migration Editor • Database Migration • Using NAS as a Temp Database or a Placeholder • Data Center Migration Editor • What would take to make Data Center Migration doable, Intelligent and within budget? Migration Definitions and Issues: Data Center Migration is the process of deploying and transferring an existing data center environment to another data center operating environment. Migrations include hardware, software, storage, network equipment, cooling systems, power supplies and data. We would leave the facilities and building infrastructure to their experts. Our focus is on the networks which include hardware and software. With the assumption that the data center is running development and production environments and everything in between including load testing and user acceptance and post production testing plus maintenance. For issues, there are too many "How" questions about the hardware and software including: How Old or Obsolete? How out dated? How many are not used? How many need to retire? How many need updates? Architect Object Oriented Design and Migration: Our focus is on how to perform the migration using Object Oriented Design and Virtualization. Turn Data Center Migration into Object Oriented Design, we need to turn both hardware and software into virtual objects or classes. We would turn each data center running feature or component into an object. Quick Plan: Our simple for formula Migration is as follows: (Migrate-able Object) = (Source-Feature-Component) - (Need to retire feature or components) + (New features) + (Contingency plan) The goal is to create a Migrate-able Object which means a virtual or a physical component that has OOD features for temporary building, migrating and testing. We need to do the following processes: • Build an inventory matrix of everything on the data centers networks • Divide the list in what we call Source-Feature-Component - for example a running application with its database and interfaces • Create an Migrate-able object(s) for each Source-Feature-Component • Create migration contingency plan for the object failure • Create a test environment for the object • Test the object • Run the object in parallel with the Source-Feature-Component • Stop the Source-Feature-Component • Move the Source-Feature-Component to the new site • Test the Source-Feature-Component • Release object resources to be reused or reuse the object These must be done in parallel with speed and there is no room for errors. Key Ingredients and Inventory Matrix: The key ingredients are: • Detailed inventory of both software and hardware • Existing issues • list of the expiration dates on both hardware and software • What will be affected by the migration. • Budget • Timeline We need to create the following entries into excel matrix or text file to be able to load the values into our Migration Editor: 1. Item ID (give each item and ID fro tracking) 2. Item Name 3. Status 4. Priority Level 5. Expiration date 6. Target Object - Migrate-able Object 7. Need to Retire 8. Update 9. New Features 10. Issues name 11. Issue Description 12. Possible Solution 13. Assumptions 14. Test Plan 15. Manpower -Talent needed 16. Timeline 17. State Date 18. End Date 19. Service Level Agreement 20. Estimated Cost 21. Comments We would be divide the matrix into Source-Feature-Components and create a Migrate-able object for each Source-Feature-Component. Basic Migration Classes: Our Migrate-able Class is basis of migration, and it inherits or extend ServerObject. Migrate-able Class declares (composed of) a number of subclasses with its creation as follows: Dependency Class - inherit-extend ServerObject{ // keeps track of dependencies Properties (related items) Methods (processes and steps) } Exception Class - inherit-extend ServerObject{ // handles errors and exceptions Properties (related items) Methods (processes and steps) } Testing Class - inherit-extend ServerObject{ // has all the test cases, sceneries and test values Properties (related items) Methods (processes and steps) } Validations Class - inherit-extend ServerObject{ // validates all the components within Migrate-able Class or object Properties (related items) Methods (processes and steps) } Migrate-able Class - inherit-extend ServerObject{ // replaces Source-Feature-Component Class Name Class Type (Virtual, Physical) Target Name Target Type (Virtual, Physical) Start Date End Date array of [dependency] array of [exception] array of [test] Validation Object Properties (related items) Methods (processes and steps) } Data Center Migration Editor: We are building a Migration editor. This editor imports the existing hardware and software inventory from a text or excel file (Source-Feature-Component) and creates a virtual Migrate-able object which contains all the needed Sub-Server and management and documentation containers. It has arrays of dependencies, exceptions, tests. A validation object is created with these arrays. We added Questions and Answers section to address issues by starting asking the right questions. Migration Editor Image is a link to Migration Editor page: 
Database Migration: Migrating the entire database to new site is a challenging and testing it could be even more of a challenge. We need to use the "divide and conquer" approach. Once we identified the Source-Feature-Component and its Migrate-able object. We can use Network-Attached Storage (NAS ) as a temporary database and store in it only the tables associated with Source-Feature-Component. Such process can be repeated to point where moving the entire database server to new site is feasible and can be tested. 
Advantage using NAS: • Inexpensive hardware • Can be treated as an object or class properties • NAS can be an independent node and has its own IP addresss • Programmable • Stored data can be converted back to the database • Easy to install and use • Easy to move around • Easy to test • Reusable • Can be used as Database Visualizer Using NAS as a Temp Database or a Placeholder: How can me move the entire database(s) or a portion or chunk of the database(s) to a new site without any production outage? Our answer is using NAS as a temp database or a placeholder for the running production applications. NAS is used as a buffer or a placeholder for literally every major database. The major issue is any running database has numerous settings, indexing, queries, etc which they could not be duplicated on the NAS. Our answer to this issue is the following steps:
Data Center Migration Editor: We are building a Migration editor. This editor imports the existing hardware and software inventory from a text or excel file (Source-Feature-Component) and creates a virtual Migrate-able Object which contains all the needed Sub-Servers and management and documentation containers. It has arrays of dependencies, exceptions and tests. A validation object is created with these arrays. Migration Editor Image is a link to Database Migration Using NAS Editor page: 
What would take to make Data Center Migration Doable, Intelligent and within Budget? Doable and Intelligent: Object Oriented Design can be used to convert software and hardware into tangible objects. These objects store in details all the data center's processes and the hardware and software information. Management and documentation are also converted into similar objects. The objects are used as the basic data structure for building intelligent software tools. The data and processes stored within these objects can help similar human intelligence with questions and cross references. They would provide options and errors checking and run statistics tracking performance and issues. Such tools would automate data center migration. They can be reused-inherited in other migration projects. Within Budget: A migration pilot project must be created and test first. Such a pilot project would neither be costly nor takes a long time. It would be the basis for OOD reusability and setting plans and processes for the rest of the migration. Creating the rest of Migrate-able Objects would easier and cost effective. Migrating these Migrate-able objects must be run in parallel and resources are reused and recycled. |
|---|
