[squid-users] Transition from Squid to bluecoat ProxySG
bpk678 at gmail.com
Sat Apr 16 14:14:26 UTC 2016
On 04/16/2016 09:39 AM, asad wrote:
> I'm in the process of helping a friend who works in a bank whose
> management have decided to move from Squid infra to bluecoat PorxySG
> I want to know what are the pitfalls that must be imagined from
> project management as on technical end.
> Few info that I'm allowed to share is
> users are 1000 and bandwidth is 40 Mbps.
> Between BCP and HQ site active passive setup/configuration.
> There are good and bad of each tech, but when there is mgt executive
> decision there leaves not much gap of debating what is better. I'm
> wishing anyone from the community who has been involved in such a task
> in past , current or in near future.
> squid-users mailing list
> squid-users at lists.squid-cache.org
i support blue coat proxies professionally, and run squid proxies
personally. while i have not migrated from one to the other, i have
done data center relocation work where 4 existing sites with proxy
footprints were consolidated into two new sites. i had to support
physically moving 14 production proxies to the new sites without
interrupting internet access for 30k+ users and myriads of production
applications that use the proxies to access internet resources.
can you explain what you mean by active / passive config? i take this
to mean some sort of failover mechanism is used. are you using load
balancing to manage this? if you are, your cutover can be a lot easier,
as you would simply insert the blue coat into the load balanced pool
and assign traffic to it.
if you are using a proxy script or PAC file, and not load balancing, you
can assign certain traffic to the blue coat in the PAC. a lot of
flexibility can be exercised in a PAC file, since you dictate the logic.
i had the luxury of both load balancing and PAC file in order to manage
my moves. i did a little of both the above to manage traffic levels
during transition periods. i was able to move the initial devices
because one site had newer gear with plenty of performance head room.
then it was a cycle of reassign traffic, move more hardware, lather,
rinse and repeat...
i would suggest you build and test your new gear extensively before
starting any cutover. develop a build process and separate validation
process to ensure consistency and accuracy of the build. check interface
settings, routing, dns settings, authentication pieces and any
particular items in your environment that is considered a show-stopper,
unacceptable risk or gap in security posture. have technical personnel
use the blue coat proxies for a couple days to a week before giving the
general user audience access to them. you can get their input about
issues and performance and tweak things.
recommend that the environment use both load balancing and a PAC file,
if you can convince the mgmt. sell them one buying more capable
hardware than you need, because failover events such as ISP (as opposed
to WAN) outages could be almost seamless and the additional load of
users pushed to an alternate device in the load balanced pool wont bring
down the box. this assumes that you maintain the active / passive
config i think you have. sell them on reliability, stability and high
i am interested to hear what decisions are made and how things progress
for you. best of luck.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the squid-users