 Hello, everyone. My name is Liu Junwei, technical director of cloud computing. Today with my co-worker Xu Jun, data center operational system team leader, we will share the topic, practice of application migration to D-Core's platform in China Mobile. First of all, we allow me to make a simple introduce about my company. China Mobile Studio Research Institute is responsible for the development of cloud computing and big data products. It has 600 employees now. First, we will introduce some background of our D-Core's platform. Then we will describe the components of our D-Core's. Next, we will share some experience of migrating applications to D-Core's platform. Last, we will show you a production case in China Mobile. In China Mobile, we often suffer problems as follows in our IT stack. Problem one, on the other hand, low-resource usage of our data center. But on the other hand, resources is not enough to satisfy the different requirements. The problem two, application deployment and scaling are very time-consuming. Maybe it needs several hours or days. Problem three, high complexity in operation management and maintenance. So what's the essential reasons? First, we think applications with traditional architecture are not well-adapted with cloud infrastructure. Application deployment and scaling has complex dependency. We need to prepare servers, install operating system, and independent libraries. Also, we need to configure application and load balance manual. Second, although we already adopted OpenStack to build our IS platform, but we still do not completely solve the problems because IS may focus on providing IT resources, not application. The resource is still statically allocated to each application, not shared with each other. We have no powerful platform which is friendly and seamless with the application. So we plan to solve these problems from two sides. One side, moving our application to cloud-native architecture to make application more accommodation with cloud. Cloud-native architecture is complex with this principle. Microsurface architecture, stateless, immutable infrastructure, and so on. The other side, this will build DECOS platform which provides powerful abilities for application with cloud-native architecture. It provides abilities like scaling, fault-tolerant. It also provides dynamic resource scheduling in a fine-grained manner. Our DECOS is made by Metosphere. It's a lightweight path platform for production system and be used to achieve street containerization applications in China mobile. Our DECOS is based on methods and a marathon. Methods and a marathon are used for cluster resources scheduling and application lifecycle management. In addition, there are other components in our DECOS. Here, we will show the service registration and discovery component. This component is based on ETCD and HAProxy. The processing flow as follows. First, we listen on marathon event bus. When application change via marathon, we will be noticed by marathon event bus. So when application actions happen, we could update app registry info like IP plus port of application in ETCD real-time. Secondly, we also monitoring ETCD. When registry information updated in ETCD, we could use the latest information to configure the HAProxy and reload HAProxy again. Then the request of the application will be dispatched to the right application instance. For example, the instance created, new created. This slide, we will show the other components in our DECOS. First is the auto scaling module, which will be used to auto scale up and down application based on monitoring metrics like CPU memory, request response time of HAProxy. The monitoring and alarm module mainly used to collect and display cluster and applications monitoring data also offer a variety of alarm mode and strategies. Then the user management module provides user authentication and authorization functions. Last, our DECOS has a dashboard for self-service. The application in Chalemba has four characteristics. Most of them are G2E enterprise applications. And there are typically three types of architecture. For the assess layer, it needs to support multiple channels like PC, mobile, and others. These logic layers include burning, sentimental, customer service, say, privacy management, and so on. For the data layer, it may use multiple types of storage like Oracle for the database and last for the fast storage because most of these applications are a lot of stateless. So with this application to our DECOS platform, we need to make some changes to these applications, make them more combined with cloud-related architecture, and make the application containerized. Next, we will share some experience about the application migration. The first problem we encounter is about the session management as shown in the picture in the slides. Some applications store the session in local web server. This way, it's not horizontal scalability. When an application instance exits the session, the session data is gone, which will cause the user to log in again. This is a very bad user experience. So we suggest to store the session data into a shared cache server, like in the Redis. Then the application could store and get the session from the cache server via the session ID. Second experience is about the whole data. Some applications use whole data in traditional ways. They load whole data from the database during the application launch. If the whole data is very big, which you may cause a long time to application to stop. So what is the way we could put the whole data in the cache server and the application as the whole data from the cache server? This can accelerate the container startup. So some applications will last to store the static files, like a phone ticket. And for the character of the containers, they may exit and launch on other servers. So we suggest to use the object storage to store and get the static files. This can separate the data and application. Then the application integrative with the storage only via the REST API. So we don't need to mount each last device to each service in our data center. There are some other experience for application migration for interactive with one service in REST platform. We try to use standard protocols like HTTP as much as possible. Why EJB-T3 protocol? It doesn't work well with HAProxy. For WebLogic, we suggest not to use the WebLogic cluster because the session is already stored in shared storage. And the WebLogic cluster configuration is complicated. We can use this REST platform to manage multiple WebLogic instances. This is a more better way. For application configuration, we would rather to code the configurations like IP and port into image. We better to use the environment rather than to configure the application. In order to easily the collection and analysis of logs, we make some rules for the location log names. They will look like an app name, and content ID, and date to present the log name. For building application docker images, it's better to avoid using too many layers in docker images and remove unnecessary data and only keep the dependent libraries and the files and keep the image size as small as possible. This is very useful for the image to escalate for image planning and the content startup. Last way, we should configure database connection for operating. Sometimes, Outstanding may take a lot of container at the same time, which will host other database connections because of the long response of the database. Now we will show a product case in China. In Zhejiang provenance, we have migrated online broker of location into our DCS platform. This app has 25 million users, 3 million active users, and 150 million PV per day. And the DCS deploy equipment is shown as a picture. It contains 93 servers and five servers for many users, deployed methods master, truekeeper, and marathon. And the eight servers are used for HAProxy. From HAProxy is two F5 load planes, one active and one backup. And the latest eight servers are methods agent. For this platform, we can run up to 2,000 containers and it could scale up to 1,000 containers with one minute. Further, for the limited time promotion activity for phone recharge in November 2015-11, our platform was successful, could cope with a huge burst as it says, and make sure the user experience. Now this application could handle 60,000 concurrent requests per second. And it could support a maximum 1,000 million PV per day and 12 million login users. This is surely in the table. This is a huge promotion compared with the traditional architecture before we went to DCS platform. That's all. That's all I share. Thank you for your attention. So what you talked about here was the conversion of your legacy application into the container world, right? Yes. OK. Thank you. Thank you. Sorry, you tell. You have 90 nodes. How many containers you run in per node and what is the average density in this deployment? Total number of containers. The average is 20 containers on each host. Could you repeat, please? Just a little bit louder. The average is 20 containers on each server. OK. Thank you. And second question, how did you scale my SQL in container environments? We didn't put the massacre in my DCS platform where massacre is on the other side. We haven't put the massacre in the DCS platform now. So how are you running my SQL in this case? Is it something separate installation or what is it? Yeah, separated. OK. Thanks. On your previous slides, you actually showed some of the MPI applications. Have you done anything with the MPI type of application with this DCS OS? No. No. OK. Thank you. Thank you.