Blog

In recent time there have been increasing interest from customers, which move their critical workloads into public cloud platforms, based on IBM Power technology. These systems are mostly essential to these customers, but also hard to support and most of the time legacy and not well undocumented. When being moved to a cloud environment, these environments, which previously were based on dedicated Power systems into isolated data centers, are now part of an ecosystem, which defers significantly from the dedicated type of approach.

Detailed design can help a lot for the environments, however, in all cases a dependency is created from a new third-party vendor – the cloud provider. Whether that is owned by IBM or not, does not really matter, as day-to-day support is always organized very differently from before. There could be a significant amount of time until tickets reach to the right Lavel 3 expert personnel from IBM, and quite oftne that time could be of the essence.

Additionally, cloud resiliency works in a different way than on-site. In cloud, when you lose a Power node, your LPAR gets restarted somewhere else (if not (hard)pinned to a host) and if you want a better availability, you should plan and configure availability solutions yourself.

We have seen these providers plan extensive maintenances or take a significant amount of time to resolve an issue – physical node, networking, disks, etc., which is putting customers in really difficult situations. Unlike Intel-based systems, where customers are used to a bit flexibility when it comes to availability, the Power-based systems are usually seen as the stability islands, which are rarely rebooted, stopped or even re-configured.

That is why in some cases we get requests or we do recommendations to customers for dual cloud implementations, usually between IBM Power VS and Skytap on Azure. These are mainly customers, which have some established footprint in IBM Cloud and Azure Native and are eager to explore a design version, where they do not depend on a single cloud provider. We are seeing this trend increase and they are a few interesting aspects to it.

First, there is the matter of the location. As Skytap and Power VS have data centers in different locations around the world, a very important estimation is how close your primary site is to you. We have had customers, that we had to move from one provider to the other, because of late discovered latency issues related to an application, which does an enormous amount of very small requests (packets) and latency proved critical. So, location is critical for these implementations, also in relation to regulations. If by any chance you have more strict regulations where your DR data center has to be at least 200 km or more away from you primary, then you need to think about how to achieve that.

Talking about Power VS and Skytap, it is important to get one thing straight. Mixing providers for Power Cloud will mean that you will not be able to take advantage of the replication services of both suppliers. Template Copies in Skytap and Global Replication Service in Power VS cannot be utilized obviously when your other data center is from a different provider. However, bear in mind that for a number of customers these two services are quite unsatisfactory either because they are very slow (template copies) or use a determined pair of data centers (GRS), which might not work for everyone.

Talking about replication, of course, sets the focus on Disaster recovery. Here is where that dual cloud model really shines as the dependency reduces significantly. That naturally requires more advanced approaches to synchronization like Oracle DataGuard, GLVM or MIMIX and etc.

Then comes the question of connectivity. If you are just starting to think about moving into public Power cloud, you will very soon realize that the network design is perhaps the most critical part of your project. Here, we have no exception, on contrary, using two different clouds will require from you to know their network specifics and work carefully with their traffic charges.

We would say there are two main types of connectivity – basically because we need to stay short in this article and not describe EVERY single option. First, you have a direct VPN between Skytap on Azure and IBM Cloud. That will not require any connectivity to Azure Native – it is basically directly supported in Skytap. In IBM Power VS, however, you will still need the VPC and the VPN gateway there in order to VPN into the Power-based workspace. But this basically is charged per connections, so should cause any cost concerns.

Second is the most resilient way mainly in terms of traffic and speed stability. Using Azure ExpressRoute between Skytap and Azure and Direct Link into IBM Cloud. These types of connections, while of course more expensive, will provide a far better stability of connection and significant more throughput. We use them in 99% of the larger projects.

While these are the more important issues in dual cloud implementation you or obviously have to think about a few other things – for instance monitoring and backup.

When we do these implementations, we usually integrate a single backup solution in both clouds integrating it with their object cloud offerings. So, if you need to backup in Skytap, you backup on Azure Blob and on COS if you are in IBM Power VS. We usually situate CommVault media agents on both platforms and enable the possibility to restore in both clouds by replication the dedupe DB between the servers. That will give you the instance possibility to restore something in IBM Power VS, which you backed up in Skytap.

For monitoring, you either go with a wide spread enterprise solution, or you might consider a multi-cloud native solution, something like our own L3C Monitor, which supports monitoring of AIX, iSeries directly into Azure Monitor and IBM Cloud Monitoring (aka Sysdig). Thus, you will have the monitors for your IBMi or AIX systems together with your other servers in Azure or IBM Cloud. Alerting can be configured on the clouds or in the application itself, which is really easy.

In case you found that interesting and you want to see how would that look for you, contact us here. Best of luck in your dual public cloud endeavor!