Здравствуйте, Sheridan, Вы писали:
S>> О! Достаточно перестать говорить о малом количестве зон, как все рассуждения о прелестях текстового конфига теряют актуальность.
S>как я понял говорится не о малом количестве зон, а о том, что БД там наклеп не нужна.
"Там" — это где?
S>> Я, наверное, тебя разочарую. Я работаю как раз там, где производят эти "различные панели управления".
S>Оооооо, ну да, ну да, как мы могли забыть.

S>Теперь понятна твоя заинтересованность в том чтобы конфиги лежали в xml, а лучше всего вообще в БД.
Это ты значит XML противопоставляешь текстовым конфигам? Ай, молодец.
S>Так и говори, что "мне было бы удобнее", а не "текстовые конфиги — нехорошо"
Я так и говорю, что "мне было бы удобнее". И нашим клиентам было бы удобнее. А с какой ещё точки зрения я должен это расценивать? С точки зрения абстрактной справедливости? Мне на неё наплевать. Мне нужен DNS-сервер, который бы хорошо масштабировался и был отказоустойчивым. И нужен веб-сервер, который позволяет хостить миллионы простых сайтов с горячей заменой. И всё это должно работать на минимальном количестве железа.

А поклонники текстовых конфигов мне тут предлагают использовать "типичных дедиков" для разгрузки корневых серверов. Ты точно всё еще в лагере тех, кто призывает экономить мощность? Или попутал чутка?

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

S> S>как я понял говорится не о малом количестве зон, а о том, что БД там наклеп не нужна.
S> "Там" — это где?
Теряешь нитть разговора? Понимаю.

S> S>Оооооо, ну да, ну да, как мы могли забыть.
S> S>Теперь понятна твоя заинтересованность в том чтобы конфиги лежали в xml, а лучше всего вообще в БД.
S> Это ты значит XML противопоставляешь текстовым конфигам? Ай, молодец.
Да. Хочешь меня попробовать поймать на том что xml тоже текстовый? Ты наверное не понимаешь, что xml трудночитаем человеком.

S> S>Так и говори, что "мне было бы удобнее", а не "текстовые конфиги — нехорошо"
S> Я так и говорю, что "мне было бы удобнее". И нашим клиентам было бы удобнее. А с какой ещё точки зрения я должен это расценивать? С точки зрения абстрактной справедливости? Мне на неё наплевать.
Да тебе я смотрю на много наплевать.

Мне нужен DNS-сервер, который бы хорошо масштабировался и был отказоустойчивым.
bind?

S> И нужен веб-сервер, который позволяет хостить миллионы простых сайтов с горячей заменой.
Апач? Нгинкс?

S> И всё это должно работать на минимальном количестве железа.
Какое в твоем понимании это железо? Как по мне так это пень 1000 с 512мб оперативки, но я думаю твое понимание на порядки выше производительность иметь будет.

S> А поклонники текстовых конфигов мне тут предлагают использовать "типичных дедиков" для разгрузки корневых серверов. Ты точно всё еще в лагере тех, кто призывает экономить мощность? Или попутал чутка?
Гм, у тебя dns более нагружен, нежели корневые сервера? Ты полагаешь что bind не справится с такой нагрузкой?

S>> И нужен веб-сервер, который позволяет хостить миллионы простых сайтов с горячей заменой.
S>Апач? Нгинкс?

Апач в жизни не сможет захостить миллион простых сайтов. И полноценной горячей замены ни в апаче ни в nginx'е нет. Их надо пинать, чтобы они заново считали конфиги

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

M> Апач в жизни не сможет захостить миллион простых сайтов.
Зависит от железа.

M> И полноценной горячей замены ни в апаче ни в nginx'е нет.
Что ты понимаешь под этим?

M> Их надо пинать, чтобы они заново считали конфиги
.htaccess?

S> M> Апач в жизни не сможет захостить миллион простых сайтов.

S> Зависит от железа.

не зависит. не сможет

S> M> И полноценной горячей замены ни в апаче ни в nginx'е нет.
S> Что ты понимаешь под этим?

добавь новый сайт в httpd.conf/nginx.conf и чтобы усе сразу поехало

S> M> Их надо пинать, чтобы они заново считали конфиги
S> .htaccess?

я имел в виду httpd.conf и иже с ними

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

S>> M> И полноценной горячей замены ни в апаче ни в nginx'е нет.
S>> Что ты понимаешь под этим?
M>добавь новый сайт в httpd.conf/nginx.conf и чтобы усе сразу поехало
Умм... А "/etc/init.d/apache reload" чем не угодил?

C> S>> M> И полноценной горячей замены ни в апаче ни в nginx'е нет.

C> S>> Что ты понимаешь под этим?

C> M>добавь новый сайт в httpd.conf/nginx.conf и чтобы усе сразу поехало

C> Умм... А "/etc/init.d/apache reload" чем не угодил?

хотелось бы чтоб сразу имхо, это именно то, о чем синклер говорил

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

C> M>добавь новый сайт в httpd.conf/nginx.conf и чтобы усе сразу поехало
C> Умм... А "/etc/init.d/apache reload" чем не угодил?
Наверное тем, что вручную запускать надо.

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

M> S> M> Апач в жизни не сможет захостить миллион простых сайтов.
M> S> Зависит от железа.
M> не зависит. не сможет
Ты ссылку забыл дать.

M> S> M> И полноценной горячей замены ни в апаче ни в nginx'е нет.
M> S> Что ты понимаешь под этим?
M> добавь новый сайт в httpd.conf/nginx.conf и чтобы усе сразу поехало
Гм, я бы следил по inotify\dnotify за конфигами и по изменению делал рестартовал апач с -k graceful, чтобы соединения не рвало. Скрипт написать можно имхо за полчаса... Точнее не скрипт, а программулину. Неважно в общем.

А вообще редко имхо нужно бывает так часто сайты добавлять\удалять. Разве что крупным хостерам...

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

S> Про удобство — согласен на 100%. А вот про производительность — расскажи это парням из 1&1. Я не знаю, с чем связана твоя убеждённость, но текстовые конфиги имеют ограничения на предел масштабирования. Увы.

О каких пределах масштабирования идет речь (более конкретно)?

S> AB>Она эффективна с точки зрения скорости работы в типичных use-caseах. Есть альтернативное мнение? Готов выслушать.
S> Есть. Я уже трижды намекнул тебе, что 1&1 используют сильно допиленный DNS-сервер (не bind) и сильно допиленный Апач. Основной допил — отрезание нахрен текстовых конфигов.

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

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

S> AB>Данные с потолка меня интересуют мало.
S> Извини, реальные данные закрыты NDA.

Тогда зачем о них вообще заикаться? Найди публично-доступные проверяемые аргументы. В противном случае мы здесь можем под видном NDA вообще начать нести полную ахинею (утрирую конечно, но тем не менее).

S> AB>В том, что цифры, когда они берутся не с потолка, наглядно показывают полное безразличие сервера к исходному формату хранения данных.
S> А можно мне тогда попросить, чтобы RU-CENTER обновлял зоны не через 6 часов, а хотя бы через 10 минут, как делаем мы?

За спрос денег не берут Но не думаю, что есть достаточно веская причина менять отработанную вполне себе работоспособную технологию. А уж обновлять зоны раз в 10 минут — мне трудно представить подобную надобность (что такое срочное не может подождать пока я попью кофе?!).

S> AB>Apache точно так же читает настройки в память. А где ты их хранишь в исходниках — да хоть на перфокартах.
S> Штатный апач — да. А вот если хочется получить реальную hi-density, то никаких перфоркарт и текстовых конфигов там не будет.

Цифры на бочку. hi-density — это сколько грамм в пакетике?

S> И никакого "чтения настроек в память" — тоже не будет. Все настройки будут обрабатываться on demand. Точно так же, как и везде — приехал запрос, начинаем запрашивать "модуль конфигурации".

Чтение настроек on demand — это повод запросить все домены одновременно и положить хостера.

S> Ну значит RU-CENTER — плохой пример. Я лично сталкиваюсь не с корневыми серверами, а с теми самыми, кому делегируют зоны. И вот там всё гораздо интереснее.

С некорневыми серверами все еще более тривиальнее и проще (и чем дальше от корня, тем проще).

S> О! Достаточно перестать говорить о малом количестве зон, как все рассуждения о прелестях текстового конфига теряют актуальность.

Так не теряют. Даже на примере зоны RU.

S> AB>"Эта хня" работает в реальной жизни. Хорошо работает. Текстовые конфиги не обязывают к ручному управлению, что доказывают нам различные панели управления.
S> Я, наверное, тебя разочарую. Я работаю как раз там, где производят эти "различные панели управления".

Только не говори, что ты причастен к тому самому страшному сну сисадмина под названием Plesk? Всегда, когда с ним сталкиваюсь, мне хочется его создателям отрубить руки и ноги, а потом медленно жарить на слабом огне. Вот эти ребята реально извратили идею до того, что приходится громоздить кучу костылей даже на три зоны.

S> AB> Словосочетание "подтверждается практикой ведущих хостеров" равносильно "из достоверных источников".
S> Ну ты же не ожидал, что я тебе выложу интимные подробности бизнеса наших партнёров? Я NDA подписывал. Sapienti sat. Или ты предполагаешь, что я тут всё это из головы нафантазировал? Увы, нет.

Увы, да. (см. выше про NDA).

S> 1. Чувак, пропадание питания в датацентре — это суровая реальность наших американских партнёров. Не надо мне тут рассказывать про дизели и всё такое — я имею информацию из первых рук.

Откажитесь от любителей в пользу профессиональных ДЦ.

S> 2. Ну вот, допустим, у тебя навернулся твой bind с 2.2 GB данных зон. Сколько времени будет восстанавливаться "бэкап"?

~14 минут. Но с учетом того, что сервер у меня дублируется, то это не имеет значения.

S> 3. Ок, ну вот ты сделал резервный сервер, который стоит в другом датацентре. Теперь у тебя узкое место — сеть. Начал ты писать через континент файлик зоны, тут в середине какая-то хня произошла — что будет? Наверное, это нифига не реалистичный сценарий. Тем не менее, я уже несколько раз наступал на то, что bind теряет зоны. Ну, конечно же, это лечится перегенерацией и рестартом, но раздражает очень сильно. Я бы предпочёл ACID, в котором ничего не пропадает.

А ничего не будет — до перегрузки зоны ты вообще файл можешь удалить с диска. По этому, если пропала связь, то запиши его еще раз. Ну и если хочется, то придумали md5 и sha.

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

M> Апач в жизни не сможет захостить миллион простых сайтов. И полноценной горячей замены ни в апаче ни в nginx'е нет. Их надо пинать, чтобы они заново считали конфиги

Захостить сможет, работать сможет, но 1 млн. сайтов даже по 10 хитов на динамику в день создадут на нем неподъемную нагрузку.

Здравствуйте, Sheridan, Вы писали:
S>Зависит от железа.
Мальчик, не фантазируй.
На "современном железе" апач выдерживает порядка 5000 простеньких сайтов. 10k получить можно, но уже могут быть трудности. Для 20k per server нужно уже очень сильно приседать.
M>> И полноценной горячей замены ни в апаче ни в nginx'е нет.
S>Что ты понимаешь под этим?
Горячая замена — это когда у тебя вот такой сервак с 20k сайтами сгорел, то обслуживание не прекратилось.
А когда речь идёт о миллионе сайтов, то у тебя получается 50 таких серверов. И ставить двойное дублирование — не выход. Потому что дорого.
Нормальная ситуация — когда у тебя весь миллион сайтов обслуживается всеми 50ю серверами. Когда кто-то ложится, нагрузка перераспределяется между оставшимися.

И вот этого ты без допиливания апача не достигнешь — именно из-за неудачной архитектуры конфигов.

Не надо свой опыт администрирования домашней странички переносить на high load.

Здравствуйте, Cyberax, Вы писали:
C>Умм... А "/etc/init.d/apache reload" чем не угодил?
А ты время померь. И прикинь, сколько это будет времени, если у тебя миллион vhost.

Здравствуйте, Sheridan, Вы писали:
S>Гм, я бы следил по inotify\dnotify за конфигами и по изменению делал рестартовал апач с -k graceful, чтобы соединения не рвало. Скрипт написать можно имхо за полчаса... Точнее не скрипт, а программулину. Неважно в общем.
Это упрётся в предел масштабирования примерно при 1000 сайтов.

S>А вообще редко имхо нужно бывает так часто сайты добавлять\удалять. Разве что крупным хостерам...
Именно. "часто" — понятие относительное.

Здравствуйте, Anton Batenev, Вы писали:
AB>О каких пределах масштабирования идет речь (более конкретно)?
Порядка миллиона доменов/vhost.

AB>Я не знаю, какую технологическую задачу решали в 1&1 (и на сайте сходу не нашел), по этому, если ты можешь рассказать о том, что же стало лучше после такого допила, то я готов выслушать. Если нет, то данный аргумент неуместен.
После допила это стало работать.

AB>Пока что я вижу проблемы с тем, что любое допиливание вносит свои ошибки. Очевидно, что они большая компания, которая может себе позволить создать трудности и героически их преодолевать, но хотелось бы, чтобы не за счет пользователей.
Всё как раз наоборот. Нужный уровень обслуживания пользователей с коробочными версиями софта получить не удалось.

По поводу крупности — все допилы делала очень маленькая группа разработчиков. Основную работу сделали в пределах года, это был примерно 2001. Ядро системы (распределённая база конфигов всего) с тех пор не трогали, хотя клиентские фрагменты, использованные в веб и днс серверах, конечно же переписывали.

AB>Тогда зачем о них вообще заикаться? Найди публично-доступные проверяемые аргументы. В противном случае мы здесь можем под видном NDA вообще начать нести полную ахинею (утрирую конечно, но тем не менее).
Если ты думаешь, что я тебе просто вот тут сижу и фантазирую, то это, конечно, твоё право.

AB>За спрос денег не берут Но не думаю, что есть достаточно веская причина менять отработанную вполне себе работоспособную технологию. А уж обновлять зоны раз в 10 минут — мне трудно представить подобную надобность (что такое срочное не может подождать пока я попью кофе?!).
А мне трудно представить клиента, который согласен ждать следующего рабочего дня, чтобы проверить новые настройки.
Вот когда RSDN на шесть часов ложится, я что-то не замечаю воплей восторга от того, что смена DNS занимает столько времени.

AB>Цифры на бочку. hi-density — это сколько грамм в пакетике?
20k на сервер.

AB>Чтение настроек on demand — это повод запросить все домены одновременно и положить хостера.

Ну запроси одновременно миллион доменов. Я посмотрю.

AB>Только не говори, что ты причастен к тому самому страшному сну сисадмина под названием Plesk?
Причастен. Но плеск — это мелкий масштаб. Он не рассчитан на крупный хостинг.
AB>Всегда, когда с ним сталкиваюсь, мне хочется его создателям отрубить руки и ноги, а потом медленно жарить на слабом огне. Вот эти ребята реально извратили идею до того, что приходится громоздить кучу костылей даже на три зоны.
А-а, ну тут всегда так. Как в форумах стонать — так все самые умные. А на собеседованиях что-то люди двух слов связать не могут. Вот эти ребята — такие же, как и все.
Причём, к слову, Плеск еще далеко не самая плохая из панелей. Может, ты укажешь на каких-то конкурентов, которые не извратили идею?

AB>Откажитесь от любителей в пользу профессиональных ДЦ.
Это и есть "профессиональные DC". Это у нас в России "полупрофессиональный DC" — это комнатка с парой шкафов в университетском городке. А в штатах всё серъёзно. Увы, не помогает.

AB>~14 минут. Но с учетом того, что сервер у меня дублируется, то это не имеет значения.
Ну, не имеет, так не имеет.

AB>А ничего не будет — до перегрузки зоны ты вообще файл можешь удалить с диска. По этому, если пропала связь, то запиши его еще раз. Ну и если хочется, то придумали md5 и sha.
О, ну вот уже пошёл дизайн своей ACID. Вот это по-нашему. Кто такие эти идиоты реляционщики, да? Вот мы-то свой ACID на основе md5 и sha наколбасим так, как надо.

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

S> C>Умм... А "/etc/init.d/apache reload" чем не угодил?
S> А ты время померь. И прикинь, сколько это будет времени, если у тебя миллион vhost.

Ты вот ругаешь и ругаешь, но ничего кроме поливания я тут не вижу. Может начнешь конструктив приводить?

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

S> S>Зависит от железа.
S> Мальчик, не фантазируй.
S> На "современном железе" апач выдерживает порядка 5000 простеньких сайтов. 10k получить можно, но уже могут быть трудности. Для 20k per server нужно уже очень сильно приседать.
Тоесть всетаки я прав — зависит от железа, так?

S> M>> И полноценной горячей замены ни в апаче ни в nginx'е нет.
S> S>Что ты понимаешь под этим?
S> Горячая замена — это когда у тебя вот такой сервак с 20k сайтами сгорел, то обслуживание не прекратилось.
Вы с мамутом определитесь. А то он одно понимает под горячей заменой, ты другое.

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

S> Нормальная ситуация — когда у тебя весь миллион сайтов обслуживается всеми 50ю серверами. Когда кто-то ложится, нагрузка перераспределяется между оставшимися.
Угу.

S> И вот этого ты без допиливания апача не достигнешь — именно из-за неудачной архитектуры конфигов.
А теперь расскажи как ты к этому пришел. При чем тут конфиги?

S> Не надо свой опыт администрирования домашней странички переносить на high load.
Я не переношу, не бойся.

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

S> S>Гм, я бы следил по inotify\dnotify за конфигами и по изменению делал рестартовал апач с -k graceful, чтобы соединения не рвало. Скрипт написать можно имхо за полчаса... Точнее не скрипт, а программулину. Неважно в общем.
S> Это упрётся в предел масштабирования примерно при 1000 сайтов.
При чем тут масштабирование? Я дал решение "проблемы", которую придумал мамут.

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

S>Ты вот ругаешь и ругаешь, но ничего кроме поливания я тут не вижу. Может начнешь конструктив приводить?
Я уже привёл конструктив. Вместо "текстовых конфигов" для хранения конфигураций такого масштаба применяется распределённая реляционная СУБД.

Здравствуйте, Sheridan, Вы писали:
S>При чем тут масштабирование? Я дал решение "проблемы", которую придумал мамут.
Эту проблему придумал не мамут, а авторы апача. Масштабирование — это такое слово, о котором ты, как админ, должен знать. Если себя хоть на волос профессионалом считаешь.