Hi! To my knowledge, you can really only have one (active) redis server in the architecture, and all api-, content- and (maybe) pulpcore-workers need access to that. If however you opt for not caching the access to the content servers, you can work without redis altogether (this may not be entirely true: https://pulp.plan.io/issues/8997). The question about the artifact storage is roughly the same, but completely independent. You can either use filesystem or s3 (other cloud storages are currently not covered by tests but may still work), but all pulp components need access to the same storage. This is by no means affected by how / if you deploy redis. Hope, this answers your question. Matthias
On Thu, Sep 23, 2021 at 10:56 PM Bin Li (BLOOMBERG/ 120 PARK) <[email protected]> wrote: > > Thanks Brain and Matthias. It's really helpful to understand how this works. > I'd like to know the answer of the same question under two different > scenarios. > In both scenarios, we will have 2 content servers behind a load balancer and > share the same external db. Api server is only run on one of the hosts. > 1) Both content servers have the same artifacts in its own filesystems > (rsyned) > 2) Both content servers shared the S3. > > We currently use filesystem as the storage and would like to move to S3. Can > redis be independent in above two cases? > > From: [email protected] At: 09/21/21 16:50:53 UTC-4:00 > To: [email protected] > Cc: Bin Li (BLOOMBERG/ 120 PARK ) , [email protected] > Subject: Re: [Pulp-list] redis on a passive backup server > > Right i did not read that correctly. It's a failover scenario. It > would even be safe to flush redis on failover. > I was thinking about multiple independent content app installations > each with their own redis server. But that is another challenge. > > On Tue, Sep 21, 2021 at 7:32 PM Brian Bouterse <[email protected]> wrote: > > > > > > > > On Mon, Sep 20, 2021 at 5:40 PM Matthias Dellweg <[email protected]> > > wrote: > >> > >> I am not sure if the cache invalidations will be pushed to all redis > >> instances if deployed that way. Maybe there is a little bit of extra > >> work needed. > > > > I imagined the backup Pulp would have its Redis empty because that Pulp > wasn't in use. If that were the case cache invalidations not reaching it would > be fine because the cache would be empty at failover time. As always though, > there could be more needed to handle some specific use cases. > > > >> > >> On Mon, Sep 20, 2021 at 10:31 PM Brian Bouterse <[email protected]> > >> wrote: > >> > > >> > I believe with 3.14+ and new style workers, you can have an independant > redis on the backup server. > >> > > >> > With the new-style tasking system (the default in 3.14) you no longer > >> > need > Redis for tasking. It's only purpose then is to help speedup the content app > which caches info about requests to make answering subsequent content-app > requests easier. If those caches miss, e.g. if you had a failover event, Pulp > will continue to work fine, just building the Redis cache data as it goes. > >> > > >> > On Mon, Sep 20, 2021 at 4:22 PM Bin Li (BLOOMBERG/ 120 PARK) > <[email protected]> wrote: > >> >> > >> >> We configured a redis slave on a passive backup server which shares the > same external database with the primary pulp server. I noticed the task queues > are now being tracked in the database. Is it still necessary to configure > redis > as a slave or we can have an independent instance of redis on the backup > server? > >> >> > >> >> Thanks > >> >> _______________________________________________ > >> >> Pulp-list mailing list > >> >> [email protected] > >> >> https://listman.redhat.com/mailman/listinfo/pulp-list > >> > > >> > _______________________________________________ > >> > Pulp-list mailing list > >> > [email protected] > >> > https://listman.redhat.com/mailman/listinfo/pulp-list > >> > > _______________________________________________ Pulp-list mailing list [email protected] https://listman.redhat.com/mailman/listinfo/pulp-list
