Jump to content
Калькуляторы

Выбор ОС под Zabbix FreeBSD vs CentOS

Коллеги, нарисовалась задача поднять zabbix для NOC. Есть ли какие минусы в инсталляции под FreeBSD в сравнении с Linux CentOS. Просто привык работать с FreeBSD, не хочется с линуксом заморачиваться.

Если нужно больше вводных данных, пишите каких, отвечу. Инсталляция крупная - более 2000 железок, в основном Cisco.

Edited by Merridius

Share this post


Link to post
Share on other sites

Меньше народу - хуже тестируется, меньше выявляется косяков. В случае возникновения проблем больше вероятность что вам никто не поможет, потому что у меньшего количества людей будет сетап похожий на ваш. С линуксом меньше проблем с зависимостями, апгрейдом, больше фитч работает автоматом без дополнительных плясок с бубном, lts ветки особенно приятны(По собственным ламерским ощущениям фряхи оставшимися где-то с FreeBSD 8). А так-то если вы действительно хорошо знаете FreeBSD - вы справитесь. По производительности так вообще пофигу под чем, уделите больше внимания базе данных, партицированием там, кеширование и т. п.

Edited by greywind

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

я скажу, что платформозависимого кода на заббиксе особо то и нет

server side - C

frontend - PHP

 

тут ИМХО лучше использовать то что лучше знаешь

Share this post


Link to post
Share on other sites

Сам в прошлом заядлый фряшник, но в данном случае посоветую центу, у самого zabbix в крупной инсталяции крутится на CentOS 7.

Share this post


Link to post
Share on other sites

Есть ли какие минусы в инсталляции под FreeBSD

отсутствие в принципе понятия "стабильная ветка"/"LTS дистрибутив". а также, цитирую, "Коллекция портов поддерживается на последних релизах веток FreeBSD-CURRENT и FreeBSD-STABLE. Предыдущие релизы не поддерживаются и могут работать или не работать корректно с обновленной коллекцией портов."

т.е. поставили вы 2 года назад скажем бздю 10.2 (самую свежую на тот момент), или 9.3 как обкатанную и стабильную, а сейчас оп - и не можете ничего из портов поставить/обновить, потому что порты с недавнего времени вообще не поддерживают ниже 10.3 ветки никак (о чем новость проскакивала).

 

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

 

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

Share this post


Link to post
Share on other sites

обновлялось в полтыка клавиши - это центос либо, еще лучше, дебиан.

 

Давно забыли миграцию на systemd ?

Share this post


Link to post
Share on other sites

Давно забыли миграцию на systemd ?

какая такая миграция? LTS дистр - не слышали, не? CentOS 5 вон до сих пор поддерживается. 10 лет, да. при этом - на дистр, который не обновлялся, нет никаких проблем накатить обновления пакетов либо поставить нужный пакет. более того, даже после окончания поддержки его можно эксплуатировать (если нет большой паранойи касательно уязвимостей), и пакеты на ту же центось 5 можно будет поставить и через 5 лет. без масштабного обновления/переустановки системы.

 

а сколько часов/суток вы протрахаетесь, если на какую-нить бздю 6.3 (ровестницу центос 5), которую прошлый админ поставил и забыл о ней, вам сейчас потребуется поставить скажем тот же mpd5 или фрирадиус? :)

 

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

Share this post


Link to post
Share on other sites

а сколько часов/суток вы протрахаетесь, если на какую-нить бздю 6.3 (ровестницу центос 5), которую прошлый админ поставил и забыл о ней, вам сейчас потребуется поставить скажем тот же mpd5 или фрирадиус? :)

 

Мин 10. 8 из них потрачу на поиск нужного пакета под конкретную версию системы.

А вот головная боль с поддержкой системы EOL и прикладного ПО - это к владельцу сервера. Вы ведь на линуксе слышали про EOL ?

 

P.S. LTS Centos некорректно сравнивать ибо это форк платной RedHat, где есть небесплатная подписка. Лучше сравнивайте с LTS Дебиана, у которого она 5 лет.

Share this post


Link to post
Share on other sites

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

 

Я так и не понял про проблемы на FreeBSD.

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

Один раз сделал и многократно применяешь.

 

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

Share this post


Link to post
Share on other sites

Мин 10. 8 из них потрачу на поиск нужного пакета под конкретную версию системы.

угу, и кучки зависимостей...

 

А вот головная боль с поддержкой системы EOL и прикладного ПО - это к владельцу сервера. Вы ведь на линуксе слышали про EOL ?

какая такая головная боль? :) сильно будет надо - можно и на следующую версию заапдейтиться. а в бзде понятия версии нет вообще ("версия дистра" это вресия ядра и базового окружения, порты - rolling-release что есть дичь и попоболь в продакшне). + поддержка свежей системы, как показала практика, ограничивается максимум 2 годами...

 

P.S. LTS Centos некорректно сравнивать ибо это форк платной RedHat, где есть небесплатная подписка. Лучше сравнивайте с LTS Дебиана, у которого она 5 лет.

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

 

ну и да, 5 лет и rolling release - это две большие разницы. rolling release никто в здравом уме в прод ставить не будет, а поставив раз - заречется навсегда от таких экспериментов.

 

Я так и не понял про проблемы на FreeBSD.

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

Один раз сделал и многократно применяешь.

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

Share this post


Link to post
Share on other sites

Просто привык работать с FreeBSD, не хочется с линуксом заморачиваться.

 

Zabbix appliance is available in the following formats:

 

vmdk (VMware/Virtualbox)

OVF (Open Virtualisation Format)

KVM

HDD/flash image, USB stick

Live CD/DVD

Xen guest

Microsoft VHD (Azure)

Microsoft VHD (Hyper-V)

 

https://www.zabbix.com/documentation/3.0/ru/manual/appliance

 

Docker.

 

https://www.zabbix.com/documentation/3.0/manual/installation/containers

 

https://www.zabbix.com/documentation/3.0/ru/manual/installation/containers

Share this post


Link to post
Share on other sites

Давно забыли миграцию на systemd ?

 

Пришлось подправить ровно один скриптик. :) Я даже не догадывлся, что это такая боль и страдания для мира. :)

Share this post


Link to post
Share on other sites

На Линукс ИМХО проще и удобнее. Берите какой нибудь Centos и не заморачиваться. Основные проблемы с БД.

Share this post


Link to post
Share on other sites

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

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

Сам Заббикс написан на C, и даже много триггеров на много хостов суровой нагрузки не создает.

 

По БД - я думаю, можно найти в сети мерялки производительности БД под разными ОСь и прочее, если для вас это важно.

Еще люди рекомендуют вместо MySQL брать Перкону или Марию или Постгрес.

Партирование таблиц крайне рекомендуется, и сразу, и на любой из БД.

 

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

 

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

Share this post


Link to post
Share on other sites

Лучше брать ту ОС которую знаешь.

Большинство приложений на ОС завязаны слабо и бсд/линух практически не отличают.

Share this post


Link to post
Share on other sites

Перкона не нужна. Счас в innodb многи фичи скопированы из xtradb. Смотрел тесты, примерно одинаковые результаты.

А вообще я за Centos. Комьюнити огромное. Все хотелки можно реализовать. Опять же, тот же ред хат.

Share this post


Link to post
Share on other sites

Мин 10. 8 из них потрачу на поиск нужного пакета под конкретную версию системы.

угу, и кучки зависимостей...

Неправда :) в таких пакетах нет расхождений от версий библиотек-зависимостей.

 

P.S. LTS Centos некорректно сравнивать ибо это форк платной RedHat, где есть небесплатная подписка. Лучше сравнивайте с LTS Дебиана, у которого она 5 лет.

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

 

Удачи в поисках опций сборки.

 

Я так и не понял про проблемы на FreeBSD.

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

Один раз сделал и многократно применяешь.

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

Чудеса в конфигах и дефолтах - это от автора пакета. В линуксе тоже авторы пакетов присутствуют и те же грабли :)

 

подтянул репо свежей ветки и запустил апдейт, скрестив пальцы...

И молишься, чтоб не было циклической зависимости пакетов и библиотек :)

Share this post


Link to post
Share on other sites

подтянул репо свежей ветки и запустил апдейт, скрестив пальцы...

И молишься, чтоб не было циклической зависимости пакетов и библиотек :)

решается докером.

Share this post


Link to post
Share on other sites

Неправда :) в таких пакетах нет расхождений от версий библиотек-зависимостей.

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

 

Чудеса в конфигах и дефолтах - это от автора пакета.

бред. яркий пример - апдейт самбы 3.х->4.x. один и тот же конфиг - а 4-я версия с ним не работает. оказывается, девелоперы поменяли дефолты.

 

ну и прочие "мелочи", типа появления новых обязательных опций (которых, ессно, в старых конфигах нет) и т.п.

 

В линуксе тоже авторы пакетов присутствуют и те же грабли :)

на LTS дистрах такого нет в принципе. потому что версии пакетов не меняются, только фиксы бэкпортируются. потому - регулярный апдейт проходит одной командой yum update && yum upgrade (или apt-get update && apt-get upgrade). преимущества freezed версий, да.

 

И молишься, чтоб не было циклической зависимости пакетов и библиотек :)

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

 

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.