Если хотите пользоваться преимуществами 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 сопоставима с ценой выделенного сервера. Выбрать готовую конфигурацию или собрать свой дедик вы можете на FirstDEDIC. Хотите, чтобы проекты летали — выбирайте скоростные NVMe-диски (быстрее SSD в 2-3 раза).
Комментарии (15)
riv1329
22.06.2018 05:52Тех кто вдохновился этой статьёй, я прошу обратит внимание не только на стоимость аренды выделенного сервера, но и на ту дополнительную работу, которую необходимо будет делать:
1. настройка и поддержание в рабочем состоянии системы резервного копирования
2. Нужна дополнительная площадка (ещё один выделенный сервер?) для резевного копирования
3. Создание и поддержание работоспособности системы отказоустойчивости. Что будет, если в выделенном сервере выйдет из строя диск? Если простой недопустим, вам придется куда-то мигрировать виртуальные машины, причем это место должно быть заранее настроено и все мероприятия по переносу должны быть отрепетированы
4. К обслуживаю всех виртуальных машин теперь добавится обслуживание как минимум двух серверов: гипервизора и сервера для резервных копий. Я имею в виду вопросы установки обновлений, мониторинг, изменение конфигураций.
5. Вопросы производительности и масштабирования теперь придётся решать вам. Например, даже при использовании SSD, дисковая подсистема может быть перегружена, например интенсивной записью. Что делать? То ли SSD менять, то ли включить writeback, но что будет с целостностью данных? Кончилось место на гипервизоре, а у вас были созданы снимки, в некоторых случаях в виртуальную машину прилетит ошибка WriteError, хорошо, если там linux — он просто заморозит операции ввода-вывода, а windows порушит ntfs и хорошо, если вы узнаете об этом сразу, а не через несколько дней, ведь резервные копии перестали создаваться…
Если все вышеперечисленные проблемы решать качественно, что количество головной боли может удвоится и даже утроится. По мере роста вашего проэкта, проблемы будут возникать все более разнообразные и без опыта эксплуатации нагруженных систем, решить их будет труднее. По сути, вам придется пройти тот-же путь, что и хостеру vps. Зато наступив на все грабли, теперь вы сами сможете предоставлять подобные услуги :-)
Я просто хотел обратить внимание, что очень часто за виртуальную машину проще заплатить, чем заниматься решением всех этих проблем. И уж точно порог начинается не от одного полностью загруженного гипервизора.
Ещё один момент — это само класс оборудования. Может оказаться так, что вам будет экономически невыгодным арендовать маленький сервер, из-за того, что сумма ресурсов, необходимых для ваших виртуальных машин в составе, так сказать большого сервера, может оказаться дешевле.
Elaugaste Автор
22.06.2018 05:58Весьма конструктивные замечания.
Стоит заметить, что резервное копирование proxmox поддерживает из коробки, по моему опыту проблем с ним пока не возникало. Отдельный сервер для резервных копий — это отличное решение, но далеко не всегда обязательное. Многое зависит от уровня отказоустойчивости, который устроит, и финасов, которые вы готовы вложить в это.
Raid 1 решает проблему внезапного выхода диска из строя.
Мониторинг smart сообщит о необходимости замены диска ещё до того, как он станет неработоспособен.
Сложности в поддержке инфраструктуры это почти не добавит, если уже есть парк виртуалок, то есть и средства мониторинга, и управления конфигурацией. Ещё один сервер погоды не сделает.
Вопросы производительности и масштабирования всегда нужно решать самому, а описанное решение даёт куда больше контроля, чем просто VDS у хостера.TaHKucT
22.06.2018 08:16Мониторинг smart сообщит о необходимости замены диска ещё до того, как он станет неработоспособен.
Далеко не факт. Бывает что диск в смарте пишет о проблеме, но при этом нормально работает годами (приличный хостер вам его конечно сразу поменяет), а бывает что диск умирает «без объявления войны»
riv1329
22.06.2018 17:01Я как раз пишу по той причине, что прошёл уже этот путь. Не спорю, все проблемы можно побороть, но времени на это потребуется не один вечер, как обманчиво может показаться из этой статьи.
Да и proxmox у меня вызывает какое-то стойкое чувство не полной надёжности. То тут косяк, то там не работает, то масса нюансов не описана в документации, а как описано, так не работает, и т.д.… но работа, конечно у них проделана адская. Пользователи, привилегии, консоль — в основном из-за этого и использую. Пока мог обходится своими руками, использовал libvirt + virsh cli или virt-manager — такая связка работает очень предсказуемо.
Приведу пример ошибочного представления о сложности задачи.
raid1 не решит проблему, и я бы сказал, что опасен без резервной площадки. Смотрите, насколько неидеальное это решение:
1. smart скорее всего вас не предупредит. Какого-то явного сигнала не будет, вам нужно интерпретировать параметры и потом доказать сапорту, что диск надо менять, а они, скорее всего откажутся, пока он окончательно не выйдет из строя.
2. Перед тем как выйти из строя, многие диски начинают сыпать неверными данными при чтении (вероятно и записывают с ошибками). raid1 ни программный, ни аппаратный, не проверяет корректность чтения, если оборудование не выставило флаг ошибки. BAD-ы на этом этапе не идут.
3. Замена диска, скорее всего будет осуществляться сапортом днём, и именно днём вы не сможете остановить сервер, т.к. на нем работают виртуальные машины с сервисами. Т.е. вам все равно потребуется резервная площадка.
4. После замены диска, может оказаться, что и второй диск тоже не исправен! Он кое-как работал, но синхронизация добила его, все, у вас всё упало.
Может показаться что это маловероятное стечении обстоятельств, но я через это проходил. Причем произойдет это всё когда вы расслабитесь, после полугода нормальной работы, например, а вы на на море. Т.е мало того, что оборудование нужно резервировать, ваши знания о гипервизорах тоже нужно резервировать в чей-то голове.
И да, в статье ничего не сказано, что хостеры сдают в аренду разные сервера, но брать нужно только с ECC RAM иначе с этой стороны можно хлебнуть.
Конечно, можно сконструировать ситуацию, когда виртуальные машины не требуют большого uptime, когда дневной простой можно потерпеть, и в крайнем случае, есть сутки, чтобы поднять всё заново на новом оборудовании. Я лишь хочу обратить ваше внимание, на то что может пойти не так.Elaugaste Автор
22.06.2018 17:20Так получилось что наша компания оказывает поддержку круглосуточно. Мониторинг состояния дисков (настроен smartd в шаблонах ОС) отправляет отчеты в поддержку, после чего мы сами сообщаем клиенту о необходимости заменить диск. Замену диска мы выполняем в любое удобное для клиента время. Доказывать ничего не нужно, если диск не исправен это будет видно либо по smart либо при тесте скорости, либо в dmesg.
dollarstar
22.06.2018 15:29Только вы забываете об одном самом главном преимуществе:
Вы точно знаете что выделенные ресурсы будут выделены.
П.С. Столкнулись с VDS на одной из знаменитых площадок. В итоге нагрузка системы не превышала 10 %, но сервер отказывался работать и даже обрывал ssh соединение. Увеличение производительности в 8 раз решило проблему, но нагрузка системы показывала не более 10%. И в такие моменты понимаешь что не стоит всему доверять :(riv1329
22.06.2018 17:03Но ведь всегда можно поменять облачного провайдера. Так что преимущество не абсолютное и, я думаю, не самое главное. Уважающий клиентов провайдер будет отслеживать нагрузку на подсистемы и уж тем более реагировать на жалобы клиентов.
dollarstar
У меня 2 вопроса к автору статьи:
1) Зачем вручную настраивать сеть, если её можно настроить через WEB?
2) Зачем вручную по ssh загружать ISO, если это можно сделать через WEB?
Elaugaste Автор
1. Статья подразумевает невысокий уровень навыков в области администрирования. При использовании интерфейса можно ошибится и «потерять» сервер, а при правке конфига по шаблону этот риск минимален. Безусловно, настройки сети можно делать и через web-морду.
2. Загрузка ISO из интерфейса подразумевает, что образы лежат на локальном компьютере. Нерационально скачивать образ себе на ПК, а уже после этого загружать его на сервер. Кроме того, не всегда скорость и стабильность соединения позволяет делать такие манипуляции. Загружать сразу на сервер будет куда быстрее.
dollarstar
2) Ну в принципе согласен, только не всегда образы можно скачать по прямым ссылкам, но в ваших словах есть рациональное звено. Так что согласен.
1) Для человека не превыкшего работать с CLI проще сделать ошибку в консоле, чем в веб меню.
И последнее: Почему Вы используете 4.х версию, ведь уже есть версия 5.2( в мае вышла)?
Elaugaste Автор
Для скриншотов использовал proxmox который был под рукой, не вижу острой необходимости обновлятся, 4 ветка вполне стабильно работает. При установке из репозитория будет установлена последняя версия, интерфейс почти не отличается потому не считаю что это критично.