FastNetMon

вторник, 24 июня 2008 г.

Снова стоит ряд практических задач

1) Во-первых требуется набрать оптимальную софтово-хардварную конфигурацию для относительно недорогого сервера бэкапов (сторадж 1-2 терабайта с рейдом 1+0 или 5)
2) Требуется продумать схему, по которой сервер бэкапов будет максимально универсален и безопасен (в данный момент предполагается использовать rsync поверх ssh). Требуется довольно немного -- механизм инкрементальных (те при обновлении файла тянем только изменившуюся часть, не изменившиеся файлы не трогаем) копий и возможность отката (с точностью до дня / часа) на месяц другой в прошлое.
3) Нужно как-то собирать логи (много-много-много логов!) с нескольких серверов, причем почти все они представляют собой обычные текстовые файлы и о таких вещах как syslog не слышали. Может есть какие централизованные системы сбора логов?
4) Вот ещё такой интересный вопрос -- все отлично знают, что легкие сервера по типу lighttpd и nginx очень хороши для раздачи статики и проксирования FastCGI / http серверов. А вот как будут они себя вести при раздаче очень больших файлов (такая своего рода "мегастатика")? Эдак очередь человек на 200 и раздача файлов по 1-2 гб. Вот если верить тестам на домашней странице Лайта http://www.lighttpd.net/benchmark , то он очень неплох при раздаче. Надо будет на досуге сравнить его с nginx при раздаче таких файлов.
5) А на каком веб сервере работает Akamai ? Пожалуй, это самый просто вопрос. Точно помню, что ATI раздает через них свои дрова, так сейчас и проверим :)

telnet a248.e.akamai.net 80
Trying 217.212.246.104...
Connected to a248.e.akamai.net.
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.0 400 Bad Request
Server: AkamaiGHost
Mime-Version: 1.0
Content-Type: text/html
Content-Length: 216
Expires: Tue, 24 Jun 2008 14:19:44 GMT
Date: Tue, 24 Jun 2008 14:19:44 GMT
Connection: close

Один вопрос решили, осталось узнать, что это за сервер такой (навряд ли открытый, но все же).
6) А я ведь думал, что когда говорили про kernel-based httpd, то это был стеб, казывается нет, прошу по ссылке: http://dir.filewatcher.com/d/Fedora/ppc64/System%20Environment/Daemons/tux-3.2.18-4.ppc64.rpm.88721.html

По этому же поводу довольно интересное обсуждение в apache-talk: http://www.lexa.ru/apache-talk/msg04850.html . Сам я довольно скептически отношусь к такого рода затеям как эта (вставлять в ядро типичный userspace демон! экий страх!), в первую очередь из-за вопроса безопасности (ну вопрос стабильности тут тоже не на последнем месте -- получить kernel panic посреди рабочего дня -- довольно интересно). Но с другой стороны можно сделать специальный сервер для раздачи и отделить его от основных серверов фаервольной стенкой, так как бы он стоял снаружи :) Если даже и взломают, то ничего ценного кроме конфига указанного сервер они не получат.

2 комментария :

  1. Анонимный25 июня 2008 г., 01:20

    2) rdiff-backup
    4) nginx неплохо себя ведет при достаточно быстром диске и достаточно большом количестве вокеров. Подробнее - в листе nginx-ru.

    ОтветитьУдалить
  2. Ага, благодарю :)
    Тут недавно как раз в руки попался человек, рассказавший, как ведет себя нджинкс при раздаче многогигабайтных файлов куче клиентов. Все рассказывать долго и нудно, но суть в том -- что Нджинкс преуверенно себя чувствует при таких нагрузках, при которымх lighttpd сдавался вообще без боя. Так что лучше Nginx для статики только Nginx :)

    За rdiff-backup спасибо отдельно, судя по списку функций на офсайте она покроет все наши потребности.

    ОтветитьУдалить

Примечание. Отправлять комментарии могут только участники этого блога.