stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reka Thirunavukkarasu <r...@wso2.com>
Subject Re: Stratos Cluster Monitoring
Date Fri, 19 Sep 2014 09:02:54 GMT
Hi

On Fri, Sep 19, 2014 at 11:15 AM, Rajkumar Rajaratnam <rajkumarr@wso2.com>
wrote:

> Hi Lahiru,
>
> Is there any specific reason to keep separate map for each type of cluster
> monitors in AutoscalerContext.
>
>     // Map<ClusterId, ClusterMonitor>
>     private Map<String, ClusterMonitor> monitors;
>     // Map<LBClusterId, LBClusterMonitor>
>     private Map<String, LbClusterMonitor> lbMonitors;
>
> Why can't we use a single map to keep all type of cluster monitors?
>
>     // Map<ClusterId, AbstractClusterMonitor>
>     private Map<String, AbstractClusterMonitor> monitors;
>
> This will simplify the logic when the number of cluster monitor types are
> increasing (now its increasing).
>

> wdyt?
>
> +1 for doing this..Even i'm doing like that in the monitor support for
Complex Application.


> Thanks.
>
> On Fri, Sep 19, 2014 at 10:46 AM, Rajkumar Rajaratnam <rajkumarr@wso2.com>
> wrote:
>
>> Hi Reka,
>>
>> On Fri, Sep 19, 2014 at 10:17 AM, Reka Thirunavukkarasu <reka@wso2.com>
>> wrote:
>>
>>> Hi
>>>
>>>
>>> Please find my answers inline..
>>>
>>> On Fri, Sep 19, 2014 at 9:57 AM, Isuru Haththotuwa <isuruh@apache.org>
>>> wrote:
>>>
>>>> Hi Raj,
>>>>
>>>> On Thu, Sep 18, 2014 at 10:53 PM, Rajkumar Rajaratnam <
>>>> rajkumarr@wso2.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> As discussed in the other thread[1], I am restructuring the existing
>>>>> cluster monitor design along with implementing docker cluster monitor.
>>>>>
>>>>> I am implementing docker cluster monitor according to the following
>>>>> design; Please note that I am renaming the existing cluster monitors
too.
>>>>> Because, If you look at the current cluster monitors' names, these are
very
>>>>> confusing; We have an abstract 'AbstractMonitor' and one of its concrete
>>>>> subclass 'ClusterMonitor', which doesn't make any sense (how it is
>>>>> different from others?).
>>>>>
>>>> Currently we only have a LBClusterMonitor and a ClusterMonitor for all
>>>> non-lb services. Maybe that is the reason why the name is not given a
>>>> specific prefix. +1 to having meaningful names now that we are going to
>>>> have several Monitor types.
>>>>
>>>>>
>>>>> Hence I am proposing the following names for stratos cluster monitors.
>>>>> Basic idea is, each cluster monitor is either monitoring a service cluster
>>>>> or a lb cluster, and each of these cluster can either be a VM cluster
or a
>>>>> Container cluster.
>>>>>
>>>>>
>>>>> ​
>>>>> Are we okay with class names and design?
>>>>>
>>>>> As you can see, plugging in a new 'entity' cluster monitor becomes
>>>>> easier with this new design.
>>>>>
>>>>> ContainerClusterMonitor has an attribute of type
>>>>> KubernetesClusterContext to keep track of information such as
>>>>> kubernetes_cluster_id, active/pending/obsoleted members, monitoring
>>>>> interval, min/max replicas.. etc, per service cluster.
>>>>>
>>>>>
>>>>> ​
>>>>> Currently, we do not have a factory design pattern for creating
>>>>> cluster monitors. I introduced a ClusterMonitorFactory which will be
used
>>>>> by AutoscalerTopologyEventReceiver.
>>>>>
>>>> +1
>>>>
>>>>>
>>>>> As Nirmal mentioned in the other thread[1], min check will be handled
>>>>> by the kubernetes itself. ContainerClusterMonitor job is to create a
>>>>> kubernetes replication controller with the minimum number of replicas
>>>>> initially via CC and need to update the number of replicas of the same
>>>>> kubernetes replication controller (again via CC) based on the health
stats
>>>>> and make sure that the number of replicas are maintained under maximum
>>>>> replicas count.
>>>>>
>>>>
>>> Earlier we used to spin LB per network partition. AFAIK, that's why we
>>> had to keep a separate LBClusterMonitor as it is monitoring almost all the
>>> network partitions.  Since we don't have the network partition concept in
>>> kubernetes, how are we going to handle LB cartridges? Do you think that
>>> still we need a separate LBClusterMonitor in docker? Also, how can we
>>> achieve the high availability by having more than one  Lbs with Docker?
>>>
>>
>> AFAIK, we haven't decided on the docker lb cartridges yet. We are going
>> to use VM lb for 4.1.0 M2. For the sake of completeness only, I have added
>> a docker lb cluster monitor
>> in the monitor hierarchy. I will update with the relevant information
>> once we decided on docker lb cartridges.
>>
>> Thanks.
>>
>>
>>> Thanks,
>>> Reka
>>>
>>>>
>>>>> Appreciate your feedback and suggestions.
>>>>>
>>>>> I will keep update this thread with progress.
>>>>>
>>>>> 1. Stratos and Kuburnetes and docker support
>>>>>
>>>>> Thanks.
>>>>>
>>>>> --
>>>>> Rajkumar Rajaratnam
>>>>> Software Engineer | WSO2, Inc.
>>>>> Mobile +94777568639 | +94783498120
>>>>>
>>>>> --
>>>>> <%2B94783498120>
>>>>> Thanks and Regards,
>>>>>
>>>>> Isuru H.
>>>>> <%2B94783498120>
>>>>> +94 716 358 048 <%2B94783498120>* <http://wso2.com/>*
>>>>>
>>>>>
>>>>> * <http://wso2.com/>*
>>>>>
>>>>>
>>>>>
>>>
>>>
>>> --
>>> Reka Thirunavukkarasu
>>> Senior Software Engineer,
>>> WSO2, Inc.:http://wso2.com,
>>> Mobile: +94776442007
>>>
>>>
>>>
>>
>>
>> --
>> Rajkumar Rajaratnam
>> Software Engineer | WSO2, Inc.
>> Mobile +94777568639 | +94783498120
>>
>
>
>
> --
> Rajkumar Rajaratnam
> Software Engineer | WSO2, Inc.
> Mobile +94777568639 | +94783498120
>



-- 
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007

Mime
View raw message