[arin-discuss] Moving Data Centers - new thread

Daniel Lis dan at bipmedia.com
Fri Apr 26 12:11:47 EDT 2019


Hello Rick, 

I'm not sure how I got on this thread in the first place but I just wanted to say great thread post. 

Very clear. I think you're spot on. Are you going to need to do this again? 

Are you looking to have more of a real-time replication scenario ? 

How are you currently setup? VPS or dedicated servers or combo? How many... 

I would be happy to lend my thoughts and have some folk here give you some ideas as well. 



-- Cheers! 

Daniel Lis | CTO 
(O) [ callto:305.340.2398 | 305.340.2398 ] ext 101 
(M) [ callto:561-909-9965 | 561-909-9965 ] 
[ mailto:Dan at BIPmedia.com | Dan at BIPmedia.com ] | [ https://bipmedia.com/ | BIPmedia.com ] 



The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access by any other person to this e-mail is not authorised. If you are not the intended recipient, please delete this e-mail. Any disclosure of this e-mail or of the parties to it, any copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited, and may be unlawful. 


From: "Matt Harris" <matt at netfire.net> 
To: "Rick Ewart" <rick at ewart.net> 
Cc: "arin-discuss" <arin-discuss at arin.net> 
Sent: Friday, April 26, 2019 12:01:44 PM 
Subject: Re: [arin-discuss] Moving Data Centers - new thread 

Hey Rick, 
If you want to get funky and do it with potentially zero downtime, you can ask the new provider for a single IPv4 address for temporary use and configure it up on your new router with a simple static default route, and then setup a gre tunnel between the border routers at the old site and the new site. As systems get moved, you place their addresses on the gre tunnel. Once everything is moved, you can then go ahead and establish your BGP session(s) and start announcing your IP space so that things work normally over there. Remove the announcements at the old site, and as soon as traffic is working, get rid of the static route and the gre tunnel and you're all set. 

Depending on your hardware and software stack, there are also more-automated/fancier ways to accomplish this like VXLAN or even creating L2 tunnels which establish adjacency for your IGP and would potentially allow it to handle some of these things, but any suggestions of that nature get more complicated and very dependent on your stack and configuration. 

Good luck, 
Matt 


On Fri, Apr 26, 2019 at 10:47 AM Rick Ewart < [ mailto:rick at ewart.net | rick at ewart.net ] > wrote: 





Hi All. 



I wanted to follow-up on the “portability” thread for a comment made in the process about data center moves…. I started a new thread since its really a different discussion. 



I have a /24 that we own and is currently advertised via BGP on our data center’s internet as well as on a dedicated circuit from another provider. I am planning for a move in the future – like a year from now. Last time I moved data centers 10 years ago I put up a firewall and switch at the new location and then moved all the servers 1 by 1 or few by few. Its was close by so it wasn’t a big deal. But virtualization has certainly changed the options available, and I expect to move about 30 minutes away from my current location. Also a lot has changed in terms of my customer’s expectations of uptime. 



I have been casually thinking about the move and wondering how I might be able to do something a bit more “slick” to move it with minimal downtime. I don’t purport to be a BGP expert so pardon me if I say something stupid but…. I was thinking that since I will put my own circuits into the new place (one with the “other provider” I have today), I could probably just use BGP to move things. The thought was to replicate at least the most critical/public facing servers to the new location and then just stop/start the BGP advertising to change to the new location. It seems to me that this should be nice and easy at least with the 1 “other provider” I have today, and avoid the need to re-IP anything. I mean, the convergence should be like normal and quick. Correct? 



If so, it seems I can have almost zero downtime on the more static things like web sites. Then I can move the SANs, main virtual hosts and such a bit more “leisurely”. Obviously things like mail servers and such will be more of an issue because they are constantly changing (but are less visible to the outside world if they go down for an hour), but DNS servers, many web servers, etc should be ok I would think. 



I welcome any thoughts on this. Want to make sure I am not overlooking something basic. 



Thanks, 

Rick 


_______________________________________________ 
ARIN-Discuss 
You are receiving this message because you are subscribed to 
the ARIN Discussion Mailing List ( [ mailto:ARIN-discuss at arin.net | ARIN-discuss at arin.net ] ). 
Unsubscribe or manage your mailing list subscription at: 
[ https://lists.arin.net/mailman/listinfo/arin-discuss | https://lists.arin.net/mailman/listinfo/arin-discuss ] 
Please contact [ mailto:info at arin.net | info at arin.net ] if you experience any issues. 





-- 
Matt Harris - Chief Security Officer 
Security, Compliance, and Engineering 
Main: +1-816-256-5446 
Mobile: +1-908-590-9472 

Email: [ mailto:matt at netfire.net | matt at netfire.net ] 

_______________________________________________ 
ARIN-Discuss 
You are receiving this message because you are subscribed to 
the ARIN Discussion Mailing List (ARIN-discuss at arin.net). 
Unsubscribe or manage your mailing list subscription at: 
https://lists.arin.net/mailman/listinfo/arin-discuss 
Please contact info at arin.net if you experience any issues. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-discuss/attachments/20190426/2dcbddf1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 586-425-max.png
Type: image/png
Size: 30289 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-discuss/attachments/20190426/2dcbddf1/attachment.png>


More information about the ARIN-discuss mailing list