Customer Relationship Management (CRM)
Data Farm Inc.

The Technical "Know-How"
Home Executive Summary Investors Trade Secret Compression Encryption Data Streaming Business Intelligence
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?

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:

Data Center Migration Editor


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.

NAS

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:

1. Clone the database server(s) as a virtual cluster
2. Clone the operation system as a virtual cluster
3. Create a virtual cluster for the production application and its interfaces
4. Create a virtual network (we will call it Migrate-able Object) for the clones and the application
5. Test the new Migrate-able Object on the existing database box
6. If the Migrate-able Object passes, then move it to the new site
7. Build a NAS cluster with the application files and tables as a temp database or a placeholder for files and tables
8. Test the Migrate-able Object on the NAS cluster
9. If it passes them you can redirect the application clients to the new running Migrate-able Object with no outage or interruption of services
10. Migrate the entire database to the new site
11. In the case of moving one portion of the database at the time, the we would repeat the same 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:

Data Center database Migration using NAS Editor

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.
       Facebook Facebook Facebook Facebook Facebook
Thinking in
Tiers
Data Access
Object
Interactive
Front
Zeros & Ones
Plus Math
Data and
Databases
Check List Issues
Mobile-Browsers Standardization Templates Conversion Index Performance FAQ
Cloud Intelligent JSP Template Indexing DAO-XML Security Clients
Server Personal Multiple
Languages
Encryption Tracing & Transformation Errors & Logging Future
Security &
Communication
Business Intelligent
Shopping Cart
Compression Data Structures Scalability
(Expandability)
Big Data
Business Transaction Ready to Use
DAO
  Internal &
External
Flexibility CRM
Data Refactoring Server Traffic   CLOB & BLOB Transparency End-to-End
Mapping & Farming       Encryption Availability Intelligence
Web Services       Compression Latency Marketing
New Technologies       Security Brainstorm (Team) Sales

About us Contact Site Map Support Privacy Terms All rights reserved