Сам себе VDS-провайдер

Если хотите пользоваться преимуществами VDS ^[1] и при этом защититься от бессовестного оверсела, когда провайдер забивает ноду под завязку и не балансирует нагрузку — есть два пути.

Можно найти своего надёжного VDS-хостера. Или убить всех ситхов самому и сделать собственную звезду смерти (ноду) — заказать выделенный сервер ^[1] и перенести туда все свои VDS ^[1]. Ведь тогда мы точно будем знать, что все ресурсы только наши и всегда будут доступны. Да ещё и ставить сможем любую ОС, какую захотим, любой софт, который приспичит, а Битрикс будет радовать попугаями благодаря высокой частоте процессора. Кто знает, может даже начальство расщедрится и выпишет премию. Поехали!

Считаем, сколько у нас мидихлориан

Для начала нужно узнать суммарную стоимость аренды парка VDS ^[1] и реальный расход ресурсов процессора, оперативной/постоянной памяти, количество IP. Выяснить частоту процессора, который выделен вашим VDS ^[1]. Тут у всех хостеров индивидуально — смотрим графики, считаем цены.

Выбираем подходящее тело

Теперь, когда мы знаем текущие потребности по ресурсам, подбираем подходящий выделенный сервер ^[1].

Процессор

При выборе процессора важно учитывать — частота ядер может быть значительно выше, чем на текущих VDS ^[1]. Если она выше в два раза — можно считать одно ядро дедика за два ядра VDS ^[1]. Тут может возникнуть буря возмущения, но стоит понимать: все проекты разные, а это самый простой способ подобрать процессор. В общем, берём количество ядер, которые реально используются старыми VDS ^[1], если частота ядер около 2 Ghz делим на два.
Полученное значение — минимальное количество ядер дедика, которое требуется.

Память

С оперативной памятью и жёстким диском всё просто. Суммируем ресурсы VDS ^[1], добавляем 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 ^[1] на новом сервере нужно настроить сетевой мост, чтобы все было по-взрослому. На этом этапе может понадобиться 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 ^[1], а также образ sysrescuecd. Образы нужно сложить в директорию /var/lib/vz/template/iso
Для загрузки используем wget и прямые ссылки. Можно не скачивать образы систем, если вы хотите просто перенести существующие VDS ^[1] на дедик. Но образ sysrescuecd может понадобиться для обслуживания VDS ^[1], поэтому очень рекомендуем скачать его сразу.

Отправляемся покорять далёкую галактику

Пришло время создавать на нашем дедике VDS ^[1]: жмём кнопку «Создать VM» в правом верхнем углу панели Proxmox, заполняем поля на всех вкладках, используя данные любой из старых VDS ^[1]. Формат образа выбираем qcow2.

Образы дисков будут создаваться по пути /var/lib/vz/images/[тут ID новой VDS].

Запрашиваем у VDS-хостера образы в формате qcow2 и загружаем их вместо ранее созданных. Выбираем VDS ^[1] в левом списке и запускаем её кнопкой «Старт». Теперь мы получили свой виртуальный сервер со всеми проектами, остаётся только поправить настройки сети в самой VDS ^[1] и сменить DNS на IP новой виртуалки. Сделать эти настройки можно через VNC, который доступен по кнопке «Консоль».

Мониторинг

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

В сводке ноды более подробная информация:

Если внезапно окажется, что какой-то ресурс ноды заканчивается, по сводкам VDS ^[1] можно определить, какая из них потребляет много ресурсов, и оптимизировать сервисы проблемной VDS ^[1]. Когда проекты перерастут текущий сервер, для перехода на более производительное железо достаточно будет переставить диски из одного сервера в другой. Такие работы занимают около 15 минут — куда быстрее, чем миграция VDS ^[1] между нодами.

Минусы у дедика тоже, конечно, есть, но Proxmox помогает их нивелировать. Первое — это если ляжет дедик, полягут все VDS ^[1]. Проблема решается резервированием, но понадобится больше дедиков. Ещё при использовании выделенного сервера нужно настроить raid 1 и следить за состоянием дисков при помощи smartd (и это Proxmox умеет). В случае с VDS ^[1] эта же проблема решается заказом виртуалок у нескольких провайдеров, но это не очень удобно.

Переход на выделенный сервер ^[1] — это разумный шаг, когда стоимость арендуемых VDS ^[1] сопоставима с ценой выделенного сервера. Выбрать готовую конфигурацию или собрать свой дедик вы можете на FirstDEDIC ^[2]. Хотите, чтобы проекты летали — выбирайте скоростные NVMe-диски (быстрее SSD в 2-3 раза).

Автор: Elaugaste

Источник ^[3]