Если хотите пользоваться преимуществами VDS и при этом защититься от бессовестного оверсела, когда провайдер забивает ноду под завязку и не балансирует нагрузку — есть два пути.
Можно найти своего надёжного VDS-хостера. Или убить всех ситхов самому и сделать собственную звезду смерти (ноду) — заказать выделенный сервер и перенести туда все свои VDS. Ведь тогда мы точно будем знать, что все ресурсы только наши и всегда будут доступны. Да ещё и ставить сможем любую ОС, какую захотим, любой софт, который приспичит, а Битрикс будет радовать попугаями благодаря высокой частоте процессора. Кто знает, может даже начальство расщедрится и выпишет премию. Поехали!
Считаем, сколько у нас мидихлориан
Для начала нужно узнать суммарную стоимость аренды парка VDS и реальный расход ресурсов процессора, оперативной/постоянной памяти, количество IP. Выяснить частоту процессора, который выделен вашим VDS. Тут у всех хостеров индивидуально — смотрим графики, считаем цены.
Выбираем подходящее тело
Теперь, когда мы знаем текущие потребности по ресурсам, подбираем подходящий выделенный сервер.
Процессор
При выборе процессора важно учитывать — частота ядер может быть значительно выше, чем на текущих VDS. Если она выше в два раза — можно считать одно ядро дедика за два ядра VDS. Тут может возникнуть буря возмущения, но стоит понимать: все проекты разные, а это самый простой способ подобрать процессор. В общем, берём количество ядер, которые реально используются старыми VDS, если частота ядер около 2 Ghz делим на два.
Полученное значение — минимальное количество ядер дедика, которое требуется.
Память
С оперативной памятью и жёстким диском всё просто. Суммируем ресурсы VDS, добавляем 1 GB оперативной памяти и ~10 GB жёсткого диска. Эти дополнительные ресурсы нужны для работы ОС и панели управления гипервизором. Если собираетесь увеличивать количество контента — заложите запас ресурсов для роста проекта.
IP-адреса
Как и в случае с памятью, берём столько же адресов, как на VDS-ках + 1 под сам дедик.
Заказываем сервер, соответствующий нашим запросам, и с учётом упомянутых нюансов. В качестве ОС выбираем Debian 9, именно под эту ОС делают годную панель управления Proxmox.
Пробуждаем силу
Спустя некоторое время у нас на руках будет root-доступ на новенький дедик.
Пора сказать пару слов о теплой, ламповой и бесплатной панели управления гипервизором Proxmox. Да, сама панель бесплатна — разработчики зарабатывают на подписке. Подписчики, в свою очередь, получают более стабильную версию панели и возможность добавить больше нод в кластерном режиме. Но для нашей цели с головой хватит бесплатной версии.
Относительно недавно панель крупно обновилась, сейчас выглядит весьма современно и функционально. Поддерживает KVM и LXC-виртуализации, позволяет организовать своё ceph-облако, поддерживает возможность резервирования, словом умеет все, что может понадобиться рядовому пользователю VDS-хостинга.
Приступаем к установке Proxmox
Подключаемся к серверу по ssh, используя putty или другой ssh-клиент и последовательно выполняем команды:
echo "deb http://download.proxmox.com/debian/pve stretch pve-no-subscription" > /etc/apt/sources.list.d/pve-install-repo.list
wget http://download.proxmox.com/debian/proxmox-ve-release-5.x.gpg -O /etc/apt/trusted.gpg.d/proxmox-ve-release-5.x.gpg
apt update && apt dist-upgrade
apt install -y proxmox-ve postfix open-iscsi
apt remove -y os-prober
После завершения установки заходим в Proxmox, для авторизации обращаемся браузером на 8006 порт дедика
https://IP-дедика:8006
Входим также под root, интерфейс вполне прилично переведён на великий и могучий — можно спокойно пользоваться.
Как только залогинитесь, увидите сообщение с намёком подписаться. Делать это необязательно — панель не перестанет работать как в случае с триальными версиями программ.
Перед созданием первой VDS на новом сервере нужно настроить сетевой мост, чтобы все было по-взрослому. На этом этапе может понадобиться KVM или ipmi-kvm (если что-то пойдёт не так, и нужно будет восстанавливать доступность дедика по сети).
Возвращаемся в ssh и редактируем конфиг /etc/network/interfaces посредством плебейского nano или православного vim. Приводим конфиг к этому виду:
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
auto vmbr0
iface vmbr0 inet static
address IP-дедика
netmask маска-подсети
gateway шлюз
bridge_ports ens3 //Тут указываем интерфейс, через который дедик ходит в интернет.
Чтобы узнать его, найдите секцию, содержащую IP сервера в выводе команды «ip a».
bridge_stp off
bridge_fd 0
bridge_maxwait 0
Сохранив отредактированный конфиг, отправляем дедик на перезагрузку. Помимо настройки сети это также загрузит новое ядро.
После запуска сервера вновь обращаемся к SSH, чтобы скачать ISO-образы операционок для будущих VDS, а также образ sysrescuecd. Образы нужно сложить в директорию /var/lib/vz/template/iso
Для загрузки используем wget и прямые ссылки. Можно не скачивать образы систем, если вы хотите просто перенести существующие VDS на дедик. Но образ sysrescuecd может понадобиться для обслуживания VDS, поэтому очень рекомендуем скачать его сразу.
Отправляемся покорять далёкую галактику
Пришло время создавать на нашем дедике VDS: жмём кнопку «Создать VM» в правом верхнем углу панели Proxmox, заполняем поля на всех вкладках, используя данные любой из старых VDS. Формат образа выбираем qcow2.
Образы дисков будут создаваться по пути /var/lib/vz/images/[тут ID новой VDS].
Запрашиваем у VDS-хостера образы в формате qcow2 и загружаем их вместо ранее созданных. Выбираем VDS в левом списке и запускаем её кнопкой «Старт». Теперь мы получили свой виртуальный сервер со всеми проектами, остаётся только поправить настройки сети в самой VDS и сменить DNS на IP новой виртуалки. Сделать эти настройки можно через VNC, который доступен по кнопке «Консоль».
Мониторинг
Завершив перенос и сменив DNS, начинаем отслеживать показатели нагрузки. Это не обязательно, но полезно. Для такого мониторинга можно просмотреть общую сводку кластера.
В сводке ноды более подробная информация:
Если внезапно окажется, что какой-то ресурс ноды заканчивается, по сводкам VDS можно определить, какая из них потребляет много ресурсов, и оптимизировать сервисы проблемной VDS. Когда проекты перерастут текущий сервер, для перехода на более производительное железо достаточно будет переставить диски из одного сервера в другой. Такие работы занимают около 15 минут — куда быстрее, чем миграция VDS между нодами.
Минусы у дедика тоже, конечно, есть, но Proxmox помогает их нивелировать. Первое — это если ляжет дедик, полягут все VDS. Проблема решается резервированием, но понадобится больше дедиков. Ещё при использовании выделенного сервера нужно настроить raid 1 и следить за состоянием дисков при помощи smartd (и это Proxmox умеет). В случае с VDS эта же проблема решается заказом виртуалок у нескольких провайдеров, но это не очень удобно.
Переход на выделенный сервер — это разумный шаг, когда стоимость арендуемых VDS сопоставима с ценой выделенного сервера. Хотите, чтобы проекты летали — выбирайте скоростные NVMe-диски (быстрее SSD в 2-3 раза).