Longhorn¶
Требования применяются к цели с capability longhorn, когда ей требуется
отказоустойчивое блочное хранилище внутри Kubernetes-кластера. Внешнее
управляемое HA-хранилище остаётся допустимой альтернативой.
Уровни обязательности определены в корневом README.md.
INF-LHN-001. Обоснованный выбор Longhorn¶
Уровень: MUST
Применяется к: capability longhorn
Manifest должен также объявлять persistent-data, если данные volume нельзя
восстановить из другого authoritative источника в пределах RTO по
INF-MAN-006. Владелец должен определить требуемые access mode, capacity,
latency/throughput, число реплик, отказные домены и поведение при degraded
volume. Для невоспроизводимых данных должны быть заданы RPO/RTO, для
воспроизводимых — источник и максимальное время полной реконструкции.
StorageClass нельзя выбирать только потому, что он является default.
Обоснование¶
Распределённое block storage добавляет репликацию и отказные режимы, которые должны соответствовать данным workload.
Проверка¶
- сопоставление PVC/StorageClass с требованиями приложения;
- сверка роли данных с capability
persistent-dataи recovery-контрактом; - нагрузочный и fault test.
Исключения¶
Не допускаются.
INF-LHN-002. Storage-узлы и диски¶
Уровень: MUST
Применяется к: production Longhorn
Данные реплик должны размещаться на стабильных явно выбранных disks/paths storage-узлов. Mount должен существовать до запуска Longhorn и не должен незаметно заменяться каталогом root filesystem после reboot. Системный диск узла не должен быть единственным storage path production-кластера. Scheduling на неподходящие узлы должен запрещаться labels/taints или настройками Longhorn.
Обоснование¶
Пропавший mount способен направить данные на root disk и исчерпать узел.
Проверка¶
- reboot каждого storage-узла;
- проверка mounts, Longhorn disks, scheduling и disk pressure;
- негативный test неподходящего узла.
Исключения¶
Выделенный data partition на том же физическом устройстве допустим для single-instance non-production, но не считается независимым отказным доменом.
INF-BCK-004. Longhorn для HA блочного хранилища¶
Уровень: MUST
Применяется к: persistent volume, которому требуется отказоустойчивое блочное хранение внутри Kubernetes-кластера
Такой volume должен использовать корпоративный Longhorn StorageClass. Количество реплик должно соответствовать числу независимых storage-узлов и быть не меньше трёх для production HA. Replica anti-affinity должна размещать реплики на разных подходящих узлах и, при наличии topology, в разных отказных доменах. Capacity reserve, minimal available percentage, over-provisioning, snapshot limits и условия degraded volume должны иметь явные платформенные значения и alerts.
Обоснование¶
Локальный том или совместное размещение реплик не переживает отказ узла.
Проверка¶
- запрос StorageClass, volume replicas и их topology;
- контролируемый отказ storage-узла с проверкой доступности данных;
- тест исчерпания capacity и degraded/rebuild состояния.
Исключения¶
При двух независимых storage-узлах допускаются две реплики с явно принятым риском. Внешнее HA-хранилище не обязано использовать Longhorn.
INF-LHN-003. Реплики и topology¶
Уровень: MUST
Применяется к: production Longhorn volume
StorageClass и volume должны реализовывать число реплик и anti-affinity из
INF-BCK-004. Новая реплика должна иметь достаточно свободного места для
полного rebuild. Soft anti-affinity не должна позволять заявлять устойчивость к
отказу узла, если реплики фактически совмещены.
Обоснование¶
Настроенное число реплик не доказывает их физическую независимость.
Проверка¶
- запрос фактического размещения replica;
- потеря узла, rebuild и повторный отказ после восстановления redundancy.
Исключения¶
Не допускаются для production high-availability.
INF-LHN-004. StorageClass и жизненный цикл volume¶
Уровень: MUST
Применяется к: Longhorn StorageClass
StorageClass должен явно задавать replica count, data locality, filesystem,
reclaim policy, expansion и binding mode. Delete reclaim policy для
защищаемых production-данных требует отдельного подтверждения удаления по
INF-DEC-001; иначе должна использоваться политика, сохраняющая данные до
управляемого удаления.
Обоснование¶
Значения default могут удалить volume вместе с ошибочно удалённым PVC.
Проверка¶
- review StorageClass/PV reclaim policy;
- удаление тестового PVC и восстановление;
- expansion test.
Исключения¶
Эфемерный воспроизводимый volume MAY использовать Delete.
INF-BCK-005. Longhorn backup не равен репликации¶
Уровень: MUST
Применяется к: production volume Longhorn
Для защищаемого volume должен выполняться Longhorn backup во внешнее S3-совместимое хранилище по расписанию, покрывающему RPO и retention. Snapshot или replica внутри того же кластера не должен считаться резервной копией для потери кластера. Для цепочки incremental backups должен быть определён периодический full backup либо другая проверка целостности backupstore.
Обоснование¶
Репликация обеспечивает доступность, но повторяет удаление и повреждение данных.
Проверка¶
- проверка backup target, расписания и последнего результата;
- восстановление volume в чистом кластере.
Исключения¶
Volume с доказуемо восстанавливаемым кэшем MAY не копироваться.
INF-LHN-005. Обслуживание и обновление¶
Уровень: MUST
Применяется к: production Longhorn
Drain или обновление storage-узла должно учитывать replica health, eviction policy и доступное место для rebuild. Одновременно нельзя выводить узлы, потеря которых превышает допустимое число replicas. Перед обновлением Longhorn должны проверяться совместимость Kubernetes, engine images, актуальный внешний backup и документированный rollback/roll-forward.
Обоснование¶
Плановое обслуживание способно последовательно удалить все здоровые replica.
Проверка¶
- rehearsal drain и rebuild;
- upgrade в non-production с volume attach/read/write;
- проверка backup и recovery action.
Исключения¶
Аварийная потеря узла следует incident runbook и не считается плановым drain.
INF-LHN-006. Наблюдаемость Longhorn¶
Уровень: MUST
Применяется к: production Longhorn
Alerts должны покрывать degraded/faulted volume, failed replica/rebuild, недоступный backup target, ошибки recurring job, disk pressure, reserved capacity, snapshot count/size и несовместимый engine image. Alert capacity должен оставлять место для rebuild самой крупной применимой replica.
Обоснование¶
Кластер без свободного места не может восстановить redundancy после отказа.
Проверка¶
- контролируемое degraded state и недоступный backup target;
- достижение warning capacity/snapshot threshold;
- проверка runbook.
Исключения¶
Не допускаются.