Re: Encryption at rest

[Arvinder Dhillon]

Do it at storage level.


On Wed, Jun 24, 2020, 1:01 PM Jeff Jirsa  wrote:

> Not really, no.
>
>
> On Wed, Jun 24, 2020 at 1:00 PM Abdul Patel  wrote:
>
>> Team,
>>
>> Do we have option in open source to do encryption at rest in cassandra ?
>>
>

Re: Implication of having similar private IPs in two datacenters

[Erick Ramirez]

>
> In a network one can assign valid private IP. Private IPs can conflict if
> we do not put any restriction on private IP.
>

Yes, you're right and I was aware of that (not realising that your question
was more around what I would consider multi-region comms). My disconnect
now is around the motivation for doing it.

Yes, it will work since C* will communicate over the broadcast address
across regions. But I personally wouldn't go down this path for the
operational complexity it adds though YMMV. Cheers!

Cassandra write path during the decommissioning process

[Jai Bheemsen Rao Dhanwada]

Hello,

I would like to understand how the writes happen when there is a node in
the cluster that is being decommissioned.

During the decommission process, the node will send the streams to the rest
of the nodes that it owns. what happened to the read and write of the data
that is owned by the node that is being decommissioned? does it even
receive reads and writes or the nodes doesn't receive any writes?

Re: Implication of having similar private IPs in two datacenters

[Jeff Jirsa]

So a few things are true:

- Cassandra uses IP addresses for internal data structures (in released
versions), so duplicating IP nominally means stomping on the wrong host
- Cassandra also differentiates broadcast IP from listen IP  (local IP)
- The broadcast IP is what the other DC is going to see, which probably
means internally things wont conflict. It does mean that your local DC
traffic is going to go out the NAT to the public IP (I think), which may or
may not be a problem
- In general this may actually work, but sounds horrible, and I wouldn't do
it if it were me.


On Wed, Jun 24, 2020 at 1:26 PM Elliott Sims  wrote:

> The Cassandra documentation doesn't require IPs to be unique among members
> of a cluster, because it's not a Cassandra limitation.  Hosts that want to
> communicate amongst themselves over the network need non-conflicting IPs,
> regardless of application.
>
> On Wed, Jun 24, 2020 at 5:09 AM manish khandelwal <
> manishkhandelwa...@gmail.com> wrote:
>
>> The nodes within one datacenter will talk on private IPs and for
>> communication across data center public ips are used. Does that  answer
>> your question? or you are asking in terms of network layer.
>>
>> As per this link
>> ,
>> there is no mention of private IP to be unique.
>>
>> In a network one can assign valid private IP. Private IPs can conflict if
>> we do not put any restriction on private IP.
>>
>> Regards
>>
>>
>> On Wed, Jun 24, 2020 at 5:12 PM Erick Ramirez 
>> wrote:
>>
>>> Putting Cassandra aside, I'm curious to know how you envision that would
>>> work from a network perspective. How would the connectivity between servers
>>> work?
>>>

Encryption at rest

[Abdul Patel]

Team,

Do we have option in open source to do encryption at rest in cassandra ?

Re: Cassandra upgrade from 3.11.3 -> 3.11.6

[Jon Haddad]

Generally speaking, don't run mixed versions longer than you have to, and
don't upgrade that way.

Why?

* We don't support it.
* We don't even test it.
* If you run into trouble and ask for help, the first thing people will
tell you is to get all nodes on the same version.

Anyone that's doing so that didn't specifically read the source and test it
out for themselves only got lucky in that they didn't hit any issues.  If
you do it, and hit issues, be prepared to get very familiar with the C*
source as you're on your own.

Be smart and go the supported, well traveled route.  You'll need to do it
when upgrading majors *anyways*, so you might as well figure out the right
way of doing it *today* and follow the same stable method every time you
upgrade.



On Wed, Jun 24, 2020 at 8:36 AM Jai Bheemsen Rao Dhanwada <
jaibheem...@gmail.com> wrote:

> Thank you all for the suggestions.
>
> I am not trying to scale up the cluster for capacity but for the upgrade
> process instead of in place upgrade I am planning to add nodes with 3.11.6
> and then decommission  the nodes with 3.11.3.
>
> On Wednesday, June 24, 2020, Durity, Sean R 
> wrote:
>
>> Streaming operations (repair/bootstrap) with different file versions is
>> usually a problem. Running a mixed version cluster is fine – for the time
>> you are doing the upgrade. I would not stay on mixed versions for any
>> longer than that. It takes more time, but I separate out the admin tasks so
>> that I can reason what should happen. I would either scale up or upgrade
>> (depending on which is more urgent), then do the other.
>>
>>
>>
>>
>>
>> Sean Durity
>>
>>
>>
>> *From:* manish khandelwal 
>> *Sent:* Wednesday, June 24, 2020 5:52 AM
>> *To:* user@cassandra.apache.org
>> *Subject:* [EXTERNAL] Re: Cassandra upgrade from 3.11.3 -> 3.11.6
>>
>>
>>
>> Rightly said by Surbhi, it is not good to scale with mixed versions as
>> debugging issues will be very difficult.
>>
>> Better to upgrade first and then scale.
>>
>>
>>
>> Regards
>>
>>
>>
>> On Wed, Jun 24, 2020 at 11:20 AM Surbhi Gupta 
>> wrote:
>>
>> In case of any issue, it gets very difficult to debug when we have
>> multiple versions.
>>
>>
>>
>> On Tue, 23 Jun 2020 at 22:23, Jürgen Albersdorfer <
>> jalbersdor...@gmail.com> wrote:
>>
>> Hi, I would say „It depends“ - as it always does. I have had a 21 Node
>> Cluster running in Production in one DC with versions ranging from 3.11.1
>> to 3.11.6 without having had any single issue for over a year. I just
>> upgraded all nodes to 3.11.6 for the sake of consistency.
>>
>> Von meinem iPhone gesendet
>>
>>
>>
>> Am 24.06.2020 um 02:56 schrieb Surbhi Gupta :
>>
>> 
>>
>>
>>
>> Hi ,
>>
>>
>>
>> We have recently upgraded from 3.11.0 to 3.11.5 . There is a sstable
>> format change from 3.11.4 .
>>
>> We also had to expand the cluster and we also discussed about expansion
>> first and than upgrade. But finally we upgraded and than expanded.
>>
>> As per our experience what I could tell you is, it is not advisable to
>> add new nodes on higher version.
>>
>> There are many bugs which got fixed from 3.11.3 to 3.11.6.
>>
>>
>>
>> Thanks
>>
>> Surbhi
>>
>>
>>
>> On Tue, Jun 23, 2020 at 5:04 PM Jai Bheemsen Rao Dhanwada <
>> jaibheem...@gmail.com> wrote:
>>
>> Hello,
>>
>>
>>
>> I am trying to upgrade from 3.11.3 to 3.11.6.
>>
>> Can I add new nodes with the 3.11.6  version to the cluster running with
>> 3.11.3?
>>
>> Also, I see the SSTable format changed from mc-* to md-*, does this cause
>> any issues?
>>
>>
>>
>>
>> --
>>
>> The information in this Internet Email is confidential and may be legally
>> privileged. It is intended solely for the addressee. Access to this Email
>> by anyone else is unauthorized. If you are not the intended recipient, any
>> disclosure, copying, distribution or any action taken or omitted to be
>> taken in reliance on it, is prohibited and may be unlawful. When addressed
>> to our clients any opinions or advice contained in this Email are subject
>> to the terms and conditions expressed in any applicable governing The Home
>> Depot terms of business or client engagement letter. The Home Depot
>> disclaims all responsibility and liability for the accuracy and content of
>> this attachment and for any damages or losses arising from any
>> inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other
>> items of a destructive nature, which may be contained in this attachment
>> and shall not be liable for direct, indirect, consequential or special
>> damages in connection with this e-mail message or its attachment.
>>
>

RE: Cassandra upgrade from 3.11.3 -> 3.11.6

[Durity, Sean R]

That seems like a lot of unnecessary streaming operations to me. I think 
someone said that streaming works between these 2 versions. But I would not use 
this approach. Why not an in-place upgrade?


Sean Durity

From: Jai Bheemsen Rao Dhanwada 
Sent: Wednesday, June 24, 2020 11:36 AM
To: user@cassandra.apache.org
Subject: [EXTERNAL] Re: Cassandra upgrade from 3.11.3 -> 3.11.6

Thank you all for the suggestions.

I am not trying to scale up the cluster for capacity but for the upgrade 
process instead of in place upgrade I am planning to add nodes with 3.11.6 and 
then decommission  the nodes with 3.11.3.

On Wednesday, June 24, 2020, Durity, Sean R 
mailto:sean_r_dur...@homedepot.com>> wrote:
Streaming operations (repair/bootstrap) with different file versions is usually 
a problem. Running a mixed version cluster is fine – for the time you are doing 
the upgrade. I would not stay on mixed versions for any longer than that. It 
takes more time, but I separate out the admin tasks so that I can reason what 
should happen. I would either scale up or upgrade (depending on which is more 
urgent), then do the other.


Sean Durity

From: manish khandelwal 
mailto:manishkhandelwa...@gmail.com>>
Sent: Wednesday, June 24, 2020 5:52 AM
To: user@cassandra.apache.org
Subject: [EXTERNAL] Re: Cassandra upgrade from 3.11.3 -> 3.11.6

Rightly said by Surbhi, it is not good to scale with mixed versions as 
debugging issues will be very difficult.
Better to upgrade first and then scale.

Regards

On Wed, Jun 24, 2020 at 11:20 AM Surbhi Gupta 
mailto:surbhi.gupt...@gmail.com>> wrote:
In case of any issue, it gets very difficult to debug when we have multiple 
versions.

On Tue, 23 Jun 2020 at 22:23, Jürgen Albersdorfer 
mailto:jalbersdor...@gmail.com>> wrote:
Hi, I would say „It depends“ - as it always does. I have had a 21 Node Cluster 
running in Production in one DC with versions ranging from 3.11.1 to 3.11.6 
without having had any single issue for over a year. I just upgraded all nodes 
to 3.11.6 for the sake of consistency.
Von meinem iPhone gesendet

Am 24.06.2020 um 02:56 schrieb Surbhi Gupta 
mailto:surbhi.gupt...@gmail.com>>:


Hi ,

We have recently upgraded from 3.11.0 to 3.11.5 . There is a sstable format 
change from 3.11.4 .
We also had to expand the cluster and we also discussed about expansion first 
and than upgrade. But finally we upgraded and than expanded.
As per our experience what I could tell you is, it is not advisable to add new 
nodes on higher version.
There are many bugs which got fixed from 3.11.3 to 3.11.6.

Thanks
Surbhi

On Tue, Jun 23, 2020 at 5:04 PM Jai Bheemsen Rao Dhanwada 
mailto:jaibheem...@gmail.com>> wrote:
Hello,

I am trying to upgrade from 3.11.3 to 3.11.6.
Can I add new nodes with the 3.11.6  version to the cluster running with 3.11.3?
Also, I see the SSTable format changed from mc-* to md-*, does this cause any 
issues?




The information in this Internet Email is confidential and may be legally 
privileged. It is intended solely for the addressee. Access to this Email by 
anyone else is unauthorized. If you are not the intended recipient, any 
disclosure, copying, distribution or any action taken or omitted to be taken in 
reliance on it, is prohibited and may be unlawful. When addressed to our 
clients any opinions or advice contained in this Email are subject to the terms 
and conditions expressed in any applicable governing The Home Depot terms of 
business or client engagement letter. The Home Depot disclaims all 
responsibility and liability for the accuracy and content of this attachment 
and for any damages or losses arising from any inaccuracies, errors, viruses, 
e.g., worms, trojan horses, etc., or other items of a destructive nature, which 
may be contained in this attachment and shall not be liable for direct, 
indirect, consequential or special damages in connection with this e-mail 
message or its attachment.



The information in this Internet Email is confidential and may be legally 
privileged. It is intended solely for the addressee. Access to this Email by 
anyone else is unauthorized. If you are not the intended recipient, any 
disclosure, copying, distribution or any action taken or omitted to be taken in 
reliance on it, is prohibited and may be unlawful. When addressed to our 
clients any opinions or advice contained in this Email are subject to the terms 
and conditions expressed in any applicable governing The Home Depot terms of 
business or client engagement letter. The Home Depot disclaims all 
responsibility and liability for the accuracy and content of this attachment 
and for any damages or losses arising from any inaccuracies, errors, viruses, 
e.g., worms, trojan horses, etc., or other items of a destructive nature, which 
may be contained in this attachment and shall not be liable for direct, 
indirect, consequential or special damages in 

Re: Cassandra upgrade from 3.11.3 -> 3.11.6

[Jai Bheemsen Rao Dhanwada]

Thank you all for the suggestions.

I am not trying to scale up the cluster for capacity but for the upgrade
process instead of in place upgrade I am planning to add nodes with 3.11.6
and then decommission  the nodes with 3.11.3.

On Wednesday, June 24, 2020, Durity, Sean R 
wrote:

> Streaming operations (repair/bootstrap) with different file versions is
> usually a problem. Running a mixed version cluster is fine – for the time
> you are doing the upgrade. I would not stay on mixed versions for any
> longer than that. It takes more time, but I separate out the admin tasks so
> that I can reason what should happen. I would either scale up or upgrade
> (depending on which is more urgent), then do the other.
>
>
>
>
>
> Sean Durity
>
>
>
> *From:* manish khandelwal 
> *Sent:* Wednesday, June 24, 2020 5:52 AM
> *To:* user@cassandra.apache.org
> *Subject:* [EXTERNAL] Re: Cassandra upgrade from 3.11.3 -> 3.11.6
>
>
>
> Rightly said by Surbhi, it is not good to scale with mixed versions as
> debugging issues will be very difficult.
>
> Better to upgrade first and then scale.
>
>
>
> Regards
>
>
>
> On Wed, Jun 24, 2020 at 11:20 AM Surbhi Gupta 
> wrote:
>
> In case of any issue, it gets very difficult to debug when we have
> multiple versions.
>
>
>
> On Tue, 23 Jun 2020 at 22:23, Jürgen Albersdorfer 
> wrote:
>
> Hi, I would say „It depends“ - as it always does. I have had a 21 Node
> Cluster running in Production in one DC with versions ranging from 3.11.1
> to 3.11.6 without having had any single issue for over a year. I just
> upgraded all nodes to 3.11.6 for the sake of consistency.
>
> Von meinem iPhone gesendet
>
>
>
> Am 24.06.2020 um 02:56 schrieb Surbhi Gupta :
>
> 
>
>
>
> Hi ,
>
>
>
> We have recently upgraded from 3.11.0 to 3.11.5 . There is a sstable
> format change from 3.11.4 .
>
> We also had to expand the cluster and we also discussed about expansion
> first and than upgrade. But finally we upgraded and than expanded.
>
> As per our experience what I could tell you is, it is not advisable to add
> new nodes on higher version.
>
> There are many bugs which got fixed from 3.11.3 to 3.11.6.
>
>
>
> Thanks
>
> Surbhi
>
>
>
> On Tue, Jun 23, 2020 at 5:04 PM Jai Bheemsen Rao Dhanwada <
> jaibheem...@gmail.com> wrote:
>
> Hello,
>
>
>
> I am trying to upgrade from 3.11.3 to 3.11.6.
>
> Can I add new nodes with the 3.11.6  version to the cluster running with
> 3.11.3?
>
> Also, I see the SSTable format changed from mc-* to md-*, does this cause
> any issues?
>
>
>
>
> --
>
> The information in this Internet Email is confidential and may be legally
> privileged. It is intended solely for the addressee. Access to this Email
> by anyone else is unauthorized. If you are not the intended recipient, any
> disclosure, copying, distribution or any action taken or omitted to be
> taken in reliance on it, is prohibited and may be unlawful. When addressed
> to our clients any opinions or advice contained in this Email are subject
> to the terms and conditions expressed in any applicable governing The Home
> Depot terms of business or client engagement letter. The Home Depot
> disclaims all responsibility and liability for the accuracy and content of
> this attachment and for any damages or losses arising from any
> inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other
> items of a destructive nature, which may be contained in this attachment
> and shall not be liable for direct, indirect, consequential or special
> damages in connection with this e-mail message or its attachment.
>

RE: Cassandra upgrade from 3.11.3 -> 3.11.6

[Durity, Sean R]

Streaming operations (repair/bootstrap) with different file versions is usually 
a problem. Running a mixed version cluster is fine – for the time you are doing 
the upgrade. I would not stay on mixed versions for any longer than that. It 
takes more time, but I separate out the admin tasks so that I can reason what 
should happen. I would either scale up or upgrade (depending on which is more 
urgent), then do the other.


Sean Durity

From: manish khandelwal 
Sent: Wednesday, June 24, 2020 5:52 AM
To: user@cassandra.apache.org
Subject: [EXTERNAL] Re: Cassandra upgrade from 3.11.3 -> 3.11.6

Rightly said by Surbhi, it is not good to scale with mixed versions as 
debugging issues will be very difficult.
Better to upgrade first and then scale.

Regards

On Wed, Jun 24, 2020 at 11:20 AM Surbhi Gupta 
mailto:surbhi.gupt...@gmail.com>> wrote:
In case of any issue, it gets very difficult to debug when we have multiple 
versions.

On Tue, 23 Jun 2020 at 22:23, Jürgen Albersdorfer 
mailto:jalbersdor...@gmail.com>> wrote:
Hi, I would say „It depends“ - as it always does. I have had a 21 Node Cluster 
running in Production in one DC with versions ranging from 3.11.1 to 3.11.6 
without having had any single issue for over a year. I just upgraded all nodes 
to 3.11.6 for the sake of consistency.
Von meinem iPhone gesendet


Am 24.06.2020 um 02:56 schrieb Surbhi Gupta 
mailto:surbhi.gupt...@gmail.com>>:


Hi ,

We have recently upgraded from 3.11.0 to 3.11.5 . There is a sstable format 
change from 3.11.4 .
We also had to expand the cluster and we also discussed about expansion first 
and than upgrade. But finally we upgraded and than expanded.
As per our experience what I could tell you is, it is not advisable to add new 
nodes on higher version.
There are many bugs which got fixed from 3.11.3 to 3.11.6.

Thanks
Surbhi

On Tue, Jun 23, 2020 at 5:04 PM Jai Bheemsen Rao Dhanwada 
mailto:jaibheem...@gmail.com>> wrote:
Hello,

I am trying to upgrade from 3.11.3 to 3.11.6.
Can I add new nodes with the 3.11.6  version to the cluster running with 3.11.3?
Also, I see the SSTable format changed from mc-* to md-*, does this cause any 
issues?




The information in this Internet Email is confidential and may be legally 
privileged. It is intended solely for the addressee. Access to this Email by 
anyone else is unauthorized. If you are not the intended recipient, any 
disclosure, copying, distribution or any action taken or omitted to be taken in 
reliance on it, is prohibited and may be unlawful. When addressed to our 
clients any opinions or advice contained in this Email are subject to the terms 
and conditions expressed in any applicable governing The Home Depot terms of 
business or client engagement letter. The Home Depot disclaims all 
responsibility and liability for the accuracy and content of this attachment 
and for any damages or losses arising from any inaccuracies, errors, viruses, 
e.g., worms, trojan horses, etc., or other items of a destructive nature, which 
may be contained in this attachment and shall not be liable for direct, 
indirect, consequential or special damages in connection with this e-mail 
message or its attachment.

Re: Implication of having similar private IPs in two datacenters

[manish khandelwal]

The nodes within one datacenter will talk on private IPs and for
communication across data center public ips are used. Does that  answer
your question? or you are asking in terms of network layer.

As per this link
,
there is no mention of private IP to be unique.

In a network one can assign valid private IP. Private IPs can conflict if
we do not put any restriction on private IP.

Regards


On Wed, Jun 24, 2020 at 5:12 PM Erick Ramirez 
wrote:

> Putting Cassandra aside, I'm curious to know how you envision that would
> work from a network perspective. How would the connectivity between servers
> work?
>
>>

Empty counter != 0

[Juliusz Stasiewicz]

Let's consider a table with two columns of counter type:
cqlsh:ks> CREATE TABLE t(p int PRIMARY KEY, c1 COUNTER, c2 COUNTER);
cqlsh:ks> UPDATE t SET c1 = c1 + 1 WHERE p = 1;


We have one row now:
 p | c1 | c2---++--
 1 |  1 | null

My question is: should we treat the null counter (`c2` here) as zero?
E.g. this query returns an empty result set:
cqlsh:ks> SELECT * FROM t WHERE c2 = 0 ALLOW FILTERING;

 p | c1 | c2---++

(0 rows)

so NULL counters are not comparable to regular integers. Makes sense in
general, but counters are specific: one could argue that since c1 := c1 + 1
ended up as 1, its previous value must have been 0 (?). On the other hand,
a counter 'nullified' by DELETE should not appear as 0...

Is this a desired (and designed) behavior? Do you think it won't change in
the future and can be relied on?

Cheers,
JS

Re: Implication of having similar private IPs in two datacenters

[Erick Ramirez]

Putting Cassandra aside, I'm curious to know how you envision that would
work from a network perspective. How would the connectivity between servers
work?

>

Re: Cassandra container, Google Cloud and Kubernetes

[Erick Ramirez]

This isn't a direct answer to your questions but you might be interested in
the Kubernetes operator for Apache Cassandra [1] from DataStax. You can use
the cass-operator to deploy a C* 3.11.6 image to your Kubernetes cluster.
The docs are available here [2].

FWIW there are several other published operators from the likes of Orange
[3] and Instaclustr [4]. The authors have come together in the community to
contribute their work and "combine" them into an "official" operator for
Cassandra. (I'm sure someone will correct me if I've made any
misrepresentation). Cheers!

[1] https://github.com/datastax/cass-operator
[2] https://docs.datastax.com/en/cass-operator/doc/
[3] https://github.com/Orange-OpenSource/casskop
[4] https://github.com/instaclustr/cassandra-operator

>

Re: Cassandra upgrade from 3.11.3 -> 3.11.6

[Erick Ramirez]

>
> Can I add new nodes with the 3.11.6  version to the cluster running with
> 3.11.3?
>

Technically you can. You'll be able to add 3.11.6 nodes to a 3.11.3
cluster. In fact, the reverse works too in my tests but I personally
wouldn't want to do it in production.


> Also, I see the SSTable format changed from mc-* to md-*, does this cause
> any issues?
>

Operations like repairs and bootstrap still works on my limited testing.
For example, if a 3.11.3 node died then you can bootstrap a replacement.

I echo the others' sentiment here and I wouldn't do this in production.
CASSANDRA-14861 [1] and CASSANDRA-14096 [2] should give you the motivation
to want to upgrade the existing nodes first before expanding the cluster.
Cheers!

[1] CASSANDRA-14861
 Sstable
min/max metadata can cause data loss
[2] CASSANDRA-14096
 Repair
merkle tree size causes OOM

Re: Cassandra upgrade from 3.11.3 -> 3.11.6

[manish khandelwal]

Rightly said by Surbhi, it is not good to scale with mixed versions as
debugging issues will be very difficult.
Better to upgrade first and then scale.

Regards

On Wed, Jun 24, 2020 at 11:20 AM Surbhi Gupta 
wrote:

> In case of any issue, it gets very difficult to debug when we have
> multiple versions.
>
> On Tue, 23 Jun 2020 at 22:23, Jürgen Albersdorfer 
> wrote:
>
>> Hi, I would say „It depends“ - as it always does. I have had a 21 Node
>> Cluster running in Production in one DC with versions ranging from 3.11.1
>> to 3.11.6 without having had any single issue for over a year. I just
>> upgraded all nodes to 3.11.6 for the sake of consistency.
>>
>> Von meinem iPhone gesendet
>>
>> Am 24.06.2020 um 02:56 schrieb Surbhi Gupta :
>>
>> 
>>
>> Hi ,
>>
>> We have recently upgraded from 3.11.0 to 3.11.5 . There is a sstable
>> format change from 3.11.4 .
>> We also had to expand the cluster and we also discussed about expansion
>> first and than upgrade. But finally we upgraded and than expanded.
>> As per our experience what I could tell you is, it is not advisable to
>> add new nodes on higher version.
>> There are many bugs which got fixed from 3.11.3 to 3.11.6.
>>
>> Thanks
>> Surbhi
>>
>> On Tue, Jun 23, 2020 at 5:04 PM Jai Bheemsen Rao Dhanwada <
>> jaibheem...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I am trying to upgrade from 3.11.3 to 3.11.6.
>>> Can I add new nodes with the 3.11.6  version to the cluster running with
>>> 3.11.3?
>>> Also, I see the SSTable format changed from mc-* to md-*, does this
>>> cause any issues?
>>>
>>>

Implication of having similar private IPs in two datacenters

[manish khandelwal]

Are there any implication if I have similar set of private IPs in two data
centers. For example if I have A,B and C as private IPs in one data center
and I define A,B and C as my private IPs in other data center, does it
impact the cluster?

Regards

Cassandra container, Google Cloud and Kubernetes

[Manu Chadha]

Hi

I want to run Cassandra container in GCP and want to orchestrate the containers 
using Kubernetes.

I have a Cassandra image in my Docker Registry. Following the steps from the 
following tutorial, I have created a cluster and have Cassandra running on it. 
https://cloud.google.com/kubernetes-engine/docs/tutorials/hello-app#step_4_create_a_cluster

These are the steps I executed

  *   get cassandra image - docker pull manuchadha25/codingjedi:3.11.4
  *   check that the images exists locally- docker images. Also check that the 
image runs - docker run manuchadha25/cassandra:3.11.4
  *   run on GCP console - export PROJECT_ID=project-id of google project
  *   run on GCP console - gcloud auth configure-docker - maybe not required as 
I want to skip putting the image in container registry.
  *   gcloud config set project $PROJECT_ID
  *   gcloud config set compute/zone compute-zone --num-nodes 2
  *   gcloud container clusters create codingjedi-cassandra-cluster 
--num-nodes=2
  *   check cluster is up - gcloud compute instances list
  *   kubectl create deployment codingjedi-cassandra-app 
--image=docker.io/manuchadha25/cassandra:3.11.4
  *   kubectl scale deployment codingjedi-cassandra-app --replicas=3
  *   kubectl autoscale deployment codingjedi-cassandra-app --cpu-percent=80 
--min=3 --max=5
  *   check all is fine- kubectl get pods
  *   kubectl expose deployment codingjedi-cassandra-app 
--name=codingjedi-cassandra-app-service --type=LoadBalancer --port 9042 
--target-port 9042
  *   check service is running - kubectl get service
  *   copy external ip address and from laptop run cqlsh external-ip 9042. This 
should start cqlsh. I am able to connect with the cluster from my laptop using 
the external IP. – cqlsh external-ip 9042

My concern is that I have not provided any configuration anywhere which would 
make the different Cassandra nodes work together. So while I have created a 
Kubernetes cluster, I have not created a Cassandra cluster. Am I correct? I 
suppose I need to do more to make the nodes work as Cassandra cluster. How do I 
do that? I mean specify SEED_ADDRESS, LISTENING address, set an external data 
volume so that the data persists etc.?

Regards
Manu


Sent from Mail for Windows 10