Картиночный сервер, где хранятся и обрабатываются все картинки, начал глючить. Раз-два в неделю зависает так, что даже автоматический резет не помогал. Похоже проблема хардварная. В хетцнере это решается просто - отдаёшь сервер им на диагностику на 12 часов. Делать неработающими картинки на 12 часов не очень хотелось. Поэтому надо было перенести его на другой сервер.
Но тут я подумал - у меня, включая картиночный, уже есть 4. На трёх диски не загружены почти. Память есть. В основном используется процессор для отдачи php. Почему бы не сделать какую-нибудь кластерную фс и убрать одну из точек отказа? Тогда все сервера с апачем будут равноправными, все вместе писать/читать с этой фс и всё будет збс.
Посмотрел какие есть кластерные фс. Самая крутая - ceph. Уже год как вышли из беты. Пишут, что офигенно быстрая и надёжная. Самовосстанавливается, нет одной точки отказа. В будущем можно просто подключать к ней жёсткие диски и она всё будут перебалансировать.
Придумано - сделано. Код на php быстро подправил: ломать - не строить. По сути надо было сломать весь код, который отвечал за перенаправление картиночных запросов на картиночный сервер.
Поставил ceph. Во время установки удивило, что они полностью тестируют только на убунте с дефолтным ядром 3.2, но рекомендуют обязательно обновляться до ядра 3.4/3.6, ибо на более ранних версиях у них не работают серверные модули о_О. Ядро 3.6 и "стабильность" у меня в глове не укладывались, но можно было всё сделать и без модулей ядра. Поэтому ceph был успешно установлен и подмонтирован.
С первого взгляда, всё было хорошо. Есть на одном сервере создать файл, то он появлялся на другом сервере.
И тут я совершил роковую ошибку. Я доверился их заявлениям о скорости/стабильности и переключил сервера на использование ceph.
продолжение следует...
20.03.2013, 10:20
Да, живу в Эстонии. — PussyFucker69#ответить↓ %comment_rating_1944408%
http://joyreactor.cc/post/701493#comment1944408
Так и должно быть?
http://joyreactor.cc/post/701493#comment1944408
Так и должно быть?
уже переключив сервера на использование ceph было обнаружено:
1) скорость записи на ceph оказалась около 5Мб/с с пяти серверов, на каждом из которых почти незагруженный raid1 2x3Gb sata. Получалось, что каждый сервер добавлял к общей скорости 1МБ/с. И это был какой-то пипец.
2) "пинг" данных был жутко большим. То есть, время записи любого мелкого файла была в среднем несколько секунд.
3) На серверах вдруг началась огромная нагрузка на харды.
4) сервер метаданных - который хранит список файлов и их метаданные вроде размера, прав и т.д. - не хочет кластеризовываться. Их было запущено 3, но реально работал только один. При этом жрал память и проц очень нехило.
Единственный работающий сервер метаданных работал на достаточно загруженной железке. Я его туда хотел поставить просто как резерв. Начал искать как его исключить из кластера - нигде не написано. Ну остановил сервис. Файловая система перестала отвечать на ls. Мониторы состояния писали, что сервер метаданных наверное упал или лагает. Ну я подумал - они же самовосстанавливающиеся! Сейчас они посмотрят на это и переключатся на другой сервер метаданных.
Прошло 30 минут.
Мониторы всё так же говорили, что один сервер метаданных "подлагивает". А остальные замечательно работают, но запросы туда не идут - все ждут, когда этот самый лучший сервер поднимется обратно. Включил его обратно. Некоторые файлы побились.
После этого я перестал эксперементировать с ceph. Позже я прочитал две интересных записи по нему:
1) файловая система на основании ceph - эксперементальная и нифига не тестировалась. И когда они писали "ceph - стабильный и крутой!" они не имели ввиду файловую систему. А то, что во всех мануалах в первую очередь пишется как создать cephfs - это для наглядности
2) их демон время от времени запускает замечательную команду sync. Вернее, он её похоже постоянно запускает. И если у вас на одном сервере кто-то ещё работает с диском, то настаёт пипец и он перестаёт использовать файловый кэш.
Несмотря на фейл с ceph, я всё же хотел убрать эту точку отказа. День потратил на изучение других фс и вот что нашёл:
1) glusterfs - восстанавливается не вручную. Время от времени случаются фейлы и вся система умирает. Об этом опыте - во втором абзаце статьи http://habrahabr.ru/post/157029/ . У них на форуме нашёл пару вопросов "У меня на последней версии всё пало нахрен. Что делать?". И ответов "ага, у меня тоже. Буду откатываться до предпоследней". При попытках потрогать ручками обнаружил "интересную" поддержку ipv6:
- утилита для онлайн-конфигурирования не умеет ipv6. На форуме советовали в таком случае использовать конфигурирование через кофиг-файлы.
- начиная с версии 3.2 нельзя конфигурировать его через конфиг-файлы. Надо использовать утилиту (которая всё так же не умеет ipv6)
- если сервер слушает порт на ipv4, то подключиться к другому серверу через ipv6 он не сможет. Из трёх пунктов следует, что запустить кластер на ipv6 можно. Но его нельзя сконфигурировать. Зато напротив "ipv6 support" стоит галочка.
- нет никакой системы авторизации. Везде советуют убивать нафиг фаервол - он только мешает. Никаких логин-паролей. Можно подключиться к любому серверу и выполнять админские команды. Надо будет попробывать просканировать чужие сервера на предмет наличия этого порта и проверить возможность запуска команды gluster volume stop & delete.
2) lustre - есть только под ядро 2.6.16 - rhel5. Я уже всё обновил до rhel6, так что отпадает.
3) ocfs2 - официальные билды только под rhel5. Говорят с openvz плохо работает
4) gfs2 - поддержка от редхата, но похоже надо очень сильно мудрить с настройкой.
После этого я плюнул, перенёс картиночный сервер на другую железку и сейчас отдам старую на тестирование. Печаь и грусть. Нет нормальных кластерных фс =(
1) скорость записи на ceph оказалась около 5Мб/с с пяти серверов, на каждом из которых почти незагруженный raid1 2x3Gb sata. Получалось, что каждый сервер добавлял к общей скорости 1МБ/с. И это был какой-то пипец.
2) "пинг" данных был жутко большим. То есть, время записи любого мелкого файла была в среднем несколько секунд.
3) На серверах вдруг началась огромная нагрузка на харды.
4) сервер метаданных - который хранит список файлов и их метаданные вроде размера, прав и т.д. - не хочет кластеризовываться. Их было запущено 3, но реально работал только один. При этом жрал память и проц очень нехило.
Единственный работающий сервер метаданных работал на достаточно загруженной железке. Я его туда хотел поставить просто как резерв. Начал искать как его исключить из кластера - нигде не написано. Ну остановил сервис. Файловая система перестала отвечать на ls. Мониторы состояния писали, что сервер метаданных наверное упал или лагает. Ну я подумал - они же самовосстанавливающиеся! Сейчас они посмотрят на это и переключатся на другой сервер метаданных.
Прошло 30 минут.
Мониторы всё так же говорили, что один сервер метаданных "подлагивает". А остальные замечательно работают, но запросы туда не идут - все ждут, когда этот самый лучший сервер поднимется обратно. Включил его обратно. Некоторые файлы побились.
После этого я перестал эксперементировать с ceph. Позже я прочитал две интересных записи по нему:
1) файловая система на основании ceph - эксперементальная и нифига не тестировалась. И когда они писали "ceph - стабильный и крутой!" они не имели ввиду файловую систему. А то, что во всех мануалах в первую очередь пишется как создать cephfs - это для наглядности
2) их демон время от времени запускает замечательную команду sync. Вернее, он её похоже постоянно запускает. И если у вас на одном сервере кто-то ещё работает с диском, то настаёт пипец и он перестаёт использовать файловый кэш.
Несмотря на фейл с ceph, я всё же хотел убрать эту точку отказа. День потратил на изучение других фс и вот что нашёл:
1) glusterfs - восстанавливается не вручную. Время от времени случаются фейлы и вся система умирает. Об этом опыте - во втором абзаце статьи http://habrahabr.ru/post/157029/ . У них на форуме нашёл пару вопросов "У меня на последней версии всё пало нахрен. Что делать?". И ответов "ага, у меня тоже. Буду откатываться до предпоследней". При попытках потрогать ручками обнаружил "интересную" поддержку ipv6:
- утилита для онлайн-конфигурирования не умеет ipv6. На форуме советовали в таком случае использовать конфигурирование через кофиг-файлы.
- начиная с версии 3.2 нельзя конфигурировать его через конфиг-файлы. Надо использовать утилиту (которая всё так же не умеет ipv6)
- если сервер слушает порт на ipv4, то подключиться к другому серверу через ipv6 он не сможет. Из трёх пунктов следует, что запустить кластер на ipv6 можно. Но его нельзя сконфигурировать. Зато напротив "ipv6 support" стоит галочка.
- нет никакой системы авторизации. Везде советуют убивать нафиг фаервол - он только мешает. Никаких логин-паролей. Можно подключиться к любому серверу и выполнять админские команды. Надо будет попробывать просканировать чужие сервера на предмет наличия этого порта и проверить возможность запуска команды gluster volume stop & delete.
2) lustre - есть только под ядро 2.6.16 - rhel5. Я уже всё обновил до rhel6, так что отпадает.
3) ocfs2 - официальные билды только под rhel5. Говорят с openvz плохо работает
4) gfs2 - поддержка от редхата, но похоже надо очень сильно мудрить с настройкой.
После этого я плюнул, перенёс картиночный сервер на другую железку и сейчас отдам старую на тестирование. Печаь и грусть. Нет нормальных кластерных фс =(
Ja,Ja, ich bin kaputt! Я же предупреждал про многое в оптимизации ещё давно(в прошлом посту)... Мог бы спросить прежде чем фигню творить, есть куча других способов, если ты всего-то мелкий джойреактор на ЧЕТЫРЁХ серверах держишь - это мда, клиника. Мало того, я тебе могу гарантировать что нормальных таких фс для хайлоада даже под кривой линукс 3.x нету, не так разбивать надо.
Ну, я не телепат, а async есть почти во всех и линуховых ФС, это как бы К.О. намекает. Естественно ещё можно избавляться от atime, но мало чего даёт, geom scheduler тоже(в линуксе штатные), но тоже ни хрена не дают. А вот что в никсах с софтрейдами кроме ужаса md - не смотрел. На деле это в разы быстрее чем хреновый LSI без кэша к примеру.
Да посты нахрен, я вообще много где по оптимизации www отметился, только это уже моё личное развлечение.
Да посты нахрен, я вообще много где по оптимизации www отметился, только это уже моё личное развлечение.
P.S. Хочешь реально скорости - бери сходу NFS, лучше заказать отдельный канал между серверами если в одной стойке. Реально СКОРОСТИ другого масштаба - простой скрипт на php , кладущий заранее известные файлы в memcache, а уж оттуда умеет забирать напрямую nginx, но суть в чистке, для этого скрипт и нужен.
Оба. Статистика нереальная же.
166805/32858 198843/42324
Пакет 1.5к, вообще должны быть забиты под завязку на раздаче, а на деле 166805/1024*1500=244343(ну -20% TCP max, а тут 32858!) или c обратной стороны 42324/1.5 примерно 28816 плюс оверхед опять же. Вопрос - откуда столько лишних? По раскладу не стоит даже blackhole судя по всему и сервер возвращает icmp unreachable.
166805/32858 198843/42324
Пакет 1.5к, вообще должны быть забиты под завязку на раздаче, а на деле 166805/1024*1500=244343(ну -20% TCP max, а тут 32858!) или c обратной стороны 42324/1.5 примерно 28816 плюс оверхед опять же. Вопрос - откуда столько лишних? По раскладу не стоит даже blackhole судя по всему и сервер возвращает icmp unreachable.
В смысле? Я забил давно и только рабочие делаю сейчас из веба. А так old-games тот же тащил из НАГРУЖЕННОГО, вытащил - надоело, правда сейчас там всё по другому, торренты я попутно сделал. Но вообще они там деградируют потихоньку, ещё система кэша была, но похоже снесли т.к. "неудобно делать рекламу на ajax фреймах".
old-games - это вот этот http://www.old-games.ru/ высоконагруженный проект с посещалкой 7k уников в день?
Apache для отдачи статики? Да вы батенька извращенец.
Пардоньте.
И да, FreeBSD "фарева", благо NGINX под него сначала разрабатывался и многие его фичи в линухе не доступны или не запилены. (З.Ы. я не против линуха)
И да, FreeBSD "фарева", благо NGINX под него сначала разрабатывался и многие его фичи в линухе не доступны или не запилены. (З.Ы. я не против линуха)
Ага, а ещё это всё частяком забрасывается.
хэцнер то еще ДС. Сомневаюсь, что они найдут проблему. Много раз уже общался с ними по этому поводу.
Реально их заставить поменять винт когда SMART начинает показывать критичные показатели как pre-fail или если появляются ошибки, что винт не отвечает.
Еще, если они все таки предложат вариант замены то лучше чуть-чуть доплатить (кажись 10 евро) и поставить гарантировано новый винт. по умолчанию они предлагают поставить бу винт с менне 700 часов работы или refurbished. который показывает по SMART пару часов работы но такой винт не протянет и месяц снова появятся лаги.
Реально их заставить поменять винт когда SMART начинает показывать критичные показатели как pre-fail или если появляются ошибки, что винт не отвечает.
Еще, если они все таки предложат вариант замены то лучше чуть-чуть доплатить (кажись 10 евро) и поставить гарантировано новый винт. по умолчанию они предлагают поставить бу винт с менне 700 часов работы или refurbished. который показывает по SMART пару часов работы но такой винт не протянет и месяц снова появятся лаги.
на первом переходе нагрузка сильно снижается, да.
На второй - удобство сильно ухудшается, а резульатат - или небольшой, или вообще нет. В своё время находил бенчмарки - там они идут практически вровень и производительность больше зависит от настроек. Единственное - апач немного больше жрёт памяти. Что-то вроде 15Мб больше на процесс. Но это копейки, по сравнению с остальными тратами.
На второй - удобство сильно ухудшается, а резульатат - или небольшой, или вообще нет. В своё время находил бенчмарки - там они идут практически вровень и производительность больше зависит от настроек. Единственное - апач немного больше жрёт памяти. Что-то вроде 15Мб больше на процесс. Но это копейки, по сравнению с остальными тратами.
сессии в мемкеш выкинул :) больше никаких существенных изменений не было.
в моем случае нагрузка реально упала, не знаю как у тебя обстоят дела. да и бенчмарки-бенчмарками, а я предпочитаю пробовать для каждого проекта что лучше.
попробуй взять в тест на том же хетзнере серв, настроить на нем nginx+fcgi, и на балансере закинуть какую-то большую подсеть пользователей на него как на постоянный бекэнд и посмотреть нагрузку. если нагрузка слабая а все работает так-же, то закинуть еще пользователей, и так до prefail. вот это и будет твой оптимальный конфиг и бенчмарк именно для твоего проекта.
хотя со своим в чужой монастырь :)
в моем случае нагрузка реально упала, не знаю как у тебя обстоят дела. да и бенчмарки-бенчмарками, а я предпочитаю пробовать для каждого проекта что лучше.
попробуй взять в тест на том же хетзнере серв, настроить на нем nginx+fcgi, и на балансере закинуть какую-то большую подсеть пользователей на него как на постоянный бекэнд и посмотреть нагрузку. если нагрузка слабая а все работает так-же, то закинуть еще пользователей, и так до prefail. вот это и будет твой оптимальный конфиг и бенчмарк именно для твоего проекта.
хотя со своим в чужой монастырь :)
Чтобы написать коммент, необходимо залогиниться
