HP D2700: схема дисковых массивов и назначение хранилищ

Версия	0.9
Дата	27.10.2026
Статус	P411 с 512 MB FBWC и firmware 6.64 работает в PCIe Slot 1 как PCIe Gen2 x8. После переноса повторных IOCK/lockup не зафиксировано. D2700 firmware 0150, все 25 дисков OK, production RAID-массивы созданы, bay 15 подтверждён как shared spare. MAIN-DATA передан в VM 103 по стабильному /dev/disk/by-id, создан production Btrfs 5.46 TiB, выполнено переключение /srv/main-data и проверка после reboot. Создано единое дерево /srv/main-data/baltikashare, настроены Snapper, группы, POSIX ACL и универсальные файловые учётные записи. Samba/NFS ещё не введены в эксплуатацию. Оба RAID50 остаются Status: OK; Parity Initialization Status: Queued.
Проект	Расширение памяти сервера

1. Назначение документа

Документ фиксирует принятую архитектуру хранения на HP ProLiant DL380 G7: физическую раскладку дисков в HP StorageWorks D2700, аппаратные RAID-массивы, назначение logical drive, резервный диск, подготовку P410i/P411 и дальнейшую интеграцию хранилища с виртуальной машиной Ubuntu Server.

В рамках этой статьи проектируются и настраиваются основное файловое хранилище, SMB/NFS, репозиторий Clonezilla, Btrfs, Snapper, Windows «Предыдущие версии», ACL и локальное резервирование выбранных данных.

Массив RECOVERY здесь описывается только как часть общей дисковой архитектуры. TFTP/PXE, восстановление Cisco IOS/IOS XE, ROMMON и связанные процедуры должны быть вынесены в отдельную Wiki-статью.

Фактически реализованная схема D2700: два RAID 50, один RAID 1 и один общий online spare.

2. Состав оборудования

Сервер	HP ProLiant DL380 G7
Гипервизор	Proxmox VE 9.1.9
Внутренний RAID-контроллер	HP Smart Array P410i, 512 MB BBWC, firmware 6.64
Внешний RAID-контроллер	HP Smart Array P411, PCIe Slot 1, 512 MB FBWC, firmware 6.64
Cache P411	512 MB Flash Backed Write Cache + supercapacitor
Array Accelerator P411	Enabled; write-back cache активен
Внешняя дисковая полка	HP StorageWorks D2700, 2U, 25 × 2.5" SFF SAS
Firmware D2700	0150
I/O Module A	Firmware 0150
I/O Module B	Firmware 0150
Текущее подключение	P411 external port 1E → SFF-8088 → D2700 I/O Module A, port P1
Режим подключения	Single Domain
Внешний SAS-кабель	SFF-8088 ↔ SFF-8088, HP 407344-002 / 408766-001

Порт P1 I/O-модуля D2700 используется как host/input. Порт P2 предназначен для дальнейшего каскадирования полок.

Разъёмы MFG на I/O-модулях D2700 являются сервисными диагностическими интерфейсами и не являются Ethernet-портами управления.

Все 25 физических дисков D2700 успешно обнаруживаются P411. На момент формирования production-конфигурации состояния Failed, Predictive Failure, Media Failure и Hardware Error отсутствовали.

После диагностики ошибок IOCK reason 61 и controller lockup 0x12 P411 перенесён из прежнего PCIe Slot 5 в Slot 1. В Slot 1 контроллер согласовал штатный для P411 линк PCIe Gen2 5 GT/s ×8 без downgrade. Текущий PCI-адрес P411 в Linux: 0000:08:00.0.

3. Физическая раскладка дисков по отсекам D2700

Отсеки	Диски	Роль	Имя
1–12	12 × 600 GB SAS 10K	Основной RAID 50	`MAIN-DATA`
13–14	2 × 146 GB SAS 15K	Служебный RAID 1	`RECOVERY`
15	1 × 600 GB SAS 10K	Общий горячий резерв	`GLOBAL-SPARE`
16–25	10 × 500 GB SAS 7.2K	Резервный RAID 50	`CRITICAL-BACKUP`

3.1. Карта отсеков

HP D2700 — отсеки 01–25

01  600 GB  MAIN-DATA
02  600 GB  MAIN-DATA
03  600 GB  MAIN-DATA
04  600 GB  MAIN-DATA
05  600 GB  MAIN-DATA
06  600 GB  MAIN-DATA
07  600 GB  MAIN-DATA
08  600 GB  MAIN-DATA
09  600 GB  MAIN-DATA
10  600 GB  MAIN-DATA
11  600 GB  MAIN-DATA
12  600 GB  MAIN-DATA

13  146 GB  RECOVERY
14  146 GB  RECOVERY

15  600 GB  GLOBAL-SPARE

16  500 GB  CRITICAL-BACKUP
17  500 GB  CRITICAL-BACKUP
18  500 GB  CRITICAL-BACKUP
19  500 GB  CRITICAL-BACKUP
20  500 GB  CRITICAL-BACKUP
21  500 GB  CRITICAL-BACKUP
22  500 GB  CRITICAL-BACKUP
23  500 GB  CRITICAL-BACKUP
24  500 GB  CRITICAL-BACKUP
25  500 GB  CRITICAL-BACKUP

4. Фактически созданные массивы D2700

4.1. Основной массив `MAIN-DATA`

Logical Drive	Logical Drive 1
Отсеки	1–12
Состав	12 × 600 GB SAS 10K
RAID	RAID 50
Number of Parity Groups	2
Parity Group 1	Bays 1–6
Parity Group 2	Bays 7–12
Strip Size контроллера	256 KiB
Full Stripe Size	около 1.2 MiB на RAID5 parity group
Полезная ёмкость	5.46 TiB / 6.00 TB
Caching	Enabled
Назначение	SMB/NFS, рабочие данные, Clonezilla и другие активные данные

RAID50 состоит из двух RAID5 parity group по шесть дисков. В каждой группе пять дисков несут data strips, один strip в каждой полосе используется под parity.

При Strip Size = 256 KiB размер полной data-полосы одной RAID5-группы:

5 × 256 KiB = 1280 KiB ≈ 1.25 MiB

RAID50 выдерживает отказ одного диска в каждой RAID5-подгруппе. Два отказа в одной и той же RAID5-группе до окончания rebuild приводят к потере всего logical drive.

4.2. Служебный массив `RECOVERY`

Отсеки	13–14
Состав	2 × 146 GB SAS 15K
RAID	RAID 1
Полезная ёмкость	около 146 GB decimal / около 136 GiB
Caching	Enabled
Назначение	будущий TFTP/PXE/Cisco recovery

Полноразмерные образы рабочих станций Clonezilla на RECOVERY не размещаются: их основное место — MAIN-DATA.

4.3. Горячий резерв `GLOBAL-SPARE`

Отсек	15
Диск	600 GB SAS 10K
Роль	Online spare
Назначение	Общий резерв для production-массивов P411

Один online spare может быть назначен нескольким массивам одного Smart Array. После отказа активного диска контроллер автоматически задействует spare и начинает rebuild.

4.3.1. Что происходит после отказа диска

Smart Array фиксирует отказ физического диска.
Диск из отсека 15 временно становится участником пострадавшего массива.
Контроллер восстанавливает данные на spare.
После rebuild массив снова получает штатную отказоустойчивость, но свободного hot spare временно нет.

Штатное состояние:
массив + свободный GLOBAL-SPARE

Отказ диска:
массив в rebuild → данные строятся на GLOBAL-SPARE

После rebuild:
массив снова отказоустойчив,
но диск отсека 15 временно является рабочим участником массива

4.3.2. После установки нового диска в исходный отсек

Новый диск распознаётся как замена отказавшего.
Данные переносятся с активированного spare на новый диск.
Новый диск становится штатным участником массива.
Отсек 15 снова освобождается под общий online spare.

Copy-back не является secure erase. Полное обнуление spare для возврата его в резерв не требуется.

4.3.3. Требования к заменяющему диску

Интерфейс SAS.
Ёмкость не меньше отказавшего диска.
Корректное определение P411/D2700.
Предпочтительно совпадение модели, RPM и sector format.
Больший диск не увеличивает существующий массив автоматически.

Во время rebuild/copy-back не извлекать spare, новый диск и не отключать D2700 без необходимости.

4.4. Резервный массив `CRITICAL-BACKUP`

Отсеки	16–25
Состав	10 × 500 GB SAS 7.2K
RAID	RAID 50
Number of Parity Groups	2
Parity Group 1	Bays 16–20
Parity Group 2	Bays 21–25
Strip Size контроллера	256 KiB
Полезная ёмкость	около 4 TB decimal / около 3.64 TiB
Caching	Enabled
Назначение	локальные копии выбранных критичных данных

5. Логика использования массивов

MAIN-DATA
├── рабочие документы
├── SMB-шары
├── NFS-репозиторий
└── Clonezilla
        │
        └── выбранные критичные копии
                ↓
        CRITICAL-BACKUP

RECOVERY
└── отдельный проект TFTP/PXE/Cisco recovery

5.1. Основные правила

MAIN-DATA — основное рабочее хранилище.
CRITICAL-BACKUP — только отобранные локальные копии.
CRITICAL-BACKUP не публикуется как обычная пользовательская шара.
RECOVERY резервируется под отдельный TFTP/PXE-проект.
GLOBAL-SPARE не форматируется и не передаётся ОС.
RAID не заменяет резервное копирование.

CRITICAL-BACKUP не является независимым backup: оба массива находятся в одной D2700, зависят от одного P411, сервера и общей инфраструктуры питания. Для действительно критичных данных нужна дополнительная копия вне D2700.

6. Имена объектов

Объект	Имя	Статус
Основной RAID 50	`MAIN-DATA`	Создан
Служебный RAID 1	`RECOVERY`	Создан
Общий горячий резерв	`GLOBAL-SPARE`	Назначен
Резервный RAID 50	`CRITICAL-BACKUP`	Создан

7. Ввод Smart Array P411 и D2700 в эксплуатацию

7.1. Первичная проверка P411 и неисправный cache

Первоначально P411 комплектовался 256 MB cache-модулем HP SPS 462974-001.

С установленным 256 MB cache наблюдалось:

1783-Slot 6 Drive Array Controller Failure!
[Controller self-test failure]

В Linux одновременно фиксировалось:

hpsa ... board not ready, timed out

Отключение батареи не изменяло результат. Тот же 256 MB cache временно проверялся во встроенном P410i; с ним P410i также переставал нормально инициализироваться.

Вывод: cache 462974-001 признан неисправным и исключён из эксплуатации.

7.2. Работа P411 без cache

После удаления неисправного cache P411 успешно проходил POST:

HP Smart Array P411 Controller
(0MB, v1.06)
0 Logical Drives

1785-Drive Array Not Configured
No Drives Detected

Это подтвердило исправность самой платы P411 и позволило обновить firmware.

7.3. Cache и батарея встроенного P410i

Штатный cache встроенного P410i:

HP SPS 462975-001
512 MB BBWC

При диагностике использовалась несовместимая батарея более старого поколения:

HP Spare 398648-001
HP Part 381573-001
4.8 V Ni-MH

С ней P410i выдавал:

1748-Slot 0 Drive Array
Unsupported Array Accelerator Battery Attached

Array Accelerator is disabled.

Правильный battery pack для P410/P411: HP Spare 462976-001 / HP Part 460499-001.

После восстановления совместимой электроники battery pack P410i перестал выдавать ошибку 1748 и начал штатную зарядку:

1794-Slot 0 Drive Array - Array Accelerator Battery is charging.
The Array Accelerator Cache will be enabled once
The Battery has been charged.
No action is required.

Array Accelerator вручную включать не требуется: после достаточной зарядки контроллер разрешает write-back cache автоматически.

Ремонт/перепаковка старого Ni-MH battery pack является нештатной процедурой. Необходимо контролировать нагрев, отсутствие вздутия и статус батареи средствами Smart Array.

7.4. Обновление firmware P411 до 6.64

Использован Service Pack for ProLiant G7.1:

P04243_001_spp-g7.1-SPPG71.3.iso

7.4.1. Попытки Ventoy/Rufus

На старом Legacy BIOS Ventoy первоначально падал в grub>. После добавления ventoy.disk.img.xz Ventoy запускался, но SPP не мог смонтировать собственную файловую систему:

Failure to communicate with kernel device-mapper driver
Unable to mount the file system [cdrom]

Rufus также не дал стабильной рабочей загрузки SPP. В итоге использован штатный механизм HPE из самого ISO.

7.4.2. Создание USB штатным `usbcreator.cmd`

На 32 GB USB создан MBR и один Primary FAT32-раздел 10 GB, отмеченный Active. Остальное пространство оставлено неразмеченным.

diskpart
list disk
select disk X
clean
convert mbr
create partition primary size=10240
select partition 1
format fs=fat32 quick label=HPE_SPP
active
assign letter=G
exit

После монтирования ISO как D::

D:\usb\usbcreator.cmd D: G:

Скрипт копирует содержимое SPP, переносит boot-файлы в корень и запускает встроенный syslinux.exe.

7.4.3. Boot Order DL380 G7

Стабильная загрузка USB началась после установки USB Controller первым устройством в BIOS Boot Order. После сервисных работ порядок загрузки следует вернуть к системному logical drive Proxmox.

7.4.4. Результат

Installed Version: 1.06
Available Version: 6.64
Result: P411 firmware 6.64

7.5. Состояние остальных firmware по SPP G7.1

Компонент	Состояние
P410i	6.64
P411	6.64
System ROM DL380 G7	2015.08.16 — актуально для используемого SPP
iLO 3	1.88 — актуально для используемого SPP
HP NC382i	Bootcode 5.2.3 / iSCSI 7.4.2 / NCSI 2.0.12 — Already up-to-date
Внутренний EH0146FARWD	HPDD — Already up-to-date
Диски D2700	Доступные firmware updates применены перед созданием production-массивов

Компоненты со статусом Already up-to-date принудительно через Force не перепрошиваются.

7.6. Первый тест D2700 без cache P411

P411 external port 1E
        │
        │ SFF-8088
        ▼
D2700 I/O Module A
Port P1

При P411 с 0 MB cache POST показывал:

1746-Slot 6 Drive Array - Unsupported Storage Connection Detected
SAS connection via expander is not supported on this controller model.

Access to all storage has been disabled until the expander and connections
beyond it are detached or controller is upgraded.

После установки исправного 512 MB FBWC ошибка 1746 исчезла, что подтвердило работоспособность связки P411 + D2700 через SAS-expander.

7.7. Установка 512 MB FBWC на P411

На P411 установлен исправный 512 MB Flash Backed Write Cache с supercapacitor.

HP Smart Array P411
512 MB
Firmware 6.64

Диагностика подтвердила:

Flash Backed Cache Module Attached
Read Cache: 100 MiB
Write Cache: 300 MiB
Read/Write Ratio: 25% / 75%
Cache Disable Code: 0
Failed Batteries: 0
Array Accelerator: Enabled

7.8. Диагностика D2700 после установки FBWC

Product: HP D2700 SAS AJ941A
Enclosure Firmware: 0150
I/O Module A Firmware: 0150
I/O Module B Firmware: 0150
Bay Count: 25
Fan Status: OK
Temperature Status: OK
Alarm Count: 0
I/O Module Failure Map: 0

P411 успешно обнаружил все 25 физических дисков. На момент проверки все присутствующие диски имели рабочее состояние; критичных media/hardware/predictive ошибок в диагностике не обнаружено.

7.9. Старые RAID-метаданные и ошибки 1787/1784

При первом полноценном запуске P411 обнаружил два старых RAID1 logical drive, оставшихся от предыдущей конфигурации дисков.

1719 - A controller failure event occurred prior to this power-up
1787 - Operating in Interim Recovery (Degraded) Mode
1784 - Logical Drive Failure
Missing Port/Box 1: Bays 1,3,4

Диагностика показала, что ссылки Missing Port/Box относились к старой сохранённой RAID-конфигурации, а не к неисправности текущих bays 1, 3 и 4 D2700. Текущие диски присутствовали и определялись как operational.

После проверки оба старых logical drive удалены. Перед созданием новой конфигурации firmware дисков D2700 обновлены.

7.10. Smart Array Advanced Pack

На P411 обнаружен ранее установленный Smart Array Advanced Pack 1.0 Demo License:

Licensed Feature Status: Inactive
License Key Status: License Key Expired
License Key Type: Demo License
License Key Date Entered: 2011-01-26
License Key Version: 1
Key Created: 2010-04-01
Expiration: 60 days after installation

Просроченный demo-key не используется текущей production-конфигурацией. RAID50, RAID1, FBWC и Single Domain не требуют этой просроченной лицензии.

Возможность Dual Domain через второй внешний порт P411 и D2700 I/O Module B рассматривается отдельно:

P411 Port 1E ─────→ D2700 I/O Module A, P1
P411 Port 2E ─────→ D2700 I/O Module B, P1

До перехода на Dual Domain необходимо отдельно подтвердить поддержку установленных SAS-дисков как dual-port, статус необходимой SAAP-функциональности и выполнить failover-тест без production-нагрузки.

7.11. Ошибка 209 и режим Online Spare Memory

209-Invalid Online Spare Memory Configuration

На каждом процессоре установлено по 5 DIMM в порядке A, B, C, D, E. Для Advanced ECC такая конфигурация допустима, но для Online Spare каналы несимметричны:

Channel 1: A + D
Channel 2: B + E
Channel 3: C

Для текущей конфигурации рекомендуется использовать Advanced ECC. Если потребуется Online Spare Memory, необходимо привести конфигурацию каналов к поддерживаемой симметричной схеме.

7.12. Создание production-массивов

После удаления старых logical drive, проверки всех физических дисков и установки FBWC в HPE Smart Storage Administrator созданы новые production logical drive:

Bays 1–12
→ MAIN-DATA
→ RAID50
→ Number of Parity Groups: 2
→ Strip Size: 256 KiB
→ Maximum Size: 5.46 TiB / 6.00 TB
→ Caching: Enabled

Bays 13–14
→ RECOVERY
→ RAID1
→ Caching: Enabled

Bays 16–25
→ CRITICAL-BACKUP
→ RAID50
→ Number of Parity Groups: 2
→ Strip Size: 256 KiB
→ Caching: Enabled

Bay 15
→ GLOBAL-SPARE
→ Online Spare

7.13. Первоначальный статус Background Parity Initialization

После создания RAID50 Smart Array сообщил:

Background parity initialization is currently queued or in progress.

После перехода к Linux фактический статус уточняется через ssacli. На текущем checkpoint оба RAID50 имеют Parity Initialization Status: Queued, то есть инициализация parity ещё не завершена и в момент проверки не выполнялась.

7.14. Повторяющийся P411 controller lockup в прежнем PCIe Slot 5

После создания production logical drive Proxmox сначала успешно обнаруживал все три устройства P411:

MAIN-DATA        /dev/sdb  ≈ 5.5 TiB
RECOVERY         /dev/sdc  ≈ 136.7 GiB
CRITICAL-BACKUP  /dev/sdd  ≈ 3.6 TiB

Однако при размещении P411 в прежнем Slot 5 через короткое время воспроизводилась последовательность:

NMI: IOCK error (debug interrupt?) for reason 61
        ↓
hpsa: resetting logical ...
        ↓
Controller lockup detected: 0x00120020 / 0x00120025
Controller lockup detected during reset wait
        ↓
sdb / sdc / sdd → Device offlined
        ↓
DID_NO_CONNECT / I/O error

ADU также зафиксировал новые события Lockup Reason = 0x0012 во внутреннем error log P411. При этом после перезагрузки RAID, диски, D2700 и FBWC снова определялись как исправные.

На этом этапе массивы не удалялись и не пересоздавались: симптомы указывали не на повреждение RAID-конфигурации, а на проблему пути P411 ↔ host/PCIe.

7.15. Диагностический режим `hpsa_simple_mode`

Для исключения проблем performant mode драйвера hpsa в GRUB добавлен параметр:

hpsa.hpsa_simple_mode=1

После загрузки состояние подтверждено:

cat /sys/module/hpsa/parameters/hpsa_simple_mode
1

host2: simple
host3: simple

В simple mode проблема в прежнем Slot 5 повторилась, поэтому сам performant mode не считается первопричиной. Параметр временно сохранён на период дальнейшей проверки стабильности.

7.16. Перенос P411 в PCIe Slot 1

P411 переставлен в PCIe Slot 1. После загрузки:

08:00.0  Smart Array P411

LnkCap: Speed 5GT/s, Width x8
LnkSta: Speed 5GT/s, Width x8

Для сравнения встроенный P410i определяется на 05:00.0 и согласовывает Width x4 (downgraded). Работа системного P410i при этом остаётся штатной.

После переноса P411 в Slot 1 в течение контрольного периода более часа не зафиксированы:

IOCK
controller lockup
reset
offline
I/O error

На текущем checkpoint это сильный признак того, что прежние ошибки были связаны с PCIe path/слотом/riser, однако наблюдение продолжается.

7.17. Установка и использование `ssacli`

На Proxmox установлена утилита HPE Smart Storage Administrator CLI:

SSACLI Version: 6.60.8.0
SOULAPI Version: 6.60.8.0

Основные безопасные команды мониторинга:

ssacli ctrl all show status
ssacli ctrl slot=1 show detail
ssacli ctrl slot=1 show config
ssacli ctrl slot=1 show config detail
ssacli ctrl slot=1 ld all show detail
ssacli ctrl slot=1 array all show detail
ssacli ctrl slot=1 pd all show status

Текущий статус контроллеров:

P410i Slot 0:
Controller Status: OK
Cache Status: OK
Battery/Capacitor Status: OK

P411 Slot 1:
Controller Status: OK
Cache Status: OK
Battery/Capacitor Status: OK
Firmware: 6.64
Driver: hpsa 3.4.20
PCI Address: 0000:08:00.0
Cache Ratio: 25% Read / 75% Write
Cache Backup Power Source: Capacitors

7.18. Подтверждение shared spare

ssacli ctrl slot=1 show config подтверждает bay 15 как общий резервный диск:

physicaldrive 1E:1:15
600 GB SAS HDD
OK
shared spare

Сам диск:

Bay: 15
Drive Type: Spare Drive
Status: OK
Last Failure Reason: No failure
Model: HP EG0600FCVBK
Rotational Speed: 10500
Firmware Revision: HPD9

В array all show detail массивы A, B и C отображают Spare Type: dedicated; дерево конфигурации при этом явно маркирует bay 15 как shared spare.

7.19. Проверка logical drive и производительности пути

После переноса P411 в Slot 1 проведены диагностические read-only тесты без файловой системы:

MAIN-DATA /dev/sdb:
8 GiB direct read ≈ 1.3 GB/s

CRITICAL-BACKUP /dev/sdd:
8 GiB direct read ≈ 611 MB/s

Также выполнена небольшая тестовая запись нулей в заведомо пустые области новых logical drive:

MAIN-DATA:       256 MiB direct write ≈ 932 MB/s
CRITICAL-BACKUP: 256 MiB direct write ≈ 1.0 GB/s

После read/write-тестов dmesg оставался чистым по фильтру:

IOCK | lockup | reset | offline | hpsa.*error | I/O error

Эти результаты используются как проверка стабильности PCIe/SAS-пути, а не как официальный benchmark массива.

7.20. Текущий статус parity initialization

ssacli показывает:

Logical Drive 1 — MAIN-DATA
Status: OK
Parity Initialization Status: Queued

Logical Drive 2 — RECOVERY
Status: OK

Logical Drive 3 — CRITICAL-BACKUP
Status: OK
Parity Initialization Status: Queued

Чтение и небольшая тестовая запись не изменили статус: оба RAID50 остались Queued. На текущем этапе конфигурация не изменяется; контроллер оставлен работать без лишней нагрузки, а статус периодически проверяется:

watch -n 60 "ssacli ctrl slot=1 ld all show detail | grep -E 'Logical Drive:|Status:|Parity Initialization'"

Несмотря на сохраняющийся статус Parity Initialization Status: Queued, logical drive имеют Status: OK, P411 после переноса в Slot 1 стабилен, а прямые read/write-тесты не вызвали IOCK, lockup, reset, offline или I/O error. Поэтому после контрольного интервала принято решение не блокировать дальнейший ввод файлового сервера ожиданием изменения parity status. Production MAIN-DATA передан в VM 103 и введён в эксплуатацию; parity status продолжает контролироваться отдельно.

8. Развёртывание виртуальной машины файлового сервера

Файловый сервер работает отдельной VM Ubuntu Server 24.04.4 LTS. ОС и конфигурация находятся на внутреннем P410i, а production-данные размещены на logical drive MAIN-DATA внешнего P411/D2700, переданном напрямую в VM 103 по стабильному /dev/disk/by-id/....

8.1. Фактические параметры VM

Proxmox VE	9.1.9
VM ID	`103`
Имя VM	`SMR-SRV-OT-SHARE`
Hostname	`smr-srv-ot-share`
ОС	Ubuntu Server 24.04.4 LTS
CPU	4 vCPU, CPU type `host`
RAM	8 GiB
BIOS	SeaBIOS
Machine	i440fx
SCSI Controller	`VirtIO SCSI single`
Системный диск	`scsi0`, 100 GiB, local-lvm
Сетевые карты	7 × VirtIO

8.2. Внутреннее хранилище Proxmox

Контроллер	P410i
Firmware	6.64
Cache	512 MB BBWC
Физические диски	8 × 146 GB SAS
Скорость	7 × 10K RPM + 1 × 15K RPM
RAID	RAID 50, две RAID5-группы по 4 диска
Logical Drive	около 880.69 GB decimal / около 820.2 GiB в Linux
Hot spare	нет

Один 15K-диск среди семи 10K не является причиной для переделки исправного массива. Дополнительная скорость 15K в данном RAID практически не используется, однако менять исправный диск только ради одинакового RPM не требуется.

Внутренний P410i используется для Proxmox и системных дисков VM. Production-данные файлового сервера размещаются на D2700/P411; временный тестовый MAIN-DATA после успешного переключения production-хранилища отсоединён от VM.

9. Системный диск и файловая система ОС

Virtual Disk: 100 GiB
└── LVM
    └── / — ext4
        └── максимально доступный объём

Корневая файловая система — ext4.
Разметка — LVM.
LVM encryption не используется.
Отдельные /var, /home, /srv на системном диске не создаются.
Корень имеет около 95.9 GiB.

9.1. Контроль разметки

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
df -hT /
pvs
vgs
lvs

10. Сетевые интерфейсы Proxmox и Ubuntu

VM многосетевая, но не маршрутизирует трафик между OT-сегментами. На переходном этапе одновременно используются Legacy VLAN 1 и новые VLAN.

Proxmox	Ubuntu	MAC	Bridge	Сегмент	Адрес
`net0`	`ens18`	BC:24:11:5D:D9:D2	`vmbr0`	Временная сеть настройки	`192.168.1.229/24`
`net1`	`ens19`	BC:24:11:46:F2:89	`vmbr1`	Production management VLAN 2100	`10.44.100.229/24`
`net2`	`ens20`	BC:24:11:10:B7:F1	`vmbr3`	Розлив VLAN 2002	`172.16.68.229/23`
`net3`	`ens21`	BC:24:11:26:DB:1B	`vmbr4`	Пивопроизводство VLAN 2030	сейчас без IPv4; затем `172.16.66.229/23`
`net4`	`ens22`	BC:24:11:9C:F1:D6	`vmbr5`	Утилиты VLAN 2040	`172.16.70.229/23`
`net5`	`ens23`	BC:24:11:32:9F:50	`vmbr6`	Legacy OT VLAN 1	`10.255.0.229/16` + `172.16.66.229/23`
`net6`	`enp2s1`	BC:24:11:67:35:97	`vmbr7`	АСТУЭ VLAN 2006	`172.17.14.229/24`

Адрес 172.16.66.229 не должен одновременно присутствовать на ens23 и ens21. После миграции 172.16.66.0/23 в VLAN2030 адрес переносится с Legacy-интерфейса на ens21.

10.1. Фактические адреса

lo      UNKNOWN 127.0.0.1/8 ::1/128
ens18   UP 192.168.1.229/24
ens19   UP 10.44.100.229/24
ens20   UP 172.16.68.229/23
ens21   UP
ens22   UP 172.16.70.229/23
ens23   UP 10.255.0.229/16 172.16.66.229/23
enp2s1  UP 172.17.14.229/24

10.2. Default gateway и DNS

Пока default gateway — 192.168.1.1 через ens18. После вывода временной сети default route должен перейти на 10.44.100.1 через ens19.

DNS на OT-интерфейсах не используется; доступ к SMB/NFS/Clonezilla/SSH планируется по IP. Временный DNS 192.168.1.1 используется только через ens18.

10.3. Netplan и cloud-init

Рабочий файл: /etc/netplan/50-cloud-init.yaml, права 600.

/etc/cloud/cloud.cfg.d/99-disable-network-config.cfg

network: {config: disabled}

Проверка изменений:

sudo netplan generate
sudo netplan try
ip -br address
ip route
resolvectl status

10.4. Проверенная связность

10.255.0.229 → 10.255.0.53
172.16.66.229 → 172.16.66.53
172.16.68.229 → 172.16.68.53
172.16.70.229 → 172.16.70.53
172.17.14.229 → 172.17.14.53
10.44.100.229 → 10.44.100.1

11. Установка Ubuntu Server 24.04

11.1. Параметры установщика

Ubuntu Server 24.04.4 LTS.
OpenSSH Server установлен.
Docker/Featured Server Snaps при установке не устанавливались.
Временная сеть: 192.168.1.229/24, gateway/DNS 192.168.1.1.

11.2. Hostname

sudo hostnamectl set-hostname smr-srv-ot-share

В /etc/hosts:

127.0.1.1 smr-srv-ot-share

Подтверждено:

Static hostname: smr-srv-ot-share
Operating System: Ubuntu 24.04.4 LTS
Kernel: Linux 6.8.0-137-generic
Virtualization: kvm

12. Базовая подготовка Ubuntu

sudo apt install -y \
  ca-certificates curl nano openssl iputils-ping tcpdump arping \
  bash-completion lsof qemu-guest-agent systemd-timesyncd ufw \
  ethtool rsync acl attr

Для Btrfs/Snapper:

sudo apt install -y btrfs-progs snapper

Samba/NFS и UFW-правила вводятся только после полной проверки production storage.

13. QEMU Guest Agent

sudo systemctl enable --now qemu-guest-agent
systemctl status qemu-guest-agent --no-pager
ls -l /dev/virtio-ports/

Подтверждено active (running) и наличие /dev/virtio-ports/org.qemu.guest_agent.0.

14. Часовой пояс и синхронизация времени

sudo timedatectl set-timezone Europe/Samara
sudo timedatectl set-local-rtc 0
sudo timedatectl set-ntp true
timedatectl status

Time zone: Europe/Samara
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

15. Запрет маршрутизации между OT-сегментами

sudo tee /etc/sysctl.d/99-disable-forwarding.conf >/dev/null <<'EOF'
net.ipv4.ip_forward = 0
net.ipv6.conf.all.forwarding = 0
EOF

sudo sysctl --system

Проверка:

sysctl net.ipv4.ip_forward
sysctl net.ipv6.conf.all.forwarding

Оба значения должны быть 0. Для многосетевого сервера используется loose reverse path filtering: rp_filter=2.

16. Переключение VM 103 на production MAIN-DATA

После стабилизации P411 в PCIe Slot 1 production logical drive MAIN-DATA был передан в VM 103 / SMR-SRV-OT-SHARE как отдельное SCSI-устройство. Тестовый 50 GiB Btrfs-диск использовался только как промежуточный стенд и после проверки production-хранилища был отсоединён.

16.1. Проверка stable ID на Proxmox

Перед подключением проверено, что стабильный идентификатор MAIN-DATA указывает именно на logical drive P411:

readlink -f /dev/disk/by-id/scsi-3600508b1001c2abf1f734aef851f07c9

На момент подключения результат:

/dev/sdb

Имена /dev/sdX не считаются постоянными. Для конфигурации VM используется только /dev/disk/by-id/....

16.2. Подключение MAIN-DATA к VM

На момент подключения scsi1 был занят тестовым 50 GiB диском, поэтому production MAIN-DATA был добавлен как scsi2:

qm set 103 \
  -scsi2 /dev/disk/by-id/scsi-3600508b1001c2abf1f734aef851f07c9,cache=none,iothread=1,backup=0

Параметры:

cache=none — не добавлять лишний host page cache поверх аппаратного FBWC P411;
iothread=1 — отдельный I/O thread для диска;
backup=0 — не включать многотерабайтный data-volume в обычный vzdump VM.

16.3. Разметка production logical drive в Ubuntu

В Ubuntu production MAIN-DATA первоначально определился как /dev/sdc размером 5.46 TiB. Создана GPT и один раздел практически на весь logical drive:

sudo parted -s -a optimal /dev/sdc \
  mklabel gpt \
  mkpart primary 1MiB 100%

sudo partprobe /dev/sdc

Результат:

/dev/sdc1  5.5T  Linux filesystem
Disklabel type: gpt

16.4. Создание production Btrfs

sudo mkfs.btrfs -L MAIN-DATA /dev/sdc1
sudo blkid /dev/sdc1

Label	`MAIN-DATA`
UUID	`98e5188a-407c-4d4a-adc1-24d8c90afb32`
Размер	5.46 TiB
Data profile	`single`
Metadata profile	`DUP`
System profile	`DUP`
Checksum	`crc32c`

Btrfs видит один block device и использует профиль SINGLE для данных. Отказоустойчивость на уровне физических дисков обеспечивает аппаратный RAID50 P411; Btrfs RAID5/6 поверх него не используется.

16.5. Переключение постоянной точки монтирования

Production Btrfs временно проверялся через /mnt/main-data-new, после чего UUID в /etc/fstab был заменён с тестового на production:

UUID=98e5188a-407c-4d4a-adc1-24d8c90afb32 /srv/main-data btrfs defaults,nofail,x-systemd.device-timeout=10s 0 0

На текущем checkpoint в fstab не добавлен явный nodiscard. Btrfs монтируется с фактическим discard=async; вопрос явного отключения discard для аппаратного RAID на механических SAS-дисках оставлен отдельным пунктом оптимизации и не считается уже выполненной настройкой.

После systemctl daemon-reload и монтирования:

findmnt /srv/main-data
df -hT /srv/main-data

Production Btrfs подтвердился как 5.5 TiB на /srv/main-data.

16.6. Проверка после reboot и удаление тестового диска

После перезагрузки VM production Btrfs автоматически смонтировался по UUID, Snapper продолжил работу, а старый тестовый 50 GiB диск остался несмонтированным. После его отсоединения production-диск изменил Linux-имя с /dev/sdc на /dev/sdb, что не повлияло на /etc/fstab.

lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS

sdb        5.5T
└─sdb1     5.5T btrfs /srv/main-data

Фактический production Btrfs после переключения:

Label: 'MAIN-DATA'
uuid: 98e5188a-407c-4d4a-adc1-24d8c90afb32
devid 1 size 5.46TiB path /dev/sdb1

17. Логическая структура production MAIN-DATA

Вместо отдельного общего shares принято единое дерево baltikashare. Корневой каталог является контейнером, а каждый функциональный ресурс — отдельным Btrfs subvolume.

/srv/main-data
└── baltikashare
    ├── clonezilla
    ├── exchange
    ├── pivoproduction
    ├── rozliv
    ├── utilities
    ├── software
    ├── documentation
    └── ot-admin

17.1. Назначение ресурсов

Ресурс	Назначение	Основной предполагаемый протокол
`clonezilla`	Образы рабочих станций и технологических ПК	NFS + административный SMB
`exchange`	Общий обмен файлами между инженерами	SMB
`pivoproduction`	Рабочие данные пивопроизводства	SMB; NFS при необходимости
`rozliv`	Рабочие данные розлива	SMB; NFS при необходимости
`utilities`	Инженерные/энергетические системы	SMB; NFS при необходимости
`software`	Дистрибутивы, утилиты, драйверы, firmware	SMB
`documentation`	Инструкции, схемы, ТЗ, паспорта, документация	SMB
`ot-admin`	Служебные OT-конфигурации и административные материалы	SMB только для admins

17.2. Создание subvolume

sudo mkdir -p /srv/main-data/baltikashare

sudo btrfs subvolume create /srv/main-data/baltikashare/clonezilla
sudo btrfs subvolume create /srv/main-data/baltikashare/exchange
sudo btrfs subvolume create /srv/main-data/baltikashare/pivoproduction
sudo btrfs subvolume create /srv/main-data/baltikashare/rozliv
sudo btrfs subvolume create /srv/main-data/baltikashare/utilities
sudo btrfs subvolume create /srv/main-data/baltikashare/software
sudo btrfs subvolume create /srv/main-data/baltikashare/documentation
sudo btrfs subvolume create /srv/main-data/baltikashare/ot-admin

Корневой /srv/main-data/baltikashare остаётся обычным каталогом. Сетевые права задаются на дочерних subvolume.

18. Snapper на production MAIN-DATA

Для каждого функционального subvolume создана отдельная конфигурация Snapper. Это позволяет задавать различную глубину хранения snapshots по назначению данных.

18.1. Конфигурации

clonezilla     → /srv/main-data/baltikashare/clonezilla
exchange       → /srv/main-data/baltikashare/exchange
pivoproduction → /srv/main-data/baltikashare/pivoproduction
rozliv         → /srv/main-data/baltikashare/rozliv
utilities      → /srv/main-data/baltikashare/utilities
software       → /srv/main-data/baltikashare/software
documentation  → /srv/main-data/baltikashare/documentation
ot-admin       → /srv/main-data/baltikashare/ot-admin

Во всех конфигурациях:

BACKGROUND_COMPARISON=no
TIMELINE_CREATE=yes
TIMELINE_CLEANUP=yes
TIMELINE_MIN_AGE=1800

BACKGROUND_COMPARISON=no уменьшает лишний фоновый I/O на файловом сервере: для текущего сценария не требуется постоянное вычисление diff между snapshot.

18.2. Политики хранения

Ресурс	Hourly	Daily	Weekly	Monthly	Yearly
`clonezilla`	24	30	12	12	1
`exchange`	24	7	2	0	0
`pivoproduction`	72	30	12	12	0
`rozliv`	72	30	12	12	0
`utilities`	72	30	12	12	0
`software`	0	14	8	6	0
`documentation`	72	60	26	24	3
`ot-admin`	72	90	26	24	5

Для exchange история намеренно короткая. Для documentation и ot-admin хранится более длинная история. Для больших Clonezilla-образов необходимо дополнительно контролировать фактическое Btrfs space usage: удалённый образ продолжает занимать блоки, пока существует snapshot, ссылающийся на эти данные.

18.3. Служебные .snapshots

Snapper автоматически создал отдельный Btrfs subvolume .snapshots внутри каждого ресурса:

baltikashare/clonezilla/.snapshots
baltikashare/exchange/.snapshots
baltikashare/pivoproduction/.snapshots
baltikashare/rozliv/.snapshots
baltikashare/utilities/.snapshots
baltikashare/software/.snapshots
baltikashare/documentation/.snapshots
baltikashare/ot-admin/.snapshots

18.4. Systemd timers

sudo systemctl start snapper-timeline.timer
sudo systemctl start snapper-cleanup.timer

systemctl is-active snapper-timeline.timer snapper-cleanup.timer

Текущий результат:

active
active

19. Модель доступа: группы, ACL и универсальные учётные записи

Принят единый принцип: пользователю не выдаются прямые ACL. Доступ определяется членством в Linux-группах, а POSIX ACL являются базовым источником прав для будущих SMB и NFS.

19.1. Группы доступа

Группа	Назначение
`admins`	Полный административный доступ ко всем ресурсам
`engineers`	Общий инженерный профиль: exchange RW, software RO, documentation RO
`clonezilla-rw`	Запись в Clonezilla repository
`pivoproduction-rw`	RW в pivoproduction
`rozliv-rw`	RW в rozliv
`utilities-rw`	RW в utilities
`software-rw`	RW в software
`documentation-rw`	RW в documentation

Ранее созданная группа exchange-rw удалена как избыточная: роль общего RW-доступа к exchange выполняет engineers.

19.2. Матрица прав

Ресурс	admins	engineers	Специализированная группа
`clonezilla`	RW	—	`clonezilla-rw` → RW
`exchange`	RW	RW	не требуется
`pivoproduction`	RW	—	`pivoproduction-rw` → RW
`rozliv`	RW	—	`rozliv-rw` → RW
`utilities`	RW	—	`utilities-rw` → RW
`software`	RW	RO	`software-rw` → RW
`documentation`	RW	RO	`documentation-rw` → RW
`ot-admin`	RW	—	только `admins`

19.3. Владельцы и SGID

Subvolume принадлежат root, основной группой является соответствующая ресурсная группа. На каталогах установлен SGID (2770), чтобы новые объекты наследовали группу родительского каталога.

clonezilla      root:clonezilla-rw
exchange        root:engineers
pivoproduction  root:pivoproduction-rw
rozliv          root:rozliv-rw
utilities       root:utilities-rw
software        root:software-rw
documentation   root:documentation-rw
ot-admin        root:admins

19.4. POSIX ACL

Для обычного специализированного ресурса, например pivoproduction:

user::rwx
group::rwx
group:admins:rwx
mask::rwx
other::---

default:user::rwx
default:group::rwx
default:group:admins:rwx
default:mask::rwx
default:other::---

Для software и documentation дополнительно:

group:engineers:r-x
default:group:engineers:r-x

Для exchange основной группой является engineers, поэтому group::rwx уже означает RW для всех инженеров.

Для ot-admin основной группой является admins; other::--- закрывает доступ всем остальным. Default ACL настроен и для этого ресурса.

19.5. Универсальные файловые учётные записи

До создания персональных пользователей заведены универсальные локальные учётные записи для тестирования и базового доступа. Они созданы без home-каталогов и с shell /usr/sbin/nologin.

Учётная запись	Группа доступа	Назначение
`baltikashare`	`admins`	администратор файлового сервера
`engineer`	`engineers`	общий инженерный профиль
`clonezilla`	`clonezilla-rw`	Clonezilla / NFS / тест repository
`pivo`	`pivoproduction-rw`	пивопроизводство
`rozliv`	`rozliv-rw`	розлив
`utilities`	`utilities-rw`	инженерные системы
`software`	`software-rw`	управление software repository
`documents`	`documentation-rw`	редактирование документации

sudo useradd -M -s /usr/sbin/nologin engineer
sudo useradd -M -s /usr/sbin/nologin clonezilla
sudo useradd -M -s /usr/sbin/nologin pivo
sudo useradd -M -s /usr/sbin/nologin rozliv
sudo useradd -M -s /usr/sbin/nologin utilities
sudo useradd -M -s /usr/sbin/nologin software
sudo useradd -M -s /usr/sbin/nologin documents

При создании через useradd система также создала для этих учётных записей отдельные private primary groups с одноимёнными именами. Они не используются как группы доступа к данным. Фактические права на файловые ресурсы выдаются через дополнительные группы engineers и *-rw.

Персональные учётные записи в дальнейшем должны использовать ту же модель: пользователь добавляется в engineers и/или специализированные ресурсные группы без изменения ACL самого каталога.

19.6. Проверка ACL до установки Samba

Перед вводом SMB права рекомендуется проверить на чистом Linux-уровне. Это отделяет ошибки POSIX ACL от будущей конфигурации Samba.

# engineer: exchange должен быть RW
sudo -u engineer touch /srv/main-data/baltikashare/exchange/.acl-test
sudo -u engineer rm /srv/main-data/baltikashare/exchange/.acl-test

# engineer: software/documentation должны читаться, но запись должна завершаться Permission denied
sudo -u engineer ls /srv/main-data/baltikashare/software
sudo -u engineer touch /srv/main-data/baltikashare/software/.acl-test

sudo -u engineer ls /srv/main-data/baltikashare/documentation
sudo -u engineer touch /srv/main-data/baltikashare/documentation/.acl-test

# профильный пользователь должен иметь RW в своём ресурсе
sudo -u rozliv touch /srv/main-data/baltikashare/rozliv/.acl-test
sudo -u rozliv rm /srv/main-data/baltikashare/rozliv/.acl-test

# и не должен иметь доступа к чужому production-ресурсу
sudo -u rozliv ls /srv/main-data/baltikashare/pivoproduction

Ожидаемый результат: разрешённые операции выполняются успешно, запрещённые возвращают Permission denied. После этой проверки Samba будет работать поверх уже подтверждённой Linux-модели прав.

20. Концепция SMB и NFS

Физические данные едины, а SMB и NFS являются только различными способами публикации тех же Btrfs subvolume. Не требуется создавать отдельные каталоги под SMB и NFS.

20.1. SMB

Планируется публиковать функциональные ресурсы отдельными share, а не открывать весь корень baltikashare одной общей шарой:

\\smr-srv-ot-share\exchange
\\smr-srv-ot-share\pivoproduction
\\smr-srv-ot-share\rozliv
\\smr-srv-ot-share\utilities
\\smr-srv-ot-share\software
\\smr-srv-ot-share\documentation
\\smr-srv-ot-share\ot-admin
\\smr-srv-ot-share\clonezilla   # при необходимости для admins

На уровне Samba планируется использовать access-based enumeration, чтобы пользователь Windows видел только доступные ему shares. Для защиты от случайного удаления планируются vfs_recycle и vfs_snapper / Windows «Предыдущие версии».

20.2. NFS

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

clonezilla — NFS требуется сразу;
производственные и общие ресурсы — NFS только при необходимости конкретного Linux/OT-клиента;
ot-admin — по умолчанию NFS не публикуется.

Для NFS необходимо отдельно учитывать UID/GID. Для Clonezilla предпочтительно использовать выделенную сервисную учётную запись clonezilla и root squashing вместо широкого no_root_squash.

20.3. Корневой каталог baltikashare

Сам факт существования ресурсов не считается секретом. Корень /srv/main-data/baltikashare можно оставить читаемым на уровне Linux, а реальный доступ защищается POSIX ACL дочерних subvolume. Фильтрацию видимых сетевых ресурсов целесообразно выполнять на уровне Samba.

21. Текущая контрольная точка и следующие этапы

21.1. Текущий статус

Этап	Состояние
P411	Slot 1, firmware 6.64, 512 MB FBWC, PCIe Gen2 x8, Controller/Cache/Capacitor OK
D2700	Firmware 0150, enclosure OK, power supply Redundant, 25/25 дисков OK
MAIN-DATA	RAID50, Status OK, 5.46 TiB, передан в VM 103
RECOVERY	RAID1, Status OK, 136.70 GiB
CRITICAL-BACKUP	RAID50, Status OK, 3.64 TiB
GLOBAL-SPARE	Bay 15, 600 GB, shared spare, Status OK
Parity MAIN-DATA	`Queued`; эксплуатацию не блокирует, состояние контролируется
Parity CRITICAL-BACKUP	`Queued`; эксплуатацию не блокирует, состояние контролируется
Старые IOCK/lockup	После переноса P411 в Slot 1 не повторяются; текущий dmesg чист
Production Btrfs	LABEL MAIN-DATA, UUID `98e5188a-407c-4d4a-adc1-24d8c90afb32`, mount `/srv/main-data`
Проверка reboot	успешна; mount по UUID работает независимо от /dev/sdX
Старый тестовый диск 50 GiB	отсоединён от VM после проверки production storage
Структура данных	8 отдельных Btrfs subvolume под `/srv/main-data/baltikashare`
Snapper	8 конфигураций, индивидуальные retention-политики, timers active
Группы	admins, engineers и ресурсные *-rw созданы
POSIX ACL	настроены, SGID и default ACL применены
Универсальные учётки	созданы: engineer, clonezilla, pivo, rozliv, utilities, software, documents
Samba	ещё не установлен/не настроен
NFS	проектируется; первым ресурсом будет clonezilla

21.2. Оперативный контроль P411

# Общий статус контроллеров
ssacli ctrl all show status

# Logical drive и parity initialization
ssacli ctrl slot=1 ld all show detail | \
grep -E 'Logical Drive:|Status:|Parity Initialization'

# Physical drive
ssacli ctrl slot=1 pd all show status

# Контроль прежней ошибки
dmesg -T | grep -iE 'IOCK|lockup|reset|offline|hpsa.*error|I/O error'

Нормальный текущий результат: все logical drive имеют Status: OK, а фильтр dmesg не возвращает строк.

21.3. Следующие этапы

Проверить POSIX ACL универсальными учётными записями непосредственно в Linux: RW для своих ресурсов, RO для engineer на software/documentation и отсутствие доступа к чужим production-каталогам.
Установить Samba и samba-vfs-modules.
Создать Samba-пароли для универсальных и далее персональных пользователей.
Опубликовать функциональные SMB shares поверх уже настроенных POSIX ACL.
Включить access-based enumeration, чтобы пользователи видели только доступные сетевые ресурсы.
Настроить vfs_recycle и vfs_snapper.
Проверить Windows «Предыдущие версии».
Настроить NFS для clonezilla с ограничением разрешённых клиентов/сетей и корректной UID/GID-моделью.
Привязать Samba/NFS к успешному mount /srv/main-data, чтобы сервисы не писали в root FS при отсутствии D2700.
После стабилизации SMB/NFS настроить UFW.
Настроить использование CRITICAL-BACKUP для выбранных критичных копий.
Добавить мониторинг P410i/P411, D2700, physical drive health, Btrfs usage, Snapper, mount и файловых сервисов.
Отдельно решить, оставлять ли hpsa_simple_mode=1 постоянно или протестировать Slot 1 в performant mode.
Отдельно решить необходимость Dual Domain через второй порт P411 и I/O Module B.

22. Порядок включения и выключения D2700

22.1. Штатное включение

Подать питание на оба блока питания D2700.
Включить D2700 и дождаться завершения инициализации.
Включить DL380 G7.
Проверить POST P411 и доступность enclosure/logical drive.

D2700 ON
   ↓
инициализация полки
   ↓
DL380 G7 ON
   ↓
P411 обнаруживает готовое storage

22.2. Штатное выключение

Корректно остановить VM.
Корректно остановить Proxmox/DL380.
Дождаться полного выключения сервера.
Перевести D2700 в Standby.
При необходимости снять AC с блоков питания полки.

22.3. Автоматический запуск после восстановления питания

Поведение D2700 после полного снятия и возврата AC необходимо отдельно проверить в рабочей конфигурации. Желаемая последовательность:

AC восстановлено
        ↓
D2700 запускается
        ↓
полка проходит инициализацию
        ↓
DL380 G7 запускается с задержкой
        ↓
P411 обнаруживает готовые logical drive

На DL380 G7 целесообразно настроить автоматический запуск с задержкой, чтобы D2700 успевала инициализироваться раньше хоста.

HP D2700: схема дисковых массивов и назначение хранилищ

HP D2700: схема дисковых массивов и назначение хранилищ

1. Назначение документа

2. Состав оборудования

3. Физическая раскладка дисков по отсекам D2700

3.1. Карта отсеков

4. Фактически созданные массивы D2700

4.1. Основной массив MAIN-DATA

4.2. Служебный массив RECOVERY

4.3. Горячий резерв GLOBAL-SPARE

4.3.1. Что происходит после отказа диска

4.3.2. После установки нового диска в исходный отсек

4.3.3. Требования к заменяющему диску

4.4. Резервный массив CRITICAL-BACKUP

5. Логика использования массивов

5.1. Основные правила

6. Имена объектов

7. Ввод Smart Array P411 и D2700 в эксплуатацию

7.1. Первичная проверка P411 и неисправный cache

7.2. Работа P411 без cache

7.3. Cache и батарея встроенного P410i

7.4. Обновление firmware P411 до 6.64

7.4.1. Попытки Ventoy/Rufus

7.4.2. Создание USB штатным usbcreator.cmd

7.4.3. Boot Order DL380 G7

7.4.4. Результат

7.5. Состояние остальных firmware по SPP G7.1

7.6. Первый тест D2700 без cache P411

7.7. Установка 512 MB FBWC на P411

7.8. Диагностика D2700 после установки FBWC

7.9. Старые RAID-метаданные и ошибки 1787/1784

7.10. Smart Array Advanced Pack

7.11. Ошибка 209 и режим Online Spare Memory

7.12. Создание production-массивов

7.13. Первоначальный статус Background Parity Initialization

7.14. Повторяющийся P411 controller lockup в прежнем PCIe Slot 5

7.15. Диагностический режим hpsa_simple_mode

7.16. Перенос P411 в PCIe Slot 1

7.17. Установка и использование ssacli

7.18. Подтверждение shared spare

7.19. Проверка logical drive и производительности пути

7.20. Текущий статус parity initialization

8. Развёртывание виртуальной машины файлового сервера

8.1. Фактические параметры VM

8.2. Внутреннее хранилище Proxmox

9. Системный диск и файловая система ОС

9.1. Контроль разметки

10. Сетевые интерфейсы Proxmox и Ubuntu

10.1. Фактические адреса

10.2. Default gateway и DNS

10.3. Netplan и cloud-init

10.4. Проверенная связность

11. Установка Ubuntu Server 24.04

11.1. Параметры установщика

11.2. Hostname

12. Базовая подготовка Ubuntu

13. QEMU Guest Agent

14. Часовой пояс и синхронизация времени

15. Запрет маршрутизации между OT-сегментами

16. Переключение VM 103 на production MAIN-DATA

16.1. Проверка stable ID на Proxmox

16.2. Подключение MAIN-DATA к VM

16.3. Разметка production logical drive в Ubuntu

16.4. Создание production Btrfs

16.5. Переключение постоянной точки монтирования

16.6. Проверка после reboot и удаление тестового диска

17. Логическая структура production MAIN-DATA

17.1. Назначение ресурсов

17.2. Создание subvolume

18. Snapper на production MAIN-DATA

18.1. Конфигурации

18.2. Политики хранения

18.3. Служебные .snapshots

18.4. Systemd timers

19. Модель доступа: группы, ACL и универсальные учётные записи

19.1. Группы доступа

19.2. Матрица прав

19.3. Владельцы и SGID

19.4. POSIX ACL

19.5. Универсальные файловые учётные записи

4.1. Основной массив `MAIN-DATA`

4.2. Служебный массив `RECOVERY`

4.3. Горячий резерв `GLOBAL-SPARE`

4.4. Резервный массив `CRITICAL-BACKUP`

7.4.2. Создание USB штатным `usbcreator.cmd`

7.15. Диагностический режим `hpsa_simple_mode`

7.17. Установка и использование `ssacli`