Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Вопрос по архитектуре WSFC, always on, ag  [new]
Alex Molskiy
Member

Откуда:
Сообщений: 25
Доброго дня.

Вопрос изучаю 2 дня, почитал течнет, на форуме, смысл технологий понятен, но остались вопросы.

Дано:
12 серверов mssql 2003+ (физических), win 2003+
На каждом есть всего по 1 бд
Каждая бд использует максимум 20% ресурсов сервера
Самые важные из этих бд - это 2 бд 1с
Для каждой бд делается бэкап

Ситуация ужасная, разные версии, неудобство управления, слишком много ресурсов в холостую

Задача:
Расположить все бд на одном мощном сервере, обеспечить клиентам прозрачный автоматической переброс на запасной сервер в случае отказа работы базы или сервера полностью. Дополнительно, но не обязательно, иметь возможность распределения запросов по серверам, как это работает в sybase mpp

Вопрос:
1. Как этого достичь? Я запутался в возможностях WSFC, always on и always on ag, что из этого нужно использовать?
4 ноя 13, 13:01    [15074010]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре WSFC, always on, ag  [new]
komrad
Member

Откуда:
Сообщений: 5735
Alex Molskiy,

вы сначала определитесь с сиквелами - "12 серверов mssql 2003+ (физических)" - такого сиквела не было
4 ноя 13, 13:10    [15074034]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре WSFC, always on, ag  [new]
aleks2
Guest
Если закрыть глаза на бред с версиями MS SQL.

То налицо самая надежная конфигурация: адын физический сервер = адын база.

Alex Molskiy
Ситуация ужасная, разные версии, неудобство управления, слишком много ресурсов в холостую

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

Alex Molskiy
Задача:
Расположить все бд на одном мощном сервере, обеспечить клиентам прозрачный автоматической переброс на запасной сервер в случае отказа работы базы или сервера полностью. Дополнительно, но не обязательно, иметь возможность распределения запросов по серверам, как это работает в sybase mpp

1. Вы ужо определитесь: один или несколько?
2. Насчет недостатков "одного" я уже сказал.
3. "прозрачный автоматической переброс" - кластер штоле? Дык дорого и не нужно. Опять же, если база подохнет - кластер не спасет.
4. Отладьте систему восстановления бэкапа на "другой сервер" и "ручное" переключение клиента - и будет вам щастье... незадорого.
4 ноя 13, 13:41    [15074103]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре WSFC, always on, ag  [new]
Spartakich
Member

Откуда: Riga
Сообщений: 380
Alex Molskiy,

AlwaysON или Mirroring.

в AlwaysON read запросы можно перебрасывать на второй сервер.
в Mirroring на второй сервер можно пускать репортинг (Enterprise version)
4 ноя 13, 13:51    [15074117]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре WSFC, always on, ag  [new]
Alex Molskiy
Member

Откуда:
Сообщений: 25
komrad
Alex Molskiy,

вы сначала определитесь с сиквелами - "12 серверов mssql 2003+ (физических)" - такого сиквела не было


Опечатался
4 ноя 13, 14:18    [15074234]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре WSFC, always on, ag  [new]
Alex Molskiy
Member

Откуда:
Сообщений: 25
aleks2
Если закрыть глаза на бред с версиями MS SQL.

То налицо самая надежная конфигурация: адын физический сервер = адын база.

Alex Molskiy
Ситуация ужасная, разные версии, неудобство управления, слишком много ресурсов в холостую

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

Alex Molskiy
Задача:
Расположить все бд на одном мощном сервере, обеспечить клиентам прозрачный автоматической переброс на запасной сервер в случае отказа работы базы или сервера полностью. Дополнительно, но не обязательно, иметь возможность распределения запросов по серверам, как это работает в sybase mpp

1. Вы ужо определитесь: один или несколько?
2. Насчет недостатков "одного" я уже сказал.
3. "прозрачный автоматической переброс" - кластер штоле? Дык дорого и не нужно. Опять же, если база подохнет - кластер не спасет.
4. Отладьте систему восстановления бэкапа на "другой сервер" и "ручное" переключение клиента - и будет вам щастье... незадорого.


1. Про один сервер имелось ввиду основной, второй подразумевался как резервный
3. Так а на кой черт все эти финтифлюшки нужны, если они не обеспечивают переброс клиентов на второй сервер, если база подохнет?
Электричество особо не собираемся экономить, но когда на сервере есть всего 1 база в 200мб, зачем их таких больше десятка держать?
4 ноя 13, 14:24    [15074253]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре WSFC, always on, ag  [new]
aleks2
Guest
Alex Molskiy
но когда на сервере есть всего 1 база в 200мб, зачем их таких больше десятка держать?

Затем,что это обеспечивает
1. Почти максимальную достижимую надежность. (ну AlwaysON, канешно, круче... но это заметно сложнее поддерживать)
2. Изолирует клиентов и их базу от влияния других.

ЗЫ. А финтифлюшки - это для разного...
4 ноя 13, 14:52    [15074350]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре WSFC, always on, ag  [new]
SERG1257
Member

Откуда:
Сообщений: 2873
Во первых озвучте конечную версию и редакцию SQL Server
Во вторых озвучте свои страхи - от чего защищатся будете.
Далее на базе этого расписывается план подбираются DR или HA согласно пункту первому.

автор
3. Так а на кой черт все эти финтифлюшки нужны, если они не обеспечивают переброс клиентов на второй сервер, если база подохнет?
Переброс обеспечивает либо кластер либо сам клиент в строке подключения
4 ноя 13, 20:51    [15075571]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить