Здравствуйте. Собственно, вопрос в следующем. Как спрятать от пользователя контейнера информацию о физических ресурсах физического сервера? Т.е. чтобы, например, cat /proc/cpuinfo выдавало бы что-нибудь "левое".
Я не знаю, такого способа. Уверен, что без серьезных изменений в коде вы такое не сделаете. Да и не зачем обманывать своих клиентов!
Спасибо за ответ. Хотелось бы уточнить, что пользователя обманывать никто не собирался. Требовалось, наоборот, настроить вывод под параметры самого контейнера, а не физического сервера.
А в чем расхождение от того, что заявлено в тарифе?
Сейчас он видит, например, что на сервере восемь процессоров. А он должен увидеть только один.
Вы через панель создаете VE? Или в консоли? А если так: vzctl set <VEID> --cpus 1 --save Сколько видит?
Через консоль. Но через CPUs я уже пробовал. Все равно cat /proc/cpuinfo выдаст наличие восьми процессоров.
В нормально ситуации пользователь внутри VE должен видеть именно сколько CPU, сколько ему выделено. -- Можете показать полностью конфиг для контейнера? -- Версия OS и ядра HN? -- OS внутри VE?
Конфигурационный файл контейнера: ONBOOT="yes" ALLOWREBOOT="yes" # UBC parameters (in form of barrier:limit) KMEMSIZE="31457280:34603008" LOCKEDPAGES="384:384" PRIVVMPAGES="79920:81920" SHMPAGES="21504:21504" NUMPROC="320:320" PHYSPAGES="0:9223372036854775807" VMGUARPAGES="24576:9223372036854775807" OOMGUARPAGES="79920:9223372036854775807" NUMTCPSOCK="360:360" NUMFLOCK="188:206" NUMPTY="1024:1024" NUMSIGINFO="256:256" TCPSNDBUF="1720320:2703360" TCPRCVBUF="1720320:2703360" OTHERSOCKBUF="1126080:2201280" DGRAMRCVBUF="262144:262144" NUMOTHERSOCK="420:420" DCACHESIZE="3409920:3624960" NUMFILE="5120:5120" AVNUMPROC="160:160" NUMIPTENT="160:160" SWAPPAGES="0:9223372036854775807" # Disk quota parameters (in form of softlimit:hardlimit) DISKSPACE="15728640:15728640" DISKINODES="200000:220000" QUOTATIME="0" QUOTAUGIDLIMIT="0" # CPU fair sheduler parameter CPUUNITS="31650" CPULIMIT="4" VE_ROOT="/vz/root/$VEID" VE_PRIVATE="/vz/private/$VEID" OSTEMPLATE="debian-6.0-amd64-minimal" ORIGIN_SAMPLE="practical" CPUS="1" HardwareNode: # uname -r 2.6.32-openvz-dzhanibekov.1-r1 Контейнер, соответственно, Debian 6
Может все-таки проблема с Debian 6? Сюдя по другим проблемам, о которых Вы писали, на ее базе? В других контейнерах проблема наблюдается?
Это нормально. Лимитирование cpus и cpulimit в ядрах свежее 2.6.18 не работает. И это не очень надо на самом деле. Предполагаю, что проверка лишних лимиов только лишние ресурсы кушает и снижает общую производительность. Жалко вам ядер? Они все равно ведь есть
Если лимитирование не работает, то как тогда ограничить использование процессора(-ов) отдельным контейнером, используя OpenVZ? Исключительно через CPUUNITS? Или это тоже не работает? Раньше писал о проблеме с темплейтом Ubuntu 8.04. И проблема была в том, что архив был битый. Попробовал на другом темплейте (CentOS 5). Результат не изменился.
Может стоит попробовать обновить ядро? На странице http://wiki.openvz.org/Download/kernel/2.6.32/2.6.32-dzhanib ekov.1 написано: Quote: Warning: this is an old version of 2.6.32 kernel. For the latest version, see Download/kernel/2.6.32/2.6.32-feoktistov.1. У нас правда 2.6.18, там все работает в этом плане корректно.
Сегодня начал с того, что обновил ядро. Теперь: # uname -r 2.6.32-openvz-feoktistov.1 Только ничего не изменилось.
Brain89 wrote on Thu, 31 March 2011 09:58 как тогда ограничить использование процессора(-ов) отдельным контейнером На самом деле важнее не ограничить а распределить имеющиеся cpuunits Но если таки надо ограничить, то обновлятся надо на http://wiki.openvz.org/Download/kernel/rhel5/028stab085.3 Quote: Хм... а разве 2.6.32 свежее 2.6.18? Конечно свежее, ибо ветка 2.6.32 появилась позже и имеет больший номер. Или как вы определяете свежесть? Мне кажется так - сегодняшняя рыбка свежее вчерашней
Ага, Вы правы. Конфуз небольшой вышел. Видимо прочитал неверно, а именно прочитанное понял, как «до ядра 2.6.18 заявленный функционал не работает».
А в чем разница между "распределить" и "ограничить"? Допустим, у меня 10 контейнеров и HN. Между ними надо раздать ресурсы так, чтобы HN получал их в 2 раза больше. Пусть всего CPUUNIT'ов у меня 120000. Тогда каждому CT надо выставить параметр равным 10000 unit'ам. Получается и распределили, и ограничили. Или я что-то не так понял?
Quote: А в чем разница между "распределить" и "ограничить"? Распределить это значит - при запросе процесса на ресурс поставить его в очередь на ресурс и при очередной процедуре распределения этого ресурса выделить процессу часть ресурса в состветсвии с неким алгоритмом одинаковым для всех. Ограничить это значит - при каждом запросе ресурса выполнять дополнительные действия по проверке заданных лимитов по списку для каждого VPS, если лимит превышен, отклонить запрос или снова поставить в очередь. Из мануала: Quote: CPUUNITS число Bogomips, умноженное на 25. Отчетные инструменты Open VZ (reporting tools) приравнивают 1 GHz PHI Intel processor к 50 000 единицам CPU. Но CPUUNITS только гарантирует нижний предел возможностей для VPS. Чтобы выделялось больше свободных ресурсов тому кто в нем нуждается лучше поставить CPUUNITS меньше чтобы свободных было больше и было больше возможностей для распределения. Было бы правильно взвешивать приоритет каждого процесса по количеству CPUUNITS для VPS при распределении CPU, но мне кажется это не работает. Здесь тупо учитывается только nice и ionice для процесса. И они равны для всех если не переназначить. Но я могу и ошибаться, плотно не изучал этот момент. Quote: чтобы HN получал их в 2 раза больше Для этого в /etc/vz/vz.conf есть параметр VE0CPUUNITS, поставьте там 20000
Попытки сборки ядра 2.6.18 закончились неудачей (ошибка make, попытки выяснить, в чем именно дело, закончились ничем). Видимо, собирать эту версию ядра надо не на свежеобновленной системе. На счет приоритезации процессов контейнера тоже думал. Хотелось все сделать средствами OpenVZ, но, видимо, надо либо ставить систему с нуля с ядром 2.6.18 , либо смотреть в сторону механизма Cpuset применительно к процессам контейнера.
Brain89 wrote on Fri, 01 April 2011 10:46 Попытки сборки ядра 2.6.18 закончились неудачей . Поставьте бинарную версию 2.6.18. Я уже писАл здесь как это делается http://forum.openvz.org/index.php?t=msg&goto=35365&& amp;srch=mkinitramfs#msg_35365
Если честно, совсем не понял, как бинарную версию ядра поставить под Gentoo... Если это совсем банально и я просто что-то неверно понял, извините заранее за ламерство.
Brain89 wrote on Mon, 04 April 2011 13:30 как бинарную версию ядра поставить под Gentoo.. Да, в генте нет initramfs-tools и нет alien Используйте вместо alien - rpm2tarbz2 В debian есть initramfs-tools, в gentoo -- genkernel Подробно описывать не стану, некогда. Разберетесь сами, документация общедоступна Это несложно.