Monday, May 20, 2019

Fire walling DSE/Cassandra ports

Fire-walling DSE/Cassandra ports, Allowing only those servers in the list are eligible for connection to database/storage etc

ssh to corresponding Cassandra node and we will designate what traffic to allow and what traffic to not.

Example: On cassandra node0, follow as below
sudo iptables -A INPUT -p tcp --dport 9042 -s appserver-IP -j ACCEPT

-A, Means appends to input rules
-p, is rule to tcp protocol traffic
--dport, is for destination port
-s, source ip to be allowed
-j, tells what to do, in this case accept traffic

Now, Similarly configure to other Cassandra/DSE nodes in the same server.
sudo iptables -A INPUT -p tcp --dport 9042 -s node1-IP -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 9042 -s node2-IP -j ACCEPT

Then we also need to allow, connection to communicate across Cassandra nodes on port 7000

sudo iptables -A INPUT -p tcp --dport 7000 -s node1-IP -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 7000 -s node2-IP -j ACCEPT

Then other attempts from other nodes to be dropped, so as follows
sudo iptables -A INPUT -p tcp --dport 9042 -j DROP
sudo iptables -A INPUT -p tcp --dport 7000 -j DROP

***
Verify by doing telnet to corresponding node from any other remote servers. Example "telnet node0 9042", it can't connect.

***

Thursday, May 2, 2019

Will Cassandra Counters cause machine resources utilization overhead?

Usually counter writes are slightly more expensive than normal writes, so it might slightly slower the commitlog replay on startup.

Couter mutations shouldn't have any negative effect on the start/stop of Cassandra process.


Concept:

A counter is divided into shards, one for each replica. Each replica owns its shard and is the only node that changes this shard. A counter write picks a leader which will do the write, the leader modifies the value of its counter shard and then sends out the states of all the shards to all the replicas. This last step is what reaches the replicas and what is stored in commitlog, it is already computed and is just a static data.

The leader reads its counter shard, updates it, and then writes it. There is some overhead on reading because you need to resolve conflicts between replicas and add up counter shards.

***