Day 22: An alternate architecture for implementation

Looking at the second strategy proposed in Day 20's article, we shall explore the implementation details of the same. The below figures give a glimpse of the implementation specific details of the architecture, its features and few limitations or further clarifications needed.




The above diagram depicts the block diagram to explain how the architecture can be built. Since the number of ports that all machines I'm using have is 1, I have built the architecture accordingly. The switch 1 and switch 2 could be the same switch even. They are shown separately for better presentation purposes. From previous experimentation, I have found that the controller and the connected switch must be in the same subnet, else switch remains unreachable from the controller. This is the reason I have assigned the same subnet to switches, LB and all the controllers - both hierarchy 1 and hierarchy 2.





Since the Load balancer also runs controller, we could as well make it the master controller and let standby take care when a single point of failure occurs. This is an alternative to the earlier architecture where load balancer and master controller are combined into one.



The above image is the continuation of the clarifications that are still needed to start implementing the architecture. We shall look into the same in tomorrow's blog.

You can refer to the previous article and next article.

Author: Shravanya
Co-Author: Swati

Comments

Popular posts from this blog

Day 12: Master Slave SDN Controller Architecture

Day 50: Tcpreplay and tcpliveplay approach

Day 10: Mininet Simulation of a basic distributed SDN controller architeture