Так и наши не майнят)
Отчего же - если памяти хватает даже в условиях оверсейла, своп задействован не будет.
В медицине есть такое понятие - декомпенсация. Тут суть другая, но внешне выглядит похоже - пока объем используемой памяти меньше объема памяти, которая есть в наличии, внешне все выглядит гладко, оверсейл заметить со стороны клиента просто невозможно. Как только несколько или даже одна ВДС повысили свои аппетиты даже в пределах своего тарифа и суммарный объем используемой памяти превысит объем установленной на сервер - все, суши весла, картина будет, как вы и описали.
Вот как по мне - именно это определяющий фактор, а не используемая технология)
UPD сбилась нумерация цитат, опубликовал после вашего изменения.
по п.1 - согласен, нужно специально включать. суть в том - что возможность есть, а значит, и нет "честности технологии" в этом отношении - опять, все от политики хостера зависит
Так ведь и на kvm есть возможность недодать ресурсы - все зависит от конкретной политики хостера. Никто не мешает на сервер с 1 четырехядерным CPU и 4Гб памяти повесить 10 виртуалок, каждой из которых будет выделено 1 ядро и 1Гб памяти - оверсейл, как он есть.
Единственное, что нельзя оверселить на kvm (по крайней мере, что вспомнилось) - объем дискового пространства. Как правило, узкое место не в этом.
Вот тут полностью согласен - если бюджет не учитывать, KVM круче :)
Ок, тезисно, раз читать статью лень)
- Ниже цена
- Выше производительность
- Возможность отдавать виртуальной машине неиспользуемые ресурсы ноды при необходимости, даже если она (виртуалка) требует больше, чем ей положено по тарифу (burst cpu, burst memory)
- Возможность живой миграции между физическими серверами
- Меньшее влияние на соседей в случае перегрузки виртуалкой дисковой подсистемы (vzswap)
Ну и, немаловажный для клиента факт, что жестко оверселить возможно не только на OVZ - тут больше от порядочности хостера зависит, чем от испольлзуемой технологии.
UPD: уточню на всякий случай - я позиционирую OpenVZ как младшего брата гипервизорной виртуализации, если можно так сказать. Т.е. если для проекта хватает возможностей OVZ - смысла покупать KVM особо не вижу. Но выбор, естественно, за клиентом - именно он рублем голосует)
Мое мнение: если задача решается на виртуальной машине с OpenVZ - лучше воспользоваться этим вариантом. Если нужны специальные настройки ядра, другая ОС, или хочется чего-то странного - выбор KVM.
На хабре был неплохой пост в защиту OVZ - http://habrahabr.ru/post/177423/, рекомендовал бы ознакомиться.
PS. Я не фанат OpenVZ, просто считаю, что каждая задача должна решаться с помощью оптимальной конкретно для данного случая технологии. Поэтому сказать, что лучше - OpenVZ или KVM без привязки к конкретной задаче, конкретному бюджету и ожидаемой нагрузке просто нереально.
Есть мнение, что оверселлинг тут не причем, если используется OVZ. Сами с таким многократно сталкивались пока к мониторингу счетчики не подключили, причина - особенности работы системы виртуализации.
http://forum.proxmox.com/threads/2822-Unable-to-fork-Cannot-allocate-memory
Собственно, задача клиента - просто обратиться в поддержку, там все сами сделают, времени пару минут от силы займет.
Здравствуйте, имеете в виду - по данным сервисов геотаргетинга?
kvm-1-ru (2 ядра / 4Gb RAM / 35Gb HDD) - 899р
kvm-2-ru (4 ядра / 8Gb RAM / 50Gb HDD) - 1199р
Расширение диска 100р за 10Гб, следовательно, VDS со 150Гб на борту будет стоить 1999 и 2199 соответственно.
Тест 3 дня. Порт 1G.
Локация - Москва
Лицензию предоставить не сможем, к сожалению. Возможна самостоятельная установка системы из подключаемого iso-образа.
PS. Если приоритет - цена, берите хетцнер не задумываясь. Маловероятно, что сможете найти что-то лучше по соотношению цена/предоставляемые ресурсы. Там свои заморочки, конечно, но если к ним готовы - все будет хорошо.
трафик можно отдельно оговаривать с хостером, который будет проксирующий вдс предоставлять.
да и вдс же несколько можно (и желательно так делать) брать.
идея не моя - собственно, практически стандарт для размещения подобных ресурсов.
А почему бы не воспользоваться классической схемой с хранилищем и прокси через один или несколько вдс в разных локациях? Выбор технологий и деталей исполнения также довольно широк.
Дороже, согласен.
Но и плюсы очевидны - о расположении хранилища никто не знает, абузы идут на контакт вдс, который выступал в роли прокси в момент анализа контента правообладателем либо на контакт вдс, где лежит сайт (зависит от конкретной схемы реализации)
Необходимости реагировать на абузы это, правда, не отменяет.
Хостеру, который разместит ваше хранилище такой вариант тоже, уверен, покажется намного более спокойным - а это, как ни крути, сильно влияет на продолжительность и продуктивность сотрудничества.
Тогда рискну предположить, что лучше побольше ядер иметь.
Если ресурсоемкая задача захватит 100% ресурсов единственного ядра, работа с другим софтом по определению будет в этот момент некомфортной.
Все это, конечно, лечится расстановкой приоритетов процессов - но это дополнительные телодвижения.
