If I know one the IP address of one Riak node, how do I use the Riak API to discover the other nodes?
Update 2013-10-22 5:37 PM CST: One of the reasons I want to do this is to detect network partitions. Being aware of them could be helpful. If my dev-ops infrastructure knows the list of Riak machines, then I could (as needed) contact each node and make sure that all are connected. If not, then it tells me that something in the dev-ops code isn't quite right or something else went wrong.
Connect to http://my-riak-node:8098/stats and inspect ring_members, which contains the "list of nodes which are members of the ring" according to the Riak HTTP API.
Related
I am using AWS ElastiCache for Redis as the caching solution for my spring-boot application. I am using spring-boot-starter-data-redis and jedis client to connect with my cache.
Imagine that I am having my cache in cluster-mode-enabled and 3 shards with 2 nodes in each. I agree then the best way of doing it is using the configuration-endpoint. Alternatively, I can list all the endpoints of all nodes and let the job done.
However, even if I use a single node's endpoint from one of the shards, my caching solution works. That doesn't looks right to me. I feel even if it works, that might case problems in the cluster in long run. When there are all together 6 nodes partitioned into 3 shards but only using one node's endpoint. I have following questions.
Is using one node's endpoint create an imbalance in the cluster?
or
Is that handled automatically by the AWS ElastiCache for Redis?
If I use only one node's endpoint does that mean the other nodes will never being used?
Thank you!
To answer your questions;
Is using one node's endpoint create an imbalance in the cluster?
NO
Is that handled automatically by the AWS ElastiCache for Redis?
Somewhat
if I use only one node's endpoint does that mean the other nodes will never being used?
No. All nodes are being used.
This is how Cluster Mode Enabled works. In your case, you have 3 shards meaning all your slots (where key-value data is stored) are divided into 3 sub-clusters ie. shards.
This was explained in this answer as well - https://stackoverflow.com/a/72058580/6024431
So, essentially, your nodes are smart enough to re-direct your requests to the nodes that has the key-slot where your data needs to be stored. So, no imbalances. Redis handles the redirection for you.
Now, while using Node endpoints, you're going to be facing other problems.
Elasticache is running on cloud (which is essentially AWS Hardware). All hardware faces issues. You have 3 primaries (1p, 2p, 3p) and 3 (1r, 2r, 3r) replicas.
So, if a primary goes down due to hardware issue (lets say 1p), the replica will get promoted to become the new Primary for the cluster (1r).
Now the problem would be, your application is connected directly to 1p which has now been demoted to replica. So, all the WRITE operations will fail.
And you will have to change the application code manually whenever this happens.
Alternatively, if you were using configurational endpoint (or other cluster level endpoints) instead of node-endpoints, this issue would only be a blip to your application at most, perhaps for 1-2 seconds.
Cheers!
My dev node is part of the Corda test network, and when I open the logs I see something like (node etc..sent you a flow which you don't have installed, you can kill it with kill flow). So I have 2 questions:
How do I reject these calls? I know the purpose of being part of the Corda network is to have the ability for CorDapps of different orgs to transact, and I don't want to go with the segregated network model (because it's more expensive for prod and pre-prod Corda nets).
Can a node on the network perform a DoS (Denial of Service) attack by sending me flows that I don't have installed and eventually bringing my node down?
I'm not sure if I'm right about my answer but as far as I know Corda Network is designed on a need to know basis and I know that you are aware of it and I was having the same doubt when I first started with Corda but I found out that one can simply block a node from sending you any undesired flows which could cost you unnecessary CPU runtime. The explanation to this is given in this link.
Apart from this I have gone through a Medium Post which explained about ResoponderFlow validating information passed through flows and one of the points mentioned over there was to verify the identity of the flow initiator(so as to find if we need that flow),which can't be done within a contract so it needs to be done inside a flow.
Also one can't keep flooding a node with a flow because it contains a timeout,maxRestartCount and backOffBase which really help in determining how the flow is getting propagated across the network.
I hope this helps you to construct a solution to your doubt.
I know the command swift-ring-builder /etc/swift/object.builder can get all storage nodes in a swift cluster. Now I want to know if there are any commands like it to get the proxy nodes in the cluster?
Every controller node itself acts as a proxy server first.The requests hit the proxy-server code in the controller node which resolves functions and methods to be called and acts upon.
The list of storage nodes MUST be accessible for all nodes in the cluster.
However, swift is agnostic about the list of proxies it has, so there is no command like that.
One suggestion, if you really need this information, would be to look at the storage nodes logs and find out the ips doing the requests. This way you can discover some or all proxies. However this method is totally imprecise.
I want to preface this by saying that I've never taken a networking class but I'm learning on the job. Things like TCP/IP networking I have a pretty basic grasp of and if you think this will hinder my attempt at this let me know.
The task I have at hand is thus: I have an Open Stack network with a bunch of nodes that can communicate with each other, all running CentOS virtual machines (just for simplicity's sake) with applications running on top of them. The task is basically to find a way to monitor the ping of every node and report whenever some kind of message (probably through http) that reports what happened. The logic of checking for the actual latency problems isn't what I'm struggling with, its the best structure to complete this task.
I'm thinking of using Nagios and setting up a distributed monitoring system. Basically my plan is to instal nagios on each node after writing my plugin (unless its already offered or exists) and it would simply ping everything else in the network once its setup and the other nodes ping it once the fact that it has joined the network is detected. I'm not sure exactly how scalable this is because if the number of nodes increase a lot would having every node pinging every other node actually be a good thing? Could it actually end up being a lot of stress on the network?
Is this a bad idea? I know a more efficient solution would be something where as long as every node is being checked (not necessarily have to have every node connected to by every other node) is more efficient. Visualizing it as a graph with a couple of points, it would be a bidirectional graph with just one path connecting each point rather than every possible point having edges between each other. But I don't know if this is the level I should be thinking about it or not.
In short, what I'm asking is: How would one go about setting up a ping monitoring system between a bunch of Open Stack nodes?
Let me know if this question makes sense. Thanks.
Still not entirely sure what you're trying to accomplish with this setup, but the Nagios setup you're describing sounds messy and likely won't cover what you need. I'd look at building packetbeat into the provisioning of each of your hosts, and then shipping that data off to Elasticsearch. That way you can watch your actual application-level traffic and response times. https://www.elastic.co/products/beats/packetbeat
I am looking for a way to replicate a small and simple relational database (like SQLite) across peers. This should work in an environment with unstable network connections, hence the need for each peer to have a full copy of the database. This should allow a peer to continue working off-line in the event of network failure.
To keep things simple, replication should only have to support the replication of addition of data, i.e. only INSERTs, not DELETEs or UPDATEs.
Does anyone know of a good - and ideally cross-platform - technology or method of creating such a system? I am currently looking at JXTA and JXSE, but I am put off by its complexity and apparant lack of life in its community after the takeover of Sun by Oracle.
Thanks!
Frans
rqlite uses the raft consensus algorithm, so it should be fairly resilient to unstable network connection.
Also, it seems to be possible to configure rqlite to accept reads even in the case of a network failure.
A similar project, dqlite, exists as a library, available in various languages, but it seems less explicit about the event of a network failure.
You may want to explore JGroups for the communication layer if you don't like JXTA. For the replication, I think you will have to implement your own code.
I am working on something similar (though the code is far from ready). I'll describe a little about my intended approach, but whether that is suitable for you depends on some key design points you'd need to consider. I am not aware of any ready-built projects that will do this, unfortunately.
In particular we'd need to know what language you wish to use, or which languages you'd rather avoid.
Also, consider how you intend to do peer dicovery - can you set up trust between node pairs manually, or do you want them to auto-discover?
Presumably all peers may insert data?
If you are able to use PHP, and are happy manually peering node pairs, then my approach may be of interest. Set up an ORM such as Doctrine, Propel or NotORM, and get each node to regularly sync with an internet time source. For each new row in a db, grab the data (either in an array or ORM object), serialise it, and push it out to all nodes that you have a trust relationship with. Where a push fails, keep a note of this and retry at periodic intervals (potentially giving up after a remote node fails to answer a large number of retries).
Pushes can either be kicked off by your application that creates the row, or can be called by whatever scheduler is available on each machine. A push message can be XML, or for simplicity can be just a POST message containing the new row and whatever metadata (e.g. timestamp of save, so as to resolve INSERT order from several nodes).
If your nodes do not have static IP addresses, they could be registered with a dynamic DNS addressing service so as to allow each node to stay in touch with peers even if their IP changes. You might also consider adding a message signing system, to ensure that messages between nodes are genuine.