Сегодня у нас произошел интересный сбой на одном из веб-сайтов наших клиентов. Из ниоткуда сайт был недоступен. Веб-сайт работает сам по себе на выделенном физическом сервере Windows 2003 R2 (я знаю, что это, наверное, излишнее, но это обсуждение на другой день). После перезапуска IIS и ColdFusion Application Service проблема повторялась несколько раз. Моя первоначальная мысль заключалась в том, что это проблема с DNS, которая случается иногда - последний раз это произошло после урагана «Сэнди», когда наш интернет-провайдер отключился, и нам пришлось внести некоторые изменения в конфигурацию сети. Но это не было проблемой DNS. Вторая мысль заключалась в том, что это была DDOS-атака, но очень мало причин, по которым кто-то захочет закрыть этот сайт. Когда мы позвонили нашему интернет-провайдеру, оператор на другом конце заметил, что трафик значительно вырос. Как оказалось, клиент непреднамеренно вызвал DDOS на веб-сайте после того, как он отправил по FTP очень большой видеофайл, а затем массово отправил ссылку на него по электронной почте. Сотни людей перешли по ссылке и поставили сайт на колени.
Я в первую очередь программист веб-сайтов, но иногда мне приходится вносить свой вклад в администрирование сервера. К сожалению, я являюсь постоянным экспертом по ColdFusion и IIS, но у меня нет большого опыта в решении этой проблемы. Какие основные шаги я могу предпринять, чтобы этого не произошло в будущем, поскольку мы не всегда можем контролировать, какие файлы клиент публикует на веб-сайте.
Вот несколько идей, которые у меня были, но я не уверен в их влиянии:
Maximum number of simultaneous Template requests
в настоящее время установлено значение 20. Я мог бы уменьшить это число примерно до 5, просто чтобы предотвратить подобные случаи, но это, вероятно, отрицательно повлияет на нормальное использование веб-сайта.Я открыт для любых предложений, поскольку я продолжаю свое исследование, чтобы сообщить техническому директору о лучших вариантах, чтобы мы могли реализовать решение.
Спасибо.
ОБНОВЛЕНИЕ: отчет об использовании с момента отключения:
Для больших статических элементов переместите их в CDN, например Amazon CloudFront.
Вот решение, с которым я работаю прямо сейчас:
Все эти ссылки для загрузки документов ведут на одну страницу с дополнительной информацией, прикрепленной в строке запроса:
/www.site.com/viewFile.cfm?fileId=1424545
Я обновил этот файл, чтобы он просто содержал iframe, указывающий на отдельный сайт, который обслуживает медиафайл:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title></title>
<style type="text/css">
html {
overflow: hidden;
}
iframe {
position: absolute;
left: 0px;
top: 0px;
width: 100%;
height: 100%;
border: none;
}
</style>
</head>
<body>
<cfoutput>
<iframe src="http://media.site.com/index.cfm#CGI.PATH_INFO#" frameborder="0"></iframe>
</cfoutput>
</body>
</html>
Этот отдельный сайт (media.site.com) находится на другом сервере (который обслуживается отдельной линией интернет-провайдера, которая на самом деле является линией 15 Мбит / с, но также обрабатывает другой трафик для компании) и index.cfm
на этом сайте содержит всю логику, которая ранее находилась на текущей целевой странице, и обслуживает файл из локального каталога, который синхронизирует файлы мультимедиа с тем местом, где они изначально находятся.
Немного хакерский, но он выполняет свою работу. Таким образом, если пользователи перегружают запросы на файлы мультимедиа, только этот сайт / сервер / IPS-линия выйдет из строя, но исходный веб-сайт все равно останется «работоспособным», так что пользователи могут выполнять обычные функции, даже если они могут не просматриваю медиафайлы.