Изображение OpenStack удалено после создания

Вопрос или проблема

Я новичок в OpenStack. Я переношу сервер из OpenStack в VMware. Я создал образ/снимок с помощью:

openstack server image create --name Odoo_v12_ubuntu_v18Snapshot Odoo_v12_ubuntu_v18

затем, просматривая список образов, выполнил:

openstack image save --file snapshot.raw 4c7d3419-eb9e-4478-8621-19274bda4bd4

В логах появляется следующее:

2025-02-12 11:29:55.571 17478 INFO eventlet.wsgi.server [req-01e87185-938a-4669-adaa-a6e42ce5dcee 00b015e30c0a469bb73e26aaa2317b78 9fa635a08a6241efb01722aef0dd716a - - -] 192.168.151.60,192.168.151.51 - - [12/Feb/2025 11:29:55] "DELETE /v1/images/1d632087-f876-4700-aec5-4d874a31cfe7 HTTP/1.1" 200 200 0.886090

Что вызывает удаление образа?

Ответ или решение

Конечно, давайте подробно разберем вашу проблему, связанную с OpenStack, и поймем, почему созданное вами изображение было удалено.

Теория

OpenStack — это платформа, обеспечивающая облачные вычисления, которая включает в себя множество сервисов для управления инфраструктурой. В своей проблеме вы используете сервис Image (Glance), который отвечает за хранение и управление образами виртуальных машин. OpenStack управляет изображением с помощью операций создания, кэширования и удаления, и каждый из этих процессов записывается в логи.

Ваш случай подразумевает, что изображение после создания было удалено, что подтверждается записью в логе:

"DELETE /v1/images/1d632087-f876-4700-aec5-4d874a31cfe7 HTTP/1.1" 200

Пример

Вы упоминаете, что сначала сделали снимок сервера, используя команду:

openstack server image create --name Odoo_v12_ubuntu_v18Snapshot Odoo_v12_ubuntu_v18

Команда openstack server image create создает снимок текущего состояния виртуальной машины, который сохраняется в сервисе Glance, и ему присваивается уникальный идентификатор (ID).

Затем вы пытались сохранить образ локально:

openstack image save --file snapshot.raw 4c7d3419-eb9e-4478-8621-19274bda4bd4

На данном этапе ваша цель — сохранить образ на локальном диске в формате raw. Однако важно обратить внимание, что в логах фиксируется операция удаления:

DELETE /v1/images/1d632087-f876-4700-aec5-4d874a31cfe7

Применение

  1. Проверка прав доступа: Операции над изображениями требуют определенных прав доступа. Убедитесь, что вы обладаете достаточными привилегиями для работы с образами. Рекомендуется проверить роли и политики доступа в OpenStack (policy.json), чтобы удостовериться, что нет конфликтов.

  2. Анализ лога: Лог указывает на то, что команда удаления выполнена успешно (200 OK). Проверьте другие серверные логи, чтобы определить инициатора удаления. Это может быть системный процесс или же скрипт, запущенный вручную или по расписанию.

  3. Целостность команд: Убедитесь, что не было ошибки в командах. Например, служебный скрипт или автоматизированный процесс могли ошибочно удалить изображение.

  4. Состояние сервисов: Убедитесь, что сервисы Glance и Nova корректно работают и никакие сторонние процессы не мешают их функционированию. Проверьте конфигурацию конфига /etc/glance/glance-api.conf, чтобы понять, как организована политика управления изображениями.

  5. Изоляция проблемы: Создайте тестовое изображение на другом сервере в той же сети или той же конфигурации OpenStack, чтобы проверить, происходит ли аналогичная проблема. Это позволит локализовать проблему конкретно на данном сервере или конфигурации.

  6. Варианты резервного копирования: Рассмотрите возможность использования более надежного способа резервного копирования. Например, импортируйте образ напрямую в VMware через их инструменты, что может предотвратить необходимость хранения образа локально.

  7. Мониторинг и уведомления: Настройте системы мониторинга и уведомлений, чтобы в будущем получать оповещения о любых операциях удаления. Это позволит оперативно реагировать на нежелательные изменения.

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

Оцените материал
Добавить комментарий

Капча загружается...