[Spacewalk-list] Low bandwidth locations

Tue Nov 25 23:35:12 UTC 2014

Hello Everyone, 
I had similar case and we built proxies closes proximity and use mix of nfs and rsync to mount and delivery rpm. Then use spacewalk pre cache proxy feature. 
I mounted /var/spool/rhn-proxy/rhn NFSv4 TCP with adjustment of MSS through iptables. 
For configuration files delivery osad help a lot and using through same proxies. 

Slava. 

From: "Waldirio Manhães Pinheiro" <waldirio at gmail.com> 
To: "spacewalk-list" <spacewalk-list at redhat.com> 
Sent: Wednesday, November 19, 2014 11:24:57 AM 
Subject: Re: [Spacewalk-list] Low bandwidth locations 

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: waldirio at gmail.com 
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 < mattmadey at gmail.com > 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 < waldirio at gmail.com > wrote: 

BQ_BEGIN

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: waldirio at gmail.com 
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 < mattmadey at gmail.com > wrote: 

BQ_BEGIN

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 
Spacewalk-list at redhat.com 
https://www.redhat.com/mailman/listinfo/spacewalk-list 

_______________________________________________ 
Spacewalk-list mailing list 
Spacewalk-list at redhat.com 
https://www.redhat.com/mailman/listinfo/spacewalk-list 

BQ_END

_______________________________________________ 
Spacewalk-list mailing list 
Spacewalk-list at redhat.com 
https://www.redhat.com/mailman/listinfo/spacewalk-list 

BQ_END

_______________________________________________ 
Spacewalk-list mailing list 
Spacewalk-list at redhat.com 
https://www.redhat.com/mailman/listinfo/spacewalk-list 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20141125/59c4d132/attachment.htm>