Not a 4.8 blocker. Scott, can someone from Ceph team take a look please.
This is a two part process. First we need to establish the baseline of EXPECTED performance. The and only then can we start an effective performance analysis.
Given that this is expected behavior, what is the expected result of this ticket? This is essentially a feature request (RFE) to tune the performance in specific conditions. It is likely too late to add this request to 5.0 z1, thus it won't be available until RHEL 5.1 (which will then be available for ODF 4.10 or later).
(In reply to Scott Ostapovicz from comment #15) > Given that this is expected behavior, what is the expected result of this > ticket? This is essentially a feature request (RFE) to tune the performance > in specific conditions. It is likely too late to add this request to 5.0 z1, > thus it won't be available until RHEL 5.1 (which will then be available for > ODF 4.10 or later). This can be documented and an RFE for Ceph can be opened and tracked for Ceph 5.1 WDYT?
This would be a research RFE to see if we can fine tune the behavior and improve performance? If so then I concur.
Marking it as a known issue and moving it out of 4.9 Can we please fill the doc text?
(In reply to Mudit Agarwal from comment #19) > Marking it as a known issue and moving it out of 4.9 > > Can we please fill the doc text?
I'm unsure what the status of this BZ.
Arbiter feature is not prioritized at the moment, and this has to be looked by Ceph folks which I guess has not happened because of the priority.
There's no meaningful Ceph work to do here. If you inject 20ms+ of networking delay into every disk IO, things are going to be slow. Any improvements we can make to performance here are going to be about how the Ceph daemons are placed in the cluster topology. That's on Rook and ODF, so I'm handing this ticket back to be evaluated. :)
Is the suggestion that a client workload should be run in the same zone as the MDS? Rook/ODF doesn't treat one of the zones as primary. It sounds like all we can do here is document that you'll get better performance if you run the workload in the same zone as MDS. Reading through this BZ, I don't understand anything else that can be done for the topology. Ultimately, if they choose a high-latency topology, performance of small files is going to suffer.
(In reply to Travis Nielsen from comment #29) > Is the suggestion that a client workload should be run in the same zone as > the MDS? And the CRUSH rule should be formulated so that that zone is used as the source for primary OSDs, yeah. > Rook/ODF doesn't treat one of the zones as primary. It sounds like > all we can do here is document that you'll get better performance if you run > the workload in the same zone as MDS. Reading through this BZ, I don't > understand anything else that can be done for the topology. Ultimately, if > they choose a high-latency topology, performance of small files is going to > suffer. Yeah, agreed. This only matters if assigning a primary site and assuming failover to the other is sensible, though I think that generally fits in with the constraints on stretch mode anyway? (If you are running both sites active, and one dies, you need to have enough spare capacity in the remainder to double its workload or you haven't bought yourself much for all that expense!)
Moving this to doc, based on the above comments.
After the DR ENG meeting, we agreed on leaving the docs as they are, with one example in the docs: the Active/Active use case that is what we are seeing more requests from the field. A KCS will be created with examples for an Active/Passive configuration, using a crushmap with all primary OSDs and MDS daemons in the Active Zone.