Пятничное, о жизни. Информационный шум.
Мне кажется, если сейчас каким-нибудь образом переместить сюда человека 20-летней давности и выдать ему современные гаджеты, то он очень быстро сойдет с ума. Ну или наложит на себя руки.
Практически вся наша повседневная жизнь проходит в условиях сильного информационного шума. С самого утра и до позднего вечера к нам приходят сообщения электронной почты, SMS, мессенджеров. Пуши приложений и т.д. и т.п.
Фактически мы уже к этому привыкли и если тот же телефон долго молчит, то начинаем беспокоиться, а все ли в порядке со связью?
И, пожалуй, остаться без связи для современного человека, это пострашнее чем остаться без трусов. Срам можно и лопухом прикрыть, а вот что делать без гаджета?
Навигация в незнакомом месте, такси, деньги, контакты – все сосредоточено в одном месте. И если мы находимся вне дома, то это место – телефон.
Это настолько плотно вошло в нашу жизнь, что наши дети уже с трудом представляют себе, что был когда-то мир без интернета и смартфонов. Что такси заказывали по телефону и предварительно еще надо было узнать точный адрес куда вызываешь. А таксист мог попросить показать дорогу…
Сегодня же, не вставая с дивана можно вызвать такси, заказать еду, купить билеты, забронировать отель и т.д. и т.п. Это, уже не говоря о таких банальных вещах, как заплатить за интернет, коммуналку или саму связь.
Обратная сторона – постоянные сообщения и уведомления. Нужные, не совсем нужные, совсем не нужные. От приложений, сайтов, сервисов, организаций и наконец самых разных людей.
И так каждый день, с утра до вечера. Но современный человек воспринимает это нормально, хотя и жалуется периодически на информационный шум. Но если после оплаты на сайте сразу не пришло подтверждение, то он уже начинает нервничать.
Если представитель организации в мессенджере молчит более 5 минут – тоже, ну действительно, что там у них случилось…
На мой взгляд, информационный шум – это примерно тоже самое что и шум большого города. Нравится, не нравится, но он есть, и мы среди него живем.
Это неотъемлемая часть нашей жизни, а когда он пропадает, то современный человек не вздыхает облегченно, а наоборот начинает нервничать, потому что это все равно что замер за окном крупный город. Первый признак, что что-то идет не так.
Мне кажется, если сейчас каким-нибудь образом переместить сюда человека 20-летней давности и выдать ему современные гаджеты, то он очень быстро сойдет с ума. Ну или наложит на себя руки.
Практически вся наша повседневная жизнь проходит в условиях сильного информационного шума. С самого утра и до позднего вечера к нам приходят сообщения электронной почты, SMS, мессенджеров. Пуши приложений и т.д. и т.п.
Фактически мы уже к этому привыкли и если тот же телефон долго молчит, то начинаем беспокоиться, а все ли в порядке со связью?
И, пожалуй, остаться без связи для современного человека, это пострашнее чем остаться без трусов. Срам можно и лопухом прикрыть, а вот что делать без гаджета?
Навигация в незнакомом месте, такси, деньги, контакты – все сосредоточено в одном месте. И если мы находимся вне дома, то это место – телефон.
Это настолько плотно вошло в нашу жизнь, что наши дети уже с трудом представляют себе, что был когда-то мир без интернета и смартфонов. Что такси заказывали по телефону и предварительно еще надо было узнать точный адрес куда вызываешь. А таксист мог попросить показать дорогу…
Сегодня же, не вставая с дивана можно вызвать такси, заказать еду, купить билеты, забронировать отель и т.д. и т.п. Это, уже не говоря о таких банальных вещах, как заплатить за интернет, коммуналку или саму связь.
Обратная сторона – постоянные сообщения и уведомления. Нужные, не совсем нужные, совсем не нужные. От приложений, сайтов, сервисов, организаций и наконец самых разных людей.
И так каждый день, с утра до вечера. Но современный человек воспринимает это нормально, хотя и жалуется периодически на информационный шум. Но если после оплаты на сайте сразу не пришло подтверждение, то он уже начинает нервничать.
Если представитель организации в мессенджере молчит более 5 минут – тоже, ну действительно, что там у них случилось…
На мой взгляд, информационный шум – это примерно тоже самое что и шум большого города. Нравится, не нравится, но он есть, и мы среди него живем.
Это неотъемлемая часть нашей жизни, а когда он пропадает, то современный человек не вздыхает облегченно, а наоборот начинает нервничать, потому что это все равно что замер за окном крупный город. Первый признак, что что-то идет не так.
Просто добавь воды сделай TRIM
На днях у одного коллеги приключилась поучительная история. Всю неделю он оптимизировал инфраструктуру по причине покупки нового оборудования и в числе прочего решил переместить Zabbix на более мощный гипервизор, на котором как раз освободилось место.
Сказано – сделано. Только вот практически сразу Zabbix начал сыпать алерты о высоком проценте использования собственных процессов. А тут коллега, ровно перед переездом, добавил на мониторинг около 35 новых узлов с чем и связал выросшую нагрузку.
Беда эта известная и в интернете полным-полно инструкций какие опции нужно крутить для того или иного процесса. Только вот инструкции почему-то не помогали и через пару часов «оптимизации» Zabbix вообще упал.
После чего была использована опция «звонок другу» и мы решили восстановить контейнер из бекапа, благо с этим было все в порядке.
Сразу обратили внимание на необычно высокий LA, который для двух выделенных контейнеру ядер показывал просто неприличные значения. При этом никакой вычислительной нагрузки нами не фиксировалось.
А если нет нагрузки, но LA держится на высоких отметках – смотри подсистему ввода-вывода. И точно, тут даже ходить никуда не пришлось, собранные самим Zabbix метрики показывали высокое значение IO wait.
После чего мы поинтересовались предысторией. Как выяснилось в этом хранилище раньше жили несколько виртуалок занимая, примерно, 70-75% его объема. После чего виртуалки уехали, а на их место приехал Zabbix.
Теперь все стало понятно. В нормальном режиме эксплуатации серверные системы нормально живут без TRIM, потому что основной характер нагрузки не предусматривает удаления значительного объема данных, они в основном дописываются или перезаписываются.
Но при переезде мы как раз выполнили удаление большого объема данных, но лежащие в основе хранилища твердотельные накопители уведомлены об этом не были. Со всеми вытекающими.
Что надо сделать? Принудительно послать TRIM, после чего буквально в течении ближайших 15 минут все пришло в норму.
Мораль сей истории проста – лечить надо причину, а не симптомы. И всегда искать причинно-следственные связи. Потому что просто так никогда ничего не случается.
На днях у одного коллеги приключилась поучительная история. Всю неделю он оптимизировал инфраструктуру по причине покупки нового оборудования и в числе прочего решил переместить Zabbix на более мощный гипервизор, на котором как раз освободилось место.
Сказано – сделано. Только вот практически сразу Zabbix начал сыпать алерты о высоком проценте использования собственных процессов. А тут коллега, ровно перед переездом, добавил на мониторинг около 35 новых узлов с чем и связал выросшую нагрузку.
Беда эта известная и в интернете полным-полно инструкций какие опции нужно крутить для того или иного процесса. Только вот инструкции почему-то не помогали и через пару часов «оптимизации» Zabbix вообще упал.
После чего была использована опция «звонок другу» и мы решили восстановить контейнер из бекапа, благо с этим было все в порядке.
Сразу обратили внимание на необычно высокий LA, который для двух выделенных контейнеру ядер показывал просто неприличные значения. При этом никакой вычислительной нагрузки нами не фиксировалось.
А если нет нагрузки, но LA держится на высоких отметках – смотри подсистему ввода-вывода. И точно, тут даже ходить никуда не пришлось, собранные самим Zabbix метрики показывали высокое значение IO wait.
После чего мы поинтересовались предысторией. Как выяснилось в этом хранилище раньше жили несколько виртуалок занимая, примерно, 70-75% его объема. После чего виртуалки уехали, а на их место приехал Zabbix.
Теперь все стало понятно. В нормальном режиме эксплуатации серверные системы нормально живут без TRIM, потому что основной характер нагрузки не предусматривает удаления значительного объема данных, они в основном дописываются или перезаписываются.
Но при переезде мы как раз выполнили удаление большого объема данных, но лежащие в основе хранилища твердотельные накопители уведомлены об этом не были. Со всеми вытекающими.
Что надо сделать? Принудительно послать TRIM, после чего буквально в течении ближайших 15 минут все пришло в норму.
Мораль сей истории проста – лечить надо причину, а не симптомы. И всегда искать причинно-следственные связи. Потому что просто так никогда ничего не случается.
Ликбез по iptables
Как показывает практика, вопросов по iptables меньше не становится и это касается не только Linux, но и Mikrotik, где под капотом тоже iptables.
Поэтому приводим полный цикл наших статей по iptables, которые закрывают основные практические вопросы.
🔹 Основы iptables для начинающих. Часть 1. Общие вопросы - здесь мы разбираем как работает iptables и каким образом пакеты проходят сквозь брандмауэр. Очень важная часть для понимания дальнейших материалов.
🔹 Основы iptables для начинающих. Часть 2. Таблица filter - разбираем фильтрацию пакетов, т.е. собственно работу брандмауэра. Приводим минимальную конфигурацию нормально закрытого брандмауэра.
🔹 Основы iptables для начинающих. Часть 3. Таблица nat - еще одна важная часть iptables - преобразование сетевых адресов, очень много ошибок и недоразумений связано с непониманием работы nat, а именно где и когда происходит преобразование и на что это влияет.
🔹 Основы iptables для начинающих. Часть 4. Таблица nat - типовые сценарии использования - продолжение предыдущей части, где мы рассматриваем типовые сценарии использования NAT - выход в интернет, проброс портов и т.д.
🔹 Основы iptables для начинающих. Как сохранить правила и восстановить их при загрузке - здесь мы рассмотрели все возможные способы сохранить и восстановить при загрузке конфигурацию вашего межсетевого экрана.
Как показывает практика, вопросов по iptables меньше не становится и это касается не только Linux, но и Mikrotik, где под капотом тоже iptables.
Поэтому приводим полный цикл наших статей по iptables, которые закрывают основные практические вопросы.
🔹 Основы iptables для начинающих. Часть 1. Общие вопросы - здесь мы разбираем как работает iptables и каким образом пакеты проходят сквозь брандмауэр. Очень важная часть для понимания дальнейших материалов.
🔹 Основы iptables для начинающих. Часть 2. Таблица filter - разбираем фильтрацию пакетов, т.е. собственно работу брандмауэра. Приводим минимальную конфигурацию нормально закрытого брандмауэра.
🔹 Основы iptables для начинающих. Часть 3. Таблица nat - еще одна важная часть iptables - преобразование сетевых адресов, очень много ошибок и недоразумений связано с непониманием работы nat, а именно где и когда происходит преобразование и на что это влияет.
🔹 Основы iptables для начинающих. Часть 4. Таблица nat - типовые сценарии использования - продолжение предыдущей части, где мы рассматриваем типовые сценарии использования NAT - выход в интернет, проброс портов и т.д.
🔹 Основы iptables для начинающих. Как сохранить правила и восстановить их при загрузке - здесь мы рассмотрели все возможные способы сохранить и восстановить при загрузке конфигурацию вашего межсетевого экрана.
Современный взгляд на уровни RAID
В комментариях к предыдущей заметке читатели задавали вопросы, а какие уровни RAID и какие технологии его построения актуальны сейчас.
Давайте разбираться. Последние годы совершили настоящую революцию в системах хранения благодаря твердотельным накопителям и NVMe. Теперь если нам нужен быстрый диск – мы просто берем быстрый диск.
А благодаря снижению их стоимости SSD и NVMе стали действительно доступны даже в бюджетных конфигурациях. При этом даже самый простой бюджетный SATA SSD по своим параметрам превосходит любой жесткий диск.
Жесткие диски все еще остались на рынке, но ушли в нишу холодного хранения данных. А эта область имеет свои особенности. Скорость записи там не так важна, как объемы хранения и стоимость этого хранения, при допустимой надежности.
Аппаратные контроллеры, когда-то это считалось круто. Умные, со своим процессором, умеющие быстро рассчитывать четность они были незаменимыми при построении таких массивов как RAID5/6.
В современных условиях с этими задачами прекрасно справится процессор, даже самый простой и даже не заметит этой нагрузки.
Другой аргумент – «батарейка», но батарейка обслуживает исключительно внутренний кеш контроллера и позволяет ему ускорить запись, отвечая системе, что все уже записано, хотя на самом деле данные еще в кеше. А сейчас мы просто можем взять быстрые диски. Про надежность – это тоже не к батарейке, а к режимам кеширования.
А вот недостатков выше крыши. Если у вас сгорел контроллер, то вам нужен второй такой же контроллер. Таже нельзя просто так перенести массив на другую аппаратную платформу. Переносить придется либо с контроллером, либо тупо переливать данные.
Программные решения позволяют всего этого избежать и предоставляют гораздо больше удобства, универсальности и иных современных плюшек. Причем для этого вам не придется менять контроллер, достаточно будет просто обновить ПО.
А что у нас остается по уровням? Помним, что если нам нужна скорость, то просто берем быстрые диски. Но одиночный диск может отказать, поэтому добавляем второй, в зеркало.
Надо что-то еще? А зачем? Собирать на SSD массивы вроде RAID 10 и т.п. лишено смысла, всегда можно взять более быстрые диски. А в случае с NVMe ограничивающими факторами будут уже не диски, а, например, пропускная способность сети.
Построение RAID 5/6 на твердотельных накопителях также лишено всякого смыла, так как это кратно увеличит Write amplification (WA) диска. Которое, как мы помним, никогда не будет равно единице и сильно зависит от конфигурации системы и внешних факторов.
Теперь считаем пенальти только по записи: для RAID 5 это будет два (запись данных, запись четности), для RAID 6 – три (запись данных, запись четности 1, запись четности 2). Таким образом, если одиночный диск у нас работал с WA равным пяти, то объединив диски в массив мы получим WA от 10 до 15, что крайне негативно скажется на их ресурсе.
Таким образом для SSD вредны любые массивы с четностью, в том числе современные RAID-Z ZFS.
В тоже время они остаются полезными при построении больших массивов из жестких дисков, когда нам нужно организовать максимальную емкость хранения при минимальных издержках. Для систем холодного хранения скорость не так важна, а при необходимости этот вопрос можно решить SSD-кешированием.
Но здесь остро стоит вопрос надежности. При использовании дисков общего назначения параметр неисправимых ошибок чтения - URE (Unrecoverable Read Error) – составит 1 ошибка на 12,5 ТБ.
Появление такой ошибки при ребилде равнозначно выходу из строя еще одного диска, что полностью разрушит массив RAID 5. Поэтому построение и использование массивов RAID 5 в современных условиях недопустимо.
Что остается? RAID 6, RAID-Z, проприетарные уровни RAID – но все это не про скорость, а про объем и эффективность хранения.
Нужна скорость? Берем быстрые NVMe диски.
В комментариях к предыдущей заметке читатели задавали вопросы, а какие уровни RAID и какие технологии его построения актуальны сейчас.
Давайте разбираться. Последние годы совершили настоящую революцию в системах хранения благодаря твердотельным накопителям и NVMe. Теперь если нам нужен быстрый диск – мы просто берем быстрый диск.
А благодаря снижению их стоимости SSD и NVMе стали действительно доступны даже в бюджетных конфигурациях. При этом даже самый простой бюджетный SATA SSD по своим параметрам превосходит любой жесткий диск.
Жесткие диски все еще остались на рынке, но ушли в нишу холодного хранения данных. А эта область имеет свои особенности. Скорость записи там не так важна, как объемы хранения и стоимость этого хранения, при допустимой надежности.
Аппаратные контроллеры, когда-то это считалось круто. Умные, со своим процессором, умеющие быстро рассчитывать четность они были незаменимыми при построении таких массивов как RAID5/6.
В современных условиях с этими задачами прекрасно справится процессор, даже самый простой и даже не заметит этой нагрузки.
Другой аргумент – «батарейка», но батарейка обслуживает исключительно внутренний кеш контроллера и позволяет ему ускорить запись, отвечая системе, что все уже записано, хотя на самом деле данные еще в кеше. А сейчас мы просто можем взять быстрые диски. Про надежность – это тоже не к батарейке, а к режимам кеширования.
А вот недостатков выше крыши. Если у вас сгорел контроллер, то вам нужен второй такой же контроллер. Таже нельзя просто так перенести массив на другую аппаратную платформу. Переносить придется либо с контроллером, либо тупо переливать данные.
Программные решения позволяют всего этого избежать и предоставляют гораздо больше удобства, универсальности и иных современных плюшек. Причем для этого вам не придется менять контроллер, достаточно будет просто обновить ПО.
А что у нас остается по уровням? Помним, что если нам нужна скорость, то просто берем быстрые диски. Но одиночный диск может отказать, поэтому добавляем второй, в зеркало.
Надо что-то еще? А зачем? Собирать на SSD массивы вроде RAID 10 и т.п. лишено смысла, всегда можно взять более быстрые диски. А в случае с NVMe ограничивающими факторами будут уже не диски, а, например, пропускная способность сети.
Построение RAID 5/6 на твердотельных накопителях также лишено всякого смыла, так как это кратно увеличит Write amplification (WA) диска. Которое, как мы помним, никогда не будет равно единице и сильно зависит от конфигурации системы и внешних факторов.
Теперь считаем пенальти только по записи: для RAID 5 это будет два (запись данных, запись четности), для RAID 6 – три (запись данных, запись четности 1, запись четности 2). Таким образом, если одиночный диск у нас работал с WA равным пяти, то объединив диски в массив мы получим WA от 10 до 15, что крайне негативно скажется на их ресурсе.
Таким образом для SSD вредны любые массивы с четностью, в том числе современные RAID-Z ZFS.
В тоже время они остаются полезными при построении больших массивов из жестких дисков, когда нам нужно организовать максимальную емкость хранения при минимальных издержках. Для систем холодного хранения скорость не так важна, а при необходимости этот вопрос можно решить SSD-кешированием.
Но здесь остро стоит вопрос надежности. При использовании дисков общего назначения параметр неисправимых ошибок чтения - URE (Unrecoverable Read Error) – составит 1 ошибка на 12,5 ТБ.
Появление такой ошибки при ребилде равнозначно выходу из строя еще одного диска, что полностью разрушит массив RAID 5. Поэтому построение и использование массивов RAID 5 в современных условиях недопустимо.
Что остается? RAID 6, RAID-Z, проприетарные уровни RAID – но все это не про скорость, а про объем и эффективность хранения.
Нужна скорость? Берем быстрые NVMe диски.
Так как снова обсуждаем RAID, то будет не лишним еще раз прочитать:
RAID массивы - краткий ликбез
RAID-массивы давно и прочно вошли в повседневную деятельность администраторов даже небольших предприятий.
Трудно найти того, кто никогда не использовал хотя бы "зеркало", но тем не менее очень и очень многие с завидной периодичностью теряют данные или испытывают иные сложности при эксплуатации массивов.
Не говоря уже о распространенных мифах, которые продолжают витать вокруг вроде бы давно избитой темы.
Кроме того, современные условия вносят свои коррективы и то, чтобы было оптимальным еще несколько лет назад сегодня утратило свою актуальность или стало нежелательным к применению.
https://interface31.ru/tech_it/2019/05/raid-likbez.html
RAID массивы - краткий ликбез
RAID-массивы давно и прочно вошли в повседневную деятельность администраторов даже небольших предприятий.
Трудно найти того, кто никогда не использовал хотя бы "зеркало", но тем не менее очень и очень многие с завидной периодичностью теряют данные или испытывают иные сложности при эксплуатации массивов.
Не говоря уже о распространенных мифах, которые продолжают витать вокруг вроде бы давно избитой темы.
Кроме того, современные условия вносят свои коррективы и то, чтобы было оптимальным еще несколько лет назад сегодня утратило свою актуальность или стало нежелательным к применению.
https://interface31.ru/tech_it/2019/05/raid-likbez.html
Какими мини-апами в tg вы пользуетесь?
Вот какой удобный Mini App появился недавно: Calendar for Telegram
Это:
💫 Быстрый доступ к расписанию, которое теперь всегда под рукой;
💫 Лёгкий шэринг событий – без e-mail! Просто отправьте приглашение другу/коллеге в чат или сразу добавьте в событие людей по их Telegram-имени или нику;
💫 Афиши – общее расписания для работы, мероприятий, совместных путешествий или спорта;
💫 Слоты – отражают доступность вашего свободного времени для назначения встреч (это как Calendly, только в вашем tCalendar);
💫 Моментальный видео-звонок – возможность создавать Google Meet сразу в tCalendar;
💫 Синхронизация с Google Календарем – все события всегда актуальны в обоих календарях;
⭐️ Ai-функции – можно назначать встречи просто отправив сообщение боту календаря с данными по предстоящему мероприятию — и всё! Событие само появится в расписании.
Самое приятное, что всё это бесплатно и незаменимо в обычной жизни👌
Юзкейс такой: поняли, что нужна встреча -> создали её тут же в тг -> пригласили участников. В Гугл календарь само придет. 🪄✨
erid: 2W5zFJBpTpU
Вот какой удобный Mini App появился недавно: Calendar for Telegram
Это:
💫 Быстрый доступ к расписанию, которое теперь всегда под рукой;
💫 Лёгкий шэринг событий – без e-mail! Просто отправьте приглашение другу/коллеге в чат или сразу добавьте в событие людей по их Telegram-имени или нику;
💫 Афиши – общее расписания для работы, мероприятий, совместных путешествий или спорта;
💫 Слоты – отражают доступность вашего свободного времени для назначения встреч (это как Calendly, только в вашем tCalendar);
💫 Моментальный видео-звонок – возможность создавать Google Meet сразу в tCalendar;
💫 Синхронизация с Google Календарем – все события всегда актуальны в обоих календарях;
⭐️ Ai-функции – можно назначать встречи просто отправив сообщение боту календаря с данными по предстоящему мероприятию — и всё! Событие само появится в расписании.
Самое приятное, что всё это бесплатно и незаменимо в обычной жизни👌
Юзкейс такой: поняли, что нужна встреча -> создали её тут же в тг -> пригласили участников. В Гугл календарь само придет. 🪄✨
erid: 2W5zFJBpTpU
Деградация данных
Деградация данных (bitrot, битовое гниение) – это достаточно актуальный в настоящее время тип разрушения цифровых данных вследствие накопления некритичных ошибок на запоминающем устройстве.
К сожалению, многие коллеги путают деградацию с выходом из строя ячеек накопителя (бед-блоки) и не придают этому вопросу серьезного значения. А зря.
С бед-блоками достаточно эффективно позволяет справляться RAID, когда в случае ошибки чтения блок заменяется резервным, а его содержимое считывается с исправной копии. Да, возможен эффект появления скрытых бед-блоков, но он решается периодическом перечитыванием содержимого массива.
Проблема битового гниения лежит глубже и именно этот термин представляется нам наиболее удачным. Как и обычное гниение он медленно и незаметно повреждает данные до тех пор, пока разрушения не перейдут в критическую фазу.
Причинами битового гниения становятся ошибки в процессе записи, не связанные с повреждением непосредственно ячеек, они могут даже произойти в оперативной памяти и при отсутствии ECC ваши данные также могут быть незаметно повреждены.
Чаще всего деградация данных происходит при длительном хранении, вследствие деградации заряда ячейки или уровня намагниченности сектора. Ошибок чтения с накопителя это не вызывает, но приводит к нарушению целостности данных.
Как правило большинство современных форматов данных имеют избыточность и изменение одного бита может быть откорректировано встроенными средствами, но для этого эти данные нужно хотя бы открыть.
В противном случае подобные ошибки могут накапливаться и в определенный момент привести к невосстановимому повреждению данных. При этом процесс битового гниения не сопровождается ошибками чтения с накопителя и может происходить на полностью исправном диске.
А так как нет никаких ошибок, то и RAID вам ничем не поможет, особенно уровни без четности. Так, например, в случае зеркала у нас могут оказаться изменены биты в произвольных местах обоих копий. И чем больше по размеру файл и реже обращения к нему – тем вероятнее такое развитие событий.
Некоторую защиту могут предоставлять массивы с четностью (RAID 5 и 6), но здесь многое зависит от контроллера или программной реализации, главное у которых – уметь производить такую проверку в фоновом режиме.
В таком случае имея одну правильную копию и целые данные четности массив может проверить целостность данных и автоматически восстановить их.
Но оптимальным решением проблемы будет вынос таких проверок на уровень файловой системы, так как это позволяет действовать наиболее эффективно и с наименьшей нагрузкой на систему.
Современные системы с контролем целостности – это ZFS, btrfs и ReFS – и именно они рекомендуются для систем хранения больших объемов информации. Каждая из них умеет в фоновом режиме проверять целостность файлов и восстанавливать поврежденные фрагменты используя контрольные суммы (при наличии избыточности, разумеется).
И именно по этой причине тот же Proxmox категорически не рекомендует использование mdadm для хранилищ виртуальных машин в производственных средах.
Деградация данных (bitrot, битовое гниение) – это достаточно актуальный в настоящее время тип разрушения цифровых данных вследствие накопления некритичных ошибок на запоминающем устройстве.
К сожалению, многие коллеги путают деградацию с выходом из строя ячеек накопителя (бед-блоки) и не придают этому вопросу серьезного значения. А зря.
С бед-блоками достаточно эффективно позволяет справляться RAID, когда в случае ошибки чтения блок заменяется резервным, а его содержимое считывается с исправной копии. Да, возможен эффект появления скрытых бед-блоков, но он решается периодическом перечитыванием содержимого массива.
Проблема битового гниения лежит глубже и именно этот термин представляется нам наиболее удачным. Как и обычное гниение он медленно и незаметно повреждает данные до тех пор, пока разрушения не перейдут в критическую фазу.
Причинами битового гниения становятся ошибки в процессе записи, не связанные с повреждением непосредственно ячеек, они могут даже произойти в оперативной памяти и при отсутствии ECC ваши данные также могут быть незаметно повреждены.
Чаще всего деградация данных происходит при длительном хранении, вследствие деградации заряда ячейки или уровня намагниченности сектора. Ошибок чтения с накопителя это не вызывает, но приводит к нарушению целостности данных.
Как правило большинство современных форматов данных имеют избыточность и изменение одного бита может быть откорректировано встроенными средствами, но для этого эти данные нужно хотя бы открыть.
В противном случае подобные ошибки могут накапливаться и в определенный момент привести к невосстановимому повреждению данных. При этом процесс битового гниения не сопровождается ошибками чтения с накопителя и может происходить на полностью исправном диске.
А так как нет никаких ошибок, то и RAID вам ничем не поможет, особенно уровни без четности. Так, например, в случае зеркала у нас могут оказаться изменены биты в произвольных местах обоих копий. И чем больше по размеру файл и реже обращения к нему – тем вероятнее такое развитие событий.
Некоторую защиту могут предоставлять массивы с четностью (RAID 5 и 6), но здесь многое зависит от контроллера или программной реализации, главное у которых – уметь производить такую проверку в фоновом режиме.
В таком случае имея одну правильную копию и целые данные четности массив может проверить целостность данных и автоматически восстановить их.
Но оптимальным решением проблемы будет вынос таких проверок на уровень файловой системы, так как это позволяет действовать наиболее эффективно и с наименьшей нагрузкой на систему.
Современные системы с контролем целостности – это ZFS, btrfs и ReFS – и именно они рекомендуются для систем хранения больших объемов информации. Каждая из них умеет в фоновом режиме проверять целостность файлов и восстанавливать поврежденные фрагменты используя контрольные суммы (при наличии избыточности, разумеется).
И именно по этой причине тот же Proxmox категорически не рекомендует использование mdadm для хранилищ виртуальных машин в производственных средах.
Спрашивают – отвечаем
Вопрос вот в чем: есть энтерпрайз 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.
Их нравы, да и наши тоже…
Исследование уязвимостей в программном обеспечении – тема тонкая, особенно в той ее части, которая касается обнародования результатов исследований. Здесь нужно действовать аналогично докторам, в первую очередь руководствуясь принципом «не навреди».
Действительно, не вовремя опубликованная информация об уязвимости может быть использована злоумышленниками и нанесет серьезный вред законопослушным пользователям.
В тоже время полное замалчивание проблем тоже не является правильной стратегией, уязвимость может быть обнаружена разными исследователями и не все из них играют на светлой стороне.
Поэтому сложилась определенная практика, когда данные об уязвимостях публикуются, но без лишних технических подробностей, особенно если для них еще нет официальных исправлений.
Но последнее время в данной отрасли творится что-то непонятное, если не сказать – беспредельное.
Не так давно в Windows Server 2025 была обнаружена уязвимость под названием BadSuccessor, которая позволяет получить полномочия администратора домена располагая в нем минимальными правами.
Атака достаточно непростая технически и Microsoft классифицировала ее как уязвимость «умеренной серьезности» и пока не выпустила оперативного исправления.
И все бы ничего, но некий шустрый Гонсалес - Логан Гоинс – написал эксплойт эксплуатирующий уязвимость и опубликовал его на GitHub с подробной инструкцией с картинками.
Т.е. перевел теоретический сценарий атаки в практическую плоскость, сделав ее доступной каждому сельскому пионеру и самому последнему сявке на «раёне». После чего можем ждать вала атак куда только смогут дотянуться юные и не очень пионеры.
С одной стороны – это не первый случай и не последний. Но публикация рабочего эксплойта к серверному продукту Microsoft на ресурсе контролируемом Microsoft, причем от собственного имени – это что-то новенькое.
Там или совсем мышей не ловят или что-то поменялось в консерватории и теперь такие действия вполне допустимы под видом «исследований».
Хотя с точки зрения российского законодательства тут явный состав уголовного преступления:
Статья 273. Создание, использование и распространение вредоносных компьютерных программ
1. Создание, распространение или использование компьютерных программ либо иной компьютерной информации, заведомо предназначенных для несанкционированного уничтожения, блокирования, модификации, копирования компьютерной информации или нейтрализации средств защиты компьютерной информации, -
наказываются ограничением свободы на срок до четырех лет, либо принудительными работами на срок до четырех лет, либо лишением свободы на тот же срок со штрафом в размере до двухсот тысяч рублей или в размере заработной платы или иного дохода осужденного за период до восемнадцати месяцев.
И подобные нормы есть в законодательстве любой развитой (и не очень) страны. Потому как публикация эксплойта для незакрытой уязвимости – это именно создание и распространение вредоносного ПО.
Но что-то подсказывает мне, что попробуй сейчас тронуть этого шустрого Гонсалеса – как поднимется шум до небес по теме преследования «свободных исследователей», ущемления и прищемления, а также прочего угнетения темными силами всего светлого и толерантного.
В такие вот времена живем…
Исследование уязвимостей в программном обеспечении – тема тонкая, особенно в той ее части, которая касается обнародования результатов исследований. Здесь нужно действовать аналогично докторам, в первую очередь руководствуясь принципом «не навреди».
Действительно, не вовремя опубликованная информация об уязвимости может быть использована злоумышленниками и нанесет серьезный вред законопослушным пользователям.
В тоже время полное замалчивание проблем тоже не является правильной стратегией, уязвимость может быть обнаружена разными исследователями и не все из них играют на светлой стороне.
Поэтому сложилась определенная практика, когда данные об уязвимостях публикуются, но без лишних технических подробностей, особенно если для них еще нет официальных исправлений.
Но последнее время в данной отрасли творится что-то непонятное, если не сказать – беспредельное.
Не так давно в Windows Server 2025 была обнаружена уязвимость под названием BadSuccessor, которая позволяет получить полномочия администратора домена располагая в нем минимальными правами.
Атака достаточно непростая технически и Microsoft классифицировала ее как уязвимость «умеренной серьезности» и пока не выпустила оперативного исправления.
И все бы ничего, но некий шустрый Гонсалес - Логан Гоинс – написал эксплойт эксплуатирующий уязвимость и опубликовал его на GitHub с подробной инструкцией с картинками.
Т.е. перевел теоретический сценарий атаки в практическую плоскость, сделав ее доступной каждому сельскому пионеру и самому последнему сявке на «раёне». После чего можем ждать вала атак куда только смогут дотянуться юные и не очень пионеры.
С одной стороны – это не первый случай и не последний. Но публикация рабочего эксплойта к серверному продукту Microsoft на ресурсе контролируемом Microsoft, причем от собственного имени – это что-то новенькое.
Там или совсем мышей не ловят или что-то поменялось в консерватории и теперь такие действия вполне допустимы под видом «исследований».
Хотя с точки зрения российского законодательства тут явный состав уголовного преступления:
Статья 273. Создание, использование и распространение вредоносных компьютерных программ
1. Создание, распространение или использование компьютерных программ либо иной компьютерной информации, заведомо предназначенных для несанкционированного уничтожения, блокирования, модификации, копирования компьютерной информации или нейтрализации средств защиты компьютерной информации, -
наказываются ограничением свободы на срок до четырех лет, либо принудительными работами на срок до четырех лет, либо лишением свободы на тот же срок со штрафом в размере до двухсот тысяч рублей или в размере заработной платы или иного дохода осужденного за период до восемнадцати месяцев.
И подобные нормы есть в законодательстве любой развитой (и не очень) страны. Потому как публикация эксплойта для незакрытой уязвимости – это именно создание и распространение вредоносного ПО.
Но что-то подсказывает мне, что попробуй сейчас тронуть этого шустрого Гонсалеса – как поднимется шум до небес по теме преследования «свободных исследователей», ущемления и прищемления, а также прочего угнетения темными силами всего светлого и толерантного.
В такие вот времена живем…
Режимы кеширования виртуальных дисков KVM в Proxmox VE
Производительность дисковой подсистемы очень часто является узким местом многих вычислительных систем, и каждый системный администратор сталкивался и сталкивается с необходимостью оптимизации процессов обмена с накопителями.
Одним из эффективных решений, позволяющих ускорить операции ввода - вывода является кеширование. Proxmox предлагает для виртуальных дисков KVM несколько режимов кеширования, в данной статье мы рассмотрим, как они работают, а также их достоинства и недостатки.
https://interface31.ru/tech_it/2023/01/rezhimy-keshirovaniya-virtual-nyh-diskov-kvm-v-proxmox-ve.html
Производительность дисковой подсистемы очень часто является узким местом многих вычислительных систем, и каждый системный администратор сталкивался и сталкивается с необходимостью оптимизации процессов обмена с накопителями.
Одним из эффективных решений, позволяющих ускорить операции ввода - вывода является кеширование. Proxmox предлагает для виртуальных дисков KVM несколько режимов кеширования, в данной статье мы рассмотрим, как они работают, а также их достоинства и недостатки.
https://interface31.ru/tech_it/2023/01/rezhimy-keshirovaniya-virtual-nyh-diskov-kvm-v-proxmox-ve.html
Ваш Zabbix напрасно поднимает панику, у нас еще много памяти
Не столь давно, после внедрения Zabbix один из заказчиков пожаловался, что Zabbix начал присылать сообщения о том, что недостаточно оперативной памяти, но на самом деле памяти еще достаточно.
На вопрос откуда такая уверенность нам кивнули на веб-интерфейс Proxmox из которого выходило, что памяти действительно еще хватает.
Так что, Zabbix неправильно считает память или напрасно нагнетает панику? Вовсе нет, давайте разбираться.
Давайте возьмем еще один хост с Proxmox и посмотрим, судя по графику у нас в запасе еще около 10 ГБ свободной памяти, неплохо.
Но если запустим команду:
При этом у нас 3,8 ГБ разделяемой памяти и 8,3 ГБ буферной/кеша.
Внимательный читатель, вооружившись калькулятором, скажет: стоп, что-то не сходятся у вас доходы с расходами.
Но в Linux есть некоторая особенность. Неактивные страницы памяти считаются занятыми, так как содержат некоторые полезные данные. В тоже время они считаются доступными, так как могут быть немедленно освобождены и переданы нуждающемуся в памяти процессу.
Т.е. если мы сложим вместе
Теперь давайте разберемся что значит каждый вид памяти:
▫️ used – использованная, память которая напрямую используется рабочими процессами в системе
▫️ free – свободная, это память которая не используется ни одним процессом и может быть выделена незамедлительно.
▫️ shared – разделяемая, используется для ускорения межпроцессного взаимодействия, что позволяет исключить передачу информации между процессами через ядро.
▫️ buff/cache – буфер ввода-вывода и кеш VFS (виртуальной файловой системы), играет очень важную роль, так как позволяет разместить в памяти наиболее часто запрашиваемые данные, системные библиотеки и т.п.
▫️ available – доступная, память которая может быть выделена процессу без обращения к пространствам подкачки.
И именно доступная (available) память наиболее точно отображает положение дел с наличием памяти в системе, и именно она используется в триггерах Zabbix.
Proxmox же просто показывает нам used, а остальное помечает свободным. Исходя из этого у нас имеется 10 ГБ «свободной» памяти, на самом деле нам доступно только 6 ГБ, где остальное?
А дело в том, что кеш тоже имеет важное значение для производительности системы и его сброс может привести к обратному эффекту – начнется интенсивное обращение к диску и общая производительность системы резко упадет.
Поэтому разные участки кеша и буферов тоже имеют собственный вес и этот вес может давать им преимущество над запущенными процессами.
В некоторых случаях система может решить, что освобождать кеш дорого и дешевле будет отправить некоторые страницы памяти в подкачку или вовсе позвать OOM Killer и пристрелить какой-нибудь жирный процесс. 🔫🔫🔫
Собственно, это мы и видим в данном случае - 4.7 ГБ памяти содержит «дорогой» кеш и не сможет быть быстро освобождена. Точнее, система будет держаться за этот кеш до последнего, потому что после его очистки плохо станет всем, а пристрелят или отправят в своп только некоторых.
Поэтому в данном случае Zabbix прав, с чем наши заказчики скоро столкнулись, когда OOM Killer начал выключать одну из малоактивных виртуалок.
Поэтому при любых непонятках с памятью ориентируйтесь не на графики и показания различных консолей, а проанализируйте ее использование при помощи команды
Не столь давно, после внедрения Zabbix один из заказчиков пожаловался, что Zabbix начал присылать сообщения о том, что недостаточно оперативной памяти, но на самом деле памяти еще достаточно.
На вопрос откуда такая уверенность нам кивнули на веб-интерфейс Proxmox из которого выходило, что памяти действительно еще хватает.
Так что, Zabbix неправильно считает память или напрасно нагнетает панику? Вовсе нет, давайте разбираться.
Давайте возьмем еще один хост с Proxmox и посмотрим, судя по графику у нас в запасе еще около 10 ГБ свободной памяти, неплохо.
Но если запустим команду:
free -h
То картина существенно изменится, как оказывается свободной памяти у нас всего 2,2 ГБ, а доступной 6,3 ГБ.При этом у нас 3,8 ГБ разделяемой памяти и 8,3 ГБ буферной/кеша.
Внимательный читатель, вооружившись калькулятором, скажет: стоп, что-то не сходятся у вас доходы с расходами.
Но в Linux есть некоторая особенность. Неактивные страницы памяти считаются занятыми, так как содержат некоторые полезные данные. В тоже время они считаются доступными, так как могут быть немедленно освобождены и переданы нуждающемуся в памяти процессу.
Т.е. если мы сложим вместе
used + shared + buff/cache то полученное значение не будет соответствовать total – free. Теперь давайте разберемся что значит каждый вид памяти:
▫️ used – использованная, память которая напрямую используется рабочими процессами в системе
▫️ free – свободная, это память которая не используется ни одним процессом и может быть выделена незамедлительно.
▫️ shared – разделяемая, используется для ускорения межпроцессного взаимодействия, что позволяет исключить передачу информации между процессами через ядро.
▫️ buff/cache – буфер ввода-вывода и кеш VFS (виртуальной файловой системы), играет очень важную роль, так как позволяет разместить в памяти наиболее часто запрашиваемые данные, системные библиотеки и т.п.
▫️ available – доступная, память которая может быть выделена процессу без обращения к пространствам подкачки.
И именно доступная (available) память наиболее точно отображает положение дел с наличием памяти в системе, и именно она используется в триггерах Zabbix.
Proxmox же просто показывает нам used, а остальное помечает свободным. Исходя из этого у нас имеется 10 ГБ «свободной» памяти, на самом деле нам доступно только 6 ГБ, где остальное?
А дело в том, что кеш тоже имеет важное значение для производительности системы и его сброс может привести к обратному эффекту – начнется интенсивное обращение к диску и общая производительность системы резко упадет.
Поэтому разные участки кеша и буферов тоже имеют собственный вес и этот вес может давать им преимущество над запущенными процессами.
В некоторых случаях система может решить, что освобождать кеш дорого и дешевле будет отправить некоторые страницы памяти в подкачку или вовсе позвать OOM Killer и пристрелить какой-нибудь жирный процесс. 🔫🔫🔫
Собственно, это мы и видим в данном случае - 4.7 ГБ памяти содержит «дорогой» кеш и не сможет быть быстро освобождена. Точнее, система будет держаться за этот кеш до последнего, потому что после его очистки плохо станет всем, а пристрелят или отправят в своп только некоторых.
Поэтому в данном случае Zabbix прав, с чем наши заказчики скоро столкнулись, когда OOM Killer начал выключать одну из малоактивных виртуалок.
Поэтому при любых непонятках с памятью ориентируйтесь не на графики и показания различных консолей, а проанализируйте ее использование при помощи команды
free.
Некоторые особенности расхода ресурса SSD или кому верить?
Сегодня один наш коллега обратил наше внимание на значение счетчиков отдаваемых S.M.A.R.T., а точнее на их несоответствие.
Есть два диска Kingston KC600 на 1024 ГБ с заявленным ресурсом записи 600 ТБ. Данные диски отдают в S.M.A.R.T. не только процент оставшегося ресурса, но и количество записанных данных блоками по 32 МБ.
Что привлекло внимание и насторожило? Согласно полученным данным износ первого диска составил 14%, а второго 18%. При заявленном ресурсе это должно соответствовать 84 ТБ и 108ТБ записанных данных.
Однако реально диски записали 53 ТБ и 52 ТБ, причем больший износ оказался у того диска, что записал меньше.
Странно…
Но внизу есть у нас еще один показатель - TLCWrites32MiB – который показывает количество блоков по 32 МБ, реально записанных в TLC. Здесь мы как раз можем оценить такой параметр как усиление записи (write amplification).
Путем несложных вычислений для первого диска получим 465 ТБ, что соответствует коэффициенту WA 8,7. Это говорит о том, что фактически на один записанный логический блок диск делает примерно 9 записей. Данный коэффициент не является постоянным и зависит от характера записи, единовременного объема, прошивки диска, параметров кеширования и т.д. и т.п.
У второго диска этот параметр оказался еще выше, при меньшем количестве логических записей – 566 ТБ. И это как раз соответствует показанному самим диском износу. Что касается усиления записи, то этот коэффициент для второго диска еще выше – 10,9, т.е. 11 физических записей на 1 логическую.
Сами абсолютные цифры записи в TLC никакого практического интереса не представляют, так как мы не знаем верхнего порога по этому параметру. Нет, зная процент износа и абсолютное значение мы можем рассчитать верхний порог, но зачем?
В отрыве от процентов это просто сферические цифры в вакууме. Поэтому счетчика в процентах нам достаточно, а запись в TLC без процентов лишена практического смысла.
И вот тут мы подходим к вопросу: а кому верить?
В первую очередь надо верить счетчику диска в процентах износа. Он рассчитывается на основе реального количества записи в TLC, где ресурс измеряется не в единицах объема данных, а в количестве перезаписей ячеек.
Заявленный в описании диска ресурс – TBW – это некое среднее по больнице количество записанных данных с учетом некого среднего коэффициента усиления WA. Ориентироваться на него можно, брать за некую константу нельзя.
Потому что даже если вы знаете ресурс и знаете средний объем ежедневно записываемых данных, то вы все равно не знаете для какого WA рассчитан этот ресурс и какой у вас фактический WA.
Что касается наших дисков, то для них можно попробовать рассчитать реальный ресурс по логической записи. Для первого диска он получится 378 ТБ, для второго 288 ТБ. Т.е. фактически вдвое меньше заявленного.
Это, кстати, объясняет и различные заявления в духе «диск А – отстой, помер, не выработав и половины ресурса», или «диски В – круть, работают вдвое больше заявленного».
На самом деле и тот и другой диск работают в рамках доступного ресурса перезаписи ячеек памяти, который в среднем по больнице одинаковый, а вот WA у каждого разный и поэтому итоговый результат, выраженный в объеме логической записи, может сильно различаться.
Как быть? Если диск предоставляет данные в износе в процентах – ориентируемся только на них. Если таких данных нет, то берем в расчет логическую запись, но ставим триггер далеко от пороговых значений.
Где именно начинать бить тревогу? Сложный вопрос, но при отсутствии в S.M.A.R.T. иных показателей о замене диска следует начинать задумываться после того, как ресурс снизится более чем на 50%.
Сегодня один наш коллега обратил наше внимание на значение счетчиков отдаваемых S.M.A.R.T., а точнее на их несоответствие.
Есть два диска Kingston KC600 на 1024 ГБ с заявленным ресурсом записи 600 ТБ. Данные диски отдают в S.M.A.R.T. не только процент оставшегося ресурса, но и количество записанных данных блоками по 32 МБ.
Что привлекло внимание и насторожило? Согласно полученным данным износ первого диска составил 14%, а второго 18%. При заявленном ресурсе это должно соответствовать 84 ТБ и 108ТБ записанных данных.
Однако реально диски записали 53 ТБ и 52 ТБ, причем больший износ оказался у того диска, что записал меньше.
Странно…
Но внизу есть у нас еще один показатель - TLCWrites32MiB – который показывает количество блоков по 32 МБ, реально записанных в TLC. Здесь мы как раз можем оценить такой параметр как усиление записи (write amplification).
Путем несложных вычислений для первого диска получим 465 ТБ, что соответствует коэффициенту WA 8,7. Это говорит о том, что фактически на один записанный логический блок диск делает примерно 9 записей. Данный коэффициент не является постоянным и зависит от характера записи, единовременного объема, прошивки диска, параметров кеширования и т.д. и т.п.
У второго диска этот параметр оказался еще выше, при меньшем количестве логических записей – 566 ТБ. И это как раз соответствует показанному самим диском износу. Что касается усиления записи, то этот коэффициент для второго диска еще выше – 10,9, т.е. 11 физических записей на 1 логическую.
Сами абсолютные цифры записи в TLC никакого практического интереса не представляют, так как мы не знаем верхнего порога по этому параметру. Нет, зная процент износа и абсолютное значение мы можем рассчитать верхний порог, но зачем?
В отрыве от процентов это просто сферические цифры в вакууме. Поэтому счетчика в процентах нам достаточно, а запись в TLC без процентов лишена практического смысла.
И вот тут мы подходим к вопросу: а кому верить?
В первую очередь надо верить счетчику диска в процентах износа. Он рассчитывается на основе реального количества записи в TLC, где ресурс измеряется не в единицах объема данных, а в количестве перезаписей ячеек.
Заявленный в описании диска ресурс – TBW – это некое среднее по больнице количество записанных данных с учетом некого среднего коэффициента усиления WA. Ориентироваться на него можно, брать за некую константу нельзя.
Потому что даже если вы знаете ресурс и знаете средний объем ежедневно записываемых данных, то вы все равно не знаете для какого WA рассчитан этот ресурс и какой у вас фактический WA.
Что касается наших дисков, то для них можно попробовать рассчитать реальный ресурс по логической записи. Для первого диска он получится 378 ТБ, для второго 288 ТБ. Т.е. фактически вдвое меньше заявленного.
Это, кстати, объясняет и различные заявления в духе «диск А – отстой, помер, не выработав и половины ресурса», или «диски В – круть, работают вдвое больше заявленного».
На самом деле и тот и другой диск работают в рамках доступного ресурса перезаписи ячеек памяти, который в среднем по больнице одинаковый, а вот WA у каждого разный и поэтому итоговый результат, выраженный в объеме логической записи, может сильно различаться.
Как быть? Если диск предоставляет данные в износе в процентах – ориентируемся только на них. Если таких данных нет, то берем в расчет логическую запись, но ставим триггер далеко от пороговых значений.
Где именно начинать бить тревогу? Сложный вопрос, но при отсутствии в S.M.A.R.T. иных показателей о замене диска следует начинать задумываться после того, как ресурс снизится более чем на 50%.
VPN и сетевое окружение
Самый часто задаваемый вопрос в комментариях к статьям о VPN звучит примерно так: я настроил VPN, настроил маршрутизацию, компьютеры в удаленной сети пингуются, но в сетевом окружении их не видно, что я сделал не так?
Когда поясняешь, что все так и сетевое обнаружение компьютеров за VPN не видит, то сразу спрашивают, а как сделать так, чтобы увидела.
Здесь мы подходим к принципу работы сетевого окружения. Каким образом компьютер в одноранговой сети может найти своих соседей?
Примерно также, как человек в лесу ищет другого человека.
Компьютер, если проводить аналогию, громко кричит на всю сеть: «эй, есть здесь кто-нибудь?»
А ему каждый активный узел отвечает: «есть, меня зовут Имярек»
Если говорить сетевым языком, то ПК отправляет широковещательный пакет, на который активные узлы отправляют ответы.
Фактически, каждый раз открывая сетевое окружение вы устраиваете такую перекличку. И кроме вас таких участников сети хватает.
Ну ладно, это мы поняли, но в чем же проблема? Сколько там того трафика? Тем более в наш век, когда гигабит как норма жизни.
Но давайте спустимся с этих сияющих высот на уровень L2 модели OSI, называемый также канальным, так как именно он отвечает за работу сети.
Каждый порт коммутатора, а на L2 мы работаем именно с коммутаторами, может передавать кадр только от одного узла сети. Также обратим ваше внимание, что здесь у нас кадры, а не пакеты.
Реальная скорость коммутатора определяется не мегабитами и мегабайтами в секунду, а количеством кадров в единицу времени. Скорость же будет зависеть от размера кадров.
Здесь можно провести аналогию с лифтом. Вот вам надо поднять на этаж шкаф, и вы стоите ждете грузовой лифт, а на лифте катаются мальчики и он практически пустой ездит между этажами, а вы с грузом стоите и ждете.
Вот так и широковещание, сами широковещательные кадры небольшие, но они как эти мальчики, фактически гоняют сеть впустую, а важные данные вынуждены ожидать своей очереди. И чем больше широковещания, тем больше у нас таких мальчиков.
Благо, широковещание ограничено широковещательным доменом, читай физической сетью, так как выполняется на канальном уровне, а широковещательный домен, по сути, совокупность портов всех коммутаторов сети.
Современные протоколы сетевого окружения, в отличии от NETBIOS работавшего на броадкасте, используют мультикаст, что немного снижает нагрузку на сеть, но принципиально вопроса не решает.
Если пояснять на пальцах, то сетевые устройства теперь уже не орут на всю сеть «есть тут кто-нибудь?», а сначала вступают в группу в мессенджере и устраивают переклички уже там.
Это снижает объем широковещания, но целиком проблему не снижает.
А причем тут VPN, спросите вы? А при том, что желание видеть устройства за VPN в сетевом окружении аналогично желанию устраивать подобные переклички не только в своей, но и в удаленных сетях.
А теперь представьте, к чему это может привести, ведь ваш ПК не один такой и VPN может связывать самые разные сети в самой разной топологии. По факту в сети будет стоять сплошной ор и для полезного трафика там останется совсем мало места.
Поэтому все широковещательные протоколы сетевого обнаружения работают только в пределах своей сети.
А для доступа к удаленным узлам используйте IP-адреса или доменные имена.
И даже в локальной сети не следует лишний раз использовать сетевое окружение, потому что пользователь, желая просто попасть в общую папку на файловом сервере будет устраивать никому не нужные переклички.
Поэтому подключайте сетевые диски, используйте ярлыки и вообще старайтесь следовать прямыми путями, накричаться еще успеете.
Самый часто задаваемый вопрос в комментариях к статьям о VPN звучит примерно так: я настроил VPN, настроил маршрутизацию, компьютеры в удаленной сети пингуются, но в сетевом окружении их не видно, что я сделал не так?
Когда поясняешь, что все так и сетевое обнаружение компьютеров за VPN не видит, то сразу спрашивают, а как сделать так, чтобы увидела.
Здесь мы подходим к принципу работы сетевого окружения. Каким образом компьютер в одноранговой сети может найти своих соседей?
Примерно также, как человек в лесу ищет другого человека.
Компьютер, если проводить аналогию, громко кричит на всю сеть: «эй, есть здесь кто-нибудь?»
А ему каждый активный узел отвечает: «есть, меня зовут Имярек»
Если говорить сетевым языком, то ПК отправляет широковещательный пакет, на который активные узлы отправляют ответы.
Фактически, каждый раз открывая сетевое окружение вы устраиваете такую перекличку. И кроме вас таких участников сети хватает.
Ну ладно, это мы поняли, но в чем же проблема? Сколько там того трафика? Тем более в наш век, когда гигабит как норма жизни.
Но давайте спустимся с этих сияющих высот на уровень L2 модели OSI, называемый также канальным, так как именно он отвечает за работу сети.
Каждый порт коммутатора, а на L2 мы работаем именно с коммутаторами, может передавать кадр только от одного узла сети. Также обратим ваше внимание, что здесь у нас кадры, а не пакеты.
Реальная скорость коммутатора определяется не мегабитами и мегабайтами в секунду, а количеством кадров в единицу времени. Скорость же будет зависеть от размера кадров.
Здесь можно провести аналогию с лифтом. Вот вам надо поднять на этаж шкаф, и вы стоите ждете грузовой лифт, а на лифте катаются мальчики и он практически пустой ездит между этажами, а вы с грузом стоите и ждете.
Вот так и широковещание, сами широковещательные кадры небольшие, но они как эти мальчики, фактически гоняют сеть впустую, а важные данные вынуждены ожидать своей очереди. И чем больше широковещания, тем больше у нас таких мальчиков.
Благо, широковещание ограничено широковещательным доменом, читай физической сетью, так как выполняется на канальном уровне, а широковещательный домен, по сути, совокупность портов всех коммутаторов сети.
Современные протоколы сетевого окружения, в отличии от NETBIOS работавшего на броадкасте, используют мультикаст, что немного снижает нагрузку на сеть, но принципиально вопроса не решает.
Если пояснять на пальцах, то сетевые устройства теперь уже не орут на всю сеть «есть тут кто-нибудь?», а сначала вступают в группу в мессенджере и устраивают переклички уже там.
Это снижает объем широковещания, но целиком проблему не снижает.
А причем тут VPN, спросите вы? А при том, что желание видеть устройства за VPN в сетевом окружении аналогично желанию устраивать подобные переклички не только в своей, но и в удаленных сетях.
А теперь представьте, к чему это может привести, ведь ваш ПК не один такой и VPN может связывать самые разные сети в самой разной топологии. По факту в сети будет стоять сплошной ор и для полезного трафика там останется совсем мало места.
Поэтому все широковещательные протоколы сетевого обнаружения работают только в пределах своей сети.
А для доступа к удаленным узлам используйте IP-адреса или доменные имена.
И даже в локальной сети не следует лишний раз использовать сетевое окружение, потому что пользователь, желая просто попасть в общую папку на файловом сервере будет устраивать никому не нужные переклички.
Поэтому подключайте сетевые диски, используйте ярлыки и вообще старайтесь следовать прямыми путями, накричаться еще успеете.
О пользе систем управление конфигурациями или тайная жизнь ваших сетевых устройств
Не так давно мы рассказывали о том, как установить и настроить свободную систему управления конфигурациями Oxidized.
🔹 Устанавливаем и настраиваем систему управления конфигурациями сетевого оборудования Oxidized
И тогда в комментариях многие писали, мол зачем так все сложно, я скриптами быстрее бекап сделаю.
Но дело в том, что Oxidized – это не бекап, резервное копирование только одна из его функций. Гораздо более ценная и полезная – это система контроля изменений, основанная на Git.
Она позволяет быстро и эффективно выявлять все внесенные в конфигурацию изменения и при необходимости также быстро их сравнивать, объединять или откатывать.
При этом анализ внесенных в конфигурацию изменений помогает выявить разные скрытые от глаз процессы.
Чтобы не быть голословными расскажем одну реальную историю.
Не так давно мы внедрили новому заказчику Oxidized и через некоторое время обнаружили что конфигурация некоторых роутеров меняется.
Мы никаких изменений не вносили, персонал заказчика тоже, поэтому мысли возникли всякие, во многом нехорошие.
Но нет, роутеры никто не взломал, оказалось они тоже могут жить своей жизнью. В частности, на некоторых роутерах самопроизвольно переключался часовой пояс. С Москвы на Самару и обратно.
Таким вот образом почему-то работало автоматическое обнаружение часового пояса.
На первый взгляд довольно незначительная ерунда, особо ни на что не влияющая. И это действительно так. При общении между собой устройства используют время UTC и серьезных проблем быть не должно.
Но могут быть проблемы с анализом логов, когда вы будете искать там события по московскому времени, а они окажутся по самарскому, т.е. на час больше.
И вряд ли кто-то, не находя в логе нужных событий пойдет первым делом проверять часовой пояс.
Но речь совершенно не об этом. Вместо часового пояса там могло быть все что угодно. Речь здесь о другом, что именно благодаря системе управления конфигурациями нам открылась тайная жизнь сетевых устройств, о которой мы даже не догадывались.
Поэтому регулярный контроль изменений, особенно если вы их не вносили, дает администратору возможность выявить и устранить нестандартное поведение устройства, либо на ранних стадиях обнаружить несанкционированный доступ.
Ни одна система резервного копирования таких возможностей не предоставляет, а сравнивать конфигурации в бекапах тем более никто руками не будет.
Не так давно мы рассказывали о том, как установить и настроить свободную систему управления конфигурациями Oxidized.
🔹 Устанавливаем и настраиваем систему управления конфигурациями сетевого оборудования Oxidized
И тогда в комментариях многие писали, мол зачем так все сложно, я скриптами быстрее бекап сделаю.
Но дело в том, что Oxidized – это не бекап, резервное копирование только одна из его функций. Гораздо более ценная и полезная – это система контроля изменений, основанная на Git.
Она позволяет быстро и эффективно выявлять все внесенные в конфигурацию изменения и при необходимости также быстро их сравнивать, объединять или откатывать.
При этом анализ внесенных в конфигурацию изменений помогает выявить разные скрытые от глаз процессы.
Чтобы не быть голословными расскажем одну реальную историю.
Не так давно мы внедрили новому заказчику Oxidized и через некоторое время обнаружили что конфигурация некоторых роутеров меняется.
Мы никаких изменений не вносили, персонал заказчика тоже, поэтому мысли возникли всякие, во многом нехорошие.
Но нет, роутеры никто не взломал, оказалось они тоже могут жить своей жизнью. В частности, на некоторых роутерах самопроизвольно переключался часовой пояс. С Москвы на Самару и обратно.
Таким вот образом почему-то работало автоматическое обнаружение часового пояса.
На первый взгляд довольно незначительная ерунда, особо ни на что не влияющая. И это действительно так. При общении между собой устройства используют время UTC и серьезных проблем быть не должно.
Но могут быть проблемы с анализом логов, когда вы будете искать там события по московскому времени, а они окажутся по самарскому, т.е. на час больше.
И вряд ли кто-то, не находя в логе нужных событий пойдет первым делом проверять часовой пояс.
Но речь совершенно не об этом. Вместо часового пояса там могло быть все что угодно. Речь здесь о другом, что именно благодаря системе управления конфигурациями нам открылась тайная жизнь сетевых устройств, о которой мы даже не догадывались.
Поэтому регулярный контроль изменений, особенно если вы их не вносили, дает администратору возможность выявить и устранить нестандартное поведение устройства, либо на ранних стадиях обнаружить несанкционированный доступ.
Ни одна система резервного копирования таких возможностей не предоставляет, а сравнивать конфигурации в бекапах тем более никто руками не будет.
Самодеятельность, художественная и не очень
Скрипты, как много в этом слове. Я думаю, что у каждого сисадмина в жизни был период, когда он на каждый чих сочинял собственный скрипт.
Как будто это что-то плохое, скажет иной читатель. Ну да как посмотреть, с какой точки зрения.
Начнем с точки зрения самого админа, если админ постоянный, на зарплате, то ему может показаться что ничего страшного в этом нет. Инфраструктура моя, скрипты мои, я все знаю, что может пойти не так?
Мы уже промолчим о том, что все скрипты должны быть документированы. По факту это очень и очень больной вопрос. Даже если изначальная версия скрипта таки прокомментирована и задокументирована, то последующие правки в него этого часто не удостаиваются, особенно мелкие и срочные. Потом это все копится и накладывается, ну вы поняли…
Так в чем же проблема собственных скриптов? Основная проблема в «эффекте автобуса», да да, это про того самого разработчика, который попал под автобус. Причем понимать это надо не буквально, а в том смысле, что неожиданный уход разработчика из проекта делает все эти скрипты бомбой замедленного действия.
Почему так? Про неполноту документации мы уже писали. К этому накладывается еще и дополнительный эффект «это все знают». Разработчик мог вполне сознательно опустить в документации некоторые, очевидные для него, моменты. Которые могут оказаться непонятны окружающим.
Далее сами скрипты. Очень многие скриптовые языки позволяют писать двумя способами: быстро, рационально, но нечитаемо или долго, неоптимально, но читаемо. Надо ли говорить, что чаще всего превалирует первый подход, особенно среди админов-«староверов», которые не используют современные среды разработки с синтаксис-помощниками и автодополнением, а ваяют скрипты буквально на коленках.
Мы, как аутсорсеры, очень часто встречались с такими скриптами, про которые никто ничего не знает и трогать откровенно боится, а написавший их товарищ давно растворился в тумане.
Ничего хорошего в этом нет, равно как и разобраться с ними за разумное время и деньги не представляется возможным. Но самая «мякотка» состоит в том, что они дублируют те возможности и функции, которые могут быть получены штатными пакетами или распространенным и широко известным сторонним софтом.
Да ладно, снова скажет кто-то, зачем тащить целый пакет, когда тут можно десятком другим строк обойтись.
А вот и нет, пакет тащить нужно, потому что ожидаемая конфигурация и ожидаемое поведение системы, в отличие от скрипта. И не важно, что это не красиво, не оптимально, не эффективно, не соответствуем вашим религиозным воззрениями (нужное подчеркнуть).
Причем наступить на эти грабли можно совершенно случайно. Для этого не нужно даже попадать под автобус. Достаточно уехать в отпуск и оказаться на некоторое время без связи.
Если в это время возникнет некоторая нештатная ситуация и коллеги не смогут разобраться в вашем творчестве, то по возвращению вас ждет достаточно неприятный разговор.
Потому что платят вам не за смелые эксперименты и самовыражение, а за поддержание инфраструктуры в стабильном, управляемом и предсказуемом виде, что подразумевает максимальную стандартизацию.
Любое нестандартное решение – это дополнительные затраты на поддержу (часто косвенные) и дополнительные риски, связанные с нестандартностью. Во многих случаях абсолютно неуместные.
А желание отдельных сотрудников использовать собственные костыли к месту и не к месту заставляет серьезно задуматься в плане их профпригодности, причем не в техническом плане (тут обычно все в порядке), а в социальном, в способности работать в коллективе и ставить общественные интересы выше собственных.
Ну а мораль сей басни проста: если есть стандартные и общепринятые решения – то следует их использовать, даже если вы можете за пять минут левым задним копытом набросать скрипт «в 1000 раз лучше».
Ну или пишите и выкладывайте его на GitHub и когда его начнут включать в дистрибутивы и использовать массы – тогда можно будет использовать его как стандартное решение.
Скрипты, как много в этом слове. Я думаю, что у каждого сисадмина в жизни был период, когда он на каждый чих сочинял собственный скрипт.
Как будто это что-то плохое, скажет иной читатель. Ну да как посмотреть, с какой точки зрения.
Начнем с точки зрения самого админа, если админ постоянный, на зарплате, то ему может показаться что ничего страшного в этом нет. Инфраструктура моя, скрипты мои, я все знаю, что может пойти не так?
Мы уже промолчим о том, что все скрипты должны быть документированы. По факту это очень и очень больной вопрос. Даже если изначальная версия скрипта таки прокомментирована и задокументирована, то последующие правки в него этого часто не удостаиваются, особенно мелкие и срочные. Потом это все копится и накладывается, ну вы поняли…
Так в чем же проблема собственных скриптов? Основная проблема в «эффекте автобуса», да да, это про того самого разработчика, который попал под автобус. Причем понимать это надо не буквально, а в том смысле, что неожиданный уход разработчика из проекта делает все эти скрипты бомбой замедленного действия.
Почему так? Про неполноту документации мы уже писали. К этому накладывается еще и дополнительный эффект «это все знают». Разработчик мог вполне сознательно опустить в документации некоторые, очевидные для него, моменты. Которые могут оказаться непонятны окружающим.
Далее сами скрипты. Очень многие скриптовые языки позволяют писать двумя способами: быстро, рационально, но нечитаемо или долго, неоптимально, но читаемо. Надо ли говорить, что чаще всего превалирует первый подход, особенно среди админов-«староверов», которые не используют современные среды разработки с синтаксис-помощниками и автодополнением, а ваяют скрипты буквально на коленках.
Мы, как аутсорсеры, очень часто встречались с такими скриптами, про которые никто ничего не знает и трогать откровенно боится, а написавший их товарищ давно растворился в тумане.
Ничего хорошего в этом нет, равно как и разобраться с ними за разумное время и деньги не представляется возможным. Но самая «мякотка» состоит в том, что они дублируют те возможности и функции, которые могут быть получены штатными пакетами или распространенным и широко известным сторонним софтом.
Да ладно, снова скажет кто-то, зачем тащить целый пакет, когда тут можно десятком другим строк обойтись.
А вот и нет, пакет тащить нужно, потому что ожидаемая конфигурация и ожидаемое поведение системы, в отличие от скрипта. И не важно, что это не красиво, не оптимально, не эффективно, не соответствуем вашим религиозным воззрениями (нужное подчеркнуть).
Причем наступить на эти грабли можно совершенно случайно. Для этого не нужно даже попадать под автобус. Достаточно уехать в отпуск и оказаться на некоторое время без связи.
Если в это время возникнет некоторая нештатная ситуация и коллеги не смогут разобраться в вашем творчестве, то по возвращению вас ждет достаточно неприятный разговор.
Потому что платят вам не за смелые эксперименты и самовыражение, а за поддержание инфраструктуры в стабильном, управляемом и предсказуемом виде, что подразумевает максимальную стандартизацию.
Любое нестандартное решение – это дополнительные затраты на поддержу (часто косвенные) и дополнительные риски, связанные с нестандартностью. Во многих случаях абсолютно неуместные.
А желание отдельных сотрудников использовать собственные костыли к месту и не к месту заставляет серьезно задуматься в плане их профпригодности, причем не в техническом плане (тут обычно все в порядке), а в социальном, в способности работать в коллективе и ставить общественные интересы выше собственных.
Ну а мораль сей басни проста: если есть стандартные и общепринятые решения – то следует их использовать, даже если вы можете за пять минут левым задним копытом набросать скрипт «в 1000 раз лучше».
Ну или пишите и выкладывайте его на GitHub и когда его начнут включать в дистрибутивы и использовать массы – тогда можно будет использовать его как стандартное решение.
Ремесло или магия?
Все, кто в школе хоть немного учил историю должны знать историю ремесленничества, когда люди, обладающие определенными знаниями и умениями, объединялись в цеха как для защиты от конкуренции, так и для сохранения и преумножения знаний.
Цеха имели трехуровневую структуру: ученик – подмастерье – мастер. Причем чтобы стать последним, нужно было пройти своеобразный экзамен: собственноручно выполнить работу, которая будет одобрена цехом.
Через какое-то время конкурировать с цехами стало сложно, да, мастер-одиночка тоже мог достигнуть определенных высот, но доходя до всего своим умом и методом проб и ошибок, тогда как цех располагал накопленным объемом знаний и системой их передачи от мастера к ученику.
Причем знания передавались дозировано, более сложные знания передавались после того, как ученик усвоил и научился применять на практике более простые.
Этот принцип перешел в образование, там тоже знания передаются дозированно, чтобы более сложные ложились на базис более простых.
А производственные отношения в целом продолжали цеховые традиции, когда более опытные специалисты передавали свои знания и умения молодым, помогая постигнуть все тонкости профессии.
Но наш век информационной доступности спутал все карты. Сейчас ученик, даже не подмастерье, может спокойно получить рецепты мастера и даже попытаться применить их на практике. Только вот станет ли он от этого мастером? Вряд-ли…
Что отличает мастера от ученика или подмастерья? Знания и опыт. Он знает не только как сделать, но и почему нужно делать именно так, а не иначе. И также он знает в каких случаях надо делать именно так, а в каких случаях делать так, наоборот не надо. Не говоря уже о том, что простые пути не всегда самые верные.
Сегодня сеть дает возможность найти большое количество инструкций «от мастеров» и выбор часто делается по принципу: вот эта инструкция проще и мне больше нравится. Ну а то, что писал эту инструкцию совсем не мастер, а захудалый подмастерье, большинству берущих подобные инструкции неведомо.
Главное, что все быстро, просто и дает желаемый результат. На первый взгляд дает. Потому как уровня знаний, дающих возможность всесторонне оценить решение нет. А настоящий мастер, предлагающий правильное, но излишне сложное решение, представляется некоторым занудой.
Ну что ты там нудишь? Видишь, чего я нашел, тяп-ляп и в продакшен. Дешево и практично.
Прозрение наступает поздно и, иногда, с очень неприятными побочными «эффектами».
И иногда думаешь, что правы были цеховые мастера прошлых лет, ибо известно, что многие знания – многие печали, особенно если они достались неокрепшим умам.
Может кто-то посчитает это за профессиональный снобизм, но знания не должны опережать текущий уровень подготовки.
Раньше с этим было попроще, неподготовленного специалиста никто бы не пустил на участок, явно превышающий его квалификацию.
Теперь же есть сеть, в которой можно найти пошаговое описание обрядов и заклинаний, которые, при их тщательном исполнении дадут желаемый результат.
Ну, и как положено настоящей магии, начали появляться различные волшебные артефакты, которые активируются волшебным словом
Таким образом ремесло начинает деградировать до волшебства. А далее знания незаметно уступят обрядам и поклонениям высшим силам. И возникнет новая каста жрецов – редких представителей рода человеческого, которые знают, как это все работает и умеющих находит общий язык с «высшими силами», ну или диктовать их волю «простым смертным» к собственной выгоде.
Возможно, я где-то сгустил краски, но в целом тенденция именно такая. Сегодня уже каждый может стать «мастером» найдя и повторив дословно нужный рецепт. А так как знаний от этого не прибавится, то система будет восприниматься некоторым «волшебным» черным ящиком.
Откуда уже недалеко до настоящих черных ящиков – готовых контейнеров. Да и пес его знает, что там внутри, главное же - слушаются заклинаний...
Все, кто в школе хоть немного учил историю должны знать историю ремесленничества, когда люди, обладающие определенными знаниями и умениями, объединялись в цеха как для защиты от конкуренции, так и для сохранения и преумножения знаний.
Цеха имели трехуровневую структуру: ученик – подмастерье – мастер. Причем чтобы стать последним, нужно было пройти своеобразный экзамен: собственноручно выполнить работу, которая будет одобрена цехом.
Через какое-то время конкурировать с цехами стало сложно, да, мастер-одиночка тоже мог достигнуть определенных высот, но доходя до всего своим умом и методом проб и ошибок, тогда как цех располагал накопленным объемом знаний и системой их передачи от мастера к ученику.
Причем знания передавались дозировано, более сложные знания передавались после того, как ученик усвоил и научился применять на практике более простые.
Этот принцип перешел в образование, там тоже знания передаются дозированно, чтобы более сложные ложились на базис более простых.
А производственные отношения в целом продолжали цеховые традиции, когда более опытные специалисты передавали свои знания и умения молодым, помогая постигнуть все тонкости профессии.
Но наш век информационной доступности спутал все карты. Сейчас ученик, даже не подмастерье, может спокойно получить рецепты мастера и даже попытаться применить их на практике. Только вот станет ли он от этого мастером? Вряд-ли…
Что отличает мастера от ученика или подмастерья? Знания и опыт. Он знает не только как сделать, но и почему нужно делать именно так, а не иначе. И также он знает в каких случаях надо делать именно так, а в каких случаях делать так, наоборот не надо. Не говоря уже о том, что простые пути не всегда самые верные.
Сегодня сеть дает возможность найти большое количество инструкций «от мастеров» и выбор часто делается по принципу: вот эта инструкция проще и мне больше нравится. Ну а то, что писал эту инструкцию совсем не мастер, а захудалый подмастерье, большинству берущих подобные инструкции неведомо.
Главное, что все быстро, просто и дает желаемый результат. На первый взгляд дает. Потому как уровня знаний, дающих возможность всесторонне оценить решение нет. А настоящий мастер, предлагающий правильное, но излишне сложное решение, представляется некоторым занудой.
Ну что ты там нудишь? Видишь, чего я нашел, тяп-ляп и в продакшен. Дешево и практично.
Прозрение наступает поздно и, иногда, с очень неприятными побочными «эффектами».
И иногда думаешь, что правы были цеховые мастера прошлых лет, ибо известно, что многие знания – многие печали, особенно если они достались неокрепшим умам.
Может кто-то посчитает это за профессиональный снобизм, но знания не должны опережать текущий уровень подготовки.
Раньше с этим было попроще, неподготовленного специалиста никто бы не пустил на участок, явно превышающий его квалификацию.
Теперь же есть сеть, в которой можно найти пошаговое описание обрядов и заклинаний, которые, при их тщательном исполнении дадут желаемый результат.
Ну, и как положено настоящей магии, начали появляться различные волшебные артефакты, которые активируются волшебным словом
docker run. Как они работают – неизвестно, да и не нужно. Что-то пошло не так? Убиваем артефакт и активируем новый. Таким образом ремесло начинает деградировать до волшебства. А далее знания незаметно уступят обрядам и поклонениям высшим силам. И возникнет новая каста жрецов – редких представителей рода человеческого, которые знают, как это все работает и умеющих находит общий язык с «высшими силами», ну или диктовать их волю «простым смертным» к собственной выгоде.
Возможно, я где-то сгустил краски, но в целом тенденция именно такая. Сегодня уже каждый может стать «мастером» найдя и повторив дословно нужный рецепт. А так как знаний от этого не прибавится, то система будет восприниматься некоторым «волшебным» черным ящиком.
Откуда уже недалеко до настоящих черных ящиков – готовых контейнеров. Да и пес его знает, что там внутри, главное же - слушаются заклинаний...
Аппаратные часы и системное время
Время – важный параметр современных систем, так как временная метка является одной из переменных в криптографических преобразованиях и отклонение системного времени от точного может привести к различным проблемам.
Но есть и еще один тонкий момент – аппаратные часы – RTC (Real Time Clock), они же часы CMOS / BIOS.
Они отличаются от системных часов, полностью программных, тем, что являются аппаратными и идут даже тогда, когда компьютер выключен. При загрузке система считывает данные аппаратных часов и принимает их за системное время, после чего начинают работать системные часы.
Системные часы мы можем подвести от часов точного времени благодаря протоколу NTP, тем самым обеспечив соответствие системного времени точному. Затем, при выключении (либо можно выполнить эту операцию вручную), система подводит аппаратные часы на материнской плате.
И вот тут возникает ряд тонкостей. Linux считает, что аппаратные часы показывают время UTC (универсальное время, оно же по Гринвичу). Т.е. если в системе мы установили часовой пояс UTC +3 (Москва) и на часах у нас 15:00, то система установит аппаратные часы на 12:00.
Windows же считает что аппаратные часы идут в поясном времени, т.е. если у нас в системе стоит тот же часовой пояс UTC +3 и на часах 15:00, то и в аппаратные часы будет записано такое-же время.
Это вызывало многочисленные приключения при использовании двойной загрузки Linux и Windows на ПК. Но, казалось бы, те времена давно прошли.
Да, сегодня двойная загрузка проходит по разряду экзотики, но на смену ей пришла виртуализация. Многие системы виртуализации поддерживают синхронизацию времени между виртуальной машиной и гипервизором, а службы синхронизации внутри виртуальной машины отключаются, обнаружив себя в виртуалке.
И вот тут начинаются чудеса. Хост отдает виртуалке время как RTC, при этом отдает согласно собственному пониманию. Т.е. хост на Linux отдаст UTC, а хост Windows – поясное время.
В первом случае Linux-гость правильно прибавит к этому значению поясное время и получит правильное значение, а вот Windows будет считать время локальным и будет отставать (или спешить) на разницу между часовым поясом и UTC.
Во втором Windows-гость покажет правильное время, а Linux добавит к нему смещение часового пояса и будет спешить или отставать.
В большинстве случаев это решается в настройках параметров виртуальной машины, но иногда может потребоваться и ручное вмешательство.
Для того чтобы Windows использовал аппаратные часы как UTC выполните:
В Linux для переключения на поясное время и обратно используйте:
Время – важный параметр современных систем, так как временная метка является одной из переменных в криптографических преобразованиях и отклонение системного времени от точного может привести к различным проблемам.
Но есть и еще один тонкий момент – аппаратные часы – RTC (Real Time Clock), они же часы CMOS / BIOS.
Они отличаются от системных часов, полностью программных, тем, что являются аппаратными и идут даже тогда, когда компьютер выключен. При загрузке система считывает данные аппаратных часов и принимает их за системное время, после чего начинают работать системные часы.
Системные часы мы можем подвести от часов точного времени благодаря протоколу NTP, тем самым обеспечив соответствие системного времени точному. Затем, при выключении (либо можно выполнить эту операцию вручную), система подводит аппаратные часы на материнской плате.
И вот тут возникает ряд тонкостей. Linux считает, что аппаратные часы показывают время UTC (универсальное время, оно же по Гринвичу). Т.е. если в системе мы установили часовой пояс UTC +3 (Москва) и на часах у нас 15:00, то система установит аппаратные часы на 12:00.
Windows же считает что аппаратные часы идут в поясном времени, т.е. если у нас в системе стоит тот же часовой пояс UTC +3 и на часах 15:00, то и в аппаратные часы будет записано такое-же время.
Это вызывало многочисленные приключения при использовании двойной загрузки Linux и Windows на ПК. Но, казалось бы, те времена давно прошли.
Да, сегодня двойная загрузка проходит по разряду экзотики, но на смену ей пришла виртуализация. Многие системы виртуализации поддерживают синхронизацию времени между виртуальной машиной и гипервизором, а службы синхронизации внутри виртуальной машины отключаются, обнаружив себя в виртуалке.
И вот тут начинаются чудеса. Хост отдает виртуалке время как RTC, при этом отдает согласно собственному пониманию. Т.е. хост на Linux отдаст UTC, а хост Windows – поясное время.
В первом случае Linux-гость правильно прибавит к этому значению поясное время и получит правильное значение, а вот Windows будет считать время локальным и будет отставать (или спешить) на разницу между часовым поясом и UTC.
Во втором Windows-гость покажет правильное время, а Linux добавит к нему смещение часового пояса и будет спешить или отставать.
В большинстве случаев это решается в настройках параметров виртуальной машины, но иногда может потребоваться и ручное вмешательство.
Для того чтобы Windows использовал аппаратные часы как UTC выполните:
reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /d 1 /t REG_DWORD /f
Чтобы переключиться назад просто удалите этот ключ в реестре.В Linux для переключения на поясное время и обратно используйте:
timedatectl set-local-rtc 1
и timedatectl set-local-rtc 0
Ну и в любом непонятном случае с часами всегда начинайте с того, в каком режиме идут RTC и в каком режиме его воспринимает система.
Как скачать DEB-пакет со всеми зависимостями
Необходимость скачать DEB-пакет со всеми зависимостями для дальнейшей локальной установки возникает не так уж и редко. Это могут быть закрытые системы или системы с невысокой скоростью связи или лимитированным трафиком.
Сделать это весьма просто, причем без всякой особой консольной магии, с использованием штатных возможностей apt.
Все скачанные пакеты система размещает в каталоге
После чего перейдем к скачиванию:
Почему именно
Если вам нужны пакеты другой архитектуры, то ее сначала нужно включить и обновить список пакетов:
После чего точно также делаем:
После чего переходим в
Необходимость скачать DEB-пакет со всеми зависимостями для дальнейшей локальной установки возникает не так уж и редко. Это могут быть закрытые системы или системы с невысокой скоростью связи или лимитированным трафиком.
Сделать это весьма просто, причем без всякой особой консольной магии, с использованием штатных возможностей apt.
Все скачанные пакеты система размещает в каталоге
/var/cache/apt/archives и там, кроме интересующих нас пакетов могут быть и разные другие, поэтому перед скачиванием нужно будет очистить кеш пакетов.apt clean
После чего перейдем к скачиванию:
apt reinstall --download-only package_name
Почему именно
reinstall? Потому что install будет работать только для неустановленных пакетов, а если пакет уже установлен в системе, то она сообщит об этом и не будет производить установку (в нашем случае скачивание, а reinstall скачает пакеты в любом случае.Если вам нужны пакеты другой архитектуры, то ее сначала нужно включить и обновить список пакетов:
dpkg --add-architecture i386
apt update
После чего точно также делаем:
apt reinstall --download-only package_name:i386
После чего переходим в
/var/cache/apt/archives и копируем скачанные пакеты на любой съемный носитель и может передать их любым удобным способом в нужную систему для установки.
Субботнее, о «братьях» наших меньших
Читаю тут время от времени соседские новости и наблюдаю привычную многим картину: террор (а по-другому я тут не скажу) бродячих собак по отношению к местному населению и их питомцам.
Выше два ролика из города Курска, где стая агрессивно атакует домашних питомцев и их хозяев. Но это еще не беда, это ее половина, настоящая беда в отношении местной власти к данной проблеме. Ответ администрации просто убивает, выделение мое:
«28.05.2025г. по адресу: г. Курск, ул. Майский бульвар, д. 27 был осуществлен выезд сотрудников подрядной организации. Отловлена одна собака, а так же установлено наличие собак с метками. В соответствии с действующим Федеральным законом от 27.12.2018г. № 498-ФЗ, животные имеющие, метки отлову не подлежат».
Отлично? Да просто зашибись! Поймали, стерилизовали, повесили бирку и отпустили, где взяли. А бирка, по мнению данных товарищей, сразу сделает собаку доброй и пушистой.
Но собака, как бы не хотелось некоторым отрицать данный факт – стайный хищник, с многовековыми инстинктами на подкорке, которые не вытравливаются оттуда не стерилизацией, ни биркой.
И если собака с биркой в единственном экземпляре может быть доброй, ласковой и пушистой, то в стае – это хищник, машина для убийства. Но на это старательно закрывают глаза.
А если человек, исключительно в целях самообороны, возьмет хороший дрын и нанесет собаченьке увечья несовместимые с нормальной жизнедеятельностью организма, то ему грозит вполне реальное административное или даже уголовное наказание.
И вот здесь логика происходящего от меня полностью ускользает. Бродячая собака может изувечить или вообще убить вашего домашнего питомца, и никто за это отвечать не будет. Может нанести увечья и даже убить человека, ответственность за это снова никто не понесет. Проверено неоднократными случаями. Особенно если у собак есть метка.
Если же человек нанесет увечья или, не приведи Господь, прибьет собаченьку – то проблемы ему гарантированы.
Хотя, по логике вещей, если собака – дикий зверь, а бродячая собака – это именно дикий зверь, угрожает жизни и здоровью человека, то такая собака должна быть ликвидирована, просто и без затей.
Представителям зоошизы, у которых все собаченьки добрые и пушистые, а нападают они только в ответ на агрессию человека, могу предложить забрать таких собак себе домой или просто заткнуть рты и помолчать.
Так вот любой дикий зверь, проявляющий агрессию на человека в его естественной среде обитания (городе, селе – не важно), должен быть быстро и без затей ликвидирован.
Бродячая собака – это именно дикий зверь, далеко не в первом поколении. Выброшенные собаки долго на улице не живут они или не переживают зиму, или становятся жертвами бродячих стай. Так что перекладывать ответственность на человека тут тоже не следует.
Но у нас почему-то существует необъяснимый перекос, когда жизнь и здоровье человека ничего не значит против жизни и здоровья собаки, которая оказывается защищена законом гораздо лучше гражданина и налогоплательщика.
Такой вот парадокс, а вы что думаете по этому поводу?
Читаю тут время от времени соседские новости и наблюдаю привычную многим картину: террор (а по-другому я тут не скажу) бродячих собак по отношению к местному населению и их питомцам.
Выше два ролика из города Курска, где стая агрессивно атакует домашних питомцев и их хозяев. Но это еще не беда, это ее половина, настоящая беда в отношении местной власти к данной проблеме. Ответ администрации просто убивает, выделение мое:
«28.05.2025г. по адресу: г. Курск, ул. Майский бульвар, д. 27 был осуществлен выезд сотрудников подрядной организации. Отловлена одна собака, а так же установлено наличие собак с метками. В соответствии с действующим Федеральным законом от 27.12.2018г. № 498-ФЗ, животные имеющие, метки отлову не подлежат».
Отлично? Да просто зашибись! Поймали, стерилизовали, повесили бирку и отпустили, где взяли. А бирка, по мнению данных товарищей, сразу сделает собаку доброй и пушистой.
Но собака, как бы не хотелось некоторым отрицать данный факт – стайный хищник, с многовековыми инстинктами на подкорке, которые не вытравливаются оттуда не стерилизацией, ни биркой.
И если собака с биркой в единственном экземпляре может быть доброй, ласковой и пушистой, то в стае – это хищник, машина для убийства. Но на это старательно закрывают глаза.
А если человек, исключительно в целях самообороны, возьмет хороший дрын и нанесет собаченьке увечья несовместимые с нормальной жизнедеятельностью организма, то ему грозит вполне реальное административное или даже уголовное наказание.
И вот здесь логика происходящего от меня полностью ускользает. Бродячая собака может изувечить или вообще убить вашего домашнего питомца, и никто за это отвечать не будет. Может нанести увечья и даже убить человека, ответственность за это снова никто не понесет. Проверено неоднократными случаями. Особенно если у собак есть метка.
Если же человек нанесет увечья или, не приведи Господь, прибьет собаченьку – то проблемы ему гарантированы.
Хотя, по логике вещей, если собака – дикий зверь, а бродячая собака – это именно дикий зверь, угрожает жизни и здоровью человека, то такая собака должна быть ликвидирована, просто и без затей.
Представителям зоошизы, у которых все собаченьки добрые и пушистые, а нападают они только в ответ на агрессию человека, могу предложить забрать таких собак себе домой или просто заткнуть рты и помолчать.
Так вот любой дикий зверь, проявляющий агрессию на человека в его естественной среде обитания (городе, селе – не важно), должен быть быстро и без затей ликвидирован.
Бродячая собака – это именно дикий зверь, далеко не в первом поколении. Выброшенные собаки долго на улице не живут они или не переживают зиму, или становятся жертвами бродячих стай. Так что перекладывать ответственность на человека тут тоже не следует.
Но у нас почему-то существует необъяснимый перекос, когда жизнь и здоровье человека ничего не значит против жизни и здоровья собаки, которая оказывается защищена законом гораздо лучше гражданина и налогоплательщика.
Такой вот парадокс, а вы что думаете по этому поводу?