Three Things to Do when Migrating eQuip! To a New Data Center
One of the perks of my job is seeing my existing customers adopt a business process of Asset Management, and outgrow the server that they originally installed eQuip!, needing new space and new performance. It’s a good problem to have, and one that is easily solvable with the use of Virtual Servers. Most customers have reduced their cost of hardware and have adopted a vitualization approach that saves them time in provisioning new applications and giving them the ability to migrate to a new home. I am completing this exercise with one of my larger publishing customers who’s database has grown, performance needs grew, and they needed to find a new home for their eQuip! environment.
We are going through the same exercise too. As we bring on more eQuip! managed customers each week, we see the need for more throughput, more memory, more disk. We took advantage of our expiring lease to bring up new servers with the newest in virutalization to give our customers the speed and throughput they expect a managed application to have. Our new environment will be in place in the next few weeks and you will see some real speed enhancements.
Finding a new home for your equipment management software can be stressing to some, but it doesn’t have to be. Yes, I have heard that moving anything ranks up there with life’s most stressing experiences, and it is compared with Death, Divorce and a Tax Audit from the IRS. I have been there. We moved our office to new and bigger quarters last year as we expanded. It ranked up there alright, but we did some planning, made better use of space, and improved our network infrastructure at the same time. The same principles apply to moving an application to a new data center or new and larger server.
While planning for our server move, and helping our large publishing customer move to their new server, we did three things to them prepare for the move.
Step 1. Get all the stakeholders together to determine exactly what the expectations are, and what is really required.
Growing user base and concurrent users will create memory requirements for the server, and will require that care be taken in partitioning the server for the application and the database. Knowing how many concurrent users you have, and how many you want to grow to, you can determine how much memory to put in your application server. How many virtual CPUs are allocated per application server is answered by the amount of processing that has to take place. Normally for a system like eQuip!, with 10 or 12 concurrent users, you can get by with the system defaults (4GB of memory and 2-4 virtual CPUS). As the number of concurrent users grow, you need to have more memory to handle the growing application space per user, and more CPU to handle the processing requirements. This is easy to do in most IT data centers that are using enterprise virtualization. Most VM Servers have over 64GB of memory to allocate to their virtual servers, and up to 16 CPUS to allocate to each server. Not that all of that is needed by one appliation!
Also look at your network requirements. Setting up a database server on a separate virtual network, and having that network communicate with your application server will make data throughput so much faster.
Also look at your data requirements. Knowing that your users draw a lot of reports or do a lot of workflow activities should tell you that you need to optimize your database server for enterprise use. Having only one user hitting a database server in one day says you can have your database server and application server on the same machine. Having 10 users hitting the same application at the same time says that you need to have your database server on its own with server optimizations.
Having your stakeholders define who and when users typically access the system will give you the information you need to get the server environment right the first time.
Step 2. Define who is doing application updates and how these updates are done.
Have you integrated eQuip! with our API? Or do you have infrastructure components that periodically query the database, update the database or run scripts to get data into other applications? Our publishing customer made a list of all processes that run against the database . They analysed each process to determine what that process was doing and why it was even there. This is a great opportunity to look at our API as there have been a number of changes and improvements to make integration so much easier. Be that as it may, these processes will break because they depend on the old environment and time will have to be allocated to changing those processes to point to the new home.
Also look at how you are using our Audit Tables and History tables. After a few years of use, those tables are quite large. I have to digress here and say that I am a pakrat by nature. I keep everything and my biggest fear of throwing something out is that i will need it right after I throw it out. I know there are rules like “If you don’t use it or have not looked at it in over a year, throw it out” but i can’t seem to get beyond that. The same with audit tables. eQuip audits everything. Every time someone changes data, edits a form, installs an asset deletes data, we track it. We can show you who modified the data and when and settle disputes like “who changed this value without my knowledge?” or prove that some rogue bug in eQuip didn’t change data. These audit tables give you a complete history of the asset, the locations where they resided, and list of KPI data over a long, long period. These tables grow to over a million rows after a while.
One of the key functions of step 2 is to determine if this data has value, how you want to archive it, and do you really need it. Reducing these audit tables will save significant time in backing up data, in copying the database, and will increase performance of saves and updates of data. KPI data and performance data is valuable over time. You may want to define a second database to store this information especially if this information is actionable.
Step 3. Define your cutover period and who is going to install and test.
If you have a task plan, or gold level support, just pick up the phone and call. We can help you do this easily. Copy the database over to the new server. If you can export your app server and clone it on the new environment, do so. That saves time,and you can adjust the server for memory and processor CPU. You will need to activate your server, so you will need to contact our support hotline to get us to reduce your activation count. Unless you want to run on two separate environments, you will not require a license upgrade to do this.
During the cutover, you can use that time to upgrade to the newest release, do database optimizations to see what added indexes you need based on your use of the eQuip! DB, or do some data auditing.
As you can see, moving an application doesn’t have to be stressful, and can benefit each user. If you need our help, we are here to advise you and if you have the right service plan, we can even do some of this for you.