True System

Linux на программном RAID-1

2022-04-08T16:20:00.006+03:00

Продолжаем сериал с установкой ОС на программное зеркало. Установка и настройка Linux будет приведена на примере Ubuntu 20.04 с GRUB в качестве загрузчика Для подавляющего большинства других актуальных дистрибутивов схема остаётся аналогичной.

Концепция та же, что и для Windows: отдельные разделы ESP, зеркалируются разделы под систему. Но обслуживать систему гораздо проще. Нет двух загрузочных пунктов, конфигурации GRUB и в /etc/fstab используются UUID — ошибиться сложно.

Установщик Ubuntu позволяет сразу создать зеркало и второй ESP.
Выбираем Custom storage layout.
Если диски не пусты, то удаляем все разделы (reformat в контекстном меню).
Назначаем первый диск в качестве загрузочного (use as boot device), затем второй (set as another boot device). Это приведет к созданию двух разделов ESP. Первый будет монтироваться в /boot/efi
Создаём на первом и втором диске разделы одинакового размера без файловой системы, выбираем Create software RAID (md).
Затем поверх массива можно создавать обычные разделы или LVM.

После загрузки смотрим, что получилось:

  lsblk
NAME            MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
loop0             7:0    0  55.4M  1 loop  /snap/core18/2128
loop1             7:1    0  70.3M  1 loop  /snap/lxd/21029
loop2             7:2    0  32.3M  1 loop  /snap/snapd/12704
sda               8:0    0 447.1G  0 disk
├─sda1            8:1    0   1.1G  0 part
└─sda2            8:2    0   100G  0 part
  └─md0           9:0    0   100G  0 raid1
    ├─vg0-lv--0 253:0    0    80G  0 lvm   /
    └─vg0-lv--1 253:1    0    20G  0 lvm   [SWAP]
sdb               8:16   0 447.1G  0 disk
├─sdb1            8:17   0   1.1G  0 part  /boot/efi
└─sdb2            8:18   0   100G  0 part
  └─md0           9:0    0   100G  0 raid1
    ├─vg0-lv--0 253:0    0    80G  0 lvm   /
    └─vg0-lv--1 253:1    0    20G  0 lvm   [SWAP]

Дождемся окончания синхронизации зеркала:

cat /proc/mdstat
[sudo] password for nosachev:
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sda2[1] sdb2[0]
      104791040 blocks super 1.2 [2/2] [UU]

Теперь нужно смонтировать второй ESP (в данном случае /dev/sda1). Монтировать его, конечно, надо по UUID, который надо найти:

sudo blkid
/dev/sdb1: UUID="6153-EE45" TYPE="vfat" 
	PARTUUID="74b52d60-f93f-4d71-be26-08d8051e20a7"
/dev/sdb2: UUID="7db4352a-9fe0-f97e-ec52-4054b3f6d0e0" 
	UUID_SUB="d973967c-e57b-be62-22e8-5c42cc1d7690" 
	LABEL="ubuntu-server:0" TYPE="linux_raid_member" 
	PARTUUID="a9266435-ff30-42ff-aa22-0fd7e42f8b9d"
/dev/sda1: UUID="6171-3842" TYPE="vfat"
	PARTUUID="49abd183-99e4-4385-8c5a-f913f49e9d1a"
/dev/sda2: UUID="7db4352a-9fe0-f97e-ec52-4054b3f6d0e0" 
	UUID_SUB="41a354a8-01a9-dc8f-e22b-b7c07c737811" 
	LABEL="ubuntu-server:0" TYPE="linux_raid_member" 
	PARTUUID="d43bf558-fb0d-4210-8e9f-ac28cc2e5adc"
/dev/md0: UUID="lL90UC-Xxnl-I0MJ-Al0f-1hA1-tfjb-M0vHD0" 
	TYPE="LVM2_member"
/dev/mapper/vg0-lv--0: UUID="17f2a56f-6012-42d9-97eb-65384e2455d5" 
	TYPE="ext4"
/dev/mapper/vg0-lv--1: UUID="d14c3ff7-b4ae-4a34-aaf1-4adc7e24aa5b" 
	TYPE="swap"
/dev/loop0: TYPE="squashfs"
/dev/loop1: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"

Создаем точку монтирования

sudo mkdir /boot/eficopy

Правим /etc/fstab, добавляем строчку:

/dev/disk/by-uuid/6171-3842 /boot/eficopy vfat defaults 0 1

Монтируем:

sudo mount /boot/eficopy

В Ubuntu можно воспользоваться

dpkg-reconfigure grub-efi-amd64

Получим на всех доступных ESP-разделах GRUB с правильной конфигурацией.

Восстановление. Вытаскиваем диск sdb, меняем на другой. Нужно создать аналогичные разделы на новом диске. Пример для gparted:

unit MiB
mklabel gpt
mkpart "EFI system partition" fat32 1MiB 1076MiB
set 1 esp on
mkpart "" 1076MiB 103476MiB

Добавляем новый раздел в массив, начнётся синхронизация:

nosachev@r1test:~$ sudo mdadm --add /dev/md0 /dev/sdb2
mdadm: added /dev/sdb2
nosachev@r1test:~$ sudo cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sdb2[2] sda2[1]
      104791040 blocks super 1.2 [2/1] [_U]
      [>....................]  recovery =  0.1% (166784/104791040) 
      	finish=20.9min speed=83392K/sec

unused devices:

Меняем в /etc/fstab UUID соотвествующего ESP-раздела, монтируем, запускаем конфигурирование GRUB.

При помощи efibootmgr можно посмотреть, какие пункты загрузки присутствуют в NVRAM и удалить ненужные:

nosachev@r1test:/boot/eficopy/EFI/ubuntu$ sudo efibootmgr -v
[sudo] password for nosachev:
BootCurrent: 0001
Timeout: 2 seconds
BootOrder: 0001,000D,000B,000C,000E,0002,0009
Boot0001* ubuntu        HD(1,GPT,
	49abd183-99e4-4385-8c5a-f913f49e9d1a,0x800,0x219800)/
    File(\EFI\ubuntu\grubx64.efi)
Boot0002* UEFI: Built-in EFI Shell     
	VenMedia(5023b95c-db26-429b-a648-bd47664c8012)..BO
Boot000B* UEFI OS       HD(1,GPT,
	49abd183-99e4-4385-8c5a-f913f49e9d1a,0x800,0x219800)/
    File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot000C* Windows Boot Manager  HD(1,GPT,
	bee52ecc-06c1-4da9-853f-d83d6f47ed95,0x800,0x219800)/
    File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)..BO
Boot000D* ubuntu        HD(1,GPT,
	bee52ecc-06c1-4da9-853f-d83d6f47ed95,0x800,0x219800)/
    File(\EFI\ubuntu\grubx64.efi)
Boot000E* UEFI OS       HD(1,GPT,
	bee52ecc-06c1-4da9-853f-d83d6f47ed95,0x800,0x219800)/
    File(\EFI\BOOT\BOOTX64.EFI)..BO

Проверить очень просто — UUID здесь соотвествуют UUID'ам разделов ESP.

Windows Server на программном RAID-1 (продолжение)

2022-04-08T15:42:00.000+03:00

Руководство по установке Windows Server 2019 на программное зеркало (см. предыдущую статью) нуждается в уточнении.

При добавлении второго диска создавать на нем раздел, который будет зеркалироваться не нужно. После выбора тома и указания для него второго диска (add disk=n) раздел аналогичного размера будет создан автоматически. Это даёт возможность использовать диск меньшего объёма, если можно уменьшить зеркалируемый том.
На этот раз всё тестировалось на реальном оборудовании (плата Supermicro X10DRI). Загрузочные пункты там выглядят вот так, можно сразу понять, какой пункт стал лишним после замены диска и удалить его. Если случайно удалили не тот, не беда — можно добавить вручную там же, или загрузиться в EFI Shell, чтобы запустить загрузчик оттуда.
Диски в зеркале должны иметь одинаковый формат секторов, т.е. одинаковые размеры физического и логического секторов. Заменить диск 512N на 512E не получится.
Как устроен BCD:
Есть основная запись для загрузчика (Windows Boot Manager) с идентификатором {bootmgr}. Там описываются параметры загрузочного меню (записи для загрузки, таймаут и т.п.).
Загрузочные записи (Windows Boot Loader). Первая запись будет иметь идентификатор {current}, вторая (после зеркалирования системного раздела) — случайно сгенерированный UUID. Поле description лучше поменять так, чтобы можно было идентифицировать диск. Можно добавить туда серийный номер.

После замены диска нужно сначала разбить зеркало. Через оснастку Disk Management это сделать просто, но если GUI нет, то через diskpart это делается так:

Выводим список дисков (в данном примере был заменен 0-й диск, системный том находится на диске 1):

DISKPART> lis dis

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online         5589 GB  5589 GB
  Disk 1    Online          447 GB      0 B   *    *
  Disk M0   Missing            0 B      0 B   *

Выделяем том и разбиваем зеркало:

sel dis 1
lis vol

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     C                NTFS   Simple       446 GB  Healthy    Boot
  Volume 1                      FAT32  Partition    260 MB  Healthy    System
  
sel vol 0
break disk=M0 nokeep

Удаляем отсутствующий диск:

sel dis M0
del dis override

Последний момент: при манипуляциях с BCD после замены диска можно случайно ошибиться и снести конфигурацию. Достаточно указать не тот раздел для {bootmgr} и можно потерять содержимое ESP.

Установка Windows Server 2019 на программный RAID-1

2021-08-10T17:09:00.005+03:00

Что делать, если нужно поставить ОС на зеркало, но чипсетного программного RAID нет, а установить дополнительный дополнительный контроллер не позволяет бюджет? В данной статье мы рассмотрим процедуру организации загрузки Windows Server 2019 с программного зеркала, а так же особенности восстановления.

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

В Windows есть два механизма создания программных массивов — на основе динамических дисков и на основе Storage Spaces. При этом только первый из них позволяет зеркалировать раздел с системой. Краткое описание процедуры при загрузке через UEFI:

Установить ОС на одиночный диск.
Создать на втором диске идентичные разделы.
Преобразовать оба диска в динамические.
Зазеркалировать системный раздел первого диска на второй диск.
Обеспечить возможность загрузки с любого из дисков — настроить дополнительный пункт в загрузочном меню и скопировать конфигурацию бутменеджера, т. е. по сути скопировать содержимое EFI-раздела с первого диска на второй.

Устанавливать будем Windows Server 2019 Standard с GUI, так как всё описанное ниже подходит и для Windows 10.

На пустом диске инсталлятор автоматически создаст дополнительный раздел восстановления размером 500 МБ в начале диска. Нам он не нужен, поэтому после запуска инсталлятора запускаем консоль через Shift-F10, запускаем diskpart, создаём три раздела:

EFI 260 МиБ
MSR 16 МиБ
системный раздел — в данном случае, для примера, на всё оставшееся пространство

После установки увидим в disk manager'е следующую картину:

Запускаем diskpart (примечание: diskpart понимает сокращённые названия команд) и смотрим таблицу разделов на диске 0:

DISKPART> sel dis 0

Disk 0 is now the selected disk.

DISKPART> lis par

  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 1    System             260 MB  1024 KB
  Partition 2    Reserved            16 MB   261 MB
  Partition 3    Primary             99 GB   277 MB

Выберем диск 1 и инициализируем его (создадим таблицу разделов GPT). При этом будет автоматически создан раздел MSR размером 15 МиБ, который мы удалим, используя дополнительный параметр override:

DISKPART> con gpt

DiskPart successfully converted the selected disk to GPT format.

DISKPART> lis par

  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 1    Reserved            15 MB    17 KB
  
DISKPART> sel par 1

Partition 1 is now the selected partition.

DISKPART> delete par override

DiskPart successfully deleted the selected partition.

Создаём те же разделы, что и на диске 0:

DISKPART> crea par efi size=260

DiskPart succeeded in creating the specified partition.

DISKPART> crea par msr size=16

DiskPart succeeded in creating the specified partition.

не создавать!: DISKPART> crea par pri

DiskPart succeeded in creating the specified partition.

DISKPART> lis par

  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 1    System             260 MB  1024 KB
  Partition 2    Reserved            16 MB   261 MB
* Partition 3    Primary             99 GB   277 MB

Преобразуем оба диска в динамические:

DISKPART> sel dis 0

Disk 0 is now the selected disk.

DISKPART> con dyn

DiskPart successfully converted the selected disk to dynamic format.

DISKPART> sel dis 1

Disk 1 is now the selected disk.

DISKPART> con dyn

DiskPart successfully converted the selected disk to dynamic format.

Зеркалируем системный раздел. В данном случае он смонтирован на C:

DISKPART> sel vol C

Volume 3 is the selected volume.

DISKPART> add disk=1

DiskPart succeeded in adding a mirror to the volume.

Начнётся процесс синхронизации зеркала:

Перейдём к дублированию загрузчика. Загрузчик сейчас находится на разделе EFI на диска 0. Аналогичный раздел на диске 1 пуст. Отформатируем его в FAT, назначим букву S (secondary), а разделу EFI на диске 0 — букву P (primary):

DISKPART> sel dis 1

Disk 1 is now the selected disk.

DISKPART> lis dis

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online          100 GB      0 B   *    *
* Disk 1    Online          100 GB      0 B   *    *

DISKPART> lis par

  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 1    System             260 MB  1024 KB
  Partition 4    Dynamic Reserved  1024 KB   261 MB
  Partition 2    Reserved            15 MB   262 MB
  Partition 3    Dynamic Data        99 GB   277 MB
  Partition 5    Dynamic Data      1007 KB    99 GB

DISKPART> sel par 1

Partition 1 is now the selected partition.

DISKPART> assign letter = S

DiskPart successfully assigned the drive letter or mount point.

DISKPART> format fs=FAT32 quick

  100 percent completed

DiskPart successfully formatted the volume.

DISKPART> sel dis 0

Disk 0 is now the selected disk.

DISKPART> lis par

  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 1    System             260 MB  1024 KB
  Partition 4    Dynamic Reserved  1024 KB   261 MB
  Partition 2    Reserved            15 MB   262 MB
  Partition 3    Dynamic Data        99 GB   277 MB
  Partition 5    Dynamic Data      1007 KB    99 GB

DISKPART> sel par 1

Partition 1 is now the selected partition.

DISKPART> assign letter=P

DiskPart successfully assigned the drive letter or mount point.

Посмотрим на конфигурацию загрузчика. Примечание: запуск bcdedit с некоторыми параметрами в консоли PowerShell приводит к ошибкам, поэтому для работы с bcdedit следует запустить cmd.

bcdedit /enum

Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=P:
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
bootshutdowndisabled    Yes
default                 {current}
resumeobject            {4e02bc8d-f967-11eb-bb60-dc5f81ee32a9}
displayorder            {current}
                        {4e02bc92-f967-11eb-bb60-dc5f81ee32a9}
toolsdisplayorder       {memdiag}
timeout                 30

Windows Boot Loader
-------------------
identifier              {current}
device                  partition=C:
path                    \Windows\system32\winload.efi
description             Windows Server
locale                  en-US
inherit                 {bootloadersettings}
recoverysequence        {4e02bc8f-f967-11eb-bb60-dc5f81ee32a9}
displaymessageoverride  Recovery
recoveryenabled         Yes
isolatedcontext         Yes
allowedinmemorysettings 0x15000075
osdevice                partition=C:
systemroot              \Windows
resumeobject            {4e02bc8d-f967-11eb-bb60-dc5f81ee32a9}
nx                      OptOut

Windows Boot Loader
-------------------
identifier              {4e02bc92-f967-11eb-bb60-dc5f81ee32a9}
device                  partition=C:
path                    \Windows\system32\winload.efi
description             Windows Server - secondary plex
locale                  en-US
inherit                 {bootloadersettings}
recoverysequence        {4e02bc8f-f967-11eb-bb60-dc5f81ee32a9}
displaymessageoverride  Recovery
recoveryenabled         Yes
isolatedcontext         Yes
allowedinmemorysettings 0x15000075
osdevice                partition=C:
systemroot              \Windows
resumeobject            {4e02bc8d-f967-11eb-bb60-dc5f81ee32a9}
nx                      OptOut

Когда мы зеркалировали системный раздел, то ОС автоматически добавила дополнительный пункт загрузки Windows Server - secondary plex. Теперь осталось скопировать всю конфигурацию загрузчика на раздел EFI диска 1. Для этого сначала создадим дубль конфигурации, получим его GUID, который затем используем, чтобы изменить букву раздела с P на S:

bcdedit /copy {bootmgr} /d "Windows Boot Manager Cloned"
The entry was successfully copied to {4e02bc94-f967-11eb-bb60-dc5f81ee32a9}.

bcdedit /set {4e02bc94-f967-11eb-bb60-dc5f81ee32a9} device partition=s:

Теперь экспортируем конфигурацию в BCD2, скопируем всё содержимое EFI-раздела на диске 0 (раздел P) на диск 1 (раздел S). Потом переименуем его на разделе S из BCD2 в BCD:

P:
bcdedit /export P:\EFI\Microsoft\Boot\BCD2
robocopy p:\ s:\ /e /r:0
Rename s:\EFI\Microsoft\Boot\BCD2 BCD
Del P:\EFI\Microsoft\Boot\BCD2

Перезагрузимся и заглянем в BIOS:

Помимо основного пункта (Windows Boot Manager), созданного при установке ОС, у нас теперь появился пункт Windows Boot Manager Cloned для загрузки со второго диска.

Временное отключение одного из дисков

Проверим конфигурацию в действии, отключив диск 0. Пункт Windows Boot Manager ничего не загрузит, воспользуемся Windows Boot Manager Cloned (или запустим boot manager через EFI Shell). Boot manager отобразит те же два пункта с загрузчиками. Первый запустить не получится, используем второй — Windows Server - secondary plex.

ОС загружается. Диск 1 теперь стал диском 0, система сообщает о потере отказоустойчивости на зеркальном томе сообщает и о потере соответствующего диска.

Допустим, что диск исправен, его просто случайно отключили, а потом вставили обратно. Тут нас подстерегает первая опасность — нужно помнить про то, что состояние системы при загрузке с этого диска будет неактуальным и выбрать пункт «Windows Server - secondary plex». После загрузки ОС мы увидим, что зеркало развалилось:

Для восстановления отказоустойчивости нужно удалить неиспользуемый раздел (в данном случае том E) и заново сделать зеркало тома C:

sel vol C
add disk=0

Замена диска на новый

Другой, более вероятный сценарий — первый диск вышел из строя, и мы заменили его на новый. В этом случае нужно повторить процедуру, выполненную после установки системы. Добавляется два нюанса:

Желательно иметь под рукой размеры разделов до преобразования дисков в динамические, чтобы не пришлось вычислять заново правильный размер раздела MSR.

Придётся править загрузчик, удалив исправив пункт, ссылающийся на уже недоступный раздел. В данном примере это {default}, так как мы заменили первый диск:

bcdedit /enum

Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  unknown
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
bootshutdowndisabled    Yes
default                 {default}
resumeobject            {4e02bc8d-f967-11eb-bb60-dc5f81ee32a9}
displayorder            {default}
                        {current}
                        {3df44507-f920-11eb-9dd3-080027bb0bb1}
toolsdisplayorder       {memdiag}
timeout                 30

Windows Boot Loader
-------------------
identifier              {default}
device                  unknown
path                    \Windows\system32\winload.efi
description             Windows Server
locale                  en-US
inherit                 {bootloadersettings}
recoverysequence        {4e02bc8f-f967-11eb-bb60-dc5f81ee32a9}
displaymessageoverride  Recovery
recoveryenabled         Yes
isolatedcontext         Yes
allowedinmemorysettings 0x15000075
osdevice                unknown
systemroot              \Windows
resumeobject            {4e02bc8d-f967-11eb-bb60-dc5f81ee32a9}
nx                      OptOut

Windows Boot Loader
-------------------
identifier              {current}
device                  partition=C:
path                    \Windows\system32\winload.efi
description             Windows Server - secondary plex
locale                  en-US
inherit                 {bootloadersettings}
recoverysequence        {4e02bc8f-f967-11eb-bb60-dc5f81ee32a9}
displaymessageoverride  Recovery
recoveryenabled         Yes
isolatedcontext         Yes
allowedinmemorysettings 0x15000075
osdevice                partition=C:
systemroot              \Windows
resumeobject            {4e02bc8d-f967-11eb-bb60-dc5f81ee32a9}
nx                      OptOut

Windows Boot Loader
-------------------
identifier              {3df44507-f920-11eb-9dd3-080027bb0bb1}
device                  partition=C:
path                    \Windows\system32\winload.efi
description             Windows Server - secondary plex - secondary plex
locale                  en-US
inherit                 {bootloadersettings}
recoverysequence        {4e02bc8f-f967-11eb-bb60-dc5f81ee32a9}
displaymessageoverride  Recovery
recoveryenabled         Yes
isolatedcontext         Yes
allowedinmemorysettings 0x15000075
osdevice                partition=C:
systemroot              \Windows
resumeobject            {4e02bc8d-f967-11eb-bb60-dc5f81ee32a9}
nx                      OptOut
The system cannot find the file specified.

**********
bcdedit /delete {default}
bcdedit /set {bootmgr} device partition=p:

Затем можно продолжить процедуру — скопировать раздел EFI.

Заключение

Механизм загрузки Windows с программного зеркала достаточно хорошо отработан. Практически он не менялся со времён выхода Windows Server 2008. Как видите, поддержание работоспособности требует большего количества действий и понимания работы загрузчика — на любом этапе можно ошибиться и потерять если не данные, то ценное время.

Следующая статья будет посвящена установке и настройке Linux на программном RAID-1.

Контроллеры и разносортные диски

2020-10-19T15:39:00.002+03:00

В этом документе специалисты Toshiba рассуждают о том, что делать при отсутствии возможности заменить вышедший из строя накопитель на полностью аналогичный.

Описывается следующая проблема. Надёжность современных дисков такова, что по статистике значительная часть из них работает дольше пяти лет. Модельный ряд несмотря на некоторое замедление прогресса постоянно меняется, и найти на замену полностью аналогичную модель уже невозможно. Какие трудности нас ожидают при замене жёстких дисков из-за различий в формате секторов (например, 512N на 512E)? Можно ли заменить диск с интерфейсом SATA на аналогичный с интерфейсом SAS? Что будет, если заменить HDD на SSD?

Далее последовало несколько опытов с современными контроллерами Broadcom 9380 и Adaptec 3154. Никаких сложных тестов на совместимость и стабильность не проводилось. Проверяли, принимает ли контроллер новый накопитель, успешно ли завершается ребилд и нет ли явных проблем с производительностью.

Результаты получились следующие:

Замена 512N на 512E (Toshiba MG03ACA300 и MG04ACA300E). Broadcom = OK, Adaptec = OK. Тем не менее, следует обратить внимание на риск нарушения целостности данных, см. статью про Advanced Format на Хабре.
Замена SAS3 на SAS2: Broadcom = OK, Adaptec = OK
Замена 512E на 4KN. Оба контроллера, естественно, отказались принимать диски с другим логическим размером сектора.
Замена SATA на SAS: Broadcom = OK, Adaptec в новой серии 3100 не поддерживает сочетание SATA и SAS в одной дисковой группе
Замена HDD на SSD: Broadcom = OK, Adaptec в новой серии 3100 не поддерживает сочетание HDD и SSD в одной дисковой группе

Прошивка SAS3-бэкплейна Supermicro

2020-08-24T17:08:00.004+03:00

Как-то раз мы пытались воспроизвести проблему клиента с мониторингом SAS-бэкплейна через sg_ses на JBOD'е 216BE2C-R741JBOD. Для это, прежде всего, понадобилось обновить прошивку экспандеров.

Всё началось с того, что в ходе прошивки мы брикнули один из экспандеров.

Так же, как и для бэкплейнов SAS-1 и SAS-2, Supermicro предоставляет три файла: основной образ прошивки с расширением fw и два так называемых MFG-образа, для первого и второго экспандера. В MFG прописана конфигурация экспандера: WWN, режимы портов, датчики и т.п.

В примечании к архиву с прошивкой рекомендовалось использовать не ExpanderXTools, а консольную утилиту CLIXTL. Подключаем наш JBOD к HBA 9300-8e, загружаем модуль ядра sg, выводим список экспандеров:

$ sudo ./CLIXTL -l
================================================================================
                        COMMAND-LINE INTERFACE XTOOL
                        version   6.10.C
                        Supermicro Computer ,Inc.
================================================================================
    PRODUCT ID          SAS ADDRESS             DEVICE NAME
01) SAS3x40             500304801F55FE7F        /dev/sg2
02) SAS3x40             500304801F55FEFF        /dev/sg4

Заливаем прошивку во все регионы флеша:

sudo ./CLIXTL -f all -t 500304801F55FE7F -d SAS3-EXPFW_66.16.13.00.fw

Firmware Region 0 - Finished
Firmware Region 1 - Finished
Firmware Region 2 - Finished
Please reset expander to activate

Перезагружаем экспандер, пытаемся прошить MFG (sudo ./CLIXTL -f 3 -t 500304801F55FE7F -d BPN-SAS3-216EL-PRI_16_13.bin -r), а он не шьётся. Нет у нас больше первого экспандера.

Восстановить его помогла статья Pieter'а Viljoen'а, в которой он столкнулся с аналогичной ситуацией на 836-м бэкплейне и подключился через USB-UART. Нужный разъём называется SDB, находится рядом с разъёмом UART. Но нам нужен именно SDB (видимо, это сокращение от sideband).

Переключаем переходник USB-UART на 3,3В и подключаем: RX, GND, TX к пинам 1, 2 и 3, соответственно.

После подключения с экспандером можно общаться через /dev/ttyUSB0. Экспандер присутствует, но без WWN:

sudo ./g3Xflash -s /dev/ttyUSB0 get avail

Initializing Interface..

INFO: Bootstrap is not present on board.

Downloading the Bootstrap
................................................................Download Bootstrap Complete.
..................
Expander: SAS3x40 (SAS_3X_40)

1) SAS3x40 (SAS_3X_40) (00000000:00000000)

Заливаем прошивку:

sudo ./g3Xflash -s /dev/ttyUSB0 down fw SAS3-EXPFW_66.16.13.00.fw 0

Initializing Interface....................
Expander: SAS3x40 (SAS_3X_40)


   Expander Validation: Passed
              Checksum: Passed
Target Firmware Region: 00
       Current Version: 66.16.13.00
   Replacement Version: 66.16.13.00
      Image Validation: Passed

Pre-Validation of image is successful.

Are you sure to download file to expander?(y/n):
***************
Downloading File...........................................................................Download Complete.

Post-validating........................................................Post-Validation of image is successful.

Download Successful.

Заливаем MFG:

sudo ./g3Xflash -s /dev/ttyUSB0 down mfg BPN-SAS3-216EL-PRI_16_13.bin 3

Initializing Interface....................
Expander: SAS3x40 (SAS_3X_40)

      Image Validation: Passed
              Checksum: Passed
       Current Version: 06.02
   Replacement Version: 10.0d

Pre-Validation of image is successful.

Are you sure to download file to expander?(y/n):y

Downloading File...........................Download Complete.

Post-validating........Post-Validation of image is successful.

Download Successful.

Перезагружаем экспандер:

sudo ./g3Xflash -s /dev/ttyUSB0 reset exp

Initializing Interface....................
Expander: SC216-P (SAS_3X_40)

Are you sure you want to reset Expander?(y/n):y

Expander reset successful.

Повторяем для второго экспандера. Далее мы столкнулись с той же проблемой, что и Питер — установился дефолтный WWN, поменять который нельзя. Если у вас только один бэкплейн, то проблемы это не представляет. Но если таких наберется несколько в одной топологии, то это приведет к конфликту адресов. В ReleaseNote к прошивке написано, что для смены WWN нужно использовать CLIXTL с ключом -s, но CLIXTL сообщает, что не знает про такой ключ.

Воспользуемся ExpanderXTools. Это всего лишь графический фронтенд для g3Xflash, но у него есть окно для смены WWN:

Увы, после Update WWN экспандер снова окирпичивается. Видно, что g3Xflash генерирует новый MFG и шьёт его. Видимо, в результате получается какой-то неправильный MFG.

Поддержка Supermicro сообщила удивительную вещь: те версии CLIXTL и g3Xflash, которые лежат в открытом доступе, лишены функционала смены WWN. Предлагают сгенерировать нужный MFG-файлы под конкретный бэкплейн. Это сработало, а для решения проблемы с sg_ses пришлось ещё и вернуть старую прошивку.

На будущее — для прошивки стоит использовать ExpanderXTools или g3Xflash, а использование CLIXTL в соответствии с описанием в ReleaseNotes приводит к окирпичиванию экспандера.

Broadcom 9300-4i/9300-8i: прошивка из IT в IR

2019-09-30T13:51:00.000+03:00

В прежние времена SAS HBA от LSI (теперь Broadcom) по умолчанию шли с прошивкой IR (Integrated RAID). Чтобы перейти на чистый HBA, нужно было шить в IT, что требовало дополнительных манипуляций.

Сейчас всё наоборот — по умолчанию прошит IT, и если вам нужен простой RAID (например, для зеркала под систему), то нужно прошить IR. Обратите внимание, что IR-стек дальше развиваться не будет, и для новых HBA серии 9400 его не существует.

Идём на страницу продукта (9300-4i, 9300-8i) и на вкладке downloads забираем архив с прошивкам. Прошивать будем 9300-4i, для 8-портового 8i всё аналогично.

В каталоге Firmware лежат основные прошивки (IT и IR, соответственно): SAS9300_4i_IT.bin и SAS9311_4i_IR.bin
В каталоге sasbios_rel — BIOS контроллера
В каталоге uefi_bsd_rel — UEFI BIOS. В подкаталоге Signed находится он же, но с цифровой подписью Microsoft, необходимой для функционирования Secure Boot.
В этом же архиве лежит утилита sas3flash под DOS, но под DOS на большинстве материнских плат у вас ничего не получится (ошибка ERROR: Failed to initialize PAL), так что нужен sas3flash для UEFI.

Копируем всё на FAT-флешку и загружаемся в EFI Shell (его можно временно выбрать в загрузочном меню по F11). Единственная флешка при отсутствии других подходящих устройств будет доступна через fs0:

Затираем флеш и шьём IR-прошивку:

sas3flash.efi -o -e 6
sas3flash.efi -o -f SAS9311_4i_IR.bin

BIOS'ов у нас теперь тоже нет, а создавать массивы и грузиться с контроллера как-то нужно, так что прошьём их:

sas3flash.efi -o -b mptsas3.rom -nossid
sas3flash.efi -o -b mpt3x64.rom -nossid

После чего можно проверить (sas3flash.efi -list):

Если вы используете UEFI, не забудьте переключить в PCIe/PCI/PnP Configuration соответствующие слоты в UEFI.
После чего можно будет увидеть в интерфейсе BIOS материнской платы настройки контроллера:

В БЗ на сайте Broadcom присутствует опечатка: UEFI BSD рекомендуют шить с ключом -f, а нужен -b.

SR-IOV и интегрированная сеть X722

2019-07-11T15:30:00.001+03:00

Обратился к нам недавно заказчик с одной проблемой: не работает SR-IOV для набортных сетевых интерфейсов платы X11DPi-N под Windows Server 2016. Поддержка в BIOS включена, для других карточек работает, всё прошито-обновлено, но Get-NetAdapterSriov выдаёт пустоту.

Я воспроизвёл это на X11DPi-N и X11DDW-L. На обеих платах были набортные X722 в гигабитном исполнении. Попробовал настроить SR-IOV в Linux — все настраивается за пару минут и работает под CentOS 7.1. Обновил i40e и iavf, добавил передачу параметров ядру (iommu и количество VF для интерфейсов):

sudo lshw -class network -businfo
Bus info          Device     Class          Description
=======================================================
pci@0000:1c:00.0  eno1       network        Ethernet Connection X722 for 1GbE
pci@0000:1c:00.1  eno2       network        Ethernet Connection X722 for 1GbE
pci@0000:1c:06.0  enp28s6    network        Ethernet Virtual Function 700 Series
pci@0000:1c:06.1  enp28s6f1  network        Ethernet Virtual Function 700 Series
pci@0000:1c:06.2  enp28s6f2  network        Ethernet Virtual Function 700 Series
pci@0000:1c:06.3  enp28s6f3  network        Ethernet Virtual Function 700 Series

Поддержка Supermicro долго не могла сказать ничего определённого, кроме предположения о конфликте с VMD. Сегодня прислали ссылку на спецификацию Intel. Так вот, SR-IOV для X722 в гигабитном исполнении не поддерживается:

Но ведь под Linux работает. Я перечитал Readme к линуксовому модулю i40e, там тоже сказано, что не должно:

NOTE: 1 Gb devices based on the Intel(R) Ethernet Network Connection X722 do
not support the following features:
  * Data Center Bridging (DCB)
  * QOS
  * VMQ
  * SR-IOV
  * Task Encapsulation offload (VXLAN, NVGRE)
  * Energy Efficient Ethernet (EEE)
  * Auto-media detect

Ладно, будем рассматривать это как незадокументированный бонус. Естественно, в продакшене использовать то, что не поддерживается официально, нельзя.

Крепление для двух дисков 2,5" MCP-220-82611-0N

2018-04-04T12:07:00.003+03:00

Внутреннее крепление для двух дисков 2,5" Supermicro MCP-220-82611-0N совместимо с материнскими платами Supermicro, но с некоторыми оговорками. Нужно учитывать высоту при подключении некоторых кабелей, например, SFF-8087, которые на платах X11DPI-N(T) расположены вертикально.

Проблема решается путём использования угловых кабелей SFF-8087—4×SATA.

Баг в инсталляторе ESXi 6.5

2016-12-29T11:15:00.000+03:00

При установке ESXi 6.5 вы можете получить сообщение об ошибке с жалобой на разделы (partedUtil failed with message: Error: The primary GPT table states that the backup GPT is located beyond the end of disk).
Такое случается при установке через EFI. Решение: загрузить какой-нибудь дистрибутив (инсталлятор какой-нибудь ОС или Live-диск) и создать на нужном диске или томе RAID-контроллера хотя бы один раздел.

Тестирование SSD Kingston DC400

2016-09-16T10:05:00.001+03:00

Корпоративные SSD от Kingston

Компания Kingston Technology знаменита в первую очередь модулями оперативной памяти, накопителями USB-флеш и относительно недорогими, но качественными накопителями SATA SSD для домашних пользователей. При этом Kingston достаточно давно присутствует на рынке SSD корпоративного класса, пусть и со сравнительно небольшим количеством моделей.
Появившийся в 2009 Kingston SSDNow E был не самостоятельной разработкой, а OEM-разновидностью очень популярного в то время Intel X25-E на базе памяти SLC. Позже портфолио компании дополнилось моделями E50 и E100, которые долгое время оставались популярными благодаря хорошему соотношению между ценой и производительностью.

Kingston DC400

Kingston DC400 был официально представлен 29 августа 2016. Новая линейка SSD относится к новому классу бюджетных накопителей для дата-центров. Они обладают сравнительно небольшим ресурсом, то есть предназначены для нагрузок с преимущественным чтением, где эти накопители демонстрируют высокую производительность и стабильный уровень задержек. Конденсаторная защита от потери питания отсутствует, но при этом обеспечивается защита целостности метаданных. Большим преимуществом таких бюджетных SSD является цена — чуть дороже домашних SSD.
Примером накопителя подобного класса может служить Intel S3100, с которым мы и будем сравнивать новинку от Kingston. Первое отличие — Kingston предлагает больший объём, от 400 до 1800 ГБ, в то время как максимальный объём Intel S3100 составляет 1000 ГБ.

Дизайн Kingston DC400 — легко узнаваемый прочный алюминиевый корпус и большая наклейка с фирменным логотипом.

Характеристики

Объём: 400, 480, 800, 960, 1600, 1800 ГБ
Форм-фактор: 2,5", высота 7 мм
Интерфейс: SATA 3.0 6 Гбит/с
Производительность
- Последовательный доступ: чтение — 555 МБ/с, запись — 510 МБ/с
- Случайный доступ (блок 4 КиБ, модель 1600 ГБ): чтение — 78000 IOPS, запись — 32000 IOPS
- QoS задержки (блок 4 КиБ, случайный доступ, перцентиль 99,9%): 400 мкс / 4 мс
Эмулируемый размер сектора: 512 байт (физический/логический)
Ресурс (модель 1600 ГБ): 0,57 DWPD
Гарантийный срок: 5 лет

Результаты тестирования

Условия тестирования

Конфигурация тестового стенда:

Процессор Intel Xeon E5-2660 V3 (10 ядер, 2,6 ГГц, HT включен)
32 ГБ памяти
Системная плата Supermicro X10SRi-F (1x socket R3, Intel C612)
SAS3 HBA Avago 9300-8i (драйвер 12.00.00.00-1, прошивка 12.00.00.00)
CentOS Linux 7.2 X86_64
Для генерации нагрузки применялся FIO версии 2.12

Тестируемое устройство:

Kingston DC400 1600 ГБ (SEDC400S371600G)
Серийный номер: 50026B726604DCB4
Прошивка: SAFM32.D
Объём: 1 600 321 314 816 байт (1,46 ГиБ)^*

^*Как и другие производители HDD и SSD Kingston указывает объём в «десятичных» гигабайтах (1 гигабайт = 10⁹ байт), в ОС и прикладном ПО используются двоичные приставки (1 гибибайт = 2³⁰ байт).
Использованы модифицированные тесты из SNIA Solid State Storage Performance Test Specification Enterprise v1.1. Данная спецификация описывает алгоритмы различных тестов и формат отчетов. Ниже приведены параметры тестов и отличия от SNIA PTS:

IOPS Test. Измеряется количество IOPS (операций ввода-вывода в секунду) для блоков различного размера (1024 КиБ, 128 КиБ, 64 КиБ, 32 КиБ, 16 КиБ, 8 КиБ, 4 КиБ, 0.5 КиБ) и случайного доступа с различным соотношением чтение/запись (100/0, 95/5, 65/35, 50/50, 35/65, 5/95, 0/100). Параметры: 16 потоков с глубиной очереди 8. Отличие от спецификации — из теста был исключён блок 0,5 КиБ (512 байт).
Throughput Test. Тестируется пропускная способность при последовательном доступе: чтение и запись блоками 1 МиБ и 128 КиБ.
Latency Test. Измеряется значение средней и максимальной задержки для различных размеров блока (8КиБ, 4КиБ, 0.5КиБ) и соотношений чтение/запись (100/0, 65/35, 0/100) при минимальной глубине очереди (1 поток с QD=1). Отличия от спецификации:
- исключён блок 0,5КиБ
- вместо однопоточной нагрузки с очередями 1 и 32 нагрузка варьируется по количеству потоков (1, 2, 4) и глубине очереди (1, 2, 4, 8, 16, 32)
- вместо соотношения 65/35 используется 70/30
- приводятся не только средние и максимальные значения, но и перцентили 99%, 99,9% и 99,99%.
- для выбранного значения количества потоков строятся графики зависимости задержки (99%, 99,99% и среднего значения) от IOPS для всех блоков и соотношений чтение/запись
Для данного накопителя мы дополнительно приводим графики задержки для нагрузок со 100% и 30% записи блоками 4 КиБ при выделении дополнительной резервной области в 15, 30 и 50% от объёма накопителя.
Write Saturation Test. Тестируется изменение производительности (IOPS и задержка) при непрерывной нагрузке (1200 раундов по 1 минуте) на случайную запись блоками 4 КиБ. Цель — добиться перехода SSD в режим насыщения, при котором контроллеру приходится непрерывно заниматься сборкой мусора для подготовки пригодных для записи блоков NAND.
Host Idle Recovery. Тестируется эффективность работы алгоритмов сборки мусора. После перехода в режим насыщения: непрерывная нагрузка на случайную запись чередуется с облегчённой нагрузкой (5 секунд + паузы 5, 10, 15, 25, 50 секунд). Отличие от спецификации — вместо рекомендованной спецификацией предварительной нагрузки длительностью менее 30 раундов (минут) используется 1200 раундов (минут) для обеспечения гарантированного перехода SSD в режим насыщения.

Для первых трех тестов проводится серия замеров из 25 раундов длительностью 1 минута каждый. Перед тестом производится зануление (в данном случае — форматирование через sg_format), затем — предварительная нагрузка: последовательная запись блоками 128 КиБ до достижения 2-кратной емкости. Далее выбирается по одной из величин окно установившегося состояния (4 раунда), которое проверяется построением графика. Критерии установившегося состояния: линейная аппроксимация в пределах окна не должна выходить за границы 90%/110% среднего значения.

SNIA PTS: IOPS test (IOPS при варьировании размера блока и соотношения чтение/запись)

Сравнение с заявленными характеристиками:

4 КиБ чтение: 65 тыс. IOPS
4 КиБ запись: 48 тыс. IOPS
8 КиБ чтение: 39 тыс. IOPS
8 КиБ запись: 35 тыс. IOPS
4 КиБ 65/35 чтение/запись: 44 тыс. IOPS

Kingston DC400 демонстрирует очень приличные показатели для накопителя бюджетного класса, для которых типичным является 5–10 тыс. IOPS на запись.

SNIA PTS: throughtput test

Пропускная способность при последовательном однопоточном доступе блоками 128 КиБ с глубиной очереди 128.

Сравнение с заявленными характеристиками:

128 КиБ последовательное чтение: 516,6 МиБ/с
128 КиБ последовательная запись: 464,2 МиБ/с

Производительность на чтение вплотную приближается к пределу пропускной способности интерфейса SATA 3. Более 400 МиБ/с на запись является отличным результатом для накопителей, позиционируемых как read intencive. Мы не проводили собственное тестирование накопителей Intel S3100, но заявленная в спецификации производительность при последовательной записи у них существенно ниже — до 118 МиБ/с.
Для сравнения приведены результаты трёх других накопителей: Kingston E50, OCZ Saber 1000 и Toshiba HK3R.

SNIA PTS: latency test

Приведены значения задержки в микросекундах (средняя, и перцентили 99%, 99.9%, 99.99%) при одном потоке с глубиной очереди 1 в зависимости от размера блока и соотношения чтение/запись (100% чтение, 70/30 чтение/запись, 100% запись).

	Kingston SEDC400S371600G
Задержка	4КиБ	8КиБ
Средняя
Чтение	182	219
Запись	70	62
Чтение/запись 70/30%	427	339
99%
Чтение	239	307
Запись	135	130
Чтение/запись 70/30%	3184	2119
99,9%
Чтение	271	337
Запись	524	153
Чтение/запись 70/30%	3817	3483
99,99%
Чтение	316	369
Запись	5000	189
Чтение/запись 70/30%	5200	4260

Здесь мы наглядно видим особенности корпоративного класса, пусть и бюджетного — низкий и стабильный уровень задержек. Для чтения (Kingston DC400 заявлен как SSD для преимущественной нагрузки на чтение) держится в пределах существенно меньше 1 мс (перцентиль 99,99% — 0,3 мс, не приведённое в таблице пиковое значние — 0,6 мс).

Latency vs IOPS test

Данные усреднялись по четырём из 25-ти раундов длительностью 35 секунд (5 «прогревочных» + 30-секундная нагрузка) каждый. Для графиков выбрана серия значений с глубиной очереди от 1 до 32 при одном потоке. По мере увеличения глубины очереди растёт задержка, и по подобному графику можно оценить не просто абстрактное число IOPS, а производительность с учётом задержки. Kingston DC400 демонстрирует хорошую оптимизацию для чтения — даже при максмальной для устройств с интерфейсом SATA глубине очереди 32 средняя задержка не превышает нескольких сотен микросекунд и остается стабильной — перцентиль 99,99% не превышает миллисекунду с небольшим.
Средняя задержка.

99,99% перцентиль задержки.

Дополнительный Over Provisioning

SSD для домашнего применения и бюджетные корпоративные модели обладают сравнительно небольшим ресурсом и низкой производительностью на запись. Помимо архитектурных особенностей (недорогая медленная NAND-память, производительность контроллера SSD и особенности его прошивки) это определяется объёмом резервной области.
Предыдущие тесты наглядно продемострировали нам, что Kingston DC400 оптимизирован для нагрузок на чтение (собственно, для них он изначально и предназначен). Появление даже 30% записи в нагрузке приводит к увеличению задержек более чем на порядок. Можно ли исправить эту ситуацию, увеличив резервную область SSD, которая увеличит порог перехода к состоянию насыщения (когда будет исчерпан пул подготовленных для записи блоков)? Конечно можно, любым из традиционных способов:

При помощи утилиты от производителя.
Задать HPA при помощи hdparm (для дисков SATA). Для NVMe — создать namespace меньшего объёма.
Выполнить secure erase и создать раздел меньшего объёма. При подключении через RAID-контроллер — том объёмом меньше максимального.

Для увеличения резервной области были выбраны значения в 15, 30 и 50% от штатного объёма SSD. Результаты для 15%-го OP и 100% записи получились странными — производительность получилась ниже, чем без дополнительного OP. Остальные результаты получились предсказуемыми:

Дополнительная резервная область в 30% от штатного объёма приводит к существенному росту производительности. Например, при средней задержке в 1 мс на нагрузке «70/30 чтение/запись» мы получаем почти 2-кратный прирост — 33 тыс. IOPS вместо 17 тыс. Если, наоборот, зафиксировать требуемое кол-во IOPS на отметке 20 тыс., то мы получаем 6-кратное снижение средней задержки.
Дальнейшее наращивание резервной области свыше 30% не имеет смысла, соответствующие линии на графиках практически совпадают.

Средняя задержка.

99,99% перцентиль задержки.

SNIA PTS: Write Saturation Test (насыщение при случайной записи блоками 4КиБ)

Рост объёмов современных SSD вынуждает увеличивать продолжительность данного теста. Стандартных 360 минут уже не достаточно для выхода в режим насыщения — тест был увеличен до 1200 минут.
Kingston DC400 снижает производительность с 48 до 25 тыс. IOPS — результат на уровне более дорогих конкурентов с ресурсом в 2-3 DWPD. Для упоминавшегося выше приблизительного аналога Intel S3100 заявлено всего 4700 IOPS.

На следующем графике представлены задержки — от среднего (в пределах каждого 60-секундного раунда) до максимума, плюс перцентили 99%, 99,9% и 99,99%. Этот график, как и предыдущий, наглядно демонстрирует особенности прошивки Kingston DC400 — так как данный SSD просто не предназначен для интенсивной нагрузки на запись (тем более непрерывной многочасовой случайной записи малыми блоками, как в данном тесте), то всё внимание уделено сохранению небольшого ресурса. Для этого алгоритм сборки мусора преднамеренно сделан «ленивым» — он не вступает в действие до полного исчерпания свободных для записи блоков NAND и затем запускается периодически, подготавливая сразу большие порции блоков. Таким образом, в жертву производительности приносится ресурс. Контроллер не допускает так называемого «усиления записи» за счёт постоянно работающей сборки мусора, перемещающей данные между блоками.

SNIA PTS: Host Idle Recovery

Графики для этого теста приведены для одной половины накопителя. Напомним, что данный тест проводится после предыдущего, т.е. накопитель находится в режиме насыщения, с небольшим запасом подготовленных для записи ячеек. Производительность на запись снижена, далее мы даём накопителю возможность восстановить её, прерывая серию из 360 раундов с непрерывной нагрузкой (чёрный цвет на графике) сериями из 360-ти раундов с увеличивающимися паузами:

5 секунд нагрузки + 5 секунд паузы
5 секунд нагрузки + 10 секунд паузы
5 секунд нагрузки + 15 секунд паузы
5 секунд нагрузки + 25 секунд паузы
5 секунд нагрузки + 50 секунд паузы

На графиках мы видим, что по мере увеличения паузы всё большая часть запросов начинает обрабатываться быстрее (растёт количество IOPS и снижается задержка).

Средняя задержка:

Перцентиль 99,99%:

Заключение

Kingston DC400 обеспечивает отличную для своего класса производительность. SSD этой линейки предназначены для нагрузок с преимущественным чтением, но при необходимости могут выдержать и кратковременную большую нагрузку на запись.

В Smartmontools появилась поддержка NVMe

2016-07-04T11:55:00.000+03:00

В пакете Smartmontools появилась базовая поддержка работы с накопителями NVMe. Можно посмотреть атрибуты и логи, мониторить здоровье NVMe через smartd.

В инфраструктуре NVMe почти сразу же наметилась проблема — при декларируемом единстве стандарта каждый производитель пишет собственный оптимизированный драйвер и набор утилит для управления и мониторинга. Конечно, существует свободный пакет nvme-cli, работающий со всеми накопителями, но работать через привычный smartctl во многих случаях будет удобнее.

Обзор HGST SN100 — NVMe в форм-факторе 2.5" (U.2)

2016-04-08T17:39:00.000+03:00

Читайте на нашем сайте: http://www.truesystem.ru/review/409099/

Контроллеры Avago (LSI) MegaRAID и обновление прошивок SSD Intel

2016-03-28T15:47:00.000+03:00

Оказывается, Intel SSD Datacenter Tool (утилита для управления SSD производства Intel с интерфейсами SATA и NVMe) поддерживает работу через RAID-контроллеры LSI MegaRAID (как произведённые LSI/Avago, так и OEM-изделия от Intel, Dell, Supermicro и т.д.).

Достаточно включить поддержку:

isdct.exe set -system EnableLSIAdapter=true

и можно выполнять любые операции, например, обновить прошивку:

isdct.exe load -intelssd 5
WARNING! You have selected to update the drives firmware!
Proceed with the update? (Y|N): y
Updating firmware...

- Intel SSD DC S3710 Series BTHV519403VJ400NGN -

Status : Firmware Updated Successfully. Please reboot the system.

Тестирование NVMe SSD Intel P3608

2016-03-09T12:49:00.000+03:00

Что может быть лучше одного быстрого NVMe SSD Intel P3600? Только два P3600 в общем корпусе!
http://www.truesystem.ru/review/362929/

Установка Linux на диск 4KN

2016-02-24T11:51:00.001+03:00

В документации к SAS HBA Adaptec 7805H попалась интересная заметка:
When installing Linux in uEFI mode on a 4K sector drive, a 200MB /boot/efi partition is allocated, by default. For some drives, this amount of space is not sufficient. For example, Seagate 4K sector drives work only with 4096MB for the /boot/efi partition.
Краткий перевод с пояснениями:
При установке Linux на диски 4KN (с физическим и логическим сектором 4 КиБ, подробнее про Advanced Format: «Диски, контроллеры, ОС и Advanced Format») по умолчанию создается системный раздел EFI (см. EFI system partition) размером 200 МиБ. Для некоторых 4KN дисков, например, Seagate, размер этого раздела необходимо увеличить до 4096 МиБ.

Новые продукты в линейке блейд-серверов Supermicro

2015-09-02T14:05:00.000+03:00

Вчера компания Supermicro анонсировала сразу несколько новых продуктов в линейке обычных блейд-серверов и в линейке MicroBlade.
Начнём с долгожданного GPU-blade для шасси 710/720 под процессоры Intel Xeon E5-2600 V3. Как вы помните по новым TwinBlade, в Supermicro из-за нехватки места решили отказаться от сменных контроллеров 10GbE и Infiniband, и теперь они распаяны на плате. С новым GPU-blade из-за тесной компоновки произошла та же история. Есть три модификации:

SBI-7128RG-X — 2 порта 10GbE
SBI-7128RG-F — один порт 56Гбит FDR Infiniband
SBI-7128RG-F2 — два порта 56Гбит FDR Infiniband

Стандартная пара гигабитных портов традиционно присутствует во всех модификациях.

Остальные характеристики:

Два процессора Intel Xeon E5-2600 V3 с TDP до 145 Вт
8 слотов DIMM, до 256 ГБ DDR4 ECC RDIMM
Возможность установки двух карт Nvidia K80/40/20/10, M60, K1/K2 или Intel Xeon Phi или четырёх обычных полноразмерных карт PCI-E 3.0 x8
Возможность установки до 8 дисков 2.5" вместо карт расширения
1 диск 2,5" + 1 SATA DOM или 2 SATA DOM

Компоновка при установке GPU:

Компоновка при установке обычных плат:

Компоновка при установке дисков:

Разумеется, можно совмещать установку различных компонентов. Например, поставить один GPU и четыре дополнительных диска.

Продукт номер два — новое шасси SBE-720F-R96. От текущего SBE-720F-R90 отличается блоками питания по 3200 Вт с сертификацией 80Plus Titanium вместо 3000 Вт.

Следующий продукт — компактное шасси высотой в 3U для серверов MicroBlade:

Шасси MBE-314E-420/416 решит сразу две проблемы:
Спрос на MicroBlade был не очень высоким. Необходимость в максимальной плотности размещения (шасси высотой 6U под 28 блейд-серверов) существует, в основном, лишь у крупных современных датацентров.
Для относительно небольших проектов существует линейка MicroCloud — 8/12/24 однопроцессорных серверов в корпусе 3U. Но у MicroCloud есть ряд недостатков, связанных с тем, что данная линейка не соответствует концепции блейд-серверов:

Отсутствие модульных свитчей. Как следствие — высокая плотность размещения кабелей. Для платформ "24-в-1" получается 48 кабелей в 3U. Не очень много, но нужно ещё обеспечить беспрепятственное извлечение серверных модулей.
Отсутствие взаимозаменяемости серверных модулей. Supermicro не гарантирует совместимость серверных модулей между платформами разных поколений (5037 и 5038). Плюс разные форм-факторы — "8-в-1" и "12/24-в-1".

Компактный MicroBlade может решить обе проблемы:

Серверные модули унифицированы, в одном шасси могут существовать разные блейд-серверы.
Модульные 10GbE свитчи существенно упрощают монтаж и обслуживание.

Появление шасси MBE-314E-420/416 и новых серверов под Xeon E3-1200 v5 ожидается в октябре этого года.

Обзор серверных SSHD Seagate TurboBoost

2015-08-04T11:56:00.000+03:00

См. на нашем сайте.

Adaptec vs LSI, точнее PMC vs Avago

2015-07-16T16:36:00.000+03:00

Новая статья на нашем сайте: Выбор контроллера SAS.

Контроллер Adaptec 6/6E виснет под ESXi 5.x

2015-07-06T12:21:00.001+03:00

Подробное описание давно известной проблемы с контроллерами Adaptec by PMC серий 6 и 6E под ESXi появилось в базе знаний Adaptec.
Краткая суть бага: в системах с процессорами Intel Xeon E5-2600v2 под управлением ESXi 5.5 (наши клиенты сообщали о существовании проблемы под любой веткой 5.x) с контроллерами Adaptec 6/6E происходит периодическое зависание. Либо полное с PSOD, либо остановка дисковой подсистемы.
Причина: драйвер aacraid использует устаревшую обработку прерываний вместо MSI.
По ссылке — описание процесса обновления драйвера (установка из vib) и добавление параметра, принудительно включающего MSI.

Обзор Toshiba PX03SN и PX02SM

2015-06-16T13:51:00.002+03:00

См. на нашем сайте.

Обзор SSD HGST Ultrastar SSD1600MR

2015-03-25T18:22:00.000+03:00

Обзор на нашем основном сайте.

Читайте нас на Хабре!

2015-03-25T18:16:00.001+03:00

Помимо основного сайта True System некоторые интересные статьи будут публиковаться на Habrahabr'е. Пока что их две:
Обзор СХД DotHill 4824
Диски, контроллеры, ОС и Advanced Format
Что-то конечно, по-прежнему будет появляться и тут, на Blogspot'е, но проблема с неработающими уведомлениями о комментариях уже давно раздражает.

Обзор SSD Kingston E50

2014-12-18T13:15:00.003+03:00

Очередной обзор SSD на нашем основном сайте: http://www.truesystem.ru/review/360953/
По просьбе трудящихся — дополнительные графики. Два последних пункта в легенде: блоки с 50% содержанием сжимаемых данных (по умолчанию — просто нули, SandForce SF-2581 умеет сжимать данные, больше IO помещается в кэш, и как следствие растёт производительность). Ешё добавлен результат с O_DSYNC (direct=1 вместе sync=1 в fio, фиолетовый график).

Обновление от 29.12.2014: дополнительный тест Host Idle Recovery из SNIA PTS Enterprise 1.1. Наглядно показывает способность SSD использовать свободное время для сборки мусора и очистки кэша. Перед основным тестом идут две подготовительных ступени: последовательная запись 128КиБ до достижения 2-кратной ёмкости и случайная запись блоками 4КиБ в течение 120 минут (25 минут, предложенных в официальной спецификации явно не хватает для выхода на установившееся состояние) — это соответствует предыдущему тесту Write Saturation Test, производительность с 14000 IOPS падает до 2000:

Каждый из цветных участков на следующем графике (State 1 AB, State 2 AB и т.д.) соответствует 360-ти раундам, состоящим из 5 секунд нагрузки (всё та же случайная запись 4КиБ) и простоя длительностью 5, 10, 15, 25, 50 секунд соответственно. Чёрные участки (State x C) — 360 5-секундных раундов с нагрузкой, но без пауз:

Заметно, что уже на первом участке (State 1, 5+5 секунд) Kingston E50 успевает выйти из насыщения и восстановиться с 2000 IOPS до 15-20 тысяч. Чем больше время паузы, тем более стабильным становится значение IOPS — SSD за это время успевает подготовить определённое количество чистых блоков и частично освободить кэш. На графиках средней и максимальной задержки видна аналогичная ситуация:

Сравнение редакций Windows Server 2012 R2

2014-11-19T13:26:00.000+03:00

Документ лежит тут: http://www.microsoft.com/en-us/download/details.aspx?id=41703&WT.mc_id=rss_alldownloads_all
Примечателен тем, что помимо редакций, доступных в обычном канале, описаны Windows Storage Server Standard и Workgroup.

Как устроен Storage Spaces

2014-11-18T12:20:00.000+03:00

С ноября 2014 года большая часть объёмных статей будет размещаться на основном сайте True System. В техническом блоге останутся небольшие заметки и какие-нибудь детальные case study.
Вот и новый материал — статья о Storage Spaces: как устроен, как используется, как быстро (или не очень) работает, как правильно его готовить.