 Yeah, hi, thank you very much for joining the session. So today we'll be talking about how to migrate to OpenStack in a painless and simple way. So my name is Nix Mironov. I'm CON co-founder of HighStacks, where we do live cloud migration and disaster recovery. And one of the cases is migration to OpenStack. But before we start talking about how to do it in a simple and painless way, so let's first identify the challenges we have when we do migration to OpenStack. So if you take a look at this slide, so there are a couple of different kind of pain points you might encounter when on your way to OpenStack. So let's imagine the case. You have a VMware, or you have bare metal, you have Amazon. Let's say, I don't know, 50 machines or something like that. And you would like to migrate to OpenStack. So first of all, first of the problems you have is differences between hypervisors. So you have ESX on VMware. You have different hypervisors on other clouds. And you need to migrate to KVM. And also the same problem you have with the volumes with disk. You have VMDKs, VHD, et cetera, et cetera. And you need to have a volume type supported by OpenStack as well. The second thing is different variety of network settings. So you might have NSX or different SDNs on VMware other clouds. And you would like to be able to run the same VPNs, load balancer, security groups, et cetera, et cetera on OpenStack. So you need a way how to do the migration. Another thing is how to understand how long it will take to do the migration. So how long the process would take. So you need to have some kind of expectation. You need to have some kind of forecast to do the migration. Downtime, another thing. So how long you can do the downtime, how long to expect the downtime during the migration, during the full replica or incremental replication. So what to expect there. And the last one is a lack of in-house expertise. So if you plan to do the migration, how to do that? So what skills you need to have, what is required to do the migration? So now let me share some thoughts on how the end-to-end migrations should look like. So first of all, when you start with the migration process, you need to identify what resources, what workloads you would like to migrate. You need to understand the machines you would like to migrate. You need to understand VPN, load balancer, security groups, and different network settings you would like to be migrated. The second thing, when you are done with identifying what workloads you would like to migrate, you need to understand the topology of your application. So you might have Active Directory, you might have LDAP, you might have databases, Oracle, SQL exchange server, you might have clients to the databases. So when you do the migration later, when you launch the application, you would be also... It would be good to be able to have an orchestration, just to boot Active Directory first, machines with databases after that, and clients after that, just not to have any kind of issues with the application consistency. Next thing is just to recreate the network settings. So when you are ready, you just do the recreation of network settings, you create the same VPNs, load balancers, firewall rules, et cetera, et cetera, on an open stack site. And later after that, you can do the replication of the data. Ideally, you need to be able to do the replication with the full replicas, and after that take incremental replicas. So in that case, the downtime for you would be less. So if you are able to do the incrementals, it's awesome. And when you have the replicas full or incrementals on the target platform, on open stack, at that very moment, you need to be able to test how the migration works. The best way is to do orchestrated launch of test migration. So you have all the disks, all the network settings on the target site, and that's their moment in an orchestrated way, either by some script or by a hit template or manually, you just do one by one, launching of different components of business applications. And the final step, when you are sure that the migration would work correctly, there are no any issues with the test migration, there are no any issues with performance, stability, et cetera, et cetera, you just plan and execute the final migration, the final cut-off. Okay, so let me briefly tell you how we do it at high stacks because we have a solution which does migration, like fully automated migration from any types of workloads to open stack. And usually with our customers, we do it in a four stages or four steps. The first step what we do are we identify what workloads we need to migrate as on the previous slide and we start the replication of the data. So we deploy agents, we start the replication, it goes in the background at the same time we can proceed with the second step. On the second step, what we do we recreate the network settings, like this step where it's currently impossible to automate because of different variety of network settings, different variety of like SDNs, et cetera, et cetera. And at that very moment, we also create migration plan. Migration plan is a scenario of what needs to be recreated, in what order, with what dependencies, with what flavors, IP addresses, Mac addresses, what needs to be recreated on an open stack. Later on the third step, we, as soon as we have full replicas and full replicas with a couple of incrementals on a target cloud, an open stack, we can launch a set of test migrations. So like from snapshots, we just boot machines in an orchestrated way, we provide customer with access to those workloads or we do testing ourselves just to see that there are new issues with performance, with stability and things like that, because like in the end of the day, two CPU on ESX and two CPU on KVM, it's not the same in terms of performance. So in some cases you need to adjust settings to get the same performance, to get the same results you had on your source cloud. And finally, when we have confidence, then we have understanding that the process is going correctly, we don't have any issues, we just plan and execute the final migration or cut over when we just take the final incremental from the original environment and instantly boot workloads in an orchestrated way from the incremental taken and switch DNS records and traffic to the target cloud to open stack. So the data flow for the migration looks the following. So for simplicity, we have for here only one machine on the source side and we have our application agent that can be external or internal agent depending on the platform, which replicates data to the target site, to the open stack. So here in the middle you can see our solution, basically it's deployed on an open stack on a target site as a virtual machine and you just need to have a floating IP address for that to be able to send data via HTTPS to the target cloud. When we send all the data, we replicate all the data, we create sender volumes and sender snapshots from all their incrementals for all the replicas we replicate. And later when we have full replicas and incrementals at this very moment, we can start migrations either test or final. In that case, we do orchestration, we do automatically P2V V2V transformation, so we change hypervisor, we inject drivers, we adjust network settings, not to have any kind of network mismatch and in that case, we execute migration. And this process is fully automated. So as I mentioned from the whole process of migration, what needs to be done manually is just to identify workloads which needs to be migrated, create migration plan and recreate network settings. All their business application migration, incrementals for replicas, P2V V2V transformation orchestration is fully automated. We have a very cute UI for that, just to be able to manage all the settings, just to download replication agents, run migrations, et cetera, et cetera. And in terms of supported platforms, we do support on the source site, we support any types of workloads where you can run Windows or Linux machines, either with external or internal replication, as I mentioned, and on the target platform, OpenStack is one of the core cases, like core targets, but also we support other clouds as well. If you have any questions, please feel free to ask. Yeah. It's running, so the question is where Highstack Sakura is running in the process of migration, so let me go a couple of slides back. So it's running in one of the projects in OpenStack on a target OpenStack, so you just deploy it in OpenStack, and you provide floating IP address, and all the data goes directly to the project, to the target OpenStack, so it's as isolated environment from the source environment to the target environment, and our solution is deployed as a virtual appliance on a target platform. So replication agent, so there are two types of agents, one is external agent, which is supported for VMware and for OpenStack, is a virtual machine deployed on a source environment, which for VMware, it uses vCenter API just to discover all the machines around it and start to replicate them. In case of internal agents, internal agents are Windows Service or Linux Service deployed directly on Windows or Linux machines. Any other questions? Okay, in that case, thank you very much, and just feel free to ask and feel free to reach me if you have any questions. Thank you.