ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Scherbakov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IGNITE-4378) Affinity function should support assigning partition to subset of cluster nodes
Date Mon, 12 Dec 2016 16:59:58 GMT

    [ https://issues.apache.org/jira/browse/IGNITE-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742451#comment-15742451
] 

Alexei Scherbakov commented on IGNITE-4378:
-------------------------------------------

Dmitriy, thanks for the comment.

* I think this is a good idea. Abstract affinity can implement the logic to combine filters
(or some other building blocks) together to produce various effects. Currently, if I use excludeNeighbors
property, I basically can't further filter down backups. Such scenarios should be implemented
by combination of filters.

I need to do more research on current affinity implementations to provide the sample base
code.

* {{AffinityPrimaryFilter}} filters only primary nodes. But they can be put together with
{{AffinityBackupFilter}} in one interface.

* Agreed.

Also I think we should provide test framework to verify AF feasibiltiy and quality.


> Affinity function should support assigning partition to subset of cluster nodes
> -------------------------------------------------------------------------------
>
>                 Key: IGNITE-4378
>                 URL: https://issues.apache.org/jira/browse/IGNITE-4378
>             Project: Ignite
>          Issue Type: New Feature
>          Components: cache
>            Reporter: Dmitriy Setrakyan
>            Assignee: Alexei Scherbakov
>             Fix For: 2.0
>
>
> Currently both default affinity function(AF) implementations randomly choose primary
node among all topology nodes.
> This may not be enough to handle complex data placement scenarios without implementing
own AF.
> On example, some partitions can be assigned to more powerful hardware, or limited to
subset of cluster nodes due to ease of management or fault tolerance scenarios.
> We should implement node filter, which will allow to choose subset of cluster nodes to
place primary and backup partitions.
> With already existing ability to filter backup nodes (using {{AffinityBackupFilter}})
it will allow to implement different approaches to data placement with Ignite without resorting
to custom AF.
> It's also desirable to include a practical example of both topology filters based on
node attribute values.
> Proposed primary filter interface is below.
> {noformat}
> /**
>  * Allows partition placement to subset of cluster node.
>  *
>  * Backup nodes also will be assigned from the subset.
>  */
> public interface AffinityPrimaryFilter extends IgniteBiClosure<Integer, List<ClusterNode>,
List<ClusterNode>> {
>     /**
>      * Return nodes allowed to contain given partition.
>      * @param partition Partition.
>      * @param currentTopologyNodes All nodes from current topology.
>      * @return Subset of nodes.
>      */
>     @Override public List<ClusterNode> apply(Integer partition, List<ClusterNode>
currentTopologyNodes);
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message