Устранение неисправностей при загрузке операционной системы на серверах без KVM — непростое занятие. Создаем себе KVM-over-IP через образ восстановления и виртуальную машину.

В случае возникновения проблем с операционной системой на удаленном сервере, администратор загружает образ восстановления и проводит необходимые работы. Такой способ отлично работает, когда причина сбоя известна, а образ восстановления и установленная на сервере операционная система из одного семейства. Если причина сбоя еще не известна, необходимо понаблюдать за ходом загрузки операционной системы.

Удаленный KVM


Получить доступ к консоли сервера можно с помощью встроенных средств, таких как IPMI или Intel® vPro™, или с помощью внешних устройств, именуемых IP-KVM. Существуют ситуации, в которых все из перечисленных технологий недоступны. Однако, это не конец. Если сервер можно удаленно перезагрузить в образ восстановления на базе операционной системы семейства Linux, то можно быстро организовать KVM-over-IP.

Образ восстановления представляет собой полноценную операционную систему, которая размещается в оперативной памяти. Таким образом, мы можем запускать любое программное обеспечение, в том числе и виртуальные машины (ВМ). То есть можно запустить ВМ, внутри которой будет работать операционная система сервера. Доступ к консоли ВМ может быть организован, например, через VNC.

Для запуска операционной системы сервера внутри ВМ необходимо указать диски сервера в качестве дисков ВМ. В операционных системах семейства Linux физические диски представляются блочными устройствами вида /dev/sdX, с которыми можно работать как с обычными файлами.

Некоторые гипервизоры, такие как QEMU и VirtualBox позволяют хранить данные ВМ в «сыром» виде, то есть только данные хранилища без метаданных гипервизора. Таким образом, ВМ можно запустить с использованием физических дисков сервера.

Подобный способ требует ресурсов на запуск образа восстановления и ВМ внутри него. Однако, при наличии четырех и более гигабайт оперативной памяти это не станет проблемой.

Подготовка окружения


В качестве виртуальной машины можно использовать легковесную и простую программу QEMU, которая чаще всего не является частью образа восстановления, поэтому должна быть установлена отдельно. Образ восстановления, который мы предлагаем клиентам, основан на Arch Linux, в котором используется пакетный менеджер pacman.

Сперва необходимо удостовериться, что образ восстановления использует последнии версии программного обеспечения. Выполнить проверку и обновить все компоненты ОС можно следующей командой:

pacman -Suy

После обновления необходимо установить QEMU. Команда на установку через pacman будет выглядеть так:

pacman -S qemu

Проверим, что qemu установилась корректно:

root@sel-rescue ~ # qemu-system-x86_64 --version
QEMU emulator version 4.0.0
Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers


Если все так, то образ восстановления готов к работе.

Запуск виртуальной машины


Сперва необходимо определиться с количеством ресурсов, выделяемых ВМ, и выяснить пути до физических дисков. В нашем случае мы выделим два ядра и два гигабайта оперативной памяти виртуальной машине, а диски находятся по пути /dev/sda и /dev/sdb. Запустим ВМ:

qemu-system-x86_64 \
-m 2048M \
-net nic -net user \
-enable-kvm \
-cpu host,nx \
-M pc \
-smp 2 \
-vga std \
-drive file=/dev/sda,format=raw,index=0,media=disk \
-drive file=/dev/sdb,format=raw,index=1,media=disk \
-vnc :0,password \
-monitor stdio


Немного подробнее о том, что значит каждый из параметров:

  • -m 2048M — выделяем 2 ГБ оперативной памяти на ВМ;
  • -net nic -net user — добавляем простое подключение к сети через гипервизор с использованием NAT (Network Address Translation);
  • -enable-kvm — включаем полную виртуализацию KVM (Kernel Virtual Machine);
  • -cpu host — говорим виртуальному процессору получить весь функционал процессора сервера;
  • -M pc — тип оборудования PC;
  • -smp 2 — виртуальный процессор должен быть двухъядерным;
  • -vga std — выбираем стандартную видеокарту, которая не поддерживает большие разрешения экрана;
  • -drive file=/dev/sda,format=raw,index=0,media=disk
    • file=/dev/sdX — путь до блочного устройства, представляющего диск сервера;
    • format=raw — помечаем, что в указанном файле все данные лежат в «сыром» виде, то есть как на диске;
    • index=0 — номер диска, должен увеличиваться для каждого следующего диска на единицу;
    • media=disk — виртуальная машина должна распознать это хранилище как диск;
  • -vnc :0, password — запускаем VNC-сервер по умолчанию на 0.0.0.0:5900, в качестве авторизации используем пароль;
  • -monitor stdio — общение администратора с qemu будет происходить через стандартные потоки ввода-вывода.

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

QEMU 4.0.0 monitor - type 'help' for more information
(qemu)


Мы указали, что авторизация происходит по паролю, но не указали сам пароль. Сделать это можно отправив команду change vnc password в QEMU-монитор. Важное замечание: пароль не может быть больше восьми символов.

(qemu) change vnc password
Password: ******


После этого мы можем подключиться любым VNC-клиентом, например, Remmina, по IP-адресу нашего сервера с указанным нами паролем.





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

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

Установка операционной системы


Виртуальная машина имеет полный доступ к дискам сервера и потому может быть использована для установки операционной системы вручную. Единственное ограничение заключается в количестве оперативной памяти: не всегда ISO-образ можно разместить в оперативной памяти. Выделим в оперативной памяти четыре гигабайта для хранения образа в /mnt:

mount -t tmpfs -o size=4G tmpfs /mnt

Также загрузим установочный образ операционной системы FreeBSD 12.0:

wget -P /mnt ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-RELEASE-amd64-bootonly.iso

Теперь можно запускать ВМ:

qemu-system-x86_64 \
-m 2048M \
-net nic -net user \
-enable-kvm \
-cpu host,nx \
-M pc \
-smp 2 \
-vga std \
-drive file=/dev/sda,format=raw,index=0,media=disk \
-drive file=/dev/sdb,format=raw,index=1,media=disk \
-vnc :0,password \
-monitor stdio \
-cdrom /mnt/FreeBSD-12.0-RELEASE-amd64-bootonly.iso \
-boot d


Флаг -boot d устанавливает загрузку с CD-привода. Подключаемся VNC-клиентом и видим загрузчик FreeBSD.



Так как для доступа в интернет использовалось получение адреса по DHCP, возможно, после настройки будет необходимо загрузиться в только что установленную систему и исправить сетевые настройки. В некоторых случаях может потребоваться установка драйверов сетевого адаптера, так как сетевая карта, установленная в сервере и эмулируемая в ВМ отличаются.

Заключение


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

Комментарии (32)


  1. amarao
    26.08.2019 13:06

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


    1. DaemonGloom
      26.08.2019 14:04

      Для ситуации с восстановлением сервера, который не загружается (но в который воткнули загрузочную флешку), latency не столь критична становится. Никто же не говорит, что так система должна работать в постоянном режиме.


      1. amarao
        26.08.2019 14:07
        +1

        Ну, в статье про это не особо говорят.


        В режиме же "один раз починить" — съехавшие имена интерфейсов почти полностью разрушают идею "загрузить как было, но с консолью". В этом режиме (при наличии запасного интерфейса) куда разумнее будет pci-passthrough для сетевого интерфейса — в этом случае сервер может "почти не заметить" что его в виртуалку загрузили. Более того, в таком режиме можно даже и в продакшен, потому что пенальти на IO почти не будет.


        1. riv1329
          27.08.2019 11:13

          pci-passthrough сохранить модель, но не расположение на шине, если этим не озаботится специально. А в новых дистрибутивах linux имя интерфейса зависит от всего, в том числе и положения на pci-e шине.


          1. amarao
            27.08.2019 11:57

            А вот, кстати, это интереснейшая задача для специализированного дистрибутива. Загрузить хост-систему так, чтобы она ничего не "заметила". Все устройства как были (за вычетом парочки прихватизированных).


            1. JerleShannara
              27.08.2019 14:11

              Как минимум всякие интересные драйвера и софт (превед старой nvidia) обнаружат, что они в виртуалке по специфике обработки некоторых команд и наличию некоторых девайсов.


              1. amarao
                27.08.2019 14:29

                Я по-этому и написал в кавычках. Никто не пытается спрятать kvm от сосредоточенного искателя. Речь о софте, который просто хочет, чтобы "не менялось".


    1. site6893
      26.08.2019 14:59

      а никто и не предлагал использовать такой «подвыверт» в продакшене ))


      1. riv1329
        27.08.2019 11:20

        hetzner использует это в продакшене. Но не всегда работает, к сожалению. Когда работает — очень удобно. Если не работает, приходится вручную создавать заявку на физическое подключение ip-kvm и ждать реакции и иногда очереди.


  1. gwathedhel
    26.08.2019 14:58

    Я может что-то недопонял, но у большинства брендовых серверов есть встроенные решения для удаленного управления (hp ilo, dell idrac). Зачем изобретать велосипед из костылей?


    1. JerleShannara
      27.08.2019 01:38

      Добавлю ещё больше, BMC с IP-KVM торчит из всяких супер-микр и прочих «компаний второго эшелона». В результате в пролёте остаются сервера формата «аренда за 500р в месяц», которые собраны на atom-ах и прочем lowend-е, где ресурсов и так не очень много, чтобы допом развешивать виртуализацию.


    1. DaemonGloom
      27.08.2019 06:05

      Из глупых ситуаций — iLo, vPro и, вероятно, все прочие (на этих сам проверял) системы управления отказываются работать в качестве kvm, если установлен отдельный gpu и указан в качестве основного.


      1. amarao
        27.08.2019 11:57

        Для таких штук там есть последовательный порт.


        1. DaemonGloom
          27.08.2019 14:17

          А windows умеет с ним нормально работать? Ну там подключить в него консоль, выдать ошибку синего экрана туда текстом, показать лог загрузки?


          1. amarao
            27.08.2019 14:30

            А зачем вам винда на сервере? O_o? Теоретически, в винде есть шелл (для ssh) и его можно заставить слушать на последовательном порту. Но это же винда!


            1. JerleShannara
              27.08.2019 15:58

              Отвечу из 2004 года — чтобы там стыренный из NCSoft сервер MMORPG Lineage II стоял. Ну или что там ещё серверного было в варианте «Windows only».


    1. riv1329
      27.08.2019 11:28

      А вот например у того-же hetzner наиболее популярные продукты — самосборные сервера. Брендовые тоже есть, но не пользуются популярностью из-за в разы большей цены.

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

      И это сервера не за 500 рублей на атоме, а что-то типа Intel® Xeon® W-2145 /128GB RAM за 112 Евро + стоимость аренды SSD, или, например Intel Xeon E3-1275v5 / 64GB RAM / 2x 512 NVME SSD за 70 Евро.

      При том что брендовые сервера указанных конфигураций будут от 300-200 евро


      1. gwathedhel
        27.08.2019 11:59

        Я просто смотрю со своей колокольни админа, который поддерживает серверную. Если сервер не бренд — это не проблема. Но если для него нужна гарантия, то это проблема. Если для него нужно еще ip-kvm, то я куплю отдельное p-kvm устройство для таких серверов.
        Если компания не может себе это позволить — то зачем мне в такой компании работать? ;)


  1. quartz64
    26.08.2019 15:16

    Интересная идея, но при отсутствии KVM-over-IP кто нам обеспечит возможность «удаленно перезагрузить в образ восстановления на базе операционной системы семейства Linux» и обратное переключение на загрузку вылеченной ОС?
    Тогда уж проще сразу виртуализовать это всё.


    1. Firemoon Автор
      26.08.2019 15:34

      Перезагрузку сервера можно осуществлять удалённо посредством, например, управляемых PDU.
      Загрузить удалённо в Rescue, а потом вернуть в вылеченную ОС — PXE.


      1. JerleShannara
        27.08.2019 01:40

        Эмм… если есть деньги на Switched-PDU, то почему нет денег на IP-KVM для старых серверов/серверов из десктопного железа?


        1. DaemonGloom
          27.08.2019 06:07

          Это может быть не switched-pdu, например, а старый бесперебойник. И удалённый узел из нескольких коммутаторов и сервера, которые можно сбросить по питанию всей толпой.
          Более простой пример — может быть человек, который в состоянии воткнуть флешку и нажать кнопку на корпусе, но не более этого.


          1. riv1329
            27.08.2019 11:34

            По тому, что switched-pdu может управлять целой стойкой серверов, и потребуется не один а несколько десятков ip-kvm


            1. JerleShannara
              27.08.2019 14:15

              Вы предлагаете ради одного сервера дёргать по питанию всю стойку? Да и IP-KVM спокойно бывает и 16 и 32 портовыми, чего вполне себе хватит на одну-две стойки (если их не 1U серверами набивать).


          1. JerleShannara
            27.08.2019 14:16

            Ставить по одному бесперебойнику на сервер? Проще тогда SNR-ERD или схожее за 1т.р. поставить — оно вполне себе может дёрнуть питание одного девайса.


            1. riv1329
              28.08.2019 15:28

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

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


              1. JerleShannara
                29.08.2019 05:49

                Вот тут увы, только если всякие около-IoT устройства, но пихать такое в ДЦ это самоубийство.


  1. nsmcan
    27.08.2019 00:06

    Виртуализация железного сервера очень часто совсем непростая задача. В общем виде для набора серверов её решить вряд ли удастся. Это во-первых.
    Даже если сервер таким образом всё же стартовал, то наблюдаете и отлаживаете Вы уже совсем другую сущность — его виртуализированный вариант. Это во-вторых. И наконец, сравните стоимость б/у-шного (или даже нового) IP-KVM свича со стоимостью Вашего часа помноженной на те часы, которые уйдут, чтобы создать и настроить инфраструктуру для Вашего решения, и купите свич (или нормальный сервер с out-of-band доступом на борту).


    1. JerleShannara
      27.08.2019 01:41

      Скажем так, я очень долгое время избавлялся от кучи авоцента, под конец продавал по 3000р за 16 портовый IP-KVM и по 1000р за каждый модуль подключения сервера. При этом тут рассматривают вариант перезагрузки через дёрганье PDUшки, которая тоже стоит денег.


      1. tartarelin
        27.08.2019 09:40

        Кому-то повезло, обычно IP-KVM стоят в разы дороже


        1. JerleShannara
          27.08.2019 14:19

          Это была почти оптовая скупка оборудования после обновления парка железа. Да и сама контора (авоцент) к тому времени была уже три раза перепродана и вся техподдержка у них пропала. А так по цене IP-KVM и умные PDUшки стоят примерно одинаково (и не гуманно), если их новыми брать.


    1. denisov_root
      27.08.2019 09:42

      Какие часы? В ДЦ типа хетзнера или ovh у которых есть огромное количество серверов без KVM но все они могут загружаться с PXE в Rescue по одному клику в течении пары минут, это огромная экономия…
      Windows к примеру без проблем таким образом админится.