[squid-users] Transition from Squid to bluecoat ProxySG

[Brendan Kearney]

On 04/16/2016 09:39 AM, asad wrote:
> Hello,
>
> 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 
> solution.
>
> 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.
>
> Thanks
>
> regards
> asad
>
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
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 
availability.

i am interested to hear what decisions are made and how things progress 
for you.  best of luck.

brendan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160416/4a136d49/attachment.html>