ipapapa
commented
7 years ago @djk29a Let us differentiate DynomiteDB (the commercial product) and Dynomite (the Netflix OSS). Dynomite does in fact use static token assignments, but that does not stop somebody from doing scale up and scale down. Dynomite's token assignment is based on the Dynamo protocol as is Casssandra and several other databases.
Conductor leverages Dyno in the DAO. If an IP changes from Dynomite, then Dyno will get the information from the Cluster Describe REST endpoint available of Dynomite to prime the connection to the new node. This happens in combination with the status that the Discovery Service/ELB/Eureka at Netflix provides.
Hope the above answers your question. Feel free to reach out for any further information.
djk29a
The current Conductor configuration line for Dynomite hosts uses the pattern
workflow.dynomite.cluster.hosts=host1:1234:zone1;host2:1234:zone2 ....This is possibly an issue in dynamically scaled environments where clusters can scale up and down frequently. I suspect that these hosts should correspond to what DynomiteDB calls seed nodes. Elasticsearch and Zookeeper have resolved this dynamic configuration problem in different, fairly authoritative ways (Elasticsearch with its AWS discovery plugin and Zookeeper with an external manager like Exhibitor). I'm concerned that we should restart all Conductor service instances if DynomiteDB hosts change in IP or number.
My current approach in AWS is to use Elastic Network Interfaces with static IPs reserved for DynomiteDB seed nodes and Conductor should set DynomiteDB hosts to these ENI IPs. If DynomiteDB has a host list change I'll trust Conductor to do client side load balancing / failover basically.
I suspect my issue is more of a Dynomite related issue, but any recommendation would be appreciated.