OMegha Public Cloud - Jumpstart Cloud for Startups

Openstack Neutron - Networking In Cloud Demystified (Network Function Virtualization)

Hi All,

Blogging after a very very long time again!!

This time decided to blog on OpenStack and believe me this is the toughest topic of all in the openstack architecture to understand.

PROJECT NEUTRON - Openstack Project that deals with networking services in a cloud environment.

When we try to find the how networking components of Openstack internally works, google is full of pictures all over, beautiful pictures but understanding it will be quite a challenge. So, decided to blog on it and take it step by step to understand the networking behind the scenes and how virtual machines gets connected to outside world.

We will be following the below sequence to understand the concept in detail.

§  Physical wiring of ethernet using 2 ethernet interfaces

o    (2 cables, we will create a bonding)

§  Ethernet bonding

o    (Doubles the speed, and increased reliability, active-active)

§  Ethernet tagging

o    (Thats why we need only 2 interfaces)

§  Network function virtualization (NFV)

o     Openstack will not help you, you have to put this in place by yourself.

§  Tie all the above together in a single and final picture

Advantages of Bonding

========================

-Spec: 802.3ad

-Active-active mechanism

-Aggregate traffic balances on both cables

-Individual flows do NOT balance

-If any connection fails, traffic moves the connection that is active

(100 Ms failover time)

How to do ethernet bonding?

===========================

Network config file /etc/network.interfaces

(Debian system, if non-debian system make necessary changes)

auto bond0

       iface bond0 inet manual

       bond-mode 802.3ad

       bond-miimon 200

       bond-slaves none

       up ip link set dev $IFACE up

       down ip link set dev $IFACE down

#Bond Slave

auto etho_interface.stdout

       iface eth0_interface.stdout inet manual

       bond-master bond0

       bond-primary eth0_interface.stdout

#Bond Slave

auto eth1_interface.stdout

       iface eth1_interface.stdout inet manual

       bond-master bond0

How to setup the VLAN trunk for management & provider network?

===============================================================

Network config file /etc/network.interfaces

(Debian system, if non-debian system make necessary changes)

#Management VLAN

auto bond0.1600

       iface bond0.1600 inet manual

       up ip link set dev $IFACE up

       down ip link set dev $IFACE down

#Provider VLAN

auto bond0.1200

       iface bond0.1200 inet manual

       up ip link set dev $IFACE up

       down ip link set dev $IFACE down

Network Function virtualization (NFV)

======================================

1) Create the management bridge

sudo ovs-vsctl add-br br-mgmt

2) Attach the VLAN 1600 interface to management bridge

sudo ovs-vsctl add-port br-mgmt bond0.1600

3) Create the provider bridge

sudo ovs-vsctl add-br br-ex

4) Attach the VLAN 1200 interface to management bridge

sudo ovs-vsctl add-port br-ex bond0.1200

5) Create the VLAN bridge

sudo ovs-vsctl add-br br-vlan

6) Attach all VLAN (trunk) to the VLAN brodge

sudo ovs-vsctl add-port br-vlan bond0

Eight Network Function Virtualization Components

====================================

1) Tap  interface

- One end to VM referred as Virtual NIC

- Other end into (5) or (6) or (7) or (8)

2) veth

- One end Openstack Controller, Network, Block or Object Storage nodes

- Other end into (6) or (7) or (8). cannot be plugged into Virtual Machine

3) Bridge internal (OVS Only)

4) Patch (OVS Only)

5) IP Tables

6) Linux Network Stack (Namespace "ip netns")

- If we put IPTables inside of namespace, we configure IpTables  we can make namespace perform as a router/NAT/LoadBalancer etc.

7) OVS (OpenvSwitch)

8) Linux Bridge

Namespace create a isolated virtual linux network stack (It may include dnsmasq, virtual router, private networks & subnets etc…)

Note:-

We may use OVS or Linux Bridge (Actually both are competitors)

Linux Bridge Vs Open vSwitch

========================================

 HAPPY LEARNING!

               

New Virtual Currency Released on March 15th 2017 (CloudCoin)

India is part of new technology e-currency consortium

On March, 15th users from all over the world will get access to new virtual currency CloudCoin. According to project participants, Cloudcoins have to become more modern and easy to use virtual currency than Bitcoin. Unlike wide known currency which was developed using cryptography methods, Cloudcoins make use of cloud technologies. Check against counterfeit for cloudcoins takes as little as 1-2 sec (for bitcoins time to write block in blockchain is about 10 min and only after writing the block your transaction is fixed and cannot be rolled back). Counterfeit check for cloudcoins is simple open API and any programmer could implement it in webpage or application. To operate with new currency user don’t have to have electronic wallet and/or any keys.

Besides that there are another principal differences between cloudcoins and cryptocurrencies. In traditional authentication systems they use one login, one password, one checking server and one database (servers and databases could have many instances for performance and scalability but logically they operate as one server and one database. In case of global counterfeit detection system RAIDA (Redundant Array of Independent Detection Agents) in order to check coin against counterfeit you have to ask 25 independent servers with 25 databases which are not being synchronized.

Wherein cloudcoins guarantee full anonymity unlike bitcoins which write down data about every transaction into blockchains where you could find the sum of the deal and the keys of deal parties. In case of cloudcoins the information is not being written down at all. So it is possible to use cloudcoins without computers or internet by printing the cloudcoin content (authentication information) on paper. You could trade with such paper money and servers will not be able to write down information about owners and transactions. So RAIDA is not a system like a public ledger which is fixing transactions but approves authenticity of money by means of servers’ responses.

If for some coin some passwords will not be approved such coin will be called “fractioned” and if the amount of such “bad” passwords is less than 8 out of 25, the coin could be “repaired” or “fixed”. Due to this mechanism the system is protected against wars, fires, floods, sudden deaths, government intervention etc. If one server with passwords database will be completely destroyed the others could approve authenticity of all existing coins.

All servers in the project are being managed by independent members of CloudCoin Consortium which could be declared as Union of server managers, software developers and marketing specialists and companies. currently there are about 30 persons - members of the Consortium. All of them have valuable amount of cloudcoins in hands. This is why they will make their best to get this new currency be with ideal reputation in order to stimulate its use and market growth.

The idea of currency with cloud authentication principles was patented in 2016 by Sean Worthington, computer science teacher from California. Project investments are not being disclosed. All funds are being spent on servers administration, software development and marketing efforts.

-

Ajith Narayanan

Member - CloudCoin Consortium

http://cloudcoin.in

HAPPY LEARNING!