Как лучше разделить хранилище на временно использование?
По вводным: есть необходимость поднимать копию n- сервисов для проведения серии тестов.
По вводным: сейчас используется следующая схема:
По вводным: 1) Резервная копия сервисов.
По вводным: 2) Восстановление сервисов на тестовую площадку.
По вводным: 3) Доп. Настройки среды и тестирование.
Сейчас ситуация такая: к сожалению мы не можем использовать:
-кластеризацию сервисов
-репликацию вм
По вводным: хотим рассмотреть возможность переноса сервисов на кластер СХД, на котором:
По вводным: - В режиме master располагается prod.
По вводным: - В режиме slave тестовая среда.
Со следующей схемой:
По вводным: 1) "Разрываем" репликацию СХД
По вводным: 2) Подключаем тестовую среду к slave
3) Проводим тесты
По вводным: 4) Отключаем тестовую среду
По вводным: 5) "Включаем" репликацию slave
Нужно понять: подскажите, какое решение вы могли бы предложить?
Опишите проблему, и специалист поможет с настройкой, исправлением ошибки или доработкой сайта. Подберём понятный план работ без лишней переписки.
Пока нет других ответов. Будьте первым, кто поможет автору.
Ответить на вопрос
Если нужно разделить хранилище под временное использование, сначала определите, что именно считается временным: кэш, scratch-диски, staging, бэкапы перед обработкой, временные файлы приложений или быстрый буфер для ETL. От этого зависит схема. Нельзя просто выделить «кусок RAID» без понимания нагрузки и риска потери данных.
Для временных данных обычно важны скорость и автоматическая очистка, а не максимальная надежность. Но если временные данные участвуют в долгой обработке, их потеря может означать повтор нескольких часов работы. Поэтому стоит разделить storage на уровни:
Практически я бы сделал отдельный раздел или отдельный dataset, чтобы временные файлы не могли забить основной том. Например, для Linux:
mkdir -p /srv/tmp-work mount /dev/vg0/tmpwork /srv/tmp-work chmod 1777 /srv/tmp-work
И добавил очистку по возрасту:
find /srv/tmp-work -type f -mtime +7 -delete find /srv/tmp-work -type d -empty -delete
Если используется ZFS, удобнее сделать отдельный dataset с quota:
zfs create pool/tmpwork zfs set quota=500G pool/tmpwork zfs set compression=lz4 pool/tmpwork
Главное правило: временное хранилище не должно влиять на основное. Отдельная точка монтирования, лимиты, мониторинг заполнения, понятная политика очистки и документация для приложений. Если данные действительно можно потерять, RAID0/один диск допустим. Если потеря приведет к простою, используйте зеркала или хотя бы быстрый восстановимый pipeline.