​​KSM Sharing в Proxmox

KSM (Kernel Same-page Merging) - специальная технология ядра Linux, позволяющая объединять страницы памяти разных процессов, тем самым добиваясь ее экономии, фактически данный процесс можно назвать дедупликацией оперативной памяти. При наличии большого количества однотипных виртуальных машин эффект от использования KSM может быть достаточно ощутимым.

👉 Обратите внимание! KSM работает только с виртуальными машинами KVM, для контейнеров LXC эта технология не применима.

KSM сразу включен Proxmox VE, но его настройки могут быть недостаточно оптимальными. Поэтому откроем файл /etc/ksmtuned.conf и ознакомимся с его содержимым. Все опции в нем закомментированы и содержат значения по умолчанию, если мы хотим изменить значение, то строку надо раскомментировать.

Начнем с двух опций:

KSM_THRES_COEF=20
KSM_THRES_CONST=2048

KSM_THRES_COEF - основной параметр, указывающий при каком объеме оставшейся свободной памяти, начнет работать KSM. Несложно подсчитать, что для системы с 64 ГБ ОЗУ это произойдет после того, как будут заняты 51,2 ГБ памяти. Второй параметр KSM_THRES_CONST указывает аналогичное значение в МБ, вы можете использовать его для более точного задания порогов, при различных значениях параметров сработает самый низкий порог.

Многим может показаться, что KSM начинает работать слишком поздно, но этому тоже есть своя причина - операция по сравнению и объединению страниц памяти довольно затратна по использованию процессора, поэтому указанные значения - это некоторый разумный компромисс. Если же у вас нет недостатка в процессорных ресурсах, но актуально рациональное использование памяти - можете попробовать изменить эти параметры.

Следующие два параметра в целом отвечают за нагрузку на CPU:

KSM_MONITOR_INTERVAL=60
KSM_SLEEP_MSEC=100

KSM_MONITOR_INTERVAL - задает промежуток между сканированиями в секундах. Сканирование происходит блоками по 16 ГБ, пауза между этими процессами задается опцией KSM_SLEEP_MSEC. Увеличение этих параметров снижают нагрузку на процессор, но уменьшают эффективность работы KSM.

Минимальное и максимальное количество страниц, которые будут просканированы и объединены задается параметрами:

KSM_NPAGES_MIN=64
KSM_NPAGES_MAX=1250

Без особой нужды и понимания того, что вы делаете, редактировать их не следует.

Агрессивность работы KSM задается следующими параметрами:

KSM_NPAGES_BOOST=300
KSM_NPAGES_DECAY=-50

KSM_NPAGES_BOOST определяет какое количество сканируемых страниц будет прибавлено к текущему значению при превышении порога оставшейся свободной памяти, KSM_NPAGES_DECAY, наоборот, уменьшает количество страниц, когда свободной памяти окажется больше, чем установлено в пороговых значениях. Таким образом достигается баланс между количеством сканируемых и объединяемых страниц и необходимым запасом свободной памяти.

Но приведенные значения совсем не догма и если у вас большое количество однотипных виртуальных машин, то можете поэкспериментировать с настройками KSM, начав с изменения KSM_THRES_COEF.

После внесения изменений не забудьте перезапустить службу командой:

systemctl restart ksmtuned

При выборе значений будьте благоразумны, помните, что за уплотнение памяти вы платите повышенной нагрузкой на процессор.

Вечерняя минутка юмора. А ведь кто-то и за правду примет.

Настраиваем программный RAID на UEFI-системах в Debian и Ubuntu

Программный RAID в Linux на основе MD-устройств успел отлично зарекомендовать себя в работе и пользуется заслуженной популярностью у администраторов, сочетая надежность и простоту создания и управления.

Но со все более широким распространением UEFI-систем приходится сталкиваться с некоторыми особенностями. Многие, если есть такая возможность, переключают настройки в режим совместимости, но это неправильно, UEFI - это стандарт для современных устройств и поэтому надо учиться работе с ним.

https://interface31.ru/tech_it/2019/08/nastraivaem-programmnyy-raid-na-uefi-sistemah-v-debian-i-ubuntu.html

Автоматизация развертывания
Управление конфигурациями
Интеграция с CI/CD
Повторное использование кода
Создание тестовых окружений

Такие возможности появятся у разработчика, который освоил Terraform

👉 9-10 ноября Слёрм проведёт интенсив «Terraform База» с Павлом Селивановым, архитектором в Yandex Cloud

Обучение пройдёт в формате онлайн-воркшопа (11 часов практики + 5 часов теории). У программы нет аналогов на русском языке.

После интенсива:
✔️ Поймёте основные принципы работы с Terraform
✔️ Получите практические навыки, как писать и поддерживать Terraform-код
✔️ Узнаете способы автоматизации
✔️ Узнаете, как избежать ошибок и «набить шишки» на начальных этапах работы с Terraform

🔴При регистрации до 8 ноября видеокурс «Terraform Мега» — в подарок

👉Посмотреть программу интенсива и занять место

#реклама
О рекламодателе

Спрашивали вчера, отвечаем

Настраиваем программный RAID на UEFI-системах в Windows

Программный RAID пользуется заслуженной популярностью, позволяя легко создавать отказоустойчивые дисковые конфигурации в недорогих системах, отличаясь простотой создания и управления.

Но с переходом современных систем на UEFI появились некоторые особенности, касающиеся процесса загрузки, которые следует понимать и принимать во внимание.

В противном случае отказоустойчивость может оказаться мнимой и при отказе одного из дисков вы просто не сможете загрузить систему.

https://interface31.ru/tech_it/2019/07/nastraivaem-programmnyy-raid-na-uefi-sistemah-v-windows.html

Так как снова обсуждаем RAID, то будет не лишним еще раз прочитать:

RAID массивы - краткий ликбез

RAID-массивы давно и прочно вошли в повседневную деятельность администраторов даже небольших предприятий.

Трудно найти того, кто никогда не использовал хотя бы "зеркало", но тем не менее очень и очень многие с завидной периодичностью теряют данные или испытывают иные сложности при эксплуатации массивов.

Не говоря уже о распространенных мифах, которые продолжают витать вокруг вроде бы давно избитой темы.

Кроме того, современные условия вносят свои коррективы и то, чтобы было оптимальным еще несколько лет назад сегодня утратило свою актуальность или стало нежелательным к применению.

https://interface31.ru/tech_it/2019/05/raid-likbez.html

Best Practices работы в Linux. Курс для сисадминов и тех, кто хочет начать карьеру в DevOps

🟡11 ноября запускаем поток «Администрирование Linux» по обновленной программе 2024 года: 57 часов практики + 22 часа теории.

За 6 недель изучите продвинутые аспекты конфигурирования, автоматизации, безопасности и оптимизации систем, а также закрепите знания практикой на стендах.

А при покупке в комплекте с потоком «Ansible: Infrastructure as Code», даем скидку 20% на оба курса 🔥

➡️Посмотреть программу курса и занять место ЗДЕСЬ

#реклама
О рекламодателе

​​Современный взгляд на уровни 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 диски.

​​Про желания и возможности

Сегодня в обсуждении снова возникли вопросы касательно некоторых наших комментариев про покупку ресурсов.

Поэтому уделим немного больше внимания этому вопросу. Сразу оговоримся, что все сказанное ниже будет касаться только бизнеса, т.е. деятельности направленной на извлечение прибыли и не касается личных и некоммерческих вопросов.

Любые ресурсы стоят денег. Это могут быть материальные ресурсы: производительность процессора, емкость и скорость памяти, дисков и т.д. Либо нематериальные – стоимость рабочего времени специалистов.

Ресурсы входят в расходную часть бизнеса и должны быть адекватны его доходам. Недостаток какого-либо ресурса также является для бизнеса убыточным или становится узким горлышком бизнес-процессов.

Поэтому если какого-то ресурса не хватает, то его следует докупить. Если вам не хватает грузчиков на склад, то надо нанять дополнительных. Большие очереди в магазинах – нужно поставить вторую кассу.

Если это дорого и не окупит вложенных затрат, то значит оно вам не надо. Скажем, если грузчиков не хватает только в дни прихода товара, то можно не брать сотрудников в штат, а просто нанять грузчиков по ГПХ на определенные дни.

Если же ресурса вам не хватает, но вы не можете себе его позволить – то вы что-то делаете не так, а то и вовсе занимаетесь ерундой.

Скорее всего вам не нужен ни этот ресурс, ни бизнес-процесс или сервис этого ресурса требующий.

Проще говоря, являясь владельцем овощного ларька вы не можете позволить себе офис класса А и автомобиль представительского класса. А если вас все-таки угораздило их приобрести, то их содержание и обслуживание пробьют дыру в балансе вашего бизнеса и быстро утянут его на дно.

Все это понятно, но как только мы переходим от реальной жизни в плоскость информационных систем, так вроде бы разумные люди начинают делать странные ошибки и ходить по граблям.

Хотя здесь все тоже самое: нужны быстрые диски – идете и покупаете, не хватает памяти – идете и покупаете. Нет денег – значит они вам не нужны. Потому что если бы это реально было узким местом в бизнес-процессах, то деньги сразу бы нашлись.

Хотите SSD корпоративного класса и брендовый сервер? Но не можете себе позволить? Значит они вам не нужны и ваши задачи прекрасно закроет обычное настольное железо.

Да, всякие корпоративные плюшки – это удобно, но удобно прежде всего администратору, а не бизнесу, которому они не нужны, точнее не нужны за такие деньги.

А админ? А админ, как бы это не было ему неприятно слышать – перебьется. Потому что предприятию это не даст ничего, кроме дыры в бюджете. И в целом такое требование равносильно тому, чтобы потребовать в качестве служебной машины Мерседес вместо Гранты.

Одним из отличных примеров несоответствия желаний и возможностей является почтовый сервер.

Очень часто можно услышать: да что-там своя почта, делов то…

А дела начинаются ровно потом. Когда выясняется, что база писем в несколько терабайт на жестких дисках ощутимо тормозит при поиске, ее надо на чем-то хранить, куда-то бекапить.

Но позволить купить себе быстрые SSD такого объема и построить хранилище бекапов с адекватной глубиной хранения фирма не в состоянии.

Тут есть два варианта. Работать как-то так, на костылях и синей изоленте, в надежде на то, что ничего страшного не случится.

Или сесть и трезво признать, что своя почта такому предприятию не нужна. И проще и дешевле будет арендовать ее в облаке.

И даже если там будут сопоставимые цифры, если считать, скажем, за год. То аренда – это растянутые по времени затраты с гарантированным результатом. Свое сервер – единовременные и результат тут достаточно непредсказуем.

Поэтому каждый раз, когда возникнет такая ситуация вспоминаем. Если ресурс нужен – покупаем, нет на это денег – то он нам не нужен или мы делаем что-то не так.
Но можно же оптимизировать и не покупать? Можно. Но для этого придется купить время специалиста, который знает, как это сделать и получить гарантированный результат.

Такой специалист вы? А что вы до сих пор здесь сидите? Вас ждут великие дела.

​​Необычайные приключения роутера Mikrotik

Эту историю рассказал сегодня коллега. В его инфраструктуре есть офис с новым Mikrotik на RouterOS 7 и одиноко стоящий где-то там в интернете сервер, с которым роутер связан OpenVPN каналом для доступа ряда сотрудников к админке сайта.

Все это было сделано давно и подробности благополучно забылись, при замене роутера коллега ничего перенастраивать не стал, исходя из того, что лучшее – враг хорошего.

Так оно и вышло. Вчера, пользуясь выходным днем, он решил обновить RouterOS на Mikrotik, потому что уже очень давно не обновлял и была она там очень старая. Почитал отзывы о новой версии – вроде как без особых косяков. Обновил, все работает.

Утром оказалось, что в офисе не работает интернет. Странно, может что у провайдера. Позвонил. Поддержка посмотрела и сказала, все нормально, оборудование видим, все работает.

Странностей становилось все больше. Коллега зашел на роутер и убедился, что интернет есть. Что роутер пингует внешние адреса, что все удаленные пользователи подключены и работают. А интернета в офисе нет.

Вот же, обновился на свою голову. Проверил практически всю конфигурацию – все нормально, но ничего не работает. Отключил все запрещающие правила, всю маркировку трафика – не помогает.

В общем он уже почти отчаялся и собирался заливать обратно старую прошивку через Netinstall, но решил заглянуть в маршруты. Все тут же стало на свои места. Там обнаружилось два очень интересных маршрута: 0.0.0.0/1 и 128.0.0.0/1.

А в конфигурации OpenVPN сервера ожидаемо обнаружилась опция:

push "redirect-gateway def1 bypass-dhcp"

Сама же RouterOS 7 с какого-то там выпуска научилась применять маршруты и даже немножко их пушить. Поэтому после обновления и произошла такая неприятная ситуация.

Конечно, есть много вопросов к разработчикам, ввод таких функций, можно сказать революционных для RouterOS следовало бы сделать более мягким, отключив их по умолчанию.

Особенно автоматический прием маршрутов. Многие привыкли и продолжают пушить их для других клиентов сети без оглядки на Mikrotik, все равно они не умеют.

А коллега мой еще раз получил урок, что любые конфигурации надо вычитывать и убирать из них все не нужные опции, даже если сейчас все работает.

Как показало его небольшое расследование – указанная опция там была всегда. Кто и для чего ее туда добавил – неизвестно, скорее всего просто скопировали конфиг с другого сервера и слегонца подправили.

​​WireGuard и systemd-resolved

Сегодня столкнулись с еще одной трудно диагностируемой ситуацией. Дано – WireGuard клиент на Debian в филиале, соединяется с WireGuard сервером на Ubuntu в основном офисе.

Коллега попытался перенаправить DNS-запросы на сервер основного офиса, указав в конфиге клиента опцию:

DNS = 192.168.10.53

Которая указывала на DNS-сервер офиса. И вроде бы даже все получилось. Но очень быстро выяснилось, что сломалось разрешение имен на самом сервере.

На любую попытку что-то пропинговать система сообщала:

Временный сбой в разрешении имен

Достаточно быстро выяснилось, что разрешение имен ломается только если поднят WireGuard-интерфейс.

Далее последовали попытки разобраться в ситуации, но безуспешные. За разрешение имен в современных системах отвечает служба systemd-resolved, которая поднимает на 127.0.0.1 локальный кеширующий DNS и направляет все запросы приложений на него.

Реальные же запросы systemd-resolved обрабатывает согласно внутренним правилам, в зависимости от настроек службы и запрашиваемых имен.

Решение гибкое, универсальное, удобное. Но после старта WG-интерфейса служба полностью переставала работать.

Анализ показал, что если в настройках интерфейса WireGuard указана опция DNS, то адрес добавлялся в файл настроек systemd-resolved, причем добавлялся корректно.

После чего systemd-resolved отказывается работать и не может достучаться не только на этот сервер, но и на остальные указанные сервера, хотя они доступны с самого узла напрямую. И команда nslookup с явным указанием сервера прекрасно имена разрешает.

Как только мы убирали из конфига WireGuard опцию DNS и перезапускали службу - systemd-resolved тут же оживал, без всяких перезапусков или иных действий с ним.

Беглый поиск по интернету показал, что проблема не нова и известна. Скорее всего это баг, только вот чей.

Поэтому не используйте опцию DNS в настройках WireGuard интерфейса на системах с systemd-resolved, либо отказывайтесь от использования последнего.

12 ноября присоединяйтесь к митапу об отечественных инфраструктурных сервисах

Эксперты «Инфосистемы Джет» расскажут о результатах тестирования доступных на рынке решений, особенностях их внедрения и поддержки у заказчика.

Что в программе?
🔹Обзор рынка отечественных ОС и инфраструктурных сервисов
🔹Технические подробности по продуктам ALD Pro, «РЕД АДМ», «Эллес», Avanpost
🔹Демонстрация функционала сервисов
🔹Опыт внедрения и обслуживания

🗓 Когда? 
12 ноября, 16:00

📍 Где? 
Online или offline

✅ Регистрация

VMware Workstation переходит на гипервизор KVM

Поглотившая бизнес VMware компания Broadcom сообщила, что ведет работы по переводу Linux-версии VMware Workstation на KVM вместо использования собственного проприетарного кода виртуализации.

Напомним, что ранее Broadcom сделала VMware Workstation бесплатным для некоммерческого использования, а также серьезно пересмотрела модель лицензирования, полностью переведя клиентскую базу на подписную модель.

Фактически Broadcom дает понять, что пути бесплатной версии VMware Workstation и коммерческих решений виртуализации расходятся и в развитии бесплатного гипервизора компания не заинтересована.

По оптимистичным прогнозам, версия VMware Workstation для Linux на основе KVM может выйти уже в следующем году.

Поэтому не стоит удивляться, если скоро мы услышим о переводе Windows-версии продукта на работу с Hyper-V, что будет полностью в рамках текущей политики.