Недавно наткнулся на старые выпуски «Разрушители легенд» и подумал, что про VDS/VPS также немало мифов. Конечно, не таких зрелищных, как взрывающийся бензобак, но не менее живучих. Только никто их не спешит «разрушать», а стоило бы. В статье разберу десять самых популярных заблуждений о VDS и объясню, почему в них верить не нужно.

Миф 1. VDS/VPS — это разные технологии

Удивительно, но некоторые до сих пор считают, что VDS и VPS — это разные технологии и нужно выбрать между «правильной» и «неправильной».

Конечно, термины исторически имели нюансы. Ранее считалось, что VPS — это контейнеры (OpenVZ), а VDS — полная виртуализация (KVM). Сейчас это один вид услуг — полностью изолированный виртуальный сервер с выделенными ресурсами. 

Почему миф до сих пор жив? 

Миф породили путаница в терминах и маркетинговые уловки провайдеров, которые говорят что-то наподобие «VDS надёжнее, чем VPS». Сейчас технологии гибридные, и принцип разделения неактуален.

Миф 2. Виртуализация снижает производительность

Бытует мнение, что любой VDS по определению медленнее физического сервера — мол, виртуализация всё съедает. 

На деле современные гипервизоры (KVM, VMware, Hyper‑V и др.) не создают критичной просадки при типичных нагрузках. Аппаратные ресурсы редко используются на 100%, а виртуализация позволяет плотнее упаковывать рабочие задачи на одном хосте.

Конечно, формально есть накладные расходы, так как около 10–20% ресурсов уходит на работу гипервизора. Но в остальном виртуальный сервер ведёт себя также, как отдельная машина. Прослойка с планировщиком CPU и контроллерами I/O не превращает VDS в «урезанную» копию.

Более того, за счёт внутренних оптимизаций в некоторых конфигурациях производительность на специализированных гипервизорах выше, чем на классическом KVM. В пике разница может достигать 30%.

Почему миф до сих пор жив? 

Корни заблуждения — в устаревших данных. Ранние решения действительно были ресурсоёмкими, особенно type 2-гипервизоры вроде VirtualBox, запускающиеся поверх ОС. Сейчас серверные гипервизоры type 1 работают прямо над железом и почти не замедляют задачи. 

Миф 3. Количество vCPU соответствует «реальным ядрам»

Если в характеристиках VDS указано, скажем, «2 vCPU», многие полагают, что это точно два физических ядра процессора, которые «свободны от других».

В реальности vCPU — это не виртуальное физическое ядро, а скорее квота времени физического CPU. Гипервизор разрезает реальные ядра на потоки виртуальных процессоров, а за счёт технологии многопоточности или просто таймшеринга несколько vCPU могут принадлежать одному ядру и «ходить по очереди» в процессор. 

Так, пометка «2 vCPU» часто означает, что виртуальная машина может параллельно иметь два потока вычислений, но реальный сервер может распределять им ресурсы в зависимости от загрузки.

При этом провайдеры обычно следят, чтобы соотношение vCPU и pCPU (виртуальные и физические) было адекватным. Если ваша ВМ будет регулярно простаивать в режиме «ready», это будет видно в метриках, и провайдер автоматически переставит ВМ на менее загруженный сервер.

Почему миф до сих пор жив? 

В заблуждение вводит терминология, а в рекламе зачастую просто указывают число vCPU, не разъясняя сути. Этот миф также подогревают устаревшие концепции, когда виртуализация действительно сильно ограничивала CPU.

Миф 4. Дисковая подсистема VDS всегда медленнее

Считается, что диск у виртуального сервера находится «в облаке» или подкачке, и потому IO-операции идут медленнее, чем на реальном HDD/SSD. 

Однако производительность хранилища зависит от оборудования провайдера. Сейчас обычно применяются SSD/NVMe RAID-массивы или выделенные дисковые пулы, дающие высокую скорость чтения и записи. Виртуализация вносит лишь минимальные расходы, поэтому потери измеряются микросекундами. 

Итак, если владелец виртуального сервера снабдил диски пропускной способностью, VDS будет «летать». Правда, если, наоборот, сэкономил на железе или перегрузил диск виртуалками, то эффект снизится, но это уже характеристика провайдера, а не технологии. 

Почему миф до сих пор жив? 

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

Миф 5. Сетевой канал виртуального сервера хуже, чем у физического

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

На практике виртуальные серверы получают реальный сетевой интерфейс (1, 10 или даже 40 Гбит) и выделенный публичный IP. В свою очередь, под капотом есть виртуальный коммутатор, и драйверы обеспечивают хорошую пропускную способность. 

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

Почему миф до сих пор жив? 

Неопытные пользователи путают VDS с классическим хостингом, где трафик лимитируется и проходит через общий NAT. Среди других причин — рассказы о контейнерах, которые устрашают новичков. На деле провайдеры проектируют свои сети для лёгкого масштабирования, а пользователи получают гарантированные каналы, близкие к заявленным. 

Миф 6. После получения root-доступа поддержки нет

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

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

Почему миф до сих пор жив? 

Логично, что миф родился из страха — раньше на обычном хостинге провайдер сам разворачивал CMS и отвечал за всё, а на VDS хостер будет только «будить» клиентов по оплате. 

На деле же отдавать контент-права провайдеру или держать всё самому — это разные уровни услуги. Если вы хотите «под ключ», то берите управляемый хостинг, если взяли VDS со свободой действий, то поддержка продолжится только по части платформы.

Миф 7. VDS-хостинг небезопасен

Есть и заблуждения о том, что на виртуальном сервере легко «заполучить» чужие данные или о том, что VPS легко взломать. 

Виртуальные машины не связаны настолько буквально. Доступ к гостевой ОС имеют только её администраторы и гипервизор, поэтому «соседи» по хост-машине не видят друг друга, не могут прочитать файлы или перехватить трафик. 

Но стоит помнить о том, что у каждого провайдера есть средства безопасности физического уровня — фаерволы, анти-DDoS, аудит, обновления гипервизора, — но локальные задачи защиты (пароли, патчи, бэкапы) ложатся на плечи клиента.

Почему миф до сих пор жив? 

Заблуждение связано с устаревшими представлениями об «общей памяти» или с историями про уязвимости гипервизоров. В реальности безопасность любой ОС зависит не от типа сервера, а от мер администратора и провайдера.

Миф 8. VDS нужен только для больших проектов

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

Наоборот, иногда на малый проект выгоднее взять минимальный VDS-тариф, чем мучиться с ограничениями общего «муравейника». Такой сервер намного надёжнее, даёт полный root-доступ и позволяет «расти», например, добавлять RAM/CPU через апгрейд тарифа. 

Кроме того, с момента появления VDS цены на услугу упали, а ценность возросла. Базовые VDS-тарифы сопоставимы с платными планами классического хостинга, а функционал, наоборот, несопоставим. Более того, пользователь VDS может оплачивать только те ресурсы, которые использует.

Почему миф до сих пор жив? 

Истоки — в истории хостинга и восприятии услуги в прошлом. Раньше VDS действительно требовал больше технической подготовки, которая пугала малый бизнес. 

Также миф подпитывают публичные кейсы, в которых провайдеры рассказывают про крупных клиентов, формируя ощущение, что VDS — это исключительно «для больших». На самом деле, ресурсы виртуального сервера доступны для всех, так что даже малый проект сразу получает стабильность.

Миф 9. Нет смысла платить за VDS, это тот же виртуальный хостинг

Некоторые считают, что VDS — тот же обычный виртуальный (shared) хостинг, только дорого, потому что сайты работают на одном и том же «железе».

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

Почему миф до сих пор жив? 

Заблуждение родилось из ценовой политики. Провайдеры классического виртуального хостинга часто рекламируют «безлимитный трафик и хранилище», создавая ощущение выгоды. В реальности чистый VPS/VDS всегда стабильнее.

Миф 10. На VDS можно использовать только Linux

Это заблуждение можно описать формулой: «Виртуальный сервер = консольный Linux». Пользователи боятся, что о привычном Windows можно забыть. 

Напомню, VDS — это «пустой компьютер в облаке» с любым выбранным окружением. Практически все хостеры позволяют выбрать ОС при создании — будь то любимые дистрибутивы Linux или Windows Server с привычным графическим окружением и RDP.

К примеру, у RUVDS доступны такие ОС, как Windows Server (201, 2022), Ubuntu, Debian, CentOS. Кроме того, на маркетплейсе любую виртуалку можно дополнить образами Docker CE, OTRS, ZeroTier или даже Minecraft.  

Почему миф до сих пор жив? 

Этой истории способствует конкуренция поставщиков и паника непосвящённых. Некоторые контент-производители или провайдеры называют VDS «безликим Linux-сервером» и не упоминают Windows-образы, поэтому пользователи думают, будто их выбор ограничен. Современные гипервизоры ничем не ограничивают клиентов. 

Вместо вывода

Когда человек не видел альтернатив, он верит слухам. Некоторые так и остались с идеей о том, что виртуализация обязательно тормозит, а «виртуальный» значит неполноценный. 

Но это не так, большинство мифов о VDS/VPS основаны на устаревших представлениях или рекламных уловках некоторых провайдеров. Иногда — и на том, и на другом одновременно. Поэтому если вы являетесь жертвой таких слухов, то пора взглянуть на VDS здраво.

О том, как выбрать VPS/VDS, рассказал в статье «Почему один и тот же сайт может летать на одном VDS и тормозить на другом».

© 2025 ООО «МТ ФИНАНС»

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


  1. netch80
    15.07.2025 10:53

    Сейчас это один вид услуг — полностью изолированный виртуальный сервер с выделенными ресурсами.

    Использую один как раз VPS хостинг, классический VZ-like. Знаю места, где такого много. Так что не надо обобщать.

    На практике виртуальные серверы получают реальный сетевой интерфейс (1, 10 или даже 40 Гбит) и выделенный публичный IP.

    Ага, как процессор (ядро, харт) так не выделяется, а как сетевой адаптер так выделяется? И как же, если их как раз заведомо меньше, чем ядер у серверного процессора?

    В свою очередь, VDS даёт гарантии стабильности и полную свободу.

    Особенно когда сеть забита DoS трафиком, угу.

    За такое только минус.


    1. mvv-rus
      15.07.2025 10:53

      Ага, как процессор (ядро, харт) так не выделяется, а как сетевой адаптер так выделяется? И как же, если их как раз заведомо меньше, чем ядер у серверного процессора?

      Была такая технология в начеле 10-х (и вроде как, и сейчас есть) - Single Root IO Virtualization (SR-IOV). Аппаратно поддерживает эмуляцию некоторога количества виртуальных PCI(e) устройств, на базе одного физического. В частности, что касается сетевых адаптеров, эмулирует несколько сетевых карт, каждая - со своим MAC, обработка прерываний от сети идет в такоей схеме, при поддержке гипервизора, прямо в ОС виртуальной машины. Например, при включенной SR-IOV обработка идет в обход сетевого сетевой стека первичного раздела Hyper-V, и, в частности драйверы фильтрации WFP, трафик виртуальных машин при включенной SR-IOV не видят и перехватывать не могут (по крайней мере, до Win12 R2 включительно) - такое вот есть там ограничение.

      Так что сеевой адаптер с SR-IOV ведет себя, в значительной мере, как аппаратный коммутатор, а потому вероятность стать узким местом при DDOS для него невелика.


      1. netch80
        15.07.2025 10:53

        Была такая технология в начеле 10-х (и вроде как, и сейчас есть) - Single Root IO Virtualization (SR-IOV).

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

        а потому вероятность стать узким местом при DDOS для него невелика.

        Кабель всё равно один. И та часть карты, что принимает и раскладывает по гостям, одна. Я именно про это говорю.

        до Win12 R2 включительно

        Win12?


        1. mvv-rus
          15.07.2025 10:53

          Win12?

          Win2012 R2 Server. Ошибочка у меня вышла.

          Кабель всё равно один. И та часть карты, что принимает и раскладывает по гостям, одна. Я именно про это говорю.

          Рассматривайте это как коммутатор: в него тоже кабель один приходит (ну, или не одно если Link Aggregation, но на хосте его тоже можно использовать), и ядро коммутации у него тоже одно. Ну, а дальше всё зависит от железа, на которое хостер не поскупился: и коммутаторы, и сетевые адптеры по цене и возможностям железа разные бывают.


          1. netch80
            15.07.2025 10:53

            Угу. Ну вот в том и дело, что когда речь идёт про CPU, доступ к диску и т.п., мы можем обеспечить какие-то гарантированные объёмы ресурса простейшими локальными методами, а если про сеть - то на это требуется обеспечение по всему пути до каждого ремота. А так как IntServ начали завозить, потом вывезли обратно и больше не завезут (локальные сети на IB и прочее за прайс x20 не считаю), то весь рассказ ТС про "гарантии стабильности и полную свободу" - уже даже не маркетинговое враньё.


            1. sirmax123
              15.07.2025 10:53

              Ну с SR-IOV все равно лучше чем без )

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

              Возможно, это зависит от модели сетевки но у меня кроме интелов проверить не начем


            1. mvv-rus
              15.07.2025 10:53

              а если про сеть - то на это требуется обеспечение по всему пути до каждого ремота.

              Я писал про конкретный вопрос, вот этот:

              Ага, как процессор (ядро, харт) так не выделяется, а как сетевой адаптер так выделяется? И как же, если их как раз заведомо меньше, чем ядер у серверного процессора?

              Железо (даже 15-летней давности) позволяет дать хосту виртуализации аппаратный (ну, почти) коммутатор, к которому подключены виртальные сетевые адаптеры и выделять для VM такой вот виртуальный адаптер. Ну, а дальше в интернет - всё так же, как и с набором физичиских серверов, подключенных к физическому комутатору.

              PS А IntServ низзя - он нарушает догму о сетевом нейтралитете.


              1. DaemonGloom
                15.07.2025 10:53

                Железо (даже 15-летней давности) позволяет дать хосту виртуализации аппаратный (ну, почти) коммутатор, к которому подключены виртальные сетевые адаптеры и выделять для VM такой вот виртуальный адаптер. Ну, а дальше в интернет - всё так же, как и с набором физичиских серверов, подключенных к физическому комутатору.

                Речь, скорее о том, что с точки зрения статьи "общее ядро процессора - это плохо и так нельзя считать", но столь же общий порт на сетевой карте - это замечательно и там будут все 1/10/40 гбит. Хотя на практике - это то же самое деление ресурса на всех, хоть SR-IOV, хоть чисто программным коммутатором.


  1. mvv-rus
    15.07.2025 10:53

    При этом провайдеры обычно следят, чтобы соотношение vCPU и pCPU (виртуальные и физические) было адекватным. Если ваша ВМ будет регулярно простаивать в режиме «ready», это будет видно в метриках, и провайдер автоматически переставит ВМ на менее загруженный сервер.

    "Адекватным" - это как и чему? Почему-то в ответе отсутствует слово "переподписка" - а она есть (если конечно не закреплять фищический процессор за виртуальным, что сами же вы называете мифом). И есть подозрение, что адекватность - это величина, обратная наглости и жадности провайдера. И интересно, она в договоре фиксируется (конкретно у вас, к примеру), или как?

    А есть ещё один нюанс: обращение к оперативной памяти. Как известно, оперативная память сама по себе (на микросхемах DRAM) - она довольно медленная, и если бы процессор работал с ней только напрямую, то его бы это сильно ограничивало, поэтому между прцессором и памятью находится кэш, да ещё и многоуровневый. И это - тоже разделяемый ресурс. И тут возникает вопрос - а как при виртуализации чувствует себя этот кэш: не сможет ли один VDS начать бесконтрольно его использовать, мешая остальным?


    1. netch80
      15.07.2025 10:53

      И тут возникает вопрос - а как при виртуализации чувствует себя этот кэш: не сможет ли один VDS начать бесконтрольно его использовать, мешая остальным?

      Лучше считать, что при переключении виртуалок на конкретном ядре кэш чистится в ноль. (Это может быть и явным действием для защиты от проблем типа Meltdown/Spectre, и неявным за счёт того, что другой гость начинает активно использовать кэш, и тогда данные прежнего вымываются.)

      А вот если есть shared L3 общий на все ядра - то зависит от плотности использования, и тут надо смотреть на политики ведения этого кэша...


  1. Lordbander
    15.07.2025 10:53

    А развейте плз мою паранойю? Вы даете VDS в облаке. На харде (один фиг) крутится образ системы.

    Вы же можете этот образ слить(физически)? накатить на другой сервер, и допустим там Windows, сбросить админский пароль и читать все, что там есть и накатано?

    Скорее всего я не прав, но пока не видел обоснования, что облаку можно доверять.


    1. Smartor
      15.07.2025 10:53

      У тех, у кого есть доступ к админскому софту, есть доступ ко всему. А у кого есть доступ к железу, есть доступ вообще ко всему :)


      1. netch80
        15.07.2025 10:53

        А у кого есть доступ к железу, есть доступ вообще ко всему :)

        Если железо его допускает и цена на операцию подъёмная. В случае Intel SGX, вам, например, денег точно не хватит, чтобы найти, как в конкретном процессоре чего доработать напильником прямо на кристалле, чтобы добраться до памяти анклава в нешифрованном виде:)


    1. netch80
      15.07.2025 10:53

      Вот против такого и придумали Intel Software Guard Extensions (не знаю насчёт адекватных аналогов у остальных), есть на программном уровне варианты шифровать все данные и обрабатывать в шифрованном виде (чисто алгоритмически описано у Шнайера), наверняка ещё что-то придумали, я только поверхностно знаю. Но у Intel и AMD сейчас даже память, занятая виртуалками, может проходить шифрование данных, чтобы при случайной её выдаче соседям или хозяйской системе они ничего не прочитали. Диск может быть запаролен, а пароль вычисляться при старте на основании данных лукапа куда-то извне. И прочая и прочая.

      В сумме это не даёт 100%, конечно, но на порядки резко усложняет подглядывание нечестным админом.


    1. mrtippler
      15.07.2025 10:53

      "Контрразведчик должен знать всегда, как никто другой, что верить в наше время нельзя никому, порой даже самому себе. Мне можно." (Мюллер)


    1. s7eepz
      15.07.2025 10:53

      От любопытных есть защита. Загружаем свой образ системы и шифруем все luks при установке.


  1. tsbt
    15.07.2025 10:53

    На тему мифа 2 про равенство быстродействия на физическом железе и вм - голословное утверждение, которое легко опровергается тестами. Qemu kvm виртуализация люто тормозная, при выполнении серии нагрузочных испытаний, при поддержании профиля нагружения таким, чтобы 50% любых ресурсов системы всегда были свободны - величины задержек времени выполнения операций стабильно выше на 14-27% по сравнению с аналогичными на физическом стенде. На вм операции выполняются совершенно в другом кольце команд, ставить знак равенства - только намеренно вводить аудиторию в заблуждение.

    Итого - статья не имеет достаточных обоснований по каждому из тезисов. Это просто мнение маркетолога. Честное тестирование было бы более показательным.


    1. netch80
      15.07.2025 10:53

      На вм операции выполняются совершенно в другом кольце команд

      Вообще отношение хозяин/гость ортогонально "кольцу команд" (слишком x86 термин, ну да пусть).

      величины задержек времени выполнения операций стабильно выше на 14-27% по сравнению с аналогичными на физическом стенде.

      Какой был процессор, в каком режиме работала kvm (как минимум, EPT/NP или shadow tables), какая битность систем, были ли вложенные гости?


  1. dupdnp
    15.07.2025 10:53

    Половина ахинея или просто высосано из пальца