- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
ну так ведь оно даже лучше получается - если нет "аппаратного балансировщика", то он не откажет.
+1.
Программные решения могут себя годами показывать с лучшей стороны. Главное - предусмотреть их отказоустойчивость. (а с аппаратными это сложнее)
А что касается второй фразы... Мне привести примеры того, когда куча опытных авиаконструкторов проектировала ракеты носители, которые падали при запуске?
Значит они были недостаточно опытными, негодными авиаконструкторами.
Andreyka добавил 11.04.2011 в 14:56
Не очень понятно, причем тут нагрузка на СУБД, и какие есть альтернативы. Сейчас все работает на одном сервере, и MySQL с нагрузкой справляется, с учетом применения memcached и Sphinx.
Пойдет трафик - сразу станет понятно ;)
Andreyka добавил 11.04.2011 в 14:57
Есть ли интеграторы, способные предложить кластер за такие же деньги, что и ISPSystems?
Я ради прикола в свое время обращался в ряд московских системных интеграторов по поводу создания кластерного хостинга.
Все как один выставили себя ничегонезнающими жадными глупцами.
Andreyka добавил 11.04.2011 в 14:59
+1.
Программные решения могут себя годами показывать с лучшей стороны. Главное - предусмотреть их отказоустойчивость. (а с аппаратными это сложнее)
С аппаратными это проще. Два стораджа, два балансировщика, два pdu и так далее.
По железу вся эта цаца выйдет в 500k$, если брать нормальное железо, а не гуано.
Значит они были недостаточно опытными, негодными авиаконструкторами.
Королев. фон Браун. По чертежу взлетали ракеты только уже у бойцов рангом поменьше (и то - не всегда)... Когда технологический процесс был отлажен до мелочей.
Панель управления, насколько я понимаю, упростит и удешевит обслуживание кластера, или нет?
Чем, например? Она для решений типовых задач. Как Вы думаете - какие типовые задачи будут в Вашем случае?
Значит они были недостаточно опытными, негодными авиаконструкторами.
Andreyka добавил 11.04.2011 в 14:56
Пойдет трафик - сразу станет понятно ;)
Andreyka добавил 11.04.2011 в 14:57
...
Трафик и так есть, без memcached сервер СУБД справляется с трудом. А что, кластер MySQL типа master-slave намного менее производителен, чем отдельно стоящий MySQL-сервер?
Александр Фролов добавил 11.04.2011 в 16:23
...
Чем, например? Она для решений типовых задач. Как Вы думаете - какие типовые задачи будут в Вашем случае?
У меня нет опыта эксплуатации кластеров, но полагаю, что панель поможет контролировать состояние кластера, добавлять, заменять и реконфигурировать серверы. Ну и по мелочи - добавлять сайты, смотреть логи, управлять сетевым экраном, и т.п.
Хотя без поддержки панели для хостинга сайтов одного магазина можно и обойтись, но зачем? По мне лучше заплатить разработчикам, и если что, они помогут.
Если вы будете находиться в локальной среде, то это даст прирост к производительности, но увеличит траффик что в локальной среде не существенно.
А если внешние каналы, то надо предоставить быстрые доступы, иначе могут быть задержки существенные.
Трафик и так есть, без memcached сервер СУБД справляется с трудом. А что, кластер MySQL типа master-slave намного менее производителен, чем отдельно стоящий MySQL-сервер?
Александр Фролов добавил 11.04.2011 в 16:23
У меня нет опыта эксплуатации кластеров, но полагаю, что панель поможет контролировать состояние кластера, добавлять и реконфигурировать серверы. Ну и по мелочи - добавлять сайты, смотреть логи, управлять сетевым экраном, и т.п.
Хотя без поддержки панели для хостинга сайтов одного магазина можно и обойтись, но зачем? По мне лучше заплатить разработчикам, и если что, они помогут.
1. Если у вас много операций чтения (SELECT и т.п.), то может быть заметное увеличение производительности. И писать в такой связке (INSERT,UPDATE и т.п.) можно только на MASTER.
И их ещё нужно будет разделить через скрипты, либо доп. средства, чтобы случайно запись не пошла на slave.
2. Панель мало что может контроллировать. Добавление серверов и переконфигурирование тоже потребует ручного вмешательства.
Без администратора(ов) в случае с кластером вам вряд ли получится обойтись.
И вы учтите, что вы покупаете конкретную реализацию кластера и конкретный продукт, который работает в том виде, как это заложили разработчики. Если что-то потребуется поменять, то это будет не в ваших силах...
Himiko добавил 11.04.2011 в 16:29
С аппаратными это проще. Два стораджа, два балансировщика, два pdu и так далее.
По железу вся эта цаца выйдет в 500k$, если брать нормальное железо, а не гуано.
У кого есть лишние 500к$, тем возможно...
Но всё решаемо просто и дёшево при желании.
1. Если у вас много операций чтения (SELECT и т.п.), то может быть заметное увеличение производительности. И писать в такой связке (INSERT,UPDATE и т.п.) можно только на MASTER.
И их ещё нужно будет разделить через скрипты, либо доп. средства, чтобы случайно запись не пошла на slave.
2. Панель мало что может контроллировать. Добавление серверов и переконфигурирование тоже потребует ручного вмешательства.
Без администратора(ов) в случае с кластером вам вряд ли получится обойтись.
Да, про кластер MySQL мне еще нужно будет почитать в толстой книжке...
Например, что делать скриптам, если вылетает мастер. Насколько я понимаю, они должны будут использовать для работыы слейв, который автоматически должен стать мастером.
Насчет администраторов тут понятно, главное чтобы им не пришлось что-то делать сразу после выхода из строя сервера, и чтобы восстановительные работы можно было делать в спокойном режиме.
Да, про кластер MySQL мне еще нужно будет почитать в толстой книжке...
Например, что делать скриптам, если вылетает мастер. Насколько я понимаю, они должны будут использовать для работыы слейв, который автоматически должен стать мастером.
Вот эта автоматика тоже должна быть продумана. Да и вылеты бывают разные. Мастер может быть просто перегружен запросами, которые в итоге сможет выполнить, а запись пойдёт уже на Slave. Много чего продумывется.
Himiko добавил 11.04.2011 в 16:43
Насчет администраторов тут понятно, главное чтобы им не пришлось что-то делать сразу после выхода из строя сервера, и чтобы восстановительные работы можно было делать в спокойном режиме.
Если вы будете балансировать MySQL-запросы по 2-м серверам (без запаса производительности), то при выходе из строя одного сервера, второй ещё может не выдержать возросшей нагрузки.
P.S.: Даже у гугла бывают проблемы и всё на 100% предусмотреть не реально, имхо.
Вот эта автоматика тоже должна быть продумана. Да и вылеты бывают разные. Мастер может быть просто перегружен запросами, которые в итоге сможет выполнить, а запись пойдёт уже на Slave. Много чего продумывется.
Himiko добавил 11.04.2011 в 16:43
Если вы будете балансировать MySQL-запросы по 2-м серверам (без запаса производительности), то при выходе из строя одного сервера, второй ещё может не выдержать возросшей нагрузки.
P.S.: Даже у гугла бывают проблемы и всё на 100% предусмотреть не реально, имхо.
Велосипеды изобретать не надо. Суть отказоустойчивости в том, что два узла хостят один и тот же экземпляр сервиса, с одинаковыми настройками, путями и так далее. Еще у них общий сторедж и минимум один сетевой адрес, которые в каждый момент времени прицеплены только к одному узлу. Кластерная служба следит за состоянием сервиса и при failover событии прибивает службу на сбойнувшем узле (или прибивает весь узел в kernel panic), подключает общий сторедж к резервному узлу, поднимает на нем общий сетевой адрес, и запускает резервный экземпляр сервиса. Всё относительно просто.
Если мы говорим о балансировке нагрузки на серверы СУБД, то она осуществляется уже ПОСЛЕ обеспечения отказоустойчивости. Обычно это репликация данных на slave-сервера, к которым идут только запросы на чтение. Схема multi-master для данного интернет-магазина, по-моему, нецелесообразна. Слишком много управляющей логики получится. Хотя, дело хозяйское.
P.S. Да, кстати, в HA-кластере узлов может быть и больше двух. Просто с двума нагляднее всего.
общий сторедж
Какая тут нафиг отказоустойчивость... Сторедж тоже нифига не общий. Простейшая отказоустойчивость - drbd.