3.5.2 · блок 3

Longhorn на практике: тома, реплики, снимки

Зачем это нужно

Longhorn — распределённое блочное хранилище для Kubernetes от Rancher/SUSE. На платформе MDP это типичный StorageClass для PVC: динамическое создание томов, репликация, UI для ops, snapshot/backup. Как ML-инженер вы не админите Longhorn каждый день, но должны понимать: как создаётся том, что происходит при падении node и как не «сломать» данные при удалении PVC.

Если вы привыкли к файлам на своём ноутбуке — представьте Longhorn как RAID-массив, размазанный по серверам кластера, с API для Kubernetes.

Основные идеи

Архитектура (упрощённо).

Longhorn Manager — control plane в namespace longhorn-system.
Engine — процесс на node, обслуживающий конкретный том (блочный I/O).
Replica — копия данных на другом node.
Instance Manager — управляет engine/replica на node.

Kubernetes видит только StorageClass → PV → mount в Pod. Внутренности Longhorn скрыты, пока всё healthy.

Dynamic provisioning. PVC с storageClassName: longhorn → Longhorn provisioner создаёт том нужного размера → биндится PV.


apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: training-checkpoints
  namespace: ml-train
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn
  resources:
    requests:
      storage: 50Gi

Number of Replicas. В StorageClass или аннотациях задаётся число реплик (часто 3). Больше реплик — выше отказоустойчивость, меньше — экономия диска.

Snapshots. Point-in-time снимок тома — быстрый способ «заморозить» состояние перед рискованным экспериментом или перед upgrade модели на inference PVC.

Backup. Snapshot можно отправить в S3/MinIO (backup target) — disaster recovery, если погиб весь кластер.

Reclaim policy. Delete — удаление PVC уничтожит том в Longhorn (осторожно в prod!). Retain — PV остаётся для ручного восстановления.

Node failure. Longhorn перестраивает реплику на живой node; Pod с RWO может перезапуститься и reattach. Время восстановления зависит от размера тома и сети — для больших checkpoint'ов закладывайте это в SLO.

Anti-pattern для ML. Один RWO том на Deployment с replicas: 3 — только одна реплика сможет смонтировать том. Для горизонтального масштабирования inference используйте object storage + локальный emptyDir или RWX с пониманием ограничений.

Как это выглядит на практике

Сценарий: checkpoint при обучении в Kubernetes Job.

1. Job монтирует PVC checkpoints (Longhorn 100Gi).

2. Python-код пишет checkpoint_epoch_10.pt каждые N шагов.

3. Node падает — Job retry, новый Pod на другой node, тот же PVC, обучение продолжается с последнего файла на диске.

4. По завершении Job артефакт копируется в MinIO (mc cp), PVC можно удалить или оставить для отладки.

Проверка состояния (read-only для студента):


kubectl get pvc -n ml-train
kubectl describe pvc training-checkpoints -n ml-train
# UI Longhorn (если доступен в MDP): Volume → Replicas → Health

Типичные проблемы.

| Симптом | Возможная причина |

|---------|-------------------|

| PVC Pending | Нет default StorageClass, нет свободного места на node |

| Pod ContainerCreating | Том ещё attaching, degraded replica |

| Медленный I/O | Перестройка реплик, сеть между node'ами |

Связь с Helm/Argo. Chart inference-сервиса включает PersistentVolumeClaim template с storageClassName из values — окружения dev/prod могут использовать разные классы или размеры.

Что сделать после занятия

[ ] Создайте PVC с StorageClass Longhorn (или аналог в учебном кластере) и смонтируйте в Pod; запишите файл, удалите Pod, убедитесь что данные на месте.
[ ] Объясните, почему три реплики Longhorn не заменяют backup в MinIO/S3.
[ ] Посмотрите reclaim policy вашего StorageClass и опишите риск при helm uninstall chart с PVC.

Официальные материалы

Открыть интерактивную версию