Практикум по кластерному хранилищу

Хранилище кластера: общее, распределённое и отказ

Сравните общий доступ к дискам VM и распределённое размещение данных. Проверьте состав оборудования, области отказа, число копий и восстановление.

База → архитектура и приёмка40 минут4 модуля7 вопросов
После курса

Что вы сможете сделать

  1. Отделять общий доступ к данным от распределённого размещения копий.
  2. Проверять область отказа и полный путь к данным, а не только число узлов.
  3. Различать size, min_size и фактическую готовность сервиса после отказа.
Модуль 1 из 4

Начните с данных и отказа

Сначала определите данные и отказ, который система должна пережить.

  • Запишите рабочий объект: VM, база или файловый сервис. Затем задайте конкретный отказ — узел, сетевой путь, стойка или хранилище. Область отказа имеет смысл только относительно выбранного события.

  • Нарисуйте путь от вычислительного узла до данных. Для SAN учитывайте блочную сеть, для NAS — файловый сервис; название NAS или SAN не доказывает независимость контроллеров, коммутаторов и питания.

  • Для каждого набора данных выберите место хранения и способ доступа. Общий ресурс может быть распределённым; это не взаимоисключающие варианты. На одной площадке могут использоваться разные схемы.

  • Для выбранной схемы составьте ведомость серверов, CPU и RAM, накопителей, контроллеров, сетевых карт, коммутаторов и питания. Укажите полезную ёмкость, задержку и нагрузку до отказа и при восстановлении. Числа берут из проекта и измерений, не из названия модели хранения.

Модуль 2 из 4

Общее внешнее хранилище

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

  • Если образ диска VM уже доступен обоим узлам Proxmox на общем хранилище, при переносе VM копировать этот диск между узлами не требуется. Другие локальные диски и доступность самого хранилища проверяют отдельно.

  • NFS и iSCSI могут дать общий доступ. Серверы, массивы, коммутаторы и питание остаются частью отдельной архитектуры. Проверьте полный маршрут и независимость путей, а не только два адреса.

  • Кворум вычислительного кластера не определяет, какая копия прикладных данных актуальна и доступна. Управляющий голос и путь к данным проверяются отдельно.

  • Общие настройки хранилища не копируют данные локальных дисков. Параметр shared обозначает уже общий ресурс, а nodes ограничивает перечень узлов доступа. Убедитесь, что узлы обращаются к одному содержимому.

Модуль 3 из 4

Распределённое хранение Ceph

Распределение данных не заменяет проверку размещения и оставшихся копий.

  • В Proxmox RBD представлен как общее блочное хранилище; данные образа распределяет Ceph. NFS и iSCSI также могут дать общий доступ, но сами названия протоколов не описывают внутреннее размещение копий.

  • В реплицируемом пуле Ceph Squid size задаёт целевое число копий, а min_size — минимальный порог для операций. Выполнение порога не снимает других условий готовности хранилища.

  • CRUSH выбирает места по иерархии и заданной области отказа. Уровень host разделяет серверы, но не гарантирует разные стойки или питание. Сопоставьте карту с фактическим размещением копий.

Модуль 4 из 4

Отказ, измерение и восстановление

Испытание проверяет архитектуру в условиях конкретного отказа.

  • До теста сохраните исходное состояние: размещение данных, доступные пути, состояние кворума, size/min_size и целевую нагрузку. Без этого трудно отличить допустимую деградацию от скрытого отказа.

  • Инициируйте только согласованный отказ. Проверьте не зелёный статус узлов, а чтение и запись приложения, задержку и доступность данных. Репликация сама по себе не доказывает готовность сервиса.

  • После возврата компонента дождитесь восстановления всех требуемых копий и снова проверьте приложение. Свяжите в отчёте событие, уцелевший путь, измерение и восстановление.

Финишная прямая

Проверьте инженерное мышление

Вопросы проверяют не память на аббревиатуры, а умение не делать лишних выводов.

01На узлах Proxmox одинаковые записи локального хранилища. Администратор включил shared, но общий доступ к диску не настраивал. Что следует из этой отметки?
02Какое утверждение верно про NFS/iSCSI и Ceph RBD в контексте Proxmox VE?
03Что задаёт size у реплицируемого пула Ceph?
04В реплицируемом пуле Ceph число доступных копий стало меньше min_size. Параметры не меняли. Что означает этот результат?
05CRUSH настроен разносить реплики по уровню «host». Что ещё нужно проверить для защиты от отказа стойки?
06Два iSCSI-пути настроены на узле. Что подтверждает их независимость?
07Какой результат лучше всего подтверждает выбранную модель хранения после отказа?

Следующий шаг

Сформулируйте задачу и уточните требования к своей системе.

Подготовить состав проекта

Откроется черновик вопроса. Отправьте его, когда будете готовы.

Проверяемая база

Источники курса

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

  • Официальная документация

    Failover Clustering topologies

    Microsoft · Microsoft Learn для Windows Server 2016–2025, проверено 29 августа 2026 года

    Определяет fault domains и показывает границу single-rack HA, stretch cluster и multi-site DR.

    Открыть первоисточник
  • Официальная документация

    Security Guidelines for Storage Infrastructure

    National Institute of Standards and Technology · NIST SP 800-209, October 2020

    Разделяет backup, replication, immutability, continuous data protection и point-in-time copies; описывает synchronous и asynchronous replication.

    Открыть первоисточник
  • Официальная документация

    What Is a Storage Area Network

    SNIA · SNIA tutorial, 14 октября 2019 года

    Определяет SAN как специализированную сеть block-level доступа к storage.

    Открыть первоисточник
  • Официальная документация

    Network Attached Storage

    SNIA Technical Council · SNIA Online Dictionary, проверено 29 августа 2026 года

    Определяет NAS через networked file access services и приводит NFS/SMB.

    Открыть первоисточник
  • Официальная документация

    Configuring Device Mapper Multipath

    Red Hat · Red Hat Enterprise Linux 9, проверено 29 августа 2026 года

    Описывает aggregation одинаковых WWID в одно multipath device, path policies, failover и ALUA detection.

    Открыть первоисточник
  • Официальная документация

    Proxmox VE Storage — pvesm.adoc, source revision 937063811643

    Proxmox Server Solutions GmbH · pve-docs 9370638116430c4b1ccb9707b5716eaad7c7c9d3; исходная редакция, не установленный выпуск

    Прочитаны введение, Storage Types, Storage Configuration и Common Storage Properties: nodes/shared. Публичное зеркало Proxmox; недоступный PDF не выдаётся за прочитанный. Совместимость конкретных версий проверяется отдельно.

    Открыть первоисточник
  • Официальная документация

    Ceph Block Device

    Ceph Foundation · Ceph Squid documentation, branch squid

    Повторная сверка 20.09.2026. Проверены вводное описание RBD и способы доступа. Ветка squid, не фиксация отдельного patch-релиза; совместимость с Proxmox этим не установлена.

    Открыть первоисточник
  • Официальная документация

    Monitoring OSDs and PGs

    Ceph Foundation · Ceph Squid documentation, branch squid

    Повторная сверка 20.09.2026. Проверены Peering, Active, Clean, Degraded и условия восстановления. Не переносим состояние одной PG на готовность всего приложения.

    Открыть первоисточник
  • Официальная документация

    Failover Clustering in Windows Server and Azure Local

    Microsoft · Microsoft Learn, обновлено 25 июня 2025 года

    Описывает nodes, clustered roles, health monitoring, failover и quorum в failover cluster.

    Открыть первоисточник
  • Официальная документация

    Recovery Point Objective — CSRC Glossary

    National Institute of Standards and Technology · CSRC glossary по NIST SP 800-34 Rev. 1, проверено 29 августа 2026 года

    Определяет RPO как точку во времени, до которой данные должны быть восстановлены после outage.

    Открыть первоисточник
  • Официальная документация

    Pools

    Ceph Foundation · Ceph Squid documentation, branch squid

    Повторная сверка 20.09.2026. Проверены определения пула, size/min_size и Setting the Number of RADOS Object Replicas. Общая фраза введения про число переживаемых отказов не использована как универсальное правило.

    Открыть первоисточник
  • Официальная документация

    CRUSH Maps

    Ceph Foundation · Ceph Squid documentation, branch squid

    Повторная сверка 20.09.2026. Проверены CRUSH structure, Devices и Creating a rule for a replicated pool: root, host/rack, device class. Отказоустойчивость проверяется по реальной топологии.

    Открыть первоисточник
  • Официальная документация

    Contingency Planning Guide for Federal Information Systems

    National Institute of Standards and Technology · NIST SP 800-34 Rev. 1, update от 11 ноября 2010 года

    Первичный planning guide по BIA, recovery strategies, RPO/RTO, contingency и disaster recovery plans.

    Открыть первоисточник
Сообщить об ошибке

Опишите проблему — постараемся исправить как можно скорее.

Спасибо!

Получили ваше сообщение.
Подтвердите действие