Never underestimate bandwith of truck, full of hard drives

[vitus_wagner]

Тут наткнулся на некоторую дискуссию, в которой люди пытаются эту bandwidth оцинить.
И немножко офигел. Как же это у людей хреново с глазомером.

1-й участник дискусии: Сколько 8-терабайтных дисков влезает в 18-wheeler? Я думаю, что минимум 1000.

Прикидываем на пальцах - жесткий диск имеет ширину 3"5, высоту примерно 1" и длину примерно вдвое больше ширины.
Получаем что штабель из 1000 дисков (10x10x10) это примерно 35" (меньше метра) в ширину, 70" (примерно 1.75) в длину и 25 см в высоту. Ну может с высотой я чуточку промахнулся, и получится 35 см, а не 25. В любом случае это габариты багажника легкового автомобиля, а не 18-wheeler

2-й участник дискуссии: если посчитать объем стандартного semi-truck то выходит где-то 165куб.м.
Объем стандартного харда согласно википедии 376.77344 куб см

итого выходит более 400тыс хардов на грузовик.

А это ничего, что жесткий диск - хрень довольно тяжелая на ощупь? Ну не как стальная болванка (плотность 5) но примерно как гранитная плитка (плотность 2,5). То есть при 400 кубических сантиметрах объема оно весит около килограмма.

400 тонн жестких дисков не увезет никакой truck. Стандартная грузополдъемность "еврофуры" 20-24 тонн. То есть надо рассчитывать на 20000 жестких дисков максимум.

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

Upd вообще-то я и сам хорош. 2"5 диски (которые вполне бывают терабайтными) весят в районе 100г. Так что напихать если не 400, то 200 тысяч дисков в фуру можно.

Comments

[hermit-h.blogspot.com]

Охлаждение дисков не учитываем? Требуется не только поддерживать температуру, но еще не плохо и влажность. А обеспечение бесперебойного питания всему этому? Да и подключение всего этого барахла в объединенную систему. Вопрос в том зачем это все на подвижную платформу ставить?

[vitus_wagner]

Зачем диски охлаждать В ПРОЦЕССЕ ПЕРЕВОЗКИ? Когда они отключены от питания?

[burbilog]

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

Приезжает (прилетает на другую планету) такой грузовик с данными, втыкается питание и толстый-толстый кабелище с кучей оптики и все скачивается.

[vitus_wagner]

Да, но все это барахло со стойками, контроллерами и охлаждением резко снижает количество терабайт на единицу грузоподъемности грузовика.

Кстати, кто сказал что нам нужно это самое охлаждение?
Если наша задача - максимально быстро слить данные по толстому-толстому оптоволоконному кабелю, то нам нужно чтобы одновременно было раскрученл ровно столько дисков что их скорость передачи данных насытила этот кабель.

Ну вторая такая же группа дисков будет параллельно раскручиваться чтобы на нее можно было переключиться.
А третья - останавливаться.

В общем, по-моему теплоемкость стоек успеет поглотить все тепло выделяемое при одноразовом скидывании инфы с дисков.

[shaplov.livejournal.com]

Завесил 3"5 жесткий диск (благо все нужное под рукой): 560грамм.

[ivanaxe]

Они разные бывают. Чисто тактильно в два раза может отличаться масса 3.5" диска в зависимости от конструктива... Всего нужного под рукой, чтобы привести точные числа, уы, нет

[silly-sad.livejournal.com]

на самом деле всё нужное у вас есть.
водопровод. кастрюля, мензурка или гранёный стопарик.
делов то

[ivanaxe]

1. Не хватает под руками "лёгкого" 3.5" диска.
2. Кастрюля в небольшом офисе, конечно, не самый частый предмет, но чем-нибудь можно заменить... а вот ёмкости, в объёме которой я был бы точно уверен, пожалуй нет. Сколхозить мерный паралелепипед можно, но погрешность!

[mar1ner]

Диапазон примерно от 0.4 до 0.7 кг. В зависимости от производителя и объёма.
2.5 дюймовые сильно экономнее выходят в плане байт на килограмм.

[ivanaxe]

Ещё интересно прикинуть, как соотносятся жёсткие диски с флеш-памятью по этому самому соотношению ёмкость-масса.

[eldhenn]

Учитывая, что уже есть флешки на 128Гб...

[vitus_wagner]

Насколько я смог нагуглить, microSD имеет размеры 15x11x1мм и вес 1,4г.
Емкость, допустим, 32Гб.

Соответвенно в тот объем, который я насчитал для 1000 3"5 жестких дисков уместится 100x130x25 микро-SD. Что даст нам 10пэтабайт вместо одного.
И весить они будут примерно в полтора раза меньше. Вся эта куча будет весить 455 кг, в то время как 1000 3"5 дисков по уточненным данным - 650.

Правда, вот уже по сравнению с 2"5 выигрыш не такой заметный. Если 2"5 диск на терабайт весит сто грамм, то эквивалентные ему по емкости 32 32Гб микроSD весят 45 грамм. То есть если в ту же массу вписать 2Тб диск, он практически сравняется.

[eldhenn]

>Вся эта куча будет весить 455 кг

Но ЖД - у них металлический корпус. А у флешек пластиковый. Не сломаются ли они под собственным весом?

[silly-sad.livejournal.com]

картина: запоминающий песок.

[jorian]

Не переживай, бывает и хуже. Мне известен случай, когда человек за десятком плат на фуре приезжал - и еще боялся, что не влезут.

[vitus_wagner]

Хорошо, что не за десятком microSD

[bydl0coder.livejournal.com]

http://en.wikipedia.org/wiki/Sneakernet

[amarao-san.livejournal.com]

Э... Вообще, насколько я знаю по своей работе, при truck based replication перевозят не HDD, а целиком сервера. Средний сервер содержит порядка 36 дисков и примерно от 10 до 40Тб полезной нагрузки, занимая при этом 4U. По весу объёму считать лениво. Зато время разгрузки очень короткое. Если же грузить прямо стойками (не нарушая коммутацию внутри стойки), то получится вообще прелесть. Выгрузил 10-20 стоек, поставил, подключил электричество, внешние каналы - всё, можно в бой.

[vitus_wagner]

Ну это немножко другой протокол. Не "truck full of hard drives", а "truck, full of server racks". Возможно, заметно более практичный,

[amarao-san.livejournal.com]

Именно. Ведь наша задача - не плотность упаковки, а задержка в доступности данных. Кстати, в этом случае "держать сервера онлайн" может оказаться даже более эффективным - вынули кабель, перевезли, воткнули кабель.

[vitus_wagner]

Какие задачи в принципе можно решать таким образом, вопрос вообще говоря интересный.

Как мне кажется задач может быть сильно больше одной.

Ну то есть задача "минимизации задержки" подвижным датацентром может и решается.

Задача резервного копирования на географически разнесенные локации как-то уже не так хорошо решается.


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

[amarao-san.livejournal.com]

Если у нас эти данные планируется копировать с диска на диск, то оптика будет выгоднее и удобнее.

Соверменные каналы быстрее, чем скорость работы дисков (а если бэкапы, то дисков под нагрузкой). Так что арендовать волокно на гигабит или два и не париться.

Вот между Тьмутараканском, у которого 100Мб на весь город, и Москвой-Питером - это да, вопрос. А между Питером и Москвой - ни разу не вопрос.

[vitus_wagner]

Да, но даже в режиме c перевозкой стоек в одном траке сотни серверов по 36 дисков в каждом. А скорость чтения даже хреновеньких SATA-дисков у меня в рабочей станции как раз к гигабиту приближается - hdparm показывает 126Мbyte/sec = 1008Mbit/sec.

[amarao-san.livejournal.com]

Именно про это я и говорю. Если у нас линейная скорость диска сравнима со скоростью канала, то канал очевидно быстрее truck based, потому что сначала вы копируете, а потом везёте (и, возможно, снова копируете) А в случае канала - просто копируете.

Я даже не рассматриваю сейчас такие мелочи как дифференциальное копирование и md5 validation, который используется во многих СХД, чтобы блоки не гонять по сети просто так.