On Tue, Jul 12, 2016 at 12:09 PM, Osura Rathnayake <osura...@gmail.com> wrote:
> Hi Imesh, > > About centralized logging, I'm trying to get logs to the Log Analytics > using few methods supported in azure. We can either parse logs in to > syslogs and send to the Log Analytics or create custom logs specifying the > logs location. As you said, logs shouldn't be in .txt extension, I got it > clarified from a azure blog. Will update you soon after I could resolve it. > > Right, thanks for the update! > No you can't dynamically add VMs to the load balancer. Backend pool, where > all the VMs reside, should be predefined. > Technically that capability should be there. Otherwise we would not be able to autoscale a server cluster dynamically. > you can auto-scale using scale sets(I'm still researching about it), > that's the equivalent of AWS auto scaling group . also you can scale up or > down a VM if it exceeds a certain parameter like CPU usage, using > monitoring rules. > > *Monitoring * > > > Azure has a native monitoring tool which involves collecting and tracking > metrics, analyzing log files, defining custom metrics and logging generated > by specific applications or workloads running in Virtual Machines. Azure > represents monitored data in a graphical manner using charts. Monitoring > also facilitates triggering alarms when certain conditions are met and also > it can be configured to take actions on the met conditions. Monitoring is > done by the Diagnostic Extension and it has following capabilities. > > · Collects and uploads the system performance information from > the Linux VM to the user's storage table, including diagnostic and syslog > information. > > · Enables users to customize the data metrics that will be > collected and uploaded. > > · Enables users to upload specified log files to a designated > storage table. > > Note: Azure storage tables are a non-relational, key-value-pair, storage > system suitable for storing massive amounts of unstructured data. > > > We can add monitor rules so that when an alert triggers it notifies the > admins via email. Furthermore we can set to take automated actions. Azure > automate actions by running runbooks. A runbook is a set of tasks that > perform some automated process in Azure Automation. We can create our own > runbooks as well. Available runbooks include, > > · Restart VM > > · Stop VM > > · Remove VM > > · Scale up VM > > · Scale down VM > > When scaling up it sets the virtual machine to the next larger size within > the size group and when scaling down it sets the virtual machine to the > next smaller size within the size group. > > More about runbooks and automation [1] > Sounds good, will us be able to do a POC on this? > > *Auto scaling * > > > Auto-scaling is the process of dynamically allocating the resources > required by an application to match performance requirements. Virtual > machine scale sets are an Azure Compute resource you can use to deploy and > manage a set of identical VMs. With all VMs configured the same, VM scale > sets are designed to support true auto-scale no pre-provisioning of VMs is > required – and as such makes it easier to build large-scale services > targeting big compute, big data, and containerized workloads [2]. > > > Note: I couldn’t practically do this as my azure free account lets me have > only 4 cores and I have used all of them on my current deployment. I’m > getting a new azure account from one of my friends in a day so hopefully I > will do this on it and update you. > Great! Thanks! > > [1] > https://azure.microsoft.com/en-us/documentation/articles/automation-intro/ > > [2] > https://azure.microsoft.com/en-us/documentation/articles/virtual-machine-scale-sets-overview/ > > > thanks, > > > On Mon, Jul 11, 2016 at 9:54 AM, Imesh Gunaratne <im...@wso2.com> wrote: > >> On Thu, Jul 7, 2016 at 7:11 PM, Osura Rathnayake <osura...@gmail.com> >> wrote: >> >>> Hi Mentors, >>> >>> >>> In addition to refining the membership scheme code, I looked into >>> following features of Azure. >>> >>> >> Good findings Osura, please find few questions inline: >> >> >>> >>> >>> *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. >>> >>> >> Can members be dynamically added and removed to/from a load balancer? To >> check this we may need to explore how autoscaling works. On AWS this is >> handled with autoscaling groups [3] >> >>> >>> *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. >>> >>> >>> >> Yes, this is mandatory. Otherwise we would not be able to autoscale a >> server cluster. >> >> I'm sorry I may have missed, how did it go with centralized logging? >> >> [3] >> http://docs.aws.amazon.com/autoscaling/latest/userguide/AutoScalingGroup.html >> >> Thanks >> >> >>> [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 >>> >> >> >> >> -- >> *Imesh Gunaratne* >> Software Architect >> WSO2 Inc: http://wso2.com >> T: +94 11 214 5345 M: +94 77 374 2057 >> W: https://medium.com/@imesh TW: @imesh >> >> > > > -- > Regards, > Osura Rathnayake > -- *Imesh Gunaratne* Software Architect WSO2 Inc: http://wso2.com T: +94 11 214 5345 M: +94 77 374 2057 W: https://medium.com/@imesh TW: @imesh
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
