Using Microsoft Azure infrastructure and Silk as an I/O service platform, enterprises can run their workloads faster, better and more efficiently than other cloud options. Silk + Azure offers superior I/O performance and data management features over traditional public cloud I/O service offerings. I/O rates up to 10x faster than native cloud, dedupe, and cloud snapshot technology all enhance the Azure cloud experience and make it more ‘SAN-like’ when Silk + Azure is utilized.
While public cloud PaaS and IaaS services offer tremendous capabilities in terms of elasticity and flexibility, they come at a cost in terms of operational control and software lifecycle management. While this applies to nearly all public cloud DBaaS services we will discuss Oracle E Cloud Exadata as a specific use case.
A variety of Oracle databases remain on premises even though many organizations have mandates to move their mission-critical Oracle workloads to the cloud for financial and techno-strategic opportunities. In my last blog, I reviewed the value proposition of using SharePlex to migrate Oracle databases from on-premises to Azure with Silk. This blog will attempt to show the techniques involved to move an Oracle database from on prem to an Azure + Silk cloud solution using a replication technology software known as SharePlex. The use case scenario is to replicate the Hammer DB benchmark TPCC schema from one Oracle Linux server to another using a Silk Data Pod (SDP) as the underlying storage for the target database. This will show the basics of migration to Azure + Silk as well as highlight the interoperability and suitability for SharePlex as a primary migration tool to do this.
One of the challenges of an Oracle Exadata migration to non-Oracle Exadata (but still Oracle) platforms is Hybrid Columnar compression and an IOPS and storage size “explosion”. Exadata’s much touted I/O capabilities are, in fact, impossible to accomplish on native cloud I/O including Microsoft Azure Ultra Disk. The capabilities of the Silk Cloud DB Virtualization Platform I/O easily match Exadata configurations and offer additional features such as snapshots, asynchronous replication capabilities, and high data compression ratios. Silk’s operational simplicity and automation are integral.
Operationalizing an Oracle database on Azure IaaS includes setting up an RMAN backup schedule much like the backup patterns used on premises. This is is important because despite whatever media you might have as a primary storage mode – it can fail. A backup destination based on a different tech stack is required for true recoverability in this case. A cost effective scenario would be a combination of near online RMAN backups in the Silk-based ASM Diskgroup +FRA and an ‘offsite’ or rather off platform/region standby and/or backup plan. This gives both good recovery time objective (RTO) and high durability (MAA). DBA best practices dictate that you have multiple copies of the data—on different media — a BlobFuse backup destination checks this box.
Oracle Automatic Storage Management (ASM) is an Oracle proprietary volume manager and file system technology that optimizes storage and management functions for Oracle. Taken together with Silk, they can form a very powerful robust and performant I/O sub system for mission critical database intensive workloads. ASM accomplishes this with DiskGroups, and ASM instances – a special kind of Oracle database instance that serves up I/O to subscribed database instances. Let’s discuss ASM a bit first and then show how Silk leverages ASM to provide best of breed performance for critical IaaS DB workloads.
One of the most ‘untouchables’ of the ‘untouchable’ workloads are AIX and Solaris hosted. These are the traditional ‘Big Iron Unix’ go-to platforms for large enterprise workloads. Each is based on a company specific RISC Chip: Power PC in the case of IBM and Sparc for Sun. AIX and Solaris are the correlated Unix OSes for each. A good number of high value, high activity on-premise workloads are still running on these RISC based commercial Unix platforms. These ‘classic’ 64-bit RISC chip-based Unix operating systems are nearly identical to Linux (or rather Linux is nearly functionally identical to them as they pre-date it). But they are of a different word byte order.
One of the most complex and common enterprise application suites available today is Oracle E-Business Suite (EBS). EBS is perhaps the poster child representative of ‘stuff that will never be fully refactored’ due to its massive size and complexity – EBS is actually an enormous collection of PL/SQL, Java, miscellaneous code, databases, web applications, business process and functions that are wrapped together in a semi-integrated suite. Nearly every Fortune 1000 company has parts of EBS running somewhere, with a massive ecosystem of Oracle and other 3rd party (usually custom) ancillary processes, programs, feeds, and targets associated with it. It is usually at the center of the business function enterprise application ecosystem and as such generates an enormous amount of data gravity around which the vast majority of the other corporate applications revolve. EBS is a huge gravity well that keeps most other applications firmly tethered to where it lives. EBS leverages an n-tier architecture with (currently) over eight hundred different schemas and many thousands of tables.
Among its many incredible capabilities, one bonus of the Silk Cloud Platform is its ability to prevent cloud overprovisioning. This amazing capability really resonated for me recently. I was provisioning an Oracle server from the Azure Marketplace, and I ran across the below chart. Maybe this is old news for some, but to me it is immediately clear that you must max out resources to get max available I/O. And the delta between the middle and the top is huge. If I needed just 4TB to accommodate my small but very heavily utilized OLTP RDBMS – I’d get only 7500 IO/sec. I’d have to max out to 32 TB to get the maximum listed throughput of 20000 IO/sec.