Если у тебя отказывает нода, ты остаешься с одной, без резервирования вообще на весь период, пока вторая нода лежит. Довольно большой период порой. И это пиздец как стремно.
Особенно в период, когда сломанная нода поднимется, и начнется ОЧЕНЬ активная работа по восстановлению реплики, последняя живая нода тоже вполне может лечь. И привет.
Где это виданно, чтобы контент на ноду поднимать?! Контент же в отдельном файл сторадже. Если это AWS, то предположу, что один точно в леднике для бэкапа. Остальные два - не знаю
Не, рейд тухлая история для больших объёмов. Raid 6 на из 12 HDD дисков на 20 ТБ полезного объёма при вылете 1 диска у меня восстанавливался дней 5. Это шляпа, если у тебя диски по 8 ТБ, например. Оно в объёме 8x8ТБ будет восстанавливаться недели 3. Даже на nvme этой займёт много времени. Тут надо хранилища, которые умеют работать с дисками по своим собственным алгоритмам, а ты уже работаешь с хранилищем.
даавно есть алго для lossless сжатия jpg, раньше был lepton, сейчас можно через jpeg-xl. но все это требует мощности от проца. но как вариант старые-невостребованные картинки можно и ужать на 10-25% - с нулевой потерей в качестве от исходника.
И пойти дальше, если браузер поддерживает jpeg-xl, то сразу его и давать, а внутри все-тот-же старый jpeg но ужатый.
Эх если бы. С jpeg-xl все печально, гугл его слил в угоду своего мерзотного webm под предлогом, что майки купили там патент на алгоритм сжатия. А гуглобарузер чуть ли не монополист на рынке браузеров.
Картинки не очень сжимаются. И их отдавать надо как-то юзерам. Ну т.е. в сторону cdn - основные проблемы у контент-генераторов, зачастую, это не хранение, как таковое, а доставка клиентам. Некоторые ДЦ контент-генераторам, арендующим сервера, по этой причине могут шейпить канал или вообще приостанавливать услуги (неоднократно такие пострадавшие такие появлялись на пороге конторы, где сейчас работаю). Поэтому нужны CDN. Им заплатить, в итоге, дешевле, чем платить за каналы ДЦ, где сервера стоят.
Смотря как хранить. Это может быть какой-нибудь SDS, типа CEPH. Там данные в 3 экземрплярах (минимум для продакшена) и всегда в онлайне. Если osd упадёт/сервер уйдёт на обслуживание, то по возвращение в онлайн оно автоматом догонит недостающие объекты в группах хранения (PG - placement group). Вообще очень классная штука, угробить такую - надо постараться. Но опять же. Это помогает сохранить доступность, но не является заменой бэкапов, если данные меняются, т.к. поменяются все три копии разом. Если данные не меняются, типа хранения контента, то тогда очень даже норм.
А там и нет никаких рейдов. Там диски, напрямую скармливаются хранилищам. А два умерших диска - я видел в живую для raid10, когда второй умирающий диск в момент восстановления гробил весь рейд. Шансов, что умрёт все три диска, хранящих все три копии в кластере - очень маловероятная история, при том, что данные динамически начнут разъезжаться по живым дискам сами, как только произойдёт вылет первого. Т.е., скорее всего, надо больше 3-х дисков потерять. А рейд - они живёт в рамках или сервера, или железной хранилки. Опять же, надо понимать, что применимость разная. В ceph ты можешь загнать 120 дисков, и оно будет работать. А любые рейды забуксуют на таком объёме. С другой стороны, хрен чего ты построешь надёжного из 4х дисков, кроме raid-массива. Т.е. условия определяют применимость инструмента.
Если можно, то какие настройки для Elasticsearch для улучшения производительности делали и какие-то лайфхаки есть?
На работе храним тексты в разы меньше по количеству, но большие по текстовому объёму, всё время какая-то хуйня с производительностью и агрегациями. (~740гб на реплику, в индексе 2 реплики и 20-35 шардов, итого где-то 2.1 ТБ)
Грешим на то что одновременные запросы пользователей могут класть периодически кластер, думаем вводить очередь сообщений для контроля.
Если лень поделиться, то приму с благодарностью вектор гугления или материалы для изучения.
что то ты вонь развел дофига, а я ведь всего лишь хотел указать на твою ошибку -
ты написал 10 гигабайт вместо, наверное, 10 террабайт или 100 гигов, уж не знаю на что ты там копишь
да? а я то думал меньше, ты случайно не учителем информатики работаешь, у меня ссдшник на терабайт, а реальный объём 894.24, так что 1 к десяти?) и что же ты на десять гигов запишешь, фотки своей краткой биографии...
Диски честно маркируют как 1 000 000 000 000 байт. Что действительно 1 терабайт.
А вот то, что системы показывают 931ГБ - они показывают как раз уже в единицах, имеющих влияние от бинарного, т.е. кибибайт, мебибайт, тебибайт. Т.е. где-то всё идёт как KB, MB, TB, а где-то не опускают и пишут KiB, MiB, TiB. Но обычно всё же опускают.
А в случае выше, скорее всего, имеет место самоубеждение. Т.к. 894 похоже на честные 960 гигабайт, уоторые являются очень распространённой цифрой в объёмах твердотельников.
у меня 931гб доступно из 1тб. но по факту они там считают тб не как 1024гб (и т.д.), а как 10^12 байт, что и выходит 931.32гб. конечно наебалово, но не такое сильное, как у тебя. а таким образом твердотельные накопители вроде вообще все производители считают испокон веков
в зависимости от количества "банок" (и размера банок) может быть разный объём накопителя. там обычные объёмы 960гб, 1тб, 1.024тб - это всё не разный подсчёт, а разный реальный объём накопителя. и все эти производители кило-, мега, гига-, тера- считают как 1000, а не 1024. а скрин с торговой площадки в этом отношении не показателен вовсе.
вот первый накопитель официально продаётся как 1тб, а маленьким шрифтом написано, что это триллион байт.
а второй накопитель раньше и не слышал такого производителя, какой-то жёсткий китай, хоть и под российским брендом. потому не нашёл нормальной спецификации. но могу сказать, что он официально и продаётся как 1024гб. а на самом накопителе написано то же самое, что у других в спецификации.
Смотря какое железо. Не в каждый сервер можно поставить 4x nvme. Например сервак (без перекоса по памяти и процу), в который можно напихать столько, обойдётся тысяч 11-16 бачей. Если самому покупать. Но это тогда надо думать, куда его размещать. Это надо серваков 4-5 для минимального покрытия - диски архитектурно не могут утилизироваться целиком во многих случаях. Целиком аренда стойки стоит тысячи 3 бачей в ДЦ. А ещё же каналы. Надо что-то думать с каналами. Чтобы выдавать столько контента, они должны быть толстыми. Это тоже деньги.
В реальности проще в таком кейса вместо аренды стоек/коллокейшена брать сервера в аренду. Правда это будет всегда кастом, и на сервер будет выходить 2-3 килобакса в месяц при условном конфиге cpu 24c/48t/256TB RAM/4xnvme 7TB/2-3Gbps публичная+5Gbps приватная сети. Ну если брать пачку, то и скинут, вероятно. Но всё равно.
Если проект не генератор денег, то как бы очень даже о чём цифры.
Отличный комментарий!