Ну то есть эта классная статья для них как раз, как призыв к действию? Чтобы они все бросили и занялись бизпредпринимательством?
Надо иметь определенный склад ума, харизму и приличный багаж знаний. Люди, которые это уже имеют, ну никак не будут сидеть по 10 лет в одной компании.
Также не надо забывать про рабочие профессии, токарь, сварщик, например. Ну какой дорогой он пойдет в бизнес?
И, с другой стороны, кто будет детали для гениев точить и сваривать гениальные задумки в работающий механизм?
Создатели «реальных ценностей» ничего никогда не создадут в этом своем свободном плавании и противопоставлении. Нужна поддержка этого самого «планктона». Эту поддержку намеренно игнорируют, принижают, недооценивают и отрицают.
Почему, кстати, «вынуждены платить»? Все добровольно.
Вы попробуйте. Test case — база данных, пишем туда много, все под кешем в writeback. Дергаем питание и смотрим что получается. Читать как работают фичи одно, а практический инструмент — немного другое.
Есть те, кто пробовал?
В случае просто с файлухой понятно, там можно отреплеить пару тройку транзакций и все вроде хорошо. Но как отреплеить кэш? Как драйвер кэша поймет, что нужно реплеить, если про файлуху и ее логику он не знает ничего?
Я знаю, что рекомендуют собрать рейд из SSD и хранить кэш там, но вот не могу понять смысла этого совета, если это не решает главной проблемы — обозначить после ребута какие блоки были dirty, а какие нет.
SSD все равно медленнее, чем память. Драйвер теряет все, что было в памяти и не успело попасть в метаданные. В таком случае даже пропажа одного бита, но непонятно где, делает весь кэш невалидным. Как-то так.
Ну здрасьте. Как кэш может форматироваться в любую ФС, он с блоками работает. Там блоки и лежат, причем у всех по-разному.
Я сейчас говорю про режим writeback. И нет еще ни одного контроллера в мире в режиме writeback, который бы без батарейки переживал ребут. Это и дает в итоге производительность в ущерб надежности.
Рекавери работает везде, во flashcache тоже. На железных контроллерах. Но в двух других режимах.
Иначе сами посудите. Какой смысл писать на быстрый SSD, потом ждать, пока все запишется на медленный диск, а потом репортить успешность операции. Быстрее будет сразу писать на диск, минуя SSD ))
Было бы интересно посмотреть, как работает, про журнал именно в кэше я не знал. Или он не для всех режимов?
Не очень понятно, как он работает. Кэш же обманывает контроллер диска, операционку и, следовательно, файлуху.
Они уже получили сигнал, что операция записи успешно завершена, но на самом деле нет. Журнал файлухи, метаданные уже содержат информацию о том, каково будет на самом деле состояние файловой системы через несколько мгновений. Вот мигает свет. Эти несколько мгновений потом зареплеятся кэшем?
Так если прикинуть, журналирование кэша убьет практически весь профит от кэша ))
Не спасет. Кэш — это прямое и деструктивное вмешательство в логику работы файловой системы.
В режиме, когда данные сначала записываются на SSD, а потом на файлуху — это самый быстрый и привлекательный режим writeback — все делается примерно так. Я сейчас утрирую и механизм немного сложнее на самом деле.
Мы пишем, драйвер кэша разбивает все на блоки, какие-то сохраняет на SSD, какие-то коммитит на диск. Разбивка оригинальная для кэша, файлуха про нее ничего не знает. Мигает свет. С точки зрения файловой системы блоки в кэше — это мусор. Только драйвер кэша знает, как превратить этот мусор в нечто, что можно записать на диск и файлуха это поймет. Только после аварии он не знает, что можно записать, а что нет — кэш невалиден и писать его никуда уже нельзя.
В итоге мы имеем кучу неконсистентных данных на файловой системе и пачку странных данных на SSD, драйвер кэша тоже уже не знает что с ними делать.
Файлуха отремонтирует что можно, зафиксит журнал и отреплеит что можно. Это выглядит, как будто мы взяли и перемешали между собой содержимое рандомных файлов. К примеру, в файле с базой данных у вас запросто могут оказаться вкрапления сислога или другой базы данных или еще чего-нибудь, куда была еще запись на момент аварии.
Никакие рейды тут не спасут. Спасет только батарейка и нормальное завершение работы сервера в случае аварии.
Это справдливо для writeback. В остальных режимах не так фатально, но тоже неприятно.
Самый ощутимый прирост дает слишком ненадежный режим. Можно, конечно, надеяться на батарейки, но они ощутимо часто отказывают. Это так, не истина в последней инстанции, а примеры из личного опыта.
В последний раз у нас неожиданно упал сервер с postgresql, стоял flashcache в writeback. Мера была вынужденная, переселить пока некуда было, а без него вообще не шевелилось. Пару дней не дожил до переселения. Все нет больше базы. Восстановить не удалось. Остальные режимы дают профит либо маленький, либо под специфичные кейсы использования.
Штука хорошая, но чудес все равно не бывает. У нас отлично работает на проектах, где инфа может потеряться без проблем. и без проблем восстановиться потом. На что-то более серьезное — я бы не рискнул.
Мне кажется, что perl надо отделить и поставить для него фронтендом, например, lighthttpd. Нет времени объяснять, всех с наступающим! Ну а если серьезно, будет проще потом разобраться с ошибками, языки разные, задачи, которые они решают — разные и по-разному. Для легких и простых штук, можно вообще попробовать embedded perl.
Было бы неплохо еще подкрутить sysctl на предмет TIME_WAIT — reuse, recycle.
inotify + *sync не дают же гарантий, что файл, который изменился, будет валидно синхронизирован.
Если сервисы нестабильны, а в амазоне так и будет, через пару месяцев такая каша начнется со статикой. Надо еще какой-то механизм инвалидации контента писать.
Не проще поставить монгу, например, и запихать туда статику, пусть она сама разбирается с консистентностью?
Вот только за этим лезть в облако амазона? Вы так говорите, как будто в облаке эта проблема действительно решена. Залил туда базу данных, а она сама как-нибудь автоматически размасштабируется.
Если качает широко, то действительно проблема. И одним облаком ее не решить. Надо чтобы ваш сервис еще был готов к качелям и к тому, что постоянно плавают ресурсы. Как объяснить базе данных, что надо реплицировать сейчас шустрее, а в час дня медленне?
Без проблем можно напихать только фронтендов. С бэкендами постоянная проблема. Запилился бекенд, я добавил новый, акей. А дальше-то что? Надо решить проблему синхронизации и разделяемого контента, обеспечить отсутствие splitbrains когда новый бекенд будет туда-сюда шастать. В итоге когда программисты допилят код для облака, это будет так долго и так дорого. А пока пилят, придется обходиться стандартными и проверенными полуавтоматическими методами.
Дешевле и надежнее все равно держать свой парк машин даже с двукратным запасом. Мы так делаем.
Другой вопрос, что открылся некий стартап. Сегодня на волне и туда толпой прилетел миллион уников, а завтра все разочаровались и никого больше нет. Тут, действительно проблема, как запуститься и как потом слить ненужное железо в случае провала. Я в такие ситуации попадал, ничего хорошего.
За два месяца можно купить такой же по мощности сервер. Только единоразово и больше платить не надо.
Прикрутить этот сервер в стойку — стоит сравнительно копейки. Накладные расходы на администраторов плюсанем, но все равно выйдет дешевле, даже если такой сервер менять каждый год.
Так зачем платить дороже за что-то, что не дает гарантий? Как бизнесу объяснить, что вот мы сейчас накупим попугаев, но возможно что-то работать всегда не будет, а чтобы всегда работало — умножьте попугаев на три.
Да еще и подстраховываться, подпирая уже оплаченные сервисы своими, которые по старинке, но надежнее. Здесь уже можно вычесть из пункта «экономим на админе».
Вот у нас наоборот с btrfs проблемы, когда все физическое блочное устройство делаешь btrfs, ядро крашится. Так происходит что с партицией, что просто raw.
ubuntu 12.04.
Ceph обеспечит отказоустойчивость своими средствами.
osd экспортирует в пул свой блочный девайс, дальше его мониторы следят за доступностью. Если блочное устройство пропадет, информация с него размажется по остальным из реплик.
У нас из трех блочных устройств вышибало два, все работало все равно. Надо только подумать где размещать метаданные и журналы. Рекаверится все само без ощутимого снижения производительности.
Вам нужна распределенная файлуха? ocfs2 неплохая. Можно тот же проксмокс и использовать его нативную gfs.
Они все какие-то не очень, у всех есть плюсы и минусы )
ceph выглядит немного лучше на фоне остальных.
Может вы его просто недонастроили? или версия старая. У нас таких проблем сейчас нет.
У них раньше были баги как раз про это, но сейчас все таймауты нормально отрабатывают.
Насколько я заметил, система очень чувствительна к синхронизированному времени между нодами. Если есть расхождения, могут начаться проблемы.
бизпредпринимательством?Надо иметь определенный склад ума, харизму и приличный багаж знаний. Люди, которые это уже имеют, ну никак не будут сидеть по 10 лет в одной компании.
Также не надо забывать про рабочие профессии, токарь, сварщик, например. Ну какой дорогой он пойдет в бизнес?
И, с другой стороны, кто будет детали для гениев точить и сваривать гениальные задумки в работающий механизм?
Почему, кстати, «вынуждены платить»? Все добровольно.
Есть те, кто пробовал?
Я сейчас говорю про режим writeback. И нет еще ни одного контроллера в мире в режиме writeback, который бы без батарейки переживал ребут. Это и дает в итоге производительность в ущерб надежности.
Рекавери работает везде, во flashcache тоже. На железных контроллерах. Но в двух других режимах.
Иначе сами посудите. Какой смысл писать на быстрый SSD, потом ждать, пока все запишется на медленный диск, а потом репортить успешность операции. Быстрее будет сразу писать на диск, минуя SSD ))
Читать — другое дело.
Не очень понятно, как он работает. Кэш же обманывает контроллер диска, операционку и, следовательно, файлуху.
Они уже получили сигнал, что операция записи успешно завершена, но на самом деле нет. Журнал файлухи, метаданные уже содержат информацию о том, каково будет на самом деле состояние файловой системы через несколько мгновений. Вот мигает свет. Эти несколько мгновений потом зареплеятся кэшем?
Так если прикинуть, журналирование кэша убьет практически весь профит от кэша ))
В режиме, когда данные сначала записываются на SSD, а потом на файлуху — это самый быстрый и привлекательный режим writeback — все делается примерно так. Я сейчас утрирую и механизм немного сложнее на самом деле.
Мы пишем, драйвер кэша разбивает все на блоки, какие-то сохраняет на SSD, какие-то коммитит на диск. Разбивка оригинальная для кэша, файлуха про нее ничего не знает. Мигает свет. С точки зрения файловой системы блоки в кэше — это мусор. Только драйвер кэша знает, как превратить этот мусор в нечто, что можно записать на диск и файлуха это поймет. Только после аварии он не знает, что можно записать, а что нет — кэш невалиден и писать его никуда уже нельзя.
В итоге мы имеем кучу неконсистентных данных на файловой системе и пачку странных данных на SSD, драйвер кэша тоже уже не знает что с ними делать.
Файлуха отремонтирует что можно, зафиксит журнал и отреплеит что можно. Это выглядит, как будто мы взяли и перемешали между собой содержимое рандомных файлов. К примеру, в файле с базой данных у вас запросто могут оказаться вкрапления сислога или другой базы данных или еще чего-нибудь, куда была еще запись на момент аварии.
Никакие рейды тут не спасут. Спасет только батарейка и нормальное завершение работы сервера в случае аварии.
Это справдливо для writeback. В остальных режимах не так фатально, но тоже неприятно.
Самый ощутимый прирост дает слишком ненадежный режим. Можно, конечно, надеяться на батарейки, но они ощутимо часто отказывают. Это так, не истина в последней инстанции, а примеры из личного опыта.
В последний раз у нас неожиданно упал сервер с postgresql, стоял flashcache в writeback. Мера была вынужденная, переселить пока некуда было, а без него вообще не шевелилось. Пару дней не дожил до переселения. Все нет больше базы. Восстановить не удалось. Остальные режимы дают профит либо маленький, либо под специфичные кейсы использования.
Штука хорошая, но чудес все равно не бывает. У нас отлично работает на проектах, где инфа может потеряться без проблем. и без проблем восстановиться потом. На что-то более серьезное — я бы не рискнул.
Было бы неплохо еще подкрутить sysctl на предмет TIME_WAIT — reuse, recycle.
Если сервисы нестабильны, а в амазоне так и будет, через пару месяцев такая каша начнется со статикой. Надо еще какой-то механизм инвалидации контента писать.
Не проще поставить монгу, например, и запихать туда статику, пусть она сама разбирается с консистентностью?
Если качает широко, то действительно проблема. И одним облаком ее не решить. Надо чтобы ваш сервис еще был готов к качелям и к тому, что постоянно плавают ресурсы. Как объяснить базе данных, что надо реплицировать сейчас шустрее, а в час дня медленне?
Без проблем можно напихать только фронтендов. С бэкендами постоянная проблема. Запилился бекенд, я добавил новый, акей. А дальше-то что? Надо решить проблему синхронизации и разделяемого контента, обеспечить отсутствие splitbrains когда новый бекенд будет туда-сюда шастать. В итоге когда программисты допилят код для облака, это будет так долго и так дорого. А пока пилят, придется обходиться стандартными и проверенными полуавтоматическими методами.
Дешевле и надежнее все равно держать свой парк машин даже с двукратным запасом. Мы так делаем.
Другой вопрос, что открылся некий стартап. Сегодня на волне и туда толпой прилетел миллион уников, а завтра все разочаровались и никого больше нет. Тут, действительно проблема, как запуститься и как потом слить ненужное железо в случае провала. Я в такие ситуации попадал, ничего хорошего.
Прикрутить этот сервер в стойку — стоит сравнительно копейки. Накладные расходы на администраторов плюсанем, но все равно выйдет дешевле, даже если такой сервер менять каждый год.
Так зачем платить дороже за что-то, что не дает гарантий? Как бизнесу объяснить, что вот мы сейчас накупим попугаев, но возможно что-то работать всегда не будет, а чтобы всегда работало — умножьте попугаев на три.
Да еще и подстраховываться, подпирая уже оплаченные сервисы своими, которые по старинке, но надежнее. Здесь уже можно вычесть из пункта «экономим на админе».
ubuntu 12.04.
osd экспортирует в пул свой блочный девайс, дальше его мониторы следят за доступностью. Если блочное устройство пропадет, информация с него размажется по остальным из реплик.
У нас из трех блочных устройств вышибало два, все работало все равно. Надо только подумать где размещать метаданные и журналы. Рекаверится все само без ощутимого снижения производительности.
Они все какие-то не очень, у всех есть плюсы и минусы )
ceph выглядит немного лучше на фоне остальных.
У них раньше были баги как раз про это, но сейчас все таймауты нормально отрабатывают.
Насколько я заметил, система очень чувствительна к синхронизированному времени между нодами. Если есть расхождения, могут начаться проблемы.