Удаление снимков в состояниях Allocated, BackingUp

Open source, Apache CloudStack, Stuck Snapshots

logo

В некоторых нештатных ситуациях снимки томов виртуальных машин в ACS могут застрять в нестандартных состояниях, таких как Allocated, BackingUp, в которых их невозможно удалить с помощью средств API. К сожалению, данная проблема встречается практически во всех версиях ACS, в последний раз была встречена в ACS 4.9.2. У администратора возникает необходимость все же как-то удалять такие снимки. В данной мини-статье дается руководство как выполнить данную процедуру.

Итак, это нештатная ситуация. Для ее решения необходимо воспользоваться редактированием сущностей снимков через БД MySQL CloudStack. Операция будет производиться в три этапа:

  1. изменение статуса проблемного снимка в БД средствами СУБД
  2. удаление снимка через API
  3. проверка удаления данных из вторичного хранилища.

Исправление

Сначала обнаружим проблемные снимки:

mysql> select * from snapshots where status != 'BackedUp' and status != 'Destroyed' and status != 'Error';

+-----+----------------+------------+-----------+-----------+------------------+-----------+------+-----------------------------------------------------------------+--------------------------------------+---------------+------------------+-------------+---------------------+---------------------+----------------+----------+------------+--------------+-----------------+---------+-------+----------+----------+
| id  | data_center_id | account_id | domain_id | volume_id | disk_offering_id | status    | path | name                                                            | uuid                                 | snapshot_type | type_description | size        | created             | removed             | backup_snap_id | swift_id | sechost_id | prev_snap_id | hypervisor_type | version | s3_id | min_iops | max_iops |
+-----+----------------+------------+-----------+-----------+------------------+-----------+------+-----------------------------------------------------------------+--------------------------------------+---------------+------------------+-------------+---------------------+---------------------+----------------+----------+------------+--------------+-----------------+---------+-------+----------+----------+
|  66 |              1 |          4 |         1 |       376 |                1 | Allocated | NULL | VM-aab02612-8b9b-4274-b727-3505558995b3_ROOT-336_20170117082532 | c35af6d6-eb89-406c-a06a-e3ab7da48c67 |             0 | MANUAL           |  8589934592 | 2017-01-17 08:25:32 | NULL                | NULL           |     NULL |       NULL |         NULL | KVM             | 2.2     |  NULL |     NULL |     NULL |
| 729 |              1 |          2 |         1 |       607 |               18 | Creating  | NULL | DONTDELETEORYOUWILLBEFIRED_ROOT-523_20170823050255              | 83549abf-7bdd-4a75-bdaa-66c01426ab2d |             3 | HOURLY           | 53687091200 | 2017-08-23 05:02:55 | 2017-08-23 05:10:44 | NULL           |     NULL |       NULL |         NULL | KVM             | 2.2     |  NULL |     NULL |     NULL |
| 879 |              1 |          2 |         1 |       607 |               18 | BackingUp | NULL | DONTDELETEORYOUWILLBEFIRED_ROOT-523_20170828070114              | 0d6e4ef3-1275-4117-8721-cf35e6211de5 |             3 | HOURLY           | 53687091200 | 2017-08-28 07:01:14 | NULL                | NULL           |     NULL |       NULL |         NULL | KVM             | 2.2     |  NULL |     NULL |     NULL |
+-----+----------------+------------+-----------+-----------+------------------+-----------+------+-----------------------------------------------------------------+--------------------------------------+---------------+------------------+-------------+---------------------+---------------------+----------------+----------+------------+--------------+-----------------+---------+-------+----------+----------+

Обратите внимание, что в этот список могут попасть снимки, которые в текущий момент создаются, поэтому в реальных условиях в запрос необходимо добавить еще фильтрацию по полю created.

Изменим их состояние на “BackedUp”:

mysql> update snapshots set status = 'BackedUp' where id=879 or id=66;

Удаление

Теперь, после исправления статуса данные снимуки могут быть удалены через API.

Проверка освобождения данных

Убедимся, что на вторичном хранилище данные были успешно удалены (на примере снимка с Id=879):


mysql> select snapshot_id, url, store_role, install_path from snapshot_store_ref,image_store where image_store.id=store_id and snapshot_id=879 and store_role = 'Image';
+-------------+--------------------------------------+------------+-----------------+
| snapshot_id | url                                  | store_role | install_path    |
+-------------+--------------------------------------+------------+-----------------+
|         879 | nfs://192.168.3.218/export/secondary | Image      | snapshots/2/607 |
+-------------+--------------------------------------+------------+-----------------+
1 row in set (0.00 sec)

Далее, необходимо зайти на данный сервер хранилища и убедиться, что указанный путь не содержит файлов.

Причины возникновения проблемы

Проблема возникает в том случае, если в процессе создания снимка происходит нештатная ситуация, такая как:

  1. потеря сетевой связности;
  2. отказ сервера управления;
  3. превышение предельной производительности инфраструктуры.

Долгосрочное решение

Автоматизированный сценарий мониторинга, обнаружения и удаления подобных снимков в автоматическом режиме и информирование ITSM об их наличии.