Thank you for your research, Frédéric,
We looked and the conf files were up to date, in the form
[v1:(...),v2:(...)]
I manage to reproduce the "incident":
[aevoo-test - ceph-0]# ceph mon dump -f json|jq '.mons[].public_addrs'
dumped monmap epoch 2
{
"addrvec": [
{
"type": "v2",
Hi Albert, David,
I came across this: https://github.com/ceph/ceph/pull/47421
"OSDs have a config file that includes addresses for the mon daemons.
We already have in place logic to cause a reconfig of OSDs if the mon map
changes, but when we do we aren't actually regenerating the config
so it's
- Le 17 Juil 24, à 15:53, Albert Shih albert.s...@obspm.fr a écrit :
> Le 17/07/2024 à 09:40:59+0200, David C. a écrit
> Hi everyone.
>
>>
>> The curiosity of Albert's cluster is that (msgr) v1 and v2 are present on the
>> mons, as well as on the osds backend.
>>
>> But v2 is absent on th
Le 17/07/2024 à 09:40:59+0200, David C. a écrit
Hi everyone.
>
> The curiosity of Albert's cluster is that (msgr) v1 and v2 are present on the
> mons, as well as on the osds backend.
>
> But v2 is absent on the public OSD and MDS network
>
> The specific point is that the public network has be
Hi,
It would seem that the order of declaration of mons addresses (v2 then v1
and not the other way around) is important.
Albert restarted all services after this modification and everything is
back to normal
Le mer. 17 juil. 2024 à 09:40, David C. a écrit :
> Hi Frédéric,
>
> The curiosity o
Hi,
> On 17 Jul 2024, at 10:21, Frédéric Nass
> wrote:
>
> Seems like msgr v2 activation did only occur after all 3 MONs were redeployed
> and used RocksDB. Not sure why this happened though.
For a work with msgr v2 only, you need to specify ms_mode to prefer-crc, at
least. For example of fst
Hi Frédéric,
The curiosity of Albert's cluster is that (msgr) v1 and v2 are present on
the mons, as well as on the osds backend.
But v2 is absent on the public OSD and MDS network
The specific point is that the public network has been changed.
At first, I thought it was the order of declaration
Hi David,
Redeploying 2 out of 3 MONs a few weeks back (to have them using RocksDB to be
ready for Quincy) prevented some clients from connecting to the cluster and
mounting cephfs volumes.
Before the redeploy, these clients were using port 6789 (v1) explicitly as
connections wouldn't work wit
Albert,
The network is ok.
However, strangely, the osd and mds did not activate msgr v2 (msgr v2 was
activated on mon).
It is possible to bypass by adding the "ms_mode=legacy" option but you need
to find out why msgr v2 is not activated
Le mar. 16 juil. 2024 à 15:18, Albert Shih a écrit :
>
Hi Albert,
I think it's related to your network change.
Can you send me the return of "ceph report" ?
Le mar. 16 juil. 2024 à 14:34, Albert Shih a écrit :
> Hi everyone
>
> My cluster ceph run currently 18.2.2 and ceph -s say everything are OK
>
> root@cthulhu1:/var/lib/ceph/crash# ceph -s
>
Le 16/07/2024 à 12:38:08+, Eugen Block a écrit
Hi,
> Are all clients trying to connect to the same ceph cluster? Have you
Yes.
> compared their ceph.conf files? Maybe during the upgrade something went
Yes they are identical, same ceph.conf everywhere. My ceph.conf are deploy
by puppet.
Are all clients trying to connect to the same ceph cluster? Have you
compared their ceph.conf files? Maybe during the upgrade something
went wrong and an old file was applied or something?
Zitat von Albert Shih :
Hi everyone
My cluster ceph run currently 18.2.2 and ceph -s say everything a
12 matches
Mail list logo
