 Hello everyone. I will share with you the presentation about IZONIKA. The topic is practice to environmental multi-talent solution compared with SDN. My presentation will be divided into four parts. The first, I will give a brief introduction to IZONIKA. The second, I will introduce IZONIKA multi-talent solution. And the third, I will introduce our company's multi-talent solution. In the end, I will give a few resolved issues in our company. Now, let us look at why we need IZONIKA, because there are some cases that VTO server cannot cover. There are four typical cases for IZONIKA. The first, you want to have a performance which VTO server cannot provide. The second case, maybe application on to exercise some hardware which cannot be utilized. And the third, some database run poorly in hypervisor. And in the end, some users want to think that dedicated hardware is more safely. This is in architecture. This diagram describes relationship between IZONIKA and the other OpenStack projects. There is no difference between physical server and VTO server. Image provider, glance provider, image service, and Lucian provider, network service. And Kingston provider, authentication service. This is logical architecture. At first, the API will save the user request from the user. And then the API will forward the request to the server scheduler. Now scheduler choose the proper node computer to deal with this request. Now, there is no difference between physical server and VTO server. Then difference comes. Now computer talk to IZONIKA API instead of hypervisor. Then IZONIKA conductor get the image from glance. And get network support from Lucian. And get a warning from Cinder. I don't need to support many physical server from many vendors through a network. Let us talk about multi-talent. This diagram looks good, but there is something we should deal with. Because before Newton cycle, in fact, no conductor can support multi-talent Lucian model. It's just that it supports flight. So all the network can be communicated. Let's talk about multi-talent background. This is a natural requirement from user. User want to apply for environmental. Not just administrator can apply for environmental. But before Newton cycle, IZONIKA doesn't support network isolationation. Also does not support security group. All talents share flight network. And in Newton cycle, multi-talent future is supported. If we want to implement multi-talent solution, there are some issues we should deal with. The first, how to execute network policy? The answer is Lucian will notify SDN controller. And the controller will send policy to TOR switch and TOR switch portal. But SDN controller, how to get which switch, which portal? So next question, how to get a physical network devices? The answer is, IZONIKA will connect LDP information. And then IZONIKA will pass LDP information to Lucian. Lucian then passes LDP information to SDN controller. And then controller will deploy network policy to TOR switch. The last issue, how to ensure network safety? The answer is, IZONIKA will divide network into TXC network, provision network, and the talent network. Every portal of TOR switch, we are experiencing this three kind of network. Let me explain, if you want to understand multi-talent solution, you will learn some concepts about, especially about network. The first network, PXC network, IZONIKA, we are PXC network just to discover new node and connect the capability of new node, of new node. And the second network is provision network. IZONIKA will use provision network to deploy environmental. In fact, there is another network called cleaning network. In our solution, we merge provision network and cleaning network. The final network is talent network. Talent network is used by user to communicate with other server. This is a total deploy view of solution. By mental, we are connected to TOR directory. And every portal of TOR, we are experiencing PXC and provision and talent. IZONIKA node has three network connections. It connects to TOR with PXC network, provision network. It also can communicate with a multi-talent controller. In multi-talent solution, there are four of those cloud administrator, cloud user and network administrator, server administrator. Every mentor has his own lifecycle. He will experience four phases. It enter cloud first. It is applied by user and it is joined by user. And it will excite cloud. Phase one, before service are entering cloud. At this phase, server administrator should set IPMI password for every parameter server. And network administrator should make sure when parameter is connected to TOR, parameter can communicate with IZONIKA node. Phase two, when servers are entering cloud, parameter is connected to TOR switch. The network type is set to PXC. Then parameter gets an IP address from IZONIKA node. Got an FTP image from IZONIKA node. So there is a little OS running on BioMantle. It can connect LDP information. And then parameter will notify IZONIKA node. IZONIKA node will store LDP information in its DB. After service are entering cloud. Now cloud administrator can save all the nodes. Phase three, user is applying service. When IZONIKA nodes receive requests, it will create a port of Lucian provision. And Lucian will tell SDN, SDN will change PXC network to provision network. When network is prepared, IZONIKA begins to provision the BioMantle. After provision, IZONIKA nodes will destroy the provision port and update the talent. So finally, SDN will change TOR port to the talent network. After that, the whole provision process is finished. Phase four, users are destroying service. If we use a thousand liter mental server anymore. So he destroys service. In fact, IZONIKA supports the convenient network separately from provision network. But in our solution, we merge them without security issues. IZONIKA will destroy the talent port first. Phase five, servers are exiting cloud. When there is something wrong with BioMantle, we can make servers exit from cloud. This is the detail of interaction of multi-talented. At first, we use a boot instance to Nava. Now we create a port from Lucian. Now we call IZONIKA API to deploy BioMantle. IZONIKA will create a provision port. Then IZONIKA will deploy BioMantle. Power of BioMantle nodes. And then provision processor is finished. So it did a provision port. Then it opted the port of the talent. Now SDN controller will deploy a real network policy to TOR port. At the end, IZONIKA will power on BioMantle nodes. Or it's finished. These are important design issues in this solution. How can provision network or PXC network access to management network? This is a general problem in many of the project. For example, when it comes to kit, how talent network access to management API? The answer of hate is talent network can access management API through public network. This is a hate solution. When it comes to normal metadata, we made a process between talent and network and almost like management network. But when it comes to IZONIKA, how should we do? Our solution is we set a provision network gateway as IZONIKA nodes. And then when IZONIKA nodes receive request, it will forward the request to open stack management network. Then we share with you a use case from our company. It's a financial case. We have deployed over 10 hundreds of physical services. At last, I will share with you the typical resolve of the issues. First, that will make sure you connect to the problem. In fact, it's a general problem, not just about IZONIKA. And the IPMN tools issues, sometimes we should upgrade the IPMN tools to latest version. And we also encounter some GPT deployment problem. We don't stream the latest code to resolve it. That's all. I hope you will get something from my speech. And now it's time for question and answer. Which SDN controller? Our company have our own SDN controller solution. So I use our own... But this solution is popular. Every SDN controller should write his own solution driver to implement this solution. I think it doesn't matter. You can request, for example, two or four networkers at the same time we can deal with it. Or you just... When it comes to this solution, you just need a connection. Yeah. SDN controller now, when control... One port, we'll experience a PXC networker and provay networker and tunnel networker. So just one port. You mean just... Maybe you want multi-networker. This is supported. But in Newton's cycle, it doesn't support... It doesn't support... When it comes to multi-networker connection, it is supported. If you have any question, you can contact me after the meeting. Thank you for your time.