Здравствуйте, Cyberax, Вы писали:
C>Этот вопрос я решил бы на уровне DNS и load ballancer'а. Так как в любом случае нужно будет обрабатывать умирание аппаратного узла.
Ну вот в том-то и дело, что с т.з. лоад балансера у тебя 51й апач в любой момент должен быть готов заменить любого из 50.
Что эквивалентно тому, что все 51 "держат" полный конфиг всего миллиона сайтов. Увы.

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

C>>Т.е. посылаешь ему SIGHUP, и он просто запускает новый nginx, который наследует открытые сокеты старого, в том числе и сокет, на который идёт accept. И потом просто начинает на нём слушать, а старый nginx завершается после смерти всех worker process.
S>Начинать-то он начинает. Но что он делает с новыми соединениями до того, как дочитает конфиг?
Старый nginx их продолжает обрабатывать. Новый nginx убивает его только после окончания чтения конфигов, т.е. уже после вхождения в основной цикл обработки событий. В Юниксах же несколько процессов могут выполнять accept() на одном слушающем сокете.

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

S> S>Тоесть, гипотетически, если у меня будет комп с терабайтом оперативки, быстрым рейдом и 4 тысячами процессоров (ну вобщем "очень крутой сервант" (ц) ) — сколько получится поднять vhost'ов?
S> А скорость света тоже считать равной бесконечности?
Я всего лишь хочу выяснить — зависит от железа оно или от чего еще. Пока что я слышу "от железа не зависит" и вижу отсутствие доказательств.

S> http://websitehostingreviews.blogspot.com/2007/04/top-10-web-hosting-largest.html
S> Это устаревшая на 2 года информация. С тех пор всё только улучшилось.
Будем считать что десятка полтора хостеров наберется с колвом сайтов выше миллиона. Ок?

S> S>4 раза в секунду будут добавлять\удалять vhost'ы? Ну-ну.
S> Ну, не во всякую секунду.
Но 4 раза?

S> S>И насчет "часы для завершения" — реальные цифры покажи с -k graceful, а не предположения. Ты же не любишь предположения, не так-ли?
S> У меня как-то нет под рукой апача с миллионом хостов. Но я при случае замерю
Договорились

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

C>>Этот вопрос я решил бы на уровне DNS и load ballancer'а. Так как в любом случае нужно будет обрабатывать умирание аппаратного узла.
S>Ну вот в том-то и дело, что с т.з. лоад балансера у тебя 51й апач в любой момент должен быть готов заменить любого из 50.
S>Что эквивалентно тому, что все 51 "держат" полный конфиг всего миллиона сайтов. Увы.
Что-то мне такой подход совсем не нравится. Я бы разбил на группы Апачей с относительно небольшими конфигами.

S> M> Ответ рядом у Антона Батенева

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

Вообще-то, там написано, что не сомжет, если ты прочтешь предложение полностью, а не только то, что тебе нравится


S> M> Апач не является самым производительным сервером в мире
S> Знаю.

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

Я не знаю.


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

S> M> Синклер о таких и говорил

S> Три с половиной хостера пока набежало. Как набежит хотябы сотня — тогда и будем говорить. А пока что напомни как тут про линух говорят? "это меньше 1%, значит неважно" — так помоему?

С логикой у тебя вообще не все в порядке. Ты прицепился к слову «три».

Тпереь переведи свой взор на цифру миллионы.
Скажем, Netcraft отслеживает 230 миллионов сайтов. GoDaddy хостит порядка 22 миллионов... Подсчеты можешь делать сам.

Здравствуйте, Cyberax, Вы писали:
C>Старый nginx их продолжает обрабатывать.
C> Новый nginx убивает его только после окончания чтения конфигов, т.е. уже после вхождения в основной цикл обработки событий. В Юниксах же несколько процессов могут выполнять accept() на одном слушающем сокете.
Непонятно. В какой момент стопается старый nginx? Представь себе клиента, который раз в секунду делает запрос, обработка которого занимает 2 секунды.
Итого, у нас всё время не менее 1го выполняющегося запроса. Если новые запросы обрабатываются старым nginx, то у него никогда не кончатся worker processes.

Здравствуйте, Sheridan, Вы писали:
S>Будем считать что десятка полтора хостеров наберется с колвом сайтов выше миллиона. Ок?
Ок. И сотки полторы — хостеров с количеством выше 100000.

S>> S>И насчет "часы для завершения" — реальные цифры покажи с -k graceful, а не предположения. Ты же не любишь предположения, не так-ли?
S>> У меня как-то нет под рукой апача с миллионом хостов. Но я при случае замерю
S>Договорились

Здравствуйте, Cyberax, Вы писали:
C>Что-то мне такой подход совсем не нравится. Я бы разбил на группы Апачей с относительно небольшими конфигами.
Какого размера будут группы? Сколько их будет?

S> S>Ты пока что твердишь что все исправит СУБД для конфигов, хотя на самом деле надо копать не в источник конфигов, а в код перечитывания конфигов. А откуда оно их читать будет — без разницы.

S>
S> Проблема — ровно в том, что код для перечитывания текстовых конфигов может быть только один.
S> СУБД, в отличие от текстовых файлов, позволяют запросить ровно то, что нужно — например, сделать
S>

S> select root_dir from vhosts where hostname = @hostname
S>

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

На этот вопрос не будет ответа. Готов принимать ставки.

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

S> AB>О каких пределах масштабирования идет речь (более конкретно)?
S> Порядка миллиона доменов/vhost.

И что случается дальше?

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

А что именно не работало до этого?

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

Не думаю, но я не могу дискутировать на подобном уровне, когда магическая фраза "под NDA" не позволяет мне сомневаться в аргументе не сомневаясь в правдивости собеседника, а это, согласись, как-то не правильно.

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

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

S> Вот когда RSDN на шесть часов ложится, я что-то не замечаю воплей восторга от того, что смена DNS занимает столько времени.

Ты же сейчас не хочешь сказать, что все проблемы за последнее время связаны с DNS? А если связаны, то решение есть очень простое — делегируйте зону себе и творите с ней все что хотите (уж найти стабильный DNS сервер, зоны которого перезагрузят практически по первому требованию, думаю не проблема). Вот только мне кажется, что TTL=900 установлен не из за DNS сервера.

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

20К виртуальных хостов на сервер? ТТХ сервера еще можно в студию?

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

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

S> А-а, ну тут всегда так. Как в форумах стонать — так все самые умные. А на собеседованиях что-то люди двух слов связать не могут. Вот эти ребята — такие же, как и все.

чур меня

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

Я вообще панели стараюсь обходить стороной. Но если уж искать панель, то ISPManager например. Работает напрямую с конфигами, отсебячины старается не нести, хотя тоже не лишен недостатков, но если придется выбирать между ними, то ISP для меня будет однозначным выбором.

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

В серьезных ДЦ два ввода питания минимум, продублированные упсами и дизелем. Пропадание питания с одного ввода для ДЦ вообще должно проходить незаметно. А если инженер задел и вырвал два провода из сервера одновременно, то тут я могу только развести руками

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

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

Какая разница сколько это времени займет, если это не является критической ситуацией? Точно так же мне будет нужно подниматься и в случае штатного обслуживания (обновления ядра например). Для этого критичные участки и дублируют.

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

Это общепринятая практика проверки файлов, не мной придуманная и вполне себе успешно работающая. Она так же удобна в отладке, работе и т.д. ибо опять же текст.

AB> В серьезных ДЦ два ввода питания минимум, продублированные упсами и дизелем. Пропадание питания с одного ввода для ДЦ вообще должно проходить незаметно. А если инженер задел и вырвал два провода из сервера одновременно, то тут я могу только развести руками

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

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

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

S> S>А кто говорил что будет легко?
S> Никто не говорил. А вот что с текстовыми конфигами будет тяжело — говорил я.
Тяжело написать код чтения\генерации конфигов — да. Поправить вручную — нет.

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

CVhostConfig *config = parcer->parce(vhost_config_file);
std::string root_dir = config->root_dir();

Причем по производительности спорно, так как в твоем случае оно будет выбирать одну запись из миллиона, а в моем парсить текстовичок размером максимум в 20кб. Хотя возможно конечно из БД будет и быстрее, но я бы лично сначала проверил.

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

M> Вообще-то, там написано, что не сомжет, если ты прочтешь предложение полностью, а не только то, что тебе нравится
"не зависит. не сможет" — где тут фраза о том, что сможет? Помоему тут явное отрицание.

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

M> Скажем, Netcraft отслеживает 230 миллионов сайтов. GoDaddy хостит порядка 22 миллионов... Подсчеты можешь делать сам.
С синклером мы об этом уже договорились вроде, почитай там рядом.

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

S> S>Будем считать что десятка полтора хостеров наберется с колвом сайтов выше миллиона. Ок?
S> Ок. И сотки полторы — хостеров с количеством выше 100000.
А теперь я опять приведу вашу любимую фразу: "меньше 1%, значит неважно".
По большому счету эти хостеры вынуждены допиливать то что есть до требуемого функционала самостоятельно. И по всей видимости допиливают.
Интересно только почему результаты допиливания не становятся достоянием общественности. Хотя в отношении апача я честно говоря лицензию не читал, может там можно такое...

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

C>> Новый nginx убивает его только после окончания чтения конфигов, т.е. уже после вхождения в основной цикл обработки событий. В Юниксах же несколько процессов могут выполнять accept() на одном слушающем сокете.
S>Непонятно. В какой момент стопается старый nginx?
При входе нового nginx в цикл событий. Точнее, не "стопается" а посылается сигнал на graceful shutdown, который устанавливает флаг ngx_noaccept.

S>Представь себе клиента, который раз в секунду делает запрос, обработка которого занимает 2 секунды.
S>Итого, у нас всё время не менее 1го выполняющегося запроса. Если новые запросы обрабатываются старым nginx, то у него никогда не кончатся worker processes.
Нет. Старый nginx просто прекращает принимать _новые_ запросы (установлен флаг ngx_noaccept), а старые запросы обрабатываются до завершения. И после завершения всех pending-запросов старый nginx просто тихо умирает своей смертью. В это время новый nginx спокойно обратабывает его входящие запросы.

В общем, всё продумано, как оказалось. Можешь сам глянуть в src/os/unix/ngx_process_cycle.c .

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

C>>Что-то мне такой подход совсем не нравится. Я бы разбил на группы Апачей с относительно небольшими конфигами.
S>Какого размера будут группы? Сколько их будет?
Ну это надо думать и экспериментировать.

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

AB> Ты же сейчас не хочешь сказать, что все проблемы за последнее время связаны с DNS? А если связаны, то решение есть очень простое — делегируйте зону себе и творите с ней все что хотите (уж найти стабильный DNS сервер, зоны которого перезагрузят практически по первому требованию, думаю не проблема). Вот только мне кажется, что TTL=900 установлен не из за DNS сервера.
Если речь о rsdn.ru, то могу предложить свой домашний серван в качестве n-го slave'а. Белый апишник есть, bind работает... Канал конечно слабоват и забит, но я и не master'ом себя предлагаю

M>> Вообще-то, там написано, что не сомжет, если ты прочтешь предложение полностью, а не только то, что тебе нравится
S>"не зависит. не сможет" — где тут фраза о том, что сможет? Помоему тут явное отрицание.

Тьфу, блин.

mamut: апач не сможет захостить миллион сайтов
sheridan: почем так безапелляционно, вон антон пишет, что сможет, но хреново
mamut: вообще-то, если внимательно прочитать, то там написано, что не сможет
sheridan: "не зависит. не сможет" — где тут фраза о том, что сможет? Помоему тут явное отрицание.

Теперь читаем еще раз:

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

Выделенное курить до полного просветления


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

О чем, в общем-то, Синклер и сказал с самого начала


M>> Скажем, Netcraft отслеживает 230 миллионов сайтов. GoDaddy хостит порядка 22 миллионов... Подсчеты можешь делать сам.
S>С синклером мы об этом уже договорились вроде, почитай там рядом.

Нифига ты там не договорился. Ты опять решил вариться в своих собственных фантазиях: «А теперь я опять приведу вашу любимую фразу: "меньше 1%, значит неважно".»

Эти хостеры — это не меньше 1%. Это — больше 20-25%. Потому что надо смотреть не на количество хотстов, а на количество сайтов, которые на них хостятся. Еще раз внимательно перечитай то, что я тебе написал про количество хостов.

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

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

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

AB>Не думаю, но я не могу дискутировать на подобном уровне, когда магическая фраза "под NDA" не позволяет мне сомневаться в аргументе не сомневаясь в правдивости собеседника, а это, согласись, как-то не правильно.
Ок, тогда предлагаю завязать дискуссию.

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

AB>Ты же сейчас не хочешь сказать, что все проблемы за последнее время связаны с DNS? А если связаны, то решение есть очень простое — делегируйте зону себе и творите с ней все что хотите (уж найти стабильный DNS сервер, зоны которого перезагрузят практически по первому требованию, думаю не проблема). Вот только мне кажется, что TTL=900 установлен не из за DNS сервера.

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

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

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

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

AB>Я вообще панели стараюсь обходить стороной. Но если уж искать панель, то ISPManager например.
Ок, отдам програму плеска на рассмотрение

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

AB>Конечно, факапы случаются, но это должно быть чем-то из ряда вон выходящим и не приводить к отказу на критичных участках (или время простоя должно быть заранее известно и прописано в SLA).
Осталось еще сделать так, чтобы SLA само по себе предотвращало ураганы и прочий форсмажор.

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

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

Здравствуйте, Sheridan, Вы писали:
S>Очень грубо — кактотак:
S>

S>CVhostConfig *config = parcer->parce(vhost_config_file);
S>std::string root_dir = config->root_dir();
S>

S>Причем по производительности спорно, так как в твоем случае оно будет выбирать одну запись из миллиона, а в моем парсить текстовичок размером максимум в 20кб. Хотя возможно конечно из БД будет и быстрее, но я бы лично сначала проверил.
О, вот это уже прогресс. Ну то есть, по крайней мере тебе не очевидно, что там происходит.
Но фишка, видишь ли, в том, что для начала тебе нужно получить vhost_config_file. А где его взять? Сначала нужно прочитать файл со списком vhost-ов, чтобы найти там запись о расположении этого файла.