Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 36
ServerLimit и MaxClients ставим равными 100. Это позволит нашим серверам одновременно обрабатывать по 100 соединений в секунду.
Не по 100 в секунду.
При использовании haproxy для https — теряется ip клиента и сопоставить это по логам потом не возможно. В beta версии уже сделали поддержку ssl
А что вы будете делать, если умрет DB-сервер, или балансировщик нагрузки?
Плакать, ибо это не отказоустойчивость, а масштабирование с разнесением логики по нескольким железкам.
Но, возможно, автор умолчал о slave базах данных (mysql? Тогда волшебная master-master репликация), о нескольких нодах балансера, при выведении из строя одной из которых её IP автоматически анонсируется на живой балансер и других забавных прихотях интернета.
Вы абсолютно правы. Умолчал. Репликация и failover — дело рук каждого отдельно. Для отказоустойчивости понадобится еще по одному серверу каждого типа. Дальше чем хотите — drbd, mysql replication, rsync, etc. Ну и heartbeat конечно. Или какой-то самописный велосипед.
Я не хотел делать сильно большую статью, поэтому не вдавался в подробности failovera.
Я не хотел делать сильно большую статью, поэтому не вдавался в подробности failovera.
Также в место drbd можно использовать csync, хорошо работает при хайлоаде. При большом кол-ве файлов, немного по тюнинговать придется, но в остальном справляется не плохо и нагрузку на cpu дает не большую.
ну если у нас есть три сервера, можно поступить по разному.
Можно организовать систему виртуализации и на них уже запускать нужные сервесы, увеличивая мощность по мере нагрузки.
Можно сразу поднять связку keepelived (vrrp) с 6 ip на них поднять HAProxy, nginx с php-fpm + percona cluster server.
Вход на HAproxy уже через RR DNS.
Обновлять nginx папку через git с определенными костылями.
+ просто делать backup mysql базы.
Можно организовать систему виртуализации и на них уже запускать нужные сервесы, увеличивая мощность по мере нагрузки.
Можно сразу поднять связку keepelived (vrrp) с 6 ip на них поднять HAProxy, nginx с php-fpm + percona cluster server.
Вход на HAproxy уже через RR DNS.
Обновлять nginx папку через git с определенными костылями.
+ просто делать backup mysql базы.
И все-таки не понимаю почему бы не использовать nginx + php-fpm, вместо каскада nginx -> apache -> php_prefork?
И зачем жестко зарезать количество коннектов через haproxy, чего у вас там такого специфического что не может прожевать nginx? Если количество коннектов зашкаливает и все воркеры php-fpm забиты (настроить их столько, чтобы максимальная нагрузка на сервер не превышала допустимые пределы), nginx будет получать отлуп в upstream и сваливаться на какой-нибудь именованый location c заглушкой «Извините, сильно большой наплыв покупателей, мы не справляемся =)»
И зачем жестко зарезать количество коннектов через haproxy, чего у вас там такого специфического что не может прожевать nginx? Если количество коннектов зашкаливает и все воркеры php-fpm забиты (настроить их столько, чтобы максимальная нагрузка на сервер не превышала допустимые пределы), nginx будет получать отлуп в upstream и сваливаться на какой-нибудь именованый location c заглушкой «Извините, сильно большой наплыв покупателей, мы не справляемся =)»
Не пойму зачем использовать haproxy и varhish когда все можно завязать на nginx.
varnish статику быстро отдает например
nginx тоже.
А вообще в highload лучше использовать CDN
А вообще в highload лучше использовать CDN
эм… ну CDN он не заменит в данном случае nginx, но вот скорость загрузки сайта увеличит.
Я и не говорил, что он что-то заменит. Я просто констатировал факт, что на highload статику необходимо выносить с основного сервера. Это полезно не только для сервера, но и для клиента, так как можно установить одновременно большее количество соединений. Ну, и не стоит забывать про географическое распределение ресурсов, что невозможно при использовании основного web-сервера для раздачи статики.
Не пойму зачем использовать haproxy и varhish когда все можно завязать на nginx.
Вот вы бы взяли, и так-же подробно описали процесс настройки и получаемые «плюшки». Мне, лично, всё это страсть как интересно, внятных текстов очень мало.
Я написал комментарий не к тому что, автор статью, а к тому что бы немного внесли ясности, чем конфигурация с haproxy и varhish лучше чем конфигурация без них.
>Вот вы бы взяли, и так-же подробно описали процесс настройки и получаемые «плюшки».
Знаете как не хватает время, на все это | Взять — Сесть и написать.
Знаете как не хватает время, на все это | Взять — Сесть и написать.
ТС, итоговая система черезчур сложна. Может все-таки почитать доки nginx`а? У него ещё модули есть.
А вот если чего-то у него нет, что есть у апача — только в этом случае наверное стоит добавлять апач, как один бэкэндов. Но точно не для того, на что уже есть прекрасный вариант а-ля php-fpm.
ps: А м.б. это ещё за ISA server спрятать? У него вообще по-мойму всё можно сделать :)
А вот если чего-то у него нет, что есть у апача — только в этом случае наверное стоит добавлять апач, как один бэкэндов. Но точно не для того, на что уже есть прекрасный вариант а-ля php-fpm.
ps: А м.б. это ещё за ISA server спрятать? У него вообще по-мойму всё можно сделать :)
Доки nginxa я читал и довольно много. Использую его повсеместно, в виду архитектуры проектов не удается полностью отказаться от апача. Но это лирика.
На счет haproxy — специально его сюда втулил для полноты схемы. Согласен достаточно nginx+varnish+php-fpm. При этом логировать ip клиентов будет легче — он не будет теряться в хэдэрах x-forvarded-for при прохождении всего пути пакета.
Можно и от nginxa отказаться в пользу haproxy, поскольку последнее показывает выше производительность по сравнению с nginxoм при высоких нагрузках (на просторах интернета есть достаточно сравнительных статей).
Можно и от варниша отказаться. И кэшировать все nginxom, убирая неугодные Cookie и хэдэры с помощью дополнительного модуля сторонних разработчиков.
Можно что угодно сделать. Сложите мысли воедино и изложите :-)
Я не занимаюсь пропагандой какой-либо схемы. Просто описал, максимально полно, что так тоже можно сделать. И оно даже должно работать. При чем каждое звено в цепи взвешено. Их можно комбинировать, удалять те, которые не нравятся, заменять более удобными.
На счет haproxy — специально его сюда втулил для полноты схемы. Согласен достаточно nginx+varnish+php-fpm. При этом логировать ip клиентов будет легче — он не будет теряться в хэдэрах x-forvarded-for при прохождении всего пути пакета.
Можно и от nginxa отказаться в пользу haproxy, поскольку последнее показывает выше производительность по сравнению с nginxoм при высоких нагрузках (на просторах интернета есть достаточно сравнительных статей).
Можно и от варниша отказаться. И кэшировать все nginxom, убирая неугодные Cookie и хэдэры с помощью дополнительного модуля сторонних разработчиков.
Можно что угодно сделать. Сложите мысли воедино и изложите :-)
Я не занимаюсь пропагандой какой-либо схемы. Просто описал, максимально полно, что так тоже можно сделать. И оно даже должно работать. При чем каждое звено в цепи взвешено. Их можно комбинировать, удалять те, которые не нравятся, заменять более удобными.
А как же настройка сервера БД? Там тоже есть очень много возможностей повысить быстрдействие вашей системы. Тем более для этого у вас есть отдельный сервер, на котором, думаю, у вас есть много памяти.
Используете какие-то кешилки для PHP? Имею в виду eAccelerator или подобные. Не помню, правда, можно ли их использовать с mod_prefork.
Используете какие-то кешилки для PHP? Имею в виду eAccelerator или подобные. Не помню, правда, можно ли их использовать с mod_prefork.
можно использовать и eAccelerator и APC.
Еще раз напоминаю: я не писал статью по оптимизации сервера!!!
То же самое касается настроек БД. Каждый разработчик в праве сам решать какую БД ему использовать. И это уже дело хостера как оптимизировать движок БД.
Еще раз напоминаю: я не писал статью по оптимизации сервера!!!
То же самое касается настроек БД. Каждый разработчик в праве сам решать какую БД ему использовать. И это уже дело хостера как оптимизировать движок БД.
Если делать отказоустойчивый кластер. то надо делать сразу правильно:
1. минимум 2 канала в интернет.
2. дублировать железки, дающие интернеты на балансировщики — маршрутизаторы, каналы, сетевые адаптеры, линки между оборудованием.
3. делать пуллы из балансировщиков, проксей, фронтендов, бекендов, дб, частично можно совмещать, допустим, nginx, squid или еще какой прокси ложить на сервера с фронтендами.
4. дублировать NAS/SAN'ы, где живет всякое файло, бд, ос, виртуалки.
5. дублировать инфрастуктуру в другом, желательно географически отдалённом ЦОДе, куда иметь отдельные каналы для репликации данных.
6. сбор логов и параметров нагрузки, аналитика мониторинга и логов.
7. Никто при этом не мешает частично или полностью использовать Amazon, Azure или других поставщиков облаков.
8. Тонкий тюнинг каждого элемента инфраструктуры — маршрутизатора, коммутатора, операционных систем, конкретных сервисов — веб сервера, сервера БД, прокси, балансировщиков, фронтенда, бекенда, кешей — очень и очень трудоёмкое занятие, не считая подбора оборудования под задачи — стоит не одного поста, а занимает много книг и много личного опыта.
1. минимум 2 канала в интернет.
2. дублировать железки, дающие интернеты на балансировщики — маршрутизаторы, каналы, сетевые адаптеры, линки между оборудованием.
3. делать пуллы из балансировщиков, проксей, фронтендов, бекендов, дб, частично можно совмещать, допустим, nginx, squid или еще какой прокси ложить на сервера с фронтендами.
4. дублировать NAS/SAN'ы, где живет всякое файло, бд, ос, виртуалки.
5. дублировать инфрастуктуру в другом, желательно географически отдалённом ЦОДе, куда иметь отдельные каналы для репликации данных.
6. сбор логов и параметров нагрузки, аналитика мониторинга и логов.
7. Никто при этом не мешает частично или полностью использовать Amazon, Azure или других поставщиков облаков.
8. Тонкий тюнинг каждого элемента инфраструктуры — маршрутизатора, коммутатора, операционных систем, конкретных сервисов — веб сервера, сервера БД, прокси, балансировщиков, фронтенда, бекенда, кешей — очень и очень трудоёмкое занятие, не считая подбора оборудования под задачи — стоит не одного поста, а занимает много книг и много личного опыта.
Кстати, Haproxy еще имеет смысл использовать, когда один и тот же веб-сервер (пусть даже апач) обслуживает несколько независимых виртуальных хостов, и чтобы при перегрузе какого-то определенного http_host-а входящие запросы не отваливались, а вставали в очередь и ждали. Т.е. чтобы исключить влияние одного виртуального хоста на другой при шаред-хостинге.
Думаю, в Вашем случае лучше использовать стратегию балансировки в haproxy leastconn заместо roundrobin.
Не хочу обидеть, но статья явно не служит и не должна использоваться кем либо как пособие. Скорее как не стОит делать.
High-Load… MaxClients 100… да вся статья. Вам стоит почитать документацию, выкинуть ненужные связки и перестать называть хайлоадом то, что даже близко не хайлоад.
High-Load… MaxClients 100… да вся статья. Вам стоит почитать документацию, выкинуть ненужные связки и перестать называть хайлоадом то, что даже близко не хайлоад.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Организация High-Load cluster с несколькими нодами