Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Migrate from legacy network in GCE

Long story short - I need to use networking between projects to have separate billing for them.

I'd like to reach all the VMs in different projects from a single point that I will use for provisioning systems (let's call it coordinator node).

It looks like VPC network peering is a perfect solution to this. But unfortunately one of the existing networks is "legacy". Here's what google docs state about legacy networks.

About legacy networks Note: Legacy networks are not recommended. Many newer GCP features are not supported in legacy networks.

OK, naturally the question arises: how do you migrate out of legacy network? Documentation does not address this topic. Is it not possible?

I have a bunch of VMs, and I'd be able to shutdown them one by one:

  1. shutdown
  2. change something
  3. restart

unfortunately it does not seem possible to change network even when VM is down?

EDIT: it has been suggested to recreate VMs keeping the same disks. I would still need a way to bridge legacy network with new VPC network to make migration fluent. Any thoughts on how to do that using GCE toolset?

like image 729
Julius Žaromskis Avatar asked Dec 08 '17 14:12

Julius Žaromskis


People also ask

What is legacy network in GCP?

Legacy networks have a single global IP address range that cannot be divided into subnets. VPC networks are divided into subnets. Each Google Cloud region can have one or more subnets in a VPC network. With VPC networks, each Google Cloud region can have one or more subnets.

How are subnetworks different than the legacy networks?

. Legacy (non-subnetwork) mode is the original approach for networks, where IP address allocation occurs at the global network level. This means the network address space spans across all regions. You can still create a legacy network, but subnetworks are the preferred approach and default behavior going forward.


1 Answers

One possible solution - for each VM in the legacy network:

  1. Get VM parameters (API get method)
  2. Delete VM without deleting PD (persistent disk)
  3. Create VM in the new VPC network using parameters from step 1 (and existing persistent disk)

This way stop-change-start is not so different from delete-recreate-with-changes. It's possible to write a script to fully automate this (migration of a whole network). I wouldn't be surprised if someone already did that.

UDPATE

https://github.com/googleinterns/vm-network-migration tool automates the above process, plus it supports migration of a whole Instance Group or Load Balancer, etc. Check it out.

like image 81
Kluyg Avatar answered Sep 28 '22 07:09

Kluyg