Приветствую, Mamut, вы писали:

M> S> Напиши мне такой же "код перечитывания конфигов", построенный на основе текстовых файлов.
M> На этот вопрос не будет ответа. Готов принимать ставки.
Поздно.

Приветствую, Sinclair, вы писали:

S> Но фишка, видишь ли, в том, что для начала тебе нужно получить vhost_config_file. А где его взять? Сначала нужно прочитать файл со списком vhost-ов, чтобы найти там запись о расположении этого файла.
Не знаю как у них там, но я бы выработал единое наименование конфигов, и не читал имена файлов откудатотам, а просто генерировал исходя из какихтотам параметров вхоста. С другой стороны написал бы автогенерацию вхоста (скрипт обычный, одна штука) с настройками по умолчанию и выкладыванием конфига и сайта по нужным местам, заодно пиная апача чтобы он всосал новый вхост.

Здравствуйте, Cyberax, Вы писали:
C>В общем, всё продумано, как оказалось. Можешь сам глянуть в src/os/unix/ngx_process_cycle.c .
Ага, то есть там трёхфазное переключение. Очень грамотно. Осталось проследить за тем, чтобы подъем не занял больше времени, чем интервал между изменениями

Здравствуйте, Sinclair, Вы писали:

C>>В общем, всё продумано, как оказалось. Можешь сам глянуть в src/os/unix/ngx_process_cycle.c .
S>Ага, то есть там трёхфазное переключение. Очень грамотно. Осталось проследить за тем, чтобы подъем не занял больше времени, чем интервал между изменениями
Как оказалось, Апач на миллионе vhost'ов вообще падает С nginx не пробовал.

В общем, такие экстремальные задачи — экстремальны. В обычной жизни как-то проще с файлами конфига, а не реестром.

Тем более, что для всяких bind'ов как раз есть возможность хранения конфигов в БД. Они только уж очень редко нужны.

Здравствуйте, Sinclair, Вы писали:

S> AB>И что случается дальше?
S> Дальше — продолжается развитие схемы хостинга высокой плотности.

Ты не ответил на вопрос — во что упираемся?

S> AB>А что именно не работало до этого?
S> Не получалось соблюсти SLA.

Какие именно пункты?

S> Не все такие пофигисты. Большинству народа как-то хочется, что если, к примеру, MX перенаправили на AS/AV гейтвей, то проверить, что он реально ловит спам и пропускает нужный контент, хочется сейчас, а не потом. Ну и то, что сам гейтвей правильно получил настройки, тоже хочется проверить. А с задержкой в 6 часов это всё придётся отложить до завтра.

Для этого DNS не нужен.

S> Я хочу сказать, что задержка на 6 часов — это как бы не самое хорошее, что можно сделать.

Мир несовершенен и перегружая зону раз в 15 минут ты его не делаешь совершеннее ни на йоту.

S> Я хочу сказать, что идея "делегировать зону себе" — приговор для high density хостинга. Можно грубо прикинуть, сколько киловатт будет бездарно выбрасываться, если каждый из клиентов GoDaddy станет "делегировать зону себе". 22 миллиона выделенных DNS серверов — это отличное решение проблемы масштаба.

Это ты в крайности бросился — менять зону раз в 10 минут нужно очень ограниченному во всех смыслах кругу лиц.

S> AB>20К виртуальных хостов на сервер? ТТХ сервера еще можно в студию?
S> Ну, пусть скажем это будет обычный 4x-гиговый 4х-корный сервер.

А теперь внимательно следи за руками. Берем стандартный Intel Core2Quad Q6600@2.40GHz. Берем сайт на стандартной CMS (пусть будет Wordpress или Bitrix). Максимальная производительность такого сайта на таком CPU будет около 250 тыс. хитов в сутки (с учетом неравномерности суточной нагрузки и тем, что он не должен лечь в ЧНН) — цифры усреднены с реальных тестов, можешь перепроверить сам. Распределим 250К хитов на 20К сайтов — 12 запросов на сайт в сутки максимум — это не хостинг, это баловство.

Продолжаем наши эксперименты. Берем заведомо слабую машинку — мой недобук в конфигурации Genuine Intel T1400@1.73GHz (это 2хСore целерон) и 1GB RAM. На ней запущен KDE, Opera, Avalon — проще говоря, смотрим что у нас по памяти:

# free -m
             total       used       free     shared    buffers     cached
Mem:          1000        463        536          0         30        205
-/+ buffers/cache:        227        772
Swap:         1023          2       1021

Создаем 20К виртуальных хостов вида:

NameVirtualHost 127.0.0.1:80

<VirtualHost 127.0.0.1:80>
        ServerName  NNNNN.example.com
        ServerAlias www.NNNNN.example.com
        ServerAdmin mickey@mouse.ru
        DocumentRoot /home/abbat/20k/NNNNN.example.com
        <Directory /home/abbat/20k/NNNNN.example.com>
                AllowOverride None
        </Directory>
</VirtualHost>
...

Получаем конфиг размером 5.1MB. Апач его при полном рестарте проглатывает за 14 секунд (против 5 секунд при отсутствии конфигов). Соответственно создаем 20К директорий вида /home/abbat/20k/NNNNN.example.com с единственным файлом внутри index.php с содержимым:

<?php
        echo 'hello world!';
?>

Они у нас занимают 157MB. Поскольку нас в данном случае интересуют лишь затраты самого Apache, то содержимое скрипта чем проще тем лучше. Смотрим еще раз на память:

# free -m
             total       used       free     shared    buffers     cached
Mem:          1000        981         18          0         30        205
-/+ buffers/cache:        745        254
Swap:         1023          2       1021

Чудес не бывает, но вроде не свопимся. Запускаем бенчмарк:

# ab -c 1 -t 60 'http://0.example.com/index.php'
...
Time per request:       1.215 [ms] (mean)
...

Отлично. Но это хост по умолчанию. Посмотрим что будет с 19999:

# ab -c 1 -t 60 'http://19999.example.com/index.php'
...
Time per request:       11.026 [ms] (mean)
...

Ага, и еще раз посередине:

# ab -c 1 -t 60 'http://10000.example.com/index.php'
...
Time per request:       6.070 [ms] (mean)
...

Линейная зависимость. Т.о., получаем до 10 тысячных секунды затрат на недобуке — на реальном сервере оно будет побыстрее (хотя упрется в скорость работы с памятью).

В итоге, из за 10ms и из за 12 запросов на сайт в сутки ты мне предлагаешь городить реляционную БД, править апач и заниматься еще бог знает чем?!!

Я не знаю какую технологическую задачу решали в 1&1, но это была явно не задача производительности.

S> AB>Ну небольшая сеточка с этим вполне справится — каждый по 25-30K запросов может держать одновременно — потребуется всего 40 машин.
S> Это уже получается примерно столько же машин, как у хостера

И что? Мне же не надо покупать физические машины — достаточно купить процессорное время в ботнете, зараженных виндузятников по миру как грязи.

S> Тем более, что никакого особенного "положить" не получится. Получится всего лишь скоростной прогрев кэша.

Лягут гораздо раньше, нежели прогреется 1млн доменов

S> Я не знаю, какие именно проблемы приводят к факапам. Но вот один из наших клиентов недавно затеял дублирование части своего хостинга во второй датацентр. Потому что вышеописанный "серьёзный DC" на прошлой неделе опять остался без света.

Я поддерживаю всячески клиента. У меня нет опыта со штатами, но от ДЦ в Германии я плакаю навзрыд — то пачкорд из сервера вылетает, то маршрутизатор роняют. В России за такие косяки хостер получает имя нарицательное вида "Мастерхост" или "Агава" (это чтобы не ругаться матом в приличном месте) и ему остается только удел нищебродов (как раз для сайтов "Я и моя собака").

S> Осталось еще сделать так, чтобы SLA само по себе предотвращало ураганы и прочий форсмажор.

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

S> AB>Какая разница сколько это времени займет, если это не является критической ситуацией? Точно так же мне будет нужно подниматься и в случае штатного обслуживания (обновления ядра например). Для этого критичные участки и дублируют.
S> В том-то и дело, что тебе надо будет "подниматься" в случае обновления ядра. Именно поэтому рулит stateless, где никакого "подъёма" вовсе нет. А ты мне рассказываешь про то, что подъем типа не важен.

Там где у тебя будет база — там тоже иногда придется обновляться и точно так же потом базу поднимать с диска. А если ты ее реплицируешь, так и я так же предлагаю репликацию, только на уровне ФС — мое решение проще и надежнее как ни крути.

S> AB>Это общепринятая практика проверки файлов, не мной придуманная и вполне себе успешно работающая. Она так же удобна в отладке, работе и т.д. ибо опять же текст.
S> Ну то есть bind общепринято проверяет зонные файлы при помощи SHA? Или ты имеешь в виду, что у меня будет в панели код, который пытается записать файл зоны "на ту сторону", ловит исключения, и в цикле пытается переповторить с перепроверкой SHA?
S> Прекрасно. Действительно, чего это я к транзакциям прицепился. Это же всё так просто делается.

Bind не проверяет — это не его забота. А проверку ты можешь реализовать как твоей душе угодно — консольный openssl тебе и посчитает и ЭЦП поставит, разве что джигу не станцует.

Здравствуйте, Mamut, Вы писали:

M> Вообще-то, в реальном мире падают даже крупные и проверенные датацентры (только в этом году летом снесло на стуки или больше почти весь MySpace — причины потери питания в датацентре уже не помню)

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

Приветствую, Anton Batenev, вы писали:

AB> S> AB>И что случается дальше?
AB> S> Дальше — продолжается развитие схемы хостинга высокой плотности.

AB> Ты не ответил на вопрос — во что упираемся?

В Синклера

Здравствуйте, Mamut, Вы писали:

M> S> Напиши мне такой же "код перечитывания конфигов", построенный на основе текстовых файлов.
M> На этот вопрос не будет ответа. Готов принимать ставки.

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

Здравствуйте, Sinclair, Вы писали:

S> Экспериментальным путём. Конфиги, как я уже полветки объясняю, становятся боттлнеком в таких конфигурациях.

Ты так и не ответил в каком месте они становятся — отнекиваешься NDA и какими-то buzz-words.

S> Потому что на их перечитывание при изменениях уходит непозволительно много времени.

Копейки.

S> Вообще идея "зачитать всё в память при старте", которую тут предлагал Антон Батенёв, утопична при высокой загрузке.

Как раз при высокой нагрузке это наиболее производительное (и бывает так, что единственно разумное) решение. В качестве элементарного примера можно привести memcached — когда БД на LiveJournal начала сосать, пришлось изобретать "базу" специального назначения (а проще говоря хэш) с прямым доступом к памяти.

S> Там этот твой "релоад" будет запускаться четыре раза в секунду, и требовать часы для завершения.

Выше я привел цифры. "Часы" там не стояли близко. Мягкий рестарт апача вообще будет незаметен. И что это за надобность такая перечитывать конфиги 345 600 раз в сутки?

Здравствуйте, Sinclair, Вы писали:

S> Ну вот в том-то и дело, что с т.з. лоад балансера у тебя 51й апач в любой момент должен быть готов заменить любого из 50.

Не должен. Предположим, что 50 серверов держат 100% нагрузки и загружают ресурс на 80% (это будет скорее всего CPU, а при большей загрузке CPU производительность начнет деградировать). Так вот выход одной ноды приведет к тому, что оставшиеся ноды получат дополнительно ~2% от их текущей нагрузки — они этого в теории даже заметить не должны.

S> Что эквивалентно тому, что все 51 "держат" полный конфиг всего миллиона сайтов. Увы.

А и не надо на всех 50 держать полный 1 млн хостов, тем более, что подобная 50-и кратная избыточность не имеет практического смысла.

Здравствуйте, Sinclair, Вы писали:

S> А когда речь идёт о миллионе сайтов, то у тебя получается 50 таких серверов. И ставить двойное дублирование — не выход. Потому что дорого.

И еще раз обратимся к цифрам. По твоим словам, у 1&1 50 серверов и 1 млн сайтов. Смотрим на тарифы — минимальный 4$. Т.е. 4M$ в месяц минимум. 50 серверов в аренду стоит ~800Круб. Что составляет ~30K$ или 0.75% от оборота (при чем в эту сумму комплектуха, питание, сеть — все уже включено).

Не находишь, что цифра 0.75% несколько странновата для слова "дорого"? Либо там совсем не миллион сайтов или совсем не 50 серверов (или и то и другое вместе).

Здравствуйте, Anton Batenev, Вы писали:

AB> Не находишь, что цифра 0.75% несколько странновата для слова "дорого"? Либо там совсем не миллион сайтов или совсем не 50 серверов (или и то и другое вместе).

А, ну собственно вот и ответ:

10 million domain names are registered and handled by 1&1
...
Servers installed: 70,000

Или другими словами 145 доменов на сервер (если тупо считать). Предположим, что часть серверов используется для других нужд (базы данных, хранилища бэкапов и т.д.), то путь даже эта цифра дойдет до 200 доменов на сервер (это 20,000 (~30%) служебных и 50,000 "боевых" серверов).

200 доменов на сервер — цифра более чем скромная (обычно вытягивают до 500-600) и ни о каком high-load тут говорить не приходится. Рулить правда этим хозяйством забавно, но это задача другого толка.

З.Ы. Синклер, я разочарован — я так ждал каких-то новых для себя откровений, а все оказалось как обычно банально.

M>> S> Напиши мне такой же "код перечитывания конфигов", построенный на основе текстовых файлов.
M>> На этот вопрос не будет ответа. Готов принимать ставки.

AB>Не будет, потому что код невалидный и не учитывает множества тонкостей, которые учитывает оригинальный апач. Например, с wildcard доменом тут будет полная засада.

В нормальной базе данных не будет.

AB> M> Вообще-то, в реальном мире падают даже крупные и проверенные датацентры (только в этом году летом снесло на стуки или больше почти весь MySpace — причины потери питания в датацентре уже не помню)

AB> Факапы случаются, но они должны быть чем-то из ряда вон выходящим, нежели обычным явлением.

Они и являются из ряда вон выходящим явлением. Но это не значит, что против них не надо защищаться

За что люблю СВ, так это за то, как обсуждение ОС плавно перетекает в меряние веб серверами...

Здравствуйте, Mamut, Вы писали:

M> AB>Не будет, потому что код невалидный и не учитывает множества тонкостей, которые учитывает оригинальный апач. Например, с wildcard доменом тут будет полная засада.
M> В нормальной базе данных не будет.

Но и запросы уже не будут столь тривиальными. Структура, которая будет учитывать все эти маленькие мелочи будет сопоставима по "громоздкости" с конфигами, плюс будет иметь накладные расходы на "прокладку". А если не видно разницы, то зачем платить больше?

Здравствуйте, 0K, Вы писали:

0K>Поясню детали: для чистоты эксперимента Win7 установил на 2-х компах. У главного сетевой адрес автоматически установился в 192.168.137.1, как только была нажата птичка "разрешить использовать подключение" соединения Wi-fi. На главном компе есть Интернет, все ок. Второй комп видит главный, даже можно заходить в расшаренные папки. А вот Интернета на втором -- нету! Что делать -- понятия не имею. Уже все перепробывал

Пропиши в настройках второго компьютера айпишник первого в поле Default getway (в настройках TCPIP). То что это не делается автоматом конекшон-шарингом действительно глупость еще та. Но эта проблема существовала в NT c самого ее появления (точнее с появления в ней поддржки TCPIP).

В остльном все твои слова полнеший гон.

Здравствуйте, alpha21264, Вы писали:

A>Но ведь вопли виндузятников, ниасиливших Линукс, тебе не надоедают...

Вообще, надоели.