Так как снова обсуждаем 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
👍20
Какие уровни RAID вы используете? (можно выбрать несколько ответов)
Anonymous Poll
16%
RAID 0
59%
RAID 1
8%
RAID 0+1
51%
RAID 10
33%
RAID 5/5E/5EE
17%
RAID 6/6E
7%
RAID 50/60
12%
RAID Z
4%
Другие уровни и реализации
5%
Ничего не понятно, но очень интересно
👍12
Best Practices работы в Linux. Курс для сисадминов и тех, кто хочет начать карьеру в DevOps
🟡11 ноября запускаем поток «Администрирование Linux» по обновленной программе 2024 года: 57 часов практики + 22 часа теории.
За 6 недель изучите продвинутые аспекты конфигурирования, автоматизации, безопасности и оптимизации систем, а также закрепите знания практикой на стендах.
А при покупке в комплекте с потоком «Ansible: Infrastructure as Code», даем скидку 20% на оба курса 🔥
➡️Посмотреть программу курса и занять место ЗДЕСЬ
#реклама
О рекламодателе
🟡11 ноября запускаем поток «Администрирование Linux» по обновленной программе 2024 года: 57 часов практики + 22 часа теории.
За 6 недель изучите продвинутые аспекты конфигурирования, автоматизации, безопасности и оптимизации систем, а также закрепите знания практикой на стендах.
А при покупке в комплекте с потоком «Ansible: Infrastructure as Code», даем скидку 20% на оба курса 🔥
➡️Посмотреть программу курса и занять место ЗДЕСЬ
#реклама
О рекламодателе
👍2
Современный взгляд на уровни 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 диски.
👍48👎4❤2👌2
Про желания и возможности
Сегодня в обсуждении снова возникли вопросы касательно некоторых наших комментариев про покупку ресурсов.
Поэтому уделим немного больше внимания этому вопросу. Сразу оговоримся, что все сказанное ниже будет касаться только бизнеса, т.е. деятельности направленной на извлечение прибыли и не касается личных и некоммерческих вопросов.
Любые ресурсы стоят денег. Это могут быть материальные ресурсы: производительность процессора, емкость и скорость памяти, дисков и т.д. Либо нематериальные – стоимость рабочего времени специалистов.
Ресурсы входят в расходную часть бизнеса и должны быть адекватны его доходам. Недостаток какого-либо ресурса также является для бизнеса убыточным или становится узким горлышком бизнес-процессов.
Поэтому если какого-то ресурса не хватает, то его следует докупить. Если вам не хватает грузчиков на склад, то надо нанять дополнительных. Большие очереди в магазинах – нужно поставить вторую кассу.
Если это дорого и не окупит вложенных затрат, то значит оно вам не надо. Скажем, если грузчиков не хватает только в дни прихода товара, то можно не брать сотрудников в штат, а просто нанять грузчиков по ГПХ на определенные дни.
Если же ресурса вам не хватает, но вы не можете себе его позволить – то вы что-то делаете не так, а то и вовсе занимаетесь ерундой.
Скорее всего вам не нужен ни этот ресурс, ни бизнес-процесс или сервис этого ресурса требующий.
Проще говоря, являясь владельцем овощного ларька вы не можете позволить себе офис класса А и автомобиль представительского класса. А если вас все-таки угораздило их приобрести, то их содержание и обслуживание пробьют дыру в балансе вашего бизнеса и быстро утянут его на дно.
Все это понятно, но как только мы переходим от реальной жизни в плоскость информационных систем, так вроде бы разумные люди начинают делать странные ошибки и ходить по граблям.
Хотя здесь все тоже самое: нужны быстрые диски – идете и покупаете, не хватает памяти – идете и покупаете. Нет денег – значит они вам не нужны. Потому что если бы это реально было узким местом в бизнес-процессах, то деньги сразу бы нашлись.
Хотите SSD корпоративного класса и брендовый сервер? Но не можете себе позволить? Значит они вам не нужны и ваши задачи прекрасно закроет обычное настольное железо.
Да, всякие корпоративные плюшки – это удобно, но удобно прежде всего администратору, а не бизнесу, которому они не нужны, точнее не нужны за такие деньги.
А админ? А админ, как бы это не было ему неприятно слышать – перебьется. Потому что предприятию это не даст ничего, кроме дыры в бюджете. И в целом такое требование равносильно тому, чтобы потребовать в качестве служебной машины Мерседес вместо Гранты.
Одним из отличных примеров несоответствия желаний и возможностей является почтовый сервер.
Очень часто можно услышать: да что-там своя почта, делов то…
А дела начинаются ровно потом. Когда выясняется, что база писем в несколько терабайт на жестких дисках ощутимо тормозит при поиске, ее надо на чем-то хранить, куда-то бекапить.
Но позволить купить себе быстрые SSD такого объема и построить хранилище бекапов с адекватной глубиной хранения фирма не в состоянии.
Тут есть два варианта. Работать как-то так, на костылях и синей изоленте, в надежде на то, что ничего страшного не случится.
Или сесть и трезво признать, что своя почта такому предприятию не нужна. И проще и дешевле будет арендовать ее в облаке.
И даже если там будут сопоставимые цифры, если считать, скажем, за год. То аренда – это растянутые по времени затраты с гарантированным результатом. Свое сервер – единовременные и результат тут достаточно непредсказуем.
Поэтому каждый раз, когда возникнет такая ситуация вспоминаем. Если ресурс нужен – покупаем, нет на это денег – то он нам не нужен или мы делаем что-то не так.
Но можно же оптимизировать и не покупать? Можно. Но для этого придется купить время специалиста, который знает, как это сделать и получить гарантированный результат.
Такой специалист вы? А что вы до сих пор здесь сидите? Вас ждут великие дела.
Сегодня в обсуждении снова возникли вопросы касательно некоторых наших комментариев про покупку ресурсов.
Поэтому уделим немного больше внимания этому вопросу. Сразу оговоримся, что все сказанное ниже будет касаться только бизнеса, т.е. деятельности направленной на извлечение прибыли и не касается личных и некоммерческих вопросов.
Любые ресурсы стоят денег. Это могут быть материальные ресурсы: производительность процессора, емкость и скорость памяти, дисков и т.д. Либо нематериальные – стоимость рабочего времени специалистов.
Ресурсы входят в расходную часть бизнеса и должны быть адекватны его доходам. Недостаток какого-либо ресурса также является для бизнеса убыточным или становится узким горлышком бизнес-процессов.
Поэтому если какого-то ресурса не хватает, то его следует докупить. Если вам не хватает грузчиков на склад, то надо нанять дополнительных. Большие очереди в магазинах – нужно поставить вторую кассу.
Если это дорого и не окупит вложенных затрат, то значит оно вам не надо. Скажем, если грузчиков не хватает только в дни прихода товара, то можно не брать сотрудников в штат, а просто нанять грузчиков по ГПХ на определенные дни.
Если же ресурса вам не хватает, но вы не можете себе его позволить – то вы что-то делаете не так, а то и вовсе занимаетесь ерундой.
Скорее всего вам не нужен ни этот ресурс, ни бизнес-процесс или сервис этого ресурса требующий.
Проще говоря, являясь владельцем овощного ларька вы не можете позволить себе офис класса А и автомобиль представительского класса. А если вас все-таки угораздило их приобрести, то их содержание и обслуживание пробьют дыру в балансе вашего бизнеса и быстро утянут его на дно.
Все это понятно, но как только мы переходим от реальной жизни в плоскость информационных систем, так вроде бы разумные люди начинают делать странные ошибки и ходить по граблям.
Хотя здесь все тоже самое: нужны быстрые диски – идете и покупаете, не хватает памяти – идете и покупаете. Нет денег – значит они вам не нужны. Потому что если бы это реально было узким местом в бизнес-процессах, то деньги сразу бы нашлись.
Хотите SSD корпоративного класса и брендовый сервер? Но не можете себе позволить? Значит они вам не нужны и ваши задачи прекрасно закроет обычное настольное железо.
Да, всякие корпоративные плюшки – это удобно, но удобно прежде всего администратору, а не бизнесу, которому они не нужны, точнее не нужны за такие деньги.
А админ? А админ, как бы это не было ему неприятно слышать – перебьется. Потому что предприятию это не даст ничего, кроме дыры в бюджете. И в целом такое требование равносильно тому, чтобы потребовать в качестве служебной машины Мерседес вместо Гранты.
Одним из отличных примеров несоответствия желаний и возможностей является почтовый сервер.
Очень часто можно услышать: да что-там своя почта, делов то…
А дела начинаются ровно потом. Когда выясняется, что база писем в несколько терабайт на жестких дисках ощутимо тормозит при поиске, ее надо на чем-то хранить, куда-то бекапить.
Но позволить купить себе быстрые SSD такого объема и построить хранилище бекапов с адекватной глубиной хранения фирма не в состоянии.
Тут есть два варианта. Работать как-то так, на костылях и синей изоленте, в надежде на то, что ничего страшного не случится.
Или сесть и трезво признать, что своя почта такому предприятию не нужна. И проще и дешевле будет арендовать ее в облаке.
И даже если там будут сопоставимые цифры, если считать, скажем, за год. То аренда – это растянутые по времени затраты с гарантированным результатом. Свое сервер – единовременные и результат тут достаточно непредсказуем.
Поэтому каждый раз, когда возникнет такая ситуация вспоминаем. Если ресурс нужен – покупаем, нет на это денег – то он нам не нужен или мы делаем что-то не так.
Но можно же оптимизировать и не покупать? Можно. Но для этого придется купить время специалиста, который знает, как это сделать и получить гарантированный результат.
Такой специалист вы? А что вы до сих пор здесь сидите? Вас ждут великие дела.
🔥29👍16🥱4💯2👌1
Необычайные приключения роутера 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, все равно они не умеют.
А коллега мой еще раз получил урок, что любые конфигурации надо вычитывать и убирать из них все не нужные опции, даже если сейчас все работает.
Как показало его небольшое расследование – указанная опция там была всегда. Кто и для чего ее туда добавил – неизвестно, скорее всего просто скопировали конфиг с другого сервера и слегонца подправили.
Эту историю рассказал сегодня коллега. В его инфраструктуре есть офис с новым 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, все равно они не умеют.
А коллега мой еще раз получил урок, что любые конфигурации надо вычитывать и убирать из них все не нужные опции, даже если сейчас все работает.
Как показало его небольшое расследование – указанная опция там была всегда. Кто и для чего ее туда добавил – неизвестно, скорее всего просто скопировали конфиг с другого сервера и слегонца подправили.
👍42👎1
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, либо отказывайтесь от использования последнего.
Сегодня столкнулись с еще одной трудно диагностируемой ситуацией. Дано – 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, либо отказывайтесь от использования последнего.
👍59👎3
12 ноября присоединяйтесь к митапу об отечественных инфраструктурных сервисах
Эксперты «Инфосистемы Джет» расскажут о результатах тестирования доступных на рынке решений, особенностях их внедрения и поддержки у заказчика.
Что в программе?
🔹Обзор рынка отечественных ОС и инфраструктурных сервисов
🔹Технические подробности по продуктам ALD Pro, «РЕД АДМ», «Эллес», Avanpost
🔹Демонстрация функционала сервисов
🔹Опыт внедрения и обслуживания
🗓 Когда?
12 ноября, 16:00
📍 Где?
Online или offline
✅ Регистрация
Эксперты «Инфосистемы Джет» расскажут о результатах тестирования доступных на рынке решений, особенностях их внедрения и поддержки у заказчика.
Что в программе?
🔹Обзор рынка отечественных ОС и инфраструктурных сервисов
🔹Технические подробности по продуктам ALD Pro, «РЕД АДМ», «Эллес», Avanpost
🔹Демонстрация функционала сервисов
🔹Опыт внедрения и обслуживания
🗓 Когда?
12 ноября, 16:00
📍 Где?
Online или offline
✅ Регистрация
👍4
VMware Workstation переходит на гипервизор KVM
Поглотившая бизнес VMware компания Broadcom сообщила, что ведет работы по переводу Linux-версии VMware Workstation на KVM вместо использования собственного проприетарного кода виртуализации.
Напомним, что ранее Broadcom сделала VMware Workstation бесплатным для некоммерческого использования, а также серьезно пересмотрела модель лицензирования, полностью переведя клиентскую базу на подписную модель.
Фактически Broadcom дает понять, что пути бесплатной версии VMware Workstation и коммерческих решений виртуализации расходятся и в развитии бесплатного гипервизора компания не заинтересована.
По оптимистичным прогнозам, версия VMware Workstation для Linux на основе KVM может выйти уже в следующем году.
Поэтому не стоит удивляться, если скоро мы услышим о переводе Windows-версии продукта на работу с Hyper-V, что будет полностью в рамках текущей политики.
Поглотившая бизнес VMware компания Broadcom сообщила, что ведет работы по переводу Linux-версии VMware Workstation на KVM вместо использования собственного проприетарного кода виртуализации.
Напомним, что ранее Broadcom сделала VMware Workstation бесплатным для некоммерческого использования, а также серьезно пересмотрела модель лицензирования, полностью переведя клиентскую базу на подписную модель.
Фактически Broadcom дает понять, что пути бесплатной версии VMware Workstation и коммерческих решений виртуализации расходятся и в развитии бесплатного гипервизора компания не заинтересована.
По оптимистичным прогнозам, версия VMware Workstation для Linux на основе KVM может выйти уже в следующем году.
Поэтому не стоит удивляться, если скоро мы услышим о переводе Windows-версии продукта на работу с Hyper-V, что будет полностью в рамках текущей политики.
🤔19🤮14🤡7🔥3😁2
Boxes – простая настольная KVM-виртуализация
Возвращаясь к вопросу настольной виртуализации в Linux, нельзя не обратить внимание на Boxes. Это простое приложение Gnome предназначенное для работы с виртуальными машинами, в качестве гипервизора используется хорошо знакомый KVM.
Получилось быстро, просто и достаточно удобно. Почему достаточно? Потому что это Gnome-приложение, построенное в соответствии со всеми представлениями «о прекрасном» разработчиков этой системы, ну и со всеми сопутствующими прибабахами.
Но тем не менее Boxes позволяет быстро и просто создавать виртуалки. Можно использовать свой образ или виртуальный диск, либо скачать готовый. В библиотеке готовых образов представлены практически все открытые ОС: Linux (включая отечественный), BSD и даже экзотическая Haiku.
Настроек, в лучших традициях Gnome, откровенно мало. У готовой виртуалки немногим больше. Но при желании вы всегда можете внести изменения вручную в файл конфигурации виртуальной машины.
Возвращаясь к вопросу настольной виртуализации в Linux, нельзя не обратить внимание на Boxes. Это простое приложение Gnome предназначенное для работы с виртуальными машинами, в качестве гипервизора используется хорошо знакомый KVM.
Получилось быстро, просто и достаточно удобно. Почему достаточно? Потому что это Gnome-приложение, построенное в соответствии со всеми представлениями «о прекрасном» разработчиков этой системы, ну и со всеми сопутствующими прибабахами.
Но тем не менее Boxes позволяет быстро и просто создавать виртуалки. Можно использовать свой образ или виртуальный диск, либо скачать готовый. В библиотеке готовых образов представлены практически все открытые ОС: Linux (включая отечественный), BSD и даже экзотическая Haiku.
Настроек, в лучших традициях Gnome, откровенно мало. У готовой виртуалки немногим больше. Но при желании вы всегда можете внести изменения вручную в файл конфигурации виртуальной машины.
👍25
Освой работу с Prometheus, Grafana, ELK, etc и настрой мониторинг!
✅ Владение инструментами Observability открывает новые карьерные горизонты администраторам Linux, DevOps-инженерам
Стройте сложные эффективные системы мониторинга и логирования инфраструктуры и приложений
💪 Ответьте на 15 вопросов и проверьте, насколько вы готовы к обучению на курсе «Observability: мониторинг, логирование, трейсинг» от OTUS.
Пройти тест и получить спец. предложение:
https://otus.pw/QJUi/?erid=LjN8KPbx5
#реклама
О рекламодателе
✅ Владение инструментами Observability открывает новые карьерные горизонты администраторам Linux, DevOps-инженерам
Стройте сложные эффективные системы мониторинга и логирования инфраструктуры и приложений
💪 Ответьте на 15 вопросов и проверьте, насколько вы готовы к обучению на курсе «Observability: мониторинг, логирование, трейсинг» от OTUS.
+ 5 новых занятий, для вашего профессионального развитияПройти тест и получить спец. предложение:
https://otus.pw/QJUi/?erid=LjN8KPbx5
#реклама
О рекламодателе
🔥2⚡1🌭1
Часто приходится работать с контрольными суммами? Облегчите себе жизнь при помощи утилиты OpenHashTab https://github.com/namazso/OpenHashTab с открытым исходным кодом под лицензией GPL 3.0.
Утилита встраивается в Проводник Windows и показывает на отдельной вкладке информацию о контрольных суммах файла (или файлов, если открыть свойства папки). Также она позволяет быстро проверить контрольную сумму на совпадение, достаточно просто скопировать ее в буфер обмена, утилита подставит и проверит ее автоматически.
Но это еще не все, отдельная кнопочка позволяет быстро проверить файл по базе VirusTotal, для этого достаточно отправить сервису контрольную сумму файла, если кто-то уже загружал и проверял его – то вы получите результат проверки.
Утилита встраивается в Проводник Windows и показывает на отдельной вкладке информацию о контрольных суммах файла (или файлов, если открыть свойства папки). Также она позволяет быстро проверить контрольную сумму на совпадение, достаточно просто скопировать ее в буфер обмена, утилита подставит и проверит ее автоматически.
Но это еще не все, отдельная кнопочка позволяет быстро проверить файл по базе VirusTotal, для этого достаточно отправить сервису контрольную сумму файла, если кто-то уже загружал и проверял его – то вы получите результат проверки.
👍29🔥11👌2🤡1
Эскалации в Zabbix
От проблем не убежать, они были, есть и будут возникать с определенной периодичностью, какие бы превентивные меры мы не принимали. Но важно не факт отсутствия проблем, а факт своевременного на них реагирования.
И очень часто в дело вступает человеческий фактор, который превращает небольшое происшествие в проблему масштаба предприятия.
Кто-то не заметил, не отработал, не хватило собственной квалификации, либо вообще принял ошибочные решения. Как все это отследить, как проконтролировать?
А на помощь нам снова придет система мониторинга Zabbix, которая умеет эскалировать проблемы. Именно она поможет отследить, что что-то пошло не так и вовремя подключить вышестоящих специалистов или руководство. А также не даст замолчать проблему или замести ее под ковер.
Все мы знаем, что в основе Zabbix лежит контроль собираемых показателей относительно заранее заданных условий при помощи триггеров. Сработавший триггер может являться основанием для действия.
Самое простое – это кого-нибудь уведомить. Но как быть, если ответственный не увидел уведомления, не отреагировал или не справляется?
Все очень просто, каждое действие состоит из некоторых операций, которых может быть несколько, и они будут выполняться по очереди.
Допустим мы создали некоторое действие, привязали к нему нужные триггеры и думаем как мы будем обрабатывать сложившуюся ситуацию.
А обрабатывать мы ее будем пошагово, с каждым шагом поднимая проблему на более высокий уровень.
Сначала выбираем длительность шага, это тот промежуток времени, за который проблема должна быть решена ответственным лицом. Не следует ставить сильно маленькое время, чтобы не получить шквал сообщений и не перебудоражить всех, кого нужно и кого не нужно.
Но и выставлять слишком большой период тоже не стоит, иначе может оказаться что мы начали «бить в колокола» слишком поздно.
Для примера мы возьмем триггер «High CPU usage», т.е. когда процессор начинает стабильно выдавать высокую загрузку. Ситуация серьезная, но не катастрофическая. Дадим на решение вопроса 15 минут. Такое же время выделим на каждый шаг.
Первый шаг – уведомить ответственное лицо, кстати, каждую операцию можно растянуть на несколько шагов. И тогда ответственное лицо будет уведомляться несколько раз.
Если никаких действий за 15 минут не последовало, то начинаем эскалировать проблему. Добавляем следующий шаг, которым уведомляем руководство ответственного лица о наличии проблемы.
Ждем еще 15 минут, если нет реакции, то мы можем не только продолжать уведомлять все более вышестоящие лица, но и выполнять некоторые действия для решения проблемы. Например, снять отчеты по нагрузке на CPU, память, диски и отправить их кому надо.
Снова нет реакции? Ну тогда в дело вступают роботы, можем прибить самый ресурсоемкий процесс. Не помогло? Кстати, для этого можно и не ждать следующие 15 минут, а задать произвольное время шага, допустим 5 минут.
Через 5 минут после того, как мы прибили процесс снова высокая нагрузка? Ну давайте последний раз всех предупредим. Не помогло? Ну тогда идем на крайние меры и перезагружаем узел.
Количество шагов ограничено только вашей фантазией и позволяет реализовывать достаточно сложные сценарии.
Причем параллельно мы можем добавлять шаги для контроля и отчетности. Скажем, после получаса существования проблемы мы можем собирать логи, показатели, историю команд и отсылать ее вышестоящему руководству для разбора полетов.
Проблема решена? Отлично, но не следует расслабляться. Настроим действия восстановления. Сюда можно добавить сбор основных метрик по решенной проблеме и отправка их ответственному сотруднику в течении следующих условных двух часов, чтобы он мог проконтролировать, что ситуация снова не ухудшается.
В общем, эскалация в Zabbix это крайне гибкий и удобный инструмент, позволяющий контролировать не только возникновение проблем, но и процесс их решения.
От проблем не убежать, они были, есть и будут возникать с определенной периодичностью, какие бы превентивные меры мы не принимали. Но важно не факт отсутствия проблем, а факт своевременного на них реагирования.
И очень часто в дело вступает человеческий фактор, который превращает небольшое происшествие в проблему масштаба предприятия.
Кто-то не заметил, не отработал, не хватило собственной квалификации, либо вообще принял ошибочные решения. Как все это отследить, как проконтролировать?
А на помощь нам снова придет система мониторинга Zabbix, которая умеет эскалировать проблемы. Именно она поможет отследить, что что-то пошло не так и вовремя подключить вышестоящих специалистов или руководство. А также не даст замолчать проблему или замести ее под ковер.
Все мы знаем, что в основе Zabbix лежит контроль собираемых показателей относительно заранее заданных условий при помощи триггеров. Сработавший триггер может являться основанием для действия.
Самое простое – это кого-нибудь уведомить. Но как быть, если ответственный не увидел уведомления, не отреагировал или не справляется?
Все очень просто, каждое действие состоит из некоторых операций, которых может быть несколько, и они будут выполняться по очереди.
Допустим мы создали некоторое действие, привязали к нему нужные триггеры и думаем как мы будем обрабатывать сложившуюся ситуацию.
А обрабатывать мы ее будем пошагово, с каждым шагом поднимая проблему на более высокий уровень.
Сначала выбираем длительность шага, это тот промежуток времени, за который проблема должна быть решена ответственным лицом. Не следует ставить сильно маленькое время, чтобы не получить шквал сообщений и не перебудоражить всех, кого нужно и кого не нужно.
Но и выставлять слишком большой период тоже не стоит, иначе может оказаться что мы начали «бить в колокола» слишком поздно.
Для примера мы возьмем триггер «High CPU usage», т.е. когда процессор начинает стабильно выдавать высокую загрузку. Ситуация серьезная, но не катастрофическая. Дадим на решение вопроса 15 минут. Такое же время выделим на каждый шаг.
Первый шаг – уведомить ответственное лицо, кстати, каждую операцию можно растянуть на несколько шагов. И тогда ответственное лицо будет уведомляться несколько раз.
Если никаких действий за 15 минут не последовало, то начинаем эскалировать проблему. Добавляем следующий шаг, которым уведомляем руководство ответственного лица о наличии проблемы.
Ждем еще 15 минут, если нет реакции, то мы можем не только продолжать уведомлять все более вышестоящие лица, но и выполнять некоторые действия для решения проблемы. Например, снять отчеты по нагрузке на CPU, память, диски и отправить их кому надо.
Снова нет реакции? Ну тогда в дело вступают роботы, можем прибить самый ресурсоемкий процесс. Не помогло? Кстати, для этого можно и не ждать следующие 15 минут, а задать произвольное время шага, допустим 5 минут.
Через 5 минут после того, как мы прибили процесс снова высокая нагрузка? Ну давайте последний раз всех предупредим. Не помогло? Ну тогда идем на крайние меры и перезагружаем узел.
Количество шагов ограничено только вашей фантазией и позволяет реализовывать достаточно сложные сценарии.
Причем параллельно мы можем добавлять шаги для контроля и отчетности. Скажем, после получаса существования проблемы мы можем собирать логи, показатели, историю команд и отсылать ее вышестоящему руководству для разбора полетов.
Проблема решена? Отлично, но не следует расслабляться. Настроим действия восстановления. Сюда можно добавить сбор основных метрик по решенной проблеме и отправка их ответственному сотруднику в течении следующих условных двух часов, чтобы он мог проконтролировать, что ситуация снова не ухудшается.
В общем, эскалация в Zabbix это крайне гибкий и удобный инструмент, позволяющий контролировать не только возникновение проблем, но и процесс их решения.
👍35❤2
А вы используете эскалации в Zabbix?
Anonymous Poll
9%
Да, активно
6%
Да, местами
4%
Только на самых критичных местах
2%
Использовали, отказались, лишняя суета
9%
Нет, но хотим использовать
15%
Не знали, теперь хотим попробовать
13%
Нам это не надо
17%
Не использумем Zabbix
2%
Нафиг нужно, это же компромат на себя
23%
Ничего не понятно, но очень интересно
Ansible: Какой тип инвентаря применяется в Ansible по умолчанию? 🤔
a) База данных
b) Динамический инвентарь
c) Инвентарь в формате JSON
d) Файл инвентаря
Пройдите тест и получите скидку на курс «Ansible: Infrastructure as Code».
На курсе мы:
✔️ систематизируем знания по Ansible и изучаем подход IaC;
✔️ учимся писать плейбуки и роли;
✔️ деплоим Flask-приложение;
✔️ настраиваем IaC в Gitlab;
✔️ обеспечиваем поддержку наших решений вдолгую.
5 вопросов по Ansible ждут вас внутри бота.
Проверяйте себя и до встречи на обучении! 🔥
#реклама
О рекламодателе
erid: LjN8KJpVQ
a) База данных
b) Динамический инвентарь
c) Инвентарь в формате JSON
d) Файл инвентаря
Пройдите тест и получите скидку на курс «Ansible: Infrastructure as Code».
На курсе мы:
✔️ систематизируем знания по Ansible и изучаем подход IaC;
✔️ учимся писать плейбуки и роли;
✔️ деплоим Flask-приложение;
✔️ настраиваем IaC в Gitlab;
✔️ обеспечиваем поддержку наших решений вдолгую.
5 вопросов по Ansible ждут вас внутри бота.
Проверяйте себя и до встречи на обучении! 🔥
#реклама
О рекламодателе
erid: LjN8KJpVQ
👍1
Сегодня хотим рассказать еще о двух небольших и удобных утилитах от компании Фаматек – разработчика известного ПО для удаленного доступа Radmin.
🔹 Advanced IP Scanner – простой и удобный сетевой сканер, который просканирует сеть, покажет работающие ПК и доступные сетевые службы на них. Все это в удобном графическом интерфейсе.
Программа тесно интегрирована с Radmin, но и даже без него быстро позволяет выполнить ряд действий, например, пропинговать узел, включить его магическим пакетом или соединиться по RDP или SSH.
🔹 Advanced Port Scanner – простой и удобный сканер портов, быстро позволяет определить открытые порты и работающие на них службы. Можно сканировать как один ПК, так и сразу группу.
Также присутствует интеграция с Radmin и набор базовых инструментов для подключения или дополнительных проверок.
Все утилиты бесплатны, просты в обращении и удобны. Рекомендуем для первичной диагностики и поддержки, особенно для сотрудников, которые не являются сетевыми специалистами.
🔹 Advanced IP Scanner – простой и удобный сетевой сканер, который просканирует сеть, покажет работающие ПК и доступные сетевые службы на них. Все это в удобном графическом интерфейсе.
Программа тесно интегрирована с Radmin, но и даже без него быстро позволяет выполнить ряд действий, например, пропинговать узел, включить его магическим пакетом или соединиться по RDP или SSH.
🔹 Advanced Port Scanner – простой и удобный сканер портов, быстро позволяет определить открытые порты и работающие на них службы. Можно сканировать как один ПК, так и сразу группу.
Также присутствует интеграция с Radmin и набор базовых инструментов для подключения или дополнительных проверок.
Все утилиты бесплатны, просты в обращении и удобны. Рекомендуем для первичной диагностики и поддержки, особенно для сотрудников, которые не являются сетевыми специалистами.
👍47