|
FEATURED ARTICLE
THE AUTOMATED MIGRATION
BY MATTHEW ZITO, CHIEF SCIENTIST
As we start to head into the home stretch of winter (at least here in New York City, anyway), automation minds turn to thoughts of spring. Springtime, for many companies, is when new fiscal years begin, new projects begin, and old projects that were put on hold for holiday freezes resurface and start going again. One very common New Year initiative is the data center migration. A large, expensive project, a data center migration is best started at the beginning of the year, so that there’s no rush to get it done before the holiday season begins, or budgets run dry. Think of a data center migration not as an annoying, unnecessarily complex initiative, but rather as a way to start the New Year fresh – a way to take the cluttered, overly messy database infrastructure in your current data center and convert it to a standardized, automated, easily manageable new infrastructure. That infrastructure will not only be easier for you and your DBA teams to manage, but will also be more compliant, easier to document, faster in turnaround time for changes, and more reliable with less downtime.
There are two basic types of data center migrations, which can be colloquially described as “pick up and move” or “new gear” migrations. The “pick up and move” data center migration is when a new facility is purchased, leased, or built, and the bare minimum of infrastructure needed is installed to get the environment ready. Typically this can mean as little as some keyboard, video, and monitor setups; Ethernet and Fiber Channel wiring; and of course, all of the racks for the servers. Any other equipment purchased for the migration varies based on the organization – sometimes new network equipment will be purchased, but then storage and existing gear will be leveraged. Once that new purchased equipment is installed, everything else at the current data center is carefully powered down, unplugged, and then moved to the new facility. At the new facility it is reconnected, powered up, and application testing begins.
The other migration style, a “new gear” migration, is significantly more expensive. Instead of moving hardware from one place to another, all new equipment is purchased for the new facility. On the database side, this means new storage, new servers, fresh OS installs – basically starting from scratch all over again. There’s fewer logistics, since there’s no power down, and things can be migrated over at leisure, but it obviously has a huge cost impact, since there’s suddenly a need for 2x the hardware. These migrations happen when bringing online a new data center and the old one will become a disaster recovery facility, or simply decommissioned.
So which style is better? They each have their pros and their cons. Pick up and move migrations are much cheaper in terms of hardware, but whenever you try to move potentially hundreds of servers at once, plug them in at a new facility, and turn them on, there’s a huge risk that something will go wrong. It could be that the storage replication wasn’t configured correctly, or that the network isn’t up yet, or that the new network switches that were purchased aren’t compatible with the Ethernet cards in the current servers. QA gets very complex, and there are a lot of challenges surrounding tracking and identifying every individual issue in the middle of a massive migration. Buying a whole data center worth of new gear, on the other hand, is really expensive, but gives a lot more leeway for identifying problems as they come up, plus the migration process can be tried over and over again until it’s 100% repeatable. The downside for this method, other than the cost, is that it’s a lot of work getting all database homes, instances, patches, configured in an appropriate fashion. One side benefit of the pick up and move is that while the QA process is a mess, at least you know that the servers will be set up the same way as when you shut them down.
So where does automation come into play in all this? Obviously, with a migration being as much work as it is, anything that can cut down on the effort level is a positive thing. But there are certain specific benefits that automation can bring you that can turn this hideously complex process into something smooth and predictable.
For pick up and move data center migrations, it is extremely risky to make any major changes to the environment as part of this process – it’s ambitious enough to power down 40 servers, move them 100 miles away, and hope that everything works on the far side. But, as database servers are being brought online at the new data center, automation can be used to bring up all of the databases on all of the servers, or attempt to, anyway, and then generate information on which ones failed to start or had errors on startup. In addition, automation can be used to provide automatic QA of servers and databases that have been brought up – for example, you might have a process that checks the expected mount points, looks for ORA-600 errors in the alert log, logs into the instance and checks for offline tablespaces or newly invalid packages, and generates alerts and a report on the health of the database environment. This saves trying to have a user go around to every server, check every one of these items, and then keep track of which servers have been checked and which haven’t. Finally, automation can be used to see just what has and hasn’t been migrated over yet, while providing an accurate and complete picture of how things are proceeding, without tons of manual, error-prone effort.
When a data center is being built fresh with all new servers, automation isn’t primarily about QA (though it can help with that too); it’s about building the environment. Think of a new server deployment as a chance to start fresh. For example, if your production environment is running older versions of Oracle or SQL Server, a new server migration is the perfect excuse to get those environments upgraded. This is because with the extra hardware, the provision->configure->upgrade->migration cycle can be tested over and over again with zero risk to the actual production data. In addition, any new standards that have been defined around how environments should be configured (standard file paths, versions, enabled database options, etc.)[remove comma] can be baked into provisioning automation, allowing new environments to be rolled out quickly and easily, and, as part of testing, torn down again just as quickly. The automation ensures that at the end of the data center move, everything is secure, standardized, and easy to manage.
Migrations are painful, time-consuming events, and no automation can completely remove the complexity of these processes. However, automation can provide dramatic ROI for both major kinds of migration by driving predictability. It could be predictability of QA, or predictability of upgrades and deployments, or even just getting a realistic, up-to-date picture of where the process is. In all of these cases, automation is the blueprint for guaranteeing a successful migration with the least amount of pain.
Newsletter Home
|
