[Spacewalk-list] Low bandwidth locations

[Waldirio Manhães Pinheiro]

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:
>
>> 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:
>>
>>> 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
>>
>
>
> _______________________________________________
> 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/20141119/081f8392/attachment.htm>