Re: OpsCenter w/SSL

[Bulat Shakirzyanov]

Hi Jacob,

OpsCenter supports simultaneous management of Cassandra clusters both with
and without client-to-node encryption enabled.

The only time you'd need to use SSL everywhere, is when encrypting
OpsCenter Daemon to OpsCenter Agents connections. In that case, you have to
make sure all OpsCenter Agents connecting to a given OpsCenter Daemon use
SSL even if those agents belong to different Cassandra clusters.


On Wed, Feb 22, 2017 at 11:18 AM, Jacob Shadix <jacobsha...@gmail.com>
wrote:

> I have OpsCenter 6.0.7 setup managing multiple clusters. Only one of those
> clusters has encryption turned on (both node-to-node and client-to-node).
> In order to manage that cluster through OpsCenter, do all subsequent
> clusters have to have encryption turned on?
>
> -- Jacob Shadix
>



-- 
Cheers,
Bulat Shakirzyanov | @avalanche123 <https://twitter.com/avalanche123>

Re: Token Ring Question

[Bulat Shakirzyanov]

Drivers actually reconstruct the token ring using information about keyspace's 
replication settings as well as token ranges assigned to each node.
Whenever you prepare a statement that is parameterized by partition key, the 
driver finds the token by first converting the key to a byte array and running 
it through the hash function (partitioner) you've configured when setting up 
the cluster. This token lets the driver find replicas (nodes owning the data), 
note that the actual replicas will be different based on replication settings 
of a given keyspace. Once the replicas are found, they are either randomized or 
not, depends on your token aware policy configuration, and the request is 
delivered to those nodes first.

To summarize, token awareness works by hashing partition key of prepared 
statements at execution time as well as by reconstruction of token rings client 
side upon initial connection and schema discovery using information about 
assigned token ranges and each keyspace's replication settings.

Ruby Drivers generation of a replica map for the network topology replication 
strategy - 
https://github.com/datastax/ruby-driver/blob/master/lib/cassandra/cluster/schema/replication_strategies/network_topology.rb


Bulat

> On Jun 24, 2016, at 12:31, Anubhav Kale  wrote:
> 
> So, can someone educate me on how token aware policies in drivers really work 
> ? It appears that it’s quite possible that the data may live on nodes that 
> don’t own the tokens for it. By “own” I mean the ownership as defined in 
> system.local / peers and is fed back to drivers.
>  
> If this statement is correct,
>  
> In my view, unless the drivers execute the *Topology.GetReplicas from 
> Cassandra core somehow (something that isn’t available to them), they will 
> never be able to tell the correct node that holds data for a given token.
>  
> Is my understanding wrong ?
>  
> From: Anubhav Kale [mailto:anubhav.k...@microsoft.com] 
> Sent: Friday, June 3, 2016 3:17 PM
> To: user@cassandra.apache.org
> Subject: RE: Token Ring Question
>  
> Thank you, I was just curious about how this works.
>  
> From: Tyler Hobbs [mailto:ty...@datastax.com] 
> Sent: Friday, June 3, 2016 3:02 PM
> To: user@cassandra.apache.org
> Subject: Re: Token Ring Question
>  
> There really is only one token ring, but conceptually it's easiest to think 
> of it like multiple rings, as OpsCenter shows it.  The only difference is 
> that every token has to be unique across the whole cluster.
> 
> Now, if the token for a particular write falls in the “primary range” of a 
> node living in DC2, does the code check for such conditions and instead put 
> it on some node in DC1 ?
>  
> Yes.  It will continue searching around the token ring until it hits a token 
> that belongs to a node in the correct datacenter.
> 
> What is the true meaning of “primary” token range in such scenarios ?
>  
> There's not really any such thing as a "primary token range", it's just a 
> convenient idea for some tools.  In reality, it's just the replica that owns 
> the first (clockwise) token.  I'm not sure what you're really asking, though 
> -- what are you concerned about?
>  
>  
> On Wed, Jun 1, 2016 at 2:40 PM, Anubhav Kale  
> wrote:
> Hello,
>  
> I recently learnt that regardless of number of Data Centers, there is really 
> only one token ring across all nodes. (I was under the impression that there 
> is one per DC like how Datastax Ops Center would show it).
>  
> Suppose we have 4 v-nodes, and 2 DCs (2 nodes in each DC) and a key space is 
> set to replicate in only one DC – say DC1.
>  
> Now, if the token for a particular write falls in the “primary range” of a 
> node living in DC2, does the code check for such conditions and instead put 
> it on some node in DC1 ? What is the true meaning of “primary” token range in 
> such scenarios ?
>  
> Is this how things works roughly speaking or am I missing something ?
>  
> Thanks !
> 
> 
> 
> --
> Tyler Hobbs
> DataStax

Re: What causes NoHostAvailableException, WriteTimeoutException, and UnavailableException?

[Bulat Shakirzyanov]

Check out Ruby Driver documentation on these topics:

Error Handling
http://datastax.github.io/ruby-driver/features/error_handling/
Retry Policies
http://datastax.github.io/ruby-driver/features/retry_policies/

While the documentation is for the Ruby Driver, the concepts were borrowed
from and map directly to the Java Driver

Cheers,

On Mon, Nov 24, 2014 at 12:57 PM, Kevin Burton bur...@spinn3r.com wrote:

 I’m trying to track down some exceptions in our production cluster.  I
 bumped up our write load and now I’m getting a non-trivial number of these
 exceptions.  Somewhere on the order of 100 per hour.

 All machines have a somewhat high CPU load because they’re doing other
 tasks.  I’m worried that perhaps my background tasks are just overloading
 cassandra and one way to mitigate this is to nice them to least favorable
 priority (this is my first tasks).

 But I can’t seem to really track down any documentation on HOW to tune
 cassandra to prevent these. I mean I get the core theory behind all of this
 just need to track down the docs so I can actually RTFM :)



 --

 Founder/CEO Spinn3r.com
 Location: *San Francisco, CA*
 blog: http://burtonator.wordpress.com
 … or check out my Google+ profile
 https://plus.google.com/102718274791889610666/posts
 http://spinn3r.com




-- 
*Bulat Shakirzyanov* | Software Alchemist

*a: *about.me/avalanche123
*e:* mallluh...@gmail.com

Re: How to setup Cassandra client-to-node encryption

[Bulat Shakirzyanov]

Hi,

You need to install JCE -
http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html

Bulat

On Sep 26, 2014, at 7:58, Lu, Boying boying...@emc.com wrote:

Hi, All,



I use the following configuration (in yaml file) to enable the
client-to-node encryption:

client_encryption_options:

enabled: true

keystore: path-to-keystore-file

keystore_password: some-password

truststore: path-to-truststore-file

truststore_password: some-password



But when Cassandra starts, I got following error:

Caused by: org.apache.thrift.transport.TTransportException: Could not bind
to port 9160

at
org.apache.thrift.transport.TSSLTransportFactory.createServer(TSSLTransportFactory.java:117)

at
org.apache.thrift.transport.TSSLTransportFactory.getServerSocket(TSSLTransportFactory.java:103)

at
org.apache.cassandra.thrift.CustomTThreadPoolServer$Factory.buildTServer(CustomTThreadPoolServer.java:253)

... 6 more

Caused by: java.lang.IllegalArgumentException: Cannot support
TLS_RSA_WITH_AES_256_CBC_SHA with currently installed providers

at sun.security.ssl.CipherSuiteList.init(CipherSuiteList.java:92)

at
sun.security.ssl.SSLServerSocketImpl.setEnabledCipherSuites(SSLServerSocketImpl.java:191)

at
org.apache.thrift.transport.TSSLTransportFactory.createServer(TSSLTransportFactory.java:113)

... 8 more



Does anyone know the root cause?



Thanks a lot.



Boying

Re: CQL query regarding indexes

[Bulat Shakirzyanov]

As far as I can tell, the problem is that you're not using a partition key
in your query. AFAIK, you always have to use partition key in where clause.
And ALLOW FILTERING option is to let cassandra filter data from the rows it
found using the partition key.

One way to solve it is to make partition_id a timeuuid column and then use
that field in your where query:

SELECT * FROM b_bank_services.messagepayload WHERE
unixTimestampOf(partition_id) = 140154480 AND
unixTimestampOf(partition_id) = 140171760;

Read more at
http://www.datastax.com/documentation/cql/3.0/cql/cql_reference/timeuuid_functions_r.html


On Thu, Jun 12, 2014 at 3:43 PM, Roshan codeva...@gmail.com wrote:

 Hi

 Cassandra - 2.0.8
 DataStax driver - 2.0.2

 I have create a keyspace and a table with indexes like below.
 CREATE TABLE services.messagepayload (
   partition_id uuid,
   messageid bigint,
   senttime timestamp,
   PRIMARY KEY (partition_id)
 ) WITH compression =
 { 'sstable_compression' : 'LZ4Compressor', 'chunk_length_kb' : 64 };

 CREATE INDEX idx_messagepayload_senttime ON services.messagepayload
 (senttime);

 While I am running the below query I am getting an exception.

 SELECT * FROM b_bank_services.messagepayload WHERE senttime=140154480
 AND senttime=140171760 ALLOW FILTERING;

 com.datastax.driver.core.exceptions.InvalidQueryException: No indexed
 columns present in by-columns clause with Equal operator

 Could someone can explain what's going on? I have create a index to the
 search column, but seems not working.

 Thanks.



 --
 View this message in context:
 http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/CQL-query-regarding-indexes-tp7595122.html
 Sent from the cassandra-u...@incubator.apache.org mailing list archive at
 Nabble.com.




-- 
*Bulat Shakirzyanov* | Software Alchemist

*a: *about.me/avalanche123
*e:* mallluh...@gmail.com