Винчестер с авито... Стоит ли?

[Gudronov]

Объясню немного корни сдвига восприятия мною подобной информации.
Во-первых, я в курсах всех этих дел настолько, что давно не испытываю ни эйфории, ни даже интереса.
Положение усубляется тем, что я начавший в 89, и до сих пор действующий программер, пропахавший все что можно, начиная от доски с фортраном и асмом, и скорее поверю в утонувшего Буратино, чем в достоинства программного рейда.
Отсюда мое некоторое излишнее неприятие вызывающих такой восторг плюшек .

[pyos]

Положение усубляется тем, что я начавший в 89, и до сих пор

, судя по всему, продолжающий жить в 89ом.

Отсюда мое некоторое излишнее неприятие вызывающих такой восторг плюшек .

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

[Openreel]

Разве это что то меняет? Не работает как требуется, значит сдохла.

Ты держишь в руках тарелку супа. Съел и голодный. Это не тарелка сдохла, это несоответствие реальности и ожиданий. А если ты начал есть суп, тарелку выронил и разбил - таки сдохла.

Ресурс флеши ограничен, это просто факт. Но ты должен понимать, что ресурс не только ххх тб записи,как вещает реклама, а ресурс уу раз стираний физических кластеров. Вот берешь ты флешку, пишешь на неё 10 килобайт в минуту и раз в минуту делаешь flush, чтоб данные не терять. А дальше, в зависимости от размера кластера флеши(не файловой системы!) у тебе с происходит стирание целого кластера, а не несчастных 10кб. И в такой ситуации ресурс флеши заканчивается гораздо быстрей, чем ты ожидал. Что еще интересней - с ростом размера флеши рост размера кластера еще быстрей и получается ресурс у мелких карт выше, чем у карт большего объёма. Короче, нужно обратить внимание на сам процесс юзанья, вполне возможно таблы с ресурсом заложены именно тут. Например кидаем на флешку каждый день гору мелких файлов, вместо одного архива.

Так мне вот и интересно, у SSD тоже быстро ресурс закончится?

У приличного SSD ресурс конечно выше, но тут уже надо смотреть нюансы, как оно через USB проброшено, насколько там все нужное SSD транслируется, или как всегда. В этом плане разные конверторы sata-usb и раньше разительно отличались, например смарт зачитать можно было далеко не через все.
В этом плане классичный хард имеет меньше гемора.

[Gudronov]

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

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

[DmitryU]

Объясню немного корни сдвига восприятия мною подобной информации.
Положение усубляется тем, что я начавший в 89, и до сих пор действующий программер, пропахавший все что можно, начиная от доски с фортраном и асмом, и скорее поверю в утонувшего Буратино, чем в достоинства программного рейда.

Ничего, что все более-менее крупные системы программно-определяемые и дисковые подсистемы у них чаще всего тоже? Вон, за стенкой у меня стоят три хранилки NetApp, которые при ближайшем рассмотрении являются компьютерами с кучей дисков и с кастомной операционной системой, не удивлюсь, если на базе линукса, кстати. И рядом стоит себе пара самосборных хранилок на Linux/Zfs. И все это во вполне продуктивной среде... И таких инсталляций несть числа. И вполне себе надежно (тут я постучу по дереву).

P.S. Я тоже начинал в 80х, и тоже давно уже без восторга.

[Gudronov]

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

Offтопик:
Чтобы далеко не ходить, у меня массив всего 16T, и этого достаточно для WMS площадью регион, со всеми потрохами, включая растровые поля (отнюдь не яндексового разрешения). И там же копия файлопомойки (кстати, с линуксового сервера), пара СУБД с пространственными базами и горячими архивами всякой мелочи. И совершенно спокойно справляется самый простой адаптек с 10 рейдом из 4 винтов. И, случись что с машиной, но не с рейдом, через полчаса я худо-бедно подниму работу на другом компе, без лишних движений.

[Оллема]

Openreel, так основной смысл был в предложении: "Разве это что то меняет? " - новую все равно надо приобретать, за просвещение, конечно, спасибо, хоть я и в курсе описанного

---------- Сообщение добавлено 12:34 ---------- Предыдущее сообщение было 12:32 ----------

В этом плане классичный хард имеет меньше гемора.

Но и меньше удобств по переноске информации, поскольку нет интерфейса USB, предоставляющий удобства "воткни куда хочешь"

[shkal]

Простите, но "крупные хранилища" никто так не собирает, с определённого уровня у всех стоят дисковые полки с резервированием всего, включая контроллеры, обычно IBM или hp

[pyos]

Простите, но "крупные хранилища" никто так не собирает, с определённого уровня у всех стоят дисковые полки с резервированием всего, включая контроллеры, обычно IBM или hp

Естественно, там стоят контроллеры, не к материнской же плате там подключать десятки-сотни дисков! И, естественно, там стоят дисковые полки, чтобы не покупать новый сервер, когда в нём кончатся посадочные под ХДД, особенно если это не СХД-шный сервер изначально.
Только вот никто при этом не заставляет использовать рейд за счёт аппаратных средств этих контроллеров, особенно учитывая кривущую реализацию всех этих всратых мегарейдовских утилит при наличии удобных утилит управления/мониторинга софтового массива у той же ХП, которая, к тому же, позволяет зависеть только от своего кода, а не чужого, зашитого в биос контроллеров. А в случае ZFS-массива аппаратный рейд в принципе неприменим.

Такое ощущение, что бо́льшая часть присутствующих даже не понимают, что именно они так рьяно критикуют.

PS

контроллеры, обычно IBM или hp

Все эти ибмы, хпы и саны - не более, чем LSI c шильдиком той или иной конторы на ПП и, иногда (сан любил этим баловаться) кастомной прошивкой, которая не даёт ему запуститься на неродном сервере.

---------- Сообщение добавлено 14:40 ---------- Предыдущее сообщение было 14:39 ----------

Я знаю и пару админов, которые тоже помнят, как все начиналось

Да-да-да. И ничего с тех пор не видели. Я уже понял, что 89ый год был апофеозом развития IT, дальше смотреть ни в коем случае нельзя.

[Openreel]

Но и меньше удобств по переноске информации, поскольку нет интерфейса USB, предоставляющий удобства "воткни куда хочешь"

Под словом "классичный хард" имелся ввиду 2.5 дюйма в коробке с USB.

---------- Сообщение добавлено 18:53 ---------- Предыдущее сообщение было 18:46 ----------

Как бы да. Файловая шара - 3 диска в пятом рейде, диск, куда пишутся автоматом бекапы - ещё два в первом, плюс по запасному диску на каждый массив. Уже семь.
Это если закрыть глаза на то, что у многих плат сейчас сата-портов всего 4.

Я про домашку. По моему опыту, если в системник воткнуть больше трёх хардов, то уже надо делать принудительное охлаждение, а это всегда лишний шум. Если больше шести, то уже вопрос, а что это за бытовой корпус.
Тогда проще сразу брать на вторичке стоечный сервак с кассетами, резервированием и всем настоящем. В свое время мог ХПшных 19" домой притащить. Но на кой мне дома этот ацкий вой нужен?!

[Ulis]

Для дома, с трема и более хардами, имеет смысл уже делать кастомный корпус, заглушенный не хуже корпуса хорошей АС.

[pyos]

Ulis, достаточно купить готовый "тихий".

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

---------- Сообщение добавлено 08:35 ---------- Предыдущее сообщение было 06:19 ----------

Я про домашку.

Я тоже. В том посте я описал свой "сервер" в кладовой.

[funny the rat]

а вне виртуалок всё равно никакие функции на серверах не ставят)

Высокопроизводительное сплошь и рядом на баре-метал. более менее серьёзные сервера реляционных баз данных практически исключительно на баре-метал по многим совершенно очевидным причинам. Всевозможные высокопроизводительные процессинговые сервера тоже как правило на бар-метал.

[pyos]

Offтопик:

Высокопроизводительное сплошь и рядом на баре-метал

Если ты про кластеры для распределённых вычислений и подобные железки - то, наверное, да, я про них не знаю ничего, кроме того, что они есть я про вебовские и СХД говорил, в основном.

[funny the rat]

Простите, но "крупные хранилища" никто так не собирает, с определённого уровня у всех стоят дисковые полки с резервированием всего, включая контроллеры, обычно IBM или hp

+1000500 именно полно 4у jbod корпусов на 48, 60, 64, 102 3.5" hdd с высокосокоростными интерфейсами. А для быстрых хранилищ соответственно там уже сплошной флеш, есть корпуса петабайтной ёмкости с соответствующими ценами.

Все эти ибмы, хпы и саны - не более, чем LSI c шильдиком той или иной конторы на ПП и, иногда (сан любил этим баловаться) кастомной прошивкой, которая не даёт ему запуститься на неродном сервере.

+1

Под словом "классичный хард" имелся ввиду 2.5 дюйма в коробке с USB.

нету 2.5" ёмких шпинделей. А особого смысла для флеша в САТА тоже не осталось. Поэтому если дешево, много и медленно, то только 3.5" шпиндель

---------- Сообщение добавлено 04:20 ---------- Предыдущее сообщение было 04:14 ----------

Если ты про кластеры для распределённых вычислений и подобные железки

Да банальный SQL работает быстрее и беспроблемнее (лучше держит нагрузку) на баре-метал. С большими базами со сложнымио зaпросами и кучей юзеров его смысла пихать в vm не имеет ибо все ресурсы хайпервайзора скорее всего ему отданы и будут даже без учёта тонкостей конфига под конкретные задачи
типа 48+ ядер с частотами за от 3+ ГГц и пол терра оперативки это часто чуть ли не минимум

[pyos]

Offтопик:

С большими базами со сложнымио зaпросами и кучей юзеров его смысла пихать в vm не имеет ибо все ресурсы хайпервайзора скорее всего ему отданы

На самом деле не редкость, когда на одной железке крутится одна виртуалку, а причина использовать виртуалку, а не голое железо, в таком случае почти всегда одна - лёгкость переноса системы на новое/запасное/просто другое железо. Да и при большом количестве виртуалок на одном гипере оная лёгкость тоже, зачастую, решает.

Другой вопрос, что, зачастую "бареметал" - это просто гипервизор первого типа с одной гостевой системой на нём.

[funny the rat]

Offтопик:

причина использовать виртуалку, а не голое железо, в таком случае почти всегда одна

В случае более менее серьёзных дб легкость переноса это даже не двадцатая причина в списке и в таких случаех нет никакого смысла виртуалить

[shkal]

pyos, Вы явно не понимаете, что такое дисковая полка, поэтому дальше написана ахинея.

[pyos]

shkal, прекрасно понимаю в отличие от. По факту есть что возразить?

[shkal]

По факту есть что возразить?

Угу. Дисковая полка - эта законченное устройство с блочным доступом, по FC либо iSCSI. обычно содержит дублированные БП и контроллеры, которые могут автоматически переподцеплять диски к другому при выходе из строя первого. От ОС хоста они вообще никак не зависят, управление конфигурацией осуществляется самой железкой, хостоя можно подключить сколько угодно, либо побить физический массив на ЛУНы и каждому выдать свой, либо совместно использовать, если ОС такой режим поддерживает (у MS только в кластерах). Никаких мегараидовских утилит там и блико нет, как и LSI (теперь broadcom) законченных раид-контроллеров. Плюс есть некоторые фичи типа репликации данных на другую полку без участия хоста.

Типичный пример (с 1 контроллером) https://www.hp-pro.net/Netshop/Stora...Y70A00KEA.html