cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colin <colpcl...@gmail.com>
Subject Re: What's to think of when increasing disk size on Cassandra nodes?
Date Thu, 09 Apr 2015 03:29:50 GMT
Yikes, 18tb/node is a very bad idea.

I dont like to go over 2-3 personally and you have to be careful with JBOD.  See one of Ellis's
latest posts on this and suggested use of LVM.  It is a reversal on previous position re JBOD.

--
Colin 
+1 612 859 6129
Skype colin.p.clark

> On Apr 8, 2015, at 3:11 PM, Jack Krupansky <jack.krupansky@gmail.com> wrote:
> 
> I can certainly sympathize if you have IT staff/management who will willingly spring
for some disk drives, but not for full machines, even if they are relatively commodity boxes.
Seems penny-wise and pound-foolish to me, but management has their own priorities, plus there
is the pre-existing Oracle mindset of dense/fat nodes as a preference.
> 
> -- Jack Krupansky
> 
>> On Wed, Apr 8, 2015 at 2:00 PM, Nate McCall <nate@thelastpickle.com> wrote:
>> First off, I agree that the preferred path is adding nodes, but it is possible. 
>> 
>> > Can C* handle up to 18 TB data size per node with this amount of RAM?
>> 
>> Depends on how deep in the weeds you want to get tuning and testing. See below. 
>> 
>> >
>> > Is it feasible to increase the disk size by mounting a new (larger) disk, copy
all SS tables to it, and then mount it on the same mount point as the original (smaller) disk
(to replace it)? 
>> 
>> Yes (with C* off of course). 
>> 
>> As for tuning, you will need to look at, experiment with, and get a good understanding
of:
>> - index_interval (turn this up now anyway if have not already ~ start at 512 and
go up from there)
>> - bloom filter space usage via bloom_filter_fp_chance 
>> - compression metadata storage via chunk_length_kb 
>> - repair time and how compaction_throughput_in_mb_per_sec and stream_throughput_outbound_megabits_per_sec
will effect such
>> 
>> The first three will have a direct negative impact on read performance.
>> 
>> You will definitely want to use JBOD so you don't have to repair everything if you
loose a single disk, but you will still be degraded for *a very long time* when you loose
a disk.  
>> 
>> This is hard and takes experimentation and research (I can't emphasize this part
enough), but i've seen it work. That said, the engineering time spent is probably more than
buying and deploying additional hardware in the first place. YMMV. 
>> 
>> 
>> --
>> -----------------
>> Nate McCall
>> Austin, TX
>> @zznate
>> 
>> Co-Founder & Sr. Technical Consultant
>> Apache Cassandra Consulting
>> http://www.thelastpickle.com
> 

Mime
View raw message