Вход | Регистрация

Информационные технологии ::

Метки:

Особенности одного сайта с большой посещаемостью

Я
   Волшебник
 
16.05.04 - 11:44
Есть такой сайт http://www.opennet.ru, на который заходит около 10000 человек в день. Интересно привести проблемы, с которыми сталкиваются подобные сайты, и решения этих проблем.

Источник: http://www.opennet.ru/guide.shtml

============================================
Используемое ПО на сайте http://www.opennet.ru
•    ОС: FreeBSD 4.8
•    Язык программирования: Perl
o    Модули: Темплейты - MCTemplate, Кэш - MCCache, Локи - MCLock, CGI - MCCGI;
•    Web-сервер: Apache 1.3 + FastCGI + mod_deflate
•    SQL-сервер: PostgreSQL
•    FTP-сервер: vsftpd
•    MTA: Postfix
•    Поиск на сайте
o    используется htdig - для объема индексируемого материала примерно 1.5 Гб htdig пока остается оптимальной системой (с хранением индексов в btree Berkeley DB файлах), главные минусы - нет предкеширования типовых запросов (можно реализовать внешним wrapper'ом или через mod_accel), не оптимальная работа при выводе результата поиска по часто встречающемуся в индексируемых документах словам (например, если ищем по слову которое встречается десятки тыс. раз - поиск будет занимать несколько минут).
o    OpenFTS - слишком медленный и ресурсоемкий конечный поиск для клиента, не хочется создавать лишнюю нагрузку на PostgreSQL сервер, который обслуживает первичные БД сайта.
o    Aspseek и mnogosearch - требуют слишком много памяти для расчета коэффициентов релевантности (не меньше 1 Гб ОЗУ), требуют MySQL для обеспечения более или менее высокой скорости операций поиска (не хочется поднимать MySQL на сервере).
•    Бэкап: fsbackup
•    Мониторинг: alertmon3
Заметки по технологии и оптимизации
•    Все что можно - преобразовывать в статику. Предгенерация контента.
•    Со временем убедился, что персональные настройки на сайте - лишнее усложнение, почти всегда достаточно разумного дефолта. Стремлюсь к простоте в оформлении и лаконизму в изложении.
•    В динамике - поиск, динамическая часть форума, контент который не выгодно хранить или отдавать в статике:
o    когда контент слишком часто изменяется;
o    когда необходимо обеспечить большую гибкость запроса;
o    когда объем контента в статике слишком велик;
o    когда запрашивается только "верхушка айсберга" (например - вывод текста новостей, интенсивно запрашиваются только последние новости, которые и можно предкэшировать "на лету", но не предгенерировать);
o    когда предгенерация требует значительных ресурсов, несопоставимых с ресурсами затрачиваемыми при отдаче того-же динамикой (например, когда много вариантов представления - выгоднее предкэшировать отдельные блоки, а не всю страницу сразу).
•    Все что нельзя превратить в статику (предгенерировать) - кэшировать через статику. Предкэширование типовых запросов и промежуточное сохранение часто используемых выборок в кэше. Например, можно прокэшировать только наиболее часто встречающиеся запросы.
•    Ту динамику, что невозможно прокэшировать - снабжать средствами защиты от перегрузок.
o    защитой от DoS/flood потоков запросов;
o    ограничить число одновременных потоков на клиента;
o    ограничить число запросов на клиента в ед. времени (средства ipfw, mod_limitconn или mod_throttle);
o    квоты на дисковое пространство (не переусердствовать, отделить первичные области диска (например, хранилище БД, данные форума - не восстановимы), от вторичных (например, предгенирированный контент, кэши - влияют на отображение, но восстановимы из первичных областей) и третичных (например, логи - потеря не так страшна));
o    квоты на процессорное время
o    квоты на размер процесса;
o    квоты на число процессов;

Практические рекомендации по тюнингу Apache:

o    FreeBSD ядро собираем с "options ACCEPT_FILTER_HTTP" (или "kldload accf_http"), в конфигурацию Apache добавляем "AcceptFilter on", перезапускаем Apache;
o    Убираем лишние модули;
o    "KeepAlive Off", а картинки отдаем через отдельный мини-http сервер для отдачи статики (mathopd, thttpd);
o    В "Options" должно быть "FollowSymLinks", но не нужно "SymLinksIfOwnerMatch" (приводит к лишней lstat() проверке при каждой отдаче файла).
o    Не используем .htaccess (AllowOverride None), все настройки, включая авторизацию, в httpd.conf (apache тратит ресурсы на попытки открыть .htaccess в каждой родительской директории);
o    Ограничиваем число одновременных запросов с одного IP через "ipfw add allow tcp from any to $IP 80 via fxp0 setup limit src-addr 15" или "iptables -A INPUT-p tcp --dport 80 -m iplimit --iplimit-above 10 -j REJECT", но не через модули apache (mod_throttle, mod_bandwidth, mod_limitconn);
•    Использовать FastCGI/mod_perl для динамики (устраивает использование FastCGI). Наиболее выгодно использовать для небольших скриптов, время загрузки и парсинга которых сравнимо с временем выполнения скрипта, либо если промежуточные данные можно держать в памяти (пример, скрипт "хинтов" в opennet). Выгода почти не ощутима для тяжелых скриптов, требующих значительного времени для выполнения и не использующих одни и те же области данных (например - скрипты поиска).
•    Использовать mod_accel - для буферизации клиентских запросов и создания внешнего кэша запросов к динамике. Увеличение sendbuffer в apache и send/recv буферов на уровне ОС. Написание скриптов с учетов кэширования. (в opennet mod_accel не используется)
•    Использовать mod_deflate для сжатия отдаваемого пользователям контента (трафика меньше и клиенту быстрее информация отдается, нагрузка на CPU от сжатия - почти незаметна);
•    Если статики очень много (например отдаются картинки) - не тратим на нее силы apache, а отдаем через спец. средства - mathopd (мой выбор) или thttpd. Можно использовать squid в режиме акселератора. Окажет помощь балансировка данных на несколько дисков, особенно если на сервере используются SCSI накопители. Или выдача статики прямо из ram-диска.


Надежность

•    Для обеспечения надежности системы важными составляющими являются системы мониторинга и резервного копирования.
o    Мониторинг.
    Слежение за возникновением проблем
    Попытки автономно решить проблему
    Оперативное сообщение о возникновении проблемы.
    Сохранение информации о факте проблемы и дампа состояния системы в момент проблемы.
    Визуализация текущего состояния.
    Визуализация динамики изменения состояния (наглядное представление на графиках):
    Мониторинг инфраструктуры (группы серверов и оборудования)
    Карта сети, в которой отображено состояние точек и связей
    Удаленный мониторинг
    Достижимость ресурса
    Работоспособность сервисов ресурса
    Локальный мониторинг
    Контроль наличия запущенных процессов
    Контроль за состоянием процессов (число процессов, расход ресурсов CPU, ОЗУ)
    Контроль за состоянием сетевых соединений (определение флуда)
    Контроль расхода дискового пространства.
    Периодическая оценка логов на предмет наличия фатальных или предупреждающих сообщений.
    Контроль общего состояния системы, нагрузки, расхода памяти, сетевого трафика и т.д.
o    Резервное копирование.
    Территориальный вынос бэкапа (пожар, форс-мажор)
    Инкрементальное накопление изменений
    Несколько уровней отката.
    Несколько уровней детализации и полноты бэкапа.
    Безопасность и конфиденциальность бэкапа (бэкап с важными данными должен быть зашифрован)
    Экономия дискового пространства за счет сжатия бэкапа.
    Легкость восстановления без необходимости доп. ПО, кроме архива бэкапа (открытый формат архива)
    Автономность, автоматическая работа без участия оператора
    Гибкость формирования бэкапа (маски файлов/директорий для помещения в бэкап и исключения из него)
o    Дополнительные системы отказоустойчивости: разбалансировка на несколько серверов (самое простое - балансировка по DNS) или БД, использование RAID, системы бесперебойного питания, резервные сетевые линки, промежуточное оборудование повышенной надежности (маршрутизаторы, коммутаторы), размещение в спец. помещении (неприкосновенность оборудование, вентиляция, фильтрование пыли, температурный режим, защита от пожара и протечки систем водоснабжения).

Дополнительные системы увеличения производительности

    Кэширование контента.
    Кэширование SQL запросов.
    Кэширование промежуточных данных
    Кэширование результата.
    Предкешированные объекты.
    Использование оптимальных алгоритмов.
    Оборудование - SCSI диски, машины с SMP.
    Тюнинг ОС.
    Разделение нагрузки на несколько серверов, вынос сервисов на отдельные машины.
    Функциональное разделение (по IP) и равномерное разделение (SQL)
    Субъективное разделение (разделение функций и операций, DNS-балансирование, IP-балансирование и т.д.)
    Разделение процессов (кластер, 2 SQL сервера для балансировки SELECT запросов.)


Безопасность

o    Ежедневное слежение за отчетами с описанием новых проблем с безопасностью в рассылках и на специализированных сайтах.
o    Не дожидаться обнаружения ошибок, попытаться предотвратить их проявление. Всегда считать, что в программе есть ошибки, обдумать что можно сделать чтобы система не пострадала от их проявления. Система должна быть неприступна, невзирая на вероятные проблемы с безопасностью в программах.
    Избыточные, параноидальные проверки в своем коде. Проверки на каждом этапе использования полученных от пользователя или иного внешнего источника данных.
    Понижение привилегий и запуск в chroot.
    Использование библиотек-врапперов подменяющих потенциально опасные библиотечные вызовы или сборка спец компиляторами с средствами защиты от переполнения буфера.
o    Сниффинг. Особое внимание следует уделить внутренней безопасности, для предотвращения появления злоумышленника в доверительной сети. Сниффер в доверительной сети, не меньшая угроза, чем открытая брешь в ПО. Средства защиты от злоумышленника в локальной сети:
    Шифрование трафика, особенно актуально для сервисов в которых присутствует передача паролей в открытом виде. Но, на одно шифрование тоже нельзя полагаться, об этом ярко говорят ошибки в реализации ssh1, openssl, mod_ssl приводящие к возможности анализа перехваченного шифрованного трафика.
(Примеры, замены: http => SSL+http, ftp => sftp, telnet, ssh1 => ssh2, pop3 => apop или pop over TLS/SSL).
    Жесткая политика доступа к ресурсам управления (ssh, snmp).
    Разграничение доступа внутренними средствами: ACL программы или tcp wrapper (/etc/hosts.allow). Желательно, чтобы доступ разграничивался как по имени пользователя совместно с ограничением по IP (каким пользователям какие действия можно производить с каких IP).
    Дублирующее ограничение средствами фаервола, можно как на локальном сервере, так и на пограничном маршрутизаторе.
    Мониторинг переполнения ARP таблиц. Использование коммутаторов (свичей), не избавляет от возможности сниффинга. Проброс каждого клиента используя VLAN через маршрутизатор или привязка MAC адреса к порту коммутатора - дорогое удовольствие, особенно в больших сетях. Частично проблему помогают решить программные средства слежения за изменением MAC адресов (чтобы пользователи самовольно не меняли IP адреса и не выставляли IP соседа) и мониторинга за переполнением ARP таблиц. Другой способ борьбы с arp-спуффингом - использование специальных патчей на шлюзовой машине или жесткая привязка MAC адресов к IP.
    Использование временных паролей (One-Time Passwords - OTP, opie, s/key). Например, генерируется список паролей и при каждом входе используется следующий пароль из списка, использованные пароли блокируются.
    Применение средств автоматического обнаружения вторжения (IDS) под вопросом, так как в таких средствах часто находят критичные ошибки способствующие взлому (пример: snort, tcpdump).
o    Закрытая система для решения спец. задач, без публичных сервисов (например, рутер, фаервол)
    Полное отсутствие сетевых сервисов.
    SSH доступ только с IP администратора и резервного trusted сервера.
    Закрытые сервисы доступны только непосредственным потребителям.
    Двойное или тройное блокирование, пакетный фильтр, libwrap/tcpwrapper и настройки самой программы.
    Если система не в trusted сети - шифрование всех потоков данных.
o    Закрытая система с сетевыми сервисами.
    SSH доступ только с IP администратора и резервного trusted сервера.
    Открыты только реально необходимые сервисы.
    Для открытых сервисов используется только доверительное ПО, в котором ранее не замечали проблем безопасности и прошедшее беглый аудит.
    Все остальное, если невозможно обойтись без него или заменить в CHROOT.
    Доверяю ПО: postfix, qmail, popa3d, vsftpd (практика прецедента - не доверять ПО в котором хоть раз найдена критическая ошибка безопасности или программа разработана без использования жесткой политики безопасности (в документации и коде это сразу заметно)).
    Запускаю в CHROOT: bind/named, apache, ftpd (BSD), inn. Доступ к OpenSSH только с доверительных хостов.
    Не запускаю в public никогда: все реализации IMAP, samba, sendmail, proftpd, wuftpd, mysql, postgresql, dhcpd, ntpd. Пример особенно безграмотных с точки зрения безопасности систем - proftpd, qpop.
    Не использовать антивирусы для проверки почты, как правило это закрытые проекты в которых не проводится аудит исходного кода. Вместо антивирусов, можно практиковать полную блокировку пересылки выполняемых файлов, или отключить проверку в архивах и запускать в chroot. Подобному решению способствуют прецеденты DoS атак (переполнение диска) через вложенные, специально скомпонованные, сжатые файлы или возможность выполнения кода на сервере через специальным образом скомпонованные заголовки письма.
o    Открытая система с локальными пользователями (например пользователи могут запускать CGI-скрипты)
    Разделение привилегий, запретить доступ к другим пользователям и системным файлам по возможности
    Желательно noexec /tmp и патч для noexec stack.
    Если можно то в chroot jail.
    Не давать исходящих коннектов, если не требуют условия.
    Убрать все suid программы которые можно убрать, использовать TCB для хранения паролей, вместо /etc/shadow
    Не оставлять бэкапы в открытом месте, иногда злоумышленник может взломать систему используя старую suid программу из бэкапа или обнаружив общедоступный файл с паролями.
    Вести подробные логи, включая аккаунтинг выполняемых процессов. syslog логи дублировать по сети на соседнюю машину.
    Применять программное обеспечения для слежения за целостностью участков файловой системы и поиска root-китов.
    Дополнительные ограничения для скриптов пользователей системы хостинга (apache в chroot):
    Запрещение connect(2), невозможность установки исходящих соединений пользовательскими скриптами (используя библиотеку враппер, подгружаемую через LD_PRELOAD в suexec, принудительно меняем для listen и connect IP на 127.0.0.1).
    Запрещение listen(2), предовращение приема соединений на сетевой порт. Борьба с процессами демонами, через мониторинг.
    Ограничение возможности использования группы exec вызовов, предусмотреть использование относительных путей и список исключений (текущая cgi-bin, /bin и т.д.);
    Запретить для cgi-скриптов возможность создания и перезаписи файлов в директориях с исполняемыми скриптами (cgi-bin).
    Квоты на дисковое пространство, время выполнения скрипта и объем используемой одним скрптом памяти.
    Права доступа к диреткории пользователя "drwx--x--- user hosting", где user - id пользователя, hosting - группа из под которой запущен apache (для раздачи статики). Таким образом скрипт пользователя не имеет доступа к диреториям других пользователей.
    Использование mod_php в режиме safe_mode (php_admin_flag safe_mode on), запретить использование URL в open (php_admin_flag allow_url_fopen off), ограничить обем ОЗУ (php_admin_value memory_limit 2M), ограничить время выполнения (php_admin_value max_execution_time 10).
    Мониторинг in/out трафика через mod_watch. Раньше получал полные данные о трафике используя "per user ip accounting", но он учитывал также mysql и прочий локальный трафик, после введения блокировки на listen() и connect(), использование mod_watch вполне оправдано. Предотвращение использование ftp аккаунта для файлового обмена, через дополнительный мониторинг.

Аспекты безопасности при написании CGI-скриптов

    Применение suexec и жесткое разграничение прав доступа (пользователь не должен видеть системных файлов и логов, не должен иметь возможность получить доступ к данным другого пользователя)
    Полностью исключить использование типовых бесплатных скриптов. Лучше все писать самостоятельно, если написание затруднено - обязателен полный аудит кода чужих скриптов.
    Паранойя при написании кода - дублирующие проверки всех параметров получаемых в диалоге скрипта с пользователем (как минимум проверка валидности с выводом сообщения об ошибке на этапе инициализации переменных с данными пользователя и жесткое вырезание недопустимых символов (s/[^\w\d_\-.]//g) перед опасными функциями (open, system)), обязательное экранирование переменных при использование в regex выражении (/\Q$var\E/, иначе $var может содержать "?{код}").
    Perl пишем на Perl: никаких `` и вызовов shell функций, скрипт с perl -w и в strict режиме;
    Перед написанием кода - обязательное планирование, перед кодированием скрипт должен уже иметь четкую структуру.
    После написание - отладка и crash тест.
    Доступ к системе web-управления, только с "trusted" хостов, желательно по HTTPS.
o    Защита обслуживаемой сети c пользователями.
    Оборудование и рабочее место администратора не должны быть подключены в рамках одной физической сети (см. выше пункт "сниффинг"). Желательно разделить сеть по отделам (директора и бухгалтерию подключить отдельно).
    Не допустить доступ к оборудованию посторонним (охрана, дети сотрудников). Обязательная парольная аутентификация на каждой машине и жесткие административные правила пользования сетью.
    Машины сети снабдить IP адресами из интранет блока. Выход во вне только через прокси или транслятор адресов. Фаерволом закрыть все кроме необходимых сервисов.
    Установка локального ПО для борьбы с вирусами, постоянное обновление пользовательских систем (установка service pack) и программ для работы в сети (IE, Opera, The Bat, Outlook).
    Повышение грамотности пользователей.
    Мониторинг уязвимостей в локальной сети, средства сканирования пользовательских машин на предмет известных уязвимостей.
o    Защита от DoS и DDoS.
-----------------------------
 
  Рекламное место пустует
   Гэст
1 - 20.06.04 - 18:01
Посмотрите DataparkSearch - http://www.dataparksearch.org/
http://www.43n39e.ru/ - пример сервера где проиндексировано свыше 6Гб.
   biobankir
2 - 22.06.04 - 16:44
Очень хрошая, полезная статья. А какими именно "Огненными стенами" пользуетесь для перекрывания всех, кроме необходимых серверов и как необходимые защищаете? Вы


Список тем форума
Рекламное место пустует   Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Ветка сдана в архив. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует