Proxmox для небольшой компании: нужен ли и на чём спотыкаются

У компании на двадцать-пятьдесят человек обычно есть один-два физических сервера. На них крутится 1С, файлы, иногда домен и терминальный доступ. Вопрос, который рано или поздно возникает: разносить это по виртуальным машинам или оставить как есть.

Ответ зависит от того, сколько задач на сервере и как часто его трогают. Разберём по порядку и начнём с того, когда виртуализация не нужна.

Когда виртуализация не нужна

Когда на сервере одна задача, и её никто не меняет.

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

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

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

Всё остальное: доводы за.

Что реально даёт Proxmox

Три вещи, ради которых вообще стоит на это идти.

Несколько изолированных машин на одном железе. 1С со своей базой данных, файловый сервер, домен, терминальный сервер: каждый в своей системе, со своими обновлениями и своими правами. Когда что-то одно ломается, остальное продолжает работать. На физическом сервере с несколькими ролями так не выходит: обновили одно, отвалилось соседнее.

Снапшот перед изменением. Состояние машины фиксируется целиком, и если после изменения что-то поехало, откат занимает минуту.

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

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

Одна оговорка, без которой этот совет в одном случае навредит. Откатывать снапшотом можно не всякую машину. Если она входит в домен Windows, возврат на состояние двухнедельной давности ломает её доверие к домену: у компьютера есть собственный пароль в домене, он меняется по расписанию, и восстановленная система будет помнить старый. С самим контроллером домена ещё строже: его так восстанавливать нельзя вовсе, для этого есть отдельная процедура. Разбор: в статье про Active Directory.

Отвязка от железа. Виртуальная машина не знает, на каком сервере она работает. Меняете сервер: переносите файл машины на новый и запускаете. Без переустановки системы, без повторной настройки, без поиска драйверов под новое железо. На физическом сервере такой переезд может занять до нескольких дней, и простоя не избежать.

Отдельно стоит знать, что Proxmox умеет не только полноценные виртуальные машины, но и контейнеры: более лёгкий вариант, где система общая, а изолируется только окружение. Для вспомогательных служб контейнер экономнее, для 1С и Windows нужна полноценная машина.

Диски: главный источник проблем

Здесь ошибаются чаще всего, и ошибки дорогие, потому что исправляются переустановкой.

Файловая система выбирается при установке, и поменять её потом трудно. Вариантов два: классическая связка с логическими томами и файловая система с контролем целостности. Первая проще и предсказуемее. Вторая даёт снапшоты на уровне хранилища, сжатие и защиту от незаметной порчи данных, но требует заметно больше оперативной памяти и вычислительных ресурсов.

Главная ловушка: поставить файловую систему с контролем целостности поверх аппаратного контроллера дисков. Ей нужен прямой доступ к дискам: она сама следит за целостностью и сама решает, откуда читать. Контроллер, который прячет диски за собой и отдаёт один логический том, ломает всю эту механику. Работать будет, а защита, ради которой всё затевалось, не сработает. Если сервер с аппаратным контроллером, либо переводите его в режим прямого доступа к дискам, либо берите классический вариант.

Тонкое выделение места, если оно включено: вторая ловушка. Часть типов хранилища в Proxmox выделяют место виртуальной машине по факту заполнения, а не всё сразу: диск объявлен на пятьсот гигабайт, а реально занимает восемьдесят. Другие типы хранилища резервируют весь объём в момент создания диска: там этой ловушки просто нет.

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

Лечится это не после, а до: знать, какой тип выделения у вашего хранилища, и если он тонкий, следить за реальной занятостью, а не только за объявленными объёмами.

Локальные диски или сетевое хранилище. Для одного сервера ответ почти всегда «локальные»: быстрее, проще, меньше того, что может отказать. Сетевое хранилище нужно, когда серверов несколько и машины должны переезжать между ними. Заводить его ради одного сервера: усложнять без выигрыша.

И отдельно про носители: 1С с базой на обычных механических дисках работает мучительно. Если на сервере планируется учётная система, под неё нужны SSD: это не роскошь, а условие, при котором пользователи не будут ждать по десять секунд на каждом документе.

Как виртуальные машины попадают в сеть офиса

Через мост: физический сетевой интерфейс сервера объединяется с виртуальными в одну общую сеть.

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

Сложности начинаются, когда сеть офиса поделена на сегменты: тогда нужно решить, в какой сегмент попадает каждая машина, и настроить это на стороне сервера и на стороне коммутатора согласованно.

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

Резервные копии: снапшот - это не копия

Разница принципиальная, и на ней теряют данные.

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

Резервная копия - это выгрузка машины целиком в другое место. Proxmox умеет делать её по расписанию штатными средствами, и для небольшой компании этого достаточно: копия машины уезжает на отдельный диск или сетевое хранилище.

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

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

1С на виртуальной машине

Работает, и это самый частый сценарий у наших клиентов.

Требования обычные: достаточно памяти под базу данных, диски SSD, отдельная машина под сервер баз данных, если пользователей много. Мы работаем и с MS SQL, и с PostgreSQL: обе живут на виртуальных машинах нормально.

Здесь у виртуализации отдельная специфика, и с ней стоит определиться сразу: основная защита базы - резервная копия, сделанная штатными средствами 1С или сервера баз данных, а не снапшот всей машины. Снапшот перед обновлением платформы или конфигурации 1С на практике делают нечасто, и полагаться на него как на план восстановления не стоит: если обновление не задалось, базу поднимают из её собственной выгрузки, а не откатывают снапшотом весь сервер.

И если снапшот машины всё же снимают (например, заодно с плановым обслуживанием сервера), стоит помнить: он не заменяет резервную копию базы. Снапшот фиксирует состояние диска в момент, когда база могла как раз писать данные, и восстановленная из такого снапшота копия способна оказаться в неаккуратном состоянии.

Нужен ли кластер

Небольшой компании - обычно нет.

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

Когда стоит звать нас

Установить Proxmox и запустить пару машин можно самостоятельно: материалов достаточно, а цена ошибки на этапе, пока туда не переехали боевые задачи, невелика.

Разговор меняется на переезде. Миграция работающего физического сервера на виртуальную машину - операция, которую делают один раз и с планом отката: надо выбрать окно, перенести данные, проверить, что всё запустилось, и сохранить возможность вернуться, если не запустилось. Сюда же: выбор дисковой конфигурации под конкретную нагрузку, стыковка с сервером баз данных и настройка резервного копирования так, чтобы оно проверялось, а не просто выполнялось.

Мы в ITHOUSE обслуживаем серверы и виртуализацию для 25+ компаний, самому долгому сопровождению - 15 лет. Работаем по будням с 9:00 до 19:00, реагируем на заявку в течение часа. Абонентское обслуживание - от 25 000 ₽ в месяц, разовые работы - от 4 000 ₽ в час, проектные считаем по смете. Лицензии 1С продаём и продлеваем.

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