- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева
День добрый,
Добрый :)
Я заметил вы любите все рассматривать в вакууме, это как 4 MB/s на технологии 3 G , работать будет только с том случае если вокруг не будет другой материи :))))
Я бы не сказал, что часто так делаю :) хотя, возможно, просто не замечаю.
Я частично согласен с вами , если человеку нужно много гигагерц и гигабайт памяти он купит сове решение за много тысяч долларов, может быть даже и у нас :))) А я говорю о хостинге , обратите внимание на это и сделайте акцент на этом!
Но важно понимать различие хостинга и подобного решения. Грубо говоря, если Вы разносите тариф за 5$ на 10 серверов, то он не может стоить меньше 50$ (можно сказать, что из 5$ только 2.5$ уходит на сервера, а остальное - на саппорт, бумажки и прочее, но я отвечу, что для такого решения на саппорт придётся тратить намного больше половины, так что прикидка работает). И тут включается разделение клиентов на категории:
1) Хостят домашнюю страничку с фотографиями котиков или рабочую страничку с контактами фирмы. Как правило, не хотят тратить на хостинг в 10 раз больше, если можно потратить столько, и (рассмотрим вакуумную ситуацию :-P) если бы Вы были единственным хостером и он пошёл за хостингом на Ваш сайт, то он купил бы обычный шаред, а не кластерный.
2) Хостят кучу клиентских сайтов, или кучу сапосайтов, и что-то понимают в хостинге. Ну, им без панели будет совсем туго - им важно делать всё самим и не ждать поддержку хостера. Да и саппортить их замучаетесь - то домен добавить, то поддомен удалить, то тариф измемнить.
3) Владельцы больших прибыльних проектов. Как правило, не готовы мириться с "соседями", приходящими из мира шареда, так как им нужно своё решение. Скорее всего, в той же гипотетической ситуации купят у Вас несколько серверов и администрирование.
Если Вы чётко можете описать категорию людей, которым это нужно и не можете придумать причин, по которым им это не нужно, и знаете примеры людей из этой категории то, без сомнения, делать это нужно.
P.S.
Точно так же как например есть почти работающий DNS кластер у cpanel... он как бы работает.... да .... пока у вас доменов до тысячи....
Даже с их вторым более легким dns-сервером?
Так я про то и говорю, что изначально речь шла про то, что продавать кластер без морды. Это настолько неудобно как для пользователей, так и для автоматизации их заведения, что лучше уж прикрепить что-нибудь. Если есть возможность написать свое - отлично, но если нет, то вот можно прикрутить вышеописанные две панели.
А что там писать, если так разобраться? :) Меню из 10 функций по работе с доменами и почтой, остальное все бекенд.
Romka_Kharkov добавил 23.01.2011 в 03:23
Кластеры обычно создаются под определенные задачи, в зависимости от задачи и реализация кластерного решения разная. Потому мне вовсе непонятен смысл Вашей темы. Обычным пользователям это однозначно не интересно (в виде дороговоизны решения), тем более, если нужно отказываться от панели управления (многие и с панелькой не способны совладать и им даже в этом вопросе нужна помощь).
Разговор не о чем, в общем.
Ну конечно вы уже успели сказать о том как у меня дорого, хотя я еще ни одной цифры не привел, не позорьтесь. (r/o)
Romka_Kharkov добавил 23.01.2011 в 03:32
1) Хостят домашнюю страничку с фотографиями котиков или рабочую страничку с контактами фирмы. Как правило, не хотят тратить на хостинг в 10 раз больше, если можно потратить столько, и (рассмотрим вакуумную ситуацию :-P) если бы Вы были единственным хостером и он пошёл за хостингом на Ваш сайт, то он купил бы обычный шаред, а не кластерный.
2) Хостят кучу клиентских сайтов, или кучу сапосайтов, и что-то понимают в хостинге. Ну, им без панели будет совсем туго - им важно делать всё самим и не ждать поддержку хостера. Да и саппортить их замучаетесь - то домен добавить, то поддомен удалить, то тариф измемнить.
3) Владельцы больших прибыльних проектов. Как правило, не готовы мириться с "соседями", приходящими из мира шареда, так как им нужно своё решение. Скорее всего, в той же гипотетической ситуации купят у Вас несколько серверов и администрирование.
Все три группы людей можно разбить смело на три :))) О как !!!! кластера, если мы говорим о тех кому пофик и о тех кому не пофик :) Согласитесь, от этого схема хуже не становится :)
Если Вы чётко можете описать категорию людей, которым это нужно и не можете придумать причин, по которым им это не нужно, и знаете примеры людей из этой категории то, без сомнения, делать это нужно.
Что же , справедливо! Я думаю что в основном интересует мнение тех , кто понимает зачем это , сложно доказать группе номер (1) например, что разбросав нагрузку разную по смыслу на разные участки этого решения повышается производительность системы в целом, сложно будет рассказать группе (2), что когда DNS+MAIL+SQL+ВСЕ ОСТАЛЬНОЕ на одном сервере шанса выжить у него гораздо меньше, чем например у сервера который обслуживает только SQL ..... Проблему с группой (3) можно решать в индивидуальном порядке, опять же разбиение на разнокалиберные участки ... не вредит общей схеме.
Даже с их вторым более легким dns-сервером?
На каких объемах доменов вы работаете с NSD? Сколько серверов в репликации? есть ли передающие через себя сервера в схеме? Да, кстати это ж кластеризация только DNS.... это отдельное решение, которое например вполне отлично реализовывается через репликацию SQL с любой оберткой, хоть NSd, хоть Named, хоть pdns...
Romka_Kharkov добавил 23.01.2011 в 03:51
-------------------------
Интересно мнение следующих людей:
-L-, Anves, MaxScorpion, neitrino, Oleg_ST, Snapius, temmokan, voooz
которые на сегодня проголосовали "Да!".
Мало того их мнение очень ВАЖНО!
зачем писать с нуля панельку?
у нас например реализована своя панель на основе ISP manager
пользователи через нашу (не ISP) панель управляют услугами, а она уже что-то делает через api ISP, что-то ставит в очередь на отправку новых конфигов на сервера
на текущий момент сейчас крутится 12 серверов с разными задачами и резервированием
День добрый,
что-то ставит в очередь на отправку новых конфигов на сервера
Это простите как?
на текущий момент сейчас крутится 12 серверов с разными задачами и резервированием
тафтология ?
Поделитесь с нами секретами технической части , или тоже надо "просто покупать"? К примеру bugsmoran хотел уточнить по поводу репликации SQL, поддерживаю его вопрос :) реализована ли кластеризация\репликация баз данных в вашем решении или как у вас базы данных живут вообще, я же не знаю.... ?
С Уважением,
Можно в кратце напомнить как там кластеризуется MySQL и как раутится трафик если поляжет фронтэнд?
100 процентная отказоустойчивость и mysql и фронтенда реализована.
масштабирование mysql присутствует даже в не кластерных версиях, если речь вести о масштабировании когда одному клиенту необходимы мощности более одного физического сервера, то тут нет технических решений, вернее оно есть от mysql, но оно налагает массу ограничений, которые не приемлемы в рамках массового хостинга. даже если у вас возникает необходимость его использования, то кластеризация базы организуется средствами mysql, а к панели он подключается как еще один сервер баз дынных.
масштабирование фроненда мастера, в процессе реализации и скоро будет закончено.
На сайте нет практически никакой ценной для технарей информации.
В документации описаны все утилиты для работы с кластером. Там имеется описание того что нужно для его развертывания, есть описание как сделать внешнюю ФС, рассмотрены преимущества и недостатки разных видов сетевых ФС (мы предлагаем несколько вариантов на выбор), все остальное сводится к обычному администрированию и рассматривать вопросы как настроить NFS сервер не входит в наши задачи, т.к. подобной информации полно на других ресурсах.
Там только флэшовая картинка для манагеров
Картинка не для манагеров, а для быстрого понимания что эта штука делает, в том числе и технарями у которых нет времени заглядывать в доки и нужно составить быстрое представление о том что позволяет продукт. Изначально на ней был изображен конечный результат к которому мы стремимся, и на данный момент все что там изображено присутствует, за исключением масштабирования мастера.
День добрый,
Это простите как?
например... конфиги апача находятся на всех серверах, если даже сайт обслуживают только 2 сервера, на тот случай, если они выйдут из строя, сайт будет переключится на другие сервера автоматически
Поделитесь с нами секретами технической части , или тоже надо "просто покупать"? К примеру bugsmoran хотел уточнить по поводу репликации SQL, поддерживаю его вопрос :) реализована ли кластеризация\репликация баз данных в вашем решении или как у вас базы данных живут вообще, я же не знаю.... ?
а вот по БД тут другое... основная БД обслуживает сайт, slave БД используется как резервная
скрипты где рабоатет апач периодически проверяют доступность основной БД и в случае сбоя, переписывают ip на сервере, т.е. пользвоатели прописывая имя сервера прописывают не IP, а внутренее имя сервера
сейчас переходим на виртуализацию части серверов по причинебыстрого восстанволения виртуального сервера из снапшота
в любом случае есть узкие места (даже не узкие, а слабоватые).... например проксирующие сервера, у нас используется их 2, и в случае сбоя одного их них, для части посетителей (±50%) сайт будет временно не доступен т.к. кэшируется ДНС
ещё как готовы, если будет качество и нормльная цена... и где можно до саппорта достучаться в любое время суток, где например саппорт поможет советом как лучше...
Я не буду работать с ISP по ряду других причин. Это субъективно. И я не исключаю варианты что в ISP есть реализации.
Я вас не на что не агитирую, впрочем как и никого другого, люди к нам приходят, изучают продукты и используют, при этом им никто ничего не навязывает, а честно рассказывают о всех преимуществах и недостатках, обоснованный выбор всегда остается за клиентом.
Вы можете сколь угодно долго игнорировать существование наших продуктов и называть их в своих перечислениях etc, но вы не измените того факта что продукты достаточно популярны и успешно используется достаточно большим количеством компаний и их клиентов. А судить о компании и продуктах исключительно по некоторым темам на данном форуме по крайне мере глупо, негатив пишут всегда, позитив крайне редко.
Точно так же как например есть почти работающий DNS кластер у cpanel... он как бы работает.... да .... пока у вас доменов до тысячи.... точно так же есть якобы рабочий вариант кластера у interworx который работает пока NFS чувствует себя нормально (сам по себе не стабильный не то что бы в кластере). Еще работал с неким пониманием кластеризации у XEN / Solus, опять же... написано.... все якобы хорошо... но есть много недоработок и назвать эту схему рабочей - я не берусь. По этому поймите правильно то, что я хотел сказать, я не утверждаю, что нет на земле решений которые бы реализовали кластер, я лишь уверяю вас в том, что все ети решения работают дай бог на 50% от того , что реально заявлено. Это я проверил на описанных выше решениях лично!!! Отсюда и тема родилась.
Вы думаете ваше решение будет лишено недостатков? Не думаю что оно подойдет абсолютному большинству клиентов. Скорее всего будет решать какие-то специфичные задачи и не сможет справится с другими. А когда вы его испытаете на сотнях тысяч реальных клиентов вы найдете много новых узких мест, таких что для их решения придется изменить подход к архитектуре.
Кстати, где-то тут bugsmoran поднимал тему про кластеризации, и там у него есть много позитивных мыслей с которыми я не могу не согласится.
Еще раз повторю, я вас никуда не агитирую, целью моего первого поста была сообщить что вы не все знаете, и пытаетесь изобретать велосипед, кстати и Андрейка не шутит, на какой-то конференции я слышал его доклад как он делал подобный кластер и натягивал на него DA.
А что там писать, если так разобраться? :) Меню из 10 функций по работе с доменами и почтой, остальное все бекенд.
Да не в том дело писать или не писать, а в том, что заголовок темы: "Есть ли желающие пожертвовать панелью управления во благо отказоустойчивости? ".
А я хочу объяснить, что жертвы не требуются. Можно, так сказать, собрать lock, stock and barrel
Можно я ж о чем, так о почему не продают? И ссылочку можно на презентацию.
http://rutube.ru/tracks/2514026.html
А что значит - отказаться от ПУ? Only SSH?
1) Считаю, что ошибки панели - это последняя причина влияющая на отказоустойчивость. Самые проблемные области телекома - каналы, роутеры, системы маршрутизации, безопасность и абузы. Потом только сервера и ПО на них. ИСП отлично работает )
2) Для нас вполне подходит решение с распределением ресурсов - почта (можно кластер), БД, бакап-сервера.
Я уже как-то оставлял устную заявку в ИСП, что хорошо бы сделать возможность подключать внешний почтовик к панели. Для обычных смертных, как говорится, которым пока не доступен кластер... да и не рассчитана рентабельность этого кластера...
оффтоп
Если еще реализовать аналог plesk expand по-человечески - то вообще... будет не хостинг а песня.
Это централизованная БД всего хостинга со всех панелей, если кто не видел. Можно посмотреть всех пользователей и все домены, зайти в нужного пользователя на панель и тд.... Подключить как раз таки центральные ДНС, БД, бакап и почтовики, распределить клиентов по панелям, сделать перенос клиента с одной панели на другую. Массовые операции над клиентами разных панелей, работа с ip серверов. Центральный вход... (с отдельной машины все же правильней).