hostplus.ws: Для меня показателем надёжности (успешность тут не причём) является тот факт, что разработчики отвечают за вопросы установки и обновления серверного ПО,
Это глупо. Разработчики панели должны разрабатывать панель, а не серверное ПО.
hostplus.ws: на сервере очень важно, чтоб всё ПО гармонировало между собой и с панелью управления, а когда ПО ставится из сторонних репозитариев, нужно потом плясать с бубном (иногда продолжительное время) дабы отстроить все цепочки работы (правда если плевать на стабильность, безопасность и т.д. то можно ставить всё тупо из RPM, скаченных из каких угодно репозитариев, как-то (ближе к стадии никак) разумеется это всё будет работать)
п.с. про оценку опыта и умственных способностей админа на основании великого умения последнего ставить ПО из RPM насмешили до слёз
Ну, вижу, Вы не считаете установку RPM тривиальной задачей ;)
RHEL как-то живёт с сотнями тысяч (если не миллионами) клиентов, и все как-то пользуются стандартными собранными RPM. И все устраивает!
hostplus.ws: 1) ISP Manager в коробочном (дефолтном, по умолчанию и т.д.) варианте позволяет выбрать между MySQL 5.0 и MySQL 5.1, да ещё так, чтоб всё ставилось и обновлялось во первых в 2 клика а во вторых полностью из своих пакетов (или исходников), не используя репозитарий ОС? А можно в два клика выполнить миграцию с 5.0 на 5.1 MySQLd? А ведь как нужно и удобно это всё...
Позволяет -- просто возьмите RPM с офсайта и поставьте их.
hostplus.ws: 2) По аналогии выбор между РАЗНЫМИ демонами FTP, DNS, POP3(IMAP4), снова ничего подобного нет там
cPanel уже начала поддерживать exim, sendmail и postfix? :) Вот это даже из коробки работает на всех ос.
hostplus.ws: 3) Тонкая и быстрая (я молчу про удобная) настройка ВСЕХ демонов (особенно актуально для Exim), а что в ISP, ничего и близко нету...а ведь как удобно, когда можно в два клика задать лимиты на отправку писем с одного домена (помогает от СПАМеров неплохо), указать колаут и т.д. и т.д.
Вы не поверите, но и лимиты на отправку писем (правда, на пользователя) там настраиваются
hostplus.ws: 4) Про миграцию и восстановление после сбоев уже тут писалось, повторяться не буду
Ну, чего нет -- того нет 🤪
hostplus.ws: 5) Про установку и обновление Apache+php я уже писал ранее (выбор всех основных MPM, включая мой любимый MPM Event (а что будет по умолчанию в ISP под CentOS? 2.2.3 апач и 5.1.6 пхп с никакой оптимизацией, с кучей ненужных модулей и отсутствием нужных) и suPHP (вместо кривых CGI и FastCGI у ISP, причём под CentOS будет только DSO и хоть убейся (повторюсь, речь идёт про коробочный вариант, сторонние пакеты уже обсуждались и все их минусы)
Выделенное жирным -- неправда. Fastcgi -- да, нет из коробки, решается, опять же, втыканием одной rpm. Из доверенного репозитория epel или rpmforge, которым пользуются ну уж не меньше, чем сипанелью, и которые панель подключает при установке. cgi тоже никто не отменял.
Я не понимаю -- для Вас показателем успешности панели является то, насколько мало мозгов должно быть у её админа, чтобы сделать хостинг на ней? Если так, то это скорее играет в минус панели, чем в плюс для конечных клиентов;). Потому что в случае любой нестандартной проблемы Вам всё равно придётся лезть в SSH и править конфиги/переустанавливать ПО. И ещё не ясно, как человеку, который способен делать это, проще ставить набор требуемого софт -- кликая мышкой по easyapache, или командой rpm -ihv http://my.repo.ru/myrepo-release.rpm && yum update -y
Да и отделите уже претензии к RHEL5 (вышедшему более 4 лет назад, когда cPanel не имела даже намёка на русский перевод, на VPS с 512мб памяти постоянно падала в OOM, а vps с ISP спокойно жил на 256, и easyapache был альфой, которая любила всё портить).
А вот с вами я как раз согласен. Действительно падает. Если в течение б-м продолжительного времени между серверами отсутствовала связь, и в каждый из них за это время успела прийти кипа запросов с использованием автоинкремента. Именно поэтому выше встречается слово "пытаться". Но ведь мы обсуждаем не промышленное отказоустойчивое решение для hiload систем, а сферический велосипед с квадратными колесами в вакууме для временно малобюджетной защиты мелких коробочных сайтов от DDoS?
Там, увы, не только с ai проблемы -- для её обхода, вроде бы, они придумали чётность этих значений инкремента -- там ещё могут быть проблемы со временем и с запросами, которые влияют на выполнение последующих.
Но для совсем несерьезных баз должно быть незаметно, да.
hostplus.ws: Во первых краеугольный камень тут - надёжность и стабильность, во вторых я упор делал в ТЗ именно на *коробочный* вариант, на любой панели можно скрутить какой угодно велосипед, вопрос в том, на сколько далеко можно уехать на этом велосипеде и на сколько этот процесс будет комфортным. Если правда в будущем добавят, что же, это будет не более чем очередной попыткой догнать лидера рынка, причём как всегда уверен в крайне кривой форме и нулевой стабильностью, сопровождаемой кучей багов и головной болью.
CL - вполне себе коробочный вариант. Как минимум два человека, которые тут отписались, точно используют его с ISPmanager, а может быть - больше.
К слову, ISPmanager научился распознавать CL в /etc/redhat-version на пару месяцев раньше cPanel :)
Boris A Dolgov добавил 10.07.2011 в 00:58
dlyanachalas: Из топега сделал вывод, что cPanel удобен хостерам, вот они его и ставят. А ISPManager удобен клиентам (это из личного опыта, и в опросе видно), но их мнение никого не волнует.
Осюда простой вопрос - а нельзя ставить сразу две панели? Одну - админам, а другую - для пользователей. Или тут всё в цену упирается? Вы же, господа хостеры, всё время твердите про нищесбродство клиентов. Так покажите пример хорошей траты денег на пользу дела ;)
На один сервер - нельзя. Но можно держать несколько серверов с разными панелями. Как выше написал KM.UA, это заставляет помнить в два раза больше особенностей панелек, тратить в два раза больше времени на обучение, развертывание, автоматизацию и интеграцию. И ещё иметь в два раза больше NS-серверов :)
myhand: На мой взгляд разумно 1) оповестить клиентов в срок, что проблемой занимаются 2) определили ее источник и оценили приблизительные сроки решения. Эти этапы разумно жестко ограничивать во времени.
А обещать заранее, что починят все что угодно в 1 час - только болтуны могут. Максимальные сроки решения проблем, конечно, можно попытаться оговорить и ограничить. Да и то, только в случае ограниченного списка нештатных ситуаций (что Вы будете делать, когда райд накроется, а клиент не позаботился о бекапе на отдельный дисковый массив, несмотря на указанные ему риски?). И эти сроки в разы будут больше часа.
Клиенту нужно не знать, что кто-то работает, а решение проблемы (можете называть это маркетингом, но это действительно так).
В принципе, мы говорим примерно одно и то же -- только Вы называете это тремя этапами и разновидностями проблем, а я -- сроком решения проблемы, зависящей от админа и решением проблемы, от него не зависящей.
Наверно, при составлении договора Ваша точка зрения более правильная.
Не могу отказать Вам в праве забрать свое нормальное распределение :) Дисперсию можно поставить побольше - порядка часа и больше. Можно поточнее оценить из своего опыта. В общем, ничего сложного не должно быть - любой толковый студент сварганит более-менее разумную модельку для простой оценки.
Проинтегрировал Ваше нормальное распределение ;) При SLA в 3 часа, мат.ожидании в 2 и дисперсии в час получается 0.32Up нарушений SLA в год, где U - количетво пользователей, а p - мат. ожидание количества срабатываний мониторинга в сутки. Забавно получается -- при 10 пользователях и срабатывании раз в 3 дня получается всего 1 нарушение SLA в год.
Можно считать, что эта прикидка была правильной для фирмы администрирования.
Теперь посмотрим на администратора, который спит 6 часов в день. Это значит, что 1/4 суток он не отвечает на события мониторинга, и они нарушают SLA, и тогда количество его нарушений равно U*(1/4)*p*365! Что почти в 300 раз больше и за год сделает 300 нарушений - почти по нарушению в сутки! Получается, что фрилансер, который спит 6 часов в день, в триста раз хуже компании из двух админов, которые покрывают всё время? :)
Я понимаю, что вторая модель натянута и из-за разбужения смсками совсем неправильная, но пока очевидного способа добавить выносливость отдельного человека не вижу. Разве что посчитать, что если четыре события подряд произошли с разницей в 6 часов друг с другом, то админ не высыпается и срывает последний SLA -- в этом случае получается, что один админ в пять раз хуже команды.
Есть мнение, а есть реальный мир - в котором даже людей убивают, несмотря на законы, которыми это четко воспрещается :(
Полносвязная репликация подразумевает что каждый ноявляется мастером и слейвом одновременно.
для 2-х машин работает точно, дописали ли для большего - не уверен, в планах было.
И часто ломает данные, если серверы не подключены друг к другу прямым шнурком :) Тоже лично сталкивался, так что для гео-нужд это не работает.
Andreyka: Не поверишь - DA может работать с софтом точно так же как и ispmanager :)
Я даже верю, что ISPmanager может работать с софтом из исходников :) Вопрос в том, что разработчики считают стандартной политикой и для чего предоставляют инструменты из коробки и техподдержку.
Для меня показателем надёжности (успешность тут не причём) является тот факт, что разработчики отвечают за вопросы установки и обновления серверного ПО,
Это глупо. Разработчики панели должны разрабатывать панель, а не серверное ПО.
на сервере очень важно, чтоб всё ПО гармонировало между собой и с панелью управления, а когда ПО ставится из сторонних репозитариев, нужно потом плясать с бубном (иногда продолжительное время) дабы отстроить все цепочки работы (правда если плевать на стабильность, безопасность и т.д. то можно ставить всё тупо из RPM, скаченных из каких угодно репозитариев, как-то (ближе к стадии никак) разумеется это всё будет работать)
п.с. про оценку опыта и умственных способностей админа на основании великого умения последнего ставить ПО из RPM насмешили до слёз
Ну, вижу, Вы не считаете установку RPM тривиальной задачей ;)
RHEL как-то живёт с сотнями тысяч (если не миллионами) клиентов, и все как-то пользуются стандартными собранными RPM. И все устраивает!
1) ISP Manager в коробочном (дефолтном, по умолчанию и т.д.) варианте позволяет выбрать между MySQL 5.0 и MySQL 5.1, да ещё так, чтоб всё ставилось и обновлялось во первых в 2 клика а во вторых полностью из своих пакетов (или исходников), не используя репозитарий ОС? А можно в два клика выполнить миграцию с 5.0 на 5.1 MySQLd? А ведь как нужно и удобно это всё...
Позволяет -- просто возьмите RPM с офсайта и поставьте их.
2) По аналогии выбор между РАЗНЫМИ демонами FTP, DNS, POP3(IMAP4), снова ничего подобного нет там
cPanel уже начала поддерживать exim, sendmail и postfix? :) Вот это даже из коробки работает на всех ос.
3) Тонкая и быстрая (я молчу про удобная) настройка ВСЕХ демонов (особенно актуально для Exim), а что в ISP, ничего и близко нету...а ведь как удобно, когда можно в два клика задать лимиты на отправку писем с одного домена (помогает от СПАМеров неплохо), указать колаут и т.д. и т.д.
Вы не поверите, но и лимиты на отправку писем (правда, на пользователя) там настраиваются
4) Про миграцию и восстановление после сбоев уже тут писалось, повторяться не буду
Ну, чего нет -- того нет 🤪
5) Про установку и обновление Apache+php я уже писал ранее (выбор всех основных MPM, включая мой любимый MPM Event (а что будет по умолчанию в ISP под CentOS? 2.2.3 апач и 5.1.6 пхп с никакой оптимизацией, с кучей ненужных модулей и отсутствием нужных) и suPHP (вместо кривых CGI и FastCGI у ISP, причём под CentOS будет только DSO и хоть убейся (повторюсь, речь идёт про коробочный вариант, сторонние пакеты уже обсуждались и все их минусы)
Выделенное жирным -- неправда. Fastcgi -- да, нет из коробки, решается, опять же, втыканием одной rpm. Из доверенного репозитория epel или rpmforge, которым пользуются ну уж не меньше, чем сипанелью, и которые панель подключает при установке. cgi тоже никто не отменял.
Я не понимаю -- для Вас показателем успешности панели является то, насколько мало мозгов должно быть у её админа, чтобы сделать хостинг на ней? Если так, то это скорее играет в минус панели, чем в плюс для конечных клиентов;). Потому что в случае любой нестандартной проблемы Вам всё равно придётся лезть в SSH и править конфиги/переустанавливать ПО. И ещё не ясно, как человеку, который способен делать это, проще ставить набор требуемого софт -- кликая мышкой по easyapache, или командой rpm -ihv http://my.repo.ru/myrepo-release.rpm && yum update -y
Да и отделите уже претензии к RHEL5 (вышедшему более 4 лет назад, когда cPanel не имела даже намёка на русский перевод, на VPS с 512мб памяти постоянно падала в OOM, а vps с ISP спокойно жил на 256, и easyapache был альфой, которая любила всё портить).
Не засоряйте интернет.
Спасибо за Ваш ответ.
Можете пожалуйста еще привести пример конфигурации этих модулей.
Какие заголовки нужно отправить с php скрипта?
Я не пользовался ими, так как делаю так, как говорит Andreyka :)
У них есть README, там есть примеры.
Да. Это достигается двумя модулями:
http://mdounin.ru/hg/ngx_http_compose_filter_module/
http://mdounin.ru/hg/ngx_http_bytes_filter_module/
А вот с вами я как раз согласен. Действительно падает. Если в течение б-м продолжительного времени между серверами отсутствовала связь, и в каждый из них за это время успела прийти кипа запросов с использованием автоинкремента. Именно поэтому выше встречается слово "пытаться". Но ведь мы обсуждаем не промышленное отказоустойчивое решение для hiload систем, а сферический велосипед с квадратными колесами в вакууме для временно малобюджетной защиты мелких коробочных сайтов от DDoS?
Там, увы, не только с ai проблемы -- для её обхода, вроде бы, они придумали чётность этих значений инкремента -- там ещё могут быть проблемы со временем и с запросами, которые влияют на выполнение последующих.
Но для совсем несерьезных баз должно быть незаметно, да.
Во первых краеугольный камень тут - надёжность и стабильность, во вторых я упор делал в ТЗ именно на *коробочный* вариант, на любой панели можно скрутить какой угодно велосипед, вопрос в том, на сколько далеко можно уехать на этом велосипеде и на сколько этот процесс будет комфортным. Если правда в будущем добавят, что же, это будет не более чем очередной попыткой догнать лидера рынка, причём как всегда уверен в крайне кривой форме и нулевой стабильностью, сопровождаемой кучей багов и головной болью.
CL - вполне себе коробочный вариант. Как минимум два человека, которые тут отписались, точно используют его с ISPmanager, а может быть - больше.
К слову, ISPmanager научился распознавать CL в /etc/redhat-version на пару месяцев раньше cPanel :)
Boris A Dolgov добавил 10.07.2011 в 00:58
Из топега сделал вывод, что cPanel удобен хостерам, вот они его и ставят. А ISPManager удобен клиентам (это из личного опыта, и в опросе видно), но их мнение никого не волнует.
Осюда простой вопрос - а нельзя ставить сразу две панели? Одну - админам, а другую - для пользователей.
Или тут всё в цену упирается? Вы же, господа хостеры, всё время твердите про нищесбродство клиентов. Так покажите пример хорошей траты денег на пользу дела ;)
На один сервер - нельзя. Но можно держать несколько серверов с разными панелями. Как выше написал KM.UA, это заставляет помнить в два раза больше особенностей панелек, тратить в два раза больше времени на обучение, развертывание, автоматизацию и интеграцию. И ещё иметь в два раза больше NS-серверов :)
На мой взгляд разумно 1) оповестить клиентов в срок, что проблемой занимаются 2) определили ее источник и оценили приблизительные сроки решения. Эти этапы разумно жестко ограничивать во времени.
А обещать заранее, что починят все что угодно в 1 час - только болтуны могут. Максимальные сроки решения проблем, конечно, можно попытаться оговорить и ограничить. Да и то, только в случае ограниченного списка нештатных ситуаций (что Вы будете делать, когда райд накроется, а клиент не позаботился о бекапе на отдельный дисковый массив, несмотря на указанные ему риски?). И эти сроки в разы будут больше часа.
Клиенту нужно не знать, что кто-то работает, а решение проблемы (можете называть это маркетингом, но это действительно так).
В принципе, мы говорим примерно одно и то же -- только Вы называете это тремя этапами и разновидностями проблем, а я -- сроком решения проблемы, зависящей от админа и решением проблемы, от него не зависящей.
Наверно, при составлении договора Ваша точка зрения более правильная.
Проинтегрировал Ваше нормальное распределение ;) При SLA в 3 часа, мат.ожидании в 2 и дисперсии в час получается 0.32Up нарушений SLA в год, где U - количетво пользователей, а p - мат. ожидание количества срабатываний мониторинга в сутки. Забавно получается -- при 10 пользователях и срабатывании раз в 3 дня получается всего 1 нарушение SLA в год.
Можно считать, что эта прикидка была правильной для фирмы администрирования.
Теперь посмотрим на администратора, который спит 6 часов в день. Это значит, что 1/4 суток он не отвечает на события мониторинга, и они нарушают SLA, и тогда количество его нарушений равно U*(1/4)*p*365! Что почти в 300 раз больше и за год сделает 300 нарушений - почти по нарушению в сутки! Получается, что фрилансер, который спит 6 часов в день, в триста раз хуже компании из двух админов, которые покрывают всё время? :)
Я понимаю, что вторая модель натянута и из-за разбужения смсками совсем неправильная, но пока очевидного способа добавить выносливость отдельного человека не вижу. Разве что посчитать, что если четыре события подряд произошли с разницей в 6 часов друг с другом, то админ не высыпается и срывает последний SLA -- в этом случае получается, что один админ в пять раз хуже команды.
😮
Полносвязная репликация подразумевает что каждый ноявляется мастером и слейвом одновременно.
для 2-х машин работает точно, дописали ли для большего - не уверен, в планах было.
И часто ломает данные, если серверы не подключены друг к другу прямым шнурком :) Тоже лично сталкивался, так что для гео-нужд это не работает.
Не поверишь - DA может работать с софтом точно так же как и ispmanager :)
Я даже верю, что ISPmanager может работать с софтом из исходников :) Вопрос в том, что разработчики считают стандартной политикой и для чего предоставляют инструменты из коробки и техподдержку.