Upgrade strategy без/с минимальным даунтаймом

[shishieff]

Доброго времени суток.

Нам бы хотелось обновить zabbix с версии1.8 до версии 2.0.1 по сути изза двух фич. Во первых это нативная поддержка JMX и второе конечно аннонсированная лучшая производительность.

Мы используем достаточно разветвленную архитектуру из 3 zabbix серверов и несколько proxy серверов, консолидирующие данные из нескольких датацентров. В zabbix поступают данные не только по производительности машин, но и business-specific параметры. Мы бы не хотели терять видимости на период обновления, учитывая что размер базы данных у нас достаточно большой. Похоже что это и является источником проблемы, так как upgrade скрипт будет её долго молотить.

+---------------------------------------+--------+-------+-------+------------+---------+
| CONCAT(table_schema, '.', table_name) | rows | DATA | idx | total_size | idxfrac |
+---------------------------------------+--------+-------+-------+------------+---------+
| zabbix.history_uint | 27.20M | 5.78G | 2.68G | 8.45G | 0.46 |
| zabbix.history | 13.48M | 1.98G | 0.88G | 2.86G | 0.45 |
| zabbix.trends_uint | 12.89M | 1.36G | 0.00G | 1.36G | 0.00 |
| zabbix.trends | 3.27M | 0.40G | 0.00G | 0.40G | 0.00 |
| zabbix.alerts | 0.35M | 0.20G | 0.05G | 0.25G | 0.25 |
| zabbix.events | 0.63M | 0.09G | 0.08G | 0.16G | 0.90 |
| zabbix.auditlog | 1.00M | 0.10G | 0.04G | 0.14G | 0.43 |
| zabbix.items | 0.01M | 0.01G | 0.01G | 0.02G | 0.65 |
| zabbix.items_applications | 0.02M | 0.01G | 0.01G | 0.01G | 1.41 |
| zabbix.triggers | 0.01M | 0.01G | 0.00G | 0.01G | 0.41 |
+---------------------------------------+--------+-------+-------+------------+---------+

Данные дублируются на различные zabbix сервера, приходя в том числе и с заббикс-прокси серверов. Мы можем вполне иметь один из заббикс серверов в дауне на обновление, но хотелось бы чтобы данные там были в целостности.
Я сначала планировал использовать zabbix-прокси на период даунтайма, чтобы закешировать данные и потом они попали в новый сервер, но насколько я понимаю нет возможности построить цепочку из прокси серверов. Проблема усугубляется тем, что заббикс прокси сервер версии 1.8 не работает с заббикс сервером 2.0. Что означает похоже, что прокси нужно будет обновлять сначала( что ОК, так как это выполняется достаточно быстро) Верно ли, что заббикс прокси 2.0 будет работать с сервером 1.8 ?

Ресурсов у нас достаточно, то есть количество серверов не проблема. Проблема понять, как возможно обновить сервер без/с минимальным даунтаймом. Есть у кого какие идеи?

[shishieff]

Никаких идей ?

[dotneft]

Zabbix прокси версии 1.8 не будет работать с 2.0. Это факт: http://www.zabbix.com/documentation/...си

Можно вообще без остановки сделать. Но для этого потребуется примерно такой план работ:
1. Перевод всех хостов на прокси
2. Остановка zabbix сервера.
3. Перевод всех серверов на zabbix сервер в вебе.
4. Обновление zabbix серверов.
5. Остановка прокси и запуск серверов.
6. Конвертация прокси
7. Перевод хостов которые были на сервере обратно на прокси (не уверен, но может не скушать данные от прокси, если для наблюдаемого сервера не выбран именно требуемый прокси)
8. Запуск новых прокси

[shishieff]

будет ли zabbix proxy 2.0 работать с zabbix сервер 1.8 ?

[dotneft]

будет ли zabbix proxy 2.0 работать с zabbix сервер 1.8 ?

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

[shishieff]

Спасибо. Становится более менее ясно.

Проблема получается в том, что у нас несколько локаций. С одной локации данные идут через прокси на 3 сервера. В другой локации данные льются напрямую на сервера. Казалось бы, что можно остановить сервер и поднять прокси вместо него на этом же айпи/порту. Сервер перевесить на другой порт и после обновления слить данные на него с прокси а потом вернуть обратно сервер на стандартный порт, опустив прокси. Даунтайм минимальный, однако такой сценарий не будет работать, так как заббикс прокси не работают в цепочке. То есть данные с удаленной локации будут потеряны для обновляемого сервера.

Насколько я теперь понимаю, обновлять прокси сервер на данной локации придется последним, так как пока существует хоть один сервер 1.8 прокси должна быть этой версии. Это означает что новые сервера 2.0 не получат данных с неё. Проблема усугубляется тем, что невозможно обновлять все сервера сразу, никто не может сидеть слепым без мониторинга несколько дней.

[shishieff]

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

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

Ах если бы заббикс прокси поддерживали цепочки!

[dotneft]

Несколько дней? оО

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

> С одной локации данные идут через прокси на 3 сервера.

прошу прощения, а это как?

[shishieff]

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

[shishieff]

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

Однако вопрос остается открытым, как сделать обновление без этого даунтайма в несколько часов( возможно больше, пока не протестировал Ж)

[shishieff]

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

1. установка заббикс-прокси 2.0 на сервер
2. остановка заббикс-сервера, поднятие на его порту прокси 2.0 при этом первый прокси сервер в цепочки уже не может слать данные на него, заббикс клиенты при этом чувствуют себя хорошо.
3. обновление сервера до 2.0
4. поднятие сервера на другом порту и дождаться пока прокси сольет закешированные данные.( не совсем понятно как понять, что кеш слит)
5. остановка прокси сервера и запуск сервера 2.0 на стандартном порту.
6. остановка первого прокси сервера и обновление его до 2.0


Тогда возникают такие вопросы:
1. как поведет себя прокси сервер 1.8 если обнаружит что он разговаривает с прокси 2.0 вместо сервера? закеширует ли он данные?
2. что будет если прокси сервер 1.8 обновить на 2.0 когда его кеш наполнен данными ( мы используем sqlite для прокси кеша) ? Насколько мне кажется сейчас ( я могу ошибаться конечно), что кеш полностью испортиться, что приведет к потере данных на момент обновления.

[dotneft]

Тогда возникают такие вопросы:
1. как поведет себя прокси сервер 1.8 если обнаружит что он разговаривает с прокси 2.0 вместо сервера? закеширует ли он данные?
2. что будет если прокси сервер 1.8 обновить на 2.0 когда его кеш наполнен данными ( мы используем sqlite для прокси кеша) ? Насколько мне кажется сейчас ( я могу ошибаться конечно), что кеш полностью испортиться, что приведет к потере данных на момент обновления.

1. Нет. Я вам и не предлагал этого.
2. Такого не должно быть. Но рекомендую сделать копию БД и проверить.

[zalex_ua]

1. как поведет себя прокси сервер 1.8 если обнаружит что он разговаривает с прокси 2.0 вместо сервера? закеширует ли он данные?
2. что будет если прокси сервер 1.8 обновить на 2.0 когда его кеш наполнен данными ( мы используем sqlite для прокси кеша) ? Насколько мне кажется сейчас ( я могу ошибаться конечно), что кеш полностью испортиться, что приведет к потере данных на момент обновления.

1. они просто не смогут "разговаривать" так как оба прокси и это не предусмотрено.

2. Кеш НЕ испортится, это и есть правильный подход в вашем случае !
Только нюанс в том что патчей под sqlite нету, не делают их. Поэтому можно временно переключится на мускул на проксях на период апгрейда, а потом опять ернетксь на sqlite.

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