Пятничное, о жизни. Информационный шум.
Мне кажется, если сейчас каким-нибудь образом переместить сюда человека 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
Мы с классной новостью! 💫
В этот четверг, 29 мая, состоится бесплатный воркшоп с Кириллом Гурбановым
📺 Погружение в ИИ-агентов: что это такое, как работает, примеры кейсов для личной жизни и бизнеса
Все подробности и регистрация в боте:
ПРИНЯТЬ УЧАСТИЕ
erid: 2W5zFJr5gdE
В этот четверг, 29 мая, состоится бесплатный воркшоп с Кириллом Гурбановым
📺 Погружение в ИИ-агентов: что это такое, как работает, примеры кейсов для личной жизни и бизнеса
Все подробности и регистрация в боте:
ПРИНЯТЬ УЧАСТИЕ
erid: 2W5zFJr5gdE
Ваш 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%.
