You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stratos.apache.org by Rajkumar Rajaratnam <ra...@wso2.com> on 2014/09/18 19:23:18 UTC
Stratos Cluster Monitoring
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?).
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.
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.
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
Re: Stratos Cluster Monitoring
Posted by Akila Ravihansa Perera <ra...@wso2.com>.
Hi Raj,
+1 for the proposed hierarchy of cluster monitors.
I also think it should be one adder class that gets the relevant monitor
type from the factory class. But I'm not sure about the original thinking
that led to this separate adder approach.
Also we will have to implement hashCode and equals methods for monitor
classes since we're keeping them in a hash map.
Thanks.
On 19 Sep 2014 18:59, "Rajkumar Rajaratnam" <ra...@wso2.com> wrote:
> Hi,
>
> Currently, we are having many ClusterMonitorAdder inner classes in
> AutoscalerTopologyEventReceiver class to create each type of cluster
> monitor)
>
> If you see, we have ClusterMonitorAdder, LbClusterMonitorAdder inner
> classes. IMO, we do not need to have separate cluster monitor adder per
> cluster type.
>
> Since we are having a cluster monitor hierarchy now, ideally we should
> have only one cluster monitor adder class which will talk to
> cluster monitor factory to get the monitor and start it as a new thread.
>
> wdyt?
>
> On Fri, Sep 19, 2014 at 2:34 PM, Reka Thirunavukkarasu <re...@wso2.com>
> wrote:
>
>> Hi Raj,
>>
>> 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 <re...@wso2.com>
>>> wrote:
>>>
>>>> Hi
>>>>
>>>>
>>>> Please find my answers inline..
>>>>
>>>> On Fri, Sep 19, 2014 at 9:57 AM, Isuru Haththotuwa <is...@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 for updating. That's fine. Will get the update later..
>>
>> Thanks,
>> Reka
>>
>> 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
>>>
>>
>>
>>
>> --
>> Reka Thirunavukkarasu
>> Senior Software Engineer,
>> WSO2, Inc.:http://wso2.com,
>> Mobile: +94776442007
>>
>>
>>
>
>
> --
> Rajkumar Rajaratnam
> Software Engineer | WSO2, Inc.
> Mobile +94777568639 | +94783498120
>
Re: Stratos Cluster Monitoring
Posted by Rajkumar Rajaratnam <ra...@wso2.com>.
Hi,
Currently, we are having many ClusterMonitorAdder inner classes in
AutoscalerTopologyEventReceiver class to create each type of cluster
monitor)
If you see, we have ClusterMonitorAdder, LbClusterMonitorAdder inner
classes. IMO, we do not need to have separate cluster monitor adder per
cluster type.
Since we are having a cluster monitor hierarchy now, ideally we should have
only one cluster monitor adder class which will talk to
cluster monitor factory to get the monitor and start it as a new thread.
wdyt?
On Fri, Sep 19, 2014 at 2:34 PM, Reka Thirunavukkarasu <re...@wso2.com>
wrote:
> Hi Raj,
>
> On Fri, Sep 19, 2014 at 10:46 AM, Rajkumar Rajaratnam <ra...@wso2.com>
> wrote:
>
>> Hi Reka,
>>
>> On Fri, Sep 19, 2014 at 10:17 AM, Reka Thirunavukkarasu <re...@wso2.com>
>> wrote:
>>
>>> Hi
>>>
>>>
>>> Please find my answers inline..
>>>
>>> On Fri, Sep 19, 2014 at 9:57 AM, Isuru Haththotuwa <is...@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 for updating. That's fine. Will get the update later..
>
> Thanks,
> Reka
>
> 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
>>
>
>
>
> --
> Reka Thirunavukkarasu
> Senior Software Engineer,
> WSO2, Inc.:http://wso2.com,
> Mobile: +94776442007
>
>
>
--
Rajkumar Rajaratnam
Software Engineer | WSO2, Inc.
Mobile +94777568639 | +94783498120
Re: Stratos Cluster Monitoring
Posted by Reka Thirunavukkarasu <re...@wso2.com>.
Hi Raj,
On Fri, Sep 19, 2014 at 10:46 AM, Rajkumar Rajaratnam <ra...@wso2.com>
wrote:
> Hi Reka,
>
> On Fri, Sep 19, 2014 at 10:17 AM, Reka Thirunavukkarasu <re...@wso2.com>
> wrote:
>
>> Hi
>>
>>
>> Please find my answers inline..
>>
>> On Fri, Sep 19, 2014 at 9:57 AM, Isuru Haththotuwa <is...@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 for updating. That's fine. Will get the update later..
Thanks,
Reka
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
>
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007
Re: Stratos Cluster Monitoring
Posted by Reka Thirunavukkarasu <re...@wso2.com>.
Hi
On Fri, Sep 19, 2014 at 11:15 AM, Rajkumar Rajaratnam <ra...@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 <ra...@wso2.com>
> wrote:
>
>> Hi Reka,
>>
>> On Fri, Sep 19, 2014 at 10:17 AM, Reka Thirunavukkarasu <re...@wso2.com>
>> wrote:
>>
>>> Hi
>>>
>>>
>>> Please find my answers inline..
>>>
>>> On Fri, Sep 19, 2014 at 9:57 AM, Isuru Haththotuwa <is...@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
Re: Stratos Cluster Monitoring
Posted by Rajkumar Rajaratnam <ra...@wso2.com>.
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?
Thanks.
On Fri, Sep 19, 2014 at 10:46 AM, Rajkumar Rajaratnam <ra...@wso2.com>
wrote:
> Hi Reka,
>
> On Fri, Sep 19, 2014 at 10:17 AM, Reka Thirunavukkarasu <re...@wso2.com>
> wrote:
>
>> Hi
>>
>>
>> Please find my answers inline..
>>
>> On Fri, Sep 19, 2014 at 9:57 AM, Isuru Haththotuwa <is...@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
Re: Stratos Cluster Monitoring
Posted by Rajkumar Rajaratnam <ra...@wso2.com>.
Hi Reka,
On Fri, Sep 19, 2014 at 10:17 AM, Reka Thirunavukkarasu <re...@wso2.com>
wrote:
> Hi
>
>
> Please find my answers inline..
>
> On Fri, Sep 19, 2014 at 9:57 AM, Isuru Haththotuwa <is...@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
Re: Stratos Cluster Monitoring
Posted by Reka Thirunavukkarasu <re...@wso2.com>.
Hi
Please find my answers inline..
On Fri, Sep 19, 2014 at 9:57 AM, Isuru Haththotuwa <is...@apache.org>
wrote:
> Hi Raj,
>
> On Thu, Sep 18, 2014 at 10:53 PM, Rajkumar Rajaratnam <ra...@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?
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
Re: Stratos Cluster Monitoring
Posted by Isuru Haththotuwa <is...@apache.org>.
Hi Raj,
On Thu, Sep 18, 2014 at 10:53 PM, Rajkumar Rajaratnam <ra...@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.
>
> 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/>*
>
>
>