Comments 129
Красота! Очень хочу освоить сборку подобных систем. Только представьте, какие возможности открываются, например, математикам — имея такой дата центр и домашний супер компьютер от нвидии. И не только… Ух!
Математики пользуется мощностями университета, я думаю им приятнее работать в коллективе, а дома отдыхать с семьёй.
Прошу прощения, не домашний, а персональный супер компьютер, например, как www.nvidia.com/object/personal_supercomputing.html. И да, не дома, а как мощности университета. Для обработки больших массивов данных нужны и большие хранилища и большая вычислительная мощь, а для университета такие предложения как раз и бюджетные и сотрудникам удобные (мне так кажется). Например, как снимаются проблемы и очереди с выделением процессорного времени, так и с квотами на дисковое пространство на больших кластерах. Все у конкретного сотрудника под конкретные задачи стоит рядом — и дата центр и вычислитель.
… и зимой на такой системе можно лежать как на печи.
Система мощная и дешёвая — кайф.
Судя по используемым материнкам, решение будет бюджетным не только в плане стоимости, но и в плане производительности. Помимо использования этих железок в датацентре Backblaze, какая у них ещё может быть ниша на рынке систем хранения?
Верно подмечено, не внушает доверия эта материнка. + совершенно не вижу расчёта производительности системы с доступом по HTTPS, на какой объём данных/количество клиентов хватит этого хранилища..?
А что материнка то? Движущихся частей нет, охлажение там будет нормальное.
За материнкой идёт процессор, который в неё ставится, и оперативка… Вся эта штука наверное надёжная, но сколько одна такая коробочка выдержит клиентов? вот у меня терабайт-полтора личных данных, которые я хочу забекапить… на борту примерно 65 терабайт, т.е. вполне может висеть порядка 50 таких же, как я клиентов. Сколько активных аплоадов/даунлоадов это дело выдержит? хотя бы 20 клиентов закачивающих/скачивающих по гигабайту данных (по несколько сотен файлов)? Конечно, Debian x86_64, HTTPS… 10, 20, 50 кб/с. Сколько будет идти процесс бекапа или восстановления? неделю-две?
Там подключение гигабит, скорость ввода-вывода там его покрывает, так что узким местом скорее будет сеть.
у вас тоже «3 RAID6 volumes» на ноду?
они только забирают ваши данные, а отдача идет очень редко, рискну предположить что у них меньше 10% исходящего трафика по отношению к входящему. К тому же им не нужна скорость все данные размазаны по серверам и одному Богу(Linux) известно на скольких серверах лежит ваш файл.
Это скажем так система бекапа, в качестве системы для СУБД это не выдерживает никакой критики.
мда… говорят об облаках, а копнув поглубже становится виден всего лишь относительно дешёвый и не быстрый бекап.
Говорить много чего можно :) В целом конечно можно собрать N таких нод для увеличения быстродействия, но тут в первую очередь преследовалась цель сделать максимально дешевое и емкое хранилище.
Вы начало-то материала посмотрите, прежде чем писать. Это строго бэкапное решение, именно так оно и проектируется.
перейдите на сайт, там все понятно — ребята и предлагают дешевый бекап по инету… респект ребятам, яд… особенно с учетом того что ребята используя гаражную поделку (ну так и есть, согласитесь) делают бизнес, имхо это очень в духе силиконовой долины из фильмов. Вообще в прайсе они не скупились, case за 750уе, обычные БП по 270$ каждый, CPU можно подешевле
БП там по 750Ватт. Корпус заказной, для мелкосерийки нормальный ценник.
БП ровно в 2 раза дешевле, или он там таки не такой простой как они пишут hotline.ua/gd/49/2590, корпус для мелкосерийки это для нормального корпуса… вы этот видели? это четырехюнитовый индустриальный каркас, даже не корпус, с дополнительной решеткой для монтажа винтов
Хрен их знает. Там указано custom wired, хотя не думаю что оно столько стоит.
Пустой индустриальный массовый корпус 4U стоит порядка 200 долларов. У них же явно мелкосерийка в пределах 500 штук. Оно так стоит и будет. Если бы они делали от пары тыщ было бы дешевле раза в два :)
корпус для мелкосерийки это для нормального корпуса… вы этот видели? это четырехюнитовый индустриальный каркас, даже не корпус, с дополнительной решеткой для монтажа винтов
Пустой индустриальный массовый корпус 4U стоит порядка 200 долларов. У них же явно мелкосерийка в пределах 500 штук. Оно так стоит и будет. Если бы они делали от пары тыщ было бы дешевле раза в два :)
Что вы понимаете под облаком?
Мы используем серверные материнки, с IPMI и прочими плюшками. Хотя десктопные материнки тоже можно использовать и на производительность это не повлияет (хотя смотря какие материнки).
а сколько памяти и какой используется в одной такой ноде? и что за процессор всем этим делом управляет?
оффтопик: Была бы у них возможность бекапить линуховые машины, цены бы этому сервису не было!
+ при этом сами серваки работают под linux
А я еще в предыдушем топике писал — нигде на сайте не сказано, что они _на самом деле_ вот на это вот бэкапят.
Этот странный эксперимент — отдельно, бизнес — отдельно.
По крайней мере цены у них вполне себе рядовые,«как у всех», не занимающихся таким извратом с самодельными серверами. Тот же mozy.com — те же 5 баксов за анлим.
Этот странный эксперимент — отдельно, бизнес — отдельно.
По крайней мере цены у них вполне себе рядовые,«как у всех», не занимающихся таким извратом с самодельными серверами. Тот же mozy.com — те же 5 баксов за анлим.
При этом серваки у них работают под линукс, почитайте их блог.
А есть информация, на каком железе работает mozy?
Нет, не встречал. Теоретически их купил EMC (точнее их материнскую компанию Decho, mozy это проект Decho). Но это ничего не значит, по сути. Вон EMC купил и VMware давным давно, а они плодотворно и много лет как дружат себе напропалую с их злейшими конкурентами — NetApp.
Так что нет там таких вот строгих правил: вы наши — значит будете жить только на нашем железе.
В марте у них было 10 PB.
www.decho.com/blog/entry/from_gigabytes_to_petabytes/
В июле перевалили за 15PB.
mozy.com/blog/misc/how-much-is-a-petabyte
Знаю, что Flickr, Yahoo! и Facebook живут на NetApp.
MySpace на Isilon.
Но вообще такая информация не часто обнародуется.
Так что нет там таких вот строгих правил: вы наши — значит будете жить только на нашем железе.
В марте у них было 10 PB.
www.decho.com/blog/entry/from_gigabytes_to_petabytes/
В июле перевалили за 15PB.
mozy.com/blog/misc/how-much-is-a-petabyte
Знаю, что Flickr, Yahoo! и Facebook живут на NetApp.
MySpace на Isilon.
Но вообще такая информация не часто обнародуется.
Flickr: blog.aboutnetapp.ru/archives/227
Oracle Datacenter: blog.aboutnetapp.ru/archives/314
Facebook: blog.aboutnetapp.ru/archives/188
Myspace: www.isilon.com/company/?sub=press&page=press&release=73
Oracle Datacenter: blog.aboutnetapp.ru/archives/314
Facebook: blog.aboutnetapp.ru/archives/188
Myspace: www.isilon.com/company/?sub=press&page=press&release=73
Да, не хорошо.
интересно, а сколько весит подобное чудо? (в прямом смысле, т.е. в кг?)
«Ни одна из этих технологий не масштабируется так дешево и надежно, не может достичь таких размеров и не управляется так легко, как самостоятельные контейнеры, каждый со своим собственным IP-адресом, ожидающие запросов по HTTPS»
респект
респект
отличное решение. вероятно по работе очень пригодится. все на виду, а ведь в голову не приходило :) наверное голова такая :)
статья должна стать образцом для тех, кто соберется описывать подобные вещи. Грамотно все изложено. Спасибо за перевод.
Спасибо, но, честно говоря, перевод читается немного трудновато.
Во-первых, перевод (почти) всегда хуже оригинала, потому что в нем к огрехам, неточностям, неоднозначностям оригинала добавляются огрехи, неточности и неоднозначности перевода.
Во-вторых, есть гениальная пословица: Do it better, if you can!
В-третьих, если от общих идей перейти к конкретике, то покажите, пожалуйста, конкретно место в статье, которое я плохо перевел, и в чем именно это «плохо». Я буду только признателен и учту на будущее.
Во-вторых, есть гениальная пословица: Do it better, if you can!
В-третьих, если от общих идей перейти к конкретике, то покажите, пожалуйста, конкретно место в статье, которое я плохо перевел, и в чем именно это «плохо». Я буду только признателен и учту на будущее.
Просто «тяжело» читать и местами я бы сформулировал предложения по-другому.
А из конкретных примеров пожалуй приведу «изумительно плотные жесткие диски». По-русски это НУ СОВСЕМ не звучит.
А из конкретных примеров пожалуй приведу «изумительно плотные жесткие диски». По-русски это НУ СОВСЕМ не звучит.
Ясно. По поводу «изумительно плотных дисков» — таких мелочей в статье куча. Оно и в оригинале аляповато звучит. И я не стал гнать отсебятину, переводя «ridiculously dense hard drives» как «жесткие диски впечатляющей плотности записи информации на пластину» или что-то в таком духе. Написано — плотные диски — перевожу как «плотные диски».
Хотя, конечно, кое-где я таки что-то менял, скажем, не люблю слэнга в таких статьях, поэтому вместо «щепок» я писал «микросхема» и т. п.
Хотя, конечно, кое-где я таки что-то менял, скажем, не люблю слэнга в таких статьях, поэтому вместо «щепок» я писал «микросхема» и т. п.
Кстати, в разделе о компании,
Gleb Budman, CEO
что-то мне подсказывает, что можно получить комментарии на русском из первых уст, если постараться.
Gleb Budman, CEO
что-то мне подсказывает, что можно получить комментарии на русском из первых уст, если постараться.
А какой внутри у этой железки температурный режим?
Диски-же большую часть времени стоят с остановленным шпинделем, если это чисто бэкапное решение?
Диски-же большую часть времени стоят с остановленным шпинделем, если это чисто бэкапное решение?
зачем там рейд6, если там и так полно точек отказа?
Без RAID-6 оно вообще не жизнеспособно. Так хоть включится. :)
Я бы не был столь категоричен. Для бекап-стораджа оно вполне подходит. Другое дело, что если их сервера дублируются, то зачем терять 6 дисков в массивах РЕЙД-6.
Затем, чтобы не терять данные при выходе из строя одного из винчестеров.
так если сервера дублируются — с чего бы данным теряться?
Данные на локальном сервере могут теряться. И на их востановление требуется время. Скажите что быстрее синхронизация полутора террабайт через SATA или 19.5 террабайт по гигабиту?
Хорошо. Рейд — софтварный. Компоненты — бюджетные (т.е. не высокопроизводительные).
Повторю свой вопрос: что быстрее — сребилдить софтварный рейд-6, емкостью 19,5 ТБ, из состояния degrated силами процессора или среплицировать 1,5 TB по SATA-300 по сети (неизвестной пропускной способности) с другого сервера?
Повторю свой вопрос: что быстрее — сребилдить софтварный рейд-6, емкостью 19,5 ТБ, из состояния degrated силами процессора или среплицировать 1,5 TB по SATA-300 по сети (неизвестной пропускной способности) с другого сервера?
Быстрее будет сребилдить рейд. Ребилд рейда жрет порядка 30% одного ядра. Сеть как раз таки известно какая 1G ethernet. Что быстрее 3G или 1G? Учтите что там еще 3 канала на один рейд.
не зная всех параметров системы, я полагаю, что скорее будет таки среплицировать отдельный диск по сети. ибо ребилд с индексов с 14 дисков потребует значительной вычислительной мощности процессора. Где там написано про 3 канала на рейд?
я полагаю, что скорее будет таки среплицировать отдельный диск по сети.
И все время пока он копируется данные будут доступны только с другого хранилища и могут измениться за время копирования.
ибо ребилд с индексов с 14 дисков потребует значительной вычислительной мощности процессора.
30% от ядра максимум.
Где там написано про 3 канала на рейд?
45 дисков 9 SATA каналов. В каждом рейде по 15 дисков соответсвенно по 3 SATA канала на рейд.
> И все время пока он копируется данные будут доступны только с другого хранилища и могут измениться за время копирования.
и неизвестная нам вероятность, что именно в этот момент они могут измениться.
>30% от ядра максимум.
и часов 20 минимум
>45 дисков 9 SATA каналов. В каждом рейде по 15 дисков соответсвенно по 3 SATA канала на рейд.
и пять дисков на канал SATA-300 (помнится, множители портов не увеличивают пропускную скорость канала).
извините, о чем спор-то идет?
и неизвестная нам вероятность, что именно в этот момент они могут измениться.
>30% от ядра максимум.
и часов 20 минимум
>45 дисков 9 SATA каналов. В каждом рейде по 15 дисков соответсвенно по 3 SATA канала на рейд.
и пять дисков на канал SATA-300 (помнится, множители портов не увеличивают пропускную скорость канала).
извините, о чем спор-то идет?
Ну видимо о целесообразности использования там рейда. Товарищи RAID там используют только чтоб иметь меньше головняков и больше автоматизма при смерти диски и его замене. Просто в случае RAID диск поменяли, запустили rebuild пошли пить чай, а в случае без RAID, заменили диск, запустили копирование, проверили что коприрование произошло удачно и т.п. Т.е если первое уже автоматизировано, то второе увы надо будет автоматизировать.
да, если там данные хранятся на отдельном хранилище и более нигде не дублируются, то естественно, рейд там жизненно необходим. Но помимо рейда им бы следовало реализовать еще систему отказоустойчивого электроснабжения с горячей заменой БП ибо в случае выхода хотя бы одного из них система встает намертво и быстренько ее оживить весьма проблематично. Отказ матери, процессора, памяти, контроллеров, бекплейнов будем считать маловероятными.
в случае же дублирования наличие рейда уже не критичен.
в случае же дублирования наличие рейда уже не критичен.
простите, а где прочитали про дублирование серверов… по моему фраза «самостоятельные контейнеры, каждый со своим собственным IP-адресом» как-бы намекают нам
Признаюсь честно — поверил на слово своему оппоненту. Т.е. дублирование — это миф?
я не знаю, просто в тексте не нашел ни упоминания ни опровержения, только косвенно по фразам могу судить что нет дублирования есть максимально-автономные ноды, перед которыми наверное стоит какой-то маршрутизатор который по id зашитому в запрос адресует входящий запрос ноде, или еще как… а вообще если у них софт свой то этим он должен заниматься и просто пулять на вычисленный внутри него айпишник из подсетки — масштабируемость линейно-сказочная пока канал дает, единственное отказы увеличиваются при масштабировании тоже линейно
Вы перечислите и помендленнее, я записываю.
PS RAID6 нужен, чтобы можно было потерять 2 диска из 15 и не заливать по сети все 19.5 террабайт.
PS RAID6 нужен, чтобы можно было потерять 2 диска из 15 и не заливать по сети все 19.5 террабайт.
напоминает разговор:
— как мне проехать к Теверской, если метро не работает?
— Вы перечислите и помендленнее, я записываю.
ЗЫ Я знаю, для чего нужен RAID, но не понимаю, о какой надежности идет речь: что вы будете делать, если откажет ХОТЯ бы один PSU?
— как мне проехать к Теверской, если метро не работает?
— Вы перечислите и помендленнее, я записываю.
ЗЫ Я знаю, для чего нужен RAID, но не понимаю, о какой надежности идет речь: что вы будете делать, если откажет ХОТЯ бы один PSU?
Выключу сервер целико и сменю его. Вы не забывайте, что там ящики продублированы. К тому же использование PSU 2+1 3+1 никак не влияют при выходе из строя материнской платы, RAID-контроллера, процессора, памяти. В любом сервере пачка точек отказа. А вот если у нас сервера продублированы, то можно отказаться от части дублирования на уровне самих серверов.
И это правильно, что они продублированы. Потому что если бы этого не было, и в это самое время мне понадобились мои данные — смог бы я их получить? Вы сами перечислили возможные точки отказа. Но возникает вопрос — если они продублированы (т.е. мои данные доступны в любое время), то зачем там РЕЙД-6 (т.е. грубо говоря, теряется 6 дисков), если все равно при выходе одного диска (или же БП, памяти, контроллера, бек-плейна и т.д.) из строя, придется останавливать весь сервер? Или же они будут ждать, пока не накопится хотя бы 3 диска (по 1-му из каждого массива), чтобы сразу их все и заменить?
Я не говорю, что это решение плохое или нежизнеспособное. Просто они закрыли одну дырку в отказоустойчивости, оставив остальные, хотя если сервера дублируются целиком, то мое имхо — это просто трата дисков.
Я не говорю, что это решение плохое или нежизнеспособное. Просто они закрыли одну дырку в отказоустойчивости, оставив остальные, хотя если сервера дублируются целиком, то мое имхо — это просто трата дисков.
то зачем там РЕЙД-6 (т.е. грубо говоря, теряется 6 дисков), если все равно при выходе одного диска (или же БП, памяти, контроллера, бек-плейна и т.д.) из строя, придется останавливать весь сервер? Или же они будут ждать, пока не накопится хотя бы 3 диска (по 1-му из каждого массива), чтобы сразу их все и заменить?
Для уменьшения простоя. Вот смотрите в ящике 45 винчестеров, выход из строя одного из них существенно выше чем выход из строя одного из PSU, конструкция позволяет их менять на ходу и не терять данные. И эта возможность дешева.
>Для уменьшения простоя.
Какой простой, если сервера дублируются?
>конструкция позволяет их менять на ходу и не терять данные
честно говоря, не заметил в тексте, чтобы диски были с hot-swap. К тому же, для замены надо вынимать весь сервер из стойки. Вряд ли это можно делать на работающем сервере.
Опять-таки, скорость деградировавшего рейда ниже. А без рейда информация с упавшего диска была бы взята просто с другого сервера.
Какой простой, если сервера дублируются?
>конструкция позволяет их менять на ходу и не терять данные
честно говоря, не заметил в тексте, чтобы диски были с hot-swap. К тому же, для замены надо вынимать весь сервер из стойки. Вряд ли это можно делать на работающем сервере.
Опять-таки, скорость деградировавшего рейда ниже. А без рейда информация с упавшего диска была бы взята просто с другого сервера.
Какой простой, если сервера дублируются?
Но тот сторадж, что вышел из строя простаивает и чем быстрее вы его вернете на место тем лучше.
честно говоря, не заметил в тексте, чтобы диски были с hot-swap.
Вообще-то как раз с hot-swap. Там используются backsplane с совмещенными разъемами питания и данных. Вытягиваете винчесте на себя он отключается, ставите обратно включается. Это все можно делать на ходу и используемые ими контроллеры это поддерживают.
К тому же, для замены надо вынимать весь сервер из стойки. Вряд ли это можно делать на работающем сервере.
Там рельсы. Достаточно выкатить на половину и сбросить крышку.
Опять-таки, скорость деградировавшего рейда ниже. А без рейда информация с упавшего диска была бы взята просто с другого сервера.
Скажите что быстрее востановка RAID6 на 19.5 террабайт или заливка по новой этих самых 19.5 террбайт по сети?
>Но тот сторадж, что вышел из строя простаивает и чем быстрее вы его вернете на место тем лучше.
Да, при выходе винта из строя, сервер продолжит работу. Но скорость работы будет ниже. К тому же, рано или поздно, винт таки придется менять.
>Вообще-то как раз с hot-swap. Там используются backsplane с совмещенными разъемами питания и данных. Вытягиваете винчесте на себя он отключается, ставите обратно включается. Это все можно делать на ходу и используемые ими контроллеры это поддерживают.
Хорошо, пусть будет так.
>Там рельсы. Достаточно выкатить на половину и сбросить крышку.
Рельсы заметил в ролике. На картинке увидел только уголок. Согласитесь, это далеко не одно и то же. К тому же, половина сервера, где расположены диски, ЗНАЧИТЕЛЬНО тяжелее той половины, где мат. плата. Где гарантия, что сервер банально не упадет под силой тяжести половины с винтами?
>Скажите что быстрее востановка RAID6 на 19.5 террабайт или заливка по новой этих самых 19.5 террбайт по сети?
Позволю себе задать встречный вопрос: что быстрее — сребилдить рейд из дегрейтед (19,5 ТБ) или среплицировать одиночный винт с другого сервера (1,5ТБ)? (имеется в виду ситуация, когда каждый винт — отдельная единица хранения).
И еще — извините, но мне наш разговор напоминает общение глухого со слепым. Ни вы, ни я не видели этих серверов в живую и не знаем, чем руководствовались разработчики. Я просто выражаю свое мнение, что если бы я делал такой сервер (к тому же, дублирующийся), я бы не стал заморачиваться с рейдом и потерей 2 дисков на массив (принцип Гугла). Я не говорю, что рейд — это что-то бесполезное. Просто в ситуации с дублированием это уже лишнее. Данный спор ни к чему не приведет. Предлагаю закончить на этом. Идет?
Да, при выходе винта из строя, сервер продолжит работу. Но скорость работы будет ниже. К тому же, рано или поздно, винт таки придется менять.
>Вообще-то как раз с hot-swap. Там используются backsplane с совмещенными разъемами питания и данных. Вытягиваете винчесте на себя он отключается, ставите обратно включается. Это все можно делать на ходу и используемые ими контроллеры это поддерживают.
Хорошо, пусть будет так.
>Там рельсы. Достаточно выкатить на половину и сбросить крышку.
Рельсы заметил в ролике. На картинке увидел только уголок. Согласитесь, это далеко не одно и то же. К тому же, половина сервера, где расположены диски, ЗНАЧИТЕЛЬНО тяжелее той половины, где мат. плата. Где гарантия, что сервер банально не упадет под силой тяжести половины с винтами?
>Скажите что быстрее востановка RAID6 на 19.5 террабайт или заливка по новой этих самых 19.5 террбайт по сети?
Позволю себе задать встречный вопрос: что быстрее — сребилдить рейд из дегрейтед (19,5 ТБ) или среплицировать одиночный винт с другого сервера (1,5ТБ)? (имеется в виду ситуация, когда каждый винт — отдельная единица хранения).
И еще — извините, но мне наш разговор напоминает общение глухого со слепым. Ни вы, ни я не видели этих серверов в живую и не знаем, чем руководствовались разработчики. Я просто выражаю свое мнение, что если бы я делал такой сервер (к тому же, дублирующийся), я бы не стал заморачиваться с рейдом и потерей 2 дисков на массив (принцип Гугла). Я не говорю, что рейд — это что-то бесполезное. Просто в ситуации с дублированием это уже лишнее. Данный спор ни к чему не приведет. Предлагаю закончить на этом. Идет?
Да, при выходе винта из строя, сервер продолжит работу. Но скорость работы будет ниже. К тому же, рано или поздно, винт таки придется менять.
Конечно и чем раньше тем лучше. Это касается и любых других систем с RAID.
Рельсы заметил в ролике. На картинке увидел только уголок. Согласитесь, это далеко не одно и то же. К тому же, половина сервера, где расположены диски, ЗНАЧИТЕЛЬНО тяжелее той половины, где мат. плата. Где гарантия, что сервер банально не упадет под силой тяжести половины с винтами?
Посмотрите ролик еще раз. Рельсы находятся со стороны жестких дисков. К тому не упадет он из-аз банальной жесткости рельсов нагрузка будет поперечная а там профиль. У нас подобные рельсы есть как-то ничего с них ни разу не падало.
Позволю себе задать встречный вопрос: что быстрее — сребилдить рейд из дегрейтед (19,5 ТБ) или среплицировать одиночный винт с другого сервера (1,5ТБ)? (имеется в виду ситуация, когда каждый винт — отдельная единица хранения).
Первое быстрее, процессора у нас до дури (ребилд занимает обычно не более 20-30% одного ядра), а скорость SATA выше чем Ethernet 1G. Плюс во время ребилда можно спокойно продолжать писать данные и сеть не занята передачей данных.
Я просто выражаю свое мнение, что если бы я делал такой сервер (к тому же, дублирующийся), я бы не стал заморачиваться с рейдом и потерей 2 дисков на массив (принцип Гугла).
RAID товарищи делали только для уменьшения сетевого трафика и заморочек с дисками. У гугла я хочу заметить используется своя файловая система которая не замечает потерь диска. Если же у вас смонтирована обычная файловая система и диск внезапно ломается, то ОС это заметит и у вас будут проблема. В случае RAID этого не происходит и выход диска из строя это штатная ситуация.
Просто в ситуации с дублированием это уже лишнее.
Вы забываете что у гугла своя файловая система :) У этих товарищей ее нет.
>>Первое быстрее, процессора у нас до дури (ребилд занимает обычно не более 20-30% одного ядра), а скорость SATA выше чем Ethernet 1G.
Попробуйте на досуге сделать ребилд для 5-6 винтов в рейд 5 или 6, поймете что это далеко не так;) Скорость ребилда будет 2-3 гигабита, а объем в 15 раз больше! Ребилд такого рейда займет больше суток, а копирование винта 8,5 часов при скорости в половину гигабита.
Попробуйте на досуге сделать ребилд для 5-6 винтов в рейд 5 или 6, поймете что это далеко не так;) Скорость ребилда будет 2-3 гигабита, а объем в 15 раз больше! Ребилд такого рейда займет больше суток, а копирование винта 8,5 часов при скорости в половину гигабита.
Попробуйте на досуге сделать ребилд для 5-6 винтов в рейд 5 или 6, поймете что это далеко не так
В том то и дело что делал. И Linux собирает его если подкруть довольно быстро.
Скорость отрегулируйте ага? По умолчанию SoftwareRAID занимает не всю полосу, опять же
востановление сумм не обязательно проводится по всему рейду. Смотрим картинку:
Как видим надо залить далеко не все данные и посчитать суммы далеко не для всех данных.
Один диск физически не может содержать контрольные суммы или данные всего рейда.
тфу. Картинка криво вставилась.
www.enhance-tech.com/images/RAID-6-Diagram_1_08.jpg
www.enhance-tech.com/images/RAID-6-Diagram_1_08.jpg
Что значит скорость отрегулировать? Оно и так в потолок не упирается, если вы про /proc/sys/dev/raid/speed_limit_max
Жаль у меня уже собрался массив когда я увидел комментарий, а то бы показал с какой оно скоростью собирается после сбоя и на какой конфигурации (рейд, правда, 5й). По сети копирование идет на сравнимой скорости (особенно если сетевых несколько, я правда не знаю как тут в статье, одна скорее всего, судя по цене матери).
Еще 15 винтов по отдельности будут сильно лучше, чем рейд6 из тех-же винтов при большом количестве одновременных запросов (если они идут к разным файлам примерно равномерно, что в данном случае вполне реально). И место экономится, тут же ребята за ценой гонятся…
Жаль у меня уже собрался массив когда я увидел комментарий, а то бы показал с какой оно скоростью собирается после сбоя и на какой конфигурации (рейд, правда, 5й). По сети копирование идет на сравнимой скорости (особенно если сетевых несколько, я правда не знаю как тут в статье, одна скорее всего, судя по цене матери).
Еще 15 винтов по отдельности будут сильно лучше, чем рейд6 из тех-же винтов при большом количестве одновременных запросов (если они идут к разным файлам примерно равномерно, что в данном случае вполне реально). И место экономится, тут же ребята за ценой гонятся…
Оно и так в потолок не упирается, если вы про /proc/sys/dev/raid/speed_limit_max
Вообще там по умолчанию 20мб/c Я обычно подкручиваю в больше, так-как у меня таки упирается.
Жаль у меня уже собрался массив когда я увидел комментарий, а то бы показал с какой оно скоростью собирается после сбоя и на какой конфигурации (рейд, правда, 5й). По сети копирование идет на сравнимой скорости (особенно если сетевых несколько, я правда не знаю как тут в статье, одна скорее всего, судя по цене матери).
Даже если оно идет со сравнимой скоростью, вам надо или отслеживать или писать свой софт для автоматической копирования.
Еще 15 винтов по отдельности будут сильно лучше, чем рейд6 из тех-же винтов при большом количестве одновременных запросов (если они идут к разным файлам примерно равномерно, что в данном случае вполне реально).
Это только если вы сам вручную их разводите, в случае же RAID это делает за вас ОС.
>Посмотрите ролик еще раз. Рельсы находятся со стороны жестких дисков. К тому не упадет он из-аз банальной жесткости рельсов нагрузка будет поперечная а там профиль. У нас подобные рельсы есть как-то ничего с них ни разу не падало.
посмотрел еще раз. Рельсы видно только в ролике, на картинке их не видно. Так что верю тому, что есть на фото. Не зная характеристик материала корпуса, можно предполагать что угодно. Я вполне допускаю такой вариант, что будучи высунутым на расстояние отсека дисков, под 45 дисками профиль корпуса может и не выдержать и надломиться.
>Первое быстрее, процессора у нас до дури (ребилд занимает обычно не более 20-30% одного ядра), а скорость SATA выше чем Ethernet 1G. Плюс во время ребилда можно спокойно продолжать писать данные и сеть не занята передачей данных.
я считаю иначе. и оба будем банально гадать.
>RAID товарищи делали только для уменьшения сетевого трафика и заморочек с дисками. У гугла я хочу заметить используется своя файловая система которая не замечает потерь диска. Если же у вас смонтирована обычная файловая система и диск внезапно ломается, то ОС это заметит и у вас будут проблема. В случае RAID этого не происходит и выход диска из строя это штатная ситуация.
в случае, если дублирование отсутствует, то рейд конечно же жизненно необходим. Но опять-таки, одна из главных заповедей рейда: рейд не является средством резервного копирования.
>Вы забываете что у гугла своя файловая система :) У этих товарищей ее нет.
и, имхо, это основной их недостаток. мое мнение — надежность данного решения (без дублирования) в качестве бекапа крайне сомнительна. Если они не могут мне гарантировать доступность и целостность моих данных в разумных пределах времени и нести за это ответственность — то зачем мне платить им деньги за сомнительный сервис?
посмотрел еще раз. Рельсы видно только в ролике, на картинке их не видно. Так что верю тому, что есть на фото. Не зная характеристик материала корпуса, можно предполагать что угодно. Я вполне допускаю такой вариант, что будучи высунутым на расстояние отсека дисков, под 45 дисками профиль корпуса может и не выдержать и надломиться.
>Первое быстрее, процессора у нас до дури (ребилд занимает обычно не более 20-30% одного ядра), а скорость SATA выше чем Ethernet 1G. Плюс во время ребилда можно спокойно продолжать писать данные и сеть не занята передачей данных.
я считаю иначе. и оба будем банально гадать.
>RAID товарищи делали только для уменьшения сетевого трафика и заморочек с дисками. У гугла я хочу заметить используется своя файловая система которая не замечает потерь диска. Если же у вас смонтирована обычная файловая система и диск внезапно ломается, то ОС это заметит и у вас будут проблема. В случае RAID этого не происходит и выход диска из строя это штатная ситуация.
в случае, если дублирование отсутствует, то рейд конечно же жизненно необходим. Но опять-таки, одна из главных заповедей рейда: рейд не является средством резервного копирования.
>Вы забываете что у гугла своя файловая система :) У этих товарищей ее нет.
и, имхо, это основной их недостаток. мое мнение — надежность данного решения (без дублирования) в качестве бекапа крайне сомнительна. Если они не могут мне гарантировать доступность и целостность моих данных в разумных пределах времени и нести за это ответственность — то зачем мне платить им деньги за сомнительный сервис?
Я вполне допускаю такой вариант, что будучи высунутым на расстояние отсека дисков, под 45 дисками профиль корпуса может и не выдержать и надломиться.
Я думаю что люди знают сапромат и заказывают рельсы из правильных материалов. У меня вот как-то за все время эксплуатации рельсов ни одни из них не надломились. Нагрузка там кстати говоря не особо критичная порядка 50 кг. Столько весит один UPS, а для них рельсы бывают в полный рост.
я считаю иначе. и оба будем банально гадать.
Я основываюсь на своем опыте работы с Software RAID.
мое мнение — надежность данного решения (без дублирования) в качестве бекапа крайне сомнительна.
Мое мнение, что надежность брендового хранилища (без дублирования) тоже сомнительна, такак существует вероятность того что оно сдохнет. В случае же дублирования эта система позволяет довольно хорошо экономить.
Если они не могут мне гарантировать доступность и целостность моих данных в разумных пределах времени и нести за это ответственность
Вы это в условиях нашли? Или так гадаете?
> Я думаю что люди знают сапромат и заказывают рельсы из правильных материалов. У меня вот как-то за все время эксплуатации рельсов ни одни из них не надломились. Нагрузка там кстати говоря не особо критичная порядка 50 кг. Столько весит один UPS, а для них рельсы бывают в полный рост.
пока все, что я увидел — это только уголок НЕ НА ВСЮ длину корпуса на имеющейся фотографии. А в ролике можно показать хоть автоматическую систему исталляции дисков — толку-то от этого какой?
И еще — много у вас было корпусов 4U с 45 дисками? Часто приходилось устанавливать УПСы весом 45 кг на высоту больше полутора метров? К тому же, рельсы для упсов не подразумевают ситуации, что УПС будет высунут из стойки на 2/3 длины и оставлен в таком положении. В таком случае при некоторой высоте установки имеет смысл сделать упор для всей стойки от опрокидывания.
> Я основываюсь на своем опыте работы с Software RAID.
а я вспоминаю ребилд 5-го рейда на 7 дисках 160 ГБ 10к РПМ УСКАЗИ-320 на недешевом аппаратном скази-рейд контроллере (какой-то адаптек, точную модель уже не вспомню), который занял что-то около 22 часов (рейд при этом, правда, работал). вряд ли они станут останавливать отдельный массив для его быстрого ребилда в оффлайн режиме.
> Мое мнение, что надежность брендового хранилища (без дублирования) тоже сомнительна, такак существует вероятность того что оно сдохнет. В случае же дублирования эта система позволяет довольно хорошо экономить.
мы сейчас что обсуждаем? сервис данного провайдера или данное хранилище для своих нужд?
> Вы это в условиях нашли? Или так гадаете?
EULA наше все.
пока все, что я увидел — это только уголок НЕ НА ВСЮ длину корпуса на имеющейся фотографии. А в ролике можно показать хоть автоматическую систему исталляции дисков — толку-то от этого какой?
И еще — много у вас было корпусов 4U с 45 дисками? Часто приходилось устанавливать УПСы весом 45 кг на высоту больше полутора метров? К тому же, рельсы для упсов не подразумевают ситуации, что УПС будет высунут из стойки на 2/3 длины и оставлен в таком положении. В таком случае при некоторой высоте установки имеет смысл сделать упор для всей стойки от опрокидывания.
> Я основываюсь на своем опыте работы с Software RAID.
а я вспоминаю ребилд 5-го рейда на 7 дисках 160 ГБ 10к РПМ УСКАЗИ-320 на недешевом аппаратном скази-рейд контроллере (какой-то адаптек, точную модель уже не вспомню), который занял что-то около 22 часов (рейд при этом, правда, работал). вряд ли они станут останавливать отдельный массив для его быстрого ребилда в оффлайн режиме.
> Мое мнение, что надежность брендового хранилища (без дублирования) тоже сомнительна, такак существует вероятность того что оно сдохнет. В случае же дублирования эта система позволяет довольно хорошо экономить.
мы сейчас что обсуждаем? сервис данного провайдера или данное хранилище для своих нужд?
> Вы это в условиях нашли? Или так гадаете?
EULA наше все.
И еще — много у вас было корпусов 4U с 45 дисками?
У меня есть корпус под 16 дисков забитый на половину у него тоже перевес в переднюю часть наблюдается и он тоже на рельсах и как-то не падает.
Часто приходилось устанавливать УПСы весом 45 кг на высоту больше полутора метров? К тому же, рельсы для упсов не подразумевают ситуации, что УПС будет высунут из стойки на 2/3 длины и оставлен в таком положении. В таком случае при некоторой высоте установки имеет смысл сделать упор для всей стойки от опрокидывания.
Давайте вопрос падает оно оттуда или не падает оставим на товарищам с сопроматом? Это это расчитывается а не делается на глазок, упор для стойки от опрокидывания конечно потребуется.
а я вспоминаю ребилд 5-го рейда на 7 дисках 160 ГБ 10к РПМ УСКАЗИ-320 на недешевом аппаратном скази-рейд контроллере (какой-то адаптек, точную модель уже не вспомню), который занял что-то около 22 часов (рейд при этом, правда, работал). вряд ли они станут останавливать отдельный массив для его быстрого ребилда в оффлайн режиме.
На аппаратных рейдах стоят маломощные по сравнению с CPU процессоры. Расширение Software RAID5 до 5 дисков с четырех посредством добавления 250Gb (сам рейд 1Tb) занял 2 часа. Причем в этом рейде есть два IDE диска. Изменение размера поисходило в online режиме. Так что вы сначала пробуйте SoftwareRAID погонять.
мы сейчас что обсуждаем? сервис данного провайдера или данное хранилище для своих нужд?
Если для своих нужд, то у меня есть вот такой вот ящик
www.aicipc.ru/products/servernye_korpusa/rackmount_storage_chassis_rsc/3u_rackmount_storage_chassis_rsc/70/
Плотность установки дисков в нем сравнима с тем что у них. Единственная разница это то что они стоят горизонтально. Там есть сдвоенный блок питания, но вот остальное в том числе диски, материнская плата и контроллеры полностью аналогичны тем что использованы в железяке выше и у меня так же используется Software RAID6. Ну каналов правда у меня поболее т.е. один диск один канал.
Я это все к чему. Надежность такого решения достаточна при условии его дублирования.
>У меня есть корпус под 16 дисков забитый на половину у него тоже перевес в переднюю часть наблюдается и он тоже на рельсах и как-то не падает.
есть разница — 8 дисков и 45. К тому же балансировка у них разная. Ну и как бы вес отличается при полной загрузке почти в 2 раза
>Давайте вопрос падает оно оттуда или не падает оставим на товарищам с сопроматом? Это это расчитывается а не делается на глазок, упор для стойки от опрокидывания конечно потребуется.
мое мнение — при массовом обслуживании в данном виде корпус неудобен.
>На аппаратных рейдах стоят маломощные по сравнению с CPU процессоры. Расширение Software RAID5 до 5 дисков с четырех посредством добавления 250Gb (сам рейд 1Tb) занял 2 часа. Причем в этом рейде есть два IDE диска. Изменение размера поисходило в online режиме. Так что вы сначала пробуйте SoftwareRAID погонять.
Хорошо, «каждый поехал своею дорогой, а поезд поехал своей» как пелось в одной песне.
>Если для своих нужд, то у меня есть вот такой вот ящик
www.aicipc.ru/products/servernye_korpusa/rackmount_storage_chassis_rsc/3u_rackmount_storage_chassis_rsc/70
симпатичная железяка. Правда, количество дисков почти в 3 раза меньше. Зато 3 БП 2+1 (в максимальной комплектации). Ну и количество каналов так же играет свою роль.
> Я это все к чему. Надежность такого решения достаточна при условии его дублирования.
Вот с этим я абсолютно согласен. Пресловутая стоимость терабайта играет свою роль и данный продукт (железка, а не услуга по хранению бекапа) наверняка может занять свою нишу.
есть разница — 8 дисков и 45. К тому же балансировка у них разная. Ну и как бы вес отличается при полной загрузке почти в 2 раза
>Давайте вопрос падает оно оттуда или не падает оставим на товарищам с сопроматом? Это это расчитывается а не делается на глазок, упор для стойки от опрокидывания конечно потребуется.
мое мнение — при массовом обслуживании в данном виде корпус неудобен.
>На аппаратных рейдах стоят маломощные по сравнению с CPU процессоры. Расширение Software RAID5 до 5 дисков с четырех посредством добавления 250Gb (сам рейд 1Tb) занял 2 часа. Причем в этом рейде есть два IDE диска. Изменение размера поисходило в online режиме. Так что вы сначала пробуйте SoftwareRAID погонять.
Хорошо, «каждый поехал своею дорогой, а поезд поехал своей» как пелось в одной песне.
>Если для своих нужд, то у меня есть вот такой вот ящик
www.aicipc.ru/products/servernye_korpusa/rackmount_storage_chassis_rsc/3u_rackmount_storage_chassis_rsc/70
симпатичная железяка. Правда, количество дисков почти в 3 раза меньше. Зато 3 БП 2+1 (в максимальной комплектации). Ну и количество каналов так же играет свою роль.
> Я это все к чему. Надежность такого решения достаточна при условии его дублирования.
Вот с этим я абсолютно согласен. Пресловутая стоимость терабайта играет свою роль и данный продукт (железка, а не услуга по хранению бекапа) наверняка может занять свою нишу.
есть разница — 8 дисков и 45. К тому же балансировка у них разная. Ну и как бы вес отличается при полной загрузке почти в 2 раза
У них даже лучше, так-как центр тяжести ближе к середине у меня на переднюю часть приходится. Даже восемь дисков тяжеел БП.
мое мнение — при массовом обслуживании в данном виде корпус неудобен.
Если он выдвигается и не падает, то единственная проблема это сплошная крышка, лучше было бы сделать две на каждую половину.
Хорошо, «каждый поехал своею дорогой, а поезд поехал своей» как пелось в одной песне.
Я просто недавно на новом Adaptec ребилдил RAID6 на 8 дисках (500Gb), так он существенно дольше лопатил.
симпатичная железяка. Правда, количество дисков почти в 3 раза меньше.
Тут другое расположение. Подобное расположение дисков они кстати просто подрезали у Sun. X4550 обладает аналогичным механизмом загрузки.
Ну вот предположим, что надо заменить 3 диск на 8 бекплейне — для этого надо вытащить полностью загруженный сервер практически 2/3 его длины. По уголку, не по рельсам.
>Если он выдвигается и не падает
Ну если 4 человека выдвигают и держат, то не падает. Может быть, имело бы смысл сделать выдвигающуюся на рельсах платформу с дисками из самого сервера. И сделать не 4U, а 5U высотой. Интересно было бы узнать, кто мог бы стать покупателем такого хранилища и каким бы спросом оно пользовалось.
>Если он выдвигается и не падает
Ну если 4 человека выдвигают и держат, то не падает. Может быть, имело бы смысл сделать выдвигающуюся на рельсах платформу с дисками из самого сервера. И сделать не 4U, а 5U высотой. Интересно было бы узнать, кто мог бы стать покупателем такого хранилища и каким бы спросом оно пользовалось.
По уголку, не по рельсам.
В видео есть рельсы. На фото рельсов физически видно не может, как и вашего присловутого уголка.
Может быть, имело бы смысл сделать выдвигающуюся на рельсах платформу с дисками из самого сервера. И сделать не 4U, а 5U высотой. Интересно было бы узнать, кто мог бы стать покупателем такого хранилища и каким бы спросом оно пользовалось.
Спросите у Sun. X4550 обладает аналогичной компоновкой. И первыми ее собсвенно Sun придумала, эти товарищи сделали лишь бюджетный вариант.
В видео есть.
А вот картинка
blog.backblaze.com/wp-content/uploads/2009/08/tim-backblaze-datacenter-servers.jpg
на ней отчетливо виден уголок, а не рельса. Или надо обвести его черным цветом?
теперь будем спорить про уголки? к чему это все?
А вот картинка
blog.backblaze.com/wp-content/uploads/2009/08/tim-backblaze-datacenter-servers.jpg
на ней отчетливо виден уголок, а не рельса. Или надо обвести его черным цветом?
теперь будем спорить про уголки? к чему это все?
Наконец-то я его увидел, но че-то хлипок шибко как-то :]
*протягивая руки в верх и смотря в небо*
ну наконец-то :)
дык об чем и речь, что как-то хлипко. Часто так не навынимаешься.
ну наконец-то :)
дык об чем и речь, что как-то хлипко. Часто так не навынимаешься.
он слишком тонок. Есть подозрение что это банальная направляющая.
Смотрите-ка, вы оказались упорнее меня. Мне в первом топике его убедить в этом не удалось. ;)
признаться, я уже глубоко сожалею об этом. Это все равно, что обсуждать наряды девушки — «вот там синенькое, это наверное шарфик!» — «Нет, есть подозрение что это виднеется обстрочка платья». И никому уже нет разницы, что это девушка и не девушка вовсе, а злобный дядя милиционер.
вот такой он спор — бессмысленный и беспощадный
вот такой он спор — бессмысленный и беспощадный
в данном случае, думается отказ psu не вероятнее отказа ввода, при такой цене железа не думаю что у них там с этим очень хорошо, они не скрывают бюджетности — и при бюджетности простой на замену psu вполне приемлем — вообще гляда на цену psu думаю что они прошли отбор по схемотехнике, т.е. 750Вт от именитых вендоров за 50% цены валом, т.е. вариант «летит psu тянет за собой ВСЕ винты» сведен к минимуму на уровне схемотехники
именно.
соответственно, если надежность ВСЕГО сервера определяется надежностью самого ненадежного компонента, то зачем нам надежный РЕЙД-6?
соответственно, если надежность ВСЕГО сервера определяется надежностью самого ненадежного компонента, то зачем нам надежный РЕЙД-6?
эээээ не понял, надежность железки != надежности хранения данных, сгорел бп или один винт, поменяли за час, извинились перед клиентом, клиент имеет данные дальше… выпали больше двух винтов из райда… суши весла и готовься к судебному иску от пользователя который 100% потерял свои данные
Примерно так. Только судебные иски бессмысленны. Сервис предоставляется, как это абсолютно всегда происходит с программным обеспечением, как есть, со всеми дефектами и багами. Не нравится — не используй. Используешь — согласился с EULA, в котором большими буквами (в прямом смысле) написано, что соглашаешься на "как есть".
И если вам это кажется странным, то вы таки житель 1/6 части суши, который может позволить себе не читать EULA никогда.
Вероятность потери данных есть всегда, и надо быть человеком редкой наивности, чтобы этого не понимать (это я не про вас, standov, а вообще про людей). Сделаете двойное дублирование — зальёт наводнением этаж. Сделаете тройное — террористы направят самолёт на дэйтацентр, как это было 9/11. Сделаете несколько дэйтацентров — в одном землетрясение (а они в Калифорнии нередко) поломает жесткие диски, а в другой врежется бензовоз. И пытаться сделать вероятность нулевой глупо. Речь лишь об умножении её на достаточно маленький коэффициент. С чем и замечательно справляется RAID6 + программная логика более высокого уровня.
По поводу аварии блока питания: на практике только бэкап может происходить каждый день. Рестор — крайне редкая операция. Поэтому с высокой вероятностью (тем более высокой, чем больше серверов у Backblaze) сгорания БП вообще клиенты не заметят. Сгорел — спокойно заменили за часа 4, включили, работает. Бэкапы тем временем отправлялись «маршрутизатором» на другие серверы. А рестор с именно этого сервера именно в эти 4 часа маловероятен. В общем, даже извиняться реально ни перед кем не придётся.
И если вам это кажется странным, то вы таки житель 1/6 части суши, который может позволить себе не читать EULA никогда.
Вероятность потери данных есть всегда, и надо быть человеком редкой наивности, чтобы этого не понимать (это я не про вас, standov, а вообще про людей). Сделаете двойное дублирование — зальёт наводнением этаж. Сделаете тройное — террористы направят самолёт на дэйтацентр, как это было 9/11. Сделаете несколько дэйтацентров — в одном землетрясение (а они в Калифорнии нередко) поломает жесткие диски, а в другой врежется бензовоз. И пытаться сделать вероятность нулевой глупо. Речь лишь об умножении её на достаточно маленький коэффициент. С чем и замечательно справляется RAID6 + программная логика более высокого уровня.
По поводу аварии блока питания: на практике только бэкап может происходить каждый день. Рестор — крайне редкая операция. Поэтому с высокой вероятностью (тем более высокой, чем больше серверов у Backblaze) сгорания БП вообще клиенты не заметят. Сгорел — спокойно заменили за часа 4, включили, работает. Бэкапы тем временем отправлялись «маршрутизатором» на другие серверы. А рестор с именно этого сервера именно в эти 4 часа маловероятен. В общем, даже извиняться реально ни перед кем не придётся.
под надежностью я понимал процент гарантированной доступности.
я исходил из того, что данные дублировались где-то еще, т.е. вышел из строя данный сторадж — данные доступны на другом.
а в случае. если все яйца в одной корзине…
где гарантия, что из-за сбоя по питанию медным тазом не накроется весь рейд?
я исходил из того, что данные дублировались где-то еще, т.е. вышел из строя данный сторадж — данные доступны на другом.
а в случае. если все яйца в одной корзине…
где гарантия, что из-за сбоя по питанию медным тазом не накроется весь рейд?
UFO just landed and posted this here
есть мнение что дело в дешевых контроллерах, которые этот режим не держат
а почему использовали RAID6 вместо RAID5EE?
Я не специалист по RAID, но Капитан О. Чевидность подсказывает мне, что потому, что стандартный уровень RAID6, допускает аварию двух дисков, а нестандартный уровень 5EE — только одного.
Например потому, что это проперитарная реализация в некоторых аппаратных контроллерах RAID.
en.wikipedia.org/wiki/Non-standard_RAID_levels#RAID_5E.2C_RAID_5EE_and_RAID_6E
en.wikipedia.org/wiki/Non-standard_RAID_levels#RAID_5E.2C_RAID_5EE_and_RAID_6E
А мы вдохновились и делаем :-)
Sign up to leave a comment.
Бюджетные петабайты: Как построить дешевое облачное хранилище. ч. 2