IBM Db2 pureScale for HPC use-cases | Amazon Web Services

Key Takeaways

Hello everyone. My name is Eduardo. I'm a partner solutions architect on AWS. Today here with me we have Ryan. Hello Ryan. >> Hi partner solutions architect on AWS. Uh pleasure to be here. So Ryan, we have customers that are adopting different flavors of DB2 on AWS and one of those flavors is for high performance computing. It's called DB2 pure scale. What can you tell us about how customers can benefit from pure scale and what challenges does it help customers overcome? All right, that's a fantastic question. So the first thing to acknowledge is pure scale is a implementation of DB2 that is wildly different from what most people think of when they think about a relational database. It it it's not like uh you know the other database engines that we have on AWS where there is a couple of servers and you just got a database engine on there. is really architected and built from the ground up with that high performance compute in mind. So this is much more like a a full clustered relational database. So there's a lot of little bits and bobs underneath. So I think let's take a moment and have a look at this on AWS in a single a context and then let's build out what IBM has done with the product to address two things resilience and you mentioned performance for those. Now normally when we talk about high availability on as we talk about multi-AZ deployments >> absolutely correct but I think let's take half a step back look at in single A so we build a glass service let's build something that's potentially a little bit fragile from an AWS standpoint >> let's look at what IBM's done to make it very resilient within a single A and then we'll zoom out and look at how you can expand that across multiple A's or even multiple regions if the requirement arises >> right so single A here we go. So within a single AWS region, and we're going to do one availability zone just for the time being, what DB2 Pure Scale is ultimately made up of is a cluster that manifests across multiple Amazon EC2 instances. So we've got Elastic Cloud Compute and we deploy a cluster of these. This has got the full core mechanism. So if something had to manifest where one of these underlying compute components fails, the DB2 pure scale architecture is able to detect that recover from it. So it's got a built-in resilience mechanism to protect against you know failure of underlying compute. >> What you need to have some kind of orchestration there, right? And >> there is there's there's a lot of black magic happening inside DB2 pure scale. So this is not a problem that the customer needs to solve. That's all done from within pure scale itself. Likewise, when you're installing and provisioning the product, you simply tell it, am I deploying this into a single A or multiple A and it will build out the underlying architecture according >> and the deployment customers can get the benefit from the AWS marketplace. Right. Right. They can subscribe to the product and deploy from there. Right. >> Correct. is available as procurement from the AWS marketplace and then it is as simple as just filling in all the little tick boxes and it builds into your AWS account. >> Okay, >> what is very interesting here is when I look at database platforms uh it's become more prevalent to have like a shared storage layer. Pure scale doesn't use a shared storage layer in the way I was expecting. It builds on top of Amazon's elastic block store or EBS >> and the EBS volumes make use of our multi-attach. >> So this EBS volume could be attached to any one of those pure scale nodes. >> And it's interesting because when you said if we lose one instance then it means all the other instances also have access to the data. >> Still have access to the data here. Okay. >> Uh, from a resilient standpoint, this is very very clever. Means I'm minimizing the amount of provision storage. It's it's super lean in terms of cost and and I can float the storage around to the nodes. >> From a performance standpoint, you did mention this is for high performance compute. So there is usually a very high requirement for performance over here. So, what we're going to do is we're going to build this on uh our IO2 provisioned IOPS EBS volumes. And these can go, keep me honest here, I think it's around 256,000 >> provisioned IOPS if that is required. >> Now, this is using actually EBS flex, right, to give you that extra boost performance. Right. In terms of throughput, it can go up to 4,000 megabits megaby per second. >> Megabits per second. Yes. So you combine that throughput with the the payload with the IOPS to get an increased uh throughput on it. >> With the architecture here, what is very common for HPC customers is to add another layer of compute in here uh mainly to cater for read focused workloads. So we will very commonly see an additional set of EC2 instances usually two of them and these are caching systems. So we'll see two caching units added in so that we can store frequently queried pieces of information. We get that better read or analytics focus. Uh why two of them again that resilience model that if something happens to one there is redundancy over there. Now for the customers that need extra performance and maybe all this part on on the on the block storage is nice but from a networking point of view how can they guarantee that they get that performance boost so that they're they don't see the laser bottlenecks from the TCP IP level stack or you know uh CPU interruptions or having to go through the uh through the operating system kernel. What is it that DB2 pure scale can do? So this is something where IBM and AWS have come together to do something very very fun. We've not just taken the best of EC2 and the best of EBS, we've combined it with what DB2 Pure Scale is doing in the background. So the first thing that we're taking advantage of is we're selecting very specific EC2 instance types that have the ability to support Amazon's elastic fabric adapter or our EFA interfaces. These are you can think of them as high-speed fiber channel interfaces but for your virtualization stack on top of AWS. So the EFA adapters provide a high-speed networkdriven connection ultimately to link us to our storage and to our other nodes. The EFA on its own is is is very cool. But when we combine it with uh remote direct memory access or RDMA, we're taking advantage of a technology at the network adapter level where interactions to the storage or interactions uh with the software to the storage don't necessarily have to go through as you mentioned the operating system kernel to talk to those components. We bypass that and go through processing at the network adapter. >> That means that the EC2 instances they can access me data that's in memory directly between the different instances. >> Correct. As as well as other external entities such as some of our >> it also prevents like having to duplicate data around different instances. Right. >> Well, there's a couple of benefits here. The first thing is you're skipping over steps of the traditional computing architecture making it faster and and we've seen that in many cases. You've seen that with GPUs for example in in other use cases. This is another compute layer sitting at the network adapter level. The other benefit that we get is we're also able to bypass components of the networking transport protocols TCP and UDP. >> Correct. So UDP being very very fast but it doesn't have a lot of safety blankets in it. TCP giving you the polar opposite very very reliable but slow because it's validating each step. We're able to take advantage of other protocols that speed up this process. So the access of switching information around is significantly faster. And what IBM's DB2 pure scale has done is bring a very resilient architecture and stack that on top of items in AWS that provide a complimentary resilience and in this case a very very slick performance benefit >> and that's the reason why you need it in a single a right to get them >> as close as everything as close as possible to each other and the workloads. If you looked at this from uh other AWS constructs, you might actually see customers take advantage of things like placement groups where when they launch their EC2 instances, those are on underlying hosts as close to each other as well. If you really wanted to get as much performance out of it as possible. >> Now, one thing Ryan just to tell to our viewers is the EFA and RDMA option. They're available today on the marketplace for DB2 pure scale deployed on Red Hat Enterprise Linux. >> They're also available on uh Suzu Linux. >> But Suz is only supporting right now TCP IP. >> Okay. >> Okay. So that's something to to bear in mind, right? If you need the EFA and the RDMA capabilities, >> go with the Red Hat Enterprise Linux option. Now the other thing is obviously you've designed here three EC2 instances and two caching instances but you can scale this right we can scale this right so let's take a step back and let's go and have a look what happens in DB2 pure scale if you enable certain flags to allow this to span multiple AWS availability zones and in so doing protect yourself against something that could potentially manifest or fail. bill if an A had to be impacted because in this design you do have resilience but if the AWS availability zone is in some way impacted everything here is going to be impacted we want to add a layer to protect against that so as I was saying let's zoom out a little bit and have a look at what happens if we do this in a multi-AZ context text. So, let's add in some more availability zones. Uh, most customers I work with are going to have three availability zones within their region. They're going to span workloads across them. Uh, in this case, I think for illustration purposes, we're just going to use two of these availability zones. Normally, when you look at something built on AWS that spans availability zones, it spans the availability >> the same application across the availability. >> Exactly. the app would be. So my initial expectation was that because there's three underlying compute nodes that make up the cluster, you would see one of those nodes in each availability zone. However, we didn't do that because this is a cluster catered for high performance compute. The idea is to have the entire cluster and all of its components in a availability zone as close as possible to the applications, but it does create a bit of a glass service. I've got something that is super resilient >> as long as the availability zone's working. The minute the A experiences problem, everything fails. >> So you're essentially going to use different a to do a DR scenario, right? >> Correct. This is identical to what Amazon does with uh our red shift service. >> So if you look at redshift, we build a highly resilient cluster in a single a. If you want more resilience, you deploy that cluster again in the next a. So if we look at this from a DB2 pure scale perspective, you've got all of the components of pure scale. So your actual cluster cororum and your additional caching nodes inside the a and then what I can do in the product is I can actually go and enable a flag inside DB2 called DR enabled. And what the DR enabled does is it then says well I can now go and deploy an additional >> DB2 pure sale cluster. And this is going to be in standby, not an active active deployment, right? >> This is not active active. Uh the DR enabled actually goes and adds in HA DR. This is the same HADR that customers are familiar with the DB2 product platform in an on- premises context and it's going to replicate the changes uh between these. This will be a a synchronous replication >> because you're having to replicate all the EBS data >> because ABS is an Abbond service, right? Multiattach is relevant with inside this availability zone. It's relevant over there. But I can't perform multiattach from here into that a. So the hr layer is facilitating. >> No need to use any additional services technologies. You're using pure DB2 services that you know DB2 administrators are used to. >> Correct. >> Um and of course just very very easy to flag enablement within the product enables it and then the customer is inside territory they are familiar with. If we want to expand this further and we want to have a look at this from a multi- region DR perspective. So let's very quickly add in another why would customers look for multi-reion DR perspective right most of customers that we talk to they have DR requests where they have a data center in a location and another not but they're close enough that they can be on on a single region multiple tell us about multi-reion vast majority of customers can achieve their DR requirements with just two availability zones in the same region there are however customers that have a high risk avoidance profile and they are trying to protect against something that could impact the entire region. Something that could impact multiple availability. This is highly unlikely but they do have a risk profile where they have to protect against that. This may be regulatory compliance. This might be a compliance that's internally in that institution. So they're usually following orders from upstream over here. As I said, very expensive to architect against. It's not the first step I would do. I would solve the single region multi-AZ problem first before I jump into multi-reion. But let's say for example, we do have a requirement for multi-reion. We want to protect against alien invasions and in the cataclysm. Here we go. So what we're going to do is we're going to deploy uh pure scale again in my adjacent region. Again, we're going to see that same highly resilient architecture with its caching layer coming into there. We're going to use HDR again, but is it going to be synchronous now because you have the network latency issue >> in this case because you've got that increased latency of going to another region. Now, I mean, this could be a region here in the US on the east coast linking to the west coast. Uh, I've got one customer that's doing some very exciting stuff from Canada all the way to Ireland. I got a question mark and I ended up being that if they did it from one side of Canada to the other side of Canada, there isn't actually a significant difference to going all the way to Ireland. It's about the same distance, the same latency. Canada's a big place. >> So in this case, what we're going to do is we would have asynchronous uh replication with the HDR. this becomes a recovering cluster. It's not going to be there to scale out performance or workload. That's what's happening over here. And in the event of a system failure here, you could cut over to that other region. Uh maybe set it up the other way around, but what's more common is to run in that region and then eventually fail back. Now from a networking point of view I see here that maybe you know could be essential to use a trans something like a AWS transit gateway. >> Correct. So bearing in mind two things here. Uh there's a couple of ways you could do this. You could do this with VPNs. You could do this with uh VPC peering. the the more modern better way of approaching this from a performance simplicity and cost point of view is to take advantage of your uh AWS transit gateway and that would then facilitate the routing between these two uh regions. This could be between multiple AWS accounts. It's also very common to see on premise >> going back to on premises because these are large scale historic customers. They're going to have a hybrid footprint. So that transit gateway is going to be in the middle of all that. >> So it's going to give you that hub and spoke architecture where you can connect multiple things together. Right. >> Correct. So as you can see DB2 pure scale available from the AWS marketplace built from the ground up to be highly performant highly resilient lots of things where we're taking advantage of the best of IBM the best of AWS and a lot of our options to meet your resilience and fit into your organization's architecture >> from a licensing point of view Ryan can customers bring the systems they already have on prem with the licenses that they already have how does that translate IBM licenses on prem into AWS. That's a common question we get always. >> So there's there's something to bear in mind here. The answer very simply is yes, you can use the licensing subscriptions you have already for your on-remise environment. The only caveat is pay attention to the older licensing model was a PVU based licensing model that doesn't directly compare to AWS. uh we are going to see licenses for the VPC licensing type that are linked to vCPUs not to the PVU value allocation for a processor. So if you are on PVU chat to your IBM uh licensing team and and would convert that to uh VPC and then you can bring it into there. But if you're already on VPC it's the exact same license. You can just uh do it as a B yol and and deploy it on AWS. In fact, if you've bought a bulk batch of VPC licenses, uh you could have some of this running on AWS, some of it running on premises, wherever your hybrid estate takes you. >> All right, this is awesome. >> I hope that addressed all of the questions. >> Yes, it certainly did. And I think it really helped our viewers understand how DB2 pur scale can run on AWS, take the benefits of AWS cloud, the scalability, all the technologies we have for high performance computing, uh high performance discs and you know networking. I I think if you look at it, it's it's not wildly different from DB2 in in a relational database context. I think the big difference is you're catering for high performance compute. So you're going to see a lot of those decisions made in the context of HPC, your biggest change is this cluster footprint being something that you're going to duplicate over and over. So going into that high performance compute space, this is something that is going to have a slightly larger cost footprint straight off the bat, >> but you need that for you need that computing power for these use cases. Yeah. >> And it what Thank you. It's as always a pleasure. >> Thank you. See you next time.