[arin-discuss] Moving Data Centers - new thread

Matt Harris matt at netfire.net
Fri Apr 26 12:01:44 EDT 2019


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 <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 (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.
>


-- 
Matt Harris - Chief Security Officer
Security, Compliance, and Engineering
Main: +1-816-256-5446
Mobile: +1-908-590-9472
Email: matt at netfire.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-discuss/attachments/20190426/e50fd09d/attachment.html>


More information about the ARIN-discuss mailing list