Поделитесь опытом. Кто и как реализовывал масштабируемость MSSQL2k. Под масштабируемость подразумевается, что база выросла из сервера. (Федерация серверов, подписка серверов, и т.п.)
Здравствуйте, mike2000, Вы писали:
M> Под масштабируемость подразумевается, что база выросла из сервера.
Что понимается под "База выросла из сервера"?
Нехватает надежности? Производительности? Или просто диски кончились?
Что за проблема, и как хочется ее решить?
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, mike2000, Вы писали:
M>> Под масштабируемость подразумевается, что база выросла из сервера. M>Что понимается под "База выросла из сервера"? M>Нехватает надежности? Производительности? Или просто диски кончились? M>Что за проблема, и как хочется ее решить?
Умножать производительность базы, не наращивая сервер железом и не разбивая базу на логические куски.
Здравствуйте, mike2000, Вы писали:
M>Умножать производительность базы, не наращивая сервер железом и не разбивая базу на логические куски.
Ну и в чем проблема? Берешь и перепроектируешь все "по-правильному".
Здравствуйте, mike2000, Вы писали:
M>Что ты имеешь ввиду под 'по -правильному'?
Имею ввиду "масштабируемо".
От сервера тут мало что зависит, вспоминая незабвенного Тома Кайта, так же как в Оракле, в MSSQL нет опции fast=true. И непосредственно настройками базы "отмасштабировать" можно только в том случае, если они изначально были удручающе кривыми.
Совершенно непонятно что же ты хочешь добиться от сервера, и что ты понимаешь под масштабируемостью.
Есть какие-то конкретные вопросы, или хочется просто "обдискутировать теоретические концепции"?
Здравствуйте, Merle, Вы писали:
M>Есть какие-то конкретные вопросы, или хочется просто "обдискутировать теоретические концепции"?
экий ты "конкретный"
насколько я понял у человека вопрос типа:
есть сервер БД. по некоторым причинам нужно разнести БД на несколько серверов. но! нужна не просто распределенная БД, а такая что...
например чтоб каждая БД имела одинаковую структуру данных и "нарезка" данных проистекала не горизонтально, а вертикально, т.е. на одном сервер половина справочника, на другом вторая половина, на третьем вообще данных в этом справочнике нет. ну и т.д.
... как можно в таких условиях организовать работу с данными? репликация? синхронизация? нотификация?
PS а может я и ошибаюсь
... << RSDN@Home 1.1.3 beta 1 >>
— сколько программистов надо чтобы заменить сгоревшую лампочку?
— сколько не бери, а лампочку не поменять — проблема аппаратная, программным путем не решается...
M>Умножать производительность базы, не наращивая сервер железом и не разбивая базу на логические куски.
вот именно что не разбивать базу на логические куски!!! каждый сервак имеет полный мета-образ базы!!!
у меня щаз примерно тоже самое в разработке, по причинам плохой связи у клиента между сегментами сети (некоторые куски пока просто не соединяются друг с другом) и потребности в "общей" БД.
в идеале надеюсь выкрутиться полумерами и дождаться хорошей связи
... << RSDN@Home 1.1.3 beta 1 >>
— сколько программистов надо чтобы заменить сгоревшую лампочку?
— сколько не бери, а лампочку не поменять — проблема аппаратная, программным путем не решается...
Здравствуйте, _MarlboroMan_, Вы писали:
_MM_>вот именно что не разбивать базу на логические куски!!! каждый сервак имеет полный мета-образ базы!!!
Ну это уже идет наращивание железом.. Так был один сервер, а стало два....
А вообще либо Partitioned Views либо Failover Clustering, либо и то и другое, в зависимости от потребностей и условий.
В твоем случае, если я правильно понял, файловер нужен, то есть по большому счету этим ОС занимается...
Возникла необходимость сделать кластер. Т.к. кластерное решение microsoft позволяет объединить максимум 4 машины, то это решение только для отказоустойчивости. А кластер это не только отказоустойчивость, но и самый простой способ масштабирования базы. Масштабирование при 4 машинах не очень — то масштабное. А мне надо.. положим 10.
есть у меня подозрение, что в данном форуме не наберется и 10 человек которые имеют опыт реального маштабирования БД пусть даже всего под кластер из 4-х машин....
... << RSDN@Home 1.1.3 beta 1 >>
— сколько программистов надо чтобы заменить сгоревшую лампочку?
— сколько не бери, а лампочку не поменять — проблема аппаратная, программным путем не решается...
Здравствуйте, mike2000, Вы писали:
M> Масштабирование при 4 машинах не очень — то масштабное. А мне надо.. положим 10.
Ну, как я уже говорил, есть два типа конфигурации, которые поддерживаются MSSQL: failover cluster, работающий на основе Microsoft Clustering Service и sclaed-out cluster (на базе distributed partitioned views), которому уже не нужна никакая специальная поддержка со стороны OS. Причём эти конфигурации не являются взаимоисключающими — они легко могут комбинироваться.
Примерно такая конструкция и работала в tpc тесте, если мне память не изменяет на 20 машинах.
На failover-кластере можно развернуть виртуальный кластерный сервис, который специальным образом конфигурируется так, чтобы он работал на дисках, которые видны со всех узлов кластера. SQL Server, при соответствующей установке, является виртуальным кластерным сервисом.
В сочетании со scaled-out кластерами, расположенными в узлах failover-кластера, получается вполне себе отказоустойчивая высокопроизводительная конфигурация, на любом количестве серверов.
Мы уже победили, просто это еще не так заметно...
