Hi community.
I' am running ceph cluster with 10 node and 180 osds, and i create an pool
erasure code 4+2 with 256 PGs, but when create an pool PG too slow, and pg
status stuck peering
EALTH_WARN Reduced data availability: 5 pgs inactive, 5 pgs peering
[WRN] PG_AVAILABILITY: Reduced data availability: 5 pgs inactive, 5 pgs
peering
pg 59.6b is stuck peering for 4m, current state creating+peering, last
acting [17,87,92,117,71,149]
pg 59.78 is stuck peering for 4m, current state creating+peering, last
acting [94,16,137,98,41,79]
pg 59.86 is stuck peering for 4m, current state creating+peering, last
acting [37,107,24,138,144,25]
and this is a pg query
"recovery_state": [
{
"name": "Started/Primary/Peering/GetInfo",
"enter_time": "2024-01-04T11:02:09.208218+0000",
"requested_info_from": [
{
"osd": "101(4)"
}
]
},
{
"name": "Started/Primary/Peering",
"enter_time": "2024-01-04T11:02:09.208209+0000",
"past_intervals": [
{
"first": "0",
"last": "0",
"all_participants": [],
"intervals": []
}
],
"probing_osds": [
"0(3)",
"36(5)",
"74(2)",
"100(0)",
"101(4)",
"150(1)"
],
"down_osds_we_would_probe": [],
"peering_blocked_by": []
},
{
"name": "Started",
"enter_time": "2024-01-04T11:02:09.208161+0000"
}
],
"agent_state": {}
Why is the pg peering state so slow, it's affected by the network?
My network lacp with two of 10Gbps NIC
--
----------------------------------------------------------------------------
*Tran Thanh Phong*
Email: tranphong079(a)gmail.com
Skype: tranphong079
I’d like to upgrade from 16.2.11 to the latest version. Is it possible to do this in one jump or do I need to go from 16.2.11 -> 16.2.14 -> 17.1.0 -> 17.2.7 -> 18.1.0 -> 18.2.1? I’m using cephadm.
Thanks
-jeremy
Hi All,
we just upgraded to Reef, everything looks great, except the new Dashboard. The Recovery Throughput graph is empty, the recovery is ongoing for 18 hours and still no data. I tried to move the prometheus service to other node and redeployed couple of times, but still no data.
Kind Regards
Zoltan
Hello!
I want to increment the interval between deep scrub in all osd.
I tryed this but not configured:
ceph config set osd.* osd_deep_scrub_interval 1209600
I have 50 osd.. should config every osd?
thanks for the support!
Dear all,
Could you please share recent experiences with support for cephfs access
from MacOS clients ?
I couldn't find any threads on this matter on the list since 2021
(Daniel Persson), where he stated that :
> Mac Mini Intel Catalina - Connected and working fine.
> Mac Mini M1 BigSur - Can't compile brew cask, no popups for extra
> permissions in the GUI.
Thanks a lot!
Cheers,
Fabien
Hello,
We've been using Ceph for managing our storage infrastructure, and we recently upgraded to the latest version (Ceph v18.2.1 "reef"). However, We've noticed that the "refresh interval" option seems to be missing in the dashboard, and we are facing challenges with monitoring our cluster in real-time.
In the earlier version of the Ceph dashboard, there was a useful "refresh interval" option that allowed us to customize the update frequency of the dashboard. This was particularly handy for monitoring changes and responding promptly. However, after the upgrade to Ceph v18.2.1 "reef", We can't seem to find this option anywhere in the dashboard.
Additionally, we observed an automatic refresh occurring at every 25 seconds. Seeking guidance locating and tuning the refresh interval settings in the latest version of Ceph to potentially reduce this interval.
We've explored the dashboard settings thoroughly and reviewed the release notes for Ceph v18.2.1 "reef", but we couldn't find any mention of the removal of the "refresh interval" option.
Any guidance or insights would be greatly appreciated!
Thanks,
Mohammad Saif
Ceph Enthusiast
>>
>> You can do that for a PoC, but that's a bad idea for any production workload. You'd want at least three nodes with OSDs to use the default RF=3 replication. You can do RF=2, but at the peril of your mortal data.
>
> I'm not sure I agree - I think size=2, min_size=2 is no worse than
> RAID1 for data security.
size=2, min_size=2 *is* RAID1. Except that you become unavailable if a single drive is unavailable.
>> That isn't even the main risk as I understand it. Of course a double
> failure is going to be a problem with size=2, or traditional RAID1,
> and I think anybody choosing this configuration accepts this risk.
We see people often enough who don’t know that. I’ve seen double failures. ymmv.
> As I understand it, the reason min_size=1 is a trap has nothing to do
> with double failures per se.
It’s one of the concerns.
>
> The issue is that Ceph OSDs are somewhat prone to flapping during
> recovery (OOM, etc). So even if the disk is fine, an OSD can go down
> for a short time. If you have size=2, min=1 configured, then when
> this happens the PG will become degraded and will continue operating
> on the other OSD, and the flapping OSD becomes stale. Then when it
> comes back up it recovers. The problem is that if the other OSD has a
> permanent failure (disk crash/etc) while the first OSD is flapping,
> now you have no good OSDs, because when the flapping OSD comes back up
> it is stale, and its PGs have no peer.
Indeed, arguably that’s an overlapping failure. I’ve seen this too, and have a pg query to demonstrate it.
> I suspect there are ways to re-activate it, though this will result in potential data
> inconsistency since writes were allowed to the cluster and will then
> get rolled back.
Yep.
> With only two OSDs I'm guessing that would be the
> main impact (well, depending on journaling behavior/etc), but if you
> have more OSDs than that then you could have situations where one file
> is getting rolled back, and some other file isn't, and so on.
But you’d have a voting majority.
>
> With min_size=2 you're fairly safe from flapping because there will
> always be two replicas that have the most recent version of every PG,
> and so you can still tolerate a permanent failure of one of them.
Exactly.
>
> size=2, min=2 doesn't suffer this failure mode, because anytime there
> is flapping the PG goes inactive and no writes can be made, so when
> the other OSD comes back up there is nothing to recover. Of course
> this results in IO blocks and downtime, which is obviously
> undesirable, but it is likely a more recoverable state than
> inconsistent writes.
Agreed, the difference between availability and durability. Depends what’s important to you.
>
> Apologies if I've gotten any of that wrong, but my understanding is
> that it is these sorts of failure modes that cause min_size=1 to be a
> trap. This isn't the sort of thing that typically happens in a RAID1
> config, or at least that admins don't think about.
It’s both.
Happy 2024!
Today's CLT meeting covered the following:
1. 2024 brings a focus on performance of Crimson (some information here: https://docs.ceph.com/en/reef/dev/crimson/crimson/ )
1. Status is available here: https://github.com/ceph/ceph.io/pull/635
2. There will be a new Crimson performance weekly meeting that will be lead by Matan Breizman
1. This does not replace the existing performance weekly, and is focused on Crimson
2. An email will follow with more details about this meeting
2. Ceph Quarterly will be published on/around the 14th of January, 2024.
1. See https://ceph.io/en/community/cq/ for previous issues of CQ
3. A development freeze on Squid is tentatively scheduled for January 31, 2024
4. Upcoming releases
1. 16.2.15 is next (the last Pacific release)
1. Anticipated by the end of January
2. 17.2.8 will follow (Quincy)
3. 18.2.2 will follow this (Reef)
Hello and a happy new year!
I'm wondering if there are some structural changes or something
regarding the release page [1]. It still doesn't contain version
18.2.1 (Reef) and the latest two Quincy releases (17.2.6, 17.2.7) are
missing as well. And for Pacific it's even worse, the latest entry is
for 16.2.11 although we're close to 16.2.5 being released. I wanted to
check the changelog for 18.2.1 which can be found in the news blog [2].
I'd understand if the changelogs would be published only in one place
(the blog?) but then it should be at least referenced in the docs.
Thanks,
Eugen
[1] https://docs.ceph.com/en/reef/releases/
[2] https://ceph.io/en/news/blog/2023/v18-2-1-reef-released/