[ceph-users] Re: Running Mons on msgrv2/3300 only.
Out of curiosity, how DNS lookup [1] works with v2 only mons? Since we can’t specify whether the port is v1 or v2 in SRV records. Or it just works if I specify 3300 port in SRV records? [1]: https://docs.ceph.com/en/latest/rados/configuration/mon-lookup-dns/ 在 2020年12月9日，18:10，Wido den Hollander 写道： On 08/12/2020 20:17, Wesley Dillingham wrote: We rebuilt all of our mons in one cluster such that they bind only to port 3300 with msgrv2. Previous to this we were binding to both 6789 and 3300. All of our server and client components are sufficiently new (14.2.x) and we haven’t observed any disruption but I am inquiring if this may be problematic for any unforeseen reason. We don’t intend to have any older clients connecting. https://docs.ceph.com/en/latest/rados/configuration/msgr2/ doesn’t mention much about running with only v2 so I just want to make sure we aren’t setting ourselves up for trouble. Thanks. No, not really. I have a couple of those servers as well where v1 was disabled completely. Wido -- Respectfully, Wes Dillingham Site Reliability Engineer IV Storage Engineering / Ceph wdillingham(at)godaddy.com ___ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-le...@ceph.io ___ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-le...@ceph.io ___ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-le...@ceph.io
[ceph-users] Re: CentOS
Hi Folks, We have CentOS Stream 8 installed on some of our community performance test gear. A couple of months ago there was a change introduced to the repository names that broke install-deps.sh, but that has now been fixed. Otherwise, Ceph master builds fine on these nodes and I don't see why packages would have any issue. I believe Octopus and Nautilus would also need that change to install-deps.sh to build properly, but otherwise I don't believe there are any major issues preventing them from working. Mark On 12/8/20 3:01 PM, Marc Roos wrote: I did not. Thanks for the info. But if I understand this[1] explanation correctly. CentOS stream is some sort of trial environment for rhel. So who is ever going to put SDS on such an OS? Last post on this blog "But if you read the FAQ, you also learn that once they start work on RHEL 9, CentOS Stream 8 ceases to exist..." [1] https://www.youtube.com/watch?v=IEEdOogPMY8 -Original Message- To: ceph-users@ceph.io Subject: [ceph-users] CentOS All; As you may or may not know; this morning RedHat announced the end of CentOS as a rebuild distribution[1]. "CentOS" will be retired in favor of the recently announced "CentOS Stream." Can Ceph be installed on CentOS Stream? Since CentOS Stream is currently at 8, the question really is: Can Ceph Octopus be installed on CentOS Stream 8? How about Nautilus? Thank you, Dominic L. Hilsbos, MBA Director - Information Technology Perform Air International Inc. dhils...@performair.com www.PerformAir.com [1: https://blog.centos.org/2020/12/future-is-centos-stream/] ___ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-le...@ceph.io ___ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-le...@ceph.io ___ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-le...@ceph.io
[ceph-users] Re: Larger number of OSDs, cheroot, cherrypy, limits + containers == broken
Ken, We have rebuilt the container images of 15.2.7 with this RPM applied, and will be deploying it to a larger (504 OSD) cluster to test - this cluster had the issue previously until we disabled polling via Prometheus. We will update as soon as it's run for a day or two and we've been able to verify the mgr issues we saw no longer occur after extended polling via external and internal prometheus instances. Thank you again for the quick update, we'll let you know as soon as we have more feedback, David On Tue, Dec 8, 2020 at 10:37 AM David Orman wrote: > Hi Ken, > > Thank you for the update! As per: > https://github.com/ceph/ceph-container/issues/1748 > > We implemented the (dropping ulimit to 1024:4096 for mgr) suggested change > last night, and on our test cluster of 504 OSDs, being polled by the > internal prometheus and our external instance, the mgrs stopped responding > and dropped out of the cluster entirely. This is impacting not just > metrics, but the mgr itself. I think this is a high priority issue, as > metrics are critical for prod, but mgr itself seems to be impacted on a > moderately sized cluster. > > Respectfully, > David Orman > > On Mon, Dec 7, 2020 at 1:50 PM Ken Dreyer wrote: > >> Thanks for bringing this up. >> >> We need to update Cheroot in Fedora and EPEL 8. I've opened >> https://src.fedoraproject.org/rpms/python-cheroot/pull-request/3 to >> get this into Fedora first. >> >> I've published an el8 RPM at >> https://fedorapeople.org/~ktdreyer/bz1868629/ for early testing. I can >> bring up a "hello world" cherrypy app with this, but I've not tested >> it with Ceph. >> >> - Ken >> >> On Mon, Dec 7, 2020 at 9:57 AM David Orman wrote: >> > >> > Hi, >> > >> > We have a ceph 15.2.7 deployment using cephadm under podman w/ systemd. >> > We've run into what we believe is: >> > >> > https://github.com/ceph/ceph-container/issues/1748 >> > https://tracker.ceph.com/issues/47875 >> > >> > In our case, eventually the mgr container stops emitting >> output/logging. We >> > are polling with external prometheus clusters, which is likely what >> > triggers the issue, as it appears some amount of time after the >> container >> > is spawned. >> > >> > Unfortunately, setting limits in the systemd service file for the mgr >> > service on the host OS doesn't work, nor does modifying the unit.run >> file >> > which is used to start the container under podman to include the >> --ulimit >> > settings as suggested. Looking inside the container: >> > >> > lib/systemd/system/ceph-mgr@.service:LimitNOFILE=1048576 >> > >> > This prevents us from deploying medium to large ceph clusters, so I >> would >> > argue it's a high priority bug that should not be closed, unless there >> is a >> > workaround that works until EPEL 8 contains the fixed version of cheroot >> > and the ceph containers include it. >> > >> > My understanding is this was fixed in cheroot 8.4.0: >> > >> > https://github.com/cherrypy/cheroot/issues/249 >> > https://github.com/cherrypy/cheroot/pull/301 >> > >> > Thank you in advance for any suggestions, >> > David >> > ___ >> > ceph-users mailing list -- ceph-users@ceph.io >> > To unsubscribe send an email to ceph-users-le...@ceph.io >> > >> >> ___ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-le...@ceph.io
[ceph-users] DocuBetter Meeting cancelled this week.
The DocuBetter meeting scheduled for one hour from the time of this email is cancelled. Send documentation concerns to me at zac.do...@gmail.com. Zac Dover Upstream Docs Ceph ___ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-le...@ceph.io
[ceph-users] Re: Running Mons on msgrv2/3300 only.
On 08/12/2020 20:17, Wesley Dillingham wrote: We rebuilt all of our mons in one cluster such that they bind only to port 3300 with msgrv2. Previous to this we were binding to both 6789 and 3300. All of our server and client components are sufficiently new (14.2.x) and we haven’t observed any disruption but I am inquiring if this may be problematic for any unforeseen reason. We don’t intend to have any older clients connecting. https://docs.ceph.com/en/latest/rados/configuration/msgr2/ doesn’t mention much about running with only v2 so I just want to make sure we aren’t setting ourselves up for trouble. Thanks. No, not really. I have a couple of those servers as well where v1 was disabled completely. Wido -- Respectfully, Wes Dillingham Site Reliability Engineer IV Storage Engineering / Ceph wdillingham(at)godaddy.com ___ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-le...@ceph.io ___ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-le...@ceph.io
