1 00:00:00,000 --> 00:00:10,733 Hi let us understand more about orchestration and master worker architecture. 2 00:00:10,733 --> 00:00:15,533 As we discussed earlier I can have docker engine installed on top of any 3 00:00:15,533 --> 00:00:20,133 operating system and I can have n number of containers. When there is a need to 4 00:00:20,133 --> 00:00:24,499 start huge number of containers for various applications one single machine 5 00:00:24,500 --> 00:00:29,633 may not be sufficient enough. So I may need to start n number of machines whenever 6 00:00:29,633 --> 00:00:34,166 I have n number of machines managing those machines it's going to be a problem 7 00:00:34,166 --> 00:00:38,599 that's where the master worker architecture comes into picture. I'm going to have 8 00:00:38,600 --> 00:00:42,766 a master and I will be having n number of worker machines 9 00:00:42,766 --> 00:00:47,566 and all the worker machines will be reporting to the master. The 10 00:00:47,566 --> 00:00:50,566 reporting could be in terms of a small heartbeat signal 11 00:00:50,566 --> 00:00:55,999 it'll keep on sending it to the master saying I am active and alive and the master will be 12 00:00:56,000 --> 00:00:59,733 having a controller or a daemon continuously running to listen 13 00:00:59,733 --> 00:01:03,599 to this particular heartbeat signal and keep managing all this 14 00:01:03,600 --> 00:01:07,900 nodes and each and every node internally it will be having the 15 00:01:07,900 --> 00:01:12,133 operating system or the docker engine all that will be installed and 16 00:01:12,133 --> 00:01:15,599 configured properly. So I am going to have the docker engine 17 00:01:15,600 --> 00:01:19,466 and each and every worker machine will be having 18 00:01:19,466 --> 00:01:22,832 the operating system and its own infrastructure and 19 00:01:22,833 --> 00:01:26,833 master also needs to have a control on this worker machines saying 20 00:01:26,833 --> 00:01:31,166 to assign the work or to get the status on what is the availability of 21 00:01:31,166 --> 00:01:35,199 the resources and what feature work to be allocated the current 22 00:01:35,200 --> 00:01:39,166 status of the work that is allocated, to get the status it's going to 23 00:01:39,166 --> 00:01:41,832 have some sort of a daemon that is running that will keep reporting 24 00:01:41,833 --> 00:01:45,399 to the master a different controller will be listening to it. 25 00:01:45,400 --> 00:01:49,466 So I may have a controller and here is going to be a listener 26 00:01:49,466 --> 00:01:52,766 and the same architecture will be available in most of the master 27 00:01:52,766 --> 00:01:56,232 worker architecture where I will be having n number 28 00:01:56,233 --> 00:02:01,766 of controllers to do different jobs and each worker machines will be having a listener 29 00:02:01,766 --> 00:02:04,799 and this is where the high availability comes into picture. In 30 00:02:04,800 --> 00:02:09,032 case if I wanted more resources what I can do? I can start similar 31 00:02:09,032 --> 00:02:12,333 such machines and make it to report to the master 32 00:02:12,333 --> 00:02:16,866 So within no time the capacity will get increased and the master will start 33 00:02:16,866 --> 00:02:21,599 managing more and more resources and this type of running n number of machines 34 00:02:21,600 --> 00:02:26,300 together and doing the coordination we call that as an orchestration and each worker 35 00:02:26,300 --> 00:02:31,566 machines will be managing n number of containers within it and I need to facilitate 36 00:02:31,566 --> 00:02:36,132 these containers to communicate within each other and that's where I'm going to 37 00:02:36,133 --> 00:02:41,766 have a virtual networking have sophisticated networking capability where each and every 38 00:02:41,766 --> 00:02:45,099 container will be in a position to communicate. There 39 00:02:45,100 --> 00:02:47,800 are n number of network implementations available to facilitate 40 00:02:47,800 --> 00:02:52,600 this and in this particular architecture whenever there is a failure of a 41 00:02:52,600 --> 00:02:56,133 worker say for example this particular machine failed for 42 00:02:56,133 --> 00:02:59,499 some reason the other machines will be in a position to take up 43 00:02:59,500 --> 00:03:04,200 those load and make the applications available. But in case if the 44 00:03:04,200 --> 00:03:07,733 master fails all the worker machines will start failing. That's 45 00:03:07,733 --> 00:03:12,066 why we will be having a high availability for the master. So there 46 00:03:12,066 --> 00:03:14,799 will be n number of masters most of the scenarios we 47 00:03:14,800 --> 00:03:19,000 will be having a odd number of masters working together and 48 00:03:19,000 --> 00:03:22,900 only one will be active at any point of time and others will be 49 00:03:22,900 --> 00:03:26,366 passive master and to manage all these masters who should 50 00:03:26,366 --> 00:03:29,799 be the master and who should be active and who should be passive 51 00:03:29,800 --> 00:03:33,966 that could be another controller which can take up this particular 52 00:03:33,966 --> 00:03:38,599 activity. Orchestration can facilitate us to provide very important 53 00:03:38,600 --> 00:03:42,733 features like high availability and scalability of the containers 54 00:03:42,733 --> 00:03:45,599 we will be having a separate discussion on what is high 55 00:03:45,600 --> 00:03:50,866 availability and scalability and how orchestration going to facilitate that.