С ребутом проблем нет, именно ребут сделать я могу в любое время сам, даже если сервер не отвечает по ssh. Я просто хочу сказать, что реально час простоя (а то и больше) — это просто банальная вещь, вроде плановой смены HDD. Если что сломается посерьезнее, или есть попадаешь в пересменку, ну или к конце концов, я или мой "штатный" админ не локализирован проблему вовремя — и время простоя будет далеко не час. Ну например 3 часа, или 6. А предлагаю простой и не дорогой способ решить эту проблему — сделать не большой кластер, вот и всё. Ну как бы вам попроще объяснить... вот в двери у вас в квартире сколько замков? Наверно ж два минимум? А дверей сколько? Тоже ж наверное не одна (подъезд, тамбур, квартира...) ну и тут как-то похожая ситуация :)
Поэтому почему моя идея не разумна, я пока честно говоря так и не понял.
И ещё, всётаки прошу обратить внимание, я изначально к кластеру приписывал функции и балансировки нагрузки. Ну два коня побольше потянут чем один... Чем же вам так кластер не нравится?
Да, точно что как об стенку... С одной стороны ТЗ конечно бы не помешало, можно было уделить время и подробно расписать, сколько система должна выдерживать нагрузки, какой должен быть максимальный даунтайм, как и на сколько система должна масштабироваться — это всё понятно... Но с другой стороны, я давно понял вашу позицию — выбирайте нормальный ДЦ в котором любой вопрос решат за 1 час. Я с этой позицией не согласен, поэтому можете считать это моей прихотью. Да, хочу клястер.
Но всё же, если вас интересуют какие-то конкретные исходные данные, которые не понятны из этого топика, и которые я должен бы был включить в ТЗ — вы можете уточнить эта данные у меня прямо здесь. Но вместо конкретных вопросов ко мне относительно темы, я получил почти 10 страниц ваших персональных убеждений.
Я изначально не позиционировал себя как разбирающийся в кластере. И вполне шел, и иду на конструктивный диалог, относительно смежных тем. Но вы просто пытайтесь выглядеть умнее всех, доказывая мою не разумность, и не только мою.
hacccker добавил 06.12.2010 в 23:20
А если сделать по подобной схеме и веб сервер и всю файловую систему? Грубо говоря не заморачиваться с балансировкой, я и сам могу ручками сначала разрешить в панели добавление аккаунтов на один сервер, а потом на второй, ну и переключать это как-то по очереди по мере наполнения.
И второй вопрос. 4-мя серверами пока не располагаю. Как на счет 2 или 3? Я думаю по предложенной мной схеме в принципе без разницы?
hacccker добавил 06.12.2010 в 23:47
Вот и товарищ V(o)ViK, и ещё некоторые в этой теме, считают, что кластер это что-то невероятное из области нанотехнологий, типа какой-то супер-компьютер или сеть компьютеров стоимость которых невероятно большая. Считают, что создавать и обслуживать кластер из нескольких серверов, может только опытный штатный админ с окладом в $4K/мес. Ну отсюда вытекает, что проще просто делать бекапы и не заморачиваться вообще.
Я же считаю, что не большой кластер — просто дополнительный не большой плюсик, лишним он не будет, а настроить все это дело можно за абсолютно адекватные деньги. И поддерживать то не большое хозяйство я вероятно смогу и сам, а если и будут какие-то вопросы, мне будет к кому обратиться за консультацией и помощью.
Ну и ещё некоторые мои убеждение, которые возможно противоречат вашим, но я бы не хотел ещё об этом спорить. Просто выскажу их.
- VDS обычно медленее шаред хостинга, поэтому даже совсем чуть-чуть крупные проекты не сидят на VDS. У меня есть клиенты, которые ушли с VDS ко мне на шаред. Им было выгодней заплатить за "повышенный" тариф шареда, чем жестко ограничиваться ресурсами VDS, за те же деньги. Ну и плюс вопросы администрирования играют роль. VDS-кой тоже нужно уметь управлять.
- Я не планирую выйти с ценой в 2 раза больше. Да и потом, ну сейчас и так разброс цен на рынке шаред хостинга, в два раза и более . Ничего страшного, это рынок :)
- Я там выше написал про бекап, все как-то восприняти в штыки... Попробую прояснить ситуацию.
1) Бекап это на самом деле вещь абстрактная, всмысле по договору я просто должен гарантировать сохранность данных. Если конечно не указанно, что гарантирую создание бекапов по такому-то графику, храню их столько то времени и предоставляю к ним доступ. Но такого как правило никто не пишет, пишут просто, что гарантируют сохранность данных. Каким способом это достигается — личное дело каждого. Кто-то сливает периодически на отдельную машину, кто-то использует RAID, кто-то использует и то и другое. Некоторые используют ещё и кластер ко всему этому, т.е. в любом случае происходит многократное дублирование информации на разных физических носителях.
2) Если бы многим клиентам нужен бы был доступ к бекапам разной давности, я бы скорее всего это предоставил. Но в большинстве случае, клиентов беспокоить сохранность данных, а не бекап как таковой.
3) Бекап самый простой вопрос в плане реализации. Ну если всем прям нужны будут бекапы, ну так уж и быть — будут бекапы. Я совсем не имел ввиду что бекапы это плохо. И возможно в будущем я пересмотрю свою точку зрения, и сделаю бекапы, как и было у меня раньше.
myhand, что вы мне пытайтесь доказать? Что кластер мне не нужен, т.к. быстрее сменить оборудование? Мне уже честно говоря надоело из пустого в порожнее...
Andreyka, на счет MySQL у меня такая идея...
Репликация + Балансировка. Объясню...
Два сервера работают с разными наборами БД, ну такая себе балансировка (30 БД на одном сервере и 30 на другом, все работают постоянно) и каждый из серверов синхронизируется с другим, ну всмысле реплицируется только другая группа. Если один сервер упал, то другой берёт вторую группу БД на себя (из своей копии которая отстаёт во времени от оригинальной)
Не знаю доступно ли объяснил :)
Такой вариант возможен? Я думаю при гигабитной сетке между серверами отставание будет не сильно большое. Имхо в случае краха сервера, лучше вернуться на 5-10 минут назад, чем лежать мёртво...
AGAVA подойдет? В договоре в основном "мы ничего не гарантируем", "мы не обязаны", "мы не несет ответственность за" итд... И это правильные договоры, с позиции компании :)
А ну извините, у меня не стойка, и не SLA и вообще я из деревни :)
Я вам выше привел пример, и рассказал какой был даунтайм, т.е. это не оценка возможного, а констатация факта. А вы мне опять про теорию устранения любой проблемы за 1 час.
Та почему.. какой вы видели самый дешевый хостинг? 2$? 1? Ну вот представьте, было 2$, стало 4$. Размыть можно тем, что дать больше места или ещё чего-то... Ничего ж страшного что цена стала не 2, а 4$ Вот вам пример линейного роста цены. Аналогично можно на прибыль пересмотреть, кто-то хочет 100% накрутки, а кому-то и 50% достаточно...
И ещё, пишите пожалуйста без ваших "Я", а то "клястер", "генияльную" мне режет глаз. Или у вас не русский акцент?
hacccker добавил 06.12.2010 в 01:33
Согласен, поэтому покачаемся тут ещё... )
Меня консультировали по связке DRDB+Heartbeat+LVS, в этом случае 50% мощностей не простаивает. Если откажет сетевой адаптер, сервер выпадет из клястера, и вся нагрузка перейдет на оставшийся. Ну так объясняли :)
hacccker добавил 06.12.2010 в 01:20
Да тема интересная, жаль некоторые сочли её за место выяснения "кто более красноглазый админ", или "ТС ничего не понимает — ему клястер не нужен" :)
Когда простаивает второй сервер это не есть гуд, поэтому мы тут дальше и дискуссируем. К Андрею возможно обращусь, пока изучаю ещё варианты предложенные. Кстати если бы Андрей что-то предложил... :)
Что именно вам там любопытно? Не в одном договоре публичной оферты я ещё не видел пункта про резервные копии 🍿
Понимайте, без SLA договора, и Ваш ДЦ который выбрали Вы, может однажды стать Вашей персональной проблемой.
Я допускаю, что стоимость может возрасти линейно, в зависимости от количества серверов в кластере.
hacccker добавил 05.12.2010 в 00:48
Примерно так и планируется.. В случае с DRDB как раз слейм постоянно синхронизируется с мастером. Если мастер упал, на слейве ставятся такие же настройки как были на мастере, и слейв становится мастером... Это несомненно решение, и возможно к нему и буду склонятся. Пока просто интересно рассмотреть ещё варианты, я имею ввиду про балансировку нагрузки на лету.
Предоставляю, но не делаю бекапа всех пользовательских данных автоматом.
Ещё раз: если саппорт хостера === инженеры в ДЦ. Если у вас это именно так — прекрасно. Я например, не имею лично доступа к своему оборудованию. Оно далеко...
Что значит проблем? У меня тоже проблем не возникает, но с момента реакции до устранения проблемы проходит какое-то время.. а там в ДЦ у инженеров свой график.. решал вопрос, попал в пересменку, пришел другой инженер — объясняешь ему всё сначала.. время идет... Аналогично плановые работы инженеры в не рабочее время не выполняют, тот же винт сменить — только в рабочее время... Если ДЦ далеко сюда же прибавляем сдвиг в часовом поясе... Фантастику рассказываю? Нет, это реальность. А спич о том, что "саппорт за час решает любую проблему" — это как раз сказка...
Дорого организация или дорого потом услуга для конечно пользователя?
Ну так и оцените по количеству серверов в кластере, вероятность отказа кластера 🍿 А я поулыбаюсь, и расскажу что все эти расчеты бред, потому что.... и тысячу причин найду :)
Верю, если у хостера как раз кластер. Или если не кластер (один сервер), тогда хостер владеет своим личным ДЦ, личным персоналом итд... Много ли у нас таких? 🍿 Не много. Если вы арендуйте сервер на площадке любого ДЦ, и не подписывали никакой SLA договор, в случае поломки простой будет ровно столько, сколько захочется персоналу этого ДЦ. Такое ощущение, что вы лично не сталкивались, а начитались маркетинговой шелухи каких-то "нормальных хостеров", которые обещают простоя не более часа в год :D
Значит в этой теме мы обсуждаем кластер, а не хостинг. Меня спросили для чего мне нужен кластер, я ответил что для хостинга. Теперь меня убеждают что не получится хостинг. Хостинг уже получился и успешно работает. Цель — развиваться дальше, повышать надёжность и производительность. Если вам нечего рассказать про кластер, не нужно мне рассказывать про хостинг. :D
Хотелка вполне адекватная. А вы никаких аргументов кроме как "глупо" привести не можете.
Это вы опять пытайтесь склонить в сторону "у нормального хостера только 1 час простой в год". И поэтому кластер не нужен. Это Бред. Скорее всего вы понятия не имейте как организованы нормальные хостеры.
Оценивать вероятность того что всё сляжет, по количество серверов в кластере глупо, поэтому я не буду это делать. Но время простоя кластер может уменьшить.
hacccker добавил 04.12.2010 в 22:20
Я понимаю, а хочется чтобы принимал, т.е. балансировал нагрузку.
hacccker добавил 04.12.2010 в 22:22
Вы извините если я где-то ввёл в заблуждение :) Ну переспросите меня пару раз 😎
hacccker добавил 04.12.2010 в 22:27
Конкуренция большая, да. Но вкидывать сразу большие деньги, ещё более глупо, чем проектировать хостинг на одном-двух серверах. И что значит вообще не смысла? Вы видите, что тут масса людей меня убеждают что кластер не нужен, а значит один клиент сидит на одном сервере. В таком случае никакой разницы нет, сколько серверов 1 или 100. Все зависит от количества клиентов.
Делали мы бэкап на отдельный.. нету большого смысла, проще использовать RAID. Куча времени и ресурсов уходило на архивирование и перекачку данных на другой компьютер.
Такс... пообщался я тут ещё с умными людьми, есть предложение
DRDB + heartbeat
Если heartbeat получится использовать как "Поглощающая (takeover) конфигурация", то чем это не решение?
hacccker добавил 04.12.2010 в 04:59
Да что ж вы к биллингу и панели привязались?:( Это имеет посредственное отношение к кластеру. Если вам это так режет глаза, в данном контексте можно считать — панели нет вообще. Или по вашему, без панели, кластер не получится? :)
За $100K я бы рассматривал какие-то программно-аппаратные решения кластера от того же Oracle. Причем мне бы все оборудование привезли куда, включили и настроили. Но пока что таких денег нет :)
Вероятность того что всё ляжет конечно есть, но она определенно ниже, чем когда используется один сервер. Или я не прав? Не очень понимаю, почему это вызывает улыбку.
hacccker добавил 04.12.2010 в 05:03
Вводите что-то вроде "shared hosting cluster" и жмите Мне повезёт 🍿
их полно...
hacccker добавил 04.12.2010 в 05:07
Я как раз в данном случае принимаю стратегическое решение. Но углубляюсь на уровень инженеров, чтобы выбрать правильного стратегическое решение.
>Нужно более точно
Если вы забыли, о чем мы тут говорим, я могу напомнить: мы говорим о кластере. Значит под фразой "виртуальный хостинг, который отличается надёжностью" — я имел ввиду хостинг на кластерной архитектуре.
