[umka]

Ну да.

У моей сети ведь может быть сколько угодно точек выхода и в каких угодно местах.

Стало быть, из каждой точки идут анонсы.

Как только сервак сдох, он перестаёт слать анонсы (потому что он сдох )) Ну или если он не до конца сдох, то другие серваки сами гасят на нём bgp.

И стало быть, трафик в мою сеть (который шёл на этот сервак) начинает идти в обход. То бишь через другую точку, где посетителей радостно встречает работоспособный сервер.

Единственный минус — каждая точка не будет расчитана на большУю нагрузку. Т.к. под маршрутизацию уходит весь L2 cache процессора :)

(хотя, если он только для себя будет трафик роутить, то наверна не так много ресурсов уйдёт)

Вообще, если всё это сделать аппаратно, то будет мегавещь! Особенно с балансировкой.

Я вижу вот такой способ реализации этой задумки.

Нам потребуется свой блок ip-адресов.

Ставим в каждый ДЦ по серванту (или по VDS-ке).

Договариваемся с провайдерами, чтобы они принимали от нас анонсы нашей сети.

Надобность в балансерах, SAN-ах и пр. "обвесах" отпадает.

Все серваки в каждом ДЦ шлют анонсы нашей сети и имеют одинаковый ip-адрес (из нашего блока).

Если сервак ломается/дохнет или по какой-то причине теряет связь со внешним миром, анонсы естественно с него перестают отправляться, и через несколько минут трафик на него перестаёт идти.

Разумеется, на всякий случай нужно пустить между всеми серверами heartbeat, чтобы в случае, если на каком-то серваке отвалился только апач (или что там у кого), чтобы другие серваки выключили на нём анонсы сети.

Все серваки друг с другом затуннелены и данные на них чудесным образом реплицируются :)

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

Если же в каждом ДЦ поставить по балансеру, то можно будет еще и раскидывать нагрузку по другим ДЦ, но это уже менее бюджетный вариант :)

В смысле, сами процессы апачевские в состоянии sleep?

А чем вам это мешает?

Делаем директорию images.

В ней делаем 100 директорий, в каждой из них делаем еще по 100 директорий, и в каждую из них кладём по 100 файлов.

Получается 1000000 файлов.

Еси локальная файловая система перестанет справляться, всё это дело разносится на несколько внешних.

О! надо было больше брать! )))

Следственный эксперимент показал, что директория с 10000 пустых файлов занимает 154 Кб!

Так что это должно нормально учитываться при квотировании.

(ufs)

Директория с 100 000 пустых файлов занимает 1584 кб.

Итого, выходит, на 1 файл ufs-ка тратит примерно 16-17 байт.

AustinTX, например, несколько серверов работают с несколькими файлохранилищами.

KM.UA +1 :D

[umka] добавил 10.01.2010 в 14:21

zahosti.ru, а теперь создайте в этой директории еще сотню пустых файлов. Её размер не увеличится :)

du показывает только актуальный размер файлов. Надо еще как-то смотреть )

У меня на FreeBSD 64-bit и ufs размер пустой директории и директории с сотней пустых файлов одинаков - 2 Кб

Подцепите этот <Location> к какому-нибудь виртуальному хосту на всякий случай.

Проверьте, чтобы там url-ы не перезаписывались всякими mod_rewrite-ами.

Проверьте error_log, может там что полезное пишут :)

AustinTX, смотря что с этими файлами делать.

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

Но если каждый из этих файликов будет открываться/запрашиваться раз в минуту — это уже другой вопрос. :)

Думаю, при нормальной организации (каталогизации и пр.) можно разместить и миллион.

MaxRequestsPerChild по-дефолту равен нулю и ничего страшного в этом нет, если нет утечек памяти и пр.

Посмотреть, какой запрос грузит сервант, можно например с помощью server-status

<VirtualHost 12.34.56.78>

    ServerName mysite.ru

    ...

    <Location /server-status>

        SetHandler server-status

        Order deny,allow

        Deny from all

        Allow from .example.com

    </Location>

</VirtualHost>

ну и потом на http://mysite.ru/server-status/

это самый простой способ

Имхо, квота на количество файлов — это жестоко.