Re: [jira] [Commented] (S4-141) Enhance S4 with the elasticity feature
Does the elastic feature of s4 contain the moving Pnode? 2013/9/8 Kurtt.Lin (JIRA) > > [ > https://issues.apache.org/jira/browse/S4-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13761224#comment-13761224] > > Kurtt.Lin commented on S4-141: > -- > > @Matthieu @Kishore thanks for your guys’ clarification and for your great > jobs in S4-110. We are on the same page now; let’s get first get one > version out relying on checkpointing for moving PEs. I've pulled S4 110 > branch out and will look into the code in the next couple of days to catch > up with you guys. > > Also agree with @Kishore that Sender and Receiver that should keep track > of topology changes. Not very urgent, though. > > Indeed lots of refactors are required. @Kishore, please break it up into > subtasks, will you? Like you said, it’s an exciting path! > > > Enhance S4 with the elasticity feature > > -- > > > > Key: S4-141 > > URL: https://issues.apache.org/jira/browse/S4-141 > > Project: Apache S4 > > Issue Type: New Feature > >Reporter: Kurtt.Lin > > Attachments: S4-141.pdf > > > > Original Estimate: 2,016h > > Remaining Estimate: 2,016h > > > > Attached is a design documentation draft, which aims at enhancing S4 > with the elasticity feature. > > Issues discussed are: > > * introduction to elasticity > > * current status with S4 > > * possible roadmap > > * the design > > * implementation with Helix > > -- > This message is automatically generated by JIRA. > If you think it was sent incorrectly, please contact your JIRA > administrators > For more information on JIRA, see: http://www.atlassian.com/software/jira >
[jira] [Commented] (S4-141) Enhance S4 with the elasticity feature
[ https://issues.apache.org/jira/browse/S4-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13761224#comment-13761224 ] Kurtt.Lin commented on S4-141: -- @Matthieu @Kishore thanks for your guys’ clarification and for your great jobs in S4-110. We are on the same page now; let’s get first get one version out relying on checkpointing for moving PEs. I've pulled S4 110 branch out and will look into the code in the next couple of days to catch up with you guys. Also agree with @Kishore that Sender and Receiver that should keep track of topology changes. Not very urgent, though. Indeed lots of refactors are required. @Kishore, please break it up into subtasks, will you? Like you said, it’s an exciting path! > Enhance S4 with the elasticity feature > -- > > Key: S4-141 > URL: https://issues.apache.org/jira/browse/S4-141 > Project: Apache S4 > Issue Type: New Feature >Reporter: Kurtt.Lin > Attachments: S4-141.pdf > > Original Estimate: 2,016h > Remaining Estimate: 2,016h > > Attached is a design documentation draft, which aims at enhancing S4 with the > elasticity feature. > Issues discussed are: > * introduction to elasticity > * current status with S4 > * possible roadmap > * the design > * implementation with Helix -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (S4-141) Enhance S4 with the elasticity feature
[ https://issues.apache.org/jira/browse/S4-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13760936#comment-13760936 ] kishore gopalakrishna commented on S4-141: -- Great write up Kurtt. Definitely the right direction Agree with Matthieu that we should first get one version relying on distributed storage like NFS, HDFS, S3, Hbase etc. However each node having local storage is definitely more appealing. The only problem would be handling failure which will then require replicating the state. We can definitely do this by storing the checkpoint data on more than one node. For example we can have a node in standby state in helix and the leader node when it checkpoints, sends the checkpoint data over to in standby node as well. This will allow us to handle failures as well. For elasticity, we can do something like you have outlined but with ability to save the checkpoint data on multiple nodes we can handle failures even during elasticity. You are right that Helix does not have any rebalancer that moves partitions around based on health/performance metrics. For small clusters writing health metrics to zookeeper per partition works but for larger cluster/partitions zk wont scale.But the rebalancer can be agnostic of where it gets the metrics. We have a contribution(patch) that uses google-or tools to periodically recompute the mapping but we should probably do this in next phase. S4-110 had to clean up some of the existing code in S4. We can start again from trunk. The main piece of code in S4 that needed change was emitter and listener. Emitter and listener kind of own the partition routing but ideally it should be the Sender and Receiver that should keep track of topology changes. As Flavio suggested, we can break it up into multiple subtasks. I can take a stab at it. Excited to see this happening!!! > Enhance S4 with the elasticity feature > -- > > Key: S4-141 > URL: https://issues.apache.org/jira/browse/S4-141 > Project: Apache S4 > Issue Type: New Feature >Reporter: Kurtt.Lin > Attachments: S4-141.pdf > > Original Estimate: 2,016h > Remaining Estimate: 2,016h > > Attached is a design documentation draft, which aims at enhancing S4 with the > elasticity feature. > Issues discussed are: > * introduction to elasticity > * current status with S4 > * possible roadmap > * the design > * implementation with Helix -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (S4-141) Enhance S4 with the elasticity feature
[ https://issues.apache.org/jira/browse/S4-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13760390#comment-13760390 ] Flavio Junqueira commented on S4-141: - It might be a good idea to break this up into subtasks so that it is easier to review and commit. > Enhance S4 with the elasticity feature > -- > > Key: S4-141 > URL: https://issues.apache.org/jira/browse/S4-141 > Project: Apache S4 > Issue Type: New Feature >Reporter: Kurtt.Lin > Attachments: S4-141.pdf > > Original Estimate: 2,016h > Remaining Estimate: 2,016h > > Attached is a design documentation draft, which aims at enhancing S4 with the > elasticity feature. > Issues discussed are: > * introduction to elasticity > * current status with S4 > * possible roadmap > * the design > * implementation with Helix -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (S4-141) Enhance S4 with the elasticity feature
[ https://issues.apache.org/jira/browse/S4-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13760318#comment-13760318 ] Matthieu Morel commented on S4-141: --- That looks quite interesting thanks for formalizing the proposal! S4-110 focuses on elasticity when adding or removing nodes. It does not consider automatic load balancing, although being able to repartition efficiently can be seen as a first step. in S4-110 Helix is used to distribute and re-distribute PEs across nodes. We actually gather keys into partitions (buckets), with nb partitions >> nb nodes (You also mention this approach in your document). Helix computes a routing table (partition->node mapping). When nodes are added or removed, Helix efficiently updates the routing table in order to minimize reallocations Regarding the transfer of state and messages: - the simplest approach is to rely on checkpointing for moving PEs. We may lose some state or some messages, but in many cases that's quite acceptable. - if more guarantees are required then something like what you propose could be envisaged, i.e. proactively migrating state and buffering messages. But it's a lot more complex to implement. Regarding the status of S4-110: this is not fully complete. Mostly because the approach requires a lot of refactoring - ideally there should be a less intrusive way to integrate Helix - and because the 0.6 codebase evolved in parallel with many refactorings as well. But it's worth having a look. > Enhance S4 with the elasticity feature > -- > > Key: S4-141 > URL: https://issues.apache.org/jira/browse/S4-141 > Project: Apache S4 > Issue Type: New Feature >Reporter: Kurtt.Lin > Attachments: S4-141.pdf > > Original Estimate: 2,016h > Remaining Estimate: 2,016h > > Attached is a design documentation draft, which aims at enhancing S4 with the > elasticity feature. > Issues discussed are: > * introduction to elasticity > * current status with S4 > * possible roadmap > * the design > * implementation with Helix -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
