As you know, the cloud is a top focus for many companies these days and it’s becoming more interesting as they have to chose between a bewildering set of feature sets, cost menus, configurations that have no standards and concerns over availability, security and ease of migration and management.
- should we move to the cloud?
- how do we migrate with minimal downtime?
- which cloud platform provides the right mix of cost, availability, features and security?
It’s really the last one that has become important these days, especially in light of the Amazon AWS/CapitalOne breach. This post however is not about this, but about expectations.
A company within the insurance sector is already in the cloud for their enterprise application (Peoplesoft) but has planned a move from one cloud provider to another. Whilst the mechanics of this are probably complex, at the heart of it from my perspective is moving their database that supports SAP to the new hardware and mitigating any performance issues that arise.
Unfortunately they arose almost immediately. The migration process itself is simple – create a new virtual machine with the appropriate operating system, CPU, memory and disk. Of course the key words there are “virtual” and “appropriate”. This client was fortunate enough to have a dedicated physical machine with fibre channel attached SAN storage with their current cloud provider and must have performed some rudimentary costing/sizing exercise to work out what to move to.
Landing on Microsoft Azure, their initial machine sizing for QA (meant to be a full size production clone and provide near-enough performance) started with a D class server (D3, 8 vCPUs, 32GB memory and 6 1TB rotating rust drives. That put them about about $425/month cost and should have been the end of the story.
It rapidly became apparent that the database performed at a level that was unacceptable; batch performance elongated significantly, online transactions were slow and everything just slowed down. My investigation showed nothing untoward however. We had the same size SGA, fewer processor cores (the other physical system was a two-node RAC cluster database) and most importantly, the SQL was executing with the same plan as in production – it was just taking longer.
This was quite evident from the AWR reports I reviewed – db file sequential read had response times measured in hundreds of milliseconds so clearly this system was constrained by I/O performance.
To cut a long story short, we tinkered with multiple configuration changes before eventually ending up on an F-series server (16 vCPUs, 32B memory, F70 premium SSD storage) which provides much better performance and closer to the client’s expectations.
But…. $426 to $7,208…. Now that’s a price premium. So the moral really is that moving to the cloud (or changing vendors) is an exercise where one must be careful in realistically sizing for performance and capacity. The positive side to this is that they do not require more Oracle RDBMS licences because of the CPU characteristics but they will if they choose to pick the 32 vCPU option for even better performance.
The last point – they are migrating from physical servers to virtual. There’s risks and benefits from doing so and you need to understand how performance will be affected due to the significant architecture changes.