 Good afternoon all. This is Deepak. I'm a trek chair for this trek, evaluating OpenStack. And today, we have our friend, Wamsi from HP, who will take us to an interesting topic of OpenStack, a popular destination for legacy IT. So hand over to Wamsi. Thanks, Deepak. Good afternoon, everyone. In this session, we'll see some key differences between the legacy environment, our legacy data centers, and the cloud operating systems. And in this journey, we'll also look at the methods to migrate from the legacy environment to OpenStack. So that's myself. My name is Wamsi. I work for Hewlett Packard Enterprise, and I'm a solution architect for infrastructure. And from an agenda point of view, we'll start with the OpenStack origins, which most of you might be knowing, and it's going to be a real quick one. And we'll discuss the various OpenStack projects followed by the migration of the legacy environments to OpenStack. And then we'll conclude the session with a simple Red Hat OpenStack 10 installation demo followed by Q&A. So this slide is really the very basics, which you all might already know where the OpenStack triggered its birth. So this is the actual email that was sent by an executive at Rackspace to the CTO of NASA at the time, essentially inviting them to come along Rackspace and create a new OpenStack platform. So this was done with the merger of Swift and Nova, which is based on storage and Nebula platforms. I hope you are familiar with this one. And now let's compare legacy IT and OpenStack. Here are some key projects, which are common to an OpenStack environment, which have been broken down just for the sake of conversation into networking, storage, compute, delivery, and operations. So in your legacy environment, you might not be using software-defined networking, but today, many environments are considering that move to software-defined networking, which is a common standard inside of OpenStack. OpenStack Neutron is a software-defined networking project which is focused on delivering networking as a service in virtual compute environments. Neutron has replaced the original networking API called Quantum in OpenStack, which was developed before. And then we move on to the storage environment, where we typically have SAN and NAS, which run block- and file-level storage within our environments that typically run within the operating system. And the file system, that's in the operating system, like Red Hat or Microsoft Windows. So in the OpenStack world, we have Swift, which is an object storage. Cinder, which is a block storage, and provides an infrastructure for managing volumes in OpenStack. We also have Glance, which provides a service where users can upload and discover data assets that are meant to be used within other services. This includes the images and metadata definitions. So we now move on to the compute virtualization layer. That is, most of you will be familiar with, the VMware Hyper-V, KVM, and those type of things, which where we are managing the VMs. And the images for an example in the VMware environment that's going to be your ESX type of services, ESX type of things. So all these things manage the compute environment. Now the bare metal recovery that is built into automation is typically seen in our legacy operating systems outside of the OpenStack, although there are software products that are common and that can do this. The bare metal inclusion into an automated infrastructure is a great attribute for OpenStack. And now when we move up to delivery section, we have messaging. And it's not the SMS, but it's the DNS and common identity service management. And of course, your LDAP, Active Directory, those type of things. And the key management is usually found with an HMS type of solution. So all these are, again, integrated into your core operating system. And then the operations, really. Take the dashboard and the orchestration engines here, which are separated into operations. And you move them down to the compute. And of course, the databases like SQL and non-SQL are the file systems that are managed within the operating system. Now this is really just a summary of OpenStack. Those found in red here are those components that are found in our legacy environments today, which you already might be familiar with. Hopefully, this has been a quick review of those projects. Now let's see how this legacy environment is replaced by enterprises and how OpenStack comes into picture. So enterprises are building clouds to the resource needs, timelines, and to monitor the entire environment. Of course, the return on investment is a major factor that contributes in making this decision. So initially, we started with server virtualization. And then we have scaled virtualization to a level where enterprises are trying to move to the cloud data center. And this could be confusing due to a vast number of applications and a number of VMs running on them. And the factors that finally contribute to move to the level of cloud federation, which is the practice of interconnecting the cloud computing environments of two or more service providers for the purpose of load balancing traffic and accommodating spikes on demand. So as stated earlier, we have started virtualization at the host level, where we have many instances in each of these hosts. And of course, this is at a hardware level and also at the OS level. But here, we are not satisfied here that the storage and networking devices, sorry, storage and networking are also being virtualized, where efficiency and resource utilization is the key when it comes to the application stability. But the question arises when the enrollment grows and when you have, say, at least 20,000 VMs running and thousands of data stores with numerous virtual network adapters, VNICs, and you have these questions like, how do you manage your apps to be cloud-ready or which applications will be moved to cloud? Or how will you provision the VMs? And how the automation will be taken care of? So this layer is found in the cloud management, which is definitely missing in our legacy places. So the solution is OpenStack, which connects applications through APIs and automates network and also solves all those questions that were raised in the previous slide. So now we have moved to the cloud. And with the aid of OpenStack technology, businesses and institutions make compute resources available to customers and partners to create more capable, scalable, flexible, and cost effective enrollments for application development and hosting. A next step in this evolution is to have the cooperation of providers of cloud services in which customers require one cloud to be fulfilled by another under the mediation of a brokering structure. Imagine having a common platform across cloud seamlessly transporting workloads. Let's take an example to illustrate this, which is on the top left-hand corner. We identified two basic dimensions of cloud federation, horizontal and vertical. While horizontal federation takes place on one level of the cloud, the application stack vertical federation spans multiple levels, like you see middleware and infrastructure as a service. Considering a business providing software as a service offering from a private or public cloud, so users submit requests to the application layer, which accesses sufficient local resources available to service request within a specified time. If the application layer cannot meet its service goals, it can optionally fulfill the request through an independent SAS layer provided by the same service as indicated by the horizontal line, which is the federation, connecting cloud A to cloud B. Results are returned to the user as if locally produced by the application, executing in cloud A. So again, the solution is open stack enables cloud federation, and federation is critical for open stacks long term success and momentum. So now the enterprises that use open stack is what I have copied from when we entered the building. Now let's see migration to open stack. So these are the basic steps required to migrate any kind of enrollment into open stack from legacy. So we have the discovery analysis phase, which is basically the due diligence. And then migrate from anywhere to anywhere from any kind of legacy enrollment to open stack. It could be AWS. It could be Azure. It could be open stack from any vendor. And then we check the cloud API support for the applications, which, as to see, which applications are cloud ready and which can be migrated to cloud. And automation, of course. This is where cloud comes into picture, through end to end automation, point to point migrations. And then once this is done, a final sync between the source and the target is done. And security is taken care of. So these are the various migrations options from the legacy DC or from the legacy environment to open stack or VMware, Rackspace, AWS. The basic migration strategy is the same. Now we'll go through the Red Hat OpenStack installation. So these are the basic requirements for the Red Hat OpenStack platform 10. And this is based on the Newton OpenStack release. Logging is configured on each node. And Red Hat OpenStack 9 is not so user-friendly, but 10 is GUI. So the deployment of the overcloud and undercloud can also be performed using GUI, however, I have done using the command line. And I have illustrated the Red Hat OpenStack platform. I've done this in my labs on the HP Proline service. However, these deployments can also be done on the IBM service and on the Dell hardware. And I have mentioned the references over here. So I've done this on the HP Proline DL 360s Gen 9, where we have the compute and controller nodes running on Red Hat 10, Red Hat OpenStack 10. And the hypervisor is 7.3. 7 pluses is the requirement. And these are the various service specifications that can be used for installation of the Red Hat OpenStack. And we have various combinations here. So for the director installation, we have the requirements, which is it can be a physical or a virtual. Hypervisors could be KVM, Red Hat, Hyper-V. It could be anything. And the minimum requirement is 8 cores, 16 gig RAM, 40 gig disk, and two networking interfaces for the overcloud and the undercloud. And before we start, the following repositories on the Red Hat should be enabled. Now while installing the undercloud, we create a director installation user for the node director. And we go through creating the directories for templates and images, then enable the repositories for installation of the triplo client. And we configure the director on the file undercloud.com, issue the command OpenStack undercloud install. And then the next step is to introspect the kernel and to deploy the full Red Hat OpenStack image. And we set up the name server on the undercloud neutron subnet. And we have the basic undercloud ready. And here we have the images. Once the undercloud is ready, the OpenStack image list, it gives the basic images that are required for the undercloud. And this is the configuration file that I have made for the undercloud, undercloud.com. And we have the local IP. And here are two ethernets, the BR control plane, which is given for the introspection, the IP range. And then once the undercloud is ready, we configure the overcloud. And to configure this, we create a node definition template and register blank nodes in the director. And the JSON file, which is on the top right hand corner. And then we tag nodes into profiles, rules, and then define the root disks, which would be on the basic overcloud, creating custom interface templates and triple O heat templates. And here we can create additional node properties as and when required. You could add any number of nodes to this and then register the nodes and create the overcloud. And we have the overcloud ready here. And then you go ahead and create the basic tenets. So this concludes our session. It's really quick, but yeah. So if anyone has any questions, so that's it. So we are done. Thank you. Thank you.