Моя первая виртуальная машина: как не накосячить

    Итак, вот перед вами свеженькая организация в vCloud Director, и вам только предстоит создать свою первую виртуальную машину. Сегодня расскажу, какие настройки выбирать при создании виртуальной машины, чтобы она работала и не просила есть. Поехали!


    Источник: drive2.ru

    Операционная система. Выбирайте современные дистрибутивы. Если берете Windows 2008 R2 и более старую или Linux до ядра 4.19.x, ждите проблем. Каких? Ну, например, вендор уже перестал поддерживать актуальное состояние Windows 2008 R2 аж в 2013 году (EOL). Это означает, что он больше не разрабатывает драйвера под вышедшее с тех пор железо, не модифицирует ОС под новое что угодно. С древними операционками вы точно не сможете использовать все возможности, которые предоставляет современный гипервизор. А уже в эти новогодние праздники остро встанет проблема с безопасностью, так как 14 января 2020 года заканчивается расширенная поддержка Windows Server 2008 R2 и перестанут выходить Security Update.

    Cores per socket. Оставляйте 1 ядро на сокет, ставьте столько сокетов, сколько вам нужно виртуальных процессоров. Да, логично наоборот, но правильно так. Если у вас нет специализированных лицензионных требований. Например, вы платите за сокет, а больше сокетов означает больше лицензий. Не ставьте 2/2, чтобы получить 4. Сделайте 4/1. Такую машину гипервизор будет обслуживать оптимальным образом. Scheduler гипервизора будет меньше пенализировать такие ВМ.
    Объясню на пальцах. Представьте, что проводник рассаживает пассажиров по вагону, вагон – как в Сапсане. В роли проводника scheduler, пассажиры – это ВМ. Пассажиров, которые едут в одиночку (однопроцессорные ВМ), ему распределить проще всего: их можно посадить на любое место. Семью из 4 человек (4-процессорные ВМ) уже сложнее. Им нужно найти 4 места в одном вагоне. А теперь представим, что все в семье хотят ехать только лицом друг другу, а таких групп мест – 4 вокруг стола – в вагоне только 2. С большой вероятностью такой семье придется пройти в следующий вагон (на следующий тик планирования). Это как раз та ситуация, как если бы вы выбрали 2 сокета по 2 ядра, чтобы получить 4. Скорее всего, придется подождать, чтобы нашлись подходящие места. Так же и с ВМ: ей придется ждать дольше, чем менее “прихотливым” ВМ с 1 сокетом и кучкой процессоров.

    Хотя эта история актуальнее для старых версий ESXi. Начиная с 6.5 (но не ранее!) механизм vNUMA отвязан от количества виртуальных сокетов, и старая рекомендация “не плодить сокеты” не так категорична. Но все еще зависит от приложения внутри гостевой ОС.



    Hot Add для CPU и Memory. Это опция добавления памяти CPU для работающей виртуальной машины. Казалось бы, прекрасная функция: не нужно гасить машину, чтобы докинуть ей ресурсов. Так вот, не все так просто, и не зря они по дефолту отключены. Лучше и не включать, если вы не знаете, что такое NUMA-топология. Допустим, под капотом облака у нас двухсокетный сервер. На каждом сокете 4 ядра. Работает это именно как 4+4, а не 8 ядер. Такая же тема с памятью: если на каждом сокете 128 ГБ, это не дает в сумме 256 ГБ. Каждый процессорный сокет имеет прямой доступ только к определенным слотам памяти. Каждый сокет вместе с причитающейся ему процессором и памятью – это физическая NUMA-нода.



    Если виртуальная машина влезает в размер физической NUMA-ноды, то она исполняется внутри этой ноды. Если виртуалка не умещается в NUMA-ноду, например по памяти, то она будет использовать память из соседней NUMA-ноды. Путь к удаленной памяти будет извилист – через межпроцессорную шину. Работать это будет не так быстро, как если бы виртуалка использовала ресурсы одной ноды.



    Когда вы включаете добавления виртуальных процессоров и памяти на горячую, все это идет только в нулевую NUMA-ноду. Например, добавилось еще 4 процессора, и на NUMA-ноде 0 стало 6, а на NUMA-ноде 1 – 2 процессора. Машину немного перекосило, и работает она также косо. Это связано с тем, что при включении vCPU Hot-Plug перестает работать vNUMA, через которую vSphere старается оптимизировать топологию NUMA для ВМ. Поэтому, принимая решение о включении CPU Hot-Add, учитывайте физическую топологию NUMA для обеспечения производительности ВМ. Это очень критично, если по каким-либо причинам в ВМ имеется несколько виртуальных сокетов. В этом случае несоответствие физической топологии вызовет сильное падение производительности: CPU Scheduler сойдет с ума, пытаясь предоставить процессорное время такой ВМ, что вызовет рост CPU Ready и Co-Stop.


    Все добавленные виртуальные процессоры (5-8) и память попали на NUMA-ноду 0.

    Отдельная история в том, что будет происходить внутри ОС и приложения после таких “добавок”. Поэтому если уж решили пользоваться этой опцией, то проверьте, поддерживает ли ваша ОС такое. Non-NUMA-Aware приложения могут сильно просесть по производительности при расположении на нескольких NUMA-нодах.

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


    Галочки не ставим.

    Дисковый контроллер (Bus type). Для дисков выбирайте дисковый контроллер Paravirtual. Этот тип контроллера требует установки драйверов в ОС VMware Tools. Paravirtual – это специальное виртуальное устройство, которое создавалось для работы в виртуализации и не эмулирует работу какого-то другого аппаратного устройства. Любая эмуляция аппаратного устройства всегда работает медленнее.

    Если вы не хотите использовать Paravirtual (но почему?), выбирайте LSI Logic SAS. Если ОС не поддерживает и его — LSI Logic Parallel. Никогда не используйте SATA и IDE. ВМ будет медленно работать, в итоге вы не получите производительности, за которой идут в облако.

    При инсталляции ОС даже свежая версия Windows может не найти драйвер для Paravirtual адаптера. В этом случае примонтируйте к ВМ два ISO файла — ваш загрузочный образ Windows и диск с VMware tools. На последнем есть необходимый драйвер.



    Сетевой адаптер. Правильный выбор – VMXNet3. VMXNet3, как и дисковый адаптер Paravirtual, это паравиртуальное устройство. Оно также требует драйверов, которые входят в VMware Tools.

    Если вдруг VMXNet3 не подходит (проявляется какая-то несовместимость), то на крайний случай используйте E1000E. Но не ожидайте от адаптера E1000E производительности больше, чем 1 Гбит.

    В общем, E1000E без прямых указаний вендоров не используйте. Казалось бы, оно новее, но сделано для обеспечения еще большей совместимости c legacy.


    Вот не надо E1000E.

    VMware Tools. Следите, чтобы они были установлены в ОС, запущены и актуальны. В VMware Tools входят драйвера устройств и разные другие компоненты, которые позволяют общаться ОС виртуальной машины с гипервизором, и наоборот. Через них происходит синхронизация времени ОС с хостом виртуализации (отключаемо), ходят heartbeat’ы, которые показывают гипервизору, что виртуалка жива, и прочее. Для работы ОС на виртуальной машине нужны как минимум драйверы сетевой карточки, дискового адаптера. Свежие версии всего вот этого входят в VMware Tools.

    По умолчанию актуальные версии Windows и Linux имеют драйвера для работы с виртуальными устройствами VMware, но если у вас будут VMware Tools, то эти драйвера будут всегда свежими. Для Linux рекомендуется использовать open-vm-tools. Это не просто лучшая интеграция с ОС, но и обновление драйверов вместе с системой.



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

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



    Кастомизация. При первом включении ВМ нужно кастомизировать, чтобы все настройки из облака (например выданный облаком IP-адрес) применились к ОС. После уберите эту галку от греха подальше, чтобы нечаянно не сбросить настройки ОС: SID, пароль администратора и т. п.



    Конечно, все вышесказанное – упрощенная картина, слова “капитана О” и, вообще, “все же это знают”. Но, как показывает практика, более 70% ВМ в облаке содержат одну или сразу несколько описанных ошибок.
    DataLine
    0,00
    Экосистема на базе дата-центров TIER III
    Поделиться публикацией

    Комментарии 6

      +1
      Может я чего не понял, но рекомендация по сокетам и ядрам несколько не соответствует тексту и картинке.
      А вообще я всегда считал, что количество сокетов VM просто не должно превышать количества сокетов на хосте. А в случае кластера с разными хостами не превышать количества сокетов на носте с минимальным их количеством. Т.е. если в кластере есть хосты с 4 и 2 сокетами, то на VM надо давать не больше 2.
      По поводу paravirtual дискового контроллера для ОС Windows тоже можно порассуждать. Например на тему того, как vmware tools начинают обновляться, включая драйвера для диска, но у них не выходит. Бывает. Только вы останетесь с неработающим системным диском по причине отсутствия в Windows родных драйверов pvscsi.
        0
        Прошу прощения, но считали не правильно, перечитайте. Рекомендую вот такую публикацию. В сети есть и сама лекция с VMworld.
        cms.vmworldonline.com/event_data/5/session_notes/SER2724BU.pdf

        Ставим 1 ядро на сокет и только так. При этом гипервизор сам построит правильную Numa топологию. В облаке вы можете не знать топологию сервера.

        При обновлении tools драйвера удалены не будут — они либо обновятся, либо нет. Но не пропадут.
        И конечно, не забываем бекап + по вкусу снепшот.
          +2
          Вы слишком категоричны, кмк. Эти презентации, как и документ Performance Best Practices для 6.5, я читал. И нигде нет однозначного утверждения про единственный сокет с множеством ядер на нем.
          Зато весьма подробно нарисовано, что не стоит превышать соотношение виртуальных ядер к физическим ядрам на один физический сокет. Точнее на один узел NUMA. Т.е. рекомендуется строить машину на одном сокете, пока количество vCPU не начнет превышать количество физических ядер. Затем придется дробить по сокетам. И в случае, когда кластер собран из узлов с разными процессорами и разным количеством физических сокетов целесообразнее ориентироваться на узел с минимальным количеством физических ядер. Что автоматически приводит к увеличению сокетов на машине. А превышать количество физических сокетов (ладно, узлов NUMA) уже совсем не стОит. Так что я продолжу соблюдать свое правило: на виртуальной машине нельзя превышать количества физических узлов NUMA. Для меня это количество совпадает с количеством сокетов, если кто работает с AMD — там может быть по-другому.
          А по поводу исчезающих драйверов pvscsi — если бы не приходилось с этим сталкиваться, то я бы не поднимал разговор. Очень просто попасть в такую ситуацию, если взвести на VM флажок автоматического обновления VMWare Tools при перезагрузке и отправить машинку на перезагрузку после установки обновлений Windows. При определенном стечении обстоятельств после перезагрузки VMWare Tools начинают обновляться, но не успевают, поскольку система обновления Windows делает принудительную вторую перезагрузку. И несколько раз я попадал на такое неудачное обновление в SLES 11.x, но там есть родные драйвера и система поднимается. Приходится только тулзы руками ставить.
            0
            Спасибо, что ещё скажешь ;) всякое бывает.
            Плюс поставил ;)
        +1
        Cores per socket. Оставляйте 1 сокет, т.е. столько сокетов, сколько вам нужно ядер. Да, логично наоборот, но правильно так.

        Про ядра с сокетами всё немного сложнее: при установке 1 ядра на сокет топология NUMA строится при первом запуске ВМ и перестраивается только при изменении количества vCPU, так что при переезде на сервер с другой физической топологией она может оказаться неоптимальной (без numa.autosize).

        Поэтому правильней (см. комментарий от Mark Achtemichuk внизу страницы) менять количество ядер в соответствии с физической топологией.
        По умолчанию актуальные версии Windows и Linux имеют драйвера для работы с виртуальными устройствами VMware

        Windows Server 2016-2019 может скачать драйверы для PVSCSI и VMXNET 3 из WU, но при установке не надёт ни дисков, ни сети.

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

      Самое читаемое