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

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 посреди рабочего дня -- довольно интересно). Но с другой стороны можно сделать специальный сервер для раздачи и отделить его от основных серверов фаервольной стенкой, так как бы он стоял снаружи :) Если даже и взломают, то ничего ценного кроме конфига указанного сервер они не получат.