Что такое хорошо и что такое плохо
В админской среде всегда любили и любят всякое нестандартное, возводя это в достоинство и формируя мнение, что любой админ должен уметь нечто такое, что недоступно остальным и позволит выкрутиться из любой ситуации.
В итоге очень и очень многие решения идут вопреки стандартным практикам и фактически представляют из себя костыли и изоленту.
Кто-то виртуозно владеет скриптами, кто-то выучил справочник твиков реестра и т.д. и т.п. И считается что это хорошо.
Нет, знания и умения – это однозначно хорошо, но, когда они идут в разрез с общепринятыми практиками – это плохо.
Попытка решить стандартные вопросы нестандартными средствами – это плохо. И никакие оправдания тут не могут быть уместны.
Исключения – это специфические системы, например, высоконагруженные, но там админы прекрасно понимают, что делают и там у них есть свои стандартные практики, которые всем остальным просто не нужны.
Попытки применять нестандартные средства говорят только об одном – администратор не владеет базовыми навыками администрирования системы, подменяя их собственными костылями.
Столь же плохо применение в системах общего назначения каких-то специализированных практик, какими бы они «крутыми» и «навороченными» не казались.
Мы не раз сталкивались с нестандартными настройками и твиками, которые вызывали сложности на ровном месте. А когда начинали выяснять что это и зачем, то могли услышать примерно следующее:
- Ну это крутые пацаны из High Load рекомендуют?
- А у тебя высокая нагрузка?
- Нет, но…
Или:
- Ну это защита от сетевых атак…
- Тебя кто-то атакует?
- Нет, но…
Все это, конечно, может выглядеть круто, но, по сути, это не дает никаких плюсов, а только сплошные минусы.
Подобные настройки могут вызывать потенциальные конфликты, приводить к сложностям в поддержке или администрировании и даже стать причиной отказов, если незнакомый с ними администратор применит настройки, явно приводящие к конфликту.
Поэтому если у вас самая обычная система, которая не испытывает высоких нагрузок и которую никто не атакует, то и настройки в ней должны быть самые стандартные, сделанные стандартными для этой системы механизмами.
И именно это будет хорошо и правильно. Потому что позволит любому знакомому с системой специалисту быстро разобраться в ней и продолжить поддержку в отсутствие ее основного «архитектора».
И все порывы сделать «лучше», «быстрее», «дешевле» и т.п. нестандартными методами должны жестко пресекаться, как контролем, так и самоконтролем.
Потому что все эти костыли и изолента имеют свойство выстреливать в самый неподходящий момент. И делать это достаточно больно.
Здесь я еще раз напомню, что платят нам не за наши пируэты и изыски, тот кто платит – он и слов таких не знает. А платят нам за стабильную и предсказуемую работу.
Если вы вчера сэкономили нестандартным решением десять тысяч рублей, а сегодня, во время вашего отпуска все это упало и разбирались с вашими художествами несколько часов, понеся убытки на сотни тысяч, то ваши мотивы никто из лиц принимающих решения просто не поймет. Со всеми вытекающими оргвыводами.
Поэтому, подводя итоги, можно сказать, что следовать стандартным практикам, даже если они не совсем оптимальны – это хорошо. А городить собственные нестандартные решения – плохо.
При этом мы не хотим сказать, что нестандартные решения не имеют права на существование. Иногда без них никак. Но при этом они должны быть именно нестандартными и становиться личным стандартом де факто.
Но даже применяя нестандартные решения нужно стараться максимально их стандартизовать: использовать стандартные пути размещения файлов, понятные наименования скриптов и переменных в них. Т.е. сделать работу с ними максимально понятной третьему лицу, который увидит это в первый раз.
Ну и конечно не забыть все это документировать. И часть документации будет совсем не лишним разместить прямо здесь, лучше всего в комментариях к скрипту или в виде файла где-то рядом.
В админской среде всегда любили и любят всякое нестандартное, возводя это в достоинство и формируя мнение, что любой админ должен уметь нечто такое, что недоступно остальным и позволит выкрутиться из любой ситуации.
В итоге очень и очень многие решения идут вопреки стандартным практикам и фактически представляют из себя костыли и изоленту.
Кто-то виртуозно владеет скриптами, кто-то выучил справочник твиков реестра и т.д. и т.п. И считается что это хорошо.
Нет, знания и умения – это однозначно хорошо, но, когда они идут в разрез с общепринятыми практиками – это плохо.
Попытка решить стандартные вопросы нестандартными средствами – это плохо. И никакие оправдания тут не могут быть уместны.
Исключения – это специфические системы, например, высоконагруженные, но там админы прекрасно понимают, что делают и там у них есть свои стандартные практики, которые всем остальным просто не нужны.
Попытки применять нестандартные средства говорят только об одном – администратор не владеет базовыми навыками администрирования системы, подменяя их собственными костылями.
Столь же плохо применение в системах общего назначения каких-то специализированных практик, какими бы они «крутыми» и «навороченными» не казались.
Мы не раз сталкивались с нестандартными настройками и твиками, которые вызывали сложности на ровном месте. А когда начинали выяснять что это и зачем, то могли услышать примерно следующее:
- Ну это крутые пацаны из High Load рекомендуют?
- А у тебя высокая нагрузка?
- Нет, но…
Или:
- Ну это защита от сетевых атак…
- Тебя кто-то атакует?
- Нет, но…
Все это, конечно, может выглядеть круто, но, по сути, это не дает никаких плюсов, а только сплошные минусы.
Подобные настройки могут вызывать потенциальные конфликты, приводить к сложностям в поддержке или администрировании и даже стать причиной отказов, если незнакомый с ними администратор применит настройки, явно приводящие к конфликту.
Поэтому если у вас самая обычная система, которая не испытывает высоких нагрузок и которую никто не атакует, то и настройки в ней должны быть самые стандартные, сделанные стандартными для этой системы механизмами.
И именно это будет хорошо и правильно. Потому что позволит любому знакомому с системой специалисту быстро разобраться в ней и продолжить поддержку в отсутствие ее основного «архитектора».
И все порывы сделать «лучше», «быстрее», «дешевле» и т.п. нестандартными методами должны жестко пресекаться, как контролем, так и самоконтролем.
Потому что все эти костыли и изолента имеют свойство выстреливать в самый неподходящий момент. И делать это достаточно больно.
Здесь я еще раз напомню, что платят нам не за наши пируэты и изыски, тот кто платит – он и слов таких не знает. А платят нам за стабильную и предсказуемую работу.
Если вы вчера сэкономили нестандартным решением десять тысяч рублей, а сегодня, во время вашего отпуска все это упало и разбирались с вашими художествами несколько часов, понеся убытки на сотни тысяч, то ваши мотивы никто из лиц принимающих решения просто не поймет. Со всеми вытекающими оргвыводами.
Поэтому, подводя итоги, можно сказать, что следовать стандартным практикам, даже если они не совсем оптимальны – это хорошо. А городить собственные нестандартные решения – плохо.
При этом мы не хотим сказать, что нестандартные решения не имеют права на существование. Иногда без них никак. Но при этом они должны быть именно нестандартными и становиться личным стандартом де факто.
Но даже применяя нестандартные решения нужно стараться максимально их стандартизовать: использовать стандартные пути размещения файлов, понятные наименования скриптов и переменных в них. Т.е. сделать работу с ними максимально понятной третьему лицу, который увидит это в первый раз.
Ну и конечно не забыть все это документировать. И часть документации будет совсем не лишним разместить прямо здесь, лучше всего в комментариях к скрипту или в виде файла где-то рядом.
Настраиваем веб-сервер Angie + PHP + MySQL с сертификатами Let's Encrypt и поддержкой HTTP/3
Angie - форк известного веб-сервера nginx, созданный его бывшими разработчиками и преследующий цель стать лучшим nginx чем сам nginx и это не преувеличение.
Начавшись как обычный проект импортозамещения Angie сегодня не только предоставляет все возможности nginx, но и предоставляет ряд новых функций и возможностей.
А для пользователей, которым просто нужен веб-сервер Angie может предложить достаточно большой выбор готовых модулей в репозитории, это очень важное преимущество, так как в nginx для добавления тех или иных модулей вам потребуется самостоятельно пересобрать продукт.
https://interface31.ru/tech_it/2025/05/nastraivaem-web-server-angie-php-mysql-lets-encrypt-http3.html
Angie - форк известного веб-сервера nginx, созданный его бывшими разработчиками и преследующий цель стать лучшим nginx чем сам nginx и это не преувеличение.
Начавшись как обычный проект импортозамещения Angie сегодня не только предоставляет все возможности nginx, но и предоставляет ряд новых функций и возможностей.
А для пользователей, которым просто нужен веб-сервер Angie может предложить достаточно большой выбор готовых модулей в репозитории, это очень важное преимущество, так как в nginx для добавления тех или иных модулей вам потребуется самостоятельно пересобрать продукт.
https://interface31.ru/tech_it/2025/05/nastraivaem-web-server-angie-php-mysql-lets-encrypt-http3.html
Вектор развития
В комментариях развернулась активная дискуссия на тему развития сотрудника и развития инфраструктуры предприятия. Многие ставят между этими понятиями знак равенства, хотя это совсем не так.
Мы уже много раз писали на эту тему, поэтому не будем повторяться, но акцентируем внимание на ключевых тезисах. Сотрудник <> Бизнес (как бы иногда бизнесу и не хотелось продвинуть иную мысль).
Бизнес занимается зарабатыванием денег, в чем его основной интерес. Сотрудник продает свое время и квалификацию за деньги – и никак иначе. А как по-другому? Бизнес его содержать в случае чего будет? Ага, держите карман шире.
Поэтому интересы у сотрудника и бизнеса разные, в чем-то они совпадают, в чем-то расходятся. И это нормально. Не нормально, когда одна из сторон начинает путать собственные интересы с интересами контрагента, ни к чему хорошему это не приводит.
Начнем с интересов бизнеса. Основной интерес- это получение прибыли. Прибыль – основа стабильной работы и развития предприятия. Падение прибыли приводит к экономии, в том числи и на ФОТ, сокращению рабочих мест и т.д. и т.п.
В этом плане интересы сотрудника и бизнеса совпадают, сотрудник также заинтересован в нормальном функционировании бизнеса, иначе он потеряет в деньгах и, возможно, лишится рабочего места.
Бизнес также заинтересован в удержании сотрудников, особенно тех, кого нельзя просто заменить с улицы. Но этот момент нужно понимать правильно, бизнес – не благотворительность. Если на линейную должность на улице стоит очередь – то и оклад там будет по нижней планке и выжимать будут все соки.
А вот если это ключевой квалифицированный сотрудник, на которого завязаны многие важные бизнес-процессы, то подход будет совершенно иной. Потому что у бизнеса здесь прямой интерес, совпадающий с интересом сотрудника.
Но вернемся к нашим баранам. IT – это такая сфера, которая никогда не стоит на месте и если мы хотим быть актуальными на рынке труда – то нужно постоянно развиваться. Никому не нужен сотрудник или подрядчик, который владеет технологиями десятилетней давности, пусть даже и в совершенстве.
Поэтому интерес сотрудника развиваться вполне естественен и понятен. И еще ему хочется совместить приятное с полезным, а именно развиваться в рамках собственного предприятия за его счет и на его ресурсах.
Но нужно ли это бизнесу? Есть заблуждение, что если бизнес не внедряет современные технологии, то он не развивается (в плане информационной инфраструктуры), но это не так. Бизнес тоже может развивать свою IT-инфраструктуру, только совсем не туда, куда смотрит сотрудник.
Вместо современных технологий может внедрятся отказоустойчивость, кластеризация и прочие сложные и специфичные вещи, которые сотруднику не интересны. Ну не видит он куда их можно применить за воротами именно этого работодателя и кому продать их на рынке труда.
А бизнесу, в свою очередь, не нужны все эти модные докеры, куберы и прочие современные технологии, у него другие задачи и потребности.
В результате возникает расхождение интересов, вектор развития предприятия не совпадает с вектором развития сотрудника и это нормально.
Для примера возьмем известную сеть Красное и Белое, информационная система у них до сих пор построена на устаревшей платформе 1С:Предприятие 7.7. Можно ли при этом сказать, что инфраструктура компании не развивается?
Нет, нельзя, потому что они развиваются, внедряют современные технологии, ту же маркировку и прочее. Т.е. движутся собственным курсом к собственным целям и достаточно успешно.
Но это курс бизнеса, который не совпадает с курсом сотрудника. Кому нужен в 2025 году специалист по «клюшкам» (жаргонное название 1Сv77)? Никому. Да, отнесутся с уважением, мол «монстр», но не более, на рынке труда спроса на таких специалистов нет.
Какой выбор у сотрудника? А выбор невелик, либо связать свою карьеру именно с этой компанией и развиваться в общем направлении, понимая, что за забором перспектив нет, или начать движение по собственному вектору, приобретая знания и навыки, востребованные современным рынком.
В комментариях развернулась активная дискуссия на тему развития сотрудника и развития инфраструктуры предприятия. Многие ставят между этими понятиями знак равенства, хотя это совсем не так.
Мы уже много раз писали на эту тему, поэтому не будем повторяться, но акцентируем внимание на ключевых тезисах. Сотрудник <> Бизнес (как бы иногда бизнесу и не хотелось продвинуть иную мысль).
Бизнес занимается зарабатыванием денег, в чем его основной интерес. Сотрудник продает свое время и квалификацию за деньги – и никак иначе. А как по-другому? Бизнес его содержать в случае чего будет? Ага, держите карман шире.
Поэтому интересы у сотрудника и бизнеса разные, в чем-то они совпадают, в чем-то расходятся. И это нормально. Не нормально, когда одна из сторон начинает путать собственные интересы с интересами контрагента, ни к чему хорошему это не приводит.
Начнем с интересов бизнеса. Основной интерес- это получение прибыли. Прибыль – основа стабильной работы и развития предприятия. Падение прибыли приводит к экономии, в том числи и на ФОТ, сокращению рабочих мест и т.д. и т.п.
В этом плане интересы сотрудника и бизнеса совпадают, сотрудник также заинтересован в нормальном функционировании бизнеса, иначе он потеряет в деньгах и, возможно, лишится рабочего места.
Бизнес также заинтересован в удержании сотрудников, особенно тех, кого нельзя просто заменить с улицы. Но этот момент нужно понимать правильно, бизнес – не благотворительность. Если на линейную должность на улице стоит очередь – то и оклад там будет по нижней планке и выжимать будут все соки.
А вот если это ключевой квалифицированный сотрудник, на которого завязаны многие важные бизнес-процессы, то подход будет совершенно иной. Потому что у бизнеса здесь прямой интерес, совпадающий с интересом сотрудника.
Но вернемся к нашим баранам. IT – это такая сфера, которая никогда не стоит на месте и если мы хотим быть актуальными на рынке труда – то нужно постоянно развиваться. Никому не нужен сотрудник или подрядчик, который владеет технологиями десятилетней давности, пусть даже и в совершенстве.
Поэтому интерес сотрудника развиваться вполне естественен и понятен. И еще ему хочется совместить приятное с полезным, а именно развиваться в рамках собственного предприятия за его счет и на его ресурсах.
Но нужно ли это бизнесу? Есть заблуждение, что если бизнес не внедряет современные технологии, то он не развивается (в плане информационной инфраструктуры), но это не так. Бизнес тоже может развивать свою IT-инфраструктуру, только совсем не туда, куда смотрит сотрудник.
Вместо современных технологий может внедрятся отказоустойчивость, кластеризация и прочие сложные и специфичные вещи, которые сотруднику не интересны. Ну не видит он куда их можно применить за воротами именно этого работодателя и кому продать их на рынке труда.
А бизнесу, в свою очередь, не нужны все эти модные докеры, куберы и прочие современные технологии, у него другие задачи и потребности.
В результате возникает расхождение интересов, вектор развития предприятия не совпадает с вектором развития сотрудника и это нормально.
Для примера возьмем известную сеть Красное и Белое, информационная система у них до сих пор построена на устаревшей платформе 1С:Предприятие 7.7. Можно ли при этом сказать, что инфраструктура компании не развивается?
Нет, нельзя, потому что они развиваются, внедряют современные технологии, ту же маркировку и прочее. Т.е. движутся собственным курсом к собственным целям и достаточно успешно.
Но это курс бизнеса, который не совпадает с курсом сотрудника. Кому нужен в 2025 году специалист по «клюшкам» (жаргонное название 1Сv77)? Никому. Да, отнесутся с уважением, мол «монстр», но не более, на рынке труда спроса на таких специалистов нет.
Какой выбор у сотрудника? А выбор невелик, либо связать свою карьеру именно с этой компанией и развиваться в общем направлении, понимая, что за забором перспектив нет, или начать движение по собственному вектору, приобретая знания и навыки, востребованные современным рынком.
Что такое QUIC и HTTP/3
Вчера, в новой статье мы рассказали, как включить поддержку QUIC и HTTP/3 в веб-сервере Angie. Но далеко не все знают для чего и зачем это нужно.
Начнем с того, что обычный HTTP давно уже перестал быть текстовым протоколом и передает самые различные данные и количество их от день ото дня растет.
Современный сайт – это не просто страничка с текстом и картинками, а полноценное веб-приложение. И протокол TCP начал играть сдерживающую роль. Как мы все знаем, TCP – протокол с подтверждением доставки, если этого не случилось, то он будет посылать данные повторно.
Ну это же не плохо? А это как посмотреть. Если к качеству связи нет претензий, то все работает хорошо, а если нет, то начинаются проблемы. Все данные прикладных протоколов, работающих поверх TCP, разбиваются на сегменты и помещаются в буфер отправки.
Если сегмент доставлен получателю, то он удаляется из буфера и уступает место другому, если же нет, то он отправляется повторно. Таким образом мы можем получить ситуацию, когда сервер многократно отправляет одни и те же сегменты блокируя тем самым отправку других. Это называется проблемой блокировки очереди.
Изначально, протокол HTTP и вовсе подразумевал отдельное соединение для каждого запроса, т.е. если на страничке есть десяток картинок, скриптов, стилей и иных элементов, то на каждое из них открывалось отдельное TCP-соединение.
Это серьезно снижало производительность протокола, так как значительное время и ресурсы тратились на установление соединения, а не передачу данных. С шифрования ситуация стала еще хуже, так как добавились накладные расходы на согласование параметров шифрования и установление защищенного соединения.
Многие эти проблемы были решены компанией Google в протоколе SPDY на базе которого впоследствии был создан HTTP/2. Хотя стандарт и не подразумевает обязательного шифрования фактическое использование HTTP/2 возможно только поверх TLS (TLS 1.2 и выше).
В новом протоколе были решены многие проблемы производительности, в частности введена конвейеризация запросов и мультиплексирование их в одно TCP-соединение, это позволило значительно сократить накладные расходы и увеличить скорость работы протокола.
Но проблема блокировки начала очереди никуда не делась и решить эту проблему можно было только сменой протокола транспортного уровня.
И тут снова подсуетилась компания Google, разработав новый протокол QUIC, который использует в качестве транспорта UDP. Так как UDP не гарантирует доставку, то никакой блокировки начала очереди не может быть в принципе.
Также UDP использует простую модель передачи без установления соединения, что также положительно влияет на производительность. При этом вопросы целостности данных и контроля доставки берет на себя протокол QUIC.
Также QUIC сразу интегрирован с криптографией и требует для своей работы не ниже TLS 1.3. Также QUIC умеет повторно использовать текущее соединение даже при переподключении клиента на другой канал связи, что важно для мобильных пользователей.
Точно также, как и в случае с HTTP/2 протокол QUIC лег в основу HTTP/3 и начинает постепенное распространение в сети интернет. Это не значит, что нужно прямо сейчас бежать добавлять поддержку HTTP/3 рабочим серверам. Но на новых установках при наличии возможности включить поддержку HTTP/3 это сделать желательно.
Вчера, в новой статье мы рассказали, как включить поддержку QUIC и HTTP/3 в веб-сервере Angie. Но далеко не все знают для чего и зачем это нужно.
Начнем с того, что обычный HTTP давно уже перестал быть текстовым протоколом и передает самые различные данные и количество их от день ото дня растет.
Современный сайт – это не просто страничка с текстом и картинками, а полноценное веб-приложение. И протокол TCP начал играть сдерживающую роль. Как мы все знаем, TCP – протокол с подтверждением доставки, если этого не случилось, то он будет посылать данные повторно.
Ну это же не плохо? А это как посмотреть. Если к качеству связи нет претензий, то все работает хорошо, а если нет, то начинаются проблемы. Все данные прикладных протоколов, работающих поверх TCP, разбиваются на сегменты и помещаются в буфер отправки.
Если сегмент доставлен получателю, то он удаляется из буфера и уступает место другому, если же нет, то он отправляется повторно. Таким образом мы можем получить ситуацию, когда сервер многократно отправляет одни и те же сегменты блокируя тем самым отправку других. Это называется проблемой блокировки очереди.
Изначально, протокол HTTP и вовсе подразумевал отдельное соединение для каждого запроса, т.е. если на страничке есть десяток картинок, скриптов, стилей и иных элементов, то на каждое из них открывалось отдельное TCP-соединение.
Это серьезно снижало производительность протокола, так как значительное время и ресурсы тратились на установление соединения, а не передачу данных. С шифрования ситуация стала еще хуже, так как добавились накладные расходы на согласование параметров шифрования и установление защищенного соединения.
Многие эти проблемы были решены компанией Google в протоколе SPDY на базе которого впоследствии был создан HTTP/2. Хотя стандарт и не подразумевает обязательного шифрования фактическое использование HTTP/2 возможно только поверх TLS (TLS 1.2 и выше).
В новом протоколе были решены многие проблемы производительности, в частности введена конвейеризация запросов и мультиплексирование их в одно TCP-соединение, это позволило значительно сократить накладные расходы и увеличить скорость работы протокола.
Но проблема блокировки начала очереди никуда не делась и решить эту проблему можно было только сменой протокола транспортного уровня.
И тут снова подсуетилась компания Google, разработав новый протокол QUIC, который использует в качестве транспорта UDP. Так как UDP не гарантирует доставку, то никакой блокировки начала очереди не может быть в принципе.
Также UDP использует простую модель передачи без установления соединения, что также положительно влияет на производительность. При этом вопросы целостности данных и контроля доставки берет на себя протокол QUIC.
Также QUIC сразу интегрирован с криптографией и требует для своей работы не ниже TLS 1.3. Также QUIC умеет повторно использовать текущее соединение даже при переподключении клиента на другой канал связи, что важно для мобильных пользователей.
Точно также, как и в случае с HTTP/2 протокол QUIC лег в основу HTTP/3 и начинает постепенное распространение в сети интернет. Это не значит, что нужно прямо сейчас бежать добавлять поддержку HTTP/3 рабочим серверам. Но на новых установках при наличии возможности включить поддержку HTTP/3 это сделать желательно.
Хардлинки и симлинки, любой Linux-админ знает о них с детства. А как насчет Windows? Там тоже все это есть. Берем и используем!
https://interface31.ru/tech_it/2022/05/rabotaem-s-zhestkimi-i-simvolicheskimi-ssylkami-v-windows.html
https://interface31.ru/tech_it/2022/05/rabotaem-s-zhestkimi-i-simvolicheskimi-ssylkami-v-windows.html
Записки IT специалиста
Работаем с жесткими и символическими ссылками в Windows
Жесткие и символические ссылки давно знакомы и активно используются Linux-администраторами, в то время как их Windows коллеги используют их гораздо реже, а некоторые вообще не знают о такой возможности. Тем не менее такая возможность в Windows существует…
Замена сбойного диска в массивах ZFS
ZFS все чаще применяется в системах хранения Linux благодаря своим широким возможностям и отличной надежности.
Но очень часто пользователи не имеют практических навыков работы с этой файловой системой, отдавая работу с ней на откуп вышестоящим системам, например, системе виртуализации Proxmox.
Первые сложности начинаются когда пользователь сталкивается с необходимостью обслуживания ZFS и не находит для этого графических инструментов.
Одна из таких задач - это замена сбойного диска в массиве, задача серьезная и ответственная, но в тоже время простая. В этой статье мы расскажем как это сделать.
https://interface31.ru/tech_it/2024/08/zamena-sboynogo-diska-v-massivah-zfs.html
ZFS все чаще применяется в системах хранения Linux благодаря своим широким возможностям и отличной надежности.
Но очень часто пользователи не имеют практических навыков работы с этой файловой системой, отдавая работу с ней на откуп вышестоящим системам, например, системе виртуализации Proxmox.
Первые сложности начинаются когда пользователь сталкивается с необходимостью обслуживания ZFS и не находит для этого графических инструментов.
Одна из таких задач - это замена сбойного диска в массиве, задача серьезная и ответственная, но в тоже время простая. В этой статье мы расскажем как это сделать.
https://interface31.ru/tech_it/2024/08/zamena-sboynogo-diska-v-massivah-zfs.html
Проверять нужно не только бекапы
Третьего дня с одним нашим заказчиком произошла поучительная история. Обособленное подразделение в области. Классическая схема Proxmox VE + Proxmox Backup Server, связка, проверенная временем, ну что может пойти не так?
Оказывается, очень даже может. Местный коллега все проверил, настроил уведомления на почту, убедился, что бекап делается корректно и разворачивается без ошибок, после чего со спокойной совестью занялся другими делами.
А дальше все пошло не так. Бухгалтер, групповой обработкой сделала не совсем то, точнее совсем не то и восстанавливать руками весь второй квартал (полтора месяца) ей как-то не хотелось, поэтому она попросила админа достать базу из резервной копии, тем более что копии бухгалтерии делались каждые два часа.
Какое же было удивление, когда наш коллега обнаружил, что последняя копия была создана вечером 14 мая. Как так? Почему? Где уведомления? Вопросов было больше, чем ответов.
Причину нашли быстро, система после очередного копирования не удалила снимок и дальнейшее резервное копирование стало невозможно. Почему не удалила? В тот день отключали электричество, а бесперебойник не вытянул.
Тут все понятно, бывает. Основной вопрос, который волновал как нас, так и нашего коллегу – почему не было уведомлений. Хотя в этом случае Proxmox должен регулярно сообщать о неудачном резервном копировании.
Ответ на него нашелся быстро – все письма лежали в папке Спам Яндекс Почты.
Причин тому может быть множество, соверменные почтовые системы используют самые различные алгоритмы. Но есть и «отягчающие обстоятельства». Офис расположен на первом этаже обычного жилого дома, и провайдер подключил интернет как «на квартиру», по тарифам для физических лиц.
Выгодно? Да. Но есть и подводные камни, IP-адрес в таком случае тоже присваивается из пула для физических лиц, а все такие пулы по умолчанию стоят в черных списках, так как по негласной договоренности в таких сетях почтовых серверов быть не должно.
Плюс почтовый сервер у нас тоже не настоящий, ни обратной зоны, ни ресурсных записей. А тут еще и адрес из домашнего пула. Вот Яндекс и не стал морочиться, отправив все сообщения в Спам. А они, как и положено, старательно отсылались.
Коллега получил неприятный разговор с руководством, а бухгалтер сидит и думает, что ей проще: исправить документы с начала квартала или заново вбить все с 14 числа.
Поэтому проверять надо не только бекапы, но и уведомления, триггеры и все с этим связанное. А также не забывать про регулярное изучение папки Спам и стараться использовать более одного канала оповещения.
Третьего дня с одним нашим заказчиком произошла поучительная история. Обособленное подразделение в области. Классическая схема Proxmox VE + Proxmox Backup Server, связка, проверенная временем, ну что может пойти не так?
Оказывается, очень даже может. Местный коллега все проверил, настроил уведомления на почту, убедился, что бекап делается корректно и разворачивается без ошибок, после чего со спокойной совестью занялся другими делами.
А дальше все пошло не так. Бухгалтер, групповой обработкой сделала не совсем то, точнее совсем не то и восстанавливать руками весь второй квартал (полтора месяца) ей как-то не хотелось, поэтому она попросила админа достать базу из резервной копии, тем более что копии бухгалтерии делались каждые два часа.
Какое же было удивление, когда наш коллега обнаружил, что последняя копия была создана вечером 14 мая. Как так? Почему? Где уведомления? Вопросов было больше, чем ответов.
Причину нашли быстро, система после очередного копирования не удалила снимок и дальнейшее резервное копирование стало невозможно. Почему не удалила? В тот день отключали электричество, а бесперебойник не вытянул.
Тут все понятно, бывает. Основной вопрос, который волновал как нас, так и нашего коллегу – почему не было уведомлений. Хотя в этом случае Proxmox должен регулярно сообщать о неудачном резервном копировании.
Ответ на него нашелся быстро – все письма лежали в папке Спам Яндекс Почты.
Причин тому может быть множество, соверменные почтовые системы используют самые различные алгоритмы. Но есть и «отягчающие обстоятельства». Офис расположен на первом этаже обычного жилого дома, и провайдер подключил интернет как «на квартиру», по тарифам для физических лиц.
Выгодно? Да. Но есть и подводные камни, IP-адрес в таком случае тоже присваивается из пула для физических лиц, а все такие пулы по умолчанию стоят в черных списках, так как по негласной договоренности в таких сетях почтовых серверов быть не должно.
Плюс почтовый сервер у нас тоже не настоящий, ни обратной зоны, ни ресурсных записей. А тут еще и адрес из домашнего пула. Вот Яндекс и не стал морочиться, отправив все сообщения в Спам. А они, как и положено, старательно отсылались.
Коллега получил неприятный разговор с руководством, а бухгалтер сидит и думает, что ей проще: исправить документы с начала квартала или заново вбить все с 14 числа.
Поэтому проверять надо не только бекапы, но и уведомления, триггеры и все с этим связанное. А также не забывать про регулярное изучение папки Спам и стараться использовать более одного канала оповещения.
Допустимые типы контента для хранилищ Proxmox
Собрали в небольшую, но полезную таблицу допустимые типы контента для разных типов хранилищ.
С ее помощью можно быстро оценить какой тип хранилища лучшим образом подходит для ваших задач.
Вся информация взята из официальных источников.
Поводом для создания подобной таблички послужили злоключения молодого коллеги, который потратил время на установку и настройку iSCSI-таргета, но только подключив его к Proxmox обнаружил, что оно не поддерживает LXC-контейнеры. 🤷♀️
Собрали в небольшую, но полезную таблицу допустимые типы контента для разных типов хранилищ.
С ее помощью можно быстро оценить какой тип хранилища лучшим образом подходит для ваших задач.
Вся информация взята из официальных источников.
Поводом для создания подобной таблички послужили злоключения молодого коллеги, который потратил время на установку и настройку iSCSI-таргета, но только подключив его к Proxmox обнаружил, что оно не поддерживает LXC-контейнеры. 🤷♀️
⚠️ Как настроить Nginx и Angie для стабильной и быстрой работы при большом количестве запросов?
👉 Приглашаем на вебинар: Оптимизация Nginx и Angie под высокие нагрузки
На вебинаре вы узнаете:
- Как оптимизировать системные параметры для повышения производительности
- Как правильно настроить TLS и сократить накладные расходы на шифрование
- Какие возможности по кэшированию есть у Nginx и Angie и как их эффективно использовать
- Как измерять и анализировать клиентскую и серверную производительность
В результате вебинара вы:
- Научитесь выявлять и настраивать ключевые параметры, влияющие на производительность
- Сможете оптимизировать конфигурацию Nginx и Angie под конкретные сценарии нагрузки
- Попробуете применять техники кэширования и настройки TLS для снижения нагрузки
- Поймёте, как оценивать эффективность настройки и устранять узкие места
Все участники получат скидку на большое обучение «Инфраструктура высоконагруженных систем».
👉 Для участия зарегистрируйтесь: https://otus.pw/YUs4/?erid=2W5zFJjJgor
Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.
👉 Приглашаем на вебинар: Оптимизация Nginx и Angie под высокие нагрузки
На вебинаре вы узнаете:
- Как оптимизировать системные параметры для повышения производительности
- Как правильно настроить TLS и сократить накладные расходы на шифрование
- Какие возможности по кэшированию есть у Nginx и Angie и как их эффективно использовать
- Как измерять и анализировать клиентскую и серверную производительность
В результате вебинара вы:
- Научитесь выявлять и настраивать ключевые параметры, влияющие на производительность
- Сможете оптимизировать конфигурацию Nginx и Angie под конкретные сценарии нагрузки
- Попробуете применять техники кэширования и настройки TLS для снижения нагрузки
- Поймёте, как оценивать эффективность настройки и устранять узкие места
Все участники получат скидку на большое обучение «Инфраструктура высоконагруженных систем».
👉 Для участия зарегистрируйтесь: https://otus.pw/YUs4/?erid=2W5zFJjJgor
Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.
Как остаться на текущем выпуске Windows 10 или не допустить автоматического обновления до Windows 11?
Все просто, достаточно указать целевую версию и спокойно оставаться на ней до окончания срока ее поддержки.
https://interface31.ru/tech_it/2022/05/otklyuchaem-obnovlenie-windows-na-sleduyushhuyu-versiyu-pri-pomoshhi-ustanovki-celevogo-vypuska.html
Все просто, достаточно указать целевую версию и спокойно оставаться на ней до окончания срока ее поддержки.
https://interface31.ru/tech_it/2022/05/otklyuchaem-obnovlenie-windows-na-sleduyushhuyu-versiyu-pri-pomoshhi-ustanovki-celevogo-vypuska.html
Записки IT специалиста
Отключаем обновление Windows на следующую версию при помощи установки целевого выпуска
Вопрос управления процессом обновления клиентских версий Windows достаточно остро стоит перед системными администраторами и одной из проблем является автоматическое обновление системы на следующую версию, что может быть не всегда желательно. Ранее этот вопрос…
Отказоустойчивость или высокая доступность?
Каждый раз, когда речь заходит о кластерных решениях начинает звучать термин «отказоустойчивый». В связи с этим у многих, особенно не посвященных в тонкости технологии возникают неверные ожидания, которые приводят к негативному опыту эксплуатации подобных систем.
Почему? Потому что «как вы лодку назовете, так она и поплывет». Начнем с понятия «отказоустойчивость». В русском языке он не допускает двойного толкования и обозначает устойчивость системы к отказу части ее компонентов.
Отказоустойчивость, как инженерное понятие, предусматривает сохранение работоспособности системы, возможно с ухудшением эксплуатационных характеристик, при отказе одного или нескольких компонентов.
Примером отказоустойчивой системы можно считать RAID (кроме RAID 0), который сохраняет работоспособность, несмотря на ухудшение характеристик для уровней с четностью, при выходе из строя заданного числа дисков.
При этом сам отказ происходит без видимых последствий для системы и пользователя. На том же RAID1 (зеркало) вы можете вообще не заметить выход из строя одного из дисков.
Теперь вернемся к кластеризации. Является ли кластер отказоустойчивым? Если говорить о современной кластеризации, когда мы говорим о виртуальных средах – то нет. Но то же самое касается и классической кластеризации приложений.
Приложение ничего не знает о внутренней кухне кластера, и оно работает с некоторым сервисом, который запущен не в сферическом вакууме, а на одной из нод кластера или на виртуальной машине, которая выполняется на одной из нод.
При этом все сетевые подключения принимает именно конкретная нода и именно в ее оперативной памяти находится обрабатываемая экземпляром сервиса информация.
Что будет при отказе этой ноды? Все открытые сеансы будут закрыты, вся несохраненная информация в оперативной памяти потеряна, все незафиксированные транзакции будут в последствии откачены.
Так о какой отказоустойчивости идет речь? Понятно, что отказоустойчивостью в классическом ее понимании тут и не пахнет. Все дело в неправильном и неудачном переводе термина «failover», в английском языке, в отличие от русского, имеющего несколько значений.
Одно из них действительно «отказоустойчивый», но в другом контексте это же слово переводится как «с обработкой отказа», что более точно отражает происходящие в кластере процессы.
Что делает кластер в случае отказа одной из нод? Он запускает отказавшие сервисы на оставшихся нодах, либо перенаправляет сеансы пользователей на работающие экземпляры служб.
Это и называется «обработка отказа», т.е. при отказе одной из нод кластер автоматически выполняет восстановление отказавшего сервиса. Но это не отказоустойчивость, а именно быстрое восстановление.
А можно ли передать рабочие процессы с одной ноды на другую без прерывания их работы? В целом да, но только при условии нормально функционирующего кластера. В этом случае одна нода передает другой содержимое оперативной памяти процесса и переключает на нее сетевые соединения.
Что касается виртуализации, то миграция без остановки работы доступна только для виртуальных машин и недоступна для контейнеров. Почему? Потому что контейнер использует ядро и окружение хостовой системы, которое невозможно передать на другой хост, поэтому контейнер обязательно потребуется перезапустить после передачи на другую ноду.
В случае отказа ноды содержимое памяти как виртуальной машины, так и контейнера теряется, и мы можем только выполнить холодный перезапуск на другом узле.
В связи с чем сегодня употребление термина «failover» считается нежелательным, как и русскоязычного «отказоустойчивый». Для того, чтобы избежать путаницы рекомендуется использовать термин «high availability» или «высокая доступность» по-русски.
Этот термин не вызывает неоправданных ожиданий и абсолютно верно отражает основную характеристику системы – доступность. Потому что даже при отказе одного или нескольких узлов ваши сервисы будут в течении короткого времени восстановлены и снова окажутся доступны для пользователей.
Каждый раз, когда речь заходит о кластерных решениях начинает звучать термин «отказоустойчивый». В связи с этим у многих, особенно не посвященных в тонкости технологии возникают неверные ожидания, которые приводят к негативному опыту эксплуатации подобных систем.
Почему? Потому что «как вы лодку назовете, так она и поплывет». Начнем с понятия «отказоустойчивость». В русском языке он не допускает двойного толкования и обозначает устойчивость системы к отказу части ее компонентов.
Отказоустойчивость, как инженерное понятие, предусматривает сохранение работоспособности системы, возможно с ухудшением эксплуатационных характеристик, при отказе одного или нескольких компонентов.
Примером отказоустойчивой системы можно считать RAID (кроме RAID 0), который сохраняет работоспособность, несмотря на ухудшение характеристик для уровней с четностью, при выходе из строя заданного числа дисков.
При этом сам отказ происходит без видимых последствий для системы и пользователя. На том же RAID1 (зеркало) вы можете вообще не заметить выход из строя одного из дисков.
Теперь вернемся к кластеризации. Является ли кластер отказоустойчивым? Если говорить о современной кластеризации, когда мы говорим о виртуальных средах – то нет. Но то же самое касается и классической кластеризации приложений.
Приложение ничего не знает о внутренней кухне кластера, и оно работает с некоторым сервисом, который запущен не в сферическом вакууме, а на одной из нод кластера или на виртуальной машине, которая выполняется на одной из нод.
При этом все сетевые подключения принимает именно конкретная нода и именно в ее оперативной памяти находится обрабатываемая экземпляром сервиса информация.
Что будет при отказе этой ноды? Все открытые сеансы будут закрыты, вся несохраненная информация в оперативной памяти потеряна, все незафиксированные транзакции будут в последствии откачены.
Так о какой отказоустойчивости идет речь? Понятно, что отказоустойчивостью в классическом ее понимании тут и не пахнет. Все дело в неправильном и неудачном переводе термина «failover», в английском языке, в отличие от русского, имеющего несколько значений.
Одно из них действительно «отказоустойчивый», но в другом контексте это же слово переводится как «с обработкой отказа», что более точно отражает происходящие в кластере процессы.
Что делает кластер в случае отказа одной из нод? Он запускает отказавшие сервисы на оставшихся нодах, либо перенаправляет сеансы пользователей на работающие экземпляры служб.
Это и называется «обработка отказа», т.е. при отказе одной из нод кластер автоматически выполняет восстановление отказавшего сервиса. Но это не отказоустойчивость, а именно быстрое восстановление.
А можно ли передать рабочие процессы с одной ноды на другую без прерывания их работы? В целом да, но только при условии нормально функционирующего кластера. В этом случае одна нода передает другой содержимое оперативной памяти процесса и переключает на нее сетевые соединения.
Что касается виртуализации, то миграция без остановки работы доступна только для виртуальных машин и недоступна для контейнеров. Почему? Потому что контейнер использует ядро и окружение хостовой системы, которое невозможно передать на другой хост, поэтому контейнер обязательно потребуется перезапустить после передачи на другую ноду.
В случае отказа ноды содержимое памяти как виртуальной машины, так и контейнера теряется, и мы можем только выполнить холодный перезапуск на другом узле.
В связи с чем сегодня употребление термина «failover» считается нежелательным, как и русскоязычного «отказоустойчивый». Для того, чтобы избежать путаницы рекомендуется использовать термин «high availability» или «высокая доступность» по-русски.
Этот термин не вызывает неоправданных ожиданий и абсолютно верно отражает основную характеристику системы – доступность. Потому что даже при отказе одного или нескольких узлов ваши сервисы будут в течении короткого времени восстановлены и снова окажутся доступны для пользователей.
Пожаловался сегодня утром очередной коллега. История проста и, по сути, давно стала классикой жанра.
Поставил собираться большой проект, сборка – это надолго. Потому поставил ее на ночь и пошел спать. Утром просыпается – а вместо сборки чистый рабочий стол, компьютер по-тихому поставил ночью обновления и перезагрузился.
Дальше пошла непечатная игра слов, которую мы здесь не приводим.
А можно ли этого избежать? Можно, для этого надо всего лишь правильно настроить политики. И мы об этому уже писали, но так как знают еще не все, то не будет лишним повторить:
https://interface31.ru/tech_it/2021/05/kak-cherez-gpo-vklyuchit-zapros-na-perezagruzku-posle-ustanovki-obnovleniy.html
Поставил собираться большой проект, сборка – это надолго. Потому поставил ее на ночь и пошел спать. Утром просыпается – а вместо сборки чистый рабочий стол, компьютер по-тихому поставил ночью обновления и перезагрузился.
Дальше пошла непечатная игра слов, которую мы здесь не приводим.
А можно ли этого избежать? Можно, для этого надо всего лишь правильно настроить политики. И мы об этому уже писали, но так как знают еще не все, то не будет лишним повторить:
https://interface31.ru/tech_it/2021/05/kak-cherez-gpo-vklyuchit-zapros-na-perezagruzku-posle-ustanovki-obnovleniy.html
Алиса такой ерундой не страдает, стрелять - так стрелять. Но оказалось неподъемной задачей заставить ее выстрелить именно в монитор. В сторону - пожалуйста.
А когда я все таки настоял - она взяла и засунула ружье в монитор. После того, как ей указали на сей косяк, она доходчиво пояснила, что я дурак и в таком формате изображения ружье не помещается в кадр.
Ладно, заменим ружье на пестик. И опять двадцать пять. В монитор стрелять надо, Алиса, в монитор...
А вы говорите людей скоро заменит. Нет, оно может и заменит, но именно с таким результатом.
А когда я все таки настоял - она взяла и засунула ружье в монитор. После того, как ей указали на сей косяк, она доходчиво пояснила, что я дурак и в таком формате изображения ружье не помещается в кадр.
Ладно, заменим ружье на пестик. И опять двадцать пять. В монитор стрелять надо, Алиса, в монитор...
А вы говорите людей скоро заменит. Нет, оно может и заменит, но именно с таким результатом.
Медь или алюминий?
Каждый раз, когда речь заходит о материале для радиаторов приходится встречаться с распространенным заблуждением, что медный радиатор эффективнее алюминиевого, хотя на самом деле это далеко не так.
Чтобы понять почему, обратимся к школьному курсу физики, а именно вспомним некоторые параметры вещества, непосредственно влияющие на свойства радиаторов.
Начнем с теплопроводности, так как именно этот параметр чаше всего приводят в качестве аргумента.
Теплопроводность – это свойство вещества передавать энергию от более нагретых участков к менее нагретым. Измеряется она в Вт/(м·К), но нас сейчас будут меньше всего волновать абсолютные цифры, гораздо важнее соотношения.
Теплопроводность меди - 401 Вт/(м·К), алюминия 202-236 Вт/(м·К). Это говорит о том, что медный радиатор равномерно прогреется в два раза быстрее алюминиевого, в целом это хорошо, так как мы быстрее заберем тепло от объекта охлаждения.
Но забрать мы его забрали, дальше что? Очевидно, что радиатор нагреется. Как сильно? А вот здесь играет роль совсем другая характеристика вещества – теплоемкость.
Теплоемкость – это количество тепловой энергии, поглощаемой (выделяемой) веществом при нагреве (охлаждении) его на один градус. В нашем случае удобно пользоваться удельной теплоемкостью, которая отражает количество теплоты на градус применительно к массе тела.
Удельная теплоемкость измеряется в Дж/(кг·К) и составляет для меди 385 Дж/(кг·К), а алюминия – 897 Дж/(кг·К), т.е. теплоемкость алюминия выше в 2,3 раза чем теплоемкость меди.
О чем это говорит? О том, что медный радиатор нагреется в 2,3 раза сильнее, чем алюминиевый той же массы.
Таким образом алюминий является более эффективным материалом для отведения тепловой энергии, так как он позволяет поглощать большее количество тепловой энергии при меньшем нагреве, чем медь.
Но при этом алюминий обладает меньшей теплопроводностью, значит хуже будет справляться с задачей быстро отвести тепло от объекта охлаждения, при этом с задачей поглощения энергии он будет справляться лучше.
К этому вопросу мы уже вернемся. А пока продолжим разбираться с тем, куда же пойдет тепловая энергия, накопленная радиатором. А пойдет она в окружающую среду в процессе теплообмена более горячего радиатора и менее горячего воздуха.
Эффективность теплообмена зависит от площади излучения тепловой энергии и разности температур радиатора и окружающей среды. Таким образом из радиаторов одной и той же массы будет эффективнее тот, который имеет большую площадь излучения.
А насколько эффективнее будут отводить тепло наши материалы? Здесь снова работает теплоемкость, только в обратную сторону. При охлаждении на один градус алюминий отдаст в 2,3 раза больше энергии чем медь.
Таким образом медь будет быстро нагреваться, но медленно охлаждаться и для эффективной работы такого радиатора нам понадобится более высокая разность температур между радиатором и окружающей средой или дополнительные меры по принудительному увеличению теплообмена (обдув).
Есть еще один немаловажный аспект. Плотность меди составляет 8900 кг/м3, а плотность алюминия 2700 кг/м3, т.е. при одних и тех же физических размерах медный радиатор будет в 3,2 раза тяжелее, но в 2,3 раза менее эффективен.
В реальном мире для обеспечения эффективности радиаторов сочетают сильные стороны разных материалов, которые взаимовыгодно подчеркивают друг друга.
Медный сердечник или тепловая трубка обладают высокой теплопроводностью и позволяют быстро отводить тепло от объекта охлаждения. Их теплоемкость при этом не играет решающей роли, их задача избежать ситуации, когда объект охлаждения уже горячий, а радиатор еще холодный.
А алюминиевый радиатор позволяет, благодаря высокой теплоемкости, принять большое количество тепла и эффективно передать его во внешнюю среду.
Таким образом наиболее эффективным будет алюминиевый радиатор с тепловой трубкой, а за ним будет идти алюминиевый радиатор с медным сердечником.
Каждый раз, когда речь заходит о материале для радиаторов приходится встречаться с распространенным заблуждением, что медный радиатор эффективнее алюминиевого, хотя на самом деле это далеко не так.
Чтобы понять почему, обратимся к школьному курсу физики, а именно вспомним некоторые параметры вещества, непосредственно влияющие на свойства радиаторов.
Начнем с теплопроводности, так как именно этот параметр чаше всего приводят в качестве аргумента.
Теплопроводность – это свойство вещества передавать энергию от более нагретых участков к менее нагретым. Измеряется она в Вт/(м·К), но нас сейчас будут меньше всего волновать абсолютные цифры, гораздо важнее соотношения.
Теплопроводность меди - 401 Вт/(м·К), алюминия 202-236 Вт/(м·К). Это говорит о том, что медный радиатор равномерно прогреется в два раза быстрее алюминиевого, в целом это хорошо, так как мы быстрее заберем тепло от объекта охлаждения.
Но забрать мы его забрали, дальше что? Очевидно, что радиатор нагреется. Как сильно? А вот здесь играет роль совсем другая характеристика вещества – теплоемкость.
Теплоемкость – это количество тепловой энергии, поглощаемой (выделяемой) веществом при нагреве (охлаждении) его на один градус. В нашем случае удобно пользоваться удельной теплоемкостью, которая отражает количество теплоты на градус применительно к массе тела.
Удельная теплоемкость измеряется в Дж/(кг·К) и составляет для меди 385 Дж/(кг·К), а алюминия – 897 Дж/(кг·К), т.е. теплоемкость алюминия выше в 2,3 раза чем теплоемкость меди.
О чем это говорит? О том, что медный радиатор нагреется в 2,3 раза сильнее, чем алюминиевый той же массы.
Таким образом алюминий является более эффективным материалом для отведения тепловой энергии, так как он позволяет поглощать большее количество тепловой энергии при меньшем нагреве, чем медь.
Но при этом алюминий обладает меньшей теплопроводностью, значит хуже будет справляться с задачей быстро отвести тепло от объекта охлаждения, при этом с задачей поглощения энергии он будет справляться лучше.
К этому вопросу мы уже вернемся. А пока продолжим разбираться с тем, куда же пойдет тепловая энергия, накопленная радиатором. А пойдет она в окружающую среду в процессе теплообмена более горячего радиатора и менее горячего воздуха.
Эффективность теплообмена зависит от площади излучения тепловой энергии и разности температур радиатора и окружающей среды. Таким образом из радиаторов одной и той же массы будет эффективнее тот, который имеет большую площадь излучения.
А насколько эффективнее будут отводить тепло наши материалы? Здесь снова работает теплоемкость, только в обратную сторону. При охлаждении на один градус алюминий отдаст в 2,3 раза больше энергии чем медь.
Таким образом медь будет быстро нагреваться, но медленно охлаждаться и для эффективной работы такого радиатора нам понадобится более высокая разность температур между радиатором и окружающей средой или дополнительные меры по принудительному увеличению теплообмена (обдув).
Есть еще один немаловажный аспект. Плотность меди составляет 8900 кг/м3, а плотность алюминия 2700 кг/м3, т.е. при одних и тех же физических размерах медный радиатор будет в 3,2 раза тяжелее, но в 2,3 раза менее эффективен.
В реальном мире для обеспечения эффективности радиаторов сочетают сильные стороны разных материалов, которые взаимовыгодно подчеркивают друг друга.
Медный сердечник или тепловая трубка обладают высокой теплопроводностью и позволяют быстро отводить тепло от объекта охлаждения. Их теплоемкость при этом не играет решающей роли, их задача избежать ситуации, когда объект охлаждения уже горячий, а радиатор еще холодный.
А алюминиевый радиатор позволяет, благодаря высокой теплоемкости, принять большое количество тепла и эффективно передать его во внешнюю среду.
Таким образом наиболее эффективным будет алюминиевый радиатор с тепловой трубкой, а за ним будет идти алюминиевый радиатор с медным сердечником.
