Мы решили запустить свой игровой хостинг и уже вплотную подобрались к планированию архитектуры. Некоторые вопросы самостоятельно решить не получается — взываем к хабраразуму.
Основной вопрос пока такой: есть физический сервер с debian на борту на нем нужно держать энное количество клиентских игровых серверов (один сервер — один процесс). И каким-то образом гибко ограничивать в ресурсах каждый процесс. Гугление вывело на утилиты nice и cpu_limit, но еще более углубленное гугление выдало многочисленные проблемы с этими утилитами, да и не совсем понятно, как ими управлять (допустим, есть 5 клиентов, значит на каждый клиент мы (грубо) отдаем 20% процессорного времени и 20% от оперативки. Добавляется еще один клиент и нужно как-то без перезапуска процессов изменить эти квоты).
Была мысль сделать свой суперлегковесный дистрибутив и сделать несколько виртуальных машин на базе qemu, но тогда не совсем понятно, каким образов управлять процессом игрового сервера внутри гостевой машины — перезапуск, например. Перезапускать полностью виртуальную машину тоже не очень хочется — будет система мониторинга серверов, которая пытается перезапустить упавшие инстансы. Можно было бы внести скрипт запуска игрового сервера в автозапуск, но не совсем понятно, что с ним делать, если он упадет и, допустим, прочесть логи из клиентской машины.
Словом, сказываются некие пробелы в администрировании unix-систем, которые самостоятельно не получается заполнить. Буду рад любым идеям и предположениям, спасибо!
Погугли побольше инфы по кличевикам «Xen», «OpenVZ», «linux containers».
Параграфы с «откровенно-рекламными хвальбами» смело пропускай, а вот там где описываются ограничения и трудности читай внимательно и с пристрастием, думая при этом о своей системе.
Думаю прочитанной инфы (обращай внимание на плюсы и минусы) должно хватить для того, чтобы принять взвешанное решение о том как устроить архитектуру.
На что обращать внимание: Да, не забывай, что помимо того, что какое-то решение распрекрасно, как ты конкретно будешь администрировать полученную систему предлагаемыми средствами.
Также (если ты не хочешь заморачиваться с виртуализацией, хотя контейнеры это почти не виртуализация) погугли еще «cpu affinity»,«ionice»,«ulimit».
А вообще, если ты поподробнее опишешь задачу как ты ее представляешь в голове, возможно получишь более конкретные советы. Потому как, не бывает универсальных решений. И то что у кого-то хорошо работало легко может херово работать у тебя.
Если характеристика потребления ресурсов изменяется условно «плавно», к примеру, вы можете гарантировать по условию, что частота экстремумов графика не будет превышать 1 герц — можно использовать AVG. Простой скрипт, на BASH или PERL, который будет ренайсить процессы в зависимости от потребления ресурсов.
Если возможно более резкое потребление ресурсов — эффективных решений нет. Виртуализация не поможет — повесить машину, на которой находится виртуалка, в целом ряде популярных случаев — не проблема. В качестве теста пробуйте, к примеру, масштабировать imagemagick convert много картинок по регулярке. Этим экспериментом как-то повесили известного хостинг-провайдера, даром что запускалось через виртуоззо.
Оффтоп. FreeBSD вообще не умеет управлять потреблением ресурсов в реальном времени, пройденный этап — даже не смотрите в ее сторону. С Debian и Ubuntu у меня и коллег это получалось.
Решение — пробуйте спрогнозировать нагрузку и спланировать ресурсы под вариант-максимум. Как показывает практика, это действительно эффективный подход. Если упираетесь в финансирование — пересматривайте бизнес-модель. У Google это, кстати, получилось…
Virtuozo — это набор кривых патчей на ядро, писаных какими-то индусами. К виртуализации сие чудо отношения вообще никакого не имеет, там всего-лишь продвинутый chroot.
Советую сравнить kvm и bhyve (нативный контейнер на BSD с лимитированием по ядрам и ram) в производительности и масшабируемости для серьёзных продакшен. Сам использую на zfs zraid1 для внепшотинга и надежности...
Всем спасибо за ответы, к сожалению, адекватного нашим задачам, решения получить не удалось, поэтому будет не самый желательный вариант — оставим всё без ограничений (вероятность утечек памяти, например, минимальна по словам разработчиков серверных приложений). И просто будет активный мониторинг, который будет предупреждать админов о заканчивающихся ресурсах
