Меню Рубрики

Установка vmware на quemu

Запускаем VMWare ESXi 6.5 под гипервизором QEMU

На свете существует замечательный гипервизор ESXi от компании VMWare, и все в нем хорошо, но вот требования к “железу”, на котором он может работать, весьма нескромные. ESXi принципиально не поддерживает программные RAID’ы, 100-мегабитные и дешевые гигабитные сетевые карты, поэтому попробовать, каков он в работе, можно только закупившись соответствующим оборудованием.
Однако ESXi самые “вкусные” возможности ESXi открываются тогда, когда у нас есть не один, а несколько хостов ESXi — это кластеризация, живая миграция, распределенное хранилище VSAN, распределенный сетевой коммутатор и т.п. В этом случае затраты на тестовое оборудование уже могут составить приличную сумму. К счастью, ESXi поддерживает Nested Virtualization — то есть способность запускаться из-под уже работающего гипервизора. При этом и внешний гипервизор понимает, что его гостю нужен доступ к аппаратной виртуализации, и ESXi знает, что работает не на голом железе. Как правило, в качестве основного гипервизора также используется ESXi — такая конфигурация поддерживается VMWare уже довольно давно. Мы же попробуем запустить ESXi, использую гипервизор QEMU. В сети есть инструкции и на этот счет, но, как мы увидим ниже, они слегка устарели.

Для начала обозначим версию QEMU, на которой будем ставить эксперименты:

Последняя на данный момент версия, но у меня фокус получался даже на 2.4.0.
Затем отключим невежливое поведение модуля KVM в моменты, когда гость пытается читать машинно-специфические регистры, которых на самом деле нет. По-умолчанию, KVM в ответ на это генерирует внутри гостя исключение General protection fault, отчего гость ложится в синий (в нашем случае-розовый) экран смерти. Сделаем под рутом:

В некоторых дистрибутивах модуль kvm грузится по умолчанию с нужными параметрами, в некоторых — нет. В любом случае нужно проверить dmesg на наличие строк

Если этих строк нет — добавить в /etc/modprobe.d/kvm.conf строку

и перезагрузиться. Для процессора Intel строка примет вид:

Что интересно — сообщения о включенных Nested Paging/Nested Virtualization в dmesg подает только kvm-amd, а kvm-intel этого не делает.

Попробуем решить проблему “в лоб” — пойдем на сайт VMWare, зарегистрируемся там и скачем последний на данный момент образ VMware-VMvisor-Installer-201701001-4887370.x86_64.iso.

Не будем измудряться, создадим аналог “флешки” на 16Gb, возьмем наверняка поддерживаемую сетевую карту e1000, поставим RAM в 4 Gb (с меньшим количеством памяти ESXi гарантированно не встанет) и запустим установку, полагая, что в такой конфигурации ESXi как минимум не увидит IDE-диска:

И тут нас ждет первая неожиданность — ESXi не только обнаруживает наш IDE-диск, но и успешно ставиться на него, правда, на пять минут подвисая на 27% установки:

Кстати, перед началом установки у меня появляется вот такое сообщение:

Ну, с процессором понятно — я использовал опцию -cpu host, которая копирует CPUID хостового процессора в гостя, а хостовой процессор у меня — AMD A8-3850 APU под почивший сокет FM1. Странно, что ESXi вообще ставится на такое железо.

А вот 8086:100e — это идентификатор чипа “Intel 82540EM Gigabit Ethernet Controller”, который с некоторых пор объявлен unsupported, т.е. он работает, но с ним не работает техническая поддержка.

Вообще, QEMU поддерживает эмуляцию разных сетевых карт:

но не все они работают в ESXi одинаково хорошо, например, с формально поддерживаемым e1000e не работает проброс портов в user-режиме сети, а у vmxnet3 пропадает половина пакетов. Так что остановимся на e1000.

Перезагружаем ВМ и видим, что гипервизор стартовал успешно. Собственно, и все — патчить QEMU для ESXi, как рекомендуют некоторые руководства, не нужно.

Нужно отметить, что я использую параметр nocow=on при создании диска, поскольку диск ВМ будет лежать на btrfs, которая сама по себе является ФС с концепцией copy-on-write. Если добавить к этому то, что и thin-provisioned диск формата qcow2 тоже реализует этот принцип, то получится кратное увеличение числа записей на диск. Параметр nocow=on заставляет qemu-img создавать файл с атрибутом nocow и тем самым блокировать механизм copy-on-write в btrfs для конкретного файла.

В режиме сети user внутри ВМ работает легковесный DHCP-сервер, поэтому адрес присваивать не нужно, однако придется пробрасывать порты. Заходим в консоль QEMU, нажав Ctrl+Alt+1, вводим там команду

и пробрасываем 443 порт с сетевого интерфейса виртуальной машины на 4443 порт хоста. Затем в браузере набираем

подтвердим исключение безопасности (ESXi, понятное дело, пока использует самоподписанный сертификат для https) и увидим Web-интерфейс гипервизора:

Удивительно, но установщик ESXi даже создал в свободной области диска “хранилище” размером целых 8Gb. Первый делом поставим пакет с обновленным Web-интерфейсом, потому что разработка этого полезнейшего компонента идет быстрее, чем выходят новые версии ESXi. Идем в консоль QEMU по Ctrl+Alt+1 и пробрасываем там 22 порт:

потом переключаемся в консоль гипервизора по Ctrl+Alt+2, нажимаем F2 — Troubleshooting Options — Enable SSH и подключаемся клиентом SSH:

Идем во временный каталог

Как видно, размер Web-интерфейса — чуть больше трех мегабайт.

Теперь попробуем улучшить нашу виртуальную машину. Первым делом сменим контроллер дисков с IDE на AHCI, потому что реализация контроллера PIIX3 1996 года выпуска в QEMU, как бы это сказать, слегка тормознутая. А контроллер AHCI (эмулируется чипсет Intel ICH9) во-первых, быстрее, а, во вторых, поддерживает очереди команд NCQ.

Даже по уменьшению времени загрузки компонентов гипервизора видно, что прирост в скорости мы получили. На радостях заходим в Web-интерфейс и… как это нет дисков? На вкладке “Adapters” AHCI-контроллер имеется, однако диски на нем не определяются. А как же тогда загрузился гипервизор? Очень просто — на начальном этапе загрузчик считывает данные диска при помощи BIOS и видеть диски напрямую ему не нужно. После того, как компоненты загружены в память, загрузчик передает на них управление, а инициализация гипервизора проходит уже без обращений к диску.

Как бы то ни было, ESXi 6.5 дисков на AHCI-контроллере не видит, а вот ESXi 6.0 эти диски видел — зуб даю. С помощью Google и такой-то матери выясняем причину: в ESXi 6.5 старый драйвер ahci замене на полностью переписанный драйвер vmw_ahci, из-за чего у кучи народа тормозят SSD, а у нас не определятся диски. Согласно совету из статьи делаем на гипервизоре

перезагружаемся и… ничего не происходит. А чего мы хотели? Дисков-то нет, записывать конфигурацию некуда, следовательно, наши изменения и не сохранились. Надо вернуться на IDE-диск, выполнить эту команду и уже потом загружаться с AHCI — тогда диски определяться.

Кстати, если мы зайдем в web-интерфейс, то увидим, что созданное установщиком 8-гигабайтное “хранилище” теперь недоступно. Так что для разных типов контроллеров VMWare имеет разные политики определения хранилищ. Теперь попробуем изобразить реальную конфигурацию системы, когда ESXi установлен на флеш-накопитель, подключенный по USB, а хранилище располагается на жестких дисках. Используем эмуляцию USB 3.0:

USB 3.0 диски тоже не определяются. Видимо, и здесь драйвер переписан. Ну что ж, мы уже знаем, что делать. Идем в консоль гипервизора, там пишем

Когда система загрузится, зайдем в Storage — Devices и увидим там нашу флешку. Кстати, с USB 3.0 контроллером nec-usb-xhci система загружается намного быстрее, чем с ich9-usb-ehci2.

Итак, минимум два драйвера контроллера диска в ESXi 6.5 переписаны заново по сравнению с ESXi 6.0. А казалось бы — только цифра после точки в номере версии изменилась, можно сказать, минорный релиз.

Если мы добавим к конфигурации виртуальной машины диск объемом 1 Tb, то сможем создать полноценное хранилище в дополнение к диску с гипервизором. Чтобы система грузилась с usb-диска, а не с ahci, воспользуемся параметром bootindex. Обычно для управления порядком загрузки применяют параметр -boot, но в нашем случае он не поможет, потому что диски “висят” на разных контроллерах. Заодно заменим платформу со старого чипсета 440fx на новый Q35/ICH9.

Заходим в консоль — вот они, наши диски.

Продолжим эксперименты: теперь нам нужно объединить несколько гипервизоров в сеть. Какой-нибудь libvirt самостоятельно создает виртуальный коммутатор и подключает к нему машины, а мы попробуем провести эти операции вручную.

Пусть у нас будут две виртуальные машины, значит, нам потребуется два виртуальных адаптера

Теперь нам нужен виртуальный коммутатор. Долгое время для этих целей принято было использовать встроенный в ядро Linux виртуальный коммутатор, управляемый утилитой brctl. Сейчас же принято решать задачу через Open vSwitch — реализацию коммутатора, предназначенную именно для виртуальных сред. Open vSwitch имеет встроенную поддержку VLAN, протоколов туннелирования (GRE и т.п) для объединения нескольких коммутаторов и, что самое интересное — технологии OpenFlow. Иными словами, в коммутатор можно загружать правила фильтрации L2/L3 в удобочитаемом формате. Раньше для фильтрации требовалось использовать iptables/ebtables, а, как говориться, хорошую вещь “ebtables” не назовут.

Установим Open vSwitch, если он еще не стоит:

Читайте также:  Установка usb адаптера на хонда цивик

Создадим виртуальный коммутатор:

Добавим в него интерфейсы:

Теперь присвоим интерфейсу коммутатора адрес:

Казалось бы, достаточно просто изменить тип сети в командной строке QEMU с user на tap, примерно так:

Зайдем в консоль ESXi и присвоим ему адрес — 192.168.101.2, а затем проверим связь:

….
и из консоли ESXi — F2- Test Network

Сделаем копию диска esxi_6.5-1.qcow2 и запустим второй экземпляра ESXi:

Тут нас ждут неожиданности: ping от хоста к первому гостю ходит лишь до того момента, пока мы не запускаем пинг ко второму гостю. После прерывания второй команды ping пакеты к первому гостю начинают ходить секунд через 10. Пинги между гостями не ходят вообще.

Ясно, что мы напортачили с mac-адресами, и действительно, QEMU присваивает всем tap-адаптерам один и тот же mac-адрес, если не указано иное.

Выключим оба ESXi’а, укажем им уникальные mac’и и запустим снова.

К нашему громадному удивлению, проблема с пингами никуда не делась, мало того, команда arp показывает, что не изменились и MAC-адреса гипервизоров. Тут самое время вспомнить, как устроена сеть в ESXi: физическая сетевая карта переведена в “неразборчивый режим” и подключена в качестве одного из портов к виртуальному коммутатору. Другим портом к этому коммутатору подключен интерфейс vmkernel, который и является сетевой картой с точки зрения гипервизора. В момент установки ESXi аппаратный адрес физической сетевой карты клонируется в vmkernel, чтобы не смущать системного администратора. После этого его можно изменить только удалив интерфейс и создав его заново или же указав гипервизору, что следует переконфигурировать vmkernel из-за изменения адреса физической карты.

Существенная различие между указанными способами состоит в том, что первый не требует перезагрузки гипервизора, а второй — требует.

Выполнив эти нехитрые операции, мы получим в одной сети два гипервизора.

Теперь можно ставить vCenter и проверять”живую миграцию”. С некоторых пор vCenter доступен в виде образа виртуальной машины с Linux и соответствующими службами на борту. Именно такой вариант мы попробуем установить. Берем образ VMware-VCSA-all-6.5.0-5178943.iso, монтируем его в хостовой ОС, запускаем инсталлятор из каталога vcsc-ui-installer\lin64 и разворачиваем образ, следуя указаниям мастера. Для виртуальной машины потребуется 10 Gb оперативной памяти, так что на хостовой системе неплохо было бы иметь минимум 16 Gb. Впрочем, у меня образ развернулся и на 12 Gb RAM, съев всю доступную память и загнав систему в своп.

После установки VCSA заходим в Web-интерфейс с учетными данными вида administrator@mydomain.tlb и паролем, которые мы указали при настройке SSO. После этого добавляем в vCenter оба хоста и получаем простейший кластер, в котором работает живая миграция. Настроим vMotion на сетевых картах обоих хостов, создадим виртуальную машину TestVM и убедимся, что она может переезжать с одного хоста на другой, меняя как хост, так и хранилище.

Кстати, на предыдущих версиях ESXi до 6.0 включительно виртуальную машину невозможно было запустить в режиме вложенной виртуализации без добавления строки

в ее конфигурационный файл. В ESXi 6.5 этого делать не требуется, и виртуальная машина запускается без вопросов.

В заключение — небольшой лайфхак. Допустим, вам нужно скопировать файл диска ВМ из хранилища ESXi куда-нибудь на сервер резервных копий, при этом у вас нет возможности пользоваться FastSCP из состава Veeam Backup and Replication. Вам на помощь придет старый добрый rsync, нужно только найти бинарный файл, который запуститься на ESXi. К сожалению, в rsync вплоть до версии 3.0.9 включительно есть баг, из-за которого некорректно обрабатываются большие файлы на томах VMFS, поэтому стоит использовать rsync версии 3.1.0. и выше. Взять его можно здесь.

источник

Как переехать с ESXi на KVM/LXD и не сойти с ума

В компании «Макснет Системы» в качестве гипервизора долгое время использовалась бесплатная версия VMware — ESXi, начиная с версии 5.0. Платная версия vSphere отпугивала моделью лицензирования, а у бесплатной был ряд недостатков, которые отсутствовали в платной, но с ними можно было смириться. Но когда в новых версиях ESXi новый веб-интерфейс отказался работать со старым, а мониторинг RAID-массивов перестал подавать признаки жизни, компания решила искать более универсальное и открытое решение. В компании уже был неплохой опыт и приятное впечатление от LXC — Linux Containers. Поэтому стало очевидно, что гипервизор мечты будет гибридным и сочетать для разных нагрузок KVM и LXD — эволюционное продолжение LXC. В поисках информации относительно KVM, компания сталкивалась с заблуждениями, граблями и вредными практиками, но тесты и время расставили все по местам.

О том, как справиться с переездом с ESXi на KVM и не проколоть колеса на граблях, расскажет Лев Николаев (maniaque) — администратор и разработчик высоконагруженных систем, тренер по информационным технологиям. Поговорим о Сети, хранилищах, контейнерах, KVM, LXD, LXC, provisioning и удобных виртуалках.

Пролог

Сразу обозначим ключевые мысли, а дальше разберем их подробнее.

Сеть. Пока скорости ваших интерфейсов не превышают 1 Гбит/с, вам хватит bridge. Как только захотите выжать больше — он будет вас ограничивать.

Хранилище. Создайте общее сетевое хранилище. Даже если вы не готовы внутри сети использовать 10 Гбит/с, то даже 1 Гбит/с даст вам 125 МБ/с хранилища. Для целого ряда нагрузок этого будет достаточно с запасом, а миграция виртуальных машин будет элементарным делом.

Контейнер или KVM? Плюсы, минусы, подводные камни. Какие виды нагрузки лучше положить в контейнер, а какие лучше оставить в KVM?

LXD или LXC. LXD — это LXC? Или другая версия? Или надстройка? Что это вообще? Развеем мифы и поймем, в чем отличия между LXD и LXC.

Удобный provisioning. Что удобнее: брать одинаковый образ или инсталлировать систему с нуля каждый раз? Как это делать быстро и аккуратно каждый раз?

Удобная виртуальная машина. Здесь будут страшные рассказы о загрузчиках, разделах, LVM.

Разное. Много мелких вопросов: как быстро перетащить виртуальную машину c ESXi на KVM, как хорошо мигрировать, как правильно виртуализировать диски?

Причина переезда

Откуда у нас появилась безумная идея переезда с ESXi на KVM/LXD? ESXi популярно среди малого и среднего бизнеса. Это хороший и дешевый гипервизор. Но есть нюансы.

Мы начинали с версии 5.0 — удобно, все работает! Следующая версия 5.5 — тоже.

С версии 6.0 — уже сложнее. На ESXi Web-интерфейс не сразу стал бесплатным, только с версии 6.5, до этого требовалась утилита под Windows. Мы с этим смирились. Кто работает на OS X покупает Parallels и ставит эту утилиту. Это всем известная боль.

Периодически слетал мониторинг. Приходилось в консоли сервера перезапускать службы менеджмента — тогда снова появлялся CIM Heartbeat. Мы терпели, так как он не всегда отваливался.

Версия ESXi 6.5 — треш, угар и бесчинства. Ужасный гипервизор. И вот почему.

  • Angular вываливается с исключением еще на входе в Web-интерфейс. Как только вы вводите логин и пароль — сразу исключение!
  • Не работает возможность удаленно мониторить статус RAID-массива так, как удобно нам. Раньше было удобно, а в версии 6.5 — все плохо.
  • Слабая поддержка современных сетевых карт от Intel. Сетевые карты от Intel и ESXi порождают боль. На форуме поддержки ESXi есть ветка агонии по этому поводу. VMware и Intel не дружат и в ближайшее время отношения не улучшатся. Печально то, что проблемы испытывают даже клиенты платных решений.
  • Нет миграции в рамках ESXi. Если только не считать миграцией процедуру с паузой, копированием и запуском. Ставим машину на паузу, быстро ее копируем и запускаем в другом месте. Но назвать это миграцией нельзя — все-таки есть простой.

Посмотрев на это все, у нас и появилась безумная идея переезда с ESXi 6.5.

Список пожеланий

Для начала мы написали список пожеланий идеального будущего, в которое мы уходим.

Управление из-под SSH, а Web и прочее опционально. Web-интерфейс — это здорово, но в командировке с iPhone зайти в Web-интерфейс ESXi и что-то там сделать неудобно и тяжело. Поэтому, единственный способ управлять всем — это SSH, другого не будет.

Виртуализация Windows. Иногда клиенты просят странные вещи, а наша миссия — им помогать.

Всегда свежие драйвера и возможность настраивать сетевую карту. Адекватное желание, но нереализуемое под чистым ESXi.

Живая миграция, а не кластеризация. Мы хотим возможность перетаскивать машины с одного гипервизора на другой, не ощущая никаких задержек, простоев и неудобств.

Список желаний готов, дальше начался тяжелый поиск.

Муки выбора

Рынок крутится вокруг KVM или LXC под разными соусами. Иногда кажется, что Kubernetes где-то сверху, где все хорошо, солнце и рай, а на уровне ниже сидят морлоки — KVM, Xen или что-то подобное…

Например, Proxmox VE — это Debian, на который натянули ядро от Ubuntu. Это выглядит странно, но приносить ли это в продакшн?

Читайте также:  Установка акустики в заднюю полку гранта

Наши соседи этажом ниже — Alt Linux. Они придумали красивое решение: собрали Proxmox VE в виде пакета. Они просто ставят пакет одной командой. Это удобно, но мы не катаем Alt Linux в продакшн, поэтому нам не подошло.

Берем KVM

В итоге мы выбрали KVM. Не взяли, Xen, например, из-за сообщества — оно у KVM сильно больше. Казалось, что мы всегда найдем ответ на свой вопрос. Позже мы выяснили, что размер сообщества не влияет на его качество.

Изначально мы рассчитывали, что возьмем Bare Metal машину, добавим Ubuntu, с которой работаем, а сверху будем катать KVM/LXD. Мы рассчитывали на возможность запускать контейнеры. Ubuntu хорошо знакомая система и никаких сюрпризов в плане решения проблем загрузки/восстановления для нас нет. Мы знаем куда пинать, если гипервизор не заводится. Нам все понятно и удобно.

Ускоренный курс по KVM

Если вы из мира ESXi, то вас ждет много интересного. Выучите три слова: QEMU, KVM и libvirt.

QEMU транслирует желания виртуализируемых ОС в вызовы обычного процесса. Отлично работает практически везде, но медленно. Сам по себе QEMU — это отдельный продукт, который виртуализирует кучу других устройств.

Дальше на сцену выходит связка QEMU-KVM. Это модуль ядра Linux для QEMU. Все инструкции виртуализировать дорого, поэтому у нас есть модуль ядра KVM, который транслирует только некоторые инструкции. Как результат — это ощутимо быстрее, потому что обрабатывается всего несколько процентов инструкций от общего набора. Это и есть все издержки на виртуализацию.

Если у вас просто QEMU, запуск виртуальной машины без обвязки выглядит так:

В параметрах описываете сеть, блочные устройства. Все замечательно, но неудобно. Поэтому есть libvirt.

Задача libvirt — быть единым инструментом для всех гипервизоров. Он может работать с чем угодно: с KVM, с LXD. Кажется, что остается только учить синтаксис libvirt, но на деле он работает хуже, чем в теории.

Эти три слова — все, что нужно, чтобы поднять первую виртуалку в KVM. Но опять-таки есть нюансы…

У libvirt есть конфиг, где хранятся виртуалки и прочие настройки. Он хранит конфигурацию в xml-файлах — стильно, модно и прямо из 90-х. При желании их можно редактировать руками, но зачем, если есть удобные команды. Также удобно то, что изменения xml-файлов чудесно версионируются. Мы используем etckeeper — версинонируем директорию etc. Использовать etckeeper уже можно и давно пора.

Ускоренный курс по LXC

По поводу LXC и LXD существует множество заблуждений.

LXC — это возможность современного ядра использовать namespaces — делать вид, что оно совсем не то ядро, что было изначально.

Этих namespaces можно создавать сколько угодно под каждый контейнер. Формально ядро одно, но ведет себя как много одинаковых ядер. LXC позволяет запускать контейнеры, но предоставляет только базовые инструменты.

Компания Canonical, которая стоит за Ubuntu и агрессивно двигает контейнеры вперед, выпустила LXD — аналог libvirt. Это обвязка, которая позволяет удобнее запускать контейнеры, но внутри это все равно LXС.

LXD — это гипервизор контейнеров, который базируется на LXС.

В LXD царствует энтерпрайз. LXD хранит конфиг в своей базе — в директории /var/lib/lxd . Там LXD ведет свой конфиг в конфиг в SQlite. Копировать его не имеет смысла, но можно записывать те команды, которые вы использовали для создания конфигурации контейнера.

Выгрузки как таковой нет, но большая часть изменений автоматизируется командами. Это аналог Docker-файла, только с ручным управлением.

Продакшн

С чем мы столкнулись, когда на этом всем поплыли в эксплуатацию.

Сколько же адского треша и угара в интернете о сети в KVM! 90% материалов говорят использовать bridge.

Перестаньте использовать bridge!

Что с ним не так? В последнее время у меня ощущение, что с контейнерами творится безумие: поставим Docker поверх Docker, чтобы можно было запускать Docker в Docker смотря Docker. Большинство не понимает, что делает bridge.

Он помещает ваш сетевой контроллер в promiscuous mode и принимает весь трафик, потому что не знает, какой его, а какой нет. В результате весь трафик bridge идет через замечательный, быстрый сетевой Linux-стек, а там много копирования. В итоге все медленно и плохо. Поэтому не используйте bridge в продакшн.

SR-IOV

SR-IOV — это возможность виртуализироваться в пределах сетевой карты. Сама сетевая карта умеет выделять часть себя для виртуальных машин, что требует определенной поддержки железом. Именно это и будет мешать мигрировать. Миграция виртуальной машины туда, где отсутствует SR-IOV, болезненна.

SR-IOV надо использовать там, где оно поддерживается всеми гипервизорами, в рамках миграции. Если же нет, то для вас есть macvtap.

macvtap

Это для тех, у кого сетевая карта не поддерживает SR-IOV. Это light-версия bridge: на одну сетевую карту навешиваются разные MAC-адреса, и используется unicast filtering: сетевая карта принимает не все подряд, а строго по списку MAC-адресов.

Больше кровавых подробностей можно прочитать в замечательном докладе Toshiaki Makita «Virtual switching technologies and Linux bridge». Он полон боли и страдания.

90% материалов о том, как строить сеть в KVM, бесполезны.

Если кто-то говорит, что bridge это классно — не разговаривайте больше с этим человеком.

С macvtap CPU экономит около 30% за счет меньшего числа копирований. Но с promiscuous mode есть свои нюансы. Нельзя с самого гипервизора — с хоста, — соединиться с сетевым интерфейсом гостевой машины. В докладе Toshiaki подробно описано об этом. Но если кратко — не получится.

С самого гипервизора редко ходят по SSH. Там удобнее стартовать консоль, например, Win-консоль. «Смотреть» трафик на интерфейсе возможно — нельзя по TCP соединиться, но трафик на гипервизоре видно.

Если ваши скорости выше 1 Гигабита — выбирайте macvtap.

При скоростях интерфейса до или около 1 Гигабита в секунду можно использовать и bridge. Но если у вас сетевая карта на 10 Gb и вы хотите как-то ее утилизировать, то остается только macvtap. Никаких других вариантов нет. Кроме SR-IOV.

systemd-networkd

Это отличный способ хранить сетевую конфигурацию на самом гипервизоре. В нашем случае это Ubuntu, но и для других систем systemd работает.

Раньше у нас был файл /etc/network/interfaces , в котором мы все держали. Один файл неудобно редактировать каждый раз — systemd-networkd позволяет разбить конфигурацию на россыпь маленьких файлов. Это удобно, потому что работает с любой системой версионирования: отправили в Git и видите, когда и какое изменение произошло.

Есть недостаток, который обнаружили наши сетевики. Когда нужно добавить новый VLAN в гипервизоре, я иду и конфигурирую. Потом говорю: «systemctl restart systemd-networkd». В этот момент у меня все хорошо, но если подняты BGP-сессии с этой машины — они рвутся. Наши сетевики это не одобряют.

Для гипервизора ничего страшного не происходит. Systemd-networkd непригодно для пограничных бордеров, серверов с поднятым BGP, а для гипервизоров — отлично.

Systemd-networkd далек от финала и не будет закончен никогда. Но это удобнее, чем редактировать один огромный файл. Альтернатива systemd-networkd в Ubuntu 18.04 — Netplan. Это «классный» способ конфигурировать сеть и наступать на грабли.

Устройство сети

После установки KVM и LXD на гипервизор, первое, что вы увидите, — два bridge. Один себе сделал KVM, а второй — LXD.

LXD и KVM пытаются развернуть свою сеть.

Если вам все-таки нужен bridge — для тестовых машин или поиграться, убейте bridge, который включается по умолчанию и создайте свой — такой, какой хотите. KVM или LXD это делают ужасно — подсовывают dnsmasq, и начинается ужас.

Хранилище

Не важно, какие реализации вам нравятся — используйте общее хранилище.

Например, по iSCSI для виртуальных машин. Вы не избавитесь от «точки отказа», но сможете консолидировать хранение в одной точке. Это открывает новые интересные возможности.

Для этого надо внутри дата-центра иметь интерфейсы хотя бы 10 Гбит/с. Но даже если у вас только 1 Гбит/с — не огорчайтесь. Это примерно 125 Мбайт/с — вполне хорошо, для гипервизоров, которые не требуют высокой дисковой нагрузки.

KVM умеет мигрировать и перетаскивать хранилища. Но, например, в режиме рабочей нагрузки перенос виртуальной машины на пару Терабайт — это боль. Для миграции с общим хранилищем хватает передачи только оперативной памяти, что элементарно. Это сокращает время миграции.

В итоге LXD или KVM?

Первоначально мы полагали, что для всех виртуалок, где ядро совпадает с хостовой системой, мы возьмем LXD. А там, где нам нужно брать другое ядро — возьмем KVM.

В реальности планы не взлетели. Чтобы понять почему, посмотрим внимательнее на LXD.

Главный плюс — экономия памяти на ядре. Ядро одно и когда запускаем новые контейнеры ядро все то же. На этом плюсы кончились и начались минусы.

Блочное устройство c rootfs надо монтировать. Это тяжелее, чем кажется.

Читайте также:  Установка люка она оке

Миграции толком нет. Она есть, и базируется на чудесном сумрачном инструменте criu, который пилят наши соотечественники. Я горжусь ими, но в простых случаях criu не работает.

zabbix-agent странно ведет себя в контейнере. Если его запустить внутри контейнера, то ряд данных вы увидите с хостовой системы, а не из контейнера. Пока с этим ничего сделать нельзя.

При взгляде на список процессов на гипервизоре, невозможно быстро понять, из какого контейнера растет конкретный процесс. Требуется время, чтобы выяснить, какой там namespace, что и куда. Если нагрузка где-то подскочила больше, чем обычно, то быстро это не понять. Это главная проблема — ограничение в возможностях реагирования. Для каждого случая проводится мини-расследование.

Единственный плюс LXD — экономия памяти на ядре и сокращение overhead.

Но Kernel Shared Memory в KVM и так экономит память.

Пока не вижу причин знакомить серьезный продакшн и LXD. Несмотря на все усилия Canonical в этой области, LXD в продакшн приносит больше проблем, чем решений. В ближайшее время ситуация не изменится.

Но, нельзя сказать, что LXD это зло. Он хорош, но в ограниченных случаях, о которых расскажу чуть позже.

Criu — это сумрачная утилита.

Создайте пустой контейнер, он приедет с DHCP-клиентом и скажите ему: «Suspend!» Получите ошибку, потому что там DHCP-клиент: «Ужас-ужас! Он сокет открывает с признаком «raw» — какой кошмар!» Хуже некуда.

Впечатления от контейнеров: миграции нет, Criu работает через раз.

Мне «нравится» рекомендация от команды LXD, что делать с Criu, чтобы не было проблем:

Возьмите из репозитория версию посвежее!

А можно ее как-то из пакета поставить, чтобы не бегать в репозиторий?

Выводы

LXD чудесен, если хочется создать CI/CD инфраструктуру. Мы берем LVM — Logical Volume Manager, делаем с него снапшот, и на нем стартуем контейнер. Все отлично работает! За секунду создается новый чистый контейнер, который настроен для тестирования и прокатки chef — мы это активно используем.

LXD слаб для серьезного продакшн. Мы не можем понять, что делать с LXD в продакшн, если он плохо работает.

Выбираем KVM и только KVM!

Миграция

Скажу об этом кратко. Для нас миграция оказалась чудесным новым миром, который нам нравится. Там все просто — есть команда для миграции и две важные опции:

Если наберете в Google «KVM migration» и откроете первый же материал, то увидите команду для миграции, но без двух последних ключей. Вы не увидите упоминания, что они важны: «Просто выполните эту команду!» Выполните команду — а оно действительно мигрирует, но только как?

undefinesource — удалить виртуальную машину из гипервизора, с которого мигрируем. Если после такой миграции ребутнетесь, то гипервизор, с которого вы ушли, заново запустит эту машину. Вы удивитесь, но это нормально.

Без второго параметра — persistent — гипервизор, куда вы переехали, вообще не считает, что это постоянная миграция. После ребута гипервизор ничего не вспомнит.

Без этого параметра виртуальная машина — круги на воде. Если первый параметр указан без второго, то догадайтесь, что будет.

С KVM таких моментов много.

  • Сеть: вам все время рассказывают про bridge — это кошмар! Читаешь и думаешь — как так?!
  • Миграция: про нее тоже ничего внятного не скажут, пока сами головой не побьетесь об эту стенку.

С чего начать?

Поздно начинать — я про другое.

Provisioning: как это разворачивать

Если вас устраивают стандартные опции установки, то механизм preseed прекрасен.

Под ESXi мы использовали virt-install. Это штатный способ разворачивать виртуальную машину. Он удобен тем, что вы создаете preseed-файл, в котором описываете образ вашего Debian/Ubuntu. Запускаете новую машину, скормив ей ISO дистрибутива и preseed-файл. Дальше машина сама раскатывается. Вы подсоединяетесь к ней по SSH, цепляете ее в chef, прокатываете кукбуки — все, понеслись в прод!

Но если вам хватает virt-install, у меня плохие новости. Это значит, что вы еще не дошли до стадии, когда хочется что-то сделать иначе. Мы дошли и поняли, что virt-install недостаточно. Мы пришли к некоторому «золотому образу», который мы клонируем и потом запускаем виртуалки.

А как правильно устроить виртуальную машину?

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

Виртуальной машине не нужен сложный процесс загрузки и умный загрузчик. Гораздо проще прицепить диски виртуальной машины к машине, у которой есть полный набор инструментов, чем в recovery mode пытаться куда-то вылезти.

Виртуальной машине нужна простота устройства. Зачем нужны разделы на виртуальном диске? Зачем люди берут виртуальный диск, и ставят туда разделы, а не LVM?

Виртуальной машине нужна максимальная расширяемость. Обычно виртуалки растут. Это «классный» процесс — увеличение раздела в MBR. Вы его удаляете, в этот момент вытирая пот со лба и думаете: «Только не записать бы сейчас, только бы не записать!» — и создаете заново с новыми параметрами.

LVM @ lilo

В итоге мы пришли к LVM @ lilo. Это загрузчик, который позволяет настраиваться из одного файла. Если для настройки конфига GRUB вы редактируете специальный файл, который управляет шаблонизатором и строит монструозный boot.cfg, то с Lilo — один файл, и больше ничего.

LVM без разделов позволяет сделать систему идеальной легко и просто. Проблема в том, что GRUB без MBR или GPT жить не может и идет на мороз. Мы ему говорим: «GRUB установись сюда», а он не может, потому что разделов нет.

LVM позволяет быстро расширяться и делать резервные копии. Стандартный диалог:

— Ребята, а как вы делаете виртуалке бэкап?

— … мы берем block device и копируем.

— Развертывать обратно пробовали?

— Ну нет, у нас же все работает!

Можно block device в виртуальной машине слизать в любой момент, но если там файловая система, то любая запись в нее требует трех телодвижений — эта процедура не атомарна.

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

Как строить контейнер?

Для запуска и создания контейнера есть штатные средства из шаблонов. LXD предлагает шаблон Ubuntu 16.04 или 18.04. Но если вы продвинутый боец и хотите не штатный шаблон, а свой кастомный rootfs, который настроите под себя, то возникает вопрос: а как в LXD создавать контейнер с нуля?

Контейнер с нуля

Подготавливаем rootfs. В этом поможет debootstrap: объясняем, какие пакеты нужны, какие нет — и ставим.

Объяснить LXD, что мы хотим создать контейнер из конкретного rootfs. Но сначала создаем пустой контейнер короткой командой:

Это даже можно автоматизировать.

Вдумчивый читатель скажет — а где rootfs my-container? Где указано, в каком месте он лежит? Но я же не сказал, что это все!

Монтируем rootfs контейнера туда, где он будет жить. Потом указываем, что у контейнера rootfs будет жить вот там:

Опять же это автоматизируется.

Жизнь контейнеров

У контейнера нет своего ядра, поэтому загрузка у него проще: systemd, init и полетели!

Если вы не используете штатные средства для работы с LVM, то в большинстве случаев для запуска контейнера понадобится монтировать rootfs контейнера в гипервизоре.

Я иногда нахожу статьи, в которых советуют «autofs». Не делайте так. У systemd есть automount-юниты, которые работают, а autofs — нет. Поэтому systemd automount-юниты можно и нужно использовать, а autofs — не стоит.

Выводы

Нам по вкусу KVM с миграцией. С LXD пока не по пути, хотя для тестов и построения инфраструктуры мы ее используем — там, где нет продакшн-нагрузки.

Нам нравится производительность KVM. Привычнее смотреть в top, видеть там процесс, который имеет отношение к этой виртуальной машине, и понимать, кто и чем у нас занимается. Это лучше, чем при помощи набора странных утилит с контейнерами выяснять, что там за подводные стуки.

Мы в восторге от миграции. Во многом это благодаря общему хранилищу. Если бы мы мигрировали, перетаскивая диски, то были бы не так счастливы.

Если вы так же, как и Лев, готовы рассказать о преодолении сложностей эксплуатации, интеграции или поддержки, то сейчас самое время подать доклад на осеннюю конференцию DevOpsConf. А мы в программном комитете поможем подготовить такое же воодушевляющие и полезное выступление, как это.

Мы не дожидаемся дедлайна Call for Papers и уже приняли несколько докладов в программу конференции. Подпишитесь на рассылку и telegram-канал и будете в курсе новостей о подготовке к DevOpsConf 2019 и не пропустите новые статьи и видео.

источник

Добавить комментарий