Lab outage 31Jan-2Feb
Hi all. We've had problems in the sepia lab again, but we're hoping that most services are back up and stable. As always, please let us know of any problems that seem to be infrastructure-related via email here or to our Slack channel https://ceph-storage.slack.com/archives/C1HFJ4VTN. Details: We had a scheduled maintenance for all lab switches on 31 Jan that was, as always, supposed to be a short interruption with no expected problems. It turned out not to be true, but after a few days of bad connectivity (not missing, just bad; lost packets, retransmissions, really bad bursty inconsistent performance) the network operations guys think they've resolved it. The cause seems to have been lack of proper support in the updated firmware and the optical transceivers on the switches (mitigated by installing a different branch of firmware), as well as at least one virtual chassis with failing internal hardware, being RMAed as of today. So things should have gotten a *lot* better as of today, but there are still some systems which will perform worse than normal and will need another interruption when the new hardware arrives. Even those hosts are connected, just experiencing bad packet integrity. Those include a few of the Ceph cluster hosts, a few test hosts, and a couple others. Even given that, the cluster has been pretty happy since reloading the last choice of firmware. The reason this was particularly annoying is that the switch hardware also runs a lot of our critical services, some of which also store data on our internal Ceph cluster which was itself also affected by the network integrity issue (loooooong heartbeats (like, tens of seconds), presumed-dead mons and osds flapping, etc.). Narrowing down on a specific cause was not fun. Anyway, we're mostly back up now, and we've identified a failing switch before it completely failed, which is a bit of a silver lining.
On Fri, Feb 3, 2023 at 12:32 PM Dan Mick <dmick@redhat.com> wrote:
Hey Dan, First of all thanks for your work on sorting this out.
Hi all. We've had problems in the sepia lab again, but we're hoping that most services are back up and stable. As always, please let us know of any problems that seem to be infrastructure-related via email here or to our Slack channel https://ceph-storage.slack.com/archives/C1HFJ4VTN.
Details: <snip> The reason this was particularly annoying is that the switch hardware also runs a lot of our critical services, some of which also store data on our internal Ceph cluster which was itself also affected by the network integrity issue (loooooong heartbeats (like, tens of seconds), presumed-dead mons and osds flapping, etc.). Narrowing down on a specific cause was not fun.
Were the osds actually flapping or were they just being reported down by osds that lost connection with them? Curious as I wouldn't expect them to actually go down, just be reported down (but then maybe that's what you meant by 'flapping').
Anyway, we're mostly back up now, and we've identified a failing switch before it completely failed, which is a bit of a silver lining. _______________________________________________ Sepia mailing list -- sepia@ceph.io To unsubscribe send an email to sepia-leave@ceph.io
-- Cheers, Brad
The reason this was particularly annoying is that the switch hardware also runs a lot of our critical services, some of which also store data on our internal Ceph cluster which was itself also affected by the network integrity issue (loooooong heartbeats (like, tens of seconds), presumed-dead mons and osds flapping, etc.). Narrowing down on a specific cause was not fun.
Were the osds actually flapping or were they just being reported down by osds that lost connection with them? Curious as I wouldn't expect them to actually go down, just be reported down (but then maybe that's what you meant by 'flapping').
I might have extemporized a bit too far. The mons were going in and out of quorum; I did not prove they were restarting. The OSDs, I don't know; all I know for certain is that they were reporting *huge* osd-to-osd heartbeat times. So the procs may not have actually exited in either case.
On Fri, Feb 3, 2023 at 1:47 PM Dan Mick <dmick@redhat.com> wrote:
The reason this was particularly annoying is that the switch hardware also runs a lot of our critical services, some of which also store data on our internal Ceph cluster which was itself also affected by the network integrity issue (loooooong heartbeats (like, tens of seconds), presumed-dead mons and osds flapping, etc.). Narrowing down on a specific cause was not fun.
Were the osds actually flapping or were they just being reported down by osds that lost connection with them? Curious as I wouldn't expect them to actually go down, just be reported down (but then maybe that's what you meant by 'flapping').
I might have extemporized a bit too far. The mons were going in and out of quorum; I did not prove they were restarting. The OSDs, I don't know; all I know for certain is that they were reporting *huge* osd-to-osd heartbeat times. So the procs may not have actually exited in either case.
Yes, from the brief look I had in the mon log there were reports coming in from osds that other osds were down but no reports I could see of osds *actually* being down. -- Cheers, Brad
participants (2)
-
Brad Hubbard
-
Dan Mick