Ok Should be necessary more info to create a sample project, like bandwidth and other infos, although one point could be use ISS (Inter Satellite Sync) and bellow them proxies. At the end of the day, I believe your main problem be a link and not a server / servers infra structure.
Let's wait for a gurus/experts answers about it! ;-) Take Care ______________ Atenciosamente Waldirio msn: [email protected] Skype: waldirio Site: www.waldirio.com.br Blog: blog.waldirio.com.br LinkedIn: http://br.linkedin.com/pub/waldirio-pinheiro/22/b21/646 PGP: www.waldirio.com.br/public.html On Wed, Nov 19, 2014 at 1:34 PM, Matthew Madey <[email protected]> wrote: > We currently have 4 Spacewalk Proxies, geographically positioned to > support the clients. Problem is, we have 8000+ clients, and they are split > up between hundreds of locations. It's a huge environment, but we've made > it work pretty well so far. To work around the issue of bandwidth, we've > been pre-staging patch bundles by delivering the metadata and packages to > the /var/cache/yum directory on all the clients, and setting the metadata > expire in yum.conf to about 7 days. We run into trouble though when someone > runs a yum clean all on a client, and it has to download the metadata over > the slow connection. Or when we have to do zero day patching, which luckily > the most recent one's (SSL and BASH) have been very small updates. We > created a separate channel for that sort of thing, so the amount of > metadata downloaded is very small. > > The traffic shaping we've done on the network layer seems to have helped a > bit, but I'm not sure what other settings we can tune in Spacewalk to > better throttle client requests. We've thought about turning off rhnsd on > the clients during peak business hours, but I'd rather not go that route. > > On Tue, Nov 18, 2014 at 12:18 PM, Waldirio Manhães Pinheiro < > [email protected]> wrote: > >> Matthew, >> >> I believe be interesting know better your environment, btw, you can work >> with proxy (between your company and filial/client) or really use Spacewalk >> Proxy. With this you will probably work better, you have to check the >> necessity according the quantity of clients or the problem caused by >> latency. >> >> Do a test with one proxy in your problematic environment and enjoy! >> >> Let me know if works for you. >> >> B'Regards >> >> ______________ >> Atenciosamente >> Waldirio >> msn: [email protected] >> Skype: waldirio >> Site: www.waldirio.com.br >> Blog: blog.waldirio.com.br >> LinkedIn: http://br.linkedin.com/pub/waldirio-pinheiro/22/b21/646 >> PGP: www.waldirio.com.br/public.html >> >> On Tue, Nov 18, 2014 at 2:20 PM, Matthew Madey <[email protected]> >> wrote: >> >>> All, >>> >>> I've run into a situation where my total metadata for channels has grown >>> quite large (about 200MB). I've done all I can as far as channel\package >>> management to reduce the size of the metadata.. >>> We have a number of locations where the bandwidth to the clients is >>> extremely small.. So downloading new metadata causes severe network latency >>> on these clients.. We've done some traffic shaping on the network layer to >>> reduce the impact, but I'm looking for other alternatives focused more >>> around Spacewalk. Looking for anyone who may have a similar situation and >>> what steps they've taken to mitigate the issue. Are there any sort of >>> throttling settings available in Spacewalk, or does this all have to be >>> done at the OS\Network layers? >>> >>> >>> >>> _______________________________________________ >>> Spacewalk-list mailing list >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/spacewalk-list >>> >> >> >> _______________________________________________ >> Spacewalk-list mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/spacewalk-list >> > > > _______________________________________________ > Spacewalk-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/spacewalk-list >
_______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
