и ругать наши компании сложно, они работают в такой нервной коррумпированной обстановке, а то еще и показательные "маски шоу" со стороны властей против какого-нить блогера хостившегося и т.п. :D
вау, культурно и грамотно! - а мы с DLag'ом тут это же самое раздули на несколько страничек! 🚬
только надо еще добавить, допустим есть кучка файлов (5-6 тыс.), в случае с XEN мы имеем индивидуальный дисковый кеш на эти 5-6 тыс. файлов, в случае OpenVZ мы имеем один общий кеш ноды... - следовательно нет оверхеда по "кешированию", аналогично с файл. дескрипторами, сетевым стеком и прочими вещами, т.е. как минимум 20% оверхеда идет от XEN
т.е. при равных условиях клиент покупающий OpenVZ решение получит более производительную платформу для своих сайтов 😎
если хостер жаден до денег, то путем двойной виртуализации можно реализовать некое подобие "мягких лимитов", просто т.е. выделить ОЗУ на 8Гб, при реальном его количестве в 4Гб, следовательно пока реальное использование ОЗУ не перевалит 4Гб, все ВПСки будут бегать относительно сносно, и даже в XEN будет казаться что ОЗУ реально больше в 2 раза :D
не все ОЗУ используется интенсивно, бывает просто возникает утечка памяти в малоактивном процессе и в этом случае swap сыграет положительную роль...
да, почитайте как они отвечают своим бывшим клиентам и спросите себя о том, нужно ли Вам такое отношение к себе?! 🚬
ужос, да вопрос уже не в этом, ... я согласен с Вами, что в у рунете такое решение будут предлагать в разы дороже чем даже 2-3 годичной "старости" бюджетный дедик...
просто мне интересна тенденция использования inCase кластера машин на Intel Atom, т.е. по сути один ящик может содержать 32-64 машины, и один общий NFS/iSCSI сторадж...
а по поводу производительности стораджа, ну можно с уверенностью сказать, что будет выше чем 5-6 летней давности 40Гб IDE диск в старом сервере, единственный минус - это позиционирование, в многодисковых RAID решениях оно безусловно страдает, но при условии использования SSD (это конечно пока дорого, но уже начинает внедрятся) - этот минус уже не так заметен...
а по ценам - вот в соседней ветке было про то, что чел отваливает 2.4к RUR в месяц за V.I.P. хостинг, пр этом 700 уников\сутки форум не тянет, антиддоса нет, ничего можно сказать нет (типичный подход "жирной" компании, у котором задача с одного дедика получить стократную окупаемость)...
ужос, Вам говорят, что хостер размещающий 100 VE'шек на ноде с 2Гб ОЗУ, без проблем будет делать тоже самое с XEN, вопрос производительности это другой вопрос, кстати оверселленные таким образом XEN'ки будут не намного "тише" чем дико тормозная нода на OpenVZ, с диким iowait'ом, когда при простое LA уже составляет 5 единиц - я такое реально наблюдал у доблестных xUSSR хостеров и не раз наблюдал :D
нет никакой ошибки, все равно будет выполняться через apache:apache, решения выше уже описали, самое безболезненное для скриптов - это mpm-itk, самое простое для DA - это собирать PHP как CGI, но там сразу возникнут косяки со скриптами... как минимум придется все права на .php файлы выставлять + проверять .htaccess'ы на наличие mod_php директив :)
да но какое это хорошее решение... т.е. вы получаете уже не VPS'ку, а реальную железку, причем это даже интереснее и "вкуснее" чем дешевый б\у дедик с "убитыми" IDE дисками 😂
не выдергивайте слов из общего контекста, я лишь хотел сказать, что жадный хостер, делающий оверселл на OpenVZ, будет делать оверселл и по XEN, т.е. все реально, для этого не надо открывать Америку или лететь на Луну...
т.е. не надо рассматривать XEN как идеальное решение, которое в корне не допускает оверсел :D
вот и я задумываюсь - насколько перспективно это решение...
а вообще там доходит уже до того, что в одном 4U ящике расположено с десяток Micro-ATX решений, на которые подается всего один молекс на 12В (решение на том же Intel Atom жрет не более 20W),... т.е. мат. плата размером с видеокарту, ... дисковая подсистема сетевая (хранилище), ... БП в самом 4U ящике парочка, один БП питает несколько мат. плат... некий такой кластер машин в одной коробке :)
а я о чем, - т.е. гляньте тарифы, гляньте саму "структуру" данного решения, т.е. это некий такой промежуточный шаг между XEN и реальным сервером...
XEN ВПСка при активной работе со свопом (разумеется у него свой своп, но диск то жесткий не свой, он общий), вообщем работа со свопом сильно использует "позиционирование" на диске, что практически в разы роняет производительность дисковой системы, следовательно 5-6 свопящихся XEN сред могут привести к серьезному iowait'у по диску на самой ноде...
как я писал выше, XEN можно оверселлить, достаточно лишь над XEN использовать виртуальную среду, ... т.е. за 30 минут можно реализовать нечто подобное на QEMU контейнере, в котором запущен линух с XEN ядром и куча контейнеров внутри него...
при условии, что многие аппаратные виртуализации могут предоставить возможность указать фиктивное количество ОЗУ, то это позволит на практике реально оверселлить XEN ... т.е. опять же вопрос в порядочности хостера :)
я же написал - хулиганы и девелоперы, т.е. испытание софта, системы контроля версий, ну и самый распространенный случай - это VPN тунеллирование, т.е. 64Мб ОЗУ хватает для этих целей выше крыши... и в данном случае XEN будет более предпочтителен, так как под OVZ в виду общего ядра реализовать многие вещи как VPN/L2TP будет весьма затруднительно (в случае с масс-VPS-хостингом просто нереально)
удалил дубль сообщения...
