 Okay. Let's start it. So thanks for coming. And I know it's a Friday. It's a Thursday, but tomorrow is a Friday. And it's our first time to be in the city, I think, for most of the people. And maybe we are looking for some fun tomorrow or the weekend. So thank you for staying with us and to see this presentation. Okay. Let me introduce myself. I'm Haiming Yang from IBM China. China System Technology Lab. It's a CSTL in STG System Technology Group. So we are basically we're making hardware. And OpenStack is kind of IBM new infrastructure to unify all the resource, including the X86 power mainframe and all kind of storage. We want to unify the storage as a bundle offer to the customer. So here's my topic is hybrid cloud with OpenStack and bridging two worlds together. Since the first day I'm in the design summit, I saw a lot of people talking about the concept of hybrid. It's kind of confused me because everybody talking, everybody has its own understanding. And I saw some presentations say hybrid is a VMware virtualization hybrid with KVM virtualization. So managed by the same OpenStack. Another people told me hybrid is I have a bunch of bare metal machines and I want to manage it together with the virtualization environment. And also someone told me is I have a data center in Atlanta, another data center in New York. How can I manage them together? And that is another kind of hybrid. And even further, I have an Amazon service and I have a software service. I have OpenStack service. How can I make them work together? This is a final hybrid. So it's pretty much infrastructure level. We can have a many different solution. But our goal is we want application, our application and the users to look at all the different infrastructure in the same way. So this is why we are here. And we want to bridge those different infrastructure together and work as a single end user experience. Okay. So first I explain a little bit of the hybrid meaning in our world. And then this presentation I will be in three sections. First, let's explain what is our implementation and what is our goal. And second is what is the major use case we want to solve in the hybrid world. And the third part is current effort on the hybrid area, which I remember this morning our colleagues in the communities proposed some Federation concept and also multi-region concept. So it's really the start point of hybrid. And we want the hybrid can go further. And then we see the real unifies of the cloud. So what is the hybrid? And I think most of people kind of agree with hybrid is a public cloud and connect the public cloud with a private cloud. So what is public cloud or what is the target for the public cloud? It's pay as you go and auto scale. So it's more like a flexibility. And for the private cloud, it's for enhance the security performance, reliability and they want a full control of your resource. So that is the target of the private cloud. And mapping to the old period is a private cloud, most likely enterprise cloud and public cloud is like MSP, managed service provider or now we call it CSP, what is called cloud service provider. So in the cloud model, my background is network. So network has a seven layered model. So I think in the cloud area, we can also separate in this layered model. So bottom layer is a physical machine. So you're using x86, you're using power or what kind of storage? You're using EMC or NetApp or what kind of switch? Cisco brocade. So this is a physical layer. And the second layer is the virtualization layer. So what kind of hypervisor are you using? Like a KVM is this dominant in the open stack world. And the VMware is a big player in enterprise layers. And also for the storage virtualization, we have so many distributed file system, like a GlassFS or SAF something. A network, I know there's a, our neighbor there is talking about a lot of SDN concept and a lot of interesting implementations. So that is a virtualized your resource with computing resource, storage resource and the network resource. Then it's come to the open stack. Usually we'll call it the IAS as a service. And above open stack, it's like a cloud foundry. Those are open shift. Those are those open source project. We can category it into like a platform as a service. Above the platform and service, there will be the software as a service. So if we are placing the public cloud and the private cloud into this layered model, we'll see the private cloud most focusing on the underneath like a physical layer and a virtualization layer and a resource manager, which is a IAS layer. And for the public cloud, it's most likely a general purpose cloud. They want something quick and reliability may not be the first priority to implement. And they want to do some quick POC, or since most small enterprise may not last like IBM 100 years, so probably just a few years. So they want to quickly test their idea and they don't want to spend so much money on their infrastructure. So that's probably the major benefit of public and the private cloud. Public will be more flexible and private will be more reliable. So how can we get a single offer to combine this benefit both from public and the private? So that is why we need a hybrid. So the first bridge cloud with toward is how we do it, is the region. We know OpenStack has a concept of region. And for one OpenStack deployment, we have a single keystone. And we have two data centers, one maybe in Atlanta with NOAA, with Neutron, with Cinder. And the other is my data center in New York. It has its own NOAA, has its own Cinder and Neutron, so those are infrastructure. And the authentication through the same keystone share the same authentication service. And because those are two data center managed by the same organization or corporation. So they will have the same administration user interface for the administrator. So what the purpose of this kind of region or multi-region deployment is targeting for the resource consolidation in the same data center. I remember in last 10 years, there's a lot of company buying a lot of hardware. Now they feel they have too much hardware. They want to combine the resource in the same management. And they want to use their hardware more efficiently because they find that most of their CPU or memory resource is wasted and not fully used. So they want to use virtualization and fully utilize the virtualization benefit to manage them together. So by this region concept, we can manage multiple virtualization hypervisors and bare metals in the same administration. So current OpenStack did a pretty well I would say did a pretty well on this part. We have an ironic to manage the bare metal. We have a community has a VMware driver, has a Hyper-V driver and a KVM driver. And IBM also have is a PowerVC driver to power manage PowerVM. So this part I think that's pretty good. And the next, this is I think if you guys in this room in the whole day, you will know there's a keystone implement the federation concept. Before the OpenStack comes out, there's a lot of federation already in this class. And I think they call a single sign on something. And they use the service outside your cloud is authentication through outside authentication method. And all your cloud will be authenticated through that service. So this is using federation. So you pretty much have a two OpenStack cloud and you build OpenStack cloud first in one data center and then you build another one. Now you want to combine them together. So it probably doesn't have the same keystone or glance or whatever, the same service. But you want to combine this two independent OpenStack cloud manager by the same organization. So you want to federate your keystone. And so this one, we have seen some users trying to adopt this concept by like a they have a primary data center in one place and they have another one which major is a backup or the disaster recovery data center. So they want to, they're still in the same organizations but they want to fully leverage the capability of their distributed topology. So somehow they also call like a distributed cloud. And that is in the same organizations. It also happens in the private and the public OpenStack cloud. If you go to, I'm not going to do commercial for Rackspace but Rackspace did some prototyping or the implementations with the two OpenStack since Rackspace is based on OpenStack and you can federate your private OpenStack environment with Rackspace public OpenStack service. This is the second kind of bridge the cloud. The third one is, I would say it's more general purpose hybrid. It's since I personally don't believe OpenStack will be the one to unify all the cloud. So outside there will still Amazon cloud, Google cloud. In China there's Alibaba cloud. So they will have a lot of a variety or even sometimes we don't call that thing as a cloud. It's just legacy stuff. Like in some of our customer environment they did a pretty good implementation to manage their infrastructure but they don't call it cloud. But their API or their operation is very unique. How can OpenStack cloud work with those sort of legacy or the supportive cloud? So this is a target we want to achieve. So I remember in the first or the second release normal API has an EC2, I think has an EC2 API and I just checked the code, it's still there. But I don't know if it's enhanced or just all the legacy stuff. And that will be interesting. So that's the original thought of NOAA how to collaborate with Amazon cloud. It's just in the API level, it's compatible. So this target will be for the OpenStack hybrid with other OpenStack, non-OpenStack cloud. So if the customer or you have bought some resource from different cloud then you can manage or unify them in your single wheel. It doesn't matter if it's your own environment or some resource outside your organization. That will be more flexible. For example, you have some contractor in your company and you don't want the contractor to use your own resource since either you don't reserve the resource for those newcomers or they don't follow, they don't apply the security enforcement. So you want to build another cloud outside your private cloud but they still need to work together. So you can have the more flexibility to choose what cloud resource vendor you're going to use and there will be a lot of, I think, sales game you can play with the resource pricing. So this is the major three cloud or we say bridge the cloud. Now this is applications that we're targeted to solve by this hybrid model. The first one is metatemporary capacity that cannot be met by the private cloud. So we have seen some interesting observations from the customer in the Black Friday. There's a traffic burst compared to the daily average traffic. So it may be 10 times. This is what we saw from one customer. But the customer won't buy the resource with 10 times. So they just want to, in one day or two days, they want to get some more resource from your public offering to response the customer requirement. So this is a cloud burst. The other one is... So temporarily the organization wants some extra resource as I mentioned in the last chart. They have a new commerce. They want a new project. They want tested. It's a good project or not a good project. So they probably just want some resource for three months to POC their ideas. So they can use their model to achieve their POC goal by using hybrid resource. So you will see here the private cloud has applications and public cloud. So in this cloud burst situation, it will automatically scale to the public cloud with some allowed application, which can meet your security requirement. So this is the first use case. The second use case is the disaster recover or the backup situations. So I know the disaster won't happen every day, but you need to prepare something for the disaster. And then the customer will buy some extra resource from the public, or it's reserved some of the public resource in the public cloud and prepare for the worst time. And then periodically there's a few steps. First, they probably replicate your metadata or your configurations from your private to the public, like your user authentications and flavors and the security policy, those things. And also the content, the content is probably the difficult part, especially with two-cloud completely different architecture. It's a little bit more easier by just if the two-cloud are both open-stack cloud. So the content includes the volume, which saves your data and the virtual machines which are running your application and the images, which is your template to deploy the VM. So at least we need, and also the relationship between the VM and the volume is because sometimes your VM is actually attached with your volume. So those are the three basic content we need to replicate from the primary to your hybrid public cloud. And then after the disaster, you also need to periodically or replay what you did on the private cloud to make sure the public cloud can catch up your latest change in your private major cloud. And then after the disaster or your private cloud has been recovered, you need to replicate back from the public to the private. And so that's what I would say is it's cheaper than you buy a bunch of hardware to build a disaster data center. So since you bought some service, disaster recovery service from the public cloud, so that resource probably not dedicated to you. It's just some of the resource in the public cloud offering, public cloud vendors will keep in mind and reserve for you. So this is the second use case for the disaster recovery or backup. So the third one is there's still some debate of is that a real hybrid case? So I would say it's a more general purpose case. So because when the cloud comes out, each wonders need to survive. So they build their cloud with some specific usage. For example, I remember in China market, there's some cloud wonders focused on the content delivery cloud. So their cloud infrastructure probably best for the video or audio delivery. And some of the cloud may, more like a general purpose, it's just provide the VM, provide a bunch of storage and hosting a small IT. So if I want an application which combines the resource or takes the benefit of all those cloud, how can we work, combine them together? So this is an example of one cloud is a computing cloud, the other is a storage cloud. So your data or your user information, you don't want to give it to the, you don't want to give it outside. I remember I think Target has some problem with leaking the customer use information. But usually the public cloud has more computing capabilities since the hardware usually two years, two years and a half, we need a change to a new generation. So they usually can get the latest, the greatest hardware. So we probably need to fully utilize the capability, computing capability from the public cloud. But you don't want to make your private information exposed in the public cloud. And I remember a long time ago, we were discussing what is the next generation of cloud or cloud computing. So we were talking about fog computing. So after cloud computing, it will be fog computing. But I think it's a joke. But I think this Federation model is pretty good. So we have a general, a big island in the, as a public service. And we keep something for ourselves, which is our own technology or some content based. So how we hybrid this kind of private and public, those content and... So this is the third model we are trying to achieve. Okay. So we need to implement this what we said in the previous chart. And the first implementations what we can do is, we want to make our life easier. I know there's the cloud OpenStack is complicated. I remember Amazon may have 2,000 APIs, but OpenStack probably only have 500 and 600 APIs. So I believe there's definitely some gap between OpenStack API and Amazon AWS APIs. So the easier way is we create an OpenStack cloud in that public cloud. That's an easy answer. Then we can just like a 2 OpenStack cloud work together. So that hybrid will be full back to like a federation model. And in this part, we probably need to solve the problem like how can we pass all the image, the template from your private to public since you want your public OpenStack cloud using the same way as your private cloud. The configuration probably easier is you can take a package and zip file and upload to your public and deploy with some script to reconfigure your public public provision OpenStack cloud. But for the data, if you like image or volume, you may take some effort. First, the network bandwidth is limited. You cannot pass all the information in a timely fashion. And second, security can allow you to do this kind of collaboration between your private and public. So there's still some work needs to do. Ideally, you shouldn't feel the difference between your private and public since both your private and your public OpenStack which hosted on the third party non-OpenStack cloud, they should be looked at the same or two regions in your Keystone point of view. And they can use the same horizon can operate. So there will be the major fourth step to implement this kind of OpenStack on your public cloud offering. It's first bare metal. Of course, you need to get a bunch of hardware and then deploy your OpenStack with a specific topology and I think probably you need a form with how many appeared, how many storage and those information you want to fill out. And you also want to say who I want to federate and what kind of user authentication I want to use. And then after deploy the cloud, you need to configure the cloud so fill up all the policy, specific information. Then the number four is I personally think it's very important since when you deploy the cloud how can you say the cloud you can use the cloud. So of course we have ten paths but to me it's like a function verification test. So in our production development engineering team so function test, a unity test is our first step and second step is a function verification test and then we also need integration test and system test. So I think if compared to the production environment this step will be like SVT system verification test. I need to test all the basic functions it's working and I also need to test it's my scalability to satisfy my requirement or the long-distance test. So my VM running 100 hours does work this way. So this kind of test I think is missing right now in the ten paths. I know there's a current project going into RAV stack maybe. This is trying to address this problem by enforce those kind of standards. So if you say your cloud, your open stack cloud is ready to go to customer. At least you need to have a third party or you need to pass kind of a standard to show you can do it. So this is the goal. Yeah, I mentioned. There's another project, I think is targeting for the same thing. You run your open stack on top of open stack. So this chart is implementation of IBM OpenStack running a soft layer. So another hybrid implementations we are discussing here is kind of a hybrid framework. It's here. I hope this is the but. Okay, here. So I still using Horizon since from Horizon I can consider it as application. It's GUI application with basic implementation of the combination of OpenStack API. And so I don't expect any change or big change in the Horizon operation. And but I expect there's some cloud cross-cloud scheduler with some consideration. For example, I think some cloud quality is better than some cloud and or some cloud price is cheaper than some cloud. So I need this kind of just a too simple example, but I do believe there's more criteria. So this part I need a cross-cloud scheduler to decide which cloud or which provision or provision resource which cloud I should place the resource or send request to. So this is a cross-cloud scheduler and this is a hybrid engine framework. This is what we think about. Oh, by the way, so here is just one kind of implementations in our mind and it's not the right answer and I think there should be some better implementation than this one outside somewhere. So this will be hybrid engine since they will expose the OpenStack API, which is the same as standard OpenStack API. And there the hybrid engine we can pass through all the OpenStack API requests to the real OpenStack cloud, which we can describe it as on-premise private cloud. So this is here. And the other one is we develop some kind of server or plug-in. So I listed here, but it doesn't mean it should be in the same package. It could be a public service. For example, it's JumpGate. This is IBM developed SoftLayer plug-in. It can be bundled. It's already in the GitHub. So I can talk to the JumpGate. It's bundled inside my package and talk to the SoftLayer API. Or I can develop like Amazon and talk to the Amazon cloud. Or whatever, if the Ali cloud the China dominant cloud want to work with the private OpenStack cloud, they need to develop another cloud adapter or the engine to talk to the OpenStack cloud. So those will be the off-premise dedicated private cloud. So this kind of framework and the plug-in model is I think probably is one way to implement this, how to hybrid OpenStack cloud with a non-OpenStack cloud. A little simple explanation of the JumpGate. So you can get the JumpGate code in the GitHub. I won't say the code is fully functioned. So we tested with it's working, I would say it's working, but it's not work as a production requirement. So there will be the two major part of the JumpGate project. So this part software API is not part of JumpGate offering. Right now we have identity service, computing image and block storage service. So it can but it doesn't say all the API has been compatible or it's working now. So you can use your OpenStack or horizon call this identity service or computing or no keystone service. You will get your machine provision through the soft layer Python library and talk to the software API. Then you will get your call has been executed in the OpenStack way. So basically the JumpGate is a translation layer to convert incoming OpenStack cloud provider API call. It will be interesting to see if we think it's a framework. So we will expose those identity compute or image block storage APIs as exposed to the OpenStack site. And we need focus on those soft layer Python libraries will be the one to do the translation from the OpenStack API to the other non-OpenStack APIs. So we will focus then developing what is the soft layer Python library we can do or whatever other cloud API you want to develop. And then if it's fully compatible or this soft layer API has functions which are similar to the OpenStack API, then we can use that talk together, combine them together. So this is the last chart, so we probably need some help. What is the challenge of hybrid programming? So first of all, what we have been doing this morning, we have a lot of discussion on federation, so that is a pretty good implementation. I think the framework is pretty nice, and we just need to federate more identity service. I'm not expert on all those identity service. And multi-region is there, so we can fully deploy multi-region is the same horizon or same GUI. But what we haven't done yet, so think about the workload part. So the first one, the heat across multi-region is not fully implemented. And I remember there's a blueprint in Icehouse talking about this implementation. In the cross-multi-region implementation, but the code has been reverted. I don't know why, because it keeps bounding and I really don't know why. And the volume replication across hybrid cloud. So we can first make life easier, so we have a tool OpenStack Cloud. How can we replicate my volume from OpenStack Cloud 1 to OpenStack Cloud 2? So for the network part, so my goal is the bigger layer to switch with isolation and security. So I created a VLAN or VXLAN in my OpenStack Cloud 1. And I have another VXLAN in OpenStack Cloud 2. So they are actually in the same VLAN or VXLAN. So logically, they are in the same broadcast area. But physically, they're completely separate. So this is the target. And I remember a long time ago in the telco business. So in Lucent, they developed IP over IP protocol since they wanted my cell phone. They wanted the cell phone to be online by using, I think it's a 3GPP or something. Or 3GPP2. And their protocol is pretty much a telco business protocol, which is a completely private protocol. I can't remember the name. But above their protocol, they developed an IP packaging, which is a packaging with IP. They keep the application level the same as the Wi-Fi style. So the bigger layer to switch, I think probably the best way to achieve this kind of hybrid network model in the bare metal provisioning. So this part, I don't think there's a single answer at this moment. So there's a lot of bullying to do the bare metal provisioning, but it's so I think the war, Opensight was still thinking the physical layer and the virtualization layer. But to me, they are all resource. The physical layer and the virtualization, they should be together, not in the layered model. So there's bare metal. And for the glance part, since my cloud, Opensight Cloud 1, probably based on KVM, and Opensight Cloud 2 based on VMware. So they are different format. How can I deploy my image into different kinds of hypervisors? So this is a challenge. And my image available, even the same hypervisor, my KVM image available in Opensight 1. But how can we pass those images from Opensight 1 to Opensight 2? This is also another challenge. And there's also interesting discussion for the object storage. So if I have a Swift cluster across the private cloud and the public cloud, then I will have a single Swift endpoint. So the customer, when the customer accessing the Swift service, it's already achieved hybrid automatically. So I think that would be super cool if we can achieve that goal. So I believe there should be more open issues in the hybrid concept. But those are problems we find in our implementation. So especially there's another challenge, like if the user has indications in private cloud and the public are completely different. So how can I operate the public cloud with the users in the private cloud? I don't think this part has been addressed completely at this moment. Okay. Yeah, so that's pretty much the topic we are talking about today. So any question? No question? I'm Jerry. You're working with Nokia. I have a question in terms of the hybrid especially when with OpenStack with third party public cloud, let's see, AWS, et cetera. So the mentioning of Federation, et cetera, mostly is for identity and authorization assignments which is to some extent easier because the bigger problem for application or workloads to shift from one cloud to another much of the features, capabilities and mismatch API, et cetera, that's the soft thin layer you can always encapsulate and translate. But the features just like for certain clouds don't have database services, don't have EOB, don't have queuing services, et cetera. How do you or IBM envision that would be handled? Thanks. Yes, so good question. So you're basically asking how application can auto scale from your private to the public. So content, how your content can be moved from private to the public. So I won't say there would be a simple solution to do that. I would see there's a bundled solution offering in the storage, in the computing network offering, you can achieve this. So think about this, your network connection from your private to the public is one megabyte. I don't think we can play anything fancy with this one megabyte of bandwidth. We definitely need some special line from your private public to achieve this fast transfer. So basically my answer is this need a bundle solution in the different layers to achieve this goal. I guess it's not only the application content it's also the application architecture of using certain services to less than queuing services to decouple. And if the queuing works differently or is even missing in certain cloud, then you will almost it will require you to re-architecture app in order to distribute your workload for DR purposes especially. So for application levels I remember a long time ago there were limitations so you have a single entry of routers and the router is a real IP and it will match a few virtual IPs. Then this router will route your request according to the load workload to your either private or public cloud. So this maybe the application level we did to fitting this new structure enterprise application usually doesn't think about this kind of new structures this distributed structures just like a single application or multiple thread running on a single server. But for the real internet application each server should be running one thread one application or even one component I don't want it running everything so this is my understanding of how we can solve this application level Thanks I think I am running out of time so thank you for coming please let me know if you have any questions