|
On 04/16/2016 09:39 AM, asad wrote:
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 |
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
