LINUX.ORG.RU

Недостатки бездисковой загрузки

 , , , ,


0

4

Бездисковая загрузка имеет ряд преимуществ. Например, если уже имеются какие-то хранилища, то хотелось бы сэкономить на hdd и raid в новых серверах, они (диски) довольно дорого стоят. Под хранилищами подразумевается всё то, что можно выбрать в установщике CentOS. Или загрузку с помощью PXE нескольких узлов на мастер.

Как сделать так, чтобы экономия на непокупке дисков была выгодна по сравнению с покупкой коммутаторов и прочего сетевого оборудования?

Варианты использования - распределенные вычисления и анализ данных. Т.е. использование вычислительных узлов (различных по своему железу) для увеличения вычислительных возможностей.

По вашему опыту, какие подводные камни бездисковой загрузки? С экономической и других сторон. Почему бы вы не рекомендовали такую загрузку, а рекомендовали бы всё-таки использовать диски и raid.

Вопрос только теоретический, хотелось бы понять, почему IRL делают так, а не иначе.

Deleted

Последнее исправление: Deleted (всего исправлений: 2)

Если вы лично используете эту технику, то получите профит. Но в рамках организации с низким уровнем персонала и нечеткими оргцелями можете получить кучу гемороя.

Для нод кластера например всё равно понадобиться локальный /tmp для кеша дистрибутивной файловой системы и временных данных реально большого размера.

psv1967 ★★★★★
()

Нужно хорошее сетевое оборудование.

Deathstalker ★★★★★
()

Оборудование, скорость — это не аргумент.

Главный вопрос: вас устраивает «все яйца в одной корзине»?

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

anonymous
()

Флешка в каждый узел решит проблемы. 10$ хватит всем.

vitruss ★★★★★
()

Если это кластер - да, бездисковая загрузка сгодится (пару нод - под хранилище, остальные - чисто вычислительные). Или флэшка в рид онли. Если интенсивное дисковое i/o - тут уже придется либо FC/FCoE storage либо отдельный сторэдж на каждой ноде.

NiTr0 ★★★★★
()
Ответ на: комментарий от tailgunner

Ты уже в который раз пишешь неконструктивные ответы на мои вопросы (я веду подсчёт). Не надо так. Во-первых, я не сообщаю, что у меня есть большие данные. Во-вторых, я не рассчитываю получить здесь действительно развёрнутый ответ, мне нужны по крайней мере ключевые слова, которых я ещё не знаю, и краткие личные мнения опытных людей.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 5)
Ответ на: комментарий от Deleted

Ты уже в который раз пишешь неконструктивные ответы на мои вопросы. Во-первых, я не сообщаю, что у меня есть большие данные. Не надо так.

А некоторые заходят в топики по тегам. Тег «big data» ты поставил просто по приколу (что тег «hdd» по приколу - уже понятно)?

мне нужны по крайней мере ключевые слова, которых я ещё не знаю

«big data» - это анализ больших массивов данных (петабайты на сегодня) и к сетевой загрузке отношения не имеет.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

это анализ больших массивов данных

И даже это не big data, скорее much data, ты забыл про скорость обработки и скорость накопления новых данных.

Петабайт то за конечное время можно хоть на калькуляторе обработать, правда жизни одной не хватит.

сетевой загрузке отношения не имеет

Имеет и причем прямое, когда мы перестаем на узле хранить копию данных.

ErasimHolmogorin
()
Последнее исправление: ErasimHolmogorin (всего исправлений: 1)

Почему бы вы не рекомендовали такую загрузку, а рекомендовали бы всё-таки использовать диски и raid.
Вопрос только теоретический, хотелось бы понять, почему IRL делают так, а не иначе.

Потому что IRL люди, которые этим занимаются, умеют решать такие задачи. Сформулирую задачу в рамках ЗЛП и решай, тут ничего особо сложного нет.

ErasimHolmogorin
()
Ответ на: комментарий от ErasimHolmogorin

это анализ больших массивов данных

И даже это не big data, скорее much data, ты забыл про скорость обработки и скорость накопления новых данных.

Я привел общепринятое определение. Но ты имеешь полное право добавить к своему личному определению скорость обработки и вообще всё, что угодно.

сетевой загрузке отношения не имеет

Имеет и причем прямое, когда мы перестаем на узле хранить копию данных.

facepalm.jpg

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Я привел общепринятое определение.

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

Глянь, где big data работает и чем это отличается о того, что применяют в различных исследовательских институтах.

Имеет и причем прямое, когда мы перестаем на узле хранить копию данных.

facepalm.jpg

SM-MIMD, NUMA, DM-MIMD - для тебя знакомы такие слова? У меня складывается ощущение, что ты не в свою сферу лезешь.

ErasimHolmogorin
()
Последнее исправление: ErasimHolmogorin (всего исправлений: 1)
Ответ на: комментарий от ErasimHolmogorin

Глянь, где big data работает и чем это отличается о того, что применяют в различных исследовательских институтах.

Хм. Что именно ты понимаешь под big data? Расскажи - я уверен, всем будет интересно.

Имеет и причем прямое, когда мы перестаем на узле хранить копию данных.

facepalm.jpg

SM-MIMD, NUMA, DM-MIMD - для тебя знакомы такие слова?

Да. Правда, я использую их к месту.

tailgunner ★★★★★
()

Недостатки бездисковой загрузки

При правильной организации, никаких.

robot12 ★★★★★
()

TIL каждый админ локалхоста с рейдом занимается на самом деле бигдатой, гг.

nezamudich ★★
()
Ответ на: комментарий от tailgunner

Ты сначала объясни почему мы должны анализ петабайта данных называть big data? Я не вижу отличия с анализом гигабайта данных, просто будет в 1000 раз дольше обрабатываться.

ErasimHolmogorin
()
Ответ на: комментарий от ErasimHolmogorin

Ты сначала объясни почему мы должны анализ петабайта данных называть big data?

Я этого и не говорил. Но без петабайта сейчас - это не big data.

Я не вижу отличия с анализом гигабайта данных, просто будет в 1000 раз дольше обрабатываться.

Чтобы петабайт обрабатывался всего в 1000 раз медленее, чем гигабайт, понадобится другая архитектура и другие аппаратные средства. В 1000 раз дороже, ага.

Но вообще-то я спрашивал, что _ты_ понимаешь под big data. Ты ответишь?

tailgunner ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.