Re: Еще раз о дисковой подсистеме

[Gena Makhomed]

On 18.08.2011 16:48, Илья Винокуров wrote:

> Так вот, при параллельной работе нескольких потоков запросы к массиву будут параллелиться между дисками.

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

например, можно достичь скорости чтения примерно в 5-10 раз больше,
если собрать RAID10 из двух компонент, каждая из которых
будет зеркалом из 5 винтов, из которых потом сделан RAID0.

но для этого - RAID 10 не нужен. для "горячего" контента
можно использовать SAS винт или зеркало из 2, 3, ... винтов.

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

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

п.с. возможно это уже даже реализовали в какой-то файловой
системе (ZFS/BTRFS), или же такую фичу можно туда добавить,
если совсем не хочется делать такую операцию своими силами.

>> Для современного диска нет ощутимой разницы в чтении 1К или 1М. Поэтому
>> читать с нескольких дисков блоки по 128К, чтобы набрать 1М - бессмысленно.

> Поэтому я и предложил увеличить размер блока данных.

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

> Конечно же, речь идет о софтовом решении. По моему мнению будущее за софтовыми RAID массивами,
> а точнее за RAIDовыми FS.

теоретически - ZFS самое лучшее решение. практически - оно не работает.
наверное нам надо будет ждать, пока не появятся 128-битные процессоры.

>> И всё равно он не полностью решает проблему - при попадании на границу
>> будут задействованы два диска вместо одного ?

> Если рассматривать работу в системе кучки процессов, насилующих RAID массив, то факт попадания одного
> файла на границу не играет никакой роли.

играет, потому что это снижает производительность всего массива.
например, если вместо RAID0/RAID5/RAID6/RAID10 используется RAID1
или полностью независимые друг от друга диски - этого глюка нет,
и дисковая подсистема сервера будет работать более эффективно.

>  Главное, чтобы план чтения блоков с конкретного диска был оптимальным.

это не главное.

главное, чтобы это програмно-аппаратное решение могло дать максимальную
производительность (максимальный траффик при рандомном и паралельном
доступе на чтение с такого массива большим количеством клиентов)

-- 
Best regards,
  Gena