Недоступные Услуги AWS ELB Apache2 503: сервер бэкэнда на полной мощности
По совпадению я решил проблему несколько минут прежде, чем видеть Ваш ответ, но это не конец истории. Это происходит, о котором на создании новых проектов (и вероятно в других местах также) Gitlab все еще сообщает http вместо https протокол на сгенерированных URL. И, например, можно было бы хотеть получить доступ к gitlab nginx сервер (при использовании Всеобъемлющей установки, поскольку кажется, что это имеет место здесь), только как localhost в обратной передаче прокси. Для достижения этого, Вам нужна следующая конфигурация Apache:
ProxyPreserveHost On
<Location /gitlab>
ProxyPass http://localhost:8929/gitlab
ProxyPassReverse http://localhost:8929/gitlab
# Necessary so Gitlab can return https addresses on some generated URLs
RequestHeader set X-FORWARDED-PROTOCOL https
RequestHeader set X-Forwarded-Ssl on
</Location>
После переменных должен затем быть введен в среде Gitlab или записан в gitlab.rb, таким образом, к сервису можно получить доступ только как localhost:
external_url 'http://localhost:8929/gitlab'
# nginx['listen_port'] = 80 # I use this when mapping host 8929 to 80 in docker container
nginx['listen_https'] = false
gitlab_rails['gitlab_shell_ssh_port'] = 2222
# Following is necessary otherwise Gitlab will generate git URLs pointing to localhost
gitlab_rails['gitlab_ssh_host'] = 'git.myexeternaldomain.com'
Вы получите сообщение «Внутренний сервер загружен», когда балансировщик нагрузки ELB выполнит свои проверки работоспособности и получит сообщение «Страница не найдена» (или другая простая ошибка) из-за ошибки -конфигурация (обычно с хостом NameVirtual).
Попробуйте выполнить поиск папки с файлами журнала с помощью пользовательского агента "ELB-HealthChecker". например,
grep ELB-HealthChecker /var/log/httpd/*
Это обычно дает ошибку в 4 или 5 раз, которую легко исправить. например, Flooding, MaxClients и т. д. придают слишком большое значение проблеме.
FYI Amazon: Почему бы не показать возвращенный ответ на запрос? Даже код статуса поможет.
вы можете увеличить значения средства проверки работоспособности elb, чтобы один медленный ответ не отвлекал сервер от elb. Лучше, если несколько пользователей будут недоступны для обслуживания, чем сайт будет недоступен для всех.
РЕДАКТИРОВАТЬ: Мы можем обойтись без предварительного нагрева кеша, увеличив тайм-аут проверки работоспособности до 25 секунд ... после 1 -2 минуты ... сайт чертовски отзывчивый
РЕДАКТИРОВАТЬ :: просто запустите кучу запросов по запросу, и когда ваши инструменты мониторинга покажут руководству, насколько вы быстры, тогда просто внесите предоплату RI amazon: P
EDIT: возможно, одного зарегистрированного экземпляра backend elb недостаточно. просто запустите еще несколько и зарегистрируйте их в elb, и это поможет вам сузить круг проблем
[ИЗМЕНИТЬ, лучше разобравшись в вопросе] Не имея никакого опыта работы с ELB, я все еще думаю, что это подозрительно похоже на ошибку 503, которая может быть выдана, когда Apache выходит на Tomcat и заполняет соединение.
Эффект заключается в том, что если Apache доставит больше запросов на подключение, чем может быть обработано с помощью бэкэнд, очереди ввода бэкэнда заполняются до тех пор, пока больше не будут приниматься соединения. Когда это происходит, соответствующие очереди вывода Apache начинают заполняться. Когда очереди заполнены, Apache выдает ошибку 503. Из этого следует, что то же самое может произойти, когда Apache является серверной частью, а интерфейс выполняет доставку с такой скоростью, чтобы очереди заполнялись.
(Гипотетическое) решение состоит в том, чтобы размер входных разъемов бэкэнда и выходных разъемов внешнего интерфейса. Это превращается в баланс между ожидаемым уровнем переполнения и доступной оперативной памятью задействованных компьютеров.
Когда это происходит, проверьте настройки maxclients и отслеживайте занятых рабочих в Apache (mod_status.). Сделайте то же самое, если возможно, с любым ELB, который соответствует невыполнению работы коннектора Tomcats, maxthreads и т. Д. Короче говоря, посмотрите на все, что касается входных очередей Apache и выходных очередей ELB.
Хотя я полностью понимаю, что это не применимо напрямую , эта ссылка содержит руководство по размеру коннектора Apache. Вам нужно будет изучить соответствующие технические детали очереди ELB, а затем выполнить математические вычисления:
Хотя я полностью понимаю, что это не имеет прямого отношения, эта ссылка содержит руководство по определению размеров коннектора Apache. Вам нужно будет изучить соответствующие технические детали очереди ELB, а затем выполнить математические вычисления:
Хотя я полностью понимаю, что это не имеет прямого отношения, эта ссылка содержит руководство по определению размеров коннектора Apache. Вам нужно будет изучить соответствующие технические детали очереди ELB, а затем выполнить математические вычисления: http://www.cubrid.org/blog/dev-platform/maxclients-in-apache-and-its-effect-on-tomcat-during-full-gc/
Как указано в комментарии ниже , перегрузка коннектора Apache - не единственная возможность всплеска трафика. Если одни запросы обслуживаются медленнее, чем другие, большее их количество также может привести к переполнению очередей соединителей. Это было правдой в моем случае.
Кроме того, когда это случилось со мной, я был сбит с толку тем, что мне пришлось перезапустить службу Apache, чтобы снова не получить 503: s. Просто переждать флуд коннектора было недостаточно. Я так и не понял этого, но можно ли предположить, что Apache обслуживает из своего кеша?
После увеличения количества рабочих и соответствующих настроек maxclients перед форком (это был многопоточный Apache в Windows, у которого есть пара других директив для очередей, если я правильно помню ) проблема 503 исчезла. На самом деле я не занимался математикой, а просто настраивал значения до тех пор, пока не смог наблюдать большой запас по пиковому потреблению ресурсов очереди. Я отпустил это.
Надеюсь, это помогло.
Я сам столкнулся с этой проблемой. Amazon ELB вернет эту ошибку, если нет исправных экземпляров. Наши сайты были неправильно настроены, поэтому проверка работоспособности ELB завершилась ошибкой, из-за чего ELB отключил два сервера от ротации. При отсутствии работоспособных сайтов ELB вернул 503 Service Unavailable: Back-end server is made.
Опоздал на несколько лет, но надеюсь, это кому-нибудь поможет.
Я видел эту ошибку, когда экземпляр, стоящий за ELB, не имел правильного публичного IP-адреса. Мне нужно было вручную создать Elastic IP и связать его с экземпляром, после чего ELB поднял его почти мгновенно.