Помогите с логической задачей

Доброго времени суток. Прошу у вас помощи в решении скорее всего для вас простой логической задачи.


Начну издалека. В планах для собственных клиентов поднять хостинг с биллингом. Для этой задачи вполне подходит Vesta CP - достаточно функциональный продукт с очень хорошим дизайном (за это отдельное спасибо разработчикам и дизанерам) и достаточным API. Но вот с терпимыми по внешнему виду биллингами огромный трабл. Плюс есть особенности местного эквайринга. В общем биллинг хотим пилить сами - выбора нет, да и просто интересно. В последствии хотим торговать хостингом для всех. Рано или поздно возможности сервера по вертикальному масштабированию закончатся и придется задумываться о горизонтальном.


Теперь сама задача.

Биллинг общается с панелью через API. Мы купим второй сервер, поставим на него Vesta CP.

Как реализовать в биллинге логику того, на каком сервере у конкретного клиента будет создаваться аккаунт согласно связке тариф-шаблон и с каким сервером в последствии работать?


И второй вопрос. Есть ли какие-либо решения, чтобы автоматически определять загрузку ресурсов сервера и выбирать самый свободный?


Заранее спасибо за ваши комментарии и решения.

Вы смотрите срез комментариев. Показать все
1
Автор поста оценил этот комментарий

Сервер в данном случае это просто железка с ресурсами. Аккаунты обычно хранят в единой базе.


Т.е. по-хорошему логика должна быть другой: инфа, с каким сервером работать и где лежат сайты Васи Пупкина, надо хранить вместе с учёткой и прочими сведениями. Ибо серверов может быть и 200 штук - запаритесь логику переписывать и данные переносить.


Решений для load balancing'а в сети полно, начиная с той же piranha - гугл в помощь.

раскрыть ветку (13)
1
Автор поста оценил этот комментарий
То есть при покупке услуги просто сохранаяем айди сервера, на котором создаем? А выбирается это балансировщиком? Я правильно понял?


По поводу гугл в помощь. Уже пытался. Все что вижу по сабжу - это nginx и разнесение типа контента по разным серверам.

раскрыть ветку (12)
Автор поста оценил этот комментарий

Не так просто, но в общем, да. Клиент приходит, регается, оплачивает услугу, мы сохраняем сведения о нём в базе, выбираем ему первый сервер по ответу от балансера и сохраняем ID хоста туда же, в его запись в базе. Дальше зависит от фантазии и желания - дополнительные слоты, миграции сайтов и прочие плюшки :)

раскрыть ветку (11)
Автор поста оценил этот комментарий
Как думаете, по какому критерию определять загруз сервера? По средней нагрузке за определенный период, по текущей нагрузке, по количеству аккаунтов, по количеству свободного места или по всем этим критериям сразу?
раскрыть ветку (1)
Автор поста оценил этот комментарий

Это уже конкретика, зависит как от серверов, так и от специфики самой нагрузки. Кому-то нужно много дискового места, кому-то критична скорость работы, а кому-то - много памяти.

Автор поста оценил этот комментарий
Почему-то отталкивал это решение, потому что оно казалось слишком очевидным. :) Осталось теперь определиться с балансировщиком. Ксати, как думаете, балансер должен находиться где-то на независимом сервере, например там же где и вторичный DNS?
раскрыть ветку (8)
Автор поста оценил этот комментарий

Балансер (например, Citrix NetScaler) должен стоять перед серверами. Также это может быть кластер из двух и более балансеров, в принципе, это не принципиально.

Типа как тут описывается: https://habrahabr.ru/post/308292/

раскрыть ветку (2)
Автор поста оценил этот комментарий
А есть ли ему open source аналоги?
раскрыть ветку (1)
Автор поста оценил этот комментарий

На хабре в комментариях народ понаписал всякого. Я лично кроме MS NLB Clustering использовал только NetScaler.

Автор поста оценил этот комментарий

Всё гениальное - просто :) обычно балансер на входе вешают, камрад sergioperez написал уже. Желательно, конечно, на отдельном хосте, но на начальном этапе это, скорее, финансовый вопрос.

Ну и тут есть нюанс: вам всё-таки придётся завязывать балансер на работу самой системы - никому не понравится зайти в панель управления и не найти свои сайты, потому что балансер тебя внезапно не туда перекинул. Т.е. простые решения, типа RR DNS, не подойдут - нужна полноценная софтина, которая сможет общаться и с вестой, и с биллингом.

раскрыть ветку (4)
Автор поста оценил этот комментарий
А если оставить балансировку только на момент заказа услуги? А пакетную миграцию учеток оставить ручной, которую любезно для нас реализовала VestaCP? В каком месте в таком случае нас ожидает ад? :)
раскрыть ветку (3)
Автор поста оценил этот комментарий

Кстати, а на Вашей системе случайно нету изкоробочного варианта LB-кластеризации? Потому что если нет, то все плохо кмк. Рано или поздно действительно придется расти вширь, и ручное\полуручное распределение ресурсов, миграция и вот это вот все кого угодно в могилу загонят.

раскрыть ветку (1)
Автор поста оценил этот комментарий
Вот вашим добрым словом и пытаемся изобрести LB. :)
Автор поста оценил этот комментарий

Для начала да, так и нужно - сайт же один раз размещаем. Динамика, вроде "хост упал - сайты переехали", это следующий этап, он существенно сложнее, т.к. нужна полноценная интеграция между частями системы. Ну, я выше уже писал.

Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку