Zabbix 5

30.01.2020, 18:54

Вышла альфа версия системы мониторинга Zabbix 5 - 5.0.0 alpha1.

Новая версия включает в себя:

  • элемент данных ipmi.get, который позволяет опрашивать и обнаруживать IPMI-сенсоры.
  • ключи элементов данных теперь могут быть длиной до 2048 символов.
  • возможность разрешать или запрещать определенные проверки на стороне клиента.
  • пароли пользователей теперь шифруются bcrypt, вместо MD5.
  • для вебхуков теперь можно использовать HTTP-прокси.
  • возможность отсоединять шаблоны при массовом обновлении.
  • поддержка мониторинга redis
  • поддержка Zabbix Agent 2 (новое поколение агента, нацеленного на лучшее сетевое взаимодействие, поддержку плагинов и больший параллелизм).

Дата выхода финального релиза не определена, но предположительно релиз Zabbix 5 можно ждать в апреле-мае текущего года.

Fedora Core OS

19.01.2020, 19:49

Fedora CoreOS готова к использованию в продакшене, сообщают разработчики.

Fedora CoreOS - новая редакция Fedora, построенная специально для запуска контейнеризированных приложений, безопасно и масштабируемо. Fedora CoreOS наследует идеи из Fedora Atomic Host и CoreOS Container Linux, поддержка которых прекратится в этом году.

Fedora CoreOS объединяет в себе средства развертывания и модель автоматического обновления Container Linux, поддержку OCI, и SELinux из Atomic Host.

Дистрибутив построен на базе Fedora 31, включает в себя Linux 5.4, systemd 243, Ignition 2.1, поддержку OCI и Docker Container с помощью Podman 1.7 и Moby 18.09.

Ошибки масштабирования систем

07.01.2020, 00:54
Отсутствие поиска архитектурного решения

Вместо этого нередко происходит описание реализации с перечислением главных компонентов (БД, ОС, языка программирования, аппаратного обеспечения и т. п.). Однако данный подход не решает проблему масштабирования. Сравните два варианта:

а) Java-платформа, работающая на Apache Felix с MySQL, GlassFish и MongoDB;
б) платформа с 3-уровневой архитектурой с изолированными зонами и отсутствием синхронной коммуникации между зонами. При хранении данных использовано сочетание реляционной и нереляционной БД с применением горизонтального шардинга и встроенной репликации.

Разумеется, правильным будет второй подход.

В проектировании не заложена вероятность ошибки

Ломается всё: оборудование, процессы и особенно люди. Но если основные службы, компоненты и потребительские сервисы правильно спроектированы и изолированы друг от друга, последствия сбоя незначительны. В обратном случае мы получаем «Титаник», печальный пример которого демонстрирует нам неправильное проектирование: отсутствие изоляции между отсеками кормовой части привело к тому, что вода банальным образом переливалась через переборки. Итог мы все помним.

Вместо распределения нагрузки — вертикальное масштабирование

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

Такое решение в архитектуре не только приводит к повышению расходов на транзакции, но и может принести существенный ущерб в случае сбоя. В конечном итоге, либо система будет слишком громоздкой и станет частично простаивать, что поставит под вопрос эффективность ваших капиталовложений, либо система окажется недостаточно крупной при росте проекта. Как бы там ни было, это всё равно закончится проблемами для вашего продукта. Достаточно вспомнить PayPal в 2004 г. и eBay в 1999 г.

Выбор неверных инструментов

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