On 13 April 2015 at 16:00, Christian Balzer wrote:
> However the vast majority of people with production clusters will be
> running something "stable", mostly Firefly at this moment.
>
> > Sorry, 0.87 is giant.
> >
> > BTW, you could also set osd_scrub_sleep to your cluster. ceph would
> > sleep
Hi,
1. In short, the OSD need to heartbeat with up to #PG x (#Replica -1 ),
but actually will be much less since most of the peers are redundant.
For example, An OSD (say OSD 1) is holding 100 PGs, especially for some PGs,
say PG 1, OSD1 is the primary OSD of PG1, then OSD1 need to pee
Hi Francois,
Actually you are discussing two separate questions here:)
1. in the 5 mons(2 in dc1, 2 in dc2, 1 in wan), can the monitor form a quorum?
How to offload the mon in WAN?
Yes and No, in one case, you lose any of your DC completely, that's
fine, the left 3 monitors could
hi, Loic:
Do you think it is patch https://github.com/ceph/ceph/pull/3318
worth of backport to firely and giant?
2015-04-13 14:00 GMT+08:00 Christian Balzer :
>
> On Mon, 13 Apr 2015 13:42:39 +0800 池信泽 wrote:
>
> I knew the scheduler was in the pipeline, good to see it made it in.
>
> How
On Mon, 13 Apr 2015 13:42:39 +0800 池信泽 wrote:
I knew the scheduler was in the pipeline, good to see it made it in.
However the vast majority of people with production clusters will be
running something "stable", mostly Firefly at this moment.
> Sorry, 0.87 is giant.
>
> BTW, you could also set
Sorry, 0.87 is giant.
BTW, you could also set osd_scrub_sleep to your cluster. ceph would
sleep some time as you defined when it has scrub some objects.
But I am not sure whether is could works good to you.
Thanks.
2015-04-13 13:30 GMT+08:00 池信泽 :
> hi, you could restrict scrub to certain times
hi, you could restrict scrub to certain times of day based on
https://github.com/ceph/ceph/pull/3318.
You could set osd_scrub_begin_hour and osd_scrub_begin_hour which are
suitable for you. This feature is available since 0.93.
But it has not been backport to 0.87 (hammer).
2015-04-13 12:55 GMT+
On 13 April 2015 at 11:02, Christian Balzer wrote:
> Yeah, that's a request/question that comes up frequently.
> And so far there's no option in Ceph to do that (AFAIK), it would be
> really nice along with scheduling options (don't scrub during peak hours),
> which have also been talked about.
>
Hi, all,
I am new to study Ceph. Trying to understand how it works and designs.
One basic question for me is about how Ceph OSD perform failure detection. I
did some searching but cannot get satisfied answer, so try to ask here and hope
someone can kindly help me.
The document said, OSD will sen
Hi,
On a testing cluster, I have a radosgw on Firefly and the other
nodes, OSDs and monitors, are on Hammer. The nodes are installed
with puppet in personal VM, so I can reproduce the problem.
Generally, I use s3cmd to check the radosgw. While radosgw is on
Firefly, I can create bucket, no problem
Christian Balzer wrote:
> Simply put, a RAID1 of SSDs will require you to get twice as many SSDs as
> otherwise needed. And most people don't want to spend that money.
> In addition to that DC level SSDs tend to very reliable and your cluster
> will have to be able to withstand losses like this an
I have a pool used for RBD in a bit of an inconsistent state. Somehow, through
OpenStack, the data associated with a child volume was deleted. If I try to
unprotect the snapshot, librbd complains there is at least one child. If I try
to list out the children, librbd errors out on looking up the ima
On Sun, 12 Apr 2015 14:37:56 -0700 Gregory Farnum wrote:
> On Sun, Apr 12, 2015 at 1:58 PM, Francois Lafont
> wrote:
> > Somnath Roy wrote:
> >
> >> Interesting scenario :-).. IMHO, I don't think cluster will be in
> >> healthy state here if the connections between dc1 and dc2 is cut. The
> >> re
Hello,
On Sun, 12 Apr 2015 22:01:06 +0100 (BST) Andrei Mikhailovsky wrote:
> JC,
>
> Thanks
>
> I think the max scrub option that you refer to is a value per osd and
> not per cluster. So, the default is not to run more than 1 scrub per
> osd. So, if you have 100 osds by default it will not
On Sun, 12 Apr 2015 18:03:52 +0200 Francois Lafont wrote:
> Hi,
>
> Christian Balzer wrote:
>
> >> I'm not sure to well understand: the model that I indicated in the
> >> link above (page 2, model SSG-6027R-OSD040H in the table) already
> >> have hotswap bays in the back, for OS drives.
> >>
> >
Gregory Farnum wrote:
>> If: (more clear with a schema in the head ;))
>>
>> 1. mon.1 and mon.2 can talk together (in dc1) and can talk with mon.5
>> (via the VPN)
>>but can't talk with mon.3 and mon.4 (in dc2)
>> 2. mon.3 and mon.4 can talk together (in dc2) and can talk with mon
On Sun, Apr 12, 2015 at 1:58 PM, Francois Lafont wrote:
> Somnath Roy wrote:
>
>> Interesting scenario :-).. IMHO, I don't think cluster will be in healthy
>> state here if the connections between dc1 and dc2 is cut. The reason is the
>> following.
>>
>> 1. only osd.5 can talk to both data cente
JC,
Thanks
I think the max scrub option that you refer to is a value per osd and not per
cluster. So, the default is not to run more than 1 scrub per osd. So, if you
have 100 osds by default it will not run more than 100 scurb processes at the
same time. However, I want to limit the number o
Somnath Roy wrote:
> Interesting scenario :-).. IMHO, I don't think cluster will be in healthy
> state here if the connections between dc1 and dc2 is cut. The reason is the
> following.
>
> 1. only osd.5 can talk to both data center OSDs and other 2 mons will not
> be. So, they can't reach to
Hi Francois,
Interesting scenario :-).. IMHO, I don't think cluster will be in healthy state
here if the connections between dc1 and dc2 is cut. The reason is the following.
1. only osd.5 can talk to both data center OSDs and other 2 mons will not be.
So, they can't reach to an agreement (and f
Hi,
To summarize, my principal question is: in a ceph cluster, is it possible
to have, among the monitors, one monitor not necessarily very efficient
and with potentially network access latencies and still avoid a negative
effect on the cluster?
I explain the context of my question because it's i
Thank you Loic & Greg. We followed the troubleshooting directions and ran the
crushtool in test mode to verify that CRUSH was giving up too soon, and then
confirmed that changing the set_choose_tries value to 100 would resolve the
issue (it did).
We then implemented the change in the cluster, wh
Hi andrei
There is one parameter, osd_max_scrub I think, that controls the number of
scrubs per OSD. But the default is 1 if I'm correct.
Can you check on one of your OSDs with the admin socket?
Then it remains the option of scheduling the deep scrubs via a cron job after
setting nodeep-scrub
Chris Kitzmiller wrote:
> Just as a single data point I can speak to my own nodes. I'm using SM 847A
> [1] chassis. They're 4U, 36 x 3.5" hot swap bays with 2 internal 2.5" bays.
> So:
>
> 30 x 7200 RPM SATA
> 6 x SSD Journals
> 2 x SSD OS / Mon
> 2 x E5-2620 2.0GHz
>
>
Hi,
Christian Balzer wrote:
>> I'm not sure to well understand: the model that I indicated in the link
>> above (page 2, model SSG-6027R-OSD040H in the table) already have hotswap
>> bays in the back, for OS drives.
>>
> Yes, but that model is pre-configured:
> 2x 2.5" 400GB SSDs, 10x 3.5" 4TB S
JC,
the restart of the osd servers seems to have stabilised the cluster. It has
been a few hours since the restart and I haven't not seen a single osd
disconnect.
Is there a way to limit the total number of scrub and/or deep-scrub processes
running at the same time? For instance, I do not wa
You're not missing anything. The script was only needed when we used the
process manager of the fastcgi module, but it has been very long since we
stopped using it.
Yehuda
- Original Message -
> From: "Greg Meier"
> To: ceph-users@lists.ceph.com
> Sent: Saturday, April 11, 2015 10:54:2
JC,
I've implemented the following changes to the ceph.conf and restarted mons and
osds.
osd_scrub_chunk_min = 1
osd_scrub_chunk_max =5
Things have become considerably worse after the changes. Shortly after doing
that, majority of osd processes started taking up over 100% cpu and the clust
28 matches
Mail list logo
