Кластерные возможности firebird
Модераторы: kdv, Alexey Kovyazin
Кластерные возможности firebird
Может ли fiebird (1.5 и выше) использоваться в кластерах с балансировкой нагрузки? Судя по результатам опытов - не может. Какие есть мнения на этот счет?
Ну почему ж без опытов? Я развернул линукс кластер с ядром openmosix'а. Идея просто прелесть. Раз классик-сервер запускает процесс на каждое соединение, то почему не заставить этот процесс мигрировать на друрой узел кластера и выполняться там? Таким образом я смогу сбивать пики нагрузки на сервер. Но оказалось процессы firebird'а не могут мигрировать. Не мигрирующими они оказываются потому, что якобы используют некий файл с качестве разделяемой памяти.
Так вот вопрос по архитектуре firebird'a: если в режиме классик-сервер ответственность за работу с файлом БД лежит на каждом серверном процессе (fb_inet_server), то зачем запускать некий lock-менеджер (fb_lock_mgr) для блокировки файла БД?
Макс. что мне удалось сделать - написать враппер, чтобы процесс fb_inet_server запускался принудительно в мигрирующем состоянии, но firebird уперся и запускает два процесса - один мигрирующий, а другой - нет. Вот такая firebird козлиная морда. Вообще удивительно, даже у MySQL есть проект по клатеризации, а у firebird нет и не придвидится.
Так вот вопрос по архитектуре firebird'a: если в режиме классик-сервер ответственность за работу с файлом БД лежит на каждом серверном процессе (fb_inet_server), то зачем запускать некий lock-менеджер (fb_lock_mgr) для блокировки файла БД?
Макс. что мне удалось сделать - написать враппер, чтобы процесс fb_inet_server запускался принудительно в мигрирующем состоянии, но firebird уперся и запускает два процесса - один мигрирующий, а другой - нет. Вот такая firebird козлиная морда. Вообще удивительно, даже у MySQL есть проект по клатеризации, а у firebird нет и не придвидится.
Классик обязан координировать доступ процессов к файлу БД через менеджер блокировок. Переписав этот менеджер (например, на основе distributed lock manager от IBM), получишь кластерный Firebird. Желющих такого кот наплакал, потому этим никто и не занимается. Можешь заплатить деньгу и получить в скором времени результат 

"желающие" и "опрос" - как бы, разное. Желающие спрашивают, например как ты, а в опросе скажут "да" просто от балды.Желающих мало? Вы проводили опрос?
Так что, проще 4-х процессорную машину поставить. То есть, те кто хочет масштабируемости, предполагают затраты на железо. А ставить 2 машинки в кластере вместо двухпроцессорной машины - это я не знаю, на анекдот похоже.
Платить - в Firebird Foundation. Сначала закинуть вопрос, потом тебе скажут сколько это может стоить.
to kdv:
>А ставить 2 машинки в кластере вместо двухпроцессорной машины - это я не знаю, на анекдот похоже.
Да нет, это не анекдот. Это правда жизни.
>Так что, проще 4-х процессорную машину поставить. То есть, те кто хочет масштабируемости, предполагают затраты на железо
Это не масштабируемость - это брутофорс в чистом виде.
>А ставить 2 машинки в кластере вместо двухпроцессорной машины - это я не знаю, на анекдот похоже.
Да нет, это не анекдот. Это правда жизни.
>Так что, проще 4-х процессорную машину поставить. То есть, те кто хочет масштабируемости, предполагают затраты на железо
Это не масштабируемость - это брутофорс в чистом виде.
Почему же вычислительный кластер это брутофорс? Нагрузка возрасла - стало быть нужно перераспределить ее по кластеру. В этом случае все сервера работают без напрягов.
В случае 4-х голового сервера 90% времени у процессоров будет утилизация 1%. Поверте - у меня есть таких парочка.
Дело не в числе пользователей (у меня до 80-100 одновременных подключений) , а в задачах. У меня большая проблема - это выборка координатной информации из базы.
В случае 4-х голового сервера 90% времени у процессоров будет утилизация 1%. Поверте - у меня есть таких парочка.
Дело не в числе пользователей (у меня до 80-100 одновременных подключений) , а в задачах. У меня большая проблема - это выборка координатной информации из базы.