Pilat

Рейтинг
250
Регистрация
08.03.2007

Да не надо ничего заменять. Классическая связка apache+nginx всё поправит. На форуме это разъясняется раз в неделю подробно. Если лень даже форум пролистать, то нанимайте админа.

Возможно, тут вот что случилось:

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

Серверные диски имеют установленной опцию, после которой при возникновении проблемы сразу выдают ошибку и диск вылетает из рейда или что-то ещё происходит восстановительно-исправительное (что может сделать рейд), но производительность в итоге не проседает.

К сожалению, в случае с SATA надпись RAID Edition в данном случае ничего не значит, некоторые диски можно перевести в первый режим, некоторые нет.

При такой низкой скорости я бы попробовал сделать копию на другом сервере или VDS и подать ту же нагрузку и проверить результат.

---------- Добавлено 03.05.2016 в 01:02 ----------

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

А Вы уверены, что

Total DISK READ : 914.72 K/s | Total DISK WRITE : 123.10 K/s
Actual DISK READ: 913.92 K/s | Actual DISK WRITE: 375.29 K/s

это половина от пиковой нагрузки? Цифры то какие-то совсем крошечные.

Вы бы остановили всё и проверили скорость чтения с диска при нулевой активности. Может диски давно умерли.

64 менее проблемный выбор. У меня есть несколько 32-х разрядных систем, и время от времени приходится совершать переход на 64.

Ну и стандартизация - проще обслуживать одинаковые архитектуры.

ownCloud работает достаточно нормально. Конечно, не без проблем, но с бытовыми задачами справляется нормально. Лучше других.

В основном это актуально для тех, кто должен автоматически переводить "местное время" в UTC.

netwind:
Нашел только тему от 2008 года "Караул, Хетцнер перестал поддерживать высокую доступность". https://www.howtoforge.com/community/threads/hetzner-to-stop-support-for-high-availability-setups.19988/
Что ожидаемо.
Алгоритм то реализует, но с API hetzner эта обвязка не заработает.
Все эти реализации отказоустойчивости рассчитаны на работу в нормальной сети, где IP в одном локальном сегменте. А тут надо чтобы вызывалось API и ip волшебным образом переключался. Тут нужна модификация обычной схемы.

Еще, кстати, вашу тему нашел (на упавшем в данный момент сервере) http://www.pilat66.ru/proxmox-i-hetzner.html

Так что именно вы имели ввиду ?

Я вчера первым делом наткнулся на https://github.com/ahes/hetzner-api-failover - похоже как раз на примочку к keepalived.

За упавший сервер спасибо. Настрою монит - что-то часто стал он падать.

Dimka:
Тогда алгоритм такой?

Посмотрите гугл на "keepalived hetzner" - keepalived как раз сам алгоритм и реализует.

---------- Добавлено 25.03.2016 в 23:46 ----------

Dimka:

2. Возможна ли ситуация с ложным срабатыванием и переключением? Например, если проблемы с каналом на резервном (проверяющим) сервере. Как учесть?

Поставьте etcd на все три сервера, он выберет лидера при крахе.

---------- Добавлено 26.03.2016 в 01:40 ----------

А лучше всего поставьте HAProxy + keepalived

lonelywoolf:
Rulin, Не проще на своём сервере почтовик поднять? При больших кол-вах ящиков/почты оно дешевле, а при малых на затратах практически не сказывается...

Основная проблема не поднять ящик, а получить к нему интерфейс. C Google сравниться никто не сможет.

Можно рассмотреть такой вариант: rsync'ом бэкапить на удалённый сервер, а там полученную копию архивировать программой типа attic - сохраняя различия с предыдущим бэкапом. Ну или простым tar'ом.

Всего: 2896