... why does the first graph show some instances as having a negative launch time? Is that meant to indicate errors, or has GCP started preemptively launching instances to anticipate requests?
AWS vs. GCP reliability is wildly different
21–30 of 245 posts
Re: AWS vs. GCP reliability is wildly different
#22... why does the first graph show some instances as having a negative launch time? Is that meant to indicate errors, or has GCP started preemptively launching instances to anticipate requests?
Re: AWS vs. GCP reliability is wildly different
#23Re: AWS vs. GCP reliability is wildly different
#24A few weeks ago I needed to change the volume type on an EC2 instance to gp3. Following the instructions, the change happened while the instance was running. I didn't need to reboot or stop the instance, it just changed the type. While the instance was running. I didn't understand how they were able to do this, I had thought volume types mapped to hardware clusters of some kind. And since I didn't understand, I wasn'…
Dunno about AWS, but GCP uses live migration, and will migrate your VM across physical machines as necessary. The disk volumes are all connected over the network, nothing really depends on the actual physical machine your VM is ran on.
Re: AWS vs. GCP reliability is wildly different
#25Earlier quoted context omitted.
Dunno about AWS, but GCP uses live migration, and will migrate your VM across physical machines as necessary. The disk volumes are all connected over the network, nothing really depends on the actual physical machine your VM is ran on.
How does migrating a vm to another physical machine work?
Re: AWS vs. GCP reliability is wildly different
#26Earlier quoted context omitted.
Dunno about AWS, but GCP uses live migration, and will migrate your VM across physical machines as necessary. The disk volumes are all connected over the network, nothing really depends on the actual physical machine your VM is ran on.
How does migrating a vm to another physical machine work?
Essential, memory state is copied to the new host, the VM is stunned for a millisecond and the cpu states is copied and resumed on the new host (you may see a dropped ping). All the networking and storage is virtual anyway so that is "moved" (it's not really moved) in the background.
Re: AWS vs. GCP reliability is wildly different
#27GCP on the other hand fills all machines with background jobs. When you want a machine, they need to terminate a background job to make room for you. That background job has a shutdown grace time. Usually thats 30 seconds.
Sometimes, to prevent fragmentation, they actually need to shuffle around many other users to give you the perfect slot - and some of those jobs have start-new-before-stop-old semantics - that's why sometimes the delay is far higher too.
Re: AWS vs. GCP reliability is wildly different
#28Earlier quoted context omitted.
Dunno about AWS, but GCP uses live migration, and will migrate your VM across physical machines as necessary. The disk volumes are all connected over the network, nothing really depends on the actual physical machine your VM is ran on.
How does migrating a vm to another physical machine work?
Re: AWS vs. GCP reliability is wildly different
#29It's meant to say "ephemeral"... right? It's hard to read after that.
ephemeral and ethereal are commonly confused words.
Re: AWS vs. GCP reliability is wildly different
#30Earlier quoted context omitted.
Dunno about AWS, but GCP uses live migration, and will migrate your VM across physical machines as necessary. The disk volumes are all connected over the network, nothing really depends on the actual physical machine your VM is ran on.
How does migrating a vm to another physical machine work?
The disks are all on the network, so no need to move anything there.