>У меня есть корпус под 16 дисков забитый на половину у него тоже перевес в переднюю часть наблюдается и он тоже на рельсах и как-то не падает.
есть разница — 8 дисков и 45. К тому же балансировка у них разная. Ну и как бы вес отличается при полной загрузке почти в 2 раза
>Давайте вопрос падает оно оттуда или не падает оставим на товарищам с сопроматом? Это это расчитывается а не делается на глазок, упор для стойки от опрокидывания конечно потребуется.
мое мнение — при массовом обслуживании в данном виде корпус неудобен.
>На аппаратных рейдах стоят маломощные по сравнению с CPU процессоры. Расширение Software RAID5 до 5 дисков с четырех посредством добавления 250Gb (сам рейд 1Tb) занял 2 часа. Причем в этом рейде есть два IDE диска. Изменение размера поисходило в online режиме. Так что вы сначала пробуйте SoftwareRAID погонять.
Хорошо, «каждый поехал своею дорогой, а поезд поехал своей» как пелось в одной песне.
симпатичная железяка. Правда, количество дисков почти в 3 раза меньше. Зато 3 БП 2+1 (в максимальной комплектации). Ну и количество каналов так же играет свою роль.
> Я это все к чему. Надежность такого решения достаточна при условии его дублирования.
Вот с этим я абсолютно согласен. Пресловутая стоимость терабайта играет свою роль и данный продукт (железка, а не услуга по хранению бекапа) наверняка может занять свою нишу.
да, если там данные хранятся на отдельном хранилище и более нигде не дублируются, то естественно, рейд там жизненно необходим. Но помимо рейда им бы следовало реализовать еще систему отказоустойчивого электроснабжения с горячей заменой БП ибо в случае выхода хотя бы одного из них система встает намертво и быстренько ее оживить весьма проблематично. Отказ матери, процессора, памяти, контроллеров, бекплейнов будем считать маловероятными.
в случае же дублирования наличие рейда уже не критичен.
> Я думаю что люди знают сапромат и заказывают рельсы из правильных материалов. У меня вот как-то за все время эксплуатации рельсов ни одни из них не надломились. Нагрузка там кстати говоря не особо критичная порядка 50 кг. Столько весит один UPS, а для них рельсы бывают в полный рост.
пока все, что я увидел — это только уголок НЕ НА ВСЮ длину корпуса на имеющейся фотографии. А в ролике можно показать хоть автоматическую систему исталляции дисков — толку-то от этого какой?
И еще — много у вас было корпусов 4U с 45 дисками? Часто приходилось устанавливать УПСы весом 45 кг на высоту больше полутора метров? К тому же, рельсы для упсов не подразумевают ситуации, что УПС будет высунут из стойки на 2/3 длины и оставлен в таком положении. В таком случае при некоторой высоте установки имеет смысл сделать упор для всей стойки от опрокидывания.
> Я основываюсь на своем опыте работы с Software RAID.
а я вспоминаю ребилд 5-го рейда на 7 дисках 160 ГБ 10к РПМ УСКАЗИ-320 на недешевом аппаратном скази-рейд контроллере (какой-то адаптек, точную модель уже не вспомню), который занял что-то около 22 часов (рейд при этом, правда, работал). вряд ли они станут останавливать отдельный массив для его быстрого ребилда в оффлайн режиме.
> Мое мнение, что надежность брендового хранилища (без дублирования) тоже сомнительна, такак существует вероятность того что оно сдохнет. В случае же дублирования эта система позволяет довольно хорошо экономить.
мы сейчас что обсуждаем? сервис данного провайдера или данное хранилище для своих нужд?
> Вы это в условиях нашли? Или так гадаете?
EULA наше все.
>Посмотрите ролик еще раз. Рельсы находятся со стороны жестких дисков. К тому не упадет он из-аз банальной жесткости рельсов нагрузка будет поперечная а там профиль. У нас подобные рельсы есть как-то ничего с них ни разу не падало.
посмотрел еще раз. Рельсы видно только в ролике, на картинке их не видно. Так что верю тому, что есть на фото. Не зная характеристик материала корпуса, можно предполагать что угодно. Я вполне допускаю такой вариант, что будучи высунутым на расстояние отсека дисков, под 45 дисками профиль корпуса может и не выдержать и надломиться.
>Первое быстрее, процессора у нас до дури (ребилд занимает обычно не более 20-30% одного ядра), а скорость SATA выше чем Ethernet 1G. Плюс во время ребилда можно спокойно продолжать писать данные и сеть не занята передачей данных.
я считаю иначе. и оба будем банально гадать.
>RAID товарищи делали только для уменьшения сетевого трафика и заморочек с дисками. У гугла я хочу заметить используется своя файловая система которая не замечает потерь диска. Если же у вас смонтирована обычная файловая система и диск внезапно ломается, то ОС это заметит и у вас будут проблема. В случае RAID этого не происходит и выход диска из строя это штатная ситуация.
в случае, если дублирование отсутствует, то рейд конечно же жизненно необходим. Но опять-таки, одна из главных заповедей рейда: рейд не является средством резервного копирования.
>Вы забываете что у гугла своя файловая система :) У этих товарищей ее нет.
и, имхо, это основной их недостаток. мое мнение — надежность данного решения (без дублирования) в качестве бекапа крайне сомнительна. Если они не могут мне гарантировать доступность и целостность моих данных в разумных пределах времени и нести за это ответственность — то зачем мне платить им деньги за сомнительный сервис?
не зная всех параметров системы, я полагаю, что скорее будет таки среплицировать отдельный диск по сети. ибо ребилд с индексов с 14 дисков потребует значительной вычислительной мощности процессора. Где там написано про 3 канала на рейд?
понятно, еще раз повторю
если бы я захотел стать их клиентом, то я бы сильно задумался о выборе именного этого провайдера, узнав. на чем они построили свою архитектуру.
это мое мнение, ни к чему не призывающее.
под надежностью я понимал процент гарантированной доступности.
я исходил из того, что данные дублировались где-то еще, т.е. вышел из строя данный сторадж — данные доступны на другом.
а в случае. если все яйца в одной корзине…
где гарантия, что из-за сбоя по питанию медным тазом не накроется весь рейд?
вот и я тоже не знаю
тут вообще полно догадок и домыслов.
но если бы я решил стать их клиентом и, узнав инфраструктуру, хорошенько бы задумался, прежде чем доверять им свои данные.
Хорошо. Рейд — софтварный. Компоненты — бюджетные (т.е. не высокопроизводительные).
Повторю свой вопрос: что быстрее — сребилдить софтварный рейд-6, емкостью 19,5 ТБ, из состояния degrated силами процессора или среплицировать 1,5 TB по SATA-300 по сети (неизвестной пропускной способности) с другого сервера?
>Но тот сторадж, что вышел из строя простаивает и чем быстрее вы его вернете на место тем лучше.
Да, при выходе винта из строя, сервер продолжит работу. Но скорость работы будет ниже. К тому же, рано или поздно, винт таки придется менять.
>Вообще-то как раз с hot-swap. Там используются backsplane с совмещенными разъемами питания и данных. Вытягиваете винчесте на себя он отключается, ставите обратно включается. Это все можно делать на ходу и используемые ими контроллеры это поддерживают.
Хорошо, пусть будет так.
>Там рельсы. Достаточно выкатить на половину и сбросить крышку.
Рельсы заметил в ролике. На картинке увидел только уголок. Согласитесь, это далеко не одно и то же. К тому же, половина сервера, где расположены диски, ЗНАЧИТЕЛЬНО тяжелее той половины, где мат. плата. Где гарантия, что сервер банально не упадет под силой тяжести половины с винтами?
>Скажите что быстрее востановка RAID6 на 19.5 террабайт или заливка по новой этих самых 19.5 террбайт по сети?
Позволю себе задать встречный вопрос: что быстрее — сребилдить рейд из дегрейтед (19,5 ТБ) или среплицировать одиночный винт с другого сервера (1,5ТБ)? (имеется в виду ситуация, когда каждый винт — отдельная единица хранения).
И еще — извините, но мне наш разговор напоминает общение глухого со слепым. Ни вы, ни я не видели этих серверов в живую и не знаем, чем руководствовались разработчики. Я просто выражаю свое мнение, что если бы я делал такой сервер (к тому же, дублирующийся), я бы не стал заморачиваться с рейдом и потерей 2 дисков на массив (принцип Гугла). Я не говорю, что рейд — это что-то бесполезное. Просто в ситуации с дублированием это уже лишнее. Данный спор ни к чему не приведет. Предлагаю закончить на этом. Идет?
>Для уменьшения простоя.
Какой простой, если сервера дублируются?
>конструкция позволяет их менять на ходу и не терять данные
честно говоря, не заметил в тексте, чтобы диски были с hot-swap. К тому же, для замены надо вынимать весь сервер из стойки. Вряд ли это можно делать на работающем сервере.
Опять-таки, скорость деградировавшего рейда ниже. А без рейда информация с упавшего диска была бы взята просто с другого сервера.
Я бы не был столь категоричен. Для бекап-стораджа оно вполне подходит. Другое дело, что если их сервера дублируются, то зачем терять 6 дисков в массивах РЕЙД-6.
И это правильно, что они продублированы. Потому что если бы этого не было, и в это самое время мне понадобились мои данные — смог бы я их получить? Вы сами перечислили возможные точки отказа. Но возникает вопрос — если они продублированы (т.е. мои данные доступны в любое время), то зачем там РЕЙД-6 (т.е. грубо говоря, теряется 6 дисков), если все равно при выходе одного диска (или же БП, памяти, контроллера, бек-плейна и т.д.) из строя, придется останавливать весь сервер? Или же они будут ждать, пока не накопится хотя бы 3 диска (по 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 (в максимальной комплектации). Ну и количество каналов так же играет свою роль.
> Я это все к чему. Надежность такого решения достаточна при условии его дублирования.
Вот с этим я абсолютно согласен. Пресловутая стоимость терабайта играет свою роль и данный продукт (железка, а не услуга по хранению бекапа) наверняка может занять свою нишу.
в случае же дублирования наличие рейда уже не критичен.
пока все, что я увидел — это только уголок НЕ НА ВСЮ длину корпуса на имеющейся фотографии. А в ролике можно показать хоть автоматическую систему исталляции дисков — толку-то от этого какой?
И еще — много у вас было корпусов 4U с 45 дисками? Часто приходилось устанавливать УПСы весом 45 кг на высоту больше полутора метров? К тому же, рельсы для упсов не подразумевают ситуации, что УПС будет высунут из стойки на 2/3 длины и оставлен в таком положении. В таком случае при некоторой высоте установки имеет смысл сделать упор для всей стойки от опрокидывания.
> Я основываюсь на своем опыте работы с Software RAID.
а я вспоминаю ребилд 5-го рейда на 7 дисках 160 ГБ 10к РПМ УСКАЗИ-320 на недешевом аппаратном скази-рейд контроллере (какой-то адаптек, точную модель уже не вспомню), который занял что-то около 22 часов (рейд при этом, правда, работал). вряд ли они станут останавливать отдельный массив для его быстрого ребилда в оффлайн режиме.
> Мое мнение, что надежность брендового хранилища (без дублирования) тоже сомнительна, такак существует вероятность того что оно сдохнет. В случае же дублирования эта система позволяет довольно хорошо экономить.
мы сейчас что обсуждаем? сервис данного провайдера или данное хранилище для своих нужд?
> Вы это в условиях нашли? Или так гадаете?
EULA наше все.
и неизвестная нам вероятность, что именно в этот момент они могут измениться.
>30% от ядра максимум.
и часов 20 минимум
>45 дисков 9 SATA каналов. В каждом рейде по 15 дисков соответсвенно по 3 SATA канала на рейд.
и пять дисков на канал SATA-300 (помнится, множители портов не увеличивают пропускную скорость канала).
извините, о чем спор-то идет?
посмотрел еще раз. Рельсы видно только в ролике, на картинке их не видно. Так что верю тому, что есть на фото. Не зная характеристик материала корпуса, можно предполагать что угодно. Я вполне допускаю такой вариант, что будучи высунутым на расстояние отсека дисков, под 45 дисками профиль корпуса может и не выдержать и надломиться.
>Первое быстрее, процессора у нас до дури (ребилд занимает обычно не более 20-30% одного ядра), а скорость SATA выше чем Ethernet 1G. Плюс во время ребилда можно спокойно продолжать писать данные и сеть не занята передачей данных.
я считаю иначе. и оба будем банально гадать.
>RAID товарищи делали только для уменьшения сетевого трафика и заморочек с дисками. У гугла я хочу заметить используется своя файловая система которая не замечает потерь диска. Если же у вас смонтирована обычная файловая система и диск внезапно ломается, то ОС это заметит и у вас будут проблема. В случае RAID этого не происходит и выход диска из строя это штатная ситуация.
в случае, если дублирование отсутствует, то рейд конечно же жизненно необходим. Но опять-таки, одна из главных заповедей рейда: рейд не является средством резервного копирования.
>Вы забываете что у гугла своя файловая система :) У этих товарищей ее нет.
и, имхо, это основной их недостаток. мое мнение — надежность данного решения (без дублирования) в качестве бекапа крайне сомнительна. Если они не могут мне гарантировать доступность и целостность моих данных в разумных пределах времени и нести за это ответственность — то зачем мне платить им деньги за сомнительный сервис?
если бы я захотел стать их клиентом, то я бы сильно задумался о выборе именного этого провайдера, узнав. на чем они построили свою архитектуру.
это мое мнение, ни к чему не призывающее.
я исходил из того, что данные дублировались где-то еще, т.е. вышел из строя данный сторадж — данные доступны на другом.
а в случае. если все яйца в одной корзине…
где гарантия, что из-за сбоя по питанию медным тазом не накроется весь рейд?
тут вообще полно догадок и домыслов.
но если бы я решил стать их клиентом и, узнав инфраструктуру, хорошенько бы задумался, прежде чем доверять им свои данные.
соответственно, если надежность ВСЕГО сервера определяется надежностью самого ненадежного компонента, то зачем нам надежный РЕЙД-6?
Повторю свой вопрос: что быстрее — сребилдить софтварный рейд-6, емкостью 19,5 ТБ, из состояния degrated силами процессора или среплицировать 1,5 TB по SATA-300 по сети (неизвестной пропускной способности) с другого сервера?
Да, при выходе винта из строя, сервер продолжит работу. Но скорость работы будет ниже. К тому же, рано или поздно, винт таки придется менять.
>Вообще-то как раз с hot-swap. Там используются backsplane с совмещенными разъемами питания и данных. Вытягиваете винчесте на себя он отключается, ставите обратно включается. Это все можно делать на ходу и используемые ими контроллеры это поддерживают.
Хорошо, пусть будет так.
>Там рельсы. Достаточно выкатить на половину и сбросить крышку.
Рельсы заметил в ролике. На картинке увидел только уголок. Согласитесь, это далеко не одно и то же. К тому же, половина сервера, где расположены диски, ЗНАЧИТЕЛЬНО тяжелее той половины, где мат. плата. Где гарантия, что сервер банально не упадет под силой тяжести половины с винтами?
>Скажите что быстрее востановка RAID6 на 19.5 террабайт или заливка по новой этих самых 19.5 террбайт по сети?
Позволю себе задать встречный вопрос: что быстрее — сребилдить рейд из дегрейтед (19,5 ТБ) или среплицировать одиночный винт с другого сервера (1,5ТБ)? (имеется в виду ситуация, когда каждый винт — отдельная единица хранения).
И еще — извините, но мне наш разговор напоминает общение глухого со слепым. Ни вы, ни я не видели этих серверов в живую и не знаем, чем руководствовались разработчики. Я просто выражаю свое мнение, что если бы я делал такой сервер (к тому же, дублирующийся), я бы не стал заморачиваться с рейдом и потерей 2 дисков на массив (принцип Гугла). Я не говорю, что рейд — это что-то бесполезное. Просто в ситуации с дублированием это уже лишнее. Данный спор ни к чему не приведет. Предлагаю закончить на этом. Идет?
Какой простой, если сервера дублируются?
>конструкция позволяет их менять на ходу и не терять данные
честно говоря, не заметил в тексте, чтобы диски были с hot-swap. К тому же, для замены надо вынимать весь сервер из стойки. Вряд ли это можно делать на работающем сервере.
Опять-таки, скорость деградировавшего рейда ниже. А без рейда информация с упавшего диска была бы взята просто с другого сервера.
Я не говорю, что это решение плохое или нежизнеспособное. Просто они закрыли одну дырку в отказоустойчивости, оставив остальные, хотя если сервера дублируются целиком, то мое имхо — это просто трата дисков.
— как мне проехать к Теверской, если метро не работает?
— Вы перечислите и помендленнее, я записываю.
ЗЫ Я знаю, для чего нужен RAID, но не понимаю, о какой надежности идет речь: что вы будете делать, если откажет ХОТЯ бы один PSU?
Соответственно, если вам звонят, а письма нет — его можно поискать, включим поиск по спаму. Если оно там — обозначить его как НЕ спам. И все — дальше оно всегда будет доставляться.
Если же письмо не критично — отправят еще раз.
Так что про спам даже не вспоминаю — все, что более месяца, удаляется автоматически.
Ну так, иногда. ради развлечения можно зайти в папку, посмотреть, что сейчас пользуется «спросом».