Comments 78
где 20Гб диски?
Были… в конце 1999 года)
где 20Гб диски?Кроме шуток, раз уж вы очевидно говорили о ТБ, из любопытства: а вам зачем? 20ТБ на одном диске хранить — так если он посыпется, то это офигеть сколько данных потеряно. Рейд тоже имеет очень хорошие шансы банально не ребилднуться на таких объемах (шанс смерти прежний, скорость выполнения ребилда прежняя, а продолжительность — сильно больше).
LTT в свое время это обсуждали, я теперь регулярно вспоминаю аргументы и понимаю, что повод для беспокойства есть. Как выживать-то с такими 20ТБ (я уж не говорю о недавно заявленных 40ТБ) дисками? Зеркало разве что… Но дорого ведь, очень.
Сейчас думают ускорить доступ через NAND для метаданных, но насколько это поможет при ребилде?
Вы ведь рассуждаете с позиции обычного потребителя (домашнего пользователя), так?Да, верно. Но мне кажется, что комментарий, на который я отвечал, тоже в первую очередь как обычный потребитель интересуется 20ТБ дисками. Но, конечно, могу ошибаться.
Компании, хостинги, облачные сервисы — им-то наверняка выгоднее использовать более емкие накопители.Вот это вопрос интересный: насколько часто у них вылетают диски и как больно по ним бьет практически удвоенный шанс (при переходе с 10ТБ на 20ТБ, например) провалить ребилд массива. Понятно, что можно увеличить количество parity дисков (в два раза, чтобы сохранить прежний шанс потерять массив целиком? Я в тервере не силен), и вот как раз тут уже нужно считать, что дороже: место в датацентре или эти самые диски. Опять же, если для покрытия в два раза выросшего шанса провалить ребилд нужно в два раза больше «запасных» дисков, то и место свободное в датацентре не появляется…
Но я обо всем этом могу только гадать, будучи домашним пользователем. Как устроен датацентр какого-нибудь Backblaze и какие там конфигурации рейдов я представления не имею. Ну спрос рождает предложение, значит смысл должен быть. А может окажется игрушкой типа SSHD. Потому что вроде бы при реально огромных объемах переходят уже на ленту, там технологии тоже на месте не стоят…
есть RAID6 есть всякие проприетарные Double Parity - там нет такой жесткой зависимости ребилда от объема как у RAID5.....
да и зеркало не так уж и дорого выходит.....
Во-первых, чистый RAID вряд ли используется. При отказе сервера, или даже шкафа, данные должны быть доступны. Но ясно, что восполнение данных нужно. Но если данные разбросаны по разным дискам, то это не вызовет сильной нагрузки в системе в общем. Зависит от количества дисков и настроек, конечно.
В Ceph вообще это вызывает серьезный перенос данных, что может грузить диски. Но, возможно, у больших компаний что-то более оптимальное.
Но тут учтите, что у Вас может быть 10000 дисков 15ТБ, к примеру, или 7500 по 20Гб. Скорее всего идет сбой диска каждые несколько минут. Главное чтобы скорость сбоев на гигабайт данных не увеличивалась на новых 20 или 22 ТБ дисках сильно.
Очевидно, выживать избыточностью, RAID6 к примеру, переживет отказ двух из 10 шпинделей.
"офигеть сколько данных" не могут потеряться, так как RAID имеет отношение только к бесперебойной работе, а за сохранность данных отвечает бакап.
Зеркало кстати говоря, совсем не очень дорого, если вы можете поставить 2-4 20ТБ диска в обычный настольный NAS.
«офигеть сколько данных» не могут потеряться, так как RAID имеет отношение только к бесперебойной работе, а за сохранность данных отвечает бакап.Верно, но покупая домой один диск на 20ТБ вместо, например, трех на 8ТБ в RAID-1, вы кладете все яйца в одну корзину. Бракованный 20ТБ диск помрет вместе с данными, а RAID-1 как минимум даст время подумать над тем, вытаскивать ли из него данные или пробовать ребилд, если один диск подведет. Цена +- одинаковая (8ТБ WD Red в РФ стоит 15 тысяч, 16ТБ WD Red — 41), вопрос в надежности. Зеркало из тех же 16ТБ обойдется в 2 раза дороже RAID1 на 8ТБ дисках за ту же полезную емкость, и даже дороже RAID6 из них.
А RAID6 на 20ТБ дисках — это совсем не про домашнее использование, конечно. Что касается корпоративного, то да, там они очевидно имеют место быть, у тех же Backblaze они в статистике присутствуют.
Я не очень понял, как три диска встанут в RAID1? Если вы имеется ввиду, что два в зеркале и один холодный бакап - так получается всего 8ТБ за 45 тысяч. А если суммировать емкость, так это страйп выходит - RAID0, любой диск помер и все данные унес. Зато 45ТБ. Логично, что вероятность выхода из строя одного диска в три раза меньше чем одного из трех.
Вопрос цены ТБ показывает на удивление ровные цифры, самые дешевые терабайты на дисках 4 и 6 ТБ, 1.70 за гиг. А вот далее ровная полочка, вплоть до 18 ТБ - 1.8 рубля за гиг. Это если смотреть по low-price (данные Никса).
В такой случае, является оправданным иметь дома 18ТБ в ПК и бакапить его на сменный 18 ТБ. Это наиболее распространенный и простой (понятный) сценарий, не требующий покупок NAS, понимания уровней RAID и все такое прочее. При этом, актуальные данные (спапшот системы) бакапятся на тот диск который в ПК и иногда бакапятся на холодный. Стример, ввиду несоразмерно высокой цены привода современных моделей, для дома, да и для SOHO не рассматривается.
Я не очень понял, как три диска встанут в RAID1? Если вы имеется ввиду, что два в зеркале и один холодный бакап — так получается всего 8ТБ за 45 тысяч.Пардон, я перепутал с ZRAID-1, который по сути RAID5, конечно. 2+1.
В такой случае, является оправданным иметь дома 18ТБ в ПК и бакапить его на сменный 18 ТБ. Это наиболее распространенный и простой (понятный) сценарий, не требующий покупок NAS, понимания уровней RAID и все такое прочее.Тут кому как нравится, полагаю. Мне проще поднять RAID, чем регулярно подключать и отключать диск.
Риски несколько выше. Порча БП, криптовымогатель, собственная оплошность подвергают опасности все данные сразу.
@Rsa97спасибо, почитал. Но получается, в отличии от 5 уровня, тут меньше емкость - половина от суммы емкости трех дисков.
У меня два пула в системе, по идее важные данные можно переместить на один из них и отключать его, когда он не нужен. Но необходимости в этих манипуляциях нет, данные не критичные.
Но получается, в отличии от 5 уровня, тут меньше емкость — половина от суммы емкости трех дисков.Да. Но меньше накладных расходов на запись, так как при записи сектора нет необходимости считывать секторы с остальных дисков для вычисления чётности.
Я не очень понял, как три диска встанут в RAID1?Есть такая технология, RAID1E.
цена моделей меньшей емкости падаетНу в общем-то на здоровом рынке все со временем должно дешеветь, а не дорожать. Объемы данных растут и мелкие диски устаревают морально.
Сам факт отсутствия новых размеров говорит о том что диски всех размеров не развиваются. То есть, в отличие других технологий, диски не просто прошли пик но и резко с него упали. Вместо постепенного сползания.Не знаю, как по мне — пока скорость не меняется, нет смысла наращивать вместимость. Почему — написал выше. Я бы предпочел, чтобы диски были надежнее и тише, а не вместительнее. По крайней мере в ближайшем будущем.
И переезжать на ленты.Лента дело благое, но чтобы с ними было терпимо работать, нужна библиотека, а еще лучше — робот. Такое дома наколдовать затруднительно, о цене вообще молчу. И все равно оно будет медленнее HDD, которые потребители активно хоронят в первую очередь из-за скорости.
А на энтерпрайзе — да, используют активно, где можно.
Самое смешное. Теперь производиетльность дисков не важна. И технологии типа двойной головки — для меня никакой ценности не несут. При любых раскладах — будет кеширование с ссд.Любопытно. Это вы из практики, или теории? Потому что я к своему домашнему пулу на ZFS прикрутил L2ARC кеш (чтения) в виде Intel DC SSD, но каких-то изменений в работе не ощутил. По факту RAID6 из 8 дисков даст прирост скорости чтения N-2, то есть в 6 раз быстрее одного диска. Это 900 мегабайт в секунду для средней скорости 150 МБ\c с диска (вполне реально для линейного чтения больших файлов, например видео). Кеш там просто не к чему прикручивать. Теперь вот сижу и думаю, для каких целей приспособить этот SSD.
С другой стороны — смотря что хранить. Файлопомойку в 20Тб представить сложновато. Как вариант — для хранения тех же бекапов. Оно вроде и есть, но если утратится — никак не критично, кроме случая, когда потеря бекапа совпала с потерей исходных данных)
Сейчас если zfs действительно осилила dRAID, то проблема отвала диска при ребилде станет не такой актуальной.
Плюс к этому где то проскакивала информация о фиче типа, если один из дисков в raid5 (как пример) отваливается и у тебя занято не все место, то оставшийся массив опять становится с одним избыточным диском (как то там этот диск выбирается по хитрому, вычисляется среднее от времени работы/количества старт-стоп и прочих параметров), просто с уменьшением доступного места.
Суть новости: в 24 году можно будет купить накопитель на блинах, и воткнуть его непосредственно в PCI Express.
Корпоративному сектору это действительно нужно?
Видимо, вопрос не в том, зачем PCI Express, а в том, зачем туда HDD втыкать :)
Боюсь представить, во сколько бы мне встал домашний NAS\сервер на 50ТБ юзабельного пространства, если бы я собирал его на SSD.
А как связан домашний NAS и интерпрайз HDD?Да просто чтобы за примером далеко не ходить. Никак, но это не отменяет того факта, что SSD не заменяет HDD, потому что цена за один 16ТБ SSD (Samsung MZILT15THMLA) — 274 тысячи рублей, а за один 16ТБ HDD (Seagate Exos X16 16 TB) — 32 тысячи. Даже если какое-нибудь QLC чудовище можно взять за полцены от Samsung-а, это все равно несравнимые цены.
Боюсь представить сколько бы стоил ваш NAS на интерпрайз HDD))Я посчитал: 8 штук Western Digital 8 TB HUS728T8TAL5204 — 150 тысяч рублей. Это не сильно дороже, если честно, я WD Red на 8ТБ брал примерно по 16 тысяч за штуку, это всего 16 тысяч рублей экономии выходит за все 8 дисков. Самый дешевый SSD на 8ТБ (Samsung MZ-77Q8T0BW) стоит сейчас на маркете 71 тысячу рублей.
А если отойти от цены вообще, то возникает вопрос: а каждому ли массиву нужна скорость SSD?
Подозреваю, что 20TB жёсткий будет всё же дешевле 20TB SSD.
В некоторых применениях ёмкость и цена может быть выжнее скорости и потребления.
Чтоб не думать, сколько и каких портов SATA/SAS на мамке разводить. Сколько дисков NVMe в серваке будет и сколько SATA/SAS и выпускать несколько конфигураций серверов с разным соотношением и т.д. и запаривать всем мозг по пропускной способности контроллера.
Унификация, короче, интерфейса подключения, да еще и без тормозов на контроллере, с которой в сервак втыкаются HDD/SSD в любом соотношении и без необходимости кукуху включать.
Ага, даже в самом дешманском EPYC на Zen3 этих линий 128 штук, так что 24 линии выделить на жесткие диски в 2U - не проблема.
По идее, 24 линии и не нужно даже выделять. HDD хватит 2 или 4 линий pcie 4.0. У 5.0 все еще лучше будет.
Вижу, не донес мысль.
У вас есть 2U сервер с 24 отсеками под диски и 4 слотами под PCIe-карты, в которые влезет 2 видеокарты по 16 линий.
Вопрос: зачем ставить какие-то хабы к дискам, чтобы "линий сэкономить" поди еще с какими-нибудь кешами, которые будут заканчиваться и правилами "ну из 24 отсеков в ЭТОМ СЕРВЕРЕ ssd пихайте в первые 12, а в остальные 12 пихайте HDD, потому-что мы решили линий сэкономить и хаб на вторые 12 отсеков поставили и там на самом деле 4 линии.
Две видеокарты по 16 линий, это 128 - 32 = 96. Т.е. нехватка линий 2U-серверу ну никак не грозит.
Тогда зачем иметь какие-то ограничения, когда никаких ограничений можно не иметь и в КАЖДЫЙ дисковый отсек привести по линии и забыть, что в какие-то отсеки SSD лучше не подключать?
Можно и так, но почему бы и не разделять? У нас же сейчас есть разделение SATA и NVME/SATA портов на бэкплейне. И тут так будет и будет достаточно свитча pcie без всяких кэшей и хабов. Это ж у эпика столько линий, а грядущий sapphire rapids вроде до 80 линий предлагает.
Вообще, я все же думаю тут будет юзкейс больше с дисковыми полками, чем прям подключением к хосту. Оно просто не нужно такое особо. Через ретаймер и наружу одной или парой кабелей. Даже SSD полки сейчас такие делают в OCP. А прямое подключение - там теперь будет EDSFF и вся туча линий уйдет туда. Там уже втыкай че хочешь, ssd, память, ускорители. Nvme hdd там вряд ли кому-то нужны будут. Не слышал даже, собирается ли кто-то паковать их в какой-нить E3.L формфактор.
А так конечно, перспективы огромные тут. Унифицированный интерфейс открывает огромный простор для дизайна платформ.
А зачем серверу в 2U две видеокарты и 24 отсека под "винты"? Я, если честно, и зачем ему одна видеокарта не совсем понимаю. Какую роль в реальной жизни выполняет сервер с двумя видюхами и 24-мя дисками?
Для этого нужны две видеокарты? Прямо вот видеокарты? Не специализированные какие-то устройства для обучения нейросети, а видеокарты?
Не специализированные какие-то устройства для обучения нейросети, а видеокарты?Профессиональные видеокарты — вещь специфическая, и нужна далеко не всем, даже профессионалам. Я бы даже сказал, что не нужна почти никому. Вот недавно еще и ECC на GDDR уступили, просочился в массмаркет с релизом Turing. Полезных фич осталось мало. Что каcается соотношения цена\производительность, то вот.
Видеокарты и есть специализированыне устройства. Напихать туда Nvidia A100 и можно обучать.
Сейчас повсюду виртуализация и на сервере не одна задача гоняется, а 100500. Данные множества виртуальных машин надо где-то хранить и это либо покупка выносной очень дорогой хранилки, либо хранить прямо на сервере, но тогда на сервер надо много дисков.
У кого хранилка выносная, надо побольше процессоров да поплотнее, 2U-сервера на 24 диска покупать и не будут.
А видеокарты зачем?
При виртуализации ни зачем. Вернее их иногда виртуалкам пробрасывают, но обычно не нужны.
А зачем эти порты вообще? Что вы в них пихать будете?
Обычно пихают RAID-контроллеры, сетевые карты 10G, адаптеры FC.
RAID-контроллеры не нужны в данном случае, если решили диски локально иметь, FC скорее всего тоже не нужен. Даже в отказоустойчивой конфигурации на пару сетевух 10G много каналов не нужно.
Видеокарты здесь приведены просто как что-то, что способно много полос занять, только и всего.
Вот для этого юзкейса nvme hdd очень полезны, но снаружи. Они как раз будут вынесены и будут монтироваться в виртуалке как nvme устройства, а на самом деле будут бегать по nvme over fabric. Или вообще будут подключены как дисковые полки к сервакам, на которых что-то вроде ceph, а уже его монтировать в виртуалки.
В серваки много дисков пихают нынче, чтобы скорость получить. Для этого облачные провайдеры EDSFF и толкают. Им надоело с m.2 и u.2 возиться ряди этого. Я не думаю, что кто-то будет пихать в жирные серваки nvme hdd и еще видюхи. Если нужно что-то обучать, то либо используется супер быстрая хранилка, либо локально nvme ssd. HDD при всем желании не переварит большие модели.
Ceph по ethernet работает. Дисковые ресурсы он тоже только по ethernet умеет отдавать.
Ceph выбирают за отказоустойчивость, выход из строя любого диска или любого (при правильной архитектуре) сервера не приводит к падению работающих на Ceph виртуалок.
В случае выхода из строя диска, который на сервере подключен как DAS (например по nvme), все что на этом диске работает - отвалится.
При использовании сети с nvme ничего принципиально не меняется, тот же FC, только другой -) Соответственно, для отказоустойчивости нужны кластерные файловые системы типа vmfs.
Ну да и что? Дисковая полка подключена извне по pcie. Либо напрямую, либо через nvme-of и ethernet фабрику. На OSD хосты эти диски монтируются как nvme блочные устройства. Мы получаем интересную схему, когда блочные устройства и их OSD не связаны физически, и мы не являемся заложниками платформ. Уже сам ceph конечно отдаст хранилище по ethernet. Понятно, что это недалеко ушло от FC и iSCSI, но в этом и идея. Индустрия мигрирует с легаси технологий на nvme, которая делает примерно тоже самое, но лучше, и много нового. А заодно унифицирует всю экосистему.
В случае выхода из строя диска, который на сервере подключен как DAS (например по nvme), все что на этом диске работает - отвалится.
Это понятно, но зато это все вливается в composable infrastructure, к которой сейчас все так стремятся. В хостах больше не нужны диски, в них больше не нужны рейд контроллеры. Хранилище монтируется по запросу удаленно с полок. Сам хост может это дело запросто собрать в raid1 и получить надежность. Этот raid1 может делать тот же DPU в хосте, а виртуалке уже выдавать готовое блочное устройство. Тут открывается огромное поле для фантазии.
Это нужно облачным провайдерам и прочим огромным клиентам. Им нужно nvme over fabric, что как раз можно получить с такими дисками. Дальше там будет либо какой-нить свитч и ретаймер, чтобы это все дело жило в отдельной полке и подключалось через внешний кабель к сервакам. Либо внутри вообще будет какой-нить DPU и это будет частью распределенного хранилища, где CPU может вообще не быть.
Почему-то в памяти всплывает NCQ, но он как раз SATA-шный.
В sas есть tcq, которая устроена лучше, чем ncq (в районе обработки ошибок), но тащить sas хочется всё меньше и меньше. nvme - вполне разумный протокол, в котором большую часть легаси закопали.
... Но вот что станет с пользователем, который обнаружит, что его /dev/nvme0p1 выдаёт 80 IOPS вместо ожидаемых 120000.... Я бы обсыпался с эксепшеном.
Не только больше, так еще самих очередей 65k можно насоздавать. И жить эти очереди могут как в оперативке хоста, так и диска. Насколько это будет полезно HDD пока непонятно. Надо наверное усложнять контроллер. Но, как ни странно, видел тесты и там HDD поверх nvme каким-то образом умудрился работать заметно так быстрее на несколько десятков мегабайт в секунду. И я так понимаю над контроллером там особо никто не мудрил.
Но, как ни странно, видел тесты и там HDD поверх nvme каким-то образом умудрился работать заметно так быстрее на несколько десятков мегабайт в секунду.Это, вероятно, на мелких файлах? Было бы очень кстати.
Попутал. В линейной пропускной способности разницы никакой. Прирост на рандоме по иопсам.
На самом деле, наличие такого размера очередей открывает для жёстких дисков возможность иметь чуть-чуть флеша для оной очереди (или памяти с батарейкой) и жевать random io с существенным приростом. Но, на самом деле это мало кому надо. Дело в том, что индустрия уже давно разделилась - HDD - это long term random access storage (всякие блобохранилища типа s3, swift, rados), а SSD (в любой инкарнации, что SATA, что SAS, что NVME) - это место для быстрого доступа к персистентным данным. Т.е. если производители HDD сейчас удесятерят IOPS'ы это не позволит им подвинуть SSD с рынка. У HDD осталась одна ниша - хорошо долго хранить задёшево. От лент их отделяет наличие random access.
Уменьшить количество полок на 50% за счет 24Тб дисков. Ну даже если будет переезд 8->12 если провайдер предпочитает диски половинной емкости от максимальной на рынке.Но разве для них не нужно будет увеличивать количество дисков избыточности? Ведь с ростом вместимости растет и шанс не дожить до конца ребилда, скорости-то прежние.
Тут речь скорее не об отсутствии контроллеров. В полках все равно скорее всего понадобится ставить ретаймер и pcie свитчи, которые точно так же будут точкой отказа и лишними затратами. Тут речь об унификации. Теперь все будет понимать nvme. Это ж за собой тянет тучу проблем с мониторингом этого всего. Помимо спеки на диски есть еще спека NVMe-MI, которая стандартизует как раз менеджмент и мониторинг устройств, бэкплейнов и прочей обвязки. Теперь все подчиняется одной общей спеке, которую пишут облачные провайдеры для себя.
В то-же время мне сложно представить что полки останутся без контроллеров. Даже если диски pcie - их все надо собрать в две платы-выхода, каждая из которых подключается ко всем дисками. И это мы не начали обсуждать дикую популярность DPU.
Это решается резервированием на уровне полок. Отвалилась полка - не беда. Все ее реплики живут в соседней. Еще как вариант, если так возможно, можно попробовать, чтобы из полки торчал nvme over fabric, а на той стороне уже будет два контроллера и пусть они ее делят между собой как вздумается. DPU тут будет очень кстати.
К слову о DPU, тут kioxia выпускает nvme-of диски https://www.servethehome.com/kioxia-em6-25gbe-nvme-of-ssd-launched/ Не надо ни DPU, ни наверное даже CPU. Сразу в ethernet фабрику. Очень любопытная архитектура хранилища вырисовывается с таким решением.
Иллюстрация того, как из двух карандашей и буханки хлеба сделать троллейбус? Каков смысл занимать драгоценные PCIe линии, если даже возможностей SAS с избытком. Ладно бы был какой-то умный гибрид механики и SSD, но такие франкенштейны тоже не взлетели.
SAS это устаревший протокол. Люди хотят nvme, а особенно nvme over fabric. Такие диски это дадут. А занимать драгоценные линии не надо. У нас для этого есть свитчи и ретаймеры.
Каков смысл занимать драгоценные PCIe линииВовсе не обязаны быть драгоценными. То, что нам на консьюмерских платформах «по барски» дают всего +-20 — осознанная сегрегация, чтобы брали HEDT. Будет запрос на 30 линий — сделают 30. А пока можно продавать втридорога (условно) те же процессоры, но с большим количеством линий — будут продавать.
Кроме того, новый Intel уже умеет PCI-E 5.0, все диски скорее всего на х1 можно пересадить при желании. Ну может быть на x2 — самые быстрые, для энтузиастов. HDD вообще можно было бы пачками грузить в x1 линию.
Ладно бы был какой-то умный гибрид механики и SSD, но такие франкенштейны тоже не взлетели.Там нечто подобное и планируется для огромных дисков. Правда для метаданных.
Ахаха, а TRIM на NVME HDD появится? ?
Seagate продемонстрировала жесткий диск с интерфейсом PCIe NVMe