From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org> To: tarantool-patches@freelists.org Cc: kostja@tarantool.org Subject: [tarantool-patches] [PATCH 2/2] swim: disseminate event for log(cluster_size) steps Date: Sun, 30 Jun 2019 01:45:03 +0200 [thread overview] Message-ID: <6ec1fe0f2d9f22d5d254bf9b434ccbd72fa72eb7.1561851087.git.v.shpilevoy@tarantool.org> (raw) In-Reply-To: <cover.1561851087.git.v.shpilevoy@tarantool.org> Before the patch there was a problem of events and anti-entropy starvation, when a cluster generates so many events, that they consume the whole UDP packet. If during the event storm something important happens, that event is likely to be lost, and not disseminated until the storm is over. Sadly, there is no way to prevent a storm, but it can be made much shorter. For that the patch makes TTD of events logarithmic instead of linear of cluster size. According to the SWIM paper and to the experiments the logarithm is really enough. Linear TTD was a redundant overkill. When events live shorter, it does not solve a problem of the events starvation - still some of them can be lost in case of a storm. But it frees some space for anti-entropy, which can finish dissemination of lost events. Experiments in a simulation of a cluster with 100 nodes showed, that a failure dissemination happened in ~110 steps if there is a storm. Linear dissemination is the worst problem. After the patch it is ~20 steps. So it is logarithmic as it should be, although with a bigger constant than without a storm. Part of #4253 --- src/lib/swim/swim.c | 117 ++++++++++++++++++++++++++++++++++++++++-- test/unit/swim.c | 30 +++++++++-- test/unit/swim.result | 3 +- 3 files changed, 142 insertions(+), 8 deletions(-) diff --git a/src/lib/swim/swim.c b/src/lib/swim/swim.c index 8edf0495d..936f6049a 100644 --- a/src/lib/swim/swim.c +++ b/src/lib/swim/swim.c @@ -327,6 +327,19 @@ struct swim_member { * allow other members to learn the dead status. */ int status_ttd; + /** + * Time To Live. When a member is dead, it can't be + * deleted from the member table immediately. Otherwise + * there is a real possibility, that other members, not + * aware of the death, will disseminate its alive state + * back via anti-entropy. TTL is a way to keep a dead + * member in the member table until the whole cluster + * knows about the death with a very hight probability, + * almost 100%. Such members are stored in a limbo queue + * for TTL round steps, and deleted afterwards. All the + * same is fair for 'left' members as well. + */ + int ttl; /** Arbitrary user data, disseminated on each change. */ char *payload; /** Payload size, in bytes. */ @@ -370,6 +383,13 @@ struct swim_member { * time in descending order. */ struct rlist in_dissemination_queue; + /** + * Members sentenced for deletion. They are kept here in + * order to wait until the whole cluster knows about their + * deletion, and nobody will try to resurrect them via + * anti-entropy. + */ + struct rlist in_limbo_queue; /** * Each time a member is updated, or created, or dropped, * it is added to an event queue. Members from this queue @@ -513,6 +533,17 @@ struct swim { * as long as the event TTD is non-zero. */ struct rlist dissemination_queue; + /** + * Queue of members waiting for their deletion. The + * members 'dead' and 'left' can't be deleted immediately + * after their new status is discovered and event about + * that is disseminated, or otherwise they may be + * resurrected back by those who didn't know about their + * death, via anti-entropy. Here the members wait until + * the whole cluster is likely to know about their death, + * and only then are deleted. + */ + struct rlist limbo_queue; /** * Queue of updated, new, and dropped members to deliver * the events to triggers. Dropped members are also kept @@ -619,11 +650,36 @@ swim_wait_ack(struct swim *swim, struct swim_member *member, static inline void swim_register_event(struct swim *swim, struct swim_member *member) { + /* + * If a member, scheduled for deletion, got an event, then + * it is alive. Somebody noticed an ack/ping from him, or + * got its new payload, or anything. Deletion of such + * members shall be canceled. + */ + if (! rlist_empty(&member->in_limbo_queue)) + rlist_del_entry(member, in_limbo_queue); if (rlist_empty(&member->in_dissemination_queue)) { rlist_add_entry(&swim->dissemination_queue, member, in_dissemination_queue); } - member->status_ttd = mh_size(swim->members); + /* + * Logarithm is a perfect number of disseminations of an + * event. + * + * Firstly, it matches the dissemination speed. + * + * Secondly, bigger number of disseminations (for example, + * linear) causes events and anti-entropy starvation in + * big clusters, when lots of events occupy the whole UDP + * packet, and factually the same packet content is being + * sent for quite a long time. No randomness. Anti-entropy + * does not get a chance to disseminate something new and + * random. Bigger orders are redundant and harmful. + * + * Thirdly, logarithm is proved by the original + * SWIM paper as the best option. + */ + member->status_ttd = log2(mh_size(swim->members)); swim_cached_round_msg_invalidate(swim); } @@ -805,6 +861,7 @@ swim_member_delete(struct swim_member *member) /* Dissemination component. */ assert(rlist_empty(&member->in_dissemination_queue)); + assert(rlist_empty(&member->in_limbo_queue)); swim_member_unref(member); } @@ -837,10 +894,40 @@ swim_member_new(const struct sockaddr_in *addr, const struct tt_uuid *uuid, /* Dissemination component. */ rlist_create(&member->in_dissemination_queue); + rlist_create(&member->in_limbo_queue); return member; } +/** Schedule member deletion after some number of steps. */ +static void +swim_send_member_to_limbo(struct swim *swim, struct swim_member *member) +{ + assert(rlist_empty(&member->in_dissemination_queue)); + assert(rlist_empty(&member->in_limbo_queue)); + rlist_add_entry(&swim->limbo_queue, member, in_limbo_queue); + int size = mh_size(swim->members); + /* + * Always linear number of steps delay would be perfect in + * terms of protection against sudden resurrection of dead + * members via anti-entropy. Even more perfect is when GC + * is off. But these values would lead to a problem when + * too many round steps are spent on sending pings to + * already 100% dead members, and when they occupy too big + * part of anti-entropy section. As a compromise here the + * linear TTL is used for small clusters, and a value of + * the same order as event dissemination speed for big + * clusters, but with a much bigger constant. + * + * According to simulations, in a cluster of size 250 a + * death event is disseminated in ~13 steps. Rarely for + * ~15 steps. But extremely rare for ~30-40 steps. + * Log2(250) is ~8, so 10 * log(N) covers all these cases, + * even super rare ones. + */ + member->ttl = MIN(size, 10 * log2(size)); +} + /** * Remove the member from all queues, hashes, destroy it and free * the memory. @@ -863,6 +950,7 @@ swim_delete_member(struct swim *swim, struct swim_member *member) /* Dissemination component. */ swim_on_member_update(swim, member, SWIM_EV_DROP); rlist_del_entry(member, in_dissemination_queue); + rlist_del_entry(member, in_limbo_queue); swim_member_delete(member); } @@ -1154,6 +1242,22 @@ swim_encode_round_msg(struct swim *swim) swim->is_round_packet_valid = true; } +/** + * Drop members, whose TTL is expired. It should be done once + * after each round step. + */ +static void +swim_decrease_member_ttl(struct swim *swim) +{ + struct swim_member *member, *tmp; + rlist_foreach_entry_safe(member, &swim->limbo_queue, + in_limbo_queue, tmp) { + assert(member->ttl > 0); + if (--member->ttl == 0) + swim_delete_member(swim, member); + } +} + /** * Decrement TTDs of all events. It is done after each round step. * Note, since we decrement TTD of all events, even those which @@ -1181,7 +1285,7 @@ swim_decrease_event_ttd(struct swim *swim) rlist_del_entry(member, in_dissemination_queue); swim_cached_round_msg_invalidate(swim); if (member->status == MEMBER_LEFT) - swim_delete_member(swim, member); + swim_send_member_to_limbo(swim, member); } } } @@ -1262,6 +1366,7 @@ swim_complete_step(struct swim_task *task, * sections. */ swim_wait_ack(swim, m, false); + swim_decrease_member_ttl(swim); swim_decrease_event_ttd(swim); } } @@ -1433,8 +1538,10 @@ swim_check_acks(struct ev_loop *loop, struct ev_timer *t, int events) break; case MEMBER_DEAD: if (m->unacknowledged_pings >= NO_ACKS_TO_GC && - swim->gc_mode == SWIM_GC_ON && m->status_ttd == 0) { - swim_delete_member(swim, m); + swim->gc_mode == SWIM_GC_ON && + m->status_ttd == 0 && + rlist_empty(&m->in_limbo_queue)) { + swim_send_member_to_limbo(swim, m); continue; } break; @@ -1892,6 +1999,7 @@ swim_new(uint64_t generation) /* Dissemination component. */ rlist_create(&swim->dissemination_queue); + rlist_create(&swim->limbo_queue); rlist_create(&swim->on_member_event); stailq_create(&swim->event_queue); swim->event_handler = fiber_new("SWIM event handler", @@ -2205,6 +2313,7 @@ swim_delete(struct swim *swim) if (! heap_node_is_stray(&m->in_wait_ack_heap)) wait_ack_heap_delete(&swim->wait_ack_heap, m); rlist_del_entry(m, in_dissemination_queue); + rlist_del_entry(m, in_limbo_queue); swim_member_delete(m); } /* diff --git a/test/unit/swim.c b/test/unit/swim.c index 07cc0f06f..6e537e95b 100644 --- a/test/unit/swim.c +++ b/test/unit/swim.c @@ -115,7 +115,7 @@ swim_test_uuid_update(void) is(swim_cluster_update_uuid(cluster, 0, &new_uuid), 0, "UUID update"); is(swim_member_status(swim_member_by_uuid(s, &old_uuid)), MEMBER_LEFT, "old UUID is marked as 'left'"); - swim_run_for(5); + swim_run_for(7); is(swim_member_by_uuid(s, &old_uuid), NULL, "old UUID is dropped after a while"); ok(swim_cluster_is_fullmesh(cluster), "dropped everywhere"); @@ -1061,7 +1061,7 @@ swim_test_triggers(void) is(tctx.ctx.events, SWIM_EV_NEW_STATUS, "status dead"); fail_if(swim_cluster_wait_status(cluster, 0, 1, - swim_member_status_MAX, 2) != 0); + swim_member_status_MAX, 4) != 0); swim_cluster_run_triggers(cluster); is(tctx.counter, 6, "drop fired a trigger"); is(tctx.ctx.events, SWIM_EV_DROP, "status dropped"); @@ -1156,7 +1156,7 @@ swim_test_generation(void) static void swim_test_dissemination_speed(void) { - swim_start_test(1); + swim_start_test(2); int size = 100; double ack_timeout = 0.1; @@ -1187,6 +1187,30 @@ swim_test_dissemination_speed(void) is(swim_cluster_wait_status_everywhere(cluster, 0, MEMBER_DEAD, log2(size) * 5), 0, "dissemination work in log time even at the very start of a cluster"); + swim_cluster_set_drop(cluster, 0, 0); + fail_if(swim_cluster_wait_status_everywhere(cluster, 0, + MEMBER_ALIVE, size) != 0); + /* + * Another big-cluster case. Assume, that something + * happened and all the members generated an event. For + * example, changed their payload. It creates a storm of + * events, among which some important ones can be lost. + * Such as a failure detection. Event age preferences do + * not help here. The only solution - make the events as + * short living as possible in order to faster free space + * in a UDP packet for other events and for anti-entropy. + * The test below proves that even when there is an event + * storm, failure dissemination still works for O(log) + * time. Although with a bit bigger constant. + */ + swim_cluster_set_drop(cluster, 0, 100); + fail_if(swim_cluster_wait_status_anywhere(cluster, 0, + MEMBER_DEAD, 5) != 0); + for (int i = 0; i < size; ++i) + swim_cluster_member_set_payload(cluster, i, "", 0); + is(swim_cluster_wait_status_everywhere(cluster, 0, MEMBER_DEAD, + log2(size) * 6), 0, + "dissemination can withstand an event storm"); swim_cluster_delete(cluster); diff --git a/test/unit/swim.result b/test/unit/swim.result index 83b6bca64..5f66200b0 100644 --- a/test/unit/swim.result +++ b/test/unit/swim.result @@ -238,8 +238,9 @@ ok 21 - subtests ok 22 - subtests *** swim_test_generation: done *** *** swim_test_dissemination_speed *** - 1..1 + 1..2 ok 1 - dissemination work in log time even at the very start of a cluster + ok 2 - dissemination can withstand an event storm ok 23 - subtests *** swim_test_dissemination_speed: done *** *** main_f: done *** -- 2.20.1 (Apple Git-117)
next prev parent reply other threads:[~2019-06-29 23:44 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-06-29 23:45 [tarantool-patches] [PATCH 0/2] SWIM big cluster improvements, part 1 Vladislav Shpilevoy 2019-06-29 23:45 ` [tarantool-patches] [PATCH 1/2] swim: prefer new events for dissemination over old Vladislav Shpilevoy 2019-06-30 16:25 ` [tarantool-patches] " Vladislav Shpilevoy 2019-06-29 23:45 ` Vladislav Shpilevoy [this message] 2019-06-30 6:55 ` [tarantool-patches] Re: [PATCH 2/2] swim: disseminate event for log(cluster_size) steps Konstantin Osipov 2019-06-30 16:24 ` Vladislav Shpilevoy
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=6ec1fe0f2d9f22d5d254bf9b434ccbd72fa72eb7.1561851087.git.v.shpilevoy@tarantool.org \ --to=v.shpilevoy@tarantool.org \ --cc=kostja@tarantool.org \ --cc=tarantool-patches@freelists.org \ --subject='Re: [tarantool-patches] [PATCH 2/2] swim: disseminate event for log(cluster_size) steps' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox