Colo: бинарник есть всегда ;). Вопрос только есть в нем то, что нужно ;)
- чего-то я Вас не понял :( Во первых ведение бинлогов вещь не декларируемая хостером и их наличие у хостера - это большой вопрос (растут они, при интенсивном использовании базы, дико и не факт что хостер их ведет). Во вторых - не понял куда из бинарного лога денется инфа? т. е. если лог есть, он содержит данные (как правило от момента последнего "нормального" бэкапа).
shav: Кто может нормально описать плюсы и минусы по сравнению с VDS?
- кто может отличить VPS от "облачного хостинга"? 😂 Уже неоднократно в этой теме высказывалась мысль, что большинство компаний предлагающих "облачный хостинг", фактически предлагают VPS с удобной панелью по изменению квот на этот VPS (диск/память/ЦПУ) и, иногда, с живой миграцией между физическими серверами. Такие "облачные хостинги" всегда имеют лимит по ЦПУ/памяти, не превышающий возможности используемого железа (т. е. не мощнее чем дедик заказанный у той же компании). Т. е. фактически в большинстве случаях речь идет о маркетинговом ходе (раньше клиента ловили на безлимит, теперь раздувают "облака"). По настоящему "облачный хостинг", на данный момент, требует от клиента написания приложений под специальный API, предлагаемый хостером, позволяющий работать с кластеризованными ресурсами (БД/сервер приложений).
Alex91: если у хостера ведется "логирование" бд, то, насколько я понимаю, возможно поставить.
mysql binlog
уточните у них
+ 1, кроме бэкапирования часто хостеры используют опцию бинарного логирования (в MySQL). По binlog-у элементарно все восстанавливается.
При битой тиблице дамп с БД не снимается, это уже чисто техническая деталь. Мы же не всегда можем оперативно увидеть, что какая-то таблица повреждена и принять соответствующие меры.
- неизвестно как хостер делает бэкап (если на живой БД, то легко представить что в бэкап попадет "битая" таблица). Можно обойтись и без дампа - тупо взять папку с базой (если речь о MySQL) скопировать на локальный комп. в локальную MySQL, запустить "починку" таблицы, а затем снять дамп на локальной базе. Но думаю что хостер ничего не даст, а вся переписка про "битую таблицу" - это отмазка при полном отсутствии бэкапа.
Вертикальное масштабирование ресурсов (scale vertically или scale up) стало возможным за счет технологии виртуализации Xen, когда ресурсы виртуальной машины могут изменяться на лету без остановки ее работы.
- все это уже обсудили в данной ветке: виртуалки с живой миграцией, которые никак не могут получить больше ресурсов (ЦПУ, память) чем есть у сервера на котором они размещены, а учитывая что ресурсы железа лимитированы, особенный интерес вызывает фраза:
В течение одной минуты вы можете получить площадку как для небольшого блога, так и для размещения всех датацентров компании Яндекс!
- видимо мощность площадки scalaxy выше мощности "всех датацентров компании Яндекс" ;) верить или не верить? Слишком мало технических деталей, чтобы можно было что-то уверенно утверждать (во всяком случае Xen больше чем есть ресурсов у одной ноды, не даст)
Brim.ru добавил 15.06.2010 в 11:34
soros26: Мне нужно чтобы стоимость хостинга была динамической, зависящей от тяжести и посещаемости сайтов. Таким образом чтобы при наличии 1-2 "легких" сайтов не пришлось бы платить 1000руб за VPS и можно было бы легко без всяких переездов на другие сервера, хостинги залить еще 10 сайтов тяжелых.
Uptime=>100%, хорошая поддержка, "широкий" диск - это как бы норма уже даже на малобюджетном хостинге.
Единственное требование к ПО-Windows платформа🚬
- либо сайты должны ориентироваться на спец. API хостера (тогда требования к ПО идут лесом), либо максимально необходимое (для 1-2 "легких" сайтов + 10 "тяжелых") количество ресурсов (ЦПУ, память) не должно превышать возможности самого мощного VPS у хостера (а его возможности лимитируются возможностями железа на котором этот VPS живет, т. е. в типичном случае лимиты: 8 ядер и 24Гб ОП), т. е. строго говоря в этом случае масштабируемость "облака" имеет границы.
Andreyka: Ок. Оплата кодеру за шардинг - 2000$, единоразово Оплата за аренду сервера с кучей ОП - 800$/ мес Посчитаем?🍾
- учить клиентов - это не та работа которой должен заниматься хостер, работа хостера раелизовывать пожелания клиента. Возможно для Вас, как для консультанта, приемлемо давать клиенту советы и рекомендации, а в нашем случае мы даем советы только по просьбе со стороны клиента (говорить вебмастеру что его г..сайт еле работает из-за того что он не знает программирования и не умеет работать с БД, просто не этично, да и коммерческой выгоды от таких разговоров для нас не предвидится, разве что получим раздраженного клиента). Короче - если клиенту нужны террабайты дисков и гигабайты памяти, нам нужно думать о том как это сделать, а не о том для чего это нужно клиенту ;)
- кстати если заплатить кодеру, можно получить сайт работающий с Google API и "немерянными" ресурсами гугловского облака, но жизнь показывает что владельцы сайтов не особенно стремятся воспользоваться облачным хостингом с эксклюзивным API.
soros26: Собственно меня интересует вот что: имеет ли смысл вообще перебрасывать малопосещаемый сайт на облачный хостинг или "облако"-это только для высокопосещаемых сайтов-порталов?
- вот Вы можете сформулировать что Вам нужно от хостинга кроме модного слова "облако"? диск? память? ЦПУ? uptime? трафик? требования к ПО? поддержка?
Andreyka: Смысл в том, что ненужно держать всю базу на одном узле
- кому "не нужно"? есть клиент, у него есть БД, в которой таблица размером 50Гб, для ускорения операций с которой клиент желает пихнуть ее в ОП и готов за это заплатить. Клиент не имеет желания менять структуру таблиц в своей базе и вообще менять приложение, он хочет решить проблему путем покупки большего количества ресурсов. Вы ему говорите - "не нужно держать всю базу на одном узле, так как есть шардинг". Внимание вопрос: какие дальнейшие действия клиента?
Cardinals: есть нормальное железо, что бы строить нормальные облака)) по началу облако может крутиться на каком нить 4 ядерном xeon'е, а начнешь платить за большие ресурсы, то перекинут вот на такой сервачек, даже и не заметишь. Вроде как обещают, что миграция без даунов и смены IP происходит в облаке.
- всегда найдется клиент пожелания которого превосходят имеющиеся возможности самого мощного сервера у хостера (который к тому же уже может быть занят другим клиентом также нуждающемся в большом количестве ресурсов). То о чем Вы пишите - это не "облако", о обычный кластер использующий расшаренное дисковое хранилище на котором запущены виртуалки (мигрировать между узлами кластера без перезапуска виртуалки умеют уже сто лет и никто это облаком не называл).
бинарник есть всегда ;). Вопрос только есть в нем то, что нужно ;)
- чего-то я Вас не понял :( Во первых ведение бинлогов вещь не декларируемая хостером и их наличие у хостера - это большой вопрос (растут они, при интенсивном использовании базы, дико и не факт что хостер их ведет). Во вторых - не понял куда из бинарного лога денется инфа? т. е. если лог есть, он содержит данные (как правило от момента последнего "нормального" бэкапа).
Кто может нормально описать плюсы и минусы по сравнению с VDS?
- кто может отличить VPS от "облачного хостинга"? 😂 Уже неоднократно в этой теме высказывалась мысль, что большинство компаний предлагающих "облачный хостинг", фактически предлагают VPS с удобной панелью по изменению квот на этот VPS (диск/память/ЦПУ) и, иногда, с живой миграцией между физическими серверами. Такие "облачные хостинги" всегда имеют лимит по ЦПУ/памяти, не превышающий возможности используемого железа (т. е. не мощнее чем дедик заказанный у той же компании). Т. е. фактически в большинстве случаях речь идет о маркетинговом ходе (раньше клиента ловили на безлимит, теперь раздувают "облака"). По настоящему "облачный хостинг", на данный момент, требует от клиента написания приложений под специальный API, предлагаемый хостером, позволяющий работать с кластеризованными ресурсами (БД/сервер приложений).
ну вообще хостеру ничего не стоит дать бинарник, мы бы дали без проблем.
- если он есть ;)
если у хостера ведется "логирование" бд, то, насколько я понимаю, возможно поставить.
mysql binlog
уточните у них
+ 1, кроме бэкапирования часто хостеры используют опцию бинарного логирования (в MySQL). По binlog-у элементарно все восстанавливается.
- неизвестно как хостер делает бэкап (если на живой БД, то легко представить что в бэкап попадет "битая" таблица). Можно обойтись и без дампа - тупо взять папку с базой (если речь о MySQL) скопировать на локальный комп. в локальную MySQL, запустить "починку" таблицы, а затем снять дамп на локальной базе. Но думаю что хостер ничего не даст, а вся переписка про "битую таблицу" - это отмазка при полном отсутствии бэкапа.
http://www.scalaxy.ru/ - облачный хостинг с кучей настроек и опций
Цитаты с указанного сайта:
- все это уже обсудили в данной ветке: виртуалки с живой миграцией, которые никак не могут получить больше ресурсов (ЦПУ, память) чем есть у сервера на котором они размещены, а учитывая что ресурсы железа лимитированы, особенный интерес вызывает фраза:
- видимо мощность площадки scalaxy выше мощности "всех датацентров компании Яндекс" ;) верить или не верить? Слишком мало технических деталей, чтобы можно было что-то уверенно утверждать (во всяком случае Xen больше чем есть ресурсов у одной ноды, не даст)
Brim.ru добавил 15.06.2010 в 11:34
Мне нужно чтобы стоимость хостинга была динамической, зависящей от тяжести и посещаемости сайтов. Таким образом чтобы при наличии 1-2 "легких" сайтов не пришлось бы платить 1000руб за VPS и можно было бы легко без всяких переездов на другие сервера, хостинги залить еще 10 сайтов тяжелых.
Uptime=>100%, хорошая поддержка, "широкий" диск - это как бы норма уже даже на малобюджетном хостинге.
Единственное требование к ПО-Windows платформа🚬
- либо сайты должны ориентироваться на спец. API хостера (тогда требования к ПО идут лесом), либо максимально необходимое (для 1-2 "легких" сайтов + 10 "тяжелых") количество ресурсов (ЦПУ, память) не должно превышать возможности самого мощного VPS у хостера (а его возможности лимитируются возможностями железа на котором этот VPS живет, т. е. в типичном случае лимиты: 8 ядер и 24Гб ОП), т. е. строго говоря в этом случае масштабируемость "облака" имеет границы.
Ок. Оплата кодеру за шардинг - 2000$, единоразово
Оплата за аренду сервера с кучей ОП - 800$/ мес
Посчитаем?🍾
- учить клиентов - это не та работа которой должен заниматься хостер, работа хостера раелизовывать пожелания клиента. Возможно для Вас, как для консультанта, приемлемо давать клиенту советы и рекомендации, а в нашем случае мы даем советы только по просьбе со стороны клиента (говорить вебмастеру что его г..сайт еле работает из-за того что он не знает программирования и не умеет работать с БД, просто не этично, да и коммерческой выгоды от таких разговоров для нас не предвидится, разве что получим раздраженного клиента). Короче - если клиенту нужны террабайты дисков и гигабайты памяти, нам нужно думать о том как это сделать, а не о том для чего это нужно клиенту ;)
- кстати если заплатить кодеру, можно получить сайт работающий с Google API и "немерянными" ресурсами гугловского облака, но жизнь показывает что владельцы сайтов не особенно стремятся воспользоваться облачным хостингом с эксклюзивным API.
Собственно меня интересует вот что: имеет ли смысл вообще перебрасывать малопосещаемый сайт на облачный хостинг или "облако"-это только для высокопосещаемых сайтов-порталов?
- вот Вы можете сформулировать что Вам нужно от хостинга кроме модного слова "облако"? диск? память? ЦПУ? uptime? трафик? требования к ПО? поддержка?
Смысл в том, что ненужно держать всю базу на одном узле
- кому "не нужно"? есть клиент, у него есть БД, в которой таблица размером 50Гб, для ускорения операций с которой клиент желает пихнуть ее в ОП и готов за это заплатить. Клиент не имеет желания менять структуру таблиц в своей базе и вообще менять приложение, он хочет решить проблему путем покупки большего количества ресурсов. Вы ему говорите - "не нужно держать всю базу на одном узле, так как есть шардинг". Внимание вопрос: какие дальнейшие действия клиента?
Шардить можно в ОП
- можно, но тогда не ясно в чем смысл Вашего замечания про шардинг (излишне лаконичный стиль общения ухудшает понимание сказанного)
Для баз давно придуман шардинг
Ваш К.О.
- готовы сравнивать шардинг и базу висящую в ОП по быстродействию? ;)
есть нормальное железо, что бы строить нормальные облака)) по началу облако может крутиться на каком нить 4 ядерном xeon'е, а начнешь платить за большие ресурсы, то перекинут вот на такой сервачек, даже и не заметишь. Вроде как обещают, что миграция без даунов и смены IP происходит в облаке.
- всегда найдется клиент пожелания которого превосходят имеющиеся возможности самого мощного сервера у хостера (который к тому же уже может быть занят другим клиентом также нуждающемся в большом количестве ресурсов). То о чем Вы пишите - это не "облако", о обычный кластер использующий расшаренное дисковое хранилище на котором запущены виртуалки (мигрировать между узлами кластера без перезапуска виртуалки умеют уже сто лет и никто это облаком не называл).