Хороший, но дешевый storage для ESXi

но денег для «решений корпоративного уровня» нет.

А чем текущий NAS не устраивает? В сетку/диски упираетесь? Имхо, самым безболезненным вариантом был бы RAID10 через iscsi и пара 10гбитных карточек в point-to-point без всякой кластеризации.

текущий NAS иногда может зависнуть, за последние полгода было уже два раза. Медленная скорость копирования с/на. Свич гигабитный, по спецификации сеть на NAS гигабит, но данные пишутся стабильно со скоростью 9,59 мб.сек. И в это время бэкап виртуалок не делался, сами виртуалки отвалились в read-only, а NAS оживился только хард ребутом. Потом писал, что проверяет целостность массива - видать SMART-событие срабатывает, но функционала по его проверке в данном NAS нет. Да тоже думал 1 машину с RAID10. Но что будет, если мать просто возьмет и умрет?

Но что будет, если мать просто возьмет и умрет?

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

Если очень хочется попробовать Ceph, то рекомендую сначала почитать опыт пользователей из недавнего: http://chneukirchen.org/blog/archive/2018/01/anatomy-of-a-ceph-meltdown.html

Конкретно про PetaSAN ничего сказать не могу.

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

этож круто!

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

На ESXI деньги есть, на хранилку нет. Оригинально. Хранилка важнее системы виртуализации.

Смысл ставить что-то, где снизу Ceph, почему просто его не взять? Только помни про 4 ноды, ссд и 10 гигабитные линки.

Из самосбора уж лучше взять что-то, где в основе лежит drbd. Там можно меньше реплик. И драйвер айскази по-человечески прикручен, а не как у цефа.

А вообще, купи самую дешевую двухголовух хранилку, можно infortrend. Самое дорогое в хранилках все равно диски.

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

Смешно. Сплит-брейн он тебе обеспечит.

На ESXI деньги есть, на хранилку нет.

И причем тут это? Хранилка ранее была на встроенном рэйде,и всех все устраивало. Прошли годы, и хранилка не требовалась. Организация не вывезет покупки двухголовой хранилки, предложат только купить очередной недо-nas. я же сразу написал, что есть в наличии.

Разве нет кластеризации «для бедных» без всяких сплит-брейнов? Ну типа drbd, типа raid1 по сети? Это к тому, что 1 машина с raid10 неустойчива, а две в связке - более надежно, чем 1. Очевидно же. Как писал ранее, не спец в кластеризации, виртуализации и прочих темных вещах. Если вам какие-то вещи кажутся очевидными глупостями, прошу рассказать, чем именно. Спасибо.

Организация не вывезет покупки двухголовой хранилки, предложат только купить очередной недо-nas. я же сразу написал, что есть в наличии.

То есть данные компании стоят дешевле 400к рублей? Так может и нет требований к отказоустойчивости?

Возьми 1 сервер, набей дисками, отдай таргет через айскази. На случай аварии просто имей бекапы.

Это к тому, что 1 машина с raid10 неустойчива, а две в связке - более надежно, чем 1. Очевидно же.

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

Разве нет кластеризации «для бедных» без всяких сплит-брейнов?

Есть куча вебморд для drbd или ceph. В частности, по первому есть неплохой цикл статей на хабре от местного завсегдатая, по второму написано на каждом заборе.

Но первый обычно оканчивается сплит-брейном на 2 машинах, а второй - не подходит для лоу-кост решений или вмвари.

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

И вы предлагаете хранить бэкапы на этом же одном сервере? Где хранить-то (безопасно и дешево) 100, 200, 300, и т.д. ГБ виртуалок?

Умирает сервер, надо снова все с нуля..

Тяжело наверное жить без бекапов в 2018.

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

Именно после этого я и пришел к «кластеризации».

..а второй - не подходит для лоу-кост решений или вмвари.

Можно, пожалуйста, аргумент против решения: 3 ноды Ceph, в каждой ноде по 2 RAID-0, по 2 диска каждый. Каждый raid-массив - это OSD. Соединены три ноды гигабитным линком в гигабитный свич.

Чем плохо это решение?

И вы предлагаете хранить бэкапы на этом же одном сервере?

Хотя бы на подключаемых eSATA. Это будет в любом случае лучше чем ваш текущий гетто-нас. Бекапить можно только жизненно-важные данные, а сами виртуалки разворачивать скриптами/ансиблом/чем хотите.

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

Никакой. Если ты не можешь здраво обосновать покупку новой хранилки - зачем эти ухищрения в обход политики партии? Чтобы в случае ЧП (а оно будет, так ты не разбираешься ни в виртуализации, ни в хранилках) тебе же и прилетело?

Какиу бонусы от внедрения? Сокращение времени восстановления? Ускорение работы виртуальных машин на Х процентов?

И вы предлагаете хранить бэкапы на этом же одном сервере? Где хранить-то (безопасно и дешево) 100, 200, 300, и т.д. ГБ виртуалок?

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

Ну и причем тут бэкапы? От того, что у тебя умер физ сервер, свободного времени не добавится. Железо обнови (особенно если сдохла мать), ОС накати, рэйд собери. Бэкапы прекрасно чувствуют себя в другом месте.

Не понимаю, как у вас получается все перевернуть наоборот - настроенное «ухищрение» позволит не иметь проблем при наличии ЧП.

синхронизируй по расписанию

а все виртуалки тушить в это время для консистенции данных?

Не понимаю, как у вас получается все перевернуть наоборот - настроенное «ухищрение» позволит не иметь проблем при наличии ЧП.

Я не знаю вашего штатного расписания и кто перед кем отвечает. Если ты пришел на новую работу и делаешь что-то, то ставь в известность всех, до кого дотягиваешься о недостатках и намерении провести работы по инфраструктуре.

а все виртуалки тушить в это время для консистенции данных?

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

Я не знаю вашего штатного расписания и кто перед кем отвечает. Если ты пришел на новую работу и делаешь что-то, то ставь в известность всех, до кого дотягиваешься о недостатках и намерении провести работы по инфраструктуре.

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

Смешно же.

А рассказать на пальцах, то бишь обосновать целесообразность введения данной схемы, почему кластер из 3 тачек лучше, чем 1 гетто-нас, я думаю, по силам почти любому.

А рассказать на пальцах, то бишь обосновать целесообразность введения данной схемы, почему кластер из 3 тачек лучше, чем 1 гетто-нас, я думаю, по силам почти любому.

В твоем случае твой кластер из 3 тачек сольет самой дешманской двухголовой хранилке. И особенно сольет в стоимости поддержки.

Даже не сомневаюсь. Только стоимость решения не соотносится с критичностью. Смысл тратить 200-400 тысяч рублей, когда можно раз в месяц(при вылете дисков) тратить 5 тысяч? Заложив даже покупку полного комплекта под ноду каждые полгода, то можно предположить, через сколько лет стоимость этих решений сравняется. К тому времени эта двуголовая штука уже будет снята с поддержки и далее со всеми вытекающими.

при апгрейде софта, когда надо апать все ноды, у тебя волосы на опе будут шевелиться. а новая версия случайно все развалит. или ты прикупишь еще пару стендов для тестирования этого чудесного софта?

Если система собрана и оттестирована - зачем обновлять её? Ну только без стереотипов.

Если нет багов в текущем функционале, мешающих работать,то зачем создавать проблемы из ничего?

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

Вот и польза кластера, а обновления ради обновления...оффлайновому софту... Излишне.

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

Вроде PetaSAN позволяет решить проблему относительно поддержки.

Я и сам лоу-скилл, если уж на то пошло.

А через время может уже и фирмы не будет, раз уже сейчас в бюджете лишних средств нет.

Спасибо за обсуждение!

Товарищи, пока идет сборка тестовой площадки под PetaSAN, может есть еще какие-то варианты организации дешевого, но отказоустойчивого кластера?

PetaSAN ведет себя очень странно. 2 ноды в виртуалке, 1 на физ серваке, при выключении 1 ноды, отрубается веб-интерфейс на другой... Надо пробовать заинсталлить все на физ.серваки.

А что если отойти от определения «кластера», и взять, как уже предлагали, но только не один, а два сервака, набить их дисками в mdadm raid, вкл iscsi, и только один подрубить к VMware?

Делать бэкапы как и прежде, скриптом каждый день, а потом полученные бэкапы (а по факту целые .vmdk-диски) переносить rsync'ом на второй сервак.

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