Не принимается по очень простой причине. Вы не можете утверждать за весь продакшен в мире, как и за то, что было на самом деле 15 лет назад. Все это, возможно к сожалению, не более чем ваше личное оценочное суждение.
И если уж начать иронизировать, то судя по статье как минимум FreeBSD есть в продакшене у ее автора :). Это не плохо и не хорошо. Просто по каким-то причинам или стечению обстоятельств ему так удобнее.
Ок, то есть сами придумали. И продолжаете фантазировать на эту тему.
Я лишь писал, что у всех свои ниши. И FreeBSD в проде тоже есть, там где она оказалась уместнее других. И не более того. А утверждение, что "мертва" не имеет под собой достаточных оснований. Только и всего.
Вас опять куда-то не туда потянуло. Вы тут распинались про FreeBSD — мертва. Я вам постарался показать, что это не совсем так. В том числе потому что крупные международные корпорации выбирают ее в качестве базовой OS для своих коммерческих продуктов. А для того, что бы знать, что используется в крупных российских компаниях нужно быть внутри их IT подразделений как минимум, так как раскрывать свою внутреннюю инфраструктуру никто не спешит. Ну и как вариант, тот же Netflix для вас видимо не особо крупная компания и highload-а у них нет? А они в общем-то стримят на весь мир с FreeBSD, судя по информации из открытых источников (https://archive.fosdem.org/2019/schedule/event/netflix_freebsd/). И по факту получается, что через Freebsd генерируется порядка 15% общемирового трафика.
Я к тому, что не стоит слишком радикально высказываться про продукт, который вам не достаточно хорошо известен. У всех свои ниши. Хотя у молодежи все обычно черно-белое и без полутонов :). Но с возрастом чаще проходит, чем не проходит.
Как в РФ не знаю. В мире есть коммерческие продукты построенные на FreeBSD, которые активно продаются и развиваются. Из того с чем сталкивался сам: Dell EMC Isilon (Scale-out NAS сторадж, с масштабированием до 250 нод и сотен петабабайт в кластере с поддержкой NAS протоколов, Hadoop и т.д.), Dell Compelent SC (mid-range сторадж).
Netapp в своих стораджах использует Freebsd, насколько просачивалась информация.
Но вам возможно будут ближе Sony PlayStation последних поколений, а также Netflix, которые активно используют Freebsd в своих продуктах.
Так что зря вы фряху хороните, только по той причине, что она вам чем-то не угодила.
Идеала нет.
Со вторым вариантом важно что-бы и сами ноды знали, что есть witness и прежде чем куда-то переключатся нужно спросить у него, сам wintess может быть тоже распределенным сервисом с "авто-перевыборами" мастера при потере текущего. Логику работы нод в случае потери связи с каким либо компонентом, в том числе и с witness-сервисом, нужно тщательно продумывать. Сам witness не будет панацеей от всех проблем, но ряд возможных неприятностей позволит исключить. Ну и никто не мешает использовать оба варианта вместе, о чем я забыл упомянуть.
По вашей схеме работы видится два решения, которые могли бы помочь избежать проблем потери связи между node 1 и node 4.
1) Повышение отказоустойчивости самой сети между нодами с использованием агрегации физических интерфейсов серверов например по LACP и/или FSN (fail safe network) и т.п. С линками между нодами, поключенными в том числе через разные физические Ethernet свитчи, пусть даже и стекированные. Главное что бы потеря любого физического линка или целиком свитча не приводила к потере связи между нодами.
2) Использование дополнительного witness (tie-breaker) сервиса, стоящего "сбоку", который отслеживает насколько жив tarantool master (например опрашивая все ноды java-сервис, видят ли они мастер ноду tarantool) и на основании получаемых статусов переключал все ноды java-сервиса на slave или запрещал им это делать. Логику работы при той или иной аварии тут нужно подбирать. Например: если большинство нод java-сервис видит что tarantool master жив, то принудительно (временно) выводить из эксплуатации ноды потерявшие связь с мастером, на давая им переключится на slave. Или в обратной ситуации, когда мастер видит меньшинство принудительно всех переключать на slave tarantool. В общем логика срабатывания дискуссионный вопрос.
50TB — это полезная емкость, не считая того, что небольшая ее часть уйдет под хранение метаданных при создании лунов, снэпшотов и т.п. Схема лицензирования на коммерческой версии UnityVSA подписочная. Т.е. покупаете лицензию на объем полезной емкости на год. Потом продлеваете или не продлеваете. Варианты 10, 25, 50 TB или бесплатная постоянная лицензия на 4TB без разрешения использования продукта в коммерческих целях (обучение, тестирование и т.п. можно). Без продления коммерческой лицензии аплайнс работать продолжит, но залочится возможность внесения изменений в конфигурацию. За ценами действительно только к продавцам.
Unity VSA — это софт с железных массивов Unity перенесенный в виртуалку. Изначально EMC-шный продукт, до поглощения Деллом. В коммерческой версии VSA кстати теперь и двух-контроллерные HA версии поддерживаются, но нужен доступ к общему датастору и виртуальные контроллеры разнесенные на разные физ. сервера. Нексента тут совсем не причем.
erasure coding и онлайн компрессия имеют свои плюсы и недостатки на медленных и больших дисках. Все сильно от реализации зависит.
Отлично, мы продвигаемся. :)
Не знаю куда вы там продвигаетесь и главное зачем? ;)
Но у нас с вами в очередной раз получается беседа человека, задействованного в продажах оборудования и человека, который занимается техподдержкой проданного, сталкиваясь со всем тем о чем заказчику при продаже умолчали или не дорассказали. Слишком разные points of view и похоже без шанса сойтись во мнениях.
За сим не вижу смысла в продолжении дискуссии, тем более что к теме статьи она уже имеет довольно опосредованное отношение.
Извините, просто для определенности: вы сейчас как теоретик в вопросе говорите, или как практик?
Как практик, который за последние как минимум 6-7 лет видел и работал с кучей epic fail stories с использованием заказчиками дедупликации на первичных данных. Хотя и пары таких приключений с заказчиками в год вполне достаточно, что бы эйфория по поводу дедупа на первичных данных сильно спала. А потому имею мнение, что дедупу место в резервном копировании, а не на первичных данных.
Ну и на первичных данных дедуп может хоть как-то приемлемо работать только если есть SSD носители как минимум под хранение мета данных, а лучше под все. Но и это не избавляет от серьезных проблем с восстановлением работоспособности оборудования, не говоря уже про данные, в случае ряда специфических аварий.
Петабайтами "перед глазами" можно померятся, только практического смысла в этом нет.
Нет, просто все зависит от того, что вы считаете за 100% производительности. Если за 100% принимаем производительность заполненного тома (что логично), то тогда не полностю заполненный том дает значительный рост производительности.
Вы это точно все в контексте медленных 16TB NL-SAS написали?
Берем средние по больнице 12 дисковые ноды ставим диски на 16TB. Получаем грубо 192TB на ноду. Плановая миграция 100-150TB (например для остановки ноды и замены DIMM модуля) на реально работающем кластере превращается в длительный и нудный процесс, при том что на кластере еще место свободное должно под эти 100-150 TB должно быть. Но это еще черт бы с ним.
Про дедуп/компрессию для первичных данных на медленных дисках такого объема — это больше похоже на шутку. Работать будет медленно и уныло и не дай бог что- то из строя выйдет и придется дедуплицированные чанки восстанавливать и активно с метаданными работать.
«Если вы ограничите заполнение тома уровнем 85%, вы получите бесплатно для вас прирост общей дисковой производительности вашей дисковой подсистемы на 25%», или же «за стоимость двух-трех HDD вы получите прирост производительности на четверть».
Не более чем удобная вендору игра слов. Условный кластер не будет иметь прироста прозводительности пока заполняется до критического объема, а вот как только заполнится, ловите просадку производительности и опять же не дай бог при этом еще и одна из нод из строя выйдет. А в таких вещах всегда лучше перебздеть, чем недобздеть.
Ok, где именно я спросил про отличия? Как по мне, описанные программы скорее имеют общее сходство. К сожалению, ни одну из них нельзя использовать в продуктиве.
Очевидно что такие устройства уже нужно пускать в кластерные ФС с репликацией, а не erasure code.
Получаются слишком уж большие накладные расходы, RF2 не надежен, так как любое плановое обслуживание одной из нод кластера приводит к тому, что часть данных остается в единственном экземпляре. Это не говоря уж про внеплановые простои. RF3 имеет слишком большой оверхед, так как из условно 3 дисков на 16TB (48TB) у вас остается всего 16TB полезной емкости. Вряд ли это кому то сильно нравится, что под защиту даже не очень важных данных тратиться в 2-раза больше емкости, чем занимают сами данные. И это еще не считая того, что нужно выполнять их резервное копирование. А еще на многих подобных решениях не рекомендуется заполнять пулы более чем на 70-85% и вот уже реально доступно не 16TB, а еще пропорционально меньше.
Ок, юмор о названиях опустили. И чем же так уникален по вашему urbackup? Расскажите. Все тем же пофайловым инкрементальным копированием?
Меня не напрягает, помимо прочтения статьи, зайти на официальный сайт утилиты и почитать, что пишут про нее разработчики. И как то там не густо с возможностями, за исключением все того же пофайлового копирования. Что в принципе годиться наверно для домашнего использования, но вот в продуктив в нормальной организации такое не поставишь по вполне объективным причинам.
Ну собственно так и посмотреть. Я рад за вас, что вы освоили bash. Но rsync по прежнему всего лишь средство пофайловой синхронизации двух директорий. А в вашем случае еще и файлы и директории, уже отсутствующие в исходнике, останутся на remote server. И придется в итоге с переполнением тома на удаленной стороне разбираться.
Не принимается по очень простой причине. Вы не можете утверждать за весь продакшен в мире, как и за то, что было на самом деле 15 лет назад. Все это, возможно к сожалению, не более чем ваше личное оценочное суждение.
И если уж начать иронизировать, то судя по статье как минимум FreeBSD есть в продакшене у ее автора :). Это не плохо и не хорошо. Просто по каким-то причинам или стечению обстоятельств ему так удобнее.
Ок, то есть сами придумали. И продолжаете фантазировать на эту тему.
Я лишь писал, что у всех свои ниши. И FreeBSD в проде тоже есть, там где она оказалась уместнее других. И не более того. А утверждение, что "мертва" не имеет под собой достаточных оснований. Только и всего.
Это вы где прочитали? Или сами придумали?
Вас опять куда-то не туда потянуло. Вы тут распинались про FreeBSD — мертва. Я вам постарался показать, что это не совсем так. В том числе потому что крупные международные корпорации выбирают ее в качестве базовой OS для своих коммерческих продуктов. А для того, что бы знать, что используется в крупных российских компаниях нужно быть внутри их IT подразделений как минимум, так как раскрывать свою внутреннюю инфраструктуру никто не спешит. Ну и как вариант, тот же Netflix для вас видимо не особо крупная компания и highload-а у них нет? А они в общем-то стримят на весь мир с FreeBSD, судя по информации из открытых источников (https://archive.fosdem.org/2019/schedule/event/netflix_freebsd/). И по факту получается, что через Freebsd генерируется порядка 15% общемирового трафика.
Я к тому, что не стоит слишком радикально высказываться про продукт, который вам не достаточно хорошо известен. У всех свои ниши. Хотя у молодежи все обычно черно-белое и без полутонов :). Но с возрастом чаще проходит, чем не проходит.
Как в РФ не знаю. В мире есть коммерческие продукты построенные на FreeBSD, которые активно продаются и развиваются. Из того с чем сталкивался сам: Dell EMC Isilon (Scale-out NAS сторадж, с масштабированием до 250 нод и сотен петабабайт в кластере с поддержкой NAS протоколов, Hadoop и т.д.), Dell Compelent SC (mid-range сторадж).
Netapp в своих стораджах использует Freebsd, насколько просачивалась информация.
Но вам возможно будут ближе Sony PlayStation последних поколений, а также Netflix, которые активно используют Freebsd в своих продуктах.
Так что зря вы фряху хороните, только по той причине, что она вам чем-то не угодила.
Ну тут решать вам :). Я просто мыслями поделился.
Идеала нет.
Со вторым вариантом важно что-бы и сами ноды знали, что есть witness и прежде чем куда-то переключатся нужно спросить у него, сам wintess может быть тоже распределенным сервисом с "авто-перевыборами" мастера при потере текущего. Логику работы нод в случае потери связи с каким либо компонентом, в том числе и с witness-сервисом, нужно тщательно продумывать. Сам witness не будет панацеей от всех проблем, но ряд возможных неприятностей позволит исключить. Ну и никто не мешает использовать оба варианта вместе, о чем я забыл упомянуть.
По вашей схеме работы видится два решения, которые могли бы помочь избежать проблем потери связи между node 1 и node 4.
1) Повышение отказоустойчивости самой сети между нодами с использованием агрегации физических интерфейсов серверов например по LACP и/или FSN (fail safe network) и т.п. С линками между нодами, поключенными в том числе через разные физические Ethernet свитчи, пусть даже и стекированные. Главное что бы потеря любого физического линка или целиком свитча не приводила к потере связи между нодами.
2) Использование дополнительного witness (tie-breaker) сервиса, стоящего "сбоку", который отслеживает насколько жив tarantool master (например опрашивая все ноды java-сервис, видят ли они мастер ноду tarantool) и на основании получаемых статусов переключал все ноды java-сервиса на slave или запрещал им это делать. Логику работы при той или иной аварии тут нужно подбирать. Например: если большинство нод java-сервис видит что tarantool master жив, то принудительно (временно) выводить из эксплуатации ноды потерявшие связь с мастером, на давая им переключится на slave. Или в обратной ситуации, когда мастер видит меньшинство принудительно всех переключать на slave tarantool. В общем логика срабатывания дискуссионный вопрос.
50TB — это полезная емкость, не считая того, что небольшая ее часть уйдет под хранение метаданных при создании лунов, снэпшотов и т.п. Схема лицензирования на коммерческой версии UnityVSA подписочная. Т.е. покупаете лицензию на объем полезной емкости на год. Потом продлеваете или не продлеваете. Варианты 10, 25, 50 TB или бесплатная постоянная лицензия на 4TB без разрешения использования продукта в коммерческих целях (обучение, тестирование и т.п. можно). Без продления коммерческой лицензии аплайнс работать продолжит, но залочится возможность внесения изменений в конфигурацию. За ценами действительно только к продавцам.
Unity VSA — это софт с железных массивов Unity перенесенный в виртуалку. Изначально EMC-шный продукт, до поглощения Деллом. В коммерческой версии VSA кстати теперь и двух-контроллерные HA версии поддерживаются, но нужен доступ к общему датастору и виртуальные контроллеры разнесенные на разные физ. сервера. Нексента тут совсем не причем.
Ок, в таком случае просто не завидуйте, вам то похоже с вашим текущим кругозором и до этого самого 1сника как до луны пешком :).
К сожалению, ваш мир единорогов срущих радугой, не имеет ни чего общего с объективной реальностью. Но поверьте, мне вас искренне жаль.
erasure coding и онлайн компрессия имеют свои плюсы и недостатки на медленных и больших дисках. Все сильно от реализации зависит.
Не знаю куда вы там продвигаетесь и главное зачем? ;)
Но у нас с вами в очередной раз получается беседа человека, задействованного в продажах оборудования и человека, который занимается техподдержкой проданного, сталкиваясь со всем тем о чем заказчику при продаже умолчали или не дорассказали. Слишком разные points of view и похоже без шанса сойтись во мнениях.
За сим не вижу смысла в продолжении дискуссии, тем более что к теме статьи она уже имеет довольно опосредованное отношение.
Как практик, который за последние как минимум 6-7 лет видел и работал с кучей epic fail stories с использованием заказчиками дедупликации на первичных данных. Хотя и пары таких приключений с заказчиками в год вполне достаточно, что бы эйфория по поводу дедупа на первичных данных сильно спала. А потому имею мнение, что дедупу место в резервном копировании, а не на первичных данных.
Ну и на первичных данных дедуп может хоть как-то приемлемо работать только если есть SSD носители как минимум под хранение мета данных, а лучше под все. Но и это не избавляет от серьезных проблем с восстановлением работоспособности оборудования, не говоря уже про данные, в случае ряда специфических аварий.
Петабайтами "перед глазами" можно померятся, только практического смысла в этом нет.
Казуистика это все. И стаканы тут не причем.
Вы это точно все в контексте медленных 16TB NL-SAS написали?
Берем средние по больнице 12 дисковые ноды ставим диски на 16TB. Получаем грубо 192TB на ноду. Плановая миграция 100-150TB (например для остановки ноды и замены DIMM модуля) на реально работающем кластере превращается в длительный и нудный процесс, при том что на кластере еще место свободное должно под эти 100-150 TB должно быть. Но это еще черт бы с ним.
Про дедуп/компрессию для первичных данных на медленных дисках такого объема — это больше похоже на шутку. Работать будет медленно и уныло и не дай бог что- то из строя выйдет и придется дедуплицированные чанки восстанавливать и активно с метаданными работать.
Не более чем удобная вендору игра слов. Условный кластер не будет иметь прироста прозводительности пока заполняется до критического объема, а вот как только заполнится, ловите просадку производительности и опять же не дай бог при этом еще и одна из нод из строя выйдет. А в таких вещах всегда лучше перебздеть, чем недобздеть.
Не беспокойтесь, КЭП, уже сделано!
Ok, где именно я спросил про отличия? Как по мне, описанные программы скорее имеют общее сходство. К сожалению, ни одну из них нельзя использовать в продуктиве.
Получаются слишком уж большие накладные расходы, RF2 не надежен, так как любое плановое обслуживание одной из нод кластера приводит к тому, что часть данных остается в единственном экземпляре. Это не говоря уж про внеплановые простои. RF3 имеет слишком большой оверхед, так как из условно 3 дисков на 16TB (48TB) у вас остается всего 16TB полезной емкости. Вряд ли это кому то сильно нравится, что под защиту даже не очень важных данных тратиться в 2-раза больше емкости, чем занимают сами данные. И это еще не считая того, что нужно выполнять их резервное копирование. А еще на многих подобных решениях не рекомендуется заполнять пулы более чем на 70-85% и вот уже реально доступно не 16TB, а еще пропорционально меньше.
Ок, юмор о названиях опустили. И чем же так уникален по вашему urbackup? Расскажите. Все тем же пофайловым инкрементальным копированием?
Меня не напрягает, помимо прочтения статьи, зайти на официальный сайт утилиты и почитать, что пишут про нее разработчики. И как то там не густо с возможностями, за исключением все того же пофайлового копирования. Что в принципе годиться наверно для домашнего использования, но вот в продуктив в нормальной организации такое не поставишь по вполне объективным причинам.
Ну собственно так и посмотреть. Я рад за вас, что вы освоили bash. Но rsync по прежнему всего лишь средство пофайловой синхронизации двух директорий. А в вашем случае еще и файлы и директории, уже отсутствующие в исходнике, останутся на remote server. И придется в итоге с переполнением тома на удаленной стороне разбираться.