Firebird 1.5 на HA-cluster (high-availaibility)
Модератор: kdv
Firebird 1.5 на HA-cluster (high-availaibility)
Hi! Вопрос- кто-нибудь поднимал сервис Firebird 1.5 на таких серверах?Нужна просто супер наженое хранилище в режиме 24x7 . HA в режиме как например http://gazette.linux.ru.net/rus/articles/clusters.html устраивает.Есть ли опыт запуска базы Firebird?
не будет тебе база работать в режиме 24x7, и собственно, не должна.
читай
http://www.ibase.ru/devinfo/doc_calford_1.htm
да, кстати, кластер такого типа (разделяемый диск) должен работать с IB/FB, только надо понимать, что на самом деле аварийное завершение IB/FB, т.е. отказ работающего с БД узла кластера, может привести к порче БД (как и обычный рестарт сервера во время работы). Соответственно продолжать работать с БД можно будет только после того, как базу проверят gfix-ом.
И кроме того, все текущие коннекты при сбое оборвутся и т.п.
Т.е. надо понимать, что кластеризация БД это намного сложнее чем кластеризация тупого файлового хранилища, как в упомянутой тобой статье.
И кластеризация БД должна в первую очередь поддерживаться именно самим сервером БД, чего у нас пока нет и неизвестно, будет ли.
черт, третий раз редактирую письмо В общем, о кластеризации клиент-серверной архитектуры можно даже не думать. О "кластере" в том или ином виде можно думать делая трехзвенную систему (клиенты, сервер приложений, сервер БД).
читай
http://www.ibase.ru/devinfo/doc_calford_1.htm
да, кстати, кластер такого типа (разделяемый диск) должен работать с IB/FB, только надо понимать, что на самом деле аварийное завершение IB/FB, т.е. отказ работающего с БД узла кластера, может привести к порче БД (как и обычный рестарт сервера во время работы). Соответственно продолжать работать с БД можно будет только после того, как базу проверят gfix-ом.
И кроме того, все текущие коннекты при сбое оборвутся и т.п.
Т.е. надо понимать, что кластеризация БД это намного сложнее чем кластеризация тупого файлового хранилища, как в упомянутой тобой статье.
И кластеризация БД должна в первую очередь поддерживаться именно самим сервером БД, чего у нас пока нет и неизвестно, будет ли.
черт, третий раз редактирую письмо В общем, о кластеризации клиент-серверной архитектуры можно даже не думать. О "кластере" в том или ином виде можно думать делая трехзвенную систему (клиенты, сервер приложений, сервер БД).
Я прошу прощения, но значит ли это - что IB можно масштабировать только репликацией?
У нас проблемы с производительностью и на данный момент ищем пути решения. Стоит W2k3 IB7, база около 400 Мб, одновременных клиентов с ней работает окло 20, сидят в терминале. Сам сервак конечно старый: 2*1GHz; RAM 1,5Gb; HDD 36Gb (SCSI 160). По наблюдениям процы забиты почти всегда на 100%, а средне статистическое около 90%, все тормозит кошмарно. И вопрос в том каким путем идти: закупать нехилый сервак (4*3Ghz...) или пытаться повесить на кластер. У нас конечно не стоит задача 24*7, но в рабочее время база должна быть доступна. Может порекомендуете что нибудь?
У нас проблемы с производительностью и на данный момент ищем пути решения. Стоит W2k3 IB7, база около 400 Мб, одновременных клиентов с ней работает окло 20, сидят в терминале. Сам сервак конечно старый: 2*1GHz; RAM 1,5Gb; HDD 36Gb (SCSI 160). По наблюдениям процы забиты почти всегда на 100%, а средне статистическое около 90%, все тормозит кошмарно. И вопрос в том каким путем идти: закупать нехилый сервак (4*3Ghz...) или пытаться повесить на кластер. У нас конечно не стоит задача 24*7, но в рабочее время база должна быть доступна. Может порекомендуете что нибудь?
гарантирую, что проблема с производительностью в приложениях и в терминале, а не в сервере.У нас проблемы с производительностью и на данный момент ищем пути решения. Стоит W2k3 IB7, база около 400 Мб, одновременных клиентов с ней работает окло 20, сидят в терминале.
размер базы по нынешним меркам - мизер. количество клиентов - тоже.
И вам просто не хватает мощности процессоров. еще я бы посоветовал развести терминальный сервер и сервер БД по разным компьютерам.
Собственно, начните с TaskManager - какие процессы занимают сколько памяти, насколько загружают процессоры. Если причина в IB - посмотрите в PerfMon что происходит на сервере.
Разбирательства с производительностью тут максимум на полчаса.
пока - да.IB можно масштабировать только репликацией?
Я, канешна, небольшой спец в IB7, но до ноября у меня на двух таких же процессорах распрекрасно жили около сотни коннектов FB-классики на 10 гиговой базе, по-настоящему активно изменяющих данные тоже около 20, остальные на чтение. И жили бы дальше, если бы 5-летнее железо просто не сдохло. Имхо тут не хватает мощности не процессоров, а писателей запросов. В смысле оптимизированных запросов. Мож ещё и создавателей струкутур, чтоб можно было писать оптимизированые запросы. Или таки действительно процы отжирает что-то другое.kdv писал(а): И вам просто не хватает мощности процессоров.
тогда - да. как бы исходный случай не оказался тем, что упомянут в www.ibase.ru/devinfo/getstat.htm, в "Когда администратор БД ничего...".до ноября у меня на двух таких же процессорах
Я посмотрел статистику использования основных ресурсов: за процы борются все кому не лень - сам IB, клиенты (клиентские проги) и еще один - spoolsv.exe который есть служба печати.
С мозгами несколько запутанее: клиентские програмы кушают от 13 до 20 Мб на чела + системные процессы терминальной сессии, IB занимает от 80 до 150 Мб. Если взглянуть на общий расход оперативки то всего 1,5 Гб свободно от 400 до 600, но при этом файл подкачки занят на 500 Мб мин., и до 1,6 Гб!!? Это выходит и мозгов маловато? Ну а вообще видимо надо разделять клиентов и IB по сервакам.
Есть в связи с этим вопрос: На какую машину ставить предпочтительней IB на новый сервак 2*3,4 ГГц(Xeon)/FSB800/RAM от 2Gb, или есть более старый 4*1,5ГГц(Xeon)/FSB400/RAM 2Gb?
С мозгами несколько запутанее: клиентские програмы кушают от 13 до 20 Мб на чела + системные процессы терминальной сессии, IB занимает от 80 до 150 Мб. Если взглянуть на общий расход оперативки то всего 1,5 Гб свободно от 400 до 600, но при этом файл подкачки занят на 500 Мб мин., и до 1,6 Гб!!? Это выходит и мозгов маловато? Ну а вообще видимо надо разделять клиентов и IB по сервакам.
Есть в связи с этим вопрос: На какую машину ставить предпочтительней IB на новый сервак 2*3,4 ГГц(Xeon)/FSB800/RAM от 2Gb, или есть более старый 4*1,5ГГц(Xeon)/FSB400/RAM 2Gb?
IB7, если купленный, должен быть 7.1 SP2 или 7.5.1, и иметь дополнительные процессорные лицензии, если его ставить на 2-4 процессорную машину.
я бы посоветовал взять perfmon с sysinternals.com, и посмотреть, сколько же реально грузит проц например IB и остальные. Если IB - меньше чем все остальное, то это "все остальное" и перенести на новый сервак.
я бы посоветовал взять perfmon с sysinternals.com, и посмотреть, сколько же реально грузит проц например IB и остальные. Если IB - меньше чем все остальное, то это "все остальное" и перенести на новый сервак.