hostplus.ws: Вопрос к ярым сторонникам продуктов ISP. Как средствами ISP Manager реализовать назначение лимитов использования ЦПУ/ОЗУ/кол-во процессов для аккаунтов шаред хостинга, да ещё так, чтоб каждый клиент получал в формате графиков и таблиц с данными отчёты о РЕАЛЬНОМ использовании ресурсов сервера? Все носятся с так называемыми лимитами нагрузки, при том, что на базе ISP Manager её толком нельзя ни контролировать, ни ограничивать, ни тем более показывать всё в визуально читаемом виде для клиента, так чтоб ему стало понятно, когда и какие лимиты он превысил (причём в моём ТЗ он ничего превысить как раз не сможет, ТЗ предполагает фактически VPS хостинг, только для клиентов шаред хостинга), слабо такое реализовать, да ещё так, чтоб это было частью самой панели и делалось всё полностью через панель? А в cPanel/WHM это базовая ф-ция с недавних пор и таких примеров можно перечислить сотнями (причём, что важно, все эти примеры будут работать исключительно надёжно и стабильно, в отличии от ISP)
В след. релизе ISPmanager обещали поддержку bsd acct из коробки. Моментальное использование, конечно, не получится, но вот среднее за последние 5/15 минут -- легко.
Или ставьте CloudLinux, который всё это сам делает и к которому скоро появится isp-плагин. (кстати, у меня есть подозрения, что в Вашем ТЗ Вы как раз и говорили о нём).
Отреагировать на событие - да. Локализовать проблему - весьма вероятно. Решить - вероятно нет. И от количества администраторов в команде это не сильно зависит, увы (Вы даже пример выше привели).
Потому и нужны SLA, в которых оговариваются сроки прежде всего 1) и 2), да и 3) - тоже. Причем сроки 3) могут в разы разниться, по сравнению с 1) и 2), в зависимости от характера проблемы.
Не совсем понял, что Вы имеете ввиду. Я, вроде бы, оговорил сроки решения администраторской проблемы, а сколько времени из него они будут спать, а сколько -- локализовывать -- это уже их проблемы.
myhand: А это причем здесь? Речь ведь шла о гораздо более простой ситуации: скажем у Вас есть два совершенно независимых клиента, в разных ДЦ, разное оборудование. Вы оговорили одинаковое SLA для них - какова вероятность того, что проблемы у них возникнут одновременно и работа над одной будет мешать выполнению условий SLA для другого? Как это зависит от условий SLA? А если у Вас 10 клиентов? А если 100?
Если Вы дадите мне распределение времени решения проблемы, которая у каждого пользователя возникает в единичный промежуток времени, то я, наверно, смогу посчитать матожидание количества нарушенных SLA за указанный период в зависимости от количества пользователей. Я не считаю это распределение тривиальным, но можно попробовать взять что-нибудь с большим пиком в нуле и нормальным распределением с пиком в 30 минутах дальше.
Однако, есть мнение, что количество невыполненых SLA должно стремиться к нулю :)
Boris A Dolgov добавил 09.07.2011 в 21:49
Andreyka: Сервер можно подоготовить к школьному DDOS, поставить raid для защиты от краха жесткого диска. Да и дата-центры не умирают каждый месяц.
Сами поедете ставить RAID клиенту? :)
Можно ли просуммировать Ваше мнение как "мониторинг не нужен, потому что все его события предусматриваются заранее"? В принципе, логично, но сервера почему-то падают.
myhand: "Угадать" - не надо. Надо математику немного знать, после чего моделирование подобных ситуаций и конкретные оценки - для Вас не составят труда.
Предложите какую-нибудь тривиальную модель и посчитайте в её рамках вероятность этого события.
Disclaimer: я ни в коем случае не наезжаю на математику, а лишь хочу сказать, что для получения адекватных результатов нужно строить весьма сложные модели, а смысла в этом особого нет -- ведь мы не на атомной станции работаем.
myhand: "Логично" будет конкретное требование по "стабильности и надежности" - выраженное в xxx минутах/часах допустимого простоя yyy раз в месяц, скажем. А Ваша логика категорически не годится для перевода в конкретную денюжку: "стабильно и надежно" без цифирок - это просто маркетинг.
Мы сейчас договор составляем или обсуждаем фактический состав услуги администрирования? Клиент хочет именно стабильности и надежности, а получает их гарантию в устраиваевующем его объеме с помощью всяких SLA и гарантий аптайма.
Хотя, я считаю определение "отреагировать на падение сервера/сервиса в течении часа в любое время решением проблемы либо сообщением о том, что она находится на более высоком уровне (датацентра или оборудования)" достаточно строгим и понятным.
Andreyka: А я считаю, что если сервер настроить грамотно и заходить раз в месяц, то этого вполне достаточно, чтоб избежать разных внештатных ситуаций, падений и смсок.
Как сервер не настроишь, это не спасёт от падения датацентра, DDoS-атаки, краха жесткого диска или ещё чего-нибудь, что требует время на выяснение причин падения.
А с чего Вы решили, что человеку, который готовится заплатить 50-150$/мес (см. разведку цен в начале топика) - в действительности нужен этот самый "не превышающий часа" срок?
Проекту, которому действительно нужна оперативная поддержка - несложно заплатить куда больше... А если кто-то обещает всем подряд подобные сроки реакции за 20$ в месяц - это полностью проблемы обещающего.
Потому что я знаю сторонние фирмы, которые предоставляют указанный часовой срок реакции за эти деньги, и весьма логично, что если проект переезжает на сервер, то ему нужны стабильность и надёжность работы.
Boris A Dolgov добавил 09.07.2011 в 18:48
myhand:
Ну дык, наверно, не постоянно звонят. А если таки настолько достали, что каждую ночь звонят - наверно чересчур "одмин" переусердствовал с числом своих клиентов по тарифам "за еду", нет? И/или попросту выполняет работу плохо.
С риском, что администратор "заболеет" (например, его трамвай переедет - с летальным исходом) - это Вы верно заметили. Если хотите застраховаться от такого форс-мажора: оговаривайте например как-то документирование работы администратором, чтобы всегда, в принципе, можно было сменить работника.
Увы, предугадать количество звонков и их время почти невозможно - и из-за этого есть возможность не уложиться в указанный срок.
Именно поэтому я считаю, что при работе с частным админом нельзя оперировать понятием "реакция в течении часа 24/7", а можно оперировать только понятием "сделаю когда смогу, но постараюсь почти всегда примерно за час".
Boris A Dolgov добавил 09.07.2011 в 18:49
Raistlin: Boris A Dolgov, Вы набираете столько сколько берут, или вы набираете столько серверов, сколько можете вести в нормальном режиме?
Я не набираю серверы, потому что считаю, что мой сон и отдых стоят дороже, чем за него готовы заплатить большинство заказчиков :)
Ну это не может быть корректным, так как делает из системы помойку. Пускай панель собирает всё через спеки и rpmbuild, чтобы каждый бинарник в системе соответствовал своему пакету и yum не мог обновить/удалить какую-нибудь библиотеку, которая нужна, и тогда это будет похоже на правильный вариант, хоть и потеряет 50% смысла RPM.
hostplus.ws: 2) Если используются пакеты, то они должны быть только из надёжных репозитариев и тут две сложности:
а) у той же CentOS многие пакеты почти не обновляются годами (httpd,php,mysqld), а использовать 2.2.3 апач и 5.1.6 пхп просто идиотизм
По сути, собственный набор настроек для CustomBuild для опытного администратора не сильно отличается от создания спеки для рпмки (только при выходе новой версии / security patch'а) нужно поменять в ней пару строк.
Но даёт rpm даёт намного больше плюсов -- в случае выхода того же security patch'a, достаточно отредактировать один файл, щёлкнуть в веб-интерфейсике (или запустить sh-скрипт, проходящийся по всем серверам с yum update), и за пару минут на всех серверах будет уже обновленные и оттестированные бинарники.
hostplus.ws: б) если использовать сторонние пакеты, то есть опасность, что в них могут быть ошибки (или того хуже, бекдоры и прочее)
посему пакеты должны делать или разработчики самой панели (идеальный вариант) или сажать специального человека, который будет заранее их готовить, обновлять и т.д. что далеко не всем провайдерам будет удобно
Ну, эта проблема действительно есть и с ней ничего поделать нельзя.
TheJetHost.com: А обновление софта в cpanel идеальное (с точки зрения хостера (в отличает от ISP)), никогда даунов на этой почве не было.
Скорее нет -- ISP делегирует управление софтом пакетному менеджеру, и это значит, что
Обновление системы занимает считанные минуты
Обновление 100 систем занимет те же минуты
Можно собрать бинарники один раз, оттестировать их, и не возвращаться к странным проблемам
Пакетный менеджер сам следит за зависимостями, нужными версиями библиотек и конфликтами
А то, что есть в cPanel - превращает сервер в бардак, да и никак не однообразно - отдельный скриптик для пересборки exim, огромный скриптище для пересборки php, и так далее.
Но custombuild от DirectAdmin ещё большая помойка -- я слышал, на 32битных системах он иногда ломает python и yum вместе с ним.
Arsch: Как определить: нужно это админу или нет? Оформлять трудовой договор с паспортом, личным его присутствием?
А это уже достаточно сложный вопрос. Можно действительно делать договор, можно поспрашивать знакомых о проверенных людях.
Boris A Dolgov добавил 08.07.2011 в 22:41
myhand:
Почему это? 😮
Мониторинг - вообще-то делает компутир. Он железный и ему пофиг на "не может". А задачей администратора является, помимо прочего - реакция на события мониторинга в соответствии с SLA.
Да, Вы меня подловили. Под "мониторинг 24/7" я имел ввиду "обработку событий мониторинга 24/7 в не превышающий часа срок".
Вопрос к ярым сторонникам продуктов ISP. Как средствами ISP Manager реализовать назначение лимитов использования ЦПУ/ОЗУ/кол-во процессов для аккаунтов шаред хостинга, да ещё так, чтоб каждый клиент получал в формате графиков и таблиц с данными отчёты о РЕАЛЬНОМ использовании ресурсов сервера? Все носятся с так называемыми лимитами нагрузки, при том, что на базе ISP Manager её толком нельзя ни контролировать, ни ограничивать, ни тем более показывать всё в визуально читаемом виде для клиента, так чтоб ему стало понятно, когда и какие лимиты он превысил (причём в моём ТЗ он ничего превысить как раз не сможет, ТЗ предполагает фактически VPS хостинг, только для клиентов шаред хостинга), слабо такое реализовать, да ещё так, чтоб это было частью самой панели и делалось всё полностью через панель? А в cPanel/WHM это базовая ф-ция с недавних пор и таких примеров можно перечислить сотнями (причём, что важно, все эти примеры будут работать исключительно надёжно и стабильно, в отличии от ISP)
В след. релизе ISPmanager обещали поддержку bsd acct из коробки. Моментальное использование, конечно, не получится, но вот среднее за последние 5/15 минут -- легко.
Или ставьте CloudLinux, который всё это сам делает и к которому скоро появится isp-плагин. (кстати, у меня есть подозрения, что в Вашем ТЗ Вы как раз и говорили о нём).
Это достаточно строго и понятно - фуфло.
Отреагировать на событие - да. Локализовать проблему - весьма вероятно. Решить - вероятно нет. И от количества администраторов в команде это не сильно зависит, увы (Вы даже пример выше привели).
Потому и нужны SLA, в которых оговариваются сроки прежде всего 1) и 2), да и 3) - тоже. Причем сроки 3) могут в разы разниться, по сравнению с 1) и 2), в зависимости от характера проблемы.
Не совсем понял, что Вы имеете ввиду. Я, вроде бы, оговорил сроки решения администраторской проблемы, а сколько времени из него они будут спать, а сколько -- локализовывать -- это уже их проблемы.
А это причем здесь? Речь ведь шла о гораздо более простой ситуации: скажем у Вас есть два совершенно независимых клиента, в разных ДЦ, разное оборудование. Вы оговорили одинаковое SLA для них - какова вероятность того, что проблемы у них возникнут одновременно и работа над одной будет мешать выполнению условий SLA для другого? Как это зависит от условий SLA? А если у Вас 10 клиентов? А если 100?
Если Вы дадите мне распределение времени решения проблемы, которая у каждого пользователя возникает в единичный промежуток времени, то я, наверно, смогу посчитать матожидание количества нарушенных SLA за указанный период в зависимости от количества пользователей. Я не считаю это распределение тривиальным, но можно попробовать взять что-нибудь с большим пиком в нуле и нормальным распределением с пиком в 30 минутах дальше.
Однако, есть мнение, что количество невыполненых SLA должно стремиться к нулю :)
Boris A Dolgov добавил 09.07.2011 в 21:49
Сервер можно подоготовить к школьному DDOS, поставить raid для защиты от краха жесткого диска. Да и дата-центры не умирают каждый месяц.
Сами поедете ставить RAID клиенту? :)
Можно ли просуммировать Ваше мнение как "мониторинг не нужен, потому что все его события предусматриваются заранее"? В принципе, логично, но сервера почему-то падают.
"Угадать" - не надо. Надо математику немного знать, после чего моделирование подобных ситуаций и конкретные оценки - для Вас не составят труда.
Предложите какую-нибудь тривиальную модель и посчитайте в её рамках вероятность этого события.
Disclaimer: я ни в коем случае не наезжаю на математику, а лишь хочу сказать, что для получения адекватных результатов нужно строить весьма сложные модели, а смысла в этом особого нет -- ведь мы не на атомной станции работаем.
"Логично" будет конкретное требование по "стабильности и надежности" - выраженное в xxx минутах/часах допустимого простоя yyy раз в месяц, скажем. А Ваша логика категорически не годится для перевода в конкретную денюжку: "стабильно и надежно" без цифирок - это просто маркетинг.
Мы сейчас договор составляем или обсуждаем фактический состав услуги администрирования? Клиент хочет именно стабильности и надежности, а получает их гарантию в устраиваевующем его объеме с помощью всяких SLA и гарантий аптайма.
Хотя, я считаю определение "отреагировать на падение сервера/сервиса в течении часа в любое время решением проблемы либо сообщением о том, что она находится на более высоком уровне (датацентра или оборудования)" достаточно строгим и понятным.
А я считаю, что если сервер настроить грамотно и заходить раз в месяц, то этого вполне достаточно, чтоб избежать разных внештатных ситуаций, падений и смсок.
Как сервер не настроишь, это не спасёт от падения датацентра, DDoS-атаки, краха жесткого диска или ещё чего-нибудь, что требует время на выяснение причин падения.
А с чего Вы решили, что человеку, который готовится заплатить 50-150$/мес (см. разведку цен в начале топика) - в действительности нужен этот самый "не превышающий часа" срок?
Проекту, которому действительно нужна оперативная поддержка - несложно заплатить куда больше... А если кто-то обещает всем подряд подобные сроки реакции за 20$ в месяц - это полностью проблемы обещающего.
Потому что я знаю сторонние фирмы, которые предоставляют указанный часовой срок реакции за эти деньги, и весьма логично, что если проект переезжает на сервер, то ему нужны стабильность и надёжность работы.
Boris A Dolgov добавил 09.07.2011 в 18:48
Ну дык, наверно, не постоянно звонят. А если таки настолько достали, что каждую ночь звонят - наверно чересчур "одмин" переусердствовал с числом своих клиентов по тарифам "за еду", нет? И/или попросту выполняет работу плохо.
С риском, что администратор "заболеет" (например, его трамвай переедет - с летальным исходом) - это Вы верно заметили. Если хотите застраховаться от такого форс-мажора: оговаривайте например как-то документирование работы администратором, чтобы всегда, в принципе, можно было сменить работника.
Увы, предугадать количество звонков и их время почти невозможно - и из-за этого есть возможность не уложиться в указанный срок.
Именно поэтому я считаю, что при работе с частным админом нельзя оперировать понятием "реакция в течении часа 24/7", а можно оперировать только понятием "сделаю когда смогу, но постараюсь почти всегда примерно за час".
Boris A Dolgov добавил 09.07.2011 в 18:49
Boris A Dolgov, Вы набираете столько сколько берут, или вы набираете столько серверов, сколько можете вести в нормальном режиме?
Я не набираю серверы, потому что считаю, что мой сон и отдых стоят дороже, чем за него готовы заплатить большинство заказчиков :)
Boris A Dolgov, Ваши системы мониторинга до сих пор не умеют слать смс? Мои мне вообще звонят.
А Вы не спите / не болеете / не отдыхаете? :)
1) Установка из исходников
Ну это не может быть корректным, так как делает из системы помойку. Пускай панель собирает всё через спеки и rpmbuild, чтобы каждый бинарник в системе соответствовал своему пакету и yum не мог обновить/удалить какую-нибудь библиотеку, которая нужна, и тогда это будет похоже на правильный вариант, хоть и потеряет 50% смысла RPM.
2) Если используются пакеты, то они должны быть только из надёжных репозитариев и тут две сложности:
а) у той же CentOS многие пакеты почти не обновляются годами (httpd,php,mysqld), а использовать 2.2.3 апач и 5.1.6 пхп просто идиотизм
По сути, собственный набор настроек для CustomBuild для опытного администратора не сильно отличается от создания спеки для рпмки (только при выходе новой версии / security patch'а) нужно поменять в ней пару строк.
Но даёт rpm даёт намного больше плюсов -- в случае выхода того же security patch'a, достаточно отредактировать один файл, щёлкнуть в веб-интерфейсике (или запустить sh-скрипт, проходящийся по всем серверам с yum update), и за пару минут на всех серверах будет уже обновленные и оттестированные бинарники.
б) если использовать сторонние пакеты, то есть опасность, что в них могут быть ошибки (или того хуже, бекдоры и прочее)
посему пакеты должны делать или разработчики самой панели (идеальный вариант) или сажать специального человека, который будет заранее их готовить, обновлять и т.д. что далеко не всем провайдерам будет удобно
Ну, эта проблема действительно есть и с ней ничего поделать нельзя.
А обновление софта в cpanel идеальное (с точки зрения хостера (в отличает от ISP)), никогда даунов на этой почве не было.
Скорее нет -- ISP делегирует управление софтом пакетному менеджеру, и это значит, что
А то, что есть в cPanel - превращает сервер в бардак, да и никак не однообразно - отдельный скриптик для пересборки exim, огромный скриптище для пересборки php, и так далее.
Но custombuild от DirectAdmin ещё большая помойка -- я слышал, на 32битных системах он иногда ломает python и yum вместе с ним.
Как определить: нужно это админу или нет?
Оформлять трудовой договор с паспортом, личным его присутствием?
А это уже достаточно сложный вопрос. Можно действительно делать договор, можно поспрашивать знакомых о проверенных людях.
Boris A Dolgov добавил 08.07.2011 в 22:41
Почему это? 😮
Мониторинг - вообще-то делает компутир. Он железный и ему пофиг на "не может". А задачей администратора является, помимо прочего - реакция на события мониторинга в соответствии с SLA.
Да, Вы меня подловили. Под "мониторинг 24/7" я имел ввиду "обработку событий мониторинга 24/7 в не превышающий часа срок".