Как я тянул свою первую сеть
В начале нулевых, на самой заре своей трудовой деятельности я работал в одном бюджетном НИИ инженером, фактически выполняя задачи системного администратора. Почему инженером? А потому что в штатном расписании не было системного администратора и появился он там очень нескоро.
И вот встал вопрос создания первой в организации локальной сети, пока что в масштабах бухгалтерии, но все как надо – на витой паре.
В один не очень прекрасный день мне выдали бухту кабеля, стопку кабель-каналов и иного сетевого оборудования и сказали – вперед!
- Это как, вперед? – не понял я, - а сеть кто тянуть будет?
- А в чем проблема? – удивился мой начальник, - сеть какая? Компьютерная. А кто тут по компьютерам?
Я немного удивился такой постановке вопроса и попытался пояснить, что сеть – это та же слаботочка, у нас в штате есть электрик, который как раз и может таким заняться, а к нему можно добавить в помощь сантехника, который один фиг днями спит в своей каморке.
Если бы это не был бюджет или руководство было бы более гибким (скажем так), то вопрос можно было бы решить легко и просто – за премию они бы сами все протянули и добавки бы попросили.
Но увы и ах, финансовым поощрением там и не пахло. А дальше вступает в силу типично бюджетная фишка: они делают вид, что платят – мы делаем вид, что работаем. При этом все это всегда прикрывалось имитацией бурной деятельности.
Но я был тогда молодой, зеленый и все мои понятия о производственных процессах были далеки от реальности.
В итоге мой начальник отправил меня к их начальнику просить на завтра две единицы рабочей силы. Их начальник не возражал, а наоборот вызвал и поставил задачу – помочь молодому инженеру завтра с прокладкой сети.
А на завтра случилось неожиданное: в подвале внезапно «забил фонтан» и сантехник оказался ну очень сильно занят, электрик задумчиво смотрел в полуразобранный щиток и идти тянуть сеть они наотрез отказались.
Ну как так? Я к их начальнику. А он мне доходчиво пояснил, что в их должностной инструкции нет ничего про компьютерные сети и они согласились помочь сугубо по причине наличия свободного времени, а так как у них появилась собственная работа, то извини…
Я к своему начальнику, тот повторил мне тоже самое. Тогда я спросил, а как же моя должностная инструкция, после чего мне доходчиво пояснили, что я вообще здесь на птичьих правах, ибо взят сугубо из жалости ко мне и гуманизма и если посмотреть в мою должностную инструкцию, то меня можно хоть сегодня выгонять за профнепригодность.
Возразить тут было нечего. Разве что надо было пояснить, что это ни они меня взяли из жалости, а я из жалости к ним пришел (что по факту так и было), но я был молод, зелен и смирившись пошел тянуть сеть.
Выдали мне оранжевую советскую дрель, ни разу ни ударную и два тупых победитовых сверла.
Сверла грелись, гнулись, после чего я их выравнивал молотком на ступеньке лестницы и шел назад бороться с бетонной стеной. Но силы были явно не равны.
Пошел к начальнику и попросил хотя бы купить новые сверла. На что получил ответ, что для того, чтобы купить новые, надо списать старые, а они вполне еще ничего, все сверлят, никто не жаловался.
Поняв, что я тут просто лягу костьми еще на первом десятке отверстий я в обеденный перерыв поехал домой и привез нормальный перфоратор.
Взамен я получил порцию ворчания от начальника, мол молодежь никуда не годится, все сверлили, никто не жаловался, а этому перфоратор подавай.
С перфоратором дело пошло веселее и к вечеру я основной объем монтажа закончил.
А на утро меня встретили ухмыляющиеся сантехник и электрик и поинтересовались как мне вчера работалось.
Потом отвели в сторонку и пояснили мне, что я эпический долбоящер. Основной смысл их речи был прост: ты же инженер, у тебя же есть спирт…
Но это уже совсем другая история…
В начале нулевых, на самой заре своей трудовой деятельности я работал в одном бюджетном НИИ инженером, фактически выполняя задачи системного администратора. Почему инженером? А потому что в штатном расписании не было системного администратора и появился он там очень нескоро.
И вот встал вопрос создания первой в организации локальной сети, пока что в масштабах бухгалтерии, но все как надо – на витой паре.
В один не очень прекрасный день мне выдали бухту кабеля, стопку кабель-каналов и иного сетевого оборудования и сказали – вперед!
- Это как, вперед? – не понял я, - а сеть кто тянуть будет?
- А в чем проблема? – удивился мой начальник, - сеть какая? Компьютерная. А кто тут по компьютерам?
Я немного удивился такой постановке вопроса и попытался пояснить, что сеть – это та же слаботочка, у нас в штате есть электрик, который как раз и может таким заняться, а к нему можно добавить в помощь сантехника, который один фиг днями спит в своей каморке.
Если бы это не был бюджет или руководство было бы более гибким (скажем так), то вопрос можно было бы решить легко и просто – за премию они бы сами все протянули и добавки бы попросили.
Но увы и ах, финансовым поощрением там и не пахло. А дальше вступает в силу типично бюджетная фишка: они делают вид, что платят – мы делаем вид, что работаем. При этом все это всегда прикрывалось имитацией бурной деятельности.
Но я был тогда молодой, зеленый и все мои понятия о производственных процессах были далеки от реальности.
В итоге мой начальник отправил меня к их начальнику просить на завтра две единицы рабочей силы. Их начальник не возражал, а наоборот вызвал и поставил задачу – помочь молодому инженеру завтра с прокладкой сети.
А на завтра случилось неожиданное: в подвале внезапно «забил фонтан» и сантехник оказался ну очень сильно занят, электрик задумчиво смотрел в полуразобранный щиток и идти тянуть сеть они наотрез отказались.
Ну как так? Я к их начальнику. А он мне доходчиво пояснил, что в их должностной инструкции нет ничего про компьютерные сети и они согласились помочь сугубо по причине наличия свободного времени, а так как у них появилась собственная работа, то извини…
Я к своему начальнику, тот повторил мне тоже самое. Тогда я спросил, а как же моя должностная инструкция, после чего мне доходчиво пояснили, что я вообще здесь на птичьих правах, ибо взят сугубо из жалости ко мне и гуманизма и если посмотреть в мою должностную инструкцию, то меня можно хоть сегодня выгонять за профнепригодность.
Возразить тут было нечего. Разве что надо было пояснить, что это ни они меня взяли из жалости, а я из жалости к ним пришел (что по факту так и было), но я был молод, зелен и смирившись пошел тянуть сеть.
Выдали мне оранжевую советскую дрель, ни разу ни ударную и два тупых победитовых сверла.
Сверла грелись, гнулись, после чего я их выравнивал молотком на ступеньке лестницы и шел назад бороться с бетонной стеной. Но силы были явно не равны.
Пошел к начальнику и попросил хотя бы купить новые сверла. На что получил ответ, что для того, чтобы купить новые, надо списать старые, а они вполне еще ничего, все сверлят, никто не жаловался.
Поняв, что я тут просто лягу костьми еще на первом десятке отверстий я в обеденный перерыв поехал домой и привез нормальный перфоратор.
Взамен я получил порцию ворчания от начальника, мол молодежь никуда не годится, все сверлили, никто не жаловался, а этому перфоратор подавай.
С перфоратором дело пошло веселее и к вечеру я основной объем монтажа закончил.
А на утро меня встретили ухмыляющиеся сантехник и электрик и поинтересовались как мне вчера работалось.
Потом отвели в сторонку и пояснили мне, что я эпический долбоящер. Основной смысл их речи был прост: ты же инженер, у тебя же есть спирт…
Но это уже совсем другая история…
👏14🤣9❤5🔥2😢1
TDP – заблуждения и реальность
TDP (Thermal Design Power) активно используется при обсуждении потребления процессоров и другой электроники. При этом данный показатель часто путают с максимальной рассеиваемой мощностью или потребляемой электрической мощностью.
Однако это не так, TDP является требованием по выбору системы охлаждения и отражает некую среднюю рассеиваемую мощность на усмотрение производителя.
Так Intel определяет его как:
▫️ Расчетная тепловая мощность (TDP) представляет собой среднюю мощность в ваттах, которую процессор рассеивает при работе на базовой частоте со всеми активными ядрами в условиях определенной Intel сложной рабочей нагрузки.
В AMD несколько иной, но тоже очень схожий подход:
▫️ TDP — это максимальная устойчивая мощность, которую процессор может потреблять с помощью «реального» программного обеспечения при работе в определенных пределах температуры и напряжения.
При этом и те и другие говорят о некой «реальной» нагрузке ими самими и определенной. Также следует отметить, что TDP рассчитывается для базовой частоты процессора, просто Intel говорит об этом прямо, а AMD несколько завуалировано.
Таким образом TDP не показывает ни реальной потребляемой мощности, ни реальной рассеиваемой тепловой. Это некий средний показатель, который призван помочь вам выбрать кулер.
Т.е. если вы на процессор с TDP 100 Вт поставите кулер способный рассеивать такую мощность, то ваш процессор при среднестатистической нагрузке перегреваться не должен.
Ключевое слово здесь – не должен. На самом деле вся система работает немного не так. То, что публикуется как TDP есть ни что иное как определенный лимит мощности для устойчивой долгосрочной работы.
Но есть еще один, второй лимит мощности, который указывает какую мощность допустимо потреблять процессору в турбо-режиме и как долго он может это делать.
У Intel эти параметры так и называются PL - Power Limit, PL1 и PL2. Их оба можно найти в документации, первый равен указанному на коробке TDP процессора, а второй указывает максимально потребляемую в турбо-режиме мощность.
Например, у Core i7-14700K это 125 Вт и 273 Вт. Разница, согласитесь, впечатляющая.
AMD публикует только PL1, он же TDP, максимальную мощность можно узнать только из неофициальных источников. Так для того же R9 5900X цифры составляют 105 Вт официальной рассеиваемой мощности и около 145 Вт максимальной.
Схема работы при этом примерно такая, при увеличении нагрузки процессор разгоняется таким образом, чтобы потребляемая им мощность не превысила значение второго лимита мощности.
Пока это значение не достигнуто процессор может продолжать работать на более высоких частотах, по достижению второго лимита мощности процессор должен через некоторое, достаточно небольшое время, вернуться к первому лимиту и работать в нем, пока не будет снята нагрузка.
Штатная цифра для процессоров Intel – 8 секунд. Рассчитана она исходя, опять-таки, из некоторых средних представлений Intel и подразумевает использование стокового охлаждения.
В целом посыл ясен – кратковременно процессор может достигать максимальной потребляемой мощности, но нахождение его в этом состоянии лимитировано. Это обусловлено тем, что ни штатная система охлаждения, ни штатная система питания могут быть не рассчитаны на долговременную высокую нагрузку.
Но данные параметры не являются догмой и, тем более, нигде жестко не прошиты. Они доступны для регулирования в BIOS и производители материнских плат и готовых компьютеров могут настраивать эти параметры согласно собственным представлениям.
Чаще всего такие настройки существенно увеличивают возможность процессоров работать по достижении второго лимита мощности, не возвращаясь к первому, т.е. практически все время находиться в турбо-режиме. Ну а почему бы и нет, если производитель знает, что система питания платы это позволяет.
Производители мобильных устройств могут, наоборот, прикрутить как лимиты, так и время нахождения в турбо-режиме ради снижения тепловыделения и экономного расхода заряда аккумулятора.
TDP (Thermal Design Power) активно используется при обсуждении потребления процессоров и другой электроники. При этом данный показатель часто путают с максимальной рассеиваемой мощностью или потребляемой электрической мощностью.
Однако это не так, TDP является требованием по выбору системы охлаждения и отражает некую среднюю рассеиваемую мощность на усмотрение производителя.
Так Intel определяет его как:
▫️ Расчетная тепловая мощность (TDP) представляет собой среднюю мощность в ваттах, которую процессор рассеивает при работе на базовой частоте со всеми активными ядрами в условиях определенной Intel сложной рабочей нагрузки.
В AMD несколько иной, но тоже очень схожий подход:
▫️ TDP — это максимальная устойчивая мощность, которую процессор может потреблять с помощью «реального» программного обеспечения при работе в определенных пределах температуры и напряжения.
При этом и те и другие говорят о некой «реальной» нагрузке ими самими и определенной. Также следует отметить, что TDP рассчитывается для базовой частоты процессора, просто Intel говорит об этом прямо, а AMD несколько завуалировано.
Таким образом TDP не показывает ни реальной потребляемой мощности, ни реальной рассеиваемой тепловой. Это некий средний показатель, который призван помочь вам выбрать кулер.
Т.е. если вы на процессор с TDP 100 Вт поставите кулер способный рассеивать такую мощность, то ваш процессор при среднестатистической нагрузке перегреваться не должен.
Ключевое слово здесь – не должен. На самом деле вся система работает немного не так. То, что публикуется как TDP есть ни что иное как определенный лимит мощности для устойчивой долгосрочной работы.
Но есть еще один, второй лимит мощности, который указывает какую мощность допустимо потреблять процессору в турбо-режиме и как долго он может это делать.
У Intel эти параметры так и называются PL - Power Limit, PL1 и PL2. Их оба можно найти в документации, первый равен указанному на коробке TDP процессора, а второй указывает максимально потребляемую в турбо-режиме мощность.
Например, у Core i7-14700K это 125 Вт и 273 Вт. Разница, согласитесь, впечатляющая.
AMD публикует только PL1, он же TDP, максимальную мощность можно узнать только из неофициальных источников. Так для того же R9 5900X цифры составляют 105 Вт официальной рассеиваемой мощности и около 145 Вт максимальной.
Схема работы при этом примерно такая, при увеличении нагрузки процессор разгоняется таким образом, чтобы потребляемая им мощность не превысила значение второго лимита мощности.
Пока это значение не достигнуто процессор может продолжать работать на более высоких частотах, по достижению второго лимита мощности процессор должен через некоторое, достаточно небольшое время, вернуться к первому лимиту и работать в нем, пока не будет снята нагрузка.
Штатная цифра для процессоров Intel – 8 секунд. Рассчитана она исходя, опять-таки, из некоторых средних представлений Intel и подразумевает использование стокового охлаждения.
В целом посыл ясен – кратковременно процессор может достигать максимальной потребляемой мощности, но нахождение его в этом состоянии лимитировано. Это обусловлено тем, что ни штатная система охлаждения, ни штатная система питания могут быть не рассчитаны на долговременную высокую нагрузку.
Но данные параметры не являются догмой и, тем более, нигде жестко не прошиты. Они доступны для регулирования в BIOS и производители материнских плат и готовых компьютеров могут настраивать эти параметры согласно собственным представлениям.
Чаще всего такие настройки существенно увеличивают возможность процессоров работать по достижении второго лимита мощности, не возвращаясь к первому, т.е. практически все время находиться в турбо-режиме. Ну а почему бы и нет, если производитель знает, что система питания платы это позволяет.
Производители мобильных устройств могут, наоборот, прикрутить как лимиты, так и время нахождения в турбо-режиме ради снижения тепловыделения и экономного расхода заряда аккумулятора.
👍17❤2
TDP – заблуждения и реальность. Продолжение
В прошлой заметке мы разобрали общие вопросы касающиеся TDP и регулировки производительности процессора. Сейчас немного углубимся в детали.
Разбирать будем на примере Intel, так как данный производитель имеет часть документации, касающейся этого вопроса в свободном доступе, AMD разглашает меньше подробностей, но в целом принцип и там и там одинаков, отличаются лишь детали реализации.
Еще раз напомним, что TDP – это всего лишь рекомендация по выбору системы охлаждения и данный параметр не отражает реального потребления процессора.
Реально же используются значения PL1 и PL2. PL1 – пороговое значение средней долговременной мощности. Его не рекомендуется устанавливать выше TDP и обычно эти значения равны.
PL2 – пиковое значение мощности которое может быть кратковременно достигнуто. При превышении этого значения вступаю в дело алгоритмы ограничения мощности и путем регулировки частоты и напряжения удерживают мощность в рамках этого значения.
Но есть один тонкий момент. Нижний предел охлаждения у нас находится на уровне PL1 (который не должен превышать TDP) и, следовательно, процессор должен уметь длительно работать с радиатором, рассеивающим указанную мощность.
Проще говоря, для условного процессора с 95 Вт TDP пользователь может купить кулер, на коробке которого указаны те же 95 Вт и не испытывать проблем.
А дальше представляем себе бассейн и две трубы, по одной в него приходит вода, по другой уходит. Радиатор всегда рассеивает свой TDP, т.е. у нас в единицу времени уходит мощность PL1.
Но тут мы открутили вентиль и начали наливать в бассейн воду в объеме PL2 за ту же единицу времени. Как долго мы можем работать в таком режиме? Очевидно, что пока не переполнится бассейн, а это зависит от его объема и его свободной части.
У радиатора это зависит от теплоемкости. Но как правильно определить доступный объем?
Для этих целей Intel использует специальный параметр Turbo Time (Tau), который рассчитывается по экспоненциально взвешенному скользящему среднему (EWMA) и определяет время, которое процессор может находиться в режиме от PL1 до PL2.
Если мы сразу выходим на мощность PL2, то это время будет равно 8 секундам, при меньших показателях мощности оно будет иным, меняющимся не линейно, а по экспоненте.
После чего процессор возвращается на уровень PL1 и не превышает его до тех пор, пока нагрузка не опустится ниже определенного значения за определенное время.
Если вернуться к аналогии, то рассчитав примерное время наполнения бассейна система ждет пока он гарантированно сольется.
Это позволяет избежать перегрева не только процессора, но и элементов питания материнской платы, которые также ориентируются на значения TDP.
У AMD примерно все тоже самое, только существует еще один ограничивающий фактор в виде температуры ядра, который также начинает ограничивать производительность даже до достижения PL2. А в особо запущенных случаях процессор даже не будет пытаться разгоняться.
Понятно, что все эти показатели высчитаны из расчета, что будет применяться самый слабый радиатор и подсистема питания также будет впритык. Но как быть обладателям дорогих материнских плат с мощным питанием и суперкулеров?
Для них производители предусматривают в BIOS специальные режимы, например, у Gigabyte он называется, как:
🔸 *Enhanced Multi-Core Performance*
Allows you to determine whether to apply the highest Turbo ratio to all CPU cores
Которое фактически изменяет лимиты PL1, PL2 и Tau с общим расчетом на то, чтобы процессор мог большее время находится в разгоне. На дорогих платах таких настроек может быть несколько, точнее несколько градаций настроек, скажем, как «умеренно, максимально, ультра».
Китайцы и вовсе пошли впереди планеты всей, на некоторых платах может быть вовсе снят лимит с PL2, а то и с PL1, точнее установлен в значение 4096W, чтобы корректно работал расчет Tau.
К чему это может привести догадаться несложно. Если вы не обеспечили эффективного охлаждения и дали предельную нагрузку, то от платы может пойти волшебный дым.
В прошлой заметке мы разобрали общие вопросы касающиеся TDP и регулировки производительности процессора. Сейчас немного углубимся в детали.
Разбирать будем на примере Intel, так как данный производитель имеет часть документации, касающейся этого вопроса в свободном доступе, AMD разглашает меньше подробностей, но в целом принцип и там и там одинаков, отличаются лишь детали реализации.
Еще раз напомним, что TDP – это всего лишь рекомендация по выбору системы охлаждения и данный параметр не отражает реального потребления процессора.
Реально же используются значения PL1 и PL2. PL1 – пороговое значение средней долговременной мощности. Его не рекомендуется устанавливать выше TDP и обычно эти значения равны.
PL2 – пиковое значение мощности которое может быть кратковременно достигнуто. При превышении этого значения вступаю в дело алгоритмы ограничения мощности и путем регулировки частоты и напряжения удерживают мощность в рамках этого значения.
Но есть один тонкий момент. Нижний предел охлаждения у нас находится на уровне PL1 (который не должен превышать TDP) и, следовательно, процессор должен уметь длительно работать с радиатором, рассеивающим указанную мощность.
Проще говоря, для условного процессора с 95 Вт TDP пользователь может купить кулер, на коробке которого указаны те же 95 Вт и не испытывать проблем.
А дальше представляем себе бассейн и две трубы, по одной в него приходит вода, по другой уходит. Радиатор всегда рассеивает свой TDP, т.е. у нас в единицу времени уходит мощность PL1.
Но тут мы открутили вентиль и начали наливать в бассейн воду в объеме PL2 за ту же единицу времени. Как долго мы можем работать в таком режиме? Очевидно, что пока не переполнится бассейн, а это зависит от его объема и его свободной части.
У радиатора это зависит от теплоемкости. Но как правильно определить доступный объем?
Для этих целей Intel использует специальный параметр Turbo Time (Tau), который рассчитывается по экспоненциально взвешенному скользящему среднему (EWMA) и определяет время, которое процессор может находиться в режиме от PL1 до PL2.
Если мы сразу выходим на мощность PL2, то это время будет равно 8 секундам, при меньших показателях мощности оно будет иным, меняющимся не линейно, а по экспоненте.
После чего процессор возвращается на уровень PL1 и не превышает его до тех пор, пока нагрузка не опустится ниже определенного значения за определенное время.
Если вернуться к аналогии, то рассчитав примерное время наполнения бассейна система ждет пока он гарантированно сольется.
Это позволяет избежать перегрева не только процессора, но и элементов питания материнской платы, которые также ориентируются на значения TDP.
У AMD примерно все тоже самое, только существует еще один ограничивающий фактор в виде температуры ядра, который также начинает ограничивать производительность даже до достижения PL2. А в особо запущенных случаях процессор даже не будет пытаться разгоняться.
Понятно, что все эти показатели высчитаны из расчета, что будет применяться самый слабый радиатор и подсистема питания также будет впритык. Но как быть обладателям дорогих материнских плат с мощным питанием и суперкулеров?
Для них производители предусматривают в BIOS специальные режимы, например, у Gigabyte он называется, как:
🔸 *Enhanced Multi-Core Performance*
Allows you to determine whether to apply the highest Turbo ratio to all CPU cores
Которое фактически изменяет лимиты PL1, PL2 и Tau с общим расчетом на то, чтобы процессор мог большее время находится в разгоне. На дорогих платах таких настроек может быть несколько, точнее несколько градаций настроек, скажем, как «умеренно, максимально, ультра».
Китайцы и вовсе пошли впереди планеты всей, на некоторых платах может быть вовсе снят лимит с PL2, а то и с PL1, точнее установлен в значение 4096W, чтобы корректно работал расчет Tau.
К чему это может привести догадаться несложно. Если вы не обеспечили эффективного охлаждения и дали предельную нагрузку, то от платы может пойти волшебный дым.
👍13❤1🔥1
TDP – суровая действительность
В молодые годы, а я только-только пришел на работу в компьютерную фирму и стал более-менее свободен в финансах, чтобы позволить себе купить не топовую, но более-менее современную систему, приключилась со мной эта история.
А рассказать я ее решил именно потому, что многие комментаторы в заметках про TDP сводили все именно к процессору, что в корне не верно.
Итак, был у меня компьютер, а сердцем того компьютера был процессор Intel Pentium 4 3 ГГц на ядре Northwood. Довольно горячий камень, надо сказать. Но далеко не такой производительный, как бы мне хотелось.
Денег радикально поменять платформу у меня не было, хотя тот же Athlon XP 3200+ выглядел крайне привлекательно, но уже не за горами были многоядерные Intel и 64-битные AMD, и я решил подождать новинки.
А что делать с текущей системой? Правильно – разогнать. В те времена это было одновременно и проще, и сложнее. Проще – потому что технических ограничений было меньше, а сложнее – информации про разгон также было крайне мало, а интернет еще не был так распространен.
Компьютер был у меня неплохой, не топовый, но собран с запасом из надежного железа, которое показало свою надежность в реальных сборках, которыми мы торговали.
В общем неделю я урывками на рабочем месте собирал информацию в сети по разгону и потом только приступил к воплощению своих идей в жизнь.
Но реальность быстро мне показала, что наши желания далеко не всегда совпадают с нашими возможностями. Процессор мертво застрял на отметке 3200 МГц, уходя по температуре в жестокий троттлинг.
Что надо сделать? Правильно – купить кулер побольше, что я и сделал, модель уже не помню, но это было что-то из суперкулеров от Thermaltake, одна из самых дорогих и эффективных моделей.
И дело пошло! Я потихоньку поднял тактовую частоту до 3500 МГц, добился стабильной работы и приготовился двигаться дальше. Через пару часов покорились 3700 МГц и я запустил стресс-тест.
Ничего не предвещало беды, но вот раздался громкий хлопок из-под стола, и квартира погрузилась во тьму, одновременно наполнившись ни с чем не сравнимым запахом горелой электроники.
Как человек с профильным образованием (инженер связи) я уже понял, что произошло, выдернул ПК из розетки и пошел включил автомат в щитке.
Последствия разгона меня очень сильно огорчили. Во-первых, взорвался блок питания, ключевые транзисторы там просто порвало, а цвет текстолита под их ножками говорил о том, что в режиме перегрева они находились достаточно длительное время.
Во-вторых, разъем доппитания 12 В полностью расплавился, намертво прикипев к плате, текстолит вокруг VRM сильно потемнел.
Процессор намертво приплавился к сокету, но вот с ним ничего страшного и не произошло. Да и приплавился не сам процессор, а некоторые его ножки, по которым шел ток питания, сам кристалл так и не перешагнул планку в 90 градусов.
Процессор сняли, нагрев сокет паяльным феном, материнская плата и блок питания на выброс. Плюс очередные траты на замену, которые оказались совсем-совсем не кстати. Так не кстати, что вместо материнской платы на чипсете Intel пришлось брать убогонький и куда менее производительный SiS.
А для себя я сделал выводы, что никогда не нужно рассматривать систему только через один ее параметр или характеристику. Иначе получится классическое: одно лечим – другое калечим.
Хотите разогнать? Разгоняйте, но перед этим убедитесь, что все компоненты системы выдержат такой режим, а не только один процессор.
В молодые годы, а я только-только пришел на работу в компьютерную фирму и стал более-менее свободен в финансах, чтобы позволить себе купить не топовую, но более-менее современную систему, приключилась со мной эта история.
А рассказать я ее решил именно потому, что многие комментаторы в заметках про TDP сводили все именно к процессору, что в корне не верно.
Итак, был у меня компьютер, а сердцем того компьютера был процессор Intel Pentium 4 3 ГГц на ядре Northwood. Довольно горячий камень, надо сказать. Но далеко не такой производительный, как бы мне хотелось.
Денег радикально поменять платформу у меня не было, хотя тот же Athlon XP 3200+ выглядел крайне привлекательно, но уже не за горами были многоядерные Intel и 64-битные AMD, и я решил подождать новинки.
А что делать с текущей системой? Правильно – разогнать. В те времена это было одновременно и проще, и сложнее. Проще – потому что технических ограничений было меньше, а сложнее – информации про разгон также было крайне мало, а интернет еще не был так распространен.
Компьютер был у меня неплохой, не топовый, но собран с запасом из надежного железа, которое показало свою надежность в реальных сборках, которыми мы торговали.
В общем неделю я урывками на рабочем месте собирал информацию в сети по разгону и потом только приступил к воплощению своих идей в жизнь.
Но реальность быстро мне показала, что наши желания далеко не всегда совпадают с нашими возможностями. Процессор мертво застрял на отметке 3200 МГц, уходя по температуре в жестокий троттлинг.
Что надо сделать? Правильно – купить кулер побольше, что я и сделал, модель уже не помню, но это было что-то из суперкулеров от Thermaltake, одна из самых дорогих и эффективных моделей.
И дело пошло! Я потихоньку поднял тактовую частоту до 3500 МГц, добился стабильной работы и приготовился двигаться дальше. Через пару часов покорились 3700 МГц и я запустил стресс-тест.
Ничего не предвещало беды, но вот раздался громкий хлопок из-под стола, и квартира погрузилась во тьму, одновременно наполнившись ни с чем не сравнимым запахом горелой электроники.
Как человек с профильным образованием (инженер связи) я уже понял, что произошло, выдернул ПК из розетки и пошел включил автомат в щитке.
Последствия разгона меня очень сильно огорчили. Во-первых, взорвался блок питания, ключевые транзисторы там просто порвало, а цвет текстолита под их ножками говорил о том, что в режиме перегрева они находились достаточно длительное время.
Во-вторых, разъем доппитания 12 В полностью расплавился, намертво прикипев к плате, текстолит вокруг VRM сильно потемнел.
Процессор намертво приплавился к сокету, но вот с ним ничего страшного и не произошло. Да и приплавился не сам процессор, а некоторые его ножки, по которым шел ток питания, сам кристалл так и не перешагнул планку в 90 градусов.
Процессор сняли, нагрев сокет паяльным феном, материнская плата и блок питания на выброс. Плюс очередные траты на замену, которые оказались совсем-совсем не кстати. Так не кстати, что вместо материнской платы на чипсете Intel пришлось брать убогонький и куда менее производительный SiS.
А для себя я сделал выводы, что никогда не нужно рассматривать систему только через один ее параметр или характеристику. Иначе получится классическое: одно лечим – другое калечим.
Хотите разогнать? Разгоняйте, но перед этим убедитесь, что все компоненты системы выдержат такой режим, а не только один процессор.
🔥18👌5🤣5⚡3❤3
Не новая, но полезная статья для тех, кто все еще прибивает гвоздями.
Используем APT Pinning для закрепления пакетов в Debian и Ubuntu
Достаточно часто при работе с Linux-системами возникает потребность в установке пакетов в версии отлично от той, что находится в репозиториях.
Чаще всего для этих целей используется ручная установка нужной версии пакета с последующей заморозкой (при необходимости) или сборка пакета из исходников.
В тоже время в основанных на Debian дистрибутивах существует штатная система закрепления пакетов APT Pinning, использование которой более предпочтительно, тем более что работать с ней совсем несложно.
✅ Читать далее: https://interface31.ru/post/ispolzuem-apt-pinning-dlya-zakrepleniya-paketov-v-debian-ubuntu/
Используем APT Pinning для закрепления пакетов в Debian и Ubuntu
Достаточно часто при работе с Linux-системами возникает потребность в установке пакетов в версии отлично от той, что находится в репозиториях.
Чаще всего для этих целей используется ручная установка нужной версии пакета с последующей заморозкой (при необходимости) или сборка пакета из исходников.
В тоже время в основанных на Debian дистрибутивах существует штатная система закрепления пакетов APT Pinning, использование которой более предпочтительно, тем более что работать с ней совсем несложно.
✅ Читать далее: https://interface31.ru/post/ispolzuem-apt-pinning-dlya-zakrepleniya-paketov-v-debian-ubuntu/
👍15❤3
Не взлетает PostgreSQL после восстановления виртуалки из бекапа
С такой проблемой обратился буквально прямо сейчас коллега. Все, говорит уже перепробовал, два раза виртуалку восстанавливал (90 ГБ между прочим), не взлетает - хоть плачь.
А завтра срочно база на 1 декабря нужна, кто-то что-то задним числом поправил, главбух и финансовый рвут и мечут.
Без паники. Что именно происходит?
Postgres запускается, долго думает, а потом падает с сообщением
Затем выходим из учетки Postgres и запускаем службу.
Что мы сделали? Читаем справку:
Почему это понадобилось? Все просто, так как бекап был сделан средствами гипервизора, без остановки СУБД журнал предзаписи оказался в несогласованном состоянии и препятствовал запуску СУБД.
С такой проблемой обратился буквально прямо сейчас коллега. Все, говорит уже перепробовал, два раза виртуалку восстанавливал (90 ГБ между прочим), не взлетает - хоть плачь.
А завтра срочно база на 1 декабря нужна, кто-то что-то задним числом поправил, главбух и финансовый рвут и мечут.
Без паники. Что именно происходит?
Postgres запускается, долго думает, а потом падает с сообщением
'failed' state with result 'timeout'
Понятно, ситуация стандартная, тебе поможет простое заклинание:su - postgres
pg_resetwal -f /var/lib/postgres/data
Затем выходим из учетки Postgres и запускаем службу.
Что мы сделали? Читаем справку:
pg_resetwal очищает журнал предзаписи (WAL) и может сбросить некоторую другую управляющую информацию, хранящуюся в файле pg_control.Почему это понадобилось? Все просто, так как бекап был сделан средствами гипервизора, без остановки СУБД журнал предзаписи оказался в несогласованном состоянии и препятствовал запуску СУБД.
1👍58🤣5🤝3
Midnight Commander 6
Это не новая версия привычного двухпанельника, а форк GNU Midnight Commander 4.8.33. Фактически – современное переосмысление привычного инструмента. Классический mc привычен, удобен, но очень многого не умеет.
Новый mc6 сохраняет все то, к чему мы привыкли и добавляет новые возможности через панельные плагины:
Основное изменение релиза — новый фреймворк панельных плагинов. Теперь содержимое панели может предоставляться динамически загружаемым плагином, а не только локальной файловой системой или встроенными VFS-модулями.
Вместе с новой архитектурой добавлены плагины для архивов, Git, Docker, Kubernetes, MongoDB, S3, FTP, SFTP, Samba и другие. Также значительно расширены возможности редактора и просмотрщика файлов, появился встроенный терминал.
Выглядит достаточно интересно, особенно работа со структурированными данными JSON, YAML, XML и т.п., а также возможность сворачивания блоков кода/конфигурации по скобкам.
Интересны также плагины для Git, Docker и S3, это как раз то, чего катастрофически не хватает современному администратору в классическом менеджере.
В общем – проект интересный, можно смотреть и тестировать, возможно именно он заменит в скором будущем классический mc.
✅ Страница разработчика: https://github.com/ilia-maslakov/mcdev
Это не новая версия привычного двухпанельника, а форк GNU Midnight Commander 4.8.33. Фактически – современное переосмысление привычного инструмента. Классический mc привычен, удобен, но очень многого не умеет.
Новый mc6 сохраняет все то, к чему мы привыкли и добавляет новые возможности через панельные плагины:
Основное изменение релиза — новый фреймворк панельных плагинов. Теперь содержимое панели может предоставляться динамически загружаемым плагином, а не только локальной файловой системой или встроенными VFS-модулями.
Вместе с новой архитектурой добавлены плагины для архивов, Git, Docker, Kubernetes, MongoDB, S3, FTP, SFTP, Samba и другие. Также значительно расширены возможности редактора и просмотрщика файлов, появился встроенный терминал.
Выглядит достаточно интересно, особенно работа со структурированными данными JSON, YAML, XML и т.п., а также возможность сворачивания блоков кода/конфигурации по скобкам.
Интересны также плагины для Git, Docker и S3, это как раз то, чего катастрофически не хватает современному администратору в классическом менеджере.
В общем – проект интересный, можно смотреть и тестировать, возможно именно он заменит в скором будущем классический mc.
✅ Страница разработчика: https://github.com/ilia-maslakov/mcdev
👍28👏1👀1
Безопасное извлечение устройства в Windows 10 и 11
Что такое безопасное извлечение устройства знают все, правда не все знают для чего именно оно нужно. Некоторые ошибочно считают, что безопасное отключение предназначено для предотвращения физического повреждения устройства. Однако это не так.
При безопасном извлечении в Windows XP действительно отключалось питание устройства, потом от этой практики отказались и с электрической точки зрения безопасное извлечение ничем не отличается от обычного.
Основное назначение безопасного отключения – это предотвратить потерю данных принудительно сбросив на устройство кеш записи, который использовался для ускорения работы с внешними накопителями.
Однако начиная с Windows 10 1809 кеширование для внешних накопителей по умолчанию отключено и для них используется политика Быстрое удаление (Quick removal), это означает что все внешние накопители можно безопасно извлекать без использования одноименной процедуры.
Такой подход несколько снижает производительность, но делает работу с флешками более простой и надежной, поэтому мы не видим смысла менять эту политику.
Другое дело, когда вы используете внешние диски и сценарий работы с ними отличается от подключил – скопировал – отключил. В этом случае имеет смысл вернуть кеширование включив политику Оптимальная производительность (Better performance).
Что такое безопасное извлечение устройства знают все, правда не все знают для чего именно оно нужно. Некоторые ошибочно считают, что безопасное отключение предназначено для предотвращения физического повреждения устройства. Однако это не так.
При безопасном извлечении в Windows XP действительно отключалось питание устройства, потом от этой практики отказались и с электрической точки зрения безопасное извлечение ничем не отличается от обычного.
Основное назначение безопасного отключения – это предотвратить потерю данных принудительно сбросив на устройство кеш записи, который использовался для ускорения работы с внешними накопителями.
Однако начиная с Windows 10 1809 кеширование для внешних накопителей по умолчанию отключено и для них используется политика Быстрое удаление (Quick removal), это означает что все внешние накопители можно безопасно извлекать без использования одноименной процедуры.
Такой подход несколько снижает производительность, но делает работу с флешками более простой и надежной, поэтому мы не видим смысла менять эту политику.
Другое дело, когда вы используете внешние диски и сценарий работы с ними отличается от подключил – скопировал – отключил. В этом случае имеет смысл вернуть кеширование включив политику Оптимальная производительность (Better performance).
1👍23❤5
Почему после внесения изменений в конфигурацию брандмауэра лучше перезагрузить роутер
Эта история произошла на днях с одним коллегой. В очередной раз внося изменения в конфигурацию брандмауэра Mikrotik он обнаружил правила, которые, согласно комментариям, относились к IPsec, который уже давно не использовался.
Он сбросил на них счетчики и несколько дней понаблюдал – счетчики не менялись. После чего он просто выключил эти правила. Ничего не сломалось и все продолжило работать как работало. На том он благополучно и забыл об этой истории.
Напомнила она о себе совсем недавно. Менеджеры стали жаловаться, что обмен с некоторыми точками происходит ну очень медленно.
Стали разбираться и выяснилось, что не так давно отвалились все входящие L2TP-соединения от точек и трафик для них пошел по медленному резервному пути.
А почему отвалились? Потому что не смогли собрать IPsec, по причине выключенных правил брандмауэра.
Так погодите, но работало же все? Правила еще когда изменились, а случилось все только сейчас.
Но это вполне нормальное поведение, в любом правильно настроенном брандмауэре на базе iptables, включая Mikrotik, первым в цепочках стоит правило, разрешающее уже установленные соединения – ESTABLISHED. И все существующие соединения будут проходить именно через него, не двигаясь по цепочкам дальше.
Поэтому вы можете хоть сто раз поменять нижестоящие правила, но действовать они начнут только для новых соединений. А если у нас каналы связи стабильны и соединения не отваливаются по таймауту, то существовать такая ситуация может бесконечно долго.
В нашем случае триггером стала перезагрузка роутера. После чего L2TP соединения, которые из установленных стали новыми устанавливаться перестали.
Поэтому, если вы не хотите неприятных неожиданностей в самый неподходящий момент – после внесения изменений в брандмауэр обязательно перезагрузите роутер. Возможно, узнаете много интересного.
Альтернативой этому может послужить сброс соединений в Connection Tracker, но для этого еще нужно знать, какие соединения сбрасывать. Или сбросить вообще все, что фактически равноценно перезагрузке роутера. Поэтому лучше и надежнее все-таки перезагрузить.
Эта история произошла на днях с одним коллегой. В очередной раз внося изменения в конфигурацию брандмауэра Mikrotik он обнаружил правила, которые, согласно комментариям, относились к IPsec, который уже давно не использовался.
Он сбросил на них счетчики и несколько дней понаблюдал – счетчики не менялись. После чего он просто выключил эти правила. Ничего не сломалось и все продолжило работать как работало. На том он благополучно и забыл об этой истории.
Напомнила она о себе совсем недавно. Менеджеры стали жаловаться, что обмен с некоторыми точками происходит ну очень медленно.
Стали разбираться и выяснилось, что не так давно отвалились все входящие L2TP-соединения от точек и трафик для них пошел по медленному резервному пути.
А почему отвалились? Потому что не смогли собрать IPsec, по причине выключенных правил брандмауэра.
Так погодите, но работало же все? Правила еще когда изменились, а случилось все только сейчас.
Но это вполне нормальное поведение, в любом правильно настроенном брандмауэре на базе iptables, включая Mikrotik, первым в цепочках стоит правило, разрешающее уже установленные соединения – ESTABLISHED. И все существующие соединения будут проходить именно через него, не двигаясь по цепочкам дальше.
Поэтому вы можете хоть сто раз поменять нижестоящие правила, но действовать они начнут только для новых соединений. А если у нас каналы связи стабильны и соединения не отваливаются по таймауту, то существовать такая ситуация может бесконечно долго.
В нашем случае триггером стала перезагрузка роутера. После чего L2TP соединения, которые из установленных стали новыми устанавливаться перестали.
Поэтому, если вы не хотите неприятных неожиданностей в самый неподходящий момент – после внесения изменений в брандмауэр обязательно перезагрузите роутер. Возможно, узнаете много интересного.
Альтернативой этому может послужить сброс соединений в Connection Tracker, но для этого еще нужно знать, какие соединения сбрасывать. Или сбросить вообще все, что фактически равноценно перезагрузке роутера. Поэтому лучше и надежнее все-таки перезагрузить.
👍29👌5❤1
Вектор развития
Дискуссия на тему развития сотрудника и развития инфраструктуры предприятия - тема вечная. Многие ставят между этими понятиями знак равенства, хотя это совсем не так.
Мы уже много раз писали на эту тему, поэтому не будем повторяться, но акцентируем внимание на ключевых тезисах. Сотрудник ≠ Бизнес (как бы иногда бизнесу и не хотелось продвинуть иную мысль).
Бизнес занимается зарабатыванием денег, в чем его основной интерес. Сотрудник продает свое время и квалификацию за деньги – и никак иначе. А как по-другому? Бизнес его содержать в случае чего будет? Ага, держите карман шире.
Поэтому интересы у сотрудника и бизнеса разные, в чем-то они совпадают, в чем-то расходятся. И это нормально. Не нормально, когда одна из сторон начинает путать собственные интересы с интересами контрагента, ни к чему хорошему это не приводит.
Начнем с интересов бизнеса. Основной интерес- это получение прибыли. Прибыль – основа стабильной работы и развития предприятия. Падение прибыли приводит к экономии, в том числе и на ФОТ, сокращению рабочих мест и т.д. и т.п.
В этом плане интересы сотрудника и бизнеса совпадают, сотрудник также заинтересован в нормальном функционировании бизнеса, иначе он потеряет в деньгах и, возможно, лишится рабочего места.
Бизнес также заинтересован в удержании сотрудников, особенно тех, кого нельзя просто заменить с улицы. Но этот момент нужно понимать правильно, бизнес – не благотворительность. Если на линейную должность на улице стоит очередь – то и оклад там будет по нижней планке и выжимать будут все соки.
А вот если это ключевой квалифицированный сотрудник, на которого завязаны многие важные бизнес-процессы, то подход будет совершенно иной. Потому что у бизнеса здесь прямой интерес, совпадающий с интересом сотрудника.
Но вернемся к IT – это такая сфера, которая никогда не стоит на месте и если мы хотим быть актуальными на рынке труда – то нужно постоянно развиваться. Никому не нужен сотрудник или подрядчик, который владеет технологиями десятилетней давности, пусть даже и в совершенстве.
Поэтому интерес сотрудника развиваться вполне естественен и понятен. И еще ему хочется совместить приятное с полезным, а именно развиваться в рамках собственного предприятия за его счет и на его ресурсах.
Но нужно ли это бизнесу? Есть заблуждение, что если бизнес не внедряет современные технологии, то он не развивается (в плане информационной инфраструктуры), но это не так. Бизнес тоже может развивать свою IT-инфраструктуру, только совсем не туда, куда смотрит сотрудник.
Вместо современных технологий может внедряться разные сложные и специфичные вещи, которые сотруднику не интересны. Ну не видит он куда их можно применить за воротами именно этого работодателя и кому продать их на рынке труда.
А бизнесу, в свою очередь, могут быть не нужны все эти докеры, куберы и прочие современные технологии, у него другие задачи и потребности.
В результате возникает расхождение интересов, вектор развития предприятия не совпадает с вектором развития сотрудника и это нормально.
Для примера возьмем известную сеть Красное и Белое, информационная система у них до сих пор построена на устаревшей платформе 1С:Предприятие 7.7. Можно ли при этом сказать, что инфраструктура компании не развивается?
Нет, нельзя, потому что они развиваются, внедряют современные технологии, ту же маркировку и прочее. Т.е. движутся собственным курсом к собственным целям и достаточно успешно.
Но это курс бизнеса, который не совпадает с курсом сотрудника. Кому нужен в 2026 году специалист по «клюшкам» (жаргонное название 1Сv77)? Никому. Да, отнесутся с уважением, мол «монстр», но не более, на рынке труда спроса на таких специалистов нет.
Какой выбор у сотрудника? А выбор невелик, либо связать свою карьеру именно с этой компанией и развиваться в общем направлении, понимая, что за забором перспектив нет, или начать движение по собственному вектору, приобретая знания и навыки, востребованные современным рынком.
Дискуссия на тему развития сотрудника и развития инфраструктуры предприятия - тема вечная. Многие ставят между этими понятиями знак равенства, хотя это совсем не так.
Мы уже много раз писали на эту тему, поэтому не будем повторяться, но акцентируем внимание на ключевых тезисах. Сотрудник ≠ Бизнес (как бы иногда бизнесу и не хотелось продвинуть иную мысль).
Бизнес занимается зарабатыванием денег, в чем его основной интерес. Сотрудник продает свое время и квалификацию за деньги – и никак иначе. А как по-другому? Бизнес его содержать в случае чего будет? Ага, держите карман шире.
Поэтому интересы у сотрудника и бизнеса разные, в чем-то они совпадают, в чем-то расходятся. И это нормально. Не нормально, когда одна из сторон начинает путать собственные интересы с интересами контрагента, ни к чему хорошему это не приводит.
Начнем с интересов бизнеса. Основной интерес- это получение прибыли. Прибыль – основа стабильной работы и развития предприятия. Падение прибыли приводит к экономии, в том числе и на ФОТ, сокращению рабочих мест и т.д. и т.п.
В этом плане интересы сотрудника и бизнеса совпадают, сотрудник также заинтересован в нормальном функционировании бизнеса, иначе он потеряет в деньгах и, возможно, лишится рабочего места.
Бизнес также заинтересован в удержании сотрудников, особенно тех, кого нельзя просто заменить с улицы. Но этот момент нужно понимать правильно, бизнес – не благотворительность. Если на линейную должность на улице стоит очередь – то и оклад там будет по нижней планке и выжимать будут все соки.
А вот если это ключевой квалифицированный сотрудник, на которого завязаны многие важные бизнес-процессы, то подход будет совершенно иной. Потому что у бизнеса здесь прямой интерес, совпадающий с интересом сотрудника.
Но вернемся к IT – это такая сфера, которая никогда не стоит на месте и если мы хотим быть актуальными на рынке труда – то нужно постоянно развиваться. Никому не нужен сотрудник или подрядчик, который владеет технологиями десятилетней давности, пусть даже и в совершенстве.
Поэтому интерес сотрудника развиваться вполне естественен и понятен. И еще ему хочется совместить приятное с полезным, а именно развиваться в рамках собственного предприятия за его счет и на его ресурсах.
Но нужно ли это бизнесу? Есть заблуждение, что если бизнес не внедряет современные технологии, то он не развивается (в плане информационной инфраструктуры), но это не так. Бизнес тоже может развивать свою IT-инфраструктуру, только совсем не туда, куда смотрит сотрудник.
Вместо современных технологий может внедряться разные сложные и специфичные вещи, которые сотруднику не интересны. Ну не видит он куда их можно применить за воротами именно этого работодателя и кому продать их на рынке труда.
А бизнесу, в свою очередь, могут быть не нужны все эти докеры, куберы и прочие современные технологии, у него другие задачи и потребности.
В результате возникает расхождение интересов, вектор развития предприятия не совпадает с вектором развития сотрудника и это нормально.
Для примера возьмем известную сеть Красное и Белое, информационная система у них до сих пор построена на устаревшей платформе 1С:Предприятие 7.7. Можно ли при этом сказать, что инфраструктура компании не развивается?
Нет, нельзя, потому что они развиваются, внедряют современные технологии, ту же маркировку и прочее. Т.е. движутся собственным курсом к собственным целям и достаточно успешно.
Но это курс бизнеса, который не совпадает с курсом сотрудника. Кому нужен в 2026 году специалист по «клюшкам» (жаргонное название 1Сv77)? Никому. Да, отнесутся с уважением, мол «монстр», но не более, на рынке труда спроса на таких специалистов нет.
Какой выбор у сотрудника? А выбор невелик, либо связать свою карьеру именно с этой компанией и развиваться в общем направлении, понимая, что за забором перспектив нет, или начать движение по собственному вектору, приобретая знания и навыки, востребованные современным рынком.
👍12🤔10🥱3❤2
Допустимые типы контента для хранилищ Proxmox
Собрали в небольшую, но полезную таблицу допустимые типы контента для разных типов хранилищ.
С ее помощью можно быстро оценить какой тип хранилища лучшим образом подходит для ваших задач.
Вся информация взята из официальных источников.
Поводом для создания подобной таблички послужили злоключения молодого коллеги, который потратил время на установку и настройку iSCSI-таргета, но только подключив его к Proxmox обнаружил, что оно не поддерживает LXC-контейнеры.
Собрали в небольшую, но полезную таблицу допустимые типы контента для разных типов хранилищ.
С ее помощью можно быстро оценить какой тип хранилища лучшим образом подходит для ваших задач.
Вся информация взята из официальных источников.
Поводом для создания подобной таблички послужили злоключения молодого коллеги, который потратил время на установку и настройку iSCSI-таргета, но только подключив его к Proxmox обнаружил, что оно не поддерживает LXC-контейнеры.
5👍28❤3🔥3🤔2
Вектор развития. Продолжение
Читатели задали очень хороший вопрос: а в чем смысл развития сотрудника по собственному вектору, вне трека предприятия? Ведь работодателю нужны не знания, а опыт – и он совершенно прав.
Что такое знания? Это просто теория. А опыт – это умение применять знания на практике. И платят хорошему специалисту именно за опыт, а не за знания. Так что получается? Менять работу?
Разные гуру и коучи бодро скажут – да! Не бойся меняться, отбрось страхи и неуверенность и вперед к новым вершинам! Но языком истории рассказывать, это не мешки разгружать, поэтому вернемся в суровую реальность.
Что значит поменять работу ради перспектив развития? Вы уходите с крепкой позиции (мидл или даже сеньор) в своем стеке на позицию начинающего (джуниора) в новом стеке, проседая как в зарплате, так и в разных прочих плюшках, включая ценность вас в глазах работодателя.
И хорошо если вам 20 с хвостиком и у вас за плечами нет детей, кредитов, ипотек, жены, тещи и стареньких родителей.
А в ином раскладе эта авантюра является именно авантюрой, с непонятным итоговым результатом. Оставить все как есть? Тоже опасно. В этом случае вы станете заложником вашего работодателя, особенно если он поймет, что за его воротами вы по факту «человек без профессии».
Как быть? Что делать? К счастью, мы живем в современном мире и не связаны именно своей локацией. Если вы понимаете, что вам надо развиваться, но в рамках своего рабочего места вы не можете этого сделать – то к вашим услугам сеть.
Начнем с открытых проектов. Многие из них держатся на паре-тройке активных разработчиков и поэтому каждый активный участник ими только приветствуется. А это отличная строка в резюме, да и просто пыль в глаза пустить – у кого еще в штате есть разработчик открытого проекта?
А работодатель вполне может оценить вашу активность в проекте и прикинуть возможный опыт, который перекроет ваш опыт с прошлой работы. Мол, да, на старом месте он со всякой ерундой работал, но вот же проект вел, активно. Нам такие нужны.
Другой вариант – пет-проекты, это тоже хороший способ рассказать о себе и показать свои умения. Особенно если этот проект имеет практическое применение. А для этого можно найти себе какое-нибудь небольшое предприятие, на котором это обкатывать в свободное от работы время.
Малый бизнес он вообще не избалован вниманием и стеснен в средствах и если вы ему за сумму малую предложите стать «подопытным кроликом» и выгоды для него будет больше чем возможного убытка – он согласится.
Также не забывайте про профессиональные сообщества. Если брать мир 1С, то тот же Инфостарт. Написали отчет или обработку? Опубликуйте. И не важно, что там есть уже сотни таких же, важен сам факт публикации. Из которых потом соберется ваше портфолио.
Работодатель не будет вникать в тонкости, он отметит, что вы ведете активную жизнь в профессиональных сообществах, имеете собственные разработки и публикации, что заменит вам опыт в рамках текущего работодателя.
И не стесняйтесь продвигать себя везде, где это возможно. Есть возможность что-то написать или опубликовать в техническом сообществе – напишите и опубликуйте. Есть возможность поехать на конференцию – езжайте.
В общем – чем больше вы засветитесь в профессиональных тусовках – тем лучше. Это та же самая строчка в резюме про опыт. Да, вы работали с устаревшим стеком, но в сообществе вас знают как грамотного специалиста по новому стеку. И это будет ваш плюс при смене работы.
Теперь вы сможете поменять рабочее место примерно с равной позиции на равную. Но, главное, вы должны быть, а не казаться. Иначе может быть очень больное приземление, когда вы уже не там и не здесь. И куда теперь идти – непонятно.
Но если вы реально втянулись в новую тему, активны в профессиональных сообществах, имеете публикации и проекты, то всем будет все равно на ваш бэкграунд, вас будут воспринимать как современного специалиста с опытом, что вам и надо.
Читатели задали очень хороший вопрос: а в чем смысл развития сотрудника по собственному вектору, вне трека предприятия? Ведь работодателю нужны не знания, а опыт – и он совершенно прав.
Что такое знания? Это просто теория. А опыт – это умение применять знания на практике. И платят хорошему специалисту именно за опыт, а не за знания. Так что получается? Менять работу?
Разные гуру и коучи бодро скажут – да! Не бойся меняться, отбрось страхи и неуверенность и вперед к новым вершинам! Но языком истории рассказывать, это не мешки разгружать, поэтому вернемся в суровую реальность.
Что значит поменять работу ради перспектив развития? Вы уходите с крепкой позиции (мидл или даже сеньор) в своем стеке на позицию начинающего (джуниора) в новом стеке, проседая как в зарплате, так и в разных прочих плюшках, включая ценность вас в глазах работодателя.
И хорошо если вам 20 с хвостиком и у вас за плечами нет детей, кредитов, ипотек, жены, тещи и стареньких родителей.
А в ином раскладе эта авантюра является именно авантюрой, с непонятным итоговым результатом. Оставить все как есть? Тоже опасно. В этом случае вы станете заложником вашего работодателя, особенно если он поймет, что за его воротами вы по факту «человек без профессии».
Как быть? Что делать? К счастью, мы живем в современном мире и не связаны именно своей локацией. Если вы понимаете, что вам надо развиваться, но в рамках своего рабочего места вы не можете этого сделать – то к вашим услугам сеть.
Начнем с открытых проектов. Многие из них держатся на паре-тройке активных разработчиков и поэтому каждый активный участник ими только приветствуется. А это отличная строка в резюме, да и просто пыль в глаза пустить – у кого еще в штате есть разработчик открытого проекта?
А работодатель вполне может оценить вашу активность в проекте и прикинуть возможный опыт, который перекроет ваш опыт с прошлой работы. Мол, да, на старом месте он со всякой ерундой работал, но вот же проект вел, активно. Нам такие нужны.
Другой вариант – пет-проекты, это тоже хороший способ рассказать о себе и показать свои умения. Особенно если этот проект имеет практическое применение. А для этого можно найти себе какое-нибудь небольшое предприятие, на котором это обкатывать в свободное от работы время.
Малый бизнес он вообще не избалован вниманием и стеснен в средствах и если вы ему за сумму малую предложите стать «подопытным кроликом» и выгоды для него будет больше чем возможного убытка – он согласится.
Также не забывайте про профессиональные сообщества. Если брать мир 1С, то тот же Инфостарт. Написали отчет или обработку? Опубликуйте. И не важно, что там есть уже сотни таких же, важен сам факт публикации. Из которых потом соберется ваше портфолио.
Работодатель не будет вникать в тонкости, он отметит, что вы ведете активную жизнь в профессиональных сообществах, имеете собственные разработки и публикации, что заменит вам опыт в рамках текущего работодателя.
И не стесняйтесь продвигать себя везде, где это возможно. Есть возможность что-то написать или опубликовать в техническом сообществе – напишите и опубликуйте. Есть возможность поехать на конференцию – езжайте.
В общем – чем больше вы засветитесь в профессиональных тусовках – тем лучше. Это та же самая строчка в резюме про опыт. Да, вы работали с устаревшим стеком, но в сообществе вас знают как грамотного специалиста по новому стеку. И это будет ваш плюс при смене работы.
Теперь вы сможете поменять рабочее место примерно с равной позиции на равную. Но, главное, вы должны быть, а не казаться. Иначе может быть очень больное приземление, когда вы уже не там и не здесь. И куда теперь идти – непонятно.
Но если вы реально втянулись в новую тему, активны в профессиональных сообществах, имеете публикации и проекты, то всем будет все равно на ваш бэкграунд, вас будут воспринимать как современного специалиста с опытом, что вам и надо.
👍12🤔9❤2👌2🫡1
Спрашивают – отвечаем
Вопрос вот в чем: есть энтерпрайз SSD за очень много денег, там все ок. А как быть бедным, кто ставит nvme в лучшем случае из топа потребительских? Что выбрать, на что смотреть?
Начнем с того, что выбрать можно все что угодно, даже не из топа, все зависит от доступного бюджета. Но перед выбором нужно внимательно посмотреть.
Начнем с того, что пишут в спецификациях. А именно с ресурса. Это основной показатель, от которого зависит как часто вы будете менять диски. Соизмеряем его с текущей нагрузкой и прикидываем затраты. Может оказаться так, что взять более дорогой диск будет выгоднее.
А может произойти ровно наоборот. Иногда выгоднее чаще менять дешевые диски, чем дорогие, но реже.
При этом следует понимать, что никакой серебряной пули в потребительском сегменте нет. Все упирается в ресурс. Это для настольного компьютера вы покупаете топовый Samsung и несколько лет радуетесь жизни.
В случае серверного применения ресурс дорого Samsung будет тратиться также быстро, как и ресурс более дешевого аналога. А если все равно через год менять, то можно не выпендриваться и взять что-нибудь попроще.
Дальше смотрим на еще один важный параметр: модель работы SLC-кеша. В описаниях его нет, тут помогут только обзоры. Например, есть полностью аппаратно одинаковые диски, но с разными вариантами кеширования и разным поведением под нагрузками.
Грубо говоря, есть два основных варианта. В первом под кеш отдается все свободное место (33% от свободной емкости накопителя TLC), который пишется на максимальной скорости. А вот потом наступает самый плохой для диска сценарий – контроллер одновременно пишет и уплотняет данные и скорость там может упасть до неприлично низких значений.
Второй вариант – небольшой кеш и потом достаточно высокая и стабильная скорость записи, но далеко уже не та, что указана в спецификациях диска.
Тут нельзя однозначно сказать, что хорошо, а что плохо, смотрите по своим задачам и нагрузкам. Где-то лучше себя покажет одна модель кеширования, где-то другая.
Определились, хорошо. Теперь обращаем внимание на потребительские характеристики. В частности, на теплоотвод и возможность его снять без потери гарантии. Лучше всего брать модели, где теплоотвод сразу не приклеен, ну или понимать, что гарантии на диск у вас не будет.
Почему? Да потому что серверная нагрузка сильно отличается от настольной и вашему диску в обязательном порядке нужен хороший теплоотвод, иначе он постоянно будет находится в состоянии перегрева или близкого к нему.
Чтобы оградить себя от внезапного отказа в обязательном порядке собираем RAID. И в этом случае нам важно добиться идентичных режимов работы у обоих дисков.
Если вы используете разъемы на материнской плате – убедитесь, что к ним подведено одинаковое количество линий PCIe и одинакового поколения.
Иначе ваш массив будет работать на скорости самого медленного диска и это в лучшем случае.
Также очень важно еще и соблюдать идентичность скоростных характеристик дисков, в частности режимов кеширования. Если один диск продолжает принимать данные на полной скорости, а второй ее резко снизил, то есть ненулевые шансы, что такой диск выкинет из массива, хотя он будет полностью исправен.
Либо мы получим резкую деградацию производительности, иногда буквально «на ровном месте».
Это условие важно соблюдать и при замене дисков в массиве. Если купить точно такой же диск нет возможности, то приобретайте максимально похожий, желательно на контроллере того же производителя.
Если это невозможно – меняйте оба диска. Также не следует сочетать в одном массиве диски на разных поколениях шины PCIe, итоговая скорость записи может упасть ниже скорости самого медленного диска.
Ну и постоянный мониторинг. Температуры, ресурса и свободного места на массиве. Не допускайте заполнения более 60-70%, лучше всего иметь запас примерно на 50%, иначе задумайтесь о приобретении более емких моделей.
Также заведите за правило менять диски раз в три года (средний срок гарантии) даже если с ними все в порядке. Кстати это касается не только NVMe.
Вопрос вот в чем: есть энтерпрайз SSD за очень много денег, там все ок. А как быть бедным, кто ставит nvme в лучшем случае из топа потребительских? Что выбрать, на что смотреть?
Начнем с того, что выбрать можно все что угодно, даже не из топа, все зависит от доступного бюджета. Но перед выбором нужно внимательно посмотреть.
Начнем с того, что пишут в спецификациях. А именно с ресурса. Это основной показатель, от которого зависит как часто вы будете менять диски. Соизмеряем его с текущей нагрузкой и прикидываем затраты. Может оказаться так, что взять более дорогой диск будет выгоднее.
А может произойти ровно наоборот. Иногда выгоднее чаще менять дешевые диски, чем дорогие, но реже.
При этом следует понимать, что никакой серебряной пули в потребительском сегменте нет. Все упирается в ресурс. Это для настольного компьютера вы покупаете топовый Samsung и несколько лет радуетесь жизни.
В случае серверного применения ресурс дорого Samsung будет тратиться также быстро, как и ресурс более дешевого аналога. А если все равно через год менять, то можно не выпендриваться и взять что-нибудь попроще.
Дальше смотрим на еще один важный параметр: модель работы SLC-кеша. В описаниях его нет, тут помогут только обзоры. Например, есть полностью аппаратно одинаковые диски, но с разными вариантами кеширования и разным поведением под нагрузками.
Грубо говоря, есть два основных варианта. В первом под кеш отдается все свободное место (33% от свободной емкости накопителя TLC), который пишется на максимальной скорости. А вот потом наступает самый плохой для диска сценарий – контроллер одновременно пишет и уплотняет данные и скорость там может упасть до неприлично низких значений.
Второй вариант – небольшой кеш и потом достаточно высокая и стабильная скорость записи, но далеко уже не та, что указана в спецификациях диска.
Тут нельзя однозначно сказать, что хорошо, а что плохо, смотрите по своим задачам и нагрузкам. Где-то лучше себя покажет одна модель кеширования, где-то другая.
Определились, хорошо. Теперь обращаем внимание на потребительские характеристики. В частности, на теплоотвод и возможность его снять без потери гарантии. Лучше всего брать модели, где теплоотвод сразу не приклеен, ну или понимать, что гарантии на диск у вас не будет.
Почему? Да потому что серверная нагрузка сильно отличается от настольной и вашему диску в обязательном порядке нужен хороший теплоотвод, иначе он постоянно будет находится в состоянии перегрева или близкого к нему.
Чтобы оградить себя от внезапного отказа в обязательном порядке собираем RAID. И в этом случае нам важно добиться идентичных режимов работы у обоих дисков.
Если вы используете разъемы на материнской плате – убедитесь, что к ним подведено одинаковое количество линий PCIe и одинакового поколения.
Иначе ваш массив будет работать на скорости самого медленного диска и это в лучшем случае.
Также очень важно еще и соблюдать идентичность скоростных характеристик дисков, в частности режимов кеширования. Если один диск продолжает принимать данные на полной скорости, а второй ее резко снизил, то есть ненулевые шансы, что такой диск выкинет из массива, хотя он будет полностью исправен.
Либо мы получим резкую деградацию производительности, иногда буквально «на ровном месте».
Это условие важно соблюдать и при замене дисков в массиве. Если купить точно такой же диск нет возможности, то приобретайте максимально похожий, желательно на контроллере того же производителя.
Если это невозможно – меняйте оба диска. Также не следует сочетать в одном массиве диски на разных поколениях шины PCIe, итоговая скорость записи может упасть ниже скорости самого медленного диска.
Ну и постоянный мониторинг. Температуры, ресурса и свободного места на массиве. Не допускайте заполнения более 60-70%, лучше всего иметь запас примерно на 50%, иначе задумайтесь о приобретении более емких моделей.
Также заведите за правило менять диски раз в три года (средний срок гарантии) даже если с ними все в порядке. Кстати это касается не только NVMe.
👍15🤔5❤3🤯1
Особенности использования райзеров для M.2 NVMe дисков
В комментариях подняли интересную тему – райзеры для M.2 дисков, что это такое? Говоря простым языком – это плата переходник, которая позволяет подключиться к штатному слоту PCIe x16 материнской платы и на полной скорости от процессора подключить до 4 NVMe дисков.
Но не все так просто в нашем мире. Нет, сама идея райзера хороша, вы не только получаете 4 диска на полной пропускной способности шины, но еще и выносите их в сторону от горячих участков материнской платы, а многие модели райзеров, как показанная на рисунке модель от ASRock, обеспечивают еще и отличное охлаждение.
Основная проблема кроется в линиях PCIe, которые конечны и которые должны быть правильно сконфигурированы. Самые распространенные райзеры – пассивные, т.е. просто плата переходник с одного разъема на другой. Без какого-либо преобразования.
И тут нам нужно не просто подать туда PCIe x16, а заставить контроллер (который в процессоре) работать в режиме x4/x4/x4/x4. Только в этом случае у нас будут видеться и работать все четыре диска райзера.
А дальше уже все не так просто и сильно зависит от железа. Начнем с процессоров AMD.
Процессоры AMD старших серий предоставляют пользователю 24 линии PCIe, 16 из них идут на первый слот для видеокарты, еще 4 линии на разъем M.2, остальные разводятся по дополнительным разъемам в самых разных вариациях.
Но если процессор содержит встроенное видеоядро, которому самому нужны PCIe линии, то решается это по-разному, в сериях AM4 (Ryzen 3000G / 4000G / 5000G) вместо PCIe 4.0 вы получите те же 24 линии PCIe 3.0.
А вот в новых сериях AM5 (Ryzen 8000G) линии сильно урезаны. На старших моделях (8700G/8600G) под основной GPU-слот выделено только 8 линий PCIe 4.0. На младших (8500G/8300G) — всего 4 линии на основной слот.
Но при этом процессоры AMD, если это реализовано в BIOS материнской платы поддерживают бифуркацию до x4/x4/x4/x4, никаких проблем с этим нет.
Кроме процессора линии PCIe может предоставлять чипсет, но он связан с процессором 4 линиями PCIe и может служить узким горлышком, особенно если вы используете сеть 2,5 G и выше или прочие линии от чипсета.
Поэтому нормальная практика в том, что чипсет предоставляет линии предыдущего поколения, если у процессора поддержка PCIe 4.0, то чипсет будет отдавать линии PCIe 3.0 и вряд ли вы найдете платы, где чипсет отдает 16 линий.
Если перейти в стан их конкурентов, то у Intel не все так радужно. Если мы берем процессоры LGA1700 — Core 12, 13, 14 поколений, то там пользователю доступно 20 линий PCIe, 16 на основной слот, 4 для NVMe.
Для LGA1851 — Core Ultra 200S / Arrow Lake количество линий было увеличено до 24 и делятся они как 16 линий на основной слот, а остальные 8 на два M.2 разъема.
Но процессоры Intel не поддерживают бифуркацию до x4/x4/x4/x4, максимум x8/x4/x4, что не дает возможности полноценно использовать пассивные райзеры.
Из хороших новостей: для общения с чипсетом процессор использует шину DMI 4.0 x8, что аналогично восьми линиям PCIe 4.0 и чипсетные линии не являются узким горлышком, ну а как и кто их развел – это уже надо спрашивать с производителей плат.
Если ваша плата или процессор не поддерживают полноценную бифуркацию до x4/x4/x4/x4, то вам нужен активный райзер, на котором установлен дополнительный чип PCIe коммутатора (моста) и который сам разложит поступившие ему 16 линий на 4 набора по 4 линии, но такие райзеры дороже.
Поэтому нельзя просто так купить и поставить райзер, а надо изучить структуру своей материнской платы, процессора и их совместные возможности, иначе можно очень сильно разочароваться.
В комментариях подняли интересную тему – райзеры для M.2 дисков, что это такое? Говоря простым языком – это плата переходник, которая позволяет подключиться к штатному слоту PCIe x16 материнской платы и на полной скорости от процессора подключить до 4 NVMe дисков.
Но не все так просто в нашем мире. Нет, сама идея райзера хороша, вы не только получаете 4 диска на полной пропускной способности шины, но еще и выносите их в сторону от горячих участков материнской платы, а многие модели райзеров, как показанная на рисунке модель от ASRock, обеспечивают еще и отличное охлаждение.
Основная проблема кроется в линиях PCIe, которые конечны и которые должны быть правильно сконфигурированы. Самые распространенные райзеры – пассивные, т.е. просто плата переходник с одного разъема на другой. Без какого-либо преобразования.
И тут нам нужно не просто подать туда PCIe x16, а заставить контроллер (который в процессоре) работать в режиме x4/x4/x4/x4. Только в этом случае у нас будут видеться и работать все четыре диска райзера.
А дальше уже все не так просто и сильно зависит от железа. Начнем с процессоров AMD.
Процессоры AMD старших серий предоставляют пользователю 24 линии PCIe, 16 из них идут на первый слот для видеокарты, еще 4 линии на разъем M.2, остальные разводятся по дополнительным разъемам в самых разных вариациях.
Но если процессор содержит встроенное видеоядро, которому самому нужны PCIe линии, то решается это по-разному, в сериях AM4 (Ryzen 3000G / 4000G / 5000G) вместо PCIe 4.0 вы получите те же 24 линии PCIe 3.0.
А вот в новых сериях AM5 (Ryzen 8000G) линии сильно урезаны. На старших моделях (8700G/8600G) под основной GPU-слот выделено только 8 линий PCIe 4.0. На младших (8500G/8300G) — всего 4 линии на основной слот.
Но при этом процессоры AMD, если это реализовано в BIOS материнской платы поддерживают бифуркацию до x4/x4/x4/x4, никаких проблем с этим нет.
Кроме процессора линии PCIe может предоставлять чипсет, но он связан с процессором 4 линиями PCIe и может служить узким горлышком, особенно если вы используете сеть 2,5 G и выше или прочие линии от чипсета.
Поэтому нормальная практика в том, что чипсет предоставляет линии предыдущего поколения, если у процессора поддержка PCIe 4.0, то чипсет будет отдавать линии PCIe 3.0 и вряд ли вы найдете платы, где чипсет отдает 16 линий.
Если перейти в стан их конкурентов, то у Intel не все так радужно. Если мы берем процессоры LGA1700 — Core 12, 13, 14 поколений, то там пользователю доступно 20 линий PCIe, 16 на основной слот, 4 для NVMe.
Для LGA1851 — Core Ultra 200S / Arrow Lake количество линий было увеличено до 24 и делятся они как 16 линий на основной слот, а остальные 8 на два M.2 разъема.
Но процессоры Intel не поддерживают бифуркацию до x4/x4/x4/x4, максимум x8/x4/x4, что не дает возможности полноценно использовать пассивные райзеры.
Из хороших новостей: для общения с чипсетом процессор использует шину DMI 4.0 x8, что аналогично восьми линиям PCIe 4.0 и чипсетные линии не являются узким горлышком, ну а как и кто их развел – это уже надо спрашивать с производителей плат.
Если ваша плата или процессор не поддерживают полноценную бифуркацию до x4/x4/x4/x4, то вам нужен активный райзер, на котором установлен дополнительный чип PCIe коммутатора (моста) и который сам разложит поступившие ему 16 линий на 4 набора по 4 линии, но такие райзеры дороже.
Поэтому нельзя просто так купить и поставить райзер, а надо изучить структуру своей материнской платы, процессора и их совместные возможности, иначе можно очень сильно разочароваться.
1🔥16👍12❤6👌3🥱1
Деградация данных
Деградация данных (bitrot, битовое гниение) – это достаточно актуальный в настоящее время тип разрушения цифровых данных вследствие накопления некритичных ошибок на запоминающем устройстве.
К сожалению, многие коллеги путают деградацию с выходом из строя ячеек накопителя (бед-блоки) и не придают этому вопросу серьезного значения. А зря.
С бед-блоками достаточно эффективно позволяет справляться RAID, когда в случае ошибки чтения блок заменяется резервным, а его содержимое считывается с исправной копии. Да, возможен эффект появления скрытых бед-блоков, но он решается периодическом перечитыванием содержимого массива.
Проблема битового гниения лежит глубже и именно этот термин представляется нам наиболее удачным. Как и обычное гниение он медленно и незаметно повреждает данные до тех пор, пока разрушения не перейдут в критическую фазу.
Причинами битового гниения становятся ошибки в процессе записи, не связанные с повреждением непосредственно ячеек, они могут даже произойти в оперативной памяти и при отсутствии ECC ваши данные также могут быть незаметно повреждены.
Чаще всего деградация данных происходит при длительном хранении, вследствие деградации заряда ячейки или уровня намагниченности сектора. Ошибок чтения с накопителя это не вызывает, но приводит к нарушению целостности данных.
Как правило большинство современных форматов данных имеют избыточность и изменение одного бита может быть откорректировано встроенными средствами, но для этого эти данные нужно хотя бы открыть.
В противном случае подобные ошибки могут накапливаться и в определенный момент привести к невосстановимому повреждению данных. При этом процесс битового гниения не сопровождается ошибками чтения с накопителя и может происходить на полностью исправном диске.
А так как нет никаких ошибок, то и RAID вам ничем не поможет, особенно уровни без четности. Так, например, в случае зеркала у нас могут оказаться изменены биты в произвольных местах обеих копий. И чем больше по размеру файл и реже обращения к нему – тем вероятнее такое развитие событий.
Некоторую защиту могут предоставлять массивы с четностью (RAID 5 и 6), но здесь многое зависит от контроллера или программной реализации, главное у которых – уметь производить такую проверку в фоновом режиме.
В таком случае имея одну правильную копию и целые данные четности массив может проверить целостность данных и автоматически восстановить их.
Но оптимальным решением проблемы будет вынос таких проверок на уровень файловой системы, так как это позволяет действовать наиболее эффективно и с наименьшей нагрузкой на систему.
Современные системы с контролем целостности – это ZFS, btrfs и ReFS – и именно они рекомендуются для систем хранения больших объемов информации. Каждая из них умеет в фоновом режиме проверять целостность файлов и восстанавливать поврежденные фрагменты используя контрольные суммы (при наличии избыточности, разумеется).
И именно по этой причине тот же Proxmox категорически не рекомендует использование mdadm для хранилищ виртуальных машин в производственных средах.
Деградация данных (bitrot, битовое гниение) – это достаточно актуальный в настоящее время тип разрушения цифровых данных вследствие накопления некритичных ошибок на запоминающем устройстве.
К сожалению, многие коллеги путают деградацию с выходом из строя ячеек накопителя (бед-блоки) и не придают этому вопросу серьезного значения. А зря.
С бед-блоками достаточно эффективно позволяет справляться RAID, когда в случае ошибки чтения блок заменяется резервным, а его содержимое считывается с исправной копии. Да, возможен эффект появления скрытых бед-блоков, но он решается периодическом перечитыванием содержимого массива.
Проблема битового гниения лежит глубже и именно этот термин представляется нам наиболее удачным. Как и обычное гниение он медленно и незаметно повреждает данные до тех пор, пока разрушения не перейдут в критическую фазу.
Причинами битового гниения становятся ошибки в процессе записи, не связанные с повреждением непосредственно ячеек, они могут даже произойти в оперативной памяти и при отсутствии ECC ваши данные также могут быть незаметно повреждены.
Чаще всего деградация данных происходит при длительном хранении, вследствие деградации заряда ячейки или уровня намагниченности сектора. Ошибок чтения с накопителя это не вызывает, но приводит к нарушению целостности данных.
Как правило большинство современных форматов данных имеют избыточность и изменение одного бита может быть откорректировано встроенными средствами, но для этого эти данные нужно хотя бы открыть.
В противном случае подобные ошибки могут накапливаться и в определенный момент привести к невосстановимому повреждению данных. При этом процесс битового гниения не сопровождается ошибками чтения с накопителя и может происходить на полностью исправном диске.
А так как нет никаких ошибок, то и RAID вам ничем не поможет, особенно уровни без четности. Так, например, в случае зеркала у нас могут оказаться изменены биты в произвольных местах обеих копий. И чем больше по размеру файл и реже обращения к нему – тем вероятнее такое развитие событий.
Некоторую защиту могут предоставлять массивы с четностью (RAID 5 и 6), но здесь многое зависит от контроллера или программной реализации, главное у которых – уметь производить такую проверку в фоновом режиме.
В таком случае имея одну правильную копию и целые данные четности массив может проверить целостность данных и автоматически восстановить их.
Но оптимальным решением проблемы будет вынос таких проверок на уровень файловой системы, так как это позволяет действовать наиболее эффективно и с наименьшей нагрузкой на систему.
Современные системы с контролем целостности – это ZFS, btrfs и ReFS – и именно они рекомендуются для систем хранения больших объемов информации. Каждая из них умеет в фоновом режиме проверять целостность файлов и восстанавливать поврежденные фрагменты используя контрольные суммы (при наличии избыточности, разумеется).
И именно по этой причине тот же Proxmox категорически не рекомендует использование mdadm для хранилищ виртуальных машин в производственных средах.
3👍13
Почему доступ в интернет по белым спискам это плохая идея
Каждый раз, когда обсуждается вопрос ограничения доступа в интернет поднимается тема белых списков. Казалось бы, что там сложного? Запретил все и разрешил нужное, теперь можно спать спокойно.
Сделать это можно несколькими способами. При помощи списков адресов, когда адрес назначения сравнивается с заранее составленным списком и либо разрешается, либо блокируется. Пример такой настройки на оборудовании Mikrotik вы можете найти в статье:
🔹 Настройка черного и белого списков в роутерах Mikrotik
Второй вариант – это настройка собственного фильтрующего DNS-сервера. Принцип работы его схож с первым методом, но производится на уровне DNS-запросов, еще до того, как браузер попытается открыть страницу.
Для разрешенных доменов имя исправно разрешается в IP-адрес, для всех иных сервер отвечает, что такого домена не существует. Более подробно это описано в статье:
🔹 Создаем собственный фильтрующий DNS-сервер на базе Pi-hole
Но если попытаться реализовать указанными способами белый список, то вам придется столкнуться с многими сложностями.
Дело в том, что современный сайт – это технически сложный программный продукт и далеко не все его компоненты расположены на одном с ним домене.
Первая сложность настигнет вас буквально сразу, браузер не сможет проверить сертификат. Почему? Потому что ему нужен доступ с CRL (списку отозванных сертификатов), адрес которого указан в сертификате.
Его нужно выяснить и добавить в белый список. Причем таких адресов может быть несколько и для следующего сайта с сертификатом этого же УЦ адрес может быть иным.
Ок, с сертификатами разобрались, но почему вместо сайта белая страница? Или он очень долго загружается?
Потому что для нормального функционирования ему нужно подгрузить скрипты, находящиеся на сторонних адресах. Снова включаем отладку, выясняем эти адреса и добавляем их в белый список.
Для чего так делается? По нескольким причинам. Основная – скорость доставки, скрипты расположенные на CDN доставляются пользователю одинаково быстро в любой точке мира, не загружают канал сайта и не оказывают нагрузки на сервер.
Вторая – это поддержание актуальных версий скриптов используя общедоступные репозитории, где они будут автоматически обновляться в пределах текущей версии при обнаружении багов или уязвимостей.
Ладно, нашли эти адреса и добавили. Но что это? Почему он так выглядит? Что это за кошмар?
Все просто, со сторонних ресурсов также подтягиваются шрифты и элементы оформления. И что? И снова ищем откуда и снова добавляем, добавляем, добавляем…
Нет картинок и мультимедийного содержимого? Снова ищем с каких CDN они распространяются, а их может быть и не один адрес. Т.е. сегодня все показывает нормально, а завтра в коде страницы другой CDN и снова начинайте сначала.
Ну вроде победили… Но радоваться рано. Пробуем войти на сайт и ничего не работает. Потому что вход реализован через сторонние сервисы вроде ЕСИА, соцсетей, Яндекса и т.д.
Потом на сайте могут не работать некоторые функции, все по той же причине подгрузки скриптов со стороны, скажем оплата.
И таких проблем может быть очень много и не все из них всплывут сразу. Поэтому заниматься подобной ерундой не имеет никакого практического смысла. В реальности достаточно заблокировать десяток сайтов – пожирателей времени, если вопрос именно в этом.
Единственный вариант, когда белый список оправдан, это когда криво работающий сайт будет наименьшим злом, по сравнению с открывшимся сторонним. Такой подход актуален, например, в образовании, где если проверка откроет не тот сайт, то проблем не избежать.
В остальном будьте благоразумны и ищите адекватные решения для поставленных задач.
Каждый раз, когда обсуждается вопрос ограничения доступа в интернет поднимается тема белых списков. Казалось бы, что там сложного? Запретил все и разрешил нужное, теперь можно спать спокойно.
Сделать это можно несколькими способами. При помощи списков адресов, когда адрес назначения сравнивается с заранее составленным списком и либо разрешается, либо блокируется. Пример такой настройки на оборудовании Mikrotik вы можете найти в статье:
🔹 Настройка черного и белого списков в роутерах Mikrotik
Второй вариант – это настройка собственного фильтрующего DNS-сервера. Принцип работы его схож с первым методом, но производится на уровне DNS-запросов, еще до того, как браузер попытается открыть страницу.
Для разрешенных доменов имя исправно разрешается в IP-адрес, для всех иных сервер отвечает, что такого домена не существует. Более подробно это описано в статье:
🔹 Создаем собственный фильтрующий DNS-сервер на базе Pi-hole
Но если попытаться реализовать указанными способами белый список, то вам придется столкнуться с многими сложностями.
Дело в том, что современный сайт – это технически сложный программный продукт и далеко не все его компоненты расположены на одном с ним домене.
Первая сложность настигнет вас буквально сразу, браузер не сможет проверить сертификат. Почему? Потому что ему нужен доступ с CRL (списку отозванных сертификатов), адрес которого указан в сертификате.
Его нужно выяснить и добавить в белый список. Причем таких адресов может быть несколько и для следующего сайта с сертификатом этого же УЦ адрес может быть иным.
Ок, с сертификатами разобрались, но почему вместо сайта белая страница? Или он очень долго загружается?
Потому что для нормального функционирования ему нужно подгрузить скрипты, находящиеся на сторонних адресах. Снова включаем отладку, выясняем эти адреса и добавляем их в белый список.
Для чего так делается? По нескольким причинам. Основная – скорость доставки, скрипты расположенные на CDN доставляются пользователю одинаково быстро в любой точке мира, не загружают канал сайта и не оказывают нагрузки на сервер.
Вторая – это поддержание актуальных версий скриптов используя общедоступные репозитории, где они будут автоматически обновляться в пределах текущей версии при обнаружении багов или уязвимостей.
Ладно, нашли эти адреса и добавили. Но что это? Почему он так выглядит? Что это за кошмар?
Все просто, со сторонних ресурсов также подтягиваются шрифты и элементы оформления. И что? И снова ищем откуда и снова добавляем, добавляем, добавляем…
Нет картинок и мультимедийного содержимого? Снова ищем с каких CDN они распространяются, а их может быть и не один адрес. Т.е. сегодня все показывает нормально, а завтра в коде страницы другой CDN и снова начинайте сначала.
Ну вроде победили… Но радоваться рано. Пробуем войти на сайт и ничего не работает. Потому что вход реализован через сторонние сервисы вроде ЕСИА, соцсетей, Яндекса и т.д.
Потом на сайте могут не работать некоторые функции, все по той же причине подгрузки скриптов со стороны, скажем оплата.
И таких проблем может быть очень много и не все из них всплывут сразу. Поэтому заниматься подобной ерундой не имеет никакого практического смысла. В реальности достаточно заблокировать десяток сайтов – пожирателей времени, если вопрос именно в этом.
Единственный вариант, когда белый список оправдан, это когда криво работающий сайт будет наименьшим злом, по сравнению с открывшимся сторонним. Такой подход актуален, например, в образовании, где если проверка откроет не тот сайт, то проблем не избежать.
В остальном будьте благоразумны и ищите адекватные решения для поставленных задач.
💯14👍11❤1🥱1