- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
myhand, попробуй добавить 15k виртхостов, при запуске будут явные тормоза
Попробовал как-то на ноутбуке. Более чем вполне шевелится (на <= 60k хостов задержки визуально нет). Сцылко на тест: /ru/forum/comment/5848378
Опять поем сказка про белого бычка? Вам уже поясняли как-то что не все плодят по лог-файлу на виртуальный хост. И не использует давно апач select для логов. И надо ничего вот так "хачить".
PS: Толи жана под Андрейкой периодически постит. Толи школьник какой :)
Чем Вы намажете увеличение стоимости вдвое, какой мифической "надежностью"? У нормального хостера простой сервера - порядка часа (и менее!) в год.
Верю, если у хостера как раз кластер. Или если не кластер (один сервер), тогда хостер владеет своим личным ДЦ, личным персоналом итд... Много ли у нас таких? 🍿 Не много. Если вы арендуйте сервер на площадке любого ДЦ, и не подписывали никакой SLA договор, в случае поломки простой будет ровно столько, сколько захочется персоналу этого ДЦ. Такое ощущение, что вы лично не сталкивались, а начитались маркетинговой шелухи каких-то "нормальных хостеров", которые обещают простоя не более часа в год :D
Кластер - получится. Хостинг - нет. Технически, хостинг - это и есть в первую очередь система управления хостингом. СУХ в просторечии.
Значит в этой теме мы обсуждаем кластер, а не хостинг. Меня спросили для чего мне нужен кластер, я ответил что для хостинга. Теперь меня убеждают что не получится хостинг. Хостинг уже получился и успешно работает. Цель — развиваться дальше, повышать надёжность и производительность. Если вам нечего рассказать про кластер, не нужно мне рассказывать про хостинг. :D
Потому, что с реальным хостингом Вы не сталкивались. Пара серверов это не хостинг и переносить Ваши хотелки по подобному опыту на что-то более масштабное - глупо.
Хотелка вполне адекватная. А вы никаких аргументов кроме как "глупо" привести не можете.
Ну а "вероятность" о которой Вы рассуждаете - весьма неаддитивно ведет себя в этом случае. И уж если речь о вероятности, что "ляжет все" - дык она как раз больше в кластерном варианте, а вовсе не наоборот.
А давайте допустим, что Вы действительно знакомы с теорвером и способны оценить вероятности. Вот Ваш будущий клиент спрашивает: а насколько меньше "чем когда используется один"? Что Вы ему ответите?
Слышите "клястер" - Вам кажется надежность "повалила"? На самом деле это даже близко не синонимы. Увы, диагноз bugsmoran подтвердился чуть менее чем полностью. "Хочу зашибись! Клястер!" Зачем - а хз.
Это вы опять пытайтесь склонить в сторону "у нормального хостера только 1 час простой в год". И поэтому кластер не нужен. Это Бред. Скорее всего вы понятия не имейте как организованы нормальные хостеры.
Оценивать вероятность того что всё сляжет, по количество серверов в кластере глупо, поэтому я не буду это делать. Но время простоя кластер может уменьшить.
hacccker добавил 04.12.2010 в 22:20
так ведь второй сервер будет простаивать :) ну не совсем - он будет занят работой по синхронизации, но запросы пользователей обрабатывать не будет.
Я понимаю, а хочется чтобы принимал, т.е. балансировал нагрузку.
hacccker добавил 04.12.2010 в 22:22
Выше ты писал, что такое тебе не очень подходит. Определяйся 🤣
Вы извините если я где-то ввёл в заблуждение :) Ну переспросите меня пару раз 😎
hacccker добавил 04.12.2010 в 22:27
Мне кажется, что на рынке хостинга дикая конкуренция, поэтому хостинг на одном-двух серверах вообще нет смысла проектировать. Следовательно, надо либо большие деньги привлекать, либо просто настроить бэкап и делать его почаще на резервный компьютер.
Конкуренция большая, да. Но вкидывать сразу большие деньги, ещё более глупо, чем проектировать хостинг на одном-двух серверах. И что значит вообще не смысла? Вы видите, что тут масса людей меня убеждают что кластер не нужен, а значит один клиент сидит на одном сервере. В таком случае никакой разницы нет, сколько серверов 1 или 100. Все зависит от количества клиентов.
Делали мы бэкап на отдельный.. нету большого смысла, проще использовать RAID. Куча времени и ресурсов уходило на архивирование и перекачку данных на другой компьютер.
тогда хостер владеет своим личным ДЦ, личным персоналом итд... Много ли у нас таких?
А есть другие? Ну не то, чтобы личный ДЦ. Но добраться до сервера саппорты могут за фиксированное время.
Такое ощущение, что вы лично не сталкивались, а начитались маркетинговой шелухи каких-то "нормальных хостеров"
Да не, я работал&работаю у таких :) Да и в "чужом" ДЦ при размещении таких проектов (а это порядка стойки) - никаких проблем с реакцией инженеров не возникает. Кому охота терять "толстого" клиента?
Хотелка вполне адекватная. А вы никаких аргументов кроме как "глупо" привести не можете.
Дорого. Лень перечислять заново все остальное, что было всказано еще по этому поводу мной и не мной.
Скорее всего вы понятия не имейте как организованы нормальные хостеры.
Извините, я не сторонник солипсизма. Сижу на жопе в офисе, работаю на хостинге администратором - стало быть так оно и есть. Мне это не снится. И стало быть знаю как он устроен.
Оценивать вероятность того что всё сляжет, по количество серверов в кластере глупо, поэтому я не буду это делать. Но время простоя кластер может уменьшить.
Делать какие-либо количественные оценки - отнюдь никогда не глупо. Глупо их не делать. Математика и экономика пока никому еще не навредили ;)
Делали мы бэкап на отдельный.. нету большого смысла, проще использовать RAID. Куча времени и ресурсов уходило на архивирование и перекачку данных на другой компьютер.
Извините, бекап и райд предназначены для (мягко говоря) - разных целей. Почти перпендикулярных. Вы не предоставляете пользователям вирт.хостинга штатно услугу бекапа (райд это не заменит)?
А есть другие? Ну не то, чтобы личный ДЦ. Но добраться до сервера саппорты могут за фиксированное время.
Ещё раз: если саппорт хостера === инженеры в ДЦ. Если у вас это именно так — прекрасно. Я например, не имею лично доступа к своему оборудованию. Оно далеко...
Да не, я работал&работаю у таких :) Да и в "чужом" ДЦ при размещении таких проектов (а это порядка стойки) - никаких проблем с реакцией инженеров не возникает. Кому охота терять "толстого" клиента?
Что значит проблем? У меня тоже проблем не возникает, но с момента реакции до устранения проблемы проходит какое-то время.. а там в ДЦ у инженеров свой график.. решал вопрос, попал в пересменку, пришел другой инженер — объясняешь ему всё сначала.. время идет... Аналогично плановые работы инженеры в не рабочее время не выполняют, тот же винт сменить — только в рабочее время... Если ДЦ далеко сюда же прибавляем сдвиг в часовом поясе... Фантастику рассказываю? Нет, это реальность. А спич о том, что "саппорт за час решает любую проблему" — это как раз сказка...
Дорого. Лень перечислять заново все остальное, что было всказано еще по этому поводу мной и не мной.
Дорого организация или дорого потом услуга для конечно пользователя?
Делать какие-либо количественные оценки - отнюдь никогда не глупо. Глупо их не делать. Математика и экономика пока никому еще не навредили ;)
Ну так и оцените по количеству серверов в кластере, вероятность отказа кластера 🍿 А я поулыбаюсь, и расскажу что все эти расчеты бред, потому что.... и тысячу причин найду :)
Andreyka,
netwind, это мои собственные наработки и они являются моим ноухау, так что не покажу, извини.
в чем проблема? это ведь маленький кирпичик сложной системы. мало кто сможет его правильно применить.
либо его просто нет.
либо он содержит ужасающие ошибки и не готов обслуживать произвольные запросы на шареде.
Извините, бекап и райд предназначены для (мягко говоря) - разных целей. Почти перпендикулярных. Вы не предоставляете пользователям вирт.хостинга штатно услугу бекапа (райд это не заменит)?
Предоставляю, но не делаю бекапа всех пользовательских данных автоматом.
Предоставляю, но не делаю бекапа всех пользовательских данных автоматом.
Любопытно было бы взглянуть на Вашу оферту...
Аналогично плановые работы инженеры в не рабочее время не выполняют, тот же винт сменить — только в рабочее время...
Ну дак это персонально Ваши проблемы. Так выбрали ДЦ. И размещаетсь там, скорее всего через вторые руки, как минимум.
Дорого организация или дорого потом услуга для конечно пользователя?
И первое и второе.
Делали мы бэкап на отдельный.. нету большого смысла, проще использовать RAID. Куча времени и ресурсов уходило на архивирование и перекачку данных на другой компьютер.
Вы не совсем меня правильно поняли. Я не имел ввиду бэкап в обычном смысле - это совершенно отдельное действие и к кластеру отношения не имеет.
Вы хотите получить отказоустойчивость. Это значит, что какие-то ресурсы выделяются под обеспечение избыточности. То есть у Вас есть три сервера, но на них используется 60% ресурсов, остальные резервируются в предположении что один из серверов сляжет и сайты переедут на оставшиеся. Соответственно каждый сайт должен иметь копию базы и файлов на другом сервере. Такие копии можно сделать для mysql блокированием таблиц и rsync (хотя тут надо не забыть проверять не только размер и даты), для файлов тоже rsync но в ускоренном варианте.
Я не уверен, что такая схема сработает для очень больших объёмов достаточно быстро, но во всяком случае, в отличии от бэкапа, перенос сайта на резервный сервер будет происходить очень быстро - время уйдёт на копирование конфигурации и добавление виртуальных хостов в апач. Бэкапить , кстати, возможно будет проще с резервных копий - они не задействованы и их не нужно дополнительно блокировать.
Схема не совсем реализует отказоустойчивый кластер, она не делает мгновенной копии всего сервера, скорее это продвинутый бэкап. Но скорость восстановления после падения будет очень большой.
Любопытно было бы взглянуть на Вашу оферту...
Что именно вам там любопытно? Не в одном договоре публичной оферты я ещё не видел пункта про резервные копии 🍿
Ну дак это персонально Ваши проблемы. Так выбрали ДЦ. И размещаетсь там, скорее всего через вторые руки, как минимум.
Понимайте, без SLA договора, и Ваш ДЦ который выбрали Вы, может однажды стать Вашей персональной проблемой.
И первое и второе.
Я допускаю, что стоимость может возрасти линейно, в зависимости от количества серверов в кластере.
hacccker добавил 05.12.2010 в 00:48
Вы не совсем меня правильно поняли. Я не имел ввиду бэкап в обычном смысле - это совершенно отдельное действие и к кластеру отношения не имеет.
Вы хотите получить отказоустойчивость. Это значит, что какие-то ресурсы выделяются под обеспечение избыточности. То есть у Вас есть три сервера, но на них используется 60% ресурсов, остальные резервируются в предположении что один из серверов сляжет и сайты переедут на оставшиеся. Соответственно каждый сайт должен иметь копию базы и файлов на другом сервере. Такие копии можно сделать для mysql блокированием таблиц и rsync (хотя тут надо не забыть проверять не только размер и даты), для файлов тоже rsync но в ускоренном варианте.
Я не уверен, что такая схема сработает для очень больших объёмов достаточно быстро, но во всяком случае, в отличии от бэкапа, перенос сайта на резервный сервер будет происходить очень быстро - время уйдёт на копирование конфигурации и добавление виртуальных хостов в апач. Бэкапить , кстати, возможно будет проще с резервных копий - они не задействованы и их не нужно дополнительно блокировать.
Схема не совсем реализует отказоустойчивый кластер, она не делает мгновенной копии всего сервера, скорее это продвинутый бэкап. Но скорость восстановления после падения будет очень большой.
Примерно так и планируется.. В случае с DRDB как раз слейм постоянно синхронизируется с мастером. Если мастер упал, на слейве ставятся такие же настройки как были на мастере, и слейв становится мастером... Это несомненно решение, и возможно к нему и буду склонятся. Пока просто интересно рассмотреть ещё варианты, я имею ввиду про балансировку нагрузки на лету.
Что именно вам там любопытно? Не в одном договоре публичной оферты я ещё не видел пункта про резервные копии 🍿
Как правило есть пункт 1) как долго хранится информация абонента 2) технические стандарты предоставления услуг (грубо говоря - как часто делаются бекапы, как долго хранятся и как быстро могут быть предоставлены).
Мне неинтересно заниматься рекламой. Возьмите (ткните пальцем) любую крупную хостинговую компанию, имеющую лицензию на оказание телематических услуг. Посмотрите оферту и прилагаемые к ней документы - там скорее всего будут варианты пунктов 1)-2).
Понимайте, без SLA договора, и Ваш ДЦ который выбрали Вы, может однажды стать Вашей персональной проблемой.
Если у Вас стойка и более - Вы просто не будете заморачиваться до "без SLA".
Вообще, интересно рассмотреть конкретные примеры "проблем" и варианты Ваших решений (без клястера). Ваша оценка возможного даунтайма.
Я допускаю, что стоимость может возрасти линейно, в зависимости от количества серверов в кластере.
Ув. hacccker, ежели у Вас стоимость будет расти линейно - разумно такую генияльную идею нафиг сразу выкинуть, верно? Я, конечно, допускаю, что Вы оговорились.