Назад | Перейти на главную страницу

Конфигурация сервера memcached для масштабируемого nginx mongodb mongdb Ubuntu

В течение последних 2 месяцев я создавал веб-приложение PHP, используя следующие методы:

Я только что получил свой выделенный сервер под управлением Ubuntu 10.4 LTS x64 со следующим оборудованием:

Статический контент для веб-приложения (несжатый, неминифицированный) всего 200 КБ. Веб-приложение PHP требует масштабируемости, оно может получить большой трафик на старте.

Теперь у меня есть несколько вопросов:

Защита от DDOS может быть сложной, потому что большую часть времени у вашего интернет-провайдера не хватает ресурсов (брандмауэры с отслеживанием состояния или пропускная способность), и ваш IP-блок пропадает.

Если вы ожидаете DDOS, выберите провайдера, который может предложить защиту от DDOS и знает, как бороться с высокой нагрузкой трафика, попросите его привести примеры и систему, которая может помочь. Выключить вас - это не ответ.

Будьте готовы заблокировать сетевые блоки агрессивной машины ddos ​​или фактические сетевые блоки ddos ​​с помощью iptables или вашего собственного восходящего брандмауэра.

если только несколько IP-адресов используют более 90% ваших ресурсов, заблокируйте их.

Разработайте методы обнаружения недобросовестных клиентов (доступ к определенным сценариям или страницам, странные запросы, запросы страниц с нарушением порядка и т. Д. И блокирование их).

рассмотрите возможность использования входящего / исходящего качества обслуживания для справедливого управления исходящей полосой пропускания для клиентов.

рассмотрите возможность разделения базы данных, логики приложения и веб-обслуживания на различное оборудование.

подумайте о балансировщике нагрузки с некоторыми узлами кэширования говядины, чтобы задержать мелких злоумышленников. Но будьте осторожны, вступать в войну за ресурсы со своим нападающим - не лучшая идея, они победят! :-(

рассмотрите возможность добавления слоя кэширования между вашим приложением и базой данных, который должен уменьшать нагрузку на ваш сервер базы данных для повторных запросов.

Если ddos ​​нацелен на статический контент, а не на веб-скрипты, которым требуются ресурсы базы данных, рассмотрите возможность использования чего-то вроде CDN (облачная вспышка), которая скрывает ваш фактический IP-адрес от остальной части Интернета и помогает распределять нагрузку географически. вы получаете более быстрый контент, доставляемый вашим пользователям, и в качестве побочного эффекта вы получаете некоторую защиту от ddos.

Если вам не нужен UDP, попросите вашего интернет-провайдера заблокировать трафик на их границе. если вам нужны только порты 80 и 443, попросите вашего интернет-провайдера заблокировать их в своем сетевом разрешении. Если ваш провайдер не знает, что такое UDP или порты, получите новый ... :-).

разместите свои DNS в отдельной инфраструктуре, с кем-нибудь большим, кто может иметь дело с ddos. Если вам необходимо разместить DNS самостоятельно, разместите его в отдельной инфраструктуре и в другой сети.

если вы используете SSL, убедитесь, что вы можете справиться с попаданием в процессор при рукопожатиях SSL. Ускорители SSL дороги. Возможно, разработать систему, в которой только оплаченные клиенты или зарегистрированные аутентифицированные клиенты могут подключаться через SSL. То же самое касается подключения к порту 80, убедитесь, что ваши пользователи зарегистрированы, прежде чем они получат доступ к приложению. Может остановить глубокие ddos-атаки на ваше приложение.

во всяком случае, звучит весело. что ты задумал?

Комментарии и другой ответ полностью верны, но я бы также рекомендовал поставить Varnish впереди в качестве кеша для статического контента (и некоторого динамического), а также обратного прокси. NGINX также делает это, но Varnish лучше в этих двух областях.

Это в основном описывает инфраструктуру моей старой компании, где мы запускали эту настройку для приложений PHP и Rails.