GeoMapX

При тестировании сервисов за реверс-прокси HAProxy посредством утилиты openload обнаружилась занимательная вещь: любой запрос выполняется не быстрее, нежели за 40 мс! Даже с "monitor-uri /TESTME" (при наличии этой директивы во фронтэнде HAProxy сам обрабатывает запрос, сообщая о состоянии текущего фронтэнда). Запросы openload через HAProxy: $ openload http://127.0.0.1/TESTME 1 URL: http://127.0.0.1:80/TESTME Clients: 1 MaTps 25.00, Tps 25.00, Resp Time 0.040, Err 0%, Count 25 MaTps 25.00, Tps 25.00, Resp Time 0.040, Err 0%, Count 50 MaTps 25.00, Tps 25.00, Resp Time 0.040, Err 0%, Count 75 MaTps 25.00, Tps 25.00, Resp Time 0.040, Err 0%, Count 100 Прямое подключение openload к серверу: $ openload http://127.0.0.1/TESTME 1 URL: http://127.0.0.1:80/TESTME Clients: 1 MaTps 2590.64, Tps 2590.64, Resp Time 0.000, Err 0%, Count 2601 MaTps 2609.15, Tps 2775.79, Resp Time 0.000, Err 0%, Count 5399 MaTps 2644.94, Tps 2967.00, Resp T...

Вилли прикладывает к исходникам HAProxy полезную утилитку, но без документации. Вот краткое описание что это есть и зачем оно нам надо. haproxy + halog

Вот уже с неделю размышляю над дальнейшей стратегией построения веб-систем. А также, как водится, перелопачиваю документацию. Наконец-то нашлось время сформулировать многое из того, о чем раньше некогда было всерьез подумать. В том числе, нашел проект и одноименный деб-пакет keepalived . Почему именно этот проект, хотя есть намного более известные аналоги ( heartbeat )? Все просто - именно keepalived рекомендует автор HAProxy , предлагая в документации варианты совместного использования и примеры конфигурации. Сам я давно и успешно использую HAProxy и с его автором общался, неизменно получая точные и ясные ответы на вопросы продакшен конфигурации и защиты от сбоев и атак различных видов. Это была первая причина. А вторая - на мой взгляд, конфигурационные параметры heartbeat придуманы точно не гуманоидами, вот пусть эти головоногие (в лучшем случае) ими и пользуются. Третья причина - костыли в heartbeat для предотвращения одновременного использования разделяемых дисков несколькими у...

При построении кластера с единой точкой входа возникает необходимость определенной настройки узлов кластера. Например, редирект должен отправлять пользователя не на хост, заданный в конфиг-файле AOL Server, а на тот хост, который указан в хидерах клиента. Имя точки входа и соответствующие веб-сервера определяются на уровне балансировщика, например, в HAProxy, таким образом, в конфиге AOL Server вовсе не должно быть имени точки входа; кроме того, точек входа может быть более одной. Задача решается с помощью приведенных ниже врапперов для встроенных функций. # Copyright 2009, Mobile Business Group # This program is free software: you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation, either version 3 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warrant...

Некоторое время назад столкнулся с неприятным "притормаживанием" при выполнении запросов. Как выяснилось, проблема в реверс-прокси Pound - в режиме HTTPS его эффективность оказалась не слишком высокой. Трафик проекта, на котором это произошло, составляет около 200 Gb в месяц, или миллион "с гаком" запросов в сутки (весь трафик по протоколу HTTPS). Притом в режиме HTTP (по отзывам разработчиков в рассылке AOLServer) Pound выдерживает до 800 запросов в секунду (ну, правда, неизвестно, на каком железе), после чего приходится ставить другой прокси. В качестве альтернативы выбрал HAProxy - и код понравился, и автор помог перенести конфиг Pound. Также оказалось очень полезным, что автор HAProxy написал патч к Stunnel4 для поддержки хидера X-forwarded-For (этот патч понадобилось немного адаптировать к версии stunnel4 в debian lenny, результат можно взять на сайте HAProxy или уже собранный пакет Stunnel4 в моем репозитории). Что приятно, после замены реверс-прокси в top-е е...