Информация

Дата основания
Местоположение
Россия
Сайт
www.hostkey.ru
Численность
11–30 человек
Дата регистрации

Блог на Хабре

Обновить
0
Рейтинг

Тестируем VPS на базе сервера KVM с томами, подключенными по iSCSI c файлера NexentaStor

Блог компании HOSTKEY
Мы в HOSTKEY недавно запустили новый сетевой файлер на базе NexentaStor для целей виртуализации и представилось время субботним вечером протестировать работу виртуальных машин на базе системы виртуализации KVM.
Мы проверим быстродействие процессора, сети и диска с картинками и размышлениями, зная что за инфраструктура стоит за этим.


Итак, наша тестовая нода KVM собрана на базе сервера Intel SR1690WBR, там стоит 2 процессора Xeon E5607 2,26GHz, 64Гб памяти и SSD диск загрузки гипервизора и жесткий диск, куда KVM любит свопить редко используемые блоки памяти. Все это подключено через 1Gbps Ethernet к нашему файлеру на NexentaStor, параметры которого подробно описаны в этом посте. Процессоры не специально подобранные, а были в запчастях. Обычно мы используем ноды в три-четыре раза крупнее для этих задач. Типовая нода имеет 196Гб памяти и два 6 ядерных процессора E5645 или E5-2630. Второй гигабитный порт смотрит в мир Интернет.

На ноде стоит старый добрый KVM, которым управляет SolusVM.
Развернем себе крупную виртуалочку:



Обратите внимание на тонкий базовый том размером в 7Тб — это с Нексенты смонтирован по iSCSI том виртуального размера в 7Тб, а на нем сделан с помощью LVM том для хранения виртуалок. Если что-то пойдет не так с нодой, то мы перемонтируем диск на свободный сервер аналогичного размера и запустим все виртуальные машины с минимальным простоем.

Итак, у нас есть 1Г памяти, 4 ядра и 1Тб диска (sic!).
проверимся:

[root@testio ~]# free -m
             total       used       free     shared    buffers     cached
Mem:           996        712        283          0        125        460
-/+ buffers/cache:        126        870
Swap:           99          0         99
[root@testio ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/vda1             985G  901G   34G  97% /
tmpfs                 499M     0  499M   0% /dev/shm



теперь посмотрим как это выглядит на Нексенте:


т.е. террабайт мы выделили, а по факту диск мы не заняли. Нексента может не резервировать место, занимать его только когда оно понадобится на деле.

промеряем скорость дисков с помощью fio, как правильно описано тут уважаемым amarao.
[root@testio ~]# cat fio.ini
[readtest]
blocksize=4k
filename=/dev/vda
rw=randread
direct=1
buffered=0
ioengine=libaio
iodepth=16

[writetest]
blocksize=4k
filename=/tmp/xxx
size=900G
rw=randwrite
direct=1
buffered=0
ioengine=libaio
iodepth=16


обратите внимание — у нас 1Тб диск и 900Гб тестовый файл для записи. Это не влезет в кэш Нексенты никак, даже боком. Если файлик сделать меньше, цифры увеличатся.

получим удивительный результат (убрал немного букв):
readtest: (groupid=0, jobs=1): err= 0: pid=4075: Sun Jan  2 01:52:14 2000
  read : io=1307.1MB, bw=28797KB/s, iops=7199 , runt= 46509msec
    clat (usec): min=58 , max=474382 , avg=2202.60, stdev=9679.77
    bw (KB/s)  : min= 1280, max=40624, per=100.00%, avg=29170.78, stdev=10972.45
    lat (usec) : 100=0.01%, 250=0.01%, 500=0.04%, 750=0.28%, 1000=0.73%
    lat (msec) : 2=89.14%, 4=6.86%, 10=1.20%, 20=1.10%, 50=0.51%
    lat (msec) : 100=0.03%, 250=0.03%, 500=0.05%
  cpu          : usr=4.79%, sys=18.70%, ctx=146562, majf=0, minf=41

writetest: (groupid=0, jobs=1): err= 0: pid=4076: Sun Jan  2 01:52:14 2000
  write: io=473612KB, bw=10190KB/s, iops=2547 , runt= 46478msec
    clat (usec): min=247 , max=1000.7K, avg=6225.70, stdev=20751.20
     lat (msec): min=1 , max=1000 , avg= 6.28, stdev=20.89
    bw (KB/s)  : min=   13, max=14792, per=100.00%, avg=10431.00, stdev=4163.53
    lat (usec) : 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01%
    lat (msec) : 2=0.07%, 4=20.12%, 10=76.81%, 20=0.93%, 50=1.05%
    lat (msec) : 100=0.69%, 250=0.15%, 500=0.12%, 750=0.02%, 1000=0.01%
    lat (msec) : 2000=0.01%



что получается:
Очередь 64: чтение 6200 IOPS и 10ms, запись 1200/44
Очередь 16: чтение 7200 IOPS и 2,4ms, запись 2500/6
Очередь 1: чтение 1260 IOPS и 4ms, запись 727/8

Не будем забывать, что диски у нас смонтированы по iSCSI через обычный Gigabit Ethernet — это верные 1мс в один конец.

Качаем файл с яндекса:
[root@testio ~]# wget ftp://ftp.yandex.ru/centos/6.3/isos/x86_64/CentOS-6.3-x86_64-bin-DVD1.iso
--2000-01-02 02:18:54--  ftp://ftp.yandex.ru/centos/6.3/isos/x86_64/CentOS-6.3-x86_64-bin-DVD1.iso
Connecting to ftp.yandex.ru|213.180.204.183|:21... connected.
Logging in as anonymous ... Logged in!
==> PASV ... done.    ==> RETR CentOS-6.3-x86_64-bin-DVD1.iso ... done.
Length: 4289386496 (4.0G) (unauthoritative)

 1% [>                         ] 69,638,574  10.7M/s  eta 6m 8s   ^C


интерфейс у нас 100М, раскачивается ровно в полку.

По быстродействию многоядерного процессора на Линуксе сложно однозначно задать систему координат для сравнения, если кто знает как это сделать — подскажите. В Винде я обычно ориентируюсь на Passmark Performance test, так как там есть бенчи практически всех процессоров этого века.

Вывод /proc/cpuinfo:
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 13
model name      : QEMU Virtual CPU version (cpu64-rhel6)
stepping        : 3
cpu MHz         : 2266.638
cache size      : 4096 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 4
wp              : yes
flags           : fpu de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 ht syscall nx lm unfair_spinlock pni cx16 hypervisor lahf_lm
bogomips        : 4533.27
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

и так еще 3 раза. Ядер на виртуалку можно сделать до 8.

То есть, в сухом остатке:

1) производительность дисковой подсистемы виртуальной машины на базе iSCSI файлера Nexenta примерно в 70 и более раз быстрее чем на пара дисков в RAID1 на SATA. У нас часто любят брать в аренду сервера на X3440 или E3-1230, ставят туда 32Гб памяти и 2 диска по 2Гб. Нарезают мелко на 30-50 виртуалок и продают недорого. Там может быть не более 200 IOPS на всех, остерегайтесь подделок. Просите тест и проверяйте с помощью fio.

2) Тонкое выделение и дедупликация — использование современного файлера позволяет нам сильно экономить на дисковых массивах, что сказывается на цене для пользователя самым хорошим образом.

3) использование KVM исключает грязный овер-комитмент системы. Сколько памяти выделено на виртуалку, столько она и получила. Память сейчас в магазине недорогая и ставить ее можно много, нет смысла экономить.

4) Мощность и быстрота современных процессоров позволяет ставить на одну ноду до 200 машин — 6 ядерные 12 поточные процессоры так быстро разгребают очередь задач, что редко можно увидеть регулярную нагрузку больше 50-60% по процессорам. Это тоже влияет на цену самым прямым образом.

5) с помощью iostat на ноде видно как на ладони, какая виртуалка как гоняет свой кусок LVM. Нарушители и абузеры, создающие паразитную нагрузку в течение длительного времени могут быстро идентифицироваться и переводится в специальный загон, где они не причиняют вреда соседям.

6) больше IOPS — меньше удельная нагрузка на файлер и ноду. Приложения работают быстрее, больше тиков процессора остается свободным.

Надеюсь, это будет полезно читателю если у него возникнет необходимость взять себе несколько виртуалок для дела. Желаете потестить сами? Обращайтесь, тест-драйв на неделю бесплатно.
Теги:хостингвиртуализациявиртуальная машинаKVMSolusVMNexentaHostkeyVPSvps хостинг
Хабы: Блог компании HOSTKEY
Рейтинг +2
Количество просмотров 8,5k Добавить в закладки 27
Комментарии
Комментарии 24

Похожие публикации

Лучшие публикации за сутки