LINUX.ORG.RU
ФорумAdmin

как лучше отдать swap виртуальным машинам?

 , ,


0

2

Есть тестовый сервак с centos. На нем поднята система виртуализации на основе kvm. Памяти 8 гиг. Винтов 2 штуки по 80 гиг и 4 по 250гиг. Как правильно настроить swap для гипевизора и гостей используя LVM-based storage pools?

Я сделал так: Настроил аппаратный raid1 из двух винтов по 80 гиг (под сам сервер) и аппаратный raid 10 из остальных под storage pool для виртуалных машин. Потом отрезал кусочек из raid1 под boot, а остальное под 2 физических тома (vms - для гостей и vghost - для гипервизора). Вывод сокращен

[root@centos-kvm-0 ~]# pvdisplay
  --- Physical volume ---
  PV Name               /dev/cciss/c0d1
  VG Name               vms
  PV Size               465,71 GiB / not usable 2,18 MiB
   
  --- Physical volume ---
  PV Name               /dev/cciss/c0d0p2
  VG Name               vg_host
  PV Size               73,91 GiB / not usable 3,00 MiB

Под гипервизор отдал swap 16 гигов (удвоенный объем памяти), создав Logical volume из группы vg_host. Системные диски для виртуалок нарезал создавая Logical volume из группы vms. swap для виртуалок нарезал создавая Logical volume из группы vghost в объеме удвоенного количества оперативки.

в итоге получилось так (для читабельности вывод сократил):

[root@centos-kvm-0 ~]# lvdisplay
  --- Logical volume ---
  LV Path                /dev/vms/vds1
  LV Name                vds1
  VG Name                vms
  LV Size                8,00 GiB
   
  --- Logical volume ---
  LV Path                /dev/vms/vds2
  LV Name                vds2
  VG Name                vms
  LV Size                30,00 GiB

   
  --- Logical volume ---
  LV Path                /dev/vg_host/lv_root
  LV Name                lv_root
  VG Name                vg_host
  LV Size                11,72 GiB
   
  --- Logical volume ---
  LV Path                /dev/vg_host/lv_swap
  LV Name                lv_swap
  VG Name                vg_host
  LV Size                17,58 GiB

  --- Logical volume ---
  LV Path                /dev/vg_host/isos
  LV Name                isos
  VG Name                vg_host
  LV Size                4,00 GiB
   
  --- Logical volume ---
  LV Path                /dev/vg_host/swap_vds1
  LV Name                swap_vds1
  VG Name                vg_host
  LV Size                2,00 GiB
   
  --- Logical volume ---
  LV Path                /dev/vg_host/swap_vds2
  LV Name                swap_vds2
  VG Name                vg_host
  LV Size                4,00 GiB
 

Знаю, что наверное для swap я дал лишнего

★★★★★

Под гипервизор отдал swap 16 гигов (удвоенный объем памяти)

Если тачка активно свопится то работать она не будет. Правда, есть шанс что в своп упадёт ненужный мусор....

Я настраиваю машину следующим образом. Я считаю что своппинг это зло и поэтому бюджет оперативки планируется заранее. Для особых случаев есть своп на пару гиг на мастер-машине и по 100 метров в виртуалках. Потом выставляю vm.swappiness = 20 и отдаю виртуалкам столько оперативы сколько мне кажется им нужно. Результат проверяю небольшим нагрузочным тестированием. Внутри виртуалок размеры кэшей БД итп подтюнены под размер выделенной оперативки.

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

Если тачка активно свопится то работать она не будет. Правда, есть шанс что в своп упадёт ненужный мусор....

Во первых мусор, во вторых можно использовать SSD, или SAN/NAS с кешированием (возможно, двухуровневым RAM->SSD->HDD).

ktulhu666 ☆☆☆ ()
Ответ на: комментарий от true_admin

Ко всему прочем ты не рассматриваешь ситуацию, когда бОльшая часть виртуалок и есть мусор (к ним редко обращаются и то только к конкретному процессу).

ktulhu666 ☆☆☆ ()
Ответ на: комментарий от ktulhu666

Своппинг это тормоза в непредсказуемый момент, зачастую неподходящий. Я неоднократно видел как из-за большого свопа тачка которая «летала» дико лагала в момент перезапуска сервисов (например, большой БД) итп. Даже с ssd. Своп на пару гиг, имхо, погоды не делает (дешевле рамы докупить), а большого объёма (хотя бы гиг на 8) ssd быстро не прокачает. Чтобы мусор упал в своп нужен высокий swappiness. Но только ОС не знает какие страницы мусор, а какие нет. Поэтому это в любом случае бьёт по производительности.

Вот поэтому я стараюсь ставить избыточное кол-во оперативы и маленький своп :).

Хотя я могу представить один вариант когда можно загнать всё в своп. Это когда есть куча сервисов которые редко нужны. Например, куча редко используемых виртуалок. Если их тормоза при первом обращение это не проблема то почему бы и не загнать их в своп.

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

Хотя я могу представить один вариант когда можно загнать всё в своп. Это когда есть куча сервисов которые редко нужны. Например, куча редко используемых виртуалок. Если их тормоза при первом обращение это не проблема то почему бы и не загнать их в своп.

Именно это я имел в виду. Либо когда есть «умное» начальство и «оптимизирующий» расходы фин отдел.

Вот поэтому я стараюсь ставить избыточное кол-во оперативы и маленький своп :).

Это, бесспорно, правильно (вообще оперативы должно быть даже с запасом), но правильно только с точки зрения «обычно в таком объеме используется». Не забывай, что для гибернации нужно минимум 90% от размера RAM (в учетом сжатия и выгрузки кеша) + то, что уже свалилось в своп. К тому же такой подход даст возможность серверу долго не падать при утечках памяти.

ktulhu666 ☆☆☆ ()
Ответ на: комментарий от true_admin

А что касательно сжатия? Сейчас есть хоть какие-нибудь нормальные решения для ускорения работы FS/свопа за счет сжатия? ZFS жрет столько оперативы, что ппц, а btrfs тормозит и падает. Мне импонируют только блочные устройства с поддержкой сжатия, но они дадут только выигрыш в скорости, но не в месте (касаемо ФС).

ktulhu666 ☆☆☆ ()
Ответ на: комментарий от ktulhu666

для гибернации нужно минимум 90% от размера RAM

Хм, с компрессией и vm.drop_caches=1/2/3 у меня оно в 30-50% укладывалось, но я не забиваю своп и не держу шибко тяжёлых приложений потому что иначе на 4-8 гигах оперативы гибернация (и пробуждение) идёт относительно долго даже на ssd.

долго не падать при утечках памяти.

Мониторинг, только мониторинг. Потому что если течёт то рано или поздно оно упадёт.

true_admin ★★★★★ ()
Ответ на: комментарий от ktulhu666

Сейчас есть хоть какие-нибудь нормальные решения для ускорения работы FS/свопа за счет сжатия?

Не в курсе, если честно. Я не люблю городить огород на блочном уровне (аля стэк из mdraid+lvm+crypto+fs+ещё что-нить) потому что админить сложнее в случае проблем (замена диска, повреждение фс). А с фс я на время перестал экспериментировать. Я раньше надеялся на btrfs, но, имхо, это пока не вариант. Да и у меня данных мало. Мне 500гиг на сервере хватает с большим запасом. А медиа-файлы (что обычно занимает больше всего места) и так уже ничем не пожмёшь.

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

Я не люблю городить огород на блочном уровне (аля стэк из mdraid+lvm+crypto+fs+ещё что-нить)

А я очень люблю. Причём всё стабильно работает и ни раз дало возможность без проблем расшириться или переехать. Но я только дома этим занимаюсь.

Я раньше надеялся на btrfs, но, имхо, это пока не вариант.

Боюсь, что это уже никогда не вариант. Есть ощущение, что Oracle поддерживает разработку btrfs только того, чтобы показать, что можно юзать только ZFS.

ktulhu666 ☆☆☆ ()
Ответ на: комментарий от true_admin

Ну я так понял, что виртуалкам надо выделить совсем мало свопа, а может и вообще нисколько. В доках redhat про своп для виртуалок ничего путного не нашел, зато там четко сказано сколько памяти давать гипервизору.

andrew667 ★★★★★ ()
Ответ на: комментарий от andrew667

Лучше всего выдавать в соответствии с собственным опытом и поставленными задачами :)

ktulhu666 ☆☆☆ ()

Я полагаю все должно зависеть от:

  • Задач которые работают на сервере;
  • Как эти задачи используют память.

Я считаю что swap надо избегать, кроме некоторых случаев, задействование swap приведет к тормозам. Отсюда, swap должен быть на быстрых дисках, но ИМХО оперативная память дешевле, конечно надо учитывать, что материнские платы под много памяти дорогие. Но тут либо шашечки, либо ехать. Я разделяю мнение true_admin.

petav ★★★★★ ()
Последнее исправление: petav (всего исправлений: 1 )
Ответ на: комментарий от true_admin

а как ты своп виртуалкам отдаешь? нарезаешь маленькие разделы с помощью LVM и скармливаешь этот диск виртуалке?

andrew667 ★★★★★ ()
Ответ на: комментарий от petav

Я-то тоже с этим согласен. Но в суровых реалиях железо уже год жду серваки новые. В старые хрен кто памяти добавит. Имеющееся железо не все используется рационально, поэтому решил консолидироваться на том что есть и грамотно все настроить. Может и высвободится 1-2 физических сервера.

andrew667 ★★★★★ ()
Ответ на: комментарий от andrew667

У меня виртуалки в обычных файлах лежат. Обычно я отдаю первые 100-1000 метров раздела под своп. В этом есть особый умысел: если надо будет от начала откусить место для загрузчика или ещё чего то я подрезаю своп.

В твоём случае я может и не стал бы заморачиваться с отдельным разделом под свой и создал бы просто файл в корне. Но я не думаю что это на что-то сильно влияет.

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

я правильно понял, что ты делаешь разбивку на парочку разделов в этих файлах и уже потом отдаешь своп-раздел виртуалке?

Касательно отдельного раздела для загрузчика на виртуальном сервере я смысла не вижу. Делаю загрузочным /, а второй раздел или диск под своп. Впрочем я ж это выше расписал.

andrew667 ★★★★★ ()
Ответ на: комментарий от andrew667

ты делаешь разбивку на парочку разделов в этих файлах и уже потом отдаешь своп-раздел виртуалке?

Делаю как-то так:

dd if=/dev/zero of=virt.raw bs=1M count=20480
parted virt.raw
kvm -cdrom arch.iso -hda virt.raw -curses ...

я смысла не вижу.

это мои заморочки. Для gpt нужен отдельный раздел с грабом. Но теперь я везде использую msdos разбивку потому что это железобетонно работает.

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

Если памяти на серваке (гипервизоре) значительное количество - 64ГБ, то ты все равно под своп немного отдаешь (пару гигов)? С виртуалками понятно - им по чуть-чуть из файла даешь.

Если интересно, то я запускаю установку скриптом, например

virt-install -n vds2 -r 2048 --disk path=/dev/vms/vds2 --disk path=/dev/vg_host/swap_vds2 -c /srv/iso/ubuntu-10.04.4-server-amd64.iso --vnc  --os-type linux --os-variant=generic26 -v --accelerate --network=bridge:brvlan199 --network=bridge:brvlan1102 --hvm

Читал доки по виртуализации от красношапки и статейки inkvizitor68sl. Для старта в принципе достаточно. Только с сеткой я мучился - на бонд vlanы кидал. На гипервизор даже айпишники из сетки в нужном vlan цеплять не нужно. С учетом mpls-сети получается очень удобно разруливать всякие штуки.

andrew667 ★★★★★ ()
Ответ на: комментарий от andrew667

то ты все равно под своп немного отдаешь (пару гигов)?

своп нужен всегда, некоторые подсистемы ядра подразумевают что он ненулевого размера, хотя тут и пишут что «а вот на моём десктопе проблем нет». По поводу кол-ва единого мнения, как видишь, нет. Точно не в два раза. Я только не понимаю, «память под гипервизор» это что? То что не будет доступна виртуалкам?Если у тебя на гипервизоре много софта не крутится то гипервизору много памяти вообще не нужно, тем более свопа.

Честно сказать я про память писал исходя из своего опыта с kvm, нюансов управления xen я не знаю. Но, с учётом того что у тебя lvm и ты можешь почти динамически менять размер свопа, разумно будет просто поиграться с параметрами системы и посмотреть что будет при разных сценариях.

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

Я только не понимаю, «память под гипервизор» это что?

Я имел в виду хостовую машину (ту, на которой будут запускаться виртуальные). Я не совсем еще разобрался со свопом, поэтому у меня были мысли такие: Делаю своп на хостовой машине (как минимум объем оперативки). И в идеале чтобы этот своп был доступен виртуалкам. Самим виртуалкам ничего дополнительно не подсовывать. А если делать таким макаром как я (большой своп хосту и отдельно еще каждой вируалке), то на своп идет слишком много места, но если что я буду спокоен.

P.S. С xen у меня вообще опыта нету. Решил осваивать kvm

andrew667 ★★★★★ ()
Последнее исправление: andrew667 (всего исправлений: 1 )
Ответ на: комментарий от andrew667

И в идеале чтобы этот своп был доступен виртуалкам.

Ааа, общий пул дисковой памяти для свопа? Думаю что это фантастика. Но у них есть balooning для памяти, это когда виртуалка запускается с небольшим объёмом памяти, а потом раздувается по мере надобности. Но с этим надо быт осторожным, приложения могут упасть раньше чем увеличится память. По крайней мере это пишут для xen. Возможно, ядро уже научилось замораживать процессы пока память не будет увеличена. Ну или пока явный отлуп не придёт что «больше памяти нету» :).

PS про то что своп должен быть всегда я не с ходу могу найти инфы, сорри. А жаль, хотелось бы ещё раз посмотреть на аргументы сторон. В гугле есть старые ссылки, но они нерепрезентативны.

true_admin ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.