Почитал тут немного, действительно вместо переключений контекса openvz следит за попытками использовать чужую память и просто ограничивает в случае необходимости.
В таком случаем более уместно сравнивать паравиртуализацию на xen c openvz, а не эмуляцию аппаратной части в xen c openvz.
Я не про процессы, а про отсутствие переключения контекстов.
Не разбирался, но по моему, утвержение безосновательное ибо слабо представляю как же так безопасно заставить работать много контейнеров в пределах одного адресного пространства, чтобы не было переключения контекстов между задачами.
Поэтому процесс, запущенный в Xen и KVM всегда будет работать медленнее, чем в OpenVZ
Вовсе необязательно. Если посмотреть на технологию сбоку, то разницы нет, везде двухэтапная планировка выполнения задачи (сначала в гостевой ОС и потом в гипервизоре) и никаких дополнительных технологий по ускорению выполнения задачи у OpenVZ нет.
Думается мне, что если Вы возьмете виртуалку на xen и контейнер на OpenVZ, запустите на обоих тестовый код на Си, который будет в цикле считать 1 << 11 несколько млн итераций, то разницы не увидите (при условии, что на гипервизорах не будет сильной конкуренции за ресурсы)
так как нет накладных расходов на запуск гостевых ядер и переключение контекстов
Рискую быть закидынным камнями, но откуда вы взяли такую глупость по поводу отсутствия переключения контекстов?
Хотите сказать что все контейнеры в OpenVZ работают в одном адресном пространстве?
Странно, вроде как Вы и не исключаете возможность сбоя ПО, но приводите такие сценарии где виноват только водитель (в продолжении приведенной Вами аналогии), похоже что движет Вами фанатизм…
Пока умолкаю, как будет информация по инциденту — отпишусь.
Намекаете на то, что это команда администраторов довела СХД до такого состояния, что она очнулась только после ресета?
Отношение к теме самое прямое, количество затраченного на это оборудование бабла и количество полученных проблем в связи с ее введением в эксплуатацию, по моему мнению, не позволяют назвать NetApp FAS3240 лучшим решением.
Буквально недавно NetApp FAS3240 сбойнул, лежала вся инфраструктура на vSphere 4.1 около 10часов.
Глюканул один контроллер который был в кластере NetApp…
Не думаю, что отечественные ботоводы сильно парятся о географии своего ботнета, более того им выгодно иметь ботов из СНГ+РФ т.к. именно днем у этого ботнета будет пик онлайн.
На счет никогда не гадь там где живешь, это скорее на про нас…
Да, было-бы интересно услышать как планируется различать клиентов.
Самый верный вариант это делать на уровне приложения, хотя-бы при помощи этих несчастных кук, но появляются риски сталкнуться с ботами которые зафлудят всю таблицу состояний этими куками.
За что заминусовали, на графики кто-нибудь смотрел?
В таком случаем более уместно сравнивать паравиртуализацию на xen c openvz, а не эмуляцию аппаратной части в xen c openvz.
Таки попробую и проверю.
Не разбирался, но по моему, утвержение безосновательное ибо слабо представляю как же так безопасно заставить работать много контейнеров в пределах одного адресного пространства, чтобы не было переключения контекстов между задачами.
Вовсе необязательно. Если посмотреть на технологию сбоку, то разницы нет, везде двухэтапная планировка выполнения задачи (сначала в гостевой ОС и потом в гипервизоре) и никаких дополнительных технологий по ускорению выполнения задачи у OpenVZ нет.
Думается мне, что если Вы возьмете виртуалку на xen и контейнер на OpenVZ, запустите на обоих тестовый код на Си, который будет в цикле считать 1 << 11 несколько млн итераций, то разницы не увидите (при условии, что на гипервизорах не будет сильной конкуренции за ресурсы)
Рискую быть закидынным камнями, но откуда вы взяли такую глупость по поводу отсутствия переключения контекстов?
Хотите сказать что все контейнеры в OpenVZ работают в одном адресном пространстве?
Пока умолкаю, как будет информация по инциденту — отпишусь.
На деле иначе, купленный тестем мерседес заглох на полпути к дому.
Отношение к теме самое прямое, количество затраченного на это оборудование бабла и количество полученных проблем в связи с ее введением в эксплуатацию, по моему мнению, не позволяют назвать NetApp FAS3240 лучшим решением.
Глюканул один контроллер который был в кластере NetApp…
На счет никогда не гадь там где живешь, это скорее на про нас…
Иными словами просто анализируете черный список?
Самый верный вариант это делать на уровне приложения, хотя-бы при помощи этих несчастных кук, но появляются риски сталкнуться с ботами которые зафлудят всю таблицу состояний этими куками.