Dieser Artikel ist aus dem April 2020
Die Livemigration von Instanzen ist in Triton-Umgebungen nicht möglich, weil weitgehend auf Shared-Storage verzichtet wird. Das ist nachvollziehbar, da Shared-Storage immer wieder Anlaß zu Ausfällen in Cloud Umgebungen ist.
Die Offlinemigration von Instanzen innerhalb von Triton-Umgebungen ist jedoch seit einiger Zeit möglich. Da sich eben die Gelegenheit bietet, paste ich den Vorgang mal kurz hier 'rein:
[root@headnode (de-gt-2) ~]# sdc-migrate migrate 056e0e4c-0295-6caf-b494-a7f2addab268
# Migration begin running in job f7e210f9-81b6-4879-ab8e-f86927c39f0e
- reserving instance
- syncing data
- running: 100% 19.2MB/s
- syncing data
- running: 100% 1.1kB/s (ETA 4s)
- stopping the instance
- syncing data
- running: 100% 337.8kB/s
- switching instances
- filesytem sync finished, switching instances
- reserving the IP addresses for the instance
- setting up the target filesystem
- hiding the original instance
- promoting the migrated instance
- removing sync snapshots
OK - switch was successful
Mit dem Parameter -n <CN> könnte man sogar noch den Computenode (CN) angeben, auf welchen man migrieren will. Zurück bleibt auf dem Quell-CN die gestoppte, alte Instanz:
[root@hh24-gts2-de30 (de-gt-2) ~]# vmadm list |grep stop
056e0e4c-0295-6caf-b494-a7f2addab268 OS 4096 stopped minio1
Die dann mit vmadm delete <uuid> gelöscht werden kann.
Wie man sieht, arbeitet die Migration mit iterativen ZFS-Snapshots damit die Downtime der Instanz so kurz wie möglich gehalten werden kann. Limitierende Faktoren sind hier (wie bei allen Migrationen von virtuellen Maschinen) natürlich die Änderungsrate innerhalb der VM und die Bandbreite, mit der man Daten übertragen kann.
Links