Мы с командой вот уже 10 лет вполне успешно пилим систему поведенческого анализа сетевого трафика PT Network Attack Discovery (PT NAD). Продукт выявляет аномальные сетевые активности и сложные целенаправленные атаки на периметре и внутри сети организации. Он захватывает трафик со скоростями 100 Мбит/с — 10 Гбит/с, индексирует и хранит его в виде исходной копии в формате PCAP. Оператор SOC может всегда заглянуть в PT NAD, провести анализ сообщений сетевых протоколов (IPv4, IPv6, ICMP, TCP, UDP, HTTP, DNS, NTP, FTP, TFTP) и расследовать атаку. Но это лирическое начало.
Однажды к нам обратился клиент с проблемой: имеется 2 HDD с производительностью записи 250 MБ/с. Из них делается хранилище RAID 0. Начинаем записывать трафик, скорость — 350 MБ/с. Он успешно пишется, но через некоторое время утилизация дисков подходит к 100% и начинаются потери при записи. Вывод клиента: проблема в PT NAD, так как диски должны все успевать. Думаю, многие уже догадываются, в чем соль. У нас тоже имелись догадки, но тем не менее мы решили их проверить. Из этой проблемы и родилось небольшое исследование по записи трафика в хранилище. Под катом — наше расследование «заговора» разработчиков HDD.
Запись трафика
В PT NAD сетевой трафик разбирается на сессии — соединения TCP/UDP/ICMP и т. д.
О сессиях хранится метаинформация: начало и конец соединения, количество переданных данных, используемые протоколы и другие данные, которые помогают при расследовании атак. Кроме того, весь сетевой трафик сессии сохраняется в хранилище в неизменном виде. Это позволяет пользователям PT NAD скачивать дампы конкретных соединений в формате PCAP для более подробного анализа и изучения с помощью сторонних приложений, например Wireshark.
Вот пример карточки сессии.
Под хранилище сессий обычно используется массив HDD, дампы заполняют 90% предоставленного места, а затем начинается процесс ротации: старые сессии удаляются, чтобы в хранилище всегда было 10% свободного места. Таким образом, в хранилище всегда присутствуют сессии за последние N дней. N зависит от объема хранилища, а также от объема поступающего в PT NAD сетевого трафика.
Сессии в хранилище объединяются в файлы размером примерно по 1 ГиБ, запись в файлы происходит последовательно блоками по 2 МиБ, используется Direct I/O (флаг открытия файла O_DIRECT). Имеются небольшие индексные файлы для поиска конкретной сессии в файле с трафиком.
Хранилище должно успевать записывать поступающий трафик. Так, при скорости трафика 10 Гбит/с хранилище должно выдавать стабильные 1,25 ГБ/с и более на запись, иначе часть трафика потеряется и не будет доступна для скачивания пользователем.
Сразу проговорим, почему мы не рассматривали SSD для хранения трафика. Теоретически SSD должны быть быстрее HDD, но серверные SSD сильно выше по цене, а для хранения трафика их требуется много: обычно это десятки терабайт. Кстати, на Хабре уже обращали внимание на недостатки SSD (см, например, https://habr.com/ru/articles/154235/ и https://habr.com/ru/companies/yadro/articles/716220/).
Подготовка к тестированию
Для исследования проблемы у нас имелся сервер с 8 дисками по 8 ТБ. Диски одинаковые, в характеристиках указана скорость записи 255 MБ/с. Из них через аппаратный RAID-контроллер (кэш RAID был включен) был собран массив RAID 6 полезной емкостью 48 ТБ.
Так как данные пишутся достаточно большими блоками и последовательно, у нас должны получаться full stripe writes. И теоретическая скорость записи в этот массив должна достигать 255 MБ/с × 6, то есть приблизительно 1,5 ГБ/с. Сравнение характеристик разных видов RAID можно посмотреть в сводной таблице: https://en.wikipedia.org/wiki/Standard_RAID_levels#Comparison.
Для тестов в качестве «сети» используется двухпортовая сетевая карта, в один порт проигрывается трафик с помощью tcpreplay, второй — слушает PT NAD.
На сервере был развернут PT NAD в ограниченном режиме, а там отключено все, кроме непосредственно записи дампов в хранилище. Для эмуляции трафика использовался tcpreplay + netmap.
sudo tcpreplay -K -i ens2f0 --topspeed -l 0 --netmap --nm-delay=5 --unique-ip /home/administrator/pcaps/syslog_1mb.pcap
Получившаяся скорость трафика по информации от tcpreplay: 9832,78 Мбит/с, 2490070,41 пак/с.
На хранилище создан раздел файловой системы (FS) ext4.
Тестирование
С такими параметрами оставили сервер примерно на сутки, и вот что получилось.
DPI traffic, DPI drops — статистика по захвату трафика до обработки и записи.
PCAP writer — статистика по записи дампов в хранилище.
PCAP writer buffers use — статистика по используемым буферам записи (здесь видно, что когда они заканчиваются, то хранилище не успевает записывать поступающие объемы и появляются дропы записи).
IO Bytes, IO counts, IO utilization — IO-статистика по хранилищу от Linux.
Free disk space — показатель того, что хранилище заполняется и держится на отметке 10% свободного пространства.
На графиках мы видим циклы по скорости записи в хранилище: примерно 4 часа оно успевает записывать все, а затем в течение нескольких часов нарастает отставание скорости записи от скорости трафика. Затем цикл повторяется снова.
Чтобы убедиться, что такое проседание скорости записи — это не особенность PT NAD, хранилище было протестировано утилитой fio. На сервере стояла версия fio 3.25, и, как оказалось, в ней присутствуют некоторые баги. В дальнейшем был собран fio-3.36 из исходников, и в нем все работает как ожидается.
Подобрали конфиг fio, чтобы запись была похожа на таковую в PT NAD:
[write-test]
ioengine=libaio
rw=write
bs=2048k
iodepth=8
fallocate=truncate
direct=1
filesize=1073741824
nrfiles=10000
openfiles=12
group_reporting=1
numjobs=2
unique_filename=1
directory=/pcaps/fio_testsЗапустили тест, где два процесса пишут по 10 ТБ каждый. И вот что получилось.
В отличие от PT NAD, fio не ограничен входящим трафиком и пишет с максимальной скоростью. Здесь хранилище уже не было пустым, и в начале теста скорость была в районе 1,3 ГБ/с. А затем начала проседать вплоть до 660 MБ/с.
PT NAD достаточно оптимально использует диск, и утилита fio не показывает каких-то значительно более высоких результатов по сравнению с PT NAD. Fio показывает скорость повыше в начале цикла, но тут у PT NAD упор в трафик: tcpreplay выдает ≈1,25 Гбит/с, не более.
При этом теоретические 1,5 ГБ/с достигаются утилитой fio на пустом хранилище, но через некоторое время скорость также падает.
Было решено попробовать другую файловую систему, на хранилище была развернута XFS. Запустили подобный тест PT NAD, и вот что получилось.
Тоже есть колебания, но не такие значительные.
Если смотреть среднюю скорость записи за сутки, то и на ext4, и на XFS она получается около 1 ГБ/с, что недостаточно для трафика 10 Гбит/с, если писать его полностью на диск (нужны стабильные 1,25 ГБ/с). При этом теоретическая скорость записи на диски в RAID 6 должна быть 1,5 ГБ/с.
XFS в целом показала себя стабильнее. Нет просадок в два раза, но и изначальная скорость меньше.
Решили протестировать в других конфигурациях. Разобрали рейд, настроили запись в каждый диск отдельно, 2 ext4, 3 XFS, 3 ZFS (без сжатия). На каждый диск попадает примерно 156 МБ/с.
Вот что получилось.
ext4:
XFS:
ZFS:
Как видим, на всех файловых системах есть циклы. Когда утилизация диска составляет 100%, присутствуют дропы по записи.
ext4 и XFS в индивидуальном зачете практически на равных, но у ext4 один длинный цикл понижения производительности, а у XFS — два более коротких. При этом в RAID 6 XFS был более стабильным. ZFS показывает более высокий IO utilization в целом.
Был также протестирован RAID 0, где теоретическая скорость записи должна быть выше, чем в RAID 6. А точнее, количество дисков умножить на производительность одного диска. В нашем случае это целых 2 ГБ/с.
Вот результат.
Но в какие-то моменты даже RAID 0 не успевает записывать весь трафик. Был также протестирован RAID 10, но там скорость записи еще ниже.
HDD и физика
Тут пора вспомнить про устройство HDD. Грубо говоря, он представляет собой вращающийся блин, на котором в плоскости по направлению вращения есть дорожки с данными.
Если взять отдельный HDD и начать его заполнять от начала и до конца, то скорость записи проседает по мере заполнения диска. Скорость зависит от того, в какое физическое место на диске мы пишем.
На внешней дорожке диска каждый сектор с данными вращается быстрее, и сама дорожка вмещает больше секторов, и скорость записи/чтения быстрее. А по мере приближения к центру диска вращение каждого сектора медленнее и секторов в кольце меньше. Тут имеется в виду линейная скорость вращения отдельных точек на дорожке.
[https://en.wikipedia.org/wiki/Hard_disk_drive_performance_characteristics#Data_transfer_rate]
В нашем хранилище этот эффект проявляется в виде тех самых циклов скорости записи. Это также можно проверить утилитой dd, если писать на диск, минуя файловую систему, при этом подбирая разные смещения и тем самым попадая в разные физические места на диске.
Обычно на всех дисках нулевое смещение: самое внешнее кольцо — самое быстрое. И чем больше смещение, тем ближе к центру диска мы попадаем. Именно так, а не наоборот, когда сектора начинаются с внутреннего кольца, так как обычно в начале устанавливается ОС, она и попадает на внешние дорожки. При этом кажется, что диск очень быстрый.
Мы протестировали одиночный диск 8 ТБ на нашем сервере. Использовали утилиту dd с флагами: direct — для прямой записи, минуя кэш Linux, seek_bytes — для выбора смещения на диске. Пример запуска:
seek_bytes |
Write speed |
Примечание |
0 |
264 МБ/с |
Запись в начало диска |
4000000000000 |
227 МБ/с |
Запись в середину диска по объему, но, так как на внешних кольцах помещается больше данных, чем на внутренних, по радиусу это ближе к внешней границе. Чем дальше к концу диска, тем медленнее доступ |
6000000000000 |
189 МБ/с |
|
7000000000000 |
156 МБ/с |
|
7700000000000 |
133 МБ/с |
Запись в конец диска |
Как видим, скорость записи варьируется от 133 до 264 МБ/с, то есть разница почти в два раза!
Вообще, эти наблюдения касаются как скорости записи, так и чтения. В нашем случае нас интересовала запись, и мы тестировали только ее.
Когда мы пишем через файловую систему (FS), то уже она решает, сколько и по каким смещениям писать, но снижения скорости на внутренних дорожках при этом все равно не избежать. Теоретически, если мы всегда оставляем какой-то процент свободного места, то файловая система должна делать так, чтобы это пространство было в конце по смещению, то есть в центре диска физически. Тогда эта деградация записи будет не так сильно заметна. Но разные файловые системы по-разному себя ведут.
Как могла бы делать FS:
Заполняем диск на 90%. По мере заполнения скорость записи медленно падает. Когда доходим до планки в 90%, начинают удаляться самые первые файлы, файловая система начинает писать новые данные на их место. Получается скользящее окно по диску, где самые медленные внутренние 10% по объему не задействованы. Это если говорить о записи на один диск. В случае использования RAID ситуация становится более сложной.
Файловая система также может начинать писать с середины диска, постепенно уходя от нее на внешние и внутренние дорожки, тогда скорость записи была бы более стабильной.
Клиенты смотрят в спецификации на диск и видят что-то вроде этого.
Или этого.
Это скриншоты из официальных спецификаций на диски Seagate и WD.
При этом в сноске у WD написано:
Up to stated speed. 1 MB/s = 1 million bytes per second. Based on internal testing; performance may vary depending upon host device, usage conditions, drive capacity, and other factors
По спецификациям может сложиться впечатление, что эта скорость будет постоянной. Но на самом деле никто не гарантирует, что указанная скорость будет достигаться на всем диапазоне свободного пространства.
Скрипт для тестирования скорости записи на диск
Для быстрой проверки эффекта замедления хранилища на языке Python был написан скрипт-обертка над dd, который делает тестовые записи данных в разные участки диска от начала до конца и выводит результаты.
Список доступных девайсов в системе можно посмотреть через lsblk. Обратите внимание, что прямая запись через dd сломает файловую систему и данные в хранилище. Поэтому тестируйте только тогда, когда вам не жалко потерять все хранящиеся там данные.
Пример запуска на одном из наших тестовых хранилищ: 10 дисков по 4 ТБ в RAID 6
$ ./test_storage.py -d /dev/sda --yes
seek=0 (0.0%): 20971520000 bytes (21 GB, 20 GiB) copied, 12.6719 s, 1.7 GB/s
seek=1600090065920 (5.0%): 20971520000 bytes (21 GB, 20 GiB) copied, 12.4469 s, 1.7 GB/s
seek=3200180131840 (10.0%): 20971520000 bytes (21 GB, 20 GiB) copied, 12.6146 s, 1.7 GB/s
seek=4800270197760 (15.0%): 20971520000 bytes (21 GB, 20 GiB) copied, 12.6342 s, 1.7 GB/s
seek=6400360263680 (20.0%): 20971520000 bytes (21 GB, 20 GiB) copied, 13.0093 s, 1.6 GB/s
seek=8000450329600 (25.0%): 20971520000 bytes (21 GB, 20 GiB) copied, 13.1088 s, 1.6 GB/s
seek=9600540395520 (30.0%): 20971520000 bytes (21 GB, 20 GiB) copied, 13.3502 s, 1.6 GB/s
seek=11200630461440 (35.0%): 20971520000 bytes (21 GB, 20 GiB) copied, 13.6182 s, 1.5 GB/s
seek=12800720527360 (40.0%): 20971520000 bytes (21 GB, 20 GiB) copied, 13.9915 s, 1.5 GB/s
seek=14400810593280 (45.0%): 20971520000 bytes (21 GB, 20 GiB) copied, 14.3044 s, 1.5 GB/s
seek=16000900659200 (50.0%): 20971520000 bytes (21 GB, 20 GiB) copied, 14.6606 s, 1.4 GB/s
seek=17600990725120 (55.0%): 20971520000 bytes (21 GB, 20 GiB) copied, 14.9608 s, 1.4 GB/s
seek=19201080791040 (60.0%): 20971520000 bytes (21 GB, 20 GiB) copied, 16.3047 s, 1.3 GB/s
seek=20801170856960 (65.0%): 20971520000 bytes (21 GB, 20 GiB) copied, 16.2788 s, 1.3 GB/s
seek=22401260922880 (70.0%): 20971520000 bytes (21 GB, 20 GiB) copied, 16.8956 s, 1.2 GB/s
seek=24001350988800 (75.0%): 20971520000 bytes (21 GB, 20 GiB) copied, 17.8074 s, 1.2 GB/s
seek=25601441054720 (80.0%): 20971520000 bytes (21 GB, 20 GiB) copied, 18.8904 s, 1.1 GB/s
seek=27201531120640 (85.0%): 20971520000 bytes (21 GB, 20 GiB) copied, 20.1645 s, 1.0 GB/s
seek=28801621186560 (90.0%): 20971520000 bytes (21 GB, 20 GiB) copied, 21.9175 s, 957 MB/s
seek=30401711252480 (95.0%): 20971520000 bytes (21 GB, 20 GiB) copied, 23.0649 s, 909 MB/s
seek=31980829802496 (99.9%): 20971520000 bytes (21 GB, 20 GiB) copied, 25.0934 s, 836 MB/s
Как видим, на RAID принцип записи такой же. Самая быстрая часть располагается в начале, а самая медленная — в конце. При этом в самом конце емкости RAID скорость записи в два раза меньше, чем в начале.
Вот сам скрипт.
#!/usr/bin/env python3
import subprocess
import re
import os
import json
from argparse import ArgumentParser
def shell_exec(cmd: str):
proc = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, encoding='utf-8', shell=True)
ret_code = proc.wait()
if ret_code != 0:
raise RuntimeError(f'"{cmd}" return {ret_code}')
return proc.communicate()
def get_device_size(dev: str):
stdout, stderr = shell_exec(f"blockdev --getsize64 '{dev}'")
return int(stdout)
def maybe_wipe_fs(dev: str, warning: str):
print(warning)
print(f'Script WILL DESTROY the file system, partitions or any data on testing device.')
agree = input("Are you sure you want to continue (yes/no)? ")
if (agree != 'yes'):
raise RuntimeError('aborted')
shell_exec(f"wipefs --all '{dev}'")
def is_mounted(cmd: str, device: dict):
NOT_FOUND = object()
mnt = device.get("mountpoints", device.get("mountpoint", NOT_FOUND))
if mnt == NOT_FOUND:
raise RuntimeError(f'Failed to get device mountpoint, check: "{cmd}"')
if mnt not in ([], [None], None):
return True
if device.get("children") not in ([], [None], None):
for child in device.get("children"):
if is_mounted(cmd, child):
return True
return False
def check_device(dev: str):
cmd = f"lsblk -J -i '{dev}'"
stdout, stderr = shell_exec(cmd)
data = json.loads(stdout)
if "blockdevices" not in data or len(data["blockdevices"]) != 1:
raise RuntimeError(f'Failed to get blockdevice, check: "{cmd}"')
device = data["blockdevices"][0]
if device.get("type") != "disk":
raise RuntimeError(f'Device is not disk, check: "{cmd}"')
if is_mounted(cmd, device):
raise RuntimeError(f'Device "{dev}" is mounted, check: "{cmd}"')
if device.get("children") not in ([], [None], None):
maybe_wipe_fs(dev, f'Disk device have children (partitions), check: "{cmd}"')
cmd = f"file --special-files '{dev}'"
stdout, stderr = shell_exec(cmd)
if stdout.strip() != f'{dev}: data':
maybe_wipe_fs(dev, f'Device "{dev}" possible contains filesystem, check: "{cmd}"')
def parse_dd_size(size: str):
# parse subset of possible suffixes of dd tool
units = {"K": 2 ** 10, "KB": 10 ** 3,
"M": 2 ** 20, "MB": 10 ** 6,
"G": 2 ** 30, "GB": 10 ** 9,
"T": 2 ** 40, "TB": 10 ** 12}
match = re.fullmatch(r'([0-9]+)([KMGT]B?)?', size)
if not match:
raise RuntimeError(f'Failed to parse bs "{size}"')
number, unit = match.group(1), match.group(2)
result = int(number)
if unit is not None:
result = result * units[unit]
return result
def make_step(args, seek: int, dev_size : int):
dd_cmd = f'dd if=/dev/zero of="{args.device}" bs={args.bs} count={args.bc} oflag=direct,seek_bytes seek={seek}'
stdout, stderr = shell_exec(dd_cmd)
percent = seek / dev_size * 100
out = stderr.split(sep='\n')[2]
print(f"seek={seek} ({percent:.1f}%): {out}")
def check_is_positive(name: str, val: int):
if val <= 0:
raise RuntimeError(f'"{name}" must be greater then 0')
if __name__ == "__main__":
try:
parser = ArgumentParser(description='Storage test. Script WILL DESTROY the file system, partitions or any data on testing device!')
parser.add_argument('device', help='device for test, i.e /dev/sdb')
parser.add_argument('--bs', help='block size for dd. Default is 2M.', default='2M')
parser.add_argument('--bc', help='block count for dd. Default is 10000.', type=int, default=10000)
parser.add_argument('--steps', help='number of steps exclude last. Default is 20.', type=int, default=20)
parser.add_argument('--alignment', help='alignment of write operations. Default is 1024.', type=int, default=1024)
args = parser.parse_args()
args.bs = parse_dd_size(args.bs)
check_is_positive("bs", args.bs)
check_is_positive("bc", args.bc)
check_is_positive("steps", args.steps)
check_is_positive("alignment", args.alignment)
if os.geteuid() != 0:
raise RuntimeError('Script must be run as root')
check_device(args.device)
dev_size = get_device_size(args.device)
for step in range(0, args.steps):
seek = step * (dev_size // args.steps)
seek = seek - (seek % args.alignment)
make_step(args, seek, dev_size)
write_size = args.bs * args.bc
last_seek = dev_size - write_size
last_seek = last_seek - (last_seek % args.alignment)
make_step(args, last_seek, dev_size)
except Exception as ex:
print(f'ERROR: {ex}')
exit(1)
except KeyboardInterrupt as ex:
print(f'\nERROR: interrupted')
exit(1)Выводы
Скорость записи в хранилище на HDD непостоянна. Нельзя полагаться на спецификации и теоретические расчеты, необходимо перепроверять производительность.
Имея хранилище на десятки терабайт, нельзя записать в него пару десятков гигабайт и надеяться, что полученная скорость записи будет всегда достижима. В идеале нужно провести тест на полное заполнение хранилища, и уже исходя из этого будет понятна средняя, минимальная и максимальная скорость записи.
Если вам нужно писать поток данных с ротацией и без потерь, то скорость потока данных не должна превышать минимальную скорость записи. Если необходима более высокая скорость, то советуем создавать более мощный RAID из большего количества дисков с большей производительностью.
При использовании утилит для тестирования производительности нужно понимать, что они делают, чтобы не получить бесполезные результаты. В утилитах бывают баги, и даже при правильном использовании нужно убедиться, что тестируется то, что надо, и как надо.
На этом наше расследование по HDD — всё. Нашу задачу по записи больших объемов трафика мы если не решили, то нашли источник проблемы, а это уже главное. А с какими проблемами при записи трафика сталкивались вы? Поделитесь в комментариях под статьей!
Алексей Сагин
Разработчик PT NAD в Positive Technologies
Комментарии (86)
NikaLapka
20.02.2025 10:25Поколение Z разработчиков открыло для себя HDD. Интересно, если им дать грампластинку и спросить, почему музыка звучит с одинаковой скоростью, от начала до конца.. Грустно всё это, а уж сколько воды в посте налили.
ajaxtpm
20.02.2025 10:25Ого, какой вы умный! Все знали заранее. А я вот не знал, статья супер, Алексей спасибо
konstanttin
20.02.2025 10:25Интересный конечно результат. Во времена, когда такие диски были в ходу, в журналах были графики с тестами скоростей. И очень странно, что прошло лет 15 и знание, что скорорость диска снижается оказалось утеряно.
SerjV
20.02.2025 10:25Да ладно, там же еще при описанной ситуации "утилизация дисков подходит к 100%" должно было триггернуть вопросом "а фрагментация свободного пространства у файловой системы тут не может влиять"?
DaneSoul
20.02.2025 10:25Так у них последовательная запись потоком идет, почему там должна возникнуть фрагментация?
stanislavskijvlad
20.02.2025 10:25Чисто к слову. Есть американский дядечка, который разбирает старую технику и объясняет, как она работает. Думаю, "они вам не пиксели" видели многие. Так вот, лазерные CD диски и приводы к ним устроены сложнее, чем рисуют на схемах. А по статье, что в ней такого нехорошего, аж Петросяны проснулись ? Как для расширения кругозора — почему нет.
Devastator82
20.02.2025 10:25Позвольте порекомендовать Вам книгу «Архитектура компьютера» Э. Таненбаума. Книга написана простым языком для широких масс (но при этом это не чтиво для домохозяек). Безусловно, книга не идеальна и имеет ряд недостатков, но доя расширения кругозора пойдет. Ее можно купить и в цифре и в бумаге за смешные для ее объема деньги. У пиратов она тоже находится без проблем.
LinkToOS
20.02.2025 10:25Поколение Z разработчиков открыло для себя HDD.
Так статья и предназначена для поколения Z, у кого первым диском был SSD. Да и для остальных полезное напоминание об особенностях HDD, в связи с тем что прогресс SSD идет с черепашьей скоростью, а потребность в объемах растет.
Ну и справедливый упрек в адрес производителей HDD, в том что они по прежнему указывают в характеристиках только максимальную скорость для внешней дорожки, и не указывают минимальную гарантированную скорость.
media808media
20.02.2025 10:25и не указывают минимальную гарантированную скорость
они её не знать тк угадать как будет использоватся носитель не могут а на тестах максимальной скорости пишут (через контролер девайса) самым быстрым способом которого у потребителя может и не быть
ahabreader
20.02.2025 10:25Он про то, чтобы добавить в характеристики ещё эту величину:
kma21
20.02.2025 10:25Как это назвать? Минимально гарантированная скорость записи? А я буду насыпать на дискрандомную запись минимальными блоками и без кеша. И получу скорость ещё меньше, чем минимально заявленная.
И можно будет диски обратно возвращать, мол, они неисправны.ahabreader
20.02.2025 10:25Как это назвать?
Так же.
Sustained transfer rate⁴ (MB/s,
maxmin)⁴ Based on internal testing ... location of the
maxmin rate is at approximately10%100% into the capacity of the HDD.От юридических солоночных хакеров отбиваться с помощью уже имеющегося "performance may vary depending on host environment, drive capacity, logical block address (LBA), and other factors" или добавить "sequential" в название величины.
vp7
20.02.2025 10:25Вы не поверите, но в спеках к дискам указывают даже seek time (avg, min, max) и много других интересных цифр.
При особом желании вы можете писать последовательно на максимально далёкие сектора (предварительно отключив кеш записи, если он есть) и получить с современного шпинделя восхитительную скорость уровня линейного чтения CD-ROM ;)
eimrine
20.02.2025 10:25Есть другая идея:
внимание на правую шкалу, которая отвечает за график жёлтым цветом Как назвать? Максимальный пинг при соблюдении условий:
Исправность поверхности и головки
Статическое положение диска и защита от собственной вибрации
Определённый размер вычитываемого блока (4кБ или 0.5кБ)
Нету пограничных ситуаций, которые могут заставить перечитывать блок больше одной попытки.
ahabreader
20.02.2025 10:25Идея устарела/устаревает вместе с дисками на 15K и 10K RPM, вместе с 2.5". "Random Read/Write: быстрее, чем у магнитной ленты", ну и ладно.
SerjV
20.02.2025 10:25Как назвать? Максимальный пинг
Это latency, "время выполнения запроса, задержка перед ответом".
И на неё помимо зоны на диске влияет (на таком тесте этого не увидеть в принципе) нагрузка на диск, т.к. запросы ставятся в очередь.
riv9231
20.02.2025 10:25Да если знать побольше о дисках, то например нужно учесть что скорость в реальных условиях при сильной фрагментации может падать почти до 0. И какую скорость надо писать? ноль? Наш диск точно записывает со скоростью больше 480КБ в секунду? (120 iops * 4К = 480КБ/сек). А 120 знаете откуда взялось? 7200RPM / 60 секунд в минуте, получается что диск делает ровно 120 оборотов в секунду. Значит при наиболее наудачном раскладе, он сможет совершенно точно спозиционировать головку 120 раз, и после каждого позиционирования будет ждать полного оборота диска уже на другой дорожке. Да иногда он бывает успевает за оборот на нескольких дорожках поработать, но ведь это уже не гарантированный результат.
SerjV
20.02.2025 10:25Угу, скандалы, интриги, расследования... А на выходе общеизвестный факт, об этом даже в Педивикии написано - "Влияние геометрии на скорость дисковых операций".
Впрочем, к чести автора - он на общедоступную информацию сослался в тексте. А не выдал за свежее открытие, как может показаться из некоторых комментариев. Но заголовок кликбейтный, ага )
Впрочем, это скорее о подходе "до нас ничего не существовало" (и забывая поговорку про то, что всё новое - это просто хорошо забытое старое) и разнице мышления у поколений, что, впрочем, на Хабре в других статьях обсуждается...
p.s. Но вот зря про IOPS не упомянули в статье, кстати. Он в ряде случаев важнее линейных скоростей.
ildarz
20.02.2025 10:25Вы зря так негативно настроены к авторам. Указанную проблему видел на практике далеко не каждый айтишник, даже знающий о ней. Знать теоретически - одно, получить на конкретном рабочем кейсе - другое, а уж доказать клиенту, что проблема не в вашем ПО, а в том, что он неправильно организовал хранилище данных - вообще третье. И вот именно о третьем текст.
SerjV
20.02.2025 10:25а уж доказать клиенту, что проблема не в вашем ПО, а в том, что он неправильно организовал хранилище данных
А уж как доказать клиенту, чтобы его еще и не обидеть - четвёртое.
А как при этом изложить так, чтобы не было смешно тем, кто имеет общее представление о компьютерном железе (а не только судит по тому железу, с каким лично он работал) - пятое...
Собственно, будь заголовок менее кликбейтным и будь пояснение о том, что тут не ставится целью срывать покровы с мирового заговора производителей дисков, но показать, как важно правильно проектировать хранилище - и реакция была бы другой.
Но тогда надо было бы еще и напомнить читателю, что IOPS важнее линейной скорости, и что надо разбираться с характером нагрузки (read iops, write iops / random iops, sequential iops). Про IOPS на Хабре даже что-то находится или тут.
Akina
20.02.2025 10:25То есть ждём РАЙД-контроллеры, которые будут учитывать описанный эффект и соответствующим образом смещать виртуальные начала дисков для обеспечения более-менее равномерности... а с учётом того, что набирающие популярность твердотельные диски такой ерунде не подвержены, уже даже и не ждём?
venanen
20.02.2025 10:25Ого, получится виртуальный вариатор, получается
blind_oracle
20.02.2025 10:25Японцы почти такой ставят на свои гибриды :) он просто работает в последовательном режиме: генерируем ток, расходуем его сразу мотором. Как Белаз, коробка и ремни не нужны.
13werwolf13
20.02.2025 10:25появилась дико упоротая идея
что если рейд (условный mdadm например для этого можно пропатчить) будет писать диски так:
допустим собираем зеркало из двух дисков одного объёма, первый пишется с начала в конец а второй с конца в начало, тогда график будет меньше проседать т.к. данные успевшие упать на тот диск который ближе к центру блина можно считать успешно записанными а на второй блин догонять их уже после. это не подойдёт для тех массивов где запись идёт постоянно с пиковой скоростью, и надёжность понижается, но там где скорость записи важнее сохранности это имеет смысл (если такие кейсы вообще существуют).
force
20.02.2025 10:25Если скорость записи важнее сохранности, то вам не нужно зеркало, вам нужен stripe.
А вообще проще использовать буферизованную запись, когда в памяти выделяется кеш и пишется в него, без всех этих странных заморочек
Jijiki
20.02.2025 10:25на FreeBSD есть geom, geom/ + возможно zones.intro-1/index.html(BSD подобные включая OpenSolaris) наверно связано с дисками(не уверен) раиды вроде да можно расчитать сколько в кластере раидов или на узле наверняка есть формула покрытия дисками(предположил), наверняка еще есть технологии какието, интересная статья
Lazhu
20.02.2025 10:25geom это класс блочных устройств
kekoz
20.02.2025 10:25Ну, справедливости терминологии ради, GEOM — это не класс, а целый фреймворк, и класс в нём — лишь одна из множества сущностей., которые тем или иным образом преобразует I/O запросы, и из которых можно выстраивать довольно затейливые иерархии.
Lazhu
20.02.2025 10:25My bad. Класс в смысле не подвид, а абстракция для низкоуровневой работы с любыми блочными устройствами. Я просто не люблю слово "фреймворк" ))
Jijiki
20.02.2025 10:25хочется добавить на Солярисе есть beadm которому нету аналога поидее на сколько я знаю, конкретно в той реализации лучше для действий и проще откатывать систему
Lazhu
20.02.2025 10:25В freebsd boot environments еще со времён солярисового zfs
Jijiki
20.02.2025 10:25долго обьяснять различие, технически да, на Фрибсд есть, но на Солярисе система будет безошибочной с этой утилой там вроде самый лучший юзкейс, из-за некоторых особенностей на ФриБСД вроде так же, но после Соляриса уже не так ощущается, это можно ощутить даже на OpenSolaris на ПК всю мощ этой утилы, по началу может показаться тормозной системой, но она крутая, помимо этой утилы много всяких штук удобных, почти не пользуешься конфигами ну или когда експерт пользуешься
zatim
20.02.2025 10:25Я что то пропустил? Вроде бы всегда во всех жестких дисках количество секторов на цилиндр - фиксированное? А ближе к центру просто плотнее запись. Древние диски даже имели провод включения предкомпенсации записи и номер цилиндра, с которого включалась компенсация - прописывался в биосе.
Это на CD дисках равномерная плотность записи и запись по спирали, как на грампластинке. И там да, по мере приближения к центру меньше "секторов" на "цилиндре", если можно так выразиться применительно к CD.
А описанный в статье эффект - это общеизвестный баг, связанный с черепичной записью SMR. И как раз запись сверхбольших файлов на диск - один из способов выяснить, черепичный диск или нет.
SerjV
20.02.2025 10:25Я что то пропустил? Вроде бы всегда во всех жестких дисках количество секторов на цилиндр - фиксированное?
Пишут, что физическая и логическая геометрия различается. В логической да, фиксированная, а в физической может быть как минимум 3 зоны - ближе к центру, посредине, ближе к краю, где количество секторов на дорожку разное (на внешней зоне выше, на внутренней ниже). Позволяет повысить плотность записи на "блин".
Физическую геометрию контроллер диска (который в самом диске имеется в виду) не показывает, кроме разве что в инженерных режимах (но это не точно ) ).
Lazhu
20.02.2025 10:25Начиная примерно с 90-х во всех дисках делают зонирование: соседние треки примерно одинаковой длины группируют в зоны. Внутри каждой зоны треки имеют одинаковое число секторов, чем дальше от центра, тем их больше. Скорость вращения, разумеется, везде одинакова, различается линейная скорость чтения (на внешних треках выше), и чтобы понять это, знать физику вовсе не обязательно. Но главная причина снижения скорости не в этом, а во времени переключения головки с одного трека на другой, и чем ближе к центру, тем эта операция производится чаще.
zatim
20.02.2025 10:25Ну, ок. Но тогда производитель, если рассуждать логически, должен указать в качестве максимальной скорости записи скорость в самой медленной, внутренней зоне. Как никак, это треть диска.
Lazhu
20.02.2025 10:25Три зоны только на картинке в википедии, чтобы самые бестолковые могли понять суть )) На самом деле их может быть сколько угодно (зависит от геометрии диска, производителя и т.п.)
Akina
20.02.2025 10:25производитель, если рассуждать логически, должен указать в качестве максимальной скорости записи скорость в самой медленной, внутренней зоне
Производитель должен одно - получить максимальную прибыль. При этом откровенно не врать. А не договаривать, выдавать максимальную скорость за гарантированную и так далее - ну за это же не бьют, а лохи, которые смотрят рекламу, а не тесты, не переводятся.
Ради интереса пробежался по даташитам нескольких попавшихся под руку хардов - везде дают Max. Sustained Transfer Rate или около того. Ни среднего, ни минимального, ни гарантированного и т.п. - нету. Производитель - он же не идиот. Он, с одной стороны, даст максимальную цифирь (ибо реклама), но, с другой, есть условия, при которых он покажет контролёру это значение (ибо "не врать").
riv9231
20.02.2025 10:25Ну и какое среднее писать, если известно что любой диск со скоростью вращения шпинделя в идеальном механическом состоянии можно затормозить до 480КБ/сек? А потом он стареет и эта скорость уменьшается почти до 0. При том что всегда можно подобрать нагрузку так, чтобы результат был ещё хуже. Что значить средняя скорость, если она зависит от нагрузки?
Коректнее говорить о линейной скорости в начале и количестве iops при случайном доступе. Так производители и не срывают этих характеристик, они есть в даташите.
riv9231
20.02.2025 10:25Уже очень давно диски не показывают ОС свою физическую геометрию, программно адресация идет по LBA-адрес сектора - одно число от нуля и до конца диска. Внутри же количество секторов разное на разном удалении от центра. Но об этом знает только контроллер диска.
YMA
20.02.2025 10:25Если что, количество зон с разным количеством секторов на трек на современных дисках измеряется десятками.
А в случае с SMR дисками и их ленточками - всё ещё интереснее, и пользователь даже знать не может, куда физически будет записан его яшмовый файл :))
Thomas_Hanniball
20.02.2025 10:25Сразу проговорим, почему мы не рассматривали SSD для хранения трафика.
Очень недальновидное решение. Вам нужен тиринг, т.е. разделение уровней хранения. Свежие данные мелкими блоками будут писаться на ssd диски enterprise уровня, которые обеспечивают стабильную скорость записи на всём своём протяжении. Затем более старые данные большими блоками будут переноситься с ssd на raid массив из hdd, где будет обычная линейная запись большими блоками.
В результате вся мелкоблочка будет на ssd, которые лучше для этого предназначены, а на hdd будет запись крупными блоками, причём это будет последовательная запись, где у hdd меньше всего проблем с просадкой скорости.
blind_oracle
20.02.2025 10:25В их случае тиринг удобнее делать из оперативки, а не через SSD как мне кажется. NAND всегда пишет достаточно большими блоками от 16кБ и выше, для мелких пакетов не очень подходит.
А если поставить достаточно памяти и писать большими блоками на диски из кольцевого буфера - будет вполне себе линейно.
ildarz
20.02.2025 10:25В результате вся мелкоблочка будет на ssd
Из текста статьи:
запись в файлы происходит последовательно блоками по 2 МиБ
А тиринг при плюс-минус равномерном потоке последовательной записи просто бессмысленен - HDD в любом случае либо будет переваривать поток, либо нет.
SerjV
20.02.2025 10:25потом пойдёт запись вместо старых данных - и вот тут ХЗ, возникнет фрагментация или нет (еще и от FS может зависеть).
А если эти данные не только пишут, а еще и читают - то в ситуации "сейчас пишем в начало диска, а вот читаем - в основном с конца" - IOPS сильно упадут...
Если только писать потоком данные как в каком-нибудь видеонаблюдении - то да, HDD или переваривают, или не перереваривают.
boxedkor
20.02.2025 10:25При использовании софтверных RAID в Linux с помощью mdadm можно задать принцип записи в RAID. Например, для RAID5 либо RAID6 можно указать чтобы данные на диски писались не всегда сначала на всех дисках, а, например, чтобы часть дисков начинала писать в начало, другая часть в конец, тем самым выравнивая скорость записи по всему объёму массива. ЕМНИП флаг --layout
4chemist
20.02.2025 10:25Ищу способ сделать рейд0 из двух одинаковых дисков чтобы блоки чередовались: нулевой на первом, последний на втором, первый на первом, предпоследний на втором и т.д. Это чтобы скорость в любом месте была приблизительно одинакова. Сохранность не важна.
mdadm --create --verbose /dev/md0 -l 0 -n 2 --layout=f1 /mnt/part0 /mnt/part1 mdadm: layout f1 not understood for raid0.layout не работает.
Busla
20.02.2025 10:25Максимальная скорость записи в RAID5 и RAID6 достигается при full stripe writes. Т.е. за одну операцию пишутся параллельно на все диски и большой блок данных и его контрольная сумма. Т.е. в каждой операции записи ждём самый медленный диск. Т.е. ваш вариант сделает весь массив таким же медленным , как конец обычного массива.
Sulerad
20.02.2025 10:25Как-будто, для этой задачи нужен очень специфичный рейд вида «записывать на быстрый диск два блока, пока на медленный пишется один», чтобы поддерживать среднюю скорость в три блока. Причём со временем соотношение скоростей будет меняться, так что придётся хранить кучу метаданных сверху.
Интересно, существуют ли уже подобные файловые системы .
ahabreader
20.02.2025 10:25расследование «заговора» разработчиков HDD
Чего не договаривают производители HDD
Что диски нельзя сушить в микроволновке...
___
Они указывают, что скорость - максимальная. Они рассказывают про уменьшение скорости на внутреннем радиусе. Упоминают на своих сайтах short-stroking*. Картинки из Victoria, HD Tune или AIDA64 в обзорах в интернете можно заметить. Эти же картинки из AIDA64 показывают, что там у SSD после исчерпания SLC-кэша, можно по аналогии задуматься про HDD. Также вопросов не будет, если знать про ухудшение звука у пластинок на внутреннем радиусе. Или про деление дисков любых видов на CLV и CAV (constant linear velocity и constant angular velocity). Или про дефрагментаторы на винде**.
* То есть уменьшение ёмкости HDD, чтобы уменьшить ход блока головок. Это в первую очередь про случайное IO, но линейное тоже растёт (внутренняя часть пластин не используется). В бытовом варианте можно место за первым разделом не выкидывать, а класть туда менее горячие данные.
** Прикольная оптимизация, продвинутую дефрагментацию объявляли ненужной скорее по принципу "нет на Linux - значит не нужно (а если появится, то станет нужно)".
Jijiki
20.02.2025 10:25Linux это не ОС, интересно как бы были теже тесты именно на ОС, с настроенной конкретностью как это должно быть для СХД, потомучто порой есть отличия как не крути. может дело в какихто тонкостях помимо ЖДшек, может есть то как конфигурируют на ОС определенные нюансы, может есть + к ЖД наблюдениям какие-то подходы, реализация ZFS на линукс ок, вот я например не пользуюсь на ПК ZFS/btrfs на линукс, пользуюсь ext4, но я не сервер и мне этого достаточно, а вот на ФриБСД пускай и ПК ZFS, на Соляре соотв их фс и вот так по крупицам приходят нюансы, а просто ЖД наблюдать ок, вопрос достаточно критичный Линукс тогда должен поддерживаться, поддержка должна быть, летать по форумам? по таким вопросам, потом далее, никаких роллинг дистрибутивов и вот уже отпадает большая часть линуксов и становится понятен вопрос, потомучто помимо обновления нужна поддержка и это критический вопрос, которого может не быть просто у линукса
и репозитории могут не помоч в поддержке, хотя безусловно удобно, но когда линукс поставляется так как сейчас, и разделен на части это проблема
Jijiki
20.02.2025 10:25еще как вариант, что можно добавить, есть сессия, помимо виртуализации, кластеров и прочего, можно подумать как делать так чтобы траффик квантовался(предположение, самоделился и самособирался или долинковывал куски ) на нужное количество ниток в зависимости от его длинны, и писался в 1 хранилище при отключении соединения или писался частями, видимо да моментов много в этом деле, часть этой реализации у вас есть, у вас есть контейнер, и во время сессии пишется контейнер, а контейнер можно делить и писать частями или предзаписывать частями, тоесть он может передаваться последовательно по 1 на сессию, а может не по 1 а нескольким ниткам на сессию, если это критичное что-то, например балансировка записи на диск посредством софта(это всё предположение и сравнение с одной утилитой)
возможно какието ОС или решения Ентерпрайз уже учитывают это, а может это невозможно но наверняка есть какието тонкости с большим размером обьема данных и запись на них, тоесть 100 терабайт(1 для всех а значит это условия для баланса, а может нет, интересно как это професионалами решается )), и прочее
MonkeyClicker
20.02.2025 10:25Какие замечательные люди работают в Positive Technologies. Можно быть уверенным, что их продукты созданы исключительными профессионалами в своей области. Автор, пишите еще о своих чудных открытиях, мы будем ждать с нетерпением. А так же мотивируйте коллег поделиться жизненным опытом, у них наверняка есть что рассказать.
HarryBlackMan
20.02.2025 10:25Следующим открытием будет черепичная запись и ее влияние на скорость диска?
Sau
20.02.2025 10:25Не обязательно же всё в одной области. Можно открыть что ЭЛТ монитор мерцает, и почему эти герцы называют частотой развёртки.
А также что за странная фиговина означает "сохранить".
Fasterpast
20.02.2025 10:25Кто не застал, можете ещё про CLV и CAV у оптических дисков почитать, не так уже актуально, но тоже любопытно может быть )
A-xyz
20.02.2025 10:25Странное ощущение возникло к концу прочтения статьи, но когда прочитал первые же комментарии - успокоился. И да, нет никакого заговора.
Itkir
20.02.2025 10:25И теоретическая скорость записи в этот массив должна достигать 255 MБ/с × 6, то есть приблизительно 1,5 ГБ/с.
У товарищей явные проблемы с теорией о RAID6.
Sau
20.02.2025 10:25Это маркетинговая скорость записи. Ведь в целом можно утверждать что они пишут данные, и суммарная скорость записи именно такая.
YMA
20.02.2025 10:25Поёрничать...
Ждём статью: "Мы использовали в проекте RAMdisk - но после перезапуска сервера данные там терялись, вы не поверите, но...." :)
hrusha
20.02.2025 10:25Это что, ждём статью про то что ЭЛТ мониторы быстрее, контрастностнее, любых современных LCD или OLED
force
20.02.2025 10:25Мы воспользовались mc для просмотра файлов и увидели, что у нас все файлы в двух копиях (левой и правой). Одну из копий мы решили удалить, но оказалось, что создатели mc не договаривают одну очень важную вещь.
Ig_B
20.02.2025 10:25Кто помнит влияние параметра "Interleave" при форматировании жесткого диска на скорость чтения?
galaxy
20.02.2025 10:25Ух, какие вы молодцы! Профессионалы.
Успехов вам в нелегком деле уничтожения рунета.
andersong
20.02.2025 10:25Подскажите, немного не в теме: вроде как изобретали перпендикулярную запись, где дорожки располагаются по радиусу диска, она вроде не должна давать описанный эффект. Отказались от этой технологии?
DaemonGloom
20.02.2025 10:25В перпендикулярной записи дорожки располагаются аналогично старому варианту. Разница только в ориентации магнитных частиц. И классические жёсткие диски сейчас (если не вспоминать черепичную запись) - именно с перпендикулярной записью.
nerudo
Начиная читать, предавался интриге - что же авторы для себя открыли: замещаемые сектора или разную линейную скорость на разных цилиндрах.
media808media
они открыли 20 век
forgot10
Причем любой человек, который жиль чуточку раньше и выбирал HDD диск для себя, чаще всего перед покупкой смотрел элементарный обзор и тестирование интересующей модели и буквально в каждом был, и график записи на диск, и упоминание, что скорость/график в начале записи и в конце сильно отличается.
В общем потратили кучу времени на то, что было в общем-то очевидным...
Nick0las
Когда-то диски были достаточно медленные, скорость HDD имела значение, статьи с графиками были актуальны и многие их читали. Потом диски стали достаточно быстрыми, чтобы не заморачиваться насчет максимальной скорости последовательного доступа, измеренной независимыми тестерами.
Другое дело, что проектируя систему где скорость критична стоило бы поискать независимые измерения. Ведь есть слово "маркетинг" и инженеры должны знать что цифры указанные в спецификации часто являются завышенными и не полностью отражают реальность.
NetBUG
Мы слишком сильно стали забывать "поля" из MHDD и графики из Victoria...
Ivanii
Они НЕ открыли зоны https://intuit.ru/studies/courses/3460/702/lecture/14152?page=2 , в зависимости от зоны разное количество секторов на дорожку.
T-helper
Тоже подумал что придумали трехслойную черепичную. Вобще в victoria всегда этот график так и выглядел
riv9231
А я ещё подумал, ну не файловые же системы они там используют? Наверное что-то своё, что пишет линейно, а метаданные на ssd.... А может SMR опять тихой сапой производители начали в диски пихать? Даже мысль в голову не пришла, что они могли не знать, что диск в конце LBA-пространства пишет медленнее чем вначале из-за разной линейной скорости пластины под головкой диска на внешнем радиусе и на внутреннем.
Например, производитель систем видеонаблюдения трассир, интересным образом учел способность дисков выходить из строя и пишет видео фрагментами поочередно на диски, которые заполняются последовательно (как бы raid0) но с учетом ключевых кадров так, чтобы при потери диска, вы в целом могли не напрягаясь смотреть видеозапись с небольшими пропусками. И дешево и почти надежно - хороший компромисс.
А тут, я правильно понял, они взяли маркетинговую скорость диска 250МБ/сек, умножили на количество дисков и записали это в характеристики их издения? А потом даже не провели испытаний, по тому что иначе бы они сразу столкнулись с реальностью.
И даже если это не их изделие, клиент явно ожидал другого и расчеты не проверялись на практике.
Как так-то?
Ilirium
Проблема не у Хьюстона, а у Positive Technologies? Производители все договаривают, просто нужно открыть даташит на конкретную модель диска. Я сам, уже давно не читал даташит на HDD диски, но не думаю, что за это время они перестали публиковать спецификацию и разные интересные технические параметры.