Hi Mentors,
In addition to refining the membership scheme code, I looked into following features of Azure. *Azure dynamic load balancing* Azure has a native load balancer which is very easy to configure. It’s a layer 4 (TCP, UDP) load balancer which helps to spread traffic among healthy virtual machines. Following are some key terms you need to know. · Backend pool: This is a pool of virtual machines that is configured to share the traffic among · Probe: The load balancer can probe the health of the various server instances. When a probe fails to respond, the load balancer stops sending new connections to the unhealthy instances. Existing connections are not impacted. · Availability set: when you have a set of virtual machines for the same purpose, azure recommends to add them to an availability set. You can configure it to: · Load balance incoming Internet traffic to virtual machines, called internet-facing load balancing · Load balance traffic between virtual machines in a virtual network, between virtual machines in cloud services, or between on-premises computers and virtual machines in a cross-premises virtual network, called internal load balancing · Forward external traffic to a specific virtual machine A diagram showing the assembly of elements is attached. Before creating the load balancer, you have to create backend pool and probes. One important thing about creating the backend pool is that only the virtual machines that are included in an availability set is permitted to add to the backend pool. And very importantly, a virtual machine can be added to an availability set only at the time of its creation. Once you created the load balancer, you can add load balancing rules where you can define ports and virtual machines that cater requests. furthermore you can define a different port for the users to access and map that to the actual port in the virtual machine which increases security. Also you can define whether requests are TCP or UDP based. more about the load balancer its advantages can be found here [1] *Capturing Virtual Machine Images as templates* Azure provides the feature of generalizing and capturing virtual machines so that they can be used as templates. This is very useful and time saving when the production environment has many instances of the same kind of virtual machine. When the virtual machine is being generalized all the data in user directories are erased so better to have wso2 product directory not in "/home/*". More about this can be found here [2]. Once the virtual machine is captured, it is stored in the storage account that is associated with the virtual machine. You can either download this or use directly by referring to the URI when you want to make other virtual machines with this template. What would be awesome is if we can fully configure the virtual machine with a given product and make it available to users. [1] https://azure.microsoft.com/en-us/documentation/articles/load-balancer-overview/ [2] https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-capture-image/ Thanks, On Wed, Jul 6, 2016 at 12:18 PM, Osura Rathnayake <osura...@gmail.com> wrote: > Hi Akila, > > Please refer to the screenshots that I have attached. When I updated > localMemberPort to 4200, I can see it being reflected in logs when members > are joining. So should I still make modifications in the code? > > .gitignore was added. > > okay I will write test cases in testNG and update > > thanks, > > On Wed, Jul 6, 2016 at 9:06 AM, Akila Ravihansa Perera <raviha...@wso2.com > > wrote: > >> Hi, >> >> On Tue, Jul 5, 2016 at 11:38 AM, Osura Rathnayake <osura...@gmail.com> >> wrote: >> >>> Hi Akila, >>> >>> Please check the modified code. It now takes the value which is >>> specified as localMemberPort in axis2.xml. >>> >> >> I still don't see any change to the logic of how member address is >> calculated. Can you double check? >> >> Please make sure "target/**" directories are ignored from .gitignore. >> These shouldn't be in the repo [1]. You might also need to ignore any IDE >> specific files. Have a look at .gitignore in Kubernetes artifacts [2]. >> >> I see that you have committed some test cases based on JUnit. Please note >> that as a platform we are moving to testng framework so better to use that. >> @Imesh, Isuru: Please correct me if I'm wrong. >> >> Shall we get a repo created under wso2-incubator for this? >> >> [1] https://github.com/osuran/azure-membership-scheme/tree/master/target >> [2] https://github.com/wso2/kubernetes-artifacts/blob/master/.gitignore >> >> Thanks. >> -- >> Akila Ravihansa Perera >> WSO2 Inc.; http://wso2.com/ >> >> Blog: http://ravihansa3000.blogspot.com >> > > > > -- > Regards, > Osura Rathnayake > -- Regards, Osura Rathnayake
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
