• Почему язык Go стал стандартом для DevOps-инженеров
    0
    Я думаю не только мне будет интересно узнать про проблемы io.RW подробнее. Расскажите пожалуйста.
  • Эксплуатация Ceph: как распределять пулы по разным типам (HDD/SSD) и группам серверов
    +1
    Чтобы расположить пул на определенных ODS есть более простое решение — device classes (доступно если мне не изменяет память с 13 версии ceph). При создании OSD можно задать ему класс. По умолчанию у ceph 3 класса — hdd, ssd и nvme. Мы можем добавить OSD со своим классом, например hdd-slow или ssd-metapool. После этого мы создаем crush rule:
    ceph osd crush rule create-replicated replicated_hdd-slow default host hdd-slow
    После этого создаем пул и назначаем ему crush_rule «replicated_hdd-slow». Все, пул будет располагаться только на OSD с указанным классом.
  • XPS 13 9310: эволюционный апгрейд флагманского ультрабука Dell с Tiger Lake внутри
    +3
    А планируются ли хоть что то из дорогих не игровых моделей на AMD? Сейчас на AMD в основном бюджетные игровые ноуты, а хочется что то типа XPS 15 — небольшой, с хорошим дисплеем, мощным процом и 16-32 RAM.
  • Многозадачность в shell-скриптах
    0
    ИМХО, но если необходима многозадачность, то лучше взять нормальный язык программирования и написать логику на нем. В баше это реализовано ужасно и любой скрипт на 200+ строк и многопоточностью будет нечитаемой кучей кода. (Это не относится к xargs -P или parallel). Контроль кодов выхода, синхронизация потоков, доступ к общим данным. Конечно все это можно заколхозить на баше, но как сисадмин, я надеюсь, что мне не достанется такой подарок на поддержку.
  • TechCrunch: требования пожарной безопасности ставят крест на обещаниях Boring Company в Лас-Вегасе
    +1
    Если в туннеле планируется движение не личных авто, а «общественных», то какой тогда смысл от машин в тоннеле? Просто потому что это тесла?
    Небольшие электропоезда на 2-3 вагона перевезут намного больше пассажиров и сделают это быстро, безопаснее и с большим комфортом.
    На крайний случай автобусы (можно тоже электрические).
  • Томские ученые нашли способ удешевить производство водородного топлива
    0
    Водород считается практически идеальным топливом, поскольку при сгорании он не выделяет вредных парниковых газов типа CO2 — только водяной пар.

    Это относится только к сгоранию чистой пары кислород-водород. При горении водорода в воздухе все не так однозначно, т.к. образуются оксиды азота и другие соединения. И их образуется тем больше, чем больше температура горения, а у водородных ДВС она выше, чем у бензиновых.
  • Много свободной RAM, NVMe Intel P4500 и все люто тормозит — история о неудачном добавлении раздела подкачки
    0
    Плюсы в следующем:
    • Не зависит от дискового бэкенда. Диск может быть в LVM/ZFS/QCOW/NFS и тд.
    • Можно вместе со снапшотом делать дамп памяти. Актуально например для серверов БД (чтобы не повреждать ее).

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

    Насчет надежности не скажу, у нас этот способ работает на паре машин, проблем не было. Но тут конечно стоит более масштабно протестировать.
    А вы уверены, что lvcreate -s надежный?) Вы же сами написали про повреждение меты LVM.
    Уверены, что у вас данные всех томов правильные и в какие то случайные сектора не записалась каша (например данные снапшотов)?
  • Много свободной RAM, NVMe Intel P4500 и все люто тормозит — история о неудачном добавлении раздела подкачки
    0
    Спасибо, интересная ссылка.
    Но я говорил о external snapshot, он не использует возможности QCOW, все операции со снапшотом делаются QEMU, можно снапшотить даже raw диски.
    Почему не используете понятно.)
  • Много свободной RAM, NVMe Intel P4500 и все люто тормозит — история о неудачном добавлении раздела подкачки
    0
    Не раскрыта тема того, что случилось с LVM VG. Почему оказалась повреждена мета?
    Второй вопрос — почему вы не делаете снапшоты средствами QEMU (external snapshot)?
  • Использование партиционирования в MySQL для Zabbix с большим количеством объектов мониторинга
    0
    Работает стандартная MySQL репликация.
    Обратите внимание, что RocksDB это только библиотека и она никак не завязана на MySQL и может применяться отдельно от него. А есть RocksDB плагины к MySQL (например у Percona он зовется MyRocks), которые реализуют интерфейс взаимодействия с библиотекой и интегрируют ее в MySQL.
    Почитать подробнее можно например тут.
  • Использование партиционирования в MySQL для Zabbix с большим количеством объектов мониторинга
    +1
    В MySQL DDL операции (ALTER, CREATE, RENAME TABLE и другие) не работают с транзакциями и выполняются сразу же, а не при комите.
    Чтобы выполнить RENAME атомарно следует делать так:
    CREATE TABLE history_tmp LIKE history;
    RENAME TABLE history TO history_old, history_tmp TO history; ;
    


    По теме самой статьи. Мы тоже некоторое время использовали партиционирование, но оно не удобно по следующим причинам:
    • Меняется схема данных. При обновлениях могут вылезать проблемы. (Актуально для версий <3.2, т.к. для них требовалась модификация индексов для работы партиционирования. )
    • Удаление данных происходит только целыми партициями. Нельзя одну метрику хранить неделю, а другую два года.


    Поэтому сейчас мы применяем не партиционирование, а храним историю в таблицах с движком RocksDB. Плюсы следующие:
    • Встроенный housekeeper работает даже на больших объемах данных. Можно гибко назначать метрикам время хранения.
    • Отличное сжатие. По сравнения с InnoDB компрессией данные стали занимать примерно в 2 раза меньше места.
    • Простая процедура миграции. Надо только поставить RocksDB плагин и сделать ALTER нужных таблиц.
    • Не меняется схема, только движок для нескольких таблиц. Пока еще ни разу не было проблем при апгрейде. (3.4 -> 4.0 -> 4.2)
    • Выборки из БД также работают быстрее.


    В общем для существующих инсталляций лучше использовать решение с RocksDB. Для новых лучше наверно использовать официальное решение с TimescaleDB.
  • Нетипичный «ls» — Habr Edition
    0
    diff -r ./ /empty_dir/ | awk -F ':' '{print $2}'

    chown -v -R root:root ./
  • Миграция реального приложения со standalone MySQL на Percona XtraDB Cluster
    0
    Про 20к интересно, это на Galera или обычная репликация? Просто у нас уже при всплесках до 1-2к начинает расти очередь на отправку. При этом трафик сети в районе нескольких мегабит, есть мнение, что дело не в пропускной способности, а в latency сети.
  • Миграция реального приложения со standalone MySQL на Percona XtraDB Cluster
    0
    Скорость записи ограничивается двумя параметрами: диском и сетью. С дисками у нас проблем нет, они могут сильно больше, чем у нас есть сейчас (сейчас 400-600 qps, диски могут вытянуть 40-60к). Сейчас ограничивающим фактором является сеть (1 Gbit/s), по ощущениям через нее можно пропихнуть 1.5-2к qps. Сеть планируем апгрейдить.

    По масштабированию на уровне кластер — если понадобится вероятно будем шардировать на уровне приложения на несколько кластеров.
  • Миграция реального приложения со standalone MySQL на Percona XtraDB Cluster
    0
    Все горячие данные помещаются в память, чтение с диска минимальное, в районе 100-200 IOPS. Да, большие выборки активно кэшируются, на nosql бд приходит около 30к rps. Из MySQL в основном делаются простые выборки по Primary Key для тех данных, которые нежелательно или не нужно кэшировать. Постоянно обновляется кэш и работают кроны, которые используют напрямую БД без кэша.

    Если репликация всё равно асинхронная, то в чем принципиальная разница для разработчика разъедутся ноды на 10 или 1000 транзакций?
    Важно то, что мы знаем на сколько они могут разъехаться, рассчитывать на константу проще. Подробнее ответил в комментарии выше.

    По каким причинам в рассмотрение не попал MySQL NDB Cluster?

    Честно говоря не помню, почему то исключили его из рассмотрения в самом начале поисков решения.
  • Миграция реального приложения со standalone MySQL на Percona XtraDB Cluster
    0
    Вы абсолютно правы, репликация все равно асинхронная и думать все равно приходится. Разница в том, что у нас например длина очереди 173 транзакции, это примерно 0.5 сек отставания при больших транзакциях (округлим до секунды). Разработчик может быть уверен, что измененные данные окажутся на слейве через секунду. В случае обычной асинхронной репликации никаких гарантий нет и слейв может отставать например на пол часа. Хотя на корню это проблему конечно не решает, это не настоящая синхронная репликация.

    Еще можно использовать переменную «wsrep_sync_wait=7». Это заставит ноду выполнить запрос только после применения всех транзакций в текущей очереди.

    Как я уже писал отказоустойчивость это основная причина внедрения кластера у нас. Но защищены только те транзакции, которые успели реплицироваться на остальные ноды. При внезапном падении сервера могут быть потерянные транзакции.
  • Миграция реального приложения со standalone MySQL на Percona XtraDB Cluster
    0
    По тестам от Percona MaxScale медленнее ProxySQL в fast-forward режиме процентов на 10-20%. Учитывая это и то, что нам важна задержка мы решили не тестировать его. В итоге ProxySQL тоже не прошел по задержкам оставив первенство Haproxy. Если у вас есть информация о том, что сейчас ситуация изменилась и MaxScale может обогнать ProxySQL, то мы с удовольствием протестируем его скорость работы.
  • Миграция реального приложения со standalone MySQL на Percona XtraDB Cluster
    0
    У нас уже был опыт использования продуктов от Percona, причем вполне успешный. Нас устраивает их скорость выпуска багфиксов и портирования патчей из апстрима. К тому же они русскоязычные и продают поддержку. Если нам понадобится помощь всегда можно купить у них поддержку их продукта.
    Во-вторых у них есть некоторые патчи на Galera Cluster, которые делают его поддержку более простой (например strict_mode, который не даст выполнить потенциально опасные операции на кластере).
  • Собираем InnoDB cluster из mysql 5.7 на centos 7
    0
    master-master обязан считать транзакцию завершенной только тогда, когда ее совершили все ноды

    Я не уверен как реализовано в MariaDB Galera, но в классическом Galera Cluster и Percona GC это не так. Каждая транзакция валидируется на всех нодах при коммите на отсутствие конфликтов, а репликация самих изменений выполняется уже после коммита.
  • Слишком мало людей обращают внимание на эту экономическую тенденцию
    0
    Противоречит, никто и не спорит. Но если бы все всё делали по логике и здравому смыслу, то мы бы жили в абсолютно другом мире. И не надо думать, что я считаю рабочих дураками, а капиталистов умниками, все они в первую очередь люди. А люди далеко не самые рациональные существа.

    Как пример — распад СССР, куча работающих заводов была продана частным лицам, казалось бы даже инвестировать в производство не надо, оно уже у тебя есть. Надо только поддерживать его на плаву и получать постоянный доход с него. Но нет, большинство заводов было закрыто и распродано или разворовано, часть на все тот же металлолом.
    Или например все знают, что алкоголизм/наркотики/курение ведут к болезням и возможно скорой смерти, но почему то кучу людей это не останавливает.
  • Слишком мало людей обращают внимание на эту экономическую тенденцию
    +1
    Вы сами говорите, что средства производства должны быть в собственности рабочего. Только станок с неба не упадет. Чтобы дать возможность рабочему работать за ним его сначала надо купить, а захочет ли рабочий вкладывать 2-10М рублей в станок, чтобы потом отбивать его стоимость 10 лет?
    Есть конечно вариант отобрать станки у злобных капиталистов и раздать рабочим, но к чему то хорошему это вряд ли приведет. Скорее всего станки сдадут на металлолом.

    ИМХО сейчас общественный строй достаточно сбалансирован, у тех же рабочих есть возможность уйти работать на завод получше к менее «эксплуатирующему» капиталисту. А если так уж не хочется работать на дядю, то открывать ИП и свое производство. Вот только со своим предприятием приходит куча проблем, никакой гарантированной зарплаты, рабочий не может весь день производить полезный продукт, а вынужден делать тысячу других дел, таких как бухучет, продажа товара, закупка сырья, реклама и тд.
    И тут выглядит логичным следующий шаг — делегировать эти обязанности кому то другому и нанять их на зарплату. Oh wait, мы же вернулись к началу, только уже рабочий стал капиталистом.
  • Про износ SSD на реальных примерах
    0
    Офф гарантия — 3.6 перезаписи всего объема накопителя (500 Гб) в день в течение 5 лет. У нас нагрузка должна быть сильно меньше, до 500 Гб в день. С такой нагрузкой скорее контроллер умрет, чем выработается ресурс.
  • Про износ SSD на реальных примерах
    0
    SAMSUNG MZ7KM480HAHP-00005
  • Про износ SSD на реальных примерах
    +3
    Интересная статья, спасибо. А не могли бы вы посчитать (среднюю, и 95/99 перцентиль) скорость износа SSD с разбиением на серверные и консьюмерские модели?
    Тот же хецнер грешит тем, что ставит в дешевые сервера десктопные SSD, причем самые дешевые. У нас их десктопные SSD живут примерно пол года с репликами БД, а ентерпрайзные самсунги уже по 2.5 года работают и умирать не собираются.
  • Как случайно написать Web-GUI для Haproxy
    +2
    а что делать, если туда надо постоянно лазить, править, ну и конечно же нет лога всех действий, не писать же каждый раз cp cfg cfg_back, со временем запутаешься и забьешь на это дело.

    Конфиг Haproxy в Ansible, Ansible в гит. И никаких проблем с версионированием изменений. Плюс без проблем разливается на кучу серверов.
    Для сбора статистики — экспортер в Prometheus, откуда можно вытягивать данные в Grafana и строить красивые графики.

    Ваш подход без сомнения имеет право на жизнь, но по моему описанное выше больше соответствует UNIX-way, т.к. легче масштабируется до десятков-сотен серверов и очень легко умеет в автоматизацию. Накрутить дополнительной логике в Ansible дело нескольких минут, на крайний случай часов, и вот у вас уже есть например авто дискавери бэкендов или автоматическое указание веса бэкенда в зависимости от количества процессорных ядер на нем и все остальное, что вы только сможете придумать. ;)
  • Несколько слов о реальной производительности гипервизора
    0
    Приятно это слышать, правда круто)
    Касательно GPLv2 — вам стоит прочитать ее внимательно. Согласно лицензионному соглашению исходные тексты обязаны быть предоставлены людям, получившим бинарники системы, тем или иным способом.

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

    Многие просто выкладывают исходники в открытый доступ, но не будучи вашим клиентом я не могу требовать их у вас.
  • Несколько слов о реальной производительности гипервизора
    0
    Вы пишите о своих наработках на базе KVM. Отправляете ли вы эти патчи в апстрим и принимают ли их? Можно ли где то у вас на сайте их получить/скачать и нужно ли для этого быть вашим клиентом?
    И QEMU и ядро Linux, частью которого является KVM, публикуются под GPLv2, соответственно исходники должны быть;).
  • Новый Dell XPS 13 глазами админа
    0
    Бп маленький, удобный. Жалко только провод не отстегивается, как на макбучных зарядках.
    Блок питания
    IMG_20180521_114636

    Вообще по характеристикам ноут почти копия Вашего Asus, если он у вас уже есть вы не выиграете в производительности от замены его на делл.
  • Новый Dell XPS 13 глазами админа
    0
    С шумом все более-менее нормально, большинство времени кулер выключен. При запуске чего то тяжелого и длительного, например компиляции большого проекта, начинает активно шуметь. Проц прогревается до 78-84 градусов.
    Использую ядро 4.16.9, дистрибутив Arch, дрова «xf86-video-intel 1:2.99.917+831+ge7bfc906-1». Проблем из-за 4К пока не видел, но не исключаю, что это из-за свежих версий софта, который я использую. Специально брал ноут только со встройкой Intel, что бы не парится с проприетарными дровами нвидии и не править их глюки.
  • Новый Dell XPS 13 глазами админа
    –5
    На просторах интернета куча текстовых и видео обзоров с качественными фото со всех ракурсов, анбоксингом и прочими радостями. Я решил, что вряд ли сделаю обзор внешности ноутбука лучше, чем они и решил сосредоточиться на функциональной части.
  • Новый Dell XPS 13 глазами админа
    0
    Я использовал 175% процентное масштабирование чтобы уменьшить интерфейсы ПО, по мне они часто занимают слишком много места на экране. Таким образом увеличивается размер полезной области экрана.
    Ну и конечно качество шрифтов сильно улучшилось, на FullHD 13-ке были заметны отдельные пиксели, с 4к пикселей не видно вообще.
  • Кластер Hyper-v из двух нод, без внешнего хранилища или гиперконвергенция на коленке
    0
    Имеется, например такое можно организовать с помощь Ceph или кластерных ФС (например Gluster). Но рекомендую все таки смотреть в сторону Ceph.
  • Оптимизация изображений для web
    0
    Судя по страничке Speed-and-memory-use libvips быстрее, но должен заметитить, что результаты imlib2 у них конечно немного странные и возможно они что то не докрутили. Более существенный, по моему мнению, недостаток imlib2- странная лицензия и достаточно маленькое комьюнити. Хотя погонять бенчмарк возможно все таки стоит.)
  • Оптимизация изображений для web
    0
    Сожалею, что не рассказал Вам ничего нового.)
    Все запросы с @ в конце отправляются nginx'ом на ресайз бэкенд.

    Nginx кэширует ответы бэкенда, и при следующем запросе она отдается уже из кэша, а не с бэкенда. В readme в репе есть пример конфига Nginx, который реализует эту логику.
    По поводу ресайза в несколько проходов. Не могли бы Вы рассказать как вы это делали и какой библиотекой? На первый взгляд похоже на проблему с алгоритмом ресайза, из-за которой он при большом изменении размера портил качество. Теоретически вариант, когда мы ресайзим большую в маленькую должен быть лучше, чем вариант, когда мы делаем «большая->средняя->маленькая», т.к. не происходит потери на шаге «большая->средняя».
  • Оптимизация изображений для web
    0
    Естественно, мы так и делаем. В моем коде это работает так:
    Вместо "/test.png" в том месте страницы, где нужна маленькая версия мы пишем "/test.png@75". Все запросы с @ в конце отправляются nginx'ом на ресайз бэкенд. Он в свою очередь пасит url, скачивает оригинал ("/test.png"), ресайзит его до нужного разрешения и отдает nginx'у. Nginx кэширует результат и отдает его клиенту.
  • Оптимизация изображений для web
    0
    Не очень понял, что вы имеете в виду под простым случаем. Часть информации мы при ресайзе естественно теряем, но это не должно ухудшать качество картинки «на глаз»(естественно если потом получившуюся картинку не растягивать до размера оригинала).
    Если же это проявляется в заметных артефакт, то есть смысл смотреть на алгоритм ресайза и его настройки.
    На всякий случай уточню предыдущий коммент: мы храним только оригиналы в максимальном используемом разрешении (200х200 в примере). Менее качественные версии генерируются динамически и только кешируются на некоторое время.
    Второй момент: например про главную. 75х75 это размер, определяемый версткой страницы, то есть в верстке есть контейнер 75х75 пикселей и мы вставляем туда версию нужного размера. Мы естественно не вставляем 75 версию в 200 контейнер.
  • Оптимизация изображений для web
    0
    Немного не наш кейс, у нас это работает например для таких случаев: аватарка пользователя хранится и показывается в профиле в 200х200, но на страницах форума показывается в 150х150, а например на главной в 75х75. И все эти уменьшенные версии надо генерить автоматом. Кроп, кадрирование и прочие фичи там не нужны.
  • Оптимизация изображений для web
    0
    Мы естественно тоже кешируем результаты nginx'ом, но бывают например, что приходит какой то трафик на старые страницы, для которых кэша нет или сбросился кэш. Отсюда интерес к производительности без кеша.
    Чем нам не понравилось решение на nginx- накрутить нашу логику в конфиге можно, но выглядеть это будет очень уж страшно. Новых проектов это конечно не касается, там больше свободы и можно и на nginx сделать красиво.
  • Оптимизация изображений для web
    0
    А у вас он проксирует весь трафик или отдельный инстанс, который занимается только ресайзом? Какую примерно нагрузку он держит с кэшированием и без?
  • Оптимизация изображений для web
    0
    Libvips дает возможность конвертировать картинки между разными форматами, в том числе в webp, но мы пока ей не пользуемся. За наводку спасибо, возможно стоит конвертировать в webp.