Re: Openstack and Cassandra

2017-01-01 Thread Shalom Sagges
Thanks for the info Romain,

Can you tell me please what are the implications of not using CPU Pinning?




Shalom Sagges
DBA
T: +972-74-700-4035
 
 We Create Meaningful Connections



On Wed, Dec 28, 2016 at 7:01 PM, Romain Hardouin 
wrote:

> Kilo is a bit old but the good news is that CPU pinning is available which
> IMHO is a must to run C* on Production.
> Of course your bottleneck will be shared HDDs.
>
> Best,
>
> Romain
>
>
> Le Mardi 27 décembre 2016 10h21, Shalom Sagges  a
> écrit :
>
>
> Hi Romain,
>
> Thanks for the input!
>
> We currently use the Kilo release of Openstack. Are you aware of any known
> bugs/issues with this release?
> We definitely defined anti-affinity rules regarding spreading C* on
> different hosts. (I surely don't want to be woken up at night due to a
> failed host ;-) )
>
> Regarding Trove, I doubt we'll use it in Production any time soon.
>
> Thanks again!
>
>
>
>
>
> Shalom Sagges
> DBA
> T: +972-74-700-4035 <+972%2074-700-4035>
>  
>  We Create Meaningful Connections
> 
>
>
> On Mon, Dec 26, 2016 at 7:37 PM, Romain Hardouin 
> wrote:
>
> Hi Shalom,
>
> I assume you'll use KVM virtualization so pay attention to your stack at
> every level:
> - Nova e.g. CPU pinning, NUMA awareness if relevant, etc. Have a look to
> extra specs.
> - libvirt
> - KVM
> - QEMU
>
> You can also be interested by resources quota on other OpenStack VMs that
> will be colocated with C* VMs.
> Don't forget to define anti-affinity rules in order to spread out your C*
> VMs on different hosts.
> Finally, watch out versions of libvirt/KVM/QEMU. Some optimizations/bugs
> are good to know.
>
> Out of curiosity, which OpenStack release are you using?
> You can be interested by Trove but C* support is for testing only.
>
> Best,
>
> Romain
>
>
>
>
>
>
> This message may contain confidential and/or privileged information.
> If you are not the addressee or authorized to receive this on behalf of
> the addressee you must not use, copy, disclose or take action based on this
> message or any information herein.
> If you have received this message in error, please advise the sender
> immediately by reply email and delete this message. Thank you.
>
>
>

-- 
This message may contain confidential and/or privileged information. 
If you are not the addressee or authorized to receive this on behalf of the 
addressee you must not use, copy, disclose or take action based on this 
message or any information herein. 
If you have received this message in error, please advise the sender 
immediately by reply email and delete this message. Thank you.


Re: Openstack and Cassandra

2016-12-28 Thread Romain Hardouin
Kilo is a bit old but the good news is that CPU pinning is available which IMHO 
is a must to run C* on Production.Of course your bottleneck will be shared HDDs.
Best,
Romain 

Le Mardi 27 décembre 2016 10h21, Shalom Sagges  a 
écrit :
 

 Hi Romain, 
Thanks for the input!
We currently use the Kilo release of Openstack. Are you aware of any known 
bugs/issues with this release?We definitely defined anti-affinity rules 
regarding spreading C* on different hosts. (I surely don't want to be woken up 
at night due to a failed host ;-) )
Regarding Trove, I doubt we'll use it in Production any time soon.
Thanks again!



 
|  |
| Shalom Sagges |
| DBA |
| T: +972-74-700-4035 |
| 
| 
|  |  |  |

 | We Create Meaningful Connections |

 |
|  |

 
On Mon, Dec 26, 2016 at 7:37 PM, Romain Hardouin  wrote:

Hi Shalom,
I assume you'll use KVM virtualization so pay attention to your stack at every 
level:- Nova e.g. CPU pinning, NUMA awareness if relevant, etc. Have a look to 
extra specs.- libvirt - KVM- QEMU
You can also be interested by resources quota on other OpenStack VMs that will 
be colocated with C* VMs.Don't forget to define anti-affinity rules in order to 
spread out your C* VMs on different hosts.Finally, watch out versions of 
libvirt/KVM/QEMU. Some optimizations/bugs are good to know.
Out of curiosity, which OpenStack release are you using?You can be interested 
by Trove but C* support is for testing only.
Best,
Romain



   


This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this on behalf of the addressee you 
must not use, copy, disclose or take action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply email and delete this message. Thank you.

   

Re: Openstack and Cassandra

2016-12-27 Thread Shalom Sagges
Hi Romain,

Thanks for the input!

We currently use the Kilo release of Openstack. Are you aware of any known
bugs/issues with this release?
We definitely defined anti-affinity rules regarding spreading C* on
different hosts. (I surely don't want to be woken up at night due to a
failed host ;-) )

Regarding Trove, I doubt we'll use it in Production any time soon.

Thanks again!





Shalom Sagges
DBA
T: +972-74-700-4035
 
 We Create Meaningful Connections



On Mon, Dec 26, 2016 at 7:37 PM, Romain Hardouin 
wrote:

> Hi Shalom,
>
> I assume you'll use KVM virtualization so pay attention to your stack at
> every level:
> - Nova e.g. CPU pinning, NUMA awareness if relevant, etc. Have a look to
> extra specs.
> - libvirt
> - KVM
> - QEMU
>
> You can also be interested by resources quota on other OpenStack VMs that
> will be colocated with C* VMs.
> Don't forget to define anti-affinity rules in order to spread out your C*
> VMs on different hosts.
> Finally, watch out versions of libvirt/KVM/QEMU. Some optimizations/bugs
> are good to know.
>
> Out of curiosity, which OpenStack release are you using?
> You can be interested by Trove but C* support is for testing only.
>
> Best,
>
> Romain
>
>
>
>
>

-- 
This message may contain confidential and/or privileged information. 
If you are not the addressee or authorized to receive this on behalf of the 
addressee you must not use, copy, disclose or take action based on this 
message or any information herein. 
If you have received this message in error, please advise the sender 
immediately by reply email and delete this message. Thank you.


Re: Openstack and Cassandra

2016-12-26 Thread Romain Hardouin
Hi Shalom,
I assume you'll use KVM virtualization so pay attention to your stack at every 
level:- Nova e.g. CPU pinning, NUMA awareness if relevant, etc. Have a look to 
extra specs.- libvirt - KVM- QEMU
You can also be interested by resources quota on other OpenStack VMs that will 
be colocated with C* VMs.Don't forget to define anti-affinity rules in order to 
spread out your C* VMs on different hosts.Finally, watch out versions of 
libvirt/KVM/QEMU. Some optimizations/bugs are good to know.
Out of curiosity, which OpenStack release are you using?You can be interested 
by Trove but C* support is for testing only.
Best,
Romain



   

Re: Openstack and Cassandra

2016-12-22 Thread Shalom Sagges
Thanks for the info Aaron!

I will test it in hope there will be no issues. If no issues will occur,
this could actually be a good idea and would save a lot of resources.

Have a great day!


Shalom Sagges
DBA
T: +972-74-700-4035
<http://www.linkedin.com/company/164748> <http://twitter.com/liveperson>
<http://www.facebook.com/LivePersonInc> We Create Meaningful Connections
<https://liveperson.docsend.com/view/8iiswfp>


On Thu, Dec 22, 2016 at 6:27 PM, Aaron Ploetz <aaronplo...@gmail.com> wrote:

> Shalom,
>
> We (Target) have been challenged by our management team to leverage
> OpenStack whenever possible, and that includes Cassandra.  I was against it
> at first, but we have done some stress testing with it and had application
> teams try it out.  So far, there haven't been any issues.
>
> A good use case for Cassandra on OpenStack, is to support an
> internal-facing application that needs to scale for disk footprint, or to
> spin-up a quick dev environment.  When building clusters to support those
> solutions, we haven't had any problems due to simply deploying on
> OpenStack.  Our largest Cassandra cluster on OpenStack is currently around
> 30 nodes.  OpenStack is a good solution for that particular use case as we
> can easily add/remove nodes to accommodate the dynamic disk usage
> requirements.
>
> However, when query latency is a primary concern, I do still recommend
> that we use one of our external cloud providers.
>
> Hope that helps,
>
> Aaron
>
> On Thu, Dec 22, 2016 at 9:51 AM, Shalom Sagges <shal...@liveperson.com>
> wrote:
>
>> Thanks Vladimir!
>>
>> I guess I'll just have to deploy and continue from there.
>>
>>
>>
>>
>> Shalom Sagges
>> DBA
>> T: +972-74-700-4035 <+972%2074-700-4035>
>> <http://www.linkedin.com/company/164748> <http://twitter.com/liveperson>
>> <http://www.facebook.com/LivePersonInc> We Create Meaningful Connections
>> <https://liveperson.docsend.com/view/8iiswfp>
>>
>>
>> On Thu, Dec 22, 2016 at 5:20 PM, Vladimir Yudovin <vla...@winguzone.com>
>> wrote:
>>
>>> Hi Shalom,
>>>
>>> I don't see any reason why it wouldn't work,  but obviously, any
>>> resource sharing affects performance. You can expect less degradation with
>>> SSD disks, I guess.
>>>
>>>
>>> Best regards, Vladimir Yudovin,
>>> *Winguzone <https://winguzone.com?from=list> - Cloud Cassandra Hosting*
>>>
>>>
>>>  On Wed, 21 Dec 2016 13:31:22 -0500 *Shalom Sagges
>>> <shal...@liveperson.com <shal...@liveperson.com>>* wrote 
>>>
>>> Hi Everyone,
>>>
>>> I am looking into the option of deploying a Cassandra cluster on
>>> Openstack nodes instead of physical nodes due to resource management
>>> considerations.
>>>
>>> Does anyone has any insights regarding this?
>>> Can this combination work properly?
>>> Since the disks (HDDs) are part of one physical machine that divide
>>> their capacity to various instances (not only Cassandra), will this affect
>>> performance, especially when the commitlog directory will probably reside
>>> with the data directory?
>>>
>>> I'm at a loss here and don't have any answers for that matter.
>>>
>>> Can anyone assist please?
>>>
>>> Thanks!
>>>
>>>
>>>
>>>
>>> Shalom Sagges
>>> DBA
>>> T: +972-74-700-4035 <+972%2074-700-4035>
>>> <http://www.linkedin.com/company/164748>
>>> <http://twitter.com/liveperson>
>>> <http://www.facebook.com/LivePersonInc>
>>> We Create Meaningful Connections
>>>
>>>
>>>
>>>
>>> This message may contain confidential and/or privileged information.
>>> If you are not the addressee or authorized to receive this on behalf of
>>> the addressee you must not use, copy, disclose or take action based on this
>>> message or any information herein.
>>> If you have received this message in error, please advise the sender
>>> immediately by reply email and delete this message. Thank you.
>>>
>>>
>>>
>>
>> This message may contain confidential and/or privileged information.
>> If you are not the addressee or authorized to receive this on behalf of
>> the addressee you must not use, copy, disclose or take action based on this
>> message or any information herein.
>> If you have received this message in error, please advise the sender
>> immediately by reply email and delete this message. Thank you.
>>
>
>

-- 
This message may contain confidential and/or privileged information. 
If you are not the addressee or authorized to receive this on behalf of the 
addressee you must not use, copy, disclose or take action based on this 
message or any information herein. 
If you have received this message in error, please advise the sender 
immediately by reply email and delete this message. Thank you.


Re: Openstack and Cassandra

2016-12-22 Thread Aaron Ploetz
Shalom,

We (Target) have been challenged by our management team to leverage
OpenStack whenever possible, and that includes Cassandra.  I was against it
at first, but we have done some stress testing with it and had application
teams try it out.  So far, there haven't been any issues.

A good use case for Cassandra on OpenStack, is to support an
internal-facing application that needs to scale for disk footprint, or to
spin-up a quick dev environment.  When building clusters to support those
solutions, we haven't had any problems due to simply deploying on
OpenStack.  Our largest Cassandra cluster on OpenStack is currently around
30 nodes.  OpenStack is a good solution for that particular use case as we
can easily add/remove nodes to accommodate the dynamic disk usage
requirements.

However, when query latency is a primary concern, I do still recommend that
we use one of our external cloud providers.

Hope that helps,

Aaron

On Thu, Dec 22, 2016 at 9:51 AM, Shalom Sagges <shal...@liveperson.com>
wrote:

> Thanks Vladimir!
>
> I guess I'll just have to deploy and continue from there.
>
>
>
>
> Shalom Sagges
> DBA
> T: +972-74-700-4035 <+972%2074-700-4035>
> <http://www.linkedin.com/company/164748> <http://twitter.com/liveperson>
> <http://www.facebook.com/LivePersonInc> We Create Meaningful Connections
> <https://liveperson.docsend.com/view/8iiswfp>
>
>
> On Thu, Dec 22, 2016 at 5:20 PM, Vladimir Yudovin <vla...@winguzone.com>
> wrote:
>
>> Hi Shalom,
>>
>> I don't see any reason why it wouldn't work,  but obviously, any resource
>> sharing affects performance. You can expect less degradation with SSD
>> disks, I guess.
>>
>>
>> Best regards, Vladimir Yudovin,
>> *Winguzone <https://winguzone.com?from=list> - Cloud Cassandra Hosting*
>>
>>
>>  On Wed, 21 Dec 2016 13:31:22 -0500 *Shalom Sagges
>> <shal...@liveperson.com <shal...@liveperson.com>>* wrote 
>>
>> Hi Everyone,
>>
>> I am looking into the option of deploying a Cassandra cluster on
>> Openstack nodes instead of physical nodes due to resource management
>> considerations.
>>
>> Does anyone has any insights regarding this?
>> Can this combination work properly?
>> Since the disks (HDDs) are part of one physical machine that divide their
>> capacity to various instances (not only Cassandra), will this affect
>> performance, especially when the commitlog directory will probably reside
>> with the data directory?
>>
>> I'm at a loss here and don't have any answers for that matter.
>>
>> Can anyone assist please?
>>
>> Thanks!
>>
>>
>>
>>
>> Shalom Sagges
>> DBA
>> T: +972-74-700-4035 <+972%2074-700-4035>
>> <http://www.linkedin.com/company/164748>
>> <http://twitter.com/liveperson>
>> <http://www.facebook.com/LivePersonInc>
>> We Create Meaningful Connections
>>
>>
>>
>>
>> This message may contain confidential and/or privileged information.
>> If you are not the addressee or authorized to receive this on behalf of
>> the addressee you must not use, copy, disclose or take action based on this
>> message or any information herein.
>> If you have received this message in error, please advise the sender
>> immediately by reply email and delete this message. Thank you.
>>
>>
>>
>
> This message may contain confidential and/or privileged information.
> If you are not the addressee or authorized to receive this on behalf of
> the addressee you must not use, copy, disclose or take action based on this
> message or any information herein.
> If you have received this message in error, please advise the sender
> immediately by reply email and delete this message. Thank you.
>


Re: Openstack and Cassandra

2016-12-22 Thread Shalom Sagges
Thanks Vladimir!

I guess I'll just have to deploy and continue from there.




Shalom Sagges
DBA
T: +972-74-700-4035
<http://www.linkedin.com/company/164748> <http://twitter.com/liveperson>
<http://www.facebook.com/LivePersonInc> We Create Meaningful Connections
<https://liveperson.docsend.com/view/8iiswfp>


On Thu, Dec 22, 2016 at 5:20 PM, Vladimir Yudovin <vla...@winguzone.com>
wrote:

> Hi Shalom,
>
> I don't see any reason why it wouldn't work,  but obviously, any resource
> sharing affects performance. You can expect less degradation with SSD
> disks, I guess.
>
>
> Best regards, Vladimir Yudovin,
> *Winguzone <https://winguzone.com?from=list> - Cloud Cassandra Hosting*
>
>
>  On Wed, 21 Dec 2016 13:31:22 -0500 *Shalom Sagges
> <shal...@liveperson.com <shal...@liveperson.com>>* wrote 
>
> Hi Everyone,
>
> I am looking into the option of deploying a Cassandra cluster on Openstack
> nodes instead of physical nodes due to resource management considerations.
>
> Does anyone has any insights regarding this?
> Can this combination work properly?
> Since the disks (HDDs) are part of one physical machine that divide their
> capacity to various instances (not only Cassandra), will this affect
> performance, especially when the commitlog directory will probably reside
> with the data directory?
>
> I'm at a loss here and don't have any answers for that matter.
>
> Can anyone assist please?
>
> Thanks!
>
>
>
>
> Shalom Sagges
> DBA
> T: +972-74-700-4035 <+972%2074-700-4035>
> <http://www.linkedin.com/company/164748>
> <http://twitter.com/liveperson>
> <http://www.facebook.com/LivePersonInc>
> We Create Meaningful Connections
>
>
>
>
> This message may contain confidential and/or privileged information.
> If you are not the addressee or authorized to receive this on behalf of
> the addressee you must not use, copy, disclose or take action based on this
> message or any information herein.
> If you have received this message in error, please advise the sender
> immediately by reply email and delete this message. Thank you.
>
>
>

-- 
This message may contain confidential and/or privileged information. 
If you are not the addressee or authorized to receive this on behalf of the 
addressee you must not use, copy, disclose or take action based on this 
message or any information herein. 
If you have received this message in error, please advise the sender 
immediately by reply email and delete this message. Thank you.


Re: Openstack and Cassandra

2016-12-22 Thread Vladimir Yudovin
Hi Shalom,



I don't see any reason why it wouldn't work,  but obviously, any resource 
sharing affects performance. You can expect less degradation with SSD disks, I 
guess.





Best regards, Vladimir Yudovin, 

Winguzone - Cloud Cassandra Hosting






 On Wed, 21 Dec 2016 13:31:22 -0500 Shalom Sagges 
shal...@liveperson.com wrote 




Hi Everyone, 



I am looking into the option of deploying a Cassandra cluster on Openstack 
nodes instead of physical nodes due to resource management considerations. 



Does anyone has any insights regarding this?

Can this combination work properly? 

Since the disks (HDDs) are part of one physical machine that divide their 
capacity to various instances (not only Cassandra), will this affect 
performance, especially when the commitlog directory will probably reside with 
the data directory?



I'm at a loss here and don't have any answers for that matter. 



Can anyone assist please? 



Thanks!





 


 
Shalom Sagges
 
DBA
 
T: +972-74-700-4035
 

 
 
 
 We Create Meaningful Connections
 
 

 

 









This message may contain confidential and/or privileged information. 

If you are not the addressee or authorized to receive this on behalf of the 
addressee you must not use, copy, disclose or take action based on this message 
or any information herein. 

If you have received this message in error, please advise the sender 
immediately by reply email and delete this message. Thank you.








Openstack and Cassandra

2016-12-21 Thread Shalom Sagges
Hi Everyone,

I am looking into the option of deploying a Cassandra cluster on Openstack
nodes instead of physical nodes due to resource management considerations.

Does anyone has any insights regarding this?
Can this combination work properly?
Since the disks (HDDs) are part of one physical machine that divide their
capacity to various instances (not only Cassandra), will this affect
performance, especially when the commitlog directory will probably reside
with the data directory?

I'm at a loss here and don't have any answers for that matter.

Can anyone assist please?

Thanks!



Shalom Sagges
DBA
T: +972-74-700-4035
<http://www.linkedin.com/company/164748> <http://twitter.com/liveperson>
<http://www.facebook.com/LivePersonInc> We Create Meaningful Connections

-- 
This message may contain confidential and/or privileged information. 
If you are not the addressee or authorized to receive this on behalf of the 
addressee you must not use, copy, disclose or take action based on this 
message or any information herein. 
If you have received this message in error, please advise the sender 
immediately by reply email and delete this message. Thank you.