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

Версия	0.7
Дата	27.10.2026
Статус	P411 с 512 MB FBWC и firmware 6.64 перенесён в PCIe Slot 1 и работает как PCIe Gen2 x8. После переноса повторных IOCK/lockup в контрольном интервале и read/write-тестах не зафиксировано. D2700 firmware 0150, все 25 дисков OK, созданы MAIN-DATA, RECOVERY и CRITICAL-BACKUP, bay 15 подтверждён как shared spare. Установлен ssacli 6.60.8.0. Оба RAID50 имеют Parity Initialization Status: Queued; production Btrfs пока не создаётся.
Проект	Расширение памяти сервера

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'"

Production Btrfs и передача MAIN-DATA в VM выполняются после подтверждения стабильной работы P411 и завершения/нормального запуска parity initialization.

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

Файловый сервер работает отдельной VM Ubuntu Server 24.04.4 LTS. ОС и конфигурация находятся на внутреннем P410i, а production-данные после ввода D2700 должны находиться на logical drive внешнего P411.

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 и временного тестового MAIN-DATA. Production-данные файлового сервера размещаются на D2700/P411.

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. Временный тестовый MAIN-DATA до переключения на production D2700

Тестовый MAIN-DATA был создан до ввода P411/D2700 и остаётся безопасным стендом для проверки Btrfs/Snapper до переключения на production logical drive.

Внешний production MAIN-DATA на P411/D2700 уже создан как RAID50 объёмом 5.46 TiB, но на текущем checkpoint ещё не передан в VM 103. Поэтому тестовый 50 GiB диск пока сохраняется.

16.1. Тестовый диск

Устройство	`scsi1`
Storage	`local-lvm`
Размер	50 GiB
Bus	SCSI
I/O thread	включён
Discard	включён

В Ubuntu: /dev/sdb, 50 GiB.

16.2. Файловая система

Для MAIN-DATA выбран Btrfs из-за snapshots и будущей интеграции Windows «Предыдущие версии». Аппаратную отказоустойчивость обеспечивает P411 RAID50.

Btrfs RAID5/RAID6 поверх аппаратного RAID не используется. Для Btrfs production MAIN-DATA будет одним block device с профилем SINGLE.

16.3. Создание Btrfs на тестовом диске

wipefs -n /dev/sdb
mkfs.btrfs -L MAIN-DATA-TEST /dev/sdb
blkid /dev/sdb
lsblk -f /dev/sdb

LABEL=MAIN-DATA-TEST
UUID=55a6a6cb-fc81-4b89-afa6-1e4fd43b015c
TYPE=btrfs
Data profile: single
Metadata profile: DUP
System profile: DUP
Checksum: crc32c

16.4. Subvolume

mkdir -p /mnt/main-data-setup
mount /dev/sdb /mnt/main-data-setup
btrfs subvolume create /mnt/main-data-setup/shares
btrfs subvolume create /mnt/main-data-setup/clonezilla
btrfs subvolume list /mnt/main-data-setup
umount /mnt/main-data-setup
rmdir /mnt/main-data-setup

MAIN-DATA (Btrfs)
├── shares
└── clonezilla

16.5. Постоянная точка монтирования

mkdir -p /srv/main-data
cp -a /etc/fstab "/etc/fstab.backup-$(date +%F-%H%M%S)"

Тестовая строка /etc/fstab:

UUID=55a6a6cb-fc81-4b89-afa6-1e4fd43b015c /srv/main-data btrfs defaults,nofail,x-systemd.device-timeout=10s 0 0

Проверка:

systemctl daemon-reload
mount -av
findmnt /srv/main-data
df -hT /srv/main-data
btrfs filesystem show /srv/main-data
btrfs filesystem usage /srv/main-data
btrfs subvolume list /srv/main-data

После установки Samba/NFS сервисы должны зависеть от успешного mount /srv/main-data. Иначе при отсутствии D2700 возможна запись в каталог системной root FS.

17. Snapper и защита от случайного удаления

Snapshots обязательны для shares и clonezilla.

17.1. Конфигурации Snapper

snapper -c shares create-config /srv/main-data/shares
snapper -c clonezilla create-config /srv/main-data/clonezilla
snapper list-configs

Config     | Subvolume
-----------+--------------------------
clonezilla | /srv/main-data/clonezilla
shares     | /srv/main-data/shares

17.2. Целевая timeline-политика

Класс	Количество	Назначение
Hourly	72	около 3 суток детальной истории
Daily	30	около месяца
Weekly	12	около 3 месяцев
Monthly	12	около года
Yearly	0	отдельные годовые точки не используются

Важно: 72 hourly — целевое значение для обеих конфигураций. Ранее фактически использовались меньшие лимиты; перед production вводом необходимо ещё раз проверить текущее состояние через snapper get-config.

for cfg in shares clonezilla; do
    snapper -c "$cfg" set-config TIMELINE_CREATE=yes
    snapper -c "$cfg" set-config TIMELINE_CLEANUP=yes
    snapper -c "$cfg" set-config TIMELINE_LIMIT_HOURLY=72
    snapper -c "$cfg" set-config TIMELINE_LIMIT_DAILY=30
    snapper -c "$cfg" set-config TIMELINE_LIMIT_WEEKLY=12
    snapper -c "$cfg" set-config TIMELINE_LIMIT_MONTHLY=12
    snapper -c "$cfg" set-config TIMELINE_LIMIT_YEARLY=0
done

17.3. Systemd timers

systemctl enable --now snapper-timeline.timer
systemctl enable --now snapper-cleanup.timer
systemctl status snapper-timeline.timer --no-pager
systemctl status snapper-cleanup.timer --no-pager
systemctl list-timers 'snapper*'

17.4. Проверка восстановления файла

Для shares проверен сценарий: создать файл → snapshot → удалить файл → прочитать из .snapshots → восстановить обратно. Тест успешный.

17.5. Проверка Clonezilla

Аналогично проверен тестовый образ 32 MiB. После удаления он сохранился в snapshot и был восстановлен.

17.6. Ручной snapshot для особо важных образов

snapper -c clonezilla create \
  --description "GOLDEN - <имя машины / назначение / дата>"

Если cleanup algorithm не задан, такой snapshot не удаляется обычной timeline-ротацией.

Snapshot не является backup. Потеря всего MAIN-DATA приведёт к потере и текущих данных, и его snapshots. Критичные Clonezilla-образы дополнительно копируются на CRITICAL-BACKUP, а действительно критичные данные — ещё и за пределы D2700.

18. План интеграции Samba, NFS и Windows «Предыдущие версии»

/srv/main-data
├── shares
│   ├── Samba
│   ├── POSIX ACL
│   ├── vfs_recycle
│   └── vfs_snapper → Windows Previous Versions
│
└── clonezilla
    ├── NFS repository
    └── Snapper snapshots

Для Samba планируется vfs_snapper для Shadow Copies/«Предыдущих версий» и vfs_recycle как первый уровень защиты от случайного удаления.

Пользователи/группы, POSIX ACL, ALLOW_USERS/ALLOW_GROUPS Snapper и единая UID/GID-модель для SMB/NFS определяются перед вводом файловых сервисов.

19. Переход с тестового MAIN-DATA на production D2700

19.1. Аппаратная часть — выполнено

512 MB FBWC на P411	Установлен и исправен
Supercapacitor	Подключён, статус OK
P411 firmware	6.64
P411 PCIe	Slot 1, PCIe Gen2 5 GT/s ×8
Ошибка 1746	После установки FBWC отсутствует
IOCK / lockup	В прежнем Slot 5 воспроизводился; после переноса в Slot 1 в текущих тестах не повторяется
D2700	Обнаружена, firmware 0150, power supply status Redundant
Physical drives	25/25 обнаружены, текущий статус OK
Старые logical drive	Удалены
Production RAID	Созданы
GLOBAL-SPARE	Bay 15 подтверждён как shared spare
ssacli	6.60.8.0 установлен

19.2. Фактически определённые logical drive в Proxmox

Назначение	Устройство	Размер	Stable ID
`MAIN-DATA`	`/dev/sdb`	≈ 5.46 TiB	`/dev/disk/by-id/scsi-3600508b1001c2abf1f734aef851f07c9`
`RECOVERY`	`/dev/sdc`	≈ 136.7 GiB	`/dev/disk/by-id/scsi-3600508b1001c9c1cee21914d5576f5ac`
`CRITICAL-BACKUP`	`/dev/sdd`	≈ 3.64 TiB	`/dev/disk/by-id/scsi-3600508b1001c8f4dc714a9a5fe884d45`

Для передачи logical drive в VM использовать именно стабильный /dev/disk/by-id/..., а не /dev/sdX.

19.3. Контроль перед созданием production Btrfs

До форматирования необходимо выполнить:

ssacli ctrl slot=1 ld all show detail
ssacli ctrl slot=1 show config
dmesg -T | grep -iE 'IOCK|lockup|reset|offline|hpsa.*error|I/O error'
lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINTS
wipefs -n /dev/sdb
fdisk -l /dev/sdb

На /dev/sdb ранее отображалась остаточная запись sdb1 размером 1K. Перед созданием Btrfs её необходимо отдельно проверить и удалить только после подтверждения, что production logical drive выбран правильно.

19.4. Передача MAIN-DATA в VM 103

Дождаться приемлемого состояния parity initialization и подтвердить стабильность P411.
Использовать stable ID MAIN-DATA.
Передать logical drive в VM 103 отдельным block device.
Не создавать файловую систему MAIN-DATA на Proxmox.
Единственным владельцем production Btrfs должна быть Ubuntu VM.

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

Остановить Samba/NFS, если они к этому моменту установлены.
Сохранить нужные тестовые данные.
Размонтировать тестовый MAIN-DATA.
Проверить wipefs -n production logical drive.
Очистить остаточные partition/filesystem signatures после повторной проверки device ID.
Создать Btrfs на production MAIN-DATA.
Создать subvolume shares и clonezilla.
Получить production UUID.
Заменить тестовый UUID в /etc/fstab.
Смонтировать production volume в /srv/main-data.
Проверить/пересоздать Snapper-конфигурации.
Повторно проверить snapshot и restore.
Только после этого запускать файловые сервисы.

20. Текущая контрольная точка

Этап	Состояние
Дисковая архитектура D2700	Реализована
P410i	Slot 0 Embedded, 512 MB BBWC, firmware 6.64, Controller/Cache/Battery Status OK
P411	Slot 1, 512 MB FBWC, firmware 6.64, PCIe Gen2 ×8
P411 PCI address	`0000:08:00.0`
P411 Controller / Cache / Capacitor	OK / OK / OK
P411 cache ratio	25% Read / 75% Write
Неисправный 256 MB cache	`462974-001` исключён из эксплуатации
hpsa	Driver 3.4.20; диагностически включён `hpsa_simple_mode=1`
Старый Slot 5	При работе P411 воспроизводились `IOCK reason 61` и `controller lockup 0x12`
Новый Slot 1	После переноса P411 ошибки в текущем контрольном интервале и read/write-тестах не повторяются
D2700	Port 1E → Module A P1, Single Domain, enclosure OK
D2700 firmware	0150
I/O Module A / B	0150 / 0150
D2700 Power Supply	Redundant
Physical drives	25/25 обнаружены; current status OK
MAIN-DATA	Logical Drive 1, RAID50, 12 × 600 GB, 5.46 TiB, NPG 2, Strip 256 KiB, Status OK
RECOVERY	Logical Drive 2, RAID1, 2 × 146 GB, 136.70 GiB, Status OK
CRITICAL-BACKUP	Logical Drive 3, RAID50, 10 × 500 GB, 3.64 TiB, NPG 2, Strip 256 KiB, Status OK
GLOBAL-SPARE	Bay 15, 600 GB 10.5K, Status OK, подтверждён как `shared spare`
MAIN-DATA parity	`Queued`
CRITICAL-BACKUP parity	`Queued`
Read test MAIN-DATA	8 GiB direct read ≈ 1.3 GB/s, без ошибок
Read test CRITICAL-BACKUP	8 GiB direct read ≈ 611 MB/s, без ошибок
Write test	256 MiB direct write на каждом RAID50; после тестов dmesg чист по IOCK/lockup/reset/offline/I/O error
ssacli	6.60.8.0 установлен и используется для мониторинга
SAAP	Старый Demo License удалён; `No Keys Stored`
SPP G7.1	Рабочий USB создан штатным `usbcreator.cmd`
Память	5 DIMM на CPU A–E; рекомендуемый режим Advanced ECC
VM SMR-SRV-OT-SHARE	Создана, VM ID 103
Ubuntu	24.04.4 LTS, базовая подготовка выполнена
Тестовый MAIN-DATA	50 GiB, Btrfs, `/srv/main-data`
Snapper	Конфигурации и восстановление проверены на тестовом volume
Production MAIN-DATA в VM	Ещё не подключён
SMB/NFS	После переключения на production Btrfs

21. Следующие этапы реализации

Продолжить наблюдение P411 в Slot 1 и контролировать отсутствие IOCK, lockup, reset и offline.
Периодически проверять Parity Initialization Status обоих RAID50 через ssacli.
Не менять RAID-конфигурацию, пока logical drive имеют Status: OK и parity находится в штатном Queued/In Progress.
После подтверждения стабильности решить, оставлять ли hpsa_simple_mode=1 постоянно или отдельно протестировать Slot 1 в performant mode.
Перед production-разметкой проверить остаточную запись sdb1 через wipefs -n и fdisk -l.
Передать MAIN-DATA в VM 103 по стабильному /dev/disk/by-id/....
Создать production Btrfs и subvolume shares / clonezilla.
Переключить /srv/main-data с тестового 50 GiB volume на production MAIN-DATA.
Повторно проверить Snapper и восстановление файлов.
Проверить фактически применённый лимит 72 hourly в обеих Snapper-конфигурациях.
Спроектировать SMB-шары, локальные группы и POSIX ACL.
Настроить Samba + vfs_recycle + vfs_snapper.
Проверить Windows «Предыдущие версии».
Настроить NFS для Clonezilla только для разрешённых сетей/клиентов.
Привязать Samba/NFS к успешному mount /srv/main-data.
Настроить UFW после утверждения SMB/NFS/SSH правил.
Настроить CRITICAL-BACKUP и копирование выбранных критичных данных.
Добавить мониторинг P410i/P411, physical drive health, D2700 enclosure, Btrfs, snapshots, mount и сервисов.
Отдельно решить вопрос необходимости Dual Domain через второй порт P411 и I/O Module B.

21.1. Команды оперативного контроля P411

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

# Конфигурация P411
ssacli ctrl slot=1 show config
ssacli ctrl slot=1 show detail

# Logical drive и parity initialization
ssacli ctrl slot=1 ld all show detail

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

# Непрерывное наблюдение parity
watch -n 60 "ssacli ctrl slot=1 ld all show detail | grep -E 'Logical Drive:|Status:|Parity Initialization'"

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

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. Временный тестовый MAIN-DATA до переключения на production D2700

16.1. Тестовый диск

16.2. Файловая система

16.3. Создание Btrfs на тестовом диске

16.4. Subvolume

16.5. Постоянная точка монтирования

17. Snapper и защита от случайного удаления

17.1. Конфигурации Snapper

17.2. Целевая timeline-политика

17.3. Systemd timers

17.4. Проверка восстановления файла

17.5. Проверка Clonezilla

17.6. Ручной snapshot для особо важных образов

18. План интеграции Samba, NFS и Windows «Предыдущие версии»

19. Переход с тестового MAIN-DATA на production D2700

19.1. Аппаратная часть — выполнено

19.2. Фактически определённые logical drive в Proxmox

19.3. Контроль перед созданием production Btrfs

19.4. Передача MAIN-DATA в VM 103

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

20. Текущая контрольная точка

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`