Один сервис — а не «всё в одной куче» одна виртуалка
Разворачиваем и сопровождаем виртуализацию для офисов и распределённых компаний. Proxmox как основной выбор, VMware и Hyper-V — где это оправдано. Размещение — у вас на железе, в дата-центре или гибридом. Без догм: виртуалка для всего, кроме того, для чего она вредна — например, нагруженной 1С.
01 / Изоляция
Падение одного — не падение всего
Перезагрузили 1С — терминалка работает. Обновили почту — файлы доступны. Каждая роль — своя виртуалка, проблемы не размазываются на всю инфраструктуру.
02 / Гибкость
Новый сервер — за минуты
Нужна виртуалка под новую задачу — развернули. Нужно больше памяти 1С — выделили. Не нужно покупать железо под каждый отдельный сервис.
03 / Переносимость
Сервер как файл
Виртуалка целиком — это один большой файл. Сгорело железо? Развернули копию на новом — работа продолжается. Не нужно заново ставить ОС, софт, настройки.
Знакомо
Когда сервер — это чулан с проводами
Несколько фраз из жизни компаний, у которых «всё на одном сервере». И — личная история про то, как мы сами лет пятнадцать назад делали именно так.
«Обновляем 1С — отключи всех заранее, потому что ляжет вообще всё»
— айтишник, 30 сотрудников
«Сервер сгорел в субботу. Подняли в среду — три дня компания стояла»
— директор, 25 сотрудников
«Боимся обновлять Windows на сервере. Там же всё разом — и 1С, и почта, и файлы»
— РОП, 50 сотрудников
«Купили новый сервер под отдельный сервис. Теперь у нас в шкафу пять железок»
— владелец, 40 сотрудников
Из практики
Сервер 2010 года: домен, 1С, терминалка и роутер на одной железке
В 2010 мы собрали клиенту первый «настоящий» сервер. По тогдашним меркам — серьёзная штука. На одной коробке жило вообще всё: контроллер домена, файловое хранилище, сервер 1С, терминальный сервер для удалённых сотрудников. И поверх — Kerio в качестве роутера и почты. Одна операционная система, одна точка отказа.
С виртуализацией тогда мало кто связывался — продукты были сырые, а железо нужного уровня для малого бизнеса просто не тянуло. Поэтому решение «всё в одну кучу» казалось единственно возможным. И действительно работало. До первой серьёзной перезагрузки. Или до первого обновления, которое что-то ломало. Или до момента, когда нагрузка от 1С начинала душить терминалку, а пользователи писали в чат «опять всё тормозит».
Та компания давно закрылась. А стыдно за то решение нам до сих пор. Не потому что мы тогда что-то делали неправильно — по тогдашней реальности это был адекватный выбор. А потому что сегодня — реальность другая, и так больше делать нельзя. Виртуализация перестала быть роскошью — стала стандартом.
Главный принцип
Не держать все яйца в одной корзине
И не покупать под каждое яйцо отдельный сервер. Виртуализация решает обе задачи разом: разные роли — разные операционные системы — настоящая изоляция, на одном физическом сервере. Ниже — четыре пункта, на которых это держится.
01
Один сервис — одна виртуалка
Контроллер домена — отдельно. Файловый сервер — отдельно. 1С — отдельно. Каждая роль в своей виртуальной машине, со своей ОС, своими настройками, своей памятью.
02
Снэпшоты до изменений
Перед обновлением — снимок виртуалки. Что-то пошло не так? Откатились за минуты к предыдущему состоянию. Не часами разбирать, что сломалось.
03
Виртуалка — это файл
Целиком сохраняется как файл, целиком переносится. Сгорел сервер — развернули копию на новом железе и работаете дальше. Не три дня настройки с нуля.
04
Виртуализация — не везде
У неё есть штраф производительности 20–30%. Для 1С с серьёзной нагрузкой это критично. Выбор «удобство или производительность» — делаем осознанно.
Частые ошибки
Где люди спотыкаются на виртуализации
Шесть типичных сценариев. Половина — про то, что виртуализации нет там, где она нужна. Половина — про то, что её вкорячили туда, где она вредит. И первое, и второе одинаково больно.
Ошибка 01
«Всё на одном сервере»
Один Windows Server, на котором и контроллер домена, и файлы, и 1С, и терминалка, и почта. Удобно: одна железка, одна лицензия, одна ОС. До первого обновления, перезагрузки или сбоя. Любая проблема с любым сервисом убивает работу всей компании. Любое обновление — операция с риском обвалить всё. Любой сервис тянет к себе ресурсы и душит соседей.
Как правильноГипервизор (Proxmox) на сервере, отдельные виртуалки под каждую роль. Контроллер домена, файлы, 1С, терминалка — каждый сам по себе. На том же физическом железе, без покупки нового.
Ошибка 02
Зоопарк физических серверов
Обратная крайность. Каждой задаче — отдельная железка. Под домен — один сервер, под 1С — второй, под файлы — третий, под почту — четвёртый. В шкафу — пять-семь железок, каждая греется, шумит, ест электричество, требует обслуживания. Использование ресурсов — 10–20% на каждой. Деньги вложены, эффективность нулевая.
Как правильноОдин-два мощных гипервизора с распределением нагрузки. Виртуалок может быть десять — а железа два. Это нормально, и это реальная экономия в долгую.
Ошибка 03
Виртуализировать всё подряд, включая 1С
Установили Proxmox — и засунули туда всё, что было. В том числе клиент-серверную 1С с реальной нагрузкой и базой на десятки гигабайт. Через месяц пользователи начинают жаловаться, что «всё стало в два раза медленнее». А оно реально стало медленнее. 1С особенно чувствительна к процессору и диску, а виртуализация добавляет накладные расходы на каждую операцию.
Как правильноТяжёлая 1С — на голом железе. Без слоя гипервизора. Удобства снэпшотов и переносимости тут проигрывают потерям производительности. Зато всё остальное — домен, файлы, почта — спокойно живёт виртуально.
Ошибка 04
Гипервизор без запаса ресурсов
Виртуализация не создаёт ресурсы из воздуха. Если на сервере 16 ГБ памяти и обычный i5 — десять виртуальных машин на нём будут жить так же плохо, как десять ролей на одной ОС. А чаще — ещё хуже, потому что гипервизор сам что-то ест. Логика «впихнём побольше виртуалок, чтобы окупить лицензию» не работает.
Как правильноСчитать ресурсы под реальные потребности виртуалок плюс 20–30% запаса. Память — самый критичный ресурс, экономить на ней нельзя. И диски — лучше SSD/NVMe, виртуалки на HDD сегодня уже несерьёзно.
Ошибка 05
«Виртуалки же бэкапятся сами»
Распространённое заблуждение. Снэпшоты гипервизора — это не бэкап. Они живут на том же физическом сервере, что и виртуалки. Сгорел сервер — пропали и виртуалки, и снэпшоты разом. Виртуализация упрощает бэкапы (виртуалку можно скопировать целиком как файл), но не делает их за вас.
Как правильноРегулярный бэкап виртуалок на отдельное хранилище — другой NAS, другой сервер, S3-облако. И обязательно проверка восстановления раз в месяц. Подробно про схему 3–2–1 — на странице файлового сервера.
Ошибка 06
VMware «потому что престижно»
Десять лет назад VMware был стандартом «по умолчанию» для серьёзной виртуализации. Сегодня — после изменений в лицензировании и ухода с российского рынка — для нового внедрения в малом бизнесе это уже сомнительный выбор. Стоит дорого, поддержка непредсказуемая, лицензионные риски реальные. Для большинства задач Proxmox делает то же самое — бесплатно и без ограничений.
Как правильноЕсли вся инфраструктура уже на VMware — оставайтесь, миграция — это отдельный проект. Для нового внедрения — Proxmox. Для специфических Microsoft-сценариев — Hyper-V. Брать VMware «как все» — больше не аргумент.
Что делаем
Работы по виртуализации
От подбора гипервизора и проектирования до миграции существующих физических серверов в виртуальную среду без простоя. Бэкапы виртуалок, снэпшоты, мониторинг ресурсов — в абонентке.
Развёртывание гипервизора
Proxmox, VMware, Hyper-V
- Подбор гипервизора под задачи. В большинстве случаев — Proxmox. Если особые сценарии — Hyper-V или VMware. Не «как у всех», а под конкретную ситуацию.
- Расчёт железа под нагрузку. Сколько памяти, ядер, дисков нужно реально — с запасом 20–30%, без перерасхода «на всякий».
- Установка и базовая настройка. Гипервизор, сеть, хранилище, кластеризация при необходимости. Документируем каждый шаг.
- Шаблоны виртуалок. Стандартный образ для нового сервера в компании — разворачивается за 10 минут вместо двух часов с нуля.
Миграция в виртуалки
Из физического в виртуальное
- P2V — Physical to Virtual. Снимаем образ работающего физического сервера, разворачиваем как виртуалку. Без переустановки, с сохранением всех настроек.
- Разнесение ролей. Если на одном физическом сервере жили 5 ролей — раскладываем по 5 виртуалкам. Изоляция, которой никогда не было.
- Миграция в окно. Подготавливаем заранее, переключаем в нерабочее время — обычно ночь с пятницы на субботу. Утром понедельника никто не замечает разницы.
- Откат на случай проблем. Старый сервер не выключаем сразу — держим неделю в режиме «горячего резерва». Если что-то пошло не так — переключаемся обратно.
Снэпшоты и откаты
Машина времени для виртуалок
- Снэпшот перед каждым изменением. Обновление, патч, эксперимент — снимок до. Что-то сломалось — откатились за минуты к рабочему состоянию.
- Регулярные снэпшоты по графику. Раз в день, раз в неделю — частоту согласуем с владельцем данных. На случай «вчера всё работало, а сегодня нет».
- Чистка старых снэпшотов. Снэпшоты занимают место. Настраиваем автоматическое удаление старых — иначе через год диск забит наполовину их истории.
- Снэпшот ≠ бэкап. Объясняем разницу. Снэпшоты живут на том же гипервизоре. Для настоящей защиты — отдельные бэкапы виртуалок.
Бэкап виртуальных машин
Не «снэпшоты», а настоящий
- Регулярный бэкап целых виртуалок. Виртуалка — это файл. Копируется целиком, восстанавливается целиком. Не нужно по отдельности бэкапить ОС, базы, настройки.
- Хранение в другом месте. Отдельный NAS, второй сервер, S3-облако. Главное — не на том же гипервизоре. Сгорело железо — копии целы.
- Proxmox Backup Server. Отдельное специализированное решение под бэкапы Proxmox: дедупликация, шифрование, проверка целостности. Бесплатно, как и сам Proxmox.
- Проверка восстановления. Раз в месяц поднимаем случайную виртуалку из бэкапа в тестовой среде. Чтобы «бэкап есть» означало «реально восстановимся».
Мониторинг и оптимизация
Чтобы видеть узкие места
- Мониторинг ресурсов. Память, CPU, диск, сеть — по каждой виртуалке. Видим, кому не хватает, кто простаивает, где намечается узкое место.
- Перераспределение нагрузки. Виртуалка задыхается — добавили памяти или ядер на лету. Без перезагрузок и простоев.
- Миграция между хостами. При наличии нескольких физических серверов — перенос работающей виртуалки с одного на другой. Без выключения.
- Регулярная ревизия. Раз в полгода смотрим: какие виртуалки нужны, какие забыли, кому пора расширяться. Без накопления «зомби-виртуалок».
Отказоустойчивость
Когда нельзя простаивать
- Кластер из двух гипервизоров. Виртуалки реплицируются между серверами. Один лёг — второй продолжает обслуживать. Простой — минуты, не дни.
- Общее хранилище. Виртуалки на сетевом хранилище — не на локальных дисках гипервизоров. Любой узел кластера может их запустить.
- Резервный гипервизор в облаке. Гибридная модель: основной кластер у вас, в дата-центре — холодный резерв. Катастрофа в офисе — поднимаемся за час в облаке.
- Документированный план восстановления. Что делать при отказе физического сервера, повреждении хранилища, потере виртуалки. Заранее, не в момент аварии.
Где разворачивать
Гипервизоры и места размещения
Два независимых вопроса: какой гипервизор и где он физически живёт. Сначала про гипервизоры, потом про места размещения. И отдельный важный пункт — что виртуализировать не надо.
Proxmox VE
Базовый выбор для большинства SMB. Бесплатный, без ограничений по функциональности, взрослый, проверенный годами. Есть всё необходимое: кластеры, бэкапы, репликация, веб-интерфейс. Установили — работает.
Hyper-V
От Microsoft. Хорош в специфических сценариях — когда у сервера основная задача (например, контроллер домена), а пара виртуалок выполняют вспомогательную роль. Как основная платформа виртуализации обычно не лучший выбор.
VMware
Раньше — золотой стандарт. После изменений лицензионной модели и ухода с российского рынка для нового внедрения — спорный выбор. Поддерживаем существующие установки, помогаем мигрировать на Proxmox при желании клиента.
У вас на железе
Сервер физически в офисе или серверной. Полный контроль, низкие задержки, никакой ежемесячной аренды — но нужны условия для серверной (питание, охлаждение, интернет с резервом). Базовый сценарий для большинства SMB.
В дата-центре
Гипервизор в коммерческом дата-центре. Нет своих серверной, питания, охлаждения — за это отвечает площадка. Платите за аренду стойки или сервера, получаете гарантию uptime. Хорошо для распределённых компаний без офиса-якоря.
Гибрид: офис + облако
Основной кластер у вас в офисе, резервный — в российском облаке (в приоритете Yandex Cloud и Selectel, есть и MWS). При катастрофе в офисе — поднимаемся в облаке. В обычное время облако спит, плата минимальная. Реальный план B без капвложений.
Полностью в облаке (IaaS)
Все виртуалки — у облачного провайдера. Без своих серверов вообще. Платите за фактическое потребление, легко масштабироваться. Хорошо для стартапов и удалённых команд. Минус — постоянная плата растёт с ростом инфраструктуры.
Что НЕ виртуализируем
Тяжёлая 1С — на голом железе. Клиент-серверная 1С с реальной нагрузкой и большой базой особенно чувствительна к процессору и диску. В виртуализации она работает в 2–3 раза медленнее — это не 20%, это критично. Удобство снэпшотов и переносимости не оправдывает потерь скорости.
Хранилище для виртуалок
SSD/NVMe — стандарт. HDD под виртуалки сегодня уже несерьёзно. Для кластеров — общее сетевое хранилище: SAN, iSCSI, Ceph. Чтобы любой узел мог запустить любую виртуалку, и переносы между хостами проходили прозрачно.
Цифры
Что фиксируем в SLA
Виртуализация даёт измеримые показатели по доступности, скорости восстановления и утилизации железа. Это не «стало лучше» — это конкретные цифры в договоре.
99,9%
Доступность с кластером
Два гипервизора в кластере с репликацией виртуалок. Один лёг — второй подхватил, простой минимальный.
5–15 мин
Откат из снэпшота
Вместо часов разбирательств «что сломалось» — откат к снимку до изменений. Виртуалка возвращается к рабочему состоянию.
−40%
Расходов на железо
Один-два мощных гипервизора вместо пяти-семи отдельных серверов. Меньше железа, меньше места, меньше электричества, меньше обслуживания.
10 мин
Новая виртуалка
Из готового шаблона — за 10 минут вместо двух часов установки с нуля. Когда нужно срочно поднять тестовый сервер или новый сервис.
3–2–1
Бэкапы виртуалок
Три копии, два разных носителя, одна — удалённо. Виртуальная машина — не исключение из правил резервного копирования.
P2V
Миграция без переустановки
Существующий физический сервер переезжает в виртуальную среду «как есть» — со всеми настройками, ПО, данными. Без переустановки и потерь.
Как начинаем
От аудита до работающего гипервизора
Срок зависит от сценария. Развёртывание Proxmox с нуля и переезд 4–5 виртуалок — обычно 1–2 недели. Кластер с отказоустойчивостью — 3–4 недели. Гибрид с облаком — отдельный проект.
Аудит
Что у вас сейчас на серверах, какая нагрузка, какие сервисы. Что выгодно виртуализировать, а что лучше оставить.
Проект
Гипервизор, состав виртуалок, расчёт ресурсов, схема бэкапов. Где железо — у вас, в дата-центре, гибрид. Смета.
Развёртывание
Гипервизор, виртуалки, миграция существующих серверов. Переключения — в нерабочее время, чтобы не задеть пользователей.
Сопровождение
Мониторинг, обновления, бэкапы, добавление новых виртуалок, перераспределение ресурсов. В рамках абонентки.
С нами уже
Виртуализация — под задачу
Два примера: уход с дорогого облака на свой сервер и гибридная архитектура для распределённой команды.
Производственная компания
Промпроизводство
Анонимно
Анонимно
Старые серверы — 4 железки разного возраста: контроллер домена, файлсервер, сервер бэкапов, сервер мониторинга. Шумят, греются, занимают полстойки и тянут лишние 2 кВт электричества. Заменили на один сервер под Proxmox VE с запасом по ресурсам в 3 раза. Все 4 роли стали виртуалками со снэпшотами и живой миграцией. Перенос за неделю по ночам, 0 простоев в рабочее время.
4 → 1
сервер вместо четырёх
×3
запас ресурсов
0
простоев в рабочее время
Мебельное производство
Производство мебели
Анонимно, 2025
Анонимно, 2025
Производство на 70+ сотрудников. Клиент захотел уровень защиты, при котором даже физический доступ к серверу не даст увидеть данные. Развернули Proxmox VE + ZFS со сквозным шифрованием всех виртуальных машин. При перезагрузке сервера или нажатии «тревожной кнопки» все ВМ блокируются — запустить можно только ручным вводом ключа или скриптом с защищённой паролем флешки.
Proxmox+ZFS
с шифрованием томов
1 нажатие
тревожной кнопки
0
данных без ключа шифрования
Стоимость
Сколько это стоит
Если вы уже наш клиент по абонентскому обслуживанию — большинство задач из этого раздела не потребует дополнительных расчётов. Если работаете с нами впервые — посчитаем стоимость отдельно.
Для клиентов на обслуживании
0 ₽
Все типовые задачи по этой услуге уже входят в абонентское обслуживание. Дополнительных счетов — нет.
Узнать про абонентское обслуживание →
Разовый проект
от 30 000 ₽
Развёртывание виртуализации
Установка гипервизора, настройка хранилища, миграция существующих систем в виртуальные машины. Срок — 7–14 рабочих дней.
Обсудить проект →
Вопросы
Что спрашивают про виртуализацию
Если своего вопроса не нашли — напишите, ответим без маркетинга.
У нас 30 человек. Реально ли нам нужна виртуализация?
Если у вас на сервере живёт больше одной роли (контроллер домена, файлы, 1С, почта) — да, имеет смысл. Виртуализация — не «для больших». Это инструмент изоляции и удобства, который окупается даже на одном физическом сервере. Альтернатива — «всё на одной ОС» с её рисками. И никто не заставляет покупать новое железо: Proxmox разворачивается на том же сервере, на котором сейчас всё работает.
Почему Proxmox, а не VMware?
Десять лет назад VMware был стандартом. Сегодня — после изменений лицензионной модели и ухода с российского рынка — выбор для нового внедрения сомнительный: цена выросла, поддержка непредсказуемая. Proxmox делает то же самое — бесплатно, без ограничений, со всеми нужными функциями (кластеры, бэкапы, репликация). Если вы уже на VMware и всё работает — оставайтесь, миграция — отдельный проект.
Можно ли виртуализировать 1С?
Технически — да, физически — лучше нет. Особенно клиент-серверную 1С с серьёзной нагрузкой. Виртуализация добавляет накладные расходы на каждую операцию, а 1С особенно чувствительна к скорости процессора и диска. На бумаге потери — 20–30%, на тяжёлых базах — в 2–3 раза. Поэтому 1С с реальной нагрузкой мы сажаем на голое железо. А вспомогательные сервисы — домен, файлы, почта, терминалка — спокойно живут в виртуалках.
Что лучше: своё железо или облако?
Зависит от ситуации. У большинства SMB своё железо в офисе или серверной — выгоднее в перспективе 3–5 лет, особенно если есть условия для размещения. Облако (IaaS на российских провайдерах — в приоритете Yandex Cloud и Selectel) — хорошо для распределённых команд без офиса-якоря, для стартапов с непредсказуемой нагрузкой, как резервная площадка. Гибрид (основное у вас, резерв в облаке) — оптимальный план B без капвложений в дублирующее железо. На аудите смотрим конкретно вашу ситуацию.
Сколько ресурсов нужно гипервизору?
Сам гипервизор Proxmox ест очень мало — 2–4 ГБ памяти и пару процентов CPU. Остальное — виртуалкам. Считаем как сумму потребностей всех виртуалок плюс 20–30% запаса на пиковую нагрузку и рост. Память — самый критичный ресурс: на ней экономить нельзя, иначе виртуалки начнут конкурировать. Диски — обязательно SSD/NVMe, HDD под виртуалки сегодня — чёрная пятница для пользователей.
А если сгорит гипервизор — что будет с виртуалками?
Ровно то же, что с обычным сервером. Поэтому два уровня защиты. Первый — кластер из двух гипервизоров с репликацией: один сгорел, виртуалки запускаются на втором. Простой минут 10–15. Второй — отдельные бэкапы виртуалок на независимое хранилище (другой NAS, S3-облако): сгорел весь кластер — разворачиваем из бэкапа на новом железе. Простой — несколько часов, но данные живы. Оба уровня — стандартная практика, отдельная плата только за кластер.
Начнём с аудита
Покажем, какие сервисы у вас просятся в виртуалки — и какие лучше не трогать
За короткую встречу разберём текущую инфраструктуру: какие серверы что делают, какая нагрузка, что виртуализировать выгодно, что оставить на голом железе. По итогам — план миграции с реальными сроками и сметой.
- Аудит инфраструктуры — бесплатно
- Подбор гипервизора и места размещения под задачи
- Миграция в виртуалки без простоя