Я веду небольшой бизнес по размещению игровых серверов для нишевой игры и арендую выделенные серверы для снижения затрат, на каждом из которых работает множество экземпляров игровых серверов. Игровые серверы можно создавать и удалять в любое время, и мне нужно решить, на какой машине будет установлен игровой сервер при его создании. После создания сервера его можно перенести на другую машину, если пожелает администратор.
Я работаю над улучшением бэкэнда, и меня больше всего беспокоит распределение игровых серверов между машинами. Сейчас я использую наивный алгоритм:
Я назначаю каждой машине вес, примерно пропорциональный объему ЦП / ОЗУ.
Чтобы очень приблизительно приблизительно ресурсы, используемые каждым игровым сервером, я назначаю каждому игровому серверу вес в зависимости от максимального количества игроков, которые могут играть на этом сервере.
Когда кто-то создает игровой сервер или запрашивает перенос существующего игрового сервера на другую машину, я вычисляю для каждой машины следующее:
(сумма весов игровых серверов на машине) / (вес машины)
и я выделяю игровой сервер машине с наименьшим результатом.
Меня больше всего беспокоит расчет весов для каждого игрового сервера. Есть много разных факторов, которые определяют использование ресурсов, таких как количество игроков, которые в данный момент находятся в сети, установленные моды, настройки сервера и т. Д. В результате я не думаю, что возможно назначить точный вес на основе свойств сервера, даже если Я составил более сложную формулу по сравнению с тем, что я сейчас делаю с максимальным количеством игроков.
Я думаю, что было бы более эффективно выделять серверы на основе эмпирических данных об использовании ресурсов либо с помощью некоторой формы программного обеспечения для балансировки нагрузки, либо с помощью специального решения. Но я не уверен, как это сделать, и я также понимаю, что могут быть совершенно разные подходы, которые я не рассматривал, поэтому любые советы будут очень благодарны!
Вы можете стандартизировать узел, получив фиксированное количество игр разного размера, и многократно клонировать этот узел. Однако это работает только в том случае, если ваши шаблоны использования относительно постоянны.
Кластерное программное обеспечение с размещением по загруженности существует. Для неизолированных прикладных программ, для экземпляров контейнеров или для полных виртуальных машин. Вы не упомянули контейнеры или что-то еще, поэтому я предполагаю, что они не используются. Вы также не упомянули платформу операционной системы, поэтому предположим, что Linux.
Возьмем, к примеру, кластеры Pacemaker, такие как RHEL HA. Ресурсы в таком кластере могут иметь определенное использование ресурсов. Таким образом, у ваших больших и малых серверов разные требования к процессору и памяти, и они расположены соответствующим образом. В качестве бонуса вы можете восстановиться после сбоя узла и перенести ресурсы на другой узел. На слайде с минусом кластеры высокой доступности сложно построить, и их нужно протестировать, чтобы убедиться, что они работают правильно.
Если бы у вас был контейнер для развертывания, Kubernetes мог бы управлять им в кластере. Опять же, довольно сложно получить эти функции.
Вы можете пересмотреть подход к использованию голых узлов и предоставить каждому серверу собственную виртуальную машину. Гипервизор может быть запущен вами или каким-либо облачным провайдером. В любом случае найдите оптимальное количество vCPU и vRAM для различных размеров. Размещение на узлах выполняется за вас в облаке с помощью такого продукта, как VMware DRS, или вручную.